RFC 4213

Basic Transition Mechanisms for IPv6 Hosts and Routers

📅 published October 2005, from ietf

RFC 4213: Basic Transition Mechanisms for IPv6 Hosts and Routers 💖

okay bestie, this one's a big deal 🦋 It was written by E. Nordmark from Sun Microsystems, Inc. and R. Gilligan from Intransa, Inc., and it came out in October 2005 as a Standards Track document. It obsoletes RFC 2893, so that older spec is officially retired now 🫶 It's also the one defining the basic transition mechanisms for IPv6 hosts and routers, so the whole thing is about getting IPv4 and IPv6 to get along ✨

Status of This Memo 📜

This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💅 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌸

Copyright (C) The Internet Society (2005) 🎀

Abstract ✨

So the vibe here is IPv4 compatibility mechanisms that IPv6 hosts and routers can actually implement 🧚 Two mechanisms get specified: dual stack and configured tunneling 💜 Dual stack means having complete implementations of both versions of the Internet Protocol (IPv4 and IPv6), and configured tunneling is how you carry IPv6 packets over unmodified IPv4 routing infrastructures. Iconic, honestly 👑

This document obsoletes RFC 2893.

Table of Contents 🗂️

1. Introduction ....................................................2
   1.1. Terminology ................................................3
2. Dual IP Layer Operation .........................................4
   2.1. Address Configuration ......................................5
   2.2. DNS ........................................................5
3. Configured Tunneling Mechanisms .................................6
   3.1. Encapsulation ..............................................7
   3.2. Tunnel MTU and Fragmentation ...............................8
        3.2.1. Static Tunnel MTU ...................................9
        3.2.2. Dynamic Tunnel MTU ..................................9
   3.3. Hop Limit .................................................11
   3.4. Handling ICMPv4 Errors ....................................11
   3.5. IPv4 Header Construction ..................................13
   3.6. Decapsulation .............................................14
   3.7. Link-Local Addresses ......................................17
   3.8. Neighbor Discovery over Tunnels ...........................18
4. Threat Related to Source Address Spoofing ......................18
5. Security Considerations ........................................19
6. Acknowledgements ...............................................21
7. References .....................................................21
   7.1. Normative References ......................................21
   7.2. Informative References ....................................21
8. Changes from RFC 2893 ..........................................23

1. Introduction 🌈

Okay so the key to a successful IPv6 transition is being compatible with the huge installed base of IPv4 hosts and routers 😭 Keeping compatibility with IPv4 while rolling out IPv6 is what makes moving the whole Internet over way less painful 🫶 This spec defines two mechanisms that IPv6 hosts and routers may implement so they can be compatible with IPv4 hosts and routers. Main character energy 💅

The mechanisms in this document are built for IPv6 hosts and routers that need to talk to IPv4 hosts and use IPv4 routing infrastructures. We expect most nodes on the Internet will need this compatibility for a long time, and maybe even forever 🙈

The mechanisms specified here are:

  • Dual IP layer (also known as dual stack): a technique for providing complete support for both Internet protocols, IPv4 and IPv6, in hosts and routers 🎀
  • Configured tunneling of IPv6 over IPv4: a technique for setting up point-to-point tunnels by wrapping IPv6 packets inside IPv4 headers so they can cross IPv4 routing infrastructures 🦋

The mechanisms defined here are meant to be the core of a "transition toolbox", which is a growing collection of techniques that implementations and users can use to make the transition easier 🧰 The tools get used as needed, and implementations and sites decide which techniques fit their specific needs 💖

This document defines the basic set of transition mechanisms, but they're not the only tools out there. Additional transition and compatibility mechanisms are specified in other documents 🌸

1.1. Terminology 📖

Here are the terms used in this document, bestie:

Types of Nodes

IPv4-only node: A host or router that implements only IPv4. It doesn't understand IPv6. The installed base of IPv4 hosts and routers that exist before the transition begins 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 operate isn't addressed in this memo 🙈

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 🌈

Techniques Used in the Transition

IPv6-over-IPv4 tunneling: The technique of encapsulating IPv6 packets within IPv4 so they can be carried across IPv4 routing infrastructures 🦋

Configured tunneling: IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint address(es) are determined by configuration information on the tunnel endpoints. All tunnels are assumed to be bidirectional. The tunnel gives the IPv6 layer a (virtual) point-to-point link, using the configured IPv4 addresses as the lower-layer endpoint addresses 🎀

Other transition mechanisms, including other tunneling mechanisms, are outside the scope of this document 🫶

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119] 🔥

2. Dual IP Layer Operation 💅

The most straightforward way for IPv6 nodes to stay compatible with IPv4-only nodes is by providing a complete IPv4 implementation 💖 IPv6 nodes that provide complete IPv4 and IPv6 implementations 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 also directly interoperate with IPv6 nodes using IPv6 packets 👑

Even though a node might be set up to support both protocols, one or the other stack might be disabled for operational reasons 🙈 Here we use a pretty loose idea of "stack". A stack that's enabled has IP addresses assigned, but whether any particular application is available on the stacks is explicitly not defined. So IPv6/IPv4 nodes can run in one of three modes:

  • With their IPv4 stack enabled and their IPv6 stack disabled.
  • With their IPv6 stack enabled and their IPv4 stack disabled.
  • With both stacks enabled.

