Tech-invite   3GPPspecs   Glossaries   IETFRFCs   Groups   SIP   ABNFs   Ti+   Search in Tech-invite

in Index   Prev   Next
in Index   Prev   Next  Group: ~ipv6

RFC 7059

A Comparison of IPv6-over-IPv4 Tunnel Mechanisms

Pages: 41
Part 1 of 2 – Pages 1 to 20
None   None   Next

Top   ToC   Page 1
Independent Submission                                       S. Steffann
Request for Comments: 7059                   S.J.M. Steffann Consultancy
Category: Informational                                   I. van Beijnum
ISSN: 2070-1721                                 Institute IMDEA Networks
                                                             R. van Rein
                                                           November 2013

            A Comparison of IPv6-over-IPv4 Tunnel Mechanisms


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

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This is a contribution to the RFC Series, independently of any other
   RFC stream.  The RFC Editor has chosen to publish this document at
   its discretion and makes no statement about its value for
   implementation or deployment.  Documents approved for publication by
   the RFC Editor are not a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.
Top   ToC   Page 2
Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Tunnel Mechanisms  . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Configured Tunnels (Manual Tunnels / 6in4) . . . . . . . .  7
     3.2.  Automatic Tunneling  . . . . . . . . . . . . . . . . . . .  8
     3.3.  IPv6 over IPv4 without Explicit Tunnels (6over4) . . . . .  9
     3.4.  Generic Routing Encapsulation (GRE)  . . . . . . . . . . . 10
     3.5.  Connection of IPv6 Domains via IPv4 Clouds (6to4)  . . . . 10
       3.5.1.  6to4 Provider Managed Tunnels  . . . . . . . . . . . . 11
     3.6.  Anything In Anything (AYIYA) . . . . . . . . . . . . . . . 12
     3.7.  Intra-Site Automatic Tunnel Addressing (ISATAP)  . . . . . 13
     3.8.  Tunneling IPv6 over UDP through NATs (Teredo)  . . . . . . 14
     3.9.  IPv6 Rapid Deployment (6rd)  . . . . . . . . . . . . . . . 15
     3.10. Native IPv6 behind NAT44 CPEs (6a44) . . . . . . . . . . . 16
     3.11. Locator/ID Separation Protocol (LISP)  . . . . . . . . . . 16
     3.12. Subnetwork Encapsulation and Adaptation Layer (SEAL) . . . 18
     3.13. Peer-to-Peer IPv6 on Any Internetwork (6bed4)  . . . . . . 19
   4.  Related Protocols  . . . . . . . . . . . . . . . . . . . . . . 20
     4.1.  Tunnel Setup Protocol (TSP)  . . . . . . . . . . . . . . . 20
     4.2.  SixXS Heartbeat Protocol . . . . . . . . . . . . . . . . . 20
     4.3.  Tunnel Information and Control Protocol (TIC)  . . . . . . 21
   5.  Common Aspects . . . . . . . . . . . . . . . . . . . . . . . . 22
     5.1.  Protocol 41 Encapsulation  . . . . . . . . . . . . . . . . 22
     5.2.  NAT and Firewalls  . . . . . . . . . . . . . . . . . . . . 22
     5.3.  MTU Considerations . . . . . . . . . . . . . . . . . . . . 24
     5.4.  IPv4 Addresses Embedded in IPv6 Addresses  . . . . . . . . 25
   6.  Evaluation of Tunnel Mechanisms  . . . . . . . . . . . . . . . 28
     6.1.  Efficiency of IPv4 Address Use . . . . . . . . . . . . . . 28
     6.2.  Supported Network Topologies . . . . . . . . . . . . . . . 29
     6.3.  Robustness . . . . . . . . . . . . . . . . . . . . . . . . 30
     6.4.  Gateway State  . . . . . . . . . . . . . . . . . . . . . . 32
     6.5.  Performance  . . . . . . . . . . . . . . . . . . . . . . . 33
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 34
   8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 35
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
   10. Informative References . . . . . . . . . . . . . . . . . . . . 35
   Appendix A.  Evaluation Criteria . . . . . . . . . . . . . . . . . 40
Top   ToC   Page 3
1.  Introduction

   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.

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

                        Encapsulating IPv6 in IPv4

   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.
Top   ToC   Page 4
   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.  However, when native IPv6
   connectivity is available, this should be preferred over tunneled
   connectivity as per rule 7 in Section 6 of [RFC6724].  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 [RFC4301], as well as IPv4-over-IPv6 tunneling, are out of
   scope for this document as they serve a different purpose, even if
   they could technically be used to provide IPv6 connectivity.

