RFC 1933

Transition Mechanisms for IPv6 Hosts and Routers

📅 published April 1996, from ietf

Bestie, this is the RFC that tells IPv6 nodes how to get along with the IPv4 crowd. 🎀✨

Title block facts: This is RFC 1933, Transition Mechanisms for IPv6 Hosts and Routers 💖. It was written by R. Gilligan and E. Nordmark at Sun Microsystems, Inc., in the Network Working Group, dated April 1996. It's on the Standards Track 🦋. It doesn't obsolete or update anything, since the title block doesn't list any.

Status of This Memo ✨

okay so this doc is an Internet standards track protocol spec for the Internet community 🌸. It asks for discussion and suggestions for improvements 💬. If you want the current standardization state of this protocol, check the latest edition of "Internet Official Protocol Standards" (STD 1) 📚. Distribution is unlimited, so share it with everyone 💅.

Abstract

this one's giving "compatibility era" 🫶. It defines IPv4 compatibility mechanisms that IPv6 hosts and routers can implement 🧚. The mechanisms are complete implementations of both IPv4 and IPv6, plus tunneling IPv6 packets over IPv4 routing infrastructure 🌈. The goal is for IPv6 nodes to stay fully compatible with IPv4, which should make deploying IPv6 way easier and help the whole Internet eventually move over to IPv6 ✨.

1. Introduction ✨

the key to a successful IPv6 transition is being compatible with the huge installed base of IPv4 hosts and routers 👑. Staying compatible with IPv4 while rolling out IPv6 makes the whole transition smoother 🍓. This spec defines a set of mechanisms that IPv6 hosts and routers MAY implement so they can be compatible with IPv4 hosts and routers 💜.

These mechanisms are meant for IPv6 hosts and routers that need to talk to IPv4 hosts and use IPv4 routing infrastructure 🦋. We expect most nodes on the Internet will need this compatibility for a long time, maybe even forever 😭.

BUT, IPv6 might be used in some environments where IPv4 interop isn't needed 🙈. IPv6 nodes built for those environments need not use or even implement these mechanisms 💅.

The mechanisms in here include:

  • Dual IP layer. Full support for both IPv4 and IPv6 in hosts and routers 🎀.
  • IPv6 over IPv4 tunneling. Wrapping IPv6 packets inside IPv4 headers so they can ride across IPv4 routing infrastructure 🚇. There are two types: configured and automatic 🫧.

More transition and compatibility mechanisms might show up later, and they'll get their own documents 🔮.

1.2. Terminology

these are the terms used in this doc, bestie 📖.

Types of Nodes

  • IPv4-only node: a host or router that only implements IPv4 🙃. An IPv4-only node doesn't understand IPv6 💀. The installed base of IPv4 hosts and routers that exist before the transition starts are IPv4-only nodes 🧱.
  • IPv6/IPv4 node: a host or router that implements both IPv4 and IPv6 🌸.
  • IPv6-only node: a host or router that implements IPv6 and does NOT implement IPv4 🌙. How IPv6-only nodes work isn't covered here 🤷‍♀️.
  • IPv6 node: any host or router that implements IPv6 👑. IPv6/IPv4 nodes and IPv6-only nodes are both IPv6 nodes ✨.
  • IPv4 node: any host or router that implements IPv4 🫶. IPv6/IPv4 nodes and IPv4-only nodes are both IPv4 nodes 💖.

Types of IPv6 Addresses

  • IPv4-compatible IPv6 address: an IPv6 address assigned to an IPv6/IPv4 node that has the high-order 96-bit prefix 0:0:0:0:0:0 and an IPv4 address in the low-order 32 bits 🧚. These are used by the automatic tunneling mechanism 🦋.
  • IPv6-only address: everything else in the IPv6 address space 🌈. It's an IPv6 address with a prefix other than 0:0:0:0:0:0 💅.

Techniques Used in the Transition

  • IPv6-over-IPv4 tunneling: wrapping IPv6 packets inside IPv4 so they can cross IPv4 routing infrastructure 🚀.
  • IPv6-in-IPv4 encapsulation: this is just another name for IPv6-over-IPv4 tunneling 🔁.
  • Configured tunneling: IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint address comes from configuration info on the encapsulating node ⚙️.
  • Automatic tunneling: IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint address comes from the IPv4 address embedded in the IPv4-compatible destination address of the IPv6 packet 🪄.

1.3. Structure of this Document

the rest of the doc is split into three sections 🗂️:

  • Section 2 talks about the IPv4-compatible address format 🎀.
  • Section 3 talks about how nodes with a dual IP layer work, aka IPv6/IPv4 nodes 💜.
  • Section 4 talks about IPv6-over-IPv4 tunneling 🦋.

2. Addressing

