idnits 2.17.1 draft-ietf-ngtrans-introduction-to-ipv6-transition-08.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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1636 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 19 instances of too long lines in the document, the longest one being 663 characters in excess of 72. ** There are 4 instances of lines with control characters in the document. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == 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 11 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 665 has weird spacing: '...routing infra...' == Line 787 has weird spacing: '... ip address ...' == Line 1532 has weird spacing: '...GP) and inte...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: '6bone' is mentioned on line 144, but not defined == Missing Reference: 'RFC 2471' is mentioned on line 159, but not defined ** Obsolete undefined reference: RFC 2471 (Obsoleted by RFC 3701) == Missing Reference: 'IPv6 HOST' is mentioned on line 539, but not defined == Missing Reference: 'SOCK64 SERVER' is mentioned on line 541, but not defined == Unused Reference: '6BONE' is defined on line 1103, but no explicit reference was found in the text == Unused Reference: 'DHCPv6' is defined on line 1105, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 1125, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 1128, but no explicit reference was found in the text == Unused Reference: 'RFC1886' is defined on line 1131, but no explicit reference was found in the text == Unused Reference: 'RFC2185' is defined on line 1148, but no explicit reference was found in the text == Unused Reference: 'RFC2672' is defined on line 1164, but no explicit reference was found in the text == Unused Reference: 'RFC2673' is defined on line 1167, but no explicit reference was found in the text == Unused Reference: 'RFC2471' is defined on line 1173, but no explicit reference was found in the text == Unused Reference: 'RFC2874' is defined on line 1192, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '6BONE' == Outdated reference: A later version (-28) exists of draft-ietf-dhc-dhcpv6-23 == Outdated reference: A later version (-08) exists of draft-ietf-ngtrans-dstm-07 -- Possible downref: Normative reference to a draft: ref. 'DSTM' -- No information found for draft-ietf-ipngwg-ipaddressassign - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IPASSIGN' -- Possible downref: Non-RFC (?) normative reference: ref. 'IRALLOC' == Outdated reference: A later version (-07) exists of draft-ietf-isis-ipv6-02 ** Obsolete normative reference: RFC 1886 (Obsoleted by RFC 3596) ** Downref: Normative reference to an Informational RFC: RFC 2081 ** Downref: Normative reference to an Informational RFC: RFC 2185 ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2374 (Obsoleted by RFC 3587) ** Obsolete normative reference: RFC 2672 (Obsoleted by RFC 6672) ** Obsolete normative reference: RFC 2673 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 2740 (Obsoleted by RFC 5340) ** Obsolete normative reference: RFC 2471 (Obsoleted by RFC 3701) ** Obsolete normative reference: RFC 2765 (Obsoleted by RFC 6145) ** Obsolete normative reference: RFC 2766 (Obsoleted by RFC 4966) ** Obsolete normative reference: RFC 2767 (Obsoleted by RFC 6535) ** Downref: Normative reference to an Informational RFC: RFC 2772 ** Obsolete normative reference: RFC 2858 (Obsoleted by RFC 4760) ** Downref: Normative reference to an Historic RFC: RFC 2874 ** Obsolete normative reference: RFC 2893 (Obsoleted by RFC 4213) ** Downref: Normative reference to an Informational RFC: RFC 3053 ** Downref: Normative reference to an Informational RFC: RFC 3089 ** Downref: Normative reference to an Informational RFC: RFC 3142 Summary: 26 errors (**), 0 flaws (~~), 25 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT W. Biemolt, SEC 2 NGTRANS WG A. Durand, SUN 3 Feb. 2002 D. Finkerson, UNL 4 A. Hazeltine, ASCI 5 M. Kaat, SEC 6 T. Larder, CISCO 7 R. van der Pol, SURFnet 8 Y. Sekiya, Keio Univ. 9 H. Steenman, AT&T 10 G. Tsirtsis, FLARION 12 An overview of the introduction of IPv6 in the Internet 14 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Distribution of this memo is unlimited. 39 Abstract 41 This document is a guide to the introduction of IPv6 in the IPv4 42 based Internet or Intranets. Several general issues to start IPv6 43 networking in a predominantly IPv4 world are discussed, such as IPv6 44 addresses, IPv6 DNS and routing issues. Short descriptions are given 45 of the different transition tools and mechanisms that 46 translate between IPv6 and IPv4 and/or tunnel IPv6 over IPv4. The 47 remainder of this document describes how IPv6 can be introduced in 48 various environments, such as ISPs and end user environments. 49 Suggestions are given on the use of the different 50 translation and migration tools in each environment. 52 Table of Contents 54 1. Introduction 55 2. The 6bone 56 3. Basic transition mechanism 57 3.1 Dual IP stack 58 3.2 Tunneling 59 4. The Tools In System Solutions 60 4.1 Connecting IPv6 islands 61 4.1.1 Configured tunnels 62 4.1.2 Automatic tunnels 63 4.1.3 Tunnel Broker 64 4.1.4 6TO4 65 4.1.5 6OVER4 66 4.2 Communication between IPv4 and IPv6 nodes. 67 4.2.1 Dual stack model 68 4.2.2 Limited Dual stack model 69 4.2.3 SOCKS64 70 4.2.4 SIIT 71 4.2.5 NAT-PT 72 4.2.6 BIS 73 4.2.7 Transport Relay Translator 74 4.2.8 DSTM 75 5. Case Studies 76 5.1 Large organization with globally routable addresses >= a /16. 77 5.1.1 Motivations 78 5.1.2 Prerequisites and conditions of transition. 79 5.1.3 Network infrastructure 80 5.1.4 dual stack servers 81 5.1.5 dual stack clients 82 5.1.6 IPv6 aware applications 83 5.1.7 Connection to the IPv6 Internet 84 5.1.8 IPv6 only hosts 85 5.1.9 IPv6 only node and IPv4 only server 86 5.2 Large organization with few global IPv4 addresses (a /24 or less) 87 5.3 The extranet case 88 5.4 Office or home network with ONE global IPv4 address 89 5.4.1 Step 1: Upgrade the NAT box and connect to the IPv6 Internet 90 5.4.2 Step 2: Dual stack clients and servers 91 5.4.3 Step 3: IPv6 aware applications 92 5.4.4 Step 4: IPv6 only hosts 93 5.5 Introducing IPv6 in an ISP environment 94 5.5.1 Introducing IPv6 in the core network 95 5.5.2 Introducing IPv6 in the customer access network 96 6. Security considerations 97 7. References 98 8. Authors' addresses 99 Appendix A - IPv6 Address Issues 100 A.1 IPv6 Address Allocation 101 A.1.1 Site local vs global addresses 102 A.1.2 Obtaining IPv6 Address Space 103 A.2 IPv6 Registration Issues 104 A.3 Example of IPv6 address allocation within a site /48 prefix 105 Appendix B. IPv6 and DNS 106 B.1 Forward mapping 107 B.2 Reverse mapping 108 B.3 Implementations 109 Appendix C. IPv6 routing issues 111 1. Introduction 113 The goal of this document is to provide an overview of several 114 transition mechanisms developed within the IETF NGtrans 115 working group. It is not intended to describe the complete 116 migration from IPv4 to IPv6 for the whole Internet. 117 It is an attempt to describe the possibilities 118 of introducing IPv6 in a predominantly IPv4 environment 119 and having both IPv6 and IPv4 connectivity. 121 The scope of this document is limited to IPv6 unicast transition. 122 Migration of IPv4 to IPv6 multicast environments is not 123 considered. 125 Section 2 provide some information and pointers about the 126 6bone[6bone], an IPv6 testbed. 128 Sections 3 and 4 provide short descriptions of the different 129 transition tools and mechanisms that translate between 130 IPv6 and IPv4 and/or tunnel IPv6 over IPv4. 132 Section 5 will discuss how IPv6 can be introduced in 133 typical environments. 135 Appendices A, B & C discuss issues about IPv6 address allocation, 136 IPv6 addresses in the DNS and IPv6 routing protocols. 138 Note: At the time this memo was originaly written, some recent 139 tools like ISATAP or TEREDO did not exist and thus they 140 are not described here. 142 2. The 6bone 144 The 6bone[6bone] is an IPv6 Testbed that is an outgrowth of the 145 IETF IPng project that created the IPv6 protocols intended 146 to eventually replace the current Internet network layer 147 protocols known as IPv4. 148 The 6bone is currently a worldwide informal collaborative 149 project, informally operated with oversight from the "NGtrans" 150 (IPv6 Transition) Working Group of the IETF. 151 The 6bone started as a virtual network (using IPv6 over IPv4 152 tunneling/encapsulation) operating over the IPv4-based Internet 153 to support IPv6 transport, and is slowly migrating to native 154 links for IPv6 transport. 155 The initial 6bone focus was on testing standards and 156 implementations, while the current focus is more on testing 157 transition and operational procedures. 158 The 6bone operates under the IPv6 Testing Address Allocation 159 (see [RFC 2471]). 161 A document describing the 6bone routing guidelines has been 162 published as RFC 2772. 164 More information can be found on http://www.6bone.net 166 By now, the 6bone is not the only IPv6 backbone. Other 167 backbones, academic and commercial are offering IPv6 services. 169 3. Basic transition mechanisms 171 [RFC2893] defines some basic mechanisms: 173 - Dual IP stack. Providing complete support for both IPv4 and 174 IPv6 in hosts or routers. 176 - IPv6 over IPv4 tunneling. Encapsulating IPv6 packets within 177 IPv4 headers to carry them over IPv4 routing infrastructures. 179 +-------------------+ +--------+ 180 | application | | IPv6 | 181 +-------------------+ | domain | +--------+ 182 | TCP / UDP | +--------*---* | 183 +-------------------+ | IPv4 | 184 | IPv4 | IPv6 | |networks| 185 +-------------------+ | *---*--------+ 186 | network layer | +--------+ | IPv6 | 187 | | | domain | 188 +-------------------+ +--------+ 190 a. dual stack node b. route IPv6 over IPv4 only networks 192 3.1 Dual IP stack 194 Dual stack nodes will be able to interoperate directly with both 195 IPv4 and IPv6 nodes. They must provide a resolver library capable of 196 dealing with the IPv4 A records as well as the IPv6 AAAA records. 197 When both A and AAAA records are listed in the DNS there are three 198 different options [RFC2893], (i) return only IPv6 address(es), (ii) 199 return only IPv4 address(es) or (iii) return both IPv4 and IPv6 200 addresses. The selection of which address type to return, or, in 201 which order can affect what type of IP traffic is generated. 203 The appellation "Dual Stack" in itself is somehow misleading. 204 Most implementations of IPv6 do not offer two completely distinct 205 TCP/IP stacks, one for IPv4 and one for IPv6, but a hybrid stack 206 in which most of the code is shared between the two protocol suites. 208 However, as the term "Dual Stack" is widely used in other documents, 209 this text will keep on using it. 211 3.2 Tunneling 213 IPv6 nodes (or networks) that are separated by IPv4 infrastructures 214 can build a virtual link by configuring a tunnel. IPv6 packets going 215 towards another IPv6 domain will then be encapsulated within IPv4 216 packets. The tunnel end-points are two IPv4 addresses and 217 two IPv6 addresses. Two types of tunneling can be employed: 218 configured and automatic. Configured tunnels are created by 219 manual configuration. The 6bone itself is an example of a network 220 containing manually configured tunnels. 221 Automatic tunnels on the other hand do not need manual configuration. 222 The tunnel end-points are automatically determined by using IPv4 223 compatible IPv6 addresses [RFC2373]. 225 Since most of the known tunneling techniques described later 226 are based on IPv4 addresses at both ends of the tunnel, 227 many of these techniques cannot work if an IPv4 address 228 translation (NAT) happens between the two end-points of the tunnel. 229 Also, When firewalls are used IP protocol 41 much be allowed 230 to go through. 232 4. The Tools In System Solutions 234 When introducing IPv6 in the Internet, one faces two different 235 sets of problems. The first one is related to having IPv6 236 communications among two or more IPv6 islands isolated in the 237 IPv4 world. The second set is related to the establishment of 238 (or some sort of) communications between the existing IPv4 world 239 and the new IPv6 world. 241 In the first set of problems, solutions are generally based 242 on dual stack routers and IPv6 in IPv4 tunnels. 244 Mechanisms to solve the second set of problems rely on dual stack 245 techniques, application level gateways, NAT technology or on 246 temporary allocation of IPv4 address and IPv4 in IPv6 tunneling. 248 This document defines some generic criteria to compare tools. 250 Applicability scope: where the transition tool applies to: 251 host, domain or global. 253 Understanding the scope of these mechanism is important when 254 one is trying to compare or combine them together. 255 A solution with scope of domain generally enables a whole domain 256 to connect but should not have any effect on the rest of the 257 Internet. A scope of a host enables the connection of 258 a single host. Thus, two mechanism of the same scope have 259 no impact on each other when applied on different places, 260 but great care is needed when applied at the same location. 261 For example, two domain one deploying 6over4 and another one 262 deploying DSTM, should not experience any problem. However, 263 it may not be easy nor recommeded to use both mechanism 264 in the same domain. A domain can most of the times be assimilated 265 to a site, but under some circonstances, can be larger and 266 include several sites, for example in the case of an ISP 267 offering NAT-PT service to its customers. 269 IPv4 requirements: what is required in the IPv4 context 270 to make the tool work. 272 IPv4 address requirements: this tries to identify how many 273 IPv4 addresses are required. In some contexts, the need 274 for many IPv4 addresses can be a no-go criteria. 276 IPv6 requirements: what is required in the IPv6 context 277 to make the tool work. 279 IPv6 address requirements: this identifies how many IPv6 addresses 280 are required for this specific solution. 282 Host requirements: what is needed for the hosts to participate 283 in this solution. 285 Router requirements: what is needed for the routers to enable 286 this solution. 288 NAT impact: will this solution work if deployed behind a NAT box? 290 Other requirements: other requirements not listed above. 292 4.1 Connecting IPv6 islands 294 The mechanisms described here are designed to enable IPv6 295 communication between IPv6 islands isolated in the IPv4 world. 296 All of these rely on tunnels. 298 4.1.1 Configured tunnels 300 Manually configured tunnels can be used to connect IPv6 hosts or 301 networks over an IPv4 infrastructure. Typically configured tunnels 302 are used between sites where traffic will be exchanged regularly. 303 Note that a site can be limited to a single host. 305 Applicability scope: global 306 IPv4 requirements: IPv4 inter connectivity between sites 307 IPv4 address requirements: >= 1 per site 308 IPv6 requirements: none 309 IPv6 address requirements: end-node needs one IPv6 address 310 Host requirements: IPv6 stack or IPv4/IPv6 stack 311 Router requirements: IPv4/IPv6 stack 312 NAT impact: will not work if the tunnel has to cross 313 a NAT BOX. 314 may work if the tunnel end-point is 315 collocated with the NAT box 316 Other requirements: none 318 4.1.2 Automatic tunnels 320 Automatic tunnels are used as configured tunnels to connect separated 321 IPv6 hosts or networks. Automatic tunnels are created when needed 322 and broken up when no longer necessary. Typically automatic tunnels 323 are used between individual hosts or between networks where only 324 incidentally there is a need for traffic exchange. A pre-requisite 325 for the use of automatic tunnels is the existence of IPv4-compatible 326 addresses for the IPv6 hosts that need to communicate. These 327 addresses allow the hosts to derive the IPv4 addresses of the tunnel 328 end-points from the IPv6 addresses. 330 Applicability scope: global 331 IPv4 requirements: IPv4 connectivity between sites 332 IPv4 address requirements: 1 per host 333 IPv6 requirements: none 334 IPv6 address requirements: IPv4-compatible addresses 335 Host requirements: IPv4/IPv6 stack 336 Router requirements: none 337 NAT impact: will not work if the tunnels have to cross 338 a NAT BOX 339 Other requirements: none 341 As this solution requires one IPv4 address per host, its domain 342 of application is extremely limited. 344 4.1.3 Tunnel Broker 346 Configuring tunnels usually requires cooperation of the two parties 347 to set up the correct tunnel end-points. Tunnel brokers [RFC3053] 348 can help people collect the necessary information to 349 set up the tunnels. A tunnel broker can be viewed as an IPv6 ISP 350 offering connectivity through IPv6 over IPv4 tunnels. 351 Current implementations are web-based tools that allow 352 interactive setup of an IPv6 over IPv4 tunnel. By requesting a 353 tunnel, the tunnel client gets assigned IPv6 addresses out of the 354 address space of the tunnel provider. 355 It can request either a single address or a network prefix 356 if a site is to be connected. 357 DNS will be updated automatically. 358 The created tunnel will provide IPv6 connectivity between the tunnel 359 provider's IPv6 environment and the isolated host/site. 361 Applicability scope: global 362 IPv4 requirements: none specific 363 IPv4 address requirements: 1 364 IPv6 requirements: none 365 IPv6 address requirements: none in the isolated client case 366 a prefix allocation if there is a network 367 to connect. 368 Host requirements: IPv4/IPv6 stack, IPv4 Web browser 369 Router requirements: none 370 NAT impact: will not work if the tunnel has to cross 371 a NAT BOX 372 may work if the tunnel client is 373 collocated with the NAT box 375 Other requirements: Tunnel server, secure DNS update, 376 some form of keep alive mechanism. 378 4.1.4 6TO4 380 The 6to4 [RFC3056] tool is applicable for the interconnection of 381 isolated IPv6 domains in an IPv4 world. The egress router of the 382 IPv6 domain creates a tunnel to the other IPv6 domain. 383 The IPv4 endpoints 384 of the tunnel are identified in the prefix of the IPv6 domain. This 385 prefix is made up of a unique 6TO4 /16 prefix plus a 32 386 bit field that identifies 387 the site by the IPv4 address of the translating egress router. 389 Another interesting effect of 6to4 is that it automatically derives 390 a /48 IPv6 from an IPv4 address. With this mechanism, sites can 391 start to deploy IPv6 without having to ask for IPv6 address space 392 from the registries. It is also very valuable in the absence 393 of IPv6 ISPs as it reduces to zero the management of tunnels. 395 Applicability scope: global 396 IPv4 requirements: IPv4 connectivity between sites 397 IPv4 address requirements: >= 1 per site 398 IPv6 requirements: globally unique 6to4 prefix 399 IPv6 address requirements: none 400 Host requirements: IPv6 stack, miminal source address selection 401 Router requirements: implementation of special forwarding and 402 decapsulation rules 403 NAT impact: will not work if the tunnel has to cross 404 a NAT BOX 405 may work if the 6to4 router is 406 collocated with the NAT box 407 Other requirements: creation of DNS record that reflects 6TO4 408 /48 prefix 409 relay router discovery mechanism 411 4.1.5 6OVER4 413 6over4 [RFC2529] interconnects isolated IPv6 hosts in a site through 414 IPv6 in IPv4 encapsulation without explicit tunnels. A virtual link 415 is created using an IPv4 multicast group with organizational local 416 scope. IPv6 multicast addresses are mapped to IPv4 multicast 417 addresses to be able to do Neighbor Discovery. To route between the 418 IPv6 Internet and the 6over4 domain in an organization, a router 419 needs to be configured as 6over4 on at least one interface. 421 Applicability scope: domain 422 IPv4 requirements: IPv4 multicast connectivity between hosts 423 IPv4 address requirements: 1 per host 424 IPv6 requirements: none 425 IPv6 address requirements: none 426 Host requirements: IPv4/IPv6 stack 427 Router requirements: 6over4 configuration to route between 428 different virtual links and/or virtual 429 links and the IPv6 Internet 430 NAT impact: Will require substantial effort 431 to make work. 432 Will have to make IPv4 multicast 433 work across NAT first. 434 Other requirements: To connect IPv6 hosts on different 435 physical links, IPv4 multicast routing 436 must be enabled on the routers connecting 437 the links 439 4.2 Communication between IPv4 and IPv6 nodes. 441 When IPv6 islands are installed and connected together using 442 one or several of the above mechanisms, communication between 443 IPv6 hosts is enabled. Communication between an IPv4 host and 444 an IPv6 host may also be important to establish. This can be done 445 in several ways, either by relaying at the application level, 446 or translating at the network layer or by temporarily allocating 447 an IPv4 address to the IPv6 node. 449 Note on Protocol Translation: 451 Typically a protocol translator maps the fields in the packets header 452 of one of the protocols to semantically similar fields in the packet 453 header of the other protocol. 454 A set of rules for the translation between IPv4 455 and IPv6 is defined in the SIIT [RFC2765] proposal discussed 456 below. It should be noted that in IPv4 applications, it is not uncommon 457 that the application has knowledge of information from the network 458 layer (like address length or the address itself). An example of this 459 is FTP. This makes it necessary not only to translate the network 460 layer packets but also to translate at the application layer. 462 4.2.1 Dual stack model 464 In the dual stack model, all IPv6 nodes, hosts or routers, are 465 dual stacked. That way, communication to IPv4 nodes takes 466 place with the IPv4 stack and communication with the IPv6 world 467 takes place with the IPv6 stack. The limitation of this approach 468 is the need to allocate an IPv4 address to each new IPv6 469 enable device. 471 Applicability scope: host 472 IPv4 requirements: IPv4 addressing plan and 473 IPv4 routing plan 474 IPv4 address requirements: 1 per host, many per router 475 IPv6 requirements: IPv6 addressing plan and 476 IPv6 routing plan 477 IPv6 address requirements: 1 per host, many per router 478 Host requirements: IPv4/IPv6 stack 479 Router requirements: IPv4/IPv6 stack, IPv6 routing protocols 480 NAT impact: IPv6 communications will be end-to-end. 481 IPv4 ones will not. 482 Other requirements: 484 4.2.2 Limited Dual stack model 486 In the limited dual stack model, only the "server" nodes are 487 dual-stacked. The new "client nodes" are IPv6 only. A server node 488 is defined as a node hosting enterprise Internet services, such as 489 file sharing, DNS, web... A client node is defined as a node 490 not offering those services but wanting to use them. 491 With this approach, fewer IPv4 addresses are used, 492 but the communication between an IPv4-only client node and an IPv6- 493 only server is broken. To re-establish this communication, 494 proxies are installed for strategic services. 496 Applicability scope: host 497 IPv4 requirements: use existing IPv4 infrastructure 498 IPv4 address requirements: 1 per server node 499 IPv6 requirements: IPv6 addressing plan and 500 IPv6 routing plan 501 IPv6 address requirements: 1 per new host, many per new router 502 Host requirements: IPv4/IPv6 stack on servers, IPv6 stack 503 on new clients 504 Router requirements: IPv4/IPv6 stack, IPv6 routing protocols 505 NAT impact: IPv6 communications will be end-to-end. 506 IPv4 ones will not. 507 Other requirements: proxies for v4 clients to v6-only servers 509 4.2.3 SOCKS64 511 The SOCKS Gateway [RFC3089] tool is a system that accepts 512 enhanced SOCKS [RFC1928] connections from IPv4 hosts 513 and relays it to IPv4 or IPv6 hosts. Especially for "socksified" 514 sites who already use SOCKS-aware clients and a SOCKS server, SOCKS 515 Gateway provides an easy way to enable IPv4 hosts to connect to IPv6 hosts. 516 No DNS modifications or address mapping are needed. The principle can 517 also be used to allow IPv6 hosts to connect to IPv4 hosts, IPv4 hosts 518 over IPv6 networks and IPv6 hosts over IPv4 networks. The latter 519 cases resemble tunnel techniques without possible problems with 520 fragmentation or hop limits. 522 Applicability scope: domain 523 IPv4 requirements: none specific 524 IPv4 address requirements: 1 per host 525 IPv6 requirements: >= 1 per site 526 IPv6 address requirements: none 527 Host requirements: clients should be "socksified" 528 Router requirements: none 529 NAT impact: The SOCKS relay and the NAT box 530 need to cooperate 531 Other requirements: dual stack SOCKS server. Here is an example: 533 /---------- SITE ----------------------------------\ 534 | | | 535 | | (IPv6 Segment) | 536 | [IPv6 HOST] ---+ | 537 | | | 538 | | | 539 | [IPv6 HOST] ---+ | 540 | | | 541 | +------ [SOCK64 SERVER] | 542 | | | | 543 | | | 544 | (IPv4/IPv6 Segment) | | 545 | ==================+=======+=======+ | 546 | | | | 547 | [IPv4 Router] [IPv6 Router] | 548 | | | | 549 \--------------------------------------------------/ 550 | | 551 | | 552 {IPv4 Internet} {IPv6 Internet} 554 4.2.4 SIIT 556 The SIIT [RFC2765] protocol describes a method to translate between IPv6 and 557 IPv4. Translation is limited to the IP packet header. The work does 558 not describe a method to assign a temporary IPv4 address to the IPv6 559 node. The translator is operating in a stateless mode, which means 560 that translation needs to be done for every packet. 562 Applicability scope: domain 563 IPv4 requirements: none 564 IPv4 address requirements: 1 temporary per IPv6 host 565 IPv6 requirements: none 566 IPv6 address requirements: IPv4-mapped and IPv4-translated addresses 567 to identify IPv4 nodes and IPv6 capable 568 nodes respectively 569 Host requirements: IPv6 stack 570 Router requirements: none 571 NAT impact: 2 (or more) levels of translation. 572 Other requirements: some address allocation mechanism 574 4.2.5 NAT-PT 576 NAT-PT, defined in [RFC2766] addresses communication between 577 IPv6 only and IPv4 only hosts. The communication is realized by use 578 of a dedicated device that does the translation between IPv4 and IPv6 579 addresses and keeps state during the time of the session. 580 The NAT-PT device also includes an application layer gateway to make 581 translation possible between IPv4 and IPv6 DNS requests and answers. 583 Applicability scope: domain 584 IPv4 requirements: none 585 IPv4 address requirements: >=1 per site 586 IPv6 requirements: none 587 IPv6 address requirements: none 588 Host requirements: IPv6 stack 589 Router requirements: none, but the router might be the NAT-PT 590 device 591 NAT impact: 2 (or more) levels of translation. 592 Other requirements: DNS in IPv6 network, ALG for application 593 wich use literal addresses 595 4.2.6 BIS 597 The Bump-In-The-Stack [RFC2767] model allows non-IPv6-capable applications 598 runningon an IPv4 host to communicate with IPv6 only hosts. 599 Added to the IPv4 stack are three modules 600 that intervene between the application and the network layers, an 601 extension to the name resolver, an address mapper and a translator. 602 The main idea is that when an IPv4 application needs to communicate 603 with an IPv6-only host, the IPv6 address of that host is mapped to 604 an IPv4 address out of a pool local to the dual stack hosts. The 605 IPv4 packet generated for the communication is translated into an 606 IPv6 packet according to SIIT. 607 One can view Bump-in-the-stack as a particular implementation 608 of NAT-PT within the IP stack of a host. 609 Note that a similar technique can be implemented at the library 610 level on a dual stack host. 612 Applicability scope: host 613 IPv4 requirements: none specific 614 IPv4 address requirements: pool of private address space per host 615 IPv6 requirements: none 616 IPv6 address requirements: none 617 Host requirements: IPv6/IPv4 stack plus extensions 618 Router requirements: none 619 NAT impact: The presence of NAT will have no effect on 620 IPv6 traffic, the IPv4 address is only 621 used internally. 623 Other requirements: ALG for application which uses literal 624 addresses 626 4.2.7 Transport Relay Translator 628 Transport Relay Translator defined in [RFC3142] enables direct 629 communication between IPv6 hosts and IPv4 hosts. This 630 mechanism is somewhat similar to NAT-PT, but does the 631 translation at the transport layer, not at the IP layer. 632 There should be a dedicated router at a site to translate 633 {UDP,TCP}/IPv6 to {UDP,TCP}/IPv4 and vice versa. 634 Also, there should be a DNS server which 635 can map IPv4 addresses to IPv6 addresses. No modification is 636 necessary for IPv6 hosts and IPv4 hosts. For scalability, 637 multiple dedicated boxes can be installed for a site with 638 multiple dummy IPv6 prefixes. UDP traffic can be relayed by 639 the same technique as that of TCP. 641 Applicability scope: domain 642 IPv4 requirements: none 643 IPv4 address requirements: 1 per site 644 IPv6 requirements: none 645 IPv6 address requirements: One dummy prefix out of the site address 646 Host requirements: none 647 Router requirements: none, but an intermediate device must be 648 a transport relay translator 649 NAT impact: May depend on the application. 650 Other requirements: DNS servers which can map IPv4 addresses 651 to IPv6 addresses 653 4.2.8 DSTM 655 Dual Stack Transition Mechanism [DSTM] is a mechanism that 656 allows a dual stack node whose IPv4 stack is enabled but not 657 yet configured to temporarily acquire an IPv4 address to 658 communicate with IPv4 only applications. 660 The main idea is that when an IPv4/IPv6 host needs an IPv4 661 address, it requests one for the duration of the 662 communication to a DSTM server. The communication with 663 the DSTM server is made on top of IPv6. 665 In the absence of IPv4 internal routing infrastructure, 666 the dual stack host will encapsulate IPv4 packets in IPv6 packets 667 to a tunnel endpoint that will decapsulate them and inject them 668 in the IPv4 infrastructure. 670 Communication initiated from an IPv4 node to a DSTM node 671 whose IPv4 stack is not yet configured is not supported 672 at the moment but will be defined in future work. 674 Applicability scope: domain 675 IPv4 requirements: none specific 676 IPv4 address requirements: >= 1 per site 677 IPv6 requirements: IPv4 in IPv6 tunneling 678 IPv6 address requirements: none 679 Host requirements: IPv4/IPv6 stack with extensions 680 Router requirements: none 681 NAT impact: Communications are done using IPv4, 682 so they may be impacted by any NAT boxes 683 encountered in the path. 684 Other requirements: IPv4 routing infrastructure or 685 tunnel end-points to decapsulate 686 IPv4 in IPv6 packets. 688 5. Case Studies 690 The initial group of scenari being considered share many 691 characteristics. They are looking at organizations with 692 well-established networks and a history of internet connectivity. 693 What distinguishes them is the number of globally routable IPv4 694 addresses that they have available. 696 5.1 Large organization with globally routable addresses >= a /16. 698 This is fairly typical for large US based Universities. 700 5.1.1 Motivations 702 Such a site may be motivated to begin the integration 703 of IPv6 into their network for a number of reasons: 705 - They wish to remain at the forefront of technology. 706 - They wish to maintain and where possible restore end-to-end 707 connectivity. They see NAT's in their future and wish 708 to prevent this from happening. 709 - They believe there will be IPv6-only devices appearing 710 at their installation and wish to be prepared for this 711 technology shift. 712 - Even though they have sufficient address space 713 to meet their data needs for the immediate future, 714 they do not have enough to migrate their 715 telephone system to IP. 716 - They have made a strategic decision to implement IPsec 717 and believe IPv6 is the best platform. 719 5.1.2 Prerequisites and conditions of transition. 721 - Integrating IPv6 cannot disrupt their current network. 722 - All of the IPv4 connectivity and functionality must continue 723 to operate. 724 - Installing IPv6 must not impact the performance of anyone but those 725 selected to test the IPv6 infrastructure. 726 - It is all right that the IPv6 performance does not match their 727 IPv4 performance, for the moment. 729 5.1.3 Network infrastructure 731 The most likely situation is that there will be a small section of 732 their network that will be made IPv6 capable. Various tools and 733 configurations can be tested in this area and as they prove stable 734 and useful they will be extended until they cover the entire 735 infrastructure. It is likely that this will happen from the core 736 of the network out, at least where installation is driven by 737 the existing networking staff. 739 Let us suppose that the network is made of a core set of routers 740 that are redundantly interconnected. This may be an ATM core, 741 it may utilize a gigabit or 100 megabit switched core, 742 and it may have some POS or be some combination of all of these. 743 In general each router will serve multiple wiring closets where 744 the layer 2-switched infrastructure resides. Again for redundancy 745 these switches are often connected to multiple routers. 747 Most likely the site will be allocated a /48 range, 748 e.g. 3FFE:ffff:0001::/48. This would give that manager the 749 equivalent of the IPv4 /16 they are currently use. 751 Having obtained the network number (and note that they 752 may even get more than one prefix if they have multiple 753 connectors), one approach would be to determine which 754 of the core or edge router nodes will be upgraded to 755 a dual stack IP implementation supporting both IPv4 756 and IPv6. 758 We would now have a situation that looks familiar: 760 ____________ 761 / \ 762 / \ 763 / IPv4 routed \ 764 \ core / 765 \ / 766 \ / 767 ------------ 768 || 769 || 770 || 771 || 772 ||Int1 773 || 774 -------- Int0 ------------- 775 | Router |____________|layer2 switch| 776 | R4/6 | ------------- 777 -------- | | | | | | | 778 | | | | | | | 779 Hosts 781 The configuration in the router called R4/6 would allow 782 both IPv4 and IPv6 traffic to pass to hosts attached 783 to IPv4 and IPv6 enabled interfaces. For instance on 784 the interface labeled Int0 (assumed to be Ethernet) 785 the following statements 786 would both be in the interface configuration: 787 ip address xxxx.xxxx.xxxx.xxxx 255.255.0.0 788 ipv6 address 3ffe:ffff:0001::0/64 eui-64. 789 While this leaves out some detail of the router configuration, 790 fundamentally that Ethernet is now IPv6 capable. 792 Assuming that there is a backbone network to connect to, 793 the interface labeled Int1 might also be configured with 794 both IPv4 and IPv6 addresses. If this is an ATM network, 795 with an ATM-connected provider a point-to-point PVC could 796 be configured allowing native IPv6 connectivity between the 797 router and the provider. Any other layer 2 technologies 798 can also bring native IPv6 service to R4/6. 799 If a native IPv6 connection cannot be set up, a tunnel 800 could be constructed out of that router using the Int1 801 interface as the local tunnel end-point. 803 Once the router is configured to forward IPv6 traffic, 804 routing must also be configured. This can be as simple 805 as a static default route pointing to the IPv6 provider. 806 External routing can also be done using BGP4+. 807 There is nothing particularly different about configuring 808 an IPv4 BGP session and an IPv6 BGP session. 810 Having done this much one final step remains before hosts 811 are introduced to this network. The next step should be to 812 obtain and operate a DNS server that is capable of 813 handling both A records and AAAA records. 815 At this point, there is an operational IPv6 network 816 at this site. Anyone connecting to the switch labeled 817 layer2 switch can send and receive IPv6 traffic as well as 818 IPv4 traffic. Other links in the site network can be 819 also upgraded to support IPv6. 821 Next hosts and services must be introduced. 823 5.1.4 Dual stack servers 825 The first step is to upgrade some enterprise servers to support 826 a dual stack, IPv4 and IPv6. 828 The dual stack servers will still serve the existing IPv4 clients. 830 Note: It may be a good practice not to use stateless auto- 831 configuration on the servers when the applications they run 832 store IP addresses in configuration files. If the IPv6 addresses 833 are derived from the MAC address of the NIC card and this one is 834 changed, the IPv6 addresses of the server will change and the 835 application may very well be confused if the configuration files are 836 not updated as well. 838 5.1.5 Dual stack clients 840 The second step is to get a dual stack IPv4/IPv6 on some clients 841 which are on the IPv6-ready link. 843 Stateless auto-configuration is very convenient for those clients 844 to lower the administration burden. 846 At this stage, the enterprise DNS should be populated with IPv6 847 addresses. 849 5.1.6 IPv6-aware applications 851 Now that some clients and some servers can communicate with IPv6, 852 it is time to obtain, setup and configure IPv6-aware applications. 853 In the dual stack model, these same application serve IPv4 and IPv6, 854 so there is no need to run two distinct applications, 855 one for IPv4 and one for IPv6. 857 Where IPv6-aware versions are not available, one of the techniques 858 described in section 4.2 could be used. 860 5.1.7 Connection to the IPv6 Internet 862 The organization may now think about a connection to the IPv6 863 Internet. If its ISP cannot deliver an IPv6 native link, a 864 configured tunnel to an IPv6 network or a 6to4 tunnel are possible 865 alternatives. That tunnel will originate from a dual stack router 866 at the border of the organization site. 868 Punching holes in the organization firewall may be necessary to dig 869 the tunnel. However, in such a case, setting up an IPv6 firewall 870 may be mandated by the organization security policy. 872 5.1.8 IPv6-only hosts 874 When all IPv6 service and all critical IPv6 applications 875 are available, one can think about deploying IPv6-only nodes 876 and IPv6-only links. 877 At this stage, those nodes will communicate only with other IPv6 878 hosts, IPv6-only or dual stacks. 880 Getting a 'pure' IPv6-only node may in practice not be possible. 881 Removing the IPv4 part of a dual stack may not be possible. 882 However, one can use a dual stack node and only configure the 883 loopback address 127.0.0.1 on the IPv4 stack. That way, this node 884 will not consume any global IPv4 addresses, and will behave very 885 much like an IPv6 only node. 887 5.1.9 IPv6-only node and IPv4-only server 889 Recalling our prerequistes IPv6-only nodes will need to talk to 890 IPv4-only servers, within the organization or on the Internet. 891 To achieve this, several techniques can be used: 893 - deploying proxies per critical applications 894 - deploying SIIT, NAT-PT or TCP-Relays 895 - deploying DSTM 897 The choice of the most suitable mechanism to deploy will depend on the organization. 899 5.2 Large organization with a few global IPv4 addresses (a /24 or less) 901 There is really very little to distinguish this scenario from 5.1. 902 Their motivation may be stronger, they are very likely losing 903 Internet functionality. The combination of a /24 or less of address 904 space more then 250 hosts in the organization will force the use 905 of NAT's. This will certainly have some effect on the range of 906 internet services available to these sites. 908 Other than being more aggressive, their deployment strategy will not 909 be much different from 5.1. 911 Differences will emerge at the edge, where the NAT's are located. 912 It is impossible to establish a tunnel end-point behind a NAT box. 913 Should a tunnel connection be required to reach the global IPv6 914 network, it will need to avoid the NAT, possibly by being located 915 in a router outside the NAT'ed network or via some other technique. 917 The existence of the NAT will also affect the use of some application 918 and host level transition tools. An examination of the tool section 919 of this document will provide information about those concerns. 921 5.3 The extranet case 923 NAT techniques make it easy for a client using an internal address 924 to initiate a connection to a server using an external address. 925 However, the opposite case, that is a client using an external address 926 trying to connect to a server using an internal address, 927 is a very difficult one. This makes communication between hosts 928 that are behind two different NAT domains even more difficult. 930 An organization that has a fairly large number of 931 branch offices which are, each of them, using the same IPv4 private 932 address space and NAT techniques, will face a very difficult problem 933 to connect them over the public Internet. 935 It even gets worse when data have to be exchanged with all the 936 organization suppliers and customers if those ones are also 937 using IPv4 private addresses and NAT techniques. 939 Re-establishing end-to-end IP connectivity for some applications 940 could become an important goal. 942 One way to achieve this is to deploy IPv6 in each site as 943 described in 5.2. The 6to4 mechanism will manage automatically all the 944 necessary tunnels between the various sites, provided that each of 945 them has, at least, one global IPv4 address. 947 5.4 Office or home network with ONE global IPv4 address 949 This is an extreme case of 5.2 and similar techniques apply. 950 Typically this type of environment consists of one network 951 segment with a small number of hosts using IPv4 private 952 addresses. The one global IPv4 address is assigned to a NAT box 953 that connects the network to an ISP. Most organizations of this 954 size do not use routers internally although some may have a few 955 internal network segments connected by a router. 957 5.4.1 Step 1: Upgrade the NAT box and connect to the IPv6 Internet 959 The first step is to upgrade or replace the NAT box with a device 960 supporting a dual stack, 6to4, and NAT-PT. In the way the NAT 961 device becomes an IPv6 router while still performing the NAT 962 function for IPv4. There are several possible methods of 963 connecting to the IPv6 Internet without affecting the existing 964 IPv4 service: 966 - a native IPv6 connection if the ISP supports both IPv4 and 967 native IPv6 connections 968 - a 6to4 connection 969 - a configured tunnel to an IPv6 provider 970 - a connection to an IPv6 tunnel broker 972 A 6to4 connection is recommended since it is likely to be some 973 time before most ISPs offer native IPv6 services. A 974 configured tunnel requires more administrative effort both 975 locally and at the IPv6 provider's end. Tunnel broker 976 connections are better suited to individual hosts or to small 977 sites with infrequent connectivity requirements. 979 At this point the organization will have a global 6to4 IPv6 prefix and 980 the NAT box acting as an IPv6 router will advertise this prefix 981 to the internal systems. This 6to4 global prefix is derived from 982 the single global IPv4 address. 984 If the IPv4 address is a DHCP-assigned or other transient 985 address, then the resulting 6to4 prefix will also be transient. 986 In this case, the IPv6 router should also be configured to 987 advertise a site-local prefix. The site-local addresses for 988 internal hosts can then be used in an internal DNS or similar 989 naming service. Using site-local addresses will promote easier 990 communication among internal hosts since these internal addresses 991 will not change when the global prefix changes. 993 5.4.2 Step 2: Dual stack clients and servers 995 Clients and servers should be upgraded to support a dual stack 996 once an IPv6 infrastructure exists. Dual stack support will 997 allow the use of IPv6 to begin while still supporting existing 998 IPv4 services. 1000 5.4.3 Step 3: IPv6-aware applications 1002 Once IPv6 is supported by the organization, IPv6 aware 1003 applications can be developed and installed. Using the dual 1004 stack model, one application can support both IPv4 and IPv6 1005 connections. 1007 5.4.4 Step 4: IPv6-only hosts 1009 IPv6 only hosts can be deployed after the important applications 1010 have become IPv6-aware. The private IPv4 addresses can be removed 1011 from the dual stack systems so that IPv6 is used for all 1012 communications. The IPv4 NAT box upgraded in step 1 also includes 1013 NAT-PT to allow communication between IPv6 only internal hosts and 1014 the IPv4 Internet. 1016 5.5 Introducing IPv6 in an ISP environment 1018 The network of an ISP consists of at least three main areas: the 1019 core network, the connections to other IPSs and the customer access 1020 network. The next two sections will discuss how an ISP can introduce 1021 IPv6 in those areas. 1023 For each area three steps must be taken first: 1025 - Request IPv6 address space 1026 - Register the IPv6 site, routing and delegations 1027 - Setup DNS 1029 5.5.1 Introducing IPv6 in the core network 1031 It is not really necessary to introduce IPv6 into the core of the 1032 network. An ISP may decide to tunnel IPv6 over its existing IPv4 1033 infrastructure. But if the ISP decides to introduce IPv6 into the 1034 core, this can be done in several ways. 1036 An ISP might decide to install a new set of dual stack or IPv6-only 1037 routers in the core. These will be interconnected by dedicated 1038 lines (ATM PVCs, leased lines, etc.) or (if the routers are dual 1039 stack) by IPv6 in IPv4 tunnels over the existing IPv4 core 1040 infrastructure. It may be necessary to establishe tunnels 1041 if some of the intermediary routers cannot be upgraded to 1042 IPv6 or if dedicated lines are either not possible to install or 1043 simply not cost effective. 1045 Routing can be setup such that IPv4 packets are 1046 routed through the old IPv4 infrastructure and IPv6 packets are 1047 routed through the new IPv6 infrastructure. 1049 When dual stack routers are stable enough to be used in the core, 1050 things become simpler. The ISP can configure the core routers as 1051 dual stack routers which will route both IPv4 and IPv6 packets. 1053 Next, a connection to the global IPv6 network should be made. This 1054 can be done by a direct IPv6 connection or by some tunneling 1055 mechanism. If the core of the network supports IPv6 and the other 1056 ISP also supports IPv6, a direct link can be used to transport IPv6 1057 packets. 1059 When there is no direct IPv6 connection, tunneling mechanisms must be 1060 used to reach the global IPv6 network. 1062 An ISP might decide to setup one or more routers at the edge of its 1063 network to act as 6to4 gateways. This enables other IPv6 islands to 1064 reach the ISP by 6to4 tunneling. An alternative to the use of 1065 dynamic tunnels is the use of static ones as is the case of the 1066 6Bone. 1068 5.5.2 Introducing IPv6 in the customer access network 1070 The customer access network consists of dial up and leased lines 1071 connected to an access router. There are at least two possibilities 1072 to introduce IPv6. The first possibility is to upgrade access 1073 routers to dual stack routers. Both IPv4 and IPv6 customers connect 1074 to these dual stack routers. 1076 Another possibility is, as in the core network, to install a new 1077 set of IPv6 or dual stack routers. IPv4-only customers connect to 1078 the old IPv4-only access routers. IPv6 customers connect to 1079 the new access routers. 1081 These IPv6 access routers must be connected to the global IPv6 1082 network. If the core does not support IPv6, one of the transition 1083 mechanisms from section 3 must be used. Dynamic tunneling can be 1084 done with for example 6to4[RFC3056]. An alternative to the use of dynamic 1085 tunnels is the use of statically configured ones. When the core 1086 network does support IPv6 the access routers can be connected to the 1087 nearest IPv6 core routea,r (either by IPv4/IPv6 link, dedicated link 1088 or tunneling over IPv4). 1090 When the customer is an IPv6-only site, the ISP might decide to 1091 provide some transition mechanisms to help the customer reach 1092 IPv4-only nodes. 1094 6. Security considerations 1096 There are no specific security issues introduced by this document. 1097 For the specific security issues with the different translations 1098 and migration tools that are discussed in section 4 of this document, 1099 the reader is referred to the referenced documents. 1101 7. References 1103 [6BONE] http://www.6bone.net 1105 [DHCPv6] J. Bound, C. Perkins, "Dynamic Host Configuration 1106 Protocol for IPv6", draft-ietf-dhc-dhcpv6-23.txt 1107 (work in progress). 1109 [DSTM] J. Bound, L. Toutain, H. Affifi, "Dual Stack Transition 1110 Mechanism (DSTM)", draft-ietf-ngtrans-dstm-07.txt 1111 (work in progress). 1113 [IPASSIGN] M. Blanchet, 1114 "A flexible method for managing the assignment of bits of an IPv6", 1115 draft-ietf-ipngwg-ipaddressassign-02.txt (work in progess) 1117 [IRALLOC] Regional IRs, "Provisional IPv6 assignment and allocation 1118 policy document (Draft 6; 27 May 1999)", 1119 ipv6policy-draft-090699.txt (work in progress). 1121 [IS-IS] C. Hopps, 1122 "Routing IPv6 with IS-IS", 1123 draft-ietf-isis-ipv6-02.txt, April 2001. 1125 [RFC1034] P. Mockapetris, "Domain names - concepts and facilities", 1126 RFC 1034, November 1987. 1128 [RFC1035] P. Mockapetris, "Domain names - implementation and 1129 specification", RFC 1035, November 1987. 1131 [RFC1886] S. Thomson and C. Huitema, "DNS Extensions to support IP 1132 version 6", RFC 1886, December 1995. 1134 [RFC1918] Y. Rekhter, B. Moskowitz, D. Karrenberg, G.J. de Groot 1135 and E. Lear, "Address Allocation for Private Internets", 1136 RFC 1918, February 1996. 1138 [RFC1928] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas and 1139 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 1140 March 1996. 1142 [RFC2080] G. Malkin, R. Minnear, "RIPng for IPv6", RFC 2080, 1143 January 1997. 1145 [RFC2081] G. Malkin, "RIPng Protocol Applicability Statement", 1146 RFC 2081, January 1997. 1148 [RFC2185] R. Callon, D. Haskin, "Routing Aspects of IPv6 1149 Transition", RFC 2185, September 1997. 1151 [RFC2373] R. Hinden, S. Deering, "IP Version 6 Addressing 1152 Architecture", RFC 2373, July 1998. 1154 [RFC2374] R. Hinden, M. O'Dell, S. Deering, "An IPv6 Aggregatable 1155 Global Unicast Address Format", RFC 2374, July 1998. 1157 [RFC2529] B. Carpenter, C. Jung, "Transmission of IPv6 over IPv4 1158 Domains without Explicit Tunnels", RFC2529, March 1999. 1160 [RFC2545] P. Marques, F. Dupont, "Use of BGP-4 Multiprotocol 1161 Extensions for IPv6 Inter-Domain Routing", RFC2545, 1162 March 1999. 1164 [RFC2672] Matt Crawford, "Non-Terminal DNS Name Redirection", 1165 RFC2672, August 1999 1167 [RFC2673] Matt Crawford, "Binary Labels in the Domain Name System", 1168 RFC 2673, August 1999. 1170 [RFC2740] R. Coltun, D. Ferguson, J. Moy, "OSPF for IPv6", 1171 RFC 2740, December 1999. 1173 [RFC2471] R. Hinden, R. FInk, J. Postel, 1174 "IPv6 Testing Address Allocation", RFC2471, December 1998. 1175 [RFC2765] E. Nordmark, "Stateless IP/ICMP Translator", 1176 RFC 2765, February 2000. 1178 [RFC2766] G. Tsirtsis, P. Srisuresh, 1179 "Network Address Translation - Protocol Translation (NAT-PT)", 1180 RFC 2766, February 2000. 1182 [RFC2767] K. Tsuchiya, H. Higuchi, Y. Atarashi, "Dual Stack Hosts 1183 using the Bump-in-the-Stack technique", 1184 RFC 2767, February 2000. 1186 [RFC2772] R. Rockell, R. Fink, "6Bone Backbone Routing Guidelines" 1187 RFC 2772, February 2000. 1189 [RFC2858] T. Bates, R. Chandra, D.Katz, Y. Rekhter, "Multiprotocol 1190 Extensions for BGP-4", RFC 2858, June 2000. 1192 [RFC2874] M. Crawford, C. Huitema, S. Thomson, "DNS Extensions to 1193 Support IP Version 6", 1194 RFC2874, July 2000 1196 [RFC2893] R. Gilligan and E. Nordmark, 1197 "Transition Mechanisms for IPv6 Hosts and Routers", 1198 RFC 2893, August 2000. 1200 [RFC3053] A. Durand, P. Fasano, I. Guardini, D. Lento, 1201 "IPv6 Tunnel Broker", RFC3053, February 2001 1203 [RFC3056] B. Carpenter, K Moore, 1204 "Connection of IPv6 Domains via IPv4 Clouds", 1205 RFC3056, February 2001 1207 [RFC3089] H. Kitamura, A. Jinzaki, S. Kobayashi, 1208 "A SOCKS-based IPv6/IPv4 Gateway Mechanism", 1209 RFC3089, April 2001. 1211 [RFC3142] J. Hagino, K. Yamamoto, 1212 "An IPv6-to-IPv4 transport relay translator", 1213 RFC3142, June 2001. 1215 8. Authors' Addresses 1217 Wim Biemolt 1218 SURFnet ExpertiseCentrum bv 1219 P.O. Box 19115 1220 3501 DC Utrecht 1221 The Netherlands 1222 Phone: +31 30 230 5305 1223 Fax: +31 30 230 5329 1224 Email: Wim.Biemolt@sec.nl 1226 Alain Durand 1227 SUN Microsystems, Inc. 1228 901 San Antonio road 1229 UMPK17-202 1230 Palo Alto, CA 94303-4900 1231 USA 1232 Email: Alain.Durand@sun.com 1234 Dale Finkerson 1235 29 WSEC 1236 University of Nebraska 1237 Lincoln, Ne. 68588 1238 Phone: +1 402 472 0450 1239 Email: dmf@unl.edu 1241 Marijke Kaat 1242 SURFnet ExpertiseCentrum bv 1243 P.O. Box 19115 1244 3501 DC Utrecht 1245 The Netherlands 1246 Phone: +31 30 230 5305 1247 Fax: +31 30 230 5329 1248 Email: Marijke.Kaat@sec.nl 1250 Andy Hazeltine 1251 Advanced Systems Consulting, Inc. 1252 4A Eves Drive, Suite 114 1253 Marlton, NJ 08053 1254 Phone: +1 856 983-3888 1255 Email: andy@advsys.com 1257 Tim Larder 1258 Cisco Systems Ltd. 1259 3, The Square, 1260 Stockley Park, 1261 Uxbridge, 1262 UB11 1BN, 1263 United Kingdom. 1264 Phone +44 (0)20 8756 8846 1265 Email: tlarder@cisco.com 1267 Yuji Sekiya 1268 Keio University 1269 5322 Endo, Fujisawa 1270 Kanagawa 252-8520 Japan 1271 Fax : +81 466 49 1101 1272 Email: sekiya@sfc.wide.ad.jp 1274 Henk Steenman 1275 AT&T, ICoE 1276 Laarderhoogtweg 25 1277 1101 EB Amsterdam 1278 The Netherlands 1279 Phone: +31 20 409 7656 1280 Fax: +31 20 453 1574 1281 Email: Henk.Steenman@icoe.att.com 1283 George Tsirtsis 1284 Flarion Technologies 1285 219 Lymington Avenue 1286 N22 6JL, London 1287 Tel/Fax: +44-20-88260073 1288 e-mail: G.Tsirtsis@Flarion.com 1290 Ronald van der Pol 1291 SURFnet bv 1292 P.O. Box 19035 1293 3501 DA Utrecht 1294 The Netherlands 1295 Phone: +31 30 230 5305 1296 Fax: +31 30 230 5329 1297 Email: Ronald.vanderPol@surfnet.nl 1299 9. Acknowledgment 1301 The authors would like to acknowledge earlier work on categorizing 1302 translators from Kazuhiko Yamamoto and Munechika Sumikawa. 1304 Appendix A. IPv6 Address Issues 1306 The IPv6 Global Unicast Address format is described in [RFC2374]. 1308 This address format splits the 128 bit IPv6 addresses into 1309 three level of hierarchy, the public topology, the site private 1310 topology, and the interface identifier. 1312 The public topology is described in the 48 first bits of an 1313 IPv6 address. Those 48 bits are made of: 1315 - 3 bits prefix to identify the IPv6 Global Unicast Address format 1316 - 45 bit network ID 1318 The site private topology is a 16 bit field. 1320 The interface identifier is a 64 bit field. 1322 | 3| 45 | 16 | 64 bits | 1323 +--+------------------+--------+--------------------------------+ 1324 |FP| network ID | SLA | Interface ID | 1325 | | | ID | | 1326 +--+------------------+--------+--------------------------------+ 1328 <--Public Topology---> Site 1329 <--------> 1330 Topology 1331 <------Interface Identifier-----> 1333 A.1 IPv6 Address Allocation 1335 IPv6 address space is very large. Much, much larger than the 1336 IPv4 address space. So the objective of IPv6 address allocation 1337 is more focused on route aggregation that address conservation. 1338 However, even though IPv6 address space is very large, it is an 1339 important resource that must be carefully managed for the good 1340 of the whole Internet. IPv6 address allocation follows 1341 strict rules that are discussed by the regional registries 1342 (RIPE-NCC, ARIN, APNIC) with guidance from the IETF. 1344 A.1.1 Site local vs global addresses 1346 Without special registration a site can deploy IPv6 site local 1347 addresses which are similar to IPv4 private addresses [RFC1918]. 1348 However, site local addresses do not allow for communication over 1349 the Internet. For this, sites need to apply for globally routable 1350 IPv6 addresses. Most sites will get a /48 prefix with 16 bits 1351 for subnetting and 64 bits for interface ID addressing. This 1352 means that each site will have 65536 subnets to define its 1353 internal topology and in each subnet almost 20 trillion hosts 1354 can be numbered. 1356 0 48 64 127 1357 +---------------------------------+--------+--------------------+ 1358 | prefix | subnet | Interface ID | 1359 +---------------------------------+--------+--------------------+ 1361 A.1.2 Obtaining IPv6 Address Space 1363 IPv6 addresses can be obtained from the same organizations as the 1364 ones who register IPv4 addresses. Regional IRs delegate 1365 a part of the IPv6 address space to local IRs who further delegate 1366 parts of the address space to their ISP customers. Site will 1367 obtain IPv6 addresses directly from their ISP. 1369 The regional IRs use a slow start mechanism [IRALLOC] to 1370 allocate address space to ISPs. A special 1371 pre-qualification procedure can be used by ISP 1372 participating in the 6bone. 1374 A.2 IPv6 Registration Issues 1376 In the current IPv4 world address space allocations are registered 1377 in the various databases managed by the regional IRs. Autonomous 1378 System (AS) information and routing policies are registered in the 1379 distributed Internet Routing Registry database (IRR). The IRs, LIRs 1380 and ISPs are supposed to register address space allocations and 1381 assignments, contact persons, AS numbers, routing policies and other 1382 useful data for network management in the various databases. 1384 A special IPv6 registration database has been setup for the 6bone 1385 community, on the whois server named "whois.6bone.net". This is a 1386 special version of the RIPE database software and it is referred to 1387 as the "6bone database". This database has special objects, the 1388 "inet6num:" object for assigned IPv6 prefixes, and the "ipv6-site:" 1389 object which is used to register specific information about a site 1390 connected to the 6bone, such as the configured tunnels and the 1391 origin AS. In the ipv6-site objects the IPV6 applications that are 1392 supported on that specific site can be found. The database can be 1393 queried by using a modified whois client or the web-based "whois" 1394 service at http://www.6bone.net/whois.html. At this time only the 1395 6bone database supports the special IPv6 objects. Currently, there 1396 are no database objects to register IPv6 routing policies. 1398 A.3 Example of IPv6 address allocation within a site /48 prefix 1399 In this example the prefix of the site is 3ffe:ffff:0001::/48. 1400 This means there are 2^16 = 65536 subnets of size /64 available 1401 (in IPv6 each interface has a netmask of length 64). 1403 Suppose the site consists of 42 different departments. To leave 1404 room for future expansion we can split the /48 into 128 /55s 1405 as follows: 1407 prefix usage 1408 3ffe:ffff:0001:0000::/55 backbone links 1409 3ffe:ffff:0001:0200::/55 reserved 1410 3ffe:ffff:0001:0400::/55 central services 1411 3ffe:ffff:0001:0600::/55 reserved 1412 3ffe:ffff:0001:0800::/55 department 1 1413 3ffe:ffff:0001:0A00::/55 reserved 1414 ... 1415 3ffe:ffff:0001:FC00::/55 department n 1416 3ffe:ffff:0001:FE00::/55 reserved 1418 Because it is difficult to predict what the best split will be 1419 (/53 or /54 or /55, etc) it is possible to assign the bits in a 1420 more flexible way. This is explained in [IPASSIGN]. Using 1421 this method makes it easier to change the prefix length to /54 or 1422 /56 in the future. 1424 The following table is an example how department 1 could use 1425 its 3ffe:ffff:0001:0800::/55 prefix: 1427 prefix usage 1428 3ffe:ffff:0001:0800::/64 reserved 1429 3ffe:ffff:0001:0801::/64 reserved 1430 3ffe:ffff:0001:0802::/64 reserved 1431 ... 1432 3ffe:ffff:0001:080E::/64 reserved 1433 3ffe:ffff:0001:080F::/64 reserved 1435 3ffe:ffff:0001:0810::/64 computer room 1436 3ffe:ffff:0001:0811::/64 computer room 1437 3ffe:ffff:0001:0812::/64 computer room 1438 ... 1439 3ffe:ffff:0001:087E::/64 computer room 1440 3ffe:ffff:0001:087F::/64 computer room 1442 3ffe:ffff:0001:0880::/64 VLAN 1 1443 3ffe:ffff:0001:0881::/64 VLAN 2 1444 3ffe:ffff:0001:0882::/64 VLAN 3 1445 ... 1446 3ffe:ffff:0001:09FE::/64 VLAN n-1 1447 3ffe:ffff:0001:09FF::/64 VLAN n 1449 Again, it is better to assign the bits as explained in 1450 [IPASSIGN]. 1452 Appendix B. IPv6 and DNS 1454 B.1 Forward mapping 1456 A host's 128 bit IPv6 address can be stored with an AAAA record. 1457 For example: 1459 $ORIGIN ipv6.surfnet.nl. 1460 ... 1461 zesbot IN AAAA 3FFE:ffff:0000:0001:02C0:4FFF:FEC6:9CC7 1463 This is similar to the use of the A record in IPv4, for example: 1465 $ORIGIN ipv6.surfnet.nl. 1466 ... 1467 zesbot IN A 192.87.110.60 1469 Note that both A and AAAA records for a given zone are stored in 1470 the same DNS data file. 1472 If a node has more than one IPv6 address it must have more than one 1473 AAAA record. For example: 1475 $ORIGIN ipv6.surfnet.nl. 1476 ... 1477 amsterdam9 IN AAAA 3FFE:ffff:0180:0000::0001 1478 IN AAAA 3FFE:ffff:0d80:0000::0005 1479 IN AAAA 3FFE:ffff:4080:0000::0009 1480 IN AAAA 3FFE:ffff:5680:0000::000D 1482 B.2 Reverse mapping 1484 IPv4 uses the "in-addr.arpa" domain for the reverse mapping. An 1485 IPv4 address is represented as a name in the in-addr.arpa domain by 1486 a sequence of bytes, written as decimal digits, separated by dots 1487 with the suffix ".in-addr.arpa". The sequence of bytes is encoded in 1488 reverse order, i.e. the low-order bytes is encoded first, followed 1489 by the next low-order bytes and so on. For example the IPv4 address 1490 192.87.110.60 is represented as a name in the in-addr.arpa domain as: 1492 60.110.87.192.in-addr.arpa. 1494 This name is stored in a DNS data file as follows: 1496 $ORIGIN 110.87.192.in-addr.arpa. 1497 ... 1498 60 IN PTR zesbot.ipv6.surfnet.nl. 1500 For IPv6 addresses the special domain "ip6.int" is defined to look 1501 up a record given an IPv6 address. The process works exactly the 1502 same as with IPv4. Except that an IPv6 address is represented by 1503 nibbles, written as hexadecimal digits, separated by dots. For 1504 example the IPv6 address 3FFE:ffff:0400:0001:02C0:4FFF:FEC6:9CC7 1505 is represented as a name in the ip6.int domain as: 1507 7.c.c.9.6.c.e.f.f.f.f.4.0.c.2.0.1.0.0.0.0.0.4.0.f.f.f.f.e.f.f.3.ip6.int. 1509 This name is stored in the a DNS data file as follows (assuming 1510 a /64 prefix): 1512 $ORIGIN 1.0.0.0.0.0.4.0.f.f.f.f.e.f.f.3.ip6.int. 1513 ... 1514 7.c.c.9.6.c.e.f.f.f.f.4.0.c.2.0 IN PTR zesbot.ipv6.surfnet.nl. 1516 Note that the IPv4 and IPv6 reverse mappings are stored in different 1517 DNS data files. 1519 Also note that ip6.int should be deprecated in the near future for ip6.arpa. 1521 B.3 Implementations 1523 Most DNS implementations will be able to deal with the reverse 1524 mapping as used with IPv6 addresses. AAAA record is implemented 1525 in recent DNS implementations. 1527 Note that although these DNS servers implement extensions to support 1528 the use of IPv6 addresses they are not necessarily IPv6 applications 1529 themselves, some use IPv4 transport. 1531 For IPv6 only nodes, an IPv6 resolver and an IPv6 DNS server 1532 are crucial.Appendix C. IPv6 routing issues To exchange reachability information routing protocols are used. There are two types of routing protocols, the intra-domain (IGP) and inter-domain (EGP) routing protocols. In the IPv4 world commonly used IGPs are RIP, OSPF and IS-IS and the EGP that is used is mostly BGP4. Besides the use of routing protocols, static routing can also be used. Routing protocols have been adapted to handle IPv6 routing information. RIP (RIPng) [RFC2080, RFC2081], BGP4 (BGP4+) [RFC2858, RFC2545], IS-IS [IS-IS] and OSPF [RFC2740] have IPv6 extensions defined. On the core of the 6bone, BGP4+ is mandated. More information about 6bone routing guidelines can be found in [RFC2772].