RFC 2185

RFC 2185 🎀 Routing Aspects Of IPv6 Transition

Title block tea ☕

Okay so this is RFC 2185, titled Routing Aspects Of IPv6 Transition 🦋. It's from September 1997 and the authors are R. Callon (Cascade Communications Co.) and D. Haskin (Bay Networks Inc.). It's classed as Informational 💅, so it's giving "here's some info," not a standard. The header doesn't list anything it obsoletes or updates, so there's nothing to report there ✨.

Status of this memo 📋

This memo gives info to the Internet community, and it does not specify an Internet standard of any kind. Distribution of this memo is unlimited 🌈.

Abstract 🎀

Okay so this doc gives an overview of the routing side of the IPv6 transition 🧚. It's built on the protocols in "Transition Mechanisms for IPv6 Hosts and Routers" [1], so you should already know those transition mechanisms before reading this, bestie 🫶.

The proposals in here come from the work of the Ngtrans working group 💜.

1. TERMINOLOGY ✨

Here's the vocab this paper uses 📖:

• node - a protocol module that implements IPv4 or IPv6.
• router - a node that forwards packets not explicitly addressed to itself.
• host - any node that is not a router.
• border router - a router that forwards packets across routing domain boundaries.
• link - a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below internet layer.
• interface - a node's attachment to a link.
• address - a network layer identifier for an interface or a group of interfaces.
• neighbors - nodes attached to the same link.
• routing domain - a collection of routers which coordinate routing knowledge using a single routing protocol.
• routing region (or just "region") - a collection of routers interconnected by a single internet protocol (e.g. IPv6) and coordinating their routing knowledge using routing protocols from a single internet protocol stack. A routing region may be a superset of a routing domain 🌸.
• tunneling - encapsulation of protocol A within protocol B, such that A treats B as though it were a datalink layer 🫧.
• reachability information - information describing the set of reachable destinations that can be used for packet forwarding decisions.
• routing information - same as reachability information.
• address prefix - the high-order bits in an address.
• routing prefix - address prefix that expresses destinations which have addresses with the matching address prefixes. It is used by routers to advertise what systems they are capable of reaching 📡.
• route leaking - advertisement of network layer reachability information across routing region boundaries.

2. ISSUES AND OUTLINE 🦋

Okay so this section gives the overview of the routing aspects of IPv4 to IPv6 transition. The approach here is designed to be compatible with the existing IPv6 transition mechanisms [1] 🔥.

During an extended IPv4-to-IPv6 transition period, IPv6-based systems have to coexist with the installed base of IPv4 systems 😭. In that dual internetworking protocol environment, both IPv4 and IPv6 routing infrastructure will be present. At first, deployed IPv6-capable domains might not be globally interconnected through IPv6-capable internet infrastructure, so they may need to communicate across IPv4-only routing regions. To get dynamic routing working in that mixed situation, there need to be mechanisms that globally distribute IPv6 network layer reachability information between dispersed IPv6 routing regions 🗺️. The same techniques can be used in later stages of the IPv4-to-IPv6 transition to route IPv4 packets between isolated IPv4-only routing regions over IPv6 infrastructure 🍓.

The IPng transition is a dual-IP-layer transition, with encapsulation added where it's necessary and appropriate 💜. The routing issues tied to this transition are:

(1) Routing for IPv4 packets

(2) Routing for IPv6 packets
        (2a) IPv6 packets with IPv6-native addresses
        (2b) IPv6 packets with IPv4-compatible addresses

(3) Operation of manually configured static tunnels

(4) Operation of automatic encapsulation
        (4a) Locating encapsulators
        (4b) Ensuring that routing is consist with
            encapsulation

The basic mechanisms for reaching these goals are: (i) Dual-IP-layer Route Computation; (ii) Manual configuration of point-to-point tunnels; and (iii) Route leaking to support automatic encapsulation 🧁.

Routing for IPv4 and IPv6 is basically dual-IP-layer routing 🌈. That means routes get calculated separately for IPv4 addresses and for IPv6 addressing. There's more on that in section 3.1 👀.

