Network Working Group M. Boucadair, Ed. Internet-Draft C. Jacquenet Intended status: Standards Track JL. Grimault Expires: April 8, 2010 M. Kassi-Lahlou P. Levis France Telecom D. Cheng Huawei Technologies Co., Ltd. Y. Lee Comcast October 5, 2009 Deploying Dual-Stack lite in IPv6-only Network draft-boucadair-dslite-interco-v4v6-02 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 April 8, 2010. Boucadair, et al. Expires April 8, 2010 [Page 1] Internet-Draft Extended DS-lite October 2009 Copyright Notice 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 Dual-Stack lite (DS-lite) [I-D.ietf-softwire-dual-stack-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. IPv6 transfer capabilities are used for the transfer of IPv4-addressed datagrams in a completely stateless scheme between the interconnection segment and the DS-lite CGN node(s). The proposed DS-lite extension is meant to encourage (if not accelerate) IPv6 deployment in networks. 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 April 8, 2010 [Page 2] Internet-Draft Extended DS-lite October 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. IPv4 Address Exhaustion . . . . . . . . . . . . . . . . . 4 1.2. Dual-Stack lite . . . . . . . . . . . . . . . . . . . . . 4 1.3. Contribution of this draft . . . . . . . . . . . . . . . . 4 1.4. What's new compared to RFC5565 . . . . . . . . . . . . . . 5 1.5. Changes since 01 . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Global Architecture . . . . . . . . . . . . . . . . . . . 7 3.2. Customer Attachment Device . . . . . . . . . . . . . . . . 8 3.3. DS-lite CGN Node . . . . . . . . . . . . . . . . . . . . . 9 3.3.1. Provisioning Information . . . . . . . . . . . . . . . 9 3.3.2. Routing Considerations . . . . . . . . . . . . . . . . 10 3.3.3. Processing Operations . . . . . . . . . . . . . . . . 10 3.4. IPv6-IPv4 Interconnection Function . . . . . . . . . . . . 12 3.4.1. Provisioning Information . . . . . . . . . . . . . . . 13 3.4.2. Routing Considerations . . . . . . . . . . . . . . . . 13 3.4.3. BGP Behavior . . . . . . . . . . . . . . . . . . . . . 14 3.4.4. Processing Operations . . . . . . . . . . . . . . . . 15 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 15 5. Multicast Considerations . . . . . . . . . . . . . . . . . . . 16 6. Applicability in the context of A+P . . . . . . . . . . . . . 16 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Boucadair, et al. Expires April 8, 2010 [Page 3] Internet-Draft Extended DS-lite October 2009 1. Introduction 1.1. IPv4 Address Exhaustion IPv4 addresses are finite resources. The current prediction is that RIRs will allocate their last /8s in 2012. Detailed information is available at http://www.potaroo.net/tools/ipv4. To address this problem, IETF has defined IPv6 Protocol [RFC2460] which extends the 32-bit address space to 128-bit address space. Unfortunately, IPv4 and IPv6 are incompatible. IPv6-only CPEs cannot reach IPv4 services w/o address family translation. Consider the fact that the Internet will take time to fully migrate to IPv6, the IETF community is actively discussing techniques to make sure IPv4-to-IPv4 communications can still be established in IPv6 access network where global IPv4 addresses have become a scarce resource that will be shared between several customers. Dual-Stack lite (DS-lite) [I-D.ietf-softwire-dual-stack-lite] is one of the potential techniques. 1.2. Dual-Stack lite DS-lite solution contains two major components: the DS-lite CPE client which initiates the IPv4-in-IPv6 softwire towards the DS-lite CGN node, and the DS-lite CGN node which terminates the IPv4-in-IPv6 softwire and performs NAT44 function on the IPv4 datagram. Hosts connected to the CPE use RFC1918 addresses to source IPv4 datagrams. The CPE forwards the IPv4 datagrams over the IPv4-in-IPv6 softwire towards the DS-lite CGN node. The CGN receives the IPv4 datagrams, performs NAT44 on them, and forwards them to the IPv4 Internet. The DS-lite CGN is configured with a pool of public IPv4 addresses that will be shared by multiple customers. Note that the deployment of DS-lite CGN capabilities is not necessarily centralized and several nodes may be deployed for load-balancing, redundancy and other scalability considerations. Current DS-lite specification defines that the DS-lite CGN nodes communicate to both IPv4 and IPv6 networks. Consider the deployment model where CGN nodes are deployed in the edge of the network, the CGN nodes MUST connect to an IPv4 core network to forward IPv4 datagrams. 1.3. Contribution of this draft This memo proposes an extended solution that allows the DS-lite CGN node to be deployed in an IPv6-only network. More precisely, this memo proposes to extend DS-lite CGN node with a new stateless encapsulation/decapsulation capability that delivers the NAT-ed IPv4 datagram in an IPv4-inferred IPv6 datagram after the NAT44 function. Boucadair, et al. Expires April 8, 2010 [Page 4] Internet-Draft Extended DS-lite October 2009 Furthermore, this document proposes a new stateless IPv6-IPv4 Interconnection Function (IPv6-IPv4 ICXF) in the border element of the IPv6 network that will translate IPv6 datagrams into IPv4 datagrams for the sake of IPv4 connectivity. In this memo, the DS-lite CGN node is not directly connected to an IPv4 network. After performing IPv4-in-IPv6 de-capsulation and NAT operation, the DS-lite CGN node will encapsulate the NAT-ed IPv4 datagram in an IPv4-in-IPv6 datagram and forward the datagram in the IPv6 network towards an ICXF-capable router located in the network border. The stateless IPv6-IPv4 Interconnection Function (IPv6-IPv4 ICXF) is introduced. This function may be hosted in an ASBR (Autonomous System Border Router) 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 datagrams and de-encapsulating IPv4-in-IPv6 datagrams. An ICXF- capable router refers to the border router implemented with IPv6-IPv4 ICXF. It resides in the border of an IPv6-only network but also connects to one or more IPv4 networks. When the ICXF-capable router receives the IPv4-inferred IPv6 datagram from a DS-lite CGN node, it will de-capsulate the datagram and forward the IPv4 datagram based on the IPv4 destination address in the header. For incoming IPv4 traffic, the ICXF router will encapsulate the IPv4 datagram into an IPv6 datagram with the IPv4-inferred IPv6 address and forward it to the appropriate DS-lite CGN node. 1.4. What's new compared to RFC5565 One of the two scenarios softwire mesh [RFC5565] covers is IPv4 tunneling through an IPv6-only backbone. Mesh defines an interconnection function at the backbone's edge routers called AFBR. All AFBRs exchange i-BGP routes. When an IPv4 datagram arrives at an AFBR, it uses a BGP-distributed route to retrieve the IPv6 destination address of the distant softwire endpoint. The AFBRs will form a mesh network tunneling the IPv4 datagrams over softwire. The AFBRs must maintain a stateful mapping table for encapsulation and de-capsulation purposes. This document covers a slightly different IPv4 over IPv6 scenario. This scenario is asymmetric. On one side of the IPv6 backbone, there are CGNs, and on the other side of the IPv6 backbone there are IPv4 Internet access points. At each IPv4 Internet access point we define an interconnection function called ICXF. All ICXFs exchange i-BGP information. In some scenarios, CGNs do not participate in the i-BGP exchanges (since IGP may be used, see Section 3.3.2 for more details). Boucadair, et al. Expires April 8, 2010 [Page 5] Internet-Draft Extended DS-lite October 2009 Unlike [RFC5565], the encapsulation at both sides is stateless: the IPv6 destination address of the distant softwire endpoint is automatically generated, based on the IPv4 destination address of the IPv4 datagram only, there is no need to refer to any route. The forwarding of the encapsulated datagrams is ensured by the installation of appropriate routes by i-BGP between ICXFs. 1.5. Changes since 01 The following changes have been made since the last version: 1. A new co-author has joined the draft's team; 2. Add a new section to position the proposed solution versus RFC5565; 3. Add a new section to describe in detail the routing considerations; 4. Add a new section on multicast considerations; 5. Various editorial changes. 2. Terminology This memo defines the following terms: o DS-lite CGN node: refers to the CGN node whose behavior is specified in [I-D.ietf-softwire-dual-stack-lite]. This node embeds a CGN function. In addition, this draft makes the assumption that the DS-lite CGN node is only connected to an IPv6 network. Within this draft, the CGN design scheme assumes that only IPv6 traffic will be forwarded in the backbone that embeds DS-lite capabilities, including IPv6 traffic that conveys encapsulated IPv4 datagrams and which is sent to ICXF-enabled routers. This encapsulation is stateless. o IPv6-IPv4 Interconnection function (IPv6-IPv4 ICXF): refers to the function that de-capsulates (resp., encapsulates) the IPv6 (resp., IPv4) datagram from DS-lite CGN node(s) and forwards the IPv4 (resp., IPv6) datagrams to the IPv4 (resp., IPv6) networks. o ICXF router: refers to the border router implemented with IPv6- IPv4 ICXF. o Access segment: This segment encompasses both the IP access and backhaul network. Boucadair, et al. Expires April 8, 2010 [Page 6] Internet-Draft Extended DS-lite October 2009 o Interconnection segment: Includes all nodes and resources which are deployed at the border of a given AS (Autonomous System) a la BGP. o Core segment: Denotes a set of IP networking capabilities and resources which are located between the interconnection and the access segments. o Customer Attachment Device: A customer may use a terminal or a CPE to access the he/she has subscribed to. This device is referred to as Customer Attachment Device. This device is standard DS-lite client device. This extension does not introduce any new functionality to that device. In this memo, CPE refers to 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 extension of the DS-lite approach. 3.1. Global Architecture Figure 1 provides an overview of the global architecture. 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 the end-user terminal devices. The service domain is IPv6 only and interconnection with adjacent IPv4 realms is implemented using IPv6-IPv4 ICXF. Boucadair, et al. Expires April 8, 2010 [Page 7] Internet-Draft Extended DS-lite October 2009 +--------------------------------+ | 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: Global Architecture The following sub-sections provide more details about the proposed solution. 3.2. Customer Attachment Device The Customer Attachment Device is (dynamically) assigned an IPv6 prefix and also acquires IPv6 reachability information to forward IPv6 traffic outside of the customer premises. The Customer Attachment Device also supports DS-lite-specific capabilities (namely an encapsulation scheme to convey privately-addressed IPv4 traffic into IPv6 datagrams that will be sent to one of the available CGN devices located in the network). DS-lite CGN IPv6 reachability information is also (dynamically) provisioned to the Customer Attachment Device, e.g. by means of a specific DHCPv6 option[I-D.dhankins-softwire-tunnel-option]. To reach a CGN, a FQDN may be provided to the Customer Attachment Device instead of an IPv6 address. For outbound IPv6 datagrams, the Customer Attachment Device routes them natively in the service domain. For outbound IPv4 datagrams, the Customer Attachment Device encapsulates the private-addressed IPv4 datagrams in IPv6 ones. These datagrams are forwarded (without any NAT operation) towards a DS-lite CGN node. Boucadair, et al. Expires April 8, 2010 [Page 8] Internet-Draft Extended DS-lite October 2009 For inbound IPv6 datagram, the Customer Attachment device routes them natively to the hosts connected to it. For inbound IPv4 datagrams, the Customer Attachment Device proceeds to de-encapsulation operation. De-encapsulated datagrams are routed locally and forwarded to the hosts connected to the Customer Attachment Device. This is standard DS-lite client behavior defined in [I-D.ietf-softwire-dual-stack-lite]. This memo does not add new requirement. 3.3. DS-lite CGN Node 3.3.1. Provisioning Information DS-lite CGN nodes are provisioned with: o Pref6: An IPv6 prefix which may be assigned by IANA or by LIR as described in [I-D.ietf-behave-address-format]. This prefix is used to construct an IPv4-inferred IPv6 address. More information are provided in Section 3.3.3. The choice between IANA and LIR is left to service provider's engineering policies. o A set of IPv6 prefixes which are structured as Pref6+IPv4_Addr: * Pref6 is the IPv6 prefix dedicated to the IPv4-IPv6 interconnection. * IPv4_Addr is a public IPv4 address used by the DS-lite CGN to enforce its NAT44 operations. + Several IPv4_Addrs may be configured on a DS-lite node. These IPv4_Addrs SHOULD be aggregated, leading to aggregated Pref6+IPv4_Addr prefixes. + Each IPv4_Addr represents multiple IPv4 customers served by the DS-lite CGN node. Figure 2 gives an example of address format. For more information about mapping address format, refer to [I-D.ietf-behave-address-format]. In this example, Pref6 is 2a01:c::/20 and the IPv4_Addr is 193.51.145.206. Then, the corresponding IPv6 prefix is: 2a01:cc13: 391c:e0::/56. Boucadair, et al. Expires April 8, 2010 [Page 9] Internet-Draft Extended DS-lite October 2009 2a01:c::11000001001100111001000111001110 = 2a01:cc13:391c:e0::/56 |Pref6 | <--------193.51.145.206--------> Figure 2: Example for an IPv4-Inferred IPv6 Prefix 3.3.2. Routing Considerations To enable stateless de-/encapsulation in the ICXF router, the DS-lite CGN nodes MUST use the aforementioned Pref6 to construct the IPv4- Inferred IPv6 address when forwarding datagrams received from a customer device. A DS-lite node (or the upstream router of the DS-lite node) advertises the IPv6 prefix it manages (i.e., the set of Pref6+ IPv4_Addr prefix described above) by IGP (e.g. OSPFv3). Such announcement is required so that all traffic sent to an IPv6 address belonging to the IPv6 prefix managed by the DS-lite CGN node MUST be forwarded to the appropriate DS-lite node. These prefixes MUST NOT be advertised to external peers (e.g., e-BGP peers). 3.3.3. Processing Operations Figure 3 shows the input and output of a DS-lite CGN node. +-------------------+ ----IPv6---\ | |----IPv6---\ ----IPv4---\\| |----IPv4---\\ -----------//| |-----------// -----------/ | |-----------/ Customer | DS-lite | /----IPv6---| CGN | /----IPv6--- //---IPv4----| |//---IPv4---- \\-----------| |\\----------- \-----------| | \----------- +-------------------+ DS-lite Interface Core Node Interface Figure 3: Modified DS-lite CGN Two main interfaces may be distinguished in a DS-lite CGN node: a. Interface with the customer device, i.e., DS-lite interface, per [I-D.ietf-softwire-dual-stack-lite]. Boucadair, et al. Expires April 8, 2010 [Page 10] Internet-Draft Extended DS-lite October 2009 b. Interface with core nodes. Note that the DS-lite CGN node does not directly connect to an IPv4 domain. The processing of the IPv4 traffic received from a customer device is as follows. IPv4-in-IPv6 datagrams (issued by the customer device) are de- encapsulated and then NAT operation is applied. Once this operation is performed, the DS-lite node encapsulates the NAT-ed IPv4 datagrams in IPv6 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: Pref6+IPv4_Addr destination address (i.e., the destination IPv4 address contained in the encapsulated datagrams). Encapsulated traffic is forwarded until it reaches 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., Figure 4), it de-capsulates 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 5), it proceeds to a de-capsulation operation and then the traffic is forwarded to the next IPv4 destination according to the installed IPv4 routes. As illustrated in Figure 4, the communications between two CPEs attached to a DS-lite domain are implemented using IPv6 transfer capabilities only. IPv4 datagrams are encapsulated in IPv6 ones. Boucadair, et al. Expires April 8, 2010 [Page 11] Internet-Draft Extended DS-lite October 2009 +------+ +---------+ +---------+ +------+ | |--IPv6---\ | |------IPv6-----\ | |---IPv6--\ | | | |--IPv4---\\| |-----IPv4------\\| |---IPv4--\\| | | |---------//| |---------------//| |---------//| | | |---------/ | |---------------/ | |---------/ | | | CPE 1| | DS-lite | | DS-lite | | CPE2 | | | /---IPv6--| CGN A | /-----IPv6------| CGN B | /---IPv6--| | | |//---IPv4--| |//----IPv4-------| |//--IPv4---| | | |\\---------| |\\---------------| |\\---------| | | | \---------| | \---------------| | \---------| | +------+ +---------+ +---------+ +------+ Note that hosts connected to each CPE are not represented in the figure. Figure 4: Flow Example involving two devices attached to distinct CGNs The following figure illustrates an example of CPE connected to a DS- lite CGN node, which establishes a communication with a remote host (referred to as RH) which is IPv4-enabled. +------+ +---------+ +---------+ +------+ | |--IPv6---\ | |------IPv6-----\ | | | | | |--IPv4---\\| |-----IPv4------\\| |---IPv4--\| | | |---------//| |---------------//| |---------/| | | |---------/ | |---------------/ | | | | | CPE 1| | DS-lite | |IPv6-IPv4| | RH | | | /---IPv6--| CGN A | /-----IPv6------| ICXF | | | | |//---IPv4--| |//----IPv4-------| |/--IPv4---| | | |\\---------| |\\---------------| |\---------| | | | \---------| | \---------------| | | | +------+ +---------+ +---------+ +------+ Note that host connected to CPE1 are not represented in the figure. Figure 5: Flow Example involving only one device attached to a DS- lite enabled domain 3.4. IPv6-IPv4 Interconnection Function A dedicated node called IPv6-IPv4 Interconnection Function (IPv6-IPv4 ICXF) is required to interconnect an IPv6-only network (which hosts a DS-lite CGN function) and an IPv4 network. This function is required Boucadair, et al. Expires April 8, 2010 [Page 12] Internet-Draft Extended DS-lite October 2009 to interconnect both realms to receive and forward IPv4 datagrams from the DS-lite clients and IPv4 Internet. The following sub-sections provide more information about the behavior of this function. 3.4.1. Provisioning Information An IPv6-IPv4 Interconnection node is provisioned with a Pref6. This prefix is used to build IPv4-inferred IPv6 addresses (structured as Pref6+IPv4_Addr). IPv4_Addr refers to an IPv4 address (or network) that can be reached through the IPv6-IPv4 interconnection node. IPv4 addresses may be statically configured or dynamically learned (IPv4 peers). 3.4.2. Routing Considerations Two modes may be considered: o Static mode: IPv4-inferred IPv6 prefixes, structured as Pref6+ IPv4_Addr, are manually configured in the IPv6-IPv4 ICXF router. o Dynamic mode: IPv6-IPv4 ICXF router is responsible to build IPv4- inferred IPv6 prefixes which are structured as Pre6+IPv4_addr. These addresses represent IPv4 reachable destinations in the IPv6- only realm. IPv4 traffic encapsulated in IPv6 datagrams will be forwarded to ICXF routers. The selection of the appropriate ICXF router is based upon the computation of the best (shortest) IPv4 route towards the IPv4 destination. There are several ways to proceed. As examples, we describe two solutions: a one-step process and a two-step process. The one-step process can be achieved using softwire mesh ([RFC5565]). ICXF routers and CGNs exchange i-BGP information. Particularly, the CGNs receive and process the i-BGP advertisements. From the i-BGP information, CGNs build IPv4 routes where the next hop is the IPv6 address of the ICXF router which has the best route to the IPv4 destination. Whenever a CGN has to encapsulate an IPv4 datagram into IPv6, it looks up the IPv6 destination in its BGP-distributed routes. The IPv6 datagram is then directly routed from the CGN to the relevant ICXF router, in a one-step process. In this scenario, CGNs maintain a full BGP IPv4 routing table, and the IPv4-in-IPv6 encapsulation is stateful. In the two-step process, ICXF routers exchange i-BGP information as in the previous scenario, but, contrary to the previous scenario, CGNs do not participate to the i-BGP mesh. Furthermore, each ICXF Boucadair, et al. Expires April 8, 2010 [Page 13] Internet-Draft Extended DS-lite October 2009 router advertises a route to Pref6 in IPv6 IGP. Whenever a CGN has to encapsulate an IPv4 datagram into IPv6, it dynamically builds the IPv6 destination address from the IPv4 destination address: Pref6+ IPv4_Addr. The IPv6 datagram is then routed to the nearest ICXF router. This ICXF router then forwards, if necessary, the IPv6 datagram to the ICXF router which has the best route to the IPv4 destination. Thus, IPv6 datagram may be routed in a two-step process. In this scenario, CGNs do not maintain any IPv4 BGP routing table, and the IPv4-in-IPv6 encapsulation is stateless. IPv4-inferred IPv6 reachability information (received from adjacent domains) should be advertised using i-BGP between ICXF routers, to avoid a full redistribution of BGP routes into IGP. Recursive routing lookup will be then executed to select the appropriate IXCF (exit point). The engineering of the relationship between IGP and i-BGP would follow best practices as those documented in [RFC4277]. Note that the ICXF router does not assign Pref6 + IPv4_Addr IPv6 addresses to its interfaces. 3.4.3. BGP Behavior This section provides a description of the BGP behavior when IPv4- inferred IPv6 routes are to be injected in i-BGP. The following steps are to be followed: o e-BGP session is maintained between an ICXF router and its IPv4 peer. IPv4 routes are exchanged between these two peers. Particularly, ICXF router advertises to its peers a set of reachable IPv4 networks through its attached domain (e.g., AS). These IPv4 networks include the IPv4 addresses used by CGN devices. o No new capability BGP attribute is required with the context of stateless IPv4-IPv6 interconnection. o Each ICXF router is configured with a dedicated IPv6 prefix (Pref6) which is to be used to build IPv4-inferred IPv6 prefixes (e.g., IPv4-inferred IPv6 prefix=Pref6+IPv4 net). o For each route towards an IPv4 network, a corresponding IPv6 prefix is built as per the method described in Section 3.3.3. These routes are then injected in i-BGP to all internal peers to synchronise the overall BGP routing table and avoid loops. Boucadair, et al. Expires April 8, 2010 [Page 14] Internet-Draft Extended DS-lite October 2009 3.4.4. Processing Operations Figure 6 shows the input and output of an IPv6-IPv4 ICXF. +-------------------+ ----IPv6---\ | | ----IPv4---\\| |----IPv4---\ -----------//| |-----------/ -----------/ | | | IPv6-IPv4 | /----IPv6---| ICXF | //---IPv4----| |/---IPv4---- \\-----------| |\----------- \-----------| | +-------------------+ Figure 6: IPv6-IPv4 Interworking Function When the interconnection node receives IPv4 traffic from an IPv4 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: Prefix6+IPv4 Destination address. The IPv4 destination address is part of the DS-lite node address space. The traffic is 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 incoming IPv6 received traffic, an Interconnection node proceeds to a de-capsulation 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 upstream and far from the customer premises since this would create a concentrator and then may be considered as Boucadair, et al. Expires April 8, 2010 [Page 15] Internet-Draft Extended DS-lite October 2009 a single point of failure. Furthermore, the routing would not be optimal, particularly for intra-domain traffic. 5. Multicast Considerations To access IPv4 multicast-based content via the CGN, the following behaviour MAY be implemented: o IPv4-inferred IPv6 multicast addresses are built based on IPv4 multicast address. An IPv4 multicast address is embedded in an IPv6 multicast one. o The ICMP proxy function embedded in a DS-lite CPE forwards ICMP Report messages towards a DS-lite CGN. These ICMP Report messages are encapsulated in IPv6 by the CPE and forwarded to the DS-lite CGN. o The CGN is then able to connect that CPE to the corresponding IPv6 multicast tree using the IPv4-inferred IPv6 multicast address. This document recommends the migration of IPv4 multicast-based services to IPv6 and CGN device to be restricted to process unicast IPv4 traffic. 6. Applicability in the context of A+P The procedure defined in this memo may also apply in the context of PRR (Port Range Router, [I-D.boucadair-port-range]) instead of DS- lite CGN. In the last case the customer attachment device should do the classification of outbound IPv4 packet between A+P and DS-lite mode and the IPv6-IPv4 interconnection function should do the classification of inbound IPv4 datagrams. In this case a specific prefix (Prefix6) may be allocated for each mode. 7. Conclusions This memo describes the mechanism to extend DS-lite to operate 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. Boucadair, et al. Expires April 8, 2010 [Page 16] Internet-Draft Extended DS-lite October 2009 o A remote IPv4 host would reach a host connected to the DS-lite enabled domain using IPv4-in-IPv6. 8. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 9. Security Considerations Security considerations defined in [I-D.ietf-softwire-dual-stack-lite] should be taken into account. In addition, current interconnection practices for ingress traffic filtering should be enforced in the interconnection points (ICXF). 10. Acknowledgements The authors would like to thank Eric Burgey for his support and suggestions. 11. References 11.1. Normative References [I-D.ietf-softwire-dual-stack-lite] Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee, Y., and R. Bush, "Dual-stack lite broadband deployments post IPv4 exhaustion", draft-ietf-softwire-dual-stack-lite-01 (work in progress), July 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. 11.2. Informative References [I-D.boucadair-port-range] Boucadair, M., Levis, P., Bajko, G., and T. Savolainen, "IPv4 Connectivity Access in the Context of IPv4 Address Boucadair, et al. Expires April 8, 2010 [Page 17] Internet-Draft Extended DS-lite October 2009 Exhaustion: Port Range based IP Architecture", draft-boucadair-port-range-02 (work in progress), July 2009. [I-D.dhankins-softwire-tunnel-option] Hankins, D., "Dynamic Host Configuration Protocol Option for Dual-Stack Lite", draft-dhankins-softwire-tunnel-option-03 (work in progress), March 2009. [I-D.ietf-behave-address-format] Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", draft-ietf-behave-address-format-00 (work in progress), August 2009. [RFC4277] McPherson, D. and K. Patel, "Experience with the BGP-4 Protocol", RFC 4277, January 2006. [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh Framework", RFC 5565, June 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 France Email: jeanluc.grimault@orange-ftgroup.com Boucadair, et al. Expires April 8, 2010 [Page 18] Internet-Draft Extended DS-lite October 2009 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. Email: Chengd@huawei.com URI: http://www.huawei.com Yiu L. Lee Comcast Email: yiu_lee@cable.comcast.com URI: http://www.comcast.com Boucadair, et al. Expires April 8, 2010 [Page 19]