the automatic tunneling mechanism uses a special kind of IPv6 address called an "IPv4-compatible" address 🪞. It's identified by an all-zeros 96-bit prefix, and it holds an IPv4 address in the low-order 32 bits 🫧. Here's the structure:

|              96-bits                 |   32-bits    |
+--------------------------------------+--------------+
|            0:0:0:0:0:0               | IPv4 Address |
+--------------------------------------+--------------+

         IPv4-Compatible IPv6 Address Format

IPv4-compatible addresses get assigned to IPv6/IPv4 nodes that support automatic tunneling 🌸. Nodes configured with IPv4-compatible addresses MAY use the complete address as their IPv6 address, and use the embedded IPv4 address as their IPv4 address 🧚.

The rest of the IPv6 address space (so every address with a 96-bit prefix other than 0:0:0:0:0:0) is called "IPv6-only Addresses" 🌙.

3. Dual IP Layer 💅

the easiest way for IPv6 nodes to stay compatible with IPv4-only nodes is to provide a complete IPv4 implementation 👑. IPv6 nodes that do that, on top of their IPv6 implementation, are called "IPv6/IPv4 nodes" 🫶. They can send and receive both IPv4 and IPv6 packets 🦋. They can directly interoperate with IPv4 nodes using IPv4 packets, and directly interoperate with IPv6 nodes using IPv6 packets 💖.

The dual IP layer technique MAY or MAY NOT be used together with the IPv6-over-IPv4 tunneling techniques described in section 4 🌈. An IPv6/IPv4 node that supports tunneling MAY support only configured tunneling, or both configured and automatic tunneling 🎀. So three configurations are possible 🔮:

  • IPv6/IPv4 node that does not perform tunneling 🙂.
  • IPv6/IPv4 node that performs configured tunneling only 🛠️.
  • IPv6/IPv4 node that performs configured tunneling and

automatic tunneling 🧚.

3.1. Address Configuration

okay, since they support both protocols, IPv6/IPv4 nodes MAY be configured with both IPv4 and IPv6 addresses 🫧. The two addresses can be related, but that's not required 🤷‍♀️. IPv6/IPv4 nodes MAY even be configured with IPv6 and IPv4 addresses that are totally unrelated 🙈.

Nodes that perform automatic tunneling are configured with IPv4-compatible IPv6 addresses ✨. These can be seen as single addresses that work as both IPv6 and IPv4 addresses 💜. The entire 128-bit IPv4-compatible IPv6 address is used as the node's IPv6 address, while the IPv4 address in the low-order 32 bits is the node's IPv4 address 🦋.

IPv6/IPv4 nodes MAY use the stateless IPv6 address configuration mechanism [5] or DHCP for IPv6 [3] to get their IPv6 address 🌸. These mechanisms MAY provide either IPv4-compatible or IPv6-only IPv6 addresses 🌈.

IPv6/IPv4 nodes MAY use IPv4 mechanisms to get their IPv4 addresses 🎀.

IPv6/IPv4 nodes that perform automatic tunneling MAY also get their IPv4-compatible IPv6 addresses from another source: IPv4 address configuration protocols 🔮. A node MAY use any IPv4 address configuration mechanism to get its IPv4 address, then "map" that address into an IPv4-compatible IPv6 address by prepending it with the 96-bit prefix 0:0:0:0:0:0 🧚. This mode lets IPv6/IPv4 nodes "leverage" the installed base of IPv4 address configuration servers 💅. It's especially handy where IPv6 routers and address configuration servers haven't been deployed yet 🫶.

Here's the exact algorithm for getting an IPv4-compatible address with IPv4-based address configuration protocols 📜:

  1. The IPv6/IPv4 node uses standard IPv4 mechanisms or protocols to get its own IPv4 address 🧭. These include:
    • The Dynamic Host Configuration Protocol (DHCP) [2] 📡
    • The Bootstrap Protocol (BOOTP) [1] 🥾
    • The Reverse Address Resolution Protocol (RARP) [9] 🔁
    • Manual configuration ✍️
    • Any other mechanism which accurately yields the node's own IPv4 address 🎯
  2. The node uses this address as its IPv4 address 💖.
  3. The node prepends the 96-bit prefix 0:0:0:0:0:0 to the 32-bit IPv4 address it got in step (1) 🌸. The result is an IPv4-compatible IPv6 address with the node's own IPv4 address embedded in the low-order 32 bits 🧚. The node uses this address as its own IPv6 address 👑.

3.1.1. IPv4 Loopback Address

lots of IPv4 implementations treat 127.0.0.1 as a "loopback address", which is an address for reaching services on the local machine 🔄. Per the host requirements specification [10], section 3.2.1.3, IPv4 packets addressed from or to the loopback address are not to be sent onto the network; they MUST remain entirely within the node 🚫. IPv6/IPv4 implementations MAY treat the IPv4-compatible IPv6 address ::127.0.0.1 as an IPv6 loopback address 🪞. Packets with this address SHOULD also remain entirely within the node, and not be transmitted onto the network 🔒.