Tunnels (either IPv4 over IPv6, or IPv6 over IPv4) can be manually configured 🎀. For example, early in the transition this might let two IPv6 domains talk to each other over an IPv4 infrastructure. Manually configured static tunnels get treated as if they were a normal data link. More on that in section 3.2 ✨.

Automatic encapsulation is where the IPv4 tunnel endpoint address gets figured out from the IPv4 address embedded in the IPv4-compatible destination address of an IPv6 packet 🙈. That setup needs routes to stay consistent between IPv4 and IPv6 routing domains for destinations using IPv4-compatible addresses. Picture a packet that starts out as IPv6 but gets encapsulated in an IPv4 packet partway along its path from source to destination. That packet has to find an encapsulator at the correct spot on its path 📍. It also has to follow one consistent route for the entire path from source to destination 💅. More on this in section 3.3 🫶.

The mechanisms for tunneling IPv6 over IPv4 are defined in the transition mechanisms specification [1] ✨.

3. MORE DETAIL OF BASIC APPROACHES 🌸

3.1 Basic Dual-IP-layer Operation

In the basic dual-IP-layer transition scheme, routers can independently support IPv4 and IPv6 routing 🦋. Other parts of the transition, like DNS support and the source host choosing which packet format to send (IPv4 or IPv6), are covered in [1] 📖. Forwarding of IPv4 packets is based on routes learned by running IPv4-specific routing protocols. Forwarding of IPv6 packets (including IPv6 packets with IPv4-compatible addresses) works the same way, but with routes learned from IPv6-specific routing protocols 💖. So separate instances of routing protocols are used for IPv4 and for IPv6. Note that this could be two instances of OSPF and/or two instances of RIP, since both OSPF and RIP can support both IPv4 and IPv6 routing 🧚.

A minor enhancement would be to use a single instance of an integrated routing protocol for both IPv4 and IPv6 routing ⭐. When this was written, though, there was no protocol that had been enhanced to do that yet 🙃. That minor enhancement doesn't change the basic dual-IP-layer nature of the transition 💜.

For initial testing of IPv6 with IPv4-compatible addresses, it can be handy to forward IPv6 packets without running any IPv6-compatible routing protocol 🧪. In that case, a dual (IPv4 and IPv6) router could run routing protocols for IPv4 only. It forwards IPv4 packets based on routes learned from IPv4 routing protocols 🛣️. It also forwards IPv6 packets with an IPv4-compatible destination address based on the route for the associated IPv4 address 🎯. This approach has a couple of drawbacks 💀. (i) It doesn't specifically allow routing of IPv6 packets via IPv6-capable routers while avoiding and routing around IPv4-only routers. (ii) It doesn't produce routes for "non-compatible" IPv6 addresses 🥲. With this method the routing protocol doesn't tell the router whether neighboring routers are IPv6-compatible. Neighbor discovery may be used to figure that out 🔍. Then, if an IPv6 packet needs to be forwarded to an IPv4-only router, it can be encapsulated to the destination host 📦.

3.2 Manually Configured Static Tunnels

Tunneling techniques are already widely deployed for bridging non-IP network layer protocols (e.g. AppleTalk, CLNP, IPX) over IPv4 routed infrastructure 🌐. IPv4 tunneling is encapsulation of arbitrary packets inside IPv4 datagrams, which get forwarded over IPv4 infrastructure between tunnel endpoints 🎁. For a tunneled protocol, the tunnel looks like a single-hop link. Routers that set up a tunnel over a network layer infrastructure can interoperate over the tunnel as if it were a one-hop, point-to-point link 🪄. Once a tunnel is up, the routers at its endpoints can establish routing adjacencies and exchange routing information 🤝. How the encapsulation protocols actually work is out of scope for this paper, so check [1] for that 📚. Static point-to-point tunnels can also be set up between a host and a router, or between two hosts 🖥️. Again, each manually configured point-to-point tunnel is treated as if it were a simple point-to-point link 💅.

