idnits 2.17.1 draft-boucadair-dslite-interco-v4v6-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 23 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == 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 (July 11, 2010) is 5028 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) == Missing Reference: 'REQ1' is mentioned on line 137, but not defined == Missing Reference: 'REQ2' is mentioned on line 139, but not defined == Missing Reference: 'REQ3' is mentioned on line 141, but not defined == Missing Reference: 'REQ4' is mentioned on line 144, but not defined == Unused Reference: 'RFC2460' is defined on line 648, but no explicit reference was found in the text == Unused Reference: 'RFC4277' is defined on line 659, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-05 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-10) exists of draft-ietf-behave-address-format-09 Summary: 2 errors (**), 0 flaws (~~), 13 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: January 12, 2011 M. Kassi-Lahlou 6 P. Levis 7 France Telecom 8 D. Cheng, Ed. 9 Huawei Technologies Co., Ltd. 10 Y. Lee, Ed. 11 Comcast 12 July 11, 2010 14 Deploying Dual-Stack Lite in IPv6 Network 15 draft-boucadair-dslite-interco-v4v6-04 17 Abstract 19 Dual-Stack lite requires that the AFTR must have IPv4 connectivity. 20 This forbids a service provider who wants to deploy AFTR in an IPv6- 21 only network. This memo proposes an extension to implement a 22 stateless IPv4-in-IPv6 encapsulation in the AFTR so that AFTR can be 23 deployed in an IPv6-only network. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 12, 2011. 48 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) controlling 68 the copyright in such materials, this document may not be modified 69 outside the IETF Standards Process, and derivative works of it may 70 not be created outside the IETF Standards Process, except to format 71 it for publication as an RFC or to translate it into languages other 72 than English. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 79 1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 81 3. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . 7 82 4. DS-Lite AFTR . . . . . . . . . . . . . . . . . . . . . . . . . 8 83 4.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . . 8 84 4.2. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 8 85 4.2.1. Processing Ingress Traffic from Customer Interface . . 9 86 4.2.2. Processing Ingress Traffic from Core Interface . . . . 9 87 4.3. Flows Examples . . . . . . . . . . . . . . . . . . . . . . 10 88 5. IPv6-IPv4 Interconnection Function (ICXF) . . . . . . . . . . 11 89 5.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . . 11 90 5.2. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 11 91 6. Routing Architecture and Considerations . . . . . . . . . . . 12 92 6.1. Static Routing . . . . . . . . . . . . . . . . . . . . . . 12 93 6.2. Dynamic Routing . . . . . . . . . . . . . . . . . . . . . 12 94 7. Multicast Considerations . . . . . . . . . . . . . . . . . . . 14 95 8. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 14 96 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14 97 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 98 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 99 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 100 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 101 13.1. Normative References . . . . . . . . . . . . . . . . . . . 15 102 13.2. Informative References . . . . . . . . . . . . . . . . . . 16 103 Appendix A. Changes Since 02 . . . . . . . . . . . . . . . . . . 16 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 106 1. Introduction 108 1.1. General 110 Dual-Stack lite (DS-lite) contains two major concepts: (1) Transport 111 IPv4 packets over an IPv6 access network, and (2) Share a public IPv4 112 address to multiple users. 114 The B4 element resided in the customer premises is provisioned an 115 global routable IPv6 address. It also establishes an IPv4-in-IPv6 116 tunnel to AFTR element. The hosts behind B4 elements are assigned 117 with [RFC1918] addresses. When the B4 receives IPv4 datagram from it 118 managed host, it will send the datagram over the IPv4-in-IPv6 tunnel 119 to the AFTR. 121 AFTR element provides the NAT function and is responsible for sharing 122 public IPv4 addresses to multiple B4 elements. It also requires 123 direct IPv4 connectivity to send and received the NAT-ed datagram to 124 the IPv4 network. 126 This model puts a demarcation in the network where the access network 127 between B4 and AFTR can be IPv6-only and the network north of AFTR 128 must be IPv4. Consider a service provider wants to extend the IPv6- 129 only network boundary from the access network to the border of the 130 network, this will force the AFTR to be deployed in the border and 131 further away from the B4s. This memo describes a framework to allow 132 a service provider to extend the IPv6-only network while to allow the 133 AFTR to stay close to the B4s. 135 1.2. Requirements 137 o [REQ1] Extend the IPv6-only boundary to the border of the network. 139 o [REQ2] Only the AS Border Router has IPv4 connectivity. 141 o [REQ3] The service provider provisions only IPv6 addresses to the 142 customers but continues to provide IPv4 services to them. 144 o [REQ4] The AFTR has only IPv6-connectivity and must be able to 145 send and receive IPv4 packets. 147 1.3. Overview 149 DS-Lite [I-D.ietf-softwire-dual-stack-lite] directly connects users 150 to IPv6 networks but at the same time provides IPv4 services by 151 tunneling IPv4 packets over an IPv6 network. 153 AFTR element is the combination of an IPv4-in-IPv6 tunnel end-point 154 and an IPv4-IPv4 NAT implemented in the same node. In addition, the 155 specification assumes that an AFTR is directly connected to the IPv4 156 network. 158 In some deployments where the service provider wants to deploy AFTR 159 in the IPv6 core network. AFTR nodes may not have direct IPv4 160 connectivity. In this scenario, IPv4 packets after NAT44 function 161 applied on an AFTR node need to be transported over the IPv6 core 162 network to the IPv4 network. This memo proposes a framework for this 163 scenario as an extension to the DS-Lite specification. 165 In this specification, we define a new stateless IPv6-IPv4 166 interconnection function (referred to as IPv6-IPv4 ICXF), in a border 167 node located at the boundaries between the IPv6 and IPv4 networks. 168 The AFTR discovers the ICXF address, and sends IPv4 encapsulated IPv6 169 packets after NAT44 function. 171 The ICXF may be hosted in an ASBR (Autonomous System Border Router) 172 or a dedicated node located at the interconnection between IPv6 and 173 IPv4 domains. A router that hosts the ICXF is referred to as an ICXF 174 router. 176 When the AFTR receives a customer's outbound packet from B4 element, 177 it de-capsulate the packet and perform standard NAT44 function. 178 Since an AFTR does not directly connect to the IPv4 network, AFTR 179 will encapsulate the NAT-ed IPv4 packet in an IPv4-in-IPv6 packet, 180 with an IPv4-Embedded IPv6 destination address 181 [I-D.ietf-behave-address-format], and forward it to an ICXF router 182 located with direct connection to the IPv4 network. When the ICXF 183 router receives the IPv4-Embedded IPv6 packet, it will de-capsulate 184 the packet and forward the IPv4 packet based on the IPv4 destination 185 address. 187 For an inbound IPv4 packet to B4 element, the ICXF router will 188 encapsulate the IPv4 packet into IPv6 packet with the IPv4-Embedded 189 IPv6 address and forward it to the appropriate DS-Lite AFTR node, 190 which de-capsulates the IPv4 packet and then follows the normal 191 procedure defined by DS-Lite architecture as if the IPv4 packet is 192 received from a directly connected IPv4 network. 194 Figure 1 provides an overview of the global architecture. Customers 195 are connected to the service domain via a CPE device. Several DS- 196 Lite AFTR nodes are deployed to manage the traffic sent and received 197 by the end-user terminal devices. The service domain is IPv6 only 198 and interconnection with adjacent IPv4 realms is implemented using 199 IPv6-IPv4 ICXF. The distributed deployment mode of AFTR nodes is 200 motivated by several reasons such as optimizing intra-domain paths, 201 avoiding single point of failure, minimizing the impact on geo- 202 localization services, minimizing the amount of customers to be 203 impacted by an AFTR node failure, etc. AFTR deployment model varies 204 from service provider to service provider and it is out of scope of 205 this specification. 207 Note in this architecture, the DS-Lite B4 element (located in a CPE) 208 and AFTR still behave exactly as defined in 209 [I-D.ietf-softwire-dual-stack-lite], but with additional functions 210 added to the AFTR when it does not directly connect to the IPv4 211 network. A new ICXF function is introduced to perform stateless 212 IPv6- IPv4 interconnection. This specification defines new 213 requirements on addressing scheme and routing. More details are 214 provided in the following sections. 216 +------------------------------+ 217 | Service Domain | +----------+ 218 +----+ | +---------+ | IPv4 | 219 |CPE1|-----------| |IPv6-IPv4|----| Domain A | 220 +----+ | | | ICXF | | | 221 | | +---------+ +----------+ 222 | | +-------+ | 223 | + |DS-Lite| | +----------+ 224 +----+ | + |AFTR A | +---------+ | IPv4 | 225 |CPE2|-----------| +-------+ |IPv6-IPv4|----| Domain B | 226 +----+ | | ICXF | | | 227 | +---------+ +----------+ 228 | +-------+ | | 229 | |DS-Lite| | | +----------+ 230 +----+ | + |AFTR B | | | | IPv4 | 231 |CPEi|-----------| +-------+ | +------| Domain C | 232 +----+ | | | | 233 | | +----------+ 234 +------------------------------+ 236 |<--------------------IPv6----------------->|<----IPv4---->| 238 Figure 1: Architecture Overview 240 2. Terminology 242 This memo defines the following terms: 244 o IPv6-IPv4 Interconnection Function (IPv6-IPv4 ICXF): refers to the 245 function that de-capsulates (resp., encapsulates) the IPv6 (resp., 246 IPv4) packet from DS-Lite AFTR node(s) and forwards the IPv4 247 (resp., IPv6) packets to the IPv4 (resp., IPv6) networks. 249 o ICXF router: refers to the border router implemented with IPv6- 250 IPv4 ICXF. 252 o DS-Lite AFTR node: refers to the AFTR node whose behavior is 253 specified in [I-D.ietf-softwire-dual-stack-lite]. In addition, 254 this specification assumes that the DS-Lite AFTR node is only 255 connected to an IPv6 network. The AFTR will encapsulate the IPv4 256 packet in an IPv6 packet (IPv4-in-IPv6) after the NAT44 function. 257 The encapsulated IPv6 packet will be forwarded to the ICXF router. 258 This IPv4-inIPv6 encapsulation is stateless. 260 o Access segment: This segment encompasses both the IP access to the 261 customers and to the service provider's network. 263 o Interconnection segment: Includes all nodes and resources which 264 are deployed at the border of a given AS (Autonomous System) a la 265 BGP. 267 o Core segment: Denotes a set of IP networking capabilities and 268 resources which are located between the interconnection and the 269 access segments. 271 o Pref6: An IPv6 prefix assigned by LIR. This prefix is configured 272 on both ICXF and AFTR. 274 o FROM-AFTR Address: An IPv4-Embedded IPv6 address 275 [I-D.ietf-behave-address-format] that combines an IPv6 prefix 276 Pref6 and the destination IPv4 address. 278 o TO-AFTR Address: An IPv4-Embedded IPv6 address 279 [I-D.ietf-behave-address-format] that combines an IPv6 prefix 280 Pref6 and a destination IPv4 address which configured in an AFTR 281 NAT pool. 283 3. Addressing 285 For outbound IPv4 packets, the AFTR performs encapsulation and the 286 ICXF router performs de-capsulation. For inbound IPv4 packets, the 287 ICXF router performs IPv4-in-IPv6 encapsulation and an AFTR performs 288 de-capsulation. 290 When an AFTR forwards an IPv6 packet with an IPv4 payload to an ICXF 291 router, the source IPv6 address is one of the AFTR's IPv6 address, 292 which is normally a global IPv6 address configured on an interface of 293 the node (e.g., an address of a loopback interface), and the 294 destination IPv6 address is the FROM-AFTR Address. 296 When an ICXF router receives an IPv4 packet, it encapsulates the IPv4 297 packet with an IPv6 header where the source IPv6 address is the ICXF 298 router's global IPv6 address and the destination IPv6 address is the 299 TO-AFTR address. The TO-AFTER address is constructed by combining 300 the Pref6 and the destination IPv4 address in the IPv4 packet. The 301 destination IPv4 address is one of the addresses configured in the 302 AFTR NAT pool. 304 In both cases, the Pref6 is an IPv6 prefix assigned by the service 305 provider, and is used to construct an IPv4-Embedded IPv6 address. 306 Figure 2 gives an example of the address format. 308 2a01:c::11000001001100111001000111001110 = 2a01:cc13:391c:e0::/56 309 |Pref6 | <--------193.51.145.206--------> 311 Figure 2: Example for an IPv4-Embedded IPv6 Prefix 313 In this example, Pref6 is 2a01:c::/20 and the IPv4_Addr is 314 193.51.145.206. Then, the corresponding IPv6 prefix is: 2a01:cc13: 315 391c:e0::/56. We use a /20 prefix for Pref6. However, an operator 316 can decide to use any prefix length. 318 4. DS-Lite AFTR 320 4.1. Provisioning 322 The AFTR must be provisioned with a set of global IPv4 prefixes for 323 NAT44 operations. In addition, an IPv6 prefix (i.e., Pref6) is 324 configured in the AFTR. The Pref6 is used to construct FROM-AFTR 325 addresses. The FROM-AFTR addresses are used in the destination 326 address field of the IPv6 header for the IPv4-in-IPv6 packets. 328 4.2. Procedure 330 Figure 3 shows the input and output of a DS-Lite AFTR node. 332 +-------------------+ 333 ----IPv6---\ | |----IPv6---\ 334 ----IPv4---\\| |----IPv4---\\ 335 -----------//| |-----------// 336 -----------/ | |-----------/ 337 Customer | DS-Lite | Core Node Interface 338 /----IPv6---| AFTR | /----IPv6--- 339 //---IPv4----| |//---IPv4---- 340 \\-----------| |\\----------- 341 \-----------| | \----------- 342 +-------------------+ 344 Figure 3: Modified DS-Lite AFTR 346 Two main (logical) interfaces may be distinguished in a DS-Lite AFTR 347 node as follows: 349 a. Interface with the customer device, i.e.- DS-Lite interface per 350 [I-D.ietf-softwire-dual-stack-lite]. 352 b. Interface with core nodes. Note that the DS-Lite AFTR does not 353 directly connect to an IPv4 domain. 355 4.2.1. Processing Ingress Traffic from Customer Interface 357 1. De-capsulate the IPv6 header from the IPv4-in-IPv6 packets (sent 358 by the customer device) 2. 360 2. NAT the IPv4 packet and create an entry in the NAT binding table 362 3. Encapsulate the NAT-ed IPv4 packets in IPv6 with a destination 363 IPv6 address built according to the addressing scheme described 364 in Section 3. Encapsulated packet is forwarded based on the 365 FROM-AFTR IPv6 address by standard routing. Depending on the 366 target IPv4 address, the destination can be an AFTR node inside 367 the service provider's domain if the IPv4 address is one of the 368 addresses owned by another AFTR (See Figure 4). Or, the 369 destination can be an ICXF router if the IPv4 address is external 370 to the service provider. 372 4.2.2. Processing Ingress Traffic from Core Interface 374 1. De-capsulate the IPv6 header and extract the IPv4 packet. 376 2. Process the embedded IPv4 packet according to 377 [I-D.ietf-softwire-dual-stack-lite]. 379 3. Forward the resulting IPv6 packet to the corresponding B4. 381 4.3. Flows Examples 383 +------+ +---------+ +---------+ +------+ 384 | |--IPv6---\ | |------IPv6-----\ | |---IPv6--\ | | 385 | |--IPv4---\\| |-----IPv4------\\| |---IPv4--\\| | 386 | |---------//| |---------------//| |---------//| | 387 | |---------/ | |---------------/ | |---------/ | | 388 | CPE 1| | DS-Lite | | DS-Lite | | CPE2 | 389 | | /---IPv6--| AFTR A | /-----IPv6------| AFTR B | /---IPv6--| | 390 | |//---IPv4--| |//----IPv4-------| |//--IPv4---| | 391 | |\\---------| |\\---------------| |\\---------| | 392 | | \---------| | \---------------| | \---------| | 393 +------+ +---------+ +---------+ +------+ 395 Note that hosts connected to each CPE are not represented in the 396 figure. 398 Figure 4: Flow Example involving two devices attached to distinct 399 AFTRs 401 The following figure illustrates an example of CPE connected to a DS- 402 Lite AFTR node, which establishes a communication with a remote host 403 (referred to as RH) which is on an IPv4 network. 405 +------+ +---------+ +---------+ +------+ 406 | |--IPv6---\ | |------IPv6-----\ | | | | 407 | |--IPv4---\\| |-----IPv4------\\| |---IPv4--\| | 408 | |---------//| |---------------//| |---------/| | 409 | |---------/ | |---------------/ | | | | 410 | CPE 1| | DS-Lite | |IPv6-IPv4| | RH | 411 | | /---IPv6--| AFTR A | /-----IPv6------| ICXF | | | 412 | |//---IPv4--| |//----IPv4-------| |/--IPv4---| | 413 | |\\---------| |\\---------------| |\---------| | 414 | | \---------| | \---------------| | | | 415 +------+ +---------+ +---------+ +------+ 417 Note that host connected to CPE1 are not represented in the figure. 419 Figure 5: Flow Example involving only one device attached to a DS- 420 lite enabled domain 422 5. IPv6-IPv4 Interconnection Function (ICXF) 424 ICXF is a border element that encapsulate IPv4 packets from external 425 IPv4 network to AFTR and de-capsulate IPv6 packets from AFTR to 426 external IPv4 network 428 Externally, the ICXF is connected to IPv4 network. It is an IPv4 429 router and performs standard IPv4 routing. It contains an IPv4 430 routing table and exchanges IPv4 prefixes to the internal and 431 external peers. 433 Internally, the ICXF is connected to an IPv6 network and exchanges 434 IPv4 prefixes to the AFTRs. Section 6 discusses the internal routing 435 in details. 437 5.1. Provisioning 439 An IPv6-IPv4 ICXF router is provisioned with an IPv6 prefix (i.e., 440 Pref6). Pref6 is used to build TO-AFTR addresses. 442 5.2. Procedure 444 Figure 6 shows the input and output of an IPv6-IPv4 ICXF. 446 +-------------------+ 447 ----IPv6---\ | | 448 ----IPv4---\\| |----IPv4---\ 449 -----------//| |-----------/ 450 -----------/ | | 451 | IPv6-IPv4 | 452 /----IPv6---| ICXF | 453 //---IPv4----| |/---IPv4---- 454 \\-----------| |\----------- 455 \-----------| | 456 +-------------------+ 458 Figure 6: IPv6-IPv4 Interworking Function 460 When the ICXF router receives an IPv4 packet from an external IPv4 461 domain, it encapsulates the IPv4 packet in IPv6 packet using the 462 following information: 464 o Source IPv6 address: One of its own IPv6 addresses. 466 o Destination IPv6 address: TO-AFTR Address which is an IPv4- 467 Embedded IPv6 address using the Pref6 and destination IPv4 address 468 of the encapsulated IPv4 packet. 470 As for the outbound IPv6 packets, an ICXF router performs de- 471 capsulation and forwards the embedded IPv4 packets to the connected 472 IPv4 networks according to IPv4 routing rule. 474 6. Routing Architecture and Considerations 476 This section describes the routing consideration to support this 477 specification, i.e.- how an IPv6 packet with an IPv4-Embedded IPv6 478 destination address is forwarded from a DS-Lite AFTR to an ICXF 479 router, and vice versa, in the IPv6 network. 481 When a DS-Lite AFTR forwards IPv4-in-IPv6 packets to an ICXF router, 482 the destination IPv6 address is an IPv4-Embedded IPv6 address, where 483 the Pref6 is an IPv6 prefix assigned to the service provider and the 484 IPv4 address is reachable through one or more ICXF routers. The 485 forwarding decision can be made based on static configuration or 486 dynamic routing. 488 6.1. Static Routing 490 The AFTR is configured with static routes, and each static route 491 points to an IPv4-Embedded IPv6 prefix. Alternatively, the AFTR can 492 contain a default route where the default is the ICXF. 494 6.2. Dynamic Routing 496 Dynamic routing is more desirable for the deployments where there are 497 multiple DS-Lite AFTRs and ICXF routers. This specification suggests 498 four dynamic routing options as documented below: 500 Option 1: 502 o AFTRs and ICXF routers are configured as a Softwire Mesh [RFC5565] 503 and iBGP is used to exchange IPv4 reachability information. AFTR 504 and ICXF will peer with each other over iBGP and exchange their 505 IPv4 reachability. Each AFTR and ICXF will compute an IPv4 506 routing table based upon the BGP table. Given an IPv4 network 507 managed by the AFTR or ICXF, the next-hop of this network is the 508 IPv6 address of the AFTR or ICXF. 510 o Pros: This routing option offers an optimized forwarding for IPv4- 511 in-IPv6 packets in the IPv6 network. 513 o Cons: DS-Lite AFTRs and ICXF routers must peer in iBGP and storing 514 BGP routes on all these nodes. 516 Option 2: 518 o ICXF router advertises its IPv4 reachability information in IGP. 519 This routing option does not require AFTRs and ICXFs to be iBGP 520 peers. For the AFTR IPv6 routing table, it contains all FROM_AFTR 521 prefixes and the ICXF IPv4 reachability information in the form on 522 IPv4-Embedded IPv6 prefixes (i.e., Pref6 + ICXF IPv4 routing 523 information). 525 o Pros: Given that the ICXF advertises all its IPv4 network 526 reachability in IPv6 network, the AFTR can choose the best path to 527 forward the packet. 529 o Cons: This optimization has a drawback: ICXF routers are required 530 to advertise its full IPv4 reachability to in IGP. As such, IPv6 531 routers will maintain the full IPv4 reachability in its IPv6 532 routing table. 534 Option 3: 536 o With this option, each ICXF router advertises a Pref6 537 (Section 5.1) in the IPv6 IGP. An AFTR forwards an IPv4-in-IPv6 538 packet always to a nearest ICXF router. In other words, the 539 nearest ICXF is the default router for all external IPv4 prefixes. 541 o Pros: Significantly reduces the size of the IPv6 routing table to 542 virtually one entry for IPv4 reachability. 544 o Cons: The closest ICXF router may not have the best route to the 545 final destination in the IPv4 network. The ICXF may forward the 546 packet to another ICXF to reach the IPv4 destination based upon 547 the local IPv4 routing information. 549 Option 4: 551 o This option requires every router in the IPv6 network to learn the 552 IPv4-Embedded IPv6 prefixes advertised by the AFTR and ICXF. 553 These prefixes are only meaningful to the AFTR and ICXF, other 554 IPv6 routers are not interested in them. To address this issue, a 555 new topology [RFC4915] or [RFC5120] can be created to store the 556 IPv4-Embedded IPv6 prefixes. 558 o This option requires the ICXF router and AFTR advertise the IPv4- 559 Embedded IPv6 prefixes in the IPv4-Embedded IPv6 topology. This 560 topology contains only the IPv4-Embedded IPv6 prefixes. Regular 561 IPv6 routers will not participate this topology. 563 o With this option, each ICXF router advertises its reachable IPv4 564 prefixes in the form of the IPv4-Embedded IPv6 addresses. These 565 LSAs will appear only in the dedicated MT. AFTR which 566 participates the MT will install the LSAs to its IPv6 routing 567 table. Those didn't participates the MT will simply ignore the 568 LSAs. 570 o Pros: Only the AFTR and ICXF install the IPv4-Embedded IPv6 571 prefixes in the IPv6 routing table. 573 o Cons: Addition administration cost to maintain a new topology in 574 ICXF and AFTR. 576 7. Multicast Considerations 578 This document describes an IPv4-IPv6 inter-connection extension to 579 DS-Lite [I-D.ietf-softwire-dual-stack-lite], which currently limits 580 the scope to transporting unicast IPv4 traffic over IPv6 network 581 only. Considerations on transporting multicast IPv4 traffic over 582 IPv6 network is out of scope. 584 8. Fragmentation 586 Tunneling IPv4 over IPv6 between AFTR and ICXF reduce the effective 587 MTU size by the size of an IPv6 header. Since ICXF tunnel is 588 stateless, the tunnel endpoint can't fragment and re-assumable the 589 oversized IPv4 packet. A service provider may increase the MTU size 590 by 40-bytes on the IPv6 network. If this is not possible, AFTR and 591 ICXF may use IPv6 Path MTU discovery. 593 ICXF nodes are stateless and not necessary to implement IPv4 594 fragmentation. 596 9. Conclusions 598 This document describes the mechanism to enable AFTR to operate on an 599 IPv6-only network while offering: 601 o Global IPv6 <==> IPv6 communications. 603 o Global IPv4 <==> IPv4 communications. 605 o A remote IPv6 host would reach a host connected to the DS-Lite 606 enabled domain using IPv6. 608 o A remote IPv4 host would reach a host connected to the DS-Lite 609 enabled domain using IPv4-in-IPv6. 611 10. IANA Considerations 613 This document makes no request of IANA. 615 Note to RFC Editor: this section may be removed on publication as an 616 RFC. 618 11. Security Considerations 620 Security considerations defined in 621 [I-D.ietf-softwire-dual-stack-lite] should be taken into account. In 622 addition, current interconnection practices for ingress traffic 623 filtering should be enforced in the interconnection points (ICXF). 625 12. Acknowledgements 627 The authors would like to thank Eric Burgey for his support and 628 suggestions. 630 13. References 632 13.1. Normative References 634 [I-D.ietf-softwire-dual-stack-lite] 635 Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee, 636 Y., and R. Bush, "Dual-Stack Lite Broadband Deployments 637 Following IPv4 Exhaustion", 638 draft-ietf-softwire-dual-stack-lite-05 (work in progress), 639 July 2010. 641 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 642 E. Lear, "Address Allocation for Private Internets", 643 BCP 5, RFC 1918, February 1996. 645 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 646 Requirement Levels", BCP 14, RFC 2119, March 1997. 648 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 649 (IPv6) Specification", RFC 2460, December 1998. 651 13.2. Informative References 653 [I-D.ietf-behave-address-format] 654 Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 655 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 656 draft-ietf-behave-address-format-09 (work in progress), 657 July 2010. 659 [RFC4277] McPherson, D. and K. Patel, "Experience with the BGP-4 660 Protocol", RFC 4277, January 2006. 662 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 663 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 664 RFC 4915, June 2007. 666 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 667 Topology (MT) Routing in Intermediate System to 668 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 670 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 671 Framework", RFC 5565, June 2009. 673 Appendix A. Changes Since 02 675 The following changes have been made since the last version: 677 1. Add a new section to define addressing scheme; 679 2. Add a new section to list all routing options in the IPv6 680 network; 682 3. Various editorial changes. 684 Authors' Addresses 686 Mohamed Boucadair (editor) 687 France Telecom 688 3, Av Francois Chateaux 689 Rennes 35000 690 France 692 Email: mohamed.boucadair@orange-ftgroup.com 693 Christian Jacquenet 694 France Telecom 696 Email: christian.jacquenet@orange-ftgroup.com 698 Jean-Luc Grimault 699 France Telecom 700 France 702 Email: jeanluc.grimault@orange-ftgroup.com 704 Mohammed Kassi-Lahlou 705 France Telecom 707 Email: mohamed.kassilahlou@orange-ftgroup.com 709 Pierre Levis 710 France Telecom 712 Email: pierre.levis@orange-ftgroup.com 714 Dean Cheng (editor) 715 Huawei Technologies Co., Ltd. 717 Email: Chengd@huawei.com 718 URI: http://www.huawei.com 720 Yiu L. Lee (editor) 721 Comcast 723 Email: yiu_lee@cable.comcast.com 724 URI: http://www.comcast.com