555 Words. Plan about 3 minute(s) to read this.
I don’t usually get excited about new RFCs. They come, they go, with varying degrees of relevance to my day to day networking world. But RFC 7059 is a little different. This informational RFC walks through IPv6-over-IPv4 tunneling. This matters to me for a couple of reasons.
- I’m about to have this problem. IPv6 is on my radar. In my specific application for IPv6, I’ll need a tunneling mechanism due to parts of the network I don’t control yet need to traverse that are IPv4 only.
- Several different IPv6 tunneling mechanisms have come and gone in recent years with various levels of success. To be fair, I’ve not kept very good track of them, as I haven’t needed them for a production network. This RFC provides the current state of these tunneling techniques, clueing me in to the approaches that are currently popular, and why. I won’t be wasting my time on tunneling techniques that the industry has rejected overall.
The RFC seems comprehensive, covering the following techniques, including several I’ve not heard of before (probably because of those RFCs I don’t get excited about). I took these right from the RFC’s table of contents.
- Configured Tunnels (Manual Tunnels / 6in4)
- Automatic Tunneling
- IPv6 over IPv4 without Explicit Tunnels (6over4)
- Generic Routing Encapsulation (GRE)
- Connection of IPv6 Domains via IPv4 Clouds (6to4)
- 6to4 Provider Managed Tunnels
- Anything In Anything (AYIYA)
- Intra-Site Automatic Tunnel Addressing (ISATAP)
- Tunneling IPv6 over UDP through NATs (Teredo)
- IPv6 Rapid Deployment (6rd)
- Native IPv6 behind NAT44 CPEs (6a44)
- Locator/ID Separation Protocol (LISP)
- Subnetwork Encapsulation and Adaptation Layer (SEAL)
- Peer-to-Peer IPv6 on Any Internetwork (6bed4)
The true glory of this RFC is that it’s written in plain English. I’ve read about IPv6 over IPv4 tunneling tools in a few different texts and whitepapers, and always came away a bit frustrated. While I had some idea of how the technique worked, I had little sense of where it fit. This RFC provides the context I’m looking for. Here’s a few sample quotes of the plain English context so that you get the idea.
From section 3.2.
Automatic tunneling has a big limitation: it only allows for communication between IPv6-capable systems that both support automatic tunneling. There are no provisions for communicating with the native IPv6 Internet. As such, the mechanism is of almost no practical use…
From section 3.3.
Because of its reliance on IPv4 multicast and because local IPv6 communication is relatively easy to facilitate using IPv6 routers, 6over4 is not supported in current operating systems. ISATAP (Section 3.7) provides very similar functionality without requiring IPv4 multicast capability and is implemented more widely.
From section 5.3.
Because of the extra IPv4 header and possible additional headers between the IPv4 and IPv6 headers, tunnels experience a reduced maximum packet size (MTU) compared to native IPv6 communication. Path MTU discovery (PMTUD) should handle this in nearly all cases, but filtering of ICMPv6 “packet too big” messages may lead to an inability to communicate because senders of large packets fail to perform PMTUD successfully.
From section 6.5.
The process of encapsulation is not inherently slow, but in some implementations, it may be. Larger routers that normally forward packets using special-purpose hardware often don’t have high-performance CPUs. If tunnel encapsulation must then be done by that relatively slow CPU, performance will be worse than regular hardware-based packet forwarding.