3.3 Automatic Tunnels

Automatic tunneling can be used when both the sending and destination nodes are connected by IPv4 routing 🎀. For automatic tunneling to work, both nodes have to be assigned IPv4-compatible IPv6 addresses 🪪. Automatic tunneling is especially useful when the source or destination hosts (or both) don't have any adjacent IPv6-capable router 🥺. Note that "adjacent router" here includes routers that are logically adjacent because of a manually configured point-to-point tunnel, which gets treated as if it's a simple point-to-point link 🔗.

With automatic tunneling, the resulting IPv4 packet is forwarded by IPv4 routers as a normal IPv4 packet, using IPv4 routes learned from routing protocols 📬. So there aren't any special IPv4 routing issues in this case ✅. There are routing issues, though, around how IPv6 routing has to work in a way that's compatible with automatic tunneling, and how tunnel endpoint addresses get selected during the encapsulation process 🧩. Automatic tunneling is useful from a source host to the destination host, from a source host to a router, and from a router to the destination host 🌷. Mechanisms for automatic tunneling from a router to another router are not currently defined 🚧.

3.3.1 Host to Host Automatic Tunneling 🎀

Okay so, if both the source and destination hosts use IPv4-compatible IPv6 addresses, automatic tunneling can cover the entire path from source host to destination host 💅. The source host wraps the IPv6 packet inside an IPv4 packet, and routers just forward it as a regular IPv4 packet all the way to the destination host. This means you can roll out IPv6-capable hosts before any routers get updated. That's such a main character move 🫶

A source host may make use of Host to Host automatic tunneling provided that the following are both true:

• the source address is an IPv4-compatible IPv6 address.
• the destination address is an IPv4-compatible IPv6 address.
• the source host does know of one or more neighboring IPv4-capable routers, or the source and destination are on the same subnet.

If all of these requirements are true, the source host can encapsulate the IPv6 packet in an IPv4 packet. The source IPv4 address gets extracted from the source IPv6 address, and the destination IPv4 address gets extracted from the destination IPv6 address 🦋

When host to host automatic tunneling is used, the packet gets forwarded as a normal IPv4 packet for its whole journey. It only gets decapsulated (i.e., the IPv4 header is removed) by the destination host. Iconic, honestly 👑

---

3.3.2 Host to Router Configured Default Tunneling 🌸

In some cases, "configured default" tunneling can be used to encapsulate the IPv6 packet on its way from the source host to an IPv6-backbone. BUT this needs the source host to be configured with an IPv4 address to use for tunneling to the backbone 😭

Configured default tunneling is especially useful when the source host doesn't know of any local IPv6-capable router (which means the packet can't be forwarded as a normal IPv6 packet directly over the link layer), and when the destination host doesn't have an IPv4-compatible IPv6 address (which means host to host tunneling is off the table) 💀

Host to router configured default tunneling may optionally also be used even when the host does know of a local IPv6 router. In this case, it's a policy decision whether the host prefers to send a native IPv6 packet to the IPv6-capable router, or prefers to send an encapsulated packet to the configured tunnel endpoint 🧚

Similarly, host to router default configured tunneling may be used even when the destination address is an IPv4-compatible IPv6 address. In this case, for example, a policy decision might be made to prefer tunneling for part of the path and native IPv6 for the rest, or to use tunneling for the entire path from source host to destination host. Choices, choices 💜

A source host may make use of host to router configured default tunneling provided that ALL of the following are true:

• the source address is an IPv4-compatible IPv6 address.
• the source host does know of one or more neighboring IPv4-capable routers
• the source host has been configured with an IPv4 address of a dual router which can serve as the tunnel endpoint.

If all of these requirements are true, the source host can encapsulate the IPv6 packet in an IPv4 packet. The source IPv4 address gets extracted from the source IPv6 address, and the destination IPv4 address corresponds to the configured address of the dual router that's acting as the tunnel endpoint ✨

