Network Working Group M. Boucadair, Ed. Internet-Draft C. Jacquenet Intended status: Informational JL. Grimault Expires: November 19, 2009 M. Kassi Lahlou P. Levis France Telecom D. Cheng Huawei Technologies Co., Ltd. May 18, 2009 Stateless IPv4-IPv6 Interconnection in the Context of DS-lite Deployment draft-boucadair-dslite-interco-v4v6-01 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 November 19, 2009. Copyright Notice Boucadair, et al. Expires November 19, 2009 [Page 1] Internet-Draft Extended DS-lite May 2009 Copyright (c) 2009 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 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). 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 November 19, 2009 [Page 2] Internet-Draft Extended DS-lite May 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Context . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Contribution of this draft . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Overall Procedure . . . . . . . . . . . . . . . . . . . . 6 3.2. Customer Attachment Device . . . . . . . . . . . . . . . . 7 3.3. DS-lite CGN Node . . . . . . . . . . . . . . . . . . . . . 8 3.3.1. Provisioning Information . . . . . . . . . . . . . . . 8 3.3.2. Routing Considerations . . . . . . . . . . . . . . . . 8 3.3.3. Processing Operations . . . . . . . . . . . . . . . . 8 3.4. IPv6-IPv4 Interconnection Function . . . . . . . . . . . . 11 3.4.1. Provisioning Information . . . . . . . . . . . . . . . 11 3.4.2. Routing Considerations . . . . . . . . . . . . . . . . 11 3.4.3. Processing Operations . . . . . . . . . . . . . . . . 12 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 12 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Boucadair, et al. Expires November 19, 2009 [Page 3] Internet-Draft Extended DS-lite May 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. Current DS-lite specification does not solve the IPv4-IPv6 Interconnection issue. This is one of the motivations of the effort documented in this memo. 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. In this memo, a stateless IPv6-IPv4 Interconnection Function (IPv6- Boucadair, et al. Expires November 19, 2009 [Page 4] Internet-Draft Extended DS-lite May 2009 IPv4 ICXF) is explicitly defined. An ICXF-capable node resides in an IPv6-only network but also connects to one or more IPv4 networks. It can encapsulate IPv4 datagrams received from a connected IPv4 network in IPv6 and then send the IPv4-inferred IPv6 datagram towards a DS- Lite CGN device located in the IPv6 network. The ICXF-capable router can also de-capsulate an IPv4 datagram from an IPv6 datagram, and then forward the IPv4 datagram accordingly. The encapsulation/ de-capsulation capabilities are facilitated by an IPv4-inferred IPv6 address scheme which is further detailed in this document. Specific forwarding capabilities are also described in this memo. Some enhancements are added to a DS-lite CGN node. A DS-lite CGN node may not directly connect to an IPv4 network and in this case, an IPv4 datagram originated from customer side and applied with NAT logic, is encapsulated in an IPv6 datagram and forwarded in the IPv6 network further towards an ICXF-capable router. And upon receiving an IPv4-inferred IPv6 datagram, it would de-capsulate the IPv4 datagram, apply NAT logic and then forward the packet to the DS-lite interface with the same behavior as defined in [I-D.ietf-softwire-dual-stack-lite]. Other functions are also described in this memo, so as to strengthen the operation of DS-Lite extensions. Multiple DS-lite CGN nodes and/or ICXF-capable routers may be deployed in a single IPv6 network, where while the former is desirably closer to customers, the latter can reside on ASBR closer to IPv4 networks. 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. Boucadair, et al. Expires November 19, 2009 [Page 5] Internet-Draft Extended DS-lite May 2009 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. 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. As a result this enhancement, a DS-lite CGN node may not directly connect to an IPv4 domain. 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 not require any modification on the customers side compared to what has been listed in [I-D.ietf-softwire-dual-stack-lite]. Boucadair, et al. Expires November 19, 2009 [Page 6] Internet-Draft Extended DS-lite May 2009 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 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 Boucadair, et al. Expires November 19, 2009 [Page 7] Internet-Draft Extended DS-lite May 2009 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. * Each IPv4 address here is served as an IPv4 source address for IPv4 hosts behind CPE (after applying NAT44 logic) in order to communicate with other hosts located in remote IPv4 domains (refer to Figure 1). 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. Boucadair, et al. Expires November 19, 2009 [Page 8] Internet-Draft Extended DS-lite May 2009 +-------------------+ ----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, i.e., DS-lite interface, per [I-D.ietf-softwire-dual-stack-lite]. b. Interface to core nodes. Note this DS-lite CGN node does not directly connect to an IPv4 domain. 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. This source IPv6 address is a global IPv6 address configured on an interface of the DS-lite CGN (e.g., loopback). 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 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 Boucadair, et al. Expires November 19, 2009 [Page 9] Internet-Draft Extended DS-lite May 2009 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 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- Boucadair, et al. Expires November 19, 2009 [Page 10] Internet-Draft Extended DS-lite May 2009 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: 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. These addresses represent IPv4 reachable destinations in the IPv6-only realm. The IPv4-inferred IPv6 reachability information will be dynamically advertised within the domain, to make sure that IPv4-addressed traffic that will be encapsulated in IPv6 datagrams will be forwarded to the relevant IPv4-IPv6 ICXF-enabled router. For scalability reasons, IPv4-inferred IPv6 reachability information may be advertised using i-BGP to avoid redistributing BGP routes in IGP. Note that the IPv6-IPv4 ICXF-capable node does not assign those addresses to its interfaces. Boucadair, et al. Expires November 19, 2009 [Page 11] Internet-Draft Extended DS-lite May 2009 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. 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. Boucadair, et al. Expires November 19, 2009 [Page 12] Internet-Draft Extended DS-lite May 2009 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 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. Boucadair, et al. Expires November 19, 2009 [Page 13] Internet-Draft Extended DS-lite May 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-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 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 Boucadair, et al. Expires November 19, 2009 [Page 14] Internet-Draft Extended DS-lite May 2009 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 Dean Cheng Huawei Technologies Co., Ltd. Phone: Fax: Email: Chengd@huawei.com URI: Boucadair, et al. Expires November 19, 2009 [Page 15]