One document matched: draft-perkins-mext-hatunaddr-01.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="no"?>
<!-- rfc ipr="pre5378Trust200902" docName='draft-perkins-mip4-authreq-01.txt'-->
<rfc ipr="trust200811" docName='draft-perkins-mext-hatunaddr-01.txt' >
<?rfc symrefs="no"?>
<front>
<title abbrev="Alternate Home Agent Tunnel">
Alternate Tunnel Source Address for Home Agent</title>
<author initials="C." surname="Perkins" fullname="Charles E. Perkins">
<organization>Tellabs Inc.</organization>
<address>
<postal>
<street>3590 North, 1st Street, Suite 300</street>
<city>San Jose</city>
<region>CA 95134</region>
<country>USA</country>
</postal>
<email>charliep@computer.org</email>
</address>
</author>
<date month="August" year="2011" />
<area>Internet</area>
<workgroup>Mobility Extensions for IPv6 [mext]</workgroup>
<keyword>Mobility</keyword>
<keyword>Proxy MIP</keyword>
<keyword>Hierarchical MIP</keyword>
<keyword>Tunneling</keyword>
<abstract>
<t>
Widely deployed mobility management systems for wireless
communications have isolated the path for forwarding data
from the control plane signaling for mobility management.
To realize this requirement with Mobile IP requires that
the control functions of the home agent be addressable at
a different IP address than the source IP address of the
tunnel between the home agent and mobile node. Similar
considerations hold for mobility anchors implementing
Hierarchical Mobile IP or PMIP.
</t>
</abstract>
</front>
<middle>
<section anchor='intro' title='Introduction'>
<t>
<xref target="RFC5944">Mobile IP</xref> and
<xref target="RFC6275">Mobile IPv6</xref> associate the Home Agent's
IP address both with the target of control messages form
the mobile node, and the source IP address for packets
tunneled to the mobile node from the Home Agent. However,
in most contemporary commercial mobility management
systems, these two IP addresses are not the same. Thus,
Mobile IP has been seen as missing an important feature,
and perhaps for that reason not fully integrated into the
mobility management systems for commercial wireless ISPs.
In this document, we specify a simple extension for
Mobile IPv6 to enable a mobile node to receive packets
tunneled to it from an IP address different from the
IP address used for sending Binding Updates and other
control messages from Mobile IPv6. The extension is
applied to the Binding Acknowledgement message, which
is expected to be processed by the mobile node before any
packets are tunneled to the mobile node from the home agent.
Almost identical considerations hold for Mobile IPv4,
<xref target="RFC5213">Proxy MIP</xref>,
<xref target="RFC5380">Hierarchical Mobile IP</xref>.
Similar extensions to the registration messages in those
MIP variations will also be specified in this document.
</t>
</section>
<section anchor='alt_ha'
title='Alternate Home Agent Tunnel Address for Mobile IPv6'>
<t>
The "Alternate Home Agent Tunnel Address" option may be included
as an extension to the Binding Acknowledgement message.
The Alternate Home Agent Tunnel Address option has an alignment
requirement of 8n+6. Its format is as follows:
</t>
<figure><artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Alternate Home Agent Tunnel Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork></figure>
<t>
The "Alternate Home Agent Tunnel Address" option may be included
as an extension to the Binding Acknowledgement message. When the
mobile node receives Binding Acknowledgement message including
the Alternate Home Agent Tunnel Address, it should enable decapsulation
for packets arriving from that alternate address. Moreover, the
mobile node MUST then use the alternate HA tunnel IP address whenever
tunneling packets
(using <xref target='RFC2473'>IPv6-in-IPv6 encapsulation</xref>)
through that the home agent.
</t>
<t>
If the Binding Acknowledgement message has the 'P' set, it is
being sent from the LMA to the MAG, and is called a
"Proxy Binding Acknowledgement" message. In this case, the
"Alternate Home Agent Tunnel Address" option may also be included.
When the MAG receives such a Proxy Binding Acknowledgement message
including the Alternate Home Agent Tunnel Address, it should enable
decapsulation for packets arriving from that alternate address.
Moreover, the MAG MUST then use the alternate HA tunnel IP address
whenever tunneling the mobile node's packets to that LMA.
</t>
<t>
If the mobile node sets the 'M' bit in the Binding Update,
then the effect is to register a regional care-of address with
the local MAP as defined in
<xref target="RFC5380">Hierarchical Mobile IP</xref>.
In this case, Binding Acknowledgement message may also include
the "Alternate Home Agent Tunnel Address" option.
When the mobile node receives such a Binding Acknowledgement message
including the Alternate Home Agent Tunnel Address, it should enable
decapsulation for packets arriving from that alternate address.
Moreover, the mobile node MUST then use the alternate HA tunnel
IP address whenever tunneling the mobile node's packets to that MAP.
</t>
</section>
<section anchor='alt_ha_v4'
title='Alternate Home Agent Tunnel Address for Mobile IPv4'>
<t>
The "Alternate Home Agent Tunnel Address" option may be included
as an extension to the Registration Reply message.
Its format is as follows:
</t>
<figure><artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length = 6 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alternate IPv4 Home Agent Tunnel Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork></figure>
<t><list style="hanging">
<t hangText="Reserved"><vspace blankLines="1"/>
Sent as zero; ignored on reception.
</t>
<t hangText="Alternate IPv4 Home Agent Tunnel Address">
<vspace blankLines="1"/>
The Alternate IPv4 Home Agent Tunnel Address required
by this home agent.
</t>
</list></t>
<t>
The home agent may include the
"Alternate IPv4 Home Agent Tunnel Address"
as an extension to the Registration Reply message. When the
mobile node receives Registration Reply message including
the Alternate IPv4 Home Agent Tunnel Address, it MUST enable
decapsulation for packets arriving from that alternate address.
Moreover, the mobile node MUST then use the alternate HA tunnel
IP address whenever tunneling packets through that the home agent.
</t>
</section>
<section anchor='sec' title='Security Considerations'>
<t>
This document does not introduce any security mechanisms,
and does not have any impact on existing security mechanisms.
Since the Binding Acknowledgement and Registration Reply messages
to the mobile node are required
to be secured, including the Alternate Home Agent Tunnel Address
extension will not enable a malicious node to create any disruption
to the desired tunneling behavior along the data path.
</t>
</section>
<section anchor='iana' title='IANA Considerations'>
<t>
This document creates a new Mobility Option for Mobile IPv6
that can be included in the Binding Acknowledgement message.
The protocol number for this new Mobility Option, the
"Alternate Home Agent Tunnel Address" option, should be
allocated from the space of Mobility Options for Mobile IPv6.
</t>
<t>
This document creates a new Extension for Mobile IPv4
that can be included in the Registration Reply message.
The protocol number for this new Extension, the
"Alternate IPv4 Home Agent Tunnel Address" option, should be
allocated from the space of non-skippable extensions for Mobile
IPv4 (i.e., a number within the range 0--127).
</t>
</section>
</middle>
<back>
<references title='Normative References'>
<?rfc include='reference.RFC.2473.xml'?>
<?rfc include='reference.RFC.5944.xml'?>
<?rfc include='reference.RFC.5213.xml'?>
<?rfc include='reference.RFC.5380.xml'?>
<?rfc include='reference.RFC.6275.xml'?>
</references>
<!--
<references title="Informative References">
</references>
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:55:59 |