Mobility Extensions for IPv6 [mext] | C. Perkins |
Internet-Draft | Tellabs Inc. |
Expires: February 04, 2012 | August 03, 2011 |
Alternate Tunnel Source Address for Home Agent
draft-perkins-mext-hatunaddr-01.txt
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.
This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 04, 2012.
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
Mobile IP [RFC5944] and Mobile IPv6 [RFC6275] 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, Proxy MIP [RFC5213], Hierarchical Mobile IP [RFC5380]. Similar extensions to the registration messages in those MIP variations will also be specified in this document.
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:
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 + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 IPv6-in-IPv6 encapsulation [RFC2473]) through that the home agent.
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.
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 Hierarchical Mobile IP [RFC5380]. 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.
The "Alternate Home Agent Tunnel Address" option may be included as an extension to the Registration Reply message. Its format is as follows:
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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.
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.
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).
[1] | Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. |
[2] | Perkins, C., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010. |
[3] | Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K. and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. |
[4] | Soliman, H., Castelluccia, C., ElMalki, K. and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, October 2008. |
[5] | Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011. |