idnits 2.17.1 draft-huitema-v6ops-teredo-00.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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 10) being 576 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 58 pages 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 126 instances of lines with control characters in the document. ** The abstract seems to contain references ([REFLECT], [RFC791], [RFC3489], [RFC1321], [RFC2460], [RFC2119], [RFC2461], [SYNCHRO], [RFC2462], [RFC3424], [RFC2104], [RFC768], [Bradner,1996], [RFC2641], [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 (June 6, 2003) is 7629 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: 'RFC2104' is mentioned on line 1338, but not defined == Missing Reference: 'RFC2641' is mentioned on line 1819, but not defined == Missing Reference: 'Bradner' is mentioned on line 2672, but not defined -- Looks like a reference, but probably isn't: '1996' on line 2672 == Unused Reference: 'RFC1918' is defined on line 2720, but no explicit reference was found in the text == Unused Reference: 'RFC3068' is defined on line 2739, but no explicit reference was found in the text == Unused Reference: 'RFC1750' is defined on line 2748, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3068 (Obsoleted by RFC 7526) ** Downref: Normative reference to an Informational RFC: RFC 3424 -- Obsolete informational reference (is this intentional?): RFC 1750 (Obsoleted by RFC 4086) -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) Summary: 13 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT C. Huitema 2 Microsoft 3 Expires December 6, 2003 June 6, 2003 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 be joined through the Teredo service, as well as 167 a 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. The value of this address is X.X.X.X. 194 (TBD IANA; experiments use the value 224.0.0.252.) 196 3 Design goals, requirements, and model of operation 198 The proposed solution transports IPv6 packets as the payload of UDP 199 packets. This is based on the observation that TCP and UDP are the 200 only protocols guaranteed to cross the majority of NAT devices. 201 Relaying packets over TCP would be possible, but would result in a 202 very poor quality of service; relaying over UDP is a better choice. 204 The design of our solution is based on a set of hypotheses and 205 observations on the behavior of NATs, our desire to provide an "IPv6 206 provider of last resort", and a list of operational requirements. It 207 results in a model of operation in which the Teredo service is 208 enabled by a set of servers and relays. 210 3.1 Hypotheses about NAT behavior 212 NAT devices typically incorporate some support for UDP, in order to 213 enable users in the natted domain to use UDP based applications. The 215 Huitema [Page 4] 216 NAT will typically allocate a "mapping" when it sees an UDP packet 217 coming through for which there is not yet an existing mapping. The 218 handling of UDP "sessions" by NAT devices differs by two important 219 parameters, the type and the duration of the mappings. 221 3.1.1 Types of UDP mappings 223 Experience shows that the implementers of NAT devices can adopt 224 widely different treatments of UDP mappings: 226 1) Some implement the simplest solution, which is to map an internal 227 UDP port, defined by an internal address and a port number on the 228 corresponding host, to an external port, defined by a global address 229 managed by the NAT and a port number valid for that address. In this 230 simple case, the mapping is retained as long as the port is active, 231 and is removed after an inactivity timer. As long as the mapping is 232 retained, any packet received by the NAT for the external port is 233 relayed to the internal address and port. These NATs are usually 234 called "cone NATs". 236 2) Some implement a more complex solution, in which the NAT not only 237 establishes a mapping for the UDP port, but also maintains a list of 238 external hosts to which traffic has been sent from that port. The 239 packets originating from third party hosts to which the local host 240 has not yet sent traffic are rejected. These NATs are usually called 241 "restricted cone NATs". 243 3) Instead of keeping just a list of authorized hosts, some NAT 244 implementations keep a list of authorized host and port pairs. UDP 245 packets coming from remote addresses are rejected if the internal 246 host has not yet sent traffic to the outside host and port pair. The 247 NATs are often called "port-restricted cone NATs" 249 4) Finally, some NATs map the same internal address and port pair to 250 different external address and port pairs, depending on the address 251 of the remote host. These NATs are usually called "symmetric NATs". 253 Measurement campaigns and studies of documentations have shown that 254 most NATs implement either option 1 or option 2, i.e. cone NATs or 255 restricted cone NATs. The Teredo solution ensures connectivity for 256 clients located behind cone NATs, restricted cone NATs, or port- 257 restricted cone NATs; it contains optimizations for clients located 258 behind a cone NAT; it does not provide connectivity for clients 259 located behind a symmetric NAT. 261 3.1.2 Lifetime of UDP mappings 263 Regardless of their types, UDP mappings are not kept forever. The 264 typical algorithm is to remove the mapping if no traffic is observed 265 on the specified port for a "lifetime" period. The Teredo client 266 that want to maintain a mapping open in the NAT will have to send 267 some "keep alive" traffic before the lifetime expires. For that, it 269 Huitema [Page 5] 270 needs an estimate of the "lifetime" parameter used in the NAT. We 271 observed that the implementation of lifetime control can vary in 272 several ways. 274 Most NATs implement a "minimum lifetime" which is set as a parameter 275 of the implementation. Our observations of various boxes showed that 276 this parameter can vary between about 45 seconds and several 277 minutes. 279 In many NATs, mappings can be kept for a duration that exceeds this 280 minimum, even in the absence of traffic. We suspect that many 281 implementation perform "garbage collection" of unused mappings on 282 special events, e.g. when the overall number of mappings exceeds 283 some limit. 285 In some cases, e.g. NATs that manage ISDN or dial-up connections, 286 the mappings will be released when the connection is released, i.e. 287 when no traffic is observed is observed on the connection for a 288 period of a few minutes. 290 Any algorithm used to estimate the lifetime of mapping will have to 291 be robust against these variations. 293 3.2 IPv6 provider of last resort 295 Teredo is designed to provide an "IPv6 access of last resort" to 296 nodes that need IPv6 connectivity but cannot use any of the other 297 transition schemes designed by the NGTRANS working group. This 298 design objective has several consequences on when to use Teredo, how 299 to program clients, and what to expect of servers. Another 300 consequence is that we expect to see a point in time at which the 301 Teredo technology ceases to be used. 303 3.2.1 When to use Teredo? 305 Teredo is designed to robustly enable IPv6 traffic through NATs, and 306 the price of robustness is a reasonable amount of overhead, due to 307 UDP encapsulation and transmission of bubbles. Nodes that want to 308 connect to the IPv6 Internet SHOULD only use the Teredo service as a 309 "last resort" option: they SHOULD prefer using direct IPv6 310 connectivity if it is locally available or if it is provided by a 311 6to4 router co-located with the local NAT, and they SHOULD prefer 312 using the less onerous "6to4" encapsulation if they can use a global 313 IPv4 address. 315 3.2.2 Autonomous deployment 317 In an IPv6-enabled network, the IPv6 service is configured 318 automatically, by using mechanisms such as IPv6 Stateless Address 319 Autoconfiguration [RFC2462] and Neighbor Discovery [RFC2461]. A 320 design objective is to configure the Teredo service as automatically 322 Huitema [Page 6] 323 as possible. In practice, it is however required that the client 324 learn the IPv4 address of a server that is willing to serve them; 325 some servers may also require some form of access control. 327 3.2.3 Minimal load on servers 329 During the peak of the transition, there will be a requirement to 330 deploy a large number of servers throughout the Internet. Minimizing 331 the load on the server is a good way to facilitate this deployment. 332 To achieve this goal, servers should be as stateless as possible, 333 and they should also not be required to carry any more traffic than 334 necessary. To achieve this objective, we require only that servers 335 enable the packet exchange between clients, but we don't require 336 servers to carry the actual data packets: these packets will have to 337 be exchanged directly between the Teredo clients, or through a 338 destination-selected relay for exchanges between Teredo clients and 339 other IPv6 clients. 341 3.2.4 Automatic sunset 343 Teredo is meant as a short-term solution to the specific problem of 344 providing IPv6 service to nodes located behind a NAT. The problem is 345 expected to be resolved over time by transforming the "IPv4 NAT" 346 into an "IPv6 router". This can be done in one of two ways: 347 upgrading the NAT to provide 6to4 functions, or upgrading the 348 Internet connection used by the NAT to a native IPv6 service, and 349 then adding IPv6 router functionality in the NAT. In either case, 350 the former NAT can present itself as an IPv6 router to the systems 351 behind it. These systems will start receiving the "router 352 advertisements"; they will notice that they have IPv6 connectivity, 353 and will stop using Teredo. 355 3.3 Operational Requirements 357 3.3.1 Robustness requirement 359 The Teredo service is designed primarily for robustness: packets are 360 carried over UDP in order to cross as many NAT implementations as 361 possible. The servers are designed to be stateless, which means that 362 they can easily be replicated. We expect indeed to find many such 363 servers replicated at multiple Internet locations. 365 3.3.2 Minimal support cost 367 The service requires the support of servers and relays. In order to 368 facilitate the deployment of these servers, the Teredo procedures 369 are designed to minimize the fraction of traffic that has to be 370 routed through the servers. 372 Meeting this objective implies that the Teredo addresses will 373 incorporate the IPv4 address and UDP port through which a Teredo 374 client can be reached. This creates an implicit limit on the 376 Huitema [Page 7] 377 stability of the Teredo addresses, which can only remain valid as 378 long as the underlying IPv4 address and UDP port remains valid. 380 3.3.3 Protection against denial of service attacks 382 The Teredo clients obtain mapped addresses and ports from the Teredo 383 servers. The service must be protected against denial of service 384 attacks in which a third party spoofs a Teredo server and sends 385 improper information to the client. 387 3.3.4 Protection against distributed denial of service attacks 389 Teredo servers will act as a relay for IPv6 packets. Improperly 390 designed packet relays can be used by denial of service attackers to 391 hide their address, making the attack untraceable. The Teredo 392 service must include adequate protection against such misuse. 394 3.3.5 Compatibility with ingress filtering 396 Routers may perform ingress filtering by checking that the source 397 address of the packets received on a given interface is 398 "legitimate", i.e. belongs to network prefixes from which traffic is 399 expected at a network interface. Ingress filtering is a recommended 400 practice, as it thwarts the use of forged source IP addresses by 401 malfeasant hackers, notably to cover their tracks during denial of 402 service attacks. The Teredo specification must not force networks to 403 disable ingress filtering. 405 4 Model of operation and deployment 407 A Teredo Network is composed of a set of clients, servers and 408 relays. In this section, we present the model of operation of a 409 given network, and then we present the deployment model. 411 4.1 Model of operation 413 The Teredo service requires the cooperation of three kinds of 414 actors: Teredo clients, who want to use IPv6 despite being located 415 behind a NAT, Teredo servers who will facilitate the service, and 416 Teredo relays that provide for the interconnection between the 417 Teredo service and the "native IPv6 Internet." 419 In order to enable the service, the Teredo servers must have IPv6 420 connectivity and an unencumbered IPv4 connection: they must have a 421 global IPv4 address; and they must have global IPv6 connectivity 422 independently of the Teredo service. 424 The Teredo relays must be connected to the IPv6 Internet and must 425 participate in IPv6 routing; they must be able to announce 426 reachability of the "Teredo service IPv6 prefix" over IPv6. They 427 must then be able to relay packets over IPv4 UDP towards Teredo 428 clients. 430 Huitema [Page 8] 431 The primary role of the servers is to enable NAT traversal. The 432 service is designed in such a way that, when NAT traversal is 433 guaranteed, packets can flow on a direct path between source and 434 destination, bypassing the Teredo server. 436 4.1.1 Encoding of Teredo addresses 438 The Teredo addresses are composed of 5 components: 440 +-------------+-------------+-------+------+-------------+ 441 | Prefix | Server IPv4 | Flags | Port | Client IPv4 | 442 +-------------+-------------+-------+------+-------------+ 444 - Prefix: the 32 bit Teredo service prefix. 445 - Server IPv4: the IPv4 address of a Teredo server. 446 - Flags: a set of 16 bits that document type of address and NAT. 447 - Port: the obfuscated "mapped UDP port" of the Teredo service at 448 the client 449 - Client IPv4: the obfuscated "mapped IPv4 address" of a client 451 In this format, both the "mapped UDP port" and "mapped IPv4 address" 452 of the client are obfuscated. Each bit in the address and port 453 number is reversed; this can be done by an exclusive OR of the 16- 454 bit port number with the hexadecimal value 0xFFFF, and an exclusive 455 OR of the 32-bit address with the hexadecimal value 0xFFFFFFFF. 457 The IPv6 addressing rules specify that "for all unicast addresses, 458 except those that start with binary value 000, Interface IDs are 459 required to be 64 bits long and to be constructed in Modified EUI-64 460 format." This dictates the encoding of the flags, 16 intermediate 461 bits which should correspond to valid values of the most significant 462 16 bits of a Modified EUI-64 ID: 464 0 0 0 1 465 |0 7 8 5 466 +----+----+----+----+ 467 |Czzz|zzUG|zzzz|zzzz| 468 +----+----+----+----+ 470 In this format: 472 - The bits "UG" should be set to the value "00", indicating a non- 473 global unicast identifier; 474 - The bit "C" (cone) should be set to 1 if the client believes it is 475 behind a cone NAT, to 0 otherwise; these values determine 476 different server behavior during the qualification procedure, as 477 specified in section 5.2.1, as well as different bubble processing 478 by clients and relays. 479 - The bits indicated with "z" must be set to zero. 481 Huitema [Page 9] 482 There are thus two valid values of the Flags field: "0x0000" (all 483 null) if the cone bit is set to 0, and "0x8000" if the cone bit is 484 set to 1. 486 A third party sends IPv6 packets to a Teredo client by sending these 487 packets over UDP to the mapped IPv4 address and port of the client 488 if the cone bit is set, or if the third party has recently received 489 direct traffic from the client. In the other cases, the third party 490 will have to first synchronize with the client, by sending an 491 initial bubble through the server. 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 cone bit is not set 687 (i.e., the C bit has the value 0). 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 | : Echo Reply --> : ! 740 | +---:--+ +-:-!+ 741 `---| S : |---------------|R: !|---- 742 .---------------| : |---------------| v !|--- 743 |IPv4 Internet | :..|<................* !| 744 | +----#-+ +----+ 745 | ^# <- Bubble+Origin ^: ^ 746 | :# Bubble ->:: ! 747 | :#...................: ! 748 | Echo Request --> :#::-----------------: ! 749 | :#::.-.-.-.-.-.-.-.-.-.- 750 | :#::! 751 | :v:v! <- Data Packet 752 | +---:-:-!-+ 753 `---------------| N :#::! |-------------------- 754 .--| :#::! |-------------------- 755 | +---:#::--+ Natted domain 756 | ^#::^ 757 | :#::! 758 | :v:v! 759 | +---------+ 760 | | A | 761 | +---------+ 763 We assume that A has already established its Teredo address through 764 an RA/RS exchange with S, as explained in section 4.1.2; in this 765 example, we will assume that the client is not located behind a cone 766 NAT. We will assume that the results of these exchanges are the 767 following: 769 - A's private address and port are: 10.0.0.2:1234. 770 - A's mapped address and port are: 9.0.0.1:4096. 771 - A's IPv6 address has been set to PREF:102:304::EFFF:F6FF:FFFE 772 - The server's IPv4 address and port are: 1.2.3.4:3544 773 - The relay's IPv4 address and port are: 5.6.7.8:3544 774 - B's IPv6 address is: 2000::B 776 A has to transmit an IPv6 packet to B. A's first action is to learn 777 the address of the relay R closest to B. To do so, A sends an ICMPv6 778 "echo request" toward B. This request carries the source address 779 PREF:102:304::EFFF:F6FF:FFFE (A's address), and the destination 780 address 2000::B (B's address); the Data field of the echo request 781 carries a nonce value, chosen by A. The request is encapsulated by A 782 in a UDP datagram, from source address and port 10.0.0.2:1234, to 783 destination address and port 1.2.3.4:3544. 785 The packet is received by the NAT N. N uses the existing mapping for 786 10.0.0.2:1234, and replaces the UDP source address and port by the 787 mapped values 9.0.0.1:4096, before forwarding the packet. 789 The packet is received over IPv4 by the server. S discards the IPv4 790 and UDP header, and forwards the content of the packet over IPv6, 791 which will be received by B, and which will appear to come from A's 792 address, PREF:102:304::EFFF:F6FF:FFFE. 794 When the request is received, B sends the echo reply to A; B simply 795 follows IPv6 routing rules. The packet is forwarded to the nearest 796 relay, R, over IPv6. R examines the destination address, and 797 observes that the the cone bit is not set in the destination 798 address. Since R has not received any direct traffic from A, R first 799 sends a bubble towards A through the server S, as specified in the 800 previous section; A will reply by its own bubble. Upon reception of 801 this bubble, R forwards the packet over UDP to the mapped address of 802 A: 9.0.0.1:4096. 804 The NAT N will receive this message. It will use the existing 805 mapping to rewrite 9.0.0.1:4096 to 10.0.0.2:1234, and forward the 806 packet to A. When A receives the packet, it learns that B can 807 possibly be reached through the relay address 5.6.7.8:3544. A can 808 also note that the Data field of the ICMPv6 echo reply matches the 809 nonce that was previously sent, which provides a reasonable 810 assurance that the packet does in fact come from B. At that point, A 811 can send the original data packet to B, by encapsulating it in a UDP 812 datagram bound to the IPv4 address and UDP port of R: 5.6.7.8:3544; 813 R will then normally relay the packet to B. Once the knowledge of 814 R's address has been acquired, A will send all further packets 815 directly through R, without having to repeat the ICMP exchange. 817 If the cone NAT validation had been successful, A would have used 818 the IPv6 address PREF:102:304:8000:EFFF:F6FF:FFFE, and R would have 819 sent B's reply directly to A. In that case, A would have learned R's 820 address from the IPv4 source address and UDP source port of the 821 incoming packet. 823 4.1.6 Exchanges between two Teredo nodes 825 The following diagram shows two Teredo clients, A and B, connected 826 through the NATs N1 and N2. The exchanges will use the Teredo server 827 S2, chosen by B. We will assume that the NAT N2 is a "restricted 828 cone" or "port-restricted cone" NAT; in this example, we will also 829 assume that A is behind a restricted cone or port-restricted cone 830 NAT. 832 .------------------------------------------------------- 833 | IPv4 Internet 834 | 835 | 4-Data packet 836 | .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-. 837 | ! +----+ ! 838 | ! 2-bubble | S2 | ! 839 | !..............................>|.........! 840 | !: +----+ :! 841 | !: 3-Bubble :! 842 | !: ................................... :! 843 | !: :.................................: :! 844 | !: v: 1-Bubble v: vv 845 | +!----:+ +-:----+ 846 `-----|!:N1::|-----------------------------| :N2:!|----- 847 .--|!: ::|----. .----| : :!|--. 848 | +-:--:-+ | | +----:!+ | 849 | ^^ :^ | | ^ :! | 850 | !: :: | | : :! | 851 | !: v: | | : vv | 852 | +------+ | | +-----+ | 853 | | A | | | | B | | 854 | +------+ | | +-----+ | 855 `--------------/ `--------------/ 857 We will assume that A and B have already obtained Teredo addresses 858 by RS/RA exchanges with they respective servers S1 and S2, and they 859 have made sure that they can receive packets from these respective 860 servers, for example by sending a keepalive packet every minute. In 861 the example, we will assume the following values: 863 - A's private address and port are: 10.0.0.2:1234. 864 - A's mapped address and port are: 9.0.0.1:4096. 865 - A is served by S1, whose address is: 1.2.3.4 866 - A's IPv6 address has been set to PREF:102:304::EFFF:F6FF:FFFE 867 - B's private address and port are: 10.0.0.3:3456. 868 - B's mapped address and port are: 8.0.0.1:1024. 869 - B is served by S2, whose address is: 9.10.11.12 870 - B's IPv6 address has been set to PREF:90A:B0C::FBFF:F7FF:FFFE 872 A has learned B's address, for example from the DNS, and starts UDP 873 or TCP communication with B. The first data packet will be sent from 874 A's IPv6 address (PREF:102:304::EFFF:F6FF:FFFE) to B's IPv6 address 875 (PREF:90A:B0C::FBFF:F7FF:FFFE). Since A has no prior knowledge of B, 876 and since B is not located behind a cone NAT, A cannot send the 877 packet directly to B; the packet is queued. Instead, A prepares two 878 bubbles, from IPv6 source address PREF:102:304::EFFF:F6FF:FFFE to 879 IPv6 destination address PREF:90A:B0C::FBFF:F7FF:FFFE. 881 The first bubble is sent from A to the mapped IPv4 address of B, 882 8.0.0.1:1024. It will probably not be received by B, since there is 883 no establish mapping at the NAT N2. The purpose of this bubble is 884 only to establish a mapping in the NAT N1. 886 The second bubble is sent from A to S2's address, 9.10.11.12:3544. 887 The bubble passes through N1. S2 receives it and transmits it to B. 888 Since there is an established mapping in N2 for transmission between 889 B and S2, the bubble is forwarded to B. 891 B responds to this bubble with its own bubble, from IPv6 source 892 address PREF:90A:B0C::FBFF:F7FF:FFFE to IPv6 destination address 893 PREF:102:304::EFFF:F6FF:FFFE. This response bubble is sent directly 894 to the mapped address of A, 9.0.0.1:4096. Since a mapping was 895 established by the first bubble, this third bubble is received by A. 897 When A receives the third bubble, it knows that direct communication 898 with B is now possible. The queued packet can now be directly 899 transmitted. 901 4.1.7 Exchanges between two Teredo nodes on the same link 903 The following diagram shows two Teredo clients, A and B, connected 904 to the same link, which is connected to the Internet through the NAT 905 N1. The exchanges will use the Teredo server S1. We are not making 906 any assumption about the NAT N1. This scenario explains how the 907 exchanges between clients on the same link can be optimized to avoid 908 routing all packets through the server S1. 910 .------------------------------------------ 911 | IPv4 Internet 912 | +------+ 913 | | S1 | 914 | +------+ 915 | ^! ^! 916 | !! !! 917 | !! !! 918 | !! !! Router Solicit, 919 | !! !! Router Advertisement 920 | !! !! 921 | !v !v 922 | +!---!-+ 923 `-----|!!N1! |---------------------------- 924 .--|!! !!|-------------------------. 925 | +-!--!!+ | 926 | ^! !! | 927 | !! !`-.-.-.-.-.-.-.-.-.-.-. | 928 | !! `-.-.-.-.-.-.-.-.-.-.-.! | 929 | !! .->___ <-. !! | 930 | !v / multicast \ !v | 931 | +------+ bubbles +------+ | 932 | | A | | B | | 933 | +------+ <===========>+------+ | 934 | direct transmissions | 935 `-----------------------------------/ 937 Both A and B discover their Teredo prefix by interacting with the 938 server S1, as explained in 4.1.2. Both A and B can discover that 939 they are possibly located behind the same NAT, by observing that 940 they are both using the same mapped IPv4 address. 942 When A wants to send a packet to B, A will send a multicast Teredo 943 bubble to the Teredo IPv4 Discovery Address, an IPv4 multicast 944 address whose scope is limited to the local link. If B is in fact on 945 the same link, B will reply with a unicast Teredo bubble sent 946 directly to the source address of the multicast bubble; B will also 947 send a multicast Teredo bubble. Upon reception of this direct 948 bubble, A will get confirmation that B is directly reachable; upon 949 reception of the multicast bubble, A will send a unicast bubble to 950 B. Once direct reachability has been confirmed by the reception of 951 unicast bubbles, the packets will be sent directly on the local 952 link, avoiding the unreliable loop through the NAT N1. 954 4.2 Deployment model 956 The deployment model makes three assumptions: 958 - That all clients, servers and relays will be cognizant of the 959 Teredo service prefix and the Teredo port, and of the Teredo IPv4 960 Discovery Address, 961 - That the clients will be configured with the IPv4 address of a 962 server, 964 - That there will be an adequate deployment of Teredo relays. 966 4.2.1 Server deployment 968 Servers may be deployed either as part of an ISP offer to its 969 subscribers, or as an enabler for an application that requires 970 direct IPv6 communication between client hosts. Servers are expected 971 to perform some amount of access control; for example, an ISP server 972 may refuse to serve requests that don't originate from an address 973 within this ISP's network; a server set up by an application 974 provider may require that clients provide some form of proof that 975 they are actually using the application. 977 Servers will originate IPv6 packets whose source address will be the 978 Teredo IPv6 address of one of their clients. In order to abide with 979 IPv6 ingress filtering rules, servers should only do so if, as an 980 IPv6 router, they advertise reachability of the Teredo service 981 prefix. 983 4.2.2 Relay deployment 985 The ingress filtering rule implies that all Teredo servers should be 986 able to act as Teredo relays; however, there is no requirement that 987 all Teredo relays act as Teredo servers. The only deployment 988 requirement for Teredo relays is IPv4 connectivity, and the capacity 989 to advertise a route to the Teredo service. There can be three kinds 990 of Teredo relays: 992 - Globally accessible Teredo relays announce reachability of the 993 Teredo service to the whole Internet, e.g. by means of BGP. 995 - Domain-specific Teredo relays announce reachability of the Teredo 996 service to a specific domain, e.g. by means of IGP. 998 - Host-specific Teredo relays announce reachability of the Teredo 999 service within a single host. 1001 In the initial deployment of the Teredo service, we expect to find a 1002 small number of globally accessible relays. We also expect that, if 1003 the service is deployed to enable a specific application, all the 1004 hosts that participate in the application and have adequate IPv4 1005 access will implement a host-based Teredo relay. 1007 5 Specification of clients, servers and relays 1009 The Teredo service is realized by having clients interact with 1010 Teredo servers through the Teredo service protocol. The clients will 1011 also receive IPv6 packets through Teredo relays. 1013 The Teredo server is designed to be stateless. It waits for Teredo 1014 requests and for IPv6 packets on the Teredo UDP port; it processes 1015 the requests by sending a response to the appropriate address and 1016 port; it forwards Teredo IPv6 packets to the appropriate IPv4 1017 address and UDP port. 1019 The Teredo relay advertises reachability of the Teredo service 1020 prefix over IPv6. It forwards Teredo IPv6 packets to the appropriate 1021 IPv4 address and UDP port. 1023 Teredo clients, servers and relays must implement the sunset 1024 procedure defined in section 5.5. 1026 5.1 Message formats 1028 5.1.1 Teredo IPv6 packets encapsulation 1030 Teredo IPv6 packets are transmitted as UDP packets [RFC768] within 1031 IPv4 [RFC791]. The source and destination IP addresses and UDP 1032 ports take values that are specified in this section. Packets can 1033 come in one of two formats, simple encapsulation and encapsulation 1034 with origin indication. 1036 When simple encapsulation is used, the packet will have a simple 1037 format, in which the IPv6 packet is carried as the payload of a UDP 1038 datagram: 1040 +------+-----+-------------+ 1041 | IPv4 | UDP | IPv6 packet | 1042 +------+-----+-------------+ 1044 When relaying packets received from third parties, the server may 1045 insert an origin indication in the first bytes of the UDP payload: 1047 +------+-----+-------------------+-------------+ 1048 | IPv4 | UDP | Origin indication | IPv6 packet | 1049 +------+-----+-------------------+-------------+ 1051 The origin indication encapsulation is an 8-octet element, with the 1052 following content: 1054 +--------+--------+-----------------+ 1055 | 0x00 | 0x00 | Origin port # | 1056 +--------+--------+-----------------+ 1057 | Origin IPv4 address | 1058 +-----------------------------------+ 1060 The first two octets of the origin indication are set to a null 1061 value; this is used to discriminate between the simple 1062 encapsulation, in which the first 4 bits of the packet contain the 1063 indication of the IPv6 protocol, and the origin indication. 1065 The following 16 bits contain the obfuscated value of the port 1066 number from which the packet was received, in network byte order. 1067 The next 32 bits contain the obfuscated IPv4 address from which the 1068 packet was received, in network byte order. In this format, both the 1069 original "IPv4 address" and "UDP port" of the client are obfuscated. 1070 Each bit in the address and port number is reversed; this can be 1071 done by an exclusive OR of the 16-bit port number with the 1072 hexadecimal value 0xFFFF, and an exclusive OR of the 32-bit address 1073 with the hexadecimal value 0xFFFFFFFF. 1075 For example, if the original UDP port number was 337 (hexadecimal 1076 0151) and original IPv4 address was 1.2.3.4 (hexadecimal: 01020304), 1077 the origin indication would contain the value "0000FEAEFEFDFCFB". 1079 When exchanging Router Solicitation and Router Advertisement 1080 messages between a client and its server, the packets may include an 1081 authentication parameter: 1083 +------+-----+----------------+-------------+ 1084 | IPv4 | UDP | Authentication | IPv6 packet | 1085 +------+-----+----------------+-------------+ 1087 The authentication encapsulation is a variable length-element, 1088 containing a client identifier, an authentication value, a nonce 1089 value, and a confirmation byte. 1091 +--------+--------+--------+--------+ 1092 | 0x00 | 0x01 | ID-len | AU-len | 1093 +--------+--------+--------+--------+ 1094 | Client identifier (ID-len | 1095 +-----------------+-----------------+ 1096 | octets) | Authentication | 1097 +-----------------+--------+--------+ 1098 | value (AU-len octets) | Nonce | 1099 +--------------------------+--------+ 1100 | value (8 octets | 1101 +--------------------------+--------+ 1102 | | Conf. | 1103 +--------------------------+--------+ 1105 The first octet of the authentication encapsulation is set to a null 1106 value, and the second octet is set to the value 1; this enables 1107 differentiation from IPv6 packets and from origin information 1108 indication encapsulation. The third octet indicates the length of 1109 the client identifier; the fourth octet indicates the length of the 1110 authentication value. The computation of the authentication value is 1111 specified in section 5.2.2. The authentication value is followed by 1112 an 8-octet nonce, and by a confirmation byte. 1114 Authentication and origin indication encapsulations may sometimes be 1115 combined, for example in the RA responses sent by the server. In 1116 this case, the authentication encapsulation MUST be the first 1117 element in the UDP payload: 1119 +------+-----+----------------+--------+-------------+ 1120 | IPv4 | UDP | Authentication | Origin | IPv6 packet | 1121 +------+-----+----------------+--------+-------------+ 1123 5.1.2 Maximum Transmission Unit 1125 Since Teredo uses UDP as an underlying transport, a Teredo 1126 Maximum Transmission Unit (MTU) could potentially be as large as the 1127 payload of the largest valid UDP datagram (65507 bytes). However, 1128 since Teredo packets can travel on unpredictable paths over the 1129 Internet, it is best to contain this MTU to a small size, in order 1130 to minimize the effect of IPv4 packet fragmentation and reassembly. 1131 The default link MTU assumed by a host, and the link MTU supplied by 1132 a Teredo server during router advertisement SHOULD normally be set 1133 to the minimum IPv6 MTU size of 1280 bytes [RFC2460]. 1135 Teredo implementations SHOULD NOT set the Don't Fragment (DF) bit of 1136 the encapsulating IPv4 header. 1138 5.2 Teredo Client specification 1140 Before using the Teredo service, the client must be configured with: 1142 - the IPv4 address of a server. 1144 If secure discovery is required, the client must also be configured 1145 with: 1147 - a client identifier, 1148 - a secret value, shared with the server. 1150 A Teredo client expects to exchange IPv6 packets through an UDP 1151 port, the Teredo service port. The client will maintain the 1152 following variables that reflect the state of the Teredo service: 1154 - Teredo connectivity status, 1155 - Mapped address and port number associated with the Teredo service 1156 port, 1157 - Teredo IPv6 prefix associated with the Teredo service port, 1158 - Teredo IPv6 address or addresses derived from the prefix, 1159 - Link local address, 1160 - Date and time of the last interaction with the Teredo server, 1161 - Teredo Refresh Interval, 1162 - Randomized Refresh Interval, 1163 - List of recent Teredo peers. 1165 Before sending any packets, the client must perform the Teredo 1166 qualification procedure, which determines the Teredo connectivity 1167 status, the mapped address and port number, and the Teredo IPv6 1168 prefix; it should then perform the cone NAT determination procedure, 1169 which determines the cone NAT status and may alter the value of the 1170 prefix. If the qualification is successful, the client may use the 1171 Teredo service port to transmit and receive IPv6 packets, according 1172 to the transmission and reception procedures; these procedures use 1173 the "list of recent peers". For each peer, the list contains: 1175 - The IPv6 address of the peer, 1176 - The mapped IPv4 address and mapped UDP port of the peer, 1177 - The status of the mapped address, i.e. trusted or not, 1178 - The value of the last "nonce" sent to the peer, 1179 - The date and time of the last reception from the peer, 1180 - The date and time of the last transmission to the peer, 1181 - The number of bubbles transmitted to the peer. 1183 The list of peers is used to enable the transmission of IPv6 packets 1184 by using a "direct path" for the IPv6 packets. The list of peers 1185 could grow over time. Clients should implement a list management 1186 strategy, for example deleting the least recently used entries. 1187 Clients should make sure that the list has a sufficient size, to 1188 avoid unnecessary exchanges of bubbles. 1190 The client must regularly perform the maintenance procedure in order 1191 to guarantee that the Teredo service port remains usable; the need 1192 to use this procedure or not depends on the delay since the last 1193 interaction with the Teredo server. The refresh procedure takes as a 1194 parameter the "Teredo refresh interval". This parameter is initially 1195 set to 30 seconds; it can be updated as a result of the optional 1196 "interval determination procedure." The randomized refresh interval 1197 is set to a value randomly chosen between 75% and 100% of the 1198 refresh interval. 1200 In order to avoid triangle routing for stations that are located 1201 behind the same NAT, the Teredo clients MAY use the optional local 1202 client discovery procedure defined in section 5.2.8. 1204 5.2.1 Qualification procedure 1206 The purpose of the qualification procedure is to establish the 1207 status of the local IPv4 connection, and to determine the Teredo 1208 IPv6 client prefix of the local Teredo interface. The procedure 1209 starts when the service is in the "initial" state, and results in a 1210 "qualified" state if successful, and in an "off-line" state if 1211 unsuccessful. 1213 /---------\ 1214 | Initial | 1215 \---------/ 1216 | 1217 +----+----+ 1218 | Set C=1 | 1219 +----+----+ 1220 | 1221 +<-----------------------------------------+ 1222 | | 1223 +----+----+ | 1224 | Start |<------+ | 1225 +----+----+ | +----+----+ 1226 | | | Set C=0 | 1227 v | +----+----+ 1228 /---------\ Timer | ^ 1229 |Starting |-------+ N attempts /----------\ Yes | 1230 \---------/------------------->| C == 1 ? |-----+ 1231 | Response \----------/ 1232 | | No 1233 V V 1234 /---------\ Yes /----------\ 1235 | C == 0? |---------+ | Off line | 1236 \---------/ | \----------/ 1237 No | v 1238 | /----------\ 1239 | | Cone NAT | 1240 +-----+-----+ \----------/ 1241 | New Server| 1242 +-----+-----+ 1243 | 1244 +----+----+ 1245 | Start |<------+ 1246 +----+----+ | 1247 | | 1248 v | 1249 /---------\ Timer | 1250 |Starting |-------+ N attempts /----------\ 1251 \---------/------------------->| Off line | 1252 | Response \----------/ 1253 | 1254 V 1255 /------------\ No /---------------\ 1256 | Same port? |-------->| Symmetric NAT | 1257 \------------/ \---------------/ 1258 | Yes 1259 V 1260 /-----------------\ 1261 | Restricted NAT | 1262 \-----------------/ 1264 Initially, the Teredo connectivity status is set to "Initial". 1266 When the interface is initialized, the system first performs the 1267 "start action" by sending a Router Solicitation message, as defined 1268 in [RFC2461]. The client picks a link-local address and uses it as 1269 the IPv6 source of the message; the "cone" bit in the address is set 1270 to 1; the IPv6 destination of the RS is the all-routers multicast 1271 address; the packet will be sent over UDP from the service port to 1272 the Teredo server's IPv4 address and Teredo UDP port. The 1273 connectivity status moves then to "Starting". 1275 In the starting state, the client waits for a router advertisement 1276 from the Teredo server. If no response comes within a time-out T, 1277 the client should repeat the start action, by resending the Router 1278 Solicitation message. If no response has arrived after N 1279 repetitions, the client concludes that it is not behind a cone NAT. 1280 It sets the "cone" bit to 0, and repeats the procedure. If after N 1281 other timer expirations and retransmissions there is still no 1282 response, the client concludes that it cannot use UDP, and that the 1283 Teredo service is not available; the status is set to "Off-line." In 1284 accordance with [RFC2461], the default time-out value is set to T=4 1285 seconds, and the maximum number of repetitions is set to N=3. 1287 If a response arrives, the client checks that the response contains 1288 an origin indication and a valid router advertisement as defined in 1289 [RFC2461], that the IPv6 destination address is equal to the link- 1290 local address used in the router solicitation, and that the router 1291 advertisement contains exactly one advertised Prefix Information 1292 option. This prefix should be a valid Teredo IPv6 server prefix: the 1293 first 32 bits should contain the global Teredo IPv6 service prefix, 1294 and the next 32 bits should contain the server's IPv4 address. If 1295 this is the case, the client learns the Teredo mapped address and 1296 Teredo mapped port from the origin indication. The source address of 1297 the Router Advertisement is a link-local server address of the 1298 Teredo server. (Responses that are not valid advertisements are 1299 simply discarded.) 1301 If the client has received an RA with the "Cone" bit set to 1, it is 1302 behind a cone NAT and is fully qualified. If the RA is received with 1303 the Cone bit set to 0, the client does not know whether the local 1304 NAT is restricted or symmetric. The client selects a secondary IPv4 1305 server address, and repeats the procedure, the cone bit remaining to 1306 the value zero. If the client does not receive a response, it 1307 detects that the service is not usable. If the client receives a 1308 response, it compares the mapped address and mapped port in this 1309 second response to the first received values. If the values are 1310 different, the client detects a symmetric NAT: it cannot use the 1311 Teredo service. If the values are the same, the client is detects a 1312 restricted cone NAT: the client is qualified to use the service. 1314 If the client is qualified, it builds a Teredo IPv6 address using 1315 the Teredo IPv6 server prefix learned from the RA and the obfuscated 1316 values of the UDP port and IPv4 address learned from the origin 1317 indication. The cone bit should be set to the value used to receive 1318 the RA, i.e. 1 if the client is behind a cone NAT, 0 otherwise. The 1319 client can start using the Teredo service. 1321 5.2.2 Secure qualification 1323 The client may be required to perform secured qualification. The 1324 client will perform exactly the algorithm described in 5.2.1, but it 1325 will incorporate an authentication encapsulation in the UDP packet 1326 carrying the router solicitation message, and it will verify the 1327 presence of a valid authentication parameter in the UDP message that 1328 carries the router advertisement provided by the sender. 1330 In these packets, the nonce value is chosen by the client, and is 1331 repeated in the response from the server; the client identifier is a 1332 value with which the client was configured. The confirmation byte is 1333 set to 0 by the client. A null value returned by the server 1334 indicates that the client's key is still valid; a non-null value 1335 indicates that the client should obtain a new key. 1337 The authentication value is computed according to the HMAC 1338 specification [RFC2104] using the following specifications: 1340 - the hash function shall be the MD5 function [RFC1321]. 1341 - the secret value shall be the shared secret with which the client 1342 was configured 1344 The clear text to be protected includes: 1346 - the nonce value, 1347 - the confirmation byte, 1348 - the origin indication encapsulation, if it is present, 1349 - the IPv6 packet. 1351 If the HMAC verification fails, the packet is silently discarded. 1353 5.2.3 Packet reception 1355 The Teredo client receives packets over the Teredo interface. The 1356 role of the packet reception procedure, besides receiving packets, 1357 is to maintain the date and time of the last interaction with the 1358 Teredo server, and the "list of recent peers." 1360 When a UDP packet is received over the Teredo service port, the 1361 Teredo client checks that it is encoded according to the packet 1362 encoding rules defined in 5.1.1, and that it contains either a valid 1363 IPv6 packet as specified in [RFC2460], or the combination of a valid 1364 origin indication encapsulation and a valid IPv6 packet, possibly 1365 protected by a valid authentication encapsulation. If this is not 1366 the case, the packet is silently discarded. 1368 Then, the Teredo client examines the IPv4 source address and UDP 1369 port number from which the packet is received. If these values match 1370 the IPv4 address of the server and the Teredo port, the client 1371 updates the "date and time of the last interaction with the Teredo 1372 server" to the current date and time; if an origin indication is 1373 present, the client should perform the "direct IPv6 connectivity 1374 test" described in section 5.2.9. 1376 If the values are different, the client examines the IPv6 source 1377 address of the packet: 1379 1) If there is an entry for the source IPv6 address in the list of 1380 peers whose status is trusted, the client compares the mapped IPv4 1381 address and mapped port in the entry with the source IPv4 address 1382 and source port of the packet. If the values match, the packet 1383 should be accepted; the date and time of the last reception from the 1384 peer should be updated. 1386 2) If there is an entry for the source IPv6 address in the list of 1387 peers whose status is not trusted, the client checks whether the 1388 packet is an ICMPv6 echo reply. If this is the case, and if the 1389 content of the reply matches the "nonce" stored in the peer entry, 1390 the packet should be accepted; the status of the entry should be 1391 changed to "trusted", the mapped IPv4 and mapped port in the entry 1392 should be set to the source IPv4 address and source port from which 1393 the packet was received, and the date and time of the last reception 1394 from the peer should be updated; any packet queued for this IPv6 1395 peer should be de-queued and forwarded to the newly learned IPv4 1396 address and UDP port. 1398 3) If the source IPv6 address is a Teredo address, the client 1399 compares the mapped IPv4 address and mapped port in the source 1400 address with the source IPv4 address and source port of the packet. 1401 If the values match, the client MUST create a peer entry for the 1402 IPv6 source address in the list of peers; it should update the entry 1403 if one already existed; the mapped IPv4 address and mapped port in 1404 the entry should be set to the value from which the packet was 1405 received, and the status should be set to "trusted". If a new entry 1406 is created, the last transmission date is set to 30 seconds before 1407 the current date, and the number of bubbles to zero. If the packet 1408 is a bubble, it should be discarded after this processing; 1409 otherwise, the packet should be accepted. In all cases, the client 1410 must de-queue and forward any packet queued for that destination. 1412 4) If the source IPv6 address is a Teredo address, and the mapped 1413 IPv4 address and mapped port in the source address do not match the 1414 source IPv4 address and source port of the packet, the client checks 1415 whether the is an existing "local" entry for that IPv6 address. If 1416 there is such an entry, and if the local IPv4 address and local port 1417 indicated in that entry match the source IPv4 address and source 1418 port of the packet, the client updates the "local" entry, whose 1419 status should be set to "trusted". If the packet is a bubble, it 1420 should be discarded after this processing; otherwise, the packet 1421 should be accepted. In all cases, the client must de-queue and 1422 forward any packet queued for that destination. 1424 5) If the IPv4 destination address through which the packet was 1425 received is the Teredo IPv4 Discovery Address, the source address is 1426 a valid Teredo address, and the destination address is the "all 1427 nodes on link" multicast address, the packet should be treated as a 1428 local discovery bubble. If no local entry already existed for the 1429 source address, a new one is created, but its status is set to "not 1430 trusted". The client SHOULD reply with a unicast Teredo bubble, sent 1431 to the source IPv4 address and source port of the local discovery 1432 bubble; the IPv6 source address of the bubble will be set to local 1433 Teredo IPv6 address; the IPv6 destination address of the bubble 1434 should be set to the IPv6 source address of the local discovery 1435 bubble. 1437 6) In the other cases, the packet may be accepted, but the client 1438 should be conscious that the source address may be spoofed; before 1439 processing the packet, the client should perform the "direct IPv6 1440 connectivity test" described in section 5.2.9. 1442 Whatever the IPv4 source address and UDP source port, the client 1443 that receives an IPv6 packet MAY send a Teredo bubble towards that 1444 target, as specified in section 5.2.6. 1446 5.2.4 Packet transmission 1448 When a Teredo client has to transmit a packet over a Teredo 1449 interface, it examines the destination IPv6 address. The client 1450 checks first if there is an entry for this IPv6 address in the list 1451 of recent Teredo peers, and if the entry is still valid: an entry 1452 associated with a local peer is valid if the last reception date and 1453 time associated with that list entry is less that 30 seconds from 1454 the current time; an entry associated with a non-local peer is valid 1455 if the last reception date and time associated with that list entry 1456 is less that 30 seconds from the current time. (Local peer entries 1457 can only be present if the client uses the local discovery procedure 1458 discussed in section 5.2.8.) 1460 The client then performs the following: 1462 1) If there is an entry for that IPv6 address in the list of peers, 1463 and if the status of the entry is set to "trusted", the IPv6 packet 1464 should be sent over UDP to the IPv4 address and UDP port specified 1465 in the entry. The client updates the date of last transmission in 1466 the peer entry. 1468 2) If the destination is not a Teredo IPv6 address, the packet is 1469 queued, and the client performs the "direct IPv6 connectivity test" 1470 described in section 5.2.8. The packet will be de-queued and 1471 forwarded if this procedure completes successfully. If the direct 1472 IPv6 connectivity test fails to complete within a 2 second time-out, 1473 it should be repeated up to 3 times. 1475 3) If the destination is the Teredo IPv6 address of a local peer 1476 (i.e. a Teredo address from which a local discovery bubble has been 1477 received in the last 600 seconds), the packet is queued. The client 1478 sends a unicast Teredo bubble to the local IPv4 address and local 1479 port specified in the entry, and a local Teredo bubble to the Teredo 1480 IPv4 discovery address. 1482 4) If the destination is a Teredo IPv6 address in which the cone bit 1483 is set to 1, the packet is sent over UDP to the mapped IPv4 address 1484 and mapped UDP port extracted from that IPv6 address. 1486 5) If the destination is a Teredo IPv6 address in which the cone bit 1487 is set to 0, the packet is queued. If the client is not located 1488 behind a cone NAT, it sends a direct bubble to the Teredo 1489 destination, i.e. to the mapped IP address and mapped port of the 1490 destination. In all cases, the client sends an indirect bubble to 1491 the Teredo destination, sending it over UDP to the server address 1492 and to the Teredo port. The packet will be de-queued and forwarded 1493 when the client receives a bubble or another packet directly from 1494 this Teredo peer. If no bubble is received within a 2 second time- 1495 out, the bubble transmission should be repeated up to 3 times. 1497 In cases 4 and 5, before sending a packet over UDP, the client MUST 1498 check that the IPv4 destination address is in the format of a global 1499 unicast address; if this is not the case, the packet MUST be 1500 silently discarded. (Note that a packet can legitimately be sent to 1501 a non-global unicast address in case 1, as a result of the local 1502 discovery procedure.) 1504 5.2.5 Maintenance 1506 The Teredo client must ensure that the mappings that it uses remain 1507 valid. It does so by checking that packets are regularly received 1508 from the Teredo server. 1510 At regular intervals, the client MUST check the "date and time of 1511 the last interaction with the Teredo server", to ensure that at 1512 least one packet has been received in the last Randomized Teredo 1513 Refresh Interval. If this is not the case, the client SHOULD send a 1514 router solicitation message to the server, as specified in 5.2.1; 1515 the client should use the same value of the "cone" bit that resulted 1516 in the reception of an RA during the qualification procedure. 1518 When the router advertisement is received, the client SHOULD check 1519 its validity as specified in 5.2.1; invalid advertisements are 1520 silently discarded. If the advertisement is valid, the client MUST 1521 check that the mapped address and port correspond to the current 1522 Teredo address. If this is not the case, the mapping has changed; 1523 the client must mark the old address as invalid, and start using the 1524 new address. 1526 5.2.6 Sending Teredo Bubbles 1528 The Teredo client may have to send a bubble towards another Teredo 1529 client, either after a packet reception or after a transmission 1530 attempt, as explained in sections 5.2.3 and 5.2.4. 1532 When a Teredo client attempts to send a bubble, it extracts the 1533 mapped IPv4 address and mapped UDP port from the Teredo IPv6 address 1534 of the target. It then checks whether there is already an entry for 1535 this IPv6 address in the current list of peers. If there is no 1536 entry, the client MUST create a new list entry for the address, 1537 setting the last reception date and the last transmission date to 30 1538 seconds before the current date, and the number of bubbles to zero. 1540 Bubbles may be lost in transit, and it is reasonable to enhance the 1541 reliability of the Teredo service by allowing multiple 1542 transmissions; however, bubbles will also be lost systematically in 1543 certain NAT configurations. In order to strike a balance between 1544 reliability and unnecessary retransmissions, we specify the 1545 following: 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 1644 - UDP source port: the Teredo service port of the sender 1646 - UDP destination port: the Teredo UDP port 1648 - UDP payload: a minimal IPv6 packet, as follows 1650 - IPv6 source: the Teredo IPv6 address of the sender 1652 - IPv6 destination: the all-nodes on-link multicast address 1654 - IPv6 payload type: 59 (No Next Header, as per [RFC2460]) 1656 - IPv6 payload length: 0 1658 - IPv6 hop limit: 1 1660 The local discovery procedure carries a denial of service risk, as 1661 malevolent nodes could send fake bubbles to unsuspecting parties, 1662 and thus capture the traffic originating from these parties. The 1663 risk is mitigated by the filtering rules described in section 5.2.5, 1664 and also by "link only" multicast scope of the Teredo IPv4 Discovery 1665 Address, which implies that packets sent to this address will not be 1666 forwarded across routers. 1668 To benefit from the "link only multicast" protection, the clients 1669 should silently discard all local discovery bubbles that are 1670 received over a unicast address. To further mitigate the denial of 1671 service risk, the client MUST silently discard all local discovery 1672 bubbles whose IPv6 source address is not a well-formed Teredo IPv6 1673 address, or whose IPv4 source address does not belong to the local 1674 IPv4 subnet; the client MAY decide to silently discard all local 1675 discovery bubbles whose Teredo IPv6 address do not include the same 1676 mapped IPv4 address as its own. 1678 If the bubble is accepted, the client checks whether there is an 1679 entry in the list of recent peers that correspond to the mapped IPv4 1680 address and mapped UDP port associated with the source IPv6 address 1681 of the bubble. If there is such an entry, the client MUST update the 1682 local peer address and local peer port parameters to reflect the 1683 IPv4 source address and UDP source port of the bubble. If there is 1684 no entry, the client MUST create one, setting the local peer address 1685 and local peer port parameters to reflect the IPv4 source address 1686 and UDP source port of the bubble the last reception date to the 1687 current date and time, the last transmission date to 30 seconds 1688 before the current date, and the number of bubbles to zero; the 1689 state of the entry is set to "not trusted". 1691 Upon reception of a discovery bubble, clients reply with a unicast 1692 bubble as specified in section 5.2.3. 1694 5.2.9 Direct IPv6 connectivity test 1696 The Teredo procedures are designed to enable direct connections 1697 between a Teredo host and a Teredo relay. Teredo hosts located 1698 behind a cone NAT will receive packets directly from relays; other 1699 Teredo hosts will learn the original addresses and UDP ports of 1700 third parties through the local Teredo server. In all of these 1701 cases, there is a risk that the IPv6 address of the source be 1702 spoofed by a malevolent party. Teredo hosts must make two decisions, 1703 whether to accept the packet for local processing, and whether to 1704 transmit further packets to the IPv6 address through the newly 1705 learned IPv4 address and UDP port. The basic rule is that the hosts 1706 should be generous in what they accept, and careful in what they 1707 send. Refusing to accept packets due to spoofing concerns would 1708 compromise connectivity, and should only be done when there is a 1709 near certainty that the source address is spoofed; on the other 1710 hand, sending packets to the wrong address should be avoided. 1712 When it wants to send a packet to an IPv6 node on the IPv6 Internet, 1713 the client should check whether a valid peer entry already exists 1714 for the IPv6 address of the destination. If this is not the case, 1715 the client will pick a random number (a nonce) and format an ICMPv6 1716 Echo Request message whose source is the local Teredo address, whose 1717 destination is the address of the IPv6 node, and whose Data field is 1718 set to the nonce. The nonce value and the date at which the packet 1719 was sent will be documented in a provisional peer entry for the IPV6 1720 destination. The ICMPv6 packet will then be sent encapsulated in a 1721 UDP packet bound to the local server IPv4 address, and to the Teredo 1722 port. The rules of section 5.2.3 specify how the reception of this 1723 packet will be processed. 1725 5.3 Teredo Server specification 1727 The Teredo server is designed to be stateless. The Teredo server 1728 waits for incoming UDP packets at the Teredo Port, using the IPv4 1729 address that has been selected for the service. 1731 The Teredo server acts as an IPv6 router. As such, it will receive 1732 Router Solicitation messages, to which it will respond with Router 1733 Advertisement messages as explained in section 5.3.2; it may also 1734 receive other packets, for example ICMPv6 messages, which are 1735 processed according to the IPv6 specification. 1737 5.3.1 Processing of Teredo IPv6 packets 1739 Upon reception of a packet on the Teredo port, the Teredo server 1740 will first check that the UDP payload contains a valid IPv6 packet; 1741 if this is not the case, the packet will be silently discarded. 1743 Before processing the packet, the Teredo server MUST check the 1744 validity of the encapsulated IPv6 source address, the IPv4 source 1745 address and the UDP source port: 1747 1) If the UDP content is not a well formed IPv6 packet, the packet 1748 MUST be silently discarded. 1750 2) If the UDP packet is not a bubble or an ICMPv6 message, it should 1751 be discarded. 1753 3) If the IPv4 source address is not in the format of a global 1754 unicast address, the packet MUST be silently discarded. 1756 4) If the IPv6 source address is an IPv6 link-local address, the 1757 IPv6 destination address is the link-local scope all routers 1758 multicast address (FF02::2), and the packet contains an ICMPv6 1759 Router Solicitation message, the packet SHOULD be accepted; it 1760 MUST be discarded if the server requires secure qualification and 1761 the authentication encapsulation is absent or cannot be verified. 1763 5) If the IPv6 source address is a Teredo IPv6 address, and if the 1764 IPv4 address and UDP port embedded in that address match the IPv4 1765 source address and UDP source port, the packet SHOULD be 1766 accepted. 1768 6) If the IPv6 source address is not a Teredo IPv6 address, and if 1769 the IPv6 destination address is a Teredo address allocated 1770 through this server, the packet SHOULD be accepted. 1772 7) In all other cases, the packet MUST be silently discarded. 1774 The Teredo server will then check the IPv6 destination address of 1775 the encapsulated IPv6 packet. 1777 If the IPv6 destination address is the link-local scope all routers 1778 multicast address (FF02::2), or the link-local address of the 1779 server, the Teredo server processes the packet; it may have to 1780 process Router Solicitation messages and ICMPv6 Echo Request 1781 messages. If the destination IPv6 address is not a global scope IPv6 1782 address, the packet MUST NOT be forwarded. 1784 If the destination address is not a Teredo IPv6 address, the packet 1785 should be relayed to the IPv6 Internet using regular IPv6 routing. 1787 If the IPv6 destination address is a valid Teredo IPv6 address, the 1788 Teredo Server MUST check that the IPv4 address derived from this 1789 IPv6 address is in the format of a global unicast address; if this 1790 is not the case, the packet MUST be silently discarded. 1792 If the address is valid, the Teredo server encapsulates the IPv6 1793 packet in a new UDP datagram, in which the following parameters are 1794 set: 1796 - The destination IPv4 address is derived from the IPv6 destination. 1798 - The source IPv4 address is the server's IPv4 address. 1800 - The destination UDP port is derived from the IPv6 destination. 1802 - The source UDP port is set to the Teredo UDP Port. 1804 If the destination IPv6 address is a Teredo client whose address is 1805 serviced by this specific server, the server should insert an origin 1806 indication in the first bytes of the UDP payload, as specified in 1807 section 5.1.1. 1809 5.3.2 Processing of router solicitations 1811 When the Teredo server receives a Router Solicitation message (RS, 1812 [RFC2641]), it retains the IPv4 address and UDP port from which the 1813 solicitation was received; these become the Teredo mapped address 1814 and Teredo mapped port of the client. The router uses these values 1815 to compose the origin indication encapsulation that will be sent 1816 with the response to the solicitation. 1818 The Teredo server responds to the router solicitation by sending a 1819 Router Advertisement message [RFC2641]. The router advertisement 1820 MUST advertise the Teredo IPv6 prefix composed from the service 1821 prefix and the server's IPv4 address. The IPv6 source address should 1822 be set to a Teredo link-local server address associated to the local 1823 interface. The IPv6 destination address is set to the IPv6 source 1824 address of the RS. The Router Advertisement message must be sent 1825 over UDP to the Teredo mapped address and Teredo mapped port of the 1826 client; the IPv4 source address and UDP source port should be set to 1827 the server's IPv4 address and Teredo Port. If the cone bit of the 1828 client's IPv6 address is set to 1, the RA must be sent from a 1829 different IPv4 source address than the server address over which the 1830 RS was received; if the cone bit is set to zero, the response must 1831 be sent back from the same address. 1833 Before sending the packet, the Teredo server MUST check that the 1834 IPv4 destination address is in the format of a global unicast 1835 address; if this is not the case, the packet MUST be silently 1836 discarded. 1838 If secure qualification is required, the server must insert a valid 1839 authentication parameter in the UDP packet carrying the router 1840 advertisement. The client identifier and the nonce value used in the 1841 authentication parameter must be the same identifier as received in 1842 the router solicitation; the confirmation byte should be set to zero 1843 if the client identifier is still valid, and a non-null value 1844 otherwise; the authentication value should be computed using the 1845 secret that corresponds to the client identifier. 1847 5.4 Teredo Relay specification 1849 Teredo relays are IPv6 routers that advertise reachability of the 1850 Teredo service IPv6 prefix through the IPv6 routing protocols. 1851 Teredo relays will receive IPv6 packets bound to Teredo clients. 1852 Teredo relays should be able to receive packets sent over IPv4 and 1853 UDP by Teredo clients; they may apply filtering rules, e.g. only 1854 accept packets from Teredo clients if they have previously sent 1855 traffic to these Teredo clients. 1857 The receiving and sending rules used by Teredo relays are very 1858 similar to those of Teredo clients. Teredo relays must use a Teredo 1859 service port to transmit packets to Teredo clients; they must 1860 maintain a "list of peers", identical to the list of peers 1861 maintained by Teredo clients. However, Teredo relays do not have to 1862 perform the qualification procedure. 1864 5.4.1 Transmission by relays to Teredo clients 1866 When a Teredo relay has to transmit a packet to a Teredo client, it 1867 examines the destination IPv6 address. By definition, the Teredo 1868 relays will only send over UDP IPv6 packets whose IPv6 destination 1869 address is a valid Teredo IPv6 address. Before processing these 1870 packets, the Teredo Server MUST check that the IPv4 destination 1871 address embedded in the Teredo IPv6 address is in the format of a 1872 global unicast address; if this is not the case, the packet MUST be 1873 silently discarded. 1875 The relay then checks if there is an entry for this IPv6 address in 1876 the list of recent Teredo peers, and if the entry is still valid. 1877 The relay then performs the following: 1879 1) If there is an entry for that IPv6 address in the list of peers, 1880 and if the status of the entry is set to "trusted", the IPv6 packet 1881 should be sent over UDP to the mapped IPv4 address and mapped UDP 1882 port of the entry. The client updates the date of last transmission 1883 in the peer entry. 1885 2) If the destination is a Teredo IPv6 address in which the cone bit 1886 is set to 1, the packet is sent over UDP to the mapped IPv4 address 1887 and mapped UDP port extracted from that IPv6 address. 1889 3) If the destination is a Teredo IPv6 address in which the cone bit 1890 is set to 0, the packet is queued. The Teredo relay creates a bubble 1891 whose source address is set to a local IPv6 address, and whose 1892 destination address is set to the Teredo IPv6 address of the 1893 packet's destination. The bubble is sent to the non-null server 1894 address corresponding to the Teredo destination. The packet will be 1895 de-queued and forwarded when a bubble or another packet will be 1896 received from this IPv6 address; if no such packet is received 1897 before a time-out of 2 seconds, the Teredo relay may repeat the 1898 bubble, up to three times. 1900 In cases 2 and 3, the Teredo relay should create a peer entry for 1901 the IPv6 address; the entry status is marked as trusted in case 2 1902 (cone NAT), not trusted in case 3. In case 3, if the Teredo relay 1903 happens to be located behind a non-cone NAT, it should also send a 1904 bubble directly to the mapped IPv4 address and mapped port number of 1905 the Teredo destination; this will "open the path" for the return 1906 bubble from the Teredo client. 1908 5.4.2 Reception from Teredo clients 1910 The Teredo relay may receive packets from Teredo clients; the 1911 packets should normally only be sent by clients to which the relay 1912 previously transmitted packets, i.e. clients whose IPv6 address is 1913 present in the list of peers. Relays, like clients, use the packet 1914 reception procedure to maintain the date and time of the last 1915 interaction with the Teredo server, and the "list of recent peers." 1917 When a UDP packet is received over the Teredo service port, the 1918 Teredo relay checks that it contains a valid IPv6 packet as 1919 specified in [RFC2460]. If this is not the case, the packet is 1920 silently discarded. 1922 Then, the Teredo relay examines whether the IPv6 source address is a 1923 valid Teredo address, and if the mapped IPv4 address and mapped port 1924 match the IPv4 source address and port number from which the packet 1925 is received. If this is not the case, the packet is silently 1926 discarded. 1928 The Teredo relay then examines whether there is an entry for the 1929 IPv6 source address in the list of recent peers. If this is not the 1930 case, the packet may be silently discarded. If this is the case, the 1931 entry status is set to "trusted"; the relay updates the "date and 1932 time of the last interaction" to the current date and time. 1934 Finally, the relay examines the destination IPv6 address. If the 1935 destination is the "all nodes multicast address", the packet should 1936 be processed locally. If the destination belongs to a range of IPv6 1937 addresses served by the relay, the packet SHOULD be accepted, and 1938 forwarded to the destination. In the other cases, the packet SHOULD 1939 be silently discarded. 1941 5.4.3 Difference between Teredo Relays and Teredo Servers 1943 Because Teredo servers can relay Teredo packets over IPv6, all 1944 Teredo servers must be capable of behaving as Teredo relays. There 1945 is however no requirement that Teredo relays behave as Teredo 1946 servers. 1948 The dual-role of server and relays implies an additional complexity 1949 for the programming of servers: the processing of incoming packets 1950 should be a combination of the server processing rules defined in 1951 5.3.1, and the relay processing rules defined in 5.4.2. 1953 5.5 Implementation of automatic sunset 1955 Teredo is designed as an interim transition mechanism, and it is 1956 important that it should not be used any longer than necessary. The 1957 "sunset" procedure will be implemented by Teredo clients, servers 1958 and relays, as specified in this section. 1960 The Teredo-capable nodes MUST NOT behave as Teredo clients if they 1961 already have IPv6 connectivity through any other means, such as 1962 native IPv6 connectivity; in particular, nodes that have a global 1963 IPv4 address SHOULD obtain connectivity through the 6to4 service 1964 rather than through the Teredo service. The classic reason why a 1965 node that does not need connectivity would still enable the Teredo 1966 service is to guarantee good performance when interacting with 1967 Teredo clients; however, a Teredo-capable node that has IPv4 1968 connectivity and that has obtained IPv6 connectivity outside the 1969 Teredo service MAY decide to behave as a Teredo relay, and still 1970 obtain good performance when interacting with Teredo clients. 1972 The Teredo servers are expected to participate in the sunset 1973 procedure by announcing a date at which they will stop providing the 1974 service. This date depends on the availability of alternative 1975 solutions to their clients, such as "dual-mode" gateways that behave 1976 simultaneously as IPv4 NATs and IPv6 routers. Most Teredo servers 1977 will not be expected to operate more than a few years, perhaps until 1978 at most 2006. 1980 Teredo relays are expected to have the same life span as Teredo 1981 servers. 1983 6 Discussion of the solution 1985 This section is an attempt at answering various questions about the 1986 design choices. 1988 6.1 Why do we require address obfuscation? 1989 The Teredo address, as specified in section 4.1.1, include an 1990 obfuscated copy of the mapped IPv4 address and UDP port of the 1991 client. This is done to prevent abusive NAT "smartness." We have 1992 experimental evidence that some NATs, probably in a desire to help 1993 applications operate more transparently across NATs, are programmed 1994 to look for occurrence of a 32-bit value that matches their local 1995 address, and to replace any such value by the local IP address 1996 allocated to the client; some may also attempt to translate the port 1997 values; this treatment is performed by some NATs even if they don't 1998 know the details of the application protocol. By obfuscating the 1999 address and port, we prevent the NAT from recognizing their own IPv4 2000 address in the UDP packets exchanged between client and server, and 2001 avoid the errors caused by a possible rewriting. 2003 6.2 Why do we have bubbles and lists of peers? 2005 Our algorithm is designed to provide robustness: the client will 2006 always wait for a successful bubble or packet reception before 2007 transmitting data packets over UDP. This ensures that data packets 2008 will always be transmitted on a direct path to another Teredo 2009 client, or on a direct path to the Teredo relay nearest from an IPv6 2010 peer. 2012 6.3 Why do servers only process bubbles and ICMPv6 messages? 2014 In this specification, Teredo servers are requested to only forward 2015 some minimal packets: initial bubbles between Teredo clients, ICMPv6 2016 messages between Teredo clients and IPv6 peers. This has two 2017 advantages: it greatly reduces the transmission load of servers, and 2018 it also helps in solving some the security issues. 2020 Restricting the traffic to a few bubbles means that the server will 2021 only have to carry a few hundred bits of data for any exchange 2022 between clients and peers. Previous designs allowed transmission of 2023 data through the server, which placed the server at risk: a lazily 2024 programmed client could skip sending bubbles, and send all its 2025 traffic through the server. 2027 Restricting the server to only carry bubbles and ICMPv6 packets 2028 removes a privacy risk: if servers were allowed to carry data, a 2029 client could be convinced to send all its data through a rogue 2030 server, where it could easily be observed. With our design, a server 2031 does not see any actual data, and thus poses a much reduced privacy 2032 risk to its clients. 2034 Restricting the type of packets that a server can relay also reduces 2035 another security risk, the use of the server as a reflection point 2036 in a denial of service attack. An attacker can induce a server to 2037 reflect packets towards a third party, but the structure of these 2038 packets is very limited, which prevents the use of the server in a 2039 "magic packet" attack. 2041 6.4 What if two clients are behind the same NAT? 2043 Our design choice implies some restrictions in the Teredo service. 2044 The first restriction concerns two clients connected to the Internet 2045 through the same NAT. 2047 .----------------------- 2048 | Private network 2049 .--. src=9.0.0.1:4096 .-----. .----------. 2050 (IPv4) src=9.0.0.1:4097;| NAT | | Teredo | 2051 (Internet)<-------------- | BOX | <-- | Client-1 | 2052 ( ) (UDP tunneled | | <. '----------' 2053 '--' IPv6) '-----' | 10.0.0.2:1234 2054 | 9.0.0.1 | | .----------. 2055 | | | | Teredo | 2056 | | '- | Client-2 | 2057 V | '----------' 2058 .--------------. | 10.0.0.3:1234 2059 | Teredo | '----------------------- 2060 | Server | 2061 '--------------' 2063 The first client uses the private address and port 10.0.0.2:1234, 2064 which is mapped to 9.0.0.1:4096 by the NAT; the second client uses 2065 10.0.0.3:1234, mapped to 9.0.0.1:4097. If the first client tries to 2066 send a direct packet to the second client, that packet will be 2067 routed to the address 9.0.0.1:4097, i.e. to the external IP address 2068 of the local NAT. There is no guarantee that the NAT will be able to 2069 correctly process these packets; there is indeed some possibility 2070 that they may be lost, and that the two clients will not be able to 2071 communicate using Teredo. 2073 We deliberately accept this restriction, as the alternative would be 2074 to relay the traffic between the two internal clients through the 2075 Teredo server. Since the clients are located behind the same NAT, in 2076 the same domain, there is a risk that the clients might exchange 2077 sensitive data without necessarily using proper protection; sending 2078 this data over the Internet to the Teredo server would expose the 2079 clients to a significant risk of information disclosure. 2081 6.5 What about symmetric NAT? 2083 The exchange of bubbles will fail if one of the Teredo clients is 2084 located behind a symmetric NAT; in practice, this means that clients 2085 located behind a symmetric NAT should not use Teredo. 2087 6.6 Do we need the Refresh Interval Determination Procedure? 2089 When the client is initialized, the Teredo Refresh Interval is set 2090 to 30 seconds. This value is lower than the minimum interval found 2091 necessary in a measurement campaign conducted by a Microsoft team in 2092 January 2001; the measured values ranged between 45 seconds and more 2093 than 15 minutes. There is always a risk that some NAT manufacturers 2094 program some ever smaller time to live intervals for their mappings, 2095 but doing so would break many applications and would probably 2096 generate an uproar from Internet users. By picking a conservatively 2097 small value, we guarantee that the service will work with most NATs. 2099 On the other hand, picking a conservative value increases the 2100 maintenance traffic and the load on the Teredo servers. We know that 2101 in many cases interval as large as 5 or 10 minutes would be 2102 adequate; however, we also know that there is a high risk of false 2103 positives, e.g. when a NAT is connected by an ISDN "on demand" link. 2104 The determination procedure is designed to quickly find whether a 2105 value larger than 30 seconds is adequate, while not trying to 2106 achieve a value larger than 2 minutes. The parameters have been 2107 chosen for rapid convergence, i.e. at most 3 iterations between the 2108 initial value of 30 seconds and the maximum value of 120 seconds or 2109 2 minutes. 2111 6.7 Why do we use a Randomized Refresh Interval? 2113 We specify in the maintenance procedure that the interval between 2114 successive refresh must be a random value chosen between 75% and 2115 100% of the Teredo Refresh Interval. This randomization procedure is 2116 meant to avoid the possible risk of synchronization that is inherent 2117 to any periodic refresh mechanism; if synchronization occurred, all 2118 Teredo clients would send their router solicitation messages quasi 2119 simultaneously to the Teredo server, which would overwhelm the 2120 server. A synchronization phenomenon caused by periodic messages is 2121 studied in [SYNCHRO]; the 75%-100% interval is meant to meet the 2122 guidelines developed in this reference publication. 2124 6.8 Scaling, failover and access control 2126 The Teredo service is designed to impose minimal requirements on 2127 servers and relays: capability to send packets over IPv4 using a 2128 regular IPv4 address; capability to send and receive packets over 2129 IPv6; capability to advertise reachability of the Teredo service 2130 prefix in at least some limited scope. These minimal requirements 2131 make it easy to deploy a large number of servers and relays, thus 2132 ensuring scalability of the service. 2134 Teredo clients may obtain a more resilient service if they can use 2135 several different servers. Teredo clients will detect that a server 2136 is failing through the failure of the qualification procedure; they 2137 may try at that point to obtain services from a different server. 2139 6.9 What about firewalls? 2141 The Teredo service is not designed to "transparently traverse 2142 firewalls." A local administrator can decide to allow or disallow 2143 the service, by programming the local firewall to authorize or deny 2144 traffic on the Teredo UDP port. 2146 Implementations of Teredo should include an administrative control 2147 that explicitly enables use of the Teredo service; the service 2148 should not start if not explicitly authorized. 2150 Implementations of Teredo should be configured to shut down the 2151 Teredo service when the Teredo client is connected within a "managed 2152 network", such as an enterprise network. For example, the 2153 implementation of Teredo in Microsoft Windows is configured to shut 2154 down the Teredo service if the client is a member of a Windows 2155 domain. 2157 6.10 Why do we use the name Teredo? 2159 "Teredo navalis" is the Latin name for a little saltwater critter 2160 that is common in the harbors of warm seas and that digs worm holes 2161 in immersed wood pieces, such as boat hulls or pilings. The animal 2162 is not an actual worm - it is a mollusk. The Teredo service also 2163 digs holes, albeit in NATs, not in wood. 2165 On one hand, one may think that the Teredo is a pretty nasty animal. 2166 On the other hand, the animal only survives in relatively clean and 2167 unpolluted water; its recent comeback in several North American 2168 harbors is a testimony to their newly retrieved cleanliness. The 2169 Teredo service should, in turn, contribute to a newly retrieved 2170 transparency of the Internet. 2172 7 Use of Teredo to implement a tunnel service 2174 It may be desirable in some cases to deploy stateful tunnel servers 2175 instead of the stateless Teredo servers. Tunnels servers generally 2176 require more resources, but an advantage is that they can 2177 potentially provide the users with "permanent" IPv6 addresses. 2179 It is possible to design a tunnel server protocol that is compatible 2180 with Teredo, in the sense that the same client could be used either 2181 in the Teredo service or with a tunnel service. In fact, this can be 2182 done by configuring the client with: 2184 - The IPv4 address of a Teredo server that acts as a tunnel broker 2185 - A client identifier 2186 - A shared secret with that server. 2188 The Teredo client will use the secure qualification procedure, as 2189 specified in section 5.2.2. Instead of returning a Teredo prefix in 2190 the router advertisement, the server will return a globally routable 2191 IPv6 prefix; this prefix may be permanently assigned to the client, 2192 which would provide the client with a stable address. The server 2193 will have to keep state, i.e. memorize the association between the 2194 prefix assigned to the client and the mapped IPv4 address and mapped 2195 UDP port of the client. 2197 The Teredo server will advertise reachability of the client prefix 2198 to the IPv6 Internet. Any packet bound to that prefix will be 2199 transmitted to the mapped IPv4 address and mapped UDP port of the 2200 client. 2202 The Teredo client, when it receives the prefix, will notice that 2203 this prefix is a global IPv6 prefix, not in the form of a Teredo 2204 prefix. The client will at that point recognize that it should 2205 operate in tunnel mode. A client that operates in tunnel mode will 2206 execute a much simpler transmission procedure: it will forward any 2207 packet sent to the Teredo interface to the IPv4 address and Teredo 2208 UDP port of the server. 2210 The Teredo client will have to perform the maintenance procedure 2211 described in section 5.2.5. The server will receive the router 2212 solicitation, and may notice a possible change of mapped IPv4 2213 address and mapped UDP port that could result from the 2214 reconfiguration of the mappings inside the NAT. The server should 2215 continue advertising the same IPv6 prefix to the client, and should 2216 update the mapped IPv4 address and mapped UDP port associated to 2217 this prefix, if necessary. 2219 8 Security Considerations 2221 The main objective of Teredo is to provide nodes located behind a 2222 NAT with a globally routable IPv6 address. This enables such nodes 2223 to use IP security services such as IKE, AH or ESP. As such, we can 2224 argue that the service has a positive effect on network security. 2225 However, the security analysis must also envisage the negative 2226 effects of the Teredo services, which we can group in four 2227 categories: security risks of directly connecting a node to the IPv6 2228 Internet, spoofing of Teredo servers to enable a man-in-the-middle 2229 attack, potential attacks aimed at denying the Teredo service to a 2230 Teredo client, and denial of service attacks against non-Teredo 2231 participating nodes that would be enabled by the Teredo service. 2233 In the following, we review in detail these four types of issues, 2234 and we present mitigating strategies for each of them. 2236 8.1 Opening a hole in the NAT 2238 The very purpose of the Teredo service is to make a machine 2239 reachable through IPv6. By definition, the machine using the service 2240 will give up whatever "firewall" service was available in the NAT 2241 box; all services declared locally will become potential target of 2242 attacks from the entire IPv6 Internet. This may sound scary, but 2243 there are three mitigating factors. 2245 The first mitigating factor is the possibility to restrict some 2246 services to only accept traffic from one of the limited address 2247 scopes defined in IPv6, e.g. link-local or site-local. There is no 2248 support for such scopes in Teredo, which implies that limited-scope 2249 services will not be accessed through Teredo, and will be restricted 2250 to whatever other IPv6 connectivity may be available, e.g. direct 2251 traffic with neighbors on the local link, behind the NAT. 2253 The second mitigating factor is the possible use of a "local 2254 firewall" solution, i.e. a piece of software that performs locally 2255 the kind of inspection and filtering that is otherwise performed in 2256 a perimeter firewall. Using such software is recommended. 2258 The third mitigating factor, already noted, is the availability of 2259 end-to-end connectivity, which allows for deployment of IP security 2260 services such as IKE, AH or ESP. Using these services in conjunction 2261 with Teredo is a good policy, as it will protect the client from 2262 possible attacks in intermediate servers such as the NAT, the Teredo 2263 server, or the Teredo relay. 2265 8.2 Using the Teredo service for a man-in-the-middle attack 2267 The goal of the Teredo service is to provide hosts located behind a 2268 NAT with a globally reachable IPv6 address. There is a possible 2269 class of attacks against this service in which an attacker somehow 2270 intercepts the router solicitation, responds with a spoofed router 2271 advertisement, and provides a Teredo client with an incorrect 2272 address. The attacker may have one of two objectives: it may try to 2273 deny service to the Teredo client by providing it with an address 2274 that is in fact unreachable, or it may try to insert itself as a 2275 relay for all client communications, effectively enabling a variety 2276 of "man-in-the-middle" attack. 2278 The secure qualification procedure described in section 5.2.2 2279 enables a good protection against attacks in which a third party 2280 tries to spoof the server. To defeat this protection, the attacker 2281 could try to obtain a copy of the secret shared between client and 2282 server. The most likely way to obtain the shared secret is to listen 2283 to the traffic and mount an offline dictionary attack; to protect 2284 against this attack, the secret shared between client and server 2285 should be provisioned by an automatic procedure and contain 2286 sufficient entropy. 2288 Another way to defeat the protection afforded by the signature 2289 procedure is to mount a complex attack, as follows: 2291 1) Client prepares router solicitation, including authentication 2292 header. 2294 2) Attacker intercepts the solicitation, and somehow manages to 2295 prevent it from reaching the server, for example by mounting a short 2296 duration DoS attack against the server. 2298 3) Attacker replaces the source IPv4 address and source UDP port of 2299 the request by one of its own addresses and port, and forwards the 2300 modified request to the server. 2302 4) Server dutifully notes the IPv4 address from which the packet is 2303 received, verifies that the Authentication encapsulation is correct, 2304 prepares a router advertisement, signs it, and sends it back to the 2305 incoming address, i.e. the attacker. 2307 5) Attacker receives the advertisement, takes note of the mapping, 2308 replaces the IPv4 address and UDP port by the original values in the 2309 intercepted message, and sends the response to the client. 2311 6) Client receives the advertisement, notes that the authentication 2312 header is present and is correct, and uses the proposed prefix and 2313 the mapped addresses in the origin indication encapsulation. 2315 The root cause of the problem is that the NAT is, in itself, a man- 2316 in-the-middle attack. The Authentication encapsulation covers the 2317 encapsulated IPv6 packet, but does not cover the encapsulating IPv4 2318 header and UDP header. It is very hard to devise an effective 2319 signature scheme, since the attacker does not do anything else than 2320 what the NAT legally does! 2322 There are however several mitigating factors that lead us to avoid 2323 worrying too much about this attack. In practice, the gain from the 2324 attack is to either deny service to the client, or obtain a "man-in- 2325 the-middle" position; however, in order to mount the attack, the 2326 attacker must be able to suppress traffic originating from the 2327 client, i.e. have denial of service capability; the attacker must 2328 also be able to observe the traffic exchanged between client and 2329 inject its own traffic in the mix, i.e. have man-in-the-middle 2330 capacity. In summary, the attack is very hard to mount, and the gain 2331 for the attacker is minimal. 2333 8.2.1 End-to-end security 2335 The most effective line of defense of a Teredo client is probably 2336 not to try to secure the Teredo service itself: even if the mapping 2337 can be securely obtained, the attacker would still be able to listen 2338 to the traffic and send spoofed packets. Rather, the Teredo client 2339 should realize that, because it is located behind a NAT, it is in a 2340 situation of vulnerability; it should systematically try to encrypt 2341 its IPv6 traffic, using IPSEC. Even if the IPv4 and UDP headers are 2342 vulnerable, the use of IPSEC will effectively prevent spoofing and 2343 listening of the IPv6 packets by third parties. By providing each 2344 client with a global IPv6 address, Teredo enables the use of IPSEC 2345 and ultimately enhances the security of these clients. 2347 8.3 Denial of the Teredo service 2349 Our analysis outlines five ways to attack the Teredo service. There 2350 are counter-measures for each of these attacks. 2352 8.3.1 Denial of service by a rogue relay 2353 An attack can be mounted on the IPv6 side of the service by setting 2354 up a rogue relay, and letting that relay advertise a route to the 2355 Teredo IPv6 prefix. This is an attack against IPv6 routing, which 2356 can also be mitigated by the same kind of procedures used to 2357 eliminate spurious route advertisements. Dual stack nodes that 2358 implement a "host local" Teredo relays are impervious to this 2359 attack. 2361 8.3.1 Denial of service by server spoofing 2363 In section 8.2, we discussed the use of spoofed router 2364 advertisements to insert an attacker in the middle of a Teredo 2365 conversation. The spoofed router advertisements can also be used to 2366 provision a client with an incorrect address, pointing to either a 2367 non existing IPv4 address or to the IPv4 address of a third party. 2369 The Teredo client will detect the attack when it fails to receive 2370 traffic through the newly acquired IPv6 address. The attack can be 2371 mitigated by using the authentication encapsulation. 2373 8.3.2 Denial of service by exceeding the number of peers 2375 A Teredo client manages a cache of recently-used peers, which makes 2376 it stateful. It is possible to mount an attack against the client by 2377 provoking it to respond to packets that appear to come from a large 2378 number of Teredo peers, thus trashing the cache and effectively 2379 denying the use of direct communication between peers. The effect 2380 will only last as long as the attack is sustained. 2382 8.3.3 Attacks against the local discovery procedure 2384 There is a possible denial of service attack against the local peer 2385 discovery procedure, if attackers can manage to send spoofed local 2386 discovery bubbles to a Teredo client. The checks described in 2387 section 5.2.8 mitigate this attack. Clients who are more interested 2388 in security than in performance could decide to disable the local 2389 discovery procedure; however, if local discovery is disabled, 2390 traffic between local nodes will end up being relayed through a 2391 server external to the local network, which has questionable 2392 security implications. 2394 8.3.4 Attacking the Teredo servers and relays 2396 It is possible to mount a brute force denial of service attack 2397 against the Teredo servers by sending them a very large number of 2398 packets. This attack will have to be "brute force", since the 2399 servers are stateless, and can be designed to process all the 2400 packets that are sent on their access line. 2402 The brute force attack against the Teredo servers is mitigated if 2403 clients are ready to "failover" to another server. Bringing down the 2404 servers will however force the clients that change servers to 2405 renumber their Teredo address. 2407 It is also possible to mount a brute force attack against a Teredo 2408 relay. This attack is mitigated if the relay under attack stops 2409 announcing the reachability of the Teredo service prefix to the IPv6 2410 network: the traffic will be picked up by the next relay. 2412 8.4 Denial of service against non-Teredo nodes 2414 There is a widely expressed concern that transition mechanisms such 2415 as Teredo can be used to mount denial of service attacks, by 2416 injecting traffic at locations where it is not expected. These 2417 attacks fall in three categories: using the Teredo servers as a 2418 reflector in a denial of service attack, using the Teredo server to 2419 carry a denial of service attack against IPv6 nodes, and using the 2420 Teredo relays to carry a denial of service attack against IPv4 2421 nodes. The analysis of these attacks follows. A common mitigating 2422 factor in all cases is the "regularity" of the Teredo traffic, which 2423 contains highly specific patterns such as the Teredo UDP port, or 2424 the Teredo IPv6 prefix. In case of attacks, these patterns can be 2425 used to quickly install filters and remove the offending traffic. 2427 8.4.1 Laundering DOS attacks from IPv4 to IPv4 2429 An attacker can use the Teredo servers as reflectors in a denial of 2430 service attack aimed at an IPv4 target. The attacker can do this in 2431 one of two ways. The first way is to construct a Router Solicitation 2432 message and post it to a Teredo server, using as IPv4 source address 2433 the spoofed address of the target; the Teredo server will then send 2434 a Router advertisement message to the target. The second way is to 2435 construct a Teredo IPv6 address using the Teredo prefix, the address 2436 of a selected server, the IPv4 of the target, and an arbitrary UDP 2437 port, and to then send packets bound to that address to the selected 2438 Teredo server. 2440 Reflector attacks are discussed in [REFLECT], which outlines various 2441 mitigating techniques against such attacks. One of these mitigations 2442 is to observe that 'the traffic generated by the reflectors [has] 2443 sufficient regularity and semantics that it can be filtered out near 2444 the victim without the filtering itself constituting a denial-of- 2445 service to the victim ("collateral damage").' The traffic reflected 2446 by the Teredo servers meets this condition: it is clearly 2447 recognizable, since it originates from the Teredo UDP port; it can 2448 be filtered out safely if the target itself is not a Teredo user. In 2449 addition, the packets relayed by servers will carry an Origin 2450 indication encapsulation, which will help determining the source of 2451 the attack. 2453 8.4.2 DOS attacks from IPv4 to IPv6 2455 An attacker may use the Teredo servers to launch a denial of service 2456 attack against an arbitrary IPv6 destination. The attacker will 2457 build an IPv6 packet bound for the target, and will send that packet 2458 to the IPv4 address and UDP port of a Teredo server, to be relayed 2459 from there to the target over IPv6. 2461 The address checks specified in section 5.3.1 provide some 2462 protection against this attack, as they ensure that the IPv6 source 2463 address will be consistent with the IPv4 source address and UDP 2464 source port used by the attacker: if the attacker cannot spoof the 2465 IPv4 source address, the target will be able to determine the origin 2466 of the attack. 2468 The address checks ensure that the IPv6 source address of packets 2469 forwarded by servers will start with the IPv6 Teredo prefix. This is 2470 a mitigating factor, as sites under attack could use this to filter 2471 out all packets sourced from that prefix during an attack. This will 2472 result in a partial loss of service, as the target will not be able 2473 to communicate with legitimate Teredo hosts that use the same 2474 prefix; however, the communication with other IPv6 hosts will remain 2475 unaffected, and the communication with Teredo hosts will be able to 2476 resume when the attack has ceased. 2478 The ICMP Traceback (ITRACE) working group is considering systems for 2479 "tracing" the source of DOS attacks. According to the proposal, when 2480 forwarding packets, routers can, with a low probability, generate a 2481 Traceback message that is sent along to the destination; with enough 2482 Traceback messages from enough routers along the path, the traffic 2483 source and path can be determined. This set up assumes that the 2484 source and destination are both using the same version of IP. In the 2485 Teredo case, the ICMP Traceback packets will be sent to the Teredo 2486 server, not the final destination. It is conceivable to "map" the 2487 IPv4 traceback to an IPv6 traceback sent by the Teredo server; the 2488 details of the solution should be specified by the ITRACE working 2489 group. 2491 8.4.3 DOS attacks from IPv6 to IPv4 2493 An attacker with IPv6 connectivity may use the Teredo relays to 2494 launch a denial of service attack against an arbitrary IPv4 2495 destination. The attacker will compose a Teredo IPv6 address using 2496 the Teredo prefix, a null server address, the IPv4 address of the 2497 target, an arbitrary UDP port, and an arbitrary node identifier. The 2498 attacker will send IPv6 packets to that address; the packets will be 2499 routed to the nearest Teredo relay, and forwarded from there to the 2500 target. 2502 The address checks specified in 5.4 are limited to verifying that 2503 packets are only relayed to a global IPv4 address. This rules out a 2504 class of attack in which the packets are bound to a broadcast or 2505 multicast address. It also rules out another class of attack in 2506 which the packets are bound for a private IPv4 address that would be 2507 reachable by the relay. 2509 The attack can be targeted at arbitrary UDP ports, such as for 2510 example the DNS port of a server. The UDP payload must be a well- 2511 formed IPv6 packet, and is thus unlikely to be accepted by any well- 2512 written UDP service; in most case, the only effect of the attack 2513 will be to overload the target with random traffic. 2515 A special case occurs if the attack is directed to an echo service. 2516 The service will echo the packets. Since the echo service sees the 2517 request coming from the IPv4 address of the relay, the echo replies 2518 will be sent back to the same relay. According to the rules 2519 specified in 5.4, these packets will be discarded by the Teredo 2520 relay. This is not a very efficient attack against the Teredo relays 2521 - establishing a legitimate session with an actual Teredo host would 2522 create more traffic. 2524 The IPv6 packets sent to the target contain the IPv6 address used by 2525 the attacker. If ingress filtering is used in the IPv6 network, this 2526 address will be hard to spoof. If ingress filtering is not used, the 2527 attacker can be traced if the IPv6 routers use a mechanism similar 2528 to ICMP Traceback. The ICMP messages will normally be collected by 2529 the same relays that forward the traffic from the attacker; the 2530 relays can use these messages to identify the source of an ongoing 2531 attack. The details of this solution should be specified by the 2532 ITRACE working group. 2534 9 IAB considerations 2536 The IAB has studied the problem of "Unilateral Self Address Fixing" 2537 (UNSAF), which is the general process by which a client attempts to 2538 determine its address in another realm on the other side of a NAT 2539 through a collaborative protocol reflection mechanism [RFC3424]. 2540 Teredo is an example of a protocol that performs this type of 2541 function. The IAB has mandated that any protocols developed for this 2542 purpose document a specific set of considerations. This section 2543 meets those requirements. 2545 9.1 Problem Definition 2547 From [RFC3424], any UNSAF proposal must provide a precise definition 2548 of a specific, limited-scope problem that is to be solved with the 2549 UNSAF proposal. A short term fix should not be generalized to solve 2550 other problems; this is why "short term fixes usually aren't". 2552 The specific problems being solved by Teredo is the provision of 2553 IPv6 connectivity for a host that cannot obtain IPv6 connectivity 2554 either natively or by other means, such as 6to4. 2556 9.2 Exit Strategy 2558 From [RFC3424], any UNSAF proposal must provide the description of 2559 an exit strategy/transition plan. The better short term fixes are 2560 the ones that will naturally see less and less use as the 2561 appropriate technology is deployed. 2563 Teredo comes with its own built in exit strategy: as soon as IPv6 2564 connectivity is obtained by other means, Teredo will cease to be 2565 used. In particular, we expect that the next generation of home 2566 routers will provide an IPv6 service in complement to the current 2567 IPv4 NAT service, e.g. by relaying connectivity obtained from the 2568 ISP, or by using a configured or automatic tunnel service. 2570 The exit strategy is facilitated by the nature of Teredo, which 2571 provides an IP level solution. IPv6 aware applications do not have 2572 to be updated to use or not use Teredo. The absence of impact on the 2573 applications makes it easier to migrate out of Teredo: network 2574 connectivity suffices. 2576 9.3 Brittleness Introduced by Teredo 2578 From [RFC3424], any UNSAF proposal must provide a discussion of 2579 specific issues that may render systems more "brittle". For 2580 example, approaches that involve using data at multiple network 2581 layers create more dependencies, increase debugging challenges, and 2582 make it harder to transition. 2584 Teredo introduces brittleness into the system in several ways: the 2585 discovery process assumes a certain classification of devices based 2586 on their treatment of UDP; the mappings need to be continuously 2587 refreshed, while the ; and addressing structure may cause some hosts 2588 located beyond a common NAT to be unreachable from each other. 2589 (There are many similarities between these points and those 2590 introduced by STUN [RFC3489].) 2592 Teredo assumes a certain classification of devices based on their 2593 treatment of UDP, e.g. cone, protected cone and symmetric. There 2594 could be devices that would not fit into one of these molds, and 2595 hence would be improperly classified by Teredo. 2597 The bindings allocated from the NAT need to be continuously 2598 refreshed. Since the timeouts for these bindings is very 2599 implementation specific, the refresh interval cannot easily be 2600 determined. When the binding is not being actively used to 2601 receive traffic, but to wait for an incoming message, the binding 2602 refresh will needlessly consume network bandwidth. 2604 The use of the Teredo server as an additional network element 2605 introduces another point of potential security attack. These 2606 attacks are largely prevented by the security measures provided by 2607 Teredo, but not entirely. 2609 The use of the Teredo server as an additional network element 2610 introduces another point of failure. If the client cannot locate a 2611 Teredo server, or if the server should be unavailable due to 2612 failure, the Teredo client will not be able to obtain IPv6 2613 connectivity. 2615 Teredo imposes some restrictions on the network topologies for 2616 proper operation. In particular, if the same NAT is on the path 2617 between two clients and the Teredo server, these clients will only 2618 be able to interoperate if they are connected to the same link, or 2619 if the common NAT is capable of "looping" packets sent by one client 2620 to another. 2622 9.4 Requirements for a Long Term Solution 2624 From [RFC3424], any UNSAF proposal must identify requirements for 2625 longer term, sound technical solutions -- contribute to the process 2626 of finding the right longer term solution. 2628 Our experience with Teredo has led to the following requirements for 2629 a long term solution to the NAT problem: the devices that implement 2630 the IPv4 NAT services should in the future also become IPv6 routers. 2632 10 IANA Considerations 2634 This memo documents a request to IANA to allocate a Teredo IPv6 2635 service prefix, and a Teredo IPv4 multicast address. 2637 11 Copyright 2639 The following copyright notice is copied from RFC 2026 [Bradner, 2640 1996], Section 10.4, and describes the applicable copyright for this 2641 document. 2643 Copyright (C) The Internet Society September 17, 2002. All Rights 2644 Reserved. 2646 This document and translations of it may be copied and furnished to 2647 others, and derivative works that comment on or otherwise explain it 2648 or assist in its implementation may be prepared, copied, published 2649 and distributed, in whole or in part, without restriction of any 2650 kind, provided that the above copyright notice and this paragraph 2651 are included on all such copies and derivative works. However, this 2652 document itself may not be modified in any way, such as by removing 2653 the copyright notice or references to the Internet Society or other 2654 Internet organizations, except as needed for the purpose of 2655 developing Internet standards in which case the procedures for 2656 copyrights defined in the Internet Standards process must be 2657 followed, or as required to translate it into languages other than 2658 English. 2660 The limited permissions granted above are perpetual and will not be 2661 revoked by the Internet Society or its successors or assignees. 2663 This document and the information contained herein is provided on an 2664 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2665 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2666 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2667 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2668 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2670 12 Intellectual Property 2672 The following notice is copied from RFC 2026 [Bradner, 1996], 2673 Section 10.4, and describes the position of the IETF concerning 2674 intellectual property claims made against this document. 2676 The IETF takes no position regarding the validity or scope of any 2677 intellectual property or other rights that might be claimed to 2678 pertain to the implementation or use other technology described in 2679 this document or the extent to which any license under such rights 2680 might or might not be available; neither does it represent that it 2681 has made any effort to identify any such rights. Information on the 2682 IETF's procedures with respect to rights in standards-track and 2683 standards-related documentation can be found in BCP-11. Copies of 2684 claims of rights made available for publication and any assurances 2685 of licenses to be made available, or the result of an attempt made 2686 to obtain a general license or permission for the use of such 2687 proprietary rights by implementers or users of this specification 2688 can be obtained from the IETF Secretariat. 2690 The IETF invites any interested party to bring to its attention any 2691 copyrights, patents or patent applications, or other proprietary 2692 rights which may cover technology that may be required to practice 2693 this standard. Please address the information to the IETF Executive 2694 Director. 2696 13 Acknowledgements 2698 Many of the ideas in this memo are the result of discussions between 2699 the author and Microsoft colleagues, notably Brian Zill, John 2700 Miller, Mohit Talwar, Joseph Davies and Rick Rashid. Several 2701 encapsulation details are inspired from earlier work by Keith Moore. 2702 The example in section 5.1 and a number of security precautions were 2703 suggested by Pekka Savola. The local discovery procedure was 2704 suggested by Richard Draves and Dave Thaler. The document was 2705 reviewed by the NGTRANS working group; Brian Carpenter, Cyndi Jung, 2706 Keith Moore, Thomas Narten, Anssi Porttikivi, Pekka Savola, and Eng 2707 Soo Guan. 2709 14 References 2711 Normative references 2713 [RFC768] J. Postel, "User Datagram Protocol", RFC 768, August 1980. 2715 [RFC791] J. Postel, "Internet Protocol", RFC 791, September 1981. 2717 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 2718 April 1992. 2720 [RFC1918] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, 2721 E. Lear, "Address Allocation for Private Internets", RFC 1918, 2722 February 1996. 2724 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 2725 Requirement Levels", RFC 2119, March 1997. 2727 [RFC2460] S. Deering, R. Hinden, "Internet Protocol, Version 6 2728 (IPv6) Specification", RFC 2460, December 1998. 2730 [RFC2461] T. Narten, E. Nordmark, W. Simpson, "Neighbor Discovery 2731 for IP Version 6 (IPv6)", RFC 2461, December 1998. 2733 [RFC2462] T. Narten, S. Thomson, "IPv6 Stateless Address 2734 Autoconfiguration", RFC 2462, December 1998. 2736 [RFC3056] B. Carpenter, K. Moore, "Connection of IPv6 Domains via 2737 IPv4 Clouds", RFC 3056, February 2001. 2739 [RFC3068] C. Huitema, "An Anycast Prefix for 6to4 Relay Routers", 2740 RFC 3068, June 2001. 2742 [RFC3424] Daigle, L., Editor, "IAB Considerations for Unilateral 2743 Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 2744 3424, November 2002. 2746 Informative references 2748 [RFC1750] D. Eastlake, S. Crocker, J. Schiller, "Randomness 2749 Recommendations for Security", RFC 1750, December 1994. 2751 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy. 2752 "STUN - Simple Traversal of User Datagram Protocol (UDP) Through 2753 Network Address Translators (NATs)", RFC 3489, March 2003. 2755 [SYNCHRO] S. Floyd, V. Jacobson, "The synchronization of periodic 2756 routing messages", ACM SIGCOMM'93 Symposium, September 1993. 2758 [REFLECT] V. Paxson, "An analysis of using reflectors for 2759 distributed denial of service attacks." Computer Communication 2760 Review, ACM SIGCOMM, Volume 31, Number 3, July 2001, pp 38-47. 2762 15 Authors' Addresses 2764 Christian Huitema 2765 Microsoft Corporation 2766 One Microsoft Way 2767 Redmond, WA 98052-6399 2768 Email: huitema@microsoft.com 2770 Table of Contents: 2772 1 Introduction .................................................... 1 2773 2 Definitions ..................................................... 2 2774 2.1 Teredo service ................................................ 2 2775 2.2 Teredo Client ................................................. 2 2776 2.3 Teredo Server ................................................. 2 2777 2.4 Teredo Relay .................................................. 3 2778 2.5 Teredo IPv6 service prefix .................................... 3 2779 2.5.1 Global Teredo IPv6 service prefix ........................... 3 2780 2.6 Teredo UDP port ............................................... 3 2781 2.7 Teredo bubble ................................................. 3 2782 2.8 Teredo service port ........................................... 3 2783 2.9 Teredo server address ......................................... 3 2784 2.10 Teredo mapped address and Teredo mapped port ................. 3 2785 2.11 Teredo IPv6 client prefix .................................... 3 2786 2.12 Teredo node identifier ....................................... 4 2787 2.13 Teredo IPv6 address .......................................... 4 2788 2.14 Teredo Refresh Interval ...................................... 4 2789 2.15 Teredo secondary port ........................................ 4 2790 2.16 Teredo IPv4 Discovery Address ................................ 4 2791 3 Design goals, requirements, and model of operation .............. 4 2792 3.1 Hypotheses about NAT behavior ................................. 4 2793 3.1.1 Types of UDP mappings ....................................... 5 2794 3.1.2 Lifetime of UDP mappings .................................... 5 2795 3.2 IPv6 provider of last resort .................................. 6 2796 3.2.1 When to use Teredo? ......................................... 6 2797 3.2.2 Autonomous deployment ....................................... 6 2798 3.2.3 Minimal load on servers ..................................... 7 2799 3.2.4 Automatic sunset ............................................ 7 2800 3.3 Operational Requirements ...................................... 7 2801 3.3.1 Robustness requirement ...................................... 7 2802 3.3.2 Minimal support cost ........................................ 7 2803 3.3.3 Protection against denial of service attacks ................ 8 2804 3.3.4 Protection against distributed denial of service attacks .... 8 2805 3.3.5 Compatibility with ingress filtering ........................ 8 2806 4 Model of operation and deployment ............................... 8 2807 4.1 Model of operation ............................................ 8 2808 4.1.1 Encoding of Teredo addresses ................................ 9 2809 4.1.2 Obtaining an address ........................................ 10 2810 4.1.3 Determining the type of NAT ................................. 12 2811 4.1.4 First packet from an IPv6 node to a Teredo node ............. 13 2812 4.1.5 First packet from a Teredo node to a regular IPv6 node ...... 14 2813 4.1.6 Exchanges between two Teredo nodes .......................... 16 2814 4.1.7 Exchanges between two Teredo nodes on the same link ......... 18 2815 4.2 Deployment model .............................................. 19 2816 4.2.1 Server deployment ........................................... 20 2817 4.2.2 Relay deployment ............................................ 20 2818 5 Specification of clients, servers and relays .................... 20 2819 5.1 Message formats ............................................... 21 2820 5.1.1 Teredo IPv6 packets encapsulation ........................... 21 2821 5.1.2 Maximum Transmission Unit ................................... 23 2822 5.2 Teredo Client specification ................................... 23 2823 5.2.1 Qualification procedure ..................................... 24 2824 5.2.2 Secure qualification ........................................ 27 2825 5.2.3 Packet reception ............................................ 27 2826 5.2.4 Packet transmission ......................................... 29 2827 5.2.5 Maintenance ................................................. 30 2828 5.2.6 Sending Teredo Bubbles ...................................... 31 2829 5.2.7 Optional Refresh Interval Determination Procedure ........... 31 2830 5.2.8 Optional local client discovery procedure ................... 32 2831 5.2.9 Direct IPv6 connectivity test ............................... 34 2832 5.3 Teredo Server specification ................................... 34 2833 5.3.1 Processing of Teredo IPv6 packets ........................... 35 2834 5.3.2 Processing of router solicitations .......................... 36 2835 5.4 Teredo Relay specification .................................... 37 2836 5.4.1 Transmission by relays to Teredo clients .................... 37 2837 5.4.2 Reception from Teredo clients ............................... 38 2838 5.4.3 Difference between Teredo Relays and Teredo Servers ......... 39 2839 5.5 Implementation of automatic sunset ............................ 39 2840 6 Discussion of the solution ...................................... 39 2841 6.1 Why do we require address obfuscation? ........................ 39 2842 6.2 Why do we have bubbles and lists of peers? .................... 40 2843 6.3 Why do servers only process bubbles and ICMPv6 messages? ...... 40 2844 6.4 What if two clients are behind the same NAT? .................. 41 2845 6.5 What about symmetric NAT? ..................................... 41 2846 6.6 Do we need the Refresh Interval Determination Procedure? ...... 41 2847 6.7 Why do we use a Randomized Refresh Interval? .................. 42 2848 6.8 Scaling, failover and access control .......................... 42 2849 6.9 What about firewalls? ......................................... 42 2850 6.10 Why do we use the name Teredo? ............................... 43 2851 7 Use of Teredo to implement a tunnel service ..................... 43 2852 8 Security Considerations ......................................... 44 2853 8.1 Opening a hole in the NAT ..................................... 44 2854 8.2 Using the Teredo service for a man-in-the-middle attack ....... 45 2855 8.2.1 End-to-end security ......................................... 46 2856 8.3 Denial of the Teredo service .................................. 46 2857 8.3.1 Denial of service by a rogue relay .......................... 46 2858 8.3.1 Denial of service by server spoofing ........................ 47 2859 8.3.2 Denial of service by exceeding the number of peers .......... 47 2860 8.3.3 Attacks against the local discovery procedure ............... 47 2861 8.3.4 Attacking the Teredo servers and relays ..................... 47 2862 8.4 Denial of service against non-Teredo nodes .................... 48 2863 8.4.1 Laundering DOS attacks from IPv4 to IPv4 .................... 48 2864 8.4.2 DOS attacks from IPv4 to IPv6 ............................... 48 2865 8.4.3 DOS attacks from IPv6 to IPv4 ............................... 49 2866 9 IAB considerations .............................................. 50 2867 9.1 Problem Definition ............................................ 50 2868 9.2 Exit Strategy ................................................. 50 2869 9.3 Brittleness Introduced by Teredo .............................. 51 2870 9.4 Requirements for a Long Term Solution ......................... 52 2871 10 IANA Considerations ............................................ 52 2872 11 Copyright ...................................................... 52 2873 12 Intellectual Property .......................................... 53 2874 13 Acknowledgements ............................................... 53 2875 14 References ..................................................... 53 2876 15 Authors' Addresses ............................................. 54