3.2. DNS

the Domain Naming System (DNS) is used by both IPv4 and IPv6 to map hostnames to addresses 🗺️. A new resource record type called "AAAA" has been defined for IPv6 addresses [6] 🎀. Since IPv6/IPv4 nodes MUST be able to interoperate directly with both IPv4 and IPv6 nodes, they MUST provide resolver libraries that can handle IPv4 "A" records as well as IPv6 "AAAA" records 💅✨.

3.2.1. Handling Records for IPv4-Compatible Addresses 💅

okay so when an IPv4-compatible IPv6 address gets assigned to an IPv6/IPv4 host that supports automatic tunneling, both an A record and an AAAA record show up in the DNS 🎀. The AAAA record holds the full IPv4-compatible IPv6 address, while the A record holds the low-order 32 bits of that address. The AAAA record is needed so queries from IPv6 hosts can get satisfied ✨, and the A record is needed so IPv4-only hosts (whose resolver libraries only support the A record type) can still locate the host 🫶.

DNS resolver libraries on IPv6/IPv4 nodes MUST be capable of handling both AAAA and A records 💖. Here's the tea though: when a query finds an AAAA record holding an IPv4-compatible IPv6 address and an A record holding the matching IPv4 address, the resolver library does not necessarily have to return both addresses. It has three options:

  • Return only the IPv6 address to the application.
  • Return only the IPv4 address to the application.
  • Return both addresses to the application.

