Netlmm Working Group D. Oulai Internet-Draft S. Krishnan Intended status: Standards Track Ericsson Expires: January 8, 2009 July 7, 2008 IPv4 support in PMIP-MIP interaction draft-oulai-netlmm-mip-interaction-v4support-00.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 January 8, 2009. Oulai & Krishnan Expires January 8, 2009 [Page 1] Internet-Draft IPv4 support in PMIP-MIP interaction July 2008 Abstract PMIPv6 and MIPv6 are respectively the leading protocols for network based and client based mobility. As backward compatibility is an important feature, IPv4 support for PMIPv6 and MIPv6 becomes mandatory. This document highlights some scenarios for PMIPv6-MIPv6 interaction with IPv4 support as well as some proposed solutions. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. Scenario Analysis . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Scenario A . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Scenario C . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Oulai & Krishnan Expires January 8, 2009 [Page 2] Internet-Draft IPv4 support in PMIP-MIP interaction July 2008 1. Introduction MIPv6 is the IETF standard for client-based mobility [RFC3775] and PMIPv6 is an extension of MIPv6 developped to offer network-based mobility [I-D.ietf-netlmm-proxymip6]. For those two protocols, backward compatibility is important and that is why IPv4 support becomes mandatory. The IPv4 support for MIPv6 is provided by DSMIP [I-D.ietf-mext-nemo-v4traversal] and PMIPv6-v4 handles the v4 support for PMIPv6 [I-D.ietf-netlmm-pmip6-ipv4-support]. Due to different reasons and network operator preferences, MIPv6 and PMIPv6 will have to interact. A work is ongoing on PMIPv6-MIPv6 interaction [I-D.giaretta-netlmm-mip-interactions]. Three scenarios have been presented. * Scenario A: Two distincts PMIPv6 domains inside a single MIPv6 domain. * Scenario B: A single domain where PMIPv6 and MIPv6 are offered. * Scenario C: A colocated LMA/HA serving distincts PMIPv6 and MIPv6 domain. In this document, we tackle the v4 support of this PMIPv6/MIPv6 interaction (PMIPv6-v4/DSMIP). First, note that we will not address scenario B mentioned in [I-D.giaretta-netlmm-mip-interactions] as it will not involve any handover. Direct applications of [I-D.ietf-netlmm-pmip6-ipv4-support] and [I-D.ietf-mext-nemo-v4traversal] can offer v4 support in scenario B. For each remaining scenarios, we have to consider the case where both source and target networks have v4 support and the case where target network do not offer v4 support. Moreover, for scenario A, it is possible that the global MIPv6 used for macro-mobility does not support IPv4. Oulai & Krishnan Expires January 8, 2009 [Page 3] Internet-Draft IPv4 support in PMIP-MIP interaction July 2008 2. Conventions used in this document 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 [RFC2119]. Oulai & Krishnan Expires January 8, 2009 [Page 4] Internet-Draft IPv4 support in PMIP-MIP interaction July 2008 3. Scenario Analysis In this section, we analyze and provide solutions for scenarios A and C depicted in [I-D.giaretta-netlmm-mip-interactions] 3.1. Scenario A In this scenario, we have two distincts PMIPv6 domains P1 and P2 inside a single global MIPv6 domain G. In case where both P1 and P2 do not support v4, the MN will use DSMIP with the HA to support v4 applications and mobility. For the remaining part of this section, we assume that the MN is in the domain P1 that offers v4 support as depicted in [I-D.ietf-netlmm-pmip6-ipv4-support]. Using PMIPv6-v4, the MN acquires an IPv6 and an IPv4 HoA. Several situations could occur. * G domain supports v4 Beforehand, MN has to run the DSMIP bootstrapping mechanism while residing in P1 to obtain DSMIP v6 and v4 HoA anchored at the HA. Then, MN registers its PMIPv6 v6 or v4 HoA as CoA with HA while still in P1. Preference is given to the v6 address in this case as there can only be one CoA. All the v6 and v4 traffic flowing through HA will be tunneled to MN using the CoA. The MN SHOULD use the v4 HoA anchored at the HA at the transport level as the v4 CoA may change after handover. However, the MN could use the v4 CoA for short-term connections v4 support in domain P2 : When moving to a P2 domain that offers v4 support, the MN acquires new v6 and v4 address. It registers its new PMIPv6 v6 HoA as CoA with HA. All the v4 traffic from HA will be encapsulated towards this CoA and the MN will encapsulate the v4 traffic with the HA address. The MN SHOULD use the v4 HoA anchored at the HA at the transport level as the CoA may change after handover. No v4 support in domain P2 : In this case, the same process described above is applyed except that the MN will not get a new PMIPv6 v4 HoA. v4 support is handled by MN and HA running DSMIP. * G domain does not supports v4 In this case, the v4 traffic is handled by the LMA1, the LMA in the domain P1 using PMIPv6-v4 [I-D.ietf-netlmm-pmip6-ipv4-support]. We recommand that LMA1 includes some DSMIP functionnalities. We will have a colocated LMA1/HA1, similar to the one depicted in scenario C of [I-D.giaretta-netlmm-mip-interactions] . The MN SHOULD be aware that there is no v4 support at HA in domain G. Oulai & Krishnan Expires January 8, 2009 [Page 5] Internet-Draft IPv4 support in PMIP-MIP interaction July 2008 We also recommand to keep the v4 anchor identity in a policy profile. If domain G supports v4, HA is the v4 anchor and if not, LMA1 is the v4 anchor. After the handover in P2 and the PMIPv6 bootstrapping, the MN interacts with the policy profile to get the v4 anchor (LMA1) address and start a DSMIP bootstrapping process with LMA1. The MN SHOULD include its previous v4 HoA in the IKEv2 exchange so this address will be used as DSMIP v4 HoA at the LMA1. Therefore, the MN will be able to continue using this address for v4 traffic. For v6 trafic, implementation has two choices. First one is to keep the tunneling between HA and LMA1 then tunnels the packet to the new address in domain P2. The second option is to update the BCE at the HA in the global domain to receive directly the v6 packets from the HA. This is possible as v6 and v4 bindings are independent. However, we recommend the first choice for simplicity. 3.2. Scenario C We assume that the MN starts in a domain that offers v4 support. The MN configures v6 and v4 HoA. * Handover PMIPv6-MIPv6 MIPv6 domain supports v4 : In the DSMIP bootstrapping mechanism, the addresses acquired in the PMIP domain are considered as v6 and v4 HoA by the HA. For this purpose, a hint must be included in the IKEv2 exchange as mentioned in [I-D.giaretta-netlmm-mip-interactions]. MN acquires new v4 and v6 addresses and registers the v6 address as CoA with HA. Depending on the transport network in the MIPv6 domain, v4 or v6 encapsulation may be used. The principles of DSMIP will rule the signaling and data transport. Also, the Binding Cache lookup considerations as presented in [I-D.giaretta-netlmm-mip-interactions] will also be applied. MIPv6 domain does not support v4 : In this case, as the LMA and the HA are colocated, the BCE at the HA will be modified to consider the v4 HoA and the principles of DSMIP could be applied. * Handover MIPv6-PMIPv6 PMIPv6 domain supports v4 : The addresses acquired in the MIPv6 domain are considered as v6 and v4 HoA by the LMA. The LMA will propose the same Home Network Prefixes (HNP) as in the MIPv6 domain. For this purpose, the HNP MUST be reserved as mentioned in [I-D.ietf-netlmm-pmip6-ipv4-support]. PMIPv6-v4 will rule the signaling and data transport. The Binding Cache lookup considerations will be applied as presented in [I-D.giaretta-netlmm-mip-interactions] . Oulai & Krishnan Expires January 8, 2009 [Page 6] Internet-Draft IPv4 support in PMIP-MIP interaction July 2008 PMIPv6 domain does not support v4 : In this case, the MN will used the v6 HoA in the PMIP domain. The MN will send a binding update to the HA. A modification is required to DSMIP allowing to have only a v4 HoA. The BU message will tell the HA to keep only the v4 HoA in the BCE and remove the v6 HoA. The MN will have two BCE. Therefore, packets coming with the v6 HoA will be handled by the LMA and forwarded to the MAG and packets coming with v4 address will be handled by the HA, encapsulated and forwarded to the v6 HoA which is the PMIPv6 v6 HoA. Another choice could be to configure a new v6 address in the PMIP domain and register it as CoA with the HA as in scenario A. Oulai & Krishnan Expires January 8, 2009 [Page 7] Internet-Draft IPv4 support in PMIP-MIP interaction July 2008 4. Security Considerations This document do not bring any new security issues compared to [I-D.giaretta-netlmm-mip-interactions] . The BCE handling in scenario C is the major task. Oulai & Krishnan Expires January 8, 2009 [Page 8] Internet-Draft IPv4 support in PMIP-MIP interaction July 2008 5. IANA Considerations TBD Oulai & Krishnan Expires January 8, 2009 [Page 9] Internet-Draft IPv4 support in PMIP-MIP interaction July 2008 6. Normative References [I-D.giaretta-netlmm-mip-interactions] Giaretta, G., "Interactions between PMIPv6 and MIPv6: scenarios and related issues", draft-giaretta-netlmm-mip-interactions-02 (work in progress), November 2007. [I-D.ietf-mext-nemo-v4traversal] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", draft-ietf-mext-nemo-v4traversal-04 (work in progress), June 2008. [I-D.ietf-netlmm-pmip6-ipv4-support] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-03 (work in progress), May 2008. [I-D.ietf-netlmm-proxymip6] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-18 (work in progress), May 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. Oulai & Krishnan Expires January 8, 2009 [Page 10] Internet-Draft IPv4 support in PMIP-MIP interaction July 2008 Authors' Addresses Desire Oulai Ericsson 8400 Blvd Decarie Town of Mount Royal, Quebec Canada Email: desire.oulai@ericsson.com Suresh Krishnan Ericsson 8400 Blvd Decarie Town of Mount Royal, Quebec Canada Email: Suresh.Krishnan@ericsson.com Oulai & Krishnan Expires January 8, 2009 [Page 11] Internet-Draft IPv4 support in PMIP-MIP interaction July 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. Oulai & Krishnan Expires January 8, 2009 [Page 12]