idnits 2.17.1 draft-gilligan-ipv6-sit-overview-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 14 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 6, 1994) is 10794 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IPAE' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6-ADDR' -- Possible downref: Non-RFC (?) normative reference: ref. 'SIT-HR' -- Possible downref: Non-RFC (?) normative reference: ref. 'SIT-TR' -- Possible downref: Non-RFC (?) normative reference: ref. 'SIT-TP' Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Robert E. Gilligan 2 INTERNET-DRAFT Sun Microsystems, Inc. 4 October 6, 1994 6 Simple Internet Transition Overview 7 9 Abstract 11 In order to address problems of scaling and address space, a new version 12 of the Internet Protocol (IP) has been developed. The currently 13 deployed IP is version 4 (IPv4), and the new IP is version 6 (IPv6). If 14 IPv6 is to be widely adopted in the global Internet, the transition from 15 the current IP must be simple and easy for users as well as network 16 operators. In order for this to occur, hosts and routers implementing 17 the new protocol must interoperate with the large installed base of 18 systems which continue to use the existing IP. In addition, the 19 transition process must not disrupt the operation of the Internet. This 20 paper provides an overview of a set of mechanisms, operational 21 practices, and transition plans that can be used for transitioning the 22 Internet from IPv4 to IPv6. These techniques are collectively termed 23 the Simple Internet Transition (SIT). 25 While specifically designed to transition the IPv4 Internet to IPv6, the 26 methods used in SIT could be adapted to transition other internet layer 27 protocols such as IPX or CLNP to IPv6. 29 Status of this Memo 31 Internet Drafts are working documents of the Internet Engineering Task 32 Force (IETF), its Areas, and its Working Groups. Note that other groups 33 may also distribute working documents as Internet Drafts. 35 Internet Drafts are draft documents valid for a maximum of six months. 36 This Internet Draft expires on April 5, 1995. Internet Drafts may be 37 updated, replaced, or obsoleted by other documents at any time. It is 38 not appropriate to use Internet Drafts as reference material or to cite 39 them other than as a "working draft" or "work in progress." 41 Please check the I-D abstract listing contained in each Internet Draft 42 directory to learn the current status of this or any other Internet 43 Draft. 45 Distribution of this memo is unlimited. 47 History and Acknowledgements 49 SIT is derived the IPAE proposal [IPAE]. IPAE was based on ideas 50 originally developed by Dave Crocker and Bob Hinden. Erik Nordmark, Ron 51 Jacoby, Steve Deering, Bob Hinden and Dave Crocker made significant 52 contributions to the design of IPAE. Many others made contributions as 53 part of the SIPP, SIP, PIP, and IPAE working groups over a period of 54 more than two years. 56 A number of people have provided feedback and suggestions on earlier 57 drafts of this paper, including: Ross Callon, Dino Farinacci, Christian 58 Huitema, Bill Simpson, ... 60 1. Introduction 62 SIT specifies a number of mechanisms and operational practices to 63 transition the Internet from IPv4 to IPv6. 65 The mechanisms employed by SIT include: 67 - Use of the dual IP layer (IPv4 and IPv6) technique in hosts and 68 routers for direct interoperability with nodes implementing both 69 protocols. 71 - Two IPv6 addressing structures that embed an IPv4 addresses 72 within IPv6 addresses. 74 - A mechanism for tunneling IPv6 packets over IPv4 routing 75 infrastructures. This technique uses the embedded IPv4 address 76 structure, which eliminates the need for tunnel configuration in 77 most cases. 79 - An optional mechanism for translating headers of IPv4 packets 80 into IPv6, and the headers of IPv6 packet into IPv4. This 81 technique allows nodes that implement only IPv6 to interoperate 82 with nodes that implement only IPv4. 84 The operational issues include: 86 - Practices for assigning IPv4 and IPv6 addresses. 88 - Practices for upgrading hosts and routers and deploying new 89 hosts and routers. 91 - Practices for deploying DNS servers that support the IPv6 92 address record type. 94 - Plans for transitioning individual Internet sites to IPv6. 96 - Plans for transitioning the global Internet to IPv6. 98 SIT provides a number of features, including: 100 - Incremental upgrade. Existing installed IPv4 hosts and routers 101 may be upgraded to IPv6 at any time without being dependent on 102 any other hosts or routers being upgraded. 104 - Incremental deployment. New IPv6 hosts and routers can be 105 installed at any time without any prerequisites. 107 - Easy Addressing. When existing installed IPv4 hosts or routers 108 are upgraded to IPv6, they may continue to use their existing 109 address. They do not need to be assigned new addresses. 111 - Low start-up costs. Little or no preparation work is needed in 112 order to upgrade existing IPv4 systems to IPv6, or to deploy new 113 IPv6 systems. 115 1.1. Additional Documents 117 This paper provides an overview of SIT. It gives an introduction to the 118 concepts used in the transition, and describes the mechanisms that are 119 employed. This is not a specification document. The requirements on 120 the hosts, routers and header translating routers will be detailed in 121 two companion documents: 123 - IPv6 Transition Mechanisms for Hosts and Routers [SIT-HR] 125 This is a detailed specification of the transition mechanisms 126 that hosts and routers implement. This is a specification 127 document, written with the standard MUST/SHOULD/MAY wording. 129 - IPv6 Transition Mechanisms for Header Translating Routers [SIT-TR] 131 This a detailed specification of the special mechanisms that 132 translating routers must implement. This is a specification 133 document, written with the standard MUST/SHOULD/MAY wording. 135 No transition proposal can be complete without a detailed plan for how 136 the transition will be carried out operationally. For SIT, this 137 information is detailed in a companion document: 139 - IPv6 Transition Plan [SIT-TP] 141 This is an informational paper detailing the specific 142 operational steps that must be taken to transition the Internet 143 to using IPv6 globally. This paper includes time lines for the 144 transition, and identifies specific milestones. 146 1.2. Intended Audience 148 Individuals such as end users and system administrators who are 149 interested in the concepts of SIT can read this paper by itself. 151 People implementing host and router software which will incorporate the 152 transition mechanisms should read this paper in conjunction with the 153 specification documents. 155 People who will be involved in the transitioning the operational 156 Internet should read this paper along with the IPv6 Transition Plan. 158 All readers should be familiar with IPv6 and IPv4. The IPv6 159 specification [IPv6] should be read before reading this document. 161 1.3. Notation 163 We use the following notation to write IPv6 addresses: 165 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:ddd.ddd.ddd.ddd 167 Where "x" represents a hex digit, and "d" represents a decimal digit. 168 Each group of hex digits separated by ":" represents 16 bits of the 169 address. Leading zero digits in each group are suppressed. Each group 170 of decimal digits separated by "." represents 8 bits of the address. 171 Leading zero digits are suppressed here also. It is expected that the 172 notation for IPv6 addresses will eventually be standardized and defined 173 in the IPv6 specification document. 175 1.4. Adaptability to Other Internet Layer Protocols 177 If IPv6 is successful as a successor to IPv4, then organizations 178 operating networks of other internet layer protocols, such as CLNP or 179 IPX, may wish to transition them also to IPv6. The techniques in SIT 180 can be adapted to transition virtually any existing internet layer 181 infrastructure to IPv6 so long as the following assumptions hold: 183 - Addresses in the other internet layer protocol can be mapped 184 into the IPv6 address space efficiently. 186 - The semantics of the other internet layer protocol are similar 187 enough for header translation to work. 189 If these assumptions do not hold, or if the population of nodes running 190 the other protocol is small, a "pure dual stack" transition approach may 191 be more appropriate. 193 The first assumption appears to be true for CLNP and IPX. IPv6 address 194 space has been assigned for CLNP NSAP and IPX addresses in the IPv6 195 Routing and Addressing specification document [IPv6-ADDR]. And both 196 CLNP and IPX are semantically close enough to IPv6 to believe that 197 header translation may be possible. 199 2. Definitions 201 A number of new terms are introduced in this paper. 203 Types of Nodes 205 IPv4-only node: 207 A host or router that speaks only IPv4. An IPv4-only 208 node does not understand IPv6. The existing installed 209 base of IPv4 hosts and routers today are all IPv4-only 210 nodes. 212 IPv6/IPv4 (dual) node: 214 A host or router that speaks both IPv4 and IPv6. 215 IPv6/IPv4 nodes must implement transition mechanisms 216 (e.g. tunneling) in addition to the basic IPv6 and IPv4 217 protocols. 219 IPv6-only node: 221 A host or router that speaks only IPv6. An IPv6-only 222 node does not understand IPv4. 224 IPv6/IPv4 header translating router: 226 An IPv6/IPv4 router that performs IPv6/IPv4 header 227 translation. 229 Types of IPv6 Addresses 231 IPv4-compatible IPv6 address: 233 An address assigned to an IPv6 node that can be used for 234 both IPv6 and IPv4. An IPv4-compatible IPv6 address 235 holds an IPv4 address in the low-order 32-bits. The 236 high-order 96 bits bears the prefix 0:0:0:0:ffff:ffff. 237 The entire 128-bit address can be used when sending IPv6 238 packets. The low-order 32-bits can be used when sending 239 IPv4 packets. 241 IPv4-compatible IPv6 addresses always identify IPv6/IPv4 242 or IPv6-only nodes; they never identify IPv4-only nodes. 244 IPv4-mapped IPv6 address: 246 The address of an IPv4-only node represented as an IPv6 247 address. The IPv4 address is stored in the low-order 248 32-bits of an IPv4-mapped IPv6 address. The high-order 249 96 bits bears the prefix 0:0:0:0:0:0. The address of 250 any IPv4 node may be mapped into the the IPv6 address 251 space by prepending the prefix 0:0:0:0:0:0 to its IPv4 252 address. 254 IPv4-mapped IPv6 addresses always identify IPv4-only 255 nodes; they never identify IPv6/IPv4 or IPv6-only nodes. 257 IPv4-incompatible IPv6 address: 259 An IPv6 address that does not necessarily hold an 260 IPv4-address embedded in the low-order 32-bits. 261 IPv4-incompatible IPv6 addresses bear prefixes other 262 than 0:0:0:0:0:0 and 0:0:0:0:ffff:ffff. 264 IPv4-incompatible IPv6 addresses always identify 265 IPv6/IPv4 or IPv6-only nodes; they never identify 266 IPv4-only nodes. 268 Types of Routing Infrastructures 270 IPv4-dominant area: 272 A region of infrastructure that routes IPv4 completely. 274 IPv6-dominant area: 276 A region of infrastructure that routes IPv6 completely. 278 Techniques Used in SIT 280 IPv6-over-IPv4 tunneling (encapsulation): 282 The technique of encapsulating IPv6 packets within IPv4 283 so that it can be carried across an IPv4-dominant area. 285 IPv6/IPv4 header translation: 287 The technique of translating IPv6 packets into IPv4, and 288 IPv4 packets into IPv6, so that IPv4-only and IPv6-only 289 hosts can interoperate. 291 3. Transition Model 293 The design of SIT is based on two fundamental assumptions about how the 294 transition will take place. The first is that the Internet will 295 transition to IPv6 in an evolutionary fashion over an extended period of 296 time. The second is that the sites that make up the Internet will 297 transition at different rates and on different time schedules. 299 It is expected that, for most Internet sites, the transition will occur 300 in two phases. First, they will evolve from their initial state, in 301 which all hosts and routers support only IPv4, to a state where most 302 hosts and routers support both IPv6 and IPv4. In the second phase, 303 Internet sites would evolve to a state where all of the hosts and 304 routers support only IPv6, and none directly support IPv4. The second 305 phase is optional. Sites may elect to stop when the first phase is 306 complete. 308 The transition from an "IPv4-only" infrastructure to a "dual IPv6 and 309 IPv4" infrastructure will take place at different speeds in different 310 Internet sites. Some organizations will transition rapidly, while 311 others will delay transition for quite some time. This transition phase 312 can begin immediately, but may be carried out over an extended period of 313 time. 315 The eventual transition of some areas of the Internet to an "IPv6-only" 316 infrastructure is unlikely to begin immediately. It will more likely 317 begin only after the first phase of transition is completed, or at least 318 well under way. Even after some areas begin a transition to IPv6-only, 319 other areas of the Internet may choose to remain IPv4-only or IPv6/IPv4 320 indefinitely. In order to accommodate this, SIT provides a way for 321 hosts that only support IPv6 to continue to interoperate with hosts that 322 only support IPv4. 324 Most organizations that do decide to transition to an IPv6-only 325 infrastructure will likely do so only after first transitioning to a 326 dual IPv6/IPv4 infrastructure. However, this is not strictly required. 327 Sites may transition directly from IPv4-only to IPv6-only if they wish. 328 And organizations building entirely new infrastructures may elect to 329 make them IPv6-only. 331 The general timeline of transition for the Internet can be viewed as: 333 IPv4 only -----> Dual IPv6/IPv4 -----> IPv6 only 335 (first phase) (second phase) 337 Today --- Time ---> Future 339 SIT is designed to optimize what is expected to be the common case for 340 most sites: a two-phase transition. SIT makes the first phase -- 341 transition to dual IPv6/IPv4 -- quite easy, requiring virtually no 342 interdependencies. The second phase -- transition to an IPv6-only 343 infrastructure -- requires somewhat more effort. Some planning is 344 needed, and translating routers must be deployed, before any IPv6-only 345 infrastructure can be built. Nevertheless, once a site has transitioned 346 to IPv6/IPv4, its subsequent transition to IPv6-only is straightforward. 348 4. System Components 350 SIT assumes that three different types of hosts and routers will exist: 352 - "IPv4-only nodes" are routers and hosts that only support IPv4; 353 They do not support IPv6. At the beginning of the transition, 354 all hosts and routers in the Internet are IPv4-only. 356 - "IPv6/IPv4 nodes" are hosts and routers that support both IPv6 357 and IPv4, as well as some additional transition mechanisms such 358 as IPv6-over-IPv4 tunneling. IPv6/IPv4 nodes can directly 359 interoperate with both IPv6 and IPv4 nodes, although to 360 interoperate with IPv4-only nodes, they must be configured with 361 an "IPv4-compatible" IPv6 address. The first transition phase 362 in a site involves converting most or all hosts and routers in 363 that site from IPv4-only to IPv6/IPv4. 365 - "IPv6-only nodes" are hosts and routers that support only IPv6. 366 IPv6-only nodes do not provide an IPv4 protocol implementation. 367 Like IPv6/IPv4 nodes, IPv6-only nodes must be configured with 368 "IPv4-compatible" IPv6 addresses in order to interoperate with 369 IPv4 nodes. The second phase of transition in a site involves 370 converting all of the hosts and routers in that site to 371 IPv6-only. 373 One additional type of node is used in the transition: 375 - "IPv6/IPv4 header translating routers" are IPv6/IPv4 routers 376 that translate IPv4 packets into IPv6, and IPv6 packets into 377 IPv4. Translating routers are needed in order for IPv6-only 378 nodes that are configured with IPv4-compatible addresses to 379 interoperate with IPv4-only nodes. 381 It is expected that as part of their normal evolution, most products 382 that implement the Internet Protocols will eventually become 383 "IPv6/IPv4". Vendors may deliver this product change as part of a 384 normal software release. Users will install such upgrades as part of 385 their normal operational procedures. Thus hosts and routers may 386 transition from IPv4-only to IPv6/IPv4 as part of a normal system 387 upgrade. Since IPv6/IPv4 hosts and routers keep their complete IPv4 388 implementation, any IPv4-only host or router can be upgraded to 389 IPv6/IPv4 without affecting its IPv4 functionallity in any way. Thus 390 most IPv4-only nodes can be upgraded to IPv6/IPv4 at any time. 392 5. Addressing 394 SIT uses two formats of IPv6 addresses, both of which hold an embedded 395 IPv4 address. IPv4-compatible are assigned to IPv6 nodes, and have 396 the following structure: 398 | 96-bits | 32-bits | 399 +--------------------------------------+--------------+ 400 | 0:0:0:0:ffff:ffff | IPv4 Address | 401 +--------------------------------------+--------------+ 403 IPv4-Compatible IPv6 Address Format 405 The addresses of IPv4 nodes are represented as IPv4-mapped IPv6 406 addresses. These addresses have the following structure: 408 | 96-bits | 32-bits | 409 +--------------------------------------+--------------+ 410 | 0:0:0:0:0:0 | IPv4 Address | 411 +--------------------------------------+--------------+ 413 IPv4-Mapped IPv6 Address Format 415 The remainder of the IPv6 address space (that is, all addresses with 416 96-bit prefixes other than 0:0:0:0:0:0 or 0:0:0:0:ffff:ffff) are termed 417 "IPv4-Incompatible IPv6 Addresses" because they are not used by the 418 transition mechanisms. 420 IPv4-compatible IPv6 addresses are designed to be used by IPv6 nodes 421 that wish to interoperate with IPv4 nodes. These addresses are listed 422 in the DNS with both IPv6 "AAAA" records and IPv4 "A" records. The AAAA 423 records holds the entire 128-bit address, while the "A" record holds 424 only the low-order 32-bits. Both types of address records are listed so 425 that they can be located by both IPv4 and IPv6 nodes. 427 IPv4-mapped IPv6 addresses are only used to represent the addresses of 428 IPv4 nodes. They are never assigned to IPv6 nodes. Thus they are 429 listed in the DNS only with "A" records. They are not listed with 430 "AAAA" records. 432 IPv4-incompatible addresses are only assigned to IPv6 nodes and can not 433 be used for interoperating with IPv4 nodes. Thus these addresses are 434 listed in the DNS only with "AAAA" records. They are not listed with 435 "A" records. 437 When administrators assign IPv4-compatible IPv6 addresses to IPv6 nodes, 438 they must assign the low-order 32-bits (the portion) 439 according to the IPv4 numbering plan used on the subnet to which that 440 node is attached. The part must be a valid, globally 441 unique, IPv4 address. 443 The entire space of IPv4-incompatible IPv6 addresses is available for 444 use in a global IPv6 addressing plan that is not burdened with 445 transition requirements. This allows, for example, the addressing plan 446 for auto-configured addresses to be developed independent of the 447 transition mechanisms. 449 IPv6 Addressing Summary: 451 Embedded DNS 452 Record IPv4 Type of Type 453 High-order 96-bit prefix Addr Node Required 454 ------------------------ ------- ---------- ------- 455 0:0:0:0:0:0 Yes IPv4-only A only 457 0:0:0:0:ffff:ffff Yes IPv6/IPv4 or A and 458 IPv6-only AAAA 460 Not 0:0:0:0:0:0 or No IPv6/IPv4 or AAAA only 461 0:0:0:0:ffff:ffff IPv6-only 463 The ability of IPv4-only, IPv6/IPv4 and IPv6-only nodes to interoperate 464 is as follows: 466 --------------------------- 467 IPv6-only node \ 468 w/ IPv4-incompatible \ 469 Address \ 470 ------------------------ \ 471 IPv6-only node \ \ 472 w/ IPv4-compatible \ \ 473 Address \ \ 474 --------------------- \ \ 475 IPv6/IPv4 node \ \ \ 476 w/ IPv4-incompatible \ \ \ 477 Address \ \ | 478 ------------------ \ \ | 479 IPv6/IPv4 node \ \ | | 480 w/ IPv4-compatible \ \ | | 481 Address \ | | | 482 --------------- \ | | | 483 IPv4-only node \ | | | | 484 ------------\ \ | | | | 485 ---------------------+---+----+----+----+----+ 486 IPv4-only node | D | D | N | T | N | 487 ---------------------+---+----+----+----+----+ 488 IPv6/IPv4 node | | | | | | 489 w/ IPv4-compatible | D | D | D | D | D | 490 Address | | | | | | 491 ---------------------+---+----+----+----+----+ 492 IPv6/IPv4 node | | | | | | 493 w/ IPv4-incompatible | N | D | D | D | D | 494 Address | | | | | | 495 ---------------------+---+----+----+----+----+ 496 IPv6-only node | | | | | | 497 w/ IPv4-compatible | T | D | D | D | D | 498 Address | | | | | | 499 ---------------------+---+----+----+----+----+ 500 IPv6-only node | | | | | | 501 w/ IPv4-incompatible | N | D | D | D | D | 502 Address | | | | | | 503 ---------------------+---+----+----+----+----+ 505 D = Direct Interoperability 506 T = Interoperability with aid of a translating router 507 N = Non Interoperable 509 6. Topologies 511 The general model of routing topology transition in SIT is based on what 512 we expect will be the "natural evolution" of IPv4 and IPv6 routing 513 within a domain. It is expected that, in most cases, IPv6 routing will 514 initially be deployed in parallel with an already existing IPv4 routing 515 infrastructure. The deployment of IPv6 routing may take place by 516 upgrading existing IPv4-only routers to IPv4/IPv6. This will occur over 517 a period of time, not all at once. The site will eventually be 518 transformed into a complete dual IPv4/IPv6 infrastructure. At some 519 later point, IPv4 routing will be turned off. This process will also 520 likely be incremental. This transition may take place by upgrading 521 IPv4/IPv6 routers to IPv6-only, or by "turning off" the IPv4 software in 522 IPv4/IPv6 routers. Eventually a pure IPv6 infrastructure will be 523 formed. 525 SIT takes into account the likelyhood that both the process of "building 526 up" the IPv6 routing, and "tearing down" the IPv4 routing, will take 527 place over an extended period of time. Using this model, we can 528 classify routing topologies in two categories: 530 - "IPv4-dominant areas" are topologies that are completely 531 connected by IPv4 routing, but may also have partial IPv6 532 routing to some subnets. An area that provides exclusively IPv4 533 routing would be considered an IPv4-dominant area, as would one 534 in which IPv6 routing was in the process of being deployed. 536 IPv4-dominant areas naturally impose some restrictions on what 537 types of hosts can operate within their boundaries. Since the 538 area carries only IPv4 traffic completely, only hosts that can 539 send and receive IPv4 can be deployed. That means that 540 IPv4-only and IPv6/IPv4 hosts can be freely deployed within 541 IPv4-dominant areas. However, IPv6-only hosts generally can not 542 be deployed in IPv4-dominant areas because there are not enough 543 (in many cases none) IPv6 routers present. 545 - "IPv6-dominant areas" are topologies that are completely 546 connected by IPv6 routing, but may also have partial IPv4 547 routing to some subnets. A topology of dual IPv4/IPv6 routing, 548 with IPv4 routing being de-commissioned, would be considered an 549 IPv6-dominant area, as would one which provided only IPv6 550 routing. 552 Like IPv4-dominant areas, IPv6-dominant areas have natural 553 restrictions on what types of hosts they can support. Since an 554 IPv6-dominant area carries only IPv6 traffic completely, only 555 hosts that can send and receive IPv6 packets can be deployed. 556 That means that IPv6/IPv4 and IPv6-only hosts can be freely 557 deployed within IPv6-dominant areas, but that IPv4-only hosts 558 generally can not. 560 A summary of which types of host may be deployed in each of the two 561 types of topology is given in the table below: 563 TOPOLOGY TYPE 565 | IPv4-dominant | IPv6-dominant | 566 -----------+---------------+---------------+ 567 IPv4-Only | Yes | No | 568 -----------+---------------+---------------+ 569 HOST TYPE IPv4/IPv6 | Yes | Yes | 570 -----------+---------------+---------------+ 571 IPv6-only | No | Yes | 572 -----------+---------------+---------------+ 574 Note that SIT does not attempt to deal with a single area that is 575 composed of a mixture of IPv4-only and IPv6-only routers. Such a 576 topology does not work. IPv6-only and IPv4-only routers will not 577 interoperate because the two can not exchange packets because the two do 578 not share a common protocol. 580 However, area sizes may be quite flexible: a single node may be treated 581 as an area, as may the entire Internet. 583 IPv4-dominant and IPv6-dominant areas may only be interconnected via a 584 header translating router. For example: 586 IPv4-dominant area ---- Translating router ---- IPv6-dominant area 588 Header translating routers are discussed in section 8. 590 7. IPv6-over-IPv4 Tunneling 592 IPv6 packets can be carried across segments of an IPv4-dominant topology 593 by using the IPv6-over-IPv4 tunneling technique. An IPv6/IPv4 node that 594 has IPv4 reachability to another IPv6/IPv4 node may send IPv6 packets to 595 that node by encapsulating them within IPv4 headers. In order for this 596 technique to work, both nodes must be assigned IPv4-compatible IPv6 597 addresses. This is necessary because the low-order 32-bits of those 598 addresses are used as source and destination addresses of the 599 encapsulating IPv4 header. 601 Two types of tunneling are used in SIT. "Automatic tunnels" are used to 602 deliver IPv6 packets all the way to their end destinations. "Configured 603 tunnels" are used to deliver IPv6 packets to an intermediary IPv4/IPv6 604 router. 606 Both types of tunneling make use of the IPv4 address embedded in 607 IPv4-compatible IPv6 addresses. In automatic tunneling, the "tunnel 608 endpoint" address is taken from the IPv4 address embedded in the IPv6 609 destination address. No additional configuration information is needed 610 because the destination address is carried in the IPv6 packet being 611 tunneled. 613 In configured tunneling, the "tunnel endpoint" address is that of an 614 intermediate IPv4/IPv6 router. This address must be configured. This 615 configuration information could come in the form of routing table 616 information on a host, or neighbor configuration information on a 617 router. 619 Automatic tunneling is a basic feature of SIT. Hosts and routers in SIT 620 make extensive use of automatic tunneling. Configured tunneling is less 621 commonly used feature. It is used only when a host or router has been 622 configured to do so. 624 7.1. Automatic IPv6-over-IPv4 Tunneling 626 Automatic tunneling is generally used between IPv6/IPv4 hosts that are 627 connected to a common IPv4-dominant area. For example, consider two 628 IPv6/IPv4 hosts H1 and H2: 630 IPv6/IPv4 ------- IPv4-dominant area ------- IPv6/IPv4 631 Host H1 Host H2 632 (0:0:0:0:ffff:ffff:129.144.1.2) (0:0:0:0:ffff:ffff:192.9.5.3) 634 If H1 wishes to send an IPv6 packet to H2, it could encapsulate that 635 packet within an IPv4 packet as follows: 637 +-------------------------------------+ 638 | | 639 | src = 129.144.1.2 | IPv4 Header 640 | dst = 192.9.5.3 | 641 | | 642 +-------------------------------------+ 643 | | 644 | src = 0:0:0:0:ffff:ffff:129.144.1.2 | 645 | dst = 0:0:0:0:ffff:ffff:192.9.5.3 | IPv6 Header 646 | | 647 +-------------------------------------+ 648 | | 649 . . 650 . . 651 . . 653 When H2 receives this packet, it decapsulates it (remove the IPv4 654 header), and then process the IPv6 header as it would any received IPv6 655 packet. 657 Note that the source address of the encapsulating IPv4 packet is the 658 low-order 32-bits of H1's IPv4-compatible IPv6 address, and the 659 destination address is the low-order 32-bits of H2's IPv4-compatible 660 IPv6 address. 662 When automatic IPv6-over-IPv4 tunneling is used between two IPv6/IPv4 663 hosts, it is "end-to-end". Automatic tunneling can also be used 664 "router-to-host". IPv6/IPv4 routers may send IPv6-over-IPv4 packets to 665 IPv6/IPv4 hosts that are connected to a common IPv4-dominant area 666 without requiring any configuration information. 668 7.2. Configured IPv6-over-IPv4 Tunneling 670 Tunneling can also be used between two IPv6/IPv4 routers, or by an 671 IPv6/IPv4 host to an IPv6/IPv4 router. In these cases, the tunneling 672 does not extend to the end host; It runs only as far as an intermediary 673 router. For example, consider two IPv6/IPv4 hosts H1 and H2 and router 674 R1: 676 IPv6/IPv4 ------- IPv4-dominant area ------- IPv6/IPv4 677 Host H1 Router R1 678 (0:0:0:0:ffff:ffff:129.144.1.2) (0:0:0:0:ffff:ffff:129.146.9.8) 679 | 680 | 681 | 682 IPv6/IPv4 Host H2 683 (0:0:0:0:ffff:ffff:192.9.5.3) 685 If H1 wishes to send an IPv6 packet to H2 via router R1, it could 686 encapsulate that packet within an IPv4 packet as follows: 688 +-------------------------------------+ 689 | | 690 | src = 129.144.1.2 | IPv4 Header 691 | dst = 129.146.9.8 | 692 | | 693 +-------------------------------------+ 694 | | 695 | src = 0:0:0:0:ffff:ffff:129.144.1.2 | 696 | dst = 0:0:0:0:ffff:ffff:192.9.5.3 | IPv6 Header 697 | | 698 +-------------------------------------+ 699 | | 700 . . 701 . . 702 . . 704 Note that the IPv4 destination address is the low-order 32-bits of R1's 705 IPv6 address, while the IPv6 destination address is H2's address. In 706 this case, R1 is the tunnel endpoint. 708 When R1 receives this packet, it decapsulates it (remove the IPv4 709 header), and then process the IPv6 header as it would any received IPv6 710 packet. It then forwards the IPv6 packet based on its IPv6 destination 711 address, and delivers the packet to H2. 713 7.3. Tunnel Addressing 715 In both types of tunneling, the source address of the IPv4 header of the 716 tunneled packet is the low-order 32-bits of the IPv4-compatible IPv6 717 address of the node that performs the encapsulation. The IPv4 718 destination address is low-order 32-bits of the IPv4-compatible IPv6 719 address of the tunnel endpoint. 721 Except for the case of translating routers (see next section), the 722 intermediary routers on the path between the encapsulating node and the 723 decapsulating node do not look at the IPv6 header of the packet. They 724 route the packet entirely based on its IPv4 header. This is the case 725 even if the routers along the path are IPv6/IPv4 routers. 727 The table below summarizes the two types of tunneling: 729 Tunneling Encapsulating Decapsulating Tunnel Endpoint 730 Type Node Node IPv4 Address 731 ----------- ------------- ------------- --------------- 732 Automatic Source Host Dest Host Low-order 32-bits 733 of dest host's 734 IPv6 address 736 Automatic Router Dest Host Low-order 32-bits 737 of dest host's 738 IPv6 address 740 Configured Source Host Router Low-order 32-bits 741 of router's IPv6 742 address 744 Configured Router Router Low-order 32-bits 745 of router's IPv6 746 address 748 7.4. Host Sending Decisions 750 When sending IPv6 packets, an IPv6/IPv4 host must decide whether to use 751 IPv6-over-IPv4 tunneling technique or not. Generally speaking, a host 752 may follow these simple rules: 754 - If the destination is located on-subnet, send directly to 755 destination. 757 - If the destination is located off-subnet, and there is at least 758 one on-subnet default IPv6 router, send in IPv6 form to the 759 router. 761 - Otherwise, send using automatic IPv6-over-IPv4 tunneling. 763 Note that the destination must be an IPv4-compatible IPv6 address in 764 order to tunnel to it. And the sending IPv6/IPv4 host must itself be 765 configured with an IPv4-compatible IPv6 address. 767 This ordering mandates a preference for sending IPv6 packets via IPv6 768 routers, rather than tunneling. This is desirable for a number of 769 reasons: 771 - Less overhead because non-encapsulated IPv6 packets are smaller 772 than IPv6-over-IPv4 packets. 774 - Traffic can take advantage of IPv6 routing features such as 775 special handling by flow ID. 777 - Ensures that IPv6 routing topology will be used as it is 778 deployed. 780 Note that a host does not explicitly need to know whether it is attached 781 to an IPv4-dominant or IPv6-dominant area. If it is attached to an 782 IPv6-dominant area, there will be an IPv6 router attached to every 783 subnet, and the host will never send tunneled packets. If it is 784 attached to an IPv4-dominant area, it will send tunneled packets if 785 there are no on-subnet IPv6 routers, and IPv6 packets otherwise. 787 8. Header Translation. 789 Header translating routers "bridge" the IPv4 infrastructure of 790 IPv4-dominant areas into the IPv6 infrastructure of IPv6-dominant areas. 791 There are two kinds of traffic that need to be bridged: IPv4 packets, 792 and IPv6 packets encapsulated within IPv4 headers sent between IPv6 793 nodes. These two types of traffic are handled differently by header 794 translators. 796 Translating routers must provide all of the features required of 797 IPv6/IPv4 routers since they must route both IPv6 and IPv4 packets. In 798 addition to their routing responsibilities, they must perform three 799 specific functions: 801 - Translate IPv4 headers into IPv6. The IPv4 packets that must be 802 translated are those that are generated by IPv4-only nodes, and 803 addressed to IPv6 nodes located within the IPv6-dominant areas 804 that the translator is attached to. For example: 806 (IPv4 packet) --> (Translate to IPv6) --> (IPv6 Packet) 808 IPv4-dominant area -- Translating router -- IPv6-dominant area 809 | | 810 | | 811 IPv4-only node IPv6-only node 813 - Translate IPv6 headers into IPv4. The IPv6 packets that must be 814 translated are those that are generated by IPv6 nodes located 815 within the IPv6-dominant area that the translator is attached 816 to, and addressed to IPv4-only nodes. For example: 818 (IPv4 packet) <-- (Translate to IPv4) <-- (IPv6 Packet) 820 IPv4-dominant area -- Translating router ----- IPv6-dominant area 821 | | 822 | | 823 IPv4-only node IPv6-only node 825 - Decapsulate all IPv6-over-IPv4 packets. Translating routers 826 must decapsulate all IPv6-over-IPv4 packets, even if it is not 827 the tunnel endpoint. For example: 829 (IPv6 packet 830 encapsulated 831 in IPv4) --> (Decapsulate) --> (IPv6 Packet) 833 IPv4-dominant area -- Translating routers ----- IPv6-dominant area 834 | | 835 | | 836 IPv6/IPv4 node IPv6-only node 838 Note that all IPv6-over-IPv4 tunnels are effectively terminated if they 839 reach a translating router. This is necessary so that the encapsulated 840 IPv6 packet can be routed based on its IPv6 destination address when it 841 passes into an IPv6-dominant area. If this "early tunnel termination" 842 were not performed, the encapsulating IPv4 header might be translated to 843 IPv6, resulting in an IPv6 packet being encapsulated within another IPv6 844 header! 845 9. Node Requirements 847 This section gives an overview of the mechanisms that each of the three 848 system components -- IPv6/IPv4 nodes, IPv6-only nodes, and translating 849 routers -- must implement. 851 9.1. IPv6/IPv4 Nodes 853 IPv6/IPv4 nodes provide complete implementations of both IPv4 and IPv6. 854 They must adhere to all IPv6 and IPv4 specifications pertinent to their 855 role as a host or router. 857 Since IPv6/IPv4 nodes implement both protocols, they can directly 858 interoperate with both IPv6 and IPv4 nodes located on the same attached 859 subnet. 861 IPv6/IPv4 nodes must implement the IPv6-over-IPv4 tunneling mechanism, 862 and must be able to determine which destinations can be reached by 863 tunneling. 865 IPv6/IPv4 routers must have the ability to participate in both IPv6 and 866 IPv4 routing systems. System administrators must have the ability to 867 disable IPv4 routing on IPv6/IPv4 routers, because those routers 868 operating in IPv6-dominant areas must not route IPv4. 870 Generally, when IPv6/IPv4 nodes send packets to IPv4-only nodes, they 871 send those packets in the IPv4 format. However, if an IPv4 destination 872 is located off-subnet, and there are no on-subnet IPv4 routers, it must 873 send an IPv6 format packet. This packet will be translated back to IPv4 874 form by a translating router before it is delivered to the destination 875 IPv4 node. When sending IPv6 format packets to IPv4 destinations, the 876 IPv6/IPv4 node composes the destination address by prepending the 877 0:0:0:0:0:0 prefix to the destination's IPv4 address. 879 An IPv6/IPv4 node must be configured with an IPv4-compatible IPv6 880 address in order to interoperate with IPv4 nodes. When sending IPv4 881 packets to IPv4 nodes, an IPv6/IPv4 node uses the low-order 32-bits of 882 its own IPv4-compatible IPv6 address as the source address. When 883 sending IPv6 format packets, it must use its full IPv4-compatible IPv6 884 address as the source. 886 IPv6/IPv4 nodes should have the ability to be configured with multiple 887 IPv6 addresses per interface. In particular, an IPv6/IPv4 node should 888 have the ability to configure each interface with an IPv4-compatible as 889 well as an IPv4-incompatible IPv6 addresses. 891 If an IPv6/IPv4 node is configured with no IPv4-compatible IPv6 892 addresses, it must treat all attempts to send packets to IPv4 893 destinations as "unreachable". This is necessary because the node can 894 provide no valid IPv4 source address in the packets it would send. 896 9.2. IPv6-only nodes 898 IPv6-only nodes provide a complete IPv6 implementation, but no IPv4 899 implementation. They can directly interoperate with other IPv6 nodes, 900 but can interoperate with IPv4-only nodes only with the assistance of a 901 header translating router. IPv6-only nodes must implement a few simple 902 mechanisms in order make interoperability with IPv4 nodes possible. 904 Like IPv6/IPv4 nodes, IPv6-only nodes must have the ability to send IPv6 905 format packets to IPv4-only nodes. However, since IPv6-only nodes never 906 send IPv4 format packets, the algorithm to do this can be simpler. When 907 requested to send a packet to an IPv4 destination, an IPv6-only node can 908 simply pre-pend the prefix 0:0:0:0:0:0 to that address, and send a IPv6 909 format packet to the resulting IPv6 address. 911 IPv6-only nodes must also have the ability to handle "A" records in the 912 DNS. Since IPv4-only nodes will only have A records listed in the DNS, 913 IPv6-only nodes must be able to utilize these records when they are 914 found in a DNS lookup. Since there is a one-to-one mapping from the 915 IPv4 addresses of IPv4-only hosts to their corresponding IPv6 address, 916 IPv6-only hosts can easily synthesize the IPv6 address by prepending the 917 prefix 0:0:0:0:0:0 to the IPv4 address. 919 (Note: The mapping of IPv4 addresses into IPv6 addresses need not affect 920 the IPv6 or transport layer code in an IPv6-only host. It can usually 921 be isolated in the DNS resolver or address parsing libraries.) 923 IPv6-only routers participate in only the IPv6 routing systems. 925 Like IPv6/IPv4 nodes, IPv6-only must be configured with IPv4-compatible 926 IPv6 addresses in order to interoperate with IPv4 nodes. And IPv6-only 927 nodes should have the ability to configure multiple IPv6 addresses per 928 interface. 930 9.3. Header Translating Routers 932 Translating routers must be configured to know which packets must be 933 translated, and which can be simply forwarded without translation. This 934 can be done by configuring the translating router to know which IPv6 935 addresses are located within the IPv6-dominant area that it it attached 936 to. Translating routers use this configuration information, along with 937 the destination IPv6 or IPv4 addresses of packets they receive to 938 determine which packets to translate. They must: 940 - Translate IPv6 packets addressed to IPv4-only nodes outside the 941 attached IPv6-dominant area to IPv4. 943 - Translate IPv4 packets addressed to nodes within the attached 944 IPv6-dominant area to IPv6. 946 - Translate IPv4 packets addressed to nodes outside the attached 947 IPv6-dominant area to IPv6 if the resulting packets would 948 transit the IPv6-dominant area. 950 When translating IPv6 packets to IPv4, translating routers use the 951 low-order 32-bits of the source and destination IPv6 addresses to 952 generate the addresses for the IPv4 packet. 954 When translating IPv4 packets to IPv6, translating routers pre-pend the 955 prefix 0:0:0:0:0:0 to the IPv4 source address to generate the source 956 address for the IPv6 packet. They prepend either the prefix 957 0:0:0:0:ffff:ffff or 0:0:0:0:0:0 to generate the destination address. 958 They use the 0:0:0:0:ffff:ffff prefix if the destination is located 959 within the attached IPv6-dominant area, and the prefix 0:0:0:0:0:0 if 960 the destination is located outside. 962 10. Upgrade Dependencies 964 Perhaps the most important issue for those who must carry out the 965 transition from IPv4 to IPv6 is that of upgrade dependencies: Which 966 transition steps must be performed before other steps can be taken? SIT 967 is designed so that the prerequisites to installation of IPv6/IPv4 nodes 968 are minimal, while the steps that must be taken before IPv6-only nodes 969 may be deployed are more involved. 971 The upgrade dependencies are summarized in the table below: 973 | Transition Step | Depends On | 974 +-------------------------------+------------------------------+ 975 | DNS upgrade to support | None | 976 | AAAA records (1) | | 977 +-------------------------------+------------------------------+ 978 | Upgrade IPv4 host or router | DNS upgrade to support | 979 | to IPv6/IPv4 | AAAA records (2) | 980 +-------------------------------+------------------------------+ 981 | Deploy new IPv6/IPv4 host or | DNS upgrade to support | 982 | router | AAAA records (2) | 983 +-------------------------------+------------------------------+ 984 | Change IPv4-dominant area to | Install Translating router | 985 | IPv6-dominant | at border | 986 | | Upgrade all routers within | 987 | | area to IPv6/IPv4 | 988 +-------------------------------+------------------------------+ 989 | Upgrade IPv6/IPv4 host or | Change area from IPv4-dom'nt | 990 | router to IPv6-only | to IPv6-dominant | 991 +-------------------------------+------------------------------+ 992 | Deploy new IPv6-only | Change area from IPv4-dom'nt | 993 | host or router | to IPv6-dominant | 994 +-------------------------------+------------------------------+ 996 Notes: 997 (1) Strictly speaking, a DNS server being upgraded to 998 support the IPv6 AAAA address record type does not 999 itself need to be upgraded to IPv6. An IPv4-only 1000 DNS server may support AAAA record types. 1002 (2) The DNS upgrade is only required if node being 1003 upgraded or installed is going to be listed in the 1004 DNS. "Unlisted" nodes do not have this dependency. 1006 11. Examples 1008 Two IPv6/IPv4 hosts may use IPv6-over-IPv4 tunneling to communicate via 1009 an IPv4 infrastructure: 1011 IPv6/IPv4 Host H1 1012 (0:0:0:0:ffff:ffff:129.144.1.2) 1013 | 1014 --+--------------------------+-- (subnet A) 1015 | 1016 (0:0:0:0:0:0:129.144.1.3) 1017 IPv4-only Router R1 1018 (0:0:0:0:0:0:129.144.2.3) 1019 | 1020 -------+-----------------+----- (subnet B) 1021 | 1022 (0:0:0:0:ffff:ffff:129.144.2.4) 1023 IPv6/IPv4 Host H2 1025 When H1 sends a packet to H2, the packets that will be transmitted on 1026 subnets A and B are: 1028 Subnet Packet IPv4 header Datalink 1029 Hop Type IPv6 header dest addr dest addr dest addr 1030 ------ ----- ----------------------------- ---------- --------- 1031 A Encap. 0:0:0:0:ffff:ffff:129.144.2.4 129.144.2.4 R1 1032 B Encap. 0:0:0:0:ffff:ffff:129.144.2.4 129.144.2.4 H2 1034 Note: 1035 Encap. = IPv6-over-IPv4 encapsulation 1037 If an IPv6/IPv4 router is added to this topology, H1 will have multiple 1038 routes to reach H2. It could use IPv6-over-IPv4 tunneling, sending the 1039 traffic via R1 or R2, or use the raw IPv6 format routing via R2. Since 1040 IPv6/IPv4 hosts prefer routes via IPv6 routers, H1 will use send the 1041 traffic via R2: 1043 IPv6/IPv4 Host H1 1044 (0:0:0:0:0:1:129.144.1.2) 1045 | 1046 --+-----+-------------------------------+-- (subnet A) 1047 | | 1048 (0:0:0:0:0:1:129.144.1.4) (0:0:0:0:0:0:129.144.1.3) 1049 IPv6/IPv4 Router R2 IPv4-only Router R1 1050 (0:0:0:0:0:1:129.144.2.6) (0:0:0:0:0:0:129.144.2.3) 1051 | | 1052 ----+--+----------------------------+----- (subnet B) 1053 | 1054 (0:0:0:0:0:1:129.144.2.4) 1055 IPv6/IPv4 Host H2 1057 Now when H1 sends a packet to H2, the packets that will be transmitted 1058 on subnets A and B are: 1060 Subnet Packet Datalink 1061 Hop Type IPv6 header dest addr dest addr 1062 ------ ----- ----------------------------- --------- 1063 A IPv6 0:0:0:0:ffff:ffff:129.144.2.4 R2 1064 B IPv6 0:0:0:0:ffff:ffff:129.144.2.4 H2 1065 12. Author's Address 1067 Robert E. Gilligan 1068 Sun Microsystems, Inc. 1069 2550 Garcia Ave. 1070 Mailstop UMTV 05-44 1071 Mountain View, California 94043 1073 415-336-1012 (voice) 1074 415-336-6015 (fax) 1076 Bob.Gilligan@Eng.Sun.COM 1078 13. References 1080 [IPAE] R. E. Gilligan. IPAE: The SIPP Interoperability and 1081 Transition Mechanism. March 1994. Internet Draft. 1083 [IPv6] S. Deering. IPv6 Protocol Specification. Internet Draft 1084 in progress. 1086 [IPv6-ADDR] R. Hinden. IP Next Generation Addressing Architecture. 1087 October 1994. Internet Draft. 1089 [SIT-HR] IPv6 Transition Mechanisms for Hosts and Routers. 1090 Internet Draft to be written. 1092 [SIT-TR] IPv6 Transition Mechanisms for Header Translating 1093 routers. Internet Draft to be written. 1095 [SIT-TP] IPv6 Transition Plan. Internet Draft to be written.