idnits 2.17.1
draft-steffann-tunnels-04.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack separate sections for Informative/Normative
References. All references will be assumed normative when checking for
downward references.
== There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses
in the document. If these are example addresses, they should be changed.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (May 31, 2013) is 3954 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Outdated reference: A later version (-13) exists of
draft-ietf-softwire-map-07
== Outdated reference: A later version (-68) exists of
draft-templin-intarea-seal-55
** Obsolete normative reference: RFC 1933 (Obsoleted by RFC 2893)
** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201)
** Obsolete normative reference: RFC 2893 (Obsoleted by RFC 4213)
** Obsolete normative reference: RFC 3068 (Obsoleted by RFC 7526)
** Obsolete normative reference: RFC 3489 (Obsoleted by RFC 5389)
** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489)
** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915)
** Obsolete normative reference: RFC 6732 (Obsoleted by RFC 7526)
** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301)
** Obsolete normative reference: RFC 6833 (Obsoleted by RFC 9301)
Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group S. Steffann
3 Internet-Draft S.J.M. Steffann Consultancy
4 Intended status: Informational I. van Beijnum
5 Expires: December 2, 2013 Institute IMDEA Networks
6 R. van Rein
7 OpenFortress
8 May 31, 2013
10 A Comparison of IPv6 over IPv4 Tunnel Mechanisms
11 draft-steffann-tunnels-04
13 Abstract
15 This document provides an overview of various ways to tunnel IPv6
16 packets over IPv4 networks. It covers mechanisms in current use,
17 touches on several mechanisms that are now only of historic interest,
18 and discusses some newer tunnel mechanisms that are not (yet) widely
19 used at the time of publication. The goal of the document is helping
20 people with an IPv6-in-IPv4 tunneling need to select the mechanisms
21 that may apply to them.
23 Status of this Memo
25 This Internet-Draft is submitted in full conformance with the
26 provisions of BCP 78 and BCP 79.
28 Internet-Drafts are working documents of the Internet Engineering
29 Task Force (IETF). Note that other groups may also distribute
30 working documents as Internet-Drafts. The list of current Internet-
31 Drafts is at http://datatracker.ietf.org/drafts/current/.
33 Internet-Drafts are draft documents valid for a maximum of six months
34 and may be updated, replaced, or obsoleted by other documents at any
35 time. It is inappropriate to use Internet-Drafts as reference
36 material or to cite them other than as "work in progress."
38 This Internet-Draft will expire on December 2, 2013.
40 Copyright Notice
42 Copyright (c) 2013 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents
47 (http://trustee.ietf.org/license-info) in effect on the date of
48 publication of this document. Please review these documents
49 carefully, as they describe your rights and restrictions with respect
50 to this document. Code Components extracted from this document must
51 include Simplified BSD License text as described in Section 4.e of
52 the Trust Legal Provisions and are provided without warranty as
53 described in the Simplified BSD License.
55 Table of Contents
57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
59 3. Tunnel Mechanisms . . . . . . . . . . . . . . . . . . . . . . 6
60 3.1. Configured Tunnels (Manual Tunnels / 6in4) . . . . . . . . 7
61 3.2. Automatic Tunneling . . . . . . . . . . . . . . . . . . . 8
62 3.3. IPv6 over IPv4 without Explicit Tunnels (6over4) . . . . . 8
63 3.4. Generic Routing Encapsulation (GRE) . . . . . . . . . . . 9
64 3.5. Connection of IPv6 Domains via IPv4 Clouds (6to4) . . . . 10
65 3.5.1. 6to4 Provider Managed Tunnels . . . . . . . . . . . . 11
66 3.6. Anything In Anything (AYIYA) . . . . . . . . . . . . . . . 12
67 3.7. Intra-site Automatic Tunnel Addressing (ISATAP) . . . . . 13
68 3.8. Tunneling IPv6 over UDP through NATs (Teredo) . . . . . . 14
69 3.9. IPv6 Rapid Deployment (6rd) . . . . . . . . . . . . . . . 14
70 3.10. Native IPv6 behind NAT44 CPEs (6a44) . . . . . . . . . . . 15
71 3.11. Locator/ID Separation Protocol (LISP) . . . . . . . . . . 16
72 3.12. Subnetwork Encapsulation and Adaptation Layer (SEAL) . . . 18
73 3.13. Peer-to-Peer IPv6 on Any Internetwork (6bed4) . . . . . . 18
74 4. Related Protocols . . . . . . . . . . . . . . . . . . . . . . 19
75 4.1. Tunnel Setup Protocol (TSP) . . . . . . . . . . . . . . . 20
76 4.2. SixXS Heartbeat Protocol . . . . . . . . . . . . . . . . . 20
77 4.3. Tunnel Information and Control protocol (TIC) . . . . . . 21
78 5. Common Aspects . . . . . . . . . . . . . . . . . . . . . . . . 21
79 5.1. Protocol 41 Encapsulation . . . . . . . . . . . . . . . . 21
80 5.2. NAT and Firewalls . . . . . . . . . . . . . . . . . . . . 22
81 5.3. MTU Considerations . . . . . . . . . . . . . . . . . . . . 24
82 5.4. IPv4 Addresses Embedded in IPv6 Addresses . . . . . . . . 25
83 6. Evaluation of Tunnel Mechanisms . . . . . . . . . . . . . . . 27
84 6.1. Efficiency of IPv4 Address Use . . . . . . . . . . . . . . 27
85 6.2. Supported Network Topologies . . . . . . . . . . . . . . . 28
86 6.3. Robustness . . . . . . . . . . . . . . . . . . . . . . . . 29
87 6.4. Gateway State . . . . . . . . . . . . . . . . . . . . . . 31
88 6.5. Performance . . . . . . . . . . . . . . . . . . . . . . . 32
89 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 33
90 8. Security considerations . . . . . . . . . . . . . . . . . . . 33
91 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 34
92 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
94 Appendix A. Evaluation Criteria . . . . . . . . . . . . . . . . . 38
95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
97 1. Introduction
99 During the transition from IPv4 to IPv6, IPv6 islands are separated
100 by a sea of IPv4. Tunnels provide connectivity between these IPv6
101 islands. Tunnels work by encapsulating IPv6 packets inside IPv4
102 packets, as shown in the figure.
104 +---------------+
105 | IPv4 |
106 | Header |
107 +---------------+
108 +---------------+ : Optional :
109 | IPv6 | : Encapsulation :
110 | Header | : Header :
111 +---------------+ +---------------+
112 | Transport | | IPv6 |
113 | Layer | ===> | Header |
114 | Header | +---------------+
115 +---------------+ | Transport |
116 | | | Layer |
117 ~ Data ~ | Header |
118 | | +---------------+
119 +---------------+ | |
120 ~ Data ~
121 | |
122 +---------------+
124 Encapsulating IPv6 in IPv4
126 Various tunnel mechanisms have been proposed over time. So many in
127 fact, that it is difficult to get an overview.
129 Some tunnel mechanisms have been abandoned by the community, others
130 have known problems and yet others have shown to be reliable. Some
131 tunnel mechanisms were designed with a particular use-case in mind,
132 others are generic. There may be documented limitations as well as
133 limitations that have cropped up in deployment.
135 This document provides an overview of available and/or noteworthy
136 tunnel mechanisms, with the intention to guide selection of the best
137 mechanism for a particular purpose. As such, the discussion of the
138 different tunnel mechanisms is limited to the working principles of
139 the different mechanisms and a few important details.
141 Please use the references to learn the full details of each
142 mechanism. For brevity, only the most relevant documents are
143 referenced. Refer to these for additional specifications, updates
144 and links to older versions of protocol specifications as well as
145 links to more general background information.
147 The intended audience for this document is everyone who needs a
148 connection to the IPv6 internet at large, but is not in the position
149 to use native (untunneled) IPv6 connectivity, and thus needs to
150 select an appropriate tunnel mechanism. However, when native IPv6
151 connectivity is availalble, this should be preferred over tunneled
152 connectivity as per rule 7 in section 6 of [RFC6724]. This document
153 is also intended as a quick reference to tunnel mechanisms for the
154 IETF community.
156 The scope of this document is limited to tunnel mechanisms for
157 providing IPv6 connectivity over an IPv4 infrastructure. Mechanisms
158 for Virtual Private Networks (VPNs) and security architectures such
159 as IPSec [RFC4301], as well as IPv4 over IPv6 tunneling are out of
160 scope for this document as they serve a different purpose, even if
161 they could technically be used to provide IPv6 connectivity.
163 2. Terminology
165 Anycast: Mechanism to provide a service, in multiple locations
166 and/or using multiple servers, by configuring each server with the
167 same IP address.
169 Carrier Grade NAT (CGN): A Network Address Translation (see NAT)
170 device used by an ISP so multiple subscribers can be served using
171 a single IPv4 address.
173 Dual stack: Also known as "dual IP layer". Nodes run IPv4 and IPv6
174 side by side, and can communicate with other dual stack nodes
175 (using IPv4 or IPv6), as well as IPv4-only nodes (using IPv4) and
176 IPv6-only nodes (using IPv6). Most current operating systems are
177 set up to use IPv4 when available as well as use IPv6 when
178 available, allowing them to run in IPv4-only, IPv6-only or dual
179 stack mode as circumstances permit. Except for a few things
180 concerning the Domain Name System (DNS), there is no separate
181 specification for dual stack beyond the specifications relevant to
182 running IPv4 and IPv6. Dual stack is one of the three IPv4-to-
183 IPv6 transition tools; the others are translation and tunnels.
185 Encapsulation: Transporting packets as data inside another packet.
186 For instance, an IPv6 packet inside an IPv4 packet.
188 Firewall: A device that selectively filters IP packets, allowing
189 some protocols through but not others. A firewall may act as a
190 switch, operating below the IP layer, or as a router.
192 Host: A device that communicates using the Internet Protocol and
193 only transmits packets from its own address.
195 ISP: Internet Service Provider; the party connecting the outside of
196 the local network's perimeter to the public Internet.
198 MTU: Maximum Transmission unit, the maximum size of a packet that
199 can be transmitted over a link (or tunnel) without splitting it
200 into multiple fragments.
202 NAT: Network Address Translation or Network Address Translator. NAT
203 makes it possible for a number of hosts to share a single IP
204 address. TCP and UDP port numbers are used to distinguish the
205 traffic to/from different hosts served by the NAT; protocols other
206 than TCP and UDP may be incompatible with NAT due to lack of port
207 numbers. NAT also breaks protocols that depend on the IP
208 addresses used in some way. Typically, NAT devices behave as a
209 host towards the public internet, and as a router towards the
210 internal network.
212 NBMA: Non-Broadcast, Multiple Access. This is a network
213 configuration in which nodes can exchange packets directly by
214 addressing them at the desired destination. However, broadcasts
215 or multicasts are not supported, so autodiscovery mechanisms such
216 as IPv6 Neighbour Discovery must be modified to use unicast to
217 work.
219 Node: A device that implements IP, either a host or a router; also
220 known as a system. See note at "NAT".
222 Path stretch: The difference between the shortest path through the
223 network and the path (tunneled) packets actually take.
225 PMTUD: Path MTU Discovery, a method to determine the smallest MTU on
226 the path between two nodes. There are separate specifications for
227 PMTUD over IPv4 [RFC1191] and IPv6 [RFC1981].
229 Router: A device that forwards IP packets that it didn't generate
230 itself. See note at "NAT".
232 System: A device that implements IP, either a host or a router; a
233 network node.
235 Translation: The IPv6 and IPv4 headers are similar enough that it is
236 possible to translate between them. This allows IPv6-only hosts
237 to communicate with IPv4-only hosts. The original specification
238 for translating between IPv6 and IPv4, was heavily criticised by
239 the Internet Architecture Board, but new specifications for
240 translating between IPv6 and IPv4 were later published [RFC6145].
241 Translation is of the three IPv4-to-IPv6 transition tools; the
242 others are dual stack and tunnels.
244 Tunnel: By encapsulating IPv6 packets inside IPv4 packets, IPv6-
245 capable hosts and IPv6-capable networks isolated from other IPv6-
246 capable systems or the IPv6 internet at large can exchange IPv6
247 packets over IPv4-only infrastructure. There are numerous ways to
248 tunnel IPv6 over IPv4. This document compares these mechanisms.
249 One of the three IPv4-to-IPv6 transition tools; the others are
250 translation and dual stack.
252 Tunnel broker: A service that provides tunneled connectivity to the
253 IPv6 internet, such as [SIXXS], [TUNBROKER] and [GOGO6].
255 3. Tunnel Mechanisms
257 Automatic tunnels (Section 3.2), configured tunnels (Section 3.1),
258 6over4 (Section 3.3), 6to4 (Section 3.5), ISATAP (Section 3.7) and
259 6rd (Section 3.9) solve similar problems at different scales. They
260 all encapsulate IPv6 packets immediately inside an IPv4 packet,
261 without using additional headers. This is called "protocol 41
262 encapsulation" (see Section 5.1), as the Protocol field in the IPv4
263 header is set to 41 to indicate that what follows is an IPv6 packet.
265 Each of these mechanisms also creates an IPv6 address for the host or
266 router running the protocol based on the system's IPv4 address in one
267 way or another (see Section 5.4). This lets 6to4, 6rd, ISATAP and
268 automatic tunnels determine the IPv4 destination address in the outer
269 IPv4 header from the IPv6 address of the destination, allowing for
270 automatic operation without the need to administratively configure
271 the remote tunnel endpoint.
273 6over4 and ISATAP provide IPv6 connectivity between IPv6-capable
274 systems within a single organisation's network that is otherwise
275 IPv4-only. 6rd allows ISPs to provide IPv6 connectivity to their
276 customers over IPv4-only last mile infrastructures. 6to4 directly
277 provides connectivity to the global IPv6 internet without involving
278 an ISP.
280 Configured tunnels (Section 3.1) also use protocol 41 encapsulation,
281 but rely on manual configuration of the remote tunnel endpoint. (The
282 Heartbeat Protocol (Section 4.2) solves this.) Configured tunnels
283 can be used within an organisation's network, but are typically used
284 by tunnel broker services to provide connectivity to the IPv6
285 internet. GRE (Section 3.4) is similar to configured tunnels, but
286 also supports tunnel protocols other than IPv6.
288 AYIYA (Section 3.6) is similar to configured tunnels and GRE, but
289 typically uses a UDP header for better compatibility with NATs and is
290 generally used with TIC (Section 4.3) to set up the tunnel rather
291 than rely on manual configuration. Teredo (Section 3.8), 6a44
292 (Section 3.10) and 6bed4 (Section 3.13) are similar to 6to4, except
293 that they are designed to work through NATs by running over UDP. Of
294 these, Teredo and 6bed4 assume no ISP involvement and 6a44 does; and
295 6bed4 is designed to work over direct IPv4 paths between peers
296 whenever possible.
298 LISP (Section 3.11) is a system for abstracting the identifying
299 function from the location function of IP addresses, which allows for
300 the use of IPv6 for the former and IPv4 for the latter.
302 SEAL (Section 3.12)) and its companion technologies (VET, AERO, IRON
303 and RANGER) provide a configured tunnel system for IPv6-in-IPv4
304 tunneling to default routers as well as automatic tunnel endpoint
305 discovery for optimisation of more-specific routes.
307 Dual-Stack Lite [RFC6333] and MAP [I-D.ietf-softwire-map], both
308 developed by the IETF Softwire working group, often come up in
309 discussions about IPv6 tunneling. However, they are _not_ IPv6-in-
310 IPv4 tunnel mechanisms. They are IPv4-in-IPv6 mechanisms for
311 providing IPv4 connectivity over an IPv6 infrastructure.
313 Please refer to Section 5 for more information about issues common to
314 many tunnel mechanisms; those issues are not discussed separately for
315 each mechanism. The mechanisms are discussed below in roughly
316 chronological order of first publication.
318 3.1. Configured Tunnels (Manual Tunnels / 6in4)
320 Configured and automatic tunnels are the two oldest tunnel
321 mechanisms, originally published in "Transition Mechanisms for IPv6
322 Hosts and Routers" [RFC1933] in 1996. The latest specification of
323 configured tunnels is "Basic Transition Mechanisms for IPv6 Hosts and
324 Routers" [RFC4213], published in 2005. The mechanism is sometimes
325 called "manual tunnels", "static tunnels", "protocol 41 tunnels" or
326 "6in4".
328 Configured tunnels connect two systems in point-to-point fashion
329 using protocol 41 encapsulation. The configuration that the name of
330 the mechanism alludes to consists of a remote "tunnel endpoint".
331 This is the IPv4 address of the system on the other side of the
332 tunnel. When a system (potentially) has multiple IPv4 addresses, the
333 local tunnel endpoint address may also need to be configured.
335 The need to explicitly set up a configured tunnel makes them more
336 difficult to deploy than automatic mechanisms. However, because
337 there is a fixed, single remote tunnel endpoint, performance is
338 predictable and easy to debug.
340 In the early days it was not unheard for a small network to get IPv6
341 connectivity from another continent. This excessive path stretch
342 makes communication over short geographic distances much less
343 efficient because the distance travelled by packets may be larger
344 than the geographic distance by an order of magnitude or more.
346 Configured tunnels are widely implemented. Common operating systems
347 can terminate configured tunnels, as well as IPv6-capable routers and
348 home gateways. The mechanism is versatile, but is mostly used
349 between isolated smaller IPv6-capable networks and the IPv6 internet,
350 often through a "tunnel broker" such as tunnelbroker.net [TUNBROKER],
351 SixXS [SIXXS] or [GOGO6].
353 [RFC4891] discusses the use of IPsec to protect the confidentiality
354 and integrity of IPv6 traffic exchanged over configured tunnels.
356 3.2. Automatic Tunneling
358 Automatic tunneling is described in [RFC2893], "Transition Mechanisms
359 for IPv6 Hosts and Routers", but removed in [RFC4213], which is an
360 update of RFC 2893. Configured tunnels (Section 3.1) are closely
361 related to automatic tunnels and are specified in RFCs 2893 and 4213,
362 too. Both use protocol 41 encapsulation.
364 Hosts that are capable of automatic tunneling use special IPv6
365 addresses: IPv4-compatible addresses. An IPv4-compatible IPv6
366 address consists of 96 zero bits followed by the system's IPv4
367 address. When sending packets to destinations within the IPv4-
368 compatible ::/96 prefix, the IPv4 destination address in the outer
369 IPv4 header is taken from the IPv4 address in the IPv4-compatible
370 IPv6 destination address.
372 Automatic tunneling has a big limitation: it only allows for
373 communication between IPv6-capable systems that both support
374 automatic tunneling. There are no provisions for communicating with
375 the native IPv6 internet. As such, the mechanism is of almost no
376 practical use and is not implemented in current operating systems, as
377 6to4 (Section 3.5) does what automatic tunneling was supposed to do,
378 but also provides connectivity to the rest of the IPv6 internet.
380 3.3. IPv6 over IPv4 without Explicit Tunnels (6over4)
382 "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels"
383 [RFC2529] was published in 1999. The mechanism is commonly known as
384 "6over4".
386 6over4 is designed to work within a single organisation's IPv4
387 network, where IPv6-capable hosts and routers are separated by IPv4-
388 only routers. 6over4 treats the IPv4 network as a "virtual Ethernet"
389 for the purpose of IPv6 communication. It uses IPv4 multicast to
390 tunnel IPv6 multicast packets. A node's IPv4 address is included in
391 the Interface Identifier used on the virtual 6over4 interface,
392 allowing the exchange of protocol 41 encapsulated packets between
393 6over4 nodes without prior administrative configuration.
395 Because multicast is supported, standard IPv6 Neighbour Discovery and
396 Stateless Address Autoconfiguration [RFC4862] can be used. Although
397 like automatic tunnels (Section 3.2) and other mechanisms, 6over4
398 embeds the IPv4 address of the host is in the IPv6 address, the
399 destination IPv4 address in the outer IPv4 header is *not* derived
400 from the IPv6 address embedded in the inner IPv6 header, but learnt
401 through Neighbour Discovery [RFC4861]. In effect, the IPv4 addresses
402 of the hosts are used as link-layer addresses, in the same way that
403 MAC addresses are used on Ethernet networks.
405 One or more routers with connectivity to the global IPv6 internet
406 send out Router Advertisements to provide 6over4 hosts with
407 connectivity to the rest of the IPv6 internet.
409 6over4 has the minimal protocol 41 encapsulation overhead and doesn't
410 require manual configuration. Hosts can only take advantage of
411 6over4 if they run the mechanism themselves. 6over4 packets can't
412 pass through a NAT successfully, as the IPv4 address exchanged
413 through Neighbour Discovery will be different from the one needed to
414 reach the host in question, and because without port numbers,
415 protocol 41 doesn't allow for multiplexing multiple hosts using this
416 encapsulation behind a single IPv4 address. However, 6over4 works
417 within IPv4 domains that reside behind a NAT in their entirety and
418 use [RFC1918] addressing.
420 Because of its reliance on IPv4 multicast and because local IPv6
421 communication is relatively easy to facilitate using IPv6 routers,
422 6over4 is not supported in current operating systems. ISATAP
423 (Section 3.7) provides very similar functionality without requiring
424 IPv4 multicast capability, and is implemented more widely.
426 3.4. Generic Routing Encapsulation (GRE)
428 Generic Routing Encapsulation (GRE) [RFC2784] is a generic point-to-
429 point tunnel mechanism that allows many other protocols to be
430 encapsulated in IP.
432 GRE is a simple protocol which is similar to configured tunnels
433 (Section 3.1) when used for IPv6-in-IPv4 tunneling. The main benefit
434 of GRE is that it can not only encapsulate IPv6 packets but any
435 protocol. The GRE header causes an extra overhead of 8 to 16 bytes
436 depending on which options are used. GRE sets the Protocol field in
437 the IP header to 47.
439 The GRE header can optionally contain a checksum, a key to separate
440 different traffic flows (for example, different tunnels) between the
441 same end points and a sequence number that can be used to prevent
442 packets from being processed out of order.
444 GRE is implemented in many routers, but not in most consumer-level
445 home gateways or desktop operating systems.
447 3.5. Connection of IPv6 Domains via IPv4 Clouds (6to4)
449 6to4 is specified in "Connection of IPv6 Domains via IPv4 Clouds"
450 [RFC3056]. It creates a block of IPv6 addresses from a locally
451 configured IPv4 address by concatenating that IPv4 address to the
452 prefix 2002::/16, resulting in a /48 IPv6 prefix. Addresses in
453 2002::/16 are considered reachable through the tunnel interface, so
454 the 6to4 network functions as a non-broadcast, multiple access (NBMA)
455 network through which 6to4 users can communicate. IPv6 packets are
456 encapsulated by adding an IPv4 header with the Protocol field set to
457 41.
459 The /48 prefix allows a single system running 6to4 to act as a
460 gateway or router for a large number of IPv6 hosts. Alternatively,
461 an individual host may run 6to4 and not act as a gateway or router.
462 The system running 6to4 must have a globally reachable IPv4 address.
463 Using 6to4 with a private IPv4 address [RFC1918] is not possible.
465 "An Anycast Prefix for 6to4 Relay Routers" [RFC3068] specifies an
466 anycast mechanism for 6to4 relays that provide connectivity between
467 the 6to4 network and the regular IPv6 internet. All public relays
468 share the IPv4 address 192.88.99.1, which corresponds to 2002:c058:
469 6301::. Relays advertise reachability towards 2002::/16 towards the
470 native IPv6 internet, so packets addressed to systems using 6to4
471 addresses are routed to the closest gateway. The gateway
472 encapsulates these packets and forwards them to the IPv4 address
473 included in the IPv6 address. Systems running 6to4 have a default
474 route pointing to 2002:c058:6301::, so they tunnel packets addressed
475 to non-6to4 IPv6 destinations to the closest relay, which
476 decapsulates the packet and forwards them as IPv6 packets.
478 The 6to4 protocol adds minimal protocol 41 overhead and requires no
479 manual configuration from users. The biggest problem specific to
480 6to4 is that it is unpredictable which 6to4 anycast relay is used.
481 These relays are often provided by third parties on a best-effort
482 basis. In practice this has caused unpredictable performance.
483 Traffic from the 6to4 network to the regular IPv6 internet will
484 likely use a different 6to4 relay than the traffic in the opposite
485 direction. If either of those relays is not reliable then the
486 communication between those networks is affected. Especially the
487 lack of control over the relay used for return traffic is considered
488 to be a problem with 6to4.
490 To avoid problems with 6to4 the IPv6 Default Address Selection
491 algorithm [RFC6724] gives IPv4 addresses a higher preference than
492 6to4 addresses. When making a connection a system will prefer native
493 IPv6 over IPv4, and IPv4 over 6to4 IPv6. This causes 6to4 to be used
494 only when a destination is not reachable over IPv4 and no other IPv6
495 connectivity is available.
497 For more information about 6to4, see "Advisory Guidelines for 6to4
498 Deployment" [RFC6343].
500 *Warning*:
502 Although many, if not all, 6to4 implementations disable the mechanism
503 when the system only has an RFC 1918 address, recently a block of
504 IPv4 address has been set aside for use in service provider operated
505 Network Address Translators, also known as Carrier Grade NAT (CGN).
506 [RFC6598] sets aside the block 100.64.0.0/10 for the use between CGNs
507 and subscriber devices. As 100.64.0.0/10 is not an RFC 1918 address
508 block, systems implementing 6to4 may fail to disable the mechanism,
509 but due to the shared nature of the 100.64.0.0/10 prefix, 6to4 cannot
510 work using these addresses. The same issue is present if an ISP
511 decides to use regular global unicast IPv4 address space behind a
512 CGN.
514 3.5.1. 6to4 Provider Managed Tunnels
516 [RFC6732] describes "6to4 Provider Managed Tunnels", which is a way
517 to make 6to4 work behind a CGN. This is accomplished by running a
518 6to4 gateway at the 6to4 gateway anycast address, and then
519 translating the IPv6 addresses used by 6to4 users behind the CGN to
520 IPv6 addresses from the ISP's range. Unlike IPv4 NAT, where multiple
521 internal hosts share a single public IPv4 address, prefix translation
522 translates entire prefixes, so each host has its own public IPv6
523 address and can receive incoming packets as usual.
525 However, if IPv6 applications are not aware that translation is
526 happening (and they have no reason to expect that it is), they may
527 not use their externally visible address in referrals, so
528 applications that use referrals are likely to fail. Additionally,
529 the translation is only specified for packets that flow through the
530 6to4 gateway, not for packets sent directly to other 6to4 users. So
531 communication with other 6to4 users is not possible. As such, the
532 use of 6to4 provider managed tunnels is discouraged except as a very
533 last resort.
535 3.6. Anything In Anything (AYIYA)
537 AYIYA [AYIYA] is designed for use by the SIXXS [SIXXS] tunnel broker
538 service. The specification has been published as an Internet-Draft
539 [I-D.massar-v6ops-ayiya].
541 The AYIYA protocol defines a method for encapsulating any protocol in
542 any other protocol. The most common way of deploying AYIYA is to use
543 the following sequence of headers: IPv4-UDP-AYIYA-IPv6, although
544 other combinations like IPv4-AYIYA-IPv6 or IPv6-SCTP-AYIYA-IPv4 are
545 also possible. The draft does not limit the contents nor the
546 protocol that carries the AYIYA packets. In this document we only
547 look at the most common usage (IPv4-UDP-AYIYA-IPv6) which is deployed
548 on the SixXS tunnel brokers to provide IPv6 access to clients behind
549 NAT devices.
551 AYIYA specifies the encapsulation, identification, checksum, security
552 and certain management operations that can be used once the tunnel is
553 established. It does not specify how the tunnel configuration
554 parameters can be negotiated. Typically, the TIC protocol described
555 in Section 4.3 protocol is used for that part of the tunnel setup,
556 although the TSP protocol (Section 4.1) could be used.
558 AYIYA provides a point-to-point tunnel, over which the endpoints can
559 route traffic for any source and destination. When using SHA-1
560 hashing for authentication, as is common when using the AICCU client
561 with a SixXS tunnel server, the total packet overhead is 72 bytes (20
562 for the IPv4 header, 8 for UDP and 44 for AYIYA).
564 AYIYA provides operational commands for querying the hostname,
565 address, contact information, software version and last error
566 message. An operational command to ask the other side of the tunnel
567 to shut down is also available. These commands in the protocol can
568 make debugging of AYIYA tunnels easier if the tools support them.
570 The main advantage of AYIYA is that it can provide a stable tunnel
571 through an IPv4 NAT, and possibly multiple layers of NAT. The UDP
572 port numbers allow multiple AYIYA users to share a single IPv4
573 address behind a NAT.
575 The client will contact the tunnel server at regular intervals and
576 the tunnel server will automatically adapt to changing IPv4 addresses
577 and/or UDP port numbers. To prevent a third party from injecting
578 rogue packets into the tunnel the client can optionally be
579 authenticated by using the identity and signature fields. A
580 timestamp is included in the AYIYA header to guard against replay
581 attacks.
583 There is currently a single implementation of this protocol: the
584 AICCU [AICCU] client software used with the SIXXS [SIXXS] tunnel
585 broker service.
587 3.7. Intra-site Automatic Tunnel Addressing (ISATAP)
589 ISATAP [RFC5214] uses protocol 41 encapsulation, to provide
590 connectivity between isolated IPv6-capable nodes within an
591 organisation's internal network. It is similar to 6over4
592 (Section 3.3), but without the requirement that the IPv4 network
593 supports multicast; unlike 6over4, ISATAP uses a Non-Broadcast
594 Multiple Access (NBMA) communication model and thus doesn't support
595 multicasts. The mechanism assigns IPv6 addresses whose interface
596 identifier is solely defined by a node's IPv4 address, which is
597 assumed to be unique.
599 In order to obtain a /64 prefix, an ISATAP host needs to send a
600 unicast Router Solicitation to receive a unicast Router Advertisement
601 from an ISATAP router. Without the ability to send and receive IPv6
602 multicasts, an ISATAP host must be configured with a Potential Router
603 List through an all-IPv4 mechanism, such as manual setup, DHCP or the
604 DNS. Site administrators are encouraged to use a DNS Fully Qualified
605 Domain Name using the convention "isatap.domainname" (e.g.,
606 isatap.example.com). Hosts will accept packets with IPv4 sender
607 addresses that are either on the Potential Router List, or that are
608 embedded in the IPv6 sender address.
610 The router's prefix and the IPv4 address together define the IPv6
611 address for the ISATAP interface. This means that precisely one
612 ISATAP address is available for each IPv4 address. As such, each
613 host needs to run ISATAP itself in order to enjoy ISATAP IPv6
614 connectivity. The IPv4 address in the destination IPv6 address is
615 used to bootstrap Neighbour Discovery.
617 [RFC5214] doesn't explicitly address the use of ISATAP using private
618 [RFC1918] addresses. Despite that, the mechanism seems compatible
619 with private addresses. NAT, however, breaks the relationship
620 between the IPv4 address embedded in the IPv6 address and would
621 therefore make communication between ISATAP hosts impossible. Any
622 device that can communicate with the ISATAP hosts over IPv4 using
623 protocol 41 can participate in the IPv6 subnet.
625 ISATAP is available in Windows, Linux and Cisco IOS.
627 3.8. Tunneling IPv6 over UDP through NATs (Teredo)
629 Teredo is specified in [RFC4380] and a few updates; it is designed as
630 an automatic tunnel mechanism of last resort. It can configure an
631 IPv6 address behind most NAT devices, but not all. Because Teredo
632 uses encapsulation in UDP, multiple Teredo clients can be
633 simultaneously active behind the same NAT. For each Teredo client, a
634 single IPv6 address is then created at the expense of a single
635 external UDP port.
637 The operation of Teredo is based on a classification of NAT [RFC3489]
638 as established during an interaction with a Teredo server. This
639 classification has since been obsoleted [RFC5389] because it assigns
640 more properties to NAT than achieved in reality.
642 Teredo is present in Windows XP and later, and is enabled by default
643 in Windows Vista and later. However, Windows will only use Teredo
644 connectivity as a way to connect to IPv6 destinations of last resort.
645 If no other IPv6 connectivity is present, Windows will not even look
646 up AAAA records when resolving domain names. This means that Teredo
647 is only used to connect to explicit IPv6 addresses obtained through
648 another mechanism than DNS. An open source implementation named
649 Miredo exists for other platforms.
651 The performance of Teredo falls noticeably short of that of IPv4.
652 The setup time of a connection involves finding a Teredo relay nearby
653 the native address to encapsulate and decapsulate traffic, and
654 finding this relay can take in the order of seconds. This process is
655 not sufficiently reliable; Teredo fails in about 37% [TERTST] of its
656 attempts to connect to native IPv6 destinations. The round trip time
657 of traffic can add tenths of a second, and jitter generally worsens
658 if it is dependent on a public relay.
660 Teredo clients need to be configured with a Teredo server when
661 setting up their local IPv6 address and when initiating a connection
662 to a native IPv6 destination. The hostnames of the Teredo servers
663 are usually pre-configured by the vendor of the Teredo
664 implementation. All Microsoft Windows implementation use Teredo
665 servers provided by Microsoft by default.
667 3.9. IPv6 Rapid Deployment (6rd)
669 6rd [RFC5969] is used by service providers to connect customer
670 networks behind a CPE to the IPv6 internet.
672 The structure of the 6rd protocol is based on 6to4 and it has the
673 same minimal overhead as all protocols that use protocol 41
674 encapsulation. The main differences between 6rd and 6to4 are that
675 6rd is meant to be used inside a service provider's network and does
676 not use a special IPv6 prefix but one or more prefixes routed to the
677 service provider. As such, 6rd users aren't immediately recognisable
678 by their IPv6 address the way 6to4 users are. Where 6to4 uses relays
679 based on global anycast routing 6rd uses relays provided and
680 maintained by the service provider. Because of this architecture the
681 tunnel does not traverse unknown networks which makes any debugging
682 much easier.
684 6rd is completely stateless once it is configured. The tunnel
685 endpoints can therefore be deployed using anycast. This is commonly
686 done for the 6rd border relays deployed by the service provider to
687 provide redundancy.
689 Because of the different prefix, the device used as the 6rd client
690 cannot use the hard-coded IPv6 prefix calculation and relay addresses
691 of 6to4. Instead, the 6rd client needs to receive configuration
692 information to work. In principle 6rd nodes may be configured in a
693 variety of ways, the most common one being through DHCP. If the
694 client receives its IPv4 address from a DHCPv4 server then the 6rd
695 configuration can be included in the DHCP message exchange using the
696 6rd DHCPv4 Option defined in [RFC5969]. Manual configuration of 6rd
697 options and configuration using [TR-069] is also possible.
699 The main advantage of using 6rd is that it allows service providers
700 to deploy IPv6 on last mile access networks that for some reason
701 cannot provide native IPv6 connectivity. It does not share the lack
702 of predictable routing that 6to4 suffers from, because all routing,
703 encapsulation and de-encapsulation is done by the service provider.
705 6rd is intended to be a service managed by an ISP or enterprise IT
706 department, which must explicitly make 6rd available for clients to
707 be able to use it.
709 3.10. Native IPv6 behind NAT44 CPEs (6a44)
711 Inspired by Teredo, the 6a44 tunnel is described in "Native IPv6
712 behind IPv4-to-IPv4 NAT Customer Premise Equipment (6a44)" [RFC6751].
713 Its purpose is to enable Internet Service Providers to establish IPv6
714 connectivity for their customers, in spite of the use of a CPE or
715 home gateway that is not prepared for IPv6. The infrastructure
716 required for this is a 6a44 relay in the ISP's network and a 6a44
717 client in the customer's internal network.
719 6a44 was explicitly designed to overcome the noted problems with
720 Teredo. Where Teredo was designed as a global solution without
721 dependency on ISP co-operation, the 6a44 tunnel explicitly assumes
722 ISP co-operation. Instead of using Teredo's well-known prefix, a /48
723 prefix out of the ISP's address space is used. A well-known
724 (anycast) IPv4 address has been assigned for the 6a44 relay to be run
725 inside the ISP network without client configuration. This well-known
726 address is allocated from the same IPv4 /24 as 6to4.
728 As part of its bootstrapping, a 6a44 client requests an address from
729 the 6a44 relay, and a regular keepalive sent by the 6a44 client to
730 the 6a44 relay keeps mapping state in NATs and firewalls on the path
731 alive. Traffic passed from the native IPv6 internet to 6a44 is
732 encapsulated in UDP and IPv4 by the relay and decapsulated by the
733 6a44 client; the opposite is done in the other direction.
735 3.11. Locator/ID Separation Protocol (LISP)
737 The Locator/ID Separation Protocol (LISP) [RFC6830] is a protocol to
738 separate the identity of systems from their location on the internet
739 and/or internal network. The addresses of the systems are called
740 Endpoint Identifiers (EIDs) and the addresses of the gateways are
741 called Routing Locators (RLOCs). It is possible to use IPv6 EIDs
742 with IPv4 RLOCs and thereby use LISP for tunneling IPv6 over IPv4.
744 LISP defines its own packet formats for encapsulation of data packets
745 and for control messages. All such packets are then encapsulated in
746 UDP. Data packets use port 4341 and control packets use port 4342.
748 The LISP specification consists of several RFC documents. The
749 relevant ones for IPv6-in-IPv4 tunneling are the base specification
750 [RFC6830], Interworking between Locator/ID Separation Protocol (LISP)
751 and Non-LISP Sites [RFC6832] and the Locator/ID Separation Protocol
752 (LISP) Map-Server Interface [RFC6833].
754 +----+ +----+
755 | MS | | MR |
756 +----+ +----+ +-----+ /-----------\
757 | | /---| xTR |---| LISP site |
758 +------+ /------------\---/ +-----+ \-----------/
759 | PxTR |---| IP network |
760 +------+ \------------/---\ +-----+ /-----------\
761 | \---| xTR |---| LISP site |
762 /---------------\ +-----+ \-----------/
763 | Non-LISP site |
764 \---------------/
766 An example of a LISP deployment
768 LISP introduces new terminology and new concepts. The relevant ones
769 for this document are:
771 ITR: Ingress Tunnel Router, a router encapsulating data packets at
772 the border of a LISP site
774 ETR: Egress Tunnel Router, a router decapsulating data packets at
775 the border of a LISP site
777 xTR: A router performing both the ITR and the ETR functions
779 PITR: Proxy ITR, a router accepting traffic from non-LISP sites,
780 encapsulating it and tunneling it to the LISP sites
782 PETR: Proxy ETR, a router accepting traffic from LISP sites to send
783 it to non-LISP sites
785 PxTR: A router performing both the PITR and the PETR functions
787 MS: Map Server, a server accepting RLOC registrations from ETRs
789 MR: Map Resolver, a server that can resolve queries for RLOCs from
790 ITRs
792 LISP ETRs register the EID prefixes that they can handle traffic for
793 in one or more Map Servers. ITRs and PITRs can then query Map
794 Resolvers to determine which RLOCs to use when sending traffic to a
795 LISP site. PITRs advertise aggregates of EID prefixes to the global
796 routing table and provide tunneling services for them so that non-
797 LISP sites can reach LISP sites. PETRs provide a way for LISP sites
798 to send traffic to non-LISP sites.
800 LISP is a complex protocol if only used for tunneling. What it
801 provides additionally is that ETRs can advertise their own RLOC
802 addresses, that one site can have multiple xTRs with independent
803 RLOCs and that the LISP site administrator can specify priorities and
804 weights for those RLOCs. This provides redundancy and explicit load
805 balancing between RLOCs. It also provides automatic tunneling
806 between different sites without using a PxTR if both sites use Map
807 Servers and Map Resolvers that are interconnected, for example by
808 participating in the LISP Beta Network [LISPBETA]. To facilitate
809 these interconnections the LISP Delegated Database Tree (DDT) system
810 is available.
812 The LISP protocol is implemented on most Cisco devices. There are
813 implementations available for FreeBSD and Linux, as well as a
814 platform independent implementation in the Python programming
815 language. Note that for LISP to work, a mapping service not unlike
816 the DNS must be in place.
818 3.12. Subnetwork Encapsulation and Adaptation Layer (SEAL)
820 The Subnetwork Encapsulation and Adaptation Layer (SEAL)
821 [I-D.templin-intarea-seal] (along with its companion technologies
822 cited therein) provides a hybrid configured/automatic tunneling
823 system. SEAL itself provides a mid-layer of encapsulation between
824 the inner IPv6 header and the outer IPv4 header, i.e., as IPv4-SEAL-
825 IPv6. SEAL can also be used in conjunction with an outer UDP
826 encapsulation header, e.g., if NAT traversal is necessary.
828 The SEAL tunnel endpoint creates bidirectional configured tunnels to
829 reach default IPv6 routers, and discovers unidirectional automatic
830 tunnels. SEAL tunnels can be configured over multiple underlying
831 IPv4 links whether the addresses are provisioned from public or
832 private IPv4 addressing domains. In that case, multi-homing and
833 traffic engineering are naturally supported.
835 SEAL provides an optional 32-bit Identifier and variable-length
836 Integrity Check Vector that can be used for packet identification,
837 message origin authentication, anti-replay and a mid-layer
838 segmentation and reassembly capability. SEAL also provides a SEAL
839 Control Message Protocol (SCMP) used for neighbour coordinations
840 between tunnel endpoints. These coordinations are used for functions
841 such as tunnel MTU signalling, route optimisations, neighbour
842 reachability testing and so on.
844 SEAL ensures that packets that are no larger than 1500 bytes can be
845 transported through the tunnel by using a tunnel segmentation
846 function. IPv6 packets that are too large to transport through the
847 tunnel whole are split into segments. The segments are encapsulated
848 in IPv4 and reassembled into the original IPv6 packets at the remote
849 tunnel endpoint. SEAL also admits packets larger than 1500 bytes
850 into the tunnel on a best-effort basis in case the path between the
851 tunnel endpoints can support the larger size.
853 When SEAL is used alone without its companion technologies, it can be
854 used in the same scenarios as for GRE. However, SEAL provides
855 advanced capabilities that make it better suited than GRE for many
856 use cases. There is currently an experimental open source
857 implementation of SEAL.
859 3.13. Peer-to-Peer IPv6 on Any Internetwork (6bed4)
861 The 6bed4 tunnel is specified in "6bed4: Peer-to-Peer IPv6 on Any
862 Internetwork" [6BED4]. A specific goal of 6bed4 is to achieve direct
863 communication between peers when the intermediate infrastructure does
864 not prohibit it. The advantage of direct communication is to get a
865 performance level similar to IPv4. The address of a 6bed4 peer is
866 formed from the external IPv4 address and UDP port. The tunnel
867 service used for fallback connectivity can run anywhere; perhaps at
868 the local ISP or perhaps with a third party service provider for
869 6bed4, or even on a well-known address. It is currently an NBMA
870 protocol; there are openings for expansion with multicast.
872 The setup of 6bed4 is somewhat similar to 6to4, except that it
873 employs UDP so it can be used behind NAT. It also has elements found
874 in Teredo, but without a need to classify NATs and induce behaviour
875 from that. The 6bed4 tunnel makes no assumption NAT devices beyond
876 straightforward UDP support. Given this, 6bed4 can create reliable
877 IPv6 tunnels.
879 In environments where direct connections between 6bed4 peers is
880 possible, additional path stretch compared to IPv4 communication is
881 avoided, so 6bed4 performance comes close to IPv4 performance. In
882 situations where this is not possible run over the direct path
883 between two peers because a NAT that does not conform to [RFC4787] is
884 on the path, a fallback to a tunnel server is used. This increases
885 path stretch and affects scalability through its impact on roundtrip
886 times and jitter.
888 Another area where the tunnel server is needed, is for connectivity
889 between 6bed4 peers and native IPv6 hosts. For reasons of
890 performance and scalability, connections between 6bed4 peers are
891 preferred over connections between a 6bed4 peer and a native IPv6
892 host. A default address exists to support zero-config operation, but
893 it is possible to locally configure a tunnel server as a fallback
894 route, which then also defines the tunnel server for the return path.
896 6bed4 has been specifically designed to support realtime interactive
897 traffic streams, such as SIP calls, between 6bed4-supporting end
898 points, assuming that each prefers 6bed4-to-6bed4 traffic over 6bed4-
899 to-native traffic. Under that premise, the only hosts that need to
900 go through a tunnel server are those that are behind a NAT with
901 Address-Dependent Mapping or Address and Port-Dependent Mapping. A
902 number of different implementations of 6bed4 have been constructed
903 [6BED4] during the ongoing development of its specification.
905 4. Related Protocols
907 The following protocols are not tunnel mechanisms but they can be
908 used in the configuration and/or setup phase of such protocols.
910 4.1. Tunnel Setup Protocol (TSP)
912 The Tunnel Setup Protocol [RFC5572] specifies a protocol for
913 negotiating the setup of a variety of tunnel encapsulations. In this
914 document we are only interested in the encapsulation of IPv6 in IPv4.
915 The Tunnel Setup Protocol can negotiate these as a protocol 41
916 encapsulated tunnel or as a UDP-encapsulated tunnel. The tunnel
917 negotiation is performed as an XML exchange over UDP or TCP.
919 As a TSP client exchanges all IPv6 traffic with the same tunnel
920 server, there are no concerns caused by NAT implementations. The
921 only concern is to send regular keepalives, for which ICMPv6 ping
922 messages to the tunnel server are suggested. When encapsulating IPv6
923 packets directly in IPv4, all protocol 41 limitations apply. To
924 avoid these, an additional UDP header may be used.
926 The Tunnel Setup Protocol treats all protocols and ports for one IPv4
927 client address as equivalent. This suffices when protocol 41 is
928 used, but for UDP it creates a situation where one user can set up a
929 tunnel behind NAT, and another user could hijack the tunnel
930 privileges.
932 Open source clients for the Tunnel Setup Protocol and a matching
933 tunnel infrastructure are provided from the freenet6 tunnel service
934 [GOGO6].
936 4.2. SixXS Heartbeat Protocol
938 The SixXS Heartbeat Protocol [I-D.massar-v6ops-heartbeat] allows
939 nodes that have intermittent connectivity or a dynamic IPv4 address
940 that changes from time to time to have continuing tunneled IPv6
941 connectivity. One of the goals of the protocol is to determine when
942 a node is no longer present at its previous IPv4 address and then
943 stop sending tunneled packets to avoid tunneled packets from being
944 delivered to the wrong node. The Heartbeat Protocol then allows a
945 tunnel broker to determine a client's new IPv4 address and continue
946 sending tunneled packets with minimal interruption.
948 To accomplish this, a node sends periodic heartbeat packets to the
949 tunnel broker. If the tunnel broker fails to receive valid heartbeat
950 packets, it shuts down the tunnel in question. Heartbeat packets
951 contain an MD5 message authentication code and a timestamp to avoid
952 replay attacks. The Heartbeat Protocol can work with different
953 tunnel mechanisms, but it is often used with configured tunnels
954 (Section 3.1).
956 The protocol is implemented in the SixXS tunnel broker; client
957 implementations are available for common operating systems. AYIYA
958 can be considered the successor of the Heartbeat Protocol.
960 4.3. Tunnel Information and Control protocol (TIC)
962 The Tunnel Information and Control protocol (TIC) protocol [TIC] is
963 the setup protocol for the [SIXXS] tunnel broker service.
965 With the TIC protocol a tunnel broker user can request a list of
966 available tunnels and points-of-presence (POPs) from the tunnel
967 broker service. When the user chooses one of the tunnels, the
968 configuration parameters for that tunnel can then be requested
969 through TIC. TIC also provides commands to control the tunnel, for
970 example to change the tunnel endpoints, enable or disable the tunnel.
972 Authentication of users is done based on username and password.
973 Certain tunnel mechanisms, such as AYIYA (Section 3.6) and configured
974 tunnels (Section 3.1) with heartbeat (Section 4.2), need a
975 synchronised clock between the tunnel server and the client. TIC
976 facilitates this by providing a server timestamp on request. The
977 client can use that to verify that its clock is synchronised with the
978 server and show an error message to the user if it is not.
980 The TIC protocol is implemented in the AICCU [AICCU] client software
981 and in AVM Fritz!Box home routers.
983 5. Common Aspects
985 The following are aspects common to many or all tunnel mechanisms.
987 5.1. Protocol 41 Encapsulation
989 The most straightforward way to encapsulate an IPv6 packet inside an
990 IPv4 packet is by simply adding an IPv4 header in front of the IPv6
991 header. In this case, the protocol field in the IPv4 header is set
992 to the value 41. This encapsulation is also known as "IPv6 in IPv4"
993 and "IP6 Encapsulation".
995 This simple "protocol 41" encapsulation is used by a number of tunnel
996 mechanisms:
998 configured tunnels (Section 3.1)
1000 automatic tunneling (Section 3.2)
1001 6over4 (Section 3.3)
1003 6to4 (Section 3.5)
1005 ISATAP (Section 3.7)
1007 6rd (Section 3.9)
1009 5.2. NAT and Firewalls
1011 It is not uncommon for NATs and firewalls to block protocol 41
1012 encapsulated packets, especially at the boundary between an
1013 organisation's internal network and the public internet. Other
1014 tunnel mechanisms than protocol 41 typically employ a UDP header, and
1015 are somewhat less likely to be filtered, assuming that tunneling is
1016 initiated on the LAN-side. UDP is usually subjected to NAPT
1017 [RFC2663] which additionally translates between internal and external
1018 port numbers. (Often, the term "NAT" is used where "NAPT" may be
1019 more appropriate.)
1021 Although protocol 41 can in principle work through NAT, there are two
1022 issues. First, when the IPv6 address is derived from the IPv4
1023 address (see Section 5.4), NATing of the outer IPv4 header breaks the
1024 relationship between the IPv4 and IPv6 addresses. Second, because
1025 protocol 41 does not use port numbers, the number of protocol 41
1026 tunnel endpoints that can be supported behind a NAT device is equal
1027 to its number of external IPv4 addresses (see Section 6.1). This
1028 limitation also applies to GRE.
1030 Tunnels that pass through a NAT device or stateful firewall need to
1031 generate traffic at regular intervals to refresh the NAT or firewall
1032 mapping. If the mapping is lost, tunneled packets from the outside
1033 won't be able to pass through the NAT/firewall until a system behind
1034 the NAT or firewall sends a tunneled packet and the mapping is
1035 recreated. Alternatively, a static mapping (often in the form of a
1036 "default" or "DMZ" host) may be configured manually.
1038 The following tunnel mechanisms are incompatible with NAT because
1039 their addresses must be derived from a globally unique IPv4 address:
1041 automatic tunneling (Section 3.2)
1043 6to4 (Section 3.5)
1045 6rd (Section 3.9)
1046 LISP (Section 3.11)
1048 Note that it is common to run 6to4 or 6rd on a home gateway device
1049 that also performs IPv4 NAT. In this configuration, NAT is not
1050 applied to tunneled packets, so NAT and 6to4/6rd can coexist.
1052 The following tunnel mechanisms cannot operate between nodes on
1053 opposing sides of a NAT, but they do work if _all_ nodes are behind a
1054 NAT (where RFC 1918 addresses are often used):
1056 6over4 (Section 3.3)
1058 ISATAP (Section 3.7)
1060 The following tunnel mechanisms may work through NAT in some
1061 circumstances, but are not designed for NAT compatibility:
1063 configured tunnels (Section 3.1)
1065 GRE (Section 3.4)
1067 The following tunnel mechanisms are designed for NAT compatibility:
1069 AYIYA (Section 3.6)
1071 Teredo (Section 3.8) (but it is unreliable)
1073 6a44 (Section 3.10)
1075 SEAL (Section 3.12)
1077 6bed4 (Section 3.13)
1079 The LISP specification requires that locator addresses (the addresses
1080 in the outer IPv4 header) are globally routable public addresses.
1082 A tunnel built over UDP makes a claim on a resource, namely an
1083 external UDP port. This may impact how well a tunnel will scale in
1084 an organisation; for instance, if every desktop runs its own tunnel
1085 client over UDP then the claim on this resource may have some impact.
1087 Note that ISPs may have multiple subscribers share a public IPv4
1088 address by performing NAT (Carrier Grade NAT, CGN or CGNAT in this
1089 context). In this case, the subscribers' home gateways may receive
1090 an address in the 100.64.0.0/10 block [RFC6598]. For the purposes of
1091 tunnel mechanisms, this address block is similar to the [RFC1918]
1092 address blocks. However, NAT/RFC1918 aware tunnel implementations
1093 may not recognise 100.64.0.0/10 as non-public addresses and fail to
1094 operate successfully. The same issue is present if an ISP decides to
1095 use regular global unicast IPv4 address space behind a CGN.
1097 5.3. MTU Considerations
1099 Because of the extra IPv4 header and possible additional headers
1100 between the IPv4 and IPv6 headers, tunnels experience a reduced
1101 maximum packet size (Maximum Transfer Unit, MTU) compared to native
1102 IPv6 communication.
1104 Path MTU discovery (PMTUD) should handle this in nearly all cases,
1105 but filtering of ICMPv6 "packet too big" messages may lead to an
1106 inability to communicate because senders of large packets fail to
1107 perform PMTUD successfully. However, when a tunnel terminates
1108 directly on the host using it, the TCP maximum segment size (MSS)
1109 option communicates the maximum packet size to the remote endpoint,
1110 so TCP-based communication may still succeed. If not, the initial
1111 TCP SYN/ACK exchange happens without issue, but then the session
1112 stalls as the larger packets containing data are lost.
1114 With tunnel mechanisms where the MTU is left unspecified, it is
1115 possible for the two endpoints to have different MTUs: typically, one
1116 uses the IPv6 minimum, 1280, while the other uses the physical MTU
1117 minus tunnel overhead, often 1480. In theory, this should lead to
1118 PMTUD failures because the "big" side unknowingly sends packets that
1119 the "small" side can't handle. However, in practice implementations
1120 handle incoming packets larger than their own MTU without issue.
1122 Only when the IPv4 MTU is reduced below 1500 bytes, for instance when
1123 using PPP over Ethernet (PPPoE, [RFC2516]), issues are more likely to
1124 arise. So when the possibility exists that tunneled packets
1125 encounter a PPPoE link, it is prudent to set the MTU of a tunnel to
1126 no more than 1472 bytes, so tunneled packets don't have to be
1127 fragmented. Additionally, Section 3.2.1 of [RFC4213] recommends
1128 limiting the MTU of tunnels to the minimum of 1280.
1130 SEAL was specifically designed to overcome these limitations by
1131 adding the capability to fragment IPv6 packets prior to encapsulation
1132 in IPv4 and then reassembling the fragments at the remote tunnel
1133 endpoint. This way, the SEAL tunnel ensures that packets that are no
1134 larger than 1500 bytes will be transported to the tunnel far end even
1135 if there are restricting links in the path. SEAL can also admit
1136 larger packets into the tunnel on a best effort basis in case the
1137 path between the tunnel endpoints can support this larger size.
1139 5.4. IPv4 Addresses Embedded in IPv6 Addresses
1141 Many tunnel mechanisms embed IPv4 addresses or further information in
1142 the IPv6 addresses they use. There are two possible reasons for
1143 this. First, with an IPv4 address embedded in the IPv6 address, the
1144 outer IPv4 header can be derived without a need to explicitly
1145 configure tunnel endpoints. Automatic tunneling, 6to4, ISATAP, 6bed4
1146 and Teredo do this. 6over4 embeds the IPv4 address for the second
1147 reason; it is embedded in the interface identifier, and thus the IPv6
1148 address, because that way, a (presumably) globally unique interface
1149 identifier can be generated.
1151 Automatic tunneling uses IPv4-compatible addresses in the prefix
1152 ::/96 (i.e., the first 96 bits are all zero).
1154 | 96 bits | 32 |
1155 +------------------------------------------------+-----------------+
1156 | 0:0:0:0:0:0 | IPv4 address |
1157 +------------------------------------------------+-----------------+
1159 The IPv4-compatible addresses structure
1161 Systems running 6to4 have addresses in the 6to4 prefix 2002::/16.
1163 | 16 | 32 | 16 | 64 bits |
1164 +--------+-----------------+--------+------------------------------+
1165 | 2002 | IPv4 address | Subnet | Interface ID |
1166 +--------+-----------------+--------+------------------------------+
1168 The 6to4 address structure
1170 Because a 6rd domain might share a common IPv4 prefix it is not
1171 always necessary to encode all 32 bits of the IPv4 address in the 6rd
1172 delegated prefix. The bits that become available because of this
1173 optimisation can be used to provide more subnet IDs to the user
1174 and/or to use a smaller address block for the 6rd prefix.
1176 | n bits | o bits | m bits | 128-n-o-m bits |
1177 +---------------+--------------+-----------+-----------------------+
1178 | 6rd prefix | IPv4 address | subnet ID | interface ID |
1179 +---------------+--------------+-----------+-----------------------+
1180 |<--- 6rd delegated prefix --->|
1182 The 6rd address structure
1184 6over4 uses the IPv4 address to generate a 64-bit Interface
1185 Identifier, which can then be used to create a 128-bit IPv6 address
1186 through Stateless Address Autoconfiguration.
1188 | 48 bits | 16 | 32 | 32 |
1189 +---------------------+--------+-----------------+-----------------+
1190 | Organisation prefix | Subnet | 0:0 | IPv4 address |
1191 +---------------------+--------+-----------------+-----------------+
1193 The 6over4 address structure
1195 The ISATAP address structure is similar to the 6over4 address
1196 structure, except that the unique/local (u) bit signifies whether the
1197 IPv4 address in the interface identifier is unique. Presumably, this
1198 is the case for any non-[RFC1918] IPv4 address. The group (g) bit is
1199 set to zero, and the remaining bits are set to to 0x00005EFE.
1201 | 48 bits | 16 | 32 | 32 |
1202 +---------------------+--------+-----------------+-----------------+
1203 | Organisation prefix | Subnet | ug00:5EFE | IPv4 address |
1204 +---------------------+--------+-----------------+-----------------+
1206 The ISATAP address structure
1208 Teredo embeds the Teredo server's IPv4 address, a number of flags, a
1209 UDP port number as well as the Teredo client's IPv4 address in the
1210 IPv6 addresses it creates. For good measure, the UDP port and client
1211 IPv4 address are "obfuscated" by flipping their bits.
1213 | 32 bits | 32 | 16 | 16 | 32 |
1214 +----------------+---------------+-------+-------+-----------------+
1215 | 2001:0 | Server IPv4 | Flags | Port | Client IPv4 |
1216 +----------------+---------------+-------+-------+-----------------+
1218 The Teredo address structure
1220 6a44 can be seen as a combination of 6rd and Teredo. The 6a44 prefix
1221 is given out by an ISP. Both the customer site (home gateway) IPv4
1222 address as well as the host's/client's RFC 1918 IPv4 address and also
1223 a port number are embedded in the IPv6 address.
1225 | 48 bits | 32 | 16 | 32 |
1226 +----------------------+-----------------+-------+-----------------+
1227 | 6a44 prefix | Cust. site IPv4 | Port | Client IPv4 |
1228 +----------------------+-----------------+-------+-----------------+
1230 The 6a44 address structure
1232 6bed4 embeds two combinations of an IPv4 address and UDP port
1233 (together acting as a "6bed4 address") in the IPv6 address; the first
1234 address is for a tunnel server that everyone is certain to reach, the
1235 other is for the direct address that most peers should be able to
1236 reach directly. The tunnel server however, is the only one with
1237 guaranteed access to the direct address.
1239 | 64 bits | 50 | 14 |
1240 +--------+-----------------------+-------------------------+-------+
1241 | prefix | general 6bed4 address | direct 6bed4 address | lanIP |
1242 +--------+-----------------------+-------------------------+-------+
1244 The 6bed4 address structure
1246 Some details of the 6bed4 address format are still work in progress
1247 at the time of this writing. The lanIP bits are free for local
1248 purposes, such as creating a DHCPv6 range.
1250 6. Evaluation of Tunnel Mechanisms
1252 The following subsections deal with the various aspects of tunnels
1253 that guide their selection.
1255 6.1. Efficiency of IPv4 Address Use
1257 With the depletion of the IPv4 address space, the ability to deploy a
1258 tunnel mechanism behind NAT as well as the number of IPv6
1259 subscribers, subnets and individual hosts that can be supported
1260 behind a single IPv4 address have become important considerations.
1262 These issues are irrelevant to tunnel mechanisms that provide IPv6
1263 connectivity between hosts within the same administrative domain,
1264 such as ISATAP or 6over4, as they can use private IPv4 addresses.
1265 This is also true for 6rd, which is used between an ISP and its
1266 customers' home gateways when the ISP has implemented NAT.
1268 6to4 cannot work behind any kind of NAT. Most other mechanisms based
1269 on protocol 41 can work behind NAT, at least in principle. In
1270 practice this difference is not as big as the protocol 41
1271 encapsulation doesn't provide any fields that allow a NAT to
1272 demultiplex tunneled packets. This means that only a single protocol
1273 41 tunnel endpoint can be supported for each public IPv4 address.
1275 This makes configured tunnels (as well as 6to4) incompatible with
1276 service provider operated NATs, where multiple subscribers share an
1277 IPv4 address.
1279 Teredo, 6a44, 6bed4, AYIYA, SEAL and TSP are designed to work through
1280 NATs and use a UDP header, so multiple tunnel endpoints can be hosted
1281 behind a single IPv4 address. On the other hand, Teredo only
1282 provides IPv6 connectivity to a single host.
1284 The following table shows how many IPv4 addresses each tunnel
1285 mechanism requires and how many IPv6 hosts it can connect. The
1286 mechanisms are listed in order of increasing numbers of supported
1287 IPv6 hosts per IPv4 address.
1289 +------------+-------------+-------------+-------------+------------+
1290 | Mechanism | Tunnels per | IPv6 hosts | Public IPv4 | NAT |
1291 | | IPv4 addr. | per tunnel | address | compatible |
1292 +------------+-------------+-------------+-------------+------------+
1293 | Auto. tun. | one | one | required | no |
1294 | 6to4 | one | multiple | required | no |
1295 | LISP | one | multiple | required | no |
1296 | 6rd | one | multiple | not needed | no |
1297 | Conf. tun. | one | multiple | not needed | limited |
1298 | GRE | one | multiple | not needed | limited |
1299 | Teredo | multiple | one | not needed | yes (*) |
1300 | 6bed4 | multiple | multiple | not needed | yes |
1301 | 6a44 | multiple | multiple | not needed | yes |
1302 | AYIYA | multiple | multiple | not needed | yes |
1303 | SEAL | multiple | multiple | not needed | yes |
1304 +------------+-------------+-------------+-------------+------------+
1306 Tunneled IPv6 hosts per IPv4 address
1308 (*) Although Teredo is designed for NAT compatibility, it doesn't
1309 work through all existing NATs.
1311 6.2. Supported Network Topologies
1313 There are two ways to use an IPv6-in-IPv4 tunnel to connect to the
1314 IPv6 internet: using a point-to-point tunnel to a tunnel broker or an
1315 ISP-operated gateway, or using a non-broadcast multiple access (NBMA)
1316 tunnel and anycasted public gateways or relays.
1318 The advantages of the point-to-point model are predictable
1319 performance and flexibility regarding the IPv6 addresses used. The
1320 advantage of the NBMA model is that traffic between two hosts or
1321 networks that both use the mechanism can flow directly without
1322 passing through a gateway (direct peer-to-peer communication.). An
1323 extra advantage of the NBMA model with public gateways is automatic
1324 configuration and no involvement from an ISP.
1326 Unfortunately, the advantages of this NBMA public anycast model come
1327 at a price: both the peer-to-peer connectivity between tunnel users
1328 and the connectivity towards the native IPv6 internet may suffer from
1329 reliability and performance issues.
1331 The anycast mechanism allows tunnel users to utilise the nearest
1332 gateway to connect to the IPv6 internet by simply giving each gateway
1333 the same address. Routing protocols then select the lowest-cost (and
1334 presumably, shortest) path towards a gateway. However, this makes
1335 the path taken by tunneled packets hard to predict or influence. It
1336 is common for traffic in two directions to use different gateways,
1337 complicating debugging even further. Because nobody is in charge or
1338 gets paid for operating a gateway, the number of public gateways is
1339 lower than would be ideal. This increases the distance to the
1340 nearest gateway for some users. There is also the possibility that
1341 gateways encounter more traffic than they can handle.
1343 The advantage of a tunnel provided by an ISP or tunnelbroker is that
1344 there is a clear responsibility for providing a good service with
1345 well maintained gateways.
1347 +------------+---------------+--------------------------------+
1348 | Mechanism | Peer-to-peer | Gateway provided by |
1349 +------------+---------------+--------------------------------+
1350 | Conf. tun. | No | ISP or Tunnel broker |
1351 | AYIYA | No | ISP or Tunnel broker |
1352 | GRE | No | N/A |
1353 | 6a44 | Within domain | ISP |
1354 | 6rd | Within domain | ISP |
1355 | 6over4 | Globally | N/A |
1356 | ISATAP | Within domain | Own organisation |
1357 | Teredo | Globally | Public |
1358 | 6to4 | Globally | Public or ISP |
1359 | 6bed4 | Globally | Public or ISP or Tunnel broker |
1360 | Auto. tun. | Globally | N/A |
1361 | LISP | Configurable | ISP or Tunnel broker |
1362 | SEAL | Configurable | ISP or Tunnel broker |
1363 +------------+---------------+--------------------------------+
1365 Topologies Supported per Tunnel Mechanism
1367 6.3. Robustness
1369 Tunnels may fail for three main reasons: when tunneled packets are
1370 filtered, typically by a firewall, when a tunnel endpoint IPv4
1371 address changes or when tunneled packets are filtered or because of
1372 NAT issues.
1374 If a tunnel endpoint gets a new address, the other side of the tunnel
1375 needs to know to send packets to the new address. With mechanisms
1376 that derive IPv6 addresses from the IPv4 address, the previous IPv6
1377 addresses become unreachable and new IPv6 addresses must be
1378 configured.
1380 Some tunnel mechanisms don't work through NAT, or are limited when
1381 working through NAT. NAT mappings can typically only be created by
1382 traffic from the "inside" to the "outside", not by traffic from
1383 outside the NAT to the network behind the NAT.
1385 Point-to-point tunnel mechanisms either work consistently or they
1386 always fail. As such, a simple ping to the other side of the tunnel
1387 is sufficient to learn its state. Also, point-to-point tunnels may
1388 support routing protocols, which can automatically reroute traffic
1389 around a failed tunnel.
1391 Some tunnel mechanisms use a public gateway to reach the native IPv6
1392 internet. Public gateways may or may not be operational and/or
1393 reachable, and may have limited performance, depending on distance
1394 and usage.
1396 Tunnel mechanisms that use a broadcast or non-broadcast multiple
1397 access (NBMA) communication model may experience failures between
1398 some combinations of tunnel endpoints and not others.
1400 The following table lists tunnel mechanisms that provide connectivity
1401 to the IPv6 internet in order of decreasing robustness. (However,
1402 even less-robust mechanisms may function well in suitable
1403 environments.)
1405 +------------+---------------+--------------------------------------+
1406 | Mechanism | Endpoint | Main issues |
1407 | | address | |
1408 | | change | |
1409 +------------+---------------+--------------------------------------+
1410 | LISP | automatic | None |
1411 | 6rd | interrupt | None |
1412 | AYIYA | automatic | Transient NAT mapping issues |
1413 | Conf. + HB | interrupt | Proto 41 filtering, competition for |
1414 | | | NAT mappings (1) |
1415 | Conf. tun. | failure | Proto 41 filtering, competition for |
1416 | | | NAT mappings, address change (1) |
1417 | GRE | failure | Proto 47 filtering, address change |
1418 | 6a44 | interrupt | NAT mapping towards peers |
1419 | 6bed4 | interrupt | NAT mapping towards peers |
1420 | 6to4 | interrupt | Enabled out of the box but filtered, |
1421 | | | gateway performance (2) |
1422 | Teredo | interrupt | NAT compatibility, mapping towards |
1423 | | | peers (3) |
1424 +------------+---------------+--------------------------------------+
1426 Susceptibility of tunnel mechanisms to problems
1428 Notes:
1430 (1): only one protocol 41 tunnel endpoint can receive a NAT mapping
1431 behind a NAT using a single public IPv4 address. Additional
1432 endpoints will not receive incoming packets. When a tunnel
1433 endpoint changes its internal address, the old NAT mapping needs
1434 to time out before a new one can be created.
1436 (2): 6to4 implementations automatically disable the mechanism when
1437 the system has an RFC 1918 address. However, 6to4 may remain
1438 enabled and be non-operational when ISPs apply NAT using non-RFC
1439 1918 addresses [RFC6598].
1441 (3): whether Teredo can obtain an address depends on the type of NAT
1442 it detects. Whether Teredo functions at such an address depends
1443 on the accuracy of that determination, which is founded on an
1444 incomplete model of NAT.
1446 On some widely used implementations, 6to4 has been enabled by default
1447 without checking whether there was connectivity to the anycasted
1448 public gateway address. As a result, 6to4-derived connectivity to
1449 the IPv6 internet was often found to be broken because of protocol 41
1450 filtering. Because of this, many operating systems now try to avoid
1451 using IPv6 over 6to4. See [RFC6343].
1453 Also see [TERTST] for more information about the robustness of
1454 Teredo.
1456 There is not a single tunnel mechanism that is more robust in all
1457 possible ways than every other tunnel mechanism. However, in general
1458 mechanisms that use public gateways and peer-to-peer tunneling tend
1459 to have the most issues. Configured tunnels on the other hand, often
1460 work very well, especially if there is no NAT on the path, but may
1461 need administrative intervention when a tunnel endpoint address
1462 changes.
1464 6.4. Gateway State
1466 There is an additional consideration that is important to operators
1467 of gateways that connect IPv6-in-IPv4 tunnels to the IPv6 internet:
1468 how much state a tunnel mechanism requires.
1470 6to4 and 6rd require no state at all: when encapsulating IPv6 packets
1471 inside an IPv4 packet, the IPv4 destination address is directly
1472 copied from bits in the IPv6 destination address. This makes all
1473 possible tunneled destinations directly reachable through a single
1474 virtual interface.
1476 Teredo, 6a44 and 6bed4 require additional logic to work through NATs,
1477 which requires them to keep track of relatively volatile state. They
1478 also work on a per-host basis rather than allowing a number of hosts
1479 to make use of a single tunnel.
1481 With configured tunnels, GRE, AYIYA and SEAL there is no direct
1482 mapping from (part of) the IPv6 destination address to the IPv4
1483 destination address. A typical implementation of these mechanisms is
1484 by having a virtual tunnel interface for each tunnel. Packets are
1485 forwarded to the correct virtual interface through a routing table
1486 lookup. Routing tables can grow very large and remain fast, so the
1487 number of virtual interfaces tends to be the limiting factor for
1488 tunnel gateways. AYIYA and the SixXS Heartbeat Protocol also keep
1489 track of the reachability status of each tunnel.
1491 6.5. Performance
1493 There are several reasons why tunneled connectivity may perform
1494 inferior to native, un-tunneled connectivity. Inherently, tunnels
1495 add one or more extra headers, and therefore increase overhead.
1496 However, for a maximum size (1500 bytes) Ethernet packet the
1497 additional overhead of an IPv4 header is only 1.3%.
1499 The process of encapsulation is not inherently slow, but in some
1500 implementations, it may be. Larger routers that normally forward
1501 packets using special purpose hardware, often don't have high
1502 performance CPUs. If then tunnel encapsulation must be done by that
1503 relatively slow CPU, performance will be worse than regular hardware-
1504 based packet forwarding.
1506 The path that tunneled packets take can be longer than the path that
1507 untunneled packets would take. (Increased path stretch.) This may
1508 or may not lead to decreased performance.
1510 +------------+-----------------+----------------------+-------------+
1511 | Mechanism | Overhead | Increased path | Variability |
1512 | | (bytes) | stretch | |
1513 +------------+-----------------+----------------------+-------------+
1514 | Conf. tun. | 20 | may be large | none |
1515 | Auto. tun. | 20 | none | none |
1516 | 6over4 | 20 | none | none |
1517 | GRE | 28 - 36 | may be large | none |
1518 | 6to4 | 20 | may be large | high |
1519 | AYIYA | 72 | may be large | low |
1520 | ISATAP | 20 | none | none |
1521 | Teredo | 28 - 36 | may be large | high |
1522 | 6rd | 20 | small | low |
1523 | 6a44 | 20 - 28 | small | low |
1524 | 6bed4 | 28 | may be large | high |
1525 | LISP | 36 | small | low |
1526 | SEAL | 24 - variable | small | low |
1527 +------------+-----------------+----------------------+-------------+
1529 Typical tunnel performance
1531 7. IANA considerations
1533 None.
1535 8. Security considerations
1537 There are many security considerations with tunneling. An important
1538 one is that through a tunnel, connectivity to the IPv6 internet may
1539 exist even though network administrators did not intend for it to be
1540 there. "Security Concerns with IP Tunneling" [RFC6169] discusses
1541 this issue in detail.
1543 Although in principle, ingress filtering (BCP 38, [RFC2827]) is
1544 possible with tunnels, in practice, it is relatively easy for spoofed
1545 packets to make their way through a tunnel. Not only is it often
1546 easy to spoof the outer IPv4 header and make false IPv6 packets seem
1547 to originate from a tunnel broker or gateway, it may also be possible
1548 for an attacker to route false IPv6 packets through a legitimate
1549 tunnel broker or gateway. Many tunneling protocols have various
1550 means of detecting and rejecting such packets, while others have
1551 limited or no such provisions. For instance, see [RFC3964] for how
1552 this can be addressed with 6to4.
1554 So it is important to recognise that unless special measures are
1555 taken (like [RFC4301]), both IPv4 and IPv6 addresses in tunnel
1556 packets may be spoofed and cannot be relied upon for access controls.
1557 Such spoofing was used successfully to discover IPv6-in-IPv4 tunnels
1558 in [TUNDISC].
1560 Tunnels may also be used by third parties to obfuscate their
1561 activities or perform amplification attacks. To avoid contributing
1562 to this problem, it is important to make sure only locally generated
1563 packets with legitimate addresses are sent out over tunnels.
1565 9. Contributors
1567 Job Snijders contributed text to the points of comparison. Fred
1568 Templin provided the text for SEAL and contributed to the security
1569 considerations. Jeroen Massar, Brian Carpenter, Tina Tsou, John
1570 Mann, Suresh Krishnan, Victor Kuarsingh, Dan Jones, Nejc Skoberne and
1571 Fred Baker reviewed the document and/or offered suggestions for
1572 improvement.
1574 10. Acknowledgements
1576 We wish to thank SURFnet and Rogier Spoor for commissioning this
1577 work; both their initiative and funding has helped this document to
1578 be written.
1580 11. References
1582 [6BED4] Van Rein, R., "6bed4: Peer-to-Peer IPv6 on Any
1583 Internetwork", .
1585 [AICCU] SixXS, "Automatic IPv6 Connectivity Client Utility
1586 (AICCU)", .
1588 [AYIYA] SixXS, "Anything In Anything (AYIYA)",
1589 .
1591 [GOGO6] "Freenet6: Free and Easy IPv6 Connectivity",
1592 .
1594 [I-D.ietf-softwire-map]
1595 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S.,
1596 Murakami, T., and T. Taylor, "Mapping of Address and Port
1597 with Encapsulation (MAP)", draft-ietf-softwire-map-07
1598 (work in progress), May 2013.
1600 [I-D.massar-v6ops-ayiya]
1601 Massar, J., "AYIYA: Anything In Anything",
1602 draft-massar-v6ops-ayiya-02 (work in progress), July 2004.
1604 [I-D.massar-v6ops-heartbeat]
1605 Massar, J., "SixXS Heartbeat Protocol",
1606 draft-massar-v6ops-heartbeat-01 (work in progress),
1607 June 2005.
1609 [I-D.templin-intarea-seal]
1610 Templin, F., "The Subnetwork Encapsulation and Adaptation
1611 Layer (SEAL)", draft-templin-intarea-seal-55 (work in
1612 progress), May 2013.
1614 [LISPBETA]
1615 "LISP Beta Network", .
1617 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
1618 November 1990.
1620 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
1621 E. Lear, "Address Allocation for Private Internets",
1622 BCP 5, RFC 1918, February 1996.
1624 [RFC1933] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
1625 IPv6 Hosts and Routers", RFC 1933, April 1996.
1627 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
1628 for IP version 6", RFC 1981, August 1996.
1630 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
1631 and R. Wheeler, "A Method for Transmitting PPP Over
1632 Ethernet (PPPoE)", RFC 2516, February 1999.
1634 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
1635 Domains without Explicit Tunnels", RFC 2529, March 1999.
1637 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
1638 Translator (NAT) Terminology and Considerations",
1639 RFC 2663, August 1999.
1641 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
1642 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
1643 March 2000.
1645 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
1646 Defeating Denial of Service Attacks which employ IP Source
1647 Address Spoofing", BCP 38, RFC 2827, May 2000.
1649 [RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
1650 IPv6 Hosts and Routers", RFC 2893, August 2000.
1652 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
1653 via IPv4 Clouds", RFC 3056, February 2001.
1655 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
1656 RFC 3068, June 2001.
1658 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
1659 "STUN - Simple Traversal of User Datagram Protocol (UDP)
1660 Through Network Address Translators (NATs)", RFC 3489,
1661 March 2003.
1663 [RFC3964] Savola, P. and C. Patel, "Security Considerations for
1664 6to4", RFC 3964, December 2004.
1666 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
1667 for IPv6 Hosts and Routers", RFC 4213, October 2005.
1669 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
1670 Internet Protocol", RFC 4301, December 2005.
1672 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
1673 Network Address Translations (NATs)", RFC 4380,
1674 February 2006.
1676 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
1677 (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
1678 RFC 4787, January 2007.
1680 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
1681 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
1682 September 2007.
1684 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
1685 Address Autoconfiguration", RFC 4862, September 2007.
1687 [RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H.
1688 Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels",
1689 RFC 4891, May 2007.
1691 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
1692 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
1693 March 2008.
1695 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
1696 "Session Traversal Utilities for NAT (STUN)", RFC 5389,
1697 October 2008.
1699 [RFC5572] Blanchet, M. and F. Parent, "IPv6 Tunnel Broker with the
1700 Tunnel Setup Protocol (TSP)", RFC 5572, February 2010.
1702 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
1703 Infrastructures (6rd) -- Protocol Specification",
1704 RFC 5969, August 2010.
1706 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
1707 Algorithm", RFC 6145, April 2011.
1709 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security
1710 Concerns with IP Tunneling", RFC 6169, April 2011.
1712 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
1713 Stack Lite Broadband Deployments Following IPv4
1714 Exhaustion", RFC 6333, August 2011.
1716 [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment",
1717 RFC 6343, August 2011.
1719 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
1720 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address
1721 Space", BCP 153, RFC 6598, April 2012.
1723 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
1724 "Default Address Selection for Internet Protocol Version 6
1725 (IPv6)", RFC 6724, September 2012.
1727 [RFC6732] Kuarsingh, V., Lee, Y., and O. Vautrin, "6to4 Provider
1728 Managed Tunnels", RFC 6732, September 2012.
1730 [RFC6751] Despres, R., Carpenter, B., Wing, D., and S. Jiang,
1731 "Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises
1732 Equipment (6a44)", RFC 6751, October 2012.
1734 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
1735 Locator/ID Separation Protocol (LISP)", RFC 6830,
1736 January 2013.
1738 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
1739 "Interworking between Locator/ID Separation Protocol
1740 (LISP) and Non-LISP Sites", RFC 6832, January 2013.
1742 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
1743 Protocol (LISP) Map-Server Interface", RFC 6833,
1744 January 2013.
1746 [SIXXS] Massar, J. and P. van Pelt, "IPv6 Deployment & Tunnel
1747 Broker", .
1749 [TERTST] Huston, G., "Testing Teredo", April 2011,
1750 .
1752 [TIC] SixXS, "Tunnel Information and Control protocol (TIC)",
1753 .
1755 [TR-069] The Broadband Forum, "CPE WAN Management Protocol",
1756 July 2011, .
1759 [TUNBROKER]
1760 Hurricane Electric, "Hurricane Electric Free IPv6 Tunnel
1761 Broker", .
1763 [TUNDISC] Colitti, L., Di Battista, G., and M. Patrignani, "IPv6-in-
1764 IPv4 tunnel discovery: methods and experimental results",
1765 IEEE eTransactions on Network and Service Management
1766 (eTNSM) vol. 1, no. 1, pag. 2-10, April 2004.
1768 Appendix A. Evaluation Criteria
1770 Each type of tunnel has specific advantages and disadvantages. We
1771 have considered the following points when evaluating the different
1772 protocols. Not every point is mentioned in each section where a
1773 protocol is described, only those that are specifically relevant to
1774 that protocol.
1776 Protocol overhead: How much overhead does the tunneling protocol
1777 cause? There are two factors that play a role: number of
1778 interactions to set up the tunnel and packet header size causing a
1779 lower MTU and/or fragmentation.
1781 Automatic configuration: Does this protocol require manual
1782 configuration at the endpoints?
1784 Predictability: How predictable is the functioning of the protocol?
1786 Single host or network: Is this protocol intended to be used by a
1787 single host or by a router that then provides IPv6 connectivity to
1788 multiple hosts?
1790 Load balancing: Does the tunnel traffic have enough entropy and/or
1791 hashability to be able to be load-balanced over multiple links, or
1792 do all tunnel packets have the same outer 5-tuple?
1794 Path stretch: Does the tunnel optimise the route, or is there a big
1795 potential for a much longer path when using the tunnel?
1797 NAT traversal: Can the tunnel pass through a NAT gateway, and does
1798 it require configuration on that NAT gateway?
1800 Tunnel endpoint mobility: Are the IPv4 addresses of the tunnel fixed
1801 or do they adjust automatically when an endpoint moves.
1803 State: Are the endpoints required to keep state for the tunnel or is
1804 the tunnel stateless?
1806 Network type: Is this network a point-to-point or NBMA type of
1807 network?
1809 Purpose: What is the intended purpose of this tunnel protocol?
1811 Related protocols: To which protocols is this tunnel protocol
1812 related? Are there alternatives?
1814 Implementations: Is this protocol supported on the major operating
1815 systems, routers and firewalls?
1817 Limitations: What are the known limitations of this protocol?
1819 Authors' Addresses
1821 Sander Steffann
1822 S.J.M. Steffann Consultancy
1823 Tienwoningenweg 46
1824 Apeldoorn, Gelderland 7312 DN
1825 The Netherlands
1827 Email: sander@steffann.nl
1828 Iljitsch van Beijnum
1829 Institute IMDEA Networks
1830 Avda. del Mar Mediterraneo, 22
1831 Leganes, Madrid 28918
1832 Spain
1834 Email: iljitsch@muada.com
1836 Rick van Rein
1837 OpenFortress
1838 Haarlebrink 5
1839 Enschede, Overijssel 7544 WP
1840 The Netherlands
1842 Email: rick@openfortress.nl