A Comparison of IPv6 over IPv4 Tunnel MechanismsS.J.M. Steffann ConsultancyTienwoningenweg 46ApeldoornGelderland7312 DNThe Netherlandssander@steffann.nlInstitute IMDEA NetworksAvda. del Mar Mediterraneo, 22LeganesMadrid28918Spainiljitsch@muada.comOpenFortressHaarlebrink 5EnschedeOverijssel7544 WPThe Netherlandsrick@openfortress.nlInternet-DraftIPv6Tunnel
This document provides an overview of
various ways to tunnel IPv6 packets over
IPv4 networks. It covers mechanisms in
current use, touches on several
mechanisms that are now only of historic
interest, and discusses some newer tunnel
mechanisms that are not (yet) widely used at
the time of publication. The goal of the document is
helping people with an IPv6-in-IPv4
tunneling need to select the mechanisms that
may apply to them.
During the transition from IPv4 to IPv6,
IPv6 islands are separated by a sea of IPv4.
Tunnels provide connectivity between these
IPv6 islands. Tunnels work by encapsulating
IPv6 packets inside IPv4 packets, as shown
in the figure.
Various tunnel mechanisms have
been proposed over time. So many in fact,
that it is difficult to get an overview.
Some tunnel mechanisms have been abandoned by the
community, others have known problems and
yet others have shown to be reliable.
Some tunnel mechanisms were designed with a particular
use-case in mind, others are generic. There
may be documented limitations as well as
limitations that have cropped up in deployment.
This document provides an overview
of available and/or noteworthy tunnel mechanisms, with the
intention to guide selection of the best
mechanism for a particular purpose.
As such, the discussion of the different
tunnel mechanisms is limited to the working
principles of the different mechanisms and a
few important details.
Please use the
references to learn the full details of each
mechanism.
For brevity, only the most relevant
documents are referenced. Refer to
these for additional specifications, updates
and links to older versions of protocol
specifications as well as links to more
general background information.
The intended audience for this
document is everyone who needs a connection
to the IPv6 internet at large, but is not in
the position to use native (untunneled) IPv6
connectivity, and thus needs to select an
appropriate tunnel mechanism. This
document is also intended as a quick
reference to tunnel mechanisms for the IETF
community.
The scope of this document is limited to
tunnel mechanisms for providing IPv6
connectivity over an IPv4 infrastructure.
Mechanisms for Virtual Private Networks
(VPNs) and security architectures such as
IPSec are out
of scope for this document as they serve a
different purpose, even if they could
technically be used to provide IPv6
connectivity.
Mechanism to provide a service, in multiple locations
and/or using multiple servers, by configuring each server with the same
IP address.
Also known as "dual IP layer".
Nodes run IPv4 and IPv6 side by side,
and can communicate with other dual stack nodes (using IPv4
or IPv6), as well as IPv4-only nodes (using IPv4) and
IPv6-only nodes (using IPv6). Most current operating systems
are set up to use IPv4 when available as well as use IPv6 when available,
allowing them to run in IPv4-only, IPv6-only or dual stack mode
as circumstances permit.
Except for a few things concerning the Domain Name System (DNS),
there is no separate specification for
dual stack beyond the specifications relevant to running IPv4 and IPv6.
Dual stack is one of the three IPv4-to-IPv6 transition tools; the others
are translation and tunnels.
Transporting packets as data inside another packet. For instance,
an IPv6 packet inside an IPv4 packet.
A device that communicates using the Internet Protocol, but
that is not a router.
Internet Service Provider; the party connecting the outside of the
local network's perimeter to the public Internet.
Maximum Transmission unit, the maximum size of a packet that
can be transmitted over a link (or tunnel) without splitting it into
multiple fragments.
Network Address Translation or Network Address Translator.
NAT makes it possible for a number of hosts to
share a single IP address. TCP and UDP port numbers are used
to distinguish the traffic to/from different hosts served
by the NAT; protocols other than TCP and UDP may be
incompatible with NAT due to lack of port numbers.
NAT also breaks protocols that depend on the IP addresses
used in some way.
Non-Broadcast, Multiple Access. This is a network configuration
in which nodes can exchange packets directly by addressing them
at the desired destination.
However, broadcasts or multicasts are not
supported, so autodiscovery mechanisms such as IPv6 Neighbour
Discovery don't work.
A device that implements IP, either a host or a router;
also known as a system.
The difference between the shortest path through the
network and the path (tunneled) packets actually take.
Path MTU Discovery, a method to determine the smallest MTU on the path between two
nodes. There are separate specifications for PMTUD over
IPv4 and IPv6 .
A device that forwards IP packets that it didn't
generate itself.
A device that implements IP, either a host or a router; a network node.
The IPv6 and IPv4 headers are similar enough that it is possible to
translate between them. This allows IPv6-only hosts to communicate
with IPv4-only hosts. The original
specification for translating between IPv6 and IPv4, was
heavily criticised by the Internet Architecture Board,
but new specifications
for translating between IPv6 and IPv4 were later published
.
Translation is of the three IPv4-to-IPv6 transition tools; the others
are dual stack and tunnels.
By encapsulating IPv6 packets inside IPv4 packets, IPv4-capable
hosts and IPv6-capable networks isolated from other IPv6-capable
systems or the IPv6 internet at large can exchange IPv6 packets
over IPv4-only infrastructure. There are numerous ways to
tunnel IPv6 over IPv4. This document compares these mechanisms.
One of the three IPv4-to-IPv6 transition tools; the others
are translation and dual stack.
A service that provides tunneled connectivity to the IPv6 internet,
such as , and .
Automatic tunnels,
configured tunnels,
6over4,
6to4,
ISATAP
and
6rd
solve similar problems at different scales.
They all encapsulate IPv6 packets immediately inside an IPv4 packet,
without using additional headers. This is called "protocol 41 encapsulation"
(see ),
as the Protocol field in the IPv4 header is set to 41
to indicate that what follows is an IPv6 packet.
Each of these mechanisms also creates an IPv6 address for the host
or router running the protocol based on the system's IPv4 address
in one way or another (see ).
This lets 6to4, 6rd, ISATAP and automatic tunnels determine the
IPv4 destination address in the outer
IPv4 header from the IPv6 address of the destination, allowing for
automatic operation without the need to administratively configure
the remote tunnel endpoint.
6over4 and ISATAP provide IPv6 connectivity between IPv6-capable
systems within a single organisation's network that is otherwise
IPv4-only. 6rd allows ISPs to provide IPv6 connectivity to their
customers over IPv4-only last mile infrastructures. 6to4
directly provides connectivity to the global IPv6 internet
without involving an ISP.
Configured tunnels also use
protocol 41 encapsulation, but rely on manual configuration
of the remote tunnel endpoint.
(The Heartbeat Protocol solves this.)
Configured tunnels can be
used within an organisation's network, but are typically
used by tunnel broker services to provide connectivity to
the IPv6 internet.
GRE is similar to configured tunnels,
but also supports tunnel protocols other than IPv6.
AYIYA is similar to configured
tunnels and GRE, but typically uses a UDP header for better
compatibility with NATs and is generally used with
TIC to set up the tunnel rather
than rely on manual configuration.
Teredo,
6a44 and
6bed4
are similar to 6to4, except
that they are designed to work through NATs by running over UDP.
Of these, Teredo and 6bed4 assume no ISP involvement and 6a44 does;
and 6bed4 is designed to work over direct IPv4 paths between peers
whenever possible.
LISP is a system for abstracting
the identifying function from the location function of IP addresses,
which allows for the use of IPv6 for the former and IPv4 for the latter.
Dual-Stack Lite
and MAP , both developed by the IETF Softwire
working group, often come up in discussions
about IPv6 tunneling. However, they are
not IPv6-in-IPv4
tunnel mechanisms. They are IPv4-in-IPv6
mechanisms for providing IPv4 connectivity
over an IPv6 infrastructure.
Please refer to for more information about
issues common to many tunnel mechanisms; those issues are not
discussed separately for each mechanism.
The mechanisms are discussed below in roughly chronological order of first
publication.
Configured and automatic tunnels are the two oldest tunnel mechanisms,
originally published in "Transition Mechanisms for IPv6 Hosts and Routers"
in 1996. The latest specification of configured
tunnels is "Basic Transition Mechanisms for IPv6 Hosts and Routers"
, published in 2005.
The mechanism is sometimes called "manual tunnels", "static tunnels",
"protocol 41 tunnels" or "6in4".
Configured tunnels connect two systems in point-to-point fashion
using protocol 41 encapsulation.
The configuration that the name of the mechanism alludes to consists
of a remote "tunnel endpoint". This is the IPv4 address of the system
on the other side of the tunnel. When a system (potentially) has
multiple IPv4 addresses, the local tunnel endpoint address may also
need to be configured.
The need to explicitly set up a configured tunnel makes them more
difficult to deploy than automatic mechanisms. However, because there
is a fixed, single remote tunnel endpoint, performance is predictable
and easy to debug.
In the early days it was not unheard
for a small network to get IPv6 connectivity from another continent.
This excessive path stretch makes communication over short geographic
distances much less efficient because the distance travelled by packets
may be larger than the geographic distance by an order of
magnitude or more.
Configured tunnels are
widely implemented. Common operating systems can terminate configured
tunnels, as well as IPv6-capable routers and home gateways.
The mechanism is
versatile, but is mostly used between isolated smaller IPv6-capable
networks and the IPv6 internet, often through a "tunnel broker"
such as tunnelbroker.net ,
SixXS or .
discusses the use of IPsec to
protect the confidentiality and integrity of IPv6 traffic
exchanged over configured tunnels.
Automatic tunneling is described in ,
"Transition Mechanisms for IPv6 Hosts and Routers",
but removed in , which is an update
of RFC 2893. Configured tunnels
are closely related to automatic tunnels and are
specified in RFCs 2893 and 4213, too. Both use protocol 41
encapsulation.
Hosts that are capable of automatic tunneling
use special IPv6 addresses: IPv4-compatible addresses.
An IPv4-compatible IPv6 address consists of 96 zero bits
followed by the system's IPv4 address. When sending
packets to destinations within the IPv4-compatible
::/96 prefix, the IPv4 destination address in the outer
IPv4 header is taken from the IPv4 address in the
IPv4-compatible IPv6 destination address.
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 and is not
implemented in current operating systems, as
6to4
does what automatic tunneling was supposed to do, but
also provides connectivity to the rest of the IPv6 internet.
"Transmission of IPv6 over IPv4 Domains
without Explicit Tunnels" was published in 1999.
The mechanism is commonly known as "6over4".
6over4 is designed to work within a single organisation's IPv4
network, where IPv6-capable hosts and routers are separated by
IPv4-only routers. 6over4 treats the IPv4 network as a "virtual
Ethernet" for the purpose of IPv6 communication. It uses IPv4
multicast to tunnel IPv6 multicast packets. A node's IPv4 address
is included in the Interface Identifier used on the virtual 6over4
interface, allowing the exchange of protocol 41 encapsulated packets
between 6over4 nodes without prior administrative configuration.
Because multicast is supported, standard IPv6 Neighbour Discovery and
Stateless Address Autoconfiguration can be
used. Although like automatic tunnels and
other mechanisms, 6over4 embeds the IPv4 address of the host is in the IPv6 address,
the destination IPv4 address in the outer IPv4 header is not derived
from the IPv6 address embedded in the inner IPv6 header, but learnt through Neighbour Discovery .
In effect, the IPv4 addresses of the hosts are used
as link-layer addresses, in the same way that MAC addresses are used
on Ethernet networks.
One or more routers with connectivity to the global IPv6 internet
send out Router Advertisements to provide 6over4 hosts with
connectivity to the rest of the IPv6 internet.
6over4 has the minimal protocol 41 encapsulation overhead and
doesn't require manual configuration.
Hosts can only take advantage of 6over4 if they run the mechanism
themselves. 6over4 packets can't pass through a NAT successfully,
as the IPv4 address exchanged through Neighbour Discovery will be
different from the one needed to reach the host in question, and
because without port numbers, protocol 41 doesn't allow for
multiplexing multiple hosts using this encapsulation behind a single
IPv4 address. However, 6over4 works within IPv4 domains that reside behind a NAT in their entirety and use
addressing.
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 provides
very similar functionality without requiring IPv4 multicast
capability, and is implemented more widely.
Generic Routing Encapsulation (GRE) is a generic point-to-point tunnel mechanism that
allows many other protocols to be encapsulated in IP.
GRE is a simple protocol which is similar to configured tunnels when used for IPv6-in-IPv4
tunneling. The main benefit of GRE is that is can not only
encapsulate IPv6 packets but any protocol. The GRE header
causes an extra overhead of 8 to 16 bytes depending on which
options are used. GRE sets the Protocol field in the IP
header to 47.
The GRE header can optionally contain a checksum, a key to
separate different traffic flows (for example, different
tunnels) between the same end points and a sequence number
that can be used to prevent packets from being processed out of order.
GRE is implemented in many routers, but not in most
consumer-level home gateways or desktop operating systems.
6to4 is specified in "Connection of IPv6 Domains via IPv4
Clouds" . It creates a block of
IPv6 addresses from a locally configured IPv4 address by
concatenating that IPv4 address to the prefix 2002::/16,
resulting in a /48 IPv6 prefix. Addresses in 2002::/16 are
considered reachable through the tunnel interface, so the
6to4 network functions as a non-broadcast, multiple access
(NBMA) network through which 6to4 users can communicate.
IPv6 packets are encapsulated by adding an IPv4 header with
the Protocol field set to 41.
The /48 prefix allows a single system running 6to4 to act as
a gateway or router for a large number of IPv6 hosts.
Alternatively, an individual host may run 6to4 and not act
as a gateway or router. The system running 6to4 must have a
globally reachable IPv4 address. Using 6to4 with a private IPv4
address is not possible.
"An Anycast Prefix for 6to4 Relay Routers" specifies an anycast mechanism for 6to4
relays that provide connectivity between the 6to4 network
and the regular IPv6 internet. All public relays share the
IPv4 address 192.88.99.1, which corresponds to
2002:c058:6301::. Relays advertise reachability towards
2002::/16 towards the native IPv6 internet, so packets
addressed to systems using 6to4 addresses are routed to the
closest gateway. The gateway encapsulates these packets and
forwards them to the IPv4 address included in the IPv6
address. Systems running 6to4 have a default route pointing
to 2002:c058:6301::, so they tunnel packets addressed to
non-6to4 IPv6 destinations to the closest relay, which
decapsulates the packet and forwards them as IPv6 packets.
The 6to4 protocol adds minimal protocol 41 overhead
and requires no manual configuration from
users. The biggest problem specific to 6to4 is that it is
unpredictable which 6to4 anycast relay is used. These
relays are often provided by third parties on a best-effort
basis. In practice this has caused unpredictable
performance.
Traffic from the 6to4 network to the regular IPv6 internet
will likely use a different 6to4 relay than the traffic in
the opposite direction. If either of those relays is not
reliable then the communication between those networks
is affected. Especially the lack of control over the
relay used for return traffic is considered to be a problem
with 6to4.
To avoid problems with 6to4 the IPv6 Default Address
Selection algorithm gives IPv4
addresses a higher preference than 6to4 addresses. When
making a connection a system will prefer native IPv6 over
IPv4, and IPv4 over 6to4 IPv6. This causes 6to4 to be used
only when a destination is not reachable over IPv4 and no
other IPv6 connectivity is available.
For more information about 6to4, see "Advisory
Guidelines for 6to4 Deployment" .
Warning:
Although many, if not all, 6to4 implementations disable the
mechanism when the system only has an RFC 1918 address,
recently a block of IPv4 address has been set aside for use
in service provider operated Network Address Translators,
also known as Carrier Grade NAT (CGN). sets aside the block 100.64.0.0/10 for
the use between CGNs and subscriber devices. As
100.64.0.0/10 is not an RFC 1918 address block, systems
implementing 6to4 may fail to disable the mechanism, but due
to the shared nature of the 100.64.0.0/10 prefix, 6to4
cannot work using these addresses.
AYIYA is designed for use by the
SIXXS tunnel broker service.
The specification has been published as an Internet-Draft
.
The AYIYA protocol defines a method for encapsulating any
protocol in any other protocol. The most common way of
deploying AYIYA is to use the following sequence of headers:
IPv4-UDP-AYIYA-IPv6, although other combinations like
IPv4-AYIYA-IPv6 or IPv6-SCTP-AYIYA-IPv4 are also possible.
The draft does not limit the contents nor the protocol that
carries the AYIYA packets. In this document we only look at
the most common usage (IPv4-UDP-AYIYA-IPv6) which is
deployed on the SixXS tunnel brokers to provide IPv6 access
to clients behind NAT devices.
AYIYA specifies the encapsulation, identification, checksum,
security and certain management operations that can be used
once the tunnel is established. It does not specify how the
tunnel configuration parameters can be negotiated.
Typically, the TIC protocol described in
protocol is used for that part of the tunnel setup,
although the TSP protocol
could be used.
AYIYA provides a point-to-point tunnel, over which the
endpoints can route traffic for any source and destination.
When using SHA-1 hashing for authentication, as is common
when using the AICCU client with a SixXS tunnel server, the
total packet overhead is 72 bytes (20 for the IPv4 header, 8
for UDP and 44 for AYIYA).
AYIYA provides operational commands for querying the
hostname, address, contact information, software version and
last error message. An operational command to ask the other
side of the tunnel to shut down is also available. These
commands in the protocol can make debugging of AYIYA tunnels
easier if the tools support them.
The main advantage of AYIYA is that it can provide a stable
tunnel through an IPv4 NAT, and possibly multiple layers of
NAT. The UDP port numbers allow multiple AYIYA users to
share a single IPv4 address behind a NAT.
The client will contact the tunnel
server at regular intervals and the tunnel server will
automatically adapt to changing IPv4 addresses and/or UDP
port numbers. To prevent a third party from injecting rogue
packets into the tunnel the client can optionally be
authenticated by using the identity and signature fields. A
timestamp is included in the AYIYA header to guard against
replay attacks.
There is currently a single
implementation of this protocol:
the AICCU client software used with the
SIXXS tunnel broker service.
ISATAP uses protocol 41 encapsulation,
to provide connectivity between isolated IPv6-capable nodes within an organisation's internal network.
It is similar
to 6over4, but without the requirement that
the IPv4 network supports multicast; unlike 6over4, ISATAP uses a
Non-Broadcast Multiple Access (NBMA) communication model
and thus doesn't support multicasts.
The mechanism assigns
IPv6 addresses whose interface identifier is solely defined by a node's
IPv4 address, which is assumed to be unique.
In order to obtain a /64 prefix, an ISATAP tunnel endpoint needs to
send a Router Solicitation. Without the ability to send and receive
IPv6 multicasts, an ISATAP host must be configured with a Potential
Router List through an all-IPv4 mechanism, such as manual setup, DHCP
or the DNS. Site administrators are encouraged to use a DNS Fully
Qualified Domain Name using the convention "isatap.domainname" (e.g.,
isatap.example.com). Hosts will accept packets with IPv4 sender
addresses that are either on the Potential Router List, or that are
embedded in the IPv6 sender address.
The router's prefix and the IPv4 address together define the IPv6
address for the ISATAP interface. This means that precisely one ISATAP
address is available for each IPv4 address. As such, each host needs
to run ISATAP itself in order to enjoy ISATAP IPv6 connectivity.
The IPv4 address in the
destination IPv6 address is used to bootstrap Neighbour Discovery.
doesn't explicitly address the use of ISATAP
using private addresses. Despite that, the
mechanism seems compatible with private addresses. NAT, however, breaks
the relationship between the IPv4 address embedded in the IPv6 address
and would therefore make communication between ISATAP hosts impossible.
Any device that can communicate with the ISATAP hosts over IPv4 using
protocol 41 can participate in the IPv6 subnet.
ISATAP is available in Windows, Linux and Cisco IOS. It is not recommended
to be run on production networks running Windows if
native IPv6 is available.
Teredo is specified in
and a few updates; it is designed as an automatic tunnel mechanism of last resort.
It can configure an IPv6 address behind most NAT devices, but not all.
Because Teredo uses
encapsulation in UDP, multiple Teredo clients can be simultaneously active
behind the same NAT. For each Teredo client, a single IPv6 address
is then created at the expense of a single external UDP port.
The operation of Teredo
is based on a classification of NAT as
established during an interaction with a Teredo server. This classification
has since been obsoleted because it assigns
more properties to NAT than achieved in reality.
Teredo is present in Windows XP and later, and is enabled by default
in Windows Vista and later.
However, Windows will only use Teredo connectivity as a way to connect
to IPv6 destinations of last resort. If no other IPv6 connectivity is
present, Windows will not even look up AAAA records when resolving domain names.
This means that Teredo is only used
to connect to explicit IPv6 addresses obtained through another
mechanism than DNS.
An open source
implementation named Miredo exists for other platforms.
The performance of Teredo falls noticeably short of that of IPv4.
The setup time of a connection involves finding a Teredo relay
nearby the native address to encapsulate and decapsulate traffic, and
finding this relay can take in the order of seconds.
This process is not sufficiently reliable;
Teredo fails in
about 37% of its attempts to connect to
native IPv6 destinations.
The round trip time of traffic can add tenths of a second, and jitter
generally worsens if it is dependent on a public relay.
Teredo clients need to be configured with a Teredo server
when setting up their local IPv6 address and when initiating a connection to
a native IPv6 destination. The hostnames of the Teredo servers are usually
pre-configured by the vendor of the Teredo implementation. All Microsoft
Windows implementation use Teredo servers provided by Microsoft by default.
6rd is used by service
providers to connect customer networks behind a CPE to the
IPv6 internet.
The structure of the 6rd protocol is based on 6to4 and it
has the same minimal overhead as all protocols that use
protocol 41 encapsulation. The main differences between 6rd
and 6to4 are that 6rd is meant to be used inside a service
provider's network and does not use a special IPv6 prefix
but one or more prefixes routed to the service provider. As
such, 6rd users aren't immediately recognisable by their
IPv6 address the way 6to4 users are. Where 6to4 uses
relays based on global anycast routing 6rd uses
relays provided and maintained by the service provider.
Because of this architecture the tunnel does not traverse
unknown networks which makes any debugging much easier.
6rd is completely stateless once it is configured. The
tunnel endpoints can therefore be deployed using anycast.
This is commonly done for the 6rd border relays deployed by
the service provider to provide redundancy.
Because of the different prefix, the device used as the 6rd
client cannot use the hard-coded IPv6 prefix calculation and
relay addresses of 6to4. Instead, the 6rd client needs to
receive configuration information to work. In principle 6rd
nodes may be configured in a variety of ways, the most
common one being through DHCP. If the client receives its
IPv4 address from a DHCPv4 server then the 6rd configuration
can be included in the DHCP message exchange using the 6rd
DHCPv4 Option defined in . Manual
configuration of 6rd options and configuration using is also possible.
The main advantage of using 6rd is that it allows service
providers to deploy IPv6 on last mile access networks that for some
reason cannot provide native IPv6 connectivity. It does not
share the lack of predictable routing that 6to4 suffers
from, because all routing, encapsulation and
de-encapsulation is done by the service provider.
A disadvantage of 6rd for clients is that 6rd is only
available when a service provider provides the relays and
address space.
Inspired by Teredo, the 6a44 tunnel is
described in "Native IPv6 behind IPv4-to-IPv4 NAT Customer Premise Equipment (6a44)"
. Its purpose is to enable Internet Service
Providers to establish IPv6 connectivity for their customers, in spite
of the use of a CPE or home gateway that is not prepared for IPv6.
The infrastructure required for this is a 6a44 relay in the ISP's
network and a 6a44 client in the customer's internal network.
6a44 was explicitly designed to overcome the noted problems with Teredo.
Where Teredo was designed as a global solution without dependency on
ISP co-operation, the 6a44 tunnel explicitly assumes ISP co-operation.
Instead of using Teredo's well-known prefix, a /48 prefix out of the
ISP's address space is used. A well-known (anycast) IPv4 address
has been assigned for the 6a44 relay to be run inside the ISP network
without client configuration. This well-known address is allocated
from the same IPv4 /24 as 6to4.
As part of its bootstrapping, a 6a44 client requests an address from
the 6a44 relay, and a regular keepalive sent by the 6a44 client to
the 6a44 relay keeps mapping state in NATs and firewalls on the path alive.
Traffic passed from the native IPv6 internet
to 6a44 is encapsulated in UDP and IPv4 by the relay and decapsulated
by the 6a44 client; the opposite is done in the other direction.
The Locator/ID Separation Protocol (LISP) is a protocol to separate the identity
of systems from their location on the internet and/or
internal network. The addresses of the systems are called
Endpoint Identifiers (EIDs) and the addresses of the
gateways are called Routing Locators (RLOCs). It is
possible to use IPv6 EIDs with IPv4 RLOCs and thereby use
LISP for tunneling IPv6 over IPv4.
LISP defines its own packet formats for encapsulation of
data packets and for control messages. All such packets are
then encapsulated in UDP. Data packets use port 4341 and
control packets use port 4342.
The LISP specification consists of several RFC documents. The
relevant ones for IPv6-in-IPv4 tunnelling are the base specification , Interworking between Locator/ID
Separation Protocol (LISP) and Non-LISP Sites and the Locator/ID Separation Protocol
(LISP) Map-Server Interface .
LISP introduces new terminology and new concepts. The
relevant ones for this document are:
Ingress Tunnel Router, a router
encapsulating data packets at the border of
a LISP site
Egress Tunnel Router, a router decapsulating
data packets at the border of a LISP site
A router performing both the ITR and the ETR
functions
Proxy ITR, a router accepting traffic from
non-LISP sites, encapsulating it and
tunneling it to the LISP sites
Proxy ETR, a router accepting traffic from
LISP sites to send it to non-LISP sites
A router performing both the PITR and the
PETR functions
Map Server, a server accepting RLOC
registrations from ETRs
Map Resolver, a server that can resolve
queries for RLOCs from ITRs
LISP ETRs register the EID prefixes that they can handle
traffic for in one or more Map Servers. ITRs and PITRs can
then query Map Resolvers to determine which RLOCs to use
when sending traffic to a LISP site. PITRs advertise
aggregates of EID prefixes to the global routing table and
provide tunneling services for them so that non-LISP sites
can reach LISP sites. PETRs provide a way for LISP sites to
send traffic to non-LISP sites.
LISP is a complex protocol if only used for tunneling. What
it provides additionally is that ETRs can advertise their
own RLOC addresses, that one site can have multiple xTRs
with independent RLOCs and that the LISP site administrator
can specify priorities and weights for those RLOCs. This
provides redundancy and explicit load balancing between
RLOCs. It also provides automatic tunneling between
different sites without using a PxTR if both sites use Map
Servers and Map Resolvers that are interconnected, for
example by participating in the LISP Beta Network . To facilitate these interconnections
the LISP Delegated Database Tree (DDT) system is available.
The LISP protocol is implemented on most Cisco devices.
There are implementations available for FreeBSD and Linux,
as well as a platform independent implementation in the
Python programming language.
The 6bed4 tunnel is specified in "6bed4: Peer-to-Peer IPv6 on Any Internetwork" .
A specific goal of 6bed4 is to achieve direct communication between peers
when the intermediate infrastructure does not prohibit it.
The advantage of direct communication is to get a performance level similar to IPv4.
The address of a 6bed4 peer is formed from the external IPv4 address and
UDP port.
The tunnel service used for fallback connectivity can run anywhere;
perhaps at the local ISP or perhaps
with a third party service provider for 6bed4, or even on a well-known
address.
It is currently an NBMA protocol; there are openings for expansion with
multicast.
The setup of 6bed4 is somewhat similar to 6to4, except that it
employs UDP so it can be used behind NAT. It also has elements found in
Teredo, but without a need to classify NATs and induce behaviour from
that. The 6bed4 tunnel makes no assumption NAT devices beyond straightforward
UDP support. Given this, 6bed4 can create reliable IPv6 tunnels.
In environments where direct connections between 6bed4 peers is
possible, additional path stretch compared to IPv4 communication
is avoided, so 6bed4 performance comes close to IPv4 performance.
In situations where this is not possible run over the direct path
between two peers because a NAT that does not conform to
is on the path,
a fallback to a tunnel server
is used. This increases path stretch and
affects scalability through its impact on roundtrip
times and jitter.
Another area where the tunnel server is needed, is for connectivity between
6bed4 peers and native IPv6 hosts. For reasons of performance and
scalability, connections between 6bed4 peers are preferred over
connections between a 6bed4 peer and a native IPv6 host. A default
address exists to support zero-config operation, but it is possible
to locally configure a tunnel server as a fallback route, which then
also defines the tunnel server for the return path.
6bed4 has been specifically designed to support realtime interactive
traffic streams, such as SIP calls, between 6bed4-supporting end points,
assuming that each prefers
6bed4-to-6bed4 traffic over 6bed4-to-native traffic. Under that
premise, the only hosts that need to go through a tunnel server are
those that are behind a NAT with Address-Dependent Mapping or
Address and Port-Dependent Mapping. A number of different implementations
of 6bed4 have been constructed during the
ongoing development of its specification.
The following protocols are not tunnel mechanisms but they can be
used in the configuration and/or setup phase of such protocols.
The Tunnel Setup Protocol 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 .
The SixXS Heartbeat Protocol
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 avoid tunneled packets from
being delivered to the wrong node.
The Hearbeat 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.
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.
The Tunnel Information and Control protocol (TIC) protocol
is the setup protocol for the 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, enable or disable the tunnel.
Authentication of users is done based on username and
password. Certain tunnel mechanisms, such as AYIYA and configured tunnels
with heartbeat, 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 and in AVM
Fritz!Box home routers.
The following are aspects common to many or all
tunnel mechanisms.
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 simple "protocol 41" encapsulation is used by a number of tunnel mechanisms:
configured tunnelsautomatic tunneling6over46to4ISATAP6rd
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.
Other tunnel mechanisms than protocol 41 typically employ a UDP header,
and are somewhat less likely to be filtered, assuming that tunnelling is
initiated on the LAN-side.
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 ), 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 ). 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, tunnelled
packets from the outside won't be able to pass through the NAT/firewall until
a system behind the NAT or firewall sends a tunneled packet and the mapping is
recreated. 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 tunneling6to46rd
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 and
use RFC 1918 addresses:
6over4ISATAP
The following tunnel mechanisms may work through NAT
in some circumstances, but are not designed for NAT compatibility:
configured tunnelsGRE
The following tunnel mechanisms
are designed for NAT compatibility:
AYIYATeredo (but it is unreliable)6a446bed4
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, CGN or CGNAT
in this context). In this case, the subscribers' home gateways
may receive an address in the 100.64.0.0/10 block .
For the purposes of tunnel mechanisms, this address block is similar
to the address blocks. However, NAT/RFC1918 aware
tunnel implementations may not recognise 100.64.0.0/10 as non-public addresses
and fail to operate successfully.
Because of the extra IPv4 header and possible
additional headers between the IPv4 and IPv6 headers, tunnels
experience a reduced maximum packet size (Maximum Transfer Unit, 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, while the other uses the physical MTU minus tunnel overhead,
often 1480. 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, ),
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 tunneled packets don't have to be fragmented.
Additionally, Section 3.2.1 of
recommends limiting the MTU of tunnels to the minimum of 1280.
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).
Systems running
6to4 have addresses in the 6to4 prefix 2002::/16.
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.
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.
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 non- IPv4 address.
The group (g) bit is set to zero, and the remaining bits are set
to to 0x00005EFE.
Teredo embeds the Teredo server's IPv4 address, a number of flags,
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.
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 also a port number are embedded in the IPv6 address.
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.
Some details of the 6bed4 address format are still work in progress at
the time of this writing. The lanIP bits are free for local purposes,
such as creating a DHCPv6 range.
The following subsections deal with the various
aspects of tunnels that guide their selection.
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,
which 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 as 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 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.
MechanismTunnels per IPv4 addr.IPv6 hosts per tunnelPublic IPv4 addressNAT compatibleAuto. tun.oneonerequiredno6to4onemultiplerequirednoLISPonemultiplerequiredno6rdonemultiplenot needednoConf. tun.onemultiplenot neededlimitedGREonemultiplenot neededlimitedTeredomultipleonenot neededyes (*)6bed4multiplemultiplenot neededyes6a44multiplemultiplenot neededyesAYIYAmultiplemultiplenot neededyes
(*) Although Teredo is designed for NAT compatibility, it doesn't work
through all existing NATs.
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 multiple 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 tunnelbroker
is that there is a clear responsibility for providing
a good service with well maintained gateways.
MechanismPeer-to-peerGateway provided byConf. tun. No ISP or Tunnel brokerAYIYA No ISP or Tunnel brokerGRE No N/A6a44 Within domain ISP6rd Within domain ISP6over4 Globally N/AISATAP Within domain Own organisationTeredo Globally Public6to4 Globally Public6bed4 Globally Public or ISP or Tunnel brokerAuto. tun. Globally N/ALISP Configurable ISP or Tunnel broker
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 may have limited
performance, depending on distance and usage.
Tunnel mechanisms that use a broadcast or non-broadcast
multiple 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.)
MechanismEndpoint address changeMain issuesLISP automatic None6rd interrupt NoneAYIYA automatic Transient NAT mapping issuesConf. + HBinterrupt Proto 41 filtering, competition for NAT mappings (1)Conf. tun. failure Proto 41 filtering, competition for NAT mappings, address change (1)GRE failure Proto 47 filtering, address change6a44 interrupt NAT mapping towards peers6bed4 interrupt NAT mapping towards peers6to4 interrupt Enabled out of the box but filtered, gateway performance (2)Teredo interrupt NAT compatibility, mapping towards peers (3)
Notes:
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.
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 non-RFC 1918 addresses .
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 .
Also see 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
may need administrative intervention when a tunnel endpoint
address changes.
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 and 6rd 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, 6a44 and 6bed4 require additional logic to work
through NATs, which requires them to keep track of
relatively volitile state. They also work on a per-host
basis rather than allowing a number of hosts to make use of
a single tunnel.
With configured tunnels, GRE and AYIYA, there is no direct
mapping from (part of) the IPv6 destination address to the
IPv4 destination address. A typical implementation of these
mechanisms is by having 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.
There are several reasons why tunneled connectivity may
perform inferior to native, un-tunnelled connectivity.
Inherently, tunnels add one or more extra headers, and
therefore increase overhead. However, for a maximum size
(1500 bytes) Ethernet packet 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 then tunnel
encapsulation must 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. (Increased path
stretch.) This may or may not lead to decreased performance.
MechanismOverhead (bytes)Increased path stretchVariabilityConf. 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
None.
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"
discusses this issue in detail.
Another issue with tunneling is that it often makes implementation
of ingress filtering (BCP 38, ) harder,
because if the IPv4 source address of the remote tunnel endpoint can
be spoofed, false IPv6 packets can be injected.
This is especially true for non-point-to-point tunnels, such
as 6to4 and Teredo because legitimate packets can arrive from
anywhere.
So it is important to recognise that
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 .
Tunnels may also be used by third parties to obfuscate their
activities or perform amplification attacks. As such, it is
important to make sure only locally generated packets with
legitimate addresses are sent out over tunnels.
Job Snijders contributed text to the points of comparison.
Jeroen Massar, Brian Carpenter and Tina Tsou reviewed the document and offered suggestions for improvement.
We wish to thank SURFnet and Rogier Spoor for commissioning this work; both their
initiative and funding has helped this document to be written.
CPE WAN Management ProtocolThe Broadband ForumHurricane Electric Free IPv6 Tunnel BrokerHurricane ElectricIPv6 Deployment & Tunnel BrokerAnything In Anything (AYIYA)SixXSAutomatic IPv6 Connectivity Client Utility (AICCU)SixXSTunnel Information and Control protocol (TIC)SixXSTesting TeredoIntra-site Automatic Tunnel Addressing Protocol Deployment GuideMicrosoftFreenet6: Free and Easy IPv6 Connectivity6bed4: Peer-to-Peer IPv6 on Any InternetworkOpenFortressLISP Beta NetworkIPv6-in-IPv4 tunnel discovery: methods and experimental resultsSixXS Heartbeat ProtocolUnfix/SixXS
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.
How much overhead does the tunneling protocol cause? There
are two factors that play a role: number of interactions to
set up the tunnel and packet header size causing a lower MTU
and/or fragmentation.
Does this protocol require manual configuration at the
endpoints?
How predictable is the functioning of the protocol?
Is this protocol intended to be used by a single host or by
a router that then provides IPv6 connectivity to multiple
hosts?
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?
Does the tunnel optimise the route, or is there a big
potential for a much longer path when using the tunnel?
Can the tunnel pass through a NAT gateway, and does it
require configuration on that NAT gateway?
Are the IPv4 addresses of the tunnel fixed or do they adjust
automatically when an endpoint moves.
Are the endpoints required to keep state for the tunnel or
is the tunnel stateless?
Is this network a point-to-point or NBMA
type of network?
What is the intended purpose of this tunnel protocol?
To which protocols is this tunnel protocol related? Are
there alternatives?
Is this protocol supported on the major operating systems,
routers and firewalls?
What are the known limitations of this protocol?