idnits 2.17.1 draft-steffann-tunnels-00.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 (February 15, 2013) is 4081 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** 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 6830 (Obsoleted by RFC 9300, RFC 9301) ** Obsolete normative reference: RFC 6833 (Obsoleted by RFC 9301) Summary: 10 errors (**), 0 flaws (~~), 2 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: August 19, 2013 Institute IMDEA Networks 6 R. van Rein 7 OpenFortress 8 February 15, 2013 10 A comparison of IPv6 tunneling mechanisms 11 draft-steffann-tunnels-00 13 Abstract 15 This document provides an overview of various ways to to tunnel IPv6 16 packets over IPv4 networks. It covers mechanisms in contemporary 17 use, touches on several mechanisms that are now only of historic 18 interest, and discusses some newer tunneling mechanisms that are not 19 (yet) widely used at the time of publication. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 19, 2013. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Tunnel Mechanisms . . . . . . . . . . . . . . . . . . . . . . 5 58 3.1. Configured Tunnels (Manual Tunnels / 6in4) . . . . . . . . 6 59 3.2. Automatic Tunneling . . . . . . . . . . . . . . . . . . . 7 60 3.3. IPv6 over IPv4 without Explicit Tunnels (6over4) . . . . . 8 61 3.4. Generic Routing Encapsulation (GRE) . . . . . . . . . . . 9 62 3.5. Connection of IPv6 Domains via IPv4 Clouds (6to4) . . . . 9 63 3.6. Anything In Anything (AYIYA) . . . . . . . . . . . . . . . 10 64 3.7. Intra-site Automatic Tunnel Addressing (ISATAP) . . . . . 11 65 3.8. Tunneling IPv6 over UDP through NATs (Teredo) . . . . . . 12 66 3.9. IPv6 Rapid Deployment (6rd) . . . . . . . . . . . . . . . 13 67 3.10. Native IPv6 behind NAT44 CPEs (6a44) . . . . . . . . . . . 14 68 3.11. Peer-to-Peer IPv6 on Any Internetwork (6bed4) . . . . . . 15 69 3.12. The Locator/ID Separation Protocol (LISP) . . . . . . . . 16 70 4. Related Protocols . . . . . . . . . . . . . . . . . . . . . . 17 71 4.1. Tunnel Information and Control protocol (TIC) . . . . . . 17 72 4.2. Tunnel Setup Protocol (TSP) . . . . . . . . . . . . . . . 18 73 4.3. Dual-Stack Lite (Softwire) . . . . . . . . . . . . . . . . 19 74 5. General Issues . . . . . . . . . . . . . . . . . . . . . . . . 19 75 5.1. Protocol 41 Encapsulation . . . . . . . . . . . . . . . . 19 76 5.2. NAT and Firewalls . . . . . . . . . . . . . . . . . . . . 20 77 5.3. MTU Considerations . . . . . . . . . . . . . . . . . . . . 21 78 5.4. IPv4 Addresses Embedded in IPv6 Addresses . . . . . . . . 22 79 6. Evaluation of Tunnel Mechanisms . . . . . . . . . . . . . . . 24 80 6.1. Efficiency of IPv4 Address Use . . . . . . . . . . . . . . 25 81 6.2. Supported Network Topologies . . . . . . . . . . . . . . . 26 82 6.3. Parties Involved in Tunnel Realisation . . . . . . . . . . 26 83 6.4. Robustness . . . . . . . . . . . . . . . . . . . . . . . . 28 84 6.5. Performance . . . . . . . . . . . . . . . . . . . . . . . 30 85 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 31 86 8. Security considerations . . . . . . . . . . . . . . . . . . . 31 87 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32 88 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 90 Appendix A. Evaluation Criteria . . . . . . . . . . . . . . . . . 35 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 93 1. Introduction 95 During the transition from IPv4 to IPv6, IPv6 islands are separated 96 by a sea of IPv4. Tunnels provide connectivity between these IPv6 97 islands. Tunnels work by encapsulating IPv6 packets inside IPv4 98 packets, as shown in the figure. 100 +---------------+ 101 | IPv4 | 102 | Header | 103 +---------------+ 104 +---------------+ : Optional : 105 | IPv6 | : Encapsulation : 106 | Header | : Header : 107 +---------------+ +---------------+ 108 | Transport | | IPv6 | 109 | Layer | ===> | Header | 110 | Header | +---------------+ 111 +---------------+ | Transport | 112 | | | Layer | 113 ~ Data ~ | Header | 114 | | +---------------+ 115 +---------------+ | | 116 ~ Data ~ 117 | | 118 +---------------+ 120 Encapsulating IPv6 in IPv4 122 Various tunnel mechanisms have been proposed over time. So many in 123 fact, that it is difficult to get an overview. 125 Some tunnel mechanisms have been abandoned by the community, others 126 have known problems and yet others have shown to be reliable. Some 127 tunnel mechanisms were designed with a particular use-case in mind, 128 others are generic. There may be documented limitations as well as 129 limitations that have cropped up in deployment. 131 This document provides an overview of available and/or noteworthy 132 tunnel mechanisms, with the intention to guide selection of the best 133 mechanism for a particular purpose. 135 As such, the discussion of the different tunnel mechanisms is limited 136 to the working principles of the different mechanisms and a few 137 important details. Please use the references to learn the full 138 details of each mechanism. The intended audience for this document 139 is everyone who needs a connection to the IPv6 internet at large, but 140 is not in the position to use native (untunneled) IPv6 connectivity, 141 and thus needs to select an appropriate tunneling mechanism. This 142 document is also intended as a quick reference to tunnel mechanisms 143 for the IETF community. 145 2. Terminology 147 Anycast: Mechanism to provide a service (in multiple locations) 148 using multiple servers by configuring each server with the same IP 149 address. 151 Dual stack: Also known as "dual IP layer". Nodes run IPv4 and IPv6 152 side by side, and can communicate with other dual stack nodes 153 (over either IPv4 or IPv6), as well as IPv4-only nodes (over IPv4) 154 and IPv6-only nodes (over IPv6). Most current operating systems 155 are set up to use IPv4 when available as well as use IPv6 when 156 available, allowing them to run in IPv4-only, IPv6-only or dual 157 stack mode as circumstances permit. Except for a few things 158 concerning the Domain Name System (DNS), there is no separate 159 specification for dual stack beyond the specifications relevant to 160 running IPv4 and IPv6. Dual stack is one of the three IPv4-to- 161 IPv6 transition tools; the others are translation and tunnels. 163 Encapsulation: Transporting packets as data inside another packet. 164 For instance, an IPv6 packet inside an IPv4 packet. 166 Host: A device that communicates using IP packets, but is not a 167 router. 169 ISP: Internet Service Provider; the party connecting the outside of 170 the local network's perimeter to the public Internet. 172 MTU: Maximum transmission Unit, the maximum size of a packet that 173 can be transmitted over a link (or tunnel) without splitting it 174 into multiple fragments. 176 NAT: Network Address Translation or Network Address Translator. NAT 177 makes it possible for a number of hosts to share a single IP 178 address. TCP and UDP port numbers are used to distinguish the 179 traffic to/from different hosts served by the NAT; protocols other 180 than TCP and UDP may be incompatible with NAT due to lack of port 181 numbers. NAT also breaks protocols that depend on the IP 182 addresses used in some way. 184 NBMA: Non-broadcast, multiple access. This is a network 185 configuration in which nodes can exchange packets directly by 186 addressing them at the desired destination. However, broadcasts 187 or multicasts are not supported, so autodiscovery mechanisms such 188 as IPv6 Neighbour Discovery don't work. 190 Node: A device that implements IP, either a host or a router; also 191 known as a system. 193 Path stretch: The difference between the shortest path through the 194 network and the path (tunneled) packets actually take. 196 PMTUD: Path MTU Discovery, a method to determine the MTU between two 197 systems where the traffic path may consist of multiple independent 198 links. There are separate standards for PMTUD over IPv4 [RFC1191] 199 and IPv6 [RFC1981]. 201 Router: A device that forwards IP packets that it didn't generate 202 itself. 204 System: A device that implements IP, either a host or a router; a 205 node. 207 Translation: The IPv6 and IPv4 headers are similar enough that it is 208 possible to translate between them. This allows IPv6-only hosts 209 to communicate with IPv4-only hosts. The original specification 210 for translating between IPv6 and IPv4, was heavily criticized by 211 the Internet Architecture Board, but new specifications for 212 translating between IPv6 and IPv4 were later published [RFC6145]. 213 Translation is of the three IPv4-to-IPv6 transition tools; the 214 others are dual stack and tunnels. 216 Tunnel: By encapsulating IPv6 packets inside IPv4 packets, IPv4- 217 capable hosts and IPv6-capable networks isolated from other IPv6- 218 capable systems or the IPv6 internet at large can exchange IPv6 219 packets over IPv4-only infrastructure. There are numerous ways to 220 tunnel IPv6 over IPv4. This document compares these mechanisms. 221 One of the three IPv4-to-IPv6 transition tools; the others are 222 translation and dual stack. 224 Tunnel broker: A service that provides tunneled connectivity to the 225 IPv6 internet, such as [SIXXS] and [TUNBROKER]. 227 3. Tunnel Mechanisms 229 Automatic tunnels (Section 3.2) 6over4 (Section 3.3), 6to4 230 (Section 3.5), ISATAP (Section 3.7) and 6rd (Section 3.9) solve 231 similar problems at different scales. They all encapsulate IPv6 232 packets immediately inside an IPv4 packet, without using additional 233 headers. This is called "protocol 41 encapsulation" (see 234 Section 5.1), as the Protocol field in the IPv4 header is set to 41 235 (decimal) to indicate that what follows is an IPv6 packet. 237 Each of these mechanisms also creates an IPv6 address for the host or 238 router running the protocol based on the system's IPv4 address in one 239 way or another (see Section 5.4). This lets 6to4, 6rd, ISATAP and 240 automatic tunnels determine the IPv4 destination address in the outer 241 IPv4 header from the IPv6 address of the destination, allowing for 242 automatic operation without the need to administratively configure 243 the remote tunnel endpoint. 245 6over4 and ISATAP provide IPv6 connectivity between IPv6-capable 246 systems within a single organisation's network that is otherwise 247 IPv4-only. 6rd allows ISPs to provide IPv6 connectivity to their 248 customers over IPv4-only last mile infrastructures. 6to4 directly 249 provides connectivity to the global IPv6 internet. 251 Configured tunnels (Section 3.1) also use protocol 41 encapsulation, 252 but rely on manual configuration of the remote tunnel endpoint. 253 Configured tunnels can be used within an organisation's network, but 254 are typically used by tunnel broker services to provide connectivity 255 to the IPv6 internet. GRE (Section 3.4) is similar to configured 256 tunnels, but also supports tunneling protocols other than IPv6. 258 AYIYA (Section 3.6) is similar to configured tunnels and GRE, but 259 typically uses a UDP header for better compatibility with NATs and is 260 generally used with TIC (Section 4.1) to set up the tunnel rather 261 than rely on manual configuration. Teredo (Section 3.8), 6a44 262 (Section 3.10) and 6bed4 (Section 3.11) are similar to 6to4, except 263 that they are designed to work through NATs by running over UDP. Of 264 these, Teredo assumes no ISP involvement and 6a44 does; and 6bed4 is 265 designed to work over direct IPv4 paths between peers. 267 LISP (Section 3.12) is a system for abstracting the identifying 268 function from the location function of IP addresses, which allows for 269 the use of IPv6 for the former and IPv4 for the latter. 271 Please refer to Section 5 for more information about issues common to 272 many tunnel mechanisms; those issues are not discussed separately for 273 each mechanism. The mechanisms are discussed in chronological order 274 of first publication below. 276 3.1. Configured Tunnels (Manual Tunnels / 6in4) 278 Configured and automatic tunnels are the two oldest tunnel 279 mechanisms, originally published in "Transition Mechanisms for IPv6 280 Hosts and Routers" [RFC1933] in 1996. The latest specification of 281 configured tunnels is "Basic Transition Mechanisms for IPv6 Hosts and 282 Routers" [RFC4213], published in 2005. The mechanism is sometimes 283 called "manual tunnels" or "6in4". 285 Configured tunnels connect two systems in point-to-point fashion. 286 The configuration that the name of the mechanism alludes to consists 287 of a remote "tunnel endpoint". This is the IPv4 address of the 288 system on the other side of the tunnel. When a system (potentially) 289 has multiple IPv4 addresses, the local tunnel endpoint address may 290 also need to be configured. 292 Due to their point-to-point nature, configured tunnels may carry 293 multicast packets. As such, Neighbour Discovery can in principle 294 operate over a configured tunnel. Configured tunnels use protocol 41 295 encapsulation. 297 The need to explicitly set up a configured tunnel makes them more 298 difficult to deploy than automatic mechanisms. However, because 299 there is a fixed, single remote tunnel endpoint, performance is 300 predictable and easy to debug. 302 In the early days it was not unheard for a small network to get IPv6 303 connectivity from another continent. This excessive path stretch 304 makes communication over short geographic distances much less 305 efficient because the distance travelled by packets may be larger 306 than the geographic distance by an order of magnitude or more. 308 Configured tunnels are widely implemented. Common operating systems 309 can terminate configured tunnels, as well as IPv6-capable routers and 310 home gateways. The mechanism is versatile, but is mostly used 311 between isolated smaller IPv6-capable networks and the IPv6 internet, 312 often through a "tunnel broker" such as tunnelbroker.net [TUNBROKER] 313 or SixXS [SIXXS]. Before the existence of 6rd (Section 3.9), 314 configured tunnels were also sometimes used by ISPs to connect their 315 IPv6-capable customers across IPv4-only access infrastructure. 317 [RFC4891] discusses the use of IPsec to protect the confidentiality 318 and integrity of IPv6 traffic exchanged over configured tunnels. 320 3.2. Automatic Tunneling 322 Automatic tunneling is described in [RFC2893], "Transition Mechanisms 323 for IPv6 Hosts and Routers", but removed in [RFC4213], which is an 324 update of RFC 2893. Configured tunnels (Section 3.1) are closely 325 related to automatic tunnels and are specified in RFCs 2893 and 4213, 326 too. Both use protocol 41 encapsulation. 328 Hosts that are capable of automatic tunneling use special IPv6 329 addresses: IPv4-compatible addresses. An IPv4-compatible IPv6 330 address consists of 96 zero bits followed by the system's IPv4 331 address. When sending packets to destinations within the IPv4- 332 compatible ::/96 prefix, the IPv4 destination address in the outer 333 IPv4 header is taken from the IPv4 address in the IPv4-compatible 334 IPv6 destination address. 336 Automatic tunneling has a big limitation: it only allows for 337 communication between IPv6-capable systems that both support 338 automatic tunneling. There are no provisions for communicating with 339 the native IPv6 internet. As such, the mechanism is of almost no 340 practical use and is not implemented in current operating systems, as 341 6to4 (Section 3.5) does what automatic tunneling was supposed to do, 342 but also provides connectivity to the rest of the IPv6 internet. 344 3.3. IPv6 over IPv4 without Explicit Tunnels (6over4) 346 [RFC2529], "Transmission of IPv6 over IPv4 Domains without Explicit 347 Tunnels", was published in 1999. It's commonly known as "6over4". 349 6over4 is designed to work within a single organization's IPv4 350 network, where IPv6-capable hosts and routers are separated by IPv4- 351 only routers. 6over4 treats the IPv4 network as a "virtual Ethernet" 352 for the purpose of IPv6 communication. It uses IPv4 multicast to 353 tunnel IPv6 multicast packets. A node's IPv4 address is included in 354 the Interface Identifier used on the virtual 6over4 interface, 355 allowing the exchange of protocol 41 encapsulated packets between 356 6over4 nodes without prior administrative configuration. 358 Because multicast is supported, standard IPv6 Neighbour Discovery and 359 Stateless Address Autoconfiguration [RFC4862] can be used. Although 360 like automatic tunnels (Section 3.2) and other mechanisms, 6over4 361 embeds the IPv4 address of the host is in the IPv6 address, the 362 destination IPv4 address in the outer IPv4 header is *not* derived 363 from the IPv6 address embedded in the inner IPv6 header, but learnt 364 through Neighbour Discovery [RFC4861]. In effect, the IPv4 addresses 365 of the hosts are used as link-layer addresses, in the same way that 366 MAC addresses are used on Ethernet networks. 368 One or more routers with connectivity to the global IPv6 internet 369 send out Router Advertisements to provide 6over4 hosts with 370 connectivity to the rest of the IPv6 internet. 372 6over4 has the minimal protocol 41 encapsulation overhead and doesn't 373 require manual configuration. 6over4 operation is stateless and peer- 374 to-peer communication is supported within the IPv4 domain. Hosts can 375 only take advantage of 6over4 if they run the mechanism themselves. 376 6over4 packets can't pass through a NAT successfully, as the IPv4 377 address exchanged through Neighbour Discovery will be different from 378 the one needed to reach the host in question, and because without 379 port numbers, protocol 41 doesn't allow for multiplexing multiple 380 hosts using this encapsulation behind a single IPv4 address. 381 However, 6over4 works within IPv4 domains that use [RFC1918] 382 addressing. 384 Because of its reliance on IPv4 multicast and because local IPv6 385 communication is relatively easy to facilitate using IPv6 routers, 386 6over4 is not supported in current operating systems, and should be 387 considered obsolete. ISATAP (Section 3.7) provides very similar 388 functionality without requiring IPv4 multicast capability, and is 389 implemented in more operating systems. 391 3.4. Generic Routing Encapsulation (GRE) 393 Generic Routing Encapsulation (GRE) [RFC2784] is a generic point-to- 394 point tunneling mechanism that allows many other protocols to be 395 encapsulated in IP. 397 GRE is a simple protocol which is similar to 6in4 (Section 3.1) when 398 used for IPv6-in-IPv4 tunneling. The main benefit of GRE is that is 399 can not only encapsulate IPv6 packets but any protocol. The GRE 400 header causes an extra overhead of 8 to 16 bytes depending on which 401 options are used. GRE sets the Protocol field in the IP header to 47 402 (decimal). 404 The GRE header can optionally contain a checksum, a key to separate 405 different traffic flows (for example different tunnels) between the 406 same end points and a sequence number that can be used to prevent out 407 of order packets to arrive. 409 GRE is implemented in many routers, but not in most consumer-level 410 home gateways or desktop operating systems. 412 3.5. Connection of IPv6 Domains via IPv4 Clouds (6to4) 414 6to4 is specified in "Connection of IPv6 Domains via IPv4 Clouds" 415 [RFC3056]. It creates a block of IPv6 addresses from a locally 416 configured IPv4 address by concatenating that IPv4 address to the 417 prefix 2002::/16, resulting in a /48 IPv6 prefix. Addresses in 418 2002::/16 are considered reachable through the tunnel interface, so 419 the 6to4 network functions as a non-broadcast, multiple access (NBMA) 420 network through which 6to4 users can communicate. IPv6 packets are 421 encapsulated by adding an IPv4 header with the Protocol field set to 422 41 (decimal). 424 The /48 prefix allows a single system running 6to4 to act as a 425 gateway or router for a large number of IPv6 hosts. Alternatively, 426 an individual host may run 6to4 and not act as a gateway or router. 428 The system running 6to4 must have a globally reachable IPv4 address. 429 Using a private IPv4 address [RFC1918] for 6to4 is not possile. 431 "An Anycast Prefix for 6to4 Relay Routers" [RFC3068] specifies an 432 anycast mechanism for 6to4 relays that provide connectivity between 433 the 6to4 network and the regular IPv6 internet. All public relays 434 share the IPv4 address 192.88.99.1, which corresponds to 2002:c058: 435 6301::. Relays advertise reachability towards 2002::/16 towards the 436 native IPv6 internet, so packets addressed to systems using 6to4 437 addresses are routed to the closest gateway. The gateway 438 encapsulates these packets and forwards them to the IPv4 address 439 included in the IPv6 address. Systems running 6to4 have a default 440 route pointing to 2002:c058:6301::, so they tunnel packets addressed 441 to non-6to4 IPv6 destinations to the closest relay, which 442 decapsulates the packet and forwards them as IPv6 packets 444 The 6to4 protocol adds minimal tunneling overhead (just the IPv4 445 header) and requires no manual configuration from the users. The 446 biggest problem specific to 6to4 is that it is unpredictable which 447 6to4 anycast relay is used. These relays are often provided by third 448 parties on a best-effort basis and do not always have enough 449 bandwidth available. Traffic from the 6to4 network to the regular 450 IPv6 internet will likely use a different 6to4 relay than the traffic 451 in the opposite direction. If either of those relays is not reliable 452 then the communication between those networks becomes unreliable. 453 Especially the lack of control over the relay used for return traffic 454 is considered to be a problem with 6to4. 456 For more information about 6to4, see the "Advisory Guidelines for 457 6to4 Deployment" [RFC6343]. 459 *Warning*: 461 Although many, if not all, 6to4 implementations disable the mechanism 462 when the system only has an RFC 1918 address, recently a block of 463 IPv4 address has been set aside for use in service provider operated 464 Network Address Translators, also known as Carrier Grade NAT (CNG). 465 [RFC6598] sets aside the block 100.64.0.0/10 for the use between CGNs 466 and subscriber devices. As 100.64.0.0/10 is not an RFC 1918 address 467 block, systems implementing 6to4 may fail to disable the mechanism, 468 but due to the shared nature of the 100.64.0.0/10 prefix, 6to4 cannot 469 work using these addresses. 471 3.6. Anything In Anything (AYIYA) 473 [AYIYA] is designed for use by the [SIXXS] tunnel broker service. An 474 Internet Draft was submitted [I-D.massar-v6ops-ayiya] but the process 475 to make it an RFC was never completed. 477 The AYIYA protocol defines a method for encapsulating any protocol in 478 any other protocol. The most common way of deploying AYIYA is to use 479 the following sequence of headers: IPv4-UDP-AYIYA-IPv6, although 480 other combinations like IPv4-AYIYA-IPv6 or IPv6-SCTP-AYIYA-IPv4 are 481 also possible. The draft does not limit the contents nor the 482 protocol that carries the AYIYA packets. In this document we only 483 look at the most common usage (IPv4-UDP-AYIYA-IPv6) which is deployed 484 on the SixXS tunnel brokers to provide IPv6 access to clients behind 485 NAT devices. 487 AYIYA specifies the encapsulation, identification, checksum, security 488 and certain management operations that can be used once the tunnel is 489 established. It does not specify how the tunnel configuration 490 parameters can be negotiated. Typically, the TIC protocol described 491 in Section 4.1 protocol is used for that part of the tunnel setup, 492 although the TSP protocol described in [RFC5572] could be used as 493 well. 495 AYIYA provides a point-to-point tunnel, over which the endpoints can 496 route traffic for any source and destination. When using SHA-1 497 hashing for authentication, as is common when using the AICCU client 498 with a SixXS tunnel server, the total packet overhead is 72 bytes (20 499 for the IPv4 header, 8 for UDP and 44 for AYIYA). 501 AYIYA provides operational commands for querying the hostname, 502 address, contact information, software version and last error 503 message. An operational command to ask the other side of the tunnel 504 to shut down is also available. These commands in the protocol can 505 make debugging of AYIYA tunnels easier if the tools support them. 507 The main advantage of AYIYA is that it can provide a stable tunnel 508 through an IPv4 NAT, and possibly multiple layers of NAT. The UDP 509 port numbers allow multiple AYIYA users to reside behind a NAT. The 510 client will contact the tunnel server at regular intervals and the 511 tunnel server will automatically adapt to changing IPv4 addresses 512 and/or UDP port numbers. The clients can be tracked through an 513 (optional) identity field and (also optional) signature field. A 514 timestamp is included in the AYIYA header to guard against replay 515 attacks. 517 The main downside is that this protocol only seems to be in use by 518 the [SIXXS] tunnel broker service and the [AICCU] client software. 520 3.7. Intra-site Automatic Tunnel Addressing (ISATAP) 522 ISATAP [RFC5214] uses protocol 41 encapsulation, to provide 523 connectivity between isolated IPv6-capable nodes within an 524 organisation's internal network. It is similar to 6over4 525 (Section 3.3), but without the requirement that the IPv4 network 526 supports multicast. Unlike 6over4, ISATAP uses a Non-Broadcast 527 Multiple Access (NBMA) communication model and thus doesn't support 528 multicasts. The mechanism assigns IPv6 addresses whose interface 529 identifier is solely defined by a node's IPv4 address, which is 530 assumed to be unique. 532 In order to obtain a /64 prefix, an ISATAP tunnel endpoint needs to 533 send a Router Solicitation. Without the ability to send and receive 534 IPv6 multicasts, an ISATAP host must be configured with a Potential 535 Router List through an all-IPv4 mechanism, such as manual setup, DHCP 536 or the DNS. Site administrators are encouraged to use a DNS Fully 537 Qualified Domain Name using the convention "isatap.domainname" (e.g., 538 isatap.example.com). Hosts will accept packets with IPv4 sender 539 addresses that are either on the Potential Router List, or that are 540 embedded in the IPv6 sender address. 542 The router's prefix and the IPv4 address together define the IPv6 543 address for the ISATAP interface. This means that precisely one 544 ISATAP address is available for each IPv4 address. As such, each 545 host needs to run ISATAP itself in order to enjoy ISATAP IPv6 546 connectivity. The IPv4 address in the destination IPv6 address is 547 used to bootstrap Neighbour Discovery. 549 [RFC5214] doesn't explicitly address the use of ISATAP using private 550 [RFC1918] addresses. Despite that, the mechanism seems compatible 551 with private addresses. NAT, however, breaks the relationship 552 between the IPv4 address embedded in the IPv6 address and would 553 therefore make communication between ISATAP hosts impossible. Any 554 device that can communicate with the ISATAP hosts over IPv4 using 555 protocol 41 can participate in the IPv6 subnet. It is therefore 556 important to filter protocol 41 traffic at the network edge when NAT 557 is not in use. 559 ISATAP is available in Windows as well as Linux. It is not 560 recommended [ISATAP-WIN] for production networks running Windows if 561 native IPv6 is available. 563 3.8. Tunneling IPv6 over UDP through NATs (Teredo) 565 Teredo [RFC4380] [RFC5991] [RFC6081] is designed as an automatic 566 tunnel mechanism of last resort. It can configure an IPv6 address 567 behind most NAT routers, but not all. Because Teredo uses 568 encapsulation in UDP, multiple Teredo clients can be simultaneously 569 active behind the same NAT router. For each Teredo client, a single 570 IPv6 address is then created at the expense of a single external UDP 571 port. 573 The operation of Teredo is based on a classification of NAT [RFC3489] 574 as established during an interaction with a Teredo server. This 575 classification has since been obsoleted [RFC5389] because it suggests 576 more certainties about NAT than achieved in reality. Teredo however, 577 relies on facilities induced from this classification, specifically 578 the assumption that any NAT which is not classified as Symmetric NAT 579 can receive a Teredo address because an external Teredo relay would 580 be able to reach the Teredo client on the same external UDP port. 581 This relay is selected near a native IPv6 destination address, so it 582 must be dynamically switched during operation. 584 Teredo is present in Windows XP and later, and is enabled by default 585 in Windows Vista and later. However, Windows will only use Teredo 586 connectivity as a way to connect to IPv6 destinations of last resort, 587 if no other IPv6 connectivity is present, Windows will not even look 588 up AAAA records when resolving domain names. An open source 589 implementation named Miredo exists for other platforms. This means 590 that Teredo is only used to connect to explicit IPv6 addresses 591 obtained through another mechanism than DNS. 593 The performance of Teredo falls noticeably short of that of IPv4. 594 The setup time of a connection involves finding a Teredo relay nearby 595 the native address to wrap and unwrap the traffic, and finding this 596 relay can take in the order of seconds. This process is not 597 sufficiently reliable; Teredo fails in about 37% [TERTST] of its 598 attempts to connect to such native IPv6 peers. The roundtrip time of 599 traffic can add tenths of a second, and jitter generally worsens if 600 it is dependent on a public relay. 602 Teredo clients need to be configured with a Teredo server when 603 setting up their local IPv6 address and when initiating a connection 604 to a native IPv6 destination. The hostnames of the Teredo servers 605 are usually pre-configured by the vendor of the Teredo 606 implementation. All Microsoft Windows implementation use Teredo 607 servers provided by Microsoft by default. 609 3.9. IPv6 Rapid Deployment (6rd) 611 6rd is specified in [RFC5969]. The original idea and the name come 612 from [RFC5569] which described a successful "rapid deployment" of 613 IPv6 by a commercial service provider. 6rd is used by service 614 providers to connect customer networks behind a CPE to the IPv6 615 internet. 617 The structure of the 6rd protocol is based on 6to4 and it has the 618 same minimal overhead as all protocols that use protocol 41 619 encapsulation. The main differences between 6rd and 6to4 are that 620 6rd is meant to be used inside a service provider's network and does 621 not use a special IPv6 prefix but one or more prefixes routed to the 622 service provider. As such, 6rd users aren't recognisable by their 623 IPv6 address like 6to4 users are. Where 6to4 uses (often public) 624 relays based on global anycast routing 6rd uses relays provided and 625 maintained by the service provider. Because of this architecture the 626 tunnel does not traverse unknown networks which makes any debugging 627 much easier. 629 6rd is completely stateless once it is configured. The tunnel 630 endpoints can therefore be deployed using anycast. This is commonly 631 done for the 6rd border relays deployed by the service provider to 632 provide redundancy. 634 Because of the different prefix the device used as the 6rd client 635 cannot use the hard-coded IPv6 prefix calculation and relay addresses 636 of 6to4. Instead, the 6rd client needs to receive configuration 637 information to work. In principle 6rd nodes may be configured in a 638 variety of ways, but the most common one being through DHCP. If the 639 client receives its IPv4 address from a DHCPv4 server then the 6rd 640 configuration can be included in the DHCP message exchange using the 641 6rd DHCPv4 Option defined in [RFC5969]. Manual configuration of 6rd 642 options and configuration using [TR-069] is also possible. 644 The main advantage of using 6rd is that it allows service providers 645 to deploy IPv6 on core networks that for some reason cannot provide 646 native IPv6 connectivity. It does not share the lack of predictable 647 routing that 6to4 suffers from, because all routing, encapsulation 648 and de-encapsulation is done by the service provider. 650 A disadvantage of 6rd for clients is that 6rd is only available when 651 a service provider provides the relays and address space. 653 3.10. Native IPv6 behind NAT44 CPEs (6a44) 655 Inspired on Teredo, the 6a44 tunnel is described in "Native IPv6 656 behind IPv4-to-IPv4 NAT Customer Premise Equipment (6a44)" [RFC6751]. 657 Its purpose is to enable Internet Service Providers to establish IPv6 658 connectivity for their customers, in spite of the use of a CPE or 659 home gateway that is not prepared for IPv6. The infrastructure 660 required for this is a 6a44 relay in the ISP's network and a 6a44 661 client in the customer's internal network. 663 6a44 was explicitly designed to overcome the noted problems with 664 Teredo. Where Teredo was designed as a global solution without 665 dependency on ISP co-operation, the 6a44 tunnel explicitly assumes 666 ISP co-operation. Instead of using Teredo's well-known prefix, a /48 667 prefix out of the ISP's address space is used. A well-known 668 (anycast) IPv4 address has been assigned for the 6a44 relay to be run 669 inside the ISP network without client configuration. This well-known 670 address is allocated from the same IPv4 /24 as 6to4. 672 As part of its bootstrapping, a 6a44 client requests an address from 673 the 6a44 relay, and a regular keepalive sent by the 6a44 client to 674 the 6a44 relay keeps mapping state in NATs and firewalls on the path 675 alive. Traffic passed from the native IPv6 internet to 6a44 is 676 encapsulated in UDP and IPv4 by the relay and decapsulated by the 677 6a44 client; the opposite is done in the other direction. 679 The 6a44 protocol is very new, so it is not possible yet to give an 680 overview of its operational impact. One detail that could be a cause 681 for some concern is that the IPv6 addresses do not use the customary 682 EUI-64 flags that normally signal a local address assignment 683 strategy. 685 3.11. Peer-to-Peer IPv6 on Any Internetwork (6bed4) 687 The 6bed4 tunnel is specified in "6bed4: Peer-to-Peer IPv6 on Any 688 Internetwork" [6BED4]. Unlike point-to-point tunneling mechanisms 689 such as configured tunnels and AYIYA, 6bed4 also allows for direct 690 communication between peers, similar to 6to4 and Teredo. The intent 691 is to equal performance level of IPv4. It is currently an NBMA 692 protocol; multicast may be supported in the future. 694 The setup of 6bed4 is reminiscent of 6to4, except that it employs UDP 695 so it can be used behind NAT. It also has elements found in Teredo, 696 but without a need to classify NAT and induce behaviour from that. 697 The 6bed4 assumptions of NAT routers come down to plain vanilla UDP 698 support. Given this, 6bed4 can create reliable IPv6 transports. 700 In environments where direct connections between 6bed4 peers is 701 possible, additional path stretch compared to IPv4 communication is 702 avoided, so 6bed4 performance comes close to IPv4 performance. In 703 situations where this is not possible run over a the direct path 704 between two peers because a NAT that does not conform to [RFC4787] is 705 on the path, a fallback to a relay server is used. This increases 706 path stretch and affects scalability through its impact on roundtrip 707 times and jitter. 709 Another area where the relay is needed, is for connectivity between 710 6bed4 peers and native IPv6 hosts. For reasons of performance and 711 scalability, connections between 6bed4 peers are preferred over 712 connections between a 6bed4 peer and a native IPv6 host. A default 713 address exists to support zero-config operation, but it is possible 714 to send traffic out through a locally configured relay, which then 715 also defines the relay for the return path. 717 6bed4 is the only tunnel today that is suitable for interactive media 718 streams, provided that all media endpoints implement 6bed4, and 719 prefer 6bed4-to-6bed4 traffic over 6bed4-to-native traffic. Under 720 that premisse, the only hosts that need to go through a relay server 721 are those that are behind a NAT with Address-Dependent Mapping or 722 Address and Port-Dependent Mapping. 724 3.12. The Locator/ID Separation Protocol (LISP) 726 The Locator/ID Separation Protocol (LISP) [RFC6830] is a protocol to 727 separate the identity of systems from their location on the internet 728 and/or internal network. The addresses of the systems are called 729 Endpoint Identifiers (EIDs) and the addresses of the gateways are 730 called Routing Locators (RLOCs). It is possible to use IPv6 EIDs 731 with IPv4 RLOCs and thereby use LISP for tunneling IPv6 over IPv4. 733 LISP defines its own packet formats for encapsulation of data packets 734 and for control messages. All such packets are then encapsulated in 735 UDP. Data packets use port 4341 and control packets use port 4342. 737 The LISP standard consists of several RFC documents. The relevant 738 ones for this document are the basic standard [RFC6830], Interworking 739 between Locator/ID Separation Protocol (LISP) and Non-LISP Sites 740 [RFC6832] and the Locator/ID Separation Protocol (LISP) Map-Server 741 Interface [RFC6833]. 743 +----+ +----+ 744 | MS | | MR | 745 +----+ +----+ +-----+ /-----------\ 746 | | /---| xTR |---| LISP site | 747 +------+ /------------\---/ +-----+ \-----------/ 748 | PxTR |---| IP network | 749 +------+ \------------/---\ +-----+ /-----------\ 750 | \---| xTR |---| LISP site | 751 /---------------\ +-----+ \-----------/ 752 | Non-LISP site | 753 \---------------/ 755 An example of a LISP deployment 757 LISP introduces new terminology and new concepts. The relevant ones 758 for this document are: 760 ITR: Ingress Tunnel Router, a router encapsulating data packets at 761 the border of a LISP site 763 ETR: Egress Tunnel Router, a router decapsulating data packets at 764 the border of a LISP site 766 xTR: A router performing both the ITR and the ETR functions 768 PITR: Proxy ITR, a router accepting traffic from non-LISP sites, 769 encapsulating it and tunneling it to the LISP sites 771 PETR: Proxy ETR, a router accepting traffic from LISP sites to send 772 it to non-LISP sites 774 PxTR: A router performing both the PITR and the PETR functions 776 MS: Map Server, a server accepting RLOC registrations from ETRs 778 MR: Map Resolver, a server that can resolve queries for RLOCs from 779 ITRs 781 LISP ETRs register the EID prefixes that they can handle traffic for 782 in one or more Map Servers. ITRs and PITRs can then query Map 783 Resolvers to determine which RLOCs to use when sending traffic to a 784 LISP site. PITRs advertise aggregates of EID prefixes to the global 785 routing table and provide tunneling services for them so that non- 786 LISP sites can reach LISP sites. PETRs provide a way for LISP sites 787 to send traffic to non-LISP sites. 789 LISP is a complex protocol if only used for tunneling. What it 790 provides additionally is that ETRs can advertise their own RLOC 791 addresses, that one site can have multiple xTRs with independent 792 RLOCs and that the LISP site administrator can specify priorities and 793 weights for those RLOCs. This provides redundancy and explicit load 794 balancing between RLOCs. It also provides automatic tunneling 795 between different sites without using a PxTR if both sites use Map 796 Servers and Map Resolvers that are interconnected, for example by 797 participating in the LISP Beta Network [LISPBETA]. 799 4. Related Protocols 801 The following protocols are not tunneling mechanisms but they can be 802 used in the configuration and/or setup phase of such protocols, or 803 are otherwise relevant in the context of IPv6-in-IPv4 tunneling. 805 4.1. Tunnel Information and Control protocol (TIC) 807 The Tunnel Information and Control protocol (TIC) protocol [TIC] is a 808 proprietary protocol for the [SIXXS] tunnel broker service. 810 With the TIC protocol a tunnel broker user can request a list of 811 available tunnels and points-of-presence (POPs) from the tunnel 812 broker service. When the user chooses one of the tunnels the 813 configuration parameters for that tunnel can then be requested 814 through TIC. 816 Authentication of users is done based on username and password. The 817 only operational complexity is that a TIC node must have time 818 synchronisation because TIC uses timestamps to avoid replay attacks. 820 4.2. Tunnel Setup Protocol (TSP) 822 The Tunnel Setup Protocol [RFC5572] is an experimental protocol for 823 negotiating the setup of a variety of tunneling encapsulations. In 824 this document we are only interested in the encapsulation of IPv6 in 825 IPv4. The Tunnel Setup Protocol can negotiate these as a protocol 41 826 encapsulated tunnel or as a UDP encapsulated tunnel. 828 Tunnel negotiation is done with an XML exchange over UDP or TCP. The 829 transport used for doing so may also be used as the IPv6 transport, 830 but tunnel negotiation packets are marked to be distinguished. 832 When run over UDP, all general remarks for UDP-based tunnels apply. 833 However, since a client exchanges all IPv6 traffic with the same 834 tunnel server, there are no concerns related to the NAT 835 implementation. The only concern is to send regular keepalives, for 836 which ICMPv6 ping messages to the tunnel server are suggested. 838 When run directly over IPv4, all protocol 41 limitations apply. As 839 such, the use of UDP is suggested unless there is a reason to prefer 840 protocol 41 encapsulation. 842 However, the Tunnel Setup Protocol negotiates the IPv4 address of a 843 client, but not its protocol and port. This is appropriate when 844 protocol 41 is used, but for UDP it creates a situation where 845 multiple users behind a NAT can claim the same tunnel access 846 privileges. This is especially easy if v6anyv4 is negotiated over 847 TCP. We therefore advise that clients should not use TCP for tunnel 848 negotiation, and that servers should offer neither v6anyv4 nor 849 v6udpv4 tunneling capabilities over TCP. 851 There are various security considerations related to TSP that are not 852 mentioned in its RFC. A server supplies each client with an IPv6 853 address to use. The specification does not express concerns about 854 tracking the relation between a client and their allocated IPv6 855 address; this is especially a concern when the IPv6 addresses are 856 dynamically assigned. 858 Open source client software for the Tunnel Setup Protocol is 859 available from the specification authors' freenet6 tunnel service. 860 The same authors have not published a server in open source. A 861 later, independent open source server implementation is incompatible 862 with the clients because these clients do not adhere to the 863 specification. 865 A public tunnel infrastructure is available by the name of gogo6, 866 once again from the specification authors. As is common with 867 centralised public tunnel infrastructure, this demonstrates the 868 problem of scalability. 870 4.3. Dual-Stack Lite (Softwire) 872 Dual-Stack Lite [RFC6333], developed by the IETF Softwire working 873 group, often comes up in discussions about IPv6 tunneling. However, 874 Dual-Stack Lite (DS-Lite) is _not_ an IPv6-in-IPv4 tunneling 875 mechanism; it is an IPv4-in-IPv6 tunneling mechanism. 877 DS-Lite allows ISPs to provide IPv4 connectivity over an IPv6-only 878 access infrastructure. To this end, DS-Lite-capable home gateways 879 encapsulate IPv4 packets inside IPv6 and forward them to a Carrier 880 Grade NAT (CGN/CGNAT) device operated by the ISP. The CGN 881 decapsulates the IPv4 packets, NATs them, and forwards them to the 882 IPv4 internet. 884 IPv6 packets are handled through native IPv6 mechanisms and not 885 tunneled. 887 5. General Issues 889 The following are aspects common to many or all tunneling mechanisms. 891 5.1. Protocol 41 Encapsulation 893 The most straightforward way to encapsulate an IPv6 packet inside an 894 IPv4 packet is by simply adding an IPv4 header in front of the IPv6 895 header. In this case, the protocol field in the IPv4 header is set 896 to the value 41 (decimal). 898 This simple protocol 41 encapsulation is used by a number of tunnel 899 mechanisms: 901 configured tunnels (Section 3.1) 903 automatic tunneling (Section 3.2) 905 6over4 (Section 3.3) 907 6to4 (Section 3.5) 909 ISATAP (Section 3.7) 911 6rd (Section 3.9) 913 5.2. NAT and Firewalls 915 It is not uncommon for firewalls to block protocol 41 encapsulated 916 packets, especially at the boundary between an organisation's 917 internal network and the public internet. Non-proto-41 tunneling 918 mechanisms typically employ a UDP header, and are somewhat less 919 likely to be filtered. 921 Although protocol 41 can in principle work through NAT, there are two 922 issues. First, when the IPv6 address is derived from the IPv4 923 address (see Section 5.4), NATting of the outer IPv4 header breaks 924 the relationship between the IPv4 and IPv6 addresses. Second, 925 because protocol 41 doesn't have any port numbers, only a single 926 protocol 41 tunnel endpoint can be supported behind a NAT device with 927 one IPv4 address (see Section 6.1). This limitation also applies to 928 GRE. 930 Tunnels that pass through a NAT device or stateful firewall need to 931 generate traffic at regular intervals to refresh the NAT or firewall 932 mapping. If the mapping is lost, tunneled packets from the outside 933 won't be able to pass through the NAT/firewall until a system behind 934 the NAT or firewall sends a tunneled packet and the mapping is 935 recreated. Alternatively, a static mapping (often in the form of a 936 "default" or "DMZ" host) may be created. 938 The following tunneling mechanisms are incompatible with NAT: 940 automatic tunneling (Section 3.2) 942 6to4 (Section 3.5) 944 6rd (Section 3.9) 946 Note that it is common to run 6to4 or 6rd on a home gateway device 947 that also performs IPv4 NAT. In this configuration, NAT is not 948 applied to tunneled packets, so NAT and 6to4/6rd can coexist. 950 The following tunneling mechanisms cannot operate between nodes on 951 opposing sides of a NAT, but they do work if _all_ nodes are behind a 952 NAT and use RFC 1918 addresses: 954 6over4 (Section 3.3) 956 ISATAP (Section 3.7) 958 The following tunneling mechanisms may work through NAT in some 959 circumstances, but are not designed for NAT compatibility: 961 configured tunnels (Section 3.1) 963 GRE (Section 3.4) 965 The following tunneling mechanisms are designed for NAT 966 compatibility: 968 AYIYA (Section 3.6) 970 Teredo (Section 3.8) 972 6a44 (Section 3.10) 974 6bed4 (Section 3.11) 976 TODO: 978 LISP (Section 3.12) 980 A tunnel built over UDP makes a claim on a resource, namely an 981 external UDP port. This may impact how well a tunnel will scale in 982 an organisation; for instance, if every desktop runs its own tunnel 983 client over UDP then the claim on this resource may have some impact. 985 Note that ISPs may have multiple subscribers share a public IPv4 986 address by performing NAT (Carrier Grade NAT, CGN or CGNAT in this 987 context). In this case, the subscribers' home gateways may receive 988 an address in the 100.64.0.0/10 block [RFC6598]. For the purposes of 989 tunnling mechanisms, this address block is similar to the [RFC1918] 990 address blocks. However, NAT/RFC1918 aware tunnel implementations 991 may not recognise 100.64.0.0/10 as non-public addresses and fail to 992 operate successfully. 994 5.3. MTU Considerations 996 Because of the the extra IPv4 header and possible additional headers 997 between the IPv4 and IPv6 headers, tunnels experience a reduced 998 maximum packet size (Maximum Transfer Unit, MTU) compared to native 999 IPv6 communication. 1001 Path MTU discovery (PMTUD) should handle this in nearly all cases, 1002 but filtering of ICMPv6 "packet too big" messages may lead to an 1003 inability to communicate because senders of large packets fail to 1004 perform PMTUD successfully. However, when a tunnel terminates 1005 directly on the host using it, the TCP maximum segment size (MSS) 1006 option communicates the maximum packet size to the remote endpoint 1007 without relying on PMTUD. 1009 With tunneling mechanisms where the MTU is left unspecified, it is 1010 not uncommon for the two endpoints to have different MTUs: typically, 1011 one uses the IPv6 minimum, 1280, while the other uses the physical 1012 MTU minus tunnel overhead, often 1480. In theory, this should lead 1013 to PMTUD failures because the "big" side unknowingly sends packets 1014 that the "small" side can't handle. However, in practice 1015 implementations handle incoming packets larger than their own MTU 1016 without issue. 1018 Only when the IPv4 MTU is reduced below 1500 bytes, for instance when 1019 using PPP over Ethernet (PPPoE, [RFC2516]), issues are more likely to 1020 arise. With this in mind, it is prudent to set the MTU of a tunnel 1021 to no more than 1472 bytes, so tunneled packets can be transported 1022 over PPPoE links without fragmentation, or even 1280, to accommodate 1023 possible additional overhead. 1025 5.4. IPv4 Addresses Embedded in IPv6 Addresses 1027 Many tunneling mechanisms embed IPv4 addresses in the IPv6 addresses 1028 they use. There are two possible reasons for this. First, because 1029 the IPv4 address that needs to go in the outer IPv4 header can be 1030 derived from the destination IPv6 address, there is no need to 1031 explicitly configure tunnel endpoints. Automatic tunneling, 6to4, 1032 ISATAP and Teredo do this. 6over4 doesn't, but still embeds the IPv4 1033 address in the interface identifier, and thus the IPv6 address, 1034 because that way, a (presumably) globally unique interface identifier 1035 can be generated. 1037 Automatic tunneling uses IPv4-compatible addresses in the prefix 1038 ::/96 (i.e., the first 96 bits are all zero). 1040 | 96 bits | 32 | 1041 +------------------------------------------------+-----------------+ 1042 | 0:0:0:0:0:0 | IPv4 address | 1043 +------------------------------------------------+-----------------+ 1045 The IPv4-compatible addresses structure 1047 Systems running 6to4 have addresses in the 6to4 prefix 2002::/16. 1049 | 16 | 32 | 16 | 64 bits | 1050 +--------+-----------------+--------+------------------------------+ 1051 | 2002 | IPv4 address | Subnet | Interface ID | 1052 +--------+-----------------+--------+------------------------------+ 1054 The 6to4 address structure 1056 Because a 6rd domain might share a common IPv4 prefix it is not 1057 always necessary to encode all 32 bits of the IPv4 address in the 6rd 1058 delegated prefix. The bits that become available because of this 1059 optimisation can be used to provide more subnet IDs to the user 1060 and/or to use a smaller address block for the 6rd prefix. 1062 | n bits | o bits | m bits | 128-n-o-m bits | 1063 +---------------+--------------+-----------+-----------------------+ 1064 | 6rd prefix | IPv4 address | subnet ID | interface ID | 1065 +---------------+--------------+-----------+-----------------------+ 1066 |<--- 6rd delegated prefix --->| 1068 The 6rd address structure 1070 6over4 uses the IPv4 address to generate a 64-bit Interface 1071 Identifier, which can then be used to create a 128-bit IPv6 address 1072 through Stateless Autoconfiguration. 1074 | 48 bits | 16 | 32 | 32 | 1075 +---------------------+--------+-----------------+-----------------+ 1076 | Organisation prefix | Subnet | 0:0 | IPv4 address | 1077 +---------------------+--------+-----------------+-----------------+ 1079 The 6over4 address structure 1081 The ISATAP address structure is similar to the 6over4 address 1082 structure, except that the unique/local (u) bit signifies whether the 1083 IPv4 address in the interface identifier is unique. Presumably, this 1084 is the case for any non-[RFC1918] IPv4 address. The group (g) bit is 1085 set to zero, and the remaining bits are set to to 0x00005EFE. 1087 | 48 bits | 16 | 32 | 32 | 1088 +---------------------+--------+-----------------+-----------------+ 1089 | Organisation prefix | Subnet | ug00:5EFE | IPv4 address | 1090 +---------------------+--------+-----------------+-----------------+ 1092 The ISATAP address structure 1094 Teredo embeds the Teredo server's IPv4 address, a number of flags, a 1095 UDP port number as well as the Teredo client's IPv4 address in the 1096 IPv6 addresses it creates. For good measure, the UDP port and client 1097 IPv4 address are "obfuscated" by flipping their bits. 1099 | 32 bits | 32 | 16 | 16 | 32 | 1100 +----------------+---------------+-------+-------+-----------------+ 1101 | 2001:0 | Server IPv4 | Flags | Port | Client IPv4 | 1102 +----------------+---------------+-------+-------+-----------------+ 1104 The Teredo address structure 1106 6a44 Can be seen as a combination of 6rd and Teredo. The 6a44 prefix 1107 is given out by an ISP. Both the customer site (home gateway) IPv4 1108 address as well as the host's/client's RFC 1918 IPv4 address and also 1109 a port number are embedded in the IPv6 address. 1111 | 48 bits | 32 | 16 | 32 | 1112 +----------------------+-----------------+-------+-----------------+ 1113 | 6a44 prefix | Cust. site IPv4 | Port | Client IPv4 | 1114 +----------------------+-----------------+-------+-----------------+ 1116 The 6a44 address structure 1118 6bed4 embeds two combinations of an IPv4 address and UDP port 1119 (together acting as a "6bed4 address") in the IPv6 address; the first 1120 address is for a relay server that everyone is certain to reach, the 1121 other is for the direct address that most peers should be able to 1122 reach directly. The relay server however, is the only one with 1123 guaranteed access to the direct address. 1125 | 16 | 48 bits | 50 | 14 | 1126 +--------+-----------------------+-------------------------+-------+ 1127 | prefix | general 6bed4 address | direct 6bed4 address | lanIP | 1128 +--------+-----------------------+-------------------------+-------+ 1130 The 6bed4 address structure 1132 The representation of the direct 6bed4 address is slightly modified 1133 to leave room in bits 70 and 71 for EUI-64 flags that signify that 1134 this local addressing scheme is used, and the unicast/multicast flag. 1135 The missing IPv4 address bits are moved to bits 112 and 113. The 1136 remaining 14 bits in the lanIP field can be used freely for local 1137 assignment. 1139 6. Evaluation of Tunnel Mechanisms 1141 The following subsections deal with the various aspects of tunnels 1142 that guide their selection. 1144 6.1. Efficiency of IPv4 Address Use 1146 With the depletion of the IPv4 address space, the ability to deploy a 1147 tunnel mechanism behind NAT as well as the number of IPv6 1148 subscribers, subnets and individual hosts that can be supported 1149 behind a single IPv4 address have become important considerations. 1151 These issues are irrelevant to tunneling mechanisms that provide IPv6 1152 connectivity between hosts within the same administrative domain, 1153 such as ISATAP or 6over4, as they can use private IPv4 addresses. 1154 This is also true for 6rd, which is used between an ISP and its 1155 customers' home gateways. 1157 Although 6to4 can't work behind any kind of NAT and most other 1158 protocol 41 mechanisms can, at least in principle, in practice this 1159 difference is not as big, as the protocol 41 encapsulation doesn't 1160 provide any fields that allow a NAT to demultiplex tunneled packets. 1161 This means that only a single protocol 41 tunnel endpoint can be 1162 supported for each IPv4 address. 1164 So a home or small office network can use 6to4 if the gateway has a 1165 public IPv4 address. A configured tunnel can also be terminated on a 1166 system that is behind a NAT, but only if no other systems attempt to 1167 use protocol 41 behind that same NAT (or rather, behind the same IPv4 1168 address). This makes configured tunnels (as well as 6to4) 1169 incompatible with service provider operated NATs, where multiple 1170 subscribers share an IPv4 address. The same goes for GRE. 1172 Teredo and 6bed4 are designed to work through NATs and use a UDP 1173 header, so multiple tunnel endpoints can be hosted behind a single 1174 IPv4 address. On the other hand, Teredo only provides IPv6 1175 connectivity to a single host. 1177 As such, we group IPv6-in-IPv4 tunneling mechanisms based on their 1178 IPv4 address use as follows, in order of declining IPv4 address use 1179 per IPv6 host: 1181 One host: Automatic tunneling supports only a single IPv6 host per 1182 IPv4 address. 1184 One SOHO: 6to4 can support a single home office or small office per 1185 IPv4 address. 1187 One organisation: Configured tunnels and GRE can support one 1188 network, but of arbitrary size, behind an IPv4 address. 1190 Many hosts: Teredo and 6bed4 support many individual hosts behind a 1191 single IPv4 address. 1193 Many SOHOs: AYIYA can support many networks of arbitrary size behind 1194 a single IPv4 address. However, the need to maintain mapping 1195 state makes it less appropriate for networks larger than a home or 1196 small office network. 1198 Not applicable: 6over4, ISATAP, 6rd and configured tunnels when used 1199 with RFC1918 addresses. 1201 6.2. Supported Network Topologies 1203 There are a few variations in the network topologies supported by 1204 IPv6 tunneling mechanisms. One aspect is whether it usually services 1205 a single host, a network or an ISP network. Another aspect is 1206 whether it supports multicast on the IPv6 level. Finally, a tunnel 1207 may be meant to connect to native addresses, or be suitable for 1208 direct traffic between peers on the same tunnel network. 1210 +------------+--------------+-----------+---------+ 1211 | Mechanism | Services | Multicast | Peering | 1212 +------------+--------------+-----------+---------+ 1213 | Conf. tun. | Host/Network | Yes/No | N/A | 1214 | Auto. tun. | Host | No | N/A | 1215 | 6over4 | Network | Yes | N/A | 1216 | GRE | Network | N/A | N/A | 1217 | 6to4 | Network | No | Yes | 1218 | AYIYA | Host | No | No | 1219 | ISATAP | Host | No | Yes | 1220 | Teredo | Host | No | No | 1221 | 6rd | ISP Network | N/A | N/A | 1222 | 6a44 | Host | No | No | 1223 | 6bed4 | Host | No | Yes | 1224 | LISP | | | | 1225 +------------+--------------+-----------+---------+ 1227 Topologies Supported per Tunnel Mechanism 1229 6.3. Parties Involved in Tunnel Realisation 1231 Dependent on the mechanisms employed by a tunnel, more or less 1232 parties may have to be involved in setting up an IPv6 tunnel. This 1233 section details the parties that need to be willing to act before a 1234 tunnel can work. 1236 Several tunnels require the presence of public gateways, usually at 1237 some well-known, anycasted address. Any particular instance of the 1238 gateway service may or may not provide a satisfactory service level, 1239 and the gateway used may be some distance away, adding path stretch. 1240 The gateway service must be available, and function properly if the 1241 tunnel is to work reliably and efficiently. Being dependent on a 1242 public gateway therefore incurs a risk of network delays. Public 1243 services are usually not under one's direct influence. 1245 Other tunnels assume that an Internet Service Provider is involved in 1246 supplying the tunnel. This leads to more influence on the proper 1247 functioning of the tunnel, but it also makes the tunnel dependent on 1248 the selection of ISP. 1250 The network perimeter filters between the ISP network and the local 1251 network usually contains firewalls and NAT. These components may be 1252 managed in part by the ISP. In general, the devices need to be co- 1253 operative for some tunnels to work reliably. 1255 The local network may host relay servers for central tunnel 1256 management. In that case, a network administrator usually sets up 1257 such a node. Other tunnels are setup in local software, and could 1258 require an end user to have system administrative skills. 1260 +------------+------------+-------------------+-----+---------------+ 1261 | Mechanism | Management | Filtering | ISP | Public | 1262 | | | Perimeter | | Gateway | 1263 +------------+------------+-------------------+-----+---------------+ 1264 | Conf. tun. | SysAdmin | Pass protocol 41 | No | No | 1265 | Auto. tun. | Automatic | Pass protocol 41 | No | No | 1266 | 6over4 | SysAdmin | Pass protocol 41 | No | No | 1267 | GRE | NetAdmin | Pass GRE | No | No | 1268 | 6to4 | Automatic | No NAT | No | Yes (3) | 1269 | AYIYA | NetAdmin | Pass plain UDP | No | Yes | 1270 | ISATAP | SysAdmin | No NAT (1) | No | No | 1271 | Teredo | Automatic | Problematic (2) | No | Yes | 1272 | 6rd | Automatic | Pass protocol 41 | Yes | No | 1273 | 6a44 | Automatic | Pass plain UDP | Yes | No | 1274 | 6bed4 | Automatic | Pass plain UDP | No | Yes (4) | 1275 | LISP | | | | | 1276 +------------+------------+-------------------+-----+---------------+ 1278 Dependencies for Operating Tunnels 1280 Notes: 1282 (1): As an exception to the general rule that ISATAP is meant to run 1283 on public IPv4 addresses, ISATAP can be used to connect networks 1284 that are behind NAT if their address spaces may be united. 1286 (2): Behind most NAT routers, Teredo should get an address 1287 allocated. It depends on the type of NAT if it will get through. 1288 This means that the protocol may be automatic, but the involvement 1289 of a NetAdmin may be required to make Teredo function. 1291 (3): Normally, 6to4 is considered an automatic tunnel that sends to 1292 an anycast address in IPv4. For traffic returning from a native 1293 address to 6to4 space, another public service is required, and 1294 this one cannot be influenced by the sending party. Public 1295 service is not required for peer-to-peer traffic between 6to4 1296 hosts. 1298 (4): The public service is required to connect peers with an 1299 Endpoint-Dependent mapping in the direct path; furthermore, it is 1300 needed to connect 6bed4 to native addresses. When used to connect 1301 two 6bed4 peers, there is rarely a need for a public service. 1303 6.4. Robustness 1305 Tunnels may fail for three main reasons: when tunneled packets are 1306 filtered, typically by a firewall, when a tunnel endpoint IPv4 1307 address changes, when tunneled packets are filtered or because of NAT 1308 issues. 1310 If a tunnel endpoint gets a new address, the other side of the tunnel 1311 needs to know to send packets to the new address. With mechanisms 1312 that derive IPv6 addresses from the IPv4 address, the previous IPv6 1313 addresses become unreachable and new IPv6 addresses must be 1314 configured. 1316 Some tunneling mechanisms don't work through NAT, or are limited when 1317 working through NAT. NAT mappings can typically only be created by 1318 traffic from the "inside" to the "outside", not by traffic from 1319 outside the NAT to the network behind the NAT. 1321 Point-to-point tunneling mechanisms either work consistently or they 1322 always fail. As such, a simple ping to the other side of the tunnel 1323 is sufficient to learn its state. Also, point-to-point tunnels may 1324 support routing protocols, which can automatically reroute traffic 1325 around a failed tunnel. 1327 Some tunnel mechanisms use a public gateway to reach the native IPv6 1328 internet. Public gateways may or may not be operational and/or 1329 reachable, and may have limited performance, depending on distance 1330 and usage. Also, if multiple gateways are reachable at the same 1331 address (using an anycast setup), performance is hard to predict and 1332 debug. It is common for traffic in two directions to use different 1333 gateways, complicating debugging even further. 1335 Tunnel mechanisms that use a broadcast or non-broadcast multiple 1336 access (NBMA) communication model may experience failures between 1337 some combinations of tunnel endpoints and not others. 1339 +------------+---------------+--------------+-----------+-----------+ 1340 | Mechanism | Endpoint | Packet | Public | NAT | 1341 | | address | filtering | gateway | mapping | 1342 | | change | | | issues | 1343 +------------+---------------+--------------+-----------+-----------+ 1344 | Conf. tun. | failure | yes/no | no | yes (1) | 1345 | Auto. tun. | interruption | per peer | no | N/A | 1346 | 6over4 | interruption | per peer | no | N/A | 1347 | GRE | failure | yes/no | no | N/A | 1348 | 6to4 | interruption | gw, per peer | yes | N/A (2) | 1349 | AYIYA | depends | yes/no | no | depends | 1350 | ISATAP | interruption | per peer | no | N/A | 1351 | Teredo | interruption | gw, per peer | yes | yes (3) | 1352 | 6rd | interruption | N/A | no | N/A | 1353 | 6a44 | interruption | yes/no | no | no (4) | 1354 | 6bed4 | interruption | yes/no | yes | no (4) | 1355 | LISP | | | | | 1356 +------------+---------------+--------------+-----------+-----------+ 1358 Susceptibility of tunneling mechanisms to problems 1360 Notes: 1362 (1): only one protocol 41 tunnel endpoint can receive a NAT mapping 1363 behind a NAT using a single public IPv4 address. Additional 1364 endpoints will not receive incoming packets. When a tunnel 1365 endpoint changes its internal address, the old NAT mapping needs 1366 to time out before a new one can be created. 1368 (2): 6to4 implementations automatically disable the mechanism when 1369 the system has an RFC 1918 address. However, 6to4 may remain 1370 enabled and be non-operational when ISPs apply NAT using non-RFC 1371 1918 addresses [RFC6598]. 1373 (3): whether Teredo can obtain an address depends on the type of NAT 1374 it detects. Whether Teredo functions at such an address depends 1375 on the accuracy of that determination, which is founded in an 1376 incomplete model of NAT. 1378 (4): 6a44 and 6bed4 make no assumptions about NAT, other than the 1379 standard ability to pass UDP out and then to be able for some time 1380 to receive return traffic from the same remote. 1382 On some widely used implementations, 6to4 has been enabled by default 1383 without checking whether there was connectivity to the anycasted 1384 public gateway address. As a result, 6to4-derived connectivity to 1385 the IPv6 internet was often found to be broken because of protocol 41 1386 filtering. Because of this, many operating systems now try to avoid 1387 using IPv6 over 6to4. See [RFC6343]. 1389 Also see [TERTST] for more information about the robustness of 1390 Teredo. 1392 There is not a single tunneling mechanism that is more robust in all 1393 possible ways than every other tunneling mechanism. However, in 1394 general mechanisms that use public gateways and peer-to-peer 1395 tunneling tend to have the most issues. Configured tunnels on the 1396 other hand, often work very well, especially if there is no NAT on 1397 the path, but need administrative intervention when a tunnel endpoint 1398 address changes. 1400 6.5. Performance 1402 There are several reasons why tunneled connectivity may perform 1403 inferior to native, un-tunnteled connectivity. Inherently, tunnels 1404 add one or more extra headers, and therefore increase overhead. 1405 However, for a maximum size Ethernet packet the additional overhead 1406 of an IPv4 header is only 1.3%. 1408 The process of encapsulation is not inherently slow, but in some 1409 implementations, it may be. Larger routers that normally forward 1410 packets using special purpose hardware, often don't have high 1411 performance CPUs. If then tunnel encapsulation must be done by that 1412 relatively slow CPU, performance will be worse than regular hardware- 1413 based packet forwarding. 1415 The path that tunneled packets take can be longer than the path that 1416 untunneled packets would take. (Increased path stretch.) This may 1417 or may not lead to decreased performance. 1419 Public gateways typically don't help performance. ISP-operated 1420 gateways are better. 1422 +------------+----------+--------------+--------+--------+----------+ 1423 | Mechanism | Over- | Increased | Gate- | In | Var- | 1424 | | head | path stretch | ways | prac- | iabil- | 1425 | | (bytes) | | | tice | ity | 1426 +------------+----------+--------------+--------+--------+----------+ 1427 | Conf. tun. | 20 | may be large | no | *** | none | 1428 | Auto. tun. | 20 | none | no | - | none | 1429 | 6over4 | 20 | none | no | - | none | 1430 | GRE | 28 - 36 | may be large | no | *** | none | 1431 | 6to4 | 20 | may be large | public | ** | high | 1432 | AYIYA | 72 | may be large | no | *** | low | 1433 | ISATAP | 20 | none | no | *** | none | 1434 | Teredo | 28 ? | may be large | public | * | high | 1435 | 6rd | 20 | small | ISP | **** | low | 1436 | 6a44 | ? | ? | | ? | ? | 1437 | 6bed4 | ? | ? | | ? | ? | 1438 | LISP | ? | small | ISP | ? | high | 1439 +------------+----------+--------------+--------+--------+----------+ 1441 Typical tunnel performance 1443 7. IANA considerations 1445 None. 1447 8. Security considerations 1449 There are many security considerations with tunneling. An important 1450 one is that through a tunnel, connectivity to the IPv6 internet may 1451 exist even though network administrators did not intend for it to be 1452 there. "Security Concerns with IP Tunneling" [RFC6169] discusses 1453 this issue in detail. 1455 Another issue with tunneling is that it often makes implementation of 1456 ingress filtering (BCP 38, [RFC2827]) harder or even impossible. 1457 This is especially true for non-point-to-point tunnels, such as 6to4 1458 and Teredo because legitimate packets can arrive from anywhere. So 1459 it is important to recognise that both IPv4 and IPv6 addresses in 1460 tunnel packets may be spoofed and cannot be relied upon for access 1461 controls. 1463 Tunnels may also be used by third parties to obfuscate their 1464 activities or perform amplification attacks. As such, it is 1465 important to make sure only locally generated packets with legitimate 1466 addresses are sent out over tunnels. 1468 9. Contributors 1470 Job Snijders contributed text to the points of comparison. 1472 10. Acknowledgements 1474 We wish to thank SURFnet and Rogier Spoor for commissioning this 1475 work; both their initiative and funding has helped this document to 1476 be written. 1478 11. References 1480 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1481 November 1990. 1483 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1484 E. Lear, "Address Allocation for Private Internets", 1485 BCP 5, RFC 1918, February 1996. 1487 [RFC1933] Gilligan, R. and E. Nordmark, "Transition Mechanisms for 1488 IPv6 Hosts and Routers", RFC 1933, April 1996. 1490 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 1491 for IP version 6", RFC 1981, August 1996. 1493 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., 1494 and R. Wheeler, "A Method for Transmitting PPP Over 1495 Ethernet (PPPoE)", RFC 2516, February 1999. 1497 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1498 Domains without Explicit Tunnels", RFC 2529, March 1999. 1500 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1501 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1502 March 2000. 1504 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1505 Defeating Denial of Service Attacks which employ IP Source 1506 Address Spoofing", BCP 38, RFC 2827, May 2000. 1508 [RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for 1509 IPv6 Hosts and Routers", RFC 2893, August 2000. 1511 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1512 via IPv4 Clouds", RFC 3056, February 2001. 1514 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 1515 RFC 3068, June 2001. 1517 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 1518 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1519 Through Network Address Translators (NATs)", RFC 3489, 1520 March 2003. 1522 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1523 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1525 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1526 Network Address Translations (NATs)", RFC 4380, 1527 February 2006. 1529 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1530 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1531 RFC 4787, January 2007. 1533 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1534 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1535 September 2007. 1537 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1538 Address Autoconfiguration", RFC 4862, September 2007. 1540 [RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H. 1541 Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", 1542 RFC 4891, May 2007. 1544 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1545 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1546 March 2008. 1548 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1549 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1550 October 2008. 1552 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 1553 Infrastructures (6rd)", RFC 5569, January 2010. 1555 [RFC5572] Blanchet, M. and F. Parent, "IPv6 Tunnel Broker with the 1556 Tunnel Setup Protocol (TSP)", RFC 5572, February 2010. 1558 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1559 Infrastructures (6rd) -- Protocol Specification", 1560 RFC 5969, August 2010. 1562 [RFC5991] Thaler, D., Krishnan, S., and J. Hoagland, "Teredo 1563 Security Updates", RFC 5991, September 2010. 1565 [RFC6081] Thaler, D., "Teredo Extensions", RFC 6081, January 2011. 1567 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1568 Algorithm", RFC 6145, April 2011. 1570 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 1571 Concerns with IP Tunneling", RFC 6169, April 2011. 1573 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1574 Stack Lite Broadband Deployments Following IPv4 1575 Exhaustion", RFC 6333, August 2011. 1577 [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", 1578 RFC 6343, August 2011. 1580 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 1581 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 1582 Space", BCP 153, RFC 6598, April 2012. 1584 [RFC6751] Despres, R., Carpenter, B., Wing, D., and S. Jiang, 1585 "Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises 1586 Equipment (6a44)", RFC 6751, October 2012. 1588 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 1589 Locator/ID Separation Protocol (LISP)", RFC 6830, 1590 January 2013. 1592 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 1593 "Interworking between Locator/ID Separation Protocol 1594 (LISP) and Non-LISP Sites", RFC 6832, January 2013. 1596 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 1597 Protocol (LISP) Map-Server Interface", RFC 6833, 1598 January 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 [TR-069] The Broadband Forum, "CPE WAN Management Protocol", 1605 July 2011, . 1608 [TUNBROKER] 1609 Hurricane Electric, "Hurricane Electric Free IPv6 Tunnel 1610 Broker", . 1612 [SIXXS] Massar, J. and P. van Pelt, "IPv6 Deployment & Tunnel 1613 Broker", . 1615 [AYIYA] SixXS, "Anything In Anything (AYIYA)", 1616 . 1618 [AICCU] SixXS, "Automatic IPv6 Connectivity Client Utility 1619 (AICCU)", . 1621 [TIC] SixXS, "Tunnel Information and Control protocol (TIC)", 1622 . 1624 [TERTST] Huston, G., "Testing Teredo", April 2011, 1625 . 1627 [ISATAP-WIN] 1628 Microsoft, "Intra-site Automatic Tunnel Addressing 1629 Protocol Deployment Guide", September 2010, . 1632 [6BED4] Van Rein, R., "6bed4: Peer-to-Peer IPv6 on Any 1633 Internetwork", . 1635 [LISPBETA] 1636 "LISP Beta Network", . 1638 Appendix A. Evaluation Criteria 1640 Each type of tunnel has specific advantages and disadvantages. We 1641 have considered the following points when evaluating the different 1642 protocols. Not every point is mentioned in each section where a 1643 protocol is described, only those that are specifically relevant to 1644 that protocol. 1646 Protocol overhead: How much overhead does the tunneling protocol 1647 cause? There are two factors that play a role: number of 1648 interactions to set up the tunnel and packet header size causing a 1649 lower MTU and/or fragmentation. 1651 Automatic configuration: Does this protocol require manual 1652 configuration at the endpoints? 1654 Predictability: How predictable is the functioning of the protocol? 1656 Single host or network: Is this protocol intended to be used by a 1657 single host or by a router that then provides IPv6 connectivity to 1658 multiple hosts? 1660 Load balancing: Does the tunnel traffic have enough entropy and/or 1661 hashability to be able to be load-balanced over multiple links, or 1662 do all tunnel packets have the same outer 5-tuple? 1664 Path stretch: Does the tunnel optimise the route, or is there a big 1665 potential for a much longer path when using the tunnel? 1667 NAT traversal: Can the tunnel pass through a NAT gateway, and does 1668 it require configuration on that NAT gateway? 1670 Tunnel endpoint mobility: Are the IPv4 addresses of the tunnel fixed 1671 or do they adjust automatically when an endpoint moves. 1673 State: Are the endpoints required to keep state for the tunnel or is 1674 the tunnel stateless? 1676 Network type: Is this network a point-to-point network, multipoint 1677 or NBMA type of network? 1679 Purpose: What is the intended purpose of this tunnel protocol? 1681 Related protocols: To which protocols is this tunnel protocol 1682 related? Are there alternatives? 1684 Implementations: Is this protocol supported on the major operating 1685 systems, routers and firewalls? 1687 Limitations: What are the known limitations of this protocol? 1689 Authors' Addresses 1691 Sander Steffann 1692 S.J.M. Steffann Consultancy 1693 Tienwoningenweg 46 1694 Apeldoorn, Gelderland 7312 DN 1695 The Netherlands 1697 Email: sander@steffann.nl 1698 Iljitsch van Beijnum 1699 Institute IMDEA Networks 1700 Avda. del Mar Mediterraneo, 22 1701 Leganes, Madrid 28918 1702 Spain 1704 Email: iljitsch@muada.com 1706 Rick van Rein 1707 OpenFortress 1708 Haarlebrink 5 1709 Enschede, Overijssel 7544 WP 1710 The Netherlands 1712 Email: rick@openfortress.nl