2.  Terminology

   Anycast:  Mechanism to provide a service, in multiple locations
      and/or using multiple servers, by configuring each server with the
      same IP address.

   Carrier-Grade NAT (CGN):  A Network Address Translation (see NAT)
      device used by an ISP so multiple subscribers can be served using
      a single IPv4 address.

   Dual stack:  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.

   Encapsulation:  Transporting a packet as data inside another packet.
      For instance, an IPv6 packet inside an IPv4 packet.

   Firewall:  A device that selectively filters IP packets, allowing
      some protocols through but not others.  A firewall may act as a
      switch, operating below the IP layer, or as a router.

   Host:  A device that communicates using the Internet Protocol and
      only transmits packets from its own address.
Top   ToC   Page 5
   ISP:  Internet Service Provider; the party connecting the outside of
      the local network's perimeter to the public Internet.

   MTU:  Maximum Transmission Unit, the maximum size of a packet that
      can be transmitted over a link (or tunnel) without splitting it
      into multiple fragments.

   NAT:  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.  Typically, NAT devices behave as a
      host towards the public Internet, and as a router towards the
      internal network.

   NBMA:  Non-Broadcast Multi-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 must be modified to use unicast to work.

   Node:  A device that implements IP, either a host or a router; also
      known as a system.  See note at "NAT".

   Path stretch:  The difference between the shortest path through the
      network and the path (tunneled) packets actually take.

   PMTUD:  Path MTU Discovery, a method to determine the smallest MTU on
      the path between two nodes.  There are separate specifications for
      PMTUD over IPv4 [RFC1191] and IPv6 [RFC1981].

   Router:  A device that forwards IP packets that it didn't generate
      itself.  See note at "NAT".

   System:  A device that implements IP, either a host or a router; a
      network node.

   Translation:  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 [RFC6145].
      Translation is one of the three IPv4-to-IPv6 transition tools; the
      others are dual stack and tunnels.
Top   ToC   Page 6
   Tunnel:  By encapsulating IPv6 packets inside IPv4 packets, IPv6-
      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.
      Tunneling is one of the three IPv4-to-IPv6 transition tools; the
      others are translation and dual stack.

   Tunnel broker:  A service that provides tunneled connectivity to the
      IPv6 Internet, such as SixXS [SIXXS],
      [TUNBROKER], and gogo6 [GOGO6].