When host to router configured default tunneling is used, the packet is forwarded as a normal IPv4 packet from the source host to the dual router serving as tunnel endpoint. The dual router decapsulates it, and then the tunnel endpoint forwards it as a normal IPv6 packet 🍓

3.3.2.1 Routing to the Endpoint for the Configured Default Tunnel 🦋

The dual router that's serving as the endpoint of the host to router configured default tunnel has to advertise reachability into IPv4 routing, enough to make sure the encapsulated packet gets forwarded to it 📡

The simplest approach is for a single IPv4 address to be assigned for use as a tunnel endpoint. One or more dual routers that have connectivity to the IPv6 backbone, and that are capable of serving as tunnel endpoint, advertise a host route to this address into IPv4 routing in the IPv4-only region. Each dual host in the associated IPv4-only region is configured with the address of this tunnel endpoint, and selects a route to this address for forwarding encapsulated packets to a tunnel endpoint (for example, the nearest tunnel endpoint, based on whatever metric(s) the local routing protocol is using) 🗺️

Sometimes there's a reason for specific hosts to prefer one of several tunnel endpoints, while still letting all the potential tunnel endpoints act as backups in case the preferred endpoint isn't reachable. In this case, each dual router with IPv6 backbone connectivity that's serving as a potential tunnel endpoint gets a unique IPv4 address taken from a single IPv4 address block. The block is assigned either to the organization administering the IPv4-only region, or to the organization administering the local part of the IPv6 backbone. In the likely case that there are much less than 250 such dual routers serving as tunnel endpoints, we suggest using multiple IPv4 addresses selected from a single 24-bit IPv4 address prefix for this purpose 🫶

Each dual router then advertises two routes into the IPv4 region: a host route corresponding to the tunnel endpoint address specifically assigned to it, and a standard (prefix) route to the associated IPv4 address block. Each dual host in the IPv4-only region is configured with a tunnel endpoint address that corresponds to the preferred tunnel endpoint for it to use. If the associated dual router is operating, the packet gets delivered to it based on the host route that it's advertising into the IPv4-only region. BUT if the associated dual router is down and some other dual router serving as a potential tunnel endpoint is operating, the packet gets delivered to the nearest operating tunnel endpoint 🌈

---

3.3.3 Router to Host Automatic Tunneling ✨

Sometimes the source host has direct connectivity to one or more IPv6-capable routers, but the destination host might not have direct connectivity to any IPv6-capable router. In this case, as long as the destination host has an IPv4-compatible IPv6 address, normal IPv6 forwarding can be used for part of the packet's path, and router to host tunneling can get the packet from an encapsulating dual router to the destination host 💖

Here's the tricky bit: the hard part is the IPv6 routing needed to deliver the IPv6 packet from the source host to the encapsulating router. For that to happen, the encapsulating router has to advertise reachability for the appropriate IPv4-compatible IPv6 addresses into the IPv6 routing region. With this approach, all IPv6 packets (including those with IPv4-compatible addresses) are routed using routes calculated from native IPv6 routing. That means encapsulating routers need to advertise specific route entries into IPv6 routing for any IPv4-compatible IPv6 addresses that belong to dual hosts reachable in a neighboring IPv4-only region. This needs manual configuration of the encapsulating routers, so you control which routes get injected into IPv6 routing protocols 🔥

Nodes in the IPv6 routing region use such a route to forward IPv6 packets along the routed path toward the router that injected (leaked) the route. At that point, the packets are encapsulated and forwarded to the destination host using normal IPv4 routing 🦋

Depending on how big the IPv4-only and dual routing regions are, leaking routes can be pretty simple, or it can get more complex. For example, consider a dual Internet backbone connected via one or two dual routers to an IPv4-only stub routing domain. In this case, there's likely already one summary address prefix being advertised into the Internet backbone to summarize IPv4 reachability to the stub domain. In that situation, the border routers would be configured to announce the IPv4 address prefix into IPv4 routing within the backbone, and also announce the corresponding IPv4-compatible IPv6 address prefix into IPv6 routing within the backbone 🌸

