idnits 2.17.1 draft-ietf-softwire-public-4over6-03.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 (August 28, 2012) is 4257 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 443, but no explicit reference was found in the text == Unused Reference: 'RFC4966' is defined on line 447, but no explicit reference was found in the text == Unused Reference: 'RFC5549' is defined on line 453, but no explicit reference was found in the text == Unused Reference: 'RFC5565' is defined on line 458, 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) == Outdated reference: A later version (-09) exists of draft-ietf-dhc-dhcpv4-over-ipv6-03 Summary: 4 errors (**), 0 flaws (~~), 6 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: March 1, 2013 Tsinghua University 6 O. Vautrin 7 Juniper Networks 8 Y. Lee 9 Comcast 10 August 28, 2012 12 Public IPv4 over IPv6 Access Network 13 draft-ietf-softwire-public-4over6-03 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 March 1, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . . 6 69 7. 4over6 BR Behavior . . . . . . . . . . . . . . . . . . . . . . 7 70 8. Fragmentation and reassembly . . . . . . . . . . . . . . . . . 8 71 9. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 73 11. Change Log from the -02 Version . . . . . . . . . . . . . . . 9 74 12. Author List . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 13.1. Normative References . . . . . . . . . . . . . . . . . . . 10 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 While different IPv4-over-IPv6 mechanisms are developed for different 88 application scenarios, the mechanism proposed in this document 89 focuses on provide full end-to-end transparency to the user-side. 90 Therefore, carrier-side address translation should be avoided and 91 public IPv4 addresses should be provisioned to end users. Further 92 more, full address is preferred than port-restricted address. With 93 full address provisioned, user-side address translation is not 94 necessarily needed either. This means minimal changes to the user 95 side: operating system could support the mechanism smoothly, while 96 transparency on upper-layer applications is guaranteed. For many 97 ISPs which are actually capable of provisioning full IPv4 addresses, 98 the mechanism provide a pure, suitable solution. 100 Another focus of this mechanism is deployment and operation 101 flexibility. This mechanism keeps IPv4-IPv6 addressing independent: 102 end user IPv4 address is not embedded in its IPv6 address. The IPv6 103 infrastructure in the middle is not involved with the IPv4-over-IPv6 104 mechanism, so no special network planning is required; the service 105 can be easily provided in on-demand style; the IPv4 address resources 106 can be managed in a flat, centralized manner rather than distributed 107 to customer sites with IPv6. The tradeoff is per-subscriber binding 108 state maintenance on the border relay. 110 The mechanism follows hub and spokes softwire model, and uses IPv4- 111 over-IPv6 tunnel between end host or CPE and border relay as basic 112 data plane method. Full IPv4 addresses are allocated from the ISP to 113 the end host or CPE over IPv6 network. Simultaneously, the binding 114 between the allocated IPv4 address and the end user's IPv6 address 115 are maintained on the border relay for encapsulation usage. 117 2. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 3. Terminology 125 Public 4over6: Public 4over6 is a per-subscriber stateful, IPv4-over- 126 IPv6 tunnel mechanism proposed by this document. Public 4over6 127 supports bidirectional communication between IPv4 Internet and IPv4 128 hosts or customer networks in IPv6 access network, by leveraging 129 IPv4-in-IPv6 tunnel and public IPv4 address allocation over IPv6. 131 4over6 Customer Edge (CE): A device functioning as a Customer Edge 132 equipment in Public 4over6 environment. The 4over6 CE can be either 133 a dual-stack capable host, or a dual-stack CPE device, both have a 134 tunnel interface to support IPv4-in-IPv6 encapsulation. In the 135 former case, the host supports both IPv4 and IPv6 stack but is 136 provisioned with IPv6 only. In the latter case, the CPE has an IPv6 137 interface connecting to ISP network, and an IPv4 interface connecting 138 to customer network; hosts in the customer network can be IPv4-only. 140 4over6 Border Relay (BR): A router functioning as the border relay in 141 Public 4over6 environment. 4over6 BR is the IPv4-in-IPv6 tunnel 142 concentrator located in IPv6 ISP network. It is a dual-stack router 143 which connects to both the IPv6 ISP network and IPv4 Internet. 145 4. Scenario and Use Cases 147 The general scenario of Public 4over6 is shown in Figure 1. Users in 148 an IPv6 network take IPv6 as their native service. Some users are 149 end hosts which face the ISP network directly, while the others are 150 customer networks behind CPEs, such as a home LAN, an enterprise 151 network, etc. The ISP network is IPv6-only rather than dual-stack, 152 which means the ISP cannot provide native IPv4 service to users. 153 However, it is acceptable that some router(s) on the carrier side 154 becomes dual-stack and connects to IPv4 Internet. So if network 155 users require IPv4 connectivity, the dual-stack router(s) will work 156 as their "entrance". 158 +-------------------------+ 159 | IPv6 ISP Network | 160 +------+ | 161 |4over6|Host | 162 | CE |=================+-------+ +-----------+ 163 +------+ |4over6 | | IPv4 | 164 +---------+ | IPv4-in-IPv6 | BR |---| Internet | 165 |Customer | +------+ | | | | 166 | IPv4 |--|4over6|=================+-------+ +-----------+ 167 | Network | | CE |CPE | 168 +---------+ +------+ | 169 | | 170 +-------------------------+ 172 Figure 1 Public 4over6 scenario 174 Public 4over6 can be applicable in several use cases. If an ISP 175 which switches to IPv6 still has plenty of IPv4 address resource, it 176 can deploy Public 4over6 to provide transparent IPv4 service for all 177 its customers. If the ISP does not have so much IPv4 addresses, it 178 can deploy Dual-Stack Lite [RFC6333] as the basic IPv4-over-IPv6 179 service. Along with DS-Lite, Public 4over6 can be deployed as a 180 value-added service, overcoming the service degradation caused by the 181 CGN. The two mechanisms can be integrated easily. A typical case of 182 the high-end users that could use Public 4over6 is IPv4 application 183 server. Full, public IPv4 address brings significant convenience in 184 this case. The DNS registration can be direct using dedicated 185 address; the access of the application service can be 186 straightforward, with no translation involved; there will be no need 187 to hold the "pinhole" for incoming traffic, and no well-known port 188 collision will come up. 190 5. Public 4over6 Address Provisioning 192 5.1. Basic Provisioning Steps 194 The following figure shows the basic provisioning steps for Public 195 4over6. 197 4over6 DHCPv6 DHCPv4 4over6 198 CE Server Server BR 199 | Assign IPv6 Addr + | | | 200 | BR's IPv6 Addr Info | | | 201 |<-------------------->| | | 202 | DHCPv6/Other | | | 203 WAN | | 204 IPv6 Configure | | 205 | | IPv4-IPv6 | 206 | Assign Public IPv4 Addr |Addr Binding| 207 |<----------------------------------->|<---------->| 208 | DHCPv4 over IPv6/Static Configure | SYN | 209 Tunnel | Binding 210 IPv4 Configure Update 211 | | 212 | IPv4-in-IPv6 Tunnel | 213 |<------------------------------------------------>| 214 | | 216 Figure 2 Public 4over6 Address Provisioning 218 The main steps are: 220 o Provision IPv6 address to 4over6 CE, along with the information of 221 4over6 BR's IPv6 address, by DHCPv6 or other means. 223 o 4over6 CE configures its WAN interface, as a result of IPv6 224 provisioning. 226 o Provision IPv4 address to 4over6 CE, by DHCPv4 over IPv6 or static 227 configuration. 229 o Synchronize the IPv4-IPv6 address binding between DHCPv4 server 230 and 4over6 BR, at the same time with DHCPv4 provisioning. 232 o 4over6 CE configures its tunnel interface, as a result of IPv4 233 provisioning. 235 o 4over6 BR updates the IPv4-IPv6 address binding table, as a result 236 of address binding synchronization. 238 5.2. Public IPv4 Address Allocation 240 Usually each CE is provisioned with one public IPv4 address. However 241 it is possible that a CE would require an IPv4 prefix. The key 242 problem here is the mechanism for IPv4 address provisioning over IPv6 243 network. 245 There are two possibilities here: DHCPv4 over IPv6, and static 246 configuration. Public 4over6 MUST support both. DHCPv4 over IPv6 247 enables DHCPv4 message to be transported in IPv6 rather than IPv4; 248 therefore, the DHCPv4 process can be performed over an IPv6 network, 249 between BR and CE. [I-D.ietf-dhc-dhcpv4-over-ipv6] describes the 250 DHCP protocol extensions to support that. As to static 251 configuration, 4over6 users and the ISP operators MUST negotiate 252 beforehand to authorize the IPv4 address(es). Then the tunnel 253 interface and the address binding are configured by the user and the 254 ISP respectively. 256 While regular users would probably take DHCPv4 over IPv6, the manual 257 configuration is usually seen in two cases: application server, which 258 requires a stable IPv4 address, and enterprise network, which usually 259 requires an IPv4 prefix rather than one single address (Note that 260 DHCPv4 does not support prefix allocation). 262 6. 4over6 CE Behavior 264 A CE MUST be provisioned with IPv6 before Public 4over6. It MUST 265 also learn the BR's IPv6 address. This IPv6 address can be 266 configured using a variety of methods, ranging from an out-of-band 267 mechanism, manual configuration, or DHCPv6 option. In order to 268 guarantee interoperability, the CE element SHOULD implement the 269 DHCPv6 option defined in [RFC6334]. 271 A CE MUST support DHCPv4 over IPv6[I-D.ietf-dhc-dhcpv4-over-ipv6], to 272 dynamically require IPv4 address over IPv6 and assign it to the IPv4- 273 in-IPv6 tunnel interface. It MUST also support static configuration 274 of the tunnel interface. In the case of prefix provisioning, Well- 275 Known IPv4 Address defined in section 5.7 of [RFC6333] SHOULD be 276 assigned to the tunnel interface, rather than using an address from 277 the prefix. If the CE has multiple IPv6 addresses on its WAN 278 interface, it MUST use the same IPv6 address for DHCPv4 over IPv6/ 279 negotiation of manual configuration, and for data plane 280 encapsulation. 282 A CE performs IPv4-in-IPv6 encapsulation and decapsulation on the 283 tunnel interface. When sending out an IPv4 packet, it performs the 284 encapsulation, using the IPv6 address of the 4over6 BR as the IPv6 285 destination address, and its own IPv6 address as the IPv6 source 286 address. The decapsulation on 4over6 CE is simple. When receiving 287 an IPv4-in-IPv6 packet, the CE just removes the IPv6 header, and 288 either hands it to upper layer or forward it to customer network 289 according to the IPv4 destination address. 291 A CE runs a regular IPv4 NAPT for its customer network when it is 292 provisioned with one single IPv4 address. In that case, the assigned 293 IPv4 address of the tunnel interface would be the external IPv4 294 address of the NAPT. Then the CE performs IPv4 private-to-public 295 translation before encapsulation of IPv4 packets from the customer 296 network, and IPv4 public-to-private translation after decapsulation 297 of IPv4-in-IPv6 packets. 299 IPv4 NAPT is not necessarily when the CE is provisioned with an IPv4 300 prefix. In this case, the detailed customer network planning is out 301 of scope. 303 7. 4over6 BR Behavior 305 4over6 BR maintains the bindings between the CE IPv6 address and CE 306 IPv4 address (prefixes). The bindings are used to provide correct 307 encapsulation destination address for inbound IPv4 packets, as well 308 as validate the IPv6-IPv4 source of the outbound IPv4-in-IPv6 309 packets. 311 The BR MUST synchronize the binding information with the IPv4 address 312 provisioning process. For static configuration this is easy: the BR 313 configures the binding right after negotiation with the customer. As 314 for DHCPv4-over-IPv6, there are multiple possibilities which are 315 deployment-specific: 317 o The BR can be collocated with the DHCPv4-over-IPv6 server. Then 318 the synchronization happens within the BR. It installs a binding 319 when send out an ACK for a DHCP lease, and delete it when the 320 lease expires or a DHCP RELEASE is received. 322 o The BR can play the role of TRA as described in 323 [I-D.ietf-dhc-dhcpv4-over-ipv6], and snoop for the DHCPv4 ACK and 324 Release messages, as well as keep a timer for each binding 325 according to the DHCP lease time. 327 o The BR does not participate in the DHCPv4-over-IPv6 process, 328 however, the bindings of the IPv4 and IPv6 addresses are static, 329 and the same image of the binding information for all users are 330 propagated to both DHCPv4-over-IPv6 server and the BR. 332 On the IPv6 side, the BR decapsulates IPv4-in-IPv6 packets coming 333 from 4over6 CEs. It removes the IPv6 header of every IPv4-in-IPv6 334 packet and forwards it to the IPv4 Internet. Before the 335 decapsulation, the BR MUST check the inner IPv4 source address 336 against the outer IPv6 source address, by matching such a binding 337 entry in the binding table. If no binding is found, the BR silently 338 drops the packet. On the IPv4 side, the BR encapsulates the IPv4 339 packets destined to 4over6 CEs. When performing the IPv4-in-IPv6 340 encapsulation, the BR uses its own IPv6 address as the IPv6 source 341 address, uses the IPv4 destination address in the packet to look up 342 IPv6 destination address in the address binding table. After the 343 encapsulation, the BR sends the IPv6 packet on its IPv6 interface to 344 reach a CE. 346 The BR MUST support hairpinning of traffic between two CEs, by 347 performing de-capsulation and re-encapsulation of packets. 349 8. Fragmentation and reassembly 351 The same considerations as described in section 5.3 and section 6.3 352 of [RFC6333] are to be taken into account. 354 9. DNS 356 The procedure described in Section 5.5 and Section 6.4 of [RFC6333] 357 is to be followed. 359 10. Security Considerations 361 The 4over6 BR SHOULD implement methods to limit service only to 362 registered customers. The first step is to allocate IPv4 addresses 363 only to registered customers. One simple solution is to filter on 364 the IPv6 source addresses of incoming DHCP packets and only respond 365 to the ones which have registered IPv6 source address. The BR can 366 also perform authentication during DHCP, for example, based on the 367 MAC address of the CEs. As to data packets, the BR can implement an 368 IPv6 ingress filter on the tunnel interface to accept only the IPv6 369 address range defined in the filter, as well as check the IPv4-IPv6 370 source address binding by looking up the binding table. 372 11. Change Log from the -02 Version 374 1. Shorten section 1 to focus on the motivation and basic principle 375 of Public 4over6. 377 2. Change the terminology: change '4over6 concentrator' to '4over6 378 BR'(or BR) and '4over6 initiator' to '4over6 CE' or (CE). 380 3. Rewrite the texts of section 4 to be more concise. 382 4. Use the new, section 5 to describe the provisioning process. 384 5. Explicitly include the case of provisioning IPv4 prefix for CE. 386 6. Restructure the behavior of 4over6 BR and CE. 388 12. Author List 390 The following are extended authors who contribute to the effort: 392 Huiling Zhao 393 China Telecom 394 Room 502, No.118, Xizhimennei Street 395 Beijing 100035 396 P.R.China 398 Phone: +86-10-58552002 399 Email: zhaohl@ctbri.com.cn 401 Chongfeng Xie 402 China Telecom 403 Room 708, No.118, Xizhimennei Street 404 Beijing 100035 405 P.R.China 407 Phone: +86-10-58552116 408 Email: xiechf@ctbri.com.cn 409 Qiong Sun 410 China Telecom 411 Room 708, No.118, Xizhimennei Street 412 Beijing 100035 413 P.R.China 415 Phone: +86-10-58552936 416 Email: sunqiong@ctbri.com.cn 418 Qi Sun 419 Tsinghua University 420 Beijing 100084 421 P.R.China 423 Phone: +86-10-62785822 424 Email: sunqibupt@gmail.com 426 Chris Metz 427 Cisco Systems 428 3700 Cisco Way 429 San Jose, CA 95134 430 USA 432 Email: chmetz@cisco.com 434 13. References 436 13.1. Normative References 438 [RFC2119] Bradner, S., "Key words for use in 439 RFCs to Indicate Requirement 440 Levels", BCP 14, RFC 2119, 441 March 1997. 443 [RFC4925] Li, X., Dawkins, S., Ward, D., and 444 A. Durand, "Softwire Problem 445 Statement", RFC 4925, July 2007. 447 [RFC4966] Aoun, C. and E. Davies, "Reasons to 448 Move the Network Address Translator 449 - Protocol Translator (NAT-PT) to 450 Historic Status", RFC 4966, 451 July 2007. 453 [RFC5549] Le Faucheur, F. and E. Rosen, 454 "Advertising IPv4 Network Layer 455 Reachability Information with an 456 IPv6 Next Hop", RFC 5549, May 2009. 458 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. 459 Rosen, "Softwire Mesh Framework", 460 RFC 5565, June 2009. 462 [RFC6333] Durand, A., Droms, R., Woodyatt, J., 463 and Y. Lee, "Dual-Stack Lite 464 Broadband Deployments Following IPv4 465 Exhaustion", RFC 6333, August 2011. 467 [RFC6334] Hankins, D. and T. Mrugalski, 468 "Dynamic Host Configuration Protocol 469 for IPv6 (DHCPv6) Option for Dual- 470 Stack Lite", RFC 6334, August 2011. 472 13.2. Informative References 474 [I-D.ietf-dhc-dhcpv4-over-ipv6] Cui, Y., Wu, P., Wu, J., and T. 475 Lemon, "DHCPv4 over IPv6 Transport", 476 draft-ietf-dhc-dhcpv4-over-ipv6-03 477 (work in progress), May 2012. 479 Authors' Addresses 481 Yong Cui 482 Tsinghua University 483 Department of Computer Science, Tsinghua University 484 Beijing 100084 485 P.R.China 487 Phone: +86-10-6260-3059 488 EMail: yong@csnet1.cs.tsinghua.edu.cn 490 Jianping Wu 491 Tsinghua University 492 Department of Computer Science, Tsinghua University 493 Beijing 100084 494 P.R.China 496 Phone: +86-10-6278-5983 497 EMail: jianping@cernet.edu.cn 498 Peng Wu 499 Tsinghua University 500 Department of Computer Science, Tsinghua University 501 Beijing 100084 502 P.R.China 504 Phone: +86-10-6278-5822 505 EMail: pengwu.thu@gmail.com 507 Olivier Vautrin 508 Juniper Networks 509 1194 N Mathilda Avenue 510 Sunnyvale, CA 94089 511 USA 513 EMail: Olivier@juniper.net 515 Yiu L. Lee 516 Comcast 517 One Comcast Center 518 Philadelphia, PA 19103 519 USA 521 EMail: yiu_lee@cable.comcast.com