RFC 7059
A Comparison of IPv6-over-IPv4 Tunnel Mechanisms
Pages: 41
Informational
Informational
Part 2 of 2 – Pages 20 to 41
4. Related Protocols
The following protocols are not tunnel mechanisms, but they can be used in the configuration and/or setup phase of such protocols.4.1. Tunnel Setup Protocol (TSP)
The Tunnel Setup Protocol [RFC5572] specifies a protocol for negotiating the setup of a variety of tunnel encapsulations. In this document, we are only interested in the encapsulation of IPv6 in IPv4. The Tunnel Setup Protocol can negotiate these as a protocol 41 encapsulated tunnel or as a UDP-encapsulated tunnel. The tunnel negotiation is performed as an XML exchange over UDP or TCP. As a TSP client exchanges all IPv6 traffic with the same tunnel server, there are no concerns caused by NAT implementations. The only concern is to send regular keepalives, for which ICMPv6 ping messages to the tunnel server are suggested. When encapsulating IPv6 packets directly in IPv4, all protocol 41 limitations apply. To avoid these, an additional UDP header may be used. The Tunnel Setup Protocol treats all protocols and ports for one IPv4 client address as equivalent. This suffices when protocol 41 is used, but for UDP it creates a situation where one user can set up a tunnel behind NAT, and another user could hijack the tunnel privileges. Open-source clients for the Tunnel Setup Protocol and a matching tunnel infrastructure are provided from the Freenet6 tunnel service [GOGO6].4.2. SixXS Heartbeat Protocol
The SixXS Heartbeat Protocol [HEARTBEAT] allows nodes that have intermittent connectivity or a dynamic IPv4 address that changes from time to time to have continuing tunneled IPv6 connectivity. One of the goals of the protocol is to determine when a node is no longer present at its previous IPv4 address and then stop sending tunneled packets to prevent them from being delivered to the wrong node. The
Heartbeat Protocol then allows a tunnel broker to determine a client's new IPv4 address and continue sending tunneled packets with minimal interruption. To accomplish this, a node sends periodic heartbeat packets to the tunnel broker. If the tunnel broker fails to receive valid heartbeat packets, it shuts down the tunnel in question. Heartbeat packets contain an MD5 message authentication code and a timestamp to avoid replay attacks. The Heartbeat Protocol can work with different tunnel mechanisms, but it is often used with configured tunnels (Section 3.1). The protocol is implemented in the SixXS tunnel broker; client implementations are available for common operating systems. AYIYA can be considered the successor of the Heartbeat Protocol.4.3. Tunnel Information and Control Protocol (TIC)
The Tunnel Information and Control (TIC) protocol [TIC] is the setup protocol for the [SIXXS] tunnel-broker service. With the TIC protocol, a tunnel-broker user can request a list of available tunnels and points of presence (POPs) from the tunnel- broker service. When the user chooses one of the tunnels, the configuration parameters for that tunnel can then be requested through TIC. TIC also provides commands to control the tunnel, for example, to change the tunnel endpoints or to enable or disable the tunnel. Authentication of users is done based on username and password. Certain tunnel mechanisms, such as AYIYA (Section 3.6) and configured tunnels (Section 3.1) with heartbeat (Section 4.2), need a synchronised clock between the tunnel server and the client. TIC facilitates this by providing a server timestamp on request. The client can use that to verify that its clock is synchronised with the server and show an error message to the user if it is not. The TIC protocol is implemented in the AICCU client software (see [AICCU]) and in AVM Fritz!Box home routers.
5. Common Aspects
The following are aspects common to many or all tunnel mechanisms.5.1. Protocol 41 Encapsulation
The most straightforward way to encapsulate an IPv6 packet inside an IPv4 packet is by simply adding an IPv4 header in front of the IPv6 header. In this case, the Protocol field in the IPv4 header is set to the value 41. This encapsulation is also known as "IPv6 in IPv4" and "IP6 Encapsulation". This simple "protocol 41" encapsulation is used by a number of tunnel mechanisms: configured tunnels (Section 3.1) automatic tunneling (Section 3.2) 6over4 (Section 3.3) 6to4 (Section 3.5) ISATAP (Section 3.7) 6rd (Section 3.9)5.2. NAT and Firewalls
It is not uncommon for NATs and firewalls to block protocol 41 encapsulated packets, especially at the boundary between an organisation's internal network and the public Internet. Tunnel mechanisms that don't use protocol 41 encapsulation typically employ a UDP header and are somewhat less likely to be filtered, assuming that tunneling is initiated on the LAN side. UDP is usually subjected to Network Address Port Translation (NAPT) [RFC2663], which additionally translates between internal and external port numbers. (Often, the term "NAT" is used where "NAPT" may be more appropriate.) Although protocol 41 can in principle work through NAT, there are two issues. First, when the IPv6 address is derived from the IPv4 address (see Section 5.4), NATing of the outer IPv4 header breaks the relationship between the IPv4 and IPv6 addresses. Second, because protocol 41 does not use port numbers, the number of protocol 41 tunnel endpoints that can be supported behind a NAT device is equal to its number of external IPv4 addresses (see Section 6.1). This limitation also applies to GRE.
Tunnels that pass through a NAT device or stateful firewall need to
generate traffic at regular intervals to refresh the NAT or firewall
mapping. If the mapping is lost, tunneled packets from the outside
won't be able to pass through the NAT or firewall until a system
behind the NAT or firewall sends a tunneled packet and the mapping is
re-created. Alternatively, a static mapping (often in the form of a
"default" or "DMZ" host) may be configured manually.
The following tunnel mechanisms are incompatible with NAT because
their addresses must be derived from a globally unique IPv4 address:
automatic tunneling (Section 3.2)
6to4 (Section 3.5)
6rd (Section 3.9)
LISP (Section 3.11)
Note that it is common to run 6to4 or 6rd on a home gateway device
that also performs IPv4 NAT. In this configuration, NAT is not
applied to tunneled packets, so NAT and 6to4/6rd can coexist.
The following tunnel mechanisms cannot operate between nodes on
opposing sides of a NAT, but they do work if _all_ nodes are behind a
NAT (where RFC 1918 addresses are often used):
6over4 (Section 3.3)
ISATAP (Section 3.7)
The following tunnel mechanisms may work through NAT in some
circumstances, but are not designed for NAT compatibility:
configured tunnels (Section 3.1)
GRE (Section 3.4)
The following tunnel mechanisms are designed for NAT compatibility:
AYIYA (Section 3.6)
Teredo (Section 3.8); but it is unreliable
6a44 (Section 3.10)
SEAL (Section 3.12)
6bed4 (Section 3.13)
The LISP specification requires that locator addresses (the addresses
in the outer IPv4 header) are globally routable public addresses.
A tunnel built over UDP makes a claim on a resource, namely, an
external UDP port. This may impact how well a tunnel will scale in
an organisation; for instance, if every desktop runs its own tunnel
client over UDP, then the claim on this resource may have some
impact.
Note that ISPs may have multiple subscribers share a public IPv4
address by performing NAT (Carrier-Grade NAT in this context). In
this case, the subscribers' home gateways may receive an address in
the 100.64.0.0/10 block [RFC6598]. For the purposes of tunnel
mechanisms, this address block is similar to the RFC 1918 address
blocks. However, tunnel implementations that are aware of NAT and
RFC 1918 addresses may not recognise 100.64.0.0/10 as non-public
addresses and fail to operate successfully. The same issue is
present if an ISP decides to use regular global unicast IPv4 address
space behind a CGN.
5.3. MTU Considerations
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. However, when a tunnel terminates
directly on the host using it, the TCP maximum segment size (MSS)
option communicates the maximum packet size to the remote endpoint,
so TCP-based communication may still succeed. If not, the initial
TCP SYN/ACK exchange happens without issue, but then the session
stalls as the larger packets containing data are lost.
With tunnel mechanisms where the MTU is left unspecified, it is
possible for the two endpoints to have different MTUs: typically, one
uses the IPv6 minimum (1280 bytes), while the other uses the physical
MTU minus tunnel overhead (often 1480 bytes). In theory, this should
lead to PMTUD failures because the "big" side unknowingly sends
packets that the "small" side can't handle. However, in practice,
implementations handle incoming packets larger than their own MTU
without issue.
Only when the IPv4 MTU is reduced below 1500 bytes, for instance, when using PPP over Ethernet (PPPoE, [RFC2516]), issues are more likely to arise. So, when the possibility exists that tunneled packets encounter a PPPoE link, it is prudent to set the MTU of a tunnel to no more than 1472 bytes, so that tunneled packets don't have to be fragmented. Additionally, Section 3.2.1 of [RFC4213] recommends limiting the MTU of tunnels to a minimum of 1280 bytes. SEAL was specifically designed to overcome these limitations by adding the capability to fragment IPv6 packets prior to encapsulation in IPv4 and then to reassemble the fragments at the remote tunnel endpoint. This way, the SEAL tunnel ensures that packets that are no larger than 1500 bytes will be transported to the tunnel far end even if there are restricting links in the path. SEAL can also admit larger packets into the tunnel on a best-effort basis in case the path between the tunnel endpoints can support this larger size.5.4. IPv4 Addresses Embedded in IPv6 Addresses
Many tunnel mechanisms embed IPv4 addresses or further information in the IPv6 addresses they use. There are two possible reasons for this. First, with an IPv4 address embedded in the IPv6 address, the outer IPv4 header can be derived without a need to explicitly configure tunnel endpoints. Automatic tunneling, 6to4, ISATAP, 6bed4, and Teredo do this. 6over4 embeds the IPv4 address for the second reason; it is embedded in the Interface Identifier and thus the IPv6 address because, that way, a (presumably) globally unique Interface Identifier can be generated. Automatic tunneling uses IPv4-compatible addresses in the prefix ::/96 (i.e., the first 96 bits are all zero). | 96 bits | 32 | +------------------------------------------------+-----------------+ | 0:0:0:0:0:0 | IPv4 address | +------------------------------------------------+-----------------+ The IPv4-Compatible Address Structure Systems running 6to4 have addresses in the 6to4 prefix 2002::/16. | 16 bits | 32 | 16 | 64 | +---------+----------------+--------+------------------------------+ | 2002 | IPv4 address | Subnet | Interface ID | +---------+----------------+--------+------------------------------+ The 6to4 Address Structure
Because a 6rd domain might share a common IPv4 prefix, it is not
always necessary to encode all 32 bits of the IPv4 address in the 6rd
delegated prefix. The bits that become available because of this
optimisation can be used to provide more subnet IDs to the user
and/or to use a smaller address block for the 6rd prefix.
| n bits | o bits | m bits | 128-n-o-m bits |
+---------------+--------------+-----------+-----------------------+
| 6rd prefix | IPv4 prefix | Subnet ID | Interface ID |
+---------------+--------------+-----------+-----------------------+
|<--- 6rd delegated prefix --->|
The 6rd Address Structure
6over4 uses the IPv4 address to generate a 64-bit Interface
Identifier, which can then be used to create a 128-bit IPv6 address
through Stateless Address Autoconfiguration.
| 48 bits | 16 | 32 | 32 |
+---------------------+--------+-----------------+-----------------+
| Organisation prefix | Subnet | 0:0 | IPv4 address |
+---------------------+--------+-----------------+-----------------+
The 6over4 Address Structure
The ISATAP address structure is similar to the 6over4 address
structure, except that the unique/local (u) bit signifies whether the
IPv4 address in the Interface Identifier is unique. Presumably, this
is the case for any IPv4 address that is not as defined in RFC 1918.
The group (g) bit is set to zero, and the remaining bits are set to
0x00005EFE.
| 48 bits | 16 | 32 | 32 |
+---------------------+--------+-----------------+-----------------+
| Organisation prefix | Subnet | ug00:5EFE | IPv4 address |
+---------------------+--------+-----------------+-----------------+
The ISATAP Address Structure
Teredo embeds the Teredo server's IPv4 address, a number of flags,
and a UDP port number, as well as the Teredo client's IPv4 address in
the IPv6 addresses it creates. For good measure, the UDP port and
client IPv4 address are "obfuscated" by flipping their bits.
| 32 bits | 32 | 16 | 16 | 32 |
+----------------+---------------+-------+-------+-----------------+
| 2001:0 | Server IPv4 | Flags | Port | Client IPv4 |
+----------------+---------------+-------+-------+-----------------+
The Teredo Address Structure
6a44 can be seen as a combination of 6rd and Teredo. The 6a44 prefix
is given out by an ISP. Both the customer site (home gateway) IPv4
address as well as the host's/client's RFC 1918 IPv4 address and a
port number are embedded in the IPv6 address.
| 48 bits | 32 | 16 | 32 |
+----------------------+-----------------+-------+-----------------+
| 6a44 prefix | Cust. site IPv4 | Port | Client IPv4 |
+----------------------+-----------------+-------+-----------------+
The 6a44 Address Structure
6bed4 embeds two combinations of an IPv4 address and UDP port
(together acting as a "6bed4 address") in the IPv6 address. The
first address is for a tunnel server that everyone is certain to
reach; the other is for the direct address that most peers should be
able to reach directly. The tunnel server, however, is the only one
with guaranteed access to the direct address.
| 32 bits | 32 | 50 | 14 |
+----------+---------------------+-------------------------+-------+
| prefix |general 6bed4 address| direct 6bed4 address | lanIP |
+----------+---------------------+-------------------------+-------+
The 6bed4 Address Structure
The general 6bed4 address field conceals the well-known UDP port for
the 6bed4 service. The direct 6bed4 address field includes two extra
bits to adhere to the EUI-64 address format. The lanIP bits are free
for local purposes, such as creating a DHCPv6 range.
6. Evaluation of Tunnel Mechanisms
The following subsections deal with various aspects of tunnels that guide their selection.6.1. Efficiency of IPv4 Address Use
With the depletion of the IPv4 address space, the ability to deploy a tunnel mechanism behind NAT as well as the number of IPv6 subscribers, subnets, and individual hosts that can be supported behind a single IPv4 address have become important considerations. These issues are irrelevant to tunnel mechanisms that provide IPv6 connectivity between hosts within the same administrative domain, such as ISATAP or 6over4, as they can use private IPv4 addresses. This is also true for 6rd; it is used between an ISP and its customers' home gateways when the ISP has implemented NAT. 6to4 cannot work behind any kind of NAT. Most other mechanisms based on protocol 41 can work behind NAT, at least in principle. In practice, this difference is not as big because the protocol 41 encapsulation doesn't provide any fields that allow a NAT to demultiplex tunneled packets. This means that only a single protocol 41 tunnel endpoint can be supported for each public IPv4 address. This makes configured tunnels (as well as 6to4) incompatible with service-provider-operated NATs, where multiple subscribers share an IPv4 address. Teredo, 6a44, 6bed4, AYIYA, SEAL, and TSP are designed to work through NATs and use a UDP header, so multiple tunnel endpoints can be hosted behind a single IPv4 address. On the other hand, Teredo only provides IPv6 connectivity to a single host. The following table shows how many IPv4 addresses each tunnel mechanism requires and how many IPv6 hosts it can connect. The mechanisms are listed in order of increasing numbers of supported IPv6 hosts per IPv4 address.
+------------+-------------+-------------+-------------+------------+
| Mechanism | Tunnels per | IPv6 hosts | Public IPv4 | NAT |
| | IPv4 addr. | per tunnel | address | compatible |
+------------+-------------+-------------+-------------+------------+
| Auto. tun. | one | one | required | no |
| 6to4 | one | multiple | required | no |
| LISP | one | multiple | required | no |
| 6rd | one | multiple | not needed | no |
| Conf. tun. | one | multiple | not needed | limited |
| GRE | one | multiple | not needed | limited |
| Teredo | multiple | one | not needed | yes (*) |
| 6bed4 | multiple | multiple | not needed | yes |
| 6a44 | multiple | multiple | not needed | yes |
| AYIYA | multiple | multiple | not needed | yes |
| SEAL | multiple | multiple | not needed | yes |
+------------+-------------+-------------+-------------+------------+
Tunneled IPv6 Hosts per IPv4 Address
(*) Although Teredo is designed for NAT compatibility, it doesn't
work through all existing NATs.
6.2. Supported Network Topologies
There are two ways to use an IPv6-in-IPv4 tunnel to connect to the
IPv6 Internet: using a point-to-point tunnel to a tunnel broker or an
ISP-operated gateway, or using a Non-Broadcast Multi-Access (NBMA)
tunnel and anycasted public gateways or relays.
The advantages of the point-to-point model are predictable
performance and flexibility regarding the IPv6 addresses used. The
advantage of the NBMA model is that traffic between two hosts or
networks that both use the mechanism can flow directly without
passing through a gateway (direct peer-to-peer communication). An
extra advantage of the NBMA model with public gateways is automatic
configuration and no involvement from an ISP.
Unfortunately, the advantages of this NBMA public anycast model come
at a price: both the peer-to-peer connectivity between tunnel users
and the connectivity towards the native IPv6 Internet may suffer from
reliability and performance issues.
The anycast mechanism allows tunnel users to utilise the nearest
gateway to connect to the IPv6 Internet by simply giving each gateway
the same address. Routing protocols then select the lowest-cost (and
presumably, shortest) path towards a gateway. However, this makes
the path taken by tunneled packets hard to predict or influence. It
is common for traffic in two directions to use different gateways,
complicating debugging even further. Because nobody is in charge or
gets paid for operating a gateway, the number of public gateways is
lower than would be ideal. This increases the distance to the
nearest gateway for some users. There is also the possibility that
gateways encounter more traffic than they can handle.
The advantage of a tunnel provided by an ISP or tunnel broker is that
there is a clear responsibility for providing a good service with
well-maintained gateways.
+------------+---------------+--------------------------------+
| Mechanism | Peer-to-peer | Gateway provided by |
+------------+---------------+--------------------------------+
| Conf. tun. | No | ISP or tunnel broker |
| AYIYA | No | ISP or tunnel broker |
| GRE | No | N/A |
| 6a44 | Within domain | ISP |
| 6rd | Within domain | ISP |
| 6over4 | Globally | N/A |
| ISATAP | Within domain | Own organisation |
| Teredo | Globally | Public |
| 6to4 | Globally | Public or ISP |
| 6bed4 | Globally | Public or ISP or tunnel broker |
| Auto. tun. | Globally | N/A |
| LISP | Configurable | ISP or tunnel broker |
| SEAL | Configurable | ISP or tunnel broker |
+------------+---------------+--------------------------------+
Topologies Supported per Tunnel Mechanism
6.3. Robustness
Tunnels may fail for three main reasons: when tunneled packets are
filtered, typically by a firewall; when a tunnel endpoint IPv4
address changes; or when tunneled packets are filtered or because of
NAT issues.
If a tunnel endpoint gets a new address, the other side of the tunnel
needs to know to send packets to the new address. With mechanisms
that derive IPv6 addresses from the IPv4 address, the previous IPv6
addresses become unreachable, and new IPv6 addresses must be
configured.
Some tunnel mechanisms don't work through NAT, or are limited when
working through NAT. NAT mappings can typically only be created by
traffic from the "inside" to the "outside", not by traffic from
outside the NAT to the network behind the NAT.
Point-to-point tunnel mechanisms either work consistently or they
always fail. As such, a simple ping to the other side of the tunnel
is sufficient to learn its state. Also, point-to-point tunnels may
support routing protocols, which can automatically reroute traffic
around a failed tunnel.
Some tunnel mechanisms use a public gateway to reach the native IPv6
Internet. Public gateways may or may not be operational and/or
reachable, and they may have limited performance, depending on
distance and usage.
Tunnel mechanisms that use a broadcast or Non-Broadcast Multi-Access
(NBMA) communication model may experience failures between some
combinations of tunnel endpoints and not others.
The following table lists tunnel mechanisms that provide connectivity
to the IPv6 Internet in order of decreasing robustness. (However,
even less-robust mechanisms may function well in suitable
environments.)
+------------+---------------+--------------------------------------+
| Mechanism | Endpoint | Main issues |
| | address | |
| | change | |
+------------+---------------+--------------------------------------+
| LISP | automatic | None |
| 6rd | interrupt | None |
| AYIYA | automatic | Transient NAT mapping issues |
| Conf. + | interrupt | Proto 41 filtering, competition for |
| Heartbeat | | NAT mappings (1) |
| Conf. tun. | failure | Proto 41 filtering, competition for |
| | | NAT mappings, address change (1) |
| GRE | failure | Proto 47 filtering, address change |
| 6a44 | interrupt | NAT mapping towards peers |
| 6bed4 | interrupt | NAT mapping towards peers |
| 6to4 | interrupt | Enabled out of the box but filtered, |
| | | gateway performance (2) |
| Teredo | interrupt | NAT compatibility, mapping towards |
| | | peers (3) |
+------------+---------------+--------------------------------------+
Susceptibility of Tunnel Mechanisms to Problems
Notes:
(1): Only one protocol 41 tunnel endpoint can receive a NAT mapping
behind a NAT using a single public IPv4 address. Additional
endpoints will not receive incoming packets. When a tunnel
endpoint changes its internal address, the old NAT mapping
needs to time out before a new one can be created.
(2): 6to4 implementations automatically disable the mechanism when
the system has an RFC 1918 address. However, 6to4 may remain
enabled and be non-operational when ISPs apply NAT using
addresses that are not as defined in RFC 1918 [RFC6598].
(3): Whether Teredo can obtain an address depends on the type of NAT
it detects. Whether Teredo functions at such an address
depends on the accuracy of that determination, which is founded
on an incomplete model of NAT.
On some widely used implementations, 6to4 has been enabled by default
without checking whether there was connectivity to the anycasted
public gateway address. As a result, 6to4-derived connectivity to
the IPv6 Internet was often found to be broken because of protocol 41
filtering. Because of this, many operating systems now try to avoid
using IPv6 over 6to4. See [RFC6343].
Also see [TERTST] for more information about the robustness of
Teredo.
There is not a single tunnel mechanism that is more robust in all
possible ways than every other tunnel mechanism. However, in
general, mechanisms that use public gateways and peer-to-peer
tunneling tend to have the most issues. Configured tunnels, on the
other hand, often work very well, especially if there is no NAT on
the path, but they may need administrative intervention when a tunnel
endpoint address changes.
6.4. Gateway State
There is an additional consideration that is important to operators
of gateways that connect IPv6-in-IPv4 tunnels to the IPv6 Internet:
how much state a tunnel mechanism requires.
6to4, 6rd, 6a44 and 6bed4 require no state at all: when encapsulating
IPv6 packets inside an IPv4 packet, the IPv4 destination address is
directly copied from bits in the IPv6 destination address. This
makes all possible tunneled destinations directly reachable through a
single virtual interface.
Teredo relays maintain a list of peers and are intended to service a limited number of hosts. The Teredo server, however, is a stateless gateway component. With configured tunnels, GRE, AYIYA, and SEAL, there is no direct mapping from (part of) the IPv6 destination address to the IPv4 destination address. A typical implementation of these mechanisms has a virtual tunnel interface for each tunnel. Packets are forwarded to the correct virtual interface through a routing table lookup. Routing tables can grow very large and remain fast, so the number of virtual interfaces tends to be the limiting factor for tunnel gateways. AYIYA and the SixXS Heartbeat Protocol also keep track of the reachability status of each tunnel.6.5. Performance
There are several reasons why tunneled connectivity may perform inferior to native, untunneled connectivity. Inherently, tunnels add one or more extra headers, and therefore increase overhead. However, for an Ethernet packet of maximum size (1500 bytes), the additional overhead of an IPv4 header is only 1.3%. 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. The path that tunneled packets take can be longer than the path that untunneled packets would take (i.e., increased path stretch can occur). This may or may not lead to decreased performance.
+------------+-----------------+----------------------+-------------+
| Mechanism | Overhead | Increased path | Variability |
| | (bytes) | stretch | |
+------------+-----------------+----------------------+-------------+
| Conf. tun. | 20 | may be large | none |
| Auto. tun. | 20 | none | none |
| 6over4 | 20 | none | none |
| GRE | 28 - 36 | may be large | none |
| 6to4 | 20 | may be large | high |
| AYIYA | 72 | may be large | low |
| ISATAP | 20 | none | none |
| Teredo | 28 - 36 | may be large | high |
| 6rd | 20 | small | low |
| 6a44 | 20 - 28 | small | low |
| 6bed4 | 28 | may be large | high |
| LISP | 36 | small | low |
| SEAL | 24 - variable | small | low |
+------------+-----------------+----------------------+-------------+
Typical Tunnel Performance
7. Security Considerations
There are many security considerations with tunneling. An important
one is that through a tunnel, connectivity to the IPv6 Internet may
exist even though network administrators did not intend for it to be
there. "Security Concerns with IP Tunneling" [RFC6169] discusses
this issue in detail.
Although, in principle, ingress filtering (BCP 38, [RFC2827]) is
possible with tunnels, in practice, it is relatively easy for spoofed
packets to make their way through a tunnel. Not only is it often
easy to spoof the outer IPv4 header and make false IPv6 packets seem
to originate from a tunnel broker or gateway, it may also be possible
for an attacker to route false IPv6 packets through a legitimate
tunnel broker or gateway. Many tunneling protocols have various
means of detecting and rejecting such packets, while others have
limited or no such provisions. For instance, see [RFC3964] for how
this can be addressed with 6to4.
So it is important to recognise that unless special measures are
taken (like [RFC4301]), both IPv4 and IPv6 addresses in tunnel
packets may be spoofed and cannot be relied upon for access controls.
Such spoofing was used successfully to discover IPv6-in-IPv4 tunnels
in [TUNDISC].
Tunnels may also be used by third parties to obfuscate their activities or perform amplification attacks. To avoid contributing to this problem, it is important to make sure only locally generated packets with legitimate addresses are sent out over tunnels.8. Contributors
Job Snijders contributed text to the points of comparison. Fred Templin provided the text for SEAL and contributed to the security considerations. Jeroen Massar, Brian Carpenter, Tina Tsou, John Mann, Suresh Krishnan, Victor Kuarsingh, Dan Jones, Nejc Skoberne, and Fred Baker reviewed the document and/or offered suggestions for improvement.9. Acknowledgements
We wish to thank SURFnet and Rogier Spoor for commissioning this work; both their initiative and funding have helped this document to be written.10. Informative References
[6BED4] Van Rein, R., "6bed4: Peer-to-Peer IPv6 on Any Internetwork", Work in Progress, July 2013. [AICCU] SixXS, "Automatic IPv6 Connectivity Client Utility (AICCU)", <http://www.sixxs.net/tools/aiccu/>. [AYIYA] SixXS, "Anything In Anything (AYIYA)", <http://www.sixxs.net/tools/ayiya/>. [GOGO6] gogo6, "Freenet6: Free and Easy IPv6 Connectivity", <http://www.gogo6.com/freenet6>. [HEARTBEAT] Massar, J., "SixXS Heartbeat Protocol", Work in Progress, June 2005. [LISPBETA] LISP4/LISP6.net, "LISP Beta Network", <http://www.lisp4.net/beta-network/>. [MAP] Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T., and T. Taylor, "Mapping of Address and Port with Encapsulation (MAP)", Work in Progress, August 2013. [MASSAR] Massar, J., "AYIYA: Anything In Anything", Work in Progress, July 2004.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC1933] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996. [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996. [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999. [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999. [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [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. [RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000. [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001. [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.
[RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, December 2004. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H. Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", RFC 4891, May 2007. [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. [RFC5572] Blanchet, M. and F. Parent, "IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)", RFC 5572, February 2010. [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010. [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns with IP Tunneling", RFC 6169, April 2011. [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011. [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", RFC 6343, August 2011. [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, April 2012. [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012. [RFC6732] Kuarsingh, V., Lee, Y., and O. Vautrin, "6to4 Provider Managed Tunnels", RFC 6732, September 2012. [RFC6751] Despres, R., Carpenter, B., Wing, D., and S. Jiang, "Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44)", RFC 6751, October 2012. [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013. [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites", RFC 6832, January 2013. [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, January 2013. [SEAL] Templin, F., "The Subnetwork Encapsulation and Adaptation Layer (SEAL)", Work in Progress, October 2013. [SIXXS] Massar, J. and P. van Pelt, "IPv6 Deployment & Tunnel Broker", <http://www.sixxs.net/>. [TERTST] Huston, G., "Testing Teredo", April 2011, <http://www.potaroo.net/ispcol/2011-04/teredo.html>. [TIC] SixXS, "Tunnel Information and Control protocol (TIC)", <http://www.sixxs.net/tools/tic/>.
[TR-069] The Broadband Forum, "CPE WAN Management Protocol", July 2011, <http://www.broadband-forum.org/technical/ download/TR-069_Amendment-4.pdf>. [TUNBROKER] Hurricane Electric, "Hurricane Electric Free IPv6 Tunnel Broker", <http://www.tunnelbroker.net/>. [TUNDISC] Colitti, L., Di Battista, G., and M. Patrignani, "IPv6-in-IPv4 tunnel discovery: methods and experimental results", IEEE eTransactions on Network and Service Management (eTNSM), vol. 1, no. 1, p. 2-10, April 2004.
Appendix A. Evaluation Criteria
Each type of tunnel has specific advantages and disadvantages. We have considered the following points when evaluating the different protocols. Not every point is mentioned in each section where a protocol is described, only those that are specifically relevant to that protocol. Protocol overhead: How much overhead does the tunneling protocol cause? There are two factors that play a role: the number of interactions to set up the tunnel and the packet header size causing a lower MTU and/or fragmentation. Automatic configuration: Does this protocol require manual configuration at the endpoints? Predictability: How predictable is the functioning of the protocol? Single host or network: Is this protocol intended to be used by a single host or by a router that then provides IPv6 connectivity to multiple hosts? Load balancing: Does the tunnel traffic have enough entropy and/or "hashability" to be able to be load-balanced over multiple links, or do all tunnel packets have the same outer 5-tuple? Path stretch: Does the tunnel optimise the route, or is there a big potential for a much longer path when using the tunnel? NAT traversal: Can the tunnel pass through a NAT gateway, and does it require configuration on that NAT gateway? Tunnel endpoint mobility: Are the IPv4 addresses of the tunnel fixed, or do they adjust automatically when an endpoint moves? State: Are the endpoints required to keep state for the tunnel, or is the tunnel stateless? Network type: Is this network a point-to-point or NBMA type of network? Purpose: What is the intended purpose of this tunnel protocol? Related protocols: To which protocols is this tunnel protocol related? Are there alternatives? Implementations: Is this protocol supported on the major operating systems, routers, and firewalls?
Limitations: What are the known limitations of this protocol?Authors' Addresses
Sander Steffann S.J.M. Steffann Consultancy Tienwoningenweg 46 Apeldoorn, Gelderland 7312 DN The Netherlands EMail: sander@steffann.nl Iljitsch van Beijnum Institute IMDEA Networks Avda. del Mar Mediterraneo, 22 Leganes, Madrid 28918 Spain EMail: iljitsch@muada.com Rick van Rein OpenFortress Haarlebrink 5 Enschede, Overijssel 7544 WP The Netherlands EMail: rick@openfortress.nl