A harder case is the border between a major Internet backbone that's IPv4-only and a major Internet backbone that supports both IPv4 and IPv6. In this case, either (i) the entire IPv4 routing table gets fed into IPv6 routing in the dual routing domain (which implies doubling the size of the routing tables in the dual domain); or (ii) manual configuration is required to determine which of the addresses in the Internet routing table include one or more IPv6-capable systems, and only those addresses get advertised into IPv6 routing in the dual domain. Eek, that's a lot of routing tables 😭🌈

3.3.4 Example of How Automatic Tunnels May be Combined ✨

okay so, tunneling only really works if packets can go both ways 🦋 but the two directions can use different kinds of tunneling, depending on the local setup, what kind of address each host has, and the policies in use 💅

Table 1 is the cheat sheet 📋 for every combo of host capabilities, using one example set of policy choices. It's built straight from the automatic tunneling requirements we just went over 🎀

Now the example in table 1 assumes the source host sends native IPv6 whenever it can, rather than encapsulating 🌸 It also assumes host to host tunneling wins over host to router tunneling when tunneling is needed 🫶 Other policies would give other combos, so don't treat this table as the only possible answer 🧚

Because of one specific policy choice, the default sending rules in [1] may not be followed 🙈

Quick note: IPv6-capable hosts that don't have any local IPv6 router MUST be given an IPv4-compatible v6 address before they can use their IPv6 abilities 💖 That's why there are no table rows for IPv6-capable hosts with an incompatible address and no router connectivity 😭 Honestly those hosts could still talk to other IPv6 hosts on the same local network without a router ✨ BUT this doc is all about routing and the router side of the IPv6 transition, so direct host-to-host chats on the same link with no router in between are out of scope here 🌈

Also, table 1 doesn't cover manually configured point-to-point tunnels 🔥 Those get treated like normal point-to-point links 💜 So any two IPv6-capable devices with a manually configured tunnel between them can be considered directly connected 👑

-----------------+------------------+--------------------------
Host A           | Host B           | Result
-----------------+------------------+--------------------------
v4-compat. addr. | v4-compat. addr. | host to host tunneling
no local v6 rtr. | no local v6 rtr. | in both directions
-----------------+------------------+--------------------------
v4-compat. addr. | v4-compat. addr. | A->B: host to host tunnel
no local v6 rtr. | local v6 rtr.    | B->A: v6 forwarding plus
                 |                  |       rtr->host tunnel
-----------------+------------------+--------------------------
v4-compat. addr. | incompat. addr.  | A->B: host to rtr tunnel
no local v6 rtr. | local v6 rtr.    |       plus v6 forwarding
                 |                  | B->A: v6 forwarding plus
                 |                  |       rtr to host tunnel
-----------------+------------------+--------------------------
v4-compat. addr. | v4-compat. addr. | end to end native v6
local v6 rtr.    | local v6 rtr.    | in both directions
-----------------+------------------+--------------------------
v4-compat. addr. | incompat. addr.  | end to end native v6
local v6 rtr.    | local v6 rtr.    | in both directions
-----------------+------------------+--------------------------
incompat. addr.  | incompat. addr.  | end to end native v6
local v6 rtr.    | local v6 rtr.    | in both directions
-----------------+------------------+--------------------------

        Table 1: Summary of Automatic Tunneling Combinations

3.3.5 Example 🦋

Okay picture this 📸 Figure 2 shows a network with two regions, A and B 💅 Region A is dual, which means its routers can forward both IPv4 and IPv6 🌈 Region B is IPv4-only, so its routers can only route IPv4 🥺 The routers R1 through R4 are dual, and r5 through r9 are IPv4-only 🧚 Hosts H3 through H8 are dual, so H7 and H8 got upgraded to be IPv6-capable even though they sit in a region whose routers aren't IPv6-capable yet 😤 Meanwhile h1 and h2 are still IPv4-only 🙈

 .........................       .......................
 .                       .       .                     .
 .       h1              .       .              |-h2   .
 .       |               .       .              |      .
 .  H3---R1--------R2---------------r5----r9----+      .
 .       |         |     .       .        |     |-H7   .
 .       |         |     .       .        |            .
 .       |         |     .       .        |            .
 .  H4---R3--------R4---------------r6----r8-----H8    .
 .                       .       .                     .
 .........................       .......................
  Region A (Dual Routers)        Region B (IPv4-only Rtrs)

            Figure 2: Example of Automatic Tunneling

