idnits 2.17.1 draft-despres-v6ops-6rd-ipv6-rapid-deployment-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 747. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 758. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 765. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 771. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 1 instance 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 239: '... MUST start with prefixes that belon...' RFC 2119 keyword, line 318: '... of the address, MUST belong to the IS...' RFC 2119 keyword, line 325: '...herefore proposed to be a MUST in 6rd....' RFC 2119 keyword, line 368: '...tation, 6rd ISPs MUST support path MTU...' RFC 2119 keyword, line 417: '...t boundaries, it MAY decide to assign ...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 9, 2008) is 5892 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: 'RFC2132' is defined on line 677, but no explicit reference was found in the text == Unused Reference: 'RFC2463' is defined on line 683, but no explicit reference was found in the text == Unused Reference: 'RFC3513' is defined on line 690, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2463 (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 2893 (Obsoleted by RFC 4213) ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) -- Obsolete informational reference (is this intentional?): RFC 3068 (Obsoleted by RFC 7526) Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Despres 3 Internet-Draft RD-IPtech 4 Expires: August 12, 2008 February 9, 2008 6 IPv6 Rapid Deployment on IPv4 infrastructures (6rd) 7 draft-despres-v6ops-6rd-ipv6-rapid-deployment-00 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 12, 2008. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2008). 38 Abstract 40 IPv6 rapid deployment (6rd) builds upon mechanisms of 6to4 (RFC3056) 41 to enable a service provider to rapidly deploy IPv6 unicast service 42 to its existing IPv4 sites. Like 6to4, it utilizes stateless IPv6 in 43 IPv4 encapsulation in order to transit IPv4-only network 44 infrastructure. Unlike 6to4, 6rd requires a service provider to use 45 one of its own IP prefixes rather than the fixed 6to4 prefix. A 46 service provider has used this mechanism for its own "rapid 47 deployment" of IPv6 (five weeks from first exposure to "opt-in" 48 deployment for 1,500,000 residential sites). 50 Table of Contents 52 1. Introduction and 6rd purpose . . . . . . . . . . . . . . . . . 3 53 2. Abbreviations and terminology . . . . . . . . . . . . . . . . 5 54 3. 6rd specification . . . . . . . . . . . . . . . . . . . . . . 6 55 3.1. General principles . . . . . . . . . . . . . . . . . . . . 6 56 3.2. 6rd ISP prefix and 6rd addresses . . . . . . . . . . . . . 8 57 3.3. Encapsulation and decapsulation in 6rd CPEs and 6rd 58 relays . . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 3.3.1. Packet format . . . . . . . . . . . . . . . . . . . . 9 60 3.3.2. 6rd prefix in non 6rd addresses - the 6rd pure 61 IPv6 tag . . . . . . . . . . . . . . . . . . . . . . . 10 62 3.3.3. Relationship between IPv6 and IPv4 addresses in 63 encapsulation packets . . . . . . . . . . . . . . . . 11 64 3.4. ICMP consideration . . . . . . . . . . . . . . . . . . . . 12 65 3.5. IPv4 routing precaution . . . . . . . . . . . . . . . . . 12 66 3.6. Pseudo code . . . . . . . . . . . . . . . . . . . . . . . 13 67 4. The 6rd DHCPv4 option . . . . . . . . . . . . . . . . . . . . 14 68 5. 6rd Applicability to ISPs that use IPv4 private addresses . . 14 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 74 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 76 Intellectual Property and Copyright Statements . . . . . . . . . . 19 78 1. Introduction and 6rd purpose 80 After having had a succinct presentation of the 6rd idea, a major ISP 81 in France, Free Telecom, did all of the following in only five weeks 82 (November 7th to December 11th 2007): (1) obtain its first IPv6 83 prefix from its RIR; (2) make the needed 6rd software modifications 84 to all CPE that it provides to its customers; (3) provision a 6to4 85 gateway, duly modified to support 6rd; (4) test IPv6 operation with a 86 few applications; (6) finish deployment; (7) announce IPv6 87 availability, at no extra charge, for all customers accepting to have 88 it. More than 1,500,000 residential customers thus became able to 89 use IPv6 in their sites, with a look and feel as that of other native 90 IPv6 solutions, at the only condition to consciously activate the 91 function in their CPEs. 93 This story is not reported to suggest that other ISPs should be able 94 to do the same. It illustrates however that, under some 95 circumstances, the following vicious circle has been broken: 97 o ISPs that have large IPv4 installed bases tend to wait for more 98 customer demand before bearing the cost of generalized IPv6 99 support. 101 o Customers tend to wait for more IPv6 depending applications before 102 requiring IPv6 support by ISPs. 104 o Application developers tend to wait for more IPv6 support by ISPs 105 before investing substantially on IPv6 dependent applications. 107 6rd has been designed to drastically simplify first IPv6 deployments 108 on IPv4 installed infrastructures. 110 Ideal conditions for 6rd deployment, which were satisfied at Free, 111 are that: 113 o The ISP controls CPEs of all its sites. 115 o It can easily modify CPE software and have it downloaded. 117 o It can quickly install gateways of its own, with high bandwidth in 118 both IPv4 and IPv6. 120 o It can adapt the software of these gateways to 6rd (preferably 121 starting with an existing 6to4 relay software to minimize the 122 effort). 124 A less ideal but workable situation is one where CPEs are provisioned 125 by customers themselves (hosts , or site entrance routers). For 126 these sites to benefit from 6rd being deployed by their ISP, they 127 need 6rd support also in their CPEs. The necessary software upgrade 128 then depends on their CPE vendor to implement 6rd, and to whoever 129 manages theses CPEs to download the new releases. The 6rd 130 specification is proposed to become a standard for this to be 131 possible. 133 The purpose of this draft is that, with it: 135 o The community of IETF experts can critically evaluate its 136 soundness. 138 o ISPs that offer only IPv4 services can determine whether, based on 139 their own constraints, they wish to use 6rd to accelerate their 140 own IPv6 deployment. 142 o CPE manufacturers can determine whether they wish to support 6rd 143 in their products. If they do, their clients whose ISPs support 144 6rd will have native IPv6 operational in their sites. 146 o Manufacturers of routers used in ISP infrastructures can determine 147 whether they wish to include 6rd support in their products. (Note 148 that in which products to do it may depend on whether address 149 parsing hardware is used, and on whether it is suitable for parse 150 6rd prefix parsing.) If they do, 6rd relays at the IPv4-IPv6 151 border will no longer have to be devices external to these 152 routers, and their number will be easily increased. The added 153 value will then move from external devices to these manufacturer's 154 routers. 156 Readers are supposed to be familiar with IPv6 address formats and 157 notation. 159 It is understood that the wording of this draft 00 can be much 160 improved, in particular with respect to the English language. But it 161 is also felt that presenting the 6rd to the IETF shouldn't be delayed 162 further, so that debates on it can start as soon as possible. 164 2. Abbreviations and terminology 166 6rd: a mechanism for IPv6 rapid deployment by independent ISPs on 167 their existing IPv4 infrastructures 169 6rd CPE: CPE which supports 6rd (host or site entrance router) 171 6rd ISP: ISP which supports 6rd (operates 6rd relays) 173 6rd site: IPv4 customer site of a 6rd ISP 175 6rd ISP anycast address: IPv4 anycast address chosen by a 6rd ISP 177 6rd ISP prefix: IPv6 prefix chosen a 6rd ISP 179 6rd ISP relay: a stateless encpasulation-decapsulation function 180 between IPv4 and IPv6 routing infrastructures of an ISP 182 6to4: Connection of IPv6 Domains via IPv4 clouds [RFC3056][RFC3068] 184 CPE: Customer Premise Equipment (host or router at site entrance) 186 DHCPv4: IPv4 Dynamic Host Configuration Protocol [RFC2131] 188 IANA: Internet Assigned Numbers Authority 190 ICMPv4: IPv4 Internet Control Message Protocol [RFC0792] 192 ICMPv6: IPv6 Internet Control Message Protocol [RFC0792] 194 IPv4: Layer 3 Internet Protocol of 1981 [RFC0791] 196 IPv6: Layer 3 Internet Protocol version 6 [RFC2460] 198 ISP: Internet Service Provider 200 MTU: Maximum Transfer Unit [RFC1191] 202 NAT: Network Address Translator [RFC2663] 204 Pure IPv6: IPv6 with addresses that contain no IPv4 address 206 RIR: Regional Internet Registry 208 Site: Customer site (has a CPE at its entrance) 210 3. 6rd specification 212 3.1. General principles 214 The 6rd specification is based on the following principles : 216 a. For RAPIDITY of IPv6 deployment by ISPs that are still IPv4-only, 217 this deployment should be feasible on their UNMODIFIED IPv4 218 INFRASTRUCTURES. 220 b. For COMPLETENESS of the IPv6 unicast service offered to their 221 customers, ISPs should make NO ASSUMPTION on how hosts of other 222 ISPs obtain their IPv6 service. 224 c. For SCALABILITY of IPv6 deployment on IPv4 infrastructures, 225 encapsulation-decapsulation functions of IPv6 packets in IPv4 226 ones should be STATELESS (load sharing between a number of 227 distributed processors should be feasible). 229 d. For EFFICIENCY, IPv6 packet between two IPv4 sites of a same ISP 230 should follow the SAME ROUTES as those of IPv4 packets between 231 the same sites. 233 The rapidity principle implies that 6rd functions should be 234 introduced only at the periphery of IPv4 infrastructures. Routing on 235 these infrastructures should be that of IPv4, with no need for an 236 independent address assignment and routing policy for IPv6. 238 The completeness principle implies that IPv6 prefixes of 6rd sites 239 MUST start with prefixes that belong to the IPv6 address spaces. (In 240 particular, the 6to4 prefix 2002::/16 would not satisfy this 241 principle: packets destined to a 6to4 site reach their destination 242 only if they come from sites where CPEs support 6to4, or from ISPs 243 where the 6to4 Anycast Address is routable in IPv4 to at least one 244 6to4 relay. Neither of these two conditions can be guaranteed by the 245 destination end ISP). 247 The scalability principle implies that encapsulation functions in 6rd 248 relays can find IPv4 destination addresses without depending on some 249 temporary states that would relate IPv4 destinations to IPv6 ones. 250 For this, the most straightforward approach consists in having the 251 IPv4 CPE address of a 6rd site explicitly contained in its IPv6 252 prefix. Since this approach happens to be compatible with 253 satisfaction of other principles, it is adopted for 6rd. 255 Another implication of the scalability principle is that 6rd relays 256 should be reachable, across the ISP IPv4 infrastructure, at an 257 anycast address. Each 6rd ISP choses for this its "6rd ISP anycast 258 address". 260 The efficiency principle implies that 6rd CPEs can recognize, in 261 packets leaving their sites, which ones can be routed to their 262 destination directly across the local ISP IPv4 infrastructure (i.e. 263 without having to go through a 6rd relay). For this, a simple 264 approach consists in each 6rd ISP to chose one and only one of its 265 IPv6 unicast prefixes as the "6rd ISP prefix" which appears at the 266 start of 6rd site addresses addresses, and to have this prefix known 267 by 6rd CPEs. 269 The architecture which results from these principles is that of 270 Figure 1. 272 6rd ISP Native 273 ______________/\_______________ IPv6 274 6rd / \ routing 275 CPEs unchanged Stateless | 276 | IPv4 infrastructure 6rd ISP relays | 277 | | | | 278 V V V V 279 ___ _____________________ ___ 280 IPv6 | | | | | | 281 | |--|-. .--------------|-------| |-------- 282 |___| | \ / | |___| 283 Customer | \ / 6rd ISP => | 284 Sites | O anycast address| <= 6rd ISP 285 ___ | / \ | ___ prefix 286 | | | / \ | | | 287 IPv6 | |--|-' '--------------|--------| |-------- 288 |___| | | |___| 289 |______________________| 291 6rd ARCHITECTURE 293 Figure 1 295 3.2. 6rd ISP prefix and 6rd addresses 297 A 6rd address is a particular case of IPv6 address, with the 298 following format: 300 <-- Link prefix -- 64 bits -->. 301 | | 302 | 16, 24 16, 8 | 303 | or or |<----------- 64 bits --------->. 304 | 32 bits 32 bits 0 bits | | 305 | | | | | | 306 | V V V | | 307 +---//----+------------+--//--+-------------------------------+ 308 |"6rd ISP | IPv4 |Subnet| Interface ID | 309 | prefix" |Site address| ID | | 310 +---//----+------------+--//--+-------------------------------+ 311 <---- Site prefix ----> 313 6rd ADDRESS FORMAT 315 Figure 2 317 According to the completeness principle above, the 6rd ISP prefix, 318 being in the first bits of the address, MUST belong to the ISP public 319 unicast address space. 321 As far as the protocol is concerned, 6rd ISP prefixes could have any 322 number of bits up to 32. But implementations of 6rd, necessary in 323 both 6rd relays and 6rd CPEs, is simpler, and more amenable hardware 324 implementation where appropriate, if 6rd ISP prefixes must be 325 multiple of 8 bits. It is therefore proposed to be a MUST in 6rd. 327 The choice between /16, /24 and /32 6rd ISP prefixes depends on 328 whether IPv6 prefixes ISPs obtain from their RIRs are short enough: 330 o With /32 RIR provided prefixes, the minimum generally recommended 331 today for initial ISP assignments, 6rd ISPs can only assign /64 332 site prefixes to their 6rd customer sites. These sites are then 333 limited to only one IPv6 link. This is expected to be 334 satisfactory initially for the vast majority of residential sites, 335 where the number of hosts is small. But this is a real 336 restriction which would advantageously be avoided with RIRs 337 cooperation (see below). 339 o With /16 RIR provided prefixes, 6rd ISPs can assign /48 site 340 prefixes to their 6rd customer sites, i.e. prefixes the length of 341 which is that RIRs recommend today for all customer sites. But 342 RIRs may be expected to be reluctant to distribute /16s, 343 especially since generalized /48 prefixes are more generous than 344 really needed, at least initially. 346 o With /24 RIR provided prefixes, 6rd ISPs can assign /56 site 347 prefixes to their 6rd customer sites. These sites can then 348 support up to 256 subnets. This is expected to be more than 349 sufficient for the most demanding residential sites, and largely 350 sufficient for almost all professional sites pending deployment of 351 native IPv6 infrastructures. 353 In view of the potential of 6rd to facilitate IPv6 availability, RIRs 354 could be advised to consider assigning /24 prefixes to ISPs that 355 deploy 6rd, and to endorse that these ISPs make their first IPv6 356 deployments with /56s distributed to their customers. 358 3.3. Encapsulation and decapsulation in 6rd CPEs and 6rd relays 360 3.3.1. Packet format 362 To traverse ISP IPv4 infrastructures, IPv6 packets are encapsulated 363 in IPv4 ones in conformance with [RFC2893]. The IPv4 protocol field 364 is set to 41, as specified by IANA for this encapsulation [Protocol 365 Numbers]. 367 In order to avoid that encapsulated packets would ever be subject to 368 IPv4 fragmentation, 6rd ISPs MUST support path MTUs of at least 1300 369 octets on their complete IPv4 infrastructures. (1300 = 1280, the 370 minimum IPv6 MTU, plus 20, the header length of the IPv4 371 encapsulating packet.) Fragmentation has to be avoided because of 372 its incompatibility with stateless functions that operate on complete 373 packets and that may be implemented in several distributed instances. 375 3.3.2. 6rd prefix in non 6rd addresses - the 6rd pure IPv6 tag 377 If an ISP has only one IPv6 prefix assigned by its RIR, as typical 378 for a first assignment, and first uses it to deploy IPv6 in 6rd, it 379 should, to avoid wasting its address space, be able to also use this 380 same prefix to build "pure IPv6" site prefixes. (IPv6 prefixes are 381 "pure" if they don't contain IPv4 addresses). 383 If a 6rd ISP prefix has such a mixed use, CPEs must distinguish 384 between destinations that are 6rd addresses of the same ISP, and 385 other destinations. Packets having the former have to be routed 386 directly to their destinations across local ISP IPv4 infrastructures; 387 packets having the latter have to be routed toward their destinations 388 via 6rd ISP relays of the local ISP). To facilitate this 389 determination, the 6rd specification requires that all pure IPv6 390 addresses that start with the 6rd ISP prefix contain a special value 391 in lieu of the beginning of an IPv4 field, the "6rd pure IPv6 tag". 393 The value of this tag has to be chosen so that it never appears at 394 the beginning of IPv4 unicast addresses assigned by the ISP. Its 395 proposed binary value is 1110 (OxE in hexadecimal, 240.0.0.0/4 in 396 IPv4 notation), which has the desired property: IANA has reserved the 397 set of all 224/8 to 239/8 consecutive prefixes, i.e. the 224/4 398 prefix, for IPv4 multicast addresses [IPv4 addresses]. 400 <-- Link prefix -- 64 bits -->. 401 | | 402 | "6rd pure | 403 | 16, 24 IPv6 tag" | 404 | or 32 bits 4 bits .<----------- 64 bits --------->. 405 | | | | | 406 | V V | | 407 +----//-----+----+-----//-----+-------------------------------+ 408 | 6rd ISP |1110| | Interface ID | 409 | prefix | | | | 410 +----//-----+----+-----//-----+-------------------------------+ 412 6rd PURE IPv6 ADDRESS FORMAT 414 Figure 3 416 NOTE: If an ISP wants to use hardware which works only, or better, on 417 octet boundaries, it MAY decide to assign pure IPv6 addresses that, 418 after the 6rd ISP prefix all start with OxE0 (binary 11100000). With 419 this restriction on assigned addresses, presence tests of the 6rd 420 prefix can be performed indifferently on 4 or 8 bits. 422 3.3.3. Relationship between IPv6 and IPv4 addresses in encapsulation 423 packets 425 IPv6 address (source or destination) IP4 address 426 in an encapsulated packet in the encapsulating packet 428 6rd site addresses 430 4 bits \ 431 +----//-----+-|--+----- | +---------------+ 432 | 6rd ISP |not : \ | IPv4 | 433 | prefix |1110: / | site address | 434 +----//-----+----+----- | +---------------+ 435 <-- IPv4 --- / 436 site address 438 Non 6rd site addresses 440 +----//-----+---------- \ 441 | not 6rd | | 442 |ISP prefix | | 443 +----//-----+---------- | +---------------+ 444 6rd \ | 6rd ISP | 445 pure IPv6 tag / |anycast address| 446 +----//-----+-|--+----- | +---------------+ 447 | 6rd ISP |1110| | 448 | prefix | | | 449 +----//-----+----+----- / 450 4 bits 452 RELATIONSHIP BETWEEN IPv6 AND IPv4 ADDRESSES 453 IN ENCAPSULATION PACKETS OF AN ISP 455 Figure 4 457 In an encapsulating packet, IPv4 addresses, source or destination, 458 have the following relationship with IPv6 addresses of the 459 encapsulated packets, respectively source or destination: 461 o If the IPv6 address starts with the 6rd ISP prefix, and if this 462 prefix is not followed by the 6rd pure IPv6 tag, this site prefix 463 is that of a 6rd site of the local ISP. The IPv4 address MUST 464 then be equal to the 32 bits which follow the 6rd ISP prefix in 465 the IPv6 site prefix. 467 o Contrarily, if the ISP prefix is followed by the 6rd pure IPv6 468 tag, or if the IPv6 address does not start with the ISP prefix, 469 then this address does not belong to a 6rd site of the local ISP. 471 These relationships MUST be implemented in encapsulation functions of 472 6rd relays and 6rd CPEs. 474 In addition, to protect against source address spoofing, 6rd CPEs and 475 6rd ISP relays SHOULD silently discard packets they receive that have 476 unrealistic source and destination addresses or unrealistic IPv4-IPv6 477 address relationships. The pseudo-code of Section 3.6 presents 478 details of these verifications. 480 3.4. ICMP consideration 482 In 6rd decapsulation functions of 6rd CPEs and 6rd relays, ICMPv4 483 packets that are received to signal unreachable destinations (ICMPv4 484 type field = 3) SHOULD be converted into ICMPv6 packets (ICMPv6 type 485 field = 1 and code field = 0). 487 For this to be possible, ISPs that support 6rd SHOULD ensure that all 488 routers of their IPv4 infrastructures return ICMPv4 packets long 489 enough to contain IPv6 source addresses of encapsulated packets. 490 (This is automatically the case if these routers conform to [RFC1812] 491 Section 4.3.2.3.) 493 ICMPv6 packets received by encapsulation functions of 6rd ISP relays 494 and 6rd CPEs are encapsulated like any other IPv6 packets. 496 3.5. IPv4 routing precaution 498 For an ISP to guarantee proper routing of IPv6 packets going from its 499 IPv4 sites to other ISPs, its IPv4 infrastructure SHOULD NOT accept 500 from other ISPs IPv4 routes that include the 6rd ISP anycast address. 502 3.6. Pseudo code 504 Figure 5 details, in pseudo code and with intuitive notations, 505 encapsulation and decapsulation functions, in both 6rd ISP relays and 506 6rd CPEs. 508 CPE DECAPSULATION ISP RELAY ENCAPSULATION 509 IF v6Pkt = ICMPv4(Unreachable) IF Packet > 1280 Octets 510 THEN Forward ICMPv6(Pkt too big) THEN Return ICMPv6(Pkt too big) 511 ELSEIF ELSEIF (S6 <> 6rdPrf... 512 (IF S4 = 6rdAnycast OR S6 = 6rdPrf.Pv6Tag...) 513 THEN [S6 <> 6rdPrf... THEN 514 OR S6 = 6rdPrf.Pv6Tag...] D4 <- bits pl to pl+32 of D6 515 ELSE [S6 = 6rdPrf... S4 <- 6rd Anycast 516 AND S6 <> 6rdPrf.Pv6Tag...]) Encapsulate IPv6 packet 517 AND D6 = 6rdPrf.v4SiteAdd... ELSE Discard packet 518 THEN Decapsulate IPv6 packet | 519 ELSE Discard packet | 520 | __________________ | ______ 521 IPv6 V | IPv4 | V | IPv6 522 ___ |MTU at least 1300 | ___ | 523 | | | | | | | 524 --<--|---|---|--<--- ---<--|-----|---|-----|--<--- 525 | | |<= CPE addresses | | | | 526 | | | | | | | 6rd 527 0::/0 | | | 6rd ISP anycast| | | | <= ISP prefix 528 => | | | address => | | | | 529 -->--|---|---|-->--- --->--|-----|---|-----|-->--- 530 |___| | | |___| | 531 A |__________________| A |______ 532 | | 533 | | 534 CPE ENCAPSULATION ISP RELAY DECAPSULATION 535 IF packet > 180 octets IF v6Pkt = ICMPv4(unreachable) 536 THEN Return ICMPv6(Pkt too big) THEN Forward ICMPv6(Pkt too big) 537 ELSEIF S6 = 6rdPrf.Pv6Tag...) ELSEIF 538 IF ( D6 = 6rdPrf... S4 <> 6rdAnycast 539 AND D6 <> 6rdPrf.Pv6Tag...) AND S6 = 6rdPrf... 540 THEN D4 <- bits pl to pl+32 of D6 AND S6 <> 6rdPrf.Pv6tag... 541 ELSE D4 <- 6rdAnycast AND ( D6 = 6rdPrf.Pv6tag... 542 S4 <- v4SiteAdd OR D6 <> 6rdPrf... 543 ELSE Discard packet THEN Decapsulate IPv6 packet 544 ELSE Discard packet 546 PSEUDO CODE DESCRIPTION OF 6rd FUNCTIONS 547 (lp being the bit length of the ISP 6rd prefix) 549 Figure 5 551 4. The 6rd DHCPv4 option 553 For full support of 6rd, ISPs that have sites with customer-supplied 554 CPEs, and suppliers of these CPEs, SHOULD support the "6rd DHCPv4 555 option. 557 With the 6rd DHCPv4 option, 6rd CPEs obtains 6rd ISP prefixes and 6rd 558 ISP anycast addresses, in a DHCPv4 message [RFC2131]. 560 The proposed format for the 6rd DHCPv4 option is as follows, where nn 561 is a code to be assigned by IANA: 563 6rd prefix length 564 (16, 24 or 32) 565 Code Length | 566 +-----+-----+-----+-----+-----+-----+--V--+-----+-----+-----+-----+ 567 |= nn | = 9 | 6rd ISP Prefix | pl |6rd ISP anycast address| 568 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 570 FORMAT OF THE 6rd DHCPv4 OPTION 572 Figure 6 574 5. 6rd Applicability to ISPs that use IPv4 private addresses 576 Some ISP support NAT functions [RFC2663] within their IPv4 577 infrastructures, so that they can assign IPv4 private addresses 578 [RFC1918] to some of their sites. These ISPs can build IPv6 6rd site 579 prefixes with such IPv4 addresses. 581 If an ISP supports several independent NAT functions (typically 582 because of an insufficient scalability of NAT-supporting devices), it 583 has to ensure, for 6rd, that address spaces behind these NATS are 584 disjoint . 586 Figure 7 presents an example where IPv4 private addresses start with 587 10.0.0.0/8 [RFC1918], a typical choice since other private address 588 prefixes leave room for less addresses. 590 ______________________________ 591 | 10.x.x.x/8 addresses | 592 | <== | 593 <-----| |-----> 594 | 6rd ISP anycast address| 595 6rd CPEs | ==> | 6rd relays 596 | | 597 <-----| 0.0.0.0/0 |-----> 598 | : | 599 | V | 600 |______________________________| 601 | 602 __|__ 603 ISP | | 604 IPv4 NAT |_____| 605 | 606 | 607 V 608 IPv4 public address infrastructure 610 EXAMPLE OF 6rd WITH ISP ASSIGNED IPV4 PRIVATE ADDRESSES 612 Figure 7 614 NOTE: This capability is another difference of scope with 6to4. It 615 may increase the interest of 6rd, for rapid IPv6 deployment, where 616 scarcity of IPv4 addresses has led ISPs to support NATs in their 617 infrastructures. 619 6. Acknowledgements 621 The author would like to warmly acknowledge the major contribution of 622 Rani Assaf to 6rd's credibility. He immediately appreciated 6rd's 623 potential, and made the daring decision to implement it, and to 624 rapidly deploy it on Free's operational network. He has also been 625 first to point out that 6rd ISP prefixes can also be used for IPv6 626 addresses other than 6rd. Patrick Grossetete made useful suggestions 627 on multi-subnet sites, and on 6rd anycast addresses. Mark Townsley 628 advised on how to proceed in IETF. 630 Besides these direct contributions, acknowledgments are due to a few 631 IPv6 confirmed experts who, when the author was still an IPv6 632 newcomer, taught him subtleties of IPv6. Without his past debates 633 with Laurent Toutain, Francis Dupont and Alain Durand, this proposal 634 would probably not have been possible. 636 7. Security Considerations 638 With the specification as is, and provided all recommended behaviors 639 are supported, the author has identified one security risk beyond 640 those that are common to all of IPv6 implementations. It results 641 from possibilities of IPv4 address spoofing: If a 6rd site may 642 receive packets with IPv4 spoofed source addresses, it may also 643 receive, in IPv6 encapsulated packets, IPv6 spoofed source addresses. 645 Since this risk is generally lived with in IPv4, letting higher 646 layers to ensure enough security when necessary, it is expected that 647 it is acceptable in practice. 649 8. IANA Considerations 651 This memo implies a request to IANA for the code of the DHCPv4 6rd 652 option presented of Section 4. 654 9. References 656 9.1. Normative References 658 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 659 September 1981. 661 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 662 RFC 792, September 1981. 664 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 665 November 1990. 667 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 668 RFC 1812, June 1995. 670 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 671 E. Lear, "Address Allocation for Private Internets", 672 BCP 5, RFC 1918, February 1996. 674 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 675 RFC 2131, March 1997. 677 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 678 Extensions", RFC 2132, March 1997. 680 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 681 (IPv6) Specification", RFC 2460, December 1998. 683 [RFC2463] Conta, A. and S. Deering, "Internet Control Message 684 Protocol (ICMPv6) for the Internet Protocol Version 6 685 (IPv6) Specification", RFC 2463, December 1998. 687 [RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for 688 IPv6 Hosts and Routers", RFC 2893, August 2000. 690 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 691 (IPv6) Addressing Architecture", RFC 3513, April 2003. 693 9.2. Informative References 695 [IPv4 addresses] 696 Internet Assigned Numbers Authority, "Internet Protocol v4 697 Address Space - 698 http://www.nro.net/documents/pdf/nro46.pdf", 699 February 2008. 701 [Protocol Numbers] 702 Internet Assigned Numbers Authority, "PROTOCOL NUMBERS - 703 http://www.iana.org/assignments/protocol-numbers", 704 January 2008. 706 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 707 Translator (NAT) Terminology and Considerations", 708 RFC 2663, August 1999. 710 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 711 via IPv4 Clouds", RFC 3056, February 2001. 713 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 714 RFC 3068, June 2001. 716 [RIR Policy] 717 Number resource Organization, "RIR Comparative Policy 718 Overview - 719 http://www.iana.org/assignments/ipv4-address-space", 720 November 2007. 722 Author's Address 724 Remi Despres 725 RD-IPtech 726 3 rue du President Wilson 727 Levallois, 728 France 730 Phone: +33 6 72 74 94 88 731 Email: remi.despres@free.fr 733 Full Copyright Statement 735 Copyright (C) The IETF Trust (2008). 737 This document is subject to the rights, licenses and restrictions 738 contained in BCP 78, and except as set forth therein, the authors 739 retain all their rights. 741 This document and the information contained herein are provided on an 742 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 743 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 744 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 745 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 746 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 747 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 749 Intellectual Property 751 The IETF takes no position regarding the validity or scope of any 752 Intellectual Property Rights or other rights that might be claimed to 753 pertain to the implementation or use of the technology described in 754 this document or the extent to which any license under such rights 755 might or might not be available; nor does it represent that it has 756 made any independent effort to identify any such rights. Information 757 on the procedures with respect to rights in RFC documents can be 758 found in BCP 78 and BCP 79. 760 Copies of IPR disclosures made to the IETF Secretariat and any 761 assurances of licenses to be made available, or the result of an 762 attempt made to obtain a general license or permission for the use of 763 such proprietary rights by implementers or users of this 764 specification can be obtained from the IETF on-line IPR repository at 765 http://www.ietf.org/ipr. 767 The IETF invites any interested party to bring to its attention any 768 copyrights, patents or patent applications, or other proprietary 769 rights that may cover technology that may be required to implement 770 this standard. Please address the information to the IETF at 771 ietf-ipr@ietf.org. 773 Acknowledgment 775 Funding for the RFC Editor function is provided by the IETF 776 Administrative Support Activity (IASA).