idnits 2.17.1 draft-despres-6rd-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 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 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 (April 7, 2009) is 5497 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4291' is defined on line 388, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3068 (Obsoleted by RFC 7526) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 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 April 7, 2009 4 Intended status: Informational 5 Expires: October 9, 2009 7 IPv6 Rapid Deployment on IPv4 infrastructures (6rd) 8 draft-despres-6rd-03 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on October 9, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 IPv6 rapid deployment (6rd) builds upon mechanisms of 6to4 (RFC3056) 47 to enable a service provider to rapidly deploy IPv6 unicast service 48 to IPv4 sites to which it provides customer premise equipment. Like 49 6to4, it utilizes stateless IPv6 in IPv4 encapsulation in order to 50 transit IPv4-only network infrastructure. Unlike 6to4, a 6rd service 51 provider uses an IPv6 prefix of its own in place of the fixed 6to4 52 prefix. A service provider has used this mechanism for its own IPv6 53 "rapid deployment": five weeks from first exposure to 6rd principles 54 to more than 1,500,000 residential sites being provided native IPv6, 55 under the only condition that they activate it. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Problem statement and purpose of 6rd . . . . . . . . . . . . . 5 61 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 6 62 4. Applicability to ISPs that assign private IPv4 addresses . . . 8 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 68 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 1. Introduction 73 After having had a succinct presentation of the 6rd idea, a major 74 French Internet service provider (ISP), Free of the Iliad group, did 75 all of the following in an impressively short delay of only five 76 weeks (November 7th to December 11th 2007): 78 1. obtain its first IPv6 prefix from its regional Internet Registry 79 (RIR), its length being 32 the length that was allocated without 80 a justification and a delay to examine it; 82 2. add 6rd support to the software of its Freebox home-gateway 83 (upgrading for this an available 6to4 code); 85 3. provision PC-compatible platform with a 6to4 gateway software; 87 4. modify it to support 6rd; 89 5. test IPv6 operation with several operating systems and 90 applications; 92 6. finish operational deployment, by means of new downloadable 93 software for Freeboxes; 95 7. announce IPv6 Internet connectivity, at no extra charge, for all 96 its customers wishing to activate it. 98 More than 1,500,000 residential customers thus became able to use 99 IPv6 if they wished to, with all the look and feel of native IPv6 100 addresses routed in IPv6. The only condition was an activation of 101 IPv6 in their Freeboxes, and of course in their IPv6 capable hosts. 103 This story is reported to illustrate that ISPs that provide customer 104 premise equipment to their customers with routing capability (router 105 CPEs), and that have so far postponed IPv6 deployment can, with the 106 dramatically reduced investment and operational costs that 6rd make 107 possible, decide to wait no longer. 109 To complete the story, Free announced, on March 6th 2008, that 110 provided two of its customer sites had IPv6 activated, its Telesites 111 application (Web sites published on TV) could now be used remotely 112 between them. 114 While IPv6 availability was limited in december 2007 to only one IPv6 115 link per customer site (with /64 site prefix assignments), it was 116 upgraded a few months later to up to 16 IPv6 links (with /60 site 117 prefix assignments), after Free had detailed its achievement and 118 plans to its RIR and obtained from it a /26 prefix. 120 Readers are supposed to be familiar with 6to4 [RFC3056]. 122 2. Problem statement and purpose of 6rd 124 Having ISPs to rapidly bring IPv6 to customers sites, in addition to 125 IPv4 and without extra charge, is a way to break the existing vicious 126 circle that has delayed IPv6 deployment: ISPs wait for customer 127 demand before deploying IPv6; customers don't demand IPv6 as long as 128 application vendors announce that their products work on existing 129 infrastructures (that are IPv4 with NATs); application vendors focus 130 their investments on NAT traversal compatibility as long as ISPs 131 don't deploy IPv6. 133 But most ISPs are not willing to add IPv6 to their current offer, at 134 no charge, unless incurred investment and operational costs are 135 extremely limited. For this, ISPs that provide router CPEs to their 136 customers have the most favorable conditions: they can upgrade their 137 router CPEs to support IPv6 encapsulation and operate gateways 138 between these infrastructures and the global IPv6 Internet to also do 139 IPv6/v4 encapsulation, so that they can keep the routing plan of 140 their IPv4 infrastructures. 142 Encapsulation a la 6to4 is very close to be sufficient for this: it 143 is simple; it is supported on many platforms including PC compatible 144 appliances; open-source portable code is available; its stateless 145 nature ensures good scalability. 147 There is however a limitation of 6to4 that prevents ISPs to use it to 148 offer full IPv6 unicast connectivity to their customers. While an 149 ISP that deploys 6to4 can guarantee that IPv6 packets outgoing from 150 its customer sites will reach the IPv6 Internet, and also guarantee 151 that packets coming from other 6to4 sites will reach its customer 152 sites, it cannot guarantee that packets from native IPv6 sites will 153 reach them. A packet coming from a native IPv6 address needs to 154 traverse, somewhere on its way, a 6to4 relay router do the required 155 IPv6/IPv4 encapsuation. The problem is that there is no guarantee to 156 have a route toward such a relay from everywhere, nor is there a 157 guarantee that all such relays do forward packets toward the complete 158 IPv4 Internet. 160 An ISP, if it operates one or several 6to4 relay routers and opens 161 IPv6 routes toward them on the IPv6 Internet for the 6to4 prefix 162 2002::/16, may receive in these relays packets destined to an unknown 163 number of other 6to4 ISPs. If it doesn't forward them, it creates a 164 black hole in which packets may be systematically lost, breaking some 165 of the IPv6 connectivity. If it does forward them, it can no longer 166 dimension its 6to4 relay routers in proportion to the traffic of its 167 own customers. Quality of service, at least for customers of other 168 6to4 ISPs, will then hardly be guaranteed. 170 The purpose of 6rd is to slightly modify 6to4 so that: 172 1. Packets that, coming from the global Internet, enter 6rd gateways 173 of an ISP are only packets destined to customer sites of this 174 ISP. 176 2. All IPv6 packets destined to 6rd customer sites of an ISP, and 177 coming from anywhere else on the IPv6 Internet, traverse a 6rd 178 gateway of this ISP. 180 3. Specification 182 The principle of 6rd is that, to build on 6to4 and suppress its 183 limitation, it is sufficient that: 185 1. 6to4 functions are modified to replace the standard prefix 186 2002::/16 by an IPv6 prefix that belongs to the ISP assigned 187 address space, and to replace the 6to4 anycast address by another 188 anycast address chosen by the ISP. 190 2. The ISP operates one or several 6rd gateways (upgraded 6to4 191 routers) at its border between its IPv4 infrastructure and the 192 IPv6 Internet. 194 3. CPE routers are IPv6 on their customer-site side and support 6rd 195 (upgraded 6to4 function). 197 Figure 1 shows how the IPv6 prefix of a customer site is derived from 198 its IPv4 address. 200 +---------------//-------.------------------------------+ 201 | 6rd-relays IPv6 prefix | IPv4 address | 202 | of the ISP | of the customer site | 203 +---------------//-------'------------------------------+ 204 <-- less or equal to 32 -><------------ 32 -------------> 205 <-- less or equal to 64 -------------------------------> 207 FORMAT OF THE IPV6 PREFIX ASSIGNED TO A 6rd CUSTOMER SITE 209 Figure 1 211 The chosen address format uses 32 bits of IPv4 address within the 212 IPv6 address for reasons of simplicity and of compatibility with the 213 existing 6to4 code. Free's customers being essentially residential, 214 limiting initially their sites to one IPv6 subnet per site was not a 215 significant restriction: most of them would not have been able to use 216 several subnets anyway; as soon as Free would get shorter a prefix 217 than /32, this restriction could be relaxed. 219 IPv4 AND IPv6 customer site 220 | 221 | 6rd CPEs 6rd relays 222 | (modified 6to4) (modified 6to4) 223 | | | 224 | | __________________________ | 225 | | | | | 226 | | | ISP IPV4 INFRASTRUCTURE | V GLOBAL 227 V V | | ___ IPV6 228 ___ | | | | INTERNET 229 | | | | .-----------------|--| |--- 230 |--| |--|-. / | |___| 231 | |___| | \ / | 232 | \ / IPv4 | IPv6 Prefix 233 | O anycast address => | <= of 6rd relays 234 | ___ | / \ of 6rd relays | of the ISP 235 | | | | / \ | ___ 236 |--| |--|-' \ | | | 237 | |___| | '-----------------|--| |--- 238 | | | |___| 239 | IPv4 addresses | 240 | <= of customer sites | 241 |__________________________| 243 ISP ARCHITECTURE TO DEPLOY IPV6 WITH 6rd 245 Figure 2 247 NOTE: If it had been important to use less than 32 bits of IPv4 248 addresses in IPv6 prefixes, this would have been possible. Since 249 Free, like many ISPs, had several RIR allocated IPv4 prefixes (6 of 250 them, having lengths from /10 to /16 in the particular case), 6rd 251 gateways and 6rd CPEs would however have had for this to support a 252 variable length mapping table. Some of the IPv4 addressing entropy 253 would thus have been extended to 6rd gateways and CPEs, and 254 complexity would have been significantly higher. This would have 255 defeated the objective of extreme simplicity to favor actual and 256 rapid deployment. 258 Figure 2 shows which nodes have to be upgraded from 6to4 to 6rd, and 259 which addresses or prefixes have to be routed to them. 261 IPv6 communication between customer sites of a same ISP is direct 262 across the ISP IPv4 infrastructure: when a CPE sees that the IPv6 263 destination address of an outgoing packet starts with its own 6rd 264 relay ISPv6 prefix, it takes the 32 bits that follow this prefix as 265 IPv4 destination of the encapsulating packet. (Sending and 266 decapsulation rules of 6to4, duly adapted to the 6rd prefix in place 267 of the 6to4 prefix, apply as described in [RFC3056] section 5.3.) 269 The IPv4 anycast address of 6rd relays may be chosen independently by 270 each ISP. The only constraint is that routes toward the ISP that are 271 advertised must not include this address. For example, Free took a 272 192.88.99.k address, routed with the same /24 prefix as 6to4 but with 273 k different from 1 to avoid confusion with the 6to4 address of 274 [RFC3068]. Another possibility is to use the anycast address of 6to4 275 and to add, in relays, a test on the IPv6 prefix of the ISP side 276 address. If it is 2002::/16, the packet is 6to4, not 6rd. 278 4. Applicability to ISPs that assign private IPv4 addresses 280 ______________________________ 281 | | 282 | 10.x.x.x/8 private addresses | 283 | <== | 284 <-----| IPv4 Anycast address |-----> 285 | of 6rd relays | 286 6rd-CPEs | ==> | 6rd-relays 287 | | 288 <-----| 0.0.0.0/0 |-----> 289 | : | 290 |______________V_______________| 291 __|__ 292 ISP-supported NAT(s) | | 293 |_____| 294 | 295 V 296 IPv4 public addresses 298 6rd APPLICABILITY TO ISPs THAT ASSIGN IPV4 PRIVATE ADDRESSES 300 Figure 3 302 If an ISP has assigned to customer sites addresses of an IPv4 private 303 space of [RFC1918], typically 10.x.x.x/8 addresses, it can also use 304 6rd to offer IPv6 to these sites. 306 IPv4 packets that contain IPv6 packets don't go to NATs which this 307 ISP needs to operate in its infrastructure: they go directly to 6rd 308 relays because their destination is the 6rd relay anycast address. 310 Note that in this case the 10.0.0.0/8 prefix is common to all IPv4 311 addresses of the addressing realm in which 6rd is used. Knowing it, 312 gateways and CPE can avoid including this constant IPv4 prefix in 313 IPv6 prefixes, and thus reduce to 24 the number of bits of IPv4 314 addresses to be used in IPv6 prefixes. 316 If an ISP is large enough to provide service to more IPv4 endpoints 317 than will fit inside a 10.x.x.x/8 addressing realm, it can configure 318 several such realms, with 6rd-relay IPv6 prefixes specific of each 319 one. Each of these prefixes is the RIR allocated ISP prefix followed 320 by an ISP assigned realm identifier. 322 5. Security Considerations 324 Security considerations for 6to4 are documented in [RFC3964]. With 325 the restriction imposed by 6rd that relays of an ISP deal only with 326 traffic that belongs to that ISP, checks that have to be done become 327 the following: 329 o CPE PACKETS TOWARD THE INTERNET: The IPv6 source must be, and the 330 IPv6 destination must no be, a 6rd address of the site. 332 o RELAY PACKETS TOWARD THE INTERNET: The IPv6 source must be a 6rd 333 address that matches the IPv4 source. The IPv6 destination must 334 not start with the ISP 6rd prefix. 336 o CPE PACKETS FROM THE INTERNET: If the IPv4 source is the 6rd- 337 relays anycast address of the local ISP, the IPv6 source must not 338 be a 6rd address of this ISP. Otherwise, the IPv6 source must be 339 the 6rd address that matches the IPv4 source. 341 o RELAY PACKETS FROM THE INTERNET: The IPv6 source must not be a 6rd 342 address of the ISP. The IPv4 destination must not be multicast, 343 i.e. must not start with 224/3. (Notes: The fact that the IPv6 344 destination starts with the IPv6 prefix of the ISP 6rd relays is 345 ensured by the routing configuration, but may be double-checked. 346 If the IPv4 address extracted from the IPv6 destination doesn't 347 belong to the ISP, the destination CPE should detect that the IPv6 348 destination contains neither its ISP 6rd prefix, if it has one, 349 nor the 6to4 prefix, and should discard the packet.) 351 These precautions being taken, it remains that, where IPv4 address 352 spoofing is possible (IPv4 sites placing unauthorized source 353 addresses in some packets they send), IPv6 address spoofing is also 354 possible. 356 6. IANA Considerations 358 ISPs that provide CPEs to all their customers need no new number 359 assignment by IANA. Their being allocated an IPv6 prefix by their 360 RIR, /32 or shorter, is sufficient. 362 For 6rd to be also used by ISPs that let customers have their own 363 CPEs, means to communicate 6rd parameters to these CPEs are needed. 364 For this, IANA has to eventually be involved." 366 7. Acknowledgements 368 The author warmly acknowledges the major contribution of Rani Assaf 369 to 6rd's proven credibility. He readily appreciated 6rd's potential, 370 and made the daring decision to rapidly implement it and deploy it on 371 Free's operational network. Mark Townsley, Brian Carpenter and 372 Patrick Grossetete have to be thanked for their encouragements and 373 suggestions as to how to proceed in IETF. 375 Acknowledgments are also due to some IPv6 old timers, in particular 376 Laurent Toutain, Francis Dupont and Alain Durand, who, when the 377 author came as a late novice on IPV6, taught him a few subtleties of 378 the subject. Without them, designing 6rd would probably not have 379 been possible. 381 8. References 383 8.1. Normative References 385 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 386 via IPv4 Clouds", RFC 3056, February 2001. 388 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 389 Architecture", RFC 4291, February 2006. 391 8.2. Informative References 393 [IPv4 addresses] 394 Internet Assigned Numbers Authority, "Internet Protocol v4 395 Address Space - http://www.iana.org/assignments/ 396 ipv4-address-space/ipv4-address-space.xhtml", 397 February 2008. 399 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 400 E. Lear, "Address Allocation for Private Internets", 401 BCP 5, RFC 1918, February 1996. 403 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 404 RFC 3068, June 2001. 406 [RFC3964] Savola, P. and C. Patel, "Security Considerations for 407 6to4", RFC 3964, December 2004. 409 Author's Address 411 Remi Despres 412 3 rue du President Wilson 413 Levallois, 414 France 416 Phone: +33 6 72 74 94 88 417 Email: remi.despres@free.fr