idnits 2.17.1 draft-ietf-ngtrans-shipworm-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 121 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC2460], [RFC2119], [RFC2461], [RFC2462], [RFC3056]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 17, 2002) is 7889 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC3056' on line 2633 looks like a reference -- Missing reference section? 'RFC2119' on line 2621 looks like a reference -- Missing reference section? 'RFC2460' on line 2624 looks like a reference -- Missing reference section? 'RFC2462' on line 2630 looks like a reference -- Missing reference section? 'RFC2461' on line 2627 looks like a reference -- Missing reference section? 'RFC768' on line 2610 looks like a reference -- Missing reference section? 'RFC791' on line 2612 looks like a reference -- Missing reference section? 'RFC2104' on line 1354 looks like a reference -- Missing reference section? 'RFC1321' on line 2614 looks like a reference -- Missing reference section? 'RFC2641' on line 1814 looks like a reference -- Missing reference section? 'SYNCHRO' on line 2642 looks like a reference -- Missing reference section? 'REFLECT' on line 2645 looks like a reference -- Missing reference section? 'Bradner' on line 2571 looks like a reference -- Missing reference section? '1996' on line 2571 looks like a reference -- Missing reference section? 'RFC1918' on line 2617 looks like a reference -- Missing reference section? 'RFC3068' on line 2636 looks like a reference -- Missing reference section? 'RFC1750' on line 2639 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT C. Huitema 2 Microsoft 3 Expires March 17, 2003 September 17, 2002 5 Teredo: Tunneling IPv6 over UDP through NATs 7 Status of this memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 We propose here a service that enables nodes located behind one or 31 several IPv4 NATs to obtain IPv6 connectivity by tunneling packets 32 over UDP; we call this the Teredo service. Running the service 33 requires the help of "Teredo servers" and "Teredo relays"; the 34 Teredo servers are stateless, and only have to manage a small 35 fraction of the traffic between Teredo clients; the Teredo relays 36 act as IPv6 routers between the Teredo service and the "native" IPv6 37 Internet. 39 1 Introduction 41 Classic tunneling methods envisaged for IPv6 transition operate by 42 sending IPv6 packets as payload of IPv4 packets; the 6to4 proposal 43 [RFC3056] proposes automatic discovery in this context. A problem 44 with these methods is that they don't work when the IPv6 candidate 45 node is isolated behind a Network Address Translator (NAT) device: 46 NATs are typically not programmed to allow the transmission of 47 arbitrary payload types; even when they are, the local address 48 cannot be used in a 6to4 scheme. 6to4 will work with a NAT if the 49 NAT and 6to4 router functions are in the same box; we want to cover 50 the relatively frequent case when the NAT cannot be readily upgraded 51 to provide a 6to4 router function. 53 A possible way to solve the problem is to rely on a set of "tunnel 54 brokers." There are however limits to any solution that is based on 56 Huitema [Page 1] 57 such brokers: the quality of service is not very good, since the 58 traffic follows a "dog leg" route from the source to the broker and 59 then the destination; the broker has to provide sufficient 60 transmission capacity to relay all packets and thus suffers a high 61 cost. For these two reasons, we tend to prefer solutions that allow 62 for "automatic tunneling", i.e. let the packets follow a direct path 63 to the destination. 65 The automatic tunneling requirement is indeed at odds with some of 66 the specificities of NATs. Establishing a direct path supposes that 67 the IPv6 candidate node can retrieve a "globally routable" address 68 that results from the translation of its local address by one or 69 several NATs; it also supposes that we can find a way to bypass the 70 various "per destination protections" that many NATs implement. In 71 this memo, we will explain how IPv6 candidates located behind NATs 72 can enlist the help of "Teredo servers" and "Teredo relays" to learn 73 their "global address" and to obtain connectivity, and how clients, 74 servers and relays can be organized in Teredo networks. 76 The specification is organized as follow. Section 2 contains the 77 definition of the terms used in the memo. Section 3 presents the 78 hypotheses on NAT behavior used in the design, as well as the 79 operational requirements that the design should meet. Section 4 80 presents the models of operation and deployment. Section 5 contains 81 the format of the messages and the specification of the protocol. 82 Section 6 is a discussion of the key design choices. Section 7 83 presents the guideline for some further work that would be 84 complementary to the current approach. Section 8 contains a security 85 discussion, and section 9 contains IANA considerations. 87 2 Definitions 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 This specification uses the following definitions: 95 2.1 Teredo service 97 The transmission of IPv6 packets over UDP, as defined in this memo. 99 2.2 Teredo Client 101 A node that has some access to the IPv4 Internet and that wants to 102 gain access to the IPv6 Internet. 104 2.3 Teredo Server 106 A node that has access to the IPv4 Internet through a globally 107 routable address, and that is used as a helper to provide IPv6 108 connectivity to Teredo clients. 110 Huitema [Page 2] 111 2.4 Teredo Relay 113 An IPv6 router that can receive traffic destined to Teredo clients 114 and forward it using the Teredo service. 116 2.5 Teredo IPv6 service prefix 118 An IPv6 addressing prefix which is used to construct the IPv6 119 address of Teredo clients. 121 2.5.1 Global Teredo IPv6 service prefix 123 An IPv6 addressing prefix whose value is XXXX:XXXX:/32. 124 (TBD IANA; experiments use the value 3FFE:831F::/32, taken from a 125 range of experimental IPv6 prefixes assigned to Microsoft.) 127 2.6 Teredo UDP port 129 The UDP port number at which Teredo Servers are waiting for packets. 130 The value of this port is 3544. 132 2.7 Teredo bubble 134 A Teredo bubble is a minimal IPv6 packet, made of an IPv6 header and 135 a null payload - the payload type is set to 59, No Next Header, as 136 per [RFC2460]. The Teredo clients and relays may send bubbles in 137 order to create a mapping in a NAT. 139 2.8 Teredo service port 141 The port through which the Teredo client sends Teredo packets. This 142 port is attached to one of the client's IPv4 interfaces. The IPv4 143 address may or may not be globally routable, as the client may be 144 located behind one or several NAT. 146 2.9 Teredo server address 148 The IPv4 address of the Teredo server selected by a particular user. 150 2.10 Teredo mapped address and Teredo mapped port 152 A global IPv4 address and a UDP port that results from the 153 translation by one or several NATs of the IPv4 address and UDP port 154 of a client's Teredo service port. The client learns these values 155 through the Teredo protocol described in this memo. 157 2.11 Teredo IPv6 client prefix 159 A global scope IPv6 prefix composed of the Teredo IPv6 service 160 prefix and the Teredo server address. 162 Huitema [Page 3] 163 2.12 Teredo node identifier 165 A 64 bit identifier that contains the UDP port and IPv4 address at 166 which a client can joined through the Teredo service, as well as a 167 flag indicating the type of NAT through which the client accesses 168 the IPv4 Internet. 170 2.13 Teredo IPv6 address 172 A Teredo IPv6 address obtained by combining a Teredo IPv6 client 173 prefix and a Teredo node identifier. 175 2.14 Teredo Refresh Interval 177 The interval during which a Teredo IPv6 Address is expected to 178 remain valid in the absence of "refresh" traffic. For a client 179 located behind a NAT, the interval depends on configuration 180 parameters of the local NAT, or the combination of NATs in the path 181 to the Teredo server. By default, clients assume an interval value 182 of 30 seconds; a longer value may be determined by local tests, 183 described in section 5. 185 2.15 Teredo secondary port 187 A UDP port used to determine the appropriate value of the refresh 188 interval, but not used to carry any Teredo traffic. 190 2.16 Teredo IPv4 Discovery Address 192 An IPv4 multicast address used to discover other Teredo clients on 193 the same IPv4 subnet. 195 3 Design goals, requirements, and model of operation 197 The proposed solution transports IPv6 packets as the payload of UDP 198 packets. This is based on the observation that TCP and UDP are the 199 only protocols guaranteed to cross the majority of NAT devices. 200 Relaying packets over TCP would be possible, but would result in a 201 very poor quality of service; relaying over UDP is a better choice. 203 The design of our solution is based on a set of hypotheses and 204 observations on the behavior of NATs, our desire to provide an "IPv6 205 provider of last resort", and a list of operational requirements. It 206 results in a model of operation in which the Teredo service is 207 enabled by a set of servers and relays. 209 3.1 Hypotheses about NAT behavior 211 NAT devices typically incorporate some support for UDP, in order to 212 enable users in the natted domain to use UDP based applications. The 213 NAT will typically allocate a "mapping" when it sees an UDP packet 214 coming through for which there is not yet an existing mapping. The 216 Huitema [Page 4] 217 handling of UDP "sessions" by NAT devices differs by two important 218 parameters, the type and the duration of the mappings. 220 3.1.1 Types of UDP mappings 222 Experience shows that the implementers of NAT devices can adopt 223 widely different treatments of UDP mappings: 225 1) Some implement the simplest solution, which is to map an internal 226 UDP port, defined by an internal address and a port number on the 227 corresponding host, to an external port, defined by a global address 228 managed by the NAT and a port number valid for that address. In this 229 simple case, the mapping is retained as long as the port is active, 230 and is removed after an inactivity timer. As long as the mapping is 231 retained, any packet received by the NAT for the external port is 232 relayed to the internal address and port. These NATs are usually 233 called "cone NATs". 235 2) Some implement a more complex solution, in which the NAT not only 236 establishes a mapping for the UDP port, but also maintains a list of 237 external hosts to which traffic has been sent from that port. The 238 packets originating from third party hosts to which the local host 239 has not yet sent traffic are rejected. These NATs are usually called 240 "restricted cone NATs". 242 3) Instead of keeping just a list of authorized hosts, some NAT 243 implementations keep a list of authorized host and port pairs. UDP 244 packets coming from remote addresses are rejected if the internal 245 host has not yet sent traffic to the outside host and port pair. The 246 NATs are often called "port-restricted cone NATs" 248 4) Finally, some NATs map the same internal address and port pair to 249 different external address and port pairs, depending on the address 250 of the remote host. These NATs are usually called "symmetric NATs". 252 Measurement campaigns and studies of documentations have shown that 253 most NATs implement either option 1 or option 2, i.e. cone NATs or 254 restricted cone NATs. The Teredo solution ensures connectivity for 255 clients located behind cone NATs, restricted cone NATs, or port- 256 restricted cone NATs; it contains optimizations for clients located 257 behind a cone NAT; it does not provide connectivity for clients 258 located behind a symmetric NAT. 260 3.1.2 Lifetime of UDP mappings 262 Regardless of their types, UDP mappings are not kept forever. The 263 typical algorithm is to remove the mapping if no traffic is observed 264 on the specified port for a "lifetime" period. The Teredo client 265 that want to maintain a mapping open in the NAT will have to send 266 some "keep alive" traffic before the lifetime expires. For that, it 267 needs an estimate of the "lifetime" parameter used in the NAT. We 268 observed that the implementation of lifetime control can vary in 270 Huitema [Page 5] 271 several ways. 273 Most NATs implement a "minimum lifetime" which is set as a parameter 274 of the implementation. Our observations of various boxes showed that 275 this parameter can vary between about 45 seconds and several 276 minutes. 278 In many NATs, mappings can be kept for a duration that exceeds this 279 minimum, even in the absence of traffic. We suspect that many 280 implementation perform "garbage collection" of unused mappings on 281 special events, e.g. when the overall number of mappings exceeds 282 some limit. 284 In some cases, e.g. NATs that manage ISDN or dial-up connections, 285 the mappings will be release when the connection is released, i.e. 286 when no traffic is observed is observed on the connection for a 287 period of a few minutes. 289 Any algorithm used to estimate the lifetime of mapping will have to 290 be robust against these variations. 292 3.2 IPv6 provider of last resort 294 Teredo is designed to provide an "IPv6 access of last resort" to 295 nodes that need IPv6 connectivity but cannot use any of the other 296 transition schemes designed by the NGTRANS working group. This 297 design objective has several consequences on when to use Teredo, how 298 to program clients, and what to expect of servers. Another 299 consequence is that we expect to see a point in time at which the 300 Teredo technology ceases to be used. 302 3.2.1 When to use Teredo? 304 Teredo is designed to robustly enable IPv6 traffic through NATs, and 305 the price of robustness is a reasonable amount of overhead, due to 306 UDP encapsulation and transmission of bubbles. Nodes that want to 307 connect to the IPv6 Internet SHOULD only use the Teredo service as a 308 "last resort" option: they SHOULD prefer using direct IPv6 309 connectivity if it is locally available or if it is provided by a 310 6to4 router co-located with the local NAT, and they SHOULD prefer 311 using the less onerous "6to4" encapsulation if they can use a global 312 IPv4 address. 314 3.2.2 Autonomous deployment 316 In an IPv6-enabled network, the IPv6 service is configured 317 automatically, by using mechanisms such as IPv6 Stateless Address 318 Autoconfiguration [RFC2462] and Neighbor Discovery [RFC2461]. A 319 design objective is to configure the Teredo service as automatically 320 as possible. In practice, it is however required that the client 321 learn the IPv4 address of a server that is willing to serve them; 323 Huitema [Page 6] 324 some servers may also require some form of access control. 326 3.2.3 Minimal load on servers 328 During the peak of the transition, there will be a requirement to 329 deploy a large number of servers throughout the Internet. Minimizing 330 the load on the server is a good way to facilitate this deployment. 331 To achieve this goal, servers should be as stateless as possible, 332 and they should also not be required to carry any more traffic than 333 necessary. To achieve this objective, we request that servers only 334 enable the packet exchange between clients, but do not carry the 335 actual data packets: these packets will have to be exchanged 336 directly between the Teredo clients, or through a destination- 337 selected relay for exchanges between Teredo clients and other IPv6 338 clients. 340 3.2.4 Automatic sunset 342 Teredo is meant as a short-term solution to the specific problem of 343 providing IPv6 service to nodes located behind a NAT. The problem is 344 expected to be resolved over time by transforming the "IPv4 NAT" 345 into an "IPv6 router". This can be done in one of two ways: 346 upgrading the NAT to provide 6to4 functions, or upgrading the 347 Internet connection used by the NAT to a native IPv6 service, and 348 then adding IPv6 router functionality in the NAT. In either case, 349 the former NAT can present itself as an IPv6 router to the systems 350 behind it. These systems will start receiving the "router 351 advertisements"; they will notice that they have IPv6 connectivity, 352 and will stop using Teredo. 354 3.3 Operational Requirements 356 3.3.1 Robustness requirement 358 The Teredo service is designed primarily for robustness: packets are 359 carried over UDP in order to cross as many NAT implementations as 360 possible. The servers are designed to be stateless, which means that 361 they can easily be replicated. We expect indeed to find many such 362 servers replicated at multiple Internet locations. 364 3.3.2 Minimal support cost 366 The service requires the support of servers and relays. In order to 367 facilitate the deployment of these servers, the Teredo procedures 368 are designed to minimize the fraction of traffic that has to be 369 routed through the servers. 371 Meeting this objective implies that the Teredo addresses will 372 incorporate the IPv4 address and UDP port through which a Teredo 373 client can be reached. This creates an implicit limit on the 374 stability of the Teredo addresses, which can only remain valid as 375 long as the underlying IPv4 address and UDP port remains valid. 377 Huitema [Page 7] 378 3.3.3 Protection against denial of service attacks 380 The Teredo clients obtain mapped addresses and ports from the Teredo 381 servers. The service must be protected against denial of service 382 attacks in which a third party spoofs a Teredo server and sends 383 improper information to the client. 385 3.3.4 Protection against distributed denial of service attacks 387 Teredo servers will act as a relay for IPv6 packets. Improperly 388 designed packet relays can be used by denial of service attackers to 389 hide their address, making the attack untraceable. The Teredo 390 service must include adequate protection against such misuse. 392 3.3.5 Compatibility with ingress filtering 394 Routers may perform ingress filtering by checking that the source 395 address of the packets received on a given interface is 396 "legitimate", i.e. belongs to network prefixes from which traffic is 397 expected at a network interface. Ingress filtering is a recommended 398 practice, as it thwarts the use of forged source IP addresses by 399 malfeasant hackers, notably to cover their tracks during denial of 400 service attacks. The Teredo specification must not force networks to 401 disable ingress filtering. 403 4 Model of operation and deployment 405 A Teredo Network is composed of a set of clients, servers and 406 relays. In this section, we present the model of operation of a 407 given network, and then we present the deployment model. 409 4.1 Model of operation 411 The Teredo service requires the cooperation of three kinds of 412 actors: Teredo clients, who want to use IPv6 despite being located 413 behind a NAT, Teredo servers who will facilitate the service, and 414 Teredo relays that provide for the interconnection between the 415 Teredo service and the "native IPv6 Internet." 417 In order to enable the service, the Teredo servers must have IPv6 418 connectivity and an unencumbered IPv4 connection: they must have a 419 global IPv4 address; and they must have global IPv6 connectivity 420 independently of the Teredo service. 422 The Teredo relays must be connected to the IPv6 Internet and must 423 participate in IPv6 routing; they must be able to announce 424 reachability of the "Teredo service IPv6 prefix" over IPv6. They 425 must then be able to relay packets over IPv4 UDP towards Teredo 426 clients. 428 The primary role of the servers is to enable NAT traversal. The 430 Huitema [Page 8] 431 service is designed in such a way that, when NAT traversal is 432 guaranteed, packets can flow on a direct path between source and 433 destination, bypassing the Teredo server. 435 4.1.1 Encoding of Teredo addresses 437 The Teredo addresses are composed of 5 components: 439 +-------------+-------------+-------+------+-------------+ 440 | Prefix | Server IPv4 | Flags | Port | Client IPv4 | 441 +-------------+-------------+-------+------+-------------+ 443 - Prefix: the 32 bit Teredo service prefix. 444 - Server IPv4: the IPv4 address of a Teredo server. 445 - Flags: a set of 16 bits that document type of address and NAT. 446 - Port: the obfuscated "mapped UDP port" of the Teredo service at 447 the client 448 - Client IPv4: the obfuscated "mapped IPv4 address" of a client 450 In this format, both the "mapped UDP port" and "mapped IPv4 address" 451 of the client are obfuscated. Each bit in the address and port 452 number is reversed; this can be done by an exclusive OR of the 16- 453 bit port number with the hexadecimal value 0xFFFF, and an exclusive 454 OR of the 32-bit address with the hexadecimal value 0xFFFFFFFF. 456 A third party sends IPv6 packets to a Teredo client by sending these 457 packets over UDP to the client IPv4 address and port if the server 458 address is null, or if the third party has recently received direct 459 traffic from the client. In the other cases, the third party will 460 have to first synchronize with the client, by sending an initial 461 bubble through the server. 463 The IPv6 addressing rules specify that "for all unicast addresses, 464 except those that start with binary value 000, Interface IDs are 465 required to be 64 bits long and to be constructed in Modified EUI-64 466 format." This dictates the encoding of the flags, 16 intermediate 467 bits which should correspond to valid values of the most significant 468 16 bits of a Modified EUI-64 ID: 470 0 0 0 1 471 |0 7 8 5 472 +----+----+----+----+ 473 |Czzz|zzUG|zzzz|zzzz| 474 +----+----+----+----+ 476 In this format: 478 - The bits "UG" should be set to the value "00", indicating a non- 479 global unicast identifier; 480 - The bit "C" (cone) should be set to 1 if the client believes it is 481 behind a cone NAT, to 0 otherwise; these values determine 483 Huitema [Page 9] 484 different server behavior during the qualification procedure, as 485 specified in section 5.2.1, as well as different bubble processing 486 by clients and relays. 487 - The bits indicated with "z" must be set to zero. 489 There are thus two valid values of the Flags field: "0x0000" (all 490 null) if the cone bit is set to 0, and "0x8000" if the cone bit is 491 set to 1. 493 In some cases, Teredo nodes use link-local addresses. These 494 addresses contain a link local prefix (FE80::/64) and a 64 bit 495 identifier, constructed using the same format as presented above. A 496 difference between link-local addresses and global addresses is that 497 the identifiers used in global addresses MUST include a global scope 498 unicast IPv4 address, while the identifiers used in link-local 499 addresses MAY include a private IPv4 address. 501 4.1.2 Obtaining an address 503 The first phase of Teredo operation is the acquisition of a Teredo 504 address prefix by the client. To do this, the client selects a 505 Teredo server, and sends it a Router Solicitation message. The 506 server replies with a router advertisement containing a Teredo 507 prefix, composed of the Teredo service prefix and the IPv4 address 508 of the server; the message also contains an "origin" indication that 509 specifies the IPv4 address and port number from which the server 510 received the router solicitation. 512 In order to explain how this works, we will use an hypothetical 513 example: a Teredo client is located at the private IP address 514 10.0.0.2 in a private network; the NAT connecting this network to 515 the public Internet responds to the local address 10.0.0.1 and is 516 visible as the public address 9.0.0.1. We present here a simplified 517 version of the procedure, in which we are only concerned with 518 determining the "mapping" of the client's address; in the next 519 section, we will explain how this procedure is in fact combined with 520 "cone NAT determination". 522 .----------------------- 523 | Private network 524 .--. _ .-----. .----------. 525 (IPv4) src=9.0.0.1:4096 | NAT | | Teredo | 526 (Internet)<-------------- | BOX | <-- | Client | 527 ( ) (UDPv4 tunneled | | '----------' 528 '--' IPv6) '-----' 10.0.0.2:1234 529 | 9.0.0.1 | 10.0.0.1 530 | | 531 | | 532 V | 533 .--------------. '----------------------- 534 | Teredo | 535 | Server | 536 '--------------' 537 [1.2.3.4] 539 When the Teredo client is turned on, it sends an IPv6 router 540 solicitation over UDP to the Teredo server, using the source address 541 and ports 10.0.0.2:1234. The NAT intercepts the packet, establishes 542 a mapping, and changes the source address and port to 9.0.0.1:4096. 543 (These values are indeed just examples.) 545 The Teredo server receives the packet and notes the source address. 546 It sends back a router advertisement that contains the server's 547 prefix (e.g. PREF:0102:0304::/64); the advertisement also contains 548 an origin indication that specifies the IPv4 address and UDP port 549 from which the router advertisement was received, in this case 550 9.0.0.1:4096. The router sends the router advertisement back over 551 UDP to the mapped IPv4 address 9.0.0.1:4096. The packet will have 552 the following format: 554 +------+-----+-------------------+-------------+ 555 | IPv4 | UDP | Origin indication | IPv6 RA | 556 +------+-----+-------------------+-------------+ 558 The "origin indication" field specifies the "mapped IPv4 address" 559 and "mapped port" of the client; the IPv6 router advertisement 560 specifies the prefix announced by the server. 562 The IPv4 packet is received by the NAT, which has remembered the 563 mapping between this external address and port pair and the private 564 address and port pair, 10.0.0.2:1234; the NAT forwards the packet to 565 the Teredo client. 567 Upon reception of this prefix, the client composes a Teredo address, 568 which in our example will be: 570 PREF:102:304::EFFF:F6FF:FFFE 572 In this address, "PREF" is the Teredo IPv6 service prefix of length 573 32; "102:304" is the hexadecimal notation of the address of the 574 Teredo server, in this example 1.2.3.4 (expressed with leading zeros 575 as 0102:0304); "EFFF" is equal to the XOR of "FFFF" with "1000", 576 which is the hexadecimal notation of the mapped port "4096"; and 577 "F6FF:FFFE" is equal to the XOR of "FFFF:FFFF" with "0900:0001", 578 which is the hexadecimal notation of the IPv4 mapped address 579 "9.0.0.1". 581 In some environments, it is necessary to secure this exchange, to 582 avoid the risk of an attacker "spoofing" the server's return. In 583 these environments, the client will be provisioned with a secret key 584 and a key identifier; the key is shared with the server. Both the 585 client's solicitation and the server's response will be protected by 586 an authentication token, carried in the UDP message: 588 +------+-----+----------------+-------------+ 589 | IPv4 | UDP | Authentication | IPv6 RS | 590 +------+-----+----------------+-------------+ 592 +------+-----+----------------+-------------------+-------------+ 593 | IPv4 | UDP | Authentication | Origin indication | IPv6 RA | 594 +------+-----+----------------+-------------------+-------------+ 596 The authentication token uses the secret key and the key identifier 597 to guarantee the integrity and the authenticity of the packets. 599 4.1.3 Determining the type of NAT 601 The previous section presented a simplified version of the prefix 602 assessment procedure. For better efficiency, the client needs to 603 determine the type of NAT behind which it is located: clients 604 located behind a "cone" NAT can receive traffic directly, and we 605 want to take advantage of this optimization: if the client is 606 located behind a cone NAT, it should use Teredo addresses in which 607 the "cone" bit is set to 1. 609 To achieve this result, the client first sends a router solicitation 610 message from a link-local address in which the "cone" bit is set to 611 1; when the server observes that the cone bit is set, it sends the 612 router advertisement in a UDP packet from a "secondary" IPv4 613 address, i.e., a different IPv4 address than the "server address" to 614 which the solicitation was sent. Only nodes located behind a cone 615 NAT will be able to receive this reply; in consequence, if the 616 client receives this reply, from an IPv4 address different than the 617 server address, it determines that it is located behind a cone NAT. 619 If the client does not receive a response to the first solicitation, 620 it repeats the procedure and sends a solicitation message from a 621 link-local address in which the "cone" bit is set to 0; the server 622 will send the reply from its "nominal" IPv4 address, so the answer 623 can be received by a non-cone NAT. The client will assume that it is 624 not behind a cone NAT. 626 The Teredo service does not work if the client is located behind a 627 symmetric NAT. The client must thus do an extra step, after 628 receiving the router advertisement from the server nominal address: 629 it should repeat the procedure by sending a solicitation to a 630 secondary server IPv4 address, and compare the mapped addresses and 631 mapped port in the two replies. If they are not the same, the client 632 detects that it is behind a symmetric NAT and cannot use the Teredo 633 service. 635 4.1.4 First packet from an IPv6 node to a Teredo node 637 The transmission of packets between a regular IPv6 node and a Teredo 638 node is presented in the following diagram, in which "A" is a Teredo 639 client located behind the NAT "N", "S" the Teredo server chosen by 640 "A", "B" a regular IPv6 node, and "R" a Teredo Relay close to "B" in 641 the IPv6 Internet Topology. 643 .---------------------------------- 644 | IPv6 Internet 645 | +---+ 646 | | B | 647 | +---+ 648 | ! 649 | +-----+ +-!-+ 650 `---| S |----------------|R! |---- 651 .---------------| |----------------| ! |--- 652 |IPv4 Internet | ..|<.................* | 653 | +---#-+ +---+ 654 | # ^! 655 | # :! 656 | #...................:! 657 | bubble+origin --> #:.-.-.-.-.-.-.-.-.-.- 658 | #:! 659 | v:v 660 | +----:--+ 661 `---------------| N #:! |-------------------------- 662 .--| #:! |-------------------- 663 | +---#-!-+ Natted domain 664 | #^! 665 | #:! 666 | v:v 667 | +-----+ 668 | | A | 669 | +-----+ 671 We assume that A has already established its Teredo address through 672 an RA/RS exchange with S, as explained in section 4.1.2; in this 673 example, we will assume that the cone NAT determination failed. We 674 will assume that the results of these exchanges are the following: 676 - A's private address and port are: 10.0.0.2:1234. 678 - A's mapped address and port are: 9.0.0.1:4096. 679 - A's IPv6 address has been set to PREF:102:304::EFFF:F6FF:FFFE 680 - The server's IPv4 address and port are: 1.2.3.4:3544 681 - The relay's IPv4 address and port are: 5.6.7.8:3544 682 - B's IPv6 address is: 2000::B 684 When B sends a packet to A, B simply follows IPv6 rules. The packet 685 is forwarded to the nearest relay, R, over IPv6. R examines the 686 destination address, and observes that the address includes the 687 notation of a server, 1.2.3.4. Since R has not yet received any 688 direct traffic from A, and since A is not located behind a cone NAT, 689 R cannot send the packet directly to A: it would probably be 690 rejected by the NAT N. Instead, R queues the packet, and formats a 691 bubble that it forwards towards A over UDP, to the address of S: 692 1.2.3.4:3544. 694 When S receives the bubble, it notices that the source is not a 695 Teredo client, but instead a regular IPv6 address. S forwards the 696 packet to A using a special envelope. The packet will have the 697 following format: 699 +------+-----+-------------------+-------------+ 700 | IPv4 | UDP | Origin indication | IPv6 bubble | 701 +------+-----+-------------------+-------------+ 703 In the IPv4 and UDP header, the source will be set to the server's 704 address and port, 1.2.3.4:3544, and the destination to A's mapped 705 address, as indicated in the IPv6 destination address: 9.0.0.1:4096. 706 The origin indication element will carry the IPv4 address and UDP 707 port of R: 5.6.7.8:3544. 709 The NAT N will receive this message. It will use the existing 710 mapping to rewrite 9.0.0.1:4096 to 10.0.0.2:1234, and forward the 711 packet to A. When A receives the packet, it will immediately send a 712 bubble back to the origin of the bubble, i.e. towards R, at the 713 address 5.6.7.8:3544. 715 When R receives the bubble from A, it notes that direct transmission 716 towards A is now possible. It forwards the queued packet to the 717 mapped address of A, 9.0.0.1:4096. The packet is received by the 718 NAT; since A has recently sent a packet to R, a mapping exists and 719 the packet is forwarded to A. 721 If the cone NAT validation had been successful, A would have used 722 the IPv6 address PREF:102:304:8000:EFFF:F6FF:FFFE, and R would have 723 sent B's packet directly to A. 725 4.1.5 First packet from a Teredo node to a regular IPv6 node 727 The exchange of packets between a Teredo Node and a regular IPv6 728 node is presented in the following diagram, in which "A" is a Teredo 729 client located behind the NAT "N", "S" the Teredo server chosen by 730 "A", "B" a regular IPv6 node, and "R" a Teredo Relay close to "B" in 731 the IPv6 Internet Topology. 733 .---------------------------------- 734 | IPv6 Internet 735 | +---+ 736 | ..................>| B | 737 | : +---+ 738 | : :^ 739 | : :! 740 | +---:--+ +-:!-+ 741 `---| S : |---------------|R:! |---- 742 .---------------| : |---------------| :! |--- 743 |IPv4 Internet | :..|<.................! | 744 | +----#-+ +----+ 745 | ^# ^ 746 | :# ! 747 | :# ! 748 | bubble+origin --> :#.-.-.-.-.-.-.-.-.-.- 749 | :#! 750 | :v! 751 | +---:-!-+ 752 `---------------| N :#! |-------------------------- 753 .--| :#! |-------------------- 754 | +---:#--+ Natted domain 755 | ^#^ 756 | :#! 757 | :v! 758 | +-------+ 759 | | A | 760 | +-------+ 762 We assume that A has already established its Teredo address through 763 an RA/RS exchange with S, as explained in section 4.1.2; in this 764 example, we will assume that the client is not located behind a cone 765 NAT. We will assume that the results of these exchanges are the 766 following: 768 - A's private address and port are: 10.0.0.2:1234. 769 - A's mapped address and port are: 9.0.0.1:4096. 770 - A's IPv6 address has been set to PREF:102:304::EFFF:F6FF:FFFE 771 - The server's IPv4 address and port are: 1.2.3.4:3544 772 - The relay's IPv4 address and port are: 5.6.7.8:3544 773 - B's IPv6 address is: 2000::B 775 A has to transmit an IPv6 packet to B. A's first action is to learn 776 the address of the relay R closest to B. To do so, A sends an ICMPv6 777 "echo request" toward B. This request carries the source address 778 PREF:102:304::EFFF:F6FF:FFFE (A's address), and the destination 779 address 2000::B (B's address); the Data field of the echo request 780 carries a nonce value, chosen by A. The request is encapsulated by A 781 in a UDP datagram, from source address and port 10.0.0.2:1234, to 782 destination address and port 1.2.3.4:3544. 784 The packet is received by the NAT N. N uses the existing mapping for 785 10.0.0.2:1234, and replaces the UDP source address and port by the 786 mapped values 9.0.0.1:4096, before forwarding the packet. 788 The packet is received over IPv4 by the server. S discards the IPv4 789 and UDP header, and forwards the content of the packet over IPv6, 790 which will be received by B, and which will appear to come from A's 791 address, PREF:102:304::EFFF:F6FF:FFFE. 793 When the request is received, B sends the echo reply to A; B simply 794 follows IPv6 routing rules. The packet is forwarded to the nearest 795 relay, R, over IPv6. R examines the destination address, and 796 observes that the address includes the address of a server, 1.2.3.4. 797 Since R has not received any direct traffic from A, R forwards the 798 packet over UDP to the address of S: 1.2.3.4:3544. 800 When S receives the packet, it notices that the source is not a 801 Teredo client, but instead a regular IPv6 address. S forwards the 802 packet to A using a special envelope. The packet will have the 803 following format: 805 +------+-----+-------------------+-------------+ 806 | IPv4 | UDP | Origin indication | IPv6 packet | 807 +------+-----+-------------------+-------------+ 809 In the IPv4 and UDP header, the source will be set to the server's 810 address and port, 1.2.3.4:p, and the destination to A's mapped 811 address, as indicated in the IPv6 destination address: 9.0.0.1:4096. 812 The origin indication element will carry the IPv4 address and UDP 813 port of R: 5.6.7.8:3544. 815 The NAT N will receive this message. It will use the existing 816 mapping to rewrite 9.0.0.1:4096 to 10.0.0.2:1234, and forward the 817 packet to A. When A receives the packet, it will notice the origin 818 indication, as reported by the server, and it will have learned that 819 B can possibly be reached through the relay address 5.6.7.8:p. A can 820 also note that the Data field of the ICMPv6 echo reply matches the 821 nonce that was previously sent, which provides a reasonable 822 assurance that the packet does in fact come from B. At that point, A 823 can send the original data packet to B, by encapsulating it in a UDP 824 datagram bound to the IPv4 address and UDP port of R: 5.6.7.8:3544; 825 R will then normally relay the packet to B. Once the knowledge of 826 R's address has been acquired, A will send all further packets 827 directly through R, without having to repeat the ICMP exchange. 829 If the cone NAT validation had been successful, A would have used 830 the IPv6 address PREF:102:304:8000:EFFF:F6FF:FFFE, and R would have 831 sent B's reply directly to A. In that case, A would have learned R's 832 address from the IPv4 source address and UDP source port of the 833 incoming packet. 835 Finally, we may observe that this procedure supposes that the relay 836 will send the ICMP echo reply to a non-cone client directly through 837 the server. This is a slight variation of the procedure described in 838 the previous section, in which the IPv6 packets are queued waiting 839 for completion of a bubble exchange between client and relay. The 840 relay may in fact choose to queue the ICMPv6 echo reply, just like 841 it queues normal packets, and forward the ICMPv6 echo reply when the 842 bubble exchange is complete. In that case, the client will learn the 843 relay's address from the IPv4 source address and UDP source port of 844 the incoming packet. 846 4.1.6 Exchanges between two Teredo nodes 848 The following diagram shows two Teredo clients, A and B, connected 849 through the NATs N1 and N2. The exchanges will use the Teredo server 850 S2, chosen by B. We will assume that the NAT N2 is a "restricted 851 cone" or "port-restricted cone" NAT; in this example, we will also 852 assume that A is behind a restricted cone or port-restricted cone 853 NAT. 855 .------------------------------------------------------- 856 | IPv4 Internet 857 | 858 | 4-Data packet 859 | .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-. 860 | ! +----+ ! 861 | ! 2-bubble | S2 | ! 862 | !..............................>|.........! 863 | !: +----+ :! 864 | !: 3-Bubble :! 865 | !: ................................... :! 866 | !: :.................................: :! 867 | !: v: 1-Bubble v: vv 868 | +!----:+ +-:----+ 869 `-----|!:N1::|-----------------------------| :N2:!|----- 870 .--|!: ::|----. .----| : :!|--. 871 | +-:--:-+ | | +----:!+ | 872 | ^^ :^ | | ^ :! | 873 | !: :: | | : :! | 874 | !: v: | | : vv | 875 | +------+ | | +-----+ | 876 | | A | | | | B | | 877 | +------+ | | +-----+ | 878 `--------------/ `--------------/ 880 We will assume that A and B have already obtained Teredo addresses 881 by RS/RA exchanges with they respective servers S1 and S2, and they 882 have made sure that they can receive packets from these respective 883 servers, for example by sending a keepalive packet every minute. In 884 the example, we will assume the following values: 886 - A's private address and port are: 10.0.0.2:1234. 887 - A's mapped address and port are: 9.0.0.1:4096. 888 - A is served by S1, whose address is: 1.2.3.4 889 - A's IPv6 address has been set to PREF:102:304::EFFF:F6FF:FFFE 890 - B's private address and port are: 10.0.0.3:3456. 891 - B's mapped address and port are: 8.0.0.1:1024. 892 - B is served by S2, whose address is: 9.10.11.12 893 - B's IPv6 address has been set to PREF:90A:B0C::FBFF:F7FF:FFFE 895 A has learned B's address, for example from the DNS, and starts UDP 896 or TCP communication with B. The first data packet will be sent from 897 A's IPv6 address (PREF:102:304::EFFF:F6FF:FFFE) to B's IPv6 address 898 (PREF:90A:B0C::FBFF:F7FF:FFFE). Since A has no prior knowledge of B, 899 and since B is not located behind a cone NAT, A cannot send the 900 packet directly to B; the packet is queued. Instead, A prepares two 901 bubbles, from IPv6 source address PREF:102:304::EFFF:F6FF:FFFE to 902 IPv6 destination address PREF:90A:B0C::FBFF:F7FF:FFFE. 904 The first bubble is sent from A to the mapped IPv4 address of B, 905 8.0.0.1:1024. It will probably not be received by B, since there is 906 no establish mapping at the NAT N2. The purpose of this bubble is 907 only to establish a mapping in the NAT N1. 909 The second bubble is sent from A to S2's address, 9.10.11.12:3544. 910 The bubble passes through N1. S2 receives it and transmits it to B. 911 Since there is an established mapping in N2 for transmission between 912 B and S2, the bubble is forwarded to B. 914 B responds to this bubble with its own bubble, from IPv6 source 915 address PREF:90A:B0C::FBFF:F7FF:FFFE to IPv6 destination address 916 PREF:102:304::EFFF:F6FF:FFFE. This response bubble is sent directly 917 to the mapped address of A, 9.0.0.1:4096. Since a mapping was 918 established by the first bubble, this third bubble is received by A. 920 When A receives the third bubble, it knows that direct communication 921 with B is now possible. The queued packet can now be directly 922 transmitted. 924 4.1.7 Exchanges between two Teredo nodes on the same link 926 The following diagram shows two Teredo clients, A and B, connected 927 to the same link, which is connected to the Internet through the NAT 928 N1. The exchanges will use the Teredo server S1. We are not making 929 any assumption about the NAT N1. This scenario explains how the 930 exchanges between clients on the same link can be optimized to avoid 931 routing all packets through the server S1. 933 .------------------------------------------ 934 | IPv4 Internet 935 | +------+ 936 | | S1 | 937 | +------+ 938 | ^! ^! 939 | !! !! 940 | !! !! 941 | !! !! Router Solicit, 942 | !! !! Router Advertisement 943 | !! !! 944 | !v !v 945 | +!---!-+ 946 `-----|!!N1! |---------------------------- 947 .--|!! !!|-------------------------. 948 | +-!--!!+ | 949 | ^! !! | 950 | !! !`-.-.-.-.-.-.-.-.-.-.-. | 951 | !! `-.-.-.-.-.-.-.-.-.-.-.! | 952 | !! .->___ <-. !! | 953 | !v / multicast \ !v | 954 | +------+ bubbles +------+ | 955 | | A | | B | | 956 | +------+ <===========>+------+ | 957 | direct transmissions | 958 `-----------------------------------/ 960 Both A and B discover their Teredo prefix by interacting with the 961 server S1, as explained in 4.1.2. 963 In order to enable direct transmission on the local link, both A and 964 B send Teredo bubbles to the Teredo IPv4 Discovery Address, an IPv4 965 multicast address whose scope is limited to the local link. These 966 bubbles enable the local hosts to discover the local IPv4 address 967 and the local UDP port associated with the Teredo IPv6 address of a 968 local host. The data packets can then be sent over UDP to this 969 address, avoiding the long path through the server S1. 971 4.2 Deployment model 973 The deployment model makes three assumptions: 975 - That all clients, servers and relays will be cognizant of the 976 Teredo service prefix and the Teredo port, 978 - That the clients will be configured with the IPv4 address of a 979 server, 981 - That there will be an adequate deployment of Teredo relays. 983 4.2.1 Server deployment 984 Servers may be deployed either as part of an ISP offer to its 985 subscribers, or as an enabler for an application that requires 986 direct IPv6 communication between client hosts. Servers are expected 987 to perform some amount of access control; for example, an ISP server 988 may refuse to serve requests that don't originate from an address 989 within this ISP's network; a server set up by an application 990 provider may require that clients provide some form of proof that 991 they are actually using the application. 993 Servers will originate IPv6 packets whose source address will be the 994 Teredo IPv6 address of one of their clients. In order to abide with 995 IPv6 ingress filtering rules, servers should only do so if, as an 996 IPv6 router, they advertise reachability of the Teredo service 997 prefix. 999 4.2.2 Relay deployment 1001 The ingress filtering rule implies that all Teredo servers should be 1002 able to act as Teredo relays; however, there is no requirement that 1003 all Teredo relays act as Teredo servers. The only deployment 1004 requirement for Teredo relays is IPv4 connectivity, and the capacity 1005 to advertise a route to the Teredo service. There can be three kinds 1006 of Teredo relays: 1008 - Globally accessible Teredo relays announce reachability of the 1009 Teredo service to the whole Internet, e.g. by means of BGP. 1011 - Domain-specific Teredo relays announce reachability of the Teredo 1012 service to a specific domain, e.g. by means of IGP. 1014 - Host-specific Teredo relays announce reachability of the Teredo 1015 service within a single host. 1017 In the initial deployment of the Teredo service, we expect to find a 1018 small number of globally accessible relays. We also expect that, if 1019 the service is deployed to enable a specific application, all the 1020 hosts that participate in the application and have adequate IPv4 1021 access will implement a host-based Teredo relay. 1023 5 Specification of clients, servers and relays 1025 The Teredo service is realized by having clients interact with 1026 Teredo servers through the Teredo service protocol. The clients will 1027 also receive IPv6 packets through Teredo relays. 1029 The Teredo server is designed to be stateless. It waits for Teredo 1030 requests and for IPv6 packets on the Teredo UDP port; it processes 1031 the requests by sending a response to the appropriate address and 1032 port; it forwards Teredo IPv6 packets to the appropriate IPv4 1033 address and UDP port. 1035 The Teredo relay advertises reachability of the Teredo service 1036 prefix over IPv6. It forwards Teredo IPv6 packets to the appropriate 1037 IPv4 address and UDP port. 1039 Teredo clients, servers and relays must implement the sunset 1040 procedure defined in section 5.5. 1042 5.1 Message formats 1044 5.1.1 Teredo IPv6 packets encapsulation 1046 Teredo IPv6 packets are transmitted as UDP packets [RFC768] within 1047 IPv4 [RFC791]. The source and destination IP addresses and UDP 1048 ports take values that are specified in this section. Packets can 1049 come in one of two formats, simple encapsulation and encapsulation 1050 with origin indication. 1052 When simple encapsulation is used, the packet will have a simple 1053 format, in which the IPv6 packet is carried as the payload of a UDP 1054 datagram: 1056 +------+-----+-------------+ 1057 | IPv4 | UDP | IPv6 packet | 1058 +------+-----+-------------+ 1060 When relaying packets received from third parties, the server may 1061 insert an origin indication in the first bytes of the UDP payload: 1063 +------+-----+-------------------+-------------+ 1064 | IPv4 | UDP | Origin indication | IPv6 packet | 1065 +------+-----+-------------------+-------------+ 1067 The origin indication encapsulation is an 8-octet element, with the 1068 following content: 1070 +--------+--------+-----------------+ 1071 | 0x00 | 0x00 | Origin port # | 1072 +--------+--------+-----------------+ 1073 | Origin IPv4 address | 1074 +-----------------------------------+ 1076 The first two octets of the origin indication are set to a null 1077 value; this is used to discriminate between the simple 1078 encapsulation, in which the first 4 bits of the packet contain the 1079 indication of the IPv6 protocol, and the origin indication. 1081 The following 16 bits contain the obfuscated value of the port 1082 number from which the packet was received, in network byte order. 1083 The next 32 bits contain the obfuscated IPv4 address from which the 1084 packet was received, in network byte order. In this format, both the 1085 original "IPv4 address" and "UDP port" of the client are obfuscated. 1086 Each bit in the address and port number is reversed; this can be 1087 done by an exclusive OR of the 16-bit port number with the 1088 hexadecimal value 0xFFFF, and an exclusive OR of the 32-bit address 1089 with the hexadecimal value 0xFFFFFFFF. 1091 For example, if the original UDP port number was 337 (hexadecimal 1092 0151) and original IPv4 address was 1.2.3.4 (hexadecimal: 01020304), 1093 the origin indication would contain the value "0000FEAEFEFDFCFB". 1095 When exchanging Router Solicitation and Router Advertisement 1096 messages between a client and its server, the packets may include an 1097 authentication parameter: 1099 +------+-----+----------------+-------------+ 1100 | IPv4 | UDP | Authentication | IPv6 packet | 1101 +------+-----+----------------+-------------+ 1103 The authentication encapsulation is a variable length-element, 1104 containing a client identifier, an authentication value, a nonce 1105 value, and a confirmation byte. 1107 +--------+--------+--------+--------+ 1108 | 0x00 | 0x01 | ID-len | AU-len | 1109 +--------+--------+--------+--------+ 1110 | Client identifier (ID-len | 1111 +-----------------+-----------------+ 1112 | octets) | Authentication | 1113 +-----------------+--------+--------+ 1114 | value (AU-len octets) | Nonce | 1115 +--------------------------+--------+ 1116 | value (8 octets | 1117 +--------------------------+--------+ 1118 | | Conf. | 1119 +--------------------------+--------+ 1121 The first octet of the authentication encapsulation is set to a null 1122 value, and the second octet is set to the value 1; this enables 1123 differentiation from IPv6 packets and from origin information 1124 indication encapsulation. The third octet indicates the length of 1125 the client identifier; the fourth octet indicates the length of the 1126 authentication value. The computation of the authentication value is 1127 specified in section 5.2.2. The authentication value is followed by 1128 an 8-octet nonce, and by a confirmation byte. 1130 Authentication and origin indication encapsulations may sometimes be 1131 combined, for example in the RA responses sent by the server. In 1132 this case, the authentication encapsulation MUST be the first 1133 element in the UDP payload: 1135 +------+-----+----------------+--------+-------------+ 1136 | IPv4 | UDP | Authentication | Origin | IPv6 packet | 1137 +------+-----+----------------+--------+-------------+ 1139 5.1.2 Maximum Transmission Unit 1141 Since Teredo uses UDP as an underlying transport, a Teredo 1142 Maximum Transmission Unit (MTU) could potentially be as large as the 1143 payload of the largest valid UDP datagram (65507 bytes). However, 1144 since Teredo packets can travel on unpredictable paths over the 1145 Internet, it is best to contain this MTU to a small size, in order 1146 to minimize the effect of IPv4 packet fragmentation and reassembly. 1147 The default link MTU assumed by a host, and the link MTU supplied by 1148 a Teredo server during router advertisement SHOULD normally be set 1149 to the minimum IPv6 MTU size of 1280 bytes [RFC2460]. 1151 Teredo implementations SHOULD NOT set the Don't Fragment (DF) bit of 1152 the encapsulating IPv4 header. 1154 5.2 Teredo Client specification 1156 Before using the Teredo service, the client must be configured with: 1158 - the IPv4 address of a server. 1160 If secure discovery is required, the client must also be configured 1161 with: 1163 - a client identifier, 1164 - a secret value, shared with the server. 1166 A Teredo client expects to exchange IPv6 packets through an UDP 1167 port, the Teredo service port. The client will maintain the 1168 following variables that reflect the state of the Teredo service: 1170 - Teredo connectivity status, 1171 - Mapped address and port number associated with the Teredo service 1172 port, 1173 - Teredo IPv6 prefix associated with the Teredo service port, 1174 - Teredo IPv6 address or addresses derived from the prefix, 1175 - Random link local address, 1176 - Date and time of the last interaction with the Teredo server, 1177 - Teredo Refresh Interval, 1178 - Randomized Refresh Interval, 1179 - List of recent Teredo peers. 1181 Before sending any packets, the client must perform the Teredo 1182 qualification procedure, which determines the Teredo connectivity 1183 status, the mapped address and port number, and the Teredo IPv6 1184 prefix; it should then perform the cone NAT determination procedure, 1185 which determines the cone NAT status and may alter the value of the 1186 prefix. If the qualification is successful, the client may use the 1187 Teredo service port to transmit and receive IPv6 packets, according 1188 to the transmission and reception procedures; these procedures use 1189 the "list of recent peers". For each peer, the list contains: 1191 - The IPv6 address of the peer, 1192 - The mapped IPv4 address and mapped UDP port of the peer, 1193 - The status of the mapped address, i.e. trusted or not, 1194 - The value of the last "nonce" sent to the peer, 1195 - The date and time of the last reception from the peer, 1196 - The date and time of the last transmission to the peer, 1197 - The number of bubbles transmitted to the peer. 1199 The list of peers is used to enable the transmission of IPv6 packets 1200 by using a "direct path" for the IPv6 packets. The list of peers 1201 could grow over time. Clients should implement a list management 1202 strategy, for example deleting the least recently used entries. 1203 Clients should make sure that the list has a sufficient size, to 1204 avoid unnecessary exchanges of bubbles. 1206 The client must regularly perform the maintenance procedure in order 1207 to guarantee that the Teredo service port remains usable; the need 1208 to use this procedure or not depends on the delay since the last 1209 interaction with the Teredo server. The refresh procedure takes as a 1210 parameter the "Teredo refresh interval". This parameter is initially 1211 set to 30 seconds; it can be updated as a result of the optional 1212 "interval determination procedure." The randomized refresh interval 1213 is set to a value randomly chosen between 75% and 100% of the 1214 refresh interval. 1216 In order to avoid triangle routing for stations that are located 1217 behind the same NAT, the Teredo clients MAY use the optional local 1218 client discovery procedure defined in section 5.2.8. 1220 5.2.1 Qualification procedure 1222 The purpose of the qualification procedure is to establish the 1223 status of the local IPv4 connection, and to determine the Teredo 1224 IPv6 client prefix of the local Teredo interface. The procedure 1225 starts when the service is in the "initial" state, and results in a 1226 "qualified" state if successful, and in an "off-line" state if 1227 unsuccessful. 1229 /---------\ 1230 | Initial | 1231 \---------/ 1232 | 1233 +----+----+ 1234 | Set d=1 | 1235 +----+----+ 1236 | 1237 +<-----------------------------------------+ 1238 | | 1239 +----+----+ | 1240 | Start |<------+ | 1241 +----+----+ | +----+----+ 1242 | | | Set C=0 | 1243 v | +----+----+ 1244 /---------\ Timer | ^ 1245 |Starting |-------+ N attempts /----------\ Yes | 1246 \---------/------------------->| C == 1 ? |-----+ 1247 | Response \----------/ 1248 | | No 1249 V V 1250 /---------\ Yes /----------\ 1251 | C == 0? |---------+ | Off line | 1252 \---------/ | \----------/ 1253 No | v 1254 | /----------\ 1255 | | Cone NAT | 1256 +-----+-----+ \----------/ 1257 | New Server| 1258 +-----+-----+ 1259 | 1260 +----+----+ 1261 | Start |<------+ 1262 +----+----+ | 1263 | | 1264 v | 1265 /---------\ Timer | 1266 |Starting |-------+ N attempts /----------\ 1267 \---------/------------------->| Off line | 1268 | Response \----------/ 1269 | 1270 V 1271 /------------\ No /---------------\ 1272 | Same port? |-------->| Symmetric NAT | 1273 \------------/ \---------------/ 1274 | Yes 1275 V 1276 /-----------------\ 1277 | Restricted NAT | 1278 \-----------------/ 1280 Initially, the Teredo connectivity status is set to "Initial". 1282 When the interface is initialized, the system first performs the 1283 "start action" by sending a Router Solicitation message, as defined 1284 in [RFC2461]. The client picks a link-local address and uses it as 1285 the IPv6 source of the message; the "cone" bit in the address is set 1286 to 1; the IPv6 destination of the RS is the all-routers multicast 1287 address; the packet will be sent over UDP from the service port to 1288 the Teredo server's IPv4 address and Teredo UDP port. The 1289 connectivity status moves then to "Starting". 1291 In the starting state, the client waits for a router advertisement 1292 from the Teredo server. If no response comes within a time-out T, 1293 the client should repeat the start action, by resending the Router 1294 Solicitation message. If no response has arrived after N 1295 repetitions, the client concludes that it is not behind a cone NAT. 1296 It sets the "cone" bit to 0, and repeats the procedure. If after N 1297 other timer expirations and retransmissions there is still no 1298 response, the client concludes that it cannot use UDP, and that the 1299 Teredo service is not available; the status is set to "Off-line." In 1300 accordance with [RFC2461], the default time-out value is set to T=4 1301 seconds, and the maximum number of repetitions is set to N=3. 1303 If a response arrives, the client checks that the response contains 1304 an origin indication and a valid router advertisement as defined in 1305 [RFC2461], that the IPv6 destination address is equal to the link- 1306 local address used in the router solicitation, and that the router 1307 advertisement contains exactly one advertised Prefix Information 1308 option. This prefix should be a valid Teredo IPv6 server prefix: the 1309 first 32 bits should contain the global Teredo IPv6 service prefix, 1310 and the next 32 bits should contain the server's IPv4 address. If 1311 this is the case, the client learns the Teredo mapped address and 1312 Teredo mapped port from the origin indication. The source address of 1313 the Router Advertisement is a link-local server address of the 1314 Teredo server. (Responses that are not valid advertisements are 1315 simply discarded.) 1317 If the client has received an RA with the "Cone" bit set to 1, it is 1318 behind a cone NAT and is fully qualified. If the RA is received with 1319 the Cone bit set to 0, the client does not know whether the local 1320 NAT is restricted or symmetric. The client selects a secondary IPv4 1321 server address, and repeats the procedure, the cone bit remaining to 1322 the value zero. If the client does not receive a response, it 1323 detects that the service is not usable. If the client receives a 1324 response, it compares the mapped address and mapped port in this 1325 second response to the first received values. If the values are 1326 different, the client detects a symmetric NAT: it cannot use the 1327 Teredo service. If the values are the same, the client is detects a 1328 restricted cone NAT: the client is qualified to use the service. 1330 If the client is qualified, it builds a Teredo IPv6 address using 1331 the Teredo IPv6 server prefix learned from the RA and the obfuscated 1332 values of the UDP port and IPv4 address learned from the origin 1333 indication. The cone bit should be set to the value used to receive 1334 the RA, i.e. 1 if the client is behind a cone NAT, 0 otherwise. The 1335 client can start using the Teredo service. 1337 5.2.2 Secure qualification 1339 The client may be required to perform secured qualification. The 1340 client will perform exactly the algorithm described in 5.2.1, but it 1341 will incorporate an authentication encapsulation in the UDP packet 1342 carrying the router solicitation message, and it will verify the 1343 presence of a valid authentication parameter in the UDP message that 1344 carries the router advertisement provided by the sender. 1346 In these packets, the nonce value is chosen by the client, and is 1347 repeated in the response from the server; the client identifier is a 1348 value with which the client was configured. The confirmation byte is 1349 set to 0 by the client. A null value returned by the server 1350 indicates that the client's key is still valid; a non-null value 1351 indicates that the client should obtain a new key. 1353 The authentication value is computed according to the HMAC 1354 specification [RFC2104] using the following specifications: 1356 - the hash function shall be the MD5 function [RFC1321]. 1357 - the secret value shall be the shared secret with which the client 1358 was configured 1360 The clear text to be protected includes: 1362 - the nonce value, 1363 - the confirmation byte, 1364 - the origin indication encapsulation, if it is present, 1365 - the IPv6 packet. 1367 If the HMAC verification fails, the packet is silently discarded. 1369 5.2.3 Packet reception 1371 The Teredo client receives packets over the Teredo interface. The 1372 role of the packet reception procedure, besides receiving packets, 1373 is to maintain the date and time of the last interaction with the 1374 Teredo server, and the "list of recent peers." 1376 When a UDP packet is received over the Teredo service port, the 1377 Teredo client checks that it is encoded according to the packet 1378 encoding rules defined in 5.1.1, and that it contains either a valid 1379 IPv6 packet as specified in [RFC2460], or the combination of a valid 1380 origin indication encapsulation and a valid IPv6 packet, possibly 1381 protected by a valid authentication encapsulation. If this is not 1382 the case, the packet is silently discarded. 1384 Then, the Teredo client examines the IPv4 source address and UDP 1385 port number from which the packet is received. If these values match 1386 the IPv4 address of the server and the Teredo port, the client 1387 updates the "date and time of the last interaction with the Teredo 1388 server" to the current date and time; if an origin indication is 1389 present, the client should perform the "direct IPv6 connectivity 1390 test" described in section 5.2.9. 1392 If the values are different, the client examines the IPv6 source 1393 address of the packet: 1395 1) If there is an entry for the source IPv6 address in the list of 1396 peers whose status is trusted, the client compares the mapped IPv4 1397 address and mapped port in the entry with the source IPv4 address 1398 and source port of the packet. If the values match, the packet 1399 should be accepted; the date and time of the last reception from the 1400 peer should be updated. 1402 2) If there is an entry for the source IPv6 address in the list of 1403 peers whose status is not trusted, the client checks whether the 1404 packet is an ICMPv6 echo reply. If this is the case, and if the 1405 content of the reply matches the "nonce" stored in the peer entry, 1406 the packet should be accepted; the status of the entry should be 1407 changed to "trusted", the mapped IPv4 and mapped port in the entry 1408 should be set to the source IPv4 address and source port from which 1409 the packet was received, and the date and time of the last reception 1410 from the peer should be updated; any packet queued for this IPv6 1411 peer should be de-queued and forwarded to the newly learned IPv4 1412 address and UDP port. 1414 3) If the source IPv6 address is a Teredo address, the client 1415 compares the mapped IPv4 address and mapped port in the source 1416 address with the source IPv4 address and source port of the packet. 1417 If the values match, the client MUST create a peer entry for the 1418 IPv6 source address in the list of peers; it should update the entry 1419 if one already existed; the mapped IPv4 address and mapped port in 1420 the entry should be set to the value from which the packet was 1421 received, and the status should be set to "trusted". If a new entry 1422 is created, the last transmission date is set to 30 seconds before 1423 the current date, and the number of bubbles to zero. If the packet 1424 is a bubble, it should be discarded after this processing; 1425 otherwise, the packet should be accepted. In all cases, the client 1426 must de-queue and forward any packet queued for that destination. 1428 4) If the IPv4 destination address through which the packet was 1429 received is the Teredo IPv4 Discovery Address, the source address is 1430 a valid Teredo address, and the destination address is the "all 1431 nodes on link" multicast address, the packet should be treated as a 1432 local discovery bubble. The client SHOULD create a new peer entry 1433 for the IPv6 source address; the mapped IPv4 address and mapped port 1434 in the entry should be set to the value from which the packet was 1435 received, and the status should be set to "trusted". However, 1436 clients MAY decide to only accept local discovery bubbles if the 1437 mapped IPv4 address included in the IPv6 source address is the same 1438 as the mapped IPv4 address of the client. 1440 5) In the other cases, the packet may be accepted, but the client 1441 should be conscious that the source address may be spoofed; before 1442 processing the packet, the client should perform the "direct IPv6 1443 connectivity test" described in section 5.2.9. 1445 Whatever the IPv4 source address and UDP source port, the client 1446 that receives an IPv6 packet MAY send a Teredo bubble towards that 1447 target, as specified in section 5.2.6. 1449 5.2.4 Packet transmission 1451 When a Teredo client has to transmit a packet over a Teredo 1452 interface, it examines the destination IPv6 address. The client 1453 checks first if there is an entry for this IPv6 address in the list 1454 of recent Teredo peers, and if the entry is still valid: an entry 1455 associated with a local peer is valid if the last reception date and 1456 time associated with that list entry is less that 600 seconds from 1457 the current time; an entry associated with a non-local peer is valid 1458 if the last reception date and time associated with that list entry 1459 is less that 30 seconds from the current time. (Local peer entries 1460 can only be present if the client uses the local discovery procedure 1461 discussed in section 5.2.8.) 1463 The client then performs the following: 1465 1) If there is an entry for that IPv6 address in the list of peers, 1466 and if the status of the entry is set to "trusted", the IPv6 packet 1467 should be sent over UDP to the mapped IPv4 address and mapped UDP 1468 port of the entry. The client updates the date of last transmission 1469 in the peer entry. 1471 2) If the destination is not a Teredo IPv6 address, the packet is 1472 queued, and the client performs the "direct IPv6 connectivity test" 1473 described in section 5.2.8. The packet will be de-queued and 1474 forwarded if this procedure completes successfully. If the direct 1475 IPv6 connectivity test fails to complete within a 2 second time-out, 1476 it should be repeated up to 3 times. 1478 3) If the destination is a Teredo IPv6 address in which the cone bit 1479 is set to 1, the packet is sent over UDP to the mapped IPv4 address 1480 and mapped UDP port extracted from that IPv6 address. 1482 4) If the destination is a Teredo IPv6 address in which the cone bit 1483 is set to 0, the packet is queued. If the client is not located 1484 behind a cone NAT, it sends a direct bubble to the Teredo 1485 destination, i.e. to the mapped IP address and mapped port of the 1486 destination. In all cases, the client sends an indirect bubble to 1487 the Teredo destination, sending it over UDP to the server address 1488 and to the Teredo port. The packet will be de-queued and forwarded 1489 when the client receives a bubble or another packet directly from 1490 this Teredo peer. If no bubble is received within a 2 second time- 1491 out, the bubble transmission should be repeated up to 3 times. 1493 In cases 3 and 4, before sending a packet over UDP, the client MUST 1494 check that the IPv4 destination address is in the format of a global 1495 unicast address; if this is not the case, the packet MUST be 1496 silently discarded. (Note that a packet can legitimately be sent to 1497 a non-global unicast address in case 1, as a result of the local 1498 discovery procedure.) 1500 5.2.5 Maintenance 1502 The Teredo client must ensure that the mappings that it uses remain 1503 valid. It does so by checking that packets are regularly received 1504 from the Teredo server. 1506 At regular intervals, the client MUST check the "date and time of 1507 the last interaction with the Teredo server", to ensure that at 1508 least one packet has been received in the last Randomized Teredo 1509 Refresh Interval. If this is not the case, the client SHOULD select 1510 a new randomized link-local address and use this address to send a 1511 router solicitation message to the server, as specified in 5.2.1; 1512 the client should use the same value of the "cone" bit that resulted 1513 in the reception of an RA during the qualification procedure. 1515 When the router advertisement is received, the client SHOULD check 1516 its validity as specified in 5.2.1; invalid advertisements are 1517 silently discarded. If the advertisement is valid, the client MUST 1518 check that the mapped address and port correspond to the current 1519 Teredo address. If this is not the case, the mapping has changed; 1520 the client must mark the old address as invalid, and start using the 1521 new address. 1523 5.2.6 Sending Teredo Bubbles 1525 The Teredo client may have to send a bubble towards another Teredo 1526 client, either after a packet reception or after a transmission 1527 attempt, as explained in sections 5.2.3 and 5.2.4. 1529 When a Teredo client attempts to send a bubble, it extracts the 1530 mapped IPv4 address and mapped UDP port from the Teredo IPv6 address 1531 of the target. It then checks whether there is already an entry for 1532 this IPv6 address in the current list of peers. If there is no 1533 entry, the client MUST create a new list entry for the address, 1534 setting the last reception date and the last transmission date to 30 1535 seconds before the current date, and the number of bubbles to zero. 1537 Bubbles may be lost in transit, and it is reasonable to enhance the 1538 reliability of the Teredo service by allowing multiple 1539 transmissions; however, bubbles will also be lost systematically in 1540 certain NAT configurations. In order to strike a balance between 1541 reliability and unnecessary retransmissions, we specify the 1542 following: 1544 - If the client implements the local discovery procedure it SHOULD 1545 NOT send a bubble to a local peer; 1547 - The client MUST NOT send a bubble if the last transmission date 1548 and time is less than 2 seconds before the current date and time; 1550 - The client MUST NOT send a bubble if it has already sent 4 bubbles 1551 to the peer in the last 300 seconds without receiving a direct 1552 response. 1554 In the other cases, the client MAY proceed with the transmission of 1555 the bubble. When transmitting the bubble, the client MUST update the 1556 last transmission date and time to that peer, and must also 1557 increment the number of transmitted bubbles. 1559 5.2.7 Optional Refresh Interval Determination Procedure 1561 In addition to the regular client resources described in the 1562 beginning of this section, the refresh interval determination 1563 procedure uses an additional UDP port, the Teredo secondary port, 1564 and the following variables: 1566 - Teredo secondary connectivity status, 1567 - Mapped address and port number of the Teredo secondary port, 1568 - Teredo secondary IPv6 prefix associated with the secondary port, 1569 - Teredo secondary IPv6 address derived from this prefix, 1570 - Date and time of the last interaction on the secondary port, 1571 - Maximum Teredo Refresh Interval. 1572 - Candidate Teredo Refresh Interval. 1574 The secondary connectivity status, mapped address and prefix are 1575 determined by running the qualification procedure on the secondary 1576 port. When the client uses the interval determination procedure, the 1577 qualification procedure MUST be run for the secondary port 1578 immediately after running it on the service port. If the secondary 1579 qualification fails, the interval determination procedure will not be 1580 used, and the interval value will remain to the default value, 30 1581 seconds. If the secondary qualification succeeds, the maximum refresh 1582 interval is set to 120 seconds, and the candidate Teredo refresh 1583 interval is set to 60 seconds, i.e. twice the Teredo refresh 1584 interval. The procedure is then performed at regular intervals, until 1585 it concludes: 1587 1) wait until the candidate refresh interval is elapsed after the 1588 last interaction on the secondary port; 1590 2) send a Teredo bubble to the Teredo secondary IPv6 address, through 1591 the service port. 1593 3) wait for reception of the bubble on the secondary port. If a timer 1594 of 2 seconds elapses without reception, repeat step 2 at most three 1595 times. If there is still no reception, the candidate has failed; if 1596 there is a reception, the candidate has succeeded. 1598 4) if the candidate has succeeded, set the Teredo refresh interval to 1599 the candidate value, and set a new candidate value to the minimum of 1600 twice the new refresh interval, or the average of the refresh 1601 interval and the maximum refresh interval. 1603 5) if the candidate has failed, set the maximum refresh interval to 1604 the candidate value. If the current refresh interval is larger than 1605 or equal to 75% of the maximum, the determination procedure has 1606 concluded; otherwise, set a new candidate value to the average of the 1607 refresh interval and the maximum refresh interval. 1609 6) if the procedure has not concluded, perform the maintenance 1610 procedure on the secondary port, which will reset the date and time 1611 of the last interaction on the secondary port, and may result in the 1612 allocation of a new Teredo secondary IPv6 address; this would not 1613 affect the values of the refresh interval, candidate interval or 1614 maximum refresh interval. 1616 The secondary port MUST NOT be used for any other purpose than the 1617 interval determination procedure. If a spurious packet is received on 1618 the secondary port, the client SHOULD repeat the maintenance 1619 procedure on this port and reset the date and time of the last 1620 interaction on the secondary port. 1622 5.2.8 Optional local client discovery procedure 1624 It is desirable to enable direct communication between Teredo 1625 clients that are located behind the same NAT, without forcing a 1626 systematic relay through a Teredo server. It is hard to design a 1627 general solution to this problem, but we can design a partial 1628 solution when the Teredo clients are connected through IPv4 to the 1629 same link. 1631 A Teredo client who wishes to enable local discovery SHOULD wait for 1632 discovery bubbles to be received on the Teredo IPv4 Discovery 1633 Address, and should send local discovery bubbles to the Teredo IPv4 1634 Discovery Address at random intervals, uniformly distributed between 1635 200 and 300 seconds. A local Teredo bubble has the following 1636 characteristics: 1638 - IPv4 source address: the IPv4 address of the sender 1640 - IPv4 destination address: the Teredo IPv4 Discovery Address 1642 - IPv4 ttl: 1 1643 - UDP source port: the Teredo service port of the sender 1645 - UDP destination port: the Teredo UDP port 1647 - UDP payload: a minimal IPv6 packet, as follows 1649 - IPv6 source: the Teredo IPv6 address of the sender 1651 - IPv6 destination: the all-nodes on-link multicast address 1653 - IPv6 payload type: 59 (No Next Header, as per [RFC2460]) 1655 - IPv6 payload length: 0 1657 - IPv6 hop limit: 1 1659 The local discovery procedure carries a denial of service risk, as 1660 malevolent nodes could send fake bubbles to unsuspecting parties, 1661 and thus capture the traffic originating from these parties. The 1662 risk is mitigated by the filtering rules described in section 5.2.5, 1663 and also by "link only" multicast scope of the Teredo IPv4 Discovery 1664 Address, which implies that packets sent to this address will not be 1665 forwarded across routers. 1667 To benefit from the "link only multicast" protection, the clients 1668 should silently discard all local discovery bubbles that are 1669 received over a unicast address. To further mitigate the denial of 1670 service risk, the client MUST silently discard all local discovery 1671 bubbles whose IPv6 source address is not a well-formed Teredo IPv6 1672 address, or whose IPv4 source address does not belong to the local 1673 IPv4 subnet; the client MAY decide to silently discard all local 1674 discovery bubbles whose Teredo IPv6 address do not include the same 1675 mapped IPv4 address as its own. 1677 If the bubble is accepted, the client checks whether there is an 1678 entry in the list of recent peers that correspond to the mapped IPv4 1679 address and mapped UDP port associated with the source IPv6 address 1680 of the bubble. If there is such an entry, the client MUST update the 1681 local peer address and local peer port parameters to reflect the 1682 IPv4 source address and UDP source port of the bubble. If there is 1683 no entry, the client MUST create one, setting the local peer address 1684 and local peer port parameters to reflect the IPv4 source address 1685 and UDP source port of the bubble the last reception date to the 1686 current date and time, the last transmission date to 30 seconds 1687 before the current date, and the number of bubbles to zero. 1689 5.2.9 Direct IPv6 connectivity test 1691 The Teredo procedures are designed to enable direct connections 1692 between a Teredo host and a Teredo relay. Teredo hosts located 1693 behind a cone NAT will receive packets directly from relays; other 1694 Teredo hosts will learn the original addresses and UDP ports of 1695 third parties through the local Teredo server. In all of these 1696 cases, there is a risk that the IPv6 address of the source be 1697 spoofed by a malevolent party. Teredo hosts must make two decisions, 1698 whether to accept the packet for local processing, and whether to 1699 transmit further packets to the IPv6 address through the newly 1700 learned IPv4 address and UDP port. The basic rule is that the hosts 1701 should be generous in what they accept, and careful in what they 1702 send. Refusing to accept packets due to spoofing concerns would 1703 compromise connectivity, and should only be done when there is a 1704 near certainty that the source address is spoofed; on the other 1705 hand, sending packets to the wrong address should be avoided. 1707 When it wants to send a packet to an IPv6 node on the IPv6 Internet, 1708 the client should check whether a valid peer entry already exists 1709 for the IPv6 address of the destination. If this is not the case, 1710 the client will pick a random number (a nonce) and format an ICMPv6 1711 Echo Request message whose source is the local Teredo address, whose 1712 destination is the address of the IPv6 node, and whose Data field is 1713 set to the nonce. The nonce value and the date at which the packet 1714 was sent will be documented in a provisional peer entry for the IPV6 1715 destination. The ICMPv6 packet will then be sent encapsulated in a 1716 UDP packet bound to the local server IPv4 address, and to the Teredo 1717 port. The rules of section 5.2.3 specify how the reception of this 1718 packet will be processed. 1720 5.3 Teredo Server specification 1722 The Teredo server is designed to be stateless. The Teredo server 1723 waits for incoming UDP packets at the Teredo Port, using the IPv4 1724 address that has been selected for the service. 1726 The Teredo server acts as an IPv6 router. As such, it will receive 1727 Router Solicitation messages, to which it will respond with Router 1728 Advertisement messages as explained in section 5.3.2; it may also 1729 receive other packets, for example ICMPv6 messages, which are 1730 processed according to the IPv6 specification. 1732 5.3.1 Processing of Teredo IPv6 packets 1734 Upon reception of a packet on the Teredo port, the Teredo server 1735 will first check that the UDP payload contains a valid IPv6 packet; 1736 if this is not the case, the packet will be silently discarded. 1738 Before processing the packet, the Teredo server MUST check the 1739 validity of the encapsulated IPv6 source address, the IPv4 source 1740 address and the UDP source port: 1742 1) If the UDP content is not a well formed IPv6 packet, the packet 1743 MUST be silently discarded. 1745 2) If the UDP packet is not a bubble or an ICMPv6 message, it should 1746 be discarded. 1748 3) If the IPv4 source address is not in the format of a global 1749 unicast address, the packet MUST be silently discarded. 1751 4) If the IPv6 source address is an IPv6 link-local address, the 1752 IPv6 destination address is the link-local scope all routers 1753 multicast address (FF02::2), and the packet contains an ICMPv6 1754 Router Solicitation message, the packet SHOULD be accepted; it 1755 MUST be discarded if the server requires secure qualification and 1756 the authentication encapsulation is absent or cannot be verified. 1758 5) If the IPv6 source address is a Teredo IPv6 address, and if the 1759 IPv4 address and UDP port embedded in that address match the IPv4 1760 source address and UDP source port, the packet SHOULD be 1761 accepted. 1763 6) If the IPv6 source address is not a Teredo IPv6 address, and if 1764 the IPv6 destination address is a Teredo address allocated 1765 through this server, the packet SHOULD be accepted. 1767 7) In all other cases, the packet MUST be silently discarded. 1769 The Teredo server will then check the IPv6 destination address of 1770 the encapsulated IPv6 packet. 1772 If the IPv6 destination address is the link-local scope all routers 1773 multicast address (FF02::2), or the link-local address of the 1774 server, the Teredo server processes the packet; it may have to 1775 process Router Solicitation messages and ICMPv6 Echo Request 1776 messages. If the destination IPv6 address is not a global scope IPv6 1777 address, the packet MUST NOT be forwarded. 1779 If the destination address is not a Teredo IPv6 address, the packet 1780 should be relayed to the IPv6 Internet using regular IPv6 routing. 1782 If the IPv6 destination address is a valid Teredo IPv6 address, the 1783 Teredo Server MUST check that the IPv4 address derived from this 1784 IPv6 address is in the format of a global unicast address; if this 1785 is not the case, the packet MUST be silently discarded. 1787 If the address is valid, the Teredo server encapsulates the IPv6 1788 packet in a new UDP datagram, in which the following parameters are 1789 set: 1791 - The destination IPv4 address is derived from the IPv6 destination. 1793 - The source IPv4 address is the server's IPv4 address. 1795 - The destination UDP port is derived from the IPv6 destination. 1797 - The source UDP port is set to the Teredo UDP Port. 1799 If the destination IPv6 address is a Teredo client whose address is 1800 serviced by this specific server, the server should insert an origin 1801 indication in the first bytes of the UDP payload, as specified in 1802 section 5.1.1. 1804 5.3.2 Processing of router solicitations 1806 When the Teredo server receives a Router Solicitation message (RS, 1807 [RFC2641]), it retains the IPv4 address and UDP port from which the 1808 solicitation was received; these become the Teredo mapped address 1809 and Teredo mapped port of the client. The router uses these values 1810 to compose the origin indication encapsulation that will be sent 1811 with the response to the solicitation. 1813 The Teredo server responds to the router solicitation by sending a 1814 Router Advertisement message [RFC2641]. The router advertisement 1815 MUST advertise the Teredo IPv6 prefix composed from the service 1816 prefix and the server's IPv4 address. The IPv6 source address should 1817 be set to a Teredo link-local server address associated to the local 1818 interface. The IPv6 destination address is set to the IPv6 source 1819 address of the RS. The Router Advertisement message must be sent 1820 over UDP to the Teredo mapped address and Teredo mapped port of the 1821 client; the IPv4 source address and UDP source port should be set to 1822 the server's IPv4 address and Teredo Port. If the cone bit of the 1823 client's IPv6 address is set to 1, the RA must be sent from a 1824 different IPv4 source address than the server address over which the 1825 RS was received; if the cone bit is set to zero, the response must 1826 be sent back from the same address. 1828 Before sending the packet, the Teredo server MUST check that the 1829 IPv4 destination address is in the format of a global unicast 1830 address; if this is not the case, the packet MUST be silently 1831 discarded. 1833 If secure qualification is required, the server must insert a valid 1834 authentication parameter in the UDP packet carrying the router 1835 advertisement. The client identifier and the nonce value used in the 1836 authentication parameter must be the same identifier as received in 1837 the router solicitation; the confirmation byte should be set to zero 1838 if the client identifier is still valid, and a non-null value 1839 otherwise; the authentication value should be computed using the 1840 secret that corresponds to the client identifier. 1842 5.4 Teredo Relay specification 1844 Teredo relays are IPv6 routers that advertise reachability of the 1845 Teredo service IPv6 prefix through the IPv6 routing protocols. 1846 Teredo relays will receive IPv6 packets bound to Teredo clients. 1847 Teredo relays should be able to receive packets sent over IPv4 and 1848 UDP by Teredo clients; they may apply filtering rules, e.g. only 1849 accept packets from Teredo clients if they have previously sent 1850 traffic to these Teredo clients. 1852 The receiving and sending rules used by Teredo relays are very 1853 similar to those of Teredo clients. Teredo relays must use a Teredo 1854 service port to transmit packets to Teredo clients; they must 1855 maintain a "list of peers", identical to the list of peers 1856 maintained by Teredo clients. However, Teredo relays do not have to 1857 perform the qualification procedure. 1859 5.4.1 Transmission by relays to Teredo clients 1861 When a Teredo relay has to transmit a packet to a Teredo client, it 1862 examines the destination IPv6 address. By definition, the Teredo 1863 relays will only send over UDP IPv6 packets whose IPv6 destination 1864 address is a valid Teredo IPv6 address. Before processing these 1865 packets, the Teredo Server MUST check that the IPv4 destination 1866 address embedded in the Teredo IPv6 address is in the format of a 1867 global unicast address; if this is not the case, the packet MUST be 1868 silently discarded. 1870 The relay then checks if there is an entry for this IPv6 address in 1871 the list of recent Teredo peers, and if the entry is still valid. 1872 The relay then performs the following: 1874 1) If there is an entry for that IPv6 address in the list of peers, 1875 and if the status of the entry is set to "trusted", the IPv6 packet 1876 should be sent over UDP to the mapped IPv4 address and mapped UDP 1877 port of the entry. The client updates the date of last transmission 1878 in the peer entry. 1880 2) If the destination is a Teredo IPv6 address in which the cone bit 1881 is set to 1, the packet is sent over UDP to the mapped IPv4 address 1882 and mapped UDP port extracted from that IPv6 address. 1884 3) If the destination is a Teredo IPv6 address in which the cone bit 1885 is set to 0, the packet is queued. The Teredo relay creates a bubble 1886 whose source address is set to a local IPv6 address, and whose 1887 destination address is set to the Teredo IPv6 address of the 1888 packet's destination. The bubble is sent to the non-null server 1889 address corresponding to the Teredo destination. The packet will be 1890 de-queued and forwarded when a bubble or another packet will be 1891 received from this IPv6 address; if no such packet is received 1892 before a time-out of 2 seconds, the Teredo relay may repeat the 1893 bubble, up to three times. 1895 In cases 2 and 3, the Teredo relay should create a peer entry for 1896 the IPv6 address; the entry status is marked as trusted in case 2 1897 (cone NAT), not trusted in case 3. In case 3, if the Teredo relay 1898 happens to be located behind a non-cone NAT, it should also send a 1899 bubble directly to the mapped IPv4 address and mapped port number of 1900 the Teredo destination; this will "open the path" for the return 1901 bubble from the Teredo client. 1903 5.4.2 Reception from Teredo clients 1905 The Teredo relay may receive packets from Teredo clients; the 1906 packets should normally only be sent by clients to which the relay 1907 previously transmitted packets, i.e. clients whose IPv6 address is 1908 present in the list of peers. Relays, like clients, use the packet 1909 reception procedure to maintain the date and time of the last 1910 interaction with the Teredo server, and the "list of recent peers." 1912 When a UDP packet is received over the Teredo service port, the 1913 Teredo relay checks that it contains a valid IPv6 packet as 1914 specified in [RFC2460]. If this is not the case, the packet is 1915 silently discarded. 1917 Then, the Teredo relay examines whether the IPv6 source address is a 1918 valid Teredo address, and if the mapped IPv4 address and mapped port 1919 match the IPv4 source address and port number from which the packet 1920 is received. If this is not the case, the packet is silently 1921 discarded. 1923 The Teredo relay then examines whether there is an entry for the 1924 IPv6 source address in the list of recent peers. If this is not the 1925 case, the packet may be silently discarded. If this is the case, the 1926 entry status is set to "trusted"; the relay updates the "date and 1927 time of the last interaction" to the current date and time. 1929 Finally, the relay examines the destination IPv6 address. If the 1930 destination is the "all nodes multicast address", the packet should 1931 be processed locally. If the destination belongs to a range of IPv6 1932 addresses served by the relay, the packet SHOULD be accepted, and 1933 forwarded to the destination. In the other cases, the packet SHOULD 1934 be silently discarded. 1936 5.4.3 Difference between Teredo Relays and Teredo Servers 1938 Because Teredo servers can relay Teredo packets over IPv6, all 1939 Teredo servers must be capable of behaving as Teredo relays. There 1940 is however no requirement that Teredo relays behave as Teredo 1941 servers. 1943 The dual-role of server and relays implies an additional complexity 1944 for the programming of servers: the processing of incoming packets 1945 should be a combination of the server processing rules defined in 1946 5.3.1, and the relay processing rules defined in 5.4.2. 1948 5.5 Implementation of automatic sunset 1950 Teredo is designed as an interim transition mechanism, and it is 1951 important that it should not be used any longer than necessary. The 1952 "sunset" procedure will be implemented by Teredo clients, servers 1953 and relays, as specified in this section. 1955 The Teredo-capable nodes MUST NOT behave as Teredo clients if they 1956 already have IPv6 connectivity through any other means, such as 1957 native IPv6 connectivity; in particular, nodes that have a global 1958 IPv4 address SHOULD obtain connectivity through the 6to4 service 1959 rather than through the Teredo service. The classic reason why a 1960 node that does not need connectivity would still enable the Teredo 1961 service is to guarantee good performance when interacting with 1962 Teredo clients; however, a Teredo-capable node that has IPv4 1963 connectivity and that has obtained IPv6 connectivity outside the 1964 Teredo service MAY decide to behave as a Teredo relay, and still 1965 obtain good performance when interacting with Teredo clients. 1967 The Teredo servers are expected to participate in the sunset 1968 procedure by announcing a date at which they will stop providing the 1969 service. This date depends on the availability of alternative 1970 solutions to their clients, such as "dual-mode" gateways that behave 1971 simultaneously as IPv4 NATs and IPv6 routers. Most Teredo servers 1972 will not be expected to operate more than a few years, perhaps until 1973 at most 2006. 1975 Teredo relays are expected to have the same life span as Teredo 1976 servers. 1978 6 Discussion of the solution 1980 This section is an attempt at answering various questions about the 1981 design choices. 1983 6.1 Why do we require address obfuscation? 1985 The Teredo address, as specified in section 4.1.1, include an 1986 obfuscated copy of the mapped IPv4 address and UDP port of the 1987 client. This is done to prevent abusive NAT "smartness." We have 1988 experimental evidence that some NATs, probably in a desire to help 1989 applications operate more transparently across NATs, are programmed 1990 to look for occurrence of a 32-bit value that matches their local 1991 address, and to replace any such value by the local IP address 1992 allocated to the client; some may also attempt to translate the port 1993 values; this treatment is performed by some NATs even if they don't 1994 know the details of the application protocol. By obfuscating the 1995 address and port, we prevent the NAT from recognizing their own IPv4 1996 address in the UDP packets exchanged between client and server, and 1997 avoid the errors caused by a possible rewriting. 1999 6.2 Why do we have bubbles and lists of peers? 2001 Our algorithm is designed to provide robustness: the client will 2002 always wait for a successful bubble or packet reception before 2003 transmitting data packets over UDP. This ensures that data packets 2004 will always be transmitted on a direct path to another Teredo 2005 client, or on a direct path to the Teredo relay nearest from an IPv6 2006 peer. 2008 6.3 Why do servers only process bubbles and ICMPv6 messages? 2010 In this specification, Teredo servers are requested to only forward 2011 some minimal packets: initial bubbles between Teredo clients, ICMPv6 2012 messages between Teredo clients and IPv6 peers. This has two 2013 advantages: it greatly reduces the transmission load of servers, and 2014 it also helps in solving some the security issues. 2016 Restricting the traffic to a few bubbles means that the server will 2017 only have to carry a few hundred bits of data for any exchange 2018 between clients and peers. Previous designs allowed transmission of 2019 data through the server, which placed the server at risk: a lazily 2020 programmed client could skip sending bubbles, and send all its 2021 traffic through the server. 2023 Restricting the server to only carry bubbles and ICMPv6 packets 2024 removes a privacy risk: if servers were allowed to carry data, a 2025 client could be convinced to send all its data through a rogue 2026 server, where it could easily be observed. With our design, a server 2027 does not see any actual data, and thus poses a much reduced privacy 2028 risk to its clients. 2030 Restricting the type of packets that a server can relay also reduces 2031 another security risk, the use of the server as a reflection point 2032 in a denial of service attack. An attacker can induce a server to 2033 reflect packets towards a third party, but the structure of these 2034 packets is very limited, which prevents the use of the server in a 2035 "magic packet" attack. 2037 6.4 What if two clients are behind the same NAT? 2039 Our design choice implies some restrictions in the Teredo service. 2040 The first restriction concerns two clients connected to the Internet 2041 through the same NAT. 2043 .----------------------- 2044 | Private network 2045 .--. src=9.0.0.1:4096 .-----. .----------. 2046 (IPv4) src=9.0.0.1:4097;| NAT | | Teredo | 2047 (Internet)<-------------- | BOX | <-- | Client-1 | 2048 ( ) (UDP tunneled | | <. '----------' 2049 '--' IPv6) '-----' | 10.0.0.2:1234 2050 | 9.0.0.1 | | .----------. 2051 | | | | Teredo | 2052 | | '- | Client-2 | 2053 V | '----------' 2054 .--------------. | 10.0.0.3:1234 2055 | Teredo | '----------------------- 2056 | Server | 2057 '--------------' 2059 The first client uses the private address and port 10.0.0.2:1234, 2060 which is mapped to 9.0.0.1:4096 by the NAT; the second client uses 2061 10.0.0.3:1234, mapped to 9.0.0.1:4097. If the first client tries to 2062 send a direct packet to the second client, that packet will be 2063 routed to the address 9.0.0.1:4097, i.e. to the external IP address 2064 of the local NAT. There is no guarantee that the NAT will be able to 2065 correctly process these packets; there is indeed some possibility 2066 that they may be lost, and that the two clients will not be able to 2067 communicate using Teredo. 2069 We deliberately accept this restriction, as the alternative would be 2070 to relay the traffic between the two internal clients through the 2071 Teredo server. Since the clients are located behind the same NAT, in 2072 the same domain, there is a risk that the clients might exchange 2073 sensitive data without necessarily using proper protection; sending 2074 this data over the Internet to the Teredo server would expose the 2075 clients to a significant risk of information disclosure. 2077 6.5 What about symmetric NAT? 2079 The exchange of bubbles will fail if one of the Teredo clients is 2080 located behind a symmetric NAT; in practice, this means that clients 2081 located behind a symmetric NAT should not use Teredo. 2083 6.6 Do we need the Refresh Interval Determination Procedure? 2085 When the client is initialized, the Teredo Refresh Interval is set 2086 to 30 seconds. This value is lower than the minimum interval found 2087 necessary in a measurement campaign conducted by a Microsoft team in 2088 January 2001; the measured values ranged between 45 seconds and more 2089 than 15 minutes. There is always a risk that some NAT manufacturers 2090 program some ever smaller time to live intervals for their mappings, 2091 but doing so would break many applications and would probably 2092 generate an uproar from Internet users. By picking a conservatively 2093 small value, we guarantee that the service will work with most NATs. 2095 On the other hand, picking a conservative value increases the 2096 maintenance traffic and the load on the Teredo servers. We know that 2097 in many cases interval as large as 5 or 10 minutes would be 2098 adequate; however, we also know that there is a high risk of false 2099 positives, e.g. when a NAT is connected by an ISDN "on demand" link. 2100 The determination procedure is designed to quickly find whether a 2101 value larger than 30 seconds is adequate, while not trying to 2102 achieve a value larger than 2 minutes. The parameters have been 2103 chosen for rapid convergence, i.e. at most 3 iterations between the 2104 initial value of 30 seconds and the maximum value of 120 seconds or 2105 2 minutes. 2107 6.7 Why do we use a Randomized Refresh Interval? 2109 We specify in the maintenance procedure that the interval between 2110 successive refresh must be a random value chosen between 75% and 2111 100% of the Teredo Refresh Interval. This randomization procedure is 2112 meant to avoid the possible risk of synchronization that is inherent 2113 to any periodic refresh mechanism; if synchronization occurred, all 2114 Teredo clients would send their router solicitation messages quasi 2115 simultaneously to the Teredo server, which would overwhelm the 2116 server. A synchronization phenomenon caused by periodic messages is 2117 studied in [SYNCHRO]; the 75%-100% interval is meant to meet the 2118 guidelines developed in this reference publication. 2120 6.8 Scaling, failover and access control 2122 The Teredo service is designed to impose minimal requirements on 2123 servers and relays: capability to send packets over IPv4 using a 2124 regular IPv4 address; capability to send and receive packets over 2125 IPv6; capability to advertise reachability of the Teredo service 2126 prefix in at least some limited scope. These minimal requirements 2127 make it easy to deploy a large number of servers and relays, thus 2128 ensuring scalability of the service. 2130 Teredo clients may obtain a more resilient service if they can use 2131 several different servers. Teredo clients will detect that a server 2132 is failing through the failure of the qualification procedure; they 2133 may try at that point to obtain services from a different server. 2135 6.9 What about firewalls? 2137 The Teredo service is not designed to "transparently traverse 2138 firewalls." A local administrator can decide to allow or disallow 2139 the service, by programming the local firewall to authorize or deny 2140 traffic on the Teredo UDP port. 2142 Implementations of Teredo should include an administrative control 2143 that explicitly enables use of the Teredo service; the service 2144 should not start if not explicitly authorized. 2146 Implementations of Teredo should be configured to shut down the 2147 Teredo service when the Teredo client is connected within a "managed 2148 network", such as an enterprise network. For example, the 2149 implementation of Teredo in Microsoft Windows is configured to shut 2150 down the Teredo service if the client is a member of a Windows 2151 domain. 2153 6.10 Why do we use the name Teredo? 2155 "Teredo navalis" is the Latin name for a little saltwater critter 2156 that is common in the harbors of warm seas and that digs worm holes 2157 in immersed wood pieces, such as boat hulls or pilings. The animal 2158 is not an actual worm - it is a mollusk. The Teredo service also 2159 digs holes, albeit in NATs, not in wood. 2161 On one hand, one may think that the Teredo is a pretty nasty animal. 2162 On the other hand, the animal only survives in relatively clean and 2163 unpolluted water; its recent comeback in several North American 2164 harbors is a testimony to their newly retrieved cleanliness. The 2165 Teredo service should, in turn, contribute to a newly retrieved 2166 transparency of the Internet. 2168 7 Use of Teredo to implement a tunnel service 2170 It may be desirable in some cases to deploy stateful tunnel servers 2171 instead of the stateless Teredo servers. Tunnels servers generally 2172 require more resources, but an advantage is that they can 2173 potentially provide the users with "permanent" IPv6 addresses. 2175 It is possible to design a tunnel server protocol that is compatible 2176 with Teredo, in the sense that the same client could be used either 2177 in the Teredo service or with a tunnel service. In fact, this can be 2178 done by configuring the client with: 2180 - The IPv4 address of a Teredo server that acts as a tunnel broker 2181 - A client identifier 2182 - A shared secret with that server. 2184 The Teredo client will use the secure qualification procedure, as 2185 specified in section 5.2.2. Instead of returning a Teredo prefix in 2186 the router advertisement, the server will return a globally routable 2187 IPv6 prefix; this prefix may be permanently assigned to the client, 2188 which would provide the client with a stable address. The server 2189 will have to keep state, i.e. memorize the association between the 2190 prefix assigned to the client and the mapped IPv4 address and mapped 2191 UDP port of the client. 2193 The Teredo server will advertise reachability of the client prefix 2194 to the IPv6 Internet. Any packet bound to that prefix will be 2195 transmitted to the mapped IPv4 address and mapped UDP port of the 2196 client. 2198 The Teredo client, when it receives the prefix, will notice that 2199 this prefix is a global IPv6 prefix, not in the form of a Teredo 2200 prefix. The client will at that point recognize that it should 2201 operate in tunnel mode. A client that operates in tunnel mode will 2202 execute a much simpler transmission procedure: it will forward any 2203 packet sent to the Teredo interface to the IPv4 address and Teredo 2204 UDP port of the server. 2206 The Teredo client will have to perform the maintenance procedure 2207 described in section 5.2.5. The server will receive the router 2208 solicitation, and may notice a possible change of mapped IPv4 2209 address and mapped UDP port that could result from the 2210 reconfiguration of the mappings inside the NAT. The server should 2211 continue advertising the same IPv6 prefix to the client, and should 2212 update the mapped IPv4 address and mapped UDP port associated to 2213 this prefix, if necessary. 2215 8 Security Considerations 2217 The main objective of Teredo is to provide nodes located behind a 2218 NAT with a globally routable IPv6 address. This enables such nodes 2219 to use IP security services such as IKE, AH or ESP. As such, we can 2220 argue that the service has a positive effect on network security. 2221 However, the security analysis must also envisage the negative 2222 effects of the Teredo services, which we can group in four 2223 categories: security risks of directly connecting a node to the IPv6 2224 Internet, spoofing of Teredo servers to enable a man-in-the-middle 2225 attack, potential attacks aimed at denying the Teredo service to a 2226 Teredo client, and denial of service attacks against non-Teredo 2227 participating nodes that would be enabled by the Teredo service. 2229 In the following, we review in detail these four types of issues, 2230 and we present mitigating strategies for each of them. 2232 8.1 Opening a hole in the NAT 2234 The very purpose of the Teredo service is to make a machine 2235 reachable through IPv6. By definition, the machine using the service 2236 will give up whatever "firewall" service was available in the NAT 2237 box; all services declared locally will become potential target of 2238 attacks from the entire IPv6 Internet. This may sound scary, but 2239 there are three mitigating factors. 2241 The first mitigating factor is the possibility to restrict some 2242 services to only accept traffic from one of the limited address 2243 scopes defined in IPv6, e.g. link-local or site-local. There is no 2244 support for such scopes in Teredo, which implies that limited-scope 2245 services will not be accessed through Teredo, and will be restricted 2246 to whatever other IPv6 connectivity may be available, e.g. direct 2247 traffic with neighbors on the local link, behind the NAT. 2249 The second mitigating factor is the possible use of a "local 2250 firewall" solution, i.e. a piece of software that performs locally 2251 the kind of inspection and filtering that is otherwise performed in 2252 a perimeter firewall. Using such software is recommended. 2254 The third mitigating factor, already noted, is the availability of 2255 end-to-end connectivity, which allows for deployment of IP security 2256 services such as IKE, AH or ESP. Using these services in conjunction 2257 with Teredo is a good policy, as it will protect the client from 2258 possible attacks in intermediate servers such as the NAT, the Teredo 2259 server, or the Teredo relay. 2261 8.2 Using the Teredo service for a man-in-the-middle attack 2263 The goal of the Teredo service is to provide hosts located behind a 2264 NAT with a globally reachable IPv6 address. There is a possible 2265 class of attacks against this service in which an attacker somehow 2266 intercepts the router solicitation, responds with a spoofed router 2267 advertisement, and provides a Teredo client with an incorrect 2268 address. The attacker may have one of two objectives: it may try to 2269 deny service to the Teredo client by providing it with an address 2270 that is in fact unreachable, or it may try to insert itself as a 2271 relay for all client communications, effectively enabling a variety 2272 of "man-in-the-middle" attack. 2274 The secure qualification procedure described in section 5.2.2 2275 enables a good protection against attacks in which a third party 2276 tries to spoof the server. To defeat this protection, the attacker 2277 could try to obtain a copy of the secret shared between client and 2278 server. The most likely way to obtain the shared secret is to listen 2279 to the traffic and mount an offline dictionary attack; to protect 2280 against this attack, the secret shared between client and server 2281 should be provisioned by an automatic procedure and contain 2282 sufficient entropy. 2284 Another way to defeat the protection afforded by the signature 2285 procedure is to mount a complex attack, as follows: 2287 1) Client prepares router solicitation, including authentication 2288 header. 2290 2) Attacker intercepts the solicitation, and somehow manages to 2291 prevent it from reaching the server, for example by mounting a short 2292 duration DoS attack against the server. 2294 3) Attacker replaces the source IPv4 address and source UDP port of 2295 the request by one of its own addresses and port, and forwards the 2296 modified request to the server. 2298 4) Server dutifully notes the IPv4 address from which the packet is 2299 received, verifies that the Authentication encapsulation is correct, 2300 prepares a router advertisement, signs it, and sends it back to the 2301 incoming address, i.e. the attacker. 2303 5) Attacker receives the advertisement, takes note of the mapping, 2304 replaces the IPv4 address and UDP port by the original values in the 2305 intercepted message, and sends the response to the client. 2307 6) Client receives the advertisement, notes that the authentication 2308 header is present and is correct, and uses the proposed prefix and 2309 the mapped addresses in the origin indication encapsulation. 2311 The root cause of the problem is that the NAT is, in itself, a man- 2312 in-the-middle attack. The Authentication encapsulation covers the 2313 encapsulated IPv6 packet, but does not cover the encapsulating IPv4 2314 header and UDP header. It is very hard to devise an effective 2315 signature scheme, since the attacker does not do anything else than 2316 what the NAT legally does! 2318 There are however several mitigating factors that lead us to avoid 2319 worrying too much about this attack. In practice, the gain from the 2320 attack is to either deny service to the client, or obtain a "man-in- 2321 the-middle" position; however, in order to mount the attack, the 2322 attacker must be able to suppress traffic originating from the 2323 client, i.e. have denial of service capability; the attacker must 2324 also be able to observe the traffic exchanged between client and 2325 inject its own traffic in the mix, i.e. have man-in-the-middle 2326 capacity. In summary, the attack is very hard to mount, and the gain 2327 for the attacker is minimal. 2329 8.2.1 End-to-end security 2331 The most effective line of defense of a Teredo client is probably 2332 not to try to secure the Teredo service itself: even if the mapping 2333 can be securely obtained, the attacker would still be able to listen 2334 to the traffic and send spoofed packets. Rather, the Teredo client 2335 should realize that, because it is located behind a NAT, it is in a 2336 situation of vulnerability; it should systematically try to encrypt 2337 its IPv6 traffic, using IPSEC. Even if the IPv4 and UDP headers are 2338 vulnerable, the use of IPSEC will effectively prevent spoofing and 2339 listening of the IPv6 packets by third parties. By providing each 2340 client with a global IPv6 address, Teredo enables the use of IPSEC 2341 and ultimately enhances the security of these clients. 2343 8.3 Denial of the Teredo service 2345 Our analysis outlines five ways to attack the Teredo service. There 2346 are counter-measures for each of these attacks. 2348 8.3.1 Denial of service by a rogue relay 2350 An attack can be mounted on the IPv6 side of the service by setting 2351 up a rogue relay, and letting that relay advertise a route to the 2352 Teredo IPv6 prefix. This is an attack against IPv6 routing, which 2353 can also be mitigated by the same kind of procedures used to 2354 eliminate spurious route advertisements. Dual stack nodes that 2355 implement a "host local" Teredo relays are impervious to this 2356 attack. 2358 8.3.1 Denial of service by server spoofing 2360 In section 8.2, we discussed the use of spoofed router 2361 advertisements to insert an attacker in the middle of a Teredo 2362 conversation. The spoofed router advertisements can also be used to 2363 provision a client with an incorrect address, pointing to either a 2364 non existing IPv4 address or to the IPv4 address of a third party. 2366 The Teredo client will detect the attack when it fails to receive 2367 traffic through the newly acquired IPv6 address. The attack can be 2368 mitigated by using the authentication encapsulation. 2370 8.3.2 Denial of service by exceeding the number of peers 2372 A Teredo client manages a cache of recently-used peers, which makes 2373 it stateful. It is possible to mount an attack against the client by 2374 provoking it to respond to packets that appear to come from a large 2375 number of Teredo peers, thus trashing the cache and effectively 2376 denying the use of direct communication between peers. The effect 2377 will only last as long as the attack is sustained. 2379 8.3.3 Attacks against the local discovery procedure 2381 There is a possible denial of service attack against the local peer 2382 discovery procedure, if attackers can manage to send spoofed local 2383 discovery bubbles to a Teredo client. The checks described in 2384 section 5.2.8 mitigate this attack. Clients who are more interested 2385 in security than in performance could decide to disable the local 2386 discovery procedure; however, if local discovery is disabled, 2387 traffic between local nodes will end up being relayed through a 2388 server external to the local network, which has questionable 2389 security implications. 2391 8.3.4 Attacking the Teredo servers and relays 2393 It is possible to mount a brute force denial of service attack 2394 against the Teredo servers by sending them a very large number of 2395 packets. This attack will have to be "brute force", since the 2396 servers are stateless, and can be designed to process all the 2397 packets that are sent on their access line. 2399 The brute force attack against the Teredo servers is mitigated if 2400 clients are ready to "failover" to another server. Bringing down the 2401 servers will however force the clients that change servers to 2402 renumber their Teredo address. 2404 It is also possible to mount a brute force attack against a Teredo 2405 relay. This attack is mitigated if the relay under attack stops 2406 announcing the reachability of the Teredo service prefix to the IPv6 2407 network: the traffic will be picked up by the next relay. 2409 8.4 Denial of service against non-Teredo nodes 2411 There is a widely expressed concern that transition mechanisms such 2412 as Teredo can be used to mount denial of service attacks, by 2413 injecting traffic at locations where it is not expected. These 2414 attacks fall in three categories: using the Teredo servers as a 2415 reflector in a denial of service attack, using the Teredo server to 2416 carry a denial of service attack against IPv6 nodes, and using the 2417 Teredo relays to carry a denial of service attack against IPv4 2418 nodes. The analysis of these attacks follows. A common mitigating 2419 factor in all cases is the "regularity" of the Teredo traffic, which 2420 contains highly specific patterns such as the Teredo UDP port, or 2421 the Teredo IPv6 prefix. In case of attacks, these patterns can be 2422 used to quickly install filters and remove the offending traffic. 2424 8.4.1 Laundering DOS attacks from IPv4 to IPv4 2426 An attacker can use the Teredo servers as reflectors in a denial of 2427 service attack aimed at an IPv4 target. The attacker can do this in 2428 one of two ways. The first way is to construct a Router Solicitation 2429 message and post it to a Teredo server, using as IPv4 source address 2430 the spoofed address of the target; the Teredo server will then send 2431 a Router advertisement message to the target. The second way is to 2432 construct a Teredo IPv6 address using the Teredo prefix, the address 2433 of a selected server, the IPv4 of the target, and an arbitrary UDP 2434 port, and to then send packets bound to that address to the selected 2435 Teredo server. 2437 Reflector attacks are discussed in [REFLECT], which outlines various 2438 mitigating techniques against such attacks. One of these mitigations 2439 is to observe that 'the traffic generated by the reflectors [has] 2440 sufficient regularity and semantics that it can be filtered out near 2441 the victim without the filtering itself constituting a denial-of- 2442 service to the victim ("collateral damage").' The traffic reflected 2443 by the Teredo servers meets this condition: it is clearly 2444 recognizable, since it originates from the Teredo UDP port; it can 2445 be filtered out safely if the target itself is not a Teredo user. In 2446 addition, the packets relayed by servers will carry an Origin 2447 indication encapsulation, which will help determining the source of 2448 the attack. 2450 8.4.2 DOS attacks from IPv4 to IPv6 2452 An attacker may use the Teredo servers to launch a denial of service 2453 attack against an arbitrary IPv6 destination. The attacker will 2454 build an IPv6 packet bound for the target, and will send that packet 2455 to the IPv4 address and UDP port of a Teredo server, to be relayed 2456 from there to the target over IPv6. 2458 The address checks specified in section 5.3.1 provide some 2459 protection against this attack, as they ensure that the IPv6 source 2460 address will be consistent with the IPv4 source address and UDP 2461 source port used by the attacker: if the attacker cannot spoof the 2462 IPv4 source address, the target will be able to determine the origin 2463 of the attack. 2465 The address checks ensure that the IPv6 source address of packets 2466 forwarded by servers will start with the IPv6 Teredo prefix. This is 2467 a mitigating factor, as sites under attack could use this to filter 2468 out all packets sourced from that prefix during an attack. This will 2469 result in a partial loss of service, as the target will not be able 2470 to communicate with legitimate Teredo hosts that use the same 2471 prefix; however, the communication with other IPv6 hosts will remain 2472 unaffected, and the communication with Teredo hosts will be able to 2473 resume when the attack has ceased. 2475 The ICMP Traceback (ITRACE) working group is considering systems for 2476 "tracing" the source of DOS attacks. According to the proposal, when 2477 forwarding packets, routers can, with a low probability, generate a 2478 Traceback message that is sent along to the destination; with enough 2479 Traceback messages from enough routers along the path, the traffic 2480 source and path can be determined. This set up assumes that the 2481 source and destination are both using the same version of IP. In the 2482 Teredo case, the ICMP Traceback packets will be sent to the Teredo 2483 server, not the final destination. It is conceivable to "map" the 2484 IPv4 traceback to an IPv6 traceback sent by the Teredo server; the 2485 details of the solution should be specified by the ITRACE working 2486 group. 2488 8.4.3 DOS attacks from IPv6 to IPv4 2490 An attacker with IPv6 connectivity may use the Teredo relays to 2491 launch a denial of service attack against an arbitrary IPv4 2492 destination. The attacker will compose a Teredo IPv6 address using 2493 the Teredo prefix, a null server address, the IPv4 address of the 2494 target, an arbitrary UDP port, and an arbitrary node identifier. The 2495 attacker will send IPv6 packets to that address; the packets will be 2496 routed to the nearest Teredo relay, and forwarded from there to the 2497 target. 2499 The address checks specified in 5.4 are limited to verifying that 2500 packets are only relayed to a global IPv4 address. This rules out a 2501 class of attack in which the packets are bound to a broadcast or 2502 multicast address. It also rules out another class of attack in 2503 which the packets are bound for a private IPv4 address that would be 2504 reachable by the relay. 2506 The attack can be targeted at arbitrary UDP ports, such as for 2507 example the DNS port of a server. The UDP payload must be a well- 2508 formed IPv6 packet, and is thus unlikely to be accepted by any well- 2509 written UDP service; in most case, the only effect of the attack 2510 will be to overload the target with random traffic. 2512 A special case occurs if the attack is directed to an echo service. 2513 The service will echo the packets. Since the echo service sees the 2514 request coming from the IPv4 address of the relay, the echo replies 2515 will be sent back to the same relay. According to the rules 2516 specified in 5.4, these packets will be discarded by the Teredo 2517 relay. This is not a very efficient attack against the Teredo relays 2518 - establishing a legitimate session with an actual Teredo host would 2519 create more traffic. 2521 The IPv6 packets sent to the target contain the IPv6 address used by 2522 the attacker. If ingress filtering is used in the IPv6 network, this 2523 address will be hard to spoof. If ingress filtering is not used, the 2524 attacker can be traced if the IPv6 routers use a mechanism similar 2525 to ICMP Traceback. The ICMP messages will normally be collected by 2526 the same relays that forward the traffic from the attacker; the 2527 relays can use these messages to identify the source of an ongoing 2528 attack. The details of this solution should be specified by the 2529 ITRACE working group. 2531 9 IANA Considerations 2533 This memo documents a request to IANA to allocate a Teredo IPv6 2534 service prefix. 2536 10 Copyright 2538 The following copyright notice is copied from RFC 2026 [Bradner, 2539 1996], Section 10.4, and describes the applicable copyright for this 2540 document. 2542 Copyright (C) The Internet Society September 17, 2002. All Rights 2543 Reserved. 2545 This document and translations of it may be copied and furnished to 2546 others, and derivative works that comment on or otherwise explain it 2547 or assist in its implementation may be prepared, copied, published 2548 and distributed, in whole or in part, without restriction of any 2549 kind, provided that the above copyright notice and this paragraph 2550 are included on all such copies and derivative works. However, this 2551 document itself may not be modified in any way, such as by removing 2552 the copyright notice or references to the Internet Society or other 2553 Internet organizations, except as needed for the purpose of 2554 developing Internet standards in which case the procedures for 2555 copyrights defined in the Internet Standards process must be 2556 followed, or as required to translate it into languages other than 2557 English. 2559 The limited permissions granted above are perpetual and will not be 2560 revoked by the Internet Society or its successors or assignees. 2562 This document and the information contained herein is provided on an 2563 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2564 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2565 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2566 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2567 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2569 11 Intellectual Property 2571 The following notice is copied from RFC 2026 [Bradner, 1996], 2572 Section 10.4, and describes the position of the IETF concerning 2573 intellectual property claims made against this document. 2575 The IETF takes no position regarding the validity or scope of any 2576 intellectual property or other rights that might be claimed to 2577 pertain to the implementation or use other technology described in 2578 this document or the extent to which any license under such rights 2579 might or might not be available; neither does it represent that it 2580 has made any effort to identify any such rights. Information on the 2581 IETF's procedures with respect to rights in standards-track and 2582 standards-related documentation can be found in BCP-11. Copies of 2583 claims of rights made available for publication and any assurances 2584 of licenses to be made available, or the result of an attempt made 2585 to obtain a general license or permission for the use of such 2586 proprietary rights by implementers or users of this specification 2587 can be obtained from the IETF Secretariat. 2589 The IETF invites any interested party to bring to its attention any 2590 copyrights, patents or patent applications, or other proprietary 2591 rights which may cover technology that may be required to practice 2592 this standard. Please address the information to the IETF Executive 2593 Director. 2595 12 Acknowledgements 2597 Many of the ideas in this memo are the result of discussions between 2598 the author and Microsoft colleagues, notably Brian Zill, John 2599 Miller, Mohit Talwar, Joseph Davies and Rick Rashid. Several 2600 encapsulation details are inspired from early work by Keith Moore. 2601 The example in section 5.1 and a number of security precautions were 2602 suggested by Pekka Savola. The local discovery procedure was 2603 suggested by Richard Draves and Dave Thaler. The document was 2604 reviewed by the NGTRANS working group; Brian Carpenter, Cyndi Jung, 2605 Keith Moore, Thomas Narten, Anssi Porttikivi, Pekka Savola, and Eng 2606 Soo Guan. 2608 13 References 2610 [RFC768] J. Postel, "User Datagram Protocol", RFC 768, August 1980. 2612 [RFC791] J. Postel, "Internet Protocol", RFC 791, September 1981. 2614 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 2615 April 1992. 2617 [RFC1918] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, 2618 E. Lear, "Address Allocation for Private Internets", RFC 1918, 2619 February 1996. 2621 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 2622 Requirement Levels", RFC 2119, March 1997. 2624 [RFC2460] S. Deering, R. Hinden, "Internet Protocol, Version 6 2625 (IPv6) Specification", RFC 2460, December 1998. 2627 [RFC2461] T. Narten, E. Nordmark, W. Simpson, "Neighbor Discovery 2628 for IP Version 6 (IPv6)", RFC 2461, December 1998. 2630 [RFC2462] T. Narten, S. Thomson, "IPv6 Stateless Address 2631 Autoconfiguration", RFC 2462, December 1998. 2633 [RFC3056] B. Carpenter, K. Moore, "Connection of IPv6 Domains via 2634 IPv4 Clouds", RFC 3056, February 2001. 2636 [RFC3068] C. Huitema, "An Anycast Prefix for 6to4 Relay Routers", 2637 RFC 3068, June 2001. 2639 [RFC1750] D. Eastlake, S. Crocker, J. Schiller, "Randomness 2640 Recommendations for Security", RFC 1750, December 1994. 2642 [SYNCHRO] S. Floyd, V. Jacobson, "The synchronization of periodic 2643 routing messages", ACM SIGCOMM'93 Symposium, September 1993. 2645 [REFLECT] V. Paxson, "An analysis of using reflectors for 2646 distributed denial of service attacks." Computer Communication 2647 Review, ACM SIGCOMM, Volume 31, Number 3, July 2001, pp 38-47. 2649 14 Authors' Addresses 2651 Christian Huitema 2652 Microsoft Corporation 2653 One Microsoft Way 2654 Redmond, WA 98052-6399 2656 Email: huitema@microsoft.com 2657 Table of Contents: 2659 1 Introduction .................................................... 1 2660 2 Definitions ..................................................... 2 2661 2.1 Teredo service ................................................ 2 2662 2.2 Teredo Client ................................................. 2 2663 2.3 Teredo Server ................................................. 2 2664 2.4 Teredo Relay .................................................. 3 2665 2.5 Teredo IPv6 service prefix .................................... 3 2666 2.5.1 Global Teredo IPv6 service prefix ........................... 3 2667 2.6 Teredo UDP port ............................................... 3 2668 2.7 Teredo bubble ................................................. 3 2669 2.8 Teredo service port ........................................... 3 2670 2.9 Teredo server address ......................................... 3 2671 2.10 Teredo mapped address and Teredo mapped port ................. 3 2672 2.11 Teredo IPv6 client prefix .................................... 3 2673 2.12 Teredo node identifier ....................................... 4 2674 2.13 Teredo IPv6 address .......................................... 4 2675 2.14 Teredo Refresh Interval ...................................... 4 2676 2.15 Teredo secondary port ........................................ 4 2677 2.16 Teredo IPv4 Discovery Address ................................ 4 2678 3 Design goals, requirements, and model of operation .............. 4 2679 3.1 Hypotheses about NAT behavior ................................. 4 2680 3.1.1 Types of UDP mappings ....................................... 5 2681 3.1.2 Lifetime of UDP mappings .................................... 5 2682 3.2 IPv6 provider of last resort .................................. 6 2683 3.2.1 When to use Teredo? ......................................... 6 2684 3.2.2 Autonomous deployment ....................................... 6 2685 3.2.3 Minimal load on servers ..................................... 7 2686 3.2.4 Automatic sunset ............................................ 7 2687 3.3 Operational Requirements ...................................... 7 2688 3.3.1 Robustness requirement ...................................... 7 2689 3.3.2 Minimal support cost ........................................ 7 2690 3.3.3 Protection against denial of service attacks ................ 8 2691 3.3.4 Protection against distributed denial of service attacks .... 8 2692 3.3.5 Compatibility with ingress filtering ........................ 8 2693 4 Model of operation and deployment ............................... 8 2694 4.1 Model of operation ............................................ 8 2695 4.1.1 Encoding of Teredo addresses ................................ 9 2696 4.1.2 Obtaining an address ........................................ 10 2697 4.1.3 Determining the type of NAT ................................. 12 2698 4.1.4 First packet from an IPv6 node to a Teredo node ............. 13 2699 4.1.5 First packet from a Teredo node to a regular IPv6 node ...... 14 2700 4.1.6 Exchanges between two Teredo nodes .......................... 17 2701 4.1.7 Exchanges between two Teredo nodes on the same link ......... 18 2702 4.2 Deployment model .............................................. 19 2703 4.2.1 Server deployment ........................................... 19 2704 4.2.2 Relay deployment ............................................ 20 2705 5 Specification of clients, servers and relays .................... 20 2706 5.1 Message formats ............................................... 21 2707 5.1.1 Teredo IPv6 packets encapsulation ........................... 21 2708 5.1.2 Maximum Transmission Unit ................................... 23 2709 5.2 Teredo Client specification ................................... 23 2710 5.2.1 Qualification procedure ..................................... 24 2711 5.2.2 Secure qualification ........................................ 27 2712 5.2.3 Packet reception ............................................ 27 2713 5.2.4 Packet transmission ......................................... 29 2714 5.2.5 Maintenance ................................................. 30 2715 5.2.6 Sending Teredo Bubbles ...................................... 30 2716 5.2.7 Optional Refresh Interval Determination Procedure ........... 31 2717 5.2.8 Optional local client discovery procedure ................... 32 2718 5.2.9 Direct IPv6 connectivity test ............................... 33 2719 5.3 Teredo Server specification ................................... 34 2720 5.3.1 Processing of Teredo IPv6 packets ........................... 34 2721 5.3.2 Processing of router solicitations .......................... 36 2722 5.4 Teredo Relay specification .................................... 36 2723 5.4.1 Transmission by relays to Teredo clients .................... 37 2724 5.4.2 Reception from Teredo clients ............................... 38 2725 5.4.3 Difference between Teredo Relays and Teredo Servers ......... 38 2726 5.5 Implementation of automatic sunset ............................ 38 2727 6 Discussion of the solution ...................................... 39 2728 6.1 Why do we require address obfuscation? ........................ 39 2729 6.2 Why do we have bubbles and lists of peers? .................... 39 2730 6.3 Why do servers only process bubbles and ICMPv6 messages? ...... 40 2731 6.4 What if two clients are behind the same NAT? .................. 40 2732 6.5 What about symmetric NAT? ..................................... 41 2733 6.6 Do we need the Refresh Interval Determination Procedure? ...... 41 2734 6.7 Why do we use a Randomized Refresh Interval? .................. 42 2735 6.8 Scaling, failover and access control .......................... 42 2736 6.9 What about firewalls? ......................................... 42 2737 6.10 Why do we use the name Teredo? ............................... 43 2738 7 Use of Teredo to implement a tunnel service ..................... 43 2739 8 Security Considerations ......................................... 44 2740 8.1 Opening a hole in the NAT ..................................... 44 2741 8.2 Using the Teredo service for a man-in-the-middle attack ....... 45 2742 8.2.1 End-to-end security ......................................... 46 2743 8.3 Denial of the Teredo service .................................. 46 2744 8.3.1 Denial of service by a rogue relay .......................... 46 2745 8.3.1 Denial of service by server spoofing ........................ 47 2746 8.3.2 Denial of service by exceeding the number of peers .......... 47 2747 8.3.3 Attacks against the local discovery procedure ............... 47 2748 8.3.4 Attacking the Teredo servers and relays ..................... 47 2749 8.4 Denial of service against non-Teredo nodes .................... 48 2750 8.4.1 Laundering DOS attacks from IPv4 to IPv4 .................... 48 2751 8.4.2 DOS attacks from IPv4 to IPv6 ............................... 48 2752 8.4.3 DOS attacks from IPv6 to IPv4 ............................... 49 2753 9 IANA Considerations ............................................. 50 2754 10 Copyright ...................................................... 50 2755 11 Intellectual Property .......................................... 51 2756 12 Acknowledgements ............................................... 51 2757 13 References ..................................................... 51 2758 14 Authors' Addresses ............................................. 52