idnits 2.17.1 draft-ietf-ngtrans-6to4-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 21 longer pages, the longest (page 1) being 64 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 20 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 483 has weird spacing: '...ly from speci...' == Line 756 has weird spacing: '... offers the s...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (June 2000) is 8715 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 186, but not defined == Missing Reference: 'IPv6' is mentioned on line 325, but not defined == Unused Reference: 'AARCH' is defined on line 904, but no explicit reference was found in the text == Unused Reference: 'API' is defined on line 910, but no explicit reference was found in the text == Unused Reference: 'RFC 2119' is defined on line 947, but no explicit reference was found in the text == Unused Reference: 'RFC 2283' is defined on line 950, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2373 (ref. 'AARCH') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2374 (ref. 'AGGR') (Obsoleted by RFC 3587) ** Obsolete normative reference: RFC 2553 (ref. 'API') (Obsoleted by RFC 3493) ** Obsolete normative reference: RFC 2462 (ref. 'CONF') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2461 (ref. 'DISC') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) == Outdated reference: A later version (-02) exists of draft-ietf-ipngwg-resv-anycast-01 -- No information found for draft-ietf-ipngwg-default-addr-select - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SELECT' == Outdated reference: A later version (-07) exists of draft-ietf-nat-rsip-protocol-03 ** Downref: Normative reference to an Experimental draft: draft-ietf-nat-rsip-protocol (ref. 'RSIP') ** Obsolete normative reference: RFC 2283 (Obsoleted by RFC 2858) Summary: 14 errors (**), 0 flaws (~~), 16 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF B. Carpenter 2 Internet Draft K. Moore 3 June 2000 5 Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels 7 Copyright Notice 9 Placeholder for ISOC copyright. 11 Abstract 13 draft-ietf-ngtrans-6to4-06.txt 15 This memo specifies an optional mechanism for assigning a unique 16 IPv6 address prefix to any site that currently has at least one 17 globally unique IPv4 address, and describes scenarios for using such 18 a prefix during the co-existence phase of IPv4 to IPv6 transition. 19 Effectively it treats the IPv4 network as a unicast link layer. Note 20 that this is not considered to be a long term solution and that sites 21 should migrate in due course to native IPv6 prefixes. 23 The motivation for this method is to allow isolated IPv6 domains or 24 hosts, attached to an IPv4 network which has no native IPv6 support, 25 to communicate with other such IPv6 domains or hosts with minimal 26 manual configuration. It also automatically provides a globally 27 unique IPv6 address prefix to any site with at least one globally 28 unique IPv4 address, even if combined with an IPv4 Network Address 29 Translator (NAT). 31 Status of this Memo 33 This document is an Internet-Draft and is in full conformance with 34 all provisions of Section 10 of RFC2026. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that 38 other groups may also distribute working documents as Internet- 39 Drafts. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet- Drafts as reference 44 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/ietf/1id-abstracts.txt 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html. 52 Table of Contents: 54 Status of this Memo.............................................1 55 0. Changes and Issues (RFC Editor: please remove before publication)3 56 1. Introduction.................................................4 57 1.1. Terminology................................................4 58 2. IPv6 Prefix Allocation.......................................5 59 2.1 Address Selection...........................................6 60 3. Encapsulation in IPv4........................................6 61 3.1. Link-Local Address and NUD.................................7 62 4. Maximum Transmission Unit....................................7 63 5. Unicast scenarios, scaling, and transition to normal prefixes8 64 5.1 Simple scenario - all sites work the same...................8 65 5.2 Mixed scenario with relay to native IPv6....................9 66 5.2.1 Variant scenario with ISP relay..........................11 67 5.2.2 Summary of relay router configuration....................12 68 5.2.2.1. BGP4+ not used........................................12 69 5.2.2.2. BGP4+ used............................................12 70 5.2.2.3. Relay router scaling..................................13 71 5.2.3 Unwilling to relay.......................................13 72 5.3 Variant scenario with tunnel to IPv6 space.................13 73 5.4 Fragmented Scenarios.......................................13 74 5.5 Multihoming................................................15 75 5.6 Transition considerations..................................15 76 5.7 Coexistence with firewall, NAT or RSIP.....................15 77 5.8 Usage within Intranets.....................................16 78 5.9 Summary of impact on routing...............................16 79 5.10. Routing loop prevention..................................17 80 6. Multicast and Anycast.......................................17 81 7. ICMP messages...............................................17 82 8. IANA considerations.........................................18 83 9. Security considerations.....................................18 84 Acknowledgements...............................................18 85 References.....................................................20 86 Authors' Addresses.............................................21 87 Intellectual Property..........................................21 88 Full Copyright Statement.......................................21 90 0. Changes and Issues (RFC Editor: please remove before publication) 92 Changes from 05 to 06 version: 94 - wording clarification in section 5.2, clause 2.2 95 - typographical errors corrected 97 Changes from 04 to 05 version: 99 - text on multicast largely removed (awaiting separate draft) 100 - noted that relay routers only accept traffic from specific sites 101 - clarified that V4ADDR must be configured on an IPv4 interface 102 - link-local text rewritten 103 - added note on NUD 104 - strengthened security text on address filtering 105 - general text clarifications and response to detail comments 107 Changes from 03 to 04 version: 109 - added terminology section 110 - another revision of the address selection text 111 - described link-local address formation 112 - changed sending rule to refer to next hop 113 - removed confusing text on IPv4 header padding 114 - clarification/corrections to exterior routing discussion 115 - clarified MTU text again 116 - added section on routing loops 117 - added and removed text on multicast 118 - added text on RSIP 119 - reformulated section on Intranet usage 120 - general text clarifications and response to detail comments 122 Changes from 02 to 03 version: 124 - changed to officially assigned TLA value 125 - sections of text re-ordered for clarity 126 - "do not fragment" is now SHOULD NOT (adopting the decision 127 reached for 6over4) 128 - new version of address selection text 129 - bogus MTU text deleted 130 - a few additional scenarios and pictures added 131 - general text clarifications and response to detail comments 133 Changes from 01 to 02 version: 135 - added some pictures 136 - added sub-section on relay via ISP 137 - added scenario on usage with configured tunnels 138 - improved discussion of routing 139 - improved and moved discussion of multicast 140 - added section on relay router config 141 - added note on incongruent routing 142 - minor fixes 144 1. Introduction 146 This memo specifies an optional mechanism for assigning a unique IPv6 147 address prefix to any site that currently has at least one globally 148 unique IPv4 address, and specifies an encapsulation mechanism for 149 transmitting IPv6 packets using such a prefix over the global IPv4 150 network. Effectively it treats the wide area IPv4 network as a 151 unicast point-to-point link layer.It also describes scenarios for 152 using such prefixes during the co-existence phase of IPv4 to IPv6 153 transition. Note that these scenarios are only part of the total 154 picture of transition to IPv6. Also note that this is not considered 155 to be a long term solution and that sites should migrate in due 156 course to native IPv6 prefixes. 158 Although the mechanism is specified for an IPv6 site, it can equally 159 be applied to an individual IPv6 host, as long as it has at least one 160 globally unique IPv4 address. 162 The motivation for this method is to allow isolated IPv6 sites or 163 hosts, attached to a wide area network which has no native IPv6 164 support, to communicate with other such IPv6 domains or hosts with 165 minimal manual configuration. 167 IPv6 sites or hosts connected using this method do not require IPv4- 168 compatible IPv6 addresses [MECH] or configured tunnels. In this way 169 IPv6 gains considerable independence of the underlying wide area 170 network and can step over many hops of IPv4 subnets. The abbreviated 171 name of this mechanism is 6to4 (not to be confused with [6OVER4]). 172 The 6to4 mechanism is typically implemented almost entirely in border 173 routers, without specific host modifications except a suggested 174 address selection default. Only a modest amount of router 175 configuration is required. 177 Sections 2 to 4 of this document specify the 6to4 scheme technically. 178 Section 5 discusses some, but not all, usage scenarios, including 179 routing aspects, for 6to4 sites. Scenarios for isolated 6to4 hosts 180 are not discussed in this document. Sections 6 to 9 discuss other 181 general considerations. 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in [RFC2119]. 187 1.1. Terminology 189 The terminology of [IPV6] applies to this document. 191 6to4 pseudo-interface. 6to4 encapsulation of IPv6 packets inside IPv4 192 packets occurs at a point that is logically equivalent to an IPv6 193 interface, with the link layer being the IPv4 unicast network. This 194 point is referred to as a pseudo-interface. Some implementors may 195 treat it exactly like any other interface and others may treat it 196 like a tunnel end-point. 198 6to4 prefix: an IPv6 prefix constructed according to the rule in 199 Section 2 below. 201 6to4 address: an IPv6 address constructed using a 6to4 prefix. 203 Native IPv6 address: an IPv6 address constructed using another type 204 of prefix than 6to4. 206 6to4 router: an IPv6 router supporting a 6to4 pseudo-interface. It is 207 normally the border router between an IPv6 site and a wide-area IPv4 208 network. 210 6to4 host: an IPv6 host which happens to have at least one 6to4 211 address. In all other respects it is a standard IPv6 host. 213 Note: an IPv6 node may in some cases use a 6to4 address for a 214 configured tunnel. Such a node may function as an IPv6 host using a 215 6to4 address on its configured tunnel interface, and it may also 216 serve as a IPv6 router for other hosts via a 6to4 pseudo-interface, 217 but these are distinct functions. 219 6to4 site: a site running IPv6 internally using 6to4 addresses, 220 therefore containing at least one 6to4 host and at least one 6to4 221 router. 223 Relay router: a 6to4 router configured to support transit routing 224 between 6to4 addresses and native IPv6 addresses. 226 6to4 exterior routing domain: a routing domain interconnecting a set 227 of 6to4 routers and relay routers. It is distinct from an IPv6 site's 228 interior routing domain, and distinct from all native IPv6 exterior 229 routing domains. 231 2. IPv6 Prefix Allocation 233 Suppose that a subscriber site has at least one valid, globally 234 unique 32-bit IPv4 address, referred to in this document as V4ADDR. 235 This address MUST be duly allocated to the site by an address 236 registry (possibly via a service provider) and it MUST NOT be a 237 private address [RFC 1918]. 239 The IANA has permanently assigned one 13-bit IPv6 Top Level 240 Aggregator (TLA) identifier under the IPv6 Format Prefix 001 [AARCH, 241 AGGR] for the 6to4 scheme.Its numeric value is 0x0002, i.e., it is 242 2002::/16 when expressed as an IPv6 address prefix. 244 The subscriber site is then deemed to have the following IPv6 address 245 prefix, without any further assignment procedures being necessary: 246 Prefix length: 48 bits 247 Format prefix: 001 248 TLA value: 0x0002 249 NLA value: V4ADDR 251 This is illustrated as follows: 253 | 3 | 13 | 32 | 16 | 64 bits | 254 +---+------+-----------+--------+--------------------------------+ 255 |FP | TLA | V4ADDR | SLA ID | Interface ID | 256 |001|0x0002| | | | 257 +---+------+-----------+--------+--------------------------------+ 259 Thus, this prefix has exactly the same format as normal prefixes 260 assigned according to [AGGR]. Within the subscriber site it can be 261 used exactly like any other valid IPv6 prefix, e.g., for automated 262 address assignment and discovery according to the normal mechanisms 263 such as [CONF, DISC], for native IPv6 routing, or for the "6over4" 264 mechanism [6OVER4]. 266 2.1 Address Selection 268 To ensure the correct operation of 6to4 in complex topologies, source 269 and destination address selection must be appropriately implemented. 270 If the source IPv6 host sending a packet has at least one 2002:: 271 address assigned to it, and if the set of IPv6 addresses returned by 272 the DNS for the destination host contains at least one 2002:: 273 address, then the source host must make an appropriate choice of the 274 source and destination addresses to be used. The mechanisms for 275 address selection in general are under study at the time of writing 276 [SELECT]. Subject to those general mechanisms, the principle that 277 will normally allow correct operation of 6to4 is this: 279 If one host has only a 6to4 address, and the other one has both a 280 6to4 and a native IPv6 address, then the 6to4 address should be used 281 for both. 283 If both hosts have a 6to4 address and a native IPv6 address, then 284 either the 6to4 address should be used for both, or the native IPv6 285 address should be used for both. The choice should be configurable. 286 The default configuration should be native IPv6 for both. 288 3. Encapsulation in IPv4 290 IPv6 packets from a 6to4 site are encapsulated in IPv4 packets when 291 they leave the site via its external IPv4 connection. Note that the 292 IPv4 interface that is carrying the 6to4 traffic is notionally 293 equivalent to an IPv6 interface, and is referred to below as a 294 pseudo-interface, although this phrase is not intended to define an 295 implementation technique. V4ADDR MUST be configured on the IPv4 296 interface. 298 IPv6 packets are transmitted in IPv4 packets [RFC 791] with an IPv4 299 protocol type of 41, the same as has been assigned [MECH] for IPv6 300 packets that are tunneled inside of IPv4 frames. The IPv4 header 301 contains the Destination and Source IPv4 addresses. One or both of 302 these will be identical to the V4ADDR field of an IPv6 prefix formed 303 as specified above (see section 5 for more details). The IPv4 packet 304 body contains the IPv6 header and payload. 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 |Version| IHL |Type of Service| Total Length | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Identification |Flags| Fragment Offset | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Time to Live | Protocol 41 | Header Checksum | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Source Address | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Destination Address | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Options | Padding | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | IPv6 header and payload ... / 322 +-------+-------+-------+-------+-------+------+------+ 324 The IPv4 Time to Live will be set as normal [RFC 791], as will the 325 encapsulated IPv6 hop limit [IPv6]. Other considerations are as 326 described in Section 4.1.2 of [MECH]. 328 3.1. Link-Local Address and NUD 330 The link-local address of a 6to4 pseudo-interface performing 6to4 331 encapsulation would, if needed, be formed as described in Section 3.7 332 of [MECH]. However, no scenario is known in which such an address 333 would be useful, since a peer 6to4 gateway cannot determine the 334 appropriate link-layer (IPv4) address to send to. 336 Neighbor Unreachability Detection (NUD) is handled as described in 337 Section 3.8 of [MECH]. 339 4. Maximum Transmission Unit 341 MTU size considerations are as described for tunnels in [MECH]. 343 If the IPv6 MTU size proves to be too large for some intermediate 344 IPv4 subnet, IPv4 fragmentation will ensue. While undesirable, this 345 is not necessarily disastrous, unless the fragments are delivered to 346 different IPv4 destinations due to some form of IPv4 anycast. The 347 IPv4 "do not fragment" bit SHOULD NOT be set in the encapsulating 348 IPv4 header. 350 5. Unicast scenarios, scaling, and transition to normal prefixes 352 5.1 Simple scenario - all sites work the same 354 The simplest deployment scenario for 6to4 is to use it between a 355 number of sites, each of which has at least one connection to a 356 shared IPv4 Internet. This could be the global Internet, or it could 357 be a corporate IP network. In the case of the global Internet, there 358 is no requirement that the sites all connect to the same Internet 359 service provider. The only requiremement is that any of the sites is 360 able to send IPv4 packets with protocol type 41 to any of the others. 361 By definition, each site has an IPv6 prefix in the format defined in 362 Section 2. It will therefore create DNS records for these addresses. 363 For example, site A which owns IPv4 address 192.1.2.3 will create DNS 364 records with the IPv6 prefix {FP=001,TLA=0x0002,NLA=192.1.2.3}/48. 365 Site B which owns address 9.254.253.252 will create DNS records with 366 the IPv6 prefix {FP=001,TLA=0x0002,NLA=9.254.253.252}/48. 368 When an IPv6 host on site B queries the DNS entry for a host on site 369 A, or otherwise obtains its address, it obtains an address with the 370 prefix {FP=001,TLA=0x0002,NLA=192.1.2.3}/48 and whatever SLA and 371 Interface ID applies. The converse applies when a host on site A 372 queries the DNS for a host on site B. IPv6 packets are formed and 373 transmitted in the normal way within both sites. 374 _______________________________ 375 | | 376 | Wide Area IPv4 Network | 377 |_______________________________| 378 / \ 379 192.1.2.3/ 9.254.253.252\ 380 _______________________________/_ ____________________\____________ 381 | / | | \ | 382 |IPv4 Site A ########## | |IPv4 Site B ########## | 383 | ____________________# 6to4 #_ | | ____________________# 6to4 #_ | 384 || # router # || || # router # || 385 ||IPv6 Site A ########## || ||IPv6 Site B ########## || 386 ||2002:c001:0203::/48 || ||2002:09fe:fdfc::/48 || 387 ||_______________________________|| ||_______________________________|| 388 | | | | 389 |_________________________________| |_________________________________| 391 Within a 6to4 site, the 2002::/16 prefix will normally be handled as 392 a default route towards the 6to4 border router. The only change to 393 standard IPv6 routing is that the 6to4 router on each 6to4 site MUST 394 include the following sending rule. Note that this rule refers to the 395 next IPv6 hop that the packet will be sent to, which is not 396 necessarily the final destination address. 398 SENDING RULE 400 if the next hop IPv6 address for an IPv6 packet is non-local 401 and its prefix is 2002::/16 402 then 403 apply any security checks (see Section 8); 404 encapsulate the packet in IPv4 as in Section 3, 405 with IPv4 destination address = the NLA value V4ADDR 406 from the next hop IPv6 address; 407 queue the packet for IPv4 forwarding. 409 A simple decapsulation rule for incoming IPv4 packets with protocol 410 type 41 MUST be implemented: 412 DECAPSULATION RULE 414 apply any security checks (see Section 8); 415 remove the IPv4 header; 416 submit the packet to local IPv6 routing. 418 In this scenario, no IPv4 routing information is imported into IPv6 419 routing (nor vice versa). The above special sending rule is the only 420 contamination of IPv6 forwarding, and it occurs only at border 421 routers. 423 In this scenario, any number of 6to4 sites can interoperate with no 424 tunnel configuration, and no special requirements from the IPv4 425 service. All that is required is the appropriate DNS entries and the 426 special sending rule configured in the 6to4 router. This router 427 SHOULD also generate the appropriate IPv6 prefix announcements [CONF, 428 DISC]. 430 Although site A and site B will each need to run IPv6 routing 431 internally, they do not need to run an IPv6 exterior routing protocol 432 in this simple scenario; IPv4 exterior routing does the job for them. 434 It is RECOMMENDED that in any case each site should use only one IPv4 435 address per 6to4 router, and that should be the address assigned to 436 the external interface of the 6to4 router. Single-homed sites 437 therefore SHOULD use only one IPv4 address for 6to4 routing. Multi- 438 homed sites are discused in section 5.3. 440 Because of the lack of configuration, and the distributed deployment 441 model, there are believed to be no particular scaling issues with the 442 basic 6to4 mechanism apart from encapsulation overhead. 443 Specifically, it introduces no new entries in IPv4 routing tables. 445 5.2 Mixed scenario with relay to native IPv6 447 During the transition to IPv6 we can expect some sites to fit the 448 model just described (isolated sites whose only connectivity is the 449 IPv4 Internet), whereas others will be part of larger islands of 450 native or tunnelled IPv6 using normal IPv6 TLA address space. The 451 6to4 sites will need connectivity to these native IPv6 islands and 452 vice versa. In the 6to4 model, this connectivity is accomplished by 453 IPv6 routers which support both 6to4 and native IPv6 addresses. 455 Although they behave essentially as standard IPv6 routers, for the 456 purposes of this document they are referred to as relay routers to 457 distinguish them from routers supporting only 6to4, or only native 458 IPv6. 460 There must be at least one router acting as a relay between the 6to4 461 domain and a given native IPv6 domain. There is nothing special 462 about it; it is simply a normal router which happens to have at least 463 one logical 6to4 pseudo-interface and at least one other IPv6 464 interface. 466 We now have three distinct classes of routing domain to consider: 468 1. the internal IPv6 routing domain of each 6to4 site; 469 2. an exterior IPv6 routing domain interconnecting 470 a given set of 6to4 border routers, including relay routers, 471 among themselves, i.e. a 6to4 exterior routing domain; 472 3. the exterior IPv6 routing domain of each native IPv6 island. 474 1. The internal routing domain of a 6to4 site behaves as described in 475 section 5.1. 477 2. There are two deployment options for a 6to4 exterior routing 478 domain: 480 2.1 No IPv6 exterior routing protocol is used. The 6to4 routers using 481 a given relay router each have a default IPv6 route pointing to the 482 relay router. The relay router MAY apply source address based filters 483 to accept traffic only from specific 6to4 routers. 485 2.2 An IPv6 exterior routing protocol is used. The set of 6to4 486 routers using a given relay router obtain native IPv6 routes from the 487 relay router using a routing protocol such as BGP4+ [RFC 2283, 488 BGP4+]. The relay router will advertise whatever native IPv6 routing 489 prefixes are appropriate on its 6to4 pseudo-interface. These prefixes 490 will indicate the regions of native IPv6 topology that the relay 491 router is willing to relay to. Their choice is a matter of routing 492 policy. It is necessary for network operators to carefully consider 493 desirable traffic patterns and topology when choosing the scope of 494 such routing advertisements. The relay router will establish BGP 495 peering only with specific 6to4 routers whose traffic it is willing 496 to accept. 498 Although this solution is more complex, it provides effective policy 499 control, i.e. BGP4+ policy determines which 6to4 routers are able to 500 use which relay router. 502 3. A relay router MUST advertise a route to 2002::/16 into the native 503 IPv6 exterior routing domain. It is a matter of routing policy how 504 far this routing advertisement of 2002::/16 is propagated in the 505 native IPv6 routing system. Since there will in general be multiple 506 relay routers advertising it, network operators will require to 507 filter it in a managed way. Incorrect policy in this area will lead 508 to potential unreachability or to perverse traffic patterns. 510 A 6to4 site which also has a native IPv6 connection MUST NOT 511 advertise its 2002::/48 routing prefix on that connection, and IPv6 512 network operators MUST filter out and discard any 2002:: routing 513 prefix advertisements longer than /16. 515 Sites which have at least one native IPv6 connection, in addition to 516 a 6to4 connection, will therefore have at least one IPv6 prefix which 517 is not a 2002:: prefix. Such sites' DNS entries will reflect this and 518 DNS lookups will return multiple addresses. If two such sites need 519 to interoperate, whether the 6to4 route or the native route will be 520 used depends on IPv6 address selection by the individual hosts (or 521 even applications). 523 Now consider again the example of the previous section. Suppose an 524 IPv6 host on site B queries the DNS entry for a host on site A, and 525 the DNS returns multiple IPv6 addresses with different prefixes. 527 ____________________________ ______________________ 528 | | | | 529 | Wide Area IPv4 Network | | Native IPv6 | 530 | | | Wide Area Network | 531 |____________________________| |______________________| 532 / \ // 533 192.1.2.3/ 9.254.253.252\ // 2001:0600::/48 534 ____________/_ ____________________\_________//_ 535 / | | \ // | 536 ########## | |IPv4 Site B ########## | 537 __# 6to4 #_ | | ____________________# 6to4 #_ | 538 # router # || || # router # || 539 ########## || ||IPv6 Site B ########## || 540 || ||2002:09fe:fdfc::/48 || 541 __Site A_____|| ||2001:0600::/48_________________|| 542 as before | | | 543 ______________| |_________________________________| 545 If the host picks the 6to4 prefix according to some rule for multiple 546 prefixes, it will simply send packets to an IPv6 address formed with 547 the prefix {FP=001,TLA=0x0002,NLA=192.1.2.3}/48. It is essential that 548 they are sourced from the prefix 549 {FP=001,TLA=0x0002,NLA=9.254.253.252}/48 for two-way connectivity to 550 be possible. The address selection mechanism of Section 2.1 will 551 ensure this. 553 5.2.1 Variant scenario with ISP relay 555 The previous scenario assumes that the relay router is provided by a 556 cooperative 6to4 user site. A variant of this is for an Internet 557 Service Provider, that already offers native IPv6 connectivity, to 558 operate a relay router. Technically this is no different from the 559 previous scenario; site B is simply an internal 6to4 site of the ISP, 560 possibly containing only one system, i.e. the relay router itself. 562 5.2.2 Summary of relay router configuration 564 A relay router participates in IPv6 unicast routing protocols on its 565 native IPv6 interface and may do so on its 6to4 pseudo-interface, but 566 these are independent routing domains with separate policies, even if 567 the same protocol, probably BGP4+, is used in both cases. 569 A relay router also participates in IPv4 unicast routing protocols on 570 its IPv4 interface used to support 6to4, but this is not further 571 discussed here. 573 On its native IPv6 interface, the relay router MUST advertise a route 574 to 2002::/16. It MUST NOT advertise a longer 2002:: routing prefix on 575 that interface. Routing policy within the native IPv6 routing domain 576 determines the scope of that advertisement, thereby limiting the 577 visibility of the relay router in that domain. 579 IPv6 packets received by the relay router whose next hop IPv6 address 580 matches 2002::/16 will be routed to its 6to4 pseudo-interface and 581 treated according to the sending rule of Section 51. 583 5.2.2.1. BGP4+ not used 585 If BGP4+ is not deployed in the 6to4 exterior routing domain (option 586 2.1 of Section 5.2), the relay router will be configured to accept 587 and relay all IPv6 traffic only from its client 6to4 sites. Each 588 6to4 router served by the relay router will be configured with a 589 default IPv6 route to the relay router (for example, Site A's default 590 IPv6 route ::/0 would point to 2002:09fe:fdfc::/48). 592 5.2.2.2. BGP4+ used 594 If BGP4+ is deployed in the 6to4 exterior routing domain (option 2.2 595 of Section 5.2), the relay router advertises IPv6 native routing 596 prefixes on its 6to4 pseudo-interface, peering only with the 6to4 597 routers that it serves. (An alternative is that these routes could 598 be advertised along with IPv4 routes using BGP4 over IPv4, rather 599 than by running a separate BGP4+ session.) The specific routes 600 advertised depend on applicable routing policy, but they must be 601 chosen from among those reachable through the relay router's native 602 IPv6 interface. In the simplest case, a default route to the whole 603 IPv6 address space could be advertised. When multiple relay routers 604 are in use, more specific routing prefixes would be advertised 605 according to the desired routing policy. The usage of BGP4+ is 606 completely standard so is not discussed further in this document. 608 5.2.2.3. Relay router scaling 610 Relay routers introduce the potential for scaling issues. In general 611 a relay router should not attempt to serve more sites than any other 612 transit router, allowing for the encapsulation overhead. 614 5.2.3 Unwilling to relay 616 It may arise that a site has a router with both 6to4 pseudo- 617 interfaces and native IPv6 interfaces, but is unwilling to act as a 618 relay router. Such a site MUST NOT advertise any 2002:: routing 619 prefix into the native IPv6 domain and MUST NOT advertise any native 620 IPv6 routing prefixes or a default IPv6 route into the 6to4 domain. 621 Within the 6to4 domain it will behave exactly as in the basic 6to4 622 scenario of Section 5.1. 624 5.3 Variant scenario with tunnel to IPv6 space 626 A 6to4 site which has no IPv6 connections to the "native" IPv6 627 Internet can acquire effective connectivity to the v6 Internet via a 628 "configured tunnel" (using the terminology in [MECH]) to a 629 cooperating router which does have IPv6 access, but which does not 630 need to be a 6to4 router. Such tunnels could be autoconfigured using 631 an IPv4 anycast address, but this is outside of the scope of this 632 document. Alternatively a tunnel broker can be used. This scenario 633 would be suitable for a small user-managed site. 635 These mechanisms are not described in detail in this document. 637 5.4 Fragmented Scenarios 639 If there are multiple relay routers between native IPv6 and the 6to4 640 world, different parts of the 6to4 world will be served by different 641 relays. The only complexity that this introduces is in the scoping of 642 2002::/16 routing advertisements within the native IPv6 world. Like 643 any BGP4+ advertisements, their scope must be correctly defined by 644 routing policy to ensure that traffic to 2002::/16 follows the 645 intended paths. 647 If there are multiple IPv6 stubs all interconnected by 6to4 through 648 the global IPv4 Internet, this is a simple generalisation of the 649 basic scenarios of sections 5.1. and 5.2 and no new issues arise. 650 This is shown in the following figure. Subject to consistent 651 configuration of routing advertisements, there are no known issues 652 with this scenario. 654 ______________ 655 | AS3 | 656 |_IPv6 Network_| Both AS1 and AS2 advertise 657 | AS1 | AS2 | 2002::/16, but only one of 658 |______|_______| them reaches AS3. 659 // \\ 660 __________//_ _\\__________ ______________ 661 | 6to4 Relay1 | | 6to4 Relay2 | | IPv6 Network | 662 |_____________| |_____________| | AS4 | 663 | | |______________| 664 ________|______________________|________ | 665 | | ______|______ 666 | Global IPv4 Network |-----| 6to4 Relay3 | 667 |________________________________________| |_____________| 668 | | | | 669 ____|___ ___|____ ____|___ ___|____ 670 | 6to4 | | 6to4 | | 6to4 | | 6to4 | 671 | Site A | | Site B | | Site C | | Site D | 672 |________| |________| |________| |________| 674 If multiple IPv6 stubs are interconnected through multiple, disjoint 675 IPv4 networks (i.e. a fragmented IPv4 world) then the 6to4 world is 676 also fragmented; this is the one scenario that must be avoided. It 677 is illustrated below to show why it does not work, since the 678 2002::/16 advertisement from Relay1 will be invisible to Relay2, and 679 vice versa. Sites A and B therefore have no connectivity to sites C 680 and D. 681 ______________ 682 | AS3 | 683 |_IPv6 Network_| Both AS1 and AS2 advertise 684 | AS1 | AS2 | 2002::/16, but sites A and B 685 |______|_______| cannot reach C and D. 686 // \\ 687 __________//_ _\\__________ 688 | 6to4 Relay1 | | 6to4 Relay2 | 689 |_____________| |_____________| 690 | | 691 ________|_______ _______|________ 692 | IPv4 Network | | IPv4 Network | 693 | Segment 1 | | Segment 2 | 694 |________________| |________________| 695 | | | | 696 ____|___ ___|____ ____|___ ___|____ 697 | 6to4 | | 6to4 | | 6to4 | | 6to4 | 698 | Site A | | Site B | | Site C | | Site D | 699 |________| |________| |________| |________| 701 5.5 Multihoming 703 Sites which are multihomed on IPv4 MAY extend the 6to4 scenario by 704 using a 2002:: prefix for each IPv4 border router, thereby 705 automatically obtaining a degree of IPv6 multihoming. 707 5.6 Transition considerations 709 If the above rules for routing advertisements and address selection 710 are followed, then a site can migrate from using 6to4 to using native 711 IPv6 connections over a long period of co-existence, with no need to 712 stop 6to4 until it has ceased to be used. The stages involved are 714 1. Run IPv6 on site using any suitable implementation. True 715 native IPv6, [6OVER4], or tunnels are all acceptable. 717 2. Configure a border router (or router plus IPv4 NAT) 718 connected to the external IPv4 network to support 6to4, 719 including advertising the appropriate 2002:: routing prefix locally. 720 Configure IPv6 DNS entries using this prefix. At this point 721 the 6to4 mechanism is automatically available, and the site 722 has obtained a "free" IPv6 prefix. 724 3. Identify a 6to4 relay router willing to relay the site's 725 traffic to the native IPv6 world. This could either be at 726 another cooperative 6to4 site, or an ISP service. If no exterior 727 routing protocol is in use in the 6to4 exterior routing domain, 728 the site's 6to4 router will be configured with a default IPv6 729 route pointing to that relay router's 6to4 address. If an exterior 730 routing protocol such as BGP4+ is in use, the site's 6to4 router 731 will be configured to establish appropriate BGP peerings. 733 4. When native external IPv6 connectivity becomes available, 734 add a second (native) IPv6 prefix to both the border router 735 configuration and the DNS configuration. At this point, an 736 address selection rule will determine when 6to4 and when 737 native IPv6 will be used. 739 5. When 6to4 usage is determined to have ceased (which may 740 be several years later), remove the 6to4 configuration. 742 5.7 Coexistence with firewall, NAT or RSIP 744 The 6to4 mechanisms appear to be unaffected by the presence of a 745 firewall at the border router. 747 If the site concerned has very limited global IPv4 address space, and 748 is running an IPv4 network address translator (NAT), all of the above 749 mechanisms remain valid. The NAT box must also contain a fully 750 functional IPv6 router including the 6to4 mechanism. The address used 751 for V4ADDR will simply be a globally unique IPv4 address allocated to 752 the NAT. In the example of Section 5.1 above, the 6to4 routers would 753 also be the sites' IPv4 NATs, which would own the globally unique 754 IPv4 addresses 192.1.2.3 and 9.254.253.252. 756 Combining a 6to4 router with an IPv4 NAT in this way offers the site 757 concerned a globally unique IPv6 /48 prefix, automatically, behind 758 the IPv4 address of the NAT. Thus every host behind the NAT can 759 become an IPv6 host with no need for additional address space 760 allocation, and no intervention by the Internet service provider. No 761 address translation is needed by these IPv6 hosts. 763 A more complex situation arises if a host is more than one NAT hop 764 away from the globally unique IPv4 address space. This document does 765 not address this situation in detail. However, it can certainly be 766 handled by administrative sub-allocation of the 2002: prefix 767 constructed from the global IPv4 address of the outermost NAT. 769 The Realm-Specific IP (RSIP) mechanism [RSIP] can also co-exist with 770 6to4. If a 6to4 border router is combined with an RSIP border router, 771 it can support IPv6 hosts using 6to4 addresses, IPv4 hosts using 772 RSIP, or dual stack hosts using both. The RSIP function provides 773 fine-grained management of dynamic global IPv4 address allocation and 774 the 6to4 function provides a stable IPv6 global address to each host. 775 As with NAT, the IPv4 address used to construct the site's 2002: 776 prefix will be one of the global addresses of the RSIP border router. 778 5.8 Usage within Intranets 780 There is nothing to stop the above scenario being deployed within a 781 private corporate network as part of its internal transition to IPv6; 782 the corporate IPv4 backbone would serve as the virtual link layer for 783 individual corporate sites using 2002:: prefixes. The V4ADDR MUST be 784 a duly allocated global IPv4 address, which MUST be unique within the 785 private network. The Intranet thereby obtains globally unique IPv6 786 addresses even if it is internally using private IPv4 addresses [RFC 787 1918]. 789 5.9 Summary of impact on routing 791 IGP (site) routing will treat the local site's 2002::/48 prefix 792 exactly like a native IPv6 site prefix assigned to the local site. 793 There will also be an IGP route to the generic 2002::/16 prefix, 794 which will be a route to the site's 6to4 router, unless this is 795 handled as a default route. 797 EGP (i.e. BGP) routing will include advertisements for the 2002::/16 798 prefix from relay routers into the native IPv6 domain, whose scope is 799 limited by routing policy. This is the only non-native IPv6 prefix 800 advertised by BGP. 802 It will be necessary for 6to4 routers to obtain routes to relay 803 routers in order to access the native IPv6 domain. In the simplest 804 case there will be a manually configured default IPv6 route to 805 {FP=001,TLA=0x0002,NLA=V4ADDR}/48, where V4ADDR is the IPv4 address 806 of a relay router. Such a route could be used to establish a BGP 807 session for the exchange of additional IPv6 routes. 809 By construction, unicast IPv6 traffic within a 6to4 domain will 810 follow exactly the same path as unicast IPv4 traffic. 812 5.10. Routing loop prevention 814 Since 6to4 has no impact on IPv4 routing, it cannot induce routing 815 loops in IPv4. Since 2002: prefixes behave exactly like standard IPv6 816 prefixes, they will not create any new mechanisms for routing loops 817 in IPv6 unless misconfigured. One very dangerous misconfiguration 818 would be an announcement of the 2002::/16 prefix into a 6to4 exterior 819 routing domain, since this would attract all 6to4 traffic into the 820 site making the announcement. Its 6to4 router would then resend non- 821 local 6to4 traffic back out, forming a loop. 823 The 2002::/16 routing prefix may be legitimately advertised into the 824 native IPv6 routing domain by a relay router, and into an IPv6 site's 825 local IPv6 routing domain; hence there is a risk of misconfiguration 826 causing it to be advertised into a 6to4 exterior routing domain. 828 To summarise, the 2002::/16 prefix MUST NOT be advertised to a 6to4 829 exterior routing domain. 831 6. Multicast and Anycast 833 It is not possible to assume the general availability of wide-area 834 IPv4 multicast, so (unlike [6OVER4]) the 6to4 mechanism must assume 835 only unicast capability in its underlying IPv4 carrier network. An 836 IPv6 multicast routing protocol is needed, and will be the subject of 837 a future document. 839 The allocated anycast address space [ANYCAST] is compatible with 840 2002:: prefixes, i.e. anycast addresses formed with such prefixes may 841 be used inside a 6to4 site. 843 7. ICMP messages 845 ICMP "unreachable" and other messages returned by the IPv4 routing 846 system will be returned to the 6to4 router that generated a 847 encapsulated 2002:: packet. However, this router will often be unable 848 to return an ICMPv6 message to the originating IPv6 node, due to the 849 lack of sufficient information in the "unreachable" message. This 850 means that the IPv4 network will appear as an undiagnosable link 851 layer for IPv6 operational purposes. Other considerations are as 852 described in Section 4.1.3 of [MECH]. 854 8. IANA considerations 856 No assignments by the IANA are required beyond the special TLA value 857 0x0002 already assigned. 859 9. Security considerations 861 Implementors should be aware that, in addition to possible attacks 862 against IPv6, security attacks against IPv4 must also be considered. 863 Use of IP security at both IPv4 and IPv6 levels should nevertheless 864 be avoided, for efficiency reasons. For example, if IPv6 is running 865 encrypted, encryption of IPv4 would be redundant except if traffic 866 analysis is felt to be a threat. If IPv6 is running authenticated, 867 then authentication of IPv4 will add little. Conversely, IPv4 868 security will not protect IPv6 traffic once it leaves the 6to4 869 domain. Therefore, implementing IPv6 security is required even if 870 IPv4 security is available. 872 By default, 6to4 traffic will be accepted and decapsulated from any 873 source from which regular IPv4 traffic is accepted. If this is for 874 any reason felt to be a security risk (for example, if IPv6 spoofing 875 is felt to be more likely than IPv4 spoofing), then additional source 876 address based packet filtering could be applied. A possible 877 plausibility check is whether the encapsulating IPv4 address is 878 consistent with the encapsulated 2002:: address. If this check is 879 applied, exceptions to it must be configured to admit traffic from 880 relay routers (Section 5). 2002:: traffic must also be excepted from 881 checks applied to prevent spoofing of "6 over 4" traffic [6OVER4]. 883 In any case, any 6to4 traffic whose source or destination address 884 embeds a V4ADDR which is not in the format of a global unicast 885 address MUST be silently discarded by both encapsulators and 886 decapsulators. Specifically, this means that IPv4 addresses defined 887 in [RFC 1918], broadcast, subnet broadcast, multicast and loopback 888 addresses are unacceptable. 890 Acknowledgements 892 The basic idea presented above is probably not original, and we have 893 had invaluable comments from Magnus Ahltorp, Harald Alvestrand, Jim 894 Bound, Randy Bush, Matt Crawford, Richard Draves, Jun-ichiro itojun 895 Hagino, Joel Halpern, Tony Hain, Andy Hazeltine, Bob Hinden, Geoff 896 Huston, Perry Metzger, Thomas Narten, Erik Nordmark, Markku Savela, 897 Ole Troan, Sowmini Varadhan, members of the Compaq IPv6 engineering 898 team, and other members of the NGTRANS working group. Some text has 899 been copied from [6OVER4]. George Tsirtsis kindly drafted two of the 900 diagrams. 902 References 904 [AARCH] Hinden, R., and S. Deering, "IP Version 6 Addressing 905 Architecture", RFC 2373 907 [AGGR] Hinden., R, O'Dell, M., and Deering, S., "An IPv6 908 Aggregatable Global Unicast Address Format", RFC 2374 910 [API] R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic 911 Socket Interface Extensions for IPv6", RFC 2553. 913 [BGP4+] Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain 914 Routing. P. Marques, F. Dupont, RFC 2545 916 [CONF] Thomson, S., and T. Narten, "IPv6 Stateless Address 917 Autoconfiguration", RFC 2462 919 [DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 920 Discovery for IP Version 6 (IPv6)", RFC 2461 922 [IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6 923 (IPv6) Specification", RFC 2460 925 [6OVER4] Carpenter, B., and Jung., C. "Transmission of IPv6 over 926 IPv4 Domains without Explicit Tunnels", RFC 2529. 928 [ANYCAST] Johnson, D. and Deering, S., Reserved IPv6 Subnet Anycast 929 Addresses, draft-ietf-ipngwg-resv-anycast-01.txt (work in progress). 931 [SELECT] Draves, R., Default Address Selection for IPv6, draft-ietf- 932 ipngwg-default-addr-select-00.txt (work in progress). 934 [RFC 791] Postel, J., "Internet Protocol", RFC 791 936 [RFC 1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G., 937 Lear, E., "Address Allocation for Private Internets", RFC 1918 939 [MECH] Transition Mechanisms for IPv6 Hosts and Routers. R. Gilligan 940 & E. Nordmark, draft-ietf-ngtrans-mech-06.txt (work in progress 941 updating RFC 1933). 943 [RSIP] Realm Specific IP: Protocol Specification, M. Borella, D. 944 Grabelsky, J. Lo, K. Tuniguchi, draft-ietf-nat-rsip-protocol-03.txt 945 (work in progress) 947 [RFC 2119] Key words for use in RFCs to Indicate Requirement Levels. 948 S. Bradner, RFC 2119 950 [RFC 2283] Multiprotocol Extensions for BGP-4, T. Bates, R. Chandra, 951 D. Katz, Y. Rekhter, RFC 2283 953 Authors' Addresses 955 Brian E. Carpenter 956 IBM 957 iCAIR, Suite 150 958 1890 Maple Avenue 959 Evanston IL 60201, USA 961 Email: brian@icair.org 963 Keith Moore 964 Innovative Computing Laboratory 965 University of Tennessee 966 104 Ayres Hall 967 Knoxville TN 37996, USA 969 Email: moore@cs.utk.edu 971 Intellectual Property 973 PLACEHOLDER for full IETF IPR Statement if needed. 975 Full Copyright Statement 977 PLACEHOLDER for full ISOC copyright Statement if needed.