MEXT WG S. Gundavelli Internet-Draft Cisco Intended status: Standards Track J. Laganier Expires: April 24, 2012 Qualcomm H. Yokota KDDI Lab C. Williams Consultant October 22, 2011 Overlapping IPv4 Address Assignment Support for Dual-stack Mobile IPv6 draft-gundavelli-mext-dsmip-ipv4-overlap-03 Abstract There are number of deployment scenarios where there is a need for a home agent to allocate the same private IPv4 address to multiple mobile nodes that it is serving. A service provider hosting home agent service for enterprises, or for supporting some of the IPv6 transitioning solutions related to IPv4 address exhaust problem, a home agent may have to allocate the same private IPv4 address to multiple mobile nodes. The Dual-stack Mobile IPv6 does not have such support. This document specifies extensions to Dual-stack Mobile IPv6 for supporting overlapping private IPv4 address assignment support. Status of this Memo This Internet-Draft is submitted 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 April 24, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Gundavelli, et al. Expires April 24, 2012 [Page 1] Internet-Draft Overlapping IPv4 Address Support October 2011 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Usecase Scenarios . . . . . . . . . . . . . . . . . . . . . . 4 3. Conventions & Terminology . . . . . . . . . . . . . . . . . . 6 3.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Considerations . . . . . . . . . . . . . . . . . . . 7 4.1. Home Agent Considerations . . . . . . . . . . . . . . . . 7 4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 7 4.1.2. Signaling Considerations . . . . . . . . . . . . . . . 7 4.2. Mobile Node Considerations . . . . . . . . . . . . . . . . 8 5. Protocol Configuration Variables . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Gundavelli, et al. Expires April 24, 2012 [Page 2] Internet-Draft Overlapping IPv4 Address Support October 2011 1. Introduction IPv4 support for Mobile IPv6 [RFC6275] is specified in Dual-stack Mobile IPv6 [RFC5555]. However, it does not have explicit support for allocating overlapping IPv4 addresses to the mobile nodes that it is serving. There are number deployment scenarios where there is a need for a home agent to allocate the same private IPv4 address to multiple mobile nodes. For example, in service provider hosted home agent deployment models, two mobile nodes from different enterprises may have to be assigned IPv4 addresses from the same overlapping address space. Another example is found in the 3GPP system architecture when a single home agent serves two packet data networks that uses overlapping private address space. In this case, two mobile nodes attached to each of these packet data networks may have to be assigned IPv4 addresses from the same overlapping address space. Additionally, the IPv6 transitioning solutions such as Per-Interface Bindings [I-D.draft-arkko-dual-stack-extra-lite] and Gateway Initiated Dual-stack Lite [I-D.draft-softwire-gateway-init-ds-lite], both the solutions require support for overlapping private IPv4 addressing support. This document specifies extensions to Dual-stack Mobile IPv6 for supporting overlapping private IPv4 address assignment support. Gundavelli, et al. Expires April 24, 2012 [Page 3] Internet-Draft Overlapping IPv4 Address Support October 2011 2. Usecase Scenarios This section identifies the use case scenarios where an home agent is required to assign IPv4 addresses to mobile nodes from an overlapping IPv4 private address space. 203.0.113.0/24 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _----_ . _-----_ . _( )_ . _( )_ +----+ . ( ENT-A )-===-. .=====( DSMIP6 )=======|MN-A| . (_ _) . \ +----------+ / (_ Tunnel_) +----+ . '----' . \| | / '-----' 203.0.113.9 . . |Home Agent|-- (MN-A@ENT-A.COM) . _----_ . /| | \ _-----_ . _( )_ . / +----------+ \ _( )_ +----+ . ( ENT-B )-==.-. .=====( DSMIP6 )=======|MN-B| . (_ _) . (_ Tunnel_) +----+ . '----' . '-----' 203.0.113.9 . . (MN-B@ENT-B.COM). 203.0.113.0/24 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (Home Agent Service Provider) Figure 1: Hosted Home Agent Service for enterprises Figure 1, illustrates the scenario where an home agent in a service provider network is supporting hosted home agent service model. The home agent has a direct forwarding path to each of the enterprises, which allows the home agent to receive from/forward to the mobile node. _-----_ _( )_ +----+ .=====( DSMIP6 )=============|MN-A| _----_ +----------+ / (_ Tunnel_) Tunnel-0 +----+ _( )_ | . | / '-----' 203.0.113.9 -( Internet )---| CGN . HA |-- (_ _) | . | \ _-----_ '----' +----------+ \ _( )_ +----+ .=====( DSMIP6 )============|MN-B| (_ Tunnel_) Tunnel-1 +----+ '-----' 203.0.113.9 Gundavelli, et al. Expires April 24, 2012 [Page 4] Internet-Draft Overlapping IPv4 Address Support October 2011 Figure 2: Support for Per-Interface Bindings Specification Figure 2, illustrates the scenario where an home agent supports Per- Interface Bindings solution, specified in [I-D.draft-arkko-dual-stack-extra-lite]. In this scenario, the CGN is collocated with the home agent, and each the mobile node NAT binding entries have the interface identifier of the DSMIPv6 tunnel, established between the mobile node and the home agent. The home agent uses the interface identifier for making the packet forwarding decision. _-----_ _( )_ +----+ .=====( DSMIP6 )=======|MN-A| _----_ +-----+ +----+ / (_ Tunnel_) +----+ _( )_ | | | | / '-----' 203.0.113.9 -( Internet )--| CGN |===| HA |-- (_ _) | | | | \ _-----_ '----' +-----+ +----+ \ _( )_ +----+ .=====( DSMIP6 )=======|MN-B| (_ Tunnel_) +----+ '-----' 203.0.113.9 Figure 3: Support for Gateway Initiated Dual-stack Lite Figure 3, illustrates the scenario where an home agent has support for the IPv6 transitioning solution, Gateway Initiated Dual-stack lite solution, specified in [I-D.draft-softwire-gateway-init-ds-lite]. In this scenario, there is typically a GRE tunnel between the CGN gateway and the home agent. Every IPv4 packet tunneled between the CGN and the home agent carries a context identifier in the GRE Key header unique to a mobile node, which allows the home agent to forward the packet to the correct mobile node. Gundavelli, et al. Expires April 24, 2012 [Page 5] Internet-Draft Overlapping IPv4 Address Support October 2011 3. Conventions & Terminology 3.1. Conventions 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 RFC 2119 [RFC2119]. 3.2. Terminology All the mobility related terms used in this document are to be interpreted as defined in the Mobile IPv6 specification [RFC6275]. Additionally, this document uses the following abbreviations: o CGN - Carrier Grade NAT o Overlapping Address Space - Private IPv4 Address Space [RFC6275] that is reused across different networks. Gundavelli, et al. Expires April 24, 2012 [Page 6] Internet-Draft Overlapping IPv4 Address Support October 2011 4. Protocol Considerations 4.1. Home Agent Considerations 4.1.1. Extensions to Binding Cache Entry To support this feature, the conceptual Binding Cache entry data structure maintained by the home agent needs to be extended to include the following new parameter. o IPv4-overlap-ctx-id: A 4-byte field used for storing the context identifier field. The home agent uses this value in this field for making the forwarding decision. 4.1.2. Signaling Considerations The following considerations MUST be applied by the home agent when allocating overlapping private IPv4 address to a mobile node from an overlapping IPv4 private address space. o On receiving a Binding Update message [RFC6275] from a mobile node with the home address option [RFC5555], the home agent MUST process the request as specified in [RFC5555]. o If the home agent based on the policy considerations determines that the mobile node MUST be assigned an IPv4 address from a non- overlapping IPv4 address space, no additional considerations from this specification need to be applied. o If the Mobile Node Identifier option [RFC4283] is not present in the received Binding Update message, but if the protocol configuration variable EnableOverlappingIPv4SupportWithRealmUniqueness is set to a value of (1), and the value of the configuration variable EnableOverlappingIPv4SupportWithAPNUniqueness is set to value of (0), the home agent MUST reject the request and send a Binding Acknowledgement message with Status field set to MISSING_MN_IDENTIFIER_OPTION (160) [RFC5213]. o If the Mobile Node Identifier option [RFC4283] is present in the received Binding Update message, but if the protocol configuration variable EnableOverlappingIPv4SupportWithRealmUniqueness is set to value of (1), the home agent MUST assign a private IPv4 address from the overlapping address space from the realm associated with the mobile node identifier. Gundavelli, et al. Expires April 24, 2012 [Page 7] Internet-Draft Overlapping IPv4 Address Support October 2011 o If the protocol configuration variable EnableOverlappingIPv4Support is set to a value of (1), the home agent MUST assign a private IPv4 address from the configured overlapping address space. This configured overlapping address space is not associated with any realm. o When the home agent assigns an IPv4 private address from an overlapping address space, the home agent MUST NOT set up an IPv4 host route over the tunnel to the mobile node, as that IPv4 address is not uniquely assigned to a single mobile node. The home agent MUST make the forwarding decision based on the context identifier that is associated with the received packet and the context identifier in the Binding Cache entry. o In deployments where the home agent is supporting hosted home agent service model, the context identifier field of the Binding Cache entry MUST be set to the identifier of the tunnel established between the home agent and the enterprise gateway. Any IPv4 packets recieved from the mobile node over the DSMIPv6 tunnel, after removing the outer header, MUST be forwarded to the enterprise to which the mobile node belongs. The home agent MUST use the context identifier field of the mobile node Binding Cache entry for performing the correlation. Similarly, any IPv4 packets received for the mobile node from the enterprise gateway, MUST be tunneled to the mobile node. o In deployments related to supporting Per-Interface Binding Support, where the home agent is collocated with the CGN, the NAT binding entries created for that mobile node for any IPv4 flows MUST be associated with the tunnel identifier established between the home agent and the mobile node. Considerations from [I-D.draft-arkko-dual-stack-extra-lite] MUST be applied for making IPv4 packet forwarding decisions. o In deployments related to supporting Gateway Initiated Dual-stack lite, considerations from [I-D.draft-softwire-gateway-init-ds-lite] MUST be applied with respect to IPv4 packet forwarding decisions and on the use of the context identifier. 4.2. Mobile Node Considerations This specification does not introduce any new considerations for the mobile node implementation. The IPv4 private address assigned from an overlapping address space, when used as the source address in any IP sessions will get NAT translated at the CGN and is not exposed to the session peers, or any other network elements. Gundavelli, et al. Expires April 24, 2012 [Page 8] Internet-Draft Overlapping IPv4 Address Support October 2011 5. Protocol Configuration Variables A home agent when supporting this specification MUST allow the following variables to be configured by the system management. The configured values for these protocol variables MUST survive server reboots and service restarts. EnableOverlappingIPv4SupportWithRealmUniqueness This flag indicates whether or not the home agent should be allowed to assign overlapping IPv4 addresses to mobile nodes. However, the assigned addresses MUST be unique within a realm scope (Ex: @cisco.com). The default value for this flag is set to (0), indicating this feature is not enabled. The value of the flag MUST be set to (0), when the value of any of the flags, EnableOverlappingIPv4Support or EnableOverlappingIPv4SupportWithAPNUniqueness is set to (1). EnableOverlappingIPv4SupportWithAPNUniqueness This flag indicates whether or not the home agent should be allowed to assign overlapping IPv4 addresses to mobile nodes. However, the assigned addresses MUST be unique within the 3GPP APN scope (Ex: @internetsvcs.cisco.com). The default value for this flag is set to (0), indicating that this feature is not enabled. The value of the flag MUST be set to (0), when the value of any of the flags, EnableOverlappingIPv4Support or EnableOverlappingIPv4SupportWithRealmUniqueness is set to (1). EnableOverlappingIPv4Support This flag indicates whether or not the home agent should be allowed to assign overlapping IPv4 addresses to mobile nodes. The assigned addresses MAY be overlapping within a realm. The default value for this flag is set to (0), indicating that this feature is not enabled. The value of the flag MUST be set to (0), when the value of any of the flags, EnableOverlappingIPv4SupportWithRealmUniqueness, or EnableOverlappingIPv4SupportWithRealmUniqueness is set to (1). Gundavelli, et al. Expires April 24, 2012 [Page 9] Internet-Draft Overlapping IPv4 Address Support October 2011 6. IANA Considerations This specification does not require any IANA actions. Gundavelli, et al. Expires April 24, 2012 [Page 10] Internet-Draft Overlapping IPv4 Address Support October 2011 7. Security Considerations This document specifies extensions to Dual-stack Mobile IPv6 for supporting overlapping private IPv4 address assignment support. These protocol extensions do not introduce any new security vulnerabilities for the following reasons: Any IPv4 packets sent (or received) by a mobile node using an IPv4 address from an overlapping IPv4 private address space, or from a non-overlapping address space are tunneled between the mobile node and the home agent. These addresses are hidden from the routing topology and from on-path network devices and hence will not introduce any new security vulnerabilities. Gundavelli, et al. Expires April 24, 2012 [Page 11] Internet-Draft Overlapping IPv4 Address Support October 2011 8. Acknowledgements The authors would like to acknowledge number of folks for all the discussions related to hosted home agent deployment models for enterprises. The authors would also like to acknowledge all the discussions related to solutions for IPv4 address exhaust problem in the 3GPP- IETF IPv6 Migration Workshops held in Shanghai and in San Francisco. Additionally, the authors would like to thank Vojislav Vucetic, Frank Brockners, Kent Leung, Flemming Andreasen and Eric Voit for the general discussions related to IPv6 transitioning solutions. Gundavelli, et al. Expires April 24, 2012 [Page 12] Internet-Draft Overlapping IPv4 Address Support October 2011 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, November 2005. [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009. [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011. 9.2. Informative References [I-D.draft-arkko-dual-stack-extra-lite] Arkko, J. and L. Eggert, "Scalable Operation of Address Translators with Per-Interface Bindings, draft (work in progress)", February 2011. [I-D.draft-softwire-gateway-init-ds-lite] Brockners, F., Gundavelli, S., Speicher, S., and D. Ward, "Gateway Initiated Dual-Stack Lite Deployment, draft-ietf-softwire-gateway-init-ds-lite (work in progress)", October 2011. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. Gundavelli, et al. Expires April 24, 2012 [Page 13] Internet-Draft Overlapping IPv4 Address Support October 2011 Authors' Addresses Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: sgundave@cisco.com Julien Laganier Qualcomm 5775 Morehouse Drive San Diego, CA 92121 USA Email: julienl@qualcomm.com Hidetoshi Yokota KDDI Lab 2-1-15 Ohara, Fujimino Saitama, 356-8502 JP Email: yokota@kddilabs.jp Carl Williams San Jose, CA USA Email: carlw@mcsr-labs.org Gundavelli, et al. Expires April 24, 2012 [Page 14]