idnits 2.17.1 draft-ietf-softwire-ipv6-6rd-10.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. == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (May 19, 2010) is 5081 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-03) exists of draft-nakibly-v6ops-tunnel-loops-02 -- Obsolete informational reference (is this intentional?): RFC 3068 (Obsoleted by RFC 7526) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force W. Townsley 3 Internet-Draft O. Troan 4 Intended status: Standards Track Cisco 5 Expires: November 20, 2010 May 19, 2010 7 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) 8 draft-ietf-softwire-ipv6-6rd-10 10 Abstract 12 This document specifies an automatic tunneling mechanism tailored to 13 advance deployment of IPv6 to end users via a Service Provider's IPv4 14 network infrastructure. Key aspects include automatic IPv6 prefix 15 delegation to sites, stateless operation, simple provisioning, and 16 service which is equivalent to native IPv6 at the sites which are 17 served by the mechanism. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 20, 2010. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 55 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. 6rd Prefix Delegation . . . . . . . . . . . . . . . . . . . . 6 57 5. Troubleshooting and Traceability . . . . . . . . . . . . . . . 7 58 6. Address Selection . . . . . . . . . . . . . . . . . . . . . . 8 59 7. 6rd Configuration . . . . . . . . . . . . . . . . . . . . . . 8 60 7.1. Customer Edge Configuration . . . . . . . . . . . . . . . 8 61 7.1.1. 6rd DHCPv4 Option . . . . . . . . . . . . . . . . . . 9 62 7.2. Border Relay Configuration . . . . . . . . . . . . . . . . 11 63 8. Neighbor Unreachability Detection . . . . . . . . . . . . . . 11 64 9. IPv6 in IPv4 Encapsulation . . . . . . . . . . . . . . . . . . 13 65 9.1. Maximum Transmission Unit . . . . . . . . . . . . . . . . 13 66 9.2. Receiving Rules . . . . . . . . . . . . . . . . . . . . . 14 67 10. Transition Considerations . . . . . . . . . . . . . . . . . . 14 68 11. IPv6 Address Space Usage . . . . . . . . . . . . . . . . . . . 14 69 12. Security Considerations . . . . . . . . . . . . . . . . . . . 15 70 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 71 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 72 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 15.1. Normative References . . . . . . . . . . . . . . . . . . . 17 74 15.2. Informative References . . . . . . . . . . . . . . . . . . 17 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 77 1. Introduction 79 The original idea and the name of the mechanism (6rd) described in 80 [RFC5569] details a successful commercial "rapid deployment" of the 81 6rd mechanism by a residential Service Provider and is recommended 82 reading. This document describes the 6rd mechanism, extended for use 83 in more general environments, and intended for advancement on the 84 IETF Standards Track. Throughout this document, the term 6to4 is 85 used to refer to the mechanism described in [RFC3056] and 6rd the 86 mechanism defined herein. 88 6rd specifies a protocol mechanism to deploy IPv6 to sites via a 89 Service Provider's (SP's) IPv4 network. It builds on 6to4 [RFC3056], 90 with the key differentiator that it utilizes an SP's own IPv6 address 91 prefix rather than a well known prefix (2002::/16). By using the 92 SP's IPv6 prefix, the operational domain of 6rd is limited to the SP 93 network and under its direct control. From the perspective of 94 customer sites and the IPv6 Internet at large, the IPv6 service 95 provided is equivalent to native IPv6. 97 The 6rd mechanism relies upon an algorithmic mapping between the IPv6 98 and IPv4 addresses that are assigned for use within the SP network. 99 This mapping allows for automatic determination of IPv4 tunnel 100 endpoints from IPv6 prefixes, allowing stateless operation of 6rd. 101 6rd views the IPv4 network as a link layer for IPv6 and supports an 102 automatic tunneling abstraction similar to the Non-Broadcast Multiple 103 Access (NBMA)[RFC2491] model. 105 A 6rd domain consists of 6rd Customer Edge (CE) routers and one or 106 more 6rd Border Relays (BRs). IPv6 packets encapsulated by 6rd 107 follow the IPv4 routing topology within the SP network among CEs and 108 BRs. 6rd BRs are traversed only for IPv6 packets that are destined to 109 or are arriving from outside the SP's 6rd domain. As 6rd is 110 stateless, BRs may be reached using anycast for failover and 111 resiliency (in a similar fashion to [RFC3068]. 113 On the "customer-facing" (i.e., "LAN") side of a CE, IPv6 is 114 implemented as it would be for any native IP service delivered by the 115 SP and further considerations for IPv6 operation on the LAN-side of 116 the CE is out of scope for this document. On the "SP-Facing" (i.e., 117 "WAN") side of the 6rd CE, the WAN interface itself, encapsulation 118 over Ethernet, ATM or PPP, as well as control protocols such as 119 PPPoE, IPCP, DHCP, etc. all remain unchanged from current IPv4 120 operation. Although 6rd was designed primarily to support IPv6 121 deployment to a customer site (such as a residential home network) by 122 an SP, it can equally be applied to an individual IPv6 host acting as 123 a CE. 125 6rd relies on IPv4 and is designed to deliver production-quality IPv6 126 alongside IPv4 with as little change to IPv4 networking and 127 operations as possible. Native IPv6 deployment within the SP network 128 itself may continue for the SP's own purposes while delivering IPv6 129 service to sites supported by 6rd. Once the SP network and 130 operations can support fully native IPv6 access and transport, 6rd 131 may be discontinued. 133 6rd utilizes the same encapsulation and base mechanism as 6to4 and 134 could be viewed as a superset of 6to4 (6to4 could be achieved by 135 setting the 6rd prefix to 2002::/16). Unlike 6to4, 6rd is for use 136 only in an environment where a service provider cooperates closely to 137 deliver the IPv6 service. 6to4 routes with the 2002::/16 prefix may 138 exist alongside 6rd in the 6rd CE router, and doing so may offer some 139 efficiencies when communicating directly with 6to4 routers. 141 The 6rd link model can be extended to support IPv6 multicast. IPv6 142 multicast support is left for future consideration. 144 How this mechanism should be used and other deployment and 145 operational considerations is considered out of scope for this 146 document. 148 2. Requirements Language 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC 2119 [RFC2119]. 154 3. Terminology 156 6rd prefix An IPv6 prefix selected by the Service Provider 157 for use by a 6rd domain. There is exactly one 158 6rd prefix for a given 6rd domain. An SP may 159 deploy 6rd with a single 6rd domain or multiple 160 6rd domains. 162 6rd Customer Edge A 6rd CE is a device functioning as a Customer 163 Edge in a 6rd deployment. In a residential 164 broadband deployment this type of device is 165 sometimes referred to as a "Residential Gateway 166 (RG)," or "Customer Premises Equipment" (CPE). 167 A typical CE router serving a residential site 168 has one CE WAN side interface, one or more CE 169 LAN side interfaces, and a 6rd virtual 170 interface. A 6rd CE may also be referred to 171 simply as a "CE" within the context of 6rd. 173 6rd delegated prefix The IPv6 prefix calculated by the CE for use 174 within the customer site by combining the 6rd 175 prefix and the CE IPv4 address obtained via 176 IPv4 configuration methods. This prefix can be 177 considered logically equivalent to a DHCPv6 178 IPv6 delegated prefix [RFC3633]. 180 6rd domain A set of 6rd CEs and BRs connected to the same 181 virtual 6rd link. A Service Provider may 182 deploy 6rd with a single 6rd domain, or may 183 utilize multiple 6rd domains. Each domain 184 requires a separate 6rd prefix. 186 CE LAN side The functionality of a 6rd CE that serves the 187 "Local Area Network (LAN)" or "customer-facing" 188 side of the CE. The CE LAN side interface is 189 fully IPv6 enabled. 191 CE WAN side The functionality of a 6rd CE that serves the 192 "Wide Area Network (WAN)" or "Service Provider- 193 facing" side of the CE. The CE WAN side is 194 IPv4-only. 196 6rd Border Relay (BR) A 6rd-enabled router managed by the service 197 provider at the edge of a 6rd domain. A border 198 relay router has at least one of each of the 199 following: an IPv4-enabled interface, a 6rd 200 virtual interface acting as an endpoint for the 201 6rd IPv6 in IPv4 tunnel, and an IPv6 interface 202 connected to the native IPv6 network. A 6rd BR 203 may also be referred to simply as a "BR" within 204 the context of 6rd. 206 BR IPv4 address The IPv4 address of the 6rd Border Relay for a 207 given 6rd domain. This IPv4 address is used by 208 the CE to send packets to a BR in order to 209 reach IPv6 destinations outside of the 6rd 210 domain. 212 6rd virtual interface Internal multi-point tunnel interface where 6rd 213 encapsulation and decapsulation of IPv6 packets 214 inside IPv4 occurs. A typical CE or BR 215 implementation requires only one 6rd virtual 216 interface. A BR operating in multiple 6rd 217 domains may require more than one 6rd virtual 218 interface, but no more than one per 6rd domain. 220 CE IPv4 address The IPv4 address given to the CE as part of 221 normal IPv4 Internet access (i.e., configured 222 via DHCP, PPP, or otherwise). This address may 223 be global or private [RFC1918] within the 6rd 224 domain. This address is used by a 6rd CE to 225 create the 6rd delegated prefix as well as to 226 send and receive IPv4-encapsulated IPv6 227 packets. 229 4. 6rd Prefix Delegation 231 The 6rd delegated prefix for use at a customer site is created by 232 combining the 6rd prefix and all or part of the CE IPv4 address. 233 From these elements, the 6rd delegated prefix is automatically 234 created by the CE for the customer site when IPv4 service is 235 obtained. This 6rd delegated prefix is used in the same manner as a 236 prefix obtained via DHCPv6 Prefix Delegation [RFC3633]. 238 In 6to4, a similar operation is performed by incorporating an entire 239 IPv4 address at a fixed location following a well-known /16 IPv6 240 prefix. In 6rd, the IPv6 prefix as well as the position and number 241 of bits of the IPv4 address incorporated varies from one 6rd domain 242 to the next. 6rd allows the SP to adjust the size of the 6rd prefix, 243 how many bits used by the 6rd mechanism, and how many bits are left 244 to be delegated to customer sites. To allow for stateless address 245 auto-configuration on the CE LAN side, a 6rd delegated prefix SHOULD 246 be /64 or shorter. 248 The 6rd delegated prefix is created by concatenating the 6rd prefix 249 and a consecutive set of bits from the CE IPv4 address in order. The 250 sum of the number of bits used by each determines the size of the 251 prefix that is delegated to the CE. 253 The figure shows the format of an IPv6 address (section 2.5.4 of 254 [RFC4291]) with a 6rd prefix and an embedded CE IPv4 address: 256 | n bits | o bits | m bits | 128-n-o-m bits | 257 +---------------+--------------+-----------+------------------------+ 258 | 6rd prefix | IPv4 address | subnet ID | interface ID | 259 +---------------+--------------+-----------+------------------------+ 260 |<--- 6rd delegated prefix --->| 262 Figure 1 264 For example, if the 6rd prefix is /32 and 24 bits of the CE IPv4 265 address is used (e.g all CE IPv4 addresses can be aggregated by a 266 10.0.0.0/8), then the size of the 6rd delegated prefix for each CE is 267 automatically calculated to be /56 (32 + 24 = 56). 269 Embedding less than the full 32 bits of a CE IPv4 address is possible 270 only when an aggregated block of IPv4 addresses is available for a 271 given 6rd domain. This may not be practical with global IPv4 272 addresses, but is quite likely in a deployment where private 273 addresses are being assigned to CEs. If private addresses overlap 274 within a given 6rd deployment, the deployment may be divided into 275 separate 6rd domains, likely along the same topology lines the NAT- 276 based IPv4 deployment itself would require. In this case, each 277 domain is addressed with a different 6rd prefix. 279 Each 6rd domain may use a different encoding of the embedded IPv4 280 address, even within the same service provider. For example, if 281 multiple IPv4 address blocks with different levels of aggregation are 282 used at the same service provider, the number of IPv4 bits needed to 283 encode the 6rd delegated prefix may vary between each block. In this 284 case, different 6rd prefixes, and hence separate 6rd domains, may be 285 used to support the different encodings. 287 Since 6rd delegated prefixes are selected algorithmically from an 288 IPv4 address, changing the IPv4 address will cause a change in the 289 IPv6 delegated prefix which would ripple through the site's network 290 and could be disruptive. As such, it is recommended that the Service 291 Provider assign CE IPv4 addresses with relatively long lifetimes. 293 6rd IPv6 address assignment and hence the IPv6 service itself is tied 294 to the IPv4 address lease, thus the 6rd service is also tied to this 295 in terms of authorization, accounting, etc. For example, the 6rd 296 delegated prefix has the same lifetime as its associated IPv4 297 address. The prefix lifetimes advertised in Router Advertisements or 298 used by DHCP on the CE LAN side MUST be equal to or shorter than the 299 IPv4 address lease time. If the IPv4 lease time is not known, the 300 lifetime of the 6rd delegated prefix SHOULD follow the defaults 301 specified in [RFC4861]. 303 5. Troubleshooting and Traceability 305 A 6rd IPv6 address and associated IPv4 address for a given customer 306 can always be determined algorithmically by the service provider that 307 operates the given 6rd domain. This may be useful for referencing 308 logs and other data at a service provider which may have more robust 309 operational tools for IPv4 than IPv6. This also allows IPv4 data 310 path, node, and endpoint monitoring to be applicable to IPv6. 312 The 6rd CE and BR SHOULD support the IPv6 Subnet-Router anycast 313 address [RFC4291] for its own 6rd delegated prefix. This allows, for 314 example, IPv6 ICMP echo messages to be sent to the 6rd virtual 315 interface itself for additional troubleshooting of the internal 316 operation of 6rd at a given CE or BR. In the case of the BR, the 317 IPv4 address used to calculate the 6rd delegated prefix is the 318 configured BR IPv4 Address. 320 6. Address Selection 322 All addresses assigned from 6rd delegated prefixes should be treated 323 as native IPv6. No changes to the source address selection or 324 destination address selection policy table [RFC3484] are necessary. 326 7. 6rd Configuration 328 For a given 6rd domain, the BR and CE MUST be configured with the 329 following four 6rd elements. The configured values for these four 330 6rd elements are identical for all CEs and BRs within a given 6rd 331 domain. 333 IPv4MaskLen The number of high-order bits that are identical 334 across all CE IPv4 addresses within a given 6rd 335 domain. For example, if there are no identical 336 bits, IPv4MaskLen is 0 and the entire CE IPv4 337 address is used to create the 6rd delegated 338 prefix. If there are 8 identical bits (e.g., the 339 Private IPv4 address range 10.0.0.0/8 is being 340 used), IPv4MaskLen is equal to 8 and IPv4MaskLen 341 high-order bits are stripped from the IPv4 342 address before constructing the corresponding 6rd 343 delegated prefix. 345 6rdPrefix The 6rd IPv6 prefix for the given 6rd domain. 347 6rdPrefixLen The length of the 6rd IPv6 prefix for the given 348 6rd domain. 350 6rdBRIPv4Address The IPv4 address of the 6rd Border Relay for a 351 given 6rd domain. 353 7.1. Customer Edge Configuration 355 The four 6rd elements are set to values which are the same across all 356 CEs within a 6rd domain. The values may be configured in a variety 357 of manners, including provisioning methods such as the Broadband 358 Forum's "TR-69" [TR069] Residential Gateway management interface, an 359 XML-based object retrieved after IPv4 connectivity is established, a 360 DNS record, an SMIv2 MIB [RFC2578], PPP IPCP, or manual configuration 361 by an administrator. This document describes how to configure the 362 necessary parameters via a single DHCP option. A CE which allows 363 IPv4 configuration by DHCP SHOULD implement this option. Other 364 configuration and management methods may use the format described by 365 this option for consistency and convenience of implementation on CEs 366 which support multiple configuration methods. 368 The only remaining provisioning information the CE requires in order 369 to calculate the 6rd delegated prefix and enable IPv6 connectivity is 370 an IPv4 address for the CE. This CE IPv4 address is configured as 371 part of obtaining IPv4 Internet access (i.e., configured via DHCP, 372 PPP, or otherwise). This address may be global or private [RFC1918] 373 within the 6rd domain. 375 A single 6rd CE MAY be connected to more than one 6rd domain, just as 376 any router may have more than one IPv6-enabled service provider 377 facing interface and more than one set of associated delegated 378 prefixes assigned by DHCPv6 PD or other means. Each domain a given 379 CE operates within would require its own set of 6rd configuration 380 elements, and would generate its own 6rd delegated prefix. 382 7.1.1. 6rd DHCPv4 Option 384 0 1 2 3 385 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 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | OPTION_6RD | option-length | IPv4MaskLen | 6rdPrefixLen | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | | 390 | 6rdPrefix | 391 | (16 octets) | 392 | | 393 | | 394 | | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | 6rdBRIPv4Address(es) | 397 . . 398 . . 399 . . 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 Figure 2 404 option-code OPTION_6RD(TBD) 406 option-length the length of the DHCP option in octets (22 407 octets with one BR IPv4 address). 409 IPv4MaskLen The number of high-order bits that are identical 410 across all CE IPv4 addresses within a given 6rd 411 domain. This may be any value between 0 and 32. 412 Any value greater than 32 is invalid. 414 6rdPrefixLen The IPv6 Prefix length of the SP's 6rd IPv6 415 prefix in number of bits. For the purpose of 416 bounds checking by DHCP option processing, the 417 sum of (32 - IPv4MaskLen) + 6rdPrefixLen MUST be 418 less than or equal to 128. 420 6rdBRIPv4Address One or more IPv4 addresses of the 6rd Border 421 Relay(s) for a given 6rd domain. 423 6rdPrefix The Service Provider's 6rd IPv6 prefix 424 represented as a 16 octet IPv6 address. The bits 425 in the prefix after the 6rdPrefixlen number of 426 bits are reserved and MUST be initialized to zero 427 by the sender and ignored by the receiver. 429 The CE MUST include a Parameter Request List Option [RFC2132] for the 430 OPTION_6RD. Because the OPTION_6RD contains one IPv4MaskLen/ 431 6rdPrefixLen/6rdPrefix block, and because DHCP cannot convey more 432 than one instance of an option, OPTION_6RD is limited to provision at 433 most a single 6rd domain. Provisioning of a CE router connected to 434 multiple 6rd domains is outside the scope of this protocol 435 specification. 437 The presence of the OPTION_6RD DHCP option is an indication of the 438 availability of the 6rd service. By default, receipt of a valid 6rd 439 DHCP option by a 6rd-capable CE results in configuration of the 6rd 440 virtual interface and associated delegated prefix for use on the CE's 441 LAN side. The CE MUST be able to configure the 6rd mechanism to be 442 disabled, in which case the 6rd DHCP option, if received, is silently 443 ignored. 445 A detailed description of CE behavior using multiple BR IPv4 446 addresses is left for future consideration. In such a case, a CE 447 MUST support at least one BR IPv4 address and MAY support more than 448 one. 450 When 6rd is enabled, a typical CE router will install a default route 451 to the BR, a black hole route for the 6rd delegated prefix, and 452 routes for any LAN side assigned and advertised prefixes. For 453 example, using a CE IPv4 address of 10.100.100.1, a BR IPv4 address 454 of 10.0.0.1, an IPv4MaskLen of 8, 2001:db8::/32 as the 6rdPrefix, and 455 one /64 prefix assigned to a LAN side Interface, a typical CE Routing 456 Table will look like: 458 ::/0 -> 6rd-virtual-int0 via 2001:db8:0:100:: (default route) 459 2001:db8::/32 -> 6rd-virtual-int0 (direct connect to 6rd) 460 2001:db8:6464:100::/56 -> Null0 (delegated prefix null route) 461 2001:db8:6464:100::/64 -> Ethernet0 (LAN interface) 463 7.2. Border Relay Configuration 465 The 6rd BR MUST be configured with the same 6rd elements as the 6rd 466 CEs operating within the same domain. 468 For increased reliability and load-balancing, the BR IPv4 address may 469 be an anycast address shared across a given 6rd domain. As 6rd is 470 stateless, any BR may be used at any time. If the BR IPv4 address is 471 anycast the relay MUST use this anycast IPv4 address as the source 472 address in packets relayed to CEs. 474 Since 6rd uses provider address space, no specific routes need to be 475 advertised externally for 6rd to operate, neither in IPv6 nor IPv4 476 BGP. However, if anycast is used for the 6rd IPv4 relays, the 477 anycast addresses must be advertised in the service provider's IGP. 479 8. Neighbor Unreachability Detection 481 Neighbor Unreachability Detection (NUD) for tunnels is described in 482 Section 3.8 of [RFC4213]. In 6rd, all CEs and BRs can be considered 483 as connected to the same virtual link and therefore neighbors to each 484 other. This section describes how to utilize neighbor unreachability 485 detection without negatively impacting the scalability of a 6rd 486 deployment. 488 A typical 6rd deployment may consist of a very large number of CEs 489 within the same domain. Reachability between CEs is based on IPv4 490 routing, and sending NUD or any periodic packets between 6rd CE 491 devices beyond isolated troubleshooting of the 6rd mechanism is NOT 492 RECOMMENDED. 494 While reachability detection between a given 6rd CE and BR is not 495 necessary for the proper operation of 6rd, in cases where a CE has 496 alternate paths for BR reachability to choose from, it could be 497 useful. Sending NUD messages to a BR, in particular periodic 498 messages from a very large number of CEs, could result in overloading 499 of the BR control message processing path, negatively affecting 500 scalability of the 6rd deployment. Instead, a CE that needs to 501 determine BR reachability MUST utilize a method which allows 502 reachability detection packets to follow a typical data forwarding 503 path without special processing by the BR. One such method is 504 described below. 506 1. The CE constructs a payload of any size and content to be sent to 507 the BR (e.g., a zero length null payload, a padded payload 508 designed to test a certain MTU, a NUD message, etc.). The exact 509 format of the message payload is not important as the BR will not 510 be processing it directly. 512 2. The desired payload is encapsulated with the inner IPv6 and outer 513 IPv4 headers as follows: 515 * The IPv6 destination address is set to an address from the 516 CE's 6rd delegated prefix that is assigned to a virtual 517 interface on the CE. 519 * The IPv6 source address is set to an address from the CE's 6rd 520 delegated prefix as well, including the same as used for the 521 IPv6 destination address. 523 * The IPv4 header is then added as it normally would for any 524 packet destined for the BR. That is, the IPv4 destination 525 address is that of the BR, and source address is the CE IPv4 526 address. 528 3. The CE sends the constructed packet out the proper interface it 529 is monitoring BR reachability on. On successful receipt at the 530 BR, the BR MUST decapsulate and forward the packet normally. 531 This is, the IPv4 header is decapsulated normally, revealing the 532 IPv6 destination as the CE, which in turn results in the packet 533 being forwarded to that CE via the 6rd mechanism (i.e., the IPv4 534 destination is that of the CE that originated the packet, and the 535 IPv4 source is that of the BR). 537 4. Arrival of the constructed IPv6 packet at the CE's IPv6 address 538 completes one round trip to and from the BR, without causing the 539 BR to process the message outside of its normal data forwarding 540 path. The CE then processes the IPv6 packet accordingly 541 (updating keepalive timers, metrics, etc). 543 The payload may be empty, or could contain values that are meaningful 544 to the CE. Sending a proper NUD message could be convenient for some 545 implementations (note that the BR will decrement the IPv6 hop-limit). 546 Since the BR forwards the packet as any other data packet without any 547 processing of the payload itself, the format of the payload is left 548 as a choice to the implementer. 550 9. IPv6 in IPv4 Encapsulation 552 IPv6 in IPv4 encapsulation and forwarding manipulations (e.g handling 553 packet markings, checksumming etc.) is performed as specified in 554 section 3.5 of Basic Transition Mechanisms for IPv6 Hosts and Routers 555 [RFC4213], which is the same mechanism used by 6to4 [RFC3056]. 556 ICMPv4 errors are handled as specified in section 3.4 of [RFC4213]. 557 By default the IPv6 Traffic class field MUST be copied to the IPv4 558 ToS field. This default behavior MAY be overridden by configuration. 559 See [RFC2983] and [RFC3168] for further information related to IP 560 Differentiated Services and tunneling. 562 IPv6 packets from a CE are encapsulated in IPv4 packets when they 563 leave the site via its CE WAN side interface. The CE IPv4 address 564 MUST be configured to send and receive packets on this interface. 566 The 6rd link is modeled as an NBMA link similar to other automatic 567 IPv6 in IPv4 tunneling mechanisms like [RFC5214] with all 6rd CEs and 568 BRs defined off-link neighbors from one other. The link-local 569 address of a 6rd virtual-interface performing the 6rd encapsulation 570 would, if needed, be formed as described in Section 3.7 of [RFC4213]. 571 However, no communication using link-local addresses will occur. 573 9.1. Maximum Transmission Unit 575 MTU and fragmentation issues for IPv6 in IPv4 tunneling are discussed 576 in detail in section 3.2 of RFC4213 [RFC4213]. 6rd's scope is limited 577 to a service provider network. IPv4 Path MTU discovery MAY be used 578 to adjust the MTU of the tunnel as described in section 3.2.2 of 579 RFC4213 [RFC4213] or the 6rd Tunnel MTU might be explicitly 580 configured. 582 The use of an anycast source address could lead to any ICMP error 583 message generated on the path being sent to a different BR. 584 Therefore using dynamic tunnel MTU [section 3.2.2, RFC4213] is 585 subject to IPv4 Path MTU blackholes. 587 Multiple BRs using the same anycast source address could send 588 fragmented packets to the same IPv6 CE at the same time. If the 589 fragmented packets from different BRs happen to use the same fragment 590 ID, incorrect reassembly might occur. For this reason a BR using an 591 anycast source address MUST set the IPv4 Don't Fragment flag. 593 If the MTU is well-managed such that the IPv4 MTU on the CE WAN side 594 interface is set so that no fragmentation occurs within the boundary 595 of the SP, then the 6rd Tunnel MTU should be set to the known IPv4 596 MTU minus the size of the encapsulating IPv4 header (20 bytes). For 597 example, if the IPv4 MTU is known to be 1500 bytes, the 6rd Tunnel 598 MTU might be set to 1480 bytes. Absent more specific information the 599 6rd Tunnel MTU SHOULD default to 1280 bytes. 601 9.2. Receiving Rules 603 In order to prevent spoofing of IPv6 addresses, the 6rd BR and CE 604 MUST validate the embedded IPv4 source address of the encapsulated 605 IPv6 packet with the IPv4 source address it is encapsulated by 606 according to the configured parameters of the 6rd domain. If the two 607 source addresses do not match, the packet MUST be dropped and a 608 counter incremented to indicate that a potential spoofing attack may 609 be underway. Additionally, a CE MUST allow forwarding of packets 610 sourced by the configured BR IPv4 Address. 612 By default, the CE router MUST drop packets received on the 6rd 613 virtual interface (i.e., after decapsulation of IPv4) for IPv6 614 destinations not within its own 6rd delegated prefix. 616 10. Transition Considerations 618 An SP network can migrate to IPv6 at its own pace with little or no 619 effect on customers being provided IPv6 via 6rd. When native IPv6 620 connectivity is available, an administrator can choose to disable 621 6rd. 623 The SP can choose to provision a separate IPv6 address block for 624 native service, or reuse the 6rd prefix block itself. If the SP uses 625 a separate address block, moving from 6rd to native IPv6 is seen as a 626 normal IPv6 renumbering event for the customer. Renumbering may also 627 be avoided by injecting the 6rd delegated prefix into the SP's IPv6 628 routing domain. Further considerations with regards to transitioning 629 from 6rd to native IPv6 are not covered in this protocol 630 specification. 632 11. IPv6 Address Space Usage 634 As 6rd uses service provider address space, 6rd uses the normal 635 address delegation a service provider gets from its RIR and no global 636 allocation of a single 6rd IANA assigned address block like the 6to4 637 2002::/16 is needed. 639 The service provider's prefix must be short enough to encode the 640 unique bits of all IPv4 addresses within a given 6rd domain and still 641 provide enough IPv6 address space to the residential site. Assuming 642 a worst case scenario using the full 32 bits for the IPv4 address, 643 assigning a /56 for customer sites would mean that each service 644 provider using 6rd would require a /24 for 6rd in addition to other 645 IPv6 addressing needs. Assuming that 6rd would be stunningly 646 successful and taken up by almost all AS number holders (32K today) 647 then the total address usage of 6rd would be equivalent to a /9. If 648 the SP instead delegated /60s to sites the service provider would 649 require a /28 and the total global address consumption by 6rd would 650 be equivalent to a /13. Again, this assumes that 6rd is used by all 651 AS number holders in the IPv4 Internet today at the same time, none 652 used any of 6rd's address compression techniques, and that none have 653 moved to native IPv6 and reclaimed the 6rd space which was being used 654 for other purposes. 656 To alleviate concerns about address usage, 6rd allows for leaving out 657 redundant IPv4 prefix bits in the encoding of the IPv4 address inside 658 the 6rd IPv6 address. This is most useful where the IPv4 address 659 space is very well aggregated. For example to provide each customer 660 with a /60, if a service provider has all its IPv4 customers under a 661 /12 then only 20 bits needs to be used to encode the IPv4 address and 662 the service provider would only need a /40 IPv6 allocation for 6rd. 663 If private address space is used then a 10/8 would require a /36. If 664 multiple 10/8 domains are used then up to 16 could be supported 665 within a /32. 667 If a Service Provider has an non-aggregatable IPv4 space and 668 requiring the use of the full 32 bit IPv4 address in the encoding of 669 the 6rd IPv6 address, the 6rd prefix MUST be no longer than /32 in 670 order to offer a 6rd delegated prefix of at least /64. 672 The 6rd address block can be reclaimed when all users of it have 673 transitioned to native IPv6 service. This may require renumbering of 674 customer sites and use of additional address space during the 675 transition period. 677 12. Security Considerations 679 A 6to4 relay router as specified in [RFC3056] can be used as an open 680 relay. It can be used to relay IPv6 traffic and as a traffic 681 anonymizer. By restricting the 6rd domain to within a provider 682 network a CE only needs to accept packets from a single or small set 683 of known 6rd BR IPv4 Addresses. As such, many of the threats against 684 6to4 as described in [RFC3964] do not apply. 686 When applying the receiving rules in Section 9.2, IPv6 packets are as 687 well protected against spoofing as IPv4 packets are within an SP 688 network. 690 A malicious user that is aware of a 6rd domain and the BR IPv4 691 address could use this information to construct a packet that would 692 cause a Border Relay to reflect tunneled packets outside of the 693 domain that it is serving. If the attacker constructs the packet 694 accordingly, and can inject a packet with an IPv6 source address that 695 looks as if it originates from within another 6rd domain, forwarding 696 loops between 6rd domains may be created, allowing the malicious user 697 to launch a packet amplification attack between 6rd domains 698 [RoutingLoop]. 700 One possible mitigation for this is to simply not allow the BR IPv4 701 address to be reachable from outside the SP's 6rd domain. In this 702 case, carefully constructed IPv6 packets still could be reflected off 703 a single BR, but the looping condition will not occur. Tunnelled 704 packets with the BR IPv4 address as the source address might also be 705 filtered to prohibit 6rd tunnels from exiting the 6rd domain. 707 To avoid forwarding loops via other internal relays, the BR should 708 employ outgoing and incoming IPv4 packets filters, filtering out all 709 known relay addresses for internal 6rd BRs, ISATAP routers or 6to4 710 relays, including the well known anycast address space for 6to4. 712 Another possible mitigation to the routing loop issue are described 713 in [I-D.nakibly-v6ops-tunnel-loops]. 715 The BR MUST install a null route [RFC4632] for its 6rd delegated 716 prefix created based on its BR IPv4 address, with the exception of 717 the IPv6 Subnet-Router anycast address. 719 13. IANA Considerations 721 IANA is requested to assign a new DHCP Option code point for 722 OPTION_6RD with a data length of 18 + N (OPTION_6RD with N/4 6rd BR 723 addresses). 725 14. Acknowledgements 727 This draft is based on Remi Despres' original idea described in 728 [RFC5569] and the work done by Rani Assaf, Alexandre Cassen, and 729 Maxime Bizon at Free Telecom. Brian Carpenter and Keith Moore 730 documented 6to4, which all of this work is based upon. We thank Fred 731 Templin for his review, contributions and sharing his experience with 732 ISATAP. Review and encouragement have been provided by many others 733 and in particular Chris Chase, Thomas Clausen, Wouter Cloetens, 734 Wojciech Dec, Bruno Decraene, Remi Despres, Alain Durand, Washam Fan, 735 Martin Gysi, Jerry Huang, Dave Thaler, Eric Voit and David Ward. 737 15. References 739 15.1. Normative References 741 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 742 E. Lear, "Address Allocation for Private Internets", 743 BCP 5, RFC 1918, February 1996. 745 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 746 Requirement Levels", BCP 14, RFC 2119, March 1997. 748 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 749 Extensions", RFC 2132, March 1997. 751 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 752 over Non-Broadcast Multiple Access (NBMA) networks", 753 RFC 2491, January 1999. 755 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 756 via IPv4 Clouds", RFC 3056, February 2001. 758 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 759 of Explicit Congestion Notification (ECN) to IP", 760 RFC 3168, September 2001. 762 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 763 for IPv6 Hosts and Routers", RFC 4213, October 2005. 765 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 766 Architecture", RFC 4291, February 2006. 768 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 769 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 770 September 2007. 772 15.2. Informative References 774 [I-D.nakibly-v6ops-tunnel-loops] 775 Nakibly, G. and F. Templin, "Routing Loop Attack using 776 IPv6 Automatic Tunnels: Problem Statement and Proposed 777 Mitigations", draft-nakibly-v6ops-tunnel-loops-02 (work in 778 progress), May 2010. 780 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 781 Schoenwaelder, Ed., "Structure of Management Information 782 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 784 [RFC2983] Black, D., "Differentiated Services and Tunnels", 785 RFC 2983, October 2000. 787 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 788 RFC 3068, June 2001. 790 [RFC3484] Draves, R., "Default Address Selection for Internet 791 Protocol version 6 (IPv6)", RFC 3484, February 2003. 793 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 794 Host Configuration Protocol (DHCP) version 6", RFC 3633, 795 December 2003. 797 [RFC3964] Savola, P. and C. Patel, "Security Considerations for 798 6to4", RFC 3964, December 2004. 800 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 801 (CIDR): The Internet Address Assignment and Aggregation 802 Plan", BCP 122, RFC 4632, August 2006. 804 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 805 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 806 March 2008. 808 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 809 Infrastructures (6rd)", RFC 5569, January 2010. 811 [RoutingLoop] 812 Nakibly and Arov, "Routing Loop Attacks using IPv6 813 Tunnels", August 2009, . 816 [TR069] "TR-069, CPE WAN Management Protocol v1.1, Version: Issue 817 1 Amendment 2", December 2007. 819 Authors' Addresses 821 Mark Townsley 822 Cisco 823 Paris, 824 France 826 Email: mark@townsley.net 828 Ole Troan 829 Cisco 830 Bergen, 831 Norway 833 Email: ot@cisco.com