The choice of which address type to return in this case (or, if both are returned, which order they're listed in) can affect what type of IP traffic gets generated 👑. If the IPv6 address is returned, the node will communicate with that destination using IPv6 packets (in most cases encapsulated in IPv4). If the IPv4 address is returned, the communication will use IPv4 packets.

The way DNS resolver implementations handle these redundant records for IPv4-compatible addresses may depend on whether that implementation supports automatic tunneling, or whether it's enabled 🦋. For example, an implementation that doesn't support automatic tunneling would not return IPv4-compatible IPv6 addresses to applications, because those destinations are generally only reachable via tunneling 🙈. On the other hand, implementations where automatic tunneling is supported and enabled MAY elect to return only the IPv4-compatible IPv6 address and not the IPv4 address 🌈.

4. IPv6-over-IPv4 Tunneling 🧚

In most deployment scenarios, the IPv6 routing infrastructure gets built up over time 🌸. While the IPv6 infrastructure is being deployed, the existing IPv4 routing infrastructure can stay functional and can be used to carry IPv6 traffic. Tunneling is the way to use an existing IPv4 routing infrastructure to carry IPv6 traffic. Literally the whole point 💜.

IPv6/IPv4 hosts and routers can tunnel IPv6 datagrams over regions of the IPv4 routing topology by encapsulating them within IPv4 packets. Tunneling can be used in a bunch of different ways:

  • Router-to-Router. IPv6/IPv4 routers interconnected by an IPv4 infrastructure can tunnel IPv6 packets between themselves. In this case, the tunnel spans one segment of the end-to-end path that the IPv6 packet takes.
  • Host-to-Router. IPv6/IPv4 hosts can tunnel IPv6 packets to an intermediary IPv6/IPv4 router that's reachable via an IPv4 infrastructure. This type of tunnel spans the first segment of the packet's end-to-end path.
  • Host-to-Host. IPv6/IPv4 hosts that are interconnected by an IPv4 infrastructure can tunnel IPv6 packets between themselves. In this case, the tunnel spans the entire end-to-end path the packet takes.
  • Router-to-Host. IPv6/IPv4 routers can tunnel IPv6 packets to their final destination IPv6/IPv4 host. This tunnel spans only the last segment of the end-to-end path.

Tunneling techniques are usually classified by the mechanism the encapsulating node uses to figure out the address of the node at the end of the tunnel 🎀. In the first two methods above (router-to-router and host-to-router), the IPv6 packet is being tunneled to a router. The endpoint of this type of tunnel is an intermediary router, which MUST decapsulate the IPv6 packet and forward it on to its final destination. When tunneling to a router, the endpoint of the tunnel is different from the destination of the packet being tunneled. So the addresses in the IPv6 packet being tunneled don't give you the IPv4 address of the tunnel endpoint. Instead, the tunnel endpoint address MUST be determined from configuration information on the node doing the tunneling. We use the term "configured tunneling" to describe this type of tunneling, where the endpoint is explicitly configured ⚙️.

In the last two methods (host-to-host and router-to-host), the IPv6 packet is tunneled all the way to its final destination 🦋.

The tunnel endpoint is the node that the IPv6 packet is addressed to. Since the endpoint of the tunnel is the destination of the IPv6 packet, the tunnel endpoint can be determined from the destination IPv6 address of that packet. If that address is an IPv4-compatible address, then the low-order 32 bits hold the IPv4 address of the destination node, and that can be used as the tunnel endpoint address. This technique avoids the need to explicitly configure the tunnel endpoint address. Deriving the tunnel endpoint address from the embedded IPv4 address in the packet's IPv6 address is called "automatic tunneling" ✨.

The two techniques (automatic and configured) differ mainly in how they determine the tunnel endpoint address. Most of the underlying mechanisms are the same:

  • The entry node of the tunnel (the encapsulating node) creates an encapsulating IPv4 header and transmits the encapsulated packet.
  • The exit node of the tunnel (the decapsulating node) receives the encapsulated packet, removes the IPv4 header, updates the IPv6 header, and processes the received IPv6 packet.
  • The encapsulating node MAY need to maintain soft state information for each tunnel, recording parameters such as the MTU of the tunnel, so it can process IPv6 packets forwarded into the tunnel. Since the number of tunnels any one host or router may be using can grow to be quite large, this state information can be cached and discarded when it's not in use 🧁.

The next section covers the common mechanisms that apply to both types of tunneling. Later sections explain how the tunnel endpoint address gets determined for automatic and configured tunneling 💖.

4.1. Common Tunneling Mechanisms

Here's how an IPv6 datagram gets encapsulated in IPv4:

                                     +-------------+
                                     |    IPv4     |
                                     |   Header    |
     +-------------+                 +-------------+
     |    IPv6     |                 |    IPv6     |
     |   Header    |                 |   Header    |
     +-------------+                 +-------------+
     |  Transport  |                 |  Transport  |
     |   Layer     |      ===>       |   Layer     |
     |   Header    |                 |   Header    |
     +-------------+                 +-------------+
     |             |                 |             |
     ~    Data     ~                 ~    Data     ~
     |             |                 |             |
     +-------------+                 +-------------+

                   Encapsulating IPv6 in IPv4

Besides adding an IPv4 header, the encapsulating node also has to deal with some trickier stuff 😭:

  • Determine when to fragment and when to report an ICMP "packet too big" error back to the source.
  • How to reflect IPv4 ICMP errors from routers along the tunnel path back to the source as IPv6 ICMP errors.

We'll get into those issues in the following sections 🫶.

4.1.1. Tunnel MTU and Fragmentation 🔥

The encapsulating node could treat encapsulation as IPv6 using IPv4 as a link layer with a very large MTU (65535-20 bytes to be exact, since 20 bytes of "extra" space are needed for the encapsulating IPv4 header). The encapsulating node would then only need to report IPv6 ICMP "packet too big" errors back to the source for packets that exceed this MTU. However, that scheme would be inefficient for two reasons:

  1. It would result in more fragmentation than needed. IPv4 layer fragmentation SHOULD be avoided because of the performance problems caused by the loss unit being smaller than the retransmission unit [11].
  2. Any IPv4 fragmentation happening inside the tunnel would have to be reassembled at the tunnel endpoint. For tunnels that terminate at a router, this would require extra memory to reassemble the IPv4 fragments into a complete IPv6 packet before that packet could be forwarded onward 🧠.

Fragmentation inside the tunnel can be cut down to a minimum if the encapsulating node tracks the IPv4 Path MTU across the tunnel, using the IPv4 Path MTU Discovery Protocol [8] and recording the resulting path MTU 🌟. The IPv6 layer in the encapsulating node can then view a tunnel as a link layer with an MTU equal to the IPv4 path MTU, minus the size of the encapsulating IPv4 header.

Heads up: this doesn't completely eliminate IPv4 fragmentation when the IPv4 path MTU would result in an IPv6 MTU less than 576 bytes. (Any link layer used by IPv6 has to have an MTU of at least 576 bytes [4].) In this case the IPv6 layer has to "see" a link layer with an MTU of 576 bytes, and the encapsulating node has to use IPv4 fragmentation in order to forward the 576 byte IPv6 packets 💀.

The encapsulating node can use the following algorithm to decide when to forward an IPv6 packet that's larger than the tunnel's path MTU using IPv4 fragmentation, and when to return an IPv6 ICMP "packet too big" message:

     if (IPv4 path MTU - 20) is less than or equal to 576
             if packet is larger than 576 bytes
                     Send IPv6 ICMP "packet too big" with MTU = 576.
                     Drop packet.
             else
                     Encapsulate but do not set the Don't Fragment
                     flag in the IPv4 header. The resulting IPv4
                     packet might be fragmented by the IPv4 layer on
                     the encapsulating node or by some router along
                     the IPv4 path.
             endif
     else
             if packet is larger than (IPv4 path MTU - 20)
                     Send IPv6 ICMP "packet too big" with
                     MTU = (IPv4 path MTU - 20).
                     Drop packet.
             else
                     Encapsulate and set the Don't Fragment flag
                     in the IPv4 header.
             endif
     endif

Encapsulating nodes with a large number of tunnels might not be able to store the IPv4 Path MTU for all of them 🌷. Those nodes can, at the cost of extra fragmentation in the network, skip the IPv4 Path MTU algorithm across the tunnel and instead use the MTU of the link layer (under IPv4) in the algorithm above, in place of the IPv4 path MTU.

In this case, the Don't Fragment bit MUST NOT be set in the encapsulating IPv4 header 🚫.

4.1.2. Hop Limit ✨

okay so IPv6-over-IPv4 tunnels are modeled as "single-hop" 🦋 That means the IPv6 hop limit gets decremented by 1 when an IPv6 packet goes through the tunnel. The whole point is to hide the tunnel. It's totally opaque to network users and can't be spotted by diagnostic tools like traceroute 🙈

The single-hop model works by having the encapsulating and decapsulating nodes handle the IPv6 hop limit field the same way they would if they were forwarding a packet onto any other datalink. So they decrement the hop limit by 1 when forwarding an IPv6 packet. (The originating node and final destination do not decrement the hop limit.) ✨

The TTL of the encapsulating IPv4 header is selected in an implementation dependent manner. The current suggested value is published in the "Assigned Numbers RFC. Implementations may provide a mechanism to allow the administrator to configure the IPv4 TTL 💅

4.1.3. Handling IPv4 ICMP errors 🚨

bestie, when the encapsulating node sends encapsulated packets into the tunnel, it might get IPv4 ICMP error messages back from IPv4 routers inside the tunnel. These packets are addressed to the encapsulating node, because it's the IPv4 source of the encapsulated packet 📬

The ICMP "packet too big" error messages are handled according to IPv4 Path MTU Discovery [8], and the resulting path MTU is recorded in the IPv4 layer. IPv6 then uses that recorded path MTU to figure out if an IPv6 ICMP "packet too big" error has to be generated, as described in section 4.1.1. 🧚

Handling every other type of ICMP error message depends on how much information is included in the "packet in error" field, which holds the encapsulated packet that caused the error.

Many older IPv4 routers only return 8 bytes of data beyond the IPv4 header of the packet in error. That's not enough to include the address fields of the IPv6 header 😭 More modern IPv4 routers may return enough data beyond the IPv4 header to include the entire IPv6 header, and possibly even the data beyond that. 🌸

If the offending packet includes enough data, the encapsulating node may extract the encapsulated IPv6 packet and use it to generate an IPv6 ICMP message directed back to the originating IPv6 node, as shown below:

        +--------------+
        | IPv4 Header  |
        | dst = encaps |
        |       node   |
        +--------------+
        |     ICMP     |
        |    Header    |
 - -    +--------------+
        | IPv4 Header  |
        | src = encaps |
IPv4    |       node   |
        +--------------+   - -
Packet  |    IPv6      |
        |    Header    |   Original IPv6
 in     +--------------+   Packet -
        |  Transport   |   Can be used to
Error   |    Header    |   generate an
        +--------------+   IPv6 ICMP
        |              |   error message
        ~     Data     ~   back to the source.
        |              |
 - -    +--------------+   - -

IPv4 ICMP Error Message Returned to Encapsulating Node

4.1.4. IPv4 Header Construction 🎀

when you encapsulate an IPv6 packet in an IPv4 datagram, the IPv4 header fields get set like this, no cap 💖

  • Version: 4
  • IP Header Length in 32-bit words: 5. There are no IPv4 options in the encapsulating header, so it's just the basic size 🧸
  • Type of Service: 0
  • Total Length: the payload length from the IPv6 header plus the length of the IPv6 and IPv4 headers. That's a constant 60 bytes, always 📏
  • Identification: generated uniquely, the same way as for any IPv4 packet the system transmits 🔢
  • Flags: set the Don't Fragment (DF) flag as specified in section 4.1.1. Set the More Fragments (MF) bit as necessary if fragmenting 🚩
  • Fragment offset: set as necessary if fragmenting 🧩
  • Time to Live: set in an implementation-specific manner ⏳
  • Protocol: 41 (the assigned payload type number for IPv6) 🦋
  • Header Checksum: calculate the checksum of the IPv4 header 🧮
  • Source Address: the IPv4 address of the outgoing interface of the encapsulating node 📤
  • Destination Address: the IPv4 address of the tunnel endpoint 📥

Any IPv6 options are preserved in the packet, sitting right after the IPv6 header 🫶

4.1.5. Decapsulating IPv6-in-IPv4 Packets 🔓

when an IPv6/IPv4 host or a router gets an IPv4 datagram addressed to one of its own IPv4 addresses, and the protocol field is 41, it strips off the IPv4 header and hands the IPv6 datagram to its IPv6 layer code. Main character energy 👑

The decapsulation looks like this:

+-------------+
|    IPv4     |
|   Header    |
+-------------+                 +-------------+
|    IPv6     |                 |    IPv6     |
|   Header    |                 |   Header    |
+-------------+                 +-------------+
|  Transport  |                 |  Transport  |
|   Layer     |      ===>       |   Layer     |
|   Header    |                 |   Header    |
+-------------+                 +-------------+
|             |                 |             |
~    Data     ~                 ~    Data     ~
|             |                 |             |
+-------------+                 +-------------+

            Decapsulating IPv6 from IPv4

When decapsulating the IPv6-in-IPv4 packet, the IPv6 header is not modified. If the packet is forwarded afterwards, its hop limit gets decremented by one 💅

The encapsulating IPv4 header is discarded 🗑️

The decapsulating node does IPv4 reassembly before it decapsulates the IPv6 packet. All IPv6 options are preserved, even if the encapsulating IPv4 packet got fragmented 🧵

After the IPv6 packet is decapsulated, it's processed the same way as any received IPv6 packet. Iconic ✨

4.2. Configured Tunneling 🗺️

in configured tunneling, the tunnel endpoint address comes from configuration information in the encapsulating node. For each tunnel, the encapsulating node must store the tunnel endpoint address. When an IPv6 packet goes over a tunnel, the tunnel endpoint address configured for that tunnel gets used as the destination address in the encapsulating IPv4 header 📍

The decision about which packets to tunnel is usually made by routing information on the encapsulating node. That's usually done with a routing table, which directs packets based on their destination address using the prefix mask and match technique 🧠

4.2.1. Default Configured Tunnel 🌈

Nodes connected to IPv4 routing infrastructure can use a configured tunnel to reach an IPv6 "backbone" 🦋 If the IPv4 address of an IPv6/IPv4 router bordering the backbone is known, a tunnel can be configured to that router. That tunnel can go into the routing table as a "default route." So every IPv6 destination address matches the route and could potentially traverse the tunnel 🌸 Since the "mask length" of such a default route is zero, it only gets used if there are no other routes with a longer mask that match the destination.

The tunnel endpoint address of a default tunnel could be the IPv4 address of one IPv6/IPv4 router at the border of the IPv6 backbone. Or, the tunnel endpoint could be an IPv4 "anycast address." With this approach, multiple IPv6/IPv4 routers at the border advertise IPv4 reachability to the same IPv4 address. All of these routers accept packets to this address as their own, and they'll decapsulate IPv6 packets tunneled to it. When an IPv6/IPv4 node sends an encapsulated packet to this address, it gets delivered to only one of the border routers, but the sending node won't know which one. The IPv4 routing system will generally carry the traffic to the closest router 🧭

Using a default tunnel to an IPv4 "anycast address" gives you a high degree of robustness, since multiple border routers can be provided. With the normal fallback mechanisms of IPv4 routing, traffic automatically switches to another router when one goes down 🛟✨

4.3. Automatic Tunneling 🪄

in automatic tunneling, the tunnel endpoint address is determined from the packet being tunneled. The destination IPv6 address in the packet must be an IPv4-compatible address. If it is, the IPv4 address component of that address -- the low-order 32-bits -- gets extracted and used as the tunnel endpoint address. IPv6 packets that are not addressed to an IPv4-compatible address can not be tunneled using automatic tunneling 🙅‍♀️

IPv6/IPv4 nodes need to figure out which IPv6 packets can be sent via automatic tunneling. One technique is to use the IPv6 routing table to direct automatic tunneling. An implementation can have a special static routing table entry for the prefix 0:0:0:0:0:0/96. (That is, a route to the all-zeros prefix with a 96-bit mask.) Packets that match this prefix get sent to a pseudo-interface driver, which performs automatic tunneling. Since all IPv4-compatible IPv6 addresses match this prefix, all packets to those destinations will be auto-tunneled 💜

4.4. Default Sending Algorithm 🧁

This section presents a combined IPv4 and IPv6 sending algorithm that IPv6/IPv4 nodes can use. The algorithm can decide when to send IPv4 packets, when to send IPv6 packets, and when to do automatic and configured tunneling. It shows how the techniques of dual IP layer, configured tunneling, and automatic tunneling can be used together. Note that is just an example to show how the techniques can be combined. IPv6/IPv6 implementations may provide different algorithms. This algorithm has the following properties:

  • Sends IPv4 packets to all IPv4 destinations.
  • Sends IPv6 packets to all IPv6 destinations on the same link.
  • Using automatic tunneling, sends IPv6 packets encapsulated in IPv4 to IPv6 destinations with IPv4-compatible addresses that are located off-link.
  • Sends IPv6 packets to IPv6 destinations located off-link when IPv6 routers are present.
  • Using the default IPv6 tunnel, sends IPv6 packets encapsulated in IPv4 to IPv6 destinations with IPv6-only addresses when no IPv6 routers are present. 🌟

Okay so, the default sending algorithm is basically a decision tree for "where does this packet go and what does it look like," and it's giving very organized. 🎀 Here's how it goes, bestie:

  • 1) First check: is the end node's address an IPv4 address? If yes, then:
    • 1.1) If the destination is on an attached link, send an IPv4 packet addressed to the end node.
    • 1.2) If the destination is off-link, then:
      • 1.2.1) If there's an IPv4 router on the link, send an IPv4 format packet. The IPv4 destination address is the end node's IPv4 address, and the datalink address is the IPv4 router's datalink address. 🦋
      • 1.2.2) Else, the destination is "unreachable" because it's off-link and there are no on-link routers. Rip. 💀
  • 2) Next, is the end node's address an IPv4-compatible IPv6 address (basically, it has the 0:0:0:0:0:0 prefix)? If yes, then:
    • 2.1) If the destination is on an attached link, send an IPv6 format packet (not encapsulated). The IPv6 destination address is the end node's IPv6 address, and the datalink address is the end node's datalink address. ✨
    • 2.2) If the destination is off-link, then:
      • 2.2.1) If there's an IPv4 router on an attached link, send an IPv6 packet encapsulated in IPv4. The IPv6 destination address is the end node's address. The IPv4 destination address is the low-order 32-bits of the end node's address. The datalink address is the IPv4 router's datalink address. 🌸
      • 2.2.2) Else, if there's an IPv6 router on an attached link, send an IPv6 format packet. The IPv6 destination address is the end node's IPv6 address, and the datalink address is the IPv6 router's datalink address.
      • 2.2.3) Else, the destination is "unreachable" because it's off-link and there are no on-link routers. 😭
  • 3) Last one: is the end node's address an IPv6-only address? If yes, then:
    • 3.1) If the destination is on an attached link, send an IPv6 format packet. The IPv6 destination address is the end node's IPv6 address, and the datalink address is the end node's datalink address. 💖
    • 3.2) If the destination is off-link, then:
      • 3.2.1) If there's an IPv6 router on an attached link, send an IPv6 format packet. The IPv6 destination address is the end node's IPv6 address, and the datalink address is the IPv6 router's datalink address.
      • 3.2.2) Else, if the destination is reachable via a configured tunnel, and there's an IPv4 router on an attached link, send an IPv6 packet encapsulated in IPv4. The IPv6 destination address is the end node's address. The IPv4 destination address is the configured IPv4 address of the tunnel endpoint. The datalink address is the IPv4 router's datalink address. 🧚
      • 3.2.3) Else, the destination is "unreachable" because it's off-link and there are no on-link IPv6 routers. Periodt. 💅