IPv6/IPv4 nodes with their IPv6 stack disabled will operate like IPv4-only nodes. Similarly, IPv6/IPv4 nodes with their IPv4 stack disabled will operate like IPv6-only nodes. IPv6/IPv4 nodes MAY provide a configuration switch to disable either their IPv4 or IPv6 stack ✨

The configured tunneling technique, described in Section 3, may or may not be used in addition to dual IP layer operation 🧚

2.1. Address Configuration 🏠

Since the nodes support both protocols, IPv6/IPv4 nodes may be configured with both IPv4 and IPv6 addresses 🌸 IPv6/IPv4 nodes use IPv4 mechanisms (e.g., DHCP) to acquire their IPv4 addresses, and IPv6 protocol mechanisms (e.g., stateless address autoconfiguration [RFC2462] and/or DHCPv6) to acquire their IPv6 addresses 💜

2.2. DNS 🌐

The Domain Naming System (DNS) is used in both IPv4 and IPv6 to map between hostnames and IP addresses 🍓 A new resource record type named "AAAA" has been defined for IPv6 addresses [RFC3596]. Since IPv6/IPv4 nodes must be able to interoperate directly with both IPv4 and IPv6 nodes, they MUST provide resolver libraries that can deal with IPv4 "A" records as well as IPv6 "AAAA" records 😭 Note that looking up A versus AAAA records is independent of whether the DNS packets are carried in IPv4 or IPv6 packets, and there's no assumption that the DNS servers know the IPv4/IPv6 capabilities of the requesting node 🙈

The issues and operational guidelines for using IPv6 with DNS are explained at more length in other documents, e.g., [DNSOPV6] 📚

DNS resolver libraries on IPv6/IPv4 nodes MUST be capable of handling both AAAA and A records. However, when a query finds an AAAA record holding an IPv6 address and an A record holding an IPv4 address, the resolver library MAY order the results returned to the application to influence which version of IP packets gets used to talk to that specific node. That's IPv6 first, or IPv4 first 🔥

The applications SHOULD be able to specify whether they want IPv4, IPv6, or both records [RFC3493]. That defines which address families the resolver looks up 💅 If there isn't an application choice, or if the application has requested both, the resolver library MUST NOT filter out any records 🫶

Since most applications try the addresses in the order the resolver returns them, this can affect the IP version "preference" of applications 🦋

The actual ordering mechanisms are out of scope of this memo. Address selection is explained at more length in [RFC3484] ✨

Part 1 of 6 done, bestie! 💜 More parts are coming, so stay tuned 🧚

3. Configured Tunneling Mechanisms ✨

okay so, in most deployments the IPv6 routing infrastructure gets built up over time 🌸 while that's happening, the existing IPv4 routing infrastructure can keep working and carry IPv6 traffic for you. Tunneling is the trick that makes this possible. It lets you use the IPv4 network you already have to move IPv6 traffic around 🫶

IPv6/IPv4 hosts and routers can tunnel IPv6 datagrams across parts of the IPv4 routing topology by wrapping them up inside IPv4 packets 🎀 There are a few different ways to do this:

  • Router-to-Router. IPv6/IPv4 routers that are connected by an IPv4 infrastructure can tunnel IPv6 packets between each other. Here the tunnel covers one segment of the end-to-end path the IPv6 packet takes 🦋
  • Host-to-Router. IPv6/IPv4 hosts can tunnel IPv6 packets to an intermediary IPv6/IPv4 router that they can reach over an IPv4 infrastructure. This kind of tunnel covers the first segment of the packet's end-to-end path ✨
  • Host-to-Host. IPv6/IPv4 hosts that are connected by an IPv4 infrastructure can tunnel IPv6 packets between themselves. In this case the tunnel covers 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 only covers the last segment of the end-to-end path 💅

Configured tunneling works for all of the cases above, but it's most likely to be used router-to-router, because you have to explicitly configure the tunneling endpoints by hand 🙈

Here's how the tunneling mechanics work:

  • The entry node of the tunnel (the encapsulator) builds an encapsulating IPv4 header and sends the encapsulated packet on its way 🧚
  • The exit node of the tunnel (the decapsulator) receives the encapsulated packet, reassembles it if needed, strips off the IPv4 header, and then processes the IPv6 packet it finds inside 💜
  • The encapsulator may need to keep soft-state information for each tunnel, recording things like the tunnel's MTU, so it can handle IPv6 packets that get forwarded into the tunnel 🍓

With configured tunneling, the encapsulator works out the tunnel endpoint addresses from the configuration it has stored for each tunnel. When an IPv6 packet goes over a tunnel, the destination and source addresses of the encapsulating IPv4 header are set as described in Section 3.5 💖

Usually, the encapsulator's routing information decides which packets get tunneled. That's typically done with a routing table, which sends packets along based on their destination address using the prefix mask and match technique 🌈

The decapsulator matches incoming protocol-41 packets against the tunnels it has configured, and it only lets through packets whose IPv4 source addresses match the tunnels configured on the decapsulator 🔥 So the operator has to make sure the tunnel's IPv4 address configuration is the same at both the encapsulator and the decapsulator. No mismatches, bestie 🫶

