idnits 2.17.1 draft-boucadair-dslite-interco-v4v6-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 22 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([I-D.ietf-softwire-dual-stack-lite]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 5, 2009) is 5317 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-01 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-05) exists of draft-dhankins-softwire-tunnel-option-03 == Outdated reference: A later version (-10) exists of draft-ietf-behave-address-format-00 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair, Ed. 3 Internet-Draft C. Jacquenet 4 Intended status: Standards Track JL. Grimault 5 Expires: April 8, 2010 M. Kassi-Lahlou 6 P. Levis 7 France Telecom 8 D. Cheng 9 Huawei Technologies Co., Ltd. 10 Y. Lee 11 Comcast 12 October 5, 2009 14 Deploying Dual-Stack lite in IPv6-only Network 15 draft-boucadair-dslite-interco-v4v6-02 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. This document may contain material 21 from IETF Documents or IETF Contributions published or made publicly 22 available before November 10, 2008. The person(s) controlling the 23 copyright in some of this material may not have granted the IETF 24 Trust the right to allow modifications of such material outside the 25 IETF Standards Process. Without obtaining an adequate license from 26 the person(s) controlling the copyright in such materials, this 27 document may not be modified outside the IETF Standards Process, and 28 derivative works of it may not be created outside the IETF Standards 29 Process, except to format it for publication as an RFC or to 30 translate it into languages other than English. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on April 8, 2010. 50 Copyright Notice 52 Copyright (c) 2009 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents in effect on the date of 57 publication of this document (http://trustee.ietf.org/license-info). 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. 61 Abstract 63 This memo describes a proposal to enhance Dual-Stack lite (DS-lite) 64 [I-D.ietf-softwire-dual-stack-lite] solution with an additional 65 feature to ease interconnection between IPv4 and IPv6 realms. When 66 deployed, no dual-stack-enabled network is required for the delivery 67 of both IPv4 and IPv6 connectivity to customers. IPv6 transfer 68 capabilities are used for the transfer of IPv4-addressed datagrams in 69 a completely stateless scheme between the interconnection segment and 70 the DS-lite CGN node(s). The proposed DS-lite extension is meant to 71 encourage (if not accelerate) IPv6 deployment in networks. 73 Requirements Language 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in RFC 2119 [RFC2119]. 79 Table of Contents 81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 82 1.1. IPv4 Address Exhaustion . . . . . . . . . . . . . . . . . 4 83 1.2. Dual-Stack lite . . . . . . . . . . . . . . . . . . . . . 4 84 1.3. Contribution of this draft . . . . . . . . . . . . . . . . 4 85 1.4. What's new compared to RFC5565 . . . . . . . . . . . . . . 5 86 1.5. Changes since 01 . . . . . . . . . . . . . . . . . . . . . 6 87 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 88 3. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 7 89 3.1. Global Architecture . . . . . . . . . . . . . . . . . . . 7 90 3.2. Customer Attachment Device . . . . . . . . . . . . . . . . 8 91 3.3. DS-lite CGN Node . . . . . . . . . . . . . . . . . . . . . 9 92 3.3.1. Provisioning Information . . . . . . . . . . . . . . . 9 93 3.3.2. Routing Considerations . . . . . . . . . . . . . . . . 10 94 3.3.3. Processing Operations . . . . . . . . . . . . . . . . 10 95 3.4. IPv6-IPv4 Interconnection Function . . . . . . . . . . . . 12 96 3.4.1. Provisioning Information . . . . . . . . . . . . . . . 13 97 3.4.2. Routing Considerations . . . . . . . . . . . . . . . . 13 98 3.4.3. BGP Behavior . . . . . . . . . . . . . . . . . . . . . 14 99 3.4.4. Processing Operations . . . . . . . . . . . . . . . . 15 100 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 15 101 5. Multicast Considerations . . . . . . . . . . . . . . . . . . . 16 102 6. Applicability in the context of A+P . . . . . . . . . . . . . 16 103 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 16 104 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 105 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 106 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 107 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 108 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 109 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 112 1. Introduction 114 1.1. IPv4 Address Exhaustion 116 IPv4 addresses are finite resources. The current prediction is that 117 RIRs will allocate their last /8s in 2012. Detailed information is 118 available at http://www.potaroo.net/tools/ipv4. To address this 119 problem, IETF has defined IPv6 Protocol [RFC2460] which extends the 120 32-bit address space to 128-bit address space. Unfortunately, IPv4 121 and IPv6 are incompatible. IPv6-only CPEs cannot reach IPv4 services 122 w/o address family translation. Consider the fact that the Internet 123 will take time to fully migrate to IPv6, the IETF community is 124 actively discussing techniques to make sure IPv4-to-IPv4 125 communications can still be established in IPv6 access network where 126 global IPv4 addresses have become a scarce resource that will be 127 shared between several customers. Dual-Stack lite (DS-lite) 128 [I-D.ietf-softwire-dual-stack-lite] is one of the potential 129 techniques. 131 1.2. Dual-Stack lite 133 DS-lite solution contains two major components: the DS-lite CPE 134 client which initiates the IPv4-in-IPv6 softwire towards the DS-lite 135 CGN node, and the DS-lite CGN node which terminates the IPv4-in-IPv6 136 softwire and performs NAT44 function on the IPv4 datagram. Hosts 137 connected to the CPE use RFC1918 addresses to source IPv4 datagrams. 138 The CPE forwards the IPv4 datagrams over the IPv4-in-IPv6 softwire 139 towards the DS-lite CGN node. The CGN receives the IPv4 datagrams, 140 performs NAT44 on them, and forwards them to the IPv4 Internet. The 141 DS-lite CGN is configured with a pool of public IPv4 addresses that 142 will be shared by multiple customers. Note that the deployment of 143 DS-lite CGN capabilities is not necessarily centralized and several 144 nodes may be deployed for load-balancing, redundancy and other 145 scalability considerations. 147 Current DS-lite specification defines that the DS-lite CGN nodes 148 communicate to both IPv4 and IPv6 networks. Consider the deployment 149 model where CGN nodes are deployed in the edge of the network, the 150 CGN nodes MUST connect to an IPv4 core network to forward IPv4 151 datagrams. 153 1.3. Contribution of this draft 155 This memo proposes an extended solution that allows the DS-lite CGN 156 node to be deployed in an IPv6-only network. More precisely, this 157 memo proposes to extend DS-lite CGN node with a new stateless 158 encapsulation/decapsulation capability that delivers the NAT-ed IPv4 159 datagram in an IPv4-inferred IPv6 datagram after the NAT44 function. 161 Furthermore, this document proposes a new stateless IPv6-IPv4 162 Interconnection Function (IPv6-IPv4 ICXF) in the border element of 163 the IPv6 network that will translate IPv6 datagrams into IPv4 164 datagrams for the sake of IPv4 connectivity. 166 In this memo, the DS-lite CGN node is not directly connected to an 167 IPv4 network. After performing IPv4-in-IPv6 de-capsulation and NAT 168 operation, the DS-lite CGN node will encapsulate the NAT-ed IPv4 169 datagram in an IPv4-in-IPv6 datagram and forward the datagram in the 170 IPv6 network towards an ICXF-capable router located in the network 171 border. 173 The stateless IPv6-IPv4 Interconnection Function (IPv6-IPv4 ICXF) is 174 introduced. This function may be hosted in an ASBR (Autonomous 175 System Border Router) or a dedicated node located at the 176 interconnection between IPv6 and IPv4 domains. This function is 177 responsible for encapsulating all received IPv4 datagrams in IPv6 178 datagrams and de-encapsulating IPv4-in-IPv6 datagrams. An ICXF- 179 capable router refers to the border router implemented with IPv6-IPv4 180 ICXF. It resides in the border of an IPv6-only network but also 181 connects to one or more IPv4 networks. When the ICXF-capable router 182 receives the IPv4-inferred IPv6 datagram from a DS-lite CGN node, it 183 will de-capsulate the datagram and forward the IPv4 datagram based on 184 the IPv4 destination address in the header. For incoming IPv4 185 traffic, the ICXF router will encapsulate the IPv4 datagram into an 186 IPv6 datagram with the IPv4-inferred IPv6 address and forward it to 187 the appropriate DS-lite CGN node. 189 1.4. What's new compared to RFC5565 191 One of the two scenarios softwire mesh [RFC5565] covers is IPv4 192 tunneling through an IPv6-only backbone. Mesh defines an 193 interconnection function at the backbone's edge routers called AFBR. 194 All AFBRs exchange i-BGP routes. When an IPv4 datagram arrives at an 195 AFBR, it uses a BGP-distributed route to retrieve the IPv6 196 destination address of the distant softwire endpoint. The AFBRs will 197 form a mesh network tunneling the IPv4 datagrams over softwire. The 198 AFBRs must maintain a stateful mapping table for encapsulation and 199 de-capsulation purposes. 201 This document covers a slightly different IPv4 over IPv6 scenario. 202 This scenario is asymmetric. On one side of the IPv6 backbone, there 203 are CGNs, and on the other side of the IPv6 backbone there are IPv4 204 Internet access points. At each IPv4 Internet access point we define 205 an interconnection function called ICXF. All ICXFs exchange i-BGP 206 information. In some scenarios, CGNs do not participate in the i-BGP 207 exchanges (since IGP may be used, see Section 3.3.2 for more 208 details). 210 Unlike [RFC5565], the encapsulation at both sides is stateless: the 211 IPv6 destination address of the distant softwire endpoint is 212 automatically generated, based on the IPv4 destination address of the 213 IPv4 datagram only, there is no need to refer to any route. The 214 forwarding of the encapsulated datagrams is ensured by the 215 installation of appropriate routes by i-BGP between ICXFs. 217 1.5. Changes since 01 219 The following changes have been made since the last version: 221 1. A new co-author has joined the draft's team; 223 2. Add a new section to position the proposed solution versus 224 RFC5565; 226 3. Add a new section to describe in detail the routing 227 considerations; 229 4. Add a new section on multicast considerations; 231 5. Various editorial changes. 233 2. Terminology 235 This memo defines the following terms: 237 o DS-lite CGN node: refers to the CGN node whose behavior is 238 specified in [I-D.ietf-softwire-dual-stack-lite]. This node 239 embeds a CGN function. In addition, this draft makes the 240 assumption that the DS-lite CGN node is only connected to an IPv6 241 network. Within this draft, the CGN design scheme assumes that 242 only IPv6 traffic will be forwarded in the backbone that embeds 243 DS-lite capabilities, including IPv6 traffic that conveys 244 encapsulated IPv4 datagrams and which is sent to ICXF-enabled 245 routers. This encapsulation is stateless. 247 o IPv6-IPv4 Interconnection function (IPv6-IPv4 ICXF): refers to the 248 function that de-capsulates (resp., encapsulates) the IPv6 (resp., 249 IPv4) datagram from DS-lite CGN node(s) and forwards the IPv4 250 (resp., IPv6) datagrams to the IPv4 (resp., IPv6) networks. 252 o ICXF router: refers to the border router implemented with IPv6- 253 IPv4 ICXF. 255 o Access segment: This segment encompasses both the IP access and 256 backhaul network. 258 o Interconnection segment: Includes all nodes and resources which 259 are deployed at the border of a given AS (Autonomous System) a la 260 BGP. 262 o Core segment: Denotes a set of IP networking capabilities and 263 resources which are located between the interconnection and the 264 access segments. 266 o Customer Attachment Device: A customer may use a terminal or a CPE 267 to access the he/she has subscribed to. This device is referred 268 to as Customer Attachment Device. This device is standard DS-lite 269 client device. This extension does not introduce any new 270 functionality to that device. In this memo, CPE refers to 271 Customer Attachment Device. 273 o IP connectivity information: A set of information (e.g., IP 274 address, default gateway, etc.) required to access IP transfer 275 delivery service. 277 3. Procedure 279 This section describes an extension of the DS-lite approach. 281 3.1. Global Architecture 283 Figure 1 provides an overview of the global architecture. Customers 284 are connected to the service domain via a CPE device. Several DS- 285 lite CGN nodes are deployed to manage the traffic issued/destined 286 from/to the end-user terminal devices. The service domain is IPv6 287 only and interconnection with adjacent IPv4 realms is implemented 288 using IPv6-IPv4 ICXF. 290 +--------------------------------+ 291 | Service Domain | +----------- 292 +----+ | +---------+ | IPv4 293 |CPE1|---------| |IPv6-IPv4|----| Domain A 294 +----+ | | ICXF | | 295 | +---------+ +----------- 296 | +-------+ | 297 | |DS-lite| | +----------- 298 +----+ | | CGN A | +---------+ | IPv4 299 |CPE2|---------| +-------+ |IPv6-IPv4|----| Domain B 300 +----+ | | ICXF | | 301 | +---------+ +----------- 302 | +-------+ | | 303 | |DS-lite| | | +----------- 304 +----+ | | CGN B | | | | IPv4 305 |CPEi|---------| +-------+ | +-------| Domain C 306 +----+ | | | 307 | | +----------- 308 +--------------------------------+ 310 |<---IPv6----------->|<-----IPv6------------->|<---IPv4---- 312 Figure 1: Global Architecture 314 The following sub-sections provide more details about the proposed 315 solution. 317 3.2. Customer Attachment Device 319 The Customer Attachment Device is (dynamically) assigned an IPv6 320 prefix and also acquires IPv6 reachability information to forward 321 IPv6 traffic outside of the customer premises. The Customer 322 Attachment Device also supports DS-lite-specific capabilities (namely 323 an encapsulation scheme to convey privately-addressed IPv4 traffic 324 into IPv6 datagrams that will be sent to one of the available CGN 325 devices located in the network). DS-lite CGN IPv6 reachability 326 information is also (dynamically) provisioned to the Customer 327 Attachment Device, e.g. by means of a specific DHCPv6 328 option[I-D.dhankins-softwire-tunnel-option]. To reach a CGN, a FQDN 329 may be provided to the Customer Attachment Device instead of an IPv6 330 address. 332 For outbound IPv6 datagrams, the Customer Attachment Device routes 333 them natively in the service domain. For outbound IPv4 datagrams, 334 the Customer Attachment Device encapsulates the private-addressed 335 IPv4 datagrams in IPv6 ones. These datagrams are forwarded (without 336 any NAT operation) towards a DS-lite CGN node. 338 For inbound IPv6 datagram, the Customer Attachment device routes them 339 natively to the hosts connected to it. For inbound IPv4 datagrams, 340 the Customer Attachment Device proceeds to de-encapsulation 341 operation. De-encapsulated datagrams are routed locally and 342 forwarded to the hosts connected to the Customer Attachment Device. 344 This is standard DS-lite client behavior defined in 345 [I-D.ietf-softwire-dual-stack-lite]. This memo does not add new 346 requirement. 348 3.3. DS-lite CGN Node 350 3.3.1. Provisioning Information 352 DS-lite CGN nodes are provisioned with: 354 o Pref6: An IPv6 prefix which may be assigned by IANA or by LIR as 355 described in [I-D.ietf-behave-address-format]. This prefix is 356 used to construct an IPv4-inferred IPv6 address. More information 357 are provided in Section 3.3.3. The choice between IANA and LIR is 358 left to service provider's engineering policies. 360 o A set of IPv6 prefixes which are structured as Pref6+IPv4_Addr: 362 * Pref6 is the IPv6 prefix dedicated to the IPv4-IPv6 363 interconnection. 365 * IPv4_Addr is a public IPv4 address used by the DS-lite CGN to 366 enforce its NAT44 operations. 368 + Several IPv4_Addrs may be configured on a DS-lite node. 369 These IPv4_Addrs SHOULD be aggregated, leading to aggregated 370 Pref6+IPv4_Addr prefixes. 372 + Each IPv4_Addr represents multiple IPv4 customers served by 373 the DS-lite CGN node. 375 Figure 2 gives an example of address format. For more information 376 about mapping address format, refer to 377 [I-D.ietf-behave-address-format]. 379 In this example, Pref6 is 2a01:c::/20 and the IPv4_Addr is 380 193.51.145.206. Then, the corresponding IPv6 prefix is: 2a01:cc13: 381 391c:e0::/56. 383 2a01:c::11000001001100111001000111001110 = 2a01:cc13:391c:e0::/56 384 |Pref6 | <--------193.51.145.206--------> 386 Figure 2: Example for an IPv4-Inferred IPv6 Prefix 388 3.3.2. Routing Considerations 390 To enable stateless de-/encapsulation in the ICXF router, the DS-lite 391 CGN nodes MUST use the aforementioned Pref6 to construct the IPv4- 392 Inferred IPv6 address when forwarding datagrams received from a 393 customer device. 395 A DS-lite node (or the upstream router of the DS-lite node) 396 advertises the IPv6 prefix it manages (i.e., the set of Pref6+ 397 IPv4_Addr prefix described above) by IGP (e.g. OSPFv3). Such 398 announcement is required so that all traffic sent to an IPv6 address 399 belonging to the IPv6 prefix managed by the DS-lite CGN node MUST be 400 forwarded to the appropriate DS-lite node. These prefixes MUST NOT 401 be advertised to external peers (e.g., e-BGP peers). 403 3.3.3. Processing Operations 405 Figure 3 shows the input and output of a DS-lite CGN node. 407 +-------------------+ 408 ----IPv6---\ | |----IPv6---\ 409 ----IPv4---\\| |----IPv4---\\ 410 -----------//| |-----------// 411 -----------/ | |-----------/ 412 Customer | DS-lite | 413 /----IPv6---| CGN | /----IPv6--- 414 //---IPv4----| |//---IPv4---- 415 \\-----------| |\\----------- 416 \-----------| | \----------- 417 +-------------------+ 419 DS-lite Interface Core Node Interface 421 Figure 3: Modified DS-lite CGN 423 Two main interfaces may be distinguished in a DS-lite CGN node: 425 a. Interface with the customer device, i.e., DS-lite interface, per 426 [I-D.ietf-softwire-dual-stack-lite]. 428 b. Interface with core nodes. Note that the DS-lite CGN node does 429 not directly connect to an IPv4 domain. 431 The processing of the IPv4 traffic received from a customer device is 432 as follows. 434 IPv4-in-IPv6 datagrams (issued by the customer device) are de- 435 encapsulated and then NAT operation is applied. Once this operation 436 is performed, the DS-lite node encapsulates the NAT-ed IPv4 datagrams 437 in IPv6 using the following information: 439 o Source IPv6 address: One of the DS-lite node IPv6 addresses. This 440 source IPv6 address is a global IPv6 address configured on an 441 interface of the DS-lite CGN (e.g., loopback). 443 o Destination IPv6 address: Pref6+IPv4_Addr destination address 444 (i.e., the destination IPv4 address contained in the encapsulated 445 datagrams). 447 Encapsulated traffic is forwarded until it reaches another DS-lite 448 CGN node, if the traffic remains in the same domain, or an IPv6-IPv4 449 Interconnection equipment. 451 o If datagrams are received by a DS-lite node (e.g., Figure 4), it 452 de-capsulates them and handles the embedded IPv4 ones according to 453 [I-D.ietf-softwire-dual-stack-lite]. 455 o If received by an Interconnection node (e.g., See Figure 5), it 456 proceeds to a de-capsulation operation and then the traffic is 457 forwarded to the next IPv4 destination according to the installed 458 IPv4 routes. 460 As illustrated in Figure 4, the communications between two CPEs 461 attached to a DS-lite domain are implemented using IPv6 transfer 462 capabilities only. IPv4 datagrams are encapsulated in IPv6 ones. 464 +------+ +---------+ +---------+ +------+ 465 | |--IPv6---\ | |------IPv6-----\ | |---IPv6--\ | | 466 | |--IPv4---\\| |-----IPv4------\\| |---IPv4--\\| | 467 | |---------//| |---------------//| |---------//| | 468 | |---------/ | |---------------/ | |---------/ | | 469 | CPE 1| | DS-lite | | DS-lite | | CPE2 | 470 | | /---IPv6--| CGN A | /-----IPv6------| CGN B | /---IPv6--| | 471 | |//---IPv4--| |//----IPv4-------| |//--IPv4---| | 472 | |\\---------| |\\---------------| |\\---------| | 473 | | \---------| | \---------------| | \---------| | 474 +------+ +---------+ +---------+ +------+ 476 Note that hosts connected to each CPE are not represented in the 477 figure. 479 Figure 4: Flow Example involving two devices attached to distinct 480 CGNs 482 The following figure illustrates an example of CPE connected to a DS- 483 lite CGN node, which establishes a communication with a remote host 484 (referred to as RH) which is IPv4-enabled. 486 +------+ +---------+ +---------+ +------+ 487 | |--IPv6---\ | |------IPv6-----\ | | | | 488 | |--IPv4---\\| |-----IPv4------\\| |---IPv4--\| | 489 | |---------//| |---------------//| |---------/| | 490 | |---------/ | |---------------/ | | | | 491 | CPE 1| | DS-lite | |IPv6-IPv4| | RH | 492 | | /---IPv6--| CGN A | /-----IPv6------| ICXF | | | 493 | |//---IPv4--| |//----IPv4-------| |/--IPv4---| | 494 | |\\---------| |\\---------------| |\---------| | 495 | | \---------| | \---------------| | | | 496 +------+ +---------+ +---------+ +------+ 498 Note that host connected to CPE1 are not represented in the figure. 500 Figure 5: Flow Example involving only one device attached to a DS- 501 lite enabled domain 503 3.4. IPv6-IPv4 Interconnection Function 505 A dedicated node called IPv6-IPv4 Interconnection Function (IPv6-IPv4 506 ICXF) is required to interconnect an IPv6-only network (which hosts a 507 DS-lite CGN function) and an IPv4 network. This function is required 508 to interconnect both realms to receive and forward IPv4 datagrams 509 from the DS-lite clients and IPv4 Internet. 511 The following sub-sections provide more information about the 512 behavior of this function. 514 3.4.1. Provisioning Information 516 An IPv6-IPv4 Interconnection node is provisioned with a Pref6. This 517 prefix is used to build IPv4-inferred IPv6 addresses (structured as 518 Pref6+IPv4_Addr). IPv4_Addr refers to an IPv4 address (or network) 519 that can be reached through the IPv6-IPv4 interconnection node. IPv4 520 addresses may be statically configured or dynamically learned (IPv4 521 peers). 523 3.4.2. Routing Considerations 525 Two modes may be considered: 527 o Static mode: IPv4-inferred IPv6 prefixes, structured as Pref6+ 528 IPv4_Addr, are manually configured in the IPv6-IPv4 ICXF router. 530 o Dynamic mode: IPv6-IPv4 ICXF router is responsible to build IPv4- 531 inferred IPv6 prefixes which are structured as Pre6+IPv4_addr. 532 These addresses represent IPv4 reachable destinations in the IPv6- 533 only realm. 535 IPv4 traffic encapsulated in IPv6 datagrams will be forwarded to ICXF 536 routers. The selection of the appropriate ICXF router is based upon 537 the computation of the best (shortest) IPv4 route towards the IPv4 538 destination. There are several ways to proceed. As examples, we 539 describe two solutions: a one-step process and a two-step process. 541 The one-step process can be achieved using softwire mesh ([RFC5565]). 542 ICXF routers and CGNs exchange i-BGP information. Particularly, the 543 CGNs receive and process the i-BGP advertisements. From the i-BGP 544 information, CGNs build IPv4 routes where the next hop is the IPv6 545 address of the ICXF router which has the best route to the IPv4 546 destination. Whenever a CGN has to encapsulate an IPv4 datagram into 547 IPv6, it looks up the IPv6 destination in its BGP-distributed routes. 548 The IPv6 datagram is then directly routed from the CGN to the 549 relevant ICXF router, in a one-step process. In this scenario, CGNs 550 maintain a full BGP IPv4 routing table, and the IPv4-in-IPv6 551 encapsulation is stateful. 553 In the two-step process, ICXF routers exchange i-BGP information as 554 in the previous scenario, but, contrary to the previous scenario, 555 CGNs do not participate to the i-BGP mesh. Furthermore, each ICXF 556 router advertises a route to Pref6 in IPv6 IGP. Whenever a CGN has 557 to encapsulate an IPv4 datagram into IPv6, it dynamically builds the 558 IPv6 destination address from the IPv4 destination address: Pref6+ 559 IPv4_Addr. The IPv6 datagram is then routed to the nearest ICXF 560 router. This ICXF router then forwards, if necessary, the IPv6 561 datagram to the ICXF router which has the best route to the IPv4 562 destination. Thus, IPv6 datagram may be routed in a two-step 563 process. In this scenario, CGNs do not maintain any IPv4 BGP routing 564 table, and the IPv4-in-IPv6 encapsulation is stateless. 566 IPv4-inferred IPv6 reachability information (received from adjacent 567 domains) should be advertised using i-BGP between ICXF routers, to 568 avoid a full redistribution of BGP routes into IGP. Recursive 569 routing lookup will be then executed to select the appropriate IXCF 570 (exit point). The engineering of the relationship between IGP and 571 i-BGP would follow best practices as those documented in [RFC4277]. 573 Note that the ICXF router does not assign Pref6 + IPv4_Addr IPv6 574 addresses to its interfaces. 576 3.4.3. BGP Behavior 578 This section provides a description of the BGP behavior when IPv4- 579 inferred IPv6 routes are to be injected in i-BGP. 581 The following steps are to be followed: 583 o e-BGP session is maintained between an ICXF router and its IPv4 584 peer. IPv4 routes are exchanged between these two peers. 585 Particularly, ICXF router advertises to its peers a set of 586 reachable IPv4 networks through its attached domain (e.g., AS). 587 These IPv4 networks include the IPv4 addresses used by CGN 588 devices. 590 o No new capability BGP attribute is required with the context of 591 stateless IPv4-IPv6 interconnection. 593 o Each ICXF router is configured with a dedicated IPv6 prefix 594 (Pref6) which is to be used to build IPv4-inferred IPv6 prefixes 595 (e.g., IPv4-inferred IPv6 prefix=Pref6+IPv4 net). 597 o For each route towards an IPv4 network, a corresponding IPv6 598 prefix is built as per the method described in Section 3.3.3. 599 These routes are then injected in i-BGP to all internal peers to 600 synchronise the overall BGP routing table and avoid loops. 602 3.4.4. Processing Operations 604 Figure 6 shows the input and output of an IPv6-IPv4 ICXF. 606 +-------------------+ 607 ----IPv6---\ | | 608 ----IPv4---\\| |----IPv4---\ 609 -----------//| |-----------/ 610 -----------/ | | 611 | IPv6-IPv4 | 612 /----IPv6---| ICXF | 613 //---IPv4----| |/---IPv4---- 614 \\-----------| |\----------- 615 \-----------| | 616 +-------------------+ 618 Figure 6: IPv6-IPv4 Interworking Function 620 When the interconnection node receives IPv4 traffic from an IPv4 621 domain, it encapsulates IPv4 datagrams in IPv6 using the following 622 information: 624 o Source IPv6 address: One of its own IPv6 addresses. 626 o Destination IPv6 address: Prefix6+IPv4 Destination address. The 627 IPv4 destination address is part of the DS-lite node address 628 space. 630 The traffic is received by a DS-lite CGN node which de-encapsulates 631 the traffic and handles the embedded IPv4 one according to current 632 DS-lite specification [I-D.ietf-softwire-dual-stack-lite]. 634 As for the incoming IPv6 received traffic, an Interconnection node 635 proceeds to a de-capsulation operation and then the traffic is 636 forwarded to the next IPv4 destination according to installed IPv4 637 routes. 639 4. Design Considerations 641 The aforementioned functions (i.e., DS-lite CGN and IPv6-IPv4 ICXF) 642 may be hosted in the same node or distinct ones according to the 643 underlying topology constraints and dimensioning considerations. 644 Nevertheless for scalability reasons, it is not recommended to deploy 645 a DS-lite CGN function upstream and far from the customer premises 646 since this would create a concentrator and then may be considered as 647 a single point of failure. Furthermore, the routing would not be 648 optimal, particularly for intra-domain traffic. 650 5. Multicast Considerations 652 To access IPv4 multicast-based content via the CGN, the following 653 behaviour MAY be implemented: 655 o IPv4-inferred IPv6 multicast addresses are built based on IPv4 656 multicast address. An IPv4 multicast address is embedded in an 657 IPv6 multicast one. 659 o The ICMP proxy function embedded in a DS-lite CPE forwards ICMP 660 Report messages towards a DS-lite CGN. These ICMP Report messages 661 are encapsulated in IPv6 by the CPE and forwarded to the DS-lite 662 CGN. 664 o The CGN is then able to connect that CPE to the corresponding IPv6 665 multicast tree using the IPv4-inferred IPv6 multicast address. 667 This document recommends the migration of IPv4 multicast-based 668 services to IPv6 and CGN device to be restricted to process unicast 669 IPv4 traffic. 671 6. Applicability in the context of A+P 673 The procedure defined in this memo may also apply in the context of 674 PRR (Port Range Router, [I-D.boucadair-port-range]) instead of DS- 675 lite CGN. In the last case the customer attachment device should do 676 the classification of outbound IPv4 packet between A+P and DS-lite 677 mode and the IPv6-IPv4 interconnection function should do the 678 classification of inbound IPv4 datagrams. In this case a specific 679 prefix (Prefix6) may be allocated for each mode. 681 7. Conclusions 683 This memo describes the mechanism to extend DS-lite to operate an 684 IPv6-only network while offering: 686 o Global IPv6 <==> IPv6 communications. 688 o Global IPv4 <==> IPv4 communications. 690 o A remote IPv6 host would reach a host connected to the DS-lite 691 enabled domain using IPv6. 693 o A remote IPv4 host would reach a host connected to the DS-lite 694 enabled domain using IPv4-in-IPv6. 696 8. IANA Considerations 698 This document makes no request of IANA. 700 Note to RFC Editor: this section may be removed on publication as an 701 RFC. 703 9. Security Considerations 705 Security considerations defined in 706 [I-D.ietf-softwire-dual-stack-lite] should be taken into account. In 707 addition, current interconnection practices for ingress traffic 708 filtering should be enforced in the interconnection points (ICXF). 710 10. Acknowledgements 712 The authors would like to thank Eric Burgey for his support and 713 suggestions. 715 11. References 717 11.1. Normative References 719 [I-D.ietf-softwire-dual-stack-lite] 720 Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee, 721 Y., and R. Bush, "Dual-stack lite broadband deployments 722 post IPv4 exhaustion", 723 draft-ietf-softwire-dual-stack-lite-01 (work in progress), 724 July 2009. 726 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 727 Requirement Levels", BCP 14, RFC 2119, March 1997. 729 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 730 (IPv6) Specification", RFC 2460, December 1998. 732 11.2. Informative References 734 [I-D.boucadair-port-range] 735 Boucadair, M., Levis, P., Bajko, G., and T. Savolainen, 736 "IPv4 Connectivity Access in the Context of IPv4 Address 737 Exhaustion: Port Range based IP Architecture", 738 draft-boucadair-port-range-02 (work in progress), 739 July 2009. 741 [I-D.dhankins-softwire-tunnel-option] 742 Hankins, D., "Dynamic Host Configuration Protocol Option 743 for Dual-Stack Lite", 744 draft-dhankins-softwire-tunnel-option-03 (work in 745 progress), March 2009. 747 [I-D.ietf-behave-address-format] 748 Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X. 749 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 750 draft-ietf-behave-address-format-00 (work in progress), 751 August 2009. 753 [RFC4277] McPherson, D. and K. Patel, "Experience with the BGP-4 754 Protocol", RFC 4277, January 2006. 756 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 757 Framework", RFC 5565, June 2009. 759 Authors' Addresses 761 Mohamed Boucadair (editor) 762 France Telecom 763 3, Av Francois Chateaux 764 Rennes 35000 765 France 767 Email: mohamed.boucadair@orange-ftgroup.com 769 Christian Jacquenet 770 France Telecom 772 Email: christian.jacquenet@orange-ftgroup.com 774 Jean-Luc Grimault 775 France Telecom 776 France 778 Email: jeanluc.grimault@orange-ftgroup.com 779 Mohammed Kassi-Lahlou 780 France Telecom 782 Email: mohamed.kassilahlou@orange-ftgroup.com 784 Pierre Levis 785 France Telecom 787 Email: pierre.levis@orange-ftgroup.com 789 Dean Cheng 790 Huawei Technologies Co., Ltd. 792 Email: Chengd@huawei.com 793 URI: http://www.huawei.com 795 Yiu L. Lee 796 Comcast 798 Email: yiu_lee@cable.comcast.com 799 URI: http://www.comcast.com