Here's the whole thing summarized in a table, so you can just glance at it like a cheat sheet. 🍓

End         | End     | IPv4    | IPv6    | Packet |      |      |
Node        | Node    | Router  | Router  | Format | IPv6 | IPv4 | DLink
Address     | On      | On      | On      | To     | Dest | Dest | Dest
Type        | Link?   | Link?   | Link?   | Send   | Addr | Addr | Addr
------------+---------+---------+---------+--------+------+------+------
IPv4        | Yes     |  N/A    |  N/A    | IPv4   |  N/A |  E4  | EL
------------+---------+---------+---------+--------+------+------+------
IPv4        | No      |  Yes    |  N/A    | IPv4   |  N/A |  E4  | RL
------------+---------+---------+---------+--------+------+------+------
IPv4        | No      |  No     |  N/A    | UNRCH  |  N/A |  N/A | N/A
------------+---------+---------+---------+--------+------+------+------
IPv4-compat | Yes     |  N/A    |  N/A    | IPv6   |  E6  |  N/A | EL
------------+---------+---------+---------+--------+------+------+------
IPv4-compat | No      |  Yes    |  N/A    | IPv6/4 |  E6  |  E4  | RL
------------+---------+---------+---------+--------+------+------+------
IPv4-compat | No      |  No     |  Yes    | IPv6   |  E6  |  N/A | RL
------------+---------+---------+---------+--------+------+------+------
IPv4-compat | No      |  No     |  No     | UNRCH  |  N/A |  N/A | N/A
------------+---------+---------+---------+--------+------+------+------
IPv6-only   | Yes     |  N/A    |  N/A    | IPv6   |  E6  |  N/A | EL
------------+---------+---------+---------+--------+------+------+------
IPv6-only   | No      |  N/A    |  Yes    | IPv6   |  E6  |  N/A | RL
------------+---------+---------+---------+--------+------+------+------
IPv6-only   | No      |  Yes    |  No     | IPv6/4 |  E6  |  T4  | RL
------------+---------+---------+---------+--------+------+------+------
IPv6-only   | No      |  No     |  No     | UNRCH  |  N/A |  N/A | N/A
------------+---------+---------+---------+--------+------+------+------