3.1. Encapsulation

Here's how an IPv6 datagram gets wrapped up in IPv4 🎀

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

                      Encapsulating IPv6 in IPv4

Adding the IPv4 header is only part of the job. The encapsulator also has to deal with a couple of trickier things 😭

  • Deciding when to fragment, and when to send an ICMPv6 "packet too big" error back to the source.
  • Reflecting ICMPv4 errors from routers along the tunnel path back to the source as ICMPv6 errors.

Those issues get covered in the sections that follow 💅

3.2. Tunnel MTU and Fragmentation

Okay, so the encapsulator could naively treat encapsulation as IPv6 using IPv4 as a link layer with a super huge MTU (65535-20 bytes at most, since 20 bytes of "extra" are needed for the encapsulating IPv4 header). It would then only need to send ICMPv6 "packet too big" errors back to the source for packets bigger than that MTU. BUT, this scheme would be inefficient or non-interoperable for three reasons, and that's why it MUST NOT be used 🙅‍♀️💀

  1. It would cause more fragmentation than needed. IPv4 layer fragmentation should be avoided because of the performance problems that come from the loss unit being smaller than the retransmission unit [KM97] 😩
  2. Any IPv4 fragmentation happening inside the tunnel, meaning between the encapsulator and the decapsulator, would have to be reassembled at the tunnel endpoint. For tunnels that end at a router, that means extra memory and other resources to put the IPv4 fragments back together into a complete IPv6 packet before it can be forwarded 🧠
  3. The encapsulator has no way of knowing whether the decapsulator can defragment such IPv4 packets (see Section 3.6 for details). It also has no way of knowing whether the decapsulator can handle such a large IPv6 Maximum Receive Unit (MRU) 🤷‍♀️

So, the encapsulator MUST NOT treat the tunnel as an interface with an MTU of 64 kilobytes. Instead, it has to either use the fixed static MTU, or the OPTIONAL dynamic MTU determination based on the IPv4 path MTU to the tunnel endpoint 🌸

If both mechanisms are implemented, the decision of which one to use SHOULD be configurable on a per-tunnel endpoint basis ⭐

3.2.1. Static Tunnel MTU

A node using a static tunnel MTU treats the tunnel interface as having a fixed-interface MTU 🦋 By default, the MTU MUST be between 1280 and 1480 bytes (inclusive), but it SHOULD be 1280 bytes. If the default isn't 1280 bytes, the implementation MUST have a configuration knob that can be used to change the MTU value 🎀

A node must be able to accept a fragmented IPv6 packet that, after reassembly, is as large as 1500 octets [RFC2460]. This memo also includes requirements (see Section 3.6) for the amount of IPv4 reassembly and IPv6 MRU that MUST be supported by all the decapsulators. These make sure everything interoperates correctly with any fixed MTU between 1280 and 1480 bytes ✨

A larger fixed MTU than these requirements support must not be configured, unless someone has administratively made sure that the decapsulator can reassemble or receive packets of that size 🙈

Picking a good tunnel MTU depends on lots of factors, at least these:

  • Whether the IPv4 protocol-41 packets will be carried over media that might have a lower path MTU (for example, IPv4 Virtual Private Networks). If so, picking too high a value might lead to IPv4 fragmentation 😬
  • Whether the tunnel is carrying IPv6 tunneled packets (for example, a mobile node with an IPv6-in-IPv4 configured tunnel and an IPv6-in-IPv6 tunnel interface). If so, picking too low a value might lead to IPv6 fragmentation 🌀

If layered encapsulation is believed to be present, it may be prudent to consider supporting dynamic MTU determination instead, since it can minimize fragmentation and optimize packet sizes 🧚

When you're using the static tunnel MTU, the Don't Fragment bit MUST NOT be set in the encapsulating IPv4 header. Because of that, the encapsulator should not receive any ICMPv4 "packet too big" messages as a result of the packets it has encapsulated 💅

3.2.2. Dynamic Tunnel MTU

Dynamic MTU determination is OPTIONAL. However, if it IS implemented, it SHOULD have the behavior described in this document 🫶

Fragmentation inside the tunnel can be cut down to a minimum if the encapsulator tracks the IPv4 path MTU across the tunnel. It does this using the IPv4 Path MTU Discovery Protocol [RFC1191] and records the resulting path MTU 🔍 The IPv6 layer in the encapsulator can then see the tunnel as a link layer with an MTU equal to the IPv4 path MTU, minus the size of the encapsulating IPv4 header 🌈

Be aware that this does not eliminate IPv4 fragmentation when the IPv4 path MTU would give an IPv6 MTU less than 1280 bytes. (Any link layer used by IPv6 has to have an MTU of at least 1280 bytes [RFC2460].) In that case, the IPv6 layer has to "see" a link layer with an MTU of 1280 bytes, and the encapsulator has to use IPv4 fragmentation in order to forward the 1280 byte IPv6 packets 😭

The encapsulator SHOULD use the following algorithm to decide when to forward an IPv6 packet that's bigger than the tunnel's path MTU using IPv4 fragmentation, and when to send back an ICMPv6 "packet too big" message per [RFC1981] 🧮

      if (IPv4 path MTU - 20) is less than 1280
              if packet is larger than 1280 bytes
                      Send ICMPv6 "packet too big" with MTU = 1280.
                      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 encapsulator or by some router along
                      the IPv4 path.
              endif
      else
              if packet is larger than (IPv4 path MTU - 20)
                      Send ICMPv6 "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

