idnits 2.17.1 draft-lee-softwire-6rd-udp-01.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 1 instance of lines with non-RFC6890-compliant IPv4 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 date (May 28, 2010) is 5053 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2460' is defined on line 593, but no explicit reference was found in the text == Unused Reference: 'RFC4787' is defined on line 604, but no explicit reference was found in the text == Unused Reference: 'RFC2132' is defined on line 618, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Softwire Working Group Y. Lee 3 Internet-Draft Comcast 4 Intended status: Informational P. Kapoor 5 Expires: November 29, 2010 Xavient 6 May 28, 2010 8 UDP Encapsulation of 6rd 9 draft-lee-softwire-6rd-udp-01 11 Abstract 13 This memo specifies the UDP encapsulation to IPv6 Rapid Deployment 14 (6rd) protocol which enables hosts behind unmodified Home Gateway 15 device to access 6rd service. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in RFC 2119 [RFC2119]. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on November 29, 2010. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. 6rd UDP Host . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.2. Home Gateway . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.3. 6rd Border Router . . . . . . . . . . . . . . . . . . . . 6 63 3.4. 6rd UDP Delegated Prefix . . . . . . . . . . . . . . . . . 6 64 3.5. 6rd UDP Host Delegated Prefix . . . . . . . . . . . . . . 6 65 3.6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.6.1. Outbound Flow from the 6rd UDP Host . . . . . . . . . 7 67 3.6.2. Inbound Flow from the Subscriber IPv6 Host . . . . . . 8 68 3.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 3.7.1. Host Model . . . . . . . . . . . . . . . . . . . . . . 8 70 3.7.2. Server Model . . . . . . . . . . . . . . . . . . . . . 9 71 4. 6rd Prefix UDP Encapsulation . . . . . . . . . . . . . . . . . 10 72 4.1. UDP-Encapsulated 6rd Header . . . . . . . . . . . . . . . 10 73 5. 6rd Border Router Discovery . . . . . . . . . . . . . . . . . 11 74 5.1. Manual Discovery . . . . . . . . . . . . . . . . . . . . . 11 75 5.2. Automatic Discovery . . . . . . . . . . . . . . . . . . . 11 76 6. MTU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 7. Comparison to the Classic 6rd . . . . . . . . . . . . . . . . 12 78 7.1. 6rd Prefix Length . . . . . . . . . . . . . . . . . . . . 12 79 7.2. Additional 6rd BR Operation . . . . . . . . . . . . . . . 12 80 7.3. Life Time of 6rd Delegated Prefix . . . . . . . . . . . . 12 81 8. Comparison to Softwire Hub-and-Spoke and Teredo . . . . . . . 12 82 9. Deployment Considerations . . . . . . . . . . . . . . . . . . 13 83 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 84 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 85 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 86 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 13.1. Normative References . . . . . . . . . . . . . . . . . . . 13 88 13.2. Informative References . . . . . . . . . . . . . . . . . . 14 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 91 1. Introduction 93 6rd protocol [I-D.ietf-softwire-ipv6-6rd] enables service providers 94 to rapidly deploy IPv6 over IPv4 network. In [RFC5569], it describes 95 the 6rd architecture to enable a service provider to deploy IPv6 96 connectivity on an IPv4 network for 1.5 million residential 97 customers. The architecture involves two major components: (1) the 98 6rd relays (6rd Border Router) in the ISP network and (2) 6rd CPE 99 (6rd CE) in the customer premise. 101 The 6rd CE in the customer home is a NAT [RFC3022] device which 102 shares a single external IPv4 address to multiple internal IPv4 103 hosts. Note that the external IPv4 address can be either public or 104 private. If private address is used, the ISP will provide NAT 105 function in the provider network. Details is described in [RFC5569] 106 Section 4. The 6rd CE is also an IPv6 router which advertises an 107 IPv6 prefix (6rd Delegated Prefix) to the internal IPv6 hosts. The 108 6rd Delegated Prefix consists of two part: the 6rd Prefix and the 109 external IPv4 address. The 6rd CE learns the 6rd Prefix, 110 IPv4MaskLen, and 6rdPrefixLen from DHCP [I-D.ietf-softwire-ipv6-6rd] 111 and calculate the 6rd Delegated Prefix. Then, the 6rd CE advertises 112 the 6rd Delegated Prefix to the customer's home network via Router 113 Advertisement [RFC4861] or DHCPv6 [RFC3315]. 115 The 6rd specification fits well to those ISPs who manage the 116 customers' home gateway (HGW). When the ISP is ready to deploy the 117 6rd, a new firmware which contains the 6rd CE implementation will be 118 pushed to the managed HGW. For the ISPs who do not manage the 119 customers' HWG, they cannot upgrade the customer's HWGs to support 120 6rd. This memo specific a UDP encapsulation to encapsulate 6rd over 121 UDP which enables ISP to deploy 6rd to hosts behind unmodified HWG. 122 There are two scenarios in which the ISP can use this specification. 124 1. First deployment scenario is the O/S in the host implements this 125 specification. The host is connect to the unmodified HGW's LAN 126 interface. One the host establishes IPv4 connectivity, it 127 initiates the 6rd discovery procedure Section 5 and construct the 128 6rd Delegated Prefix. When the host sends an IPv6 datagram, it 129 encapsulates the IPv4 datagram with a standard UDP header 130 [RFC0768], then it encapsulates the IPv6 datagram in an IPv4 131 header following the procedure defined in [RFC5569]. Details of 132 the UDP encapsulation is described in Section 4. 134 2. Second deployment scenario is a dedicated server implements this 135 specification. The server is connected to the unmodified HGW's 136 LAN interface. Once the server establishes IPv4 connectivity, it 137 initiates the 6rd discovery procedure Section 5 and construct the 138 6rd Delegated Prefix. Then, it advertises the 6rd Prefix via 139 Router Advertisement or DHCPv6 to the HGW LAN so that IPv6 140 datagram will use the server as a gateway to establish IPv6 141 sessions. This enables the hosts connecting to the HGW's LAN to 142 access 6rd service without additional configuration. 144 This specification defines the udp encapsulation that allows to 145 deploy 6rd behind a 6rd unaware NAT-ed gateway. The general 146 mechanism is still stateless and requires little change to the IPv4 147 networking. 149 2. Terminology 151 This documents users terms defined in [I-D.ietf-softwire-ipv6-6rd]. 152 In addition, we defines the following new terms: 154 o HGW: is referred to the edge device installed in customer home. 155 It typically provides NAT function to the home equipments. The 156 HGW in this context is unaware of 6rd. 158 o External IPv4 address: is referred to the external IPv4 address 159 assigned by the ISP to the HGW. This address can be either a 160 public IPv4 address of a private [RFC1918] address. 162 o Internal IPv4 address: is referred to the internal IPv4 address 163 assigned by the HGW to the 6rd host. This address is a [RFC1918] 164 address. 166 o 6rd UDP Host: is the host implemented this specification. 168 o 6rd UDP Delegated Prefix: is referred to the 6rd Delegated Prefix 169 [I-D.ietf-softwire-ipv6-6rd] generated by the 6rd BR to identify 170 the host implemented this specification. The 6rd UDP Delegated 171 Prefix is different from the 6rd Delegated Prefix in which the 16- 172 bit udp source port information is part of the 6rd delegated 173 prefix calculation. 175 o 6rd UDP Host Delegated Prefix: is referred to the 6rd Delegated 176 Prefix used by the host. This is different from the 6rd UDP 177 Delegated Prefix in which the 16-bit udp source port information 178 in the IPv6 address will be replaced by zeros. 180 3. Overview 181 3.1. 6rd UDP Host 183 Before the host can use 6rd, it needs to discover five pieces of 184 information: the 6rd prefix, the external IPv4 address, the 185 IPv4MaskLen, the 6rdPreflixLen, and the 6rd BR IPv4 address. 186 Section 5 discusses the process to discover the information. The 187 host calculates the 6rd UDP Host Delegated Prefix following the 188 procedure described in Section 3.5. 190 The 6rd udp host implemented this specification must be able to 191 encapsulate and de-capsulate udp and IPv4 headers when sending and 192 receiving IPv6 datagrams. It must also allocate an available udp 193 port during startup. This port must be used in the 6rd encapsulation 194 during the life time of the process. 196 When the host wants to initiate an IPv6 session to an outside IPv6 197 host, the first encapsulates is to append the IPv6 datagram with an 198 udp header. The udp source port is the udp port allocated at 199 startup; the destination port is an IANA defined port. The second 200 encapsulate is to append the IPv4 header. The source address will be 201 the internal IPv4 address assigned by the HGW; the destination 202 address will be the 6rd BR's IPv4 address. 204 Since 6rd udp host is behind the HGW, it must send a keepalive 205 message to the 6rd BR to maintain the udp NAT binding alive. The 206 keepalive is a simple udp packet which has special IPv6 destination 207 address so that the 6rd BR will rsecognize this is a keepalive 208 packet. When the 6rd receives this special udp datagram, it must 209 discard the datagram and sends a response to the 6rd udp host. In 210 the response, the IPv6 address contains only the 6rd udp delegated 211 prefix and zero-pad the rest of the bits. When the 6rd udp host 212 receives this datagram. It must discard it. The 6rd udp host must 213 send the keepalive frequent enough to keep the binding. 215 3.2. Home Gateway 217 The HGW in this specification is a typical HGW found in retailed 218 stores. In the WAN side, it connects to the ISP and runs DHCP 219 client. The ISP offers an IPv4 address, a default gateway, and list 220 of DNS servers to the HGW. In the LAN side, it runs DHCP server and 221 offers [RFC1918] address to the hosts on the LAN. The HGW provides 222 standard NAT [RFC3022] functions to allow multiple hosts to share a 223 single external IPv4 address. When a host connects to the HGW, the 224 host requests the Internal IPv4 address and the Internal IPv4 Gateway 225 via DHCP. The HGW is not aware of the 6rd service. 227 3.3. 6rd Border Router 229 The 6rd BR implemented this specification must be configured to 230 receive UDP packet on port XXXX (TBD) in its IPv4 interface facing 231 the 6rd udp hosts. When it receives a udp packet, it de-capsulates 232 the udp header and extract the udp source port information. Then it 233 replaces the 16-bit zero-padded bit to the udp source port 234 information and forms the 6rd delegated prefix. The 6rd BR must be 235 pre-configured with the IPv4MaxLen and 6rdPrefixLen. 237 When the 6rd BR receives an IPv6 packet in its IPv6 interface, it 238 must extract the 16-bit udp source port from the IPv6 destination 239 address and use it to construct the udp header for encapsulation. 240 The 6rd BR must also zero-pad the 16-bit udp source port information 241 in the IPv6 destination address before sending to the 6rd udp host. 243 This procedure is equivalent to NAT66 [I-D.mrw-behave-nat66] 244 operation where the 6rd BR performs the stateless NAT function to 245 embed the NAT-ed udp port information into the 6rd prefix. 247 3.4. 6rd UDP Delegated Prefix 249 In order to keep 6rd BR operation stateless and to make 6rd 250 implementations co-exist with the HGW NAT at the same time, this 251 specification defines a new 6rd delegated prefix 252 [I-D.ietf-softwire-ipv6-6rd] calculation procedure which is slightly 253 different from the classic 6rd delegated prefix calculation. This 254 specification proposes to include the 16-bit UDP source port 255 information in the 6rd delegated prefix. 257 The 6rd udp delegated prefix is calculated by concatenating the 6rd 258 prefix, a consecutive set of bits from the CE IPv4 address, and the 259 16-bit udp source port. The sum of the number of bits must be less 260 than or equal to 64. 262 For example, the 6rd prefix is 2001:DB8::/32; the IPv4 address is 263 192.0.1.100/24; the IPv4MaskLen is 16; the 6rdPrefixLen is 32; and 264 the source UDP is 12345. The 6rd udp delegated prefix is 2001:DB8: 265 0164:3039::/64 267 The 6rd udp delegated prefix is generated and used by 6rd BR. 269 3.5. 6rd UDP Host Delegated Prefix 271 Since the 6rd Host calculating the delegrated prefix is behind the 272 NAT, it does not know the NAT-ed udp source port. When the 6rd 273 constructs the 6rd UDP Delegated Prefix, it will not populate the 16- 274 bit UDP source port information. Instead, it will zero-pad the 16- 275 bit field. This will also ensure that the 6rd udp host delegated 276 prefix will not change if the old NAT-ed binding in the HGW expires 277 and a new binding is formed. 279 Following the previous example, the 6rd host udp delegated prefix 280 behind the HGW is 2001:DB8:0164::/64 282 The 6rd udp host delegated prefix is used by the 6rd udp host. 284 3.6. Procedures 286 3.6.1. Outbound Flow from the 6rd UDP Host 288 3.6.1.1. 6rd UDP Host 290 When the 6rd udp operation on the host starts, it must allocate an 291 available udp port. This port is used in the source udp port of the 292 udp encapsulation. 294 When the 6rd host wants to send an IPv6 datagram to an IPv6 295 destination, it puts the 6rd udp host delegated prefix in the source 296 IPv6 address field. Then the host encapsulates the IPv6 datagram 297 with a udp header. The source port is the udp port allocated during 298 the startup process and the destination port is the well-known port 299 assigned by IANA. Then, the host encapsulates the udp datagram with 300 an IPv4 header. The IPv4 header contains the 6rd BR in the 301 destination address field and the internal IPv4 address in the source 302 address field. The datagram is passed to the relevant routing 303 mechanism. 305 3.6.1.2. Home Gateway 307 When the HGW receives the first udp datagram, it NATs the source port 308 and source IPv4 address to create a NAT binding in its table. Then, 309 the HGW forwards the IPv4 udp datagram to the 6rd BR. Any subsequent 310 udp datagram designating the same udp port and IPv4 address from the 311 same udp port and IPv4 address will use the same NAT binding. This 312 specification contains no new requirement to the HGW. 314 3.6.1.3. 6rd Border Router 316 When the 6rd BR receives the udp datagram, it de-capsulates the IPv4 317 and udp headers, and extracts the 16-bit udp source port information 318 in the udp header. Then, it calculates a new IPv6 source address by 319 replacing the 6rd udp host delegated prefix with the 6rd udp 320 delegated prefix. Then, the 6rd BR forwards the IPv6 datagram to the 321 IPv6 destination. 323 3.6.2. Inbound Flow from the Subscriber IPv6 Host 325 3.6.2.1. 6rd Border Router 327 When the 6rd BR receives the IPv6 datagram, it extracts the 16-bit 328 udp destination port information from the IPv6 destination address. 329 It calculates the new IPv6 destination address by replacing the 6rd 330 udp delegated address with the 6rd udp host delegated address. It 331 also constructs the udp header by putting the extracted 16-bit into 332 the destination port and XXXX (TBD) in the source port. Finally, the 333 6rd BR extracts the IPv4 address from the IPv6 destination address, 334 encapsulate the IPv6 datagram with the udp header and IPv4 header, 335 and forward it to the provider network. 337 3.6.2.2. Home Gateway 339 When the HGW receives the IPv4 datagram, it performs the standard NAT 340 function by replacing the destination IPv4 address and udp 341 destination port to the address and port stored in the NAT binding 342 table. Then, it forwards the datagram to the host in the LAN. This 343 specification contains no new requirement to the HGW. 345 3.6.2.3. 6rd UDP Host 347 When the 6rd host receives the datagram. It de-capsulates the udp 348 and IPv4 headers and forwards the IPv6 datagram to its IPv6 interface 349 or to connected destination. 351 3.7. Examples 353 3.7.1. Host Model 355 This example explains how the Host Model works. Both 6rd Host A and 356 6rd Host B learn the 6rd prefix via static or dynamic configuration. 357 They also learn the external IPv4 address by some external mechanism. 358 Host A and Host B create the 6rd delegated prefix by concatenating 359 6rd prefix, the external IPv4 address, and pads 16-bit at the end of 360 the external IPv4 address. The resulting 6rd udp host delegated 361 prefix must be less than or equal to 64. 363 | IPv6 364 | Global Internet 365 +-----+ 366 | | 6rd Border Router 367 +-----+ 368 | 369 +----------------------+ 370 | | 371 | ISP IPv4 Network | 372 | | 373 | | 374 +----------------------+ 375 | External IPv4 Address 376 +-----+ 377 | | Unmodified HGW 378 +-----+ 379 | Internal IPv4 Address 380 _________ 381 | | 382 +===+ +===+ 383 6rd Host A | | | | 6rd Host B 384 +===+ +===+ 386 Figure 1 388 3.7.2. Server Model 390 This example is very similar to the Host Model. Instead of the host 391 implementing this specification, only a server device is required to 392 implement this specification. The server uses the same mechanism 393 described in the Host Model to construct the 6rd udp host delegated 394 prefix. When the server is ready to provide the 6rd service, it 395 announces the 6rd udp host delegated prefix in the Router 396 Advertisement. Client A and Client B receive the 6rd udp host 397 delegated Prefix and auto-config the IPv6 interface. 399 | IPv6 400 | Global Internet 401 +-----+ 402 | | 6rd Border Router 403 +-----+ 404 | 405 +----------------------+ 406 | | 407 | ISP IPv4 Network | 408 | | 409 | | 410 +----------------------+ 411 | External IPv4 Address 412 +-----+ 413 | | Unmodified HGW 414 +-----+ 415 | Internal IPv4 Address 416 ______________________________________ 417 | -- 6rd --> | | 418 | UDP Host | | 419 +===+ Delegated +---+ +---+ 420 | s | Prefix | c | | c | 421 +===+ +---+ +---+ 422 Server Client A Client B 424 Figure 2 426 In this model, Client A and B are ordinary IPv6 hosts unaware of any 427 6rd specific knowledge. They learn the prefix and default router 428 (which is the Server) via standard RA. 430 4. 6rd Prefix UDP Encapsulation 432 4.1. UDP-Encapsulated 6rd Header 434 0 1 2 3 435 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Source Port | Destination Port | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Length | Checksum | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | 6rd Datagram | 442 ~ ~ 443 | | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 Where 448 o Source Port is any available port. 450 o Destination Port must be the well-known port assigned by IANA. 452 o this specification does not introduce new requirement to the IPv4 453 UDP Length and Checksum. 455 5. 6rd Border Router Discovery 457 In the classic 6rd framework, the 6rd CE connects directly to the 458 ISP. The ISP uses DHCP to pass the 6rd Prefix, IPv4MaskLen, 459 6rdPrefixLen, and the 6rd BR address to the CPE CE. In this 460 specification, the 6rd host is not directly connected to the ISP. 461 Between the ISP and the 6rd host, there is a HGW which is unaware of 462 6rd. The ISP can't use DHCP to pass the necessary information to the 463 6rd hosts. In this specification, we suggest two discovery 464 mechanisms. 466 5.1. Manual Discovery 468 The ISP gives the customers the 6rd Prefix, IPv4MaskLen, 469 6rdPreflixLen, and 6rd BR information. If the customers want to 470 start the 6rd service, they must enter the information manually. 471 This method is only feasible in very small scale deployment and not 472 recommended for any large scale deployment. 474 5.2. Automatic Discovery 476 The ISP uses RADIUS [RFC2865] or DIAMETER [RFC3588] to distribute the 477 6rd Prefix, IPv4MaskLen, 6rdPrefixlen, and 6rd BR address 478 information. When the customer starts the 6rd service, he/she must 479 authenticate him/herself to the ISP. Upon a successful 480 authentication, he/she will be given the necessary parameters through 481 either RADIUS or DIAMETER response. 483 6. MTU 485 Similar to other tunnel encapsulations, this specification reduces 486 the effect MTU size. The encapsulation overhead is 20-byte for IPv4 487 header and 8-byte for UDP. The host and 6rd BR must account for this 488 overhead. 490 7. Comparison to the Classic 6rd 492 This specification is considered more restrictive than the classic 493 6rd. There are three major areas: 495 7.1. 6rd Prefix Length 497 In the classic 6rd model, the maximum 6rd Prefix length can be as 498 long as 32 + IPv4MaskLen. In this specification, the maximum 6rd 499 Prefix length is 16 + IPv4MaskLen due to encapsulating the udp source 500 port information in the 6rd udp delegated prefix. 502 7.2. Additional 6rd BR Operation 504 In the classic 6rd architecture, the 6rd BR does a simple de- 505 capsulation and encapsulation. When the 6rd BR receives a udp 506 datagram from the ISP network, the 6rd BR must calculate a new IPv6 507 source address after the de-capsulation. The new IPv6 source address 508 contains the 6rd udp delegated prefix in which the udp source port 509 information is embedded in it. When the 6rd BR receives an IPv6 510 datagram from the IPv6 Internet, it reverses the process by replacing 511 the 6rd udp delegated prefix to the 6rd host udp delegated prefix. 512 This is a stateless NAT66 [I-D.mrw-behave-nat66] operation. 514 7.3. Life Time of 6rd Delegated Prefix 516 In classic 6rd model, the life time of the 6rd delegate prefix is 517 bounced by the life time of the external IPv4 address. The life time 518 of the external IPv4 address could be hours or even days. In this 519 specification, the life time of the 6rd udp delegated prefix is 520 bounced by the life time of the NAT binding in the HGW. The HGW can 521 expire the udp binding if there is no traffic passing for few 522 seconds. This specification requires the 6rd udp host to send 523 keepalive to the 6rd BR to refresh the binding frequently. However, 524 the 6rd host udp delegated prefix used in the LAN will not suffer 525 from the same short-lived interval. Since the 6rd host udp delegated 526 prefix does not contain the udp port information, its life time is 527 equal to 6rd delegated prefix which is bounced by the life time of 528 the IPv4 external address. 530 8. Comparison to Softwire Hub-and-Spoke and Teredo 532 Softwire Hub-and-Spoke [RFC5571] and Teredo [RFC4380] are two 533 protocols that provide IPv6 connectivity to hosts behind typical HGW. 535 Softwire Hub-and-Spoke uses L2TPv2 over UDP [RFC2661] for the tunnel 536 protocol; Teredo defines its own tunneling protocol for UDP 537 encapsulation. This specification provides similar functionality. 538 The benefit of this specification is that the operation is stateless 539 and requires no control protocol. However, this specification 540 require external bootstrapping process to pass provisioning 541 information to the 6rd udp host. 543 9. Deployment Considerations 545 The same 6rd BR can support both classic 6rd and 6rd UDP 546 encapsulation. To achieve this, the classic 6rd and 6rd udp 547 encapsulation must use different 6rd prefixes. In a deployment 548 scenario where customers have mixed 6rd CE and typical HGW, this 549 specification potentially saves operation cost by deploying only one 550 type of network equipment. This specification also useful for 551 operator to speedup the 6rd deployment process by offering users a 552 softwire download of 6rd udp host which works behind their home 553 gateways, and for users who do not want to change their home 554 gateways. 556 10. IANA Considerations 558 This specification requests IANA to assign a UDP port for the 6rd UDP 559 encapsulation. 561 11. Security Considerations 563 TBD 565 12. Acknowledgements 567 TBD 569 13. References 571 13.1. Normative References 573 [I-D.ietf-softwire-ipv6-6rd] 574 Townsley, M. and O. Troan, "IPv6 Rapid Deployment on IPv4 575 Infrastructures (6rd)", draft-ietf-softwire-ipv6-6rd-10 576 (work in progress), May 2010. 578 [I-D.mrw-behave-nat66] 579 Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Address 580 Translation (NAT66)", draft-mrw-behave-nat66-02 (work in 581 progress), March 2009. 583 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 584 August 1980. 586 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 587 E. Lear, "Address Allocation for Private Internets", 588 BCP 5, RFC 1918, February 1996. 590 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 591 Requirement Levels", BCP 14, RFC 2119, March 1997. 593 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 594 (IPv6) Specification", RFC 2460, December 1998. 596 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 597 Address Translator (Traditional NAT)", RFC 3022, 598 January 2001. 600 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 601 Network Address Translations (NATs)", RFC 4380, 602 February 2006. 604 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 605 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 606 RFC 4787, January 2007. 608 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 609 Infrastructures (6rd)", RFC 5569, January 2010. 611 [RFC5571] Storer, B., Pignataro, C., Dos Santos, M., Stevant, B., 612 Toutain, L., and J. Tremblay, "Softwire Hub and Spoke 613 Deployment Framework with Layer Two Tunneling Protocol 614 Version 2 (L2TPv2)", RFC 5571, June 2009. 616 13.2. Informative References 618 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 619 Extensions", RFC 2132, March 1997. 621 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 622 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 623 RFC 2661, August 1999. 625 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 626 "Remote Authentication Dial In User Service (RADIUS)", 627 RFC 2865, June 2000. 629 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 630 and M. Carney, "Dynamic Host Configuration Protocol for 631 IPv6 (DHCPv6)", RFC 3315, July 2003. 633 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 634 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 636 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 637 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 638 September 2007. 640 Authors' Addresses 642 Yiu L. Lee 643 Comcast 645 Email: yiu_lee@cable.comcast.com 646 URI: http://www.comcast.com 648 Prashant Kapoor 649 Xavient 651 Email: pkapoor@xavient.com 652 URI: http://www.xavient.com