And here's the key to all the abbreviations, so nothing gets lost in translation:

        Key to Abbreviations
        --------------------
        N/A:    Not applicable or does not matter.
        E6:     IPv6 address of end node.
        E4:     IPv4 address of end node (low-order 32-bits of
                IPv4-compatible address).
        EL:     Datalink address of end node.
        T4:     IPv4 address of the tunnel endpoint.
        R6:     IPv6 address of router.
        R4:     IPv4 address of router.
        RL:     Datalink address of router.
        IPv4:   IPv4 packet format.
        IPv6:   IPv6 packet format.
        IPv6/4: IPv6 encapsulated in IPv4 packet format.
        UNRCH:  Destination is unreachable.  Don't send a packet.

Okay, so before picking a packet format, you have to figure out whether the destination is on your attached link or not. ✨ IPv4 and IPv6 do this in totally different ways, which is so extra. IPv4 ANDs both the destination address and the interface address with the interface's netmask, then compares the results. If they match, the destination is on-link. You can read more about this in Section 3.3.1.1 of the host requirements specification [10]. IPv6 uses the neighbor discovery algorithm from "Neighbor Discovery for IP Version 6" [7] instead.

IPv6/IPv4 nodes need to use both methods, depending on the address:

  • If a destination is an IPv4 address, the on/off link check is done by comparing with the netmask, as described in RFC 1122 section 3.3.1.1. 🌈
  • If a destination is represented by an IPv4-compatible IPv6 address (prefix 0:0:0:0:0:0), the decision uses the IPv4 netmask comparison algorithm on the low-order 32-bits (the IPv4 address part) of the destination address.
  • If the destination is represented by an IPv6-only address (any prefix other than 0:0:0:0:0:0), the on/off link determination is made using the IPv6 neighbor discovery mechanism. 👑