Encapsulators that have a big pile of tunnels may choose between dynamic and static tunnel MTUs on a per-tunnel endpoint basis 👑 When the number of tunnels any one node is using is large, it helps to know that this state information can be cached and thrown away when it's not in use 🗑️✨

Note that using dynamic tunnel MTU is subject to IPv4 path MTU blackholes if ICMPv4 "packet too big" messages get dropped by firewalls or aren't generated by the routers [RFC1435, RFC2923]. Yikes, so keep an eye out for that 😱🎀

3.3. Hop Limit 🦋

Okay so IPv6-over-IPv4 tunnels are modeled as "single-hop" from the IPv6 point of view ✨ The tunnel is totally opaque to people using the network, and diagnostic tools like traceroute can't detect it 🙈

The single-hop model works because encapsulators and decapsulators 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 whenever they forward an IPv6 packet. (The originating node and the final destination do not decrement the hop limit 🫶)

The TTL of the encapsulating IPv4 header is picked in an implementation-dependent manner 🌸 The current suggested value is published in the "Assigned Numbers" RFC [RFC3232][ASSIGNED]. Implementations MAY provide a mechanism to let the administrator configure the IPv4 TTL as the IP Tunnel MIB [RFC4087] 🎀

3.4. Handling ICMPv4 Errors 💌

In response to encapsulated packets that it sent into the tunnel, the encapsulator might get ICMPv4 error messages from IPv4 routers inside the tunnel 👀 These packets are addressed to the encapsulator, since it's the IPv4 source of the encapsulated packet.

ICMPv4 error handling only matters for dynamic MTU determination, even though the functions could also be used with static MTU tunnels 🧚

The ICMPv4 "packet too big" error messages are handled according to IPv4 Path MTU Discovery [RFC1191], and the resulting path MTU gets recorded in the IPv4 layer 🔥 IPv6 then uses that recorded path MTU to figure out whether an ICMPv6 "packet too big" error has to be generated, as described in Section 3.2.2 💜

How the other types of ICMPv4 error messages get handled depends on how much information is available from 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, which is not enough to include the address fields of the IPv6 header 💀 More modern IPv4 routers are likely to return enough data beyond the IPv4 header to include the entire IPv6 header, and maybe even the data beyond that. See [RFC1812] ✨

If sufficient data bytes from the offending packet are available, the encapsulator MAY extract the encapsulated IPv6 packet and use it to generate an ICMPv6 message directed back to the originating IPv6 node, as shown below 🦋

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

             ICMPv4 Error Message Returned to Encapsulating Node

When ICMPv4 errors come in like that and they're not "packet too big", it would be useful to log the error as an error related to the tunnel 📝 Also, if enough headers are available, then the originating node MAY send an ICMPv6 error of type "unreachable" with code "address unreachable" to the IPv6 source 💖 (The "address unreachable" code is appropriate since, from the IPv6 perspective, the tunnel is a link, and that code is used for link-specific errors [RFC2463] 🌈)

Now, the tea 🍵 When the IPv4 path MTU is exceeded and there aren't enough bytes of payload associated with the ICMPv4 errors, or the ICMPv4 errors don't cause ICMPv6 errors even though there's enough payload, there will be at least two packet drops instead of at least one (the case of a single layer of MTU discovery) 😭 Picture an IPv6 host connected to an IPv4/IPv6 router, which is connected to a network where an ICMPv4 error about too big packet size gets generated. First, the router needs to learn the tunnel (IPv4) MTU, which causes at least one packet loss. Then the host needs to learn the (IPv6) MTU from the router, which also causes at least one packet loss 🙈 Still, in every case there can be more than one packet loss if there are multiple large packets in flight at the same time 💀

3.5. IPv4 Header Construction 🎀

When you encapsulate an IPv6 packet in an IPv4 datagram, the IPv4 header fields get set like this 👑

  • Version: 4
  • IP Header Length in 32-bit words: 5 (There are no IPv4 options in the encapsulating header 🙅‍♀️)
  • Type of Service: 0 unless otherwise specified. (See [RFC2983] and [RFC3168] Section 9.1 for issues relating to the Type-of-Service byte and tunneling 🌸)
  • Total Length: Payload length from IPv6 header plus length of IPv6 and IPv4 headers (i.e., IPv6 payload length plus a constant 60 bytes) ✨
  • Identification: Generated uniquely as for any IPv4 packet transmitted by the system 🔥
  • Flags: Set the Don't Fragment (DF) flag as specified in Section 3.2. 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, as described in Section 3.3 💜
  • Protocol: 41 (Assigned payload type number for IPv6) 🍓
  • Header Checksum: Calculate the checksum of the IPv4 header [RFC791] 🫶
  • Source Address: An IPv4 address of the encapsulator, either configured by the administrator or an address of the outgoing interface 💅
  • Destination Address: IPv4 address of the tunnel endpoint 🌈

