Network Working Group M. Boucadair, Ed. Internet-Draft C. Jacquenet Intended status: Informational JL. Grimault Expires: October 31, 2009 M. Kassi Lahlou P. Levis France Telecom April 29, 2009 Stateless IPv4-IPv6 Interconnection in the Context of DS-lite Deployment draft-boucadair-dslite-interco-v4v6-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 October 31, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the Boucadair, et al. Expires October 31, 2009 [Page 1] Internet-Draft Extended DS-lite April 2009 document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This memo describes a proposal to enhance DS-lite solution with an additional feature to ease interconnection between IPv4 and IPv6 realms. When deployed, no dual-stack-enabled network is required for the delivery of both IPv4 and IPv6 connectivity to customers. Only IPv6 is required to be deployed in core and access networks. Particularly, IPv6 transfer capabilities are used for the transfer of IPv4-addressed packets in a completely stateless scheme between the interconnection segment and the DS-lite CGN node(s). This memo proposes an IPv4-inferred scheme to build IPv6 addresses. The proposed solution allows Service Providers to maintain an IPv6- only network. Requirements Language 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]. Boucadair, et al. Expires October 31, 2009 [Page 2] Internet-Draft Extended DS-lite April 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Context . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Contribution of this draft . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Overall Procedure . . . . . . . . . . . . . . . . . . . . 5 3.2. Customer Attachment Device . . . . . . . . . . . . . . . . 7 3.3. DS-lite CGN Node . . . . . . . . . . . . . . . . . . . . . 7 3.3.1. Provisioning Information . . . . . . . . . . . . . . . 7 3.3.2. Routing Considerations . . . . . . . . . . . . . . . . 8 3.3.3. Processing Operations . . . . . . . . . . . . . . . . 8 3.4. IPv6-IPv4 Interconnection Function . . . . . . . . . . . . 10 3.4.1. Provisioning Information . . . . . . . . . . . . . . . 10 3.4.2. Routing Considerations . . . . . . . . . . . . . . . . 10 3.4.3. Processing Operations . . . . . . . . . . . . . . . . 11 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 12 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Boucadair, et al. Expires October 31, 2009 [Page 3] Internet-Draft Extended DS-lite April 2009 1. Introduction 1.1. Context It is commonly agreed that IPv4 address shortage is a fact. Several solutions have been proposed to cope with this sensitive issue. All these solutions are based on IP address sharing and differ in where the IP address sharing function is enforced. The first category is denoted as Port Range [I-D.boucadair-port-range] or A+P solutions [I-D.ymbk-aplusp]. The spirit of this category is to assign the same public IP address to several customers' devices (called also port restricted devices) together with a Port Range. Communications issued/destined to a port-restricted device can be established only if the ports belong to the provisioned Port Range. Dedicated means to provision the Port Range have been proposed (see [I-D.bajko-pripaddrassign] and [I-D.boucadair-pppext-portrange-option] for instance). The second category is known as CGN (for Carrier Grade NAT). Two main CGN flavors can be distinguished. Double NAT, in which two levels of NAT are cascaded: one in the CPE and one in the network (i.e. CGN). And DS-lite [I-D.ietf-softwire-dual-stack-lite] which gets rid of the CPE NAT level. This solution requires a Dual Stack CPE. Thus, a given CPE is assigned with an IPv6 prefix to be used for its native IPv6 communications and also to encapsulate the IPv4 packets into IPv6 ones between the CPE and the DS-lite CGN. Note that the deployment of DS-lite CGN equipment is not necessarily centralized and several DS-lite CGN nodes may be deployed to handle traffic issued/destined from/to end-user devices. Whilst the DS-lite solution enhances the Double NAT scenario by avoiding a NAT level and the allocation of a specific private IPv4 address to the CPE, it does not solve the IPv4-IPv6 interworking issue. 1.2. Contribution of this draft This memo proposes an extended DS-lite approach to solve both IPv4 address shortage and also to allow stateless IPv4-IPv6 interconnection. More precisely, this memo proposes to update DS- lite nodes with new encapsulation and de-encapsulation capabilities to be applied on the interface to core network of a given service provider. Furthermore, a new function embedded in IPv6-IPv4 interconnection nodes (e.g. ASBR or a dedicated node) is also introduced. The activation of the proposed solution allows a service provider to operate a network which is IPv6-only. Boucadair, et al. Expires October 31, 2009 [Page 4] Internet-Draft Extended DS-lite April 2009 [I-D.boucadair-behave-ipv6-portrange] introduces a slightly modified IPv4-IPv6 interworking function (which takes into account the port number information) compatible with the Port Range based solutions. 2. Terminology This memo makes use of the following terms: o DS-lite CGN node: refers to the CGN node which behaviour is specified in [I-D.ietf-softwire-dual-stack-lite]. This node embedded a CGN function. o Access segment: This segment encloses both IP access and backhaul network. o Interconnection segment: Includes all nodes and resources which are deployed at the border of a given AS (Autonomous System) a la BGP (Border Gateway Protocol). o Core segment: Denotes a set of IP networking capabilities and resources which are between the interconnection and the access segments. o Customer Attachment Device: A customer may use a terminal or a CPE to access its subscribed services. This device is referred to as Customer Attachment Device. o IP connectivity information: A set of information (e.g. IP address, default gateway, etc) required to access IP transfer delivery service. 3. Procedure This section describes an updated DS-lite solution. 3.1. Overall Procedure The overall proposed procedure is summarised hereafter: o A new IPv6-IPv4 Interconnection function (IPv6-IPv4 ICXF) is introduced. This function may be hosted in an ASBR or a dedicated node located at the interconnection between IPv6 and IPv4 domains. This function is responsible for encapsulating all received IPv4 datagrams in IPv6 ones and de-encapsulating IPv4-in-IPv6 datagrams. Boucadair, et al. Expires October 31, 2009 [Page 5] Internet-Draft Extended DS-lite April 2009 o DS-lite CGN nodes are deployed in the access network. These nodes are compliant with [I-D.ietf-softwire-dual-stack-lite]. In addition, these nodes are enhanced with new IPv4-in-IPv6 encapsulation and de-encapsulation functions. These newly introduced functions are stateless. Once these functions are enabled, a given DS-lite node is responsible to handle IPv4-in- IPv6 traffic in all its interfaces. No plain IPv4 traffic is sent/received by the DS-lite CGN in all its interfaces. Only IPv4-in-IPv6 packets are handled. o Customer Attachment Devices are provisioned with an IPv6 prefix that will not only be used for native IPv6 communication, but also to encapsulate IPv4 datagrams. The proposed solution does no require any modification on the customers side compared to what has been listed in [I-D.ietf-softwire-dual-stack-lite]. This figure provides an overview of the overall environment. Customers are connected to the service domain via a CPE device. Several DS-lite CGN nodes are deployed to manage the traffic issued/ destined from/to end user device. The local domain is IPv6 only and interconnection with adjacent IPv4 realms is implemented using IPv6- IPv4 ICXF. +--------------------------------+ | Service Domain | +----------- +----+ | +---------+ | IPv4 |CPE1|---------| |IPv6-IPv4|----| Domain A +----+ | | ICXF | | | +---------+ +----------- | +-------+ | | |DS-lite| | +----------- +----+ | | CGN A | +---------+ | IPv4 |CPE2|---------| +-------+ |IPv6-IPv4|----| Domain B +----+ | | ICXF | | | +---------+ +----------- | +-------+ | | | |DS-lite| | | +----------- +----+ | | CGN B | | | | IPv4 |CPEi|---------| +-------+ | +-------| Domain C +----+ | | | | | +----------- +--------------------------------+ |<---IPv6----------->|<-----IPv6------------->|<---IPv4---- Figure 1: Environment Overview The following sub-sections provide more details about the proposed Boucadair, et al. Expires October 31, 2009 [Page 6] Internet-Draft Extended DS-lite April 2009 solution. 3.2. Customer Attachment Device The Customer Attachment Device is provisioned with an IPv6 prefix and the IPv6 address of a DS-lite CGN, by means of DHCPv6 for example. For robustness reasons, the IPv6 address of a DS-Lite CGN is recommended to be an anycast address. A Customer Attachment Device encapsulates the privately addressed IPv4 traffic in IPv6 datagrams. These messages are then forwarded (without any NAT operation) towards a DS-lite CGN node. As for incoming traffic, a Customer Attachment Device proceeds to de- encapsulation operation. De-encapsulated datagrams are handled locally or are forwarded to the appropriate machine connected to the LAN behind the Customer Attachment Device. The current specification does not require any modification on a DS- lite compliant CPE. 3.3. DS-lite CGN Node 3.3.1. Provisioning Information In addition to the required configuration information to activate DS- lite mode described in [I-D.ietf-softwire-dual-stack-lite], DS-lite CGN nodes are provisioned with: o WKIPv6: an IPv6 prefix that can be assigned by IANA or extracted from the prefix assigned to the service provider. This prefix is used to build an IPv4-inferred IPv6 address. More information are provided in Section 3.3.3. o A set of IPv6 prefixes which are structured as WKIPv6+IPv4_addr: * WKIPv6: the same as the one mentioned in the previous bullet. * IPv4_addr is an IPv4 address used by the DS-lite CGN to enforce its NAT44 operations. * Several IPv4 addresses may be configured on a DS-lite node. These IPv4 addresses may be aggregated, leading to aggregated WKIPv6+IPv4_addr prefixes. Boucadair, et al. Expires October 31, 2009 [Page 7] Internet-Draft Extended DS-lite April 2009 3.3.2. Routing Considerations A DS-lite node (or a third party) advertises in IGP the IPv6 prefixes it manages (i.e. the set of WKIPv6+IPv4_addr prefixes described above). Such announcement is required so that all traffic destined to an IPv6 address belonging to an IPv6 prefix configured on the DS- lite CGN node MUST be forwarded to the DS-Lite node. 3.3.3. Processing Operations Figure 2 shows the input and output of a DS-lite CGN node. +-------------------+ ----IPv6---\ | |----IPv6---\ ----IPv4---\\| |----IPv4---\\ -----------//| |-----------// -----------/ | |-----------/ | DS-Lite | /----IPv6---| CGN | /----IPv6--- //---IPv4----| |//---IPv4---- \\-----------| |\\----------- \-----------| | \----------- +-------------------+ Figure 2: Modified DS-lite CGN Two main interfaces may be distinguished in a DS-lite CGN node: a. Interface to the customer device. b. Interface to core nodes. The handling of the traffic received from a customer device is as follows. IPv4-in-IPv6 packets are de-encapsulated and then NAT operation is applied. Once this operation is performed, the DS-lite node encapsulates the NATed IPv4 datagrams in IPv6 ones using the following information: o Source IPv6 address: One of the DS-Lite node IPv6 addresses. o Destination IPv6 address: WKIPv6+Original IPv4 address (i.e. the destination IPv4 address contained in the encapsulated datagrams). Encapsulated traffic is then forwarded until reaching another DS-lite Boucadair, et al. Expires October 31, 2009 [Page 8] Internet-Draft Extended DS-lite April 2009 CGN node, if the traffic remains in the same domain, or an IPv6-IPv4 Interconnection equipment. o If datagrams are received by a DS-lite node (e.g. See Figure 3), it de-encapsulates them and handles the embedded IPv4 ones according to [I-D.ietf-softwire-dual-stack-lite]. o If received by an Interconnection node (e.g. See Figure 4), it proceeds to a de-encapsulation operation and then the traffic is forwarded to the next IPv4 destination according to installed IPv4 routes. As illustrated in the figure, the communications between two CPEs attached to a DS-lite enabled domain are implemented using IPv6 only capabilities. IPv4 datagrams are encapsulated in IPv6 ones. The NAT function is implemented by DS-lite CGN nodes. +------+ +---------+ +---------+ +------+ | |--IPv6---\ | |------IPv6-----\ | |---IPv6--\ | | | |--IPv4---\\| |-----IPv4------\\| |---IPv4--\\| | | |---------//| |---------------//| |---------//| | | |---------/ | |---------------/ | |---------/ | | | CPE 1| | DS-lite | | DS-lite | | CPE2 | | | /---IPv6--| CGN A | /-----IPv6------| CGN B | /---IPv6--| | | |//---IPv4--| |//----IPv4-------| |//--IPv4---| | | |\\---------| |\\---------------| |\\---------| | | | \---------| | \---------------| | \---------| | +------+ +---------+ +---------+ +------+ Machines behind each CPE are not represented in the figure. Figure 3: Flow Example involving two devices attached to the same DS- lite enabled domain Boucadair, et al. Expires October 31, 2009 [Page 9] Internet-Draft Extended DS-lite April 2009 The following figure illustrates an example of a CPE, located behind a DS-lite CGN node, which establishes a communication with a remote machine (referred to as RM) which is IPv4-only. +------+ +---------+ +---------+ +------+ | |--IPv6---\ | |------IPv6-----\ | | | | | |--IPv4---\\| |-----IPv4------\\| |---IPv4--\| | | |---------//| |---------------//| |---------/| | | |---------/ | |---------------/ | | | | | CPE 1| | DS-lite | |IPv6-IPv4| | RM | | | /---IPv6--| CGN A | /-----IPv6------| ICXF | | | | |//---IPv4--| |//----IPv4-------| |/--IPv4---| | | |\\---------| |\\---------------| |\---------| | | | \---------| | \---------------| | | | +------+ +---------+ +---------+ +------+ Machines located behind CPE1 are not represented in the figure. Figure 4: Flow Example involving only one device attached to a DS- lite enabled domain 3.4. IPv6-IPv4 Interconnection Function As mentioned above, a dedicated node called IPv6-IPv4 Interconnection function (IPv6-IPv4 ICXF) is required to interconnect an IPv6-only domain (which hosts a DS-lite CGN function) and an IPv4 one. This function is required to interconnect both realms without introducing any additional NAT operation in the path. The following sub-sections provide more information about the behaviour of this function. 3.4.1. Provisioning Information An IPv6-IPv4 Interconnection node is provisioned with a WKIPv6 which is an IPv6 prefix that can be assigned by IANA or be part of the service provider's prefix. This prefix is used to build IPv4- inferred IPv6 addresses (structured as WKIPv6+IPv4_addr). IPv4_addr refers to an IPv4 address (or network) that can be reached through the IPv6-IPv4 Interworking node. These IPv4 addresses may be static or dynamic (e.g. learned via a dedicated protocol such as BGP). 3.4.2. Routing Considerations Two modes may be envisaged: Boucadair, et al. Expires October 31, 2009 [Page 10] Internet-Draft Extended DS-lite April 2009 o Static mode: IPv4-inferred IPv6 prefixes, structured as WKIPv6+ IPv4_addr, are provided to IPv6-IPv4 ICXF through a dedicated configuration means (e.g. CLI). o Dynamic mode: IPv6-IPv4 ICXF is responsible to build IPv4-inferred IPv6 prefixes which are structured as WKIPv6+IPv4_addr. The aforementioned IPv4-inferred IPv6 prefixes are then advertised in IGP. Thus, IPv4-encapsulated traffic will reach the appropriate IPv6-IPv4 ICXF. 3.4.3. Processing Operations Figure 5 shows the input and output of an IPv6-IPv4 ICXF. +-------------------+ ----IPv6---\ | | ----IPv4---\\| |----IPv4---\ -----------//| |-----------/ -----------/ | | | IPv6-IPv4 | /----IPv6---| ICXF | //---IPv4----| |/---IPv4---- \\-----------| |\----------- \-----------| | +-------------------+ Figure 5: IPv6-IPv4 Interworking Function Concretely, when the interconnection node receives IPv4 traffic from an adjacent domain, it encapsulates IPv4 datagrams in IPv6 using the following information: o Source IPv6 address: One of its own IPv6 addresses. o Destination IPv6 address: WKIPv6+Original IPv4 address. The traffic is then received by a DS-lite CGN node which de- encapsulates the traffic and handles the embedded IPv4 one according to current DS-lite specification [I-D.ietf-softwire-dual-stack-lite]. As for the IPv6 received traffic, an Interconnection node proceeds to a de-encapsulation operation and then the traffic is forwarded to the next IPv4 destination according to installed IPv4 routes. Boucadair, et al. Expires October 31, 2009 [Page 11] Internet-Draft Extended DS-lite April 2009 4. Design Considerations The aforementioned functions (i.e. DS-lite CGN and IPv6-IPv4 ICXF) may be hosted in the same node or distinct ones according to the underlying topology constraints and dimensioning considerations. Nevertheless for scalability reasons, it is not recommended to deploy a DS-lite CGN function far (from the access network) in the network since this would create a concentrator and then may be considered as a single point of failure. Furthermore, the routing would not be optimal, particularly for intra-domain traffic. 5. Conclusions This proposal allows to migrate toward an IPv6-only network while offering: o Global IPv6 <==> IPv6 communications. o Global IPv4 <==> IPv4 communications. o A remote IPv6 host would reach a host connected to the DS-lite enabled domain using IPv6. o A remote IPv4 host would reach a host connected to the DS-lite enabled domain using IPv4-in-IPv6. Since end user's devices are DS(-lite), the appropriate connectivity protocol (IPv4 or IPv6) is selected to issue outgoing traffic. Therefore, IPv4-to-IPv6 and IPv6-to-IPv4 communications are not considered as valid scenarios within the proposed architecture. 6. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 7. Security Considerations TBC Boucadair, et al. Expires October 31, 2009 [Page 12] Internet-Draft Extended DS-lite April 2009 8. Acknowledgements TBC 9. References 9.1. Normative References [I-D.ietf-softwire-dual-stack-lite] Durand, A., Droms, R., Haberman, B., and J. Woodyatt, "Dual-stack lite broadband deployments post IPv4 exhaustion", draft-ietf-softwire-dual-stack-lite-00 (work in progress), March 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [I-D.bajko-pripaddrassign] Bajko, G., Savolainen, T., Boucadair, M., and P. Levis, "Port Restricted IP Address Assignment", draft-bajko-pripaddrassign-01 (work in progress), March 2009. [I-D.boucadair-behave-ipv6-portrange] Boucadair, M., Levis, P., Grimault, J., Villefranque, A., and M. Kassi-Lahlou, "Flexible IPv6 Migration Scenarios in the Context of IPv4 Address Shortage", draft-boucadair-behave-ipv6-portrange-01 (work in progress), March 2009. [I-D.boucadair-port-range] Boucadair, M., Levis, P., Bajko, G., and T. Savolainen, "IPv4 Connectivity Access in the Context of IPv4 Address Exhaustion", draft-boucadair-port-range-01 (work in progress), January 2009. [I-D.boucadair-pppext-portrange-option] Boucadair, M., Levis, P., Grimault, J., and A. Villefranque, "Port Range Configuration Options for PPP IPCP", draft-boucadair-pppext-portrange-option-00 (work in progress), February 2009. [I-D.ymbk-aplusp] Bush, R., Maennel, O., Zorz, J., Bellovin, S., and L. Cittadini, "The A+P Approach to the IPv4 Address Boucadair, et al. Expires October 31, 2009 [Page 13] Internet-Draft Extended DS-lite April 2009 Shortage", draft-ymbk-aplusp-03 (work in progress), March 2009. Authors' Addresses Mohamed BOUCADAIR (editor) France Telecom 3, Av Francois Chateaux Rennes, 35000 France Email: mohamed.boucadair@orange-ftgroup.com Christian JACQUENET France Telecom Email: christian.jacquenet@orange-ftgroup.com Jean Luc GRIMAULT France Telecom Email: jeanluc.grimault@orange-ftgroup.com Mohammed KASSI LAHLOU France Telecom Email: mohamed.kassilahlou@orange-ftgroup.com Pierre LEVIS France Telecom Email: pierre.levis@orange-ftgroup.com Boucadair, et al. Expires October 31, 2009 [Page 14]