Supported Network Topologies - Evaluation of Tunnel Mechanisms

6. Evaluation of Tunnel Mechanisms

6.2. Supported Network Topologies

| 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 | +---+---+---+

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.)

+---+---+---+

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

performance CPUs. If tunnel encapsulation must then be done by that relatively slow CPU, performance will be worse than regular 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.

+---+---+---+---+

| 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, 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

Dans le document This is a contribution to the RFC Series, independently of any other RFC stream (Page 29-0)