idnits 2.17.1 draft-ietf-ngtrans-routing-aspects-02.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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** Bad filename characters: the document name given in the document, 'draft-ietf-ngtrans-routing-aspects-02.txt)', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-ngtrans-routing-aspects-02.txt)', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-ngtrans-routing-aspects-02.txt)', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-ngtrans-routing-aspects-02.txt)', but the file name used is 'draft-ietf-ngtrans-routing-aspects-02' == 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 an Introduction 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. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 239 has weird spacing: '...ated as if it...' == Line 401 has weird spacing: '...culated from ...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (November 1996) is 10023 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) ** Obsolete normative reference: RFC 1933 (ref. '1') (Obsoleted by RFC 2893) Summary: 13 errors (**), 1 flaw (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Ross Callon 3 Internet Draft Dimitry Haskin 4 Expires May 1997 Bay Networks Inc. 5 November 1996 7 Routing Aspects Of IPv6 Transition 8 (draft-ietf-ngtrans-routing-aspects-02.txt) 10 Status of this memo 12 This document is an Internet-Draft. Internet-Drafts are 13 working documents of the Internet Engineering Task Force 14 (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of 19 six months and may be updated, replaced, or obsoleted by 20 other documents at any time. It is inappropriate to use 21 Internet-Drafts as reference material or to cite them other 22 than as ''work in progress.'' 24 To learn the current status of any Internet-Draft, please 25 check the ''1id-abstracts.txt'' listing contained in the 26 Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), 27 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 28 ds.internic.net (US East Coast), or ftp.isi.edu (US West 29 Coast). 31 Abstract 33 This internet draft gives an overview of the routing aspects 34 of the IPv6 transition. It is based on the protocols defined 35 in the document "Transition Mechanisms for IPv6 Hosts and 36 Routers" [1]. Readers should be familiar with the transition 37 mechanisms before reading this document. 39 The proposals contained in this document are based on the 40 work of the Ngtrans working group. 42 1. TERMINOLOGY 44 This paper uses the following terminology: 46 node - a protocol module that implements IPv4 or IPv6. 48 router - a node that forwards packets not explicitly 49 addressed to itself. 51 host - any node that is not a router. 53 border router - a router that forwards packets across 54 routing domain boundaries. 56 link - a communication facility or medium over which 57 nodes can communicate at the link layer, i.e., 58 the layer immediately below internet layer. 60 interface - a node's attachment to a link. 62 address - an network layer identifier for an interface or 63 a group of interfaces. 65 neighbors - nodes attached to the same link. 67 routing domain - a collection of routers which coordinate 68 routing knowledge using a single routing 69 protocol. 71 routing region (or just "region") - a collection of routers 72 interconnected by a single internet protocol 73 (e.g. IPv6) and coordinating their routing 74 knowledge using routing protocols from a single 75 internet protocol stack. A routing region may be 76 a superset of a routing domain. 78 tunneling - encapsulation of protocol A within protocol B, 79 such that A treats B as though it were a 80 datalink layer. 82 reachability information - information describing the set of 83 reachable destinations that can be used for 84 packet forwarding decisions. 86 routing information - same as reachability information. 88 address prefix - the high-order bits in an address. 90 routing prefix - address prefix that expresses destinations 91 which have addresses with the matching address 92 prefixes. It is used by routers to advertise what 93 systems they are capable of reaching. 95 route leaking - advertisement of network layer reachability 96 information across routing region boundaries. 98 2. ISSUES AND OUTLINE 100 This internet draft gives an overview of the routing aspects of 101 IPv4 to IPv6 transition. The approach outlined here is designed 102 to be compatible with the existing mechanisms for IPv6 103 transition [1]. 105 During an extended IPv4-to-IPv6 transition period, IPv6-based 106 systems must coexist with the installed base of IPv4 systems. In 107 such a dual internetworking protocol environment, both IPv4 and 108 IPv6 routing infrastructure will be present. Initially, deployed 109 IPv6-capable domains might not be globally interconnected via 110 IPv6-capable internet infrastructure and therefore may need to 111 communicate across IPv4-only routing regions. In order to achieve 112 dynamic routing in such a mixed environment, there need to be 113 mechanisms to globally distribute IPv6 network layer reachability 114 information between dispersed IPv6 routing regions. The same 115 techniques can be used in later stages of IPv4-to-IPv6 transition 116 to route IPv4 packets between isolated IPv4-only routing region 117 over IPv6 infrastructure. 119 The IPng transition provides a dual-IP-layer transition, augmented 120 by use of encapsulation where necessary and appropriate. Routing 121 issues related to this transition include: 123 (1) Routing for IPv4 packets 125 (2) Routing for IPv6 packets 126 (2a) IPv6 packets with IPv6-native addresses 127 (2b) IPv6 packets with IPv4-compatible addresses 129 (3) Operation of manually configured static tunnels 131 (4) Operation of automatic encapsulation 132 (4a) Locating encapsulators 133 (4b) Ensuring that routing is consist with 134 encapsulation 136 Basic mechanisms required to accomplish these goals include: 137 (i) Dual-IP-layer Route Computation; (ii) Manual configuration of 138 point-to-point tunnels; and (iii) Route leaking to support 139 automatic encapsulation. 141 The basic mechanism for routing of IPv4 and IPv6 involves 142 dual-IP-layer routing. This implies that routes are separately 143 calculated for IPv4 addresses and for IPv6 addressing. This is 144 discussed in more detail in section 3.1. 146 Tunnels (either IPv4 over IPv6, or IPv6 over IPv4) may be manually 147 configured. For example, in the early stages of transition this 148 may be used to allow two IPv6 domains to interact over an IPv4 149 infrastructure. Manually configured static tunnels are treated as 150 if they were a normal data link. This is discussed in more detail 151 in section 3.2. 153 Use of automatic encapsulation, where the IPv4 tunnel endpoint 154 address is determined from the IPv4 address embedded in the IPv4- 155 compatible destination address of IPv6 packet, requires 156 of routes between IPv4 routes and IPv6 routes for destinations using 157 IPv4-compatible addresses. For example, consider a packet which 158 starts off as an IPv6 packet, but then is encapsulated in an IPv4 159 packet in the middle of its path from source to destination. This 160 packet must locate an encapsulator at the correct part of its 161 path. Also, this packet has to follow a consistent route for the 162 entire path from source to destination. This is discussed in more 163 detail in section 3.3. 165 The mechanisms for tunneling IPv6 over IPv4 are defined in the 166 transition mechanisms specification [1]. 168 3. MORE DETAIL OF BASIC APPROACHES 170 3.1 Basic Dual-IP-layer Operation 172 In the basic dual-IP-layer transition scheme, routers may 173 independently support IPv4 and IPv6 routing. Other parts of the 174 transition, such as DNS support, and selection by the source host 175 of which packet format to transmit (IPv4 or IPv6) are discussed 176 in [1]. Forwarding of IPv4 packets is based on routes learned 177 through running IPv4-specific routing protocols. Similarly, 178 forwarding of IPv6 packets (including IPv6-packets with 179 IPv4-compatible addresses) is based on routes learned through 180 running IPv6-specific routing protocols. This implies that 181 separate instances of routing protocols are used for IPv4 and for 182 IPv6 (although note that this could consist of two instances of 183 OSPF and/or two instances of RIP, since both OSPF and RIP are 184 capable of supporting both IPv4 and IPv6 routing). 186 A minor enhancement would be to use an single instance of an 187 integrated routing protocol to support routing for both IPv4 and 188 IPv6. At the time that this is written there is no protocol which 189 has yet been enhanced to support this. This minor enhancement 190 does not change the basic dual-IP-layer nature of the transition. 192 For initial testing of IPv6 with IPv4-compatible addresses, it 193 may be useful to allow forwarding of IPv6 packets without running 194 any IPv6-compatible routing protocol. In this case, a dual (IPv4 195 and IPv6) router could run routing protocols for IPv4 only. It 196 then forwards IPv4 packets based on routes learned from IPv4 197 routing protocols. Also, it forwards IPv6 packets with an 198 IPv4-compatible destination address based on the route for the 199 associated IPv4 address. There are a couple of drawbacks with 200 this approach: (i) It does not specifically allow for routing of 201 IPv6 packets via IPv6-capable routers while avoiding and routing 202 around IPv4-only routers; (ii) It does not produce routes for 203 "non-compatible" IPv6 addresses. With this method the routing 204 protocol does not tell the router whether neighboring routers 205 are IPv6-compatible. However, neighbor discovery may be used to 206 determine this. Then if an IPv6 packet needs to be forwarded to 207 an IPv4-only router it can be encapsulated to the destination 208 host. 210 3.2 Manually Configured Static Tunnels 212 Tunneling techniques are already widely deployed for bridging 213 non-IP network layer protocols (e.g. Appletalk, CLNP, IPX) over 214 IPv4 routed infrastructure. IPv4 tunneling is an encapsulation of 215 arbitrary packets inside IPv4 datagrams that are forwarded over 216 IPv4 infrastructure between tunnel endpoints. For a tunneled 217 protocol, a tunnel appears as a single-hop link (i.e. routers 218 that establish a tunnel over a network layer infrastructure can 219 inter-operate over the tunnel as if it were a one-hop, point-to- 220 point link). Once a tunnel is established, routers at the tunnel 221 endpoints can establish routing adjacencies and exchange routing 222 information. Describing the protocols for performing 223 encapsulation is outside the scope of this paper (see [1]). 224 Static point-to-point tunnels may also be established between a 225 host and a router, or between two hosts. Again, each manually 226 configured point-to-point tunnel is treated as if it was a simple 227 point-to-point link. 229 3.3 Automatic Tunnels 231 Automatic tunneling may be used when both the sending and 232 destination nodes are connected by IPv4 routing. In order for 233 automatic tunneling to work, both nodes must be assigned IPv4- 234 compatible IPv6 addresses. Automatic tunneling can be especially 235 useful where either source or destination hosts (or both) do not 236 have any adjacent IPv6-capable router. Note that by "adjacent 237 router", this includes routers which are logically adjacent by 238 virtue of a manually configured point-to-point tunnel (which is 239 treated as if it is a simple point-to-point link). 241 With automatic tunneling, the resulting IPv4 packet is forwarded 242 by IPv4 routers as a normal IPv4 packet, using IPv4 routes 243 learned from routing protocols. There are therefore no special 244 issues related to IPv4 routing in this case. There are however 245 routing issues relating to how IPv6 routing works in a manner 246 which is compatible with automatic tunneling, and how tunnel 247 endpoint addresses are selected during the encapsulation process. 248 Automatic tunneling is useful from a source host to the destination 249 host, from a source host to a router, and from a router to the 250 destination host. Mechanisms for automatic tunneling from a router 251 to another router are not currently defined. 253 3.3.1 Host to Host Automatic Tunneling 255 If both source and destination hosts make use of IPv4-compatible 256 IPv6 addresses, then it is possible for automatic tunneling to be 257 used for the entire path from the source host to the destination 258 host. In this case, the IPv6 packet is encapsulated in an IPv4 259 packet by the source host, and is forwarded by routers as an IPv4 260 packet all the way to the destination host. This allows initial 261 deployment of IPv6-capable hosts to be done prior to the update 262 of any routers. 264 A source host may make use of Host to Host automatic tunneling 265 provided that the following are both true: 267 - the source address is an IPv4-compatible IPv6 address. 268 - the destination address is an IPv4-compatible IPv6 address. 269 - the source host does know of one or more neighboring IPv4- 270 capable routers, or the source and destination are on the 271 same subnet. 273 If all of these requirements are true, then the source host may 274 encapsulate the IPv6 packet in an IPv4 packet, using a source 275 IPv4 address which is extracted from the associated source IPv6 276 address, and using a destination IPv4 address which is extracted 277 from the associated destination IPv6 address. 279 Where host to host automatic tunneling is used, the packet is 280 forwarded as a normal IPv4 packet for its entire path, and is 281 decapsulated (i.e., the IPv4 header is removed) only by the 282 destination host. 284 If the source host has a neighboring IPv6 router, or if the 285 source and destination are on the same subnet, then automatic 286 tunneling need not be used. The packet can be sent in "raw 287 IPv6" form and forwarded via IPv6 routing. 289 3.3.2 Host to Router Configured Default Tunneling 291 In some cases "configured default" tunneling may be used to 292 encapsulate the IPv6 packet for transmission from the source 293 host to an IPv6-backbone. However, this requires that the 294 source host be configured with an IPv4 address to use for 295 tunneling to the backbone. 297 Configured default tunneling is particularly useful if the source 298 host does not know of any local IPv6-capable router (implying that 299 the packet cannot be forwarded as a normal IPv6 packet directly 300 over the link layer), and when the destination host does not have 301 an IPv4-compatible IPv6 address (implying that host to host 302 tunneling cannot be used). 304 Host to router configured default tunneling may optionally 305 also be used even when the host does know of a local IPv6 306 router. In this case it is a policy decision whether the 307 host prefers to send a native IPv6 packet to the IPv6-capable 308 router or prefers to send an encapsulated packet to the 309 configured tunnel endpoint. 311 Similary host to router default configured tunneling may be 312 used even when the destination address is an IPv4-compatible 313 IPv6 address. In this case for example a policy decision may 314 be made to prefer tunneling for part of the path and native 315 IPv6 for part of the path, or alternatively to use tunneling 316 for the entire path from source host to destination host. 318 A source host may make use of host to router configured default 319 tunneling provided that ALL of the following are true: 321 - the source address is an IPv4-compatible IPv6 address. 322 - the source host does know of one or more neighboring IPv4- 323 capable routers 324 - the source host has been configured with an IPv4 address of 325 an dual router which can serve as the tunnel endpoint. 327 If all of these requirements are true, then the source host may 328 encapsulate the IPv6 packet in an IPv4 packet, using a source 329 IPv4 address which is extracted from the associated source IPv6 330 address, and using a destination IPv4 address which corresponds to 331 the configured address of the dual router which is serving as 332 the tunnel endpoint. 334 When host to router configured default tunneling is used, the 335 packet is forwarded as a normal IPv4 packet from the source host 336 to the dual router serving as tunnel endpoint, is decapsulated by 337 the dual router, and is then forwarded as a normal IPv6 packet by 338 the tunnel endpoint. 340 3.3.2.1 Routing to the Endpoint for the Configured Default Tunnel 342 The dual router which is serving as the end point of the host to 343 router configured default tunnel must advertise reachability into 344 IPv4 routing sufficient to cause the encapsulated packet to be 345 forwarded to it. 347 The simplest approach is for a single IPv4 address to be assigned 348 for use as a tunnel endpoint. One or more dual routers, which 349 have connectivity to the IPv6 backbone and which are capable of 350 serving as tunnel endpoint, advertise a host route to this address 351 into IPv4 routing in the IPv4-only region. Each dual host in the 352 associated IPv4-only region is configured with the address of this 353 tunnel endpoint and selects a route to this address for forwarding 354 encapsulated packet to a tunnel end point (for example, the nearest 355 tunnel end point, based on whatever metric(s) the local routing 356 protocol is using). 358 Finally, in some cases there may be some reason for specific 359 hosts to prefer one of several tunnel endpoints, while allowing 360 all potential tunnel endpoints to serve as backups in case the 361 preferred endpoint is not reachable. In this case, each dual 362 router with IPv6 backbone connectivity which is serving as 363 potential tunnel endpoint is given a unique IPv4 address taken 364 from a single IPv4 address block (where the IPv4 address block is 365 assigned either to the organization administering the IPv4-only 366 region, or to the organization administering the local part of 367 the IPv6 backbone). In the likely case that there are much less 368 than 250 such dual routers serving as tunnel endpoints, we 369 suggest using multiple IPv4 addresses selected from a single 370 24-bit IPv4 address prefix for this purpose. Each dual router 371 then advertises two routes into the IPv4 region: A host route 372 corresponding to the tunnel endpoint address specifically 373 assigned to it, and also a standard (prefix) route to the 374 associated IPv4 address block. Each dual host in the IPv4-only 375 region is configured with a tunnel endpoint address which 376 corresponds to the preferred tunnel endpoint for it to use. If 377 the associated dual router is operating, then the packet will be 378 delivered to it based upon the host route that it is advertising 379 into the IPv4-only region. However, if the associated dual router 380 is down, but some other dual router serving as a potential tunnel 381 endpoint is operating, then the packet will be delivered to the 382 nearest operating tunnel endpoint. 384 3.3.3 Router to Host Automatic Tunneling 386 In some cases the source host may have direct connectivity to one 387 or more IPv6-capable routers, but the destination host might not 388 have direct connectivity to any IPv6-capable router. In this 389 case, provided that the destination host has an IPv4-compatible 390 IPv6 address, normal IPv6 forwarding may be used for part of the 391 packet's path, and router to host tunneling may be used to get 392 the packet from an encapsulating dual router to the destination 393 host. 395 In this case, the hard part is the IPv6 routing required to 396 deliver the IPv6 packet from the source host to the encapsulating 397 router. For this to happen, the encapsulating router has to 398 advertise reachability for the appropriate IPv4-compatible IPv6 399 addresses into the IPv6 routing region. With this approach, all 400 IPv6 packets (including those with IPv4-compatible addresses) are 401 routed using routes calculated from native IPv6 routing. This 402 implies that encapsulating routers need to advertise into IPv6 403 routing specific route entries corresponding to any IPv4-compatible 404 IPv6 addresses that belong to dual hosts which can be reached in 405 an neighboring IPv4-only region. This requires manual configuration 406 of the encapsulating routers to control which routes are to be 407 injected into IPv6 routing protocols. Nodes in the IPv6 routing 408 region would use such a route to forward IPv6 packets along 409 the routed path toward the router that injected (leaked) the route, 410 at which point packets are encapsulated and forwarded to the 411 destination host using normal IPv4 routing. 413 Depending upon the extent of the IPv4-only and dual routing 414 regions, the leaking of routes may be relatively simple or may be 415 more complex. For example, consider a dual Internet backbone, 416 connected via one or two dual routers to an IPv4-only stub 417 routing domain. In this case, it is likely that there is already 418 one summary address prefix which is being advertised into the 419 Internet backbone in order to summarize IPv4 reachability to the 420 stub domain. In such a case, the border routers would be configured 421 to announce the IPv4 address prefix into the IPv4 routing within the 422 backbone, and also announce the corresponding IPv4-compatible 423 IPv6 address prefix into IPv6 routing within the backbone. 425 A more difficult case involves the border between a major Internet 426 backbone which is IPv4-only, and a major Internet backbone which 427 supports both IPv4 and IPv6. In this case, it requires that either 428 (i) the entire IPv4 routing table be fed into IPv6 routing in the 429 dual routing domain (implying a doubling of the size of the routing 430 tables in the dual domain); or (ii) Manual configuration is required 431 to determine which of the addresses contained in the Internet routing 432 table include one or more IPv6-capable systems, and only these 433 addresses be advertised into IPv6 routing in the dual domain. 435 3.3.4 Example of How Automatic Tunnels May be Combined 437 Clearly tunneling is useful only if communication can be achieved 438 in both directions. However, different forms of tunneling may be 439 used in each direction, depending upon the local environment, 440 the form of address of the two hosts which are exchanging IPv6 441 packets, and the policies in use. 443 Table 1 summarizes the form of tunneling that will result given 444 each possible combination of host capabilities, and given one 445 possible set of policy decisions. This table is derived directly 446 from the requirements for automatic tunneling discussed above. 448 The example in table 1 uses a specific set of policy decisions: 449 It is assumed in table 1 that the source host will transmit a 450 native IPv6 where possible in preference over encapsulation. It 451 is also assumed that where tunneling is needed, host to host 452 tunneling will be preferred over host to router tunneling. Other 453 combinations are therefore possible if other policies are used. 455 Note that IPv6-capable hosts which do not have any local IPv6 456 router must be given an IPv4-compatible v6 address in order to 457 make use of their IPv6 capabilities. Thus, there are no entries 458 for IPv6-capable hosts which have an incompatible IPv6 address 459 and which also do not have any connectivity to any local IPv6 460 router. In fact, such hosts could communicate with other IPv6 461 hosts on the same local network without the use of a router. 462 However, since this internet draft focuses on routing and router 463 implications of IPv6 transition, direct communication between two 464 hosts on the same local network without any intervening router is 465 outside the scope of this internet draft. 467 Also, table 1 does not consider manually configured point-to-point 468 tunnels. Such tunnels are treated as if they were normal point- 469 to-point links. Thus any two IPv6-capable devices which have a 470 manually configured tunnel between them may be considered to be 471 directly connected. 473 -----------------+------------------+-------------------------- 474 Host A | Host B | Result 475 -----------------+------------------+-------------------------- 476 v4-compat. addr. | v4-compat. addr. | host to host tunneling 477 no local v6 rtr. | no local v6 rtr. | in both directions 478 -----------------+------------------+-------------------------- 479 v4-compat. addr. | v4-compat. addr. | A->B: host to host tunnel 480 no local v6 rtr. | local v6 rtr. | B->A: v6 forwarding plus 481 | | rtr->host tunnel 482 -----------------+------------------+-------------------------- 483 v4-compat. addr. | incompat. addr. | A->B: host to rtr tunnel 484 no local v6 rtr. | local v6 rtr. | plus v6 forwarding 485 | | B->A: v6 forwarding plus 486 | | rtr to host tunnel 487 -----------------+------------------+-------------------------- 488 v4-compat. addr. | v4-compat. addr. | end to end native v6 489 local v6 rtr. | local v6 rtr. | in both directions 490 -----------------+------------------+-------------------------- 491 v4-compat. addr. | incompat. addr. | end to end native v6 492 local v6 rtr. | local v6 rtr. | in both directions 493 -----------------+------------------+-------------------------- 494 incompat. addr. | incompat. addr. | end to end native v6 495 local v6 rtr. | local v6 rtr. | in both directions 496 -----------------+------------------+-------------------------- 498 Table 1: Summary of Automatic Tunneling Combinations 500 4. EXAMPLE 502 Figure 2 illustrates an example network with two regions A and B. 503 Region A is dual, meaning that the routers within region A are 504 capable of forwarding both IPv4 and IPv6. Region B is IPv4-only, 505 implying that the routers within region B are capable of routing 506 only IPv4. The illustrated routers R1 through R4 are dual. The 507 illustrated routers r5 through r9 are IPv4-only. Also assume 508 that hosts H3 through H8 are dual. Thus H7 and H8 have been 509 upgraded to be IPv6-capable, even though they exist in a region 510 in which the routers are not IPv4-capable. However, host h1 and 511 h2 are IPv4-only. 513 ......................... ....................... 514 . . . . 515 . h1 . . |-h2 . 516 . | . . | . 517 . H3---R1--------R2---------------r5----r9----+ . 518 . | | . . | |-H7 . 519 . | | . . | . 520 . | | . . | . 521 . H4---R3--------R4---------------r6----r8-----H8 . 522 . . . . 523 ......................... ....................... 524 Region A (Dual Routers) Region B (IPv4-only Rtrs) 526 Figure 2: Example of Automatic Tunneling 528 Consider a packet from h1 to H8. In this case, since h1 is IPv4- 529 only, it will send an IPv4 packet. This packet will traverse 530 regions A and B as a normal IPv4 packet for the entire path. 531 Routing will take place using normal IPv4 routing methods, with 532 no change from the operation of the current IPv4 Internet (modulo 533 normal advances in the operation of IPv4, of course). Similarly, 534 consider a return packet from H8 to h1. Here again H8 will 535 transmit an IPv4 packet, which will be forwarded as a normal IPv4 536 packet for the entire path. 538 Consider a packet from H3 to H8. In this case, since H8 is in an 539 IPv4-only routing domain, we can assume that H8 uses an 540 IPv4-compatible IPv6 address. Since both source and destination are 541 IPv6-capable, H3 may transmit an IPv6 packet destined to H8. The 542 packet will be forwarded as far as R2 (or R4) as an IPv6 packet. 544 Router R2 (or R4) will then encapsulate the full IPv6 packet in 545 an IPv4 header for delivery to H8. In this case it is necessary 546 for routing of IPv6 within region A to be capable of delivering 547 this packet correctly to R2 (or R4). As explained in section 3.3, 548 routers R2 and R4 may inject routes to IPv4-compatible IPv6 549 addresses into the IPv6 routing used within region A corresponding 550 to the routes which are available via IPv4 routing within region B. 552 Consider a return packet from H8 to H3. Again, since both source 553 and destination are IPv6-capable, a IPv6 packet may be transmitted 554 by H8. However, since H8 does not have any direct connectivity to 555 an IPv6-capable router, H8 must make use of an automatic tunnel. 556 Which form of automatic tunnel will be used depends upon the type 557 of address assigned to H3. 559 If H3 is assigned an IPv4-compatible address, then the 560 requirements specified in section 3.3.1 will all be satisfied. In 561 this case host H8 may encapsulate the full IPv6 packet in an 562 IPv4 header using a source IPv4 address extracted from the IPv6 563 address of H8, and using a destination IPv4 address extracted 564 from the IPv6 address of H3. 566 If H3 has an IPv6-only address, then it is not possible for H8 to 567 extract an IPv4 address to use as the destination tunnel address 568 from the IPv6 address of H3. In this case H8 must use host to 569 router tunneling, as specified in section 3.3.2. In this case one 570 or both of R2 and R4 must have been configured with a tunnel 571 endpoint IPv4 address (R2 and R4 may use either the same address 572 or different addresses for this purpose). R2 and/or R4 therefore 573 advertise reachability to the tunnel endpoint address to r5 and r6 574 (respectively), which advertise this reachability information into 575 region B. Also, H8 must have been configured to know which tunnel 576 endpoint address to use for host to router tunneling. This will 577 result in the IPv6 packet, encapsulated in an IPv4 header, to be 578 transmitted as far as the border router R2 or R4. The border router 579 will then strip off the IPv4 header, and forward the remaining IPv6 580 packet as a normal IPv6 packet using the normal IPv6 routing used 581 in region A. 583 5. INTERACTION BETWEEN IPv4 AND IPv6 INTER-DOMAIN ROUTING 585 As discussed above, if route leaking is employed then IPv4 routes 586 which are acquired by an inter-region dual router may need to be 587 injected into an IPv6 routing region. Such an inter-region dual 588 router may use BGP-4 for IPv4 inter-domain routing. Since the 589 Inter-Domain Routing Protocol (IDRP) has been adopted for IPv6 590 inter-domain routing, IDRP may need to be used to propagate the 591 IPv4 route into IPv6 routing. 593 When routes learned with BGP are injected into IDRP, it would be 594 highly desirable to preserve routing attributes associated with 595 the routes in order to minimize the effect of the inter-region 596 route leaking onto the routing integrity. Since practically all 597 routing attributes that are carried in BGP-4 are also present in 598 IDRP, the mapping of the BGP-4 attributes to the IDRP attributes 599 is straightforward. However, since addresses and routing domain 600 identifiers that are carried by IDRP and BGP-4 are assigned from 601 different number spaces there is a need to ensure that 32-bit 602 IPv4 addresses and 16-bit routing domain identifiers (Autonomous 603 System numbers in IPv4 terminology) are uniquely represented in 604 the larger IPv6 number space. 606 Since IPv6 domain identifiers are allocated from the 128-bit IPv6 607 address space and IPv6 addresses with 96 leading zero bits are 608 reserved to represent addresses assigned from the IPv4 address 609 space, it will be natural to reserve IPv6 addresses (for use as 610 routing domain identifiers) with 112 leading zero bits to uniquely 611 represent IPv4 Autonomous System numbers. 613 6. SECURITY CONSIDERATIONS 615 Use of tunneling may violate firewalls of underlying routing 616 infrastructure. 618 No other security issues are discussed in this paper. 620 7. REFERENCES 622 [1] Transition Mechanisms for IPv6 Hosts and Routers, 623 Bob Gilligan and Erik Nordmark, Sun Microsystems, 624 RFC 1933, April 8, 1996. 626 8. AUTHORS' ADDRESSES 628 Ross Callon 629 Bay Networks Inc. 630 3 Federal Street 631 Billerica, MA 01821 632 email: rcallon@baynetworks.com 634 Dimitry Haskin 635 Bay Networks, Inc. 636 2 Federal Street 637 Billerica, MA 01821 638 email: dhaskin@baynetworks.com