Consider a packet from h1 to H8 🎀 Since h1 is IPv4-only, it sends an IPv4 packet 💖 That packet goes through regions A and B as a normal IPv4 packet the whole way 🫶 Routing uses normal IPv4 methods, with no change from today's IPv4 Internet (modulo normal advances in the operation of IPv4, of course) 🌸 Now the return trip, a packet from H8 to h1, works the same way: H8 sends an IPv4 packet and it gets forwarded as a normal IPv4 packet the entire path 🦋

Next, a packet from H3 to H8 💅 H8 is in an IPv4-only routing domain, so we can assume H8 uses an IPv4-compatible IPv6 address 🧚 Since both source and destination are IPv6-capable, H3 can send an IPv6 packet to H8 ✨ The packet gets forwarded as an IPv6 packet as far as R2 (or R4) 🌈

Then Router R2 (or R4) encapsulates the full IPv6 packet in an IPv4 header to deliver it to H8 🔥 For this to work, routing of IPv6 within region A has to be able to deliver this packet correctly to R2 (or R4) 💜 As explained in section 3.3, routers R2 and R4 may inject routes to IPv4-compatible IPv6 addresses into the IPv6 routing used within region A, matching the routes that are available via IPv4 routing within region B 👑

Now the return packet from H8 to H3 💖 Again, both source and destination are IPv6-capable, so H8 may transmit an IPv6 packet 🎀 But H8 has no direct connectivity to an IPv6-capable router, so H8 MUST use an automatic tunnel 😭 Which form of automatic tunnel gets used depends on the type of address assigned to H3 🫶

If H3 is assigned an IPv4-compatible address, then the requirements in section 3.3.1 are all satisfied ✨ In that case H8 can encapsulate the full IPv6 packet in an IPv4 header, using a source IPv4 address pulled from H8's IPv6 address and a destination IPv4 address pulled from H3's IPv6 address 🦋

If H3 has an IPv6-only address, then H8 can't extract an IPv4 address from H3's IPv6 address to use as the destination tunnel address 🙈 So in this case H8 MUST use host to router tunneling, as specified in section 3.3.2 💅 Here, one or both of R2 and R4 MUST have been configured with a tunnel endpoint IPv4 address (R2 and R4 may use either the same address or different addresses for this purpose) 🧚 R2 and/or R4 then advertise reachability to the tunnel endpoint address to r5 and r6 (respectively), which advertise this reachability information into region B ✨ Also, H8 MUST have been configured to know which tunnel endpoint address to use for host to router tunneling 🌈 That way the IPv6 packet, encapsulated in an IPv4 header, gets transmitted as far as the border router R2 or R4 🔥 The border router then strips off the IPv4 header and forwards the remaining IPv6 packet as a normal IPv6 packet using the normal IPv6 routing used in region A 💜

4. SECURITY CONSIDERATIONS 🚨

Use of tunneling may violate firewalls of underlying routing infrastructure 💀 Like, this is a big deal, so please keep it in mind 😭

No other security issues are discussed in this paper 🫶

5. REFERENCES 📚

[1] Gilligan, B. and E. Nordmark. Transition Mechanisms for IPv6
    Hosts and Routers, Sun Microsystems, RFC 1933,  April 1996.

6. AUTHORS' ADDRESSES 🎀

Ross Callon
Cascade Communications Co.
5 Carlisle Road
Westford, MA 01886
email: rcallon@casc.com
Dimitry Haskin
Bay Networks, Inc.
2 Federal Street
Billerica, MA 01821
email: dhaskin@baynetworks.com