5. Acknowledgements

Big shoutout to the members of the IPng working group and the IPng transition working group for all their contributions and super thorough review of this document. 🫶 Special thanks to Jim Bound, Ross Callon, and Bob Hinden for lots of helpful suggestions, and to John Moy for suggesting the IPv4 "anycast address" default tunnel technique. You're all iconic. 🌟

6. Security Considerations

Okay, bestie, deep breath. 😭 Security issues are not discussed in this memo. Let that sink in. Whatever you do with this one, go in with your eyes open. 🙈

7. Authors' Addresses

These are the two people who wrote it, with their contact info right here:

Robert E. Gilligan
Sun Microsystems, Inc.
2550 Garcia Ave.
Mailstop UMTV 05-44
Mountain View, California 94043

Phone: 415-336-1012
Fax:   415-336-6015
EMail: Bob.Gilligan@Eng.Sun.COM


Erik Nordmark
Sun Microsystems, Inc.
2550 Garcia Ave.
Mailstop UMTV 05-44
Mountain View, California 94043

Phone: 415-336-2788
Fax:   415-336-6015
EMail: Erik.Nordmark@Eng.Sun.COM

7. References

Here's every source this spec leans on, exactly as cited. 📚

[1] Croft, W., and J. Gilmore, "Bootstrap Protocol", RFC 951,
    September 1985.

[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541.
    October 1993.

[3] Bound, J., "Dynamic Host Configuration Protocol for IPv6 for IPv6
    (DHCPv6)", Work in Progress, November 1995.

[4] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6)
    Specification", RFC 1883, December 1995.

[5] Thomson, S., and T. Nartan, "IPv6 Stateless Address
    Autoconfiguration, Work in Progress, December 1995.

[6] Thomson, S., and C. Huitema. "DNS Extensions to support IP
    version 6", RFC 1886, December 1995.

[7] Nartan, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for
    IP Version 6 (IPv6)", Work in Progress, November 1995.

[8] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
    November 1990.

[9] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "Reverse
    Address Resolution Protocol", RFC 903, June 1984.

[10] Braden, R., "Requirements for Internet Hosts - Communication
     Layers", STD 3, RFC 1122, October 1989.

[11] Kent, C., and J. Mogul, "Fragmentation Considered Harmful".  In
     Proc.  SIGCOMM '87 Workshop on Frontiers in Computer
     Communications Technology.  August 1987.

That's the whole thing, bestie! 🌈✨ You made it through the sending algorithm, the on/off link stuff, and all the references. Honestly, iconic. 💖

📦 where this page comes from