3.  Tunnel Mechanisms

   Automatic tunnels (Section 3.2), configured tunnels (Section 3.1),
   6over4 (Section 3.3), 6to4 (Section 3.5), the Intra-Site Automatic
   Tunnel Addressing Protocol (ISATAP) (Section 3.7), and 6rd
   (Section 3.9) 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 Section 5.1), as the Protocol field in the IPv4 header is set to
   41 to indicate that what follows is an IPv6 packet.

   6to4, 6rd, ISATAP, and automatic tunneling each generate an IPv6
   address or range of IPv6 addresses for the host or router running the
   protocol based on the system's IPv4 address in one way or another
   (see Section 5.4).  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 (Section 3.1) also use protocol 41 encapsulation
   but rely on manual configuration of the remote tunnel endpoint.  (The
   Heartbeat Protocol (Section 4.2) 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 (Section 3.4) is similar to configured tunnels, but
   also supports encapsulating protocols other than IPv6.
Top   ToC   Page 7
   AYIYA (Section 3.6) is similar to configured tunnels and GRE but
   typically uses a UDP header for better compatibility with NATs and is
   generally used with the Tunnel Information and Control (TIC) protocol
   (Section 4.3) to set up the tunnel rather than rely on manual
   configuration.  Teredo (Section 3.8), 6a44 (Section 3.10), and 6bed4
   (Section 3.13) 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; 6bed4 is designed to work
   over direct IPv4 paths between peers whenever possible.

   The Locator/ID Separation Protocol (LISP) (Section 3.11) is a system
   for abstracting the identifying function from the location function
   of IP addresses; this allows for the use of IPv6 for the former and
   IPv4 for the latter.

   The Subnetwork Encapsulation and Adaptation Layer (SEAL)
   (Section 3.12) and its companion technologies (Virtual Enterprise
   Traversal (VET), Asymmetric Extended Route Optimization (AERO),
   Internet Routing Overlay Network (IRON), and Routing and Addressing
   in Networks with Global Enterprise Recursion (RANGER)) provide a
   configured tunnel system for IPv6-in-IPv4 tunneling to default
   routers as well as automatic tunnel endpoint discovery for
   optimisation of more-specific routes.

   Dual-Stack Lite [RFC6333] and MAP [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 Section 5 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.

3.1.  Configured Tunnels (Manual Tunnels / 6in4)

   Configured and automatic tunnels are the two oldest tunnel
   mechanisms, originally published in "Transition Mechanisms for IPv6
   Hosts and Routers" [RFC1933] in 1996.  The latest specification of
   configured tunnels is "Basic Transition Mechanisms for IPv6 Hosts and
   Routers" [RFC4213], published in 2005.  The mechanism is sometimes
   called "manual tunnels", "static tunnels", "protocol 41 tunnels", or

   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".
Top   ToC   Page 8
   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 configured tunnels makes them more
   difficult to deploy than automatic mechanisms.  However, because
   there is a fixed, single remote tunnel endpoint, performance is
   predictable and the tunnel is easy to debug.

   In the early days, it was not unheard of 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 [TUNBROKER], SixXS
   [SIXXS], or gogo6 [GOGO6].

   [RFC4891] discusses the use of IPsec to protect the confidentiality
   and integrity of IPv6 traffic exchanged over configured tunnels.

3.2.  Automatic Tunneling

   Automatic tunneling is described in [RFC2893], "Transition Mechanisms
   for IPv6 Hosts and Routers", but removed in [RFC4213], which is a
   replacement of RFC 2893.  Configured tunnels (Section 3.1) 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 (Section 3.5) does what automatic tunneling was supposed to do,
   but it also provides connectivity to the rest of the IPv6 Internet.
Top   ToC   Page 9
3.3.  IPv6 over IPv4 without Explicit Tunnels (6over4)

   "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels"
   [RFC2529] was published in 1999.  The mechanism is commonly known as

   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 [RFC4862] can be used.  Although,
   like automatic tunnels (Section 3.2) and other mechanisms, 6over4
   embeds the IPv4 address of the host 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 [RFC4861].  In effect, the IPv4 addresses
   of the hosts are used as link-layer addresses in the same way that
   Media Access Control (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 overhead for protocol 41 encapsulation 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 RFC 1918 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
   (Section 3.7) provides very similar functionality without requiring
   IPv4 multicast capability and is implemented more widely.
Top   ToC   Page 10
3.4.  Generic Routing Encapsulation (GRE)

   Generic Routing Encapsulation (GRE) [RFC2784] is a generic point-to-
   point tunnel mechanism that allows many other protocols to be
   encapsulated in IP.

   GRE is a simple protocol that is similar to configured tunnels
   (Section 3.1) when used for IPv6-in-IPv4 tunneling.  The main benefit
   of GRE is that it can encapsulate any protocol's packets, not only
   IPv6 packets.  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 endpoints, 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.

3.5.  Connection of IPv6 Domains via IPv4 Clouds (6to4)

   6to4 is specified in "Connection of IPv6 Domains via IPv4 Clouds"
   [RFC3056].  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 Multi-Access (NBMA)
   network through which 6to4 users can communicate.  IPv6 packets are
   encapsulated by adding an IPv4 header with the Protocol field set to

   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 [RFC1918] is not possible.

   "An Anycast Prefix for 6to4 Relay Routers" [RFC3068] 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, which corresponds to 2002:c058:
   6301::.  Relays advertise reachability towards 2002::/16 to 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
Top   ToC   Page 11
   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 overhead for protocol 41 encapsulation
   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 [RFC6724] 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" [RFC6343].


   Although many, if not all, 6to4 implementations disable the mechanism
   when the system only has an RFC 1918 address, recently a block of
   IPv4 addresses has been set aside for use in service-provider-
   operated Network Address Translators, also known as Carrier-Grade
   NATs (CGNs).  [RFC6598] sets aside the block for the
   use between CGNs and subscriber devices.  As is not an
   RFC 1918 address block, systems implementing 6to4 may fail to disable
   the mechanism, but due to the shared nature of the
   prefix, 6to4 cannot work using these addresses.  The same issue is
   present if an ISP decides to use regular global unicast IPv4 address
   space behind a CGN.

3.5.1.  6to4 Provider Managed Tunnels

   [RFC6732] describes "6to4 provider managed tunnels", which are a way
   to make 6to4 work behind a CGN.  This is accomplished by running a
   6to4 gateway at the 6to4 gateway anycast address, and then
   translating the IPv6 addresses used by 6to4 users behind the CGN to
   IPv6 addresses from the ISP's range.  Unlike IPv4 NAT, where multiple
Top   ToC   Page 12
   internal hosts share a single public IPv4 address, prefix translation
   maps entire prefixes, so each host has its own public IPv6 address
   and can receive incoming packets as usual.

   However, if IPv6 applications are not aware that translation is
   happening (and they have no reason to expect that it is), they may
   not use their externally visible address in referrals, so
   applications that use referrals are likely to fail.  Additionally,
   the translation is only specified for packets that flow through the
   6to4 gateway, not for packets sent directly to other 6to4 users.  So,
   communication with other 6to4 users is not possible.  As such, the
   use of 6to4 provider managed tunnels is discouraged except as a very
   last resort.

3.6.  Anything In Anything (AYIYA)

   AYIYA [AYIYA] is designed for use by the SixXS [SIXXS] tunnel-broker
   service.  For more information, see the specification [MASSAR].

   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.  That document 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) that 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 Section 4.3 is used for that part of the tunnel
   setup, although the Tunnel Setup Protocol (TSP) (Section 4.1) could
   just as well 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 Automatic
   IPv6 Connectivity Client Utility (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).
Top   ToC   Page 13
   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.  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

   There is currently a single implementation of this protocol: the
   AICCU [AICCU] client software used with the SixXS [SIXXS] tunnel-
   broker service.

3.7.  Intra-Site Automatic Tunnel Addressing (ISATAP)

   ISATAP [RFC5214] uses protocol 41 encapsulation to provide
   connectivity between isolated IPv6-capable nodes within an
   organisation's internal network.  It is similar to 6over4
   (Section 3.3), but without the requirement that the IPv4 network
   supports multicast; unlike 6over4, ISATAP uses a Non-Broadcast Multi-
   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 host needs to send a
   unicast Router Solicitation to receive a unicast Router Advertisement
   from an ISATAP router.  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.,  Hosts will accept packets with IPv4 sender
   addresses that are either on the Potential Router List or 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
Top   ToC   Page 14
   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.

   [RFC5214] doesn't explicitly address the use of ISATAP using private
   RFC 1918 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.

3.8.  Tunneling IPv6 over UDP through NATs (Teredo)

   Teredo is specified in [RFC4380] 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 [RFC3489]
   as established during an interaction with a Teredo server.  This
   classification has since been obsoleted (by [RFC5389]) 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, if IPv6 connectivity is only
   possible through Teredo, then Windows will not 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% [TERTST] of its
   attempts to connect to native IPv6 destinations.  The roundtrip time
   of traffic can add tenths of a second, and jitter generally worsens
   if it is dependent on a public relay.
Top   ToC   Page 15
   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 preconfigured by the vendor of the Teredo implementation.
   All Microsoft Windows implementations use Teredo servers provided by
   Microsoft by default.

3.9.  IPv6 Rapid Deployment (6rd)

   6rd [RFC5969] is used by service providers to connect customer
   networks behind a CPE (Customer Premises Equipment) to the IPv6

   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; this 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 [RFC5969].  Manual configuration of 6rd
   options and configuration using [TR-069] 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 decapsulation are done by the service provider.
Top   ToC   Page 16
   6rd is intended to be a service managed by an ISP or enterprise IT
   department that must explicitly make 6rd available for clients to be
   able to use it.

3.10.  Native IPv6 behind NAT44 CPEs (6a44)

   Inspired by Teredo, the 6a44 tunnel is described in "Native IPv6
   behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44)"
   [RFC6751].  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 cooperation, the 6a44 tunnel explicitly assumes ISP
   cooperation.  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.

3.11.  Locator/ID Separation Protocol (LISP)

   The Locator/ID Separation Protocol (LISP) [RFC6830] 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 RFCs.  The relevant ones
   for IPv6-in-IPv4 tunneling are the base specification [RFC6830],
   "Interworking between Locator/ID Separation Protocol (LISP) and Non-
   LISP Sites" [RFC6832], and "Locator/ID Separation Protocol (LISP)
   Map-Server Interface" [RFC6833].
Top   ToC   Page 17
                    +----+    +----+
                    | MS |    | MR |
                    +----+    +----+       +-----+   /-----------\
                       |        |      /---| xTR |---| LISP site |
          +------+   /------------\---/    +-----+   \-----------/
          | PxTR |---| IP network |
          +------+   \------------/---\    +-----+   /-----------\
                            |          \---| xTR |---| LISP site |
                    /---------------\      +-----+   \-----------/
                    | Non-LISP site |

                      An Example of a LISP Deployment

   LISP introduces new terminology and new concepts.  The relevant ones
   for this document are:

   ITR:  Ingress Tunnel Router, a router encapsulating data packets at
      the border of a LISP site

   ETR:  Egress Tunnel Router, a router decapsulating data packets at
      the border of a LISP site

   xTR:  A router performing both the ITR and the ETR functions

   PITR:  Proxy ITR, a router accepting traffic from non-LISP sites,
      encapsulating it, and tunneling it to the LISP sites

   PETR:  Proxy ETR, a router accepting traffic from LISP sites to send
      it to non-LISP sites

   PxTR:  A router performing both the PITR and the PETR functions

   MS:  Map Server, a server accepting RLOC registrations from ETRs

   MR:  Map Resolver, a server that can resolve queries for RLOCs from

   LISP ETRs register the EID prefixes for which they can handle traffic
   with 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.
Top   ToC   Page 18
   LISP is a complex protocol if only used for tunneling.  Features of
   LISP are 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 allows for 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 [LISPBETA].  To facilitate these
   interconnections, the LISP Delegated Database Tree (DDT) system is

   LISP 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.  Note that for
   LISP to work, a mapping service not unlike the DNS must be in place.

3.12.  Subnetwork Encapsulation and Adaptation Layer (SEAL)

   The Subnetwork Encapsulation and Adaptation Layer (SEAL) [SEAL]
   (along with its companion technologies cited therein) provides a
   hybrid configured/automatic tunneling system.  SEAL itself provides a
   mid-layer of encapsulation between the inner IPv6 header and the
   outer IPv4 header, i.e., as IPv4-SEAL-IPv6.  SEAL can also be used in
   conjunction with an outer UDP encapsulation header, e.g., if NAT
   traversal is necessary.

   The SEAL tunnel endpoint creates bidirectional configured tunnels to
   reach default IPv6 routers, and it discovers unidirectional automatic
   tunnels.  SEAL tunnels can be configured over multiple underlying
   IPv4 links whether the addresses are provisioned from public or
   private IPv4 addressing domains.  In that case, multihoming and
   traffic engineering are naturally supported.

   SEAL provides an optional 32-bit identifier and variable-length
   Integrity Check Vector that can be used for packet identification,
   message origin authentication, anti-replay, and a mid-layer
   segmentation and reassembly capability.  SEAL also provides a SEAL
   Control Message Protocol (SCMP) used for neighbour coordinations
   between tunnel endpoints.  These coordinations are used for functions
   such as tunnel MTU signalling, route optimisations, neighbour
   reachability testing, and so on.

   SEAL ensures that packets that are no larger than 1500 bytes can be
   transported through the tunnel by using a tunnel segmentation
   function.  IPv6 packets that are too large to transport through the
   tunnel whole are split into segments.  The segments are encapsulated
   in IPv4 and reassembled into the original IPv6 packets at the remote
Top   ToC   Page 19
   tunnel endpoint.  SEAL also admits packets larger than 1500 bytes
   into the tunnel on a best-effort basis in case the path between the
   tunnel endpoints can support the larger size.

   When SEAL is used alone without its companion technologies, it can be
   used in the same scenarios as for GRE.  However, SEAL provides
   advanced capabilities that make it better suited than GRE for many
   use cases.  There is currently an experimental open-source
   implementation of SEAL.

3.13.  Peer-to-Peer IPv6 on Any Internetwork (6bed4)

   The 6bed4 tunnel is specified in "6bed4: Peer-to-Peer IPv6 on Any
   Internetwork" [6BED4].  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 publicly visible IPv4 address and UDP port.  The
   tunnel service used for fallback connectivity can run anywhere --
   perhaps at the local ISP or 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 assumptions about the
   capabilities of NAT devices beyond being able to do straightforward
   NAT on UDP packets.  Given this, 6bed4 can create reliable IPv6

   In environments where direct connections between 6bed4 peers are
   possible, additional path stretch compared to IPv4 communication is
   avoided, so 6bed4 performance comes close to IPv4 performance.  In
   situations where it is not possible to run over the direct path
   between two peers because a NAT that does not conform to [RFC4787] 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.
Top   ToC   Page 20
   6bed4 has been specifically designed to support real-time 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
   [6BED4] during the ongoing development of its specification.

(page 20 continued on part 2)

Next Section