When encapsulating the packets, the node must ensure that it will use the correct source address so that the packets are acceptable to the decapsulator, as described in Section 3.6 🙌 Configuring the source address is especially appropriate when automatic selection of the source address could produce different results over a certain period of time. This is often the case with multiple addresses and multiple interfaces, or when routes may change frequently 🌪️ Therefore, it SHOULD be possible to administratively specify the source address of a tunnel 👑

3.6. Decapsulation

okay so 💖 when an IPv6/IPv4 host or a router gets an IPv4 datagram that's addressed to one of its own IPv4 addresses (or a joined multicast group address) and the protocol field is 41, that packet is potentially a tunnel packet 🦋. It then needs to be checked that it belongs to one of the configured tunnel interfaces (by looking at the source/destination addresses), reassembled if it got fragmented at the IPv4 level, and have its IPv4 header removed so the leftover IPv6 datagram can be handed to the IPv6 layer code on the node ✨.

The decapsulator MUST verify that the tunnel source address is correct before it processes packets any further 🙈. This is how it handles the address spoofing problems (see Section 4). The check also applies to packets delivered to transport protocols on the decapsulator. To do it, the decapsulator confirms that the source address is the IPv4 address of the encapsulator, as configured on the decapsulator. Packets whose IPv4 source address does not match MUST be discarded, and an ICMP message SHOULD NOT be generated. Still, if the implementation normally sends an ICMP message when it gets an unknown protocol packet, such an error message MAY be sent (e.g., ICMPv4 Protocol 41 Unreachable) 💅.

A side effect of this address verification is that the node will silently discard packets with a wrong source address, and packets that it received but weren't directly addressed to it (e.g., broadcast addresses). Iconic behaviour, honestly 🔥.

Independent of any other forms of IPv4 ingress filtering the administrator of the node may have configured, the implementation MAY perform ingress filtering. That means checking that the packet is arriving from the interface in the direction of the route toward the tunnel end-point, kind of like a Strict Reverse Path Forwarding (RPF) check [RFC3704]. Since this can cause problems on tunnels that are routed through multiple links, it is RECOMMENDED that this check, if done, is disabled by default 🌸. The packets caught by this check SHOULD be discarded, and an ICMP message SHOULD NOT be generated by default.

The decapsulator MUST be capable of having, on the tunnel interfaces, an IPv6 MRU of at least the maximum of 1500 bytes and the largest (IPv6) interface MTU on the decapsulator 🎀.

The decapsulator MUST be capable of reassembling an IPv4 packet that, after reassembly, is the maximum of 1500 bytes and the largest (IPv4) interface MTU on the decapsulator. The 1500-byte number comes from encapsulators using the static MTU scheme in Section 3.2.1, while encapsulators using the dynamic scheme in Section 3.2.2 can cause up to the largest interface MTU on the decapsulator to be received. (Note that it is strictly the interface MTU on the last IPv4 router before the decapsulator that matters, but for most links the MTU is the same between all neighbors.)

This reassembly limit lets the encapsulator's dynamic tunnel MTU determination take advantage of larger IPv4 path MTUs 🧚. An implementation MAY have a configuration knob that sets a larger value of the tunnel reassembly buffers than the number above, but it MUST NOT be set below that number ⭐.

The decapsulation is shown below:

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

                  Decapsulating IPv6 from IPv4

The decapsulator does IPv4 reassembly before it decapsulates the IPv6 packet.

When decapsulating the packet, the IPv6 header is not modified. (However, see [RFC2983] and [RFC3168] section 9.1 for issues relating to the Type of Service byte and tunneling.) If the packet is forwarded afterwards, its hop limit is decremented by one 🍓.

The encapsulating IPv4 header is discarded, and the resulting packet is checked for validity when it's submitted to the IPv6 layer. When reconstructing the IPv6 packet, the length MUST be determined from the IPv6 payload length, since the IPv4 packet might be padded (so it could be longer than the IPv6 packet plus the IPv4 header being removed) 🫶.

After the decapsulation, the node MUST silently discard a packet with an invalid IPv6 source address. The list of invalid source addresses SHOULD include at least:

  • all multicast addresses (FF00::/8)
  • the loopback address (::1)
  • all the IPv4-compatible IPv6 addresses [RFC3513] (::/96), excluding the unspecified address for Duplicate Address Detection (::/128)
  • all the IPv4-mapped IPv6 addresses (::ffff:0:0/96)

In addition, the node should be configured to perform ingress filtering [RFC2827][RFC3704] on the IPv6 source address, similar to how it's done on any of its interfaces, e.g.:

  1. if the tunnel is toward the Internet, the node should be configured to check that the site's IPv6 prefixes are not used as the source addresses, or
  2. if the tunnel is toward an edge network, the node should be configured to check that the source address belongs to that edge network.

The prefix lists in the first option typically need to be configured manually. The second one could be verified automatically, e.g., by using a strict unicast RPF check, as long as an interface can be designated to be toward an edge 👑.

It is RECOMMENDED that the implementations provide a single knob to make it easier to for the administrators to enable strict ingress filtering toward edge networks 💜.

The configured tunnels are IPv6 interfaces (over the IPv4 "link layer"), so they MUST have link-local addresses 🌈. The link-local addresses are used by, e.g., routing protocols operating over the tunnels.

