idnits 2.17.1 draft-ietf-softwire-public-4over6-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 13, 2012) is 4184 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) == Unused Reference: 'RFC4925' is defined on line 464, but no explicit reference was found in the text == Unused Reference: 'RFC4966' is defined on line 468, but no explicit reference was found in the text == Unused Reference: 'RFC5549' is defined on line 474, but no explicit reference was found in the text == Unused Reference: 'RFC5565' is defined on line 479, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4925 ** Downref: Normative reference to an Informational RFC: RFC 4966 ** Obsolete normative reference: RFC 5549 (Obsoleted by RFC 8950) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Cui 3 Internet-Draft J. Wu 4 Intended status: Standards Track P. Wu 5 Expires: April 16, 2013 Tsinghua University 6 O. Vautrin 7 Juniper Networks 8 Y. Lee 9 Comcast 10 October 13, 2012 12 Public IPv4 over IPv6 Access Network 13 draft-ietf-softwire-public-4over6-04 15 Abstract 17 When the service provider networks are upgraded to IPv6, end users 18 will continue to demand IPv4 connectivity. This document proposes a 19 mechanism for hosts or customer networks in IPv6 access network to 20 build bidirectional IPv4 communication with the IPv4 Internet. The 21 mechanism follows the hub and spokes softwire model, and uses IPv4- 22 over-IPv6 tunnel as basic method to traverse IPv6 network. The bi- 23 directionality of this IPv4 communication is achieved by explicitly 24 allocating public IPv4 addresses to end users, as well as maintaining 25 IPv4-IPv6 address binding on the border relay. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on April 16, 2013. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 63 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Scenario and Use Cases . . . . . . . . . . . . . . . . . . . . 4 65 5. Public 4over6 Address Provisioning . . . . . . . . . . . . . . 5 66 5.1. Basic Provisioning Steps . . . . . . . . . . . . . . . . . 5 67 5.2. Public IPv4 Address Allocation . . . . . . . . . . . . . . 6 68 6. 4over6 CE Behavior . . . . . . . . . . . . . . . . . . . . . . 7 69 7. 4over6 BR Behavior . . . . . . . . . . . . . . . . . . . . . . 8 70 8. Fragmentation and reassembly . . . . . . . . . . . . . . . . . 9 71 9. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 11. Change Log from the -03 Version . . . . . . . . . . . . . . . 9 74 12. Author List . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 13.1. Normative References . . . . . . . . . . . . . . . . . . . 11 77 13.2. Informative References . . . . . . . . . . . . . . . . . . 11 79 1. Introduction 81 When deploying IPv6 networks, IPv4 connectivity is still a required 82 functionality by end users. It is used for IPv4 communicate with 83 IPv4-only part of the Internet during the IPv4-IPv6 transition 84 period. IPv4-over-IPv6 tunnel mechanisms are the general solutions 85 to provide this type of IPv4 services. 87 The advantage of IPv4-over-IPv6 tunnel mechanisms is the transparency 88 to the IPv6 infrastructure: since IPv4 is actually only needed on the 89 end user side as well as beyond the tunnel concentrator, most parts 90 and functionalities of the ISP network can remain IPv6 only. 91 Therefore, operators can run an IPv6-only infrastructure instead of a 92 fully dual-stack network, as well as save the IPv4 address resource 93 from being assigned all over the network. 95 While different IPv4-over-IPv6 mechanisms are developed for different 96 application scenarios, the mechanism proposed in this document 97 focuses on provide full end-to-end transparency to the user-side. 98 Therefore, carrier-side address translation should be avoided and 99 public IPv4 addresses should be provisioned to end users. Further 100 more, full address is preferred than port-restricted address. With 101 full address provisioned, user-side address translation is not 102 necessarily needed either. This means minimal changes to the user 103 side: operating system could support the mechanism smoothly, while 104 transparency on upper-layer applications is guaranteed. For many 105 ISPs which are actually capable of provisioning full IPv4 addresses, 106 the mechanism provide a pure, suitable solution. 108 Another focus of this mechanism is deployment and operation 109 flexibility. This mechanism keeps IPv4-IPv6 addressing independent: 110 end user IPv4 address is not embedded in its IPv6 address. The IPv6 111 infrastructure in the middle is not involved with the IPv4-over-IPv6 112 mechanism, so no special network planning is required; the service 113 can be provided in on-demand style; the IPv4 address resources can be 114 managed in a flat, centralized manner rather than distributed to 115 customer sites with IPv6. The tradeoff is per-subscriber binding 116 state maintenance on the border relay. 118 The mechanism follows hub and spokes softwire model, and uses IPv4- 119 over-IPv6 tunnel between end host or CPE and border relay as basic 120 data plane method. Full IPv4 addresses are allocated from the ISP to 121 the end host or CPE over IPv6 network. Simultaneously, the binding 122 between the allocated IPv4 address and the end user's IPv6 address 123 are maintained on the border relay for encapsulation usage. 125 2. Requirements Language 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119]. 130 3. Terminology 132 Public 4over6: Public 4over6 is a per-subscriber stateful, IPv4-over- 133 IPv6 tunnel mechanism proposed by this document. Public 4over6 134 supports bidirectional communication between IPv4 Internet and IPv4 135 hosts or customer networks in IPv6 access network, by leveraging 136 IPv4-in-IPv6 tunnel and public IPv4 address allocation over IPv6. 138 4over6 Customer Edge (CE): A device functioning as a Customer Edge 139 equipment in Public 4over6 environment. The 4over6 CE can be either 140 a dual-stack capable host, or a dual-stack CPE device, both have a 141 tunnel interface to support IPv4-in-IPv6 encapsulation. In the 142 former case, the host supports both IPv4 and IPv6 stack but is 143 provisioned with IPv6 only. In the latter case, the CPE has an IPv6 144 interface connecting to ISP network, and an IPv4 or dual-stack 145 interface connecting to customer network; hosts in the customer 146 network can be IPv4-only or dual-stack. 148 4over6 Border Relay (BR): A router functioning as the border relay in 149 Public 4over6 environment. 4over6 BR is the IPv4-in-IPv6 tunnel 150 concentrator located in IPv6 ISP network. It is a dual-stack router 151 which connects to both the IPv6 ISP network and IPv4 Internet. The 152 4over6 BR also works as a DHCPv4 over IPv6 153 [I-D.ietf-dhc-dhcpv4-over-ipv6] server/relay for assigning public 154 IPv4 address to 4over6 CEs. 156 4. Scenario and Use Cases 158 The general scenario of Public 4over6 is shown in Figure 1. Users in 159 an IPv6 network take IPv6 as their native service. Some users are 160 end hosts which face the ISP network directly, while the others are 161 customer networks behind CPEs, such as a home LAN, an enterprise 162 network, etc. The ISP network is IPv6-only rather than dual-stack, 163 which means the ISP cannot provide native IPv4 service to users. 164 However, it is acceptable that some router(s) on the carrier side 165 becomes dual-stack and connects to IPv4 Internet. So if network 166 users require IPv4 connectivity, the dual-stack router(s) will work 167 as their "entrance". 169 +-------------------------+ 170 | IPv6 ISP Network | 171 +------+ | 172 |4over6|Host | 173 | CE |=================+-------+ +-----------+ 174 +------+ |4over6 | | IPv4 | 175 +---------+ | IPv4-in-IPv6 | BR |---| Internet | 176 |Customer | +------+ | | | | 177 | IPv4 |--|4over6|=================+-------+ +-----------+ 178 | Network | | CE |CPE | 179 +---------+ +------+ | 180 | | 181 +-------------------------+ 183 Figure 1 Public 4over6 scenario 185 Public 4over6 can be applicable in several use cases. If an ISP 186 which switches to IPv6 still has plenty of IPv4 address resource, it 187 can deploy Public 4over6 to provide transparent IPv4 service for all 188 its customers. If the ISP does not have so much IPv4 addresses, it 189 can deploy Dual-Stack Lite [RFC6333] as the basic IPv4-over-IPv6 190 service. Along with DS-Lite, Public 4over6 can be deployed as a 191 value-added service, overcoming the service degradation caused by the 192 CGN. The two mechanisms can be integrated, because the IPv4-in-IPv6 193 tunnel functions are the same; the difference is that DS-Lite employs 194 a CGN while Public 4over6 employs an IPv4 provisioning process. A 195 typical case of the high-end users that could use Public 4over6 is 196 IPv4 application server. Full, public IPv4 address brings 197 significant convenience in this case. The DNS registration can be 198 direct using dedicated address; the access of the application service 199 can be straightforward, with no translation involved; there will be 200 no need to hold the "pinhole" for incoming traffic, and no well-known 201 port collision will come up. 203 5. Public 4over6 Address Provisioning 205 5.1. Basic Provisioning Steps 207 The following figure shows the basic provisioning steps for Public 208 4over6. 210 4over6 DHCPv6 4over6 DHCPv4 211 CE Server BR Server 212 | Assign IPv6 Addr + | | | 213 | BR's IPv6 Addr Info | | | 214 |<---------------------| | | 215 | DHCPv6/Other | | | 217 WAN | | 218 IPv6 Configure | | 219 | | | 220 | Assign Public IPv4 Addr(DHCPv4-over-v6/Static Conf)| 221 |<------------------------------------|<-------------| 222 | | IPv4-IPv6 | 223 | | Binding SYN | 224 Tunnel | 225 IPv4 Configure Binding Update 226 | | 227 | IPv4-in-IPv6 Tunnel | 228 |<----------------------------------->| 229 | | 231 Figure 2 Public 4over6 Address Provisioning 233 The main steps are: 235 o Provision IPv6 address to 4over6 CE, along with the information of 236 4over6 BR's IPv6 address, by DHCPv6 or other means. 238 o 4over6 CE configures its WAN interface, as a result of IPv6 239 provisioning. 241 o Provision IPv4 address to 4over6 CE, by DHCPv4 over IPv6 or static 242 configuration. 244 o Synchronize the IPv4-IPv6 address binding between DHCPv4 server 245 and 4over6 BR, at the same time with DHCPv4 provisioning. 247 o 4over6 CE configures its tunnel interface, as a result of IPv4 248 provisioning. 250 o 4over6 BR updates the IPv4-IPv6 address binding table, as a result 251 of address binding synchronization. 253 5.2. Public IPv4 Address Allocation 255 Usually each CE is provisioned with one public IPv4 address. However 256 it is possible that a CE would require an IPv4 prefix. The key 257 problem here is the mechanism for IPv4 address provisioning over IPv6 258 network. 260 There are two possibilities here: DHCPv4 over IPv6, and static 261 configuration. Public 4over6 MUST support both. DHCPv4 over IPv6 262 enables DHCPv4 message to be transported in IPv6 rather than IPv4; 263 therefore, the DHCPv4 process can be performed over an IPv6 network, 264 between BR and CE. [I-D.ietf-dhc-dhcpv4-over-ipv6] describes the 265 DHCP protocol extensions to support that. As to static 266 configuration, 4over6 users and the ISP operators MUST negotiate 267 beforehand to authorize the IPv4 address(es). Then the tunnel 268 interface and the address binding are configured by the user and the 269 ISP respectively. 271 While regular users would probably take DHCPv4 over IPv6, the manual 272 configuration is usually seen in two cases: application server, which 273 requires a stable IPv4 address, and enterprise network, which usually 274 requires an IPv4 prefix rather than one single address (Note that 275 DHCPv4 does not support prefix allocation). 277 6. 4over6 CE Behavior 279 A CE MUST be provisioned with IPv6 before Public 4over6. It MUST 280 also learn the BR's IPv6 address. This IPv6 address can be 281 configured using a variety of methods, ranging from an out-of-band 282 mechanism, manual configuration, or DHCPv6 option. In order to 283 guarantee interoperability, the CE element SHOULD implement the AFTR- 284 Name DHCPv6 option defined in [RFC6334]. 286 A CE MUST support DHCPv4 over IPv6[I-D.ietf-dhc-dhcpv4-over-ipv6], to 287 dynamically require IPv4 address over IPv6 and assign it to the IPv4- 288 in-IPv6 tunnel interface. The CE considers the BR as DHCPv4-over- 289 IPv6 server/relay for public IPv4 address allocation, whose IPv6 290 address is learned by the CE as described above. 292 A CE MUST also support static configuration of the tunnel interface. 293 In the case of prefix provisioning, Well-Known IPv4 Address defined 294 in section 5.7 of [RFC6333] SHOULD be assigned to the tunnel 295 interface, rather than using an address from the prefix. If the CE 296 has multiple IPv6 addresses on its WAN interface, it MUST use the 297 same IPv6 address for DHCPv4 over IPv6/negotiation of manual 298 configuration, and for data plane encapsulation. 300 A CE performs IPv4-in-IPv6 encapsulation and decapsulation on the 301 tunnel interface. When sending out an IPv4 packet, it performs the 302 encapsulation, using the IPv6 address of the 4over6 BR as the IPv6 303 destination address, and its own IPv6 address as the IPv6 source 304 address. The decapsulation on 4over6 CE is simple. When receiving 305 an IPv4-in-IPv6 packet, the CE just removes the IPv6 header, and 306 either hands it to upper layer or forward it to customer network 307 according to the IPv4 destination address. 309 A CE runs a regular IPv4 NAPT for its customer network when it is 310 provisioned with one single IPv4 address. In that case, the assigned 311 IPv4 address of the tunnel interface would be the external IPv4 312 address of the NAPT. Then the CE performs IPv4 private-to-public 313 translation before encapsulation of IPv4 packets from the customer 314 network, and IPv4 public-to-private translation after decapsulation 315 of IPv4-in-IPv6 packets. 317 IPv4 NAPT is not necessarily when the CE is provisioned with an IPv4 318 prefix. In this case, the detailed customer network planning is out 319 of scope. 321 4over6 CE supports backward compatibility with DS-Lite. A CE MAY 322 employ Well-Known IPv4 Address for B4 [RFC6333] and switch to Dual- 323 Stack Lite for IPv4 communications, if it can't get a public IPv4 324 address from the DHCPv4 server (maybe because the DHCPv4 over IPv6 325 process fails or the DHCPv4 server refuses to allocate a public IPv4 326 address to it, etc.). 328 7. 4over6 BR Behavior 330 4over6 BR maintains the bindings between the CE IPv6 address and CE 331 IPv4 address (prefixes). The bindings are used to provide correct 332 encapsulation destination address for inbound IPv4 packets, as well 333 as validate the IPv6-IPv4 source of the outbound IPv4-in-IPv6 334 packets. 336 The BR MUST synchronize the binding information with the IPv4 address 337 provisioning process. For static configuration, the BR configures 338 the binding right after negotiation with the customer. As for 339 DHCPv4-over-IPv6, there are multiple possibilities which are 340 deployment-specific: 342 o The BR can be collocated with the DHCPv4-over-IPv6 server. Then 343 the synchronization happens within the BR. It installs a binding 344 when send out an ACK for a DHCP lease, and delete it when the 345 lease expires or a DHCP RELEASE is received. 347 o The BR can play the role of TRA as described in 348 [I-D.ietf-dhc-dhcpv4-over-ipv6], and snoop for the DHCPv4 ACK and 349 Release messages, as well as keep a timer for each binding 350 according to the DHCP lease time. 352 On the IPv6 side, the BR decapsulates IPv4-in-IPv6 packets coming 353 from 4over6 CEs. It removes the IPv6 header of every IPv4-in-IPv6 354 packet and forwards it to the IPv4 Internet. Before the 355 decapsulation, the BR MUST check the inner IPv4 source address 356 against the outer IPv6 source address, by matching such a binding 357 entry in the binding table. If no binding is found, the BR silently 358 drops the packet. On the IPv4 side, the BR encapsulates the IPv4 359 packets destined to 4over6 CEs. When performing the IPv4-in-IPv6 360 encapsulation, the BR uses its own IPv6 address as the IPv6 source 361 address, uses the IPv4 destination address in the packet to look up 362 IPv6 destination address in the address binding table. After the 363 encapsulation, the BR sends the IPv6 packet on its IPv6 interface to 364 reach a CE. 366 The BR MUST support hairpinning of traffic between two CEs, by 367 performing de-capsulation and re-encapsulation of packets. 369 8. Fragmentation and reassembly 371 The same considerations as described in section 5.3 and section 6.3 372 of [RFC6333] are to be taken into account. 374 9. DNS 376 The procedure described in Section 5.5 and Section 6.4 of [RFC6333] 377 is to be followed. 379 10. Security Considerations 381 The 4over6 BR SHOULD implement methods to limit service only to 382 registered customers. The first step is to allocate IPv4 addresses 383 only to registered customers. One simple solution is to filter on 384 the IPv6 source addresses of incoming DHCP packets and only respond 385 to the ones which have registered IPv6 source address. The BR can 386 also perform authentication during DHCP, for example, based on the 387 MAC address of the CEs. As to data packets, the BR can implement an 388 IPv6 ingress filter on the tunnel interface to accept only the IPv6 389 address range defined in the filter, as well as check the IPv4-IPv6 390 source address binding by looking up the binding table. 392 11. Change Log from the -03 Version 394 1. Explain the motivation of IPv4-over-IPv6 for Public 4over6 in 395 section 1. 397 2. Clarify that customer network behind the 4over6 CE could be IPv4- 398 only or dual-stack in section 3. 400 3. Explain how to integrate Public 4over6 and DS-lite as a typical 401 use case in section 4 and section 5. 403 4. Improve the preciseness of the texts. 405 5. Remove the text that describes the BR not participating the 406 DHCPv4-over-IPv6 process. 408 12. Author List 410 The following are extended authors who contribute to the effort: 412 Huiling Zhao 413 China Telecom 414 Room 502, No.118, Xizhimennei Street 415 Beijing 100035 416 P.R.China 418 Phone: +86-10-58552002 419 Email: zhaohl@ctbri.com.cn 421 Chongfeng Xie 422 China Telecom 423 Room 708, No.118, Xizhimennei Street 424 Beijing 100035 425 P.R.China 427 Phone: +86-10-58552116 428 Email: xiechf@ctbri.com.cn 430 Qiong Sun 431 China Telecom 432 Room 708, No.118, Xizhimennei Street 433 Beijing 100035 434 P.R.China 436 Phone: +86-10-58552936 437 Email: sunqiong@ctbri.com.cn 439 Qi Sun 440 Tsinghua University 441 Beijing 100084 442 P.R.China 444 Phone: +86-10-62785822 445 Email: sunqibupt@gmail.com 447 Chris Metz 448 Cisco Systems 449 3700 Cisco Way 450 San Jose, CA 95134 451 USA 453 Email: chmetz@cisco.com 455 13. References 457 13.1. Normative References 459 [RFC2119] Bradner, S., "Key words for use in 460 RFCs to Indicate Requirement 461 Levels", BCP 14, RFC 2119, 462 March 1997. 464 [RFC4925] Li, X., Dawkins, S., Ward, D., and 465 A. Durand, "Softwire Problem 466 Statement", RFC 4925, July 2007. 468 [RFC4966] Aoun, C. and E. Davies, "Reasons to 469 Move the Network Address Translator 470 - Protocol Translator (NAT-PT) to 471 Historic Status", RFC 4966, 472 July 2007. 474 [RFC5549] Le Faucheur, F. and E. Rosen, 475 "Advertising IPv4 Network Layer 476 Reachability Information with an 477 IPv6 Next Hop", RFC 5549, May 2009. 479 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. 480 Rosen, "Softwire Mesh Framework", 481 RFC 5565, June 2009. 483 [RFC6333] Durand, A., Droms, R., Woodyatt, J., 484 and Y. Lee, "Dual-Stack Lite 485 Broadband Deployments Following IPv4 486 Exhaustion", RFC 6333, August 2011. 488 [RFC6334] Hankins, D. and T. Mrugalski, 489 "Dynamic Host Configuration Protocol 490 for IPv6 (DHCPv6) Option for Dual- 491 Stack Lite", RFC 6334, August 2011. 493 13.2. Informative References 495 [I-D.ietf-dhc-dhcpv4-over-ipv6] Cui, Y., Wu, P., Wu, J., and T. 497 Lemon, "DHCPv4 over IPv6 Transport", 498 draft-ietf-dhc-dhcpv4-over-ipv6-05 499 (work in progress), September 2012. 501 Authors' Addresses 503 Yong Cui 504 Tsinghua University 505 Department of Computer Science, Tsinghua University 506 Beijing 100084 507 P.R.China 509 Phone: +86-10-6260-3059 510 EMail: yong@csnet1.cs.tsinghua.edu.cn 512 Jianping Wu 513 Tsinghua University 514 Department of Computer Science, Tsinghua University 515 Beijing 100084 516 P.R.China 518 Phone: +86-10-6278-5983 519 EMail: jianping@cernet.edu.cn 521 Peng Wu 522 Tsinghua University 523 Department of Computer Science, Tsinghua University 524 Beijing 100084 525 P.R.China 527 Phone: +86-10-6278-5822 528 EMail: pengwu.thu@gmail.com 530 Olivier Vautrin 531 Juniper Networks 532 1194 N Mathilda Avenue 533 Sunnyvale, CA 94089 534 USA 536 EMail: Olivier@juniper.net 538 Yiu L. Lee 539 Comcast 540 One Comcast Center 541 Philadelphia, PA 19103 542 USA 544 EMail: yiu_lee@cable.comcast.com