Network Working Group V. Devarapalli Internet-Draft N. Kant Intended status: Informational H. Lim Expires: August 27, 2008 Azaire Networks February 24, 2008 Mobile IPv6 Home Link Operation over SDO point-to-point links draft-devarapalli-mext-mipv6-home-link-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 27, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract The Mobile IPv6 protocol is being adopted by various Standards Development Organizations (SDO) for mobility across wide area networks. Some of the architectures developed by these SDOs require some of the access links to be home link for mobile node. The belief is that if the mobile node thinks it is attached to the home link, there will not be additional packet overhead due to Mobile IPv6 tunneling. Many of these links where the mobile node is supposed to Devarapalli, et al. Expires August 27, 2008 [Page 1] Internet-Draft MIPv6 Home Link Operation February 2008 be attached to the home link are point-to-point links. There are some issues with making these point-to-point links appear like home link to the mobile node. This document captures some of the issues related to this, and analyzes possible solutions. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Issues with using Point-to-Point links as Home Links . . . . . 4 3.1. Detecting Attachment to the Home Link . . . . . . . . . . 4 3.2. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Home Address Management on the Mobile Node . . . . . . . . 5 3.4. Forwarding at the Home Agent . . . . . . . . . . . . . . . 6 3.5. Indicating Service Selection Option . . . . . . . . . . . 6 4. Solution Analysis . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Modified Binding Update Message Format . . . . . . . . . . 9 4.2. Modified Binding Acknowledgement Message Format . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Devarapalli, et al. Expires August 27, 2008 [Page 2] Internet-Draft MIPv6 Home Link Operation February 2008 1. Introduction The Mobile IPv6 protocol [2] is being adopted by various Standards Development Organizations (SDOs) for mobility across wide area cellular networks. The architectures being developed by the SDOs involve some access links where bandwidth is considered scarce. Therefore, the SDOs have designed the architectures so that the Mobile IPv6 signaling and tunneling overhead can be avoided over these access links. For various reasons, Route Optimization is not being considered by the SDOs. According to RFC 3775 [2], the mobile node does not have a valid binding cache entry at the home agent and a Mobile IPv6 tunnel with the home agent only when it is attached to the home link. Therefore the architectures being developed by the SDOs require of the access links to appear to the mobile node as home link so that the Mobile IPv6 overhead can be avoided. The access links where the mobile node is attached to the home link is of various types. They typically tend to be point-to-point links. The following describes examples of point-to-point links where Mobile IPv6 home link operation is desired. o GTP tunnels/PDP Contexts - GTP tunnels [4] between network entities or PDP contexts between the mobile node and a network entity are used as single hop point-to-point links between the mobile node and the home agent. The architectures in [5] and [6] show scenarios where the home agent is co-located with a network entity that terminates the GTP tunnels. In these cases, the mobile node, whenever it attaches over these access links is attached to the home link. Note that this document uses the terms GTP and PDP context very loosely. For more details about GTP tunnels or PDP contexts, please see [4]. o PMIPv6 tunnels - [5] shows an architecture where the Proxy Mobile IPv6 Local Mobility Anchor functionality [7] and Mobile IPv6 home agent functionality are co-located. In this architecture whenever the mobile node is attached to the access link where PMIPv6 is used, it appears to the mobile node as if it is attached to the home link. In this case, the concatenation of PMIPv6 tunnel between the Mobile Access Gateway and the Local Mobility Anchor and the point-to-point link between the mobile node and the mobile access gateway is used as the point-to-point link between the mobile node and the home agent. o IPsec tunnels - [6] describes a scenario where a network entities that terminates IPsec tunnels from the mobile node is co-located with Mobile IPv6 home agent function. In this case, whenever the Devarapalli, et al. Expires August 27, 2008 [Page 3] Internet-Draft MIPv6 Home Link Operation February 2008 mobile node is attached over IPsec tunnels, it appears to the mobile node as if it is attached to the home link. In this case, an IPsec tunnel is used as point-to-point link between the mobile node and the home agent. In some of the scenarios in [5], it is possible to use concatenated GTP and PMIPv6 tunnel or concatenated IPsec tunnel and PMIPv6 tunnel as point-to-point links between the mobile node and the home agent. There are also scenarios where two concatenated PMIPv6 tunnels are used to provide a home link for the mobile node. There are some issues with using point-to-point links based on GTP/ PMIPv6/IPsec tunnels between the mobile node and the home agent. This document discusses some of the issues and analyzes possible solutions. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. 3. Issues with using Point-to-Point links as Home Links The following describes some of the issues with using point-to-point links as home links. 3.1. Detecting Attachment to the Home Link In Mobile IPv6, a mobile node detects that it has attached to the home link when it receives a router advertisement with the home prefix. Some of the point-to-point links like IPsec tunnels and PMIPv6 tunnels do not support running neighbor discovery in the tunnels. When the home link is created by concatenating a GTP tunnel with a PMIPv6 tunnel or an IPsec tunnel with PMIPv6 tunnels, it becomes difficult for a router advertisement to be sent over the concatenated tunnels. If the mobile node is not able to use router discovery to detect attaching to the home link, then the only possible solution would be to configure the mobile node with the information on which links it needs to treat as home links. This solution is not sufficient in most cases. Devarapalli, et al. Expires August 27, 2008 [Page 4] Internet-Draft MIPv6 Home Link Operation February 2008 3.2. Bootstrapping Mobile IPv6 bootstrapping [8] and [9] depends on the use of IKEv2 between the mobile node and the home agent to bootstrap the MIPv6 home address. According to RFC 3775, when the mobile node is attached to the home link, it does not have to run IKEv1/IKEv2 with the home agent to setup the necessary security associations. Most often, the IKEv2 exchange is triggered by the need to send a binding update. So if the mobile node boots up the home link, it may not be able to use IKEv2 to bootstrap the MIPv6 home address. The IKEv2 exchange is only used to bootstrap the MIPv6 home address. The DS-MIPv6 [11] IPv4 home address is obtained by the mobile node using the exchange of Binding Update and Binding Acknowledgement with the home agent. The Mobile Network Prefixes required for mobile router operation, as described in [10], may also obtained using the Binding Update and Binding Acknowledgement exchange between the mobile router and the home agent. This is specified in [12]. According to the current specifications, the mobile node (or the mobile router) does not send a Binding Update to the home agent when it is attached to the home link. Since it is not typical for the mobile node to initiate an IKEv2 exchange with its home agent and not possible to send a Binding Update from the home link, there is a need for other bootstrapping mechanisms that would work across all point-to-point home links. However, this would result in the mobile node using different bootstrapping mechanisms depending on the point-to-point that appears as the home link. The mobile node would also end with using different bootstrapping mechanisms when attached to the home link and when attached to the visited link. To avoid this, it would be desirable to use the same bootstrapping mechanisms irrespective of the point-to-point link that appears as the home link and/or the visited link. 3.3. Home Address Management on the Mobile Node When the mobile node boots up on the home link, it will configure the IPv6 home address (and the IPv4 home address). The home address(es) are configured using address configuration mechanisms specific to the point-to-point links. The mobile node then assigns the address(es) to the interface that corresponds to the point-to-point link. The Mobile IPv6 stack that is running on the mobile node needs to know that the addresses now assigned to the point-to-point links are also the home addresses and should be assigned to the Mobile IPv6 virtual interface when the mobile node moves away from the home and attaches to a visited link. Devarapalli, et al. Expires August 27, 2008 [Page 5] Internet-Draft MIPv6 Home Link Operation February 2008 3.4. Forwarding at the Home Agent According to RFC 3775, when the mobile node is attached to the home link, it behaves as a regular IPv6 host and is able to send/receive packets directly without going through the home agent. In case the home agent needs to send any packet to the mobile node, it has a valid neighbor cache entry for the mobile node which is then used to forward packets to the mobile node. When point-to-point links are used a home links, then the packets meant for the mobile node always reach the home agent first and are then forwarded to the mobile node. However, the home agent cannot construct a neighbor cache entry for the mobile node, since most of the point-to-point links mentioned in Section 1 do not support sending neighbor solicitation and receiving neighbor advertisement messages. The home agent would need to associate the mobile node's home address with the point-to-point link between the mobile node and the home agent. This would require tighter integration between the function that terminates the point-to-point link and the home agent function on the same network node. In some of the configurations described in [5] and [6], it may be possible that two different access links for a mobile node appear as a home link. When the mobile node performs a handover between these two interfaces, it would appear to it, that it attached to the same home link using another interface. For this scenario to work, the home agent would need to know that the mobile node, after a handover, is reachable at home over a different point-to-point link. This would again require tighter integration between the functions that terminate the two different types of point-to-point link and the home agent function. 3.5. Indicating Service Selection Option A new extension, the Service Selection for Mobile IPv6, has been specified in [13] for the mobile node to indicate to the home agent which service it wants to access. The Service Selection option is sent in the Binding Update. When the mobile node boots up in the home link, it won't be able to indicate the service it wants to access to the home agent, since the Binding Update message is not sent from the home link. It is possible to indicate the Service the mobile node wants to access in the IKEv2 exchange with the home agent. The service information is encoded in the IDr payload in the IKEv2 exchange. However, this requires the mobile node to initiate an IKEv2 exchange with the mobile node from the home link. According to RFC 3775, the mobile node does not have to initiate an IKEv2 exchange when it boots Devarapalli, et al. Expires August 27, 2008 [Page 6] Internet-Draft MIPv6 Home Link Operation February 2008 up in the home link. 4. Solution Analysis A straight forward solution to avoid the issues described in Section 3 is to avoid the home link operation. The mobile node is always attached to the visited link. The home link becomes a virtual home link in this case. However, this solution may not be acceptable due to resource constraints on some of the point-to-point links mentioned in Section 1. A possible solution would be for the mobile node to perform an IKEv2 exchange and a Binding Update/Binding Acknowledgement exchange with the home agent even when it is attached to the home link. A new flag 'C' is used in the Binding Update and Binding Acknowledgement messages to indicate that these messages are being sent on the home link and are used only for bootstrapping and configuring other information. The Home Agent does not create a binding cache entry when it processes the Binding Update with the 'C' flag set. This extension to Mobile IPv6, should only be used by those mobile nodes which boot up on the home link using point-to-point links. The use of the extensions specified in the section should be configurable on the mobile node and the home agent. A regular Binding Update, as defined in [2], cannot be used for bootstrapping and obtaining configuration information when the mobile node is on the home link. When the home agent receives a Binding Update from a mobile node on the home link, it is treated as a de- registration Binding Update. When the home agent receives the de- registration Binding Update from the mobile node and it does not have a valid binding cache entry for the mobile node, it responds with the failed status 133 (Not home agent for this mobile node) in the Binding Acknowledgement [2]. The DS-MIPv6 IPv4 home address and Mobile Network prefixes will not be sent in the Binding Acknowledgement, since the Binding Update is seen as a failed one. This is one of the reasons why a new flag (the 'C' flag) is necessary in the Binding Update. Whenever the mobile node boots up on a point-to-point link, it first configures information, including the IP address, specific to the point-to-point link. The mobile node then initiates an IKEv2 exchange with the home agent as described in [3]. If the home agent detects that the mobile node is sending IKEv2 messages from a point- to-point link shared with the mobile node, it obtains the IPv6 address assigned to the mobile node for the point-to-point link, and sends the same address in the INTERNAL_IP6_ADDRESS attribute in the IKE_AUTH response message [3]. This indicates to the mobile node Devarapalli, et al. Expires August 27, 2008 [Page 7] Internet-Draft MIPv6 Home Link Operation February 2008 that the address it obtained earlier as part of point-to-point access link setup, is now usable as the IPv6 home address also. The IKEv2 exchange also sets up the necessary security associations for protecting the Binding Update and Binding Acknowledgement messages. Once the IKEv2 exchange is complete, the mobile node sends a Binding Update with the 'C' flag set to the home agent. The 'C' flag indicates that this Binding Update is only being sent for bootstrapping and not to create a binding cache entry. The bootstrap information may include requests for the DS-MIPv6 IPv4 home address [11], and the NEMO Mobile Network Prefixes [12]. The mobile node may also indicate the service it wants to access using the service selection option [13]. The Binding Update includes the home address that the mobile node obtained earlier as part of the IKEv2 exchange. When the home agent processes the Binding Update with the 'C' flag set, it MUST treat the message as a Binding Update sent from the home link. The home agent does not create a binding cache entry for the mobile node. The home agent associates the point-to-point link over which the Binding Update was received with the home address of the mobile node. This is used to create a forwarding entry on the home agent to forward packets meant for the mobile node's home address to the point-to-point link shared with the mobile node. Once the Binding Update processing is successful, the home agent responds with a Binding Acknowledgement to the mobile node. In the Binding Acknowledgement, the home agent indicates that it is sent from the home link, by setting the 'C' bit. The home agent also includes information like the IPv4 home address and the NEMO Mobile Network Prefixes in the Binding Acknowledgement if the mobile node had requested the same. If the IPv4 home address was sent by the home agent, another forwarding entry is created to forward packets meant for the IPv4 home address to the point-to-point link over which the Binding Update was received. When the mobile node receives a Binding Acknowledgement with the 'C' flag set, it treats this message as a confirmation that it is attached to the home link. The mobile node configures the IPv4 home address as the DS-MIPv6 IPv4 home address. The mobile node obtains other bootstrapping information it had requested for in the Binding Update. When the mobile node moves away its home link and attaches to the visited link, it sends regular Mobile IPv6 Binding Updates to the home agent. Devarapalli, et al. Expires August 27, 2008 [Page 8] Internet-Draft MIPv6 Home Link Operation February 2008 4.1. Modified Binding Update Message Format The following shows the modified message format for the initial Binding Update sent from the home link. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|M|R|P|C| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home Link Exchange (C) A new flag (C) that indicates that the Binding Update is sent from the home link and is used for bootstrapping and configuration. The rest of the fields in the Binding Update format illustrated above are as described in [2], [10], [14] and [7]. 4.2. Modified Binding Acknowledgement Message Format The following shows the modified message format for the initial Binding Acknowledgement sent from the home link. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status |K|R|P|C| Resvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Devarapalli, et al. Expires August 27, 2008 [Page 9] Internet-Draft MIPv6 Home Link Operation February 2008 Home Link Exchange (C) A new flag (C) that indicates that the Binding Acknowledgement is sent from the home link and is used for bootstrapping and configuration. The rest of the fields in the Binding Acknowledgement format illustrated above are as described in [2], [10], and [7]. 5. Security Considerations This document does not introduce any new security considerations due to the IKEv2 exchange and the Binding Update/Binding Acknowledgement exchange between the mobile node and the home agent when the mobile node boots up on the home link. Please see RFC 3775 [2] for security considerations regarding the use of Mobile IPv6. 6. IANA Considerations This document does not require any new assignments from IANA. 7. References 7.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [3] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007. 7.2. Informative References [4] 3rd Generation Partnership Project, "3GPP Technical Specification 29.060 V8.2.0: Technical Specification Group Core Network and Terminals; General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface (Release 8)", December 2007. [5] 3rd Generation Partnership Project, "3GPP Technical Specification 23.402 V8.0.0: Technical Specification Group Devarapalli, et al. Expires August 27, 2008 [Page 10] Internet-Draft MIPv6 Home Link Operation February 2008 Services and System Aspects; Architecture enhancements for non- 3GPP accesses (Release 8)", December 2007. [6] 3rd Generation Partnership Project, "3GPP Technical Specification 23.327 V0.2.0: Technical Specification Group Services and System Aspects; Mobility between 3GPP-Wireless Local Area Network (WLAN) Interworking and 3GPP Systems (Release 8)", January 2008. [7] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-10 (work in progress), February 2008. [8] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007. [9] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the Integrated Scenario", draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in progress), July 2007. [10] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [11] Soliman, H., "Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-06 (work in progress), November 2007. [12] Kniveton, T. and P. Thubert, "Mobile Network Prefix Delegation", draft-ietf-nemo-prefix-delegation-02 (work in progress), August 2007. [13] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service Selection for Mobile IPv6", draft-korhonen-mip6-service-06 (work in progress), December 2007. [14] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005. Devarapalli, et al. Expires August 27, 2008 [Page 11] Internet-Draft MIPv6 Home Link Operation February 2008 Authors' Addresses Vijay Devarapalli Azaire Networks 3121 Jay Street Santa Clara, CA 95054 USA Email: vijay.devarapalli@azairenet.com Nishi Kant Azaire Networks 3121 Jay Street Santa Clara, CA 95054 USA Email: nishi.kant@azairenet.com Heeseon Lim Azaire Networks 3121 Jay Street Santa Clara, CA 95054 USA Email: heeseon.lim@azairenet.com Devarapalli, et al. Expires August 27, 2008 [Page 12] Internet-Draft MIPv6 Home Link Operation February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Devarapalli, et al. Expires August 27, 2008 [Page 13]