The interface identifier [RFC3513] for one of these interfaces may be based on the 32-bit IPv4 address of an underlying interface, or formed using some other means, as long as it's unique from the other tunnel endpoint with a reasonably high probability.

It may be desirable to form the link-local address in a way that minimizes both the probability and the effect of having to renumber the link-local address when the topology or hardware changes 🦋.

If an IPv4 address is used to form the IPv6 link-local address, the interface identifier is the IPv4 address, prepended by zeros. The "Universal/Local" bit is zero, which means the interface identifier is not globally unique. The link-local address is formed by appending the interface identifier to the prefix FE80::/64.

When the host has more than one IPv4 address in use on the physical interface concerned, the administrator or the implementation picks one of those IPv4 addresses when forming the link-local address 🎀.

      +-------+-------+-------+-------+-------+-------+------+------+
      |  FE      80      00      00      00      00      00     00  |
      +-------+-------+-------+-------+-------+-------+------+------+
      |  00      00      00      00   |        IPv4 Address         |
      +-------+-------+-------+-------+-------+-------+------+------+

3.8. Neighbor Discovery over Tunnels

Configured tunnel implementations MUST at least accept and respond to the probe packets used by Neighbor Unreachability Detection (NUD) [RFC2461] 🙌. The implementations SHOULD also send NUD probe packets to detect when the configured tunnel fails, at which point the implementation can use an alternate path to reach the destination. Neighbor Discovery allows the sending of NUD probes to be omitted for router-to-router links if the routing protocol tracks bidirectional reachability 🧠.

For the purposes of Neighbor Discovery, the configured tunnels specified in this document are assumed to NOT have a link-layer address, even though the link-layer (IPv4) does have an address 🤓. This means that:

  • the sender of Neighbor Discovery packets SHOULD NOT include Source Link Layer Address options or Target Link Layer Address options on the tunnel link.
  • the receiver MUST, while otherwise processing the Neighbor Discovery packet, silently ignore the content of any Source Link Layer Address options or Target Link Layer Address options received on the tunnel link.

Not using link-layer address options is consistent with how Neighbor Discovery is used on other point-to-point links 💅.

The stakes are high here, bestie 😭. Read this part slowly.

The specification above has rules that apply tunnel source address verification in particular, and ingress filtering [RFC2827][RFC3704] in general, to packets before they're decapsulated. When IP-in-IP tunneling is used (no matter which IP versions), it's important that it doesn't get used to bypass any ingress filtering in place for non-tunneled packets. So the rules in this document were derived with this in mind: if ingress filtering is used for IPv4 and IPv6, tunneling should not give an easy way to get around that filtering 🛡️.

Here's the scary scenario. Without specific ingress filtering checks in the decapsulator, an attacker could inject a packet with:

  • Outer IPv4 source: real IPv4 address of attacker
  • Outer IPv4 destination: IPv4 address of decapsulator
  • Inner IPv6 source: Alice, which is either the decapsulator or a node close to it
  • Inner IPv6 destination: Bob

Even if all IPv4 routers between the attacker and the decapsulator implement IPv4 ingress filtering, and all IPv6 routers between the decapsulator and Bob implement IPv6 ingress filtering, these spoofed packets would not be filtered out 😱. As a result, Bob would receive a packet that looks like it was sent from Alice, even though the sender was some unrelated node.

The fix is to have the decapsulator accept only encapsulated packets from the explicitly configured source address (i.e., the other end of the tunnel), as specified in Section 3.6. This doesn't give complete protection in cases where ingress filtering hasn't been deployed, but it does give a significant increase in security 🔐. The issue and the remaining threats are discussed at more length in Security Considerations.

5. Security Considerations 🔐

Okay, so the general security stuff for using IPv6 lives in its own doc, [V6SEC]. Go read that too, bestie 📚

Tunnel implementers need to know that even though a tunnel counts as a link (as defined in [RFC2460]), the threat model is rather different from other links, because a tunnel can potentially reach all of the Internet 🌍 It's giving "the whole internet is in the group chat" energy 💀

Several mechanisms (e.g., Neighbor Discovery) depend on Hop Count being 255 and/or the addresses being link local to make sure a packet came from on-link in a semi-trusted environment 🫶 Tunnels are way more vulnerable to this assumption breaking than physical links 😭 Any attacker anywhere on the Internet can send an IPv6-in-IPv4 packet to the tunnel decapsulator, and that gets an encapsulated IPv6 packet injected into the configured tunnel interface. The only way to stop that is if the decapsulation checks can discard packets injected like that 🙅‍♀️

So this memo says decapsulators should take these steps (as described in Section 3.6) to mitigate this threat 🛡️

  • IPv4 source address of the packet MUST be the same as configured for the tunnel end-point;
  • Independent of any IPv4 ingress filtering the administrator may have configured, the implementation MAY perform IPv4 ingress filtering to check that the IPv4 packets are received from an expected interface (but as this may cause some problems, it may be disabled by default);
  • IPv6 packets with several, obviously invalid IPv6 source addresses received from the tunnel MUST be discarded (see Section 3.6 for details); and
  • IPv6 ingress filtering should be performed (typically requiring configuration from the operator), to check that the tunneled IPv6 packets are received from an expected interface.

The first check is the most vital one 👑 To get around it, the attacker has to know the tunnel's source (which can be anywhere from hard to super predictable) and then be able to spoof it (which is the easier part, sadly) 🙈

If the leftover threats from tunnel source verification still seem significant, a tunneling scheme with authentication should be used instead. Think IPsec [RFC2401] (the preferable pick ✨) or Generic Routing Encapsulation with a pre-configured secret key [RFC2890]. Configured tunnels get set up more or less by hand anyway, so sorting out the keying material is probably not a big deal 🔑 Setting up secure IPsec IPv6-in-IPv4 tunnels is covered in another doc, [V64IPSEC] 💜

If the tunneling happens inside one administrative domain, proper ingress filtering at the edge of that domain can also kill the threat from outside it 🏰 So shorter tunnels are preferable to longer ones, especially ones that could span the whole Internet 🌸

Also, an implementation MUST treat interfaces to different links as separate, so that, for example, Neighbor Discovery packets arriving on one link can't mess with other links 🧚 This is especially important for tunnel links 🎀

⚠️ Don't be the node that waves hello to probers! When a packet gets dropped because its IPv4 source doesn't match the allowed addresses for a tunnel, the node should not "acknowledge" that the tunnel exists. Otherwise someone could use that to probe for the acceptable tunnel endpoint addresses 🕵️‍♀️ For that reason the specification says such packets MUST be discarded, and an ICMP error message SHOULD NOT be generated. The exception is if the implementation normally sends ICMP destination unreachable messages for unknown protocols. In that case, the same code MAY be sent. As should be obvious, if you return a different ICMP code for other protocols, that can hint that the IPv6 stack (or the protocol 41 tunneling processing) is turned on. So the behaviour should stay consistent with how the implementation normally acts, so it stays transparent to probing 🦋

6. Acknowledgements 🫶

Huge thanks to the members of the IPv6 working group, the Next Generation Transition (ngtrans) working group, and the v6ops working group for all their contributions and super thorough review of this document 💖 Special shoutouts (in alphabetical order) to Jim Bound, Ross Callon, Tim Chown, Alex Conta, Bob Hinden, Bill Manning, John Moy, Mohan Parthasarathy, Chirayu Patel, Pekka Savola, and Fred Templin for all the helpful suggestions 🌈 Pekka Savola also helped with editing the final revisions of the spec 👑

7. References 📚

7.1. Normative References

[RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791, September
           1981.

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

[RFC1981]  McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
           for IP version 6", RFC 1981, August 1996.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
           (IPv6) Specification", RFC 2460, December 1998.

[RFC2463]  Conta, A. and S. Deering, "Internet Control Message
           Protocol (ICMPv6) for the Internet Protocol Version 6
           (IPv6) Specification", RFC 2463, December 1998.

7.2. Informative References

[ASSIGNED] IANA, "Assigned numbers online database",
           http://www.iana.org/numbers.html

[DNSOPV6]  Durand, A., Ihren, J., and Savola P., "Operational
           Considerations and Issues with IPv6 DNS", Work in
           Progress, October 2004.

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

[V6SEC]    Savola, P., "IPv6 Transition/Co-existence Security
           Considerations", Work in Progress, October 2004.

[V64IPSEC] Graveman, R., et al., "Using IPsec to Secure IPv6-over-
           IPv4 Tunnels", Work in Progress, December 2004.

[RFC1435]  Knowles, S., "IESG Advice from Experience with Path MTU
           Discovery", RFC 1435, March 1993.

[RFC1812]  Baker, F., "Requirements for IP Version 4 Routers", RFC
           1812, June 1995.

[RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
           Internet Protocol", RFC 2401, November 1998.

[RFC2461]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor
           Discovery for IP Version 6 (IPv6)", RFC 2461, December
           1998.

[RFC2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
           Autoconfiguration", RFC 2462, December 1998.

[RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
           Defeating Denial of Service Attacks which employ IP Source
           Address Spoofing", BCP 38, RFC 2827, May 2000.

[RFC2890]  Dommety, G., "Key and Sequence Number Extensions to GRE",
           RFC 2890, September 2000.

[RFC2923]  Lahey, K., "TCP Problems with Path MTU Discovery", RFC
           2923, September 2000.

[RFC2983]  Black, D., "Differentiated Services and Tunnels", RFC
           2983, October 2000.

[RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
           via IPv4 Clouds", RFC 3056, February 2001.

[RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
           of Explicit Congestion Notification (ECN) to IP", RFC
           3168, September 2001.

[RFC3232]  Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
           an On-line Database", RFC 3232, January 2002.

[RFC3484]  Draves, R., "Default Address Selection for Internet
           Protocol version 6 (IPv6)", RFC 3484, February 2003.

[RFC3493]  Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
           Stevens, "Basic Socket Interface Extensions for IPv6", RFC
           3493, February 2003.

[RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
           (IPv6) Addressing Architecture", RFC 3513, April 2003.

[RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
           "DNS Extensions to Support IP Version 6", RFC 3596,
           October 2003.

[RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
           Networks", BCP 84, RFC 3704, March 2004.

[RFC4087]  Thaler, D., "IP Tunnel MIB", RFC 4087, June 2005.

8. Changes from RFC 2893 ✨

okay bestie, this section is basically the glow-up log 💅 The main goal of all these changes is to make the doc only include the mechanisms that are actually widely used 🧹

RFC 2893 has a thing called automatic tunneling. But RFC 3056 [RFC3056] has a way more general mechanism 🌸 It gives every node with a (global) IPv4 address a /48 IPv6 prefix, which is enough for a whole site 🏡

Here's everything that changed since RFC 2893 🦋

  • Removed references to A6 and kept AAAA.
  • Removed automatic tunneling and the use of IPv4-compatible addresses.
  • Removed the default Configured Tunnel that used the IPv4 "Anycast Address" 🙅‍♀️
  • Removed the Source Address Selection section, since [RFC3484] covers it now 📚
  • Removed the brief mention of 6over4.
  • Split things into normative and non-normative references, plus other reference cleanup 🗂️
  • Dropped "or equal" from "if (IPv4 path MTU - 20) is less than or equal to 1280". It's now "is less than 1280"? No wait, it's just the "or equal" that got dropped, so the check is simpler 🤓 The exact text is if (IPv4 path MTU - 20) is less than or equal to 1280 for the original, and the "or equal" part is what got removed.
  • Dropped this bit: "However, IPv6 may be used in some environments where interoperability with IPv4 is not required. IPv6 nodes that are designed to be used in such environments need not use or even implement these mechanisms." Bye bye 👋
  • Split the Static MTU and Dynamic MTU cases into separate sections. Also clarified that the dynamic path MTU mechanism is OPTIONAL, but if it is implemented it should follow the rules in section 3.2.2 🎀
  • Specified that Static MTU defaults to an MTU of 1280 to 1480 bytes, and that this may be configurable. Also talked through the issues with using Static MTU in more depth 🧠
  • Specified minimal rules for IPv4 reassembly and IPv6 MRU, to help interoperability and minimize blackholes 🕳️
  • Restated the "currently underway" language about Type-of-Service, and loosely pointed at [RFC2983] and [RFC3168] 🍓
  • Fixed the reference to Assigned Numbers so it points to the online version, with a proper pointer to the "Assigned Numbers is obsolete" RFC 📎
  • Clarified the text about ingress filtering. It applies to packets delivered to transport protocols on the decapsulator, as well as packets the decapsulator forwards. It also explains how the decapsulator's checks help when IPv4 and IPv6 ingress filtering are both in place 🛡️
  • Removed unidirectional tunneling. Tunnels are now assumed to be bidirectional, between endpoint addresses (not nodes) 🔁
  • Removed the guidelines for advertising addresses in DNS, since that's slightly out of scope and another document has the details 🧭
  • Removed the SHOULD requirement that link-local addresses should be formed based on IPv4 addresses 🙃
  • Added a SHOULD for implementing a knob to set the source address of the tunnel, plus discussion of why that's useful 🔧
  • Added stronger wording for source address checks. Both IPv4 and IPv6 source addresses MUST be checked, and RPF-like ingress filtering is optional 🔍
  • Rewrote the security considerations to be more precise about the threats of tunneling 😤
  • Added a note about considering TTL=255 when encapsulating 🌈
  • Added more discussion in Section 3.2 about why an "infinite" IPv6 MTU leads to likely interoperability problems 🙈
  • Added an explicit requirement that if both MTU determination methods are used, choosing one should be possible on a per-tunnel basis 💜
  • Clarified that ICMPv4 error handling only applies to dynamic MTU determination 🧾
  • Removed and clarified DNS record filtering. An API is a SHOULD, and if it does not exist, MUST NOT filter anything. Decree ordering is out of scope, but refer to RFC3484 📖
  • Added a note that the destination IPv4 address could also be a multicast address 📡
  • Made it RECOMMENDED to provide a toggle to perform strict ingress filtering on an interface 🎚️
  • Generalized the text on the data in ICMPv4 messages 💬
  • Made a lot of miscellaneous editorial cleanups 🧹✨

Authors' Addresses

Here's where you can find the authors, bestie 💌

Erik Nordmark
Sun Microsystems
17 Network Circle
Menlo Park, CA 94025
USA

Phone: +1 650 786 2921
EMail: erik.nordmark@sun.com


Robert E. Gilligan
Intransa, Inc.
2870 Zanker Rd., Suite 100
San Jose, CA 95134 USA

Phone : +1 408 678 8600
Fax :   +1 408 678 8800
EMail:  bob.gilligan@acm.org

Copyright (C) The Internet Society (2005) 📜

This document is subject to the rights, licenses and restrictions contained in BCP 78. Except as set forth there, the authors keep all their rights 🔒

This document and the information in it are provided on an "AS IS" basis. THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF doesn't take a position on whether any Intellectual Property Rights or other rights that might be claimed to cover the technology in this document are valid or in scope, or on whether any license under those rights is available. It also doesn't claim to have independently looked for any such rights 🔎 Info on how RFC documents handle rights is in BCP 78 and BCP 79 📚

Copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that will be made available, and the results of any attempt to get a general license or permission to use those rights are available from the IETF's online IPR repository at http://www.ietf.org/ipr 🗃️

The IETF invites anyone interested to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💌

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society 🫶

📦 where this page comes from