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