idnits 2.17.1 draft-huitema-v6ops-teredo-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 12. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2194. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2201. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2207. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 22 instances of lines with control characters in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (March 8, 2004) is 7353 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 928, but not defined == Missing Reference: 'RFC2641' is mentioned on line 1461, but not defined == Missing Reference: 'RFC3667' is mentioned on line 2211, but not defined ** Obsolete undefined reference: RFC 3667 (Obsoleted by RFC 3978) == Unused Reference: 'RFC1918' is defined on line 2135, but no explicit reference was found in the text == Unused Reference: 'RFC3068' is defined on line 2154, but no explicit reference was found in the text == Unused Reference: 'RFC1750' is defined on line 2163, but no explicit reference was found in the text == Unused Reference: 'SYNCHRO' is defined on line 2170, 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 (~~), 12 warnings (==), 8 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 9, 2004 March 8, 2004 5 Teredo: Tunneling IPv6 over UDP through NATs 7 Status of this memo 9 By submitting this Internet-Draft, I certify that any applicable 10 patent or other IPR claims of which I am aware have been disclosed, 11 and any of which I become aware will be disclosed, in accordance 12 with RFC 3668. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 We propose here a service that enables nodes located behind one or 33 more IPv4 NATs to obtain IPv6 connectivity by tunneling packets over 34 UDP; we call this the Teredo service. Running the service requires 35 the help of "Teredo servers" and "Teredo relays"; the Teredo servers 36 are stateless, and only have to manage a small fraction of the 37 traffic between Teredo clients; the Teredo relays act as IPv6 38 routers between the Teredo service and the "native" IPv6 Internet; 39 the relays can also provide interoperability with hosts using other 40 transition mechanisms such as "6to4". 42 Huitema [Page 1] 43 Table of Contents: 45 1 Introduction .................................................... 4 46 2 Definitions ..................................................... 4 47 2.1 Teredo service ................................................ 5 48 2.2 Teredo Client ................................................. 5 49 2.3 Teredo Server ................................................. 5 50 2.4 Teredo Relay .................................................. 5 51 2.5 Teredo IPv6 service prefix .................................... 5 52 2.5.1 Global Teredo IPv6 service prefix ........................... 5 53 2.6 Teredo UDP port ............................................... 5 54 2.7 Teredo bubble ................................................. 5 55 2.8 Teredo service port ........................................... 5 56 2.9 Teredo server address ......................................... 6 57 2.10 Teredo mapped address and Teredo mapped port ................. 6 58 2.11 Teredo IPv6 client prefix .................................... 6 59 2.12 Teredo node identifier ....................................... 6 60 2.13 Teredo IPv6 address .......................................... 6 61 2.14 Teredo Refresh Interval ...................................... 6 62 2.15 Teredo secondary port ........................................ 6 63 2.16 Teredo IPv4 Discovery Address ................................ 6 64 3 Design goals, requirements, and model of operation .............. 6 65 3.1 Hypotheses about NAT behavior ................................. 7 66 3.2 IPv6 provider of last resort .................................. 8 67 3.2.1 When to use Teredo? ......................................... 8 68 3.2.2 Autonomous deployment ....................................... 8 69 3.2.3 Minimal load on servers ..................................... 8 70 3.2.4 Automatic sunset ............................................ 9 71 3.3 Operational Requirements ...................................... 9 72 3.3.1 Robustness requirement ...................................... 9 73 3.3.2 Minimal support cost ........................................ 9 74 3.3.3 Protection against denial of service attacks ................ 9 75 3.3.4 Protection against distributed denial of service attacks .... 9 76 3.3.5 Compatibility with ingress filtering ........................ 10 77 3.4 Model of operation ............................................ 10 78 4 Teredo Addresses ................................................ 11 79 5 Specification of clients, servers and relays .................... 12 80 5.1 Message formats ............................................... 12 81 5.1.1 Teredo IPv6 packet encapsulation ............................ 12 82 5.1.2 Maximum Transmission Unit ................................... 14 83 5.2 Teredo Client specification ................................... 15 84 5.2.1 Qualification procedure ..................................... 16 85 5.2.2 Secure qualification ........................................ 19 86 5.2.3 Packet reception ............................................ 20 87 5.2.4 Packet transmission ......................................... 22 88 5.2.5 Maintenance ................................................. 23 89 5.2.6 Sending Teredo Bubbles ...................................... 23 90 5.2.7 Optional Refresh Interval Determination Procedure ........... 24 91 5.2.8 Optional local client discovery procedure ................... 25 92 5.2.9 Direct IPv6 connectivity test ............................... 26 93 5.2.10 Working around symmetric NAT ............................... 27 95 Huitema [Page 2] 96 5.3 Teredo Server specification ................................... 28 97 5.3.1 Processing of Teredo IPv6 packets ........................... 28 98 5.3.2 Processing of router solicitations .......................... 29 99 5.4 Teredo Relay specification .................................... 30 100 5.4.1 Transmission by relays to Teredo clients .................... 30 101 5.4.2 Reception from Teredo clients ............................... 31 102 5.4.3 Difference between Teredo Relays and Teredo Servers ......... 32 103 5.5 Implementation of automatic sunset ............................ 32 104 6 Use of Teredo to implement a tunnel service ..................... 33 105 7 Security Considerations ......................................... 34 106 7.1 Opening a hole in the NAT ..................................... 34 107 7.2 Using the Teredo service for a man-in-the-middle attack ....... 35 108 7.2.1 End-to-end security ......................................... 36 109 7.3 Denial of the Teredo service .................................. 36 110 7.3.1 Denial of service by a rogue relay .......................... 37 111 8.3.1 Denial of service by server spoofing ........................ 37 112 7.3.2 Denial of service by exceeding the number of peers .......... 37 113 7.3.3 Attacks against the local discovery procedure ............... 37 114 7.3.4 Attacking the Teredo servers and relays ..................... 37 115 7.4 Denial of service against non-Teredo nodes .................... 38 116 7.4.1 Laundering DoS attacks from IPv4 to IPv4 .................... 38 117 7.4.2 DOS attacks from IPv4 to IPv6 ............................... 39 118 7.4.3 DOS attacks from IPv6 to IPv4 ............................... 39 119 8 IAB considerations .............................................. 40 120 8.1 Problem Definition ............................................ 40 121 8.2 Exit Strategy ................................................. 40 122 8.3 Brittleness Introduced by Teredo .............................. 41 123 8.4 Requirements for a Long Term Solution ......................... 42 124 9 IANA Considerations ............................................. 42 125 10 Acknowledgements ............................................... 42 126 11 References ..................................................... 42 127 12 Authors' Addresses ............................................. 43 128 13 Intellectual Property Statement ................................ 44 129 14 Copyright ...................................................... 44 131 Huitema [Page 3] 132 1 Introduction 134 Classic tunneling methods envisaged for IPv6 transition operate by 135 sending IPv6 packets as payload of IPv4 packets; the 6to4 proposal 136 [RFC3056] proposes automatic discovery in this context. A problem 137 with these methods is that they don't work when the IPv6 candidate 138 node is isolated behind a Network Address Translator (NAT) device: 139 NATs are typically not programmed to allow the transmission of 140 arbitrary payload types; even when they are, the local address 141 cannot be used in a 6to4 scheme. 6to4 will work with a NAT if the 142 NAT and 6to4 router functions are in the same box; we want to cover 143 the relatively frequent case when the NAT cannot be readily upgraded 144 to provide a 6to4 router function. 146 A possible way to solve the problem is to rely on a set of "tunnel 147 brokers." There are however limits to any solution that is based on 148 such brokers: the quality of service may be limited, since the 149 traffic follows a "dog leg" route from the source to the broker and 150 then the destination; the broker has to provide sufficient 151 transmission capacity to relay all packets and thus suffers a high 152 cost. For these two reasons, it may be desirable to have solutions 153 that allow for "automatic tunneling", i.e. let the packets follow a 154 direct path to the destination. 156 The automatic tunneling requirement is indeed at odds with some of 157 the specificities of NATs. Establishing a direct path supposes that 158 the IPv6 candidate node can retrieve a "globally routable" address 159 that results from the translation of its local address by one or 160 more NATs; it also supposes that we can find a way to bypass the 161 various "per destination protections" that many NATs implement. In 162 this memo, we will explain how IPv6 candidates located behind NATs 163 can enlist the help of "Teredo servers" and "Teredo relays" to learn 164 their "global address" and to obtain connectivity, and how clients, 165 servers and relays can be organized in Teredo networks. 167 The specification is organized as follows. Section 2 contains the 168 definition of the terms used in the memo. Section 3 presents the 169 hypotheses on NAT behavior used in the design, as well as the 170 operational requirements that the design should meet. Section 4 171 presents the IPv6 address format used by Teredo. Section 5 contains 172 the format of the messages and the specification of the protocol. 173 Section 6 presents the guideline for some further work that would be 174 complementary to the current approach. Section 7 contains a security 175 discussion, section 8 a discussion of the so called "UNSAF" issues, 176 and section 9 contains IANA considerations. 178 2 Definitions 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in [RFC2119]. 184 Huitema [Page 4] 185 This specification uses the following definitions: 187 2.1 Teredo service 189 The transmission of IPv6 packets over UDP, as defined in this memo. 191 2.2 Teredo Client 193 A node that has some access to the IPv4 Internet and wants to gain 194 access to the IPv6 Internet. 196 2.3 Teredo Server 198 A node that has access to the IPv4 Internet through a globally 199 routable address, and is used as a helper to provide IPv6 200 connectivity to Teredo clients. 202 2.4 Teredo Relay 204 An IPv6 router that can receive traffic destined to Teredo clients 205 and forward it using the Teredo service. 207 2.5 Teredo IPv6 service prefix 209 An IPv6 addressing prefix which is used to construct the IPv6 210 address of Teredo clients. 212 2.5.1 Global Teredo IPv6 service prefix 214 An IPv6 addressing prefix whose value is XXXX:XXXX:/32. 215 (TBD IANA; experiments use the value 3FFE:831F::/32, taken from a 216 range of experimental IPv6 prefixes assigned to Microsoft.) 218 2.6 Teredo UDP port 220 The UDP port number at which Teredo Servers are waiting for packets. 221 The value of this port is 3544. 223 2.7 Teredo bubble 225 A Teredo bubble is a minimal IPv6 packet, made of an IPv6 header and 226 a null payload - the payload type is set to 59, No Next Header, as 227 per [RFC2460]. The Teredo clients and relays may send bubbles in 228 order to create a mapping in a NAT. 230 2.8 Teredo service port 232 The port through which the Teredo client sends Teredo packets. This 233 port is attached to one of the client's IPv4 addresses. The IPv4 234 address may or may not be globally routable, as the client may be 235 located behind one or more NAT. 237 Huitema [Page 5] 238 2.9 Teredo server address 240 The IPv4 address of the Teredo server selected by a particular user. 242 2.10 Teredo mapped address and Teredo mapped port 244 A global IPv4 address and a UDP port that results from the 245 translation of the IPv4 address and UDP port of a client's Teredo 246 service port by one or more NATs. The client learns these values 247 through the Teredo protocol described in this memo. 249 2.11 Teredo IPv6 client prefix 251 A global scope IPv6 prefix composed of the Teredo IPv6 service 252 prefix and the Teredo server address. 254 2.12 Teredo node identifier 256 A 64 bit identifier that contains the UDP port and IPv4 address at 257 which a client can be joined through the Teredo service, as well as 258 a flag indicating the type of NAT through which the client accesses 259 the IPv4 Internet. 261 2.13 Teredo IPv6 address 263 A Teredo IPv6 address obtained by combining a Teredo IPv6 client 264 prefix and a Teredo node identifier. 266 2.14 Teredo Refresh Interval 268 The interval during which a Teredo IPv6 Address is expected to 269 remain valid in the absence of "refresh" traffic. For a client 270 located behind a NAT, the interval depends on configuration 271 parameters of the local NAT, or the combination of NATs in the path 272 to the Teredo server. By default, clients assume an interval value 273 of 30 seconds; a longer value may be determined by local tests, as 274 described in section 5. 276 2.15 Teredo secondary port 278 A UDP port used to determine the appropriate value of the refresh 279 interval, but not used to carry any Teredo traffic. 281 2.16 Teredo IPv4 Discovery Address 283 An IPv4 multicast address used to discover other Teredo clients on 284 the same IPv4 subnet. The value of this address is X.X.X.X. 285 (TBD IANA; experiments use the value 224.0.0.252.) 287 3 Design goals, requirements, and model of operation 289 Huitema [Page 6] 290 The proposed solution transports IPv6 packets as the payload of UDP 291 packets. This is based on the observation that TCP and UDP are the 292 only protocols guaranteed to cross the majority of NAT devices. 293 Tunneling packets over TCP would be possible, but would result in a 294 poor quality of service; encapsulation over UDP is a better choice. 296 The design of our solution is based on a set of hypotheses and 297 observations on the behavior of NATs, our desire to provide an "IPv6 298 provider of last resort", and a list of operational requirements. It 299 results in a model of operation in which the Teredo service is 300 enabled by a set of servers and relays. 302 3.1 Hypotheses about NAT behavior 304 NAT devices typically incorporate some support for UDP, in order to 305 enable users in the natted domain to use UDP based applications. The 306 NAT will typically allocate a "mapping" when it sees an UDP packet 307 coming through for which there is not yet an existing mapping. The 308 handling of UDP "sessions" by NAT devices differs by two important 309 parameters, the type and the duration of the mappings. 311 The type of mappings is analyzed in [RFC3489], which distinguishes 312 between "Cone NAT", "restricted cone NAT", "port restricted cone 313 NAT" and "symmetric NAT". The Teredo solution ensures connectivity 314 for clients located behind cone NATs, retricted cone NATs or port- 315 restricted cone NATs. these three types NATs. 317 Clients located behind a symmetric NAT will only be able to use 318 Teredo if they can somehow program the NAT and reserve a Teredo 319 service port for each client, for example using the DMZ functions of 320 the NAT. This is obviously an onerous requirement, at odds with the 321 design goal of an automatic solution. However, measurement campaigns 322 and studies of documentations have shown that, at least in simple 323 "unmanaged" networks, symmetric NATs are a small minority; moreover, 324 it seems that new NAT models or firmware upgrades avoid the 325 "symmetric" design. 327 Regardless of their types, UDP mappings are not kept forever. The 328 typical algorithm is to remove the mapping if no traffic is observed 329 on the specified port for a "lifetime" period. The Teredo client 330 that wants to maintain a mapping open in the NAT will have to send 331 some "keep alive" traffic before the lifetime expires. For that, it 332 needs an estimate of the "lifetime" parameter used in the NAT. We 333 observed that the implementation of lifetime control can vary in 334 several ways. 336 Most NATs implement a "minimum lifetime" which is set as a parameter 337 of the implementation. Our observations of various boxes showed that 338 this parameter can vary between about 45 seconds and several 339 minutes. 341 In many NATs, mappings can be kept for a duration that exceeds this 343 Huitema [Page 7] 344 minimum, even in the absence of traffic. We suspect that many 345 implementation perform "garbage collection" of unused mappings on 346 special events, e.g. when the overall number of mappings exceeds 347 some limit. 349 In some cases, e.g. NATs that manage ISDN or dial-up connections, 350 the mappings will be released when the connection is released, i.e. 351 when no traffic is observed on the connection for a period of a few 352 minutes. 354 Any algorithm used to estimate the lifetime of mapping will have to 355 be robust against these variations. 357 3.2 IPv6 provider of last resort 359 Teredo is designed to provide an "IPv6 access of last resort" to 360 nodes that need IPv6 connectivity but cannot use any of the other 361 IPv6 transition schemes. This design objective has several 362 consequences on when to use Teredo, how to program clients, and what 363 to expect of servers. Another consequence is that we expect to see a 364 point in time at which the Teredo technology ceases to be used. 366 3.2.1 When to use Teredo? 368 Teredo is designed to robustly enable IPv6 traffic through NATs, and 369 the price of robustness is a reasonable amount of overhead, due to 370 UDP encapsulation and transmission of bubbles. Nodes that want to 371 connect to the IPv6 Internet SHOULD only use the Teredo service as a 372 "last resort" option: they SHOULD prefer using direct IPv6 373 connectivity if it is locally available, if it is provided by a 6to4 374 router co-located with the local NAT, or if it is provided by a 375 configured tunnel service; and they SHOULD prefer using the less 376 onerous "6to4" encapsulation if they can use a global IPv4 address. 378 3.2.2 Autonomous deployment 380 In an IPv6-enabled network, the IPv6 service is configured 381 automatically, by using mechanisms such as IPv6 Stateless Address 382 Autoconfiguration [RFC2462] and Neighbor Discovery [RFC2461]. A 383 design objective is to configure the Teredo service as automatically 384 as possible. In practice, it is however required that the client 385 learn the IPv4 address of a server that is willing to serve them; 386 some servers may also require some form of access control. 388 3.2.3 Minimal load on servers 390 During the peak of the transition, there will be a requirement to 391 deploy a large number of servers throughout the Internet. Minimizing 392 the load on the server is a good way to facilitate this deployment. 393 To achieve this goal, servers should be as stateless as possible, 394 and they should also not be required to carry any more traffic than 396 Huitema [Page 8] 397 necessary. To achieve this objective, we require only that servers 398 enable the packet exchange between clients, but we don't require 399 servers to carry the actual data packets: these packets will have to 400 be exchanged directly between the Teredo clients, or through a 401 destination-selected relay for exchanges between Teredo clients and 402 other IPv6 clients. 404 3.2.4 Automatic sunset 406 Teredo is meant as a short-term solution to the specific problem of 407 providing IPv6 service to nodes located behind a NAT. The problem is 408 expected to be resolved over time by transforming the "IPv4 NAT" 409 into an "IPv6 router". This can be done in one of two ways: 410 upgrading the NAT to provide 6to4 functions, or upgrading the 411 Internet connection used by the NAT to a native IPv6 service, and 412 then adding IPv6 router functionality in the NAT. In either case, 413 the former NAT can present itself as an IPv6 router to the systems 414 behind it. These systems will start receiving the "router 415 advertisements"; they will notice that they have IPv6 connectivity, 416 and will stop using Teredo. 418 3.3 Operational Requirements 420 3.3.1 Robustness requirement 422 The Teredo service is designed primarily for robustness: packets are 423 carried over UDP in order to cross as many NAT implementations as 424 possible. The servers are designed to be stateless, which means that 425 they can easily be replicated. We expect indeed to find many such 426 servers replicated at multiple Internet locations. 428 3.3.2 Minimal support cost 430 The service requires the support of servers and relays. In order to 431 facilitate the deployment of these servers, the Teredo procedures 432 are designed to minimize the fraction of traffic that has to be 433 routed through the servers. 435 Meeting this objective implies that the Teredo addresses will 436 incorporate the IPv4 address and UDP port through which a Teredo 437 client can be reached. This creates an implicit limit on the 438 stability of the Teredo addresses, which can only remain valid as 439 long as the underlying IPv4 address and UDP port remains valid. 441 3.3.3 Protection against denial of service attacks 443 The Teredo clients obtain mapped addresses and ports from the Teredo 444 servers. The service must be protected against denial of service 445 attacks in which a third party spoofs a Teredo server and sends 446 improper information to the client. 448 3.3.4 Protection against distributed denial of service attacks 450 Huitema [Page 9] 451 Teredo servers will act as a relay for IPv6 packets. Improperly 452 designed packet relays can be used by denial of service attackers to 453 hide their address, making the attack untraceable. The Teredo 454 service must include adequate protection against such misuse. 456 3.3.5 Compatibility with ingress filtering 458 Routers may perform ingress filtering by checking that the source 459 address of the packets received on a given interface is 460 "legitimate", i.e. belongs to network prefixes from which traffic is 461 expected at a network interface. Ingress filtering is a recommended 462 practice, as it thwarts the use of forged source IP addresses by 463 malfeasant hackers, notably to cover their tracks during denial of 464 service attacks. The Teredo specification must not force networks to 465 disable ingress filtering. 467 3.4 Model of operation 469 The operation of Teredo involves four types of nodes: Teredo 470 clients, Teredo servers, Teredo relays, and "plain" IPv6 nodes. 472 Teredo clients start operation by interacting with a Teredo server, 473 performing a "qualification procedure". During this procedure, the 474 client will discover whether it is behind a cone, restricted cone or 475 symmetric NAT. If the client is not located behind a symmetric NAT, 476 the procedure will be successful and the client will configure a 477 "Teredo address". 479 The Teredo address embeds the "mapped address and port" through 480 which the client can receive IPv4/UDP packets encapsulating IPv6 481 packets. If the client is not located behind a cone NAT, packet 482 transmission must be preceded by an exchange of "bubbles" that will 483 install a mapping in the NAT. This document specifies how the 484 bubbles can be exchanged between Teredo clients in order to enable 485 transmission along a direct path. 487 Teredo clients can exchange IPv6 packets with plain IPv6 nodes (e.g. 488 native nodes or 6to4 nodes) through Teredo relays. Teredo relays 489 advertise reachability of the Teredo prefix to a certain subset of 490 the IPv6 Internet: a relay set up by an ISP will typically serve 491 only the IPv6 customers of this ISP; a relay set-up for a site will 492 only serve the IPv6 hosts of this site. Dual-stack hosts may 493 implement a "local relay", allowing them to communicate directly 494 with Teredo hosts by sending IPv6 packets over UDP and IPv4. 496 In order to prevent spoofing, the Teredo clients perform a relay 497 discovery procedure by sending an ICMP echo request to the native 498 host, through the Teredo server. The payload of the echo request 499 contains a large random number. The echo reply is forwarded by the 500 relay closest to the native or 6to4 peer, enabling the Teredo client 501 to discover this relay. In order to prevent spoofing, the Teredo 502 client verifies that the payload of the echo reply contains the 503 proper random number. 505 The procedures are designed so that the Teredo server only 506 participates in the qualification procedure and in the exchange of 507 bubbles and ICMP echo requests. The Teredo server never carries 508 actual data traffic. There are two rationales for this design: 509 reduce the load on the server in order to enable scaling; and avoid 510 privacy issues that could occur if a Teredo server kept copies of 511 the client's data packets. 513 4 Teredo Addresses 515 The Teredo addresses are composed of 5 components: 517 +-------------+-------------+-------+------+-------------+ 518 | Prefix | Server IPv4 | Flags | Port | Client IPv4 | 519 +-------------+-------------+-------+------+-------------+ 521 - Prefix: the 32 bit Teredo service prefix. 522 - Server IPv4: the IPv4 address of a Teredo server. 523 - Flags: a set of 16 bits that document type of address and NAT. 524 - Port: the obfuscated "mapped UDP port" of the Teredo service at 525 the client 526 - Client IPv4: the obfuscated "mapped IPv4 address" of the client 528 In this format, both the "mapped UDP port" and "mapped IPv4 address" 529 of the client are obfuscated. Each bit in the address and port 530 number is reversed; this can be done by an exclusive OR of the 16- 531 bit port number with the hexadecimal value 0xFFFF, and an exclusive 532 OR of the 32-bit address with the hexadecimal value 0xFFFFFFFF. 534 The IPv6 addressing rules specify that "for all unicast addresses, 535 except those that start with binary value 000, Interface IDs are 536 required to be 64 bits long and to be constructed in Modified EUI-64 537 format." This dictates the encoding of the flags, 16 intermediate 538 bits which should correspond to valid values of the most significant 539 16 bits of a Modified EUI-64 ID: 541 0 0 0 1 542 |0 7 8 5 543 +----+----+----+----+ 544 |Czzz|zzUG|zzzz|zzzz| 545 +----+----+----+----+ 547 In this format: 549 - The bits "UG" should be set to the value "00", indicating a non- 550 global unicast identifier; 551 - The bit "C" (cone) should be set to 1 if the client believes it is 552 behind a cone NAT, to 0 otherwise; these values determine 553 different server behavior during the qualification procedure, as 554 specified in section 5.2.1, as well as different bubble processing 555 by clients and relays. 556 - The bits indicated with "z" must be set to sent as zero and 557 ignored on receipt. 559 There are thus two currently specified values of the Flags field: 560 "0x0000" (all null) if the cone bit is set to 0, and "0x8000" if the 561 cone bit is set to 1. (Further versions of this specification may 562 assign new values to the reserved bits.) 564 In some cases, Teredo nodes use link-local addresses. These 565 addresses contain a link local prefix (FE80::/64) and a 64 bit 566 identifier, constructed using the same format as presented above. A 567 difference between link-local addresses and global addresses is that 568 the identifiers used in global addresses MUST include a global scope 569 unicast IPv4 address, while the identifiers used in link-local 570 addresses MAY include a private IPv4 address. 572 5 Specification of clients, servers and relays 574 The Teredo service is realized by having clients interact with 575 Teredo servers through the Teredo service protocol. The clients will 576 also receive IPv6 packets through Teredo relays. 578 The Teredo server is designed to be stateless. It waits for Teredo 579 requests and for IPv6 packets on the Teredo UDP port; it processes 580 the requests by sending a response to the appropriate address and 581 port; it forwards Teredo IPv6 packets to the appropriate IPv4 582 address and UDP port. 584 The Teredo relay advertises reachability of the Teredo service 585 prefix over IPv6. The scope of advertisement may be the entire 586 Internet, or a smaller subset such as an ISP network or an IPv6 587 site; it may even be as small as a single host in the case of "local 588 relays". The relay forwards Teredo IPv6 packets to the appropriate 589 IPv4 address and UDP port. 591 Teredo clients, servers and relays must implement the sunset 592 procedure defined in section 5.5. 594 5.1 Message formats 596 5.1.1 Teredo IPv6 packet encapsulation 598 Teredo IPv6 packets are transmitted as UDP packets [RFC768] within 599 IPv4 [RFC791]. The source and destination IP addresses and UDP 600 ports take values that are specified in this section. Packets can 601 come in one of two formats, simple encapsulation and encapsulation 602 with origin indication. 604 When simple encapsulation is used, the packet will have a simple 605 format, in which the IPv6 packet is carried as the payload of a UDP 606 datagram: 608 +------+-----+-------------+ 609 | IPv4 | UDP | IPv6 packet | 610 +------+-----+-------------+ 612 When relaying packets received from third parties, the server may 613 insert an origin indication in the first bytes of the UDP payload: 615 +------+-----+-------------------+-------------+ 616 | IPv4 | UDP | Origin indication | IPv6 packet | 617 +------+-----+-------------------+-------------+ 619 The origin indication encapsulation is an 8-octet element, with the 620 following content: 622 +--------+--------+-----------------+ 623 | 0x00 | 0x00 | Origin port # | 624 +--------+--------+-----------------+ 625 | Origin IPv4 address | 626 +-----------------------------------+ 628 The first two octets of the origin indication are set to a null 629 value; this is used to discriminate between the simple 630 encapsulation, in which the first 4 bits of the packet contain the 631 indication of the IPv6 protocol, and the origin indication. 633 The following 16 bits contain the obfuscated value of the port 634 number from which the packet was received, in network byte order. 635 The next 32 bits contain the obfuscated IPv4 address from which the 636 packet was received, in network byte order. In this format, both the 637 original "IPv4 address" and "UDP port" of the client are obfuscated. 638 Each bit in the address and port number is reversed; this can be 639 done by an exclusive OR of the 16-bit port number with the 640 hexadecimal value 0xFFFF, and an exclusive OR of the 32-bit address 641 with the hexadecimal value 0xFFFFFFFF. 643 For example, if the original UDP port number was 337 (hexadecimal 644 0151) and original IPv4 address was 1.2.3.4 (hexadecimal: 01020304), 645 the origin indication would contain the value "0000FEAEFEFDFCFB". 647 When exchanging Router Solicitation and Router Advertisement 648 messages between a client and its server, the packets may include an 649 authentication parameter: 651 +------+-----+----------------+-------------+ 652 | IPv4 | UDP | Authentication | IPv6 packet | 653 +------+-----+----------------+-------------+ 655 The authentication encapsulation is a variable length-element, 656 containing a client identifier, an authentication value, a nonce 657 value, and a confirmation byte. 659 +--------+--------+--------+--------+ 660 | 0x00 | 0x01 | ID-len | AU-len | 661 +--------+--------+--------+--------+ 662 | Client identifier (ID-len | 663 +-----------------+-----------------+ 664 | octets) | Authentication | 665 +-----------------+--------+--------+ 666 | value (AU-len octets) | Nonce | 667 +--------------------------+--------+ 668 | value (8 octets | 669 +--------------------------+--------+ 670 | | Conf. | 671 +--------------------------+--------+ 673 The first octet of the authentication encapsulation is set to a null 674 value, and the second octet is set to the value 1; this enables 675 differentiation from IPv6 packets and from origin information 676 indication encapsulation. The third octet indicates the length in 677 bytes of the client identifier; the fourth octet indicates the 678 length in bytes of the authentication value. The computation of the 679 authentication value is specified in section 5.2.2. The 680 authentication value is followed by an 8-octet nonce, and by a 681 confirmation byte. 683 Both ID-len and AU-len can be set to null values if the server does 684 not require an explicit authentication of the client. 686 Authentication and origin indication encapsulations may sometimes be 687 combined, for example in the RA responses sent by the server. In 688 this case, the authentication encapsulation MUST be the first 689 element in the UDP payload: 691 +------+-----+----------------+--------+-------------+ 692 | IPv4 | UDP | Authentication | Origin | IPv6 packet | 693 +------+-----+----------------+--------+-------------+ 695 5.1.2 Maximum Transmission Unit 697 Since Teredo uses UDP as an underlying transport, a Teredo 698 Maximum Transmission Unit (MTU) could potentially be as large as the 699 payload of the largest valid UDP datagram (65507 bytes). However, 700 since Teredo packets can travel on unpredictable paths over the 701 Internet, it is best to contain this MTU to a small size, in order 702 to minimize the effect of IPv4 packet fragmentation and reassembly. 703 The default link MTU assumed by a host, and the link MTU supplied by 704 a Teredo server during router advertisement SHOULD normally be set 705 to the minimum IPv6 MTU size of 1280 bytes [RFC2460]. 707 Teredo implementations SHOULD NOT set the Don't Fragment (DF) bit of 708 the encapsulating IPv4 header. 710 5.2 Teredo Client specification 712 Before using the Teredo service, the client must be configured with: 714 - the IPv4 address of a server. 716 If secure discovery is required, the client must also be configured 717 with: 719 - a client identifier, 720 - a secret value, shared with the server, 721 - an authentication algorithm, shared with the server. 723 A Teredo client expects to exchange IPv6 packets through an UDP 724 port, the Teredo service port. The client will maintain the 725 following variables that reflect the state of the Teredo service: 727 - Teredo connectivity status, 728 - Mapped address and port number associated with the Teredo service 729 port, 730 - Teredo IPv6 prefix associated with the Teredo service port, 731 - Teredo IPv6 address or addresses derived from the prefix, 732 - Link local address, 733 - Date and time of the last interaction with the Teredo server, 734 - Teredo Refresh Interval, 735 - Randomized Refresh Interval, 736 - List of recent Teredo peers. 738 Before sending any packets, the client must perform the Teredo 739 qualification procedure, which determines the Teredo connectivity 740 status, the mapped address and port number, and the Teredo IPv6 741 prefix; it should then perform the cone NAT determination procedure, 742 which determines the cone NAT status and may alter the value of the 743 prefix. If the qualification is successful, the client may use the 744 Teredo service port to transmit and receive IPv6 packets, according 745 to the transmission and reception procedures. These procedures use 746 the "list of recent peers". For each peer, the list contains: 748 - The IPv6 address of the peer, 749 - The mapped IPv4 address and mapped UDP port of the peer, 750 - The status of the mapped address, i.e. trusted or not, 751 - The value of the last "nonce" sent to the peer, 752 - The date and time of the last reception from the peer, 753 - The date and time of the last transmission to the peer, 754 - The number of bubbles transmitted to the peer. 756 The list of peers is used to enable the transmission of IPv6 packets 757 by using a "direct path" for the IPv6 packets. The list of peers 758 could grow over time. Clients should implement a list management 759 strategy, for example deleting the least recently used entries. 760 Clients should make sure that the list has a sufficient size, to 761 avoid unnecessary exchanges of bubbles. 763 The client must regularly perform the maintenance procedure in order 764 to guarantee that the Teredo service port remains usable; the need 765 to use this procedure or not depends on the delay since the last 766 interaction with the Teredo server. The refresh procedure takes as a 767 parameter the "Teredo refresh interval". This parameter is initially 768 set to 30 seconds; it can be updated as a result of the optional 769 "interval determination procedure." The randomized refresh interval 770 is set to a value randomly chosen between 75% and 100% of the 771 refresh interval. 773 In order to avoid triangle routing for stations that are located 774 behind the same NAT, the Teredo clients MAY use the optional local 775 client discovery procedure defined in section 5.2.8. 777 5.2.1 Qualification procedure 779 The purpose of the qualification procedure is to establish the 780 status of the local IPv4 connection, and to determine the Teredo 781 IPv6 client prefix of the local Teredo interface. The procedure 782 starts when the service is in the "initial" state, and results in a 783 "qualified" state if successful, and in an "off-line" state if 784 unsuccessful. 786 /---------\ 787 | Initial | 788 \---------/ 789 | 790 +----+----------+ 791 | Set ConeBit=1 | 792 +----+----------+ 793 | 794 +<-------------------------------------------+ 795 | | 796 +----+----+ | 797 | Start |<------+ | 798 +----+----+ | +----------+----+ 799 | | | Set ConeBit=0 | 800 v | +----------+----+ 801 /---------\ Timer | N ^ 802 |Starting |-------+ attempts /----------------\Yes| 803 \---------/----------------->| ConeBit == 1 ? |---+ 804 | Response \----------------/ 805 | | No 806 V V 807 /---------------\ Yes /----------\ 808 | ConeBit == 1? |---------+ | Off line | 809 \---------------/ | \----------/ 810 No | v 811 | /----------\ 812 | | Cone NAT | 813 +-----+-----+ \----------/ 814 | New Server| 815 +-----+-----+ 816 | 817 +----+----+ 818 | Start |<------+ 819 +----+----+ | 820 | | 821 v | 822 /---------\ Timer | 823 |Starting |-------+ N attempts /----------\ 824 \---------/------------------->| Off line | 825 | Response \----------/ 826 | 827 V 828 /------------\ No /---------------\ 829 | Same port? |-------->| Symmetric NAT | 830 \------------/ \---------------/ 831 | Yes 832 V 833 /----------------------\ 834 | Restricted Cone NAT | 835 \----------------------/ 837 Initially, the Teredo connectivity status is set to "Initial". 839 When the interface is initialized, the system first performs the 840 "start action" by sending a Router Solicitation message, as defined 841 in [RFC2461]. The client picks a link-local address and uses it as 842 the IPv6 source of the message; the "cone" bit in the address is set 843 to 1 (see section 4 for the address format); the IPv6 destination of 844 the RS is the all-routers multicast address; the packet will be sent 845 over UDP from the service port to the Teredo server's IPv4 address 846 and Teredo UDP port. The connectivity status moves then to 847 "Starting". 849 In the starting state, the client waits for a router advertisement 850 from the Teredo server. If no response comes within a time-out T, 851 the client should repeat the start action, by resending the Router 852 Solicitation message. If no response has arrived after N 853 repetitions, the client concludes that it is not behind a cone NAT. 854 It sets the "cone" bit to 0, and repeats the procedure. If after N 855 other timer expirations and retransmissions there is still no 856 response, the client concludes that it cannot use UDP, and that the 857 Teredo service is not available; the status is set to "Off-line." In 858 accordance with [RFC2461], the default time-out value is set to T=4 859 seconds, and the maximum number of repetitions is set to N=3. 861 If a response arrives, the client checks that the response contains 862 an origin indication and a valid router advertisement as defined in 863 [RFC2461], that the IPv6 destination address is equal to the link- 864 local address used in the router solicitation, and that the router 865 advertisement contains exactly one advertised Prefix Information 866 option. This prefix should be a valid Teredo IPv6 server prefix: the 867 first 32 bits should contain the global Teredo IPv6 service prefix, 868 and the next 32 bits should contain the server's IPv4 address. If 869 this is the case, the client learns the Teredo mapped address and 870 Teredo mapped port from the origin indication. The IPv6 source 871 address of the Router Advertisement is a link-local server address 872 of the Teredo server. (Responses that are not valid advertisements 873 are simply discarded.) 875 If the client has received an RA with the "Cone" bit in the IPv6 876 destination address set to 1, it is behind a cone NAT and is fully 877 qualified. If the RA is received with the Cone bit set to 0, the 878 client does not know whether the local NAT is restricted or 879 symmetric. The client selects a secondary IPv4 server address, and 880 repeats the procedure, the cone bit remaining to the value zero. If 881 the client does not receive a response, it detects that the service 882 is not usable. If the client receives a response, it compares the 883 mapped address and mapped port in this second response to the first 884 received values. If the values are different, the client detects a 885 symmetric NAT: it cannot use the Teredo service. If the values are 886 the same, the client detects a port-restricted or restricted cone 887 NAT: the client is qualified to use the service. (Teredo operates 888 the same way for restricted and port-restricted NAT.) 890 If the client is qualified, it builds a Teredo IPv6 address using 891 the Teredo IPv6 server prefix learned from the RA and the obfuscated 892 values of the UDP port and IPv4 address learned from the origin 893 indication. The cone bit should be set to the value used to receive 894 the RA, i.e. 1 if the client is behind a cone NAT, 0 otherwise. The 895 client can start using the Teredo service. 897 5.2.2 Secure qualification 899 The client may be required to perform secured qualification. The 900 client will perform exactly the algorithm described in 5.2.1, but it 901 will incorporate an authentication encapsulation in the UDP packet 902 carrying the router solicitation message, and it will verify the 903 presence of a valid authentication parameter in the UDP message that 904 carries the router advertisement provided by the sender. 906 In these packets, the nonce value is chosen by the client, and is 907 repeated in the response from the server; the client identifier is a 908 value with which the client was configured. 910 A first level of protection is provided by just checking that the 911 value of the nonce in the response matches the value initially sent 912 by the client. If no other protection is used, the authentication 913 payload does not contain any identifier or authentication field; the 914 ID-len and AU-len fields are set to a null value. When stronger 915 protection is required, the authentication payload contains the 916 identifier and location fields, as explained in the following 917 paragraphs. 919 The confirmation byte is set to 0 by the client. A null value 920 returned by the server indicates that the client's key is still 921 valid; a non-null value indicates that the client should obtain a 922 new key. 924 The authentication value is computed according to an algorithm 925 agreed upon by client and server. To maximize interoperability, this 926 specification defines a default algorithm in which the 927 authentication value is computed according the HMAC specification 928 [RFC2104] using the following specifications: 930 - the hash function shall be the MD5 function [RFC1321]. 931 - the secret value shall be the shared secret with which the client 932 was configured 934 The clear text to be protected includes: 936 - the nonce value, 937 - the confirmation byte, 938 - the origin indication encapsulation, if it is present, 939 - the IPv6 packet. 941 If the HMAC verification fails, the packet is silently discarded. 943 5.2.3 Packet reception 945 The Teredo client receives packets over the Teredo interface. The 946 role of the packet reception procedure, besides receiving packets, 947 is to maintain the date and time of the last interaction with the 948 Teredo server, and the "list of recent peers." 950 When a UDP packet is received over the Teredo service port, the 951 Teredo client checks that it is encoded according to the packet 952 encoding rules defined in 5.1.1, and that it contains either a valid 953 IPv6 packet, or the combination of a valid origin indication 954 encapsulation and a valid IPv6 packet, possibly protected by a valid 955 authentication encapsulation. If this is not the case, the packet is 956 silently discarded. 958 An IPv6 packet is deemed valid if it conforms to [RFC2460]: the 959 protocol identifier should indicate an IPv6 packet and the payload 960 length should be consistent with the length of the UDP datagram in 961 which the packet is encapsulated. In addition, the client should 962 check that the IPv6 destination address correspond to its own Teredo 963 address. 965 Then, the Teredo client examines the IPv4 source address and UDP 966 port number from which the packet is received. If these values match 967 the IPv4 address of the server and the Teredo port, the client 968 updates the "date and time of the last interaction with the Teredo 969 server" to the current date and time; if an origin indication is 970 present, the client should perform the "direct IPv6 connectivity 971 test" described in section 5.2.9. 973 If the values are different, the client examines the IPv6 source 974 address of the packet: 976 1) If there is an entry for the source IPv6 address in the list of 977 peers whose status is trusted, the client compares the mapped IPv4 978 address and mapped port in the entry with the source IPv4 address 979 and source port of the packet. If the values match, the packet is 980 accepted; the date and time of the last reception from the peer is 981 updated. 983 2) If there is an entry for the source IPv6 address in the list of 984 peers whose status is not trusted, the client checks whether the 985 packet is an ICMPv6 echo reply. If this is the case, and if the 986 ICMPv6 data of the reply matches the "nonce" stored in the peer 987 entry, the packet should be accepted; the status of the entry should 988 be changed to "trusted", the mapped IPv4 and mapped port in the 989 entry should be set to the source IPv4 address and source port from 990 which the packet was received, and the date and time of the last 991 reception from the peer should be updated; any packet queued for 992 this IPv6 peer (as specified in 5.2.4) should be de-queued and 993 forwarded to the newly learned IPv4 address and UDP port. 995 3) If the source IPv6 address is a Teredo address, the client 996 compares the mapped IPv4 address and mapped port in the source 997 address with the source IPv4 address and source port of the packet. 998 If the values match, the client MUST create a peer entry for the 999 IPv6 source address in the list of peers; it should update the entry 1000 if one already existed; the mapped IPv4 address and mapped port in 1001 the entry should be set to the value from which the packet was 1002 received, and the status should be set to "trusted". If a new entry 1003 is created, the last transmission date is set to 30 seconds before 1004 the current date, and the number of bubbles to zero. If the packet 1005 is a bubble, it should be discarded after this processing; 1006 otherwise, the packet should be accepted. In all cases, the client 1007 must de-queue and forward any packet queued for that destination. 1009 4) If the IPv4 destination address through which the packet was 1010 received is the Teredo IPv4 Discovery Address, the source address is 1011 a valid Teredo address, and the destination address is the "all 1012 nodes on link" multicast address, the packet should be treated as a 1013 local discovery bubble. If no local entry already existed for the 1014 source address, a new one is created, but its status is set to "not 1015 trusted". The client SHOULD reply with a unicast Teredo bubble, sent 1016 to the source IPv4 address and source port of the local discovery 1017 bubble; the IPv6 source address of the bubble will be set to local 1018 Teredo IPv6 address; the IPv6 destination address of the bubble 1019 should be set to the IPv6 source address of the local discovery 1020 bubble. (Clients that do not implement the optional local discovery 1021 procedure will not process local discovery bubbles.) 1023 5) If the source IPv6 address is a Teredo address, and the mapped 1024 IPv4 address and mapped port in the source address do not match the 1025 source IPv4 address and source port of the packet, the client checks 1026 whether there is an existing "local" entry for that IPv6 address. If 1027 there is such an entry, and if the local IPv4 address and local port 1028 indicated in that entry match the source IPv4 address and source 1029 port of the packet, the client updates the "local" entry, whose 1030 status should be set to "trusted". If the packet is a bubble, it 1031 should be discarded after this processing; otherwise, the packet 1032 should be accepted. In all cases, the client must de-queue and 1033 forward any packet queued for that destination. 1035 6) In the other cases, the packet may be accepted, but the client 1036 should be conscious that the source address may be spoofed; before 1037 processing the packet, the client should perform the "direct IPv6 1038 connectivity test" described in section 5.2.9. 1040 Whatever the IPv4 source address and UDP source port, the client 1041 that receives an IPv6 packet MAY send a Teredo bubble towards that 1042 target, as specified in section 5.2.6. 1044 5.2.4 Packet transmission 1046 When a Teredo client has to transmit a packet over a Teredo 1047 interface, it examines the destination IPv6 address. The client 1048 checks first if there is an entry for this IPv6 address in the list 1049 of recent Teredo peers, and if the entry is still valid: an entry 1050 associated with a local peer is valid if the last reception date and 1051 time associated with that list entry is less that 30 seconds from 1052 the current time; an entry associated with a non-local peer is valid 1053 if the last reception date and time associated with that list entry 1054 is less that 30 seconds from the current time. (Local peer entries 1055 can only be present if the client uses the local discovery procedure 1056 discussed in section 5.2.8.) 1058 The client then performs the following: 1060 1) If there is an entry for that IPv6 address in the list of peers, 1061 and if the status of the entry is set to "trusted", the IPv6 packet 1062 should be sent over UDP to the IPv4 address and UDP port specified 1063 in the entry. The client updates the date of last transmission in 1064 the peer entry. 1066 2) If the destination is not a Teredo IPv6 address, the packet is 1067 queued, and the client performs the "direct IPv6 connectivity test" 1068 described in section 5.2.9. The packet will be de-queued and 1069 forwarded if this procedure completes successfully. If the direct 1070 IPv6 connectivity test fails to complete within a 2 second time-out, 1071 it should be repeated up to 3 times. 1073 3) If the destination is the Teredo IPv6 address of a local peer 1074 (i.e. a Teredo address from which a local discovery bubble has been 1075 received in the last 600 seconds), the packet is queued. The client 1076 sends a unicast Teredo bubble to the local IPv4 address and local 1077 port specified in the entry, and a local Teredo bubble to the Teredo 1078 IPv4 discovery address. 1080 4) If the destination is a Teredo IPv6 address in which the cone bit 1081 is set to 1, the packet is sent over UDP to the mapped IPv4 address 1082 and mapped UDP port extracted from that IPv6 address. 1084 5) If the destination is a Teredo IPv6 address in which the cone bit 1085 is set to 0, the packet is queued. If the client is not located 1086 behind a cone NAT, it sends a direct bubble to the Teredo 1087 destination, i.e. to the mapped IP address and mapped port of the 1088 destination. In all cases, the client sends an indirect bubble to 1089 the Teredo destination, sending it over UDP to the server address 1090 and to the Teredo port. The packet will be de-queued and forwarded 1091 when the client receives a bubble or another packet directly from 1092 this Teredo peer. If no bubble is received within a 2 second time- 1093 out, the bubble transmission should be repeated up to 3 times. 1095 In cases 4 and 5, before sending a packet over UDP, the client MUST 1096 check that the IPv4 destination address is in the format of a global 1097 unicast address; if this is not the case, the packet MUST be 1098 silently discarded. (Note that a packet can legitimately be sent to 1099 a non-global unicast address in case 1, as a result of the local 1100 discovery procedure.) 1102 5.2.5 Maintenance 1104 The Teredo client must ensure that the mappings that it uses remain 1105 valid. It does so by checking that packets are regularly received 1106 from the Teredo server. 1108 At regular intervals, the client MUST check the "date and time of 1109 the last interaction with the Teredo server", to ensure that at 1110 least one packet has been received in the last Randomized Teredo 1111 Refresh Interval. If this is not the case, the client SHOULD send a 1112 router solicitation message to the server, as specified in 5.2.1; 1113 the client should use the same value of the "cone" bit that resulted 1114 in the reception of an RA during the qualification procedure. 1116 When the router advertisement is received, the client SHOULD check 1117 its validity as specified in 5.2.1; invalid advertisements are 1118 silently discarded. If the advertisement is valid, the client MUST 1119 check that the mapped address and port correspond to the current 1120 Teredo address. If this is not the case, the mapping has changed; 1121 the client must mark the old address as invalid, and start using the 1122 new address. 1124 5.2.6 Sending Teredo Bubbles 1126 The Teredo client may have to send a bubble towards another Teredo 1127 client, either after a packet reception or after a transmission 1128 attempt, as explained in sections 5.2.3 and 5.2.4. There are two 1129 kinds of bubbles: direct bubbles, that are sent directly to the 1130 mapped IPv4 address and mapped UDP port of the peer, and indirect 1131 bubbles that are sent through the Teredo server of the peer. 1133 When a Teredo client attempts to send a direct bubble, it extracts 1134 the mapped IPv4 address and mapped UDP port from the Teredo IPv6 1135 address of the target. It then checks whether there is already an 1136 entry for this IPv6 address in the current list of peers. If there 1137 is no entry, the client MUST create a new list entry for the 1138 address, setting the last reception date and the last transmission 1139 date to 30 seconds before the current date, and the number of 1140 bubbles to zero. 1142 When a Teredo client attempts to send an indirect bubble, it 1143 extracts the Teredo server IPv4 address from the Teredo prefix of 1144 the IPv6 address of the target (different clients may be using 1145 different servers); the bubble will be sent to that IPv4 address and 1146 the Teredo UDP port. 1148 Bubbles may be lost in transit, and it is reasonable to enhance the 1149 reliability of the Teredo service by allowing multiple 1150 transmissions; however, bubbles will also be lost systematically in 1151 certain NAT configurations. In order to strike a balance between 1152 reliability and unnecessary retransmissions, we specify the 1153 following: 1155 - The client MUST NOT send a bubble if the last transmission date 1156 and time is less than 2 seconds before the current date and time; 1158 - The client MUST NOT send a bubble if it has already sent 4 bubbles 1159 to the peer in the last 300 seconds without receiving a direct 1160 response. 1162 In the other cases, the client MAY proceed with the transmission of 1163 the bubble. When transmitting the bubble, the client MUST update the 1164 last transmission date and time to that peer, and must also 1165 increment the number of transmitted bubbles. 1167 5.2.7 Optional Refresh Interval Determination Procedure 1169 In addition to the regular client resources described in the 1170 beginning of this section, the refresh interval determination 1171 procedure uses an additional UDP port, the Teredo secondary port, 1172 and the following variables: 1174 - Teredo secondary connectivity status, 1175 - Mapped address and port number of the Teredo secondary port, 1176 - Teredo secondary IPv6 prefix associated with the secondary port, 1177 - Teredo secondary IPv6 address derived from this prefix, 1178 - Date and time of the last interaction on the secondary port, 1179 - Maximum Teredo Refresh Interval. 1180 - Candidate Teredo Refresh Interval. 1182 The secondary connectivity status, mapped address and prefix are 1183 determined by running the qualification procedure on the secondary 1184 port. When the client uses the interval determination procedure, the 1185 qualification procedure MUST be run for the secondary port 1186 immediately after running it on the service port. If the secondary 1187 qualification fails, the interval determination procedure will not be 1188 used, and the interval value will remain to the default value, 30 1189 seconds. If the secondary qualification succeeds, the maximum refresh 1190 interval is set to 120 seconds, and the candidate Teredo refresh 1191 interval is set to 60 seconds, i.e. twice the Teredo refresh 1192 interval. The procedure is then performed at regular intervals, until 1193 it concludes: 1195 1) wait until the candidate refresh interval is elapsed after the 1196 last interaction on the secondary port; 1198 2) send a Teredo bubble to the Teredo secondary IPv6 address, through 1199 the service port. 1201 3) wait for reception of the bubble on the secondary port. If a timer 1202 of 2 seconds elapses without reception, repeat step 2 at most three 1203 times. If there is still no reception, the candidate has failed; if 1204 there is a reception, the candidate has succeeded. 1206 4) if the candidate has succeeded, set the Teredo refresh interval to 1207 the candidate value, and set a new candidate value to the minimum of 1208 twice the new refresh interval, or the average of the refresh 1209 interval and the maximum refresh interval. 1211 5) if the candidate has failed, set the maximum refresh interval to 1212 the candidate value. If the current refresh interval is larger than 1213 or equal to 75% of the maximum, the determination procedure has 1214 concluded; otherwise, set a new candidate value to the average of the 1215 refresh interval and the maximum refresh interval. 1217 6) if the procedure has not concluded, perform the maintenance 1218 procedure on the secondary port, which will reset the date and time 1219 of the last interaction on the secondary port, and may result in the 1220 allocation of a new Teredo secondary IPv6 address; this would not 1221 affect the values of the refresh interval, candidate interval or 1222 maximum refresh interval. 1224 The secondary port MUST NOT be used for any other purpose than the 1225 interval determination procedure. It should be closed when the 1226 procedure ends. 1228 5.2.8 Optional local client discovery procedure 1230 It is desirable to enable direct communication between Teredo 1231 clients that are located behind the same NAT, without forcing a 1232 systematic relay through a Teredo server. It is hard to design a 1233 general solution to this problem, but we can design a partial 1234 solution when the Teredo clients are connected through IPv4 to the 1235 same link. 1237 A Teredo client who wishes to enable local discovery SHOULD join the 1238 IPv4 multicast group identified by Teredo IPv4 Discovery Address. 1239 The client SHOULD wait for discovery bubbles to be received on the 1240 Teredo IPv4 Discovery Address. The client SHOULD send local 1241 discovery bubbles to the Teredo IPv4 Discovery Address at random 1242 intervals, uniformly distributed between 200 and 300 seconds. A 1243 local Teredo bubble has the following characteristics: 1245 - IPv4 source address: the IPv4 address of the sender 1247 - IPv4 destination address: the Teredo IPv4 Discovery Address 1249 - IPv4 ttl: 1 1251 - UDP source port: the Teredo service port of the sender 1252 - UDP destination port: the Teredo UDP port 1254 - UDP payload: a minimal IPv6 packet, as follows 1256 - IPv6 source: the global Teredo IPv6 address of the sender 1258 - IPv6 destination: the all-nodes on-link multicast address 1260 - IPv6 payload type: 59 (No Next Header, as per [RFC2460]) 1262 - IPv6 payload length: 0 1264 - IPv6 hop limit: 1 1266 The local discovery procedure carries a denial of service risk, as 1267 malevolent nodes could send fake bubbles to unsuspecting parties, 1268 and thus capture the traffic originating from these parties. The 1269 risk is mitigated by the filtering rules described in section 5.2.5, 1270 and also by "link only" multicast scope of the Teredo IPv4 Discovery 1271 Address, which implies that packets sent to this address will not be 1272 forwarded across routers. 1274 To benefit from the "link only multicast" protection, the clients 1275 should silently discard all local discovery bubbles that are 1276 received over a unicast address. To further mitigate the denial of 1277 service risk, the client MUST silently discard all local discovery 1278 bubbles whose IPv6 source address is not a well-formed Teredo IPv6 1279 address, or whose IPv4 source address does not belong to the local 1280 IPv4 subnet; the client MAY decide to silently discard all local 1281 discovery bubbles whose Teredo IPv6 address do not include the same 1282 mapped IPv4 address as its own. 1284 If the bubble is accepted, the client checks whether there is an 1285 entry in the list of recent peers that correspond to the mapped IPv4 1286 address and mapped UDP port associated with the source IPv6 address 1287 of the bubble. If there is such an entry, the client MUST update the 1288 local peer address and local peer port parameters to reflect the 1289 IPv4 source address and UDP source port of the bubble. If there is 1290 no entry, the client MUST create one, setting the local peer address 1291 and local peer port parameters to reflect the IPv4 source address 1292 and UDP source port of the bubble, the last reception date to the 1293 current date and time, the last transmission date to 30 seconds 1294 before the current date, and the number of bubbles to zero; the 1295 state of the entry is set to "not trusted". 1297 Upon reception of a discovery bubble, clients reply with a unicast 1298 bubble as specified in section 5.2.3. 1300 5.2.9 Direct IPv6 connectivity test 1302 The Teredo procedures are designed to enable direct connections 1303 between a Teredo host and a Teredo relay. Teredo hosts located 1304 behind a cone NAT will receive packets directly from relays; other 1305 Teredo hosts will learn the original addresses and UDP ports of 1306 third parties through the local Teredo server. In all of these 1307 cases, there is a risk that the IPv6 address of the source be 1308 spoofed by a malevolent party. Teredo hosts must make two decisions, 1309 whether to accept the packet for local processing, and whether to 1310 transmit further packets to the IPv6 address through the newly 1311 learned IPv4 address and UDP port. The basic rule is that the hosts 1312 should be generous in what they accept, and careful in what they 1313 send. Refusing to accept packets due to spoofing concerns would 1314 compromise connectivity, and should only be done when there is a 1315 near certainty that the source address is spoofed; on the other 1316 hand, sending packets to the wrong address should be avoided. 1318 When the client wants to send a packet to an IPv6 node on the IPv6 1319 Internet, it should check whether a valid peer entry already exists 1320 for the IPv6 address of the destination. If this is not the case, 1321 the client will pick a random number (a nonce) and format an ICMPv6 1322 Echo Request message whose source is the local Teredo address, whose 1323 destination is the address of the IPv6 node, and whose Data field is 1324 set to the nonce. The nonce value and the date at which the packet 1325 was sent will be documented in a provisional peer entry for the IPV6 1326 destination. The ICMPv6 packet will then be sent encapsulated in a 1327 UDP packet destined to the Teredo server IPv4 address, and to the 1328 Teredo port. The rules of section 5.2.3 specify how the reply to 1329 this packet will be processed. 1331 5.2.10 Working around symmetric NAT 1333 The client procedures are designed to enable IPv6 connectivity 1334 through the most common types of NAT, which are commonly called 1335 "Cone NAT" and "restricted cone NAT" [RFC3489]. Some NAT employ a 1336 different design; they are often called "symmetric NAT". The 1337 qualification algorithm in section 5.2.1 will not succeed when the 1338 local NAT is a symmetric NAT. 1340 In many cases, it is possible to work around the limitations of 1341 these NAT by explicitly reserving a UDP port for Teredo service on a 1342 client, using a function often called "DMZ" in the NAT's manual. 1343 This port will become the "service port" used by the Teredo hosts. 1344 The implementers of Teredo functions in hosts must make sure that 1345 the value of the service port can be explicitly provisioned, so that 1346 user can provision the same value in the host and in the NAT. 1348 The reservation procedure guarantees that the port mapping will 1349 remain the same for all destinations. After the explicit 1350 reservation, the qualification algorithm in section 5.2.1 will 1351 succeed, and the Teredo client will behave as if behind a "cone 1352 NAT". 1354 When different clients use Teredo behind a single symmetric NAT, 1355 each of these clients must reserve and use a different service port. 1357 5.3 Teredo Server specification 1359 The Teredo server is designed to be stateless. The Teredo server 1360 waits for incoming UDP packets at the Teredo Port, using the IPv4 1361 address that has been selected for the service. In addition, the 1362 server is able to receive and transmit some packets using a 1363 different IPv4 address and a different port number. 1365 The Teredo server acts as an IPv6 router. As such, it will receive 1366 Router Solicitation messages, to which it will respond with Router 1367 Advertisement messages as explained in section 5.3.2; it may also 1368 receive other packets, for example ICMPv6 messages and Teredo 1369 bubbles, which are processed according to the IPv6 specification. 1371 By default, the routing functions of the Teredo server are limited. 1372 Teredo servers are expected to relay Teredo bubbles and ICMPv6 1373 messages, but they are not expected to relay other types of IPv6 1374 packets. Operators may however decide to combine 1376 5.3.1 Processing of Teredo IPv6 packets 1378 Before processing the packet, the Teredo server MUST check the 1379 validity of the encapsulated IPv6 source address, the IPv4 source 1380 address and the UDP source port: 1382 1) If the UDP content is not a well formed Teredo IPv6 packet, as 1383 defined in section 5.1.1, the packet MUST be silently discarded. 1385 2) If the UDP packet is not a Teredo bubble or an ICMPv6 message, it 1386 SHOULD be discarded. (The packet may be processed if the Teredo 1387 server also operates as a Teredo relay, as explained in section 1388 5.4.) 1390 3) If the IPv4 source address is not in the format of a global 1391 unicast address, the packet MUST be silently discarded. 1393 4) If the IPv6 source address is an IPv6 link-local address, the 1394 IPv6 destination address is the link-local scope all routers 1395 multicast address (FF02::2), and the packet contains an ICMPv6 1396 Router Solicitation message, the packet MUST be accepted; it MUST 1397 be discarded if the server requires secure qualification and the 1398 authentication encapsulation is absent or verification fails. 1400 5) If the IPv6 source address is a Teredo IPv6 address, and if the 1401 IPv4 address and UDP port embedded in that address match the IPv4 1402 source address and UDP source port, the packet SHOULD be 1403 accepted. 1405 6) If the IPv6 source address is not a Teredo IPv6 address, and if 1406 the IPv6 destination address is a Teredo address allocated 1407 through this server, the packet SHOULD be accepted. 1409 7) In all other cases, the packet MUST be silently discarded. 1411 The Teredo server will then check the IPv6 destination address of 1412 the encapsulated IPv6 packet: 1414 If the IPv6 destination address is the link-local scope all routers 1415 multicast address (FF02::2), or the link-local address of the 1416 server, the Teredo server processes the packet; it may have to 1417 process Router Solicitation messages and ICMPv6 Echo Request 1418 messages. 1420 If the destination IPv6 address is not a global scope IPv6 address, 1421 the packet MUST NOT be forwarded. 1423 If the destination address is not a Teredo IPv6 address the packet 1424 should be relayed to the IPv6 Internet using regular IPv6 routing. 1426 If the IPv6 destination address is a valid Teredo IPv6 address as 1427 defined in 2.13, the Teredo Server MUST check that the IPv4 address 1428 derived from this IPv6 address is in the format of a global unicast 1429 address; if this is not the case, the packet MUST be silently 1430 discarded. 1432 If the address is valid, the Teredo server encapsulates the IPv6 1433 packet in a new UDP datagram, in which the following parameters are 1434 set: 1436 - The destination IPv4 address is derived from the IPv6 destination. 1438 - The source IPv4 address is the Teredo server IPv4 address. 1440 - The destination UDP port is derived from the IPv6 destination. 1442 - The source UDP port is set to the Teredo UDP Port. 1444 If the destination IPv6 address is a Teredo client whose address is 1445 serviced by this specific server, the server should insert an origin 1446 indication in the first bytes of the UDP payload, as specified in 1447 section 5.1.1. (To verify that the client is served by this server, 1448 the server compares bits 32-63 of the client's Teredo IPv6 address 1449 to the server's IPv4 address.) 1451 5.3.2 Processing of router solicitations 1453 When the Teredo server receives a Router Solicitation message (RS, 1454 [RFC2641]), it retains the IPv4 address and UDP port from which the 1455 solicitation was received; these become the Teredo mapped address 1456 and Teredo mapped port of the client. The router uses these values 1457 to compose the origin indication encapsulation that will be sent 1458 with the response to the solicitation. 1460 The Teredo server responds to the router solicitation by sending a 1461 Router Advertisement message [RFC2641]. The router advertisement 1462 MUST advertise the Teredo IPv6 prefix composed from the service 1463 prefix and the server's IPv4 address. The IPv6 source address should 1464 be set to a Teredo link-local server address associated to the local 1465 interface; this address is derived from the IPv4 address of the 1466 server and from the Teredo port, as specified in section 4; the C 1467 bit is set to 1. The IPv6 destination address is set to the IPv6 1468 source address of the RS. The Router Advertisement message must be 1469 sent over UDP to the Teredo mapped address and Teredo mapped port of 1470 the client; the IPv4 source address and UDP source port should be 1471 set to the server's IPv4 address and Teredo Port. If the cone bit of 1472 the client's IPv6 address is set to 1, the RA must be sent from a 1473 different IPv4 source address than the server address over which the 1474 RS was received; if the cone bit is set to zero, the response must 1475 be sent back from the same address. 1477 Before sending the packet, the Teredo server MUST check that the 1478 IPv4 destination address is in the format of a global unicast 1479 address; if this is not the case, the packet MUST be silently 1480 discarded. 1482 If secure qualification is required, the server must insert a valid 1483 authentication parameter in the UDP packet carrying the router 1484 advertisement. The client identifier and the nonce value used in the 1485 authentication parameter must be the same identifier as received in 1486 the router solicitation; the confirmation byte should be set to zero 1487 if the client identifier is still valid, and a non-null value 1488 otherwise; the authentication value should be computed using the 1489 secret that corresponds to the client identifier. 1491 5.4 Teredo Relay specification 1493 Teredo relays are IPv6 routers that advertise reachability of the 1494 Teredo service IPv6 prefix through the IPv6 routing protocols. (A 1495 minimal Teredo relay may serve just a local host, and would not 1496 advertise the prefix beyond this host.) Teredo relays will receive 1497 IPv6 packets bound to Teredo clients. Teredo relays should be able 1498 to receive packets sent over IPv4 and UDP by Teredo clients; they 1499 may apply filtering rules, e.g. only accept packets from Teredo 1500 clients if they have previously sent traffic to these Teredo 1501 clients. 1503 The receiving and sending rules used by Teredo relays are very 1504 similar to those of Teredo clients. Teredo relays must use a Teredo 1505 service port to transmit packets to Teredo clients; they must 1506 maintain a "list of peers", identical to the list of peers 1507 maintained by Teredo clients. 1509 5.4.1 Transmission by relays to Teredo clients 1510 When a Teredo relay has to transmit a packet to a Teredo client, it 1511 examines the destination IPv6 address. By definition, the Teredo 1512 relays will only send over UDP IPv6 packets whose IPv6 destination 1513 address is a valid Teredo IPv6 address. 1515 Before processing these packets, the Teredo Server MUST check that 1516 the IPv4 destination address embedded in the Teredo IPv6 address is 1517 in the format of a global unicast address; if this is not the case, 1518 the packet MUST be silently discarded. 1520 The relay then checks if there is an entry for this IPv6 address in 1521 the list of recent Teredo peers, and if the entry is still valid. 1522 The relay then performs the following: 1524 1) If there is an entry for that IPv6 address in the list of peers, 1525 and if the status of the entry is set to "trusted", the IPv6 packet 1526 should be sent over UDP to the mapped IPv4 address and mapped UDP 1527 port of the entry. The client updates the date of last transmission 1528 in the peer entry. 1530 2) If the destination is a Teredo IPv6 address in which the cone bit 1531 is set to 1, the packet is sent over UDP to the mapped IPv4 address 1532 and mapped UDP port extracted from that IPv6 address. 1534 3) If the destination is a Teredo IPv6 address in which the cone bit 1535 is set to 0, the packet is queued. The Teredo relay creates a bubble 1536 whose source address is set to a local IPv6 address, and whose 1537 destination address is set to the Teredo IPv6 address of the 1538 packet's destination. The bubble is sent to the non-null server 1539 address corresponding to the Teredo destination. The packet will be 1540 de-queued and forwarded when a bubble or another packet will be 1541 received from this IPv6 address; if no such packet is received 1542 before a time-out of 2 seconds, the Teredo relay may repeat the 1543 bubble, up to three times. 1545 In cases 2 and 3, the Teredo relay should create a peer entry for 1546 the IPv6 address; the entry status is marked as trusted in case 2 1547 (cone NAT), not trusted in case 3. In case 3, if the Teredo relay 1548 happens to be located behind a non-cone NAT, it should also send a 1549 bubble directly to the mapped IPv4 address and mapped port number of 1550 the Teredo destination; this will "open the path" for the return 1551 bubble from the Teredo client. 1553 5.4.2 Reception from Teredo clients 1555 The Teredo relay may receive packets from Teredo clients; the 1556 packets should normally only be sent by clients to which the relay 1557 previously transmitted packets, i.e. clients whose IPv6 address is 1558 present in the list of peers. Relays, like clients, use the packet 1559 reception procedure to maintain the date and time of the last 1560 interaction with the Teredo server, and the "list of recent peers." 1561 When a UDP packet is received over the Teredo service port, the 1562 Teredo relay checks that it contains a valid IPv6 packet as 1563 specified in [RFC2460]. If this is not the case, the packet is 1564 silently discarded. 1566 Then, the Teredo relay examines whether the IPv6 source address is a 1567 valid Teredo address, and if the mapped IPv4 address and mapped port 1568 match the IPv4 source address and port number from which the packet 1569 is received. If this is not the case, the packet is silently 1570 discarded. 1572 The Teredo relay then examines whether there is an entry for the 1573 IPv6 source address in the list of recent peers. If this is not the 1574 case, the packet may be silently discarded. If this is the case, the 1575 entry status is set to "trusted"; the relay updates the "date and 1576 time of the last interaction" to the current date and time. 1578 Finally, the relay examines the destination IPv6 address. If the 1579 destination belongs to a range of IPv6 addresses served by the 1580 relay, the packet SHOULD be accepted and forwarded to the 1581 destination. In the other cases, the packet SHOULD be silently 1582 discarded. 1584 5.4.3 Difference between Teredo Relays and Teredo Servers 1586 Because Teredo servers can relay Teredo packets over IPv6, all 1587 Teredo servers must be capable of behaving as Teredo relays. There 1588 is however no requirement that Teredo relays behave as Teredo 1589 servers. 1591 The dual-role of server and relays implies an additional complexity 1592 for the programming of servers: the processing of incoming packets 1593 should be a combination of the server processing rules defined in 1594 5.3.1, and the relay processing rules defined in 5.4.2. (Section 5.3 1595 only specifies the rules implemented by a pure server, not a 1596 combination relay+server.) 1598 5.5 Implementation of automatic sunset 1600 Teredo is designed as an interim transition mechanism, and it is 1601 important that it should not be used any longer than necessary. The 1602 "sunset" procedure will be implemented by Teredo clients, servers 1603 and relays, as specified in this section. 1605 The Teredo-capable nodes MUST NOT behave as Teredo clients if they 1606 already have IPv6 connectivity through any other means, such as 1607 native IPv6 connectivity; in particular, nodes that have a global 1608 IPv4 address SHOULD obtain connectivity through the 6to4 service 1609 rather than through the Teredo service. The classic reason why a 1610 node that does not need connectivity would still enable the Teredo 1611 service is to guarantee good performance when interacting with 1612 Teredo clients; however, a Teredo-capable node that has IPv4 1613 connectivity and that has obtained IPv6 connectivity outside the 1614 Teredo service MAY decide to behave as a Teredo relay, and still 1615 obtain good performance when interacting with Teredo clients. 1617 The Teredo servers are expected to participate in the sunset 1618 procedure by announcing a date at which they will stop providing the 1619 service. This date depends on the availability of alternative 1620 solutions to their clients, such as "dual-mode" gateways that behave 1621 simultaneously as IPv4 NATs and IPv6 routers. Most Teredo servers 1622 will not be expected to operate more than a few years, perhaps until 1623 at most 2006. 1625 Teredo relays are expected to have the same life span as Teredo 1626 servers. 1628 6 Use of Teredo to implement a tunnel service 1630 It may be desirable in some cases to deploy stateful tunnel servers 1631 instead of the stateless Teredo servers. Tunnel servers generally 1632 require more resources, but an advantage is that they can 1633 potentially provide the users with "permanent" IPv6 addresses. 1635 It is possible to design a tunnel server protocol that is compatible 1636 with Teredo, in the sense that the same client could be used either 1637 in the Teredo service or with a tunnel service. In fact, this can be 1638 done by configuring the client with: 1640 - The IPv4 address of a Teredo server that acts as a tunnel broker 1641 - A client identifier 1642 - A shared secret with that server. 1644 The Teredo client will use the secure qualification procedure, as 1645 specified in section 5.2.2. Instead of returning a Teredo prefix in 1646 the router advertisement, the server will return a globally routable 1647 IPv6 prefix; this prefix may be permanently assigned to the client, 1648 which would provide the client with a stable address. The server 1649 will have to keep state, i.e. memorize the association between the 1650 prefix assigned to the client and the mapped IPv4 address and mapped 1651 UDP port of the client. 1653 The Teredo server will advertise reachability of the client prefix 1654 to the IPv6 Internet. Any packet bound to that prefix will be 1655 transmitted to the mapped IPv4 address and mapped UDP port of the 1656 client. 1658 The Teredo client, when it receives the prefix, will notice that 1659 this prefix is a global IPv6 prefix, not in the form of a Teredo 1660 prefix. The client will at that point recognize that it should 1661 operate in tunnel mode. A client that operates in tunnel mode will 1662 execute a much simpler transmission procedure: it will forward any 1663 packet sent to the Teredo interface to the IPv4 address and Teredo 1664 UDP port of the server. 1666 The Teredo client will have to perform the maintenance procedure 1667 described in section 5.2.5. The server will receive the router 1668 solicitation, and may notice a possible change of mapped IPv4 1669 address and mapped UDP port that could result from the 1670 reconfiguration of the mappings inside the NAT. The server should 1671 continue advertising the same IPv6 prefix to the client, and should 1672 update the mapped IPv4 address and mapped UDP port associated to 1673 this prefix, if necessary. 1675 7 Security Considerations 1677 The main objective of Teredo is to provide nodes located behind a 1678 NAT with a globally routable IPv6 address. This enables such nodes 1679 to use IP security services such as IKE, AH or ESP. As such, we can 1680 argue that the service has a positive effect on network security. 1681 However, the security analysis must also envisage the negative 1682 effects of the Teredo services, which we can group in four 1683 categories: security risks of directly connecting a node to the IPv6 1684 Internet, spoofing of Teredo servers to enable a man-in-the-middle 1685 attack, potential attacks aimed at denying the Teredo service to a 1686 Teredo client, and denial of service attacks against non-Teredo 1687 participating nodes that would be enabled by the Teredo service. 1689 In the following, we review in detail these four types of issues, 1690 and we present mitigating strategies for each of them. 1692 7.1 Opening a hole in the NAT 1694 The very purpose of the Teredo service is to make a machine 1695 reachable through IPv6. By definition, the machine using the service 1696 will give up whatever "firewall" service was available in the NAT 1697 box. The services that listen to the Teredo IPv6 address will become 1698 potential target of attacks from the entire IPv6 Internet. This may 1699 sound scary, but there are three mitigating factors. 1701 The first mitigating factor is the possibility to restrict some 1702 services to only accept traffic from local neighbors, e.g. using 1703 link local addresses. Teredo does not support communication using 1704 link local addresses. This implies that link-local services will not 1705 be accessed through Teredo, and will be restricted to whatever other 1706 IPv6 connectivity may be available, e.g. direct traffic with 1707 neighbors on the local link, behind the NAT. 1709 The second mitigating factor is the possible use of a "local 1710 firewall" solution, i.e. a piece of software that performs locally 1711 the kind of inspection and filtering that is otherwise performed in 1712 a perimeter firewall. Using such software is recommended. 1714 The third mitigating factor, already noted, is the availability of 1715 end-to-end connectivity, which allows for deployment of IP security 1716 services such as IKE, AH or ESP. Using these services in conjunction 1717 with Teredo is a good policy, as it will protect the client from 1718 possible attacks in intermediate servers such as the NAT, the Teredo 1719 server, or the Teredo relay. (These services can however only be 1720 used if the parties in the communication can negotiate a key, which 1721 requires agreeing on some credentials; this is known to be a hard 1722 problem.) 1724 7.2 Using the Teredo service for a man-in-the-middle attack 1726 The goal of the Teredo service is to provide hosts located behind a 1727 NAT with a globally reachable IPv6 address. There is a possible 1728 class of attacks against this service in which an attacker somehow 1729 intercepts the router solicitation, responds with a spoofed router 1730 advertisement, and provides a Teredo client with an incorrect 1731 address. The attacker may have one of two objectives: it may try to 1732 deny service to the Teredo client by providing it with an address 1733 that is in fact unreachable, or it may try to insert itself as a 1734 relay for all client communications, effectively enabling a variety 1735 of "man-in-the-middle" attack. 1737 The simple nonce verification procedure described in section 5.2.2 1738 provides a first level of protection against attacks in which a 1739 third party tries to spoof the server. In practice, the nonce 1740 procedure can only be defeated if the attacker is "on path". 1742 If client and server share a secret, the secure qualification 1743 procedure described in section 5.2.2 provides further protection. To 1744 defeat this protection, the attacker could try to obtain a copy of 1745 the secret shared between client and server. The most likely way to 1746 obtain the shared secret is to listen to the traffic and mount an 1747 offline dictionary attack; to protect against this attack, the 1748 secret shared between client and server should contain sufficient 1749 entropy. (This probably requires some automated procedure for 1750 provisioning the shared secret.) 1752 If the shared secret contains sufficient entropy, the attacker would 1753 have to defeat the one way function used to compute the 1754 authentication value. This specification suggests a default 1755 algorithm combining HMAC and MD5. If the protection afforded by MD5 1756 was not deemed sufficient, clients and servers can be agree to use a 1757 different algorithm, e.g. SHA1. 1759 Another way to defeat the protection afforded by the signature 1760 procedure is to mount a complex attack, as follows: 1762 1) Client prepares router solicitation, including authentication 1763 encapsulation. 1765 2) Attacker intercepts the solicitation, and somehow manages to 1766 prevent it from reaching the server, for example by mounting a short 1767 duration DoS attack against the server. 1769 3) Attacker replaces the source IPv4 address and source UDP port of 1770 the request by one of its own addresses and port, and forwards the 1771 modified request to the server. 1773 4) Server dutifully notes the IPv4 address from which the packet is 1774 received, verifies that the Authentication encapsulation is correct, 1775 prepares a router advertisement, signs it, and sends it back to the 1776 incoming address, i.e. the attacker. 1778 5) Attacker receives the advertisement, takes note of the mapping, 1779 replaces the IPv4 address and UDP port by the original values in the 1780 intercepted message, and sends the response to the client. 1782 6) Client receives the advertisement, notes that the authentication 1783 header is present and is correct, and uses the proposed prefix and 1784 the mapped addresses in the origin indication encapsulation. 1786 The root cause of the problem is that the NAT is, in itself, a man- 1787 in-the-middle attack. The Authentication encapsulation covers the 1788 encapsulated IPv6 packet, but does not cover the encapsulating IPv4 1789 header and UDP header. It is very hard to devise an effective 1790 signature scheme, since the attacker does not do anything else than 1791 what the NAT legally does! 1793 There are however several mitigating factors that lead us to avoid 1794 worrying too much about this attack. In practice, the gain from the 1795 attack is to either deny service to the client, or obtain a "man-in- 1796 the-middle" position; however, in order to mount the attack, the 1797 attacker must be able to suppress traffic originating from the 1798 client, i.e. have denial of service capability; the attacker must 1799 also be able to observe the traffic exchanged between client and 1800 inject its own traffic in the mix, i.e. have man-in-the-middle 1801 capacity. In summary, the attack is very hard to mount, and the gain 1802 for the attacker is minimal. 1804 7.2.1 End-to-end security 1806 The most effective line of defense of a Teredo client is probably 1807 not to try to secure the Teredo service itself: even if the mapping 1808 can be securely obtained, the attacker would still be able to listen 1809 to the traffic and send spoofed packets. Rather, the Teredo client 1810 should realize that, because it is located behind a NAT, it is in a 1811 situation of vulnerability; it should systematically try to encrypt 1812 its IPv6 traffic, using IPSEC. Even if the IPv4 and UDP headers are 1813 vulnerable, the use of IPSEC will effectively prevent spoofing and 1814 listening of the IPv6 packets by third parties. By providing each 1815 client with a global IPv6 address, Teredo enables the use of IPSEC 1816 and ultimately enhances the security of these clients. 1818 7.3 Denial of the Teredo service 1820 Our analysis outlines five ways to attack the Teredo service. There 1821 are counter-measures for each of these attacks. 1823 7.3.1 Denial of service by a rogue relay 1825 An attack can be mounted on the IPv6 side of the service by setting 1826 up a rogue relay, and letting that relay advertise a route to the 1827 Teredo IPv6 prefix. This is an attack against IPv6 routing, which 1828 can also be mitigated by the same kind of procedures used to 1829 eliminate spurious route advertisements. Dual stack nodes that 1830 implement a "host local" Teredo relays are impervious to this 1831 attack. 1833 8.3.1 Denial of service by server spoofing 1835 In section 7.2, we discussed the use of spoofed router 1836 advertisements to insert an attacker in the middle of a Teredo 1837 conversation. The spoofed router advertisements can also be used to 1838 provision a client with an incorrect address, pointing to either a 1839 non-existing IPv4 address or to the IPv4 address of a third party. 1841 The Teredo client will detect the attack when it fails to receive 1842 traffic through the newly acquired IPv6 address. The attack can be 1843 mitigated by using the authentication encapsulation. 1845 7.3.2 Denial of service by exceeding the number of peers 1847 A Teredo client manages a cache of recently-used peers, which makes 1848 it stateful. It is possible to mount an attack against the client by 1849 provoking it to respond to packets that appear to come from a large 1850 number of Teredo peers, thus trashing the cache and effectively 1851 denying the use of direct communication between peers. The effect 1852 will only last as long as the attack is sustained. 1854 7.3.3 Attacks against the local discovery procedure 1856 There is a possible denial of service attack against the local peer 1857 discovery procedure, if attackers can manage to send spoofed local 1858 discovery bubbles to a Teredo client. The checks described in 1859 section 5.2.8 mitigate this attack. Clients who are more interested 1860 in security than in performance could decide to disable the local 1861 discovery procedure; however, if local discovery is disabled, 1862 traffic between local nodes will end up being relayed through a 1863 server external to the local network, which has questionable 1864 security implications. 1866 7.3.4 Attacking the Teredo servers and relays 1868 It is possible to mount a brute force denial of service attack 1869 against the Teredo servers by sending them a very large number of 1870 packets. This attack will have to be "brute force", since the 1871 servers are stateless, and can be designed to process all the 1872 packets that are sent on their access line. 1874 The brute force attack against the Teredo servers is mitigated if 1875 clients are ready to "failover" to another server. Bringing down the 1876 servers will however force the clients that change servers to 1877 renumber their Teredo address. 1879 It is also possible to mount a brute force attack against a Teredo 1880 relay. This attack is mitigated if the relay under attack stops 1881 announcing the reachability of the Teredo service prefix to the IPv6 1882 network: the traffic will be picked up by the next relay. 1884 An attack similar to 7.3.2 can be mounted against a relay. An IPv6 1885 host can send IPv6 packets to a large number of Teredo destinations, 1886 forcing the relay to establish state for each of these destinations. 1887 Teredo relays can obtain some protection by limiting the range of 1888 IPv6 clients that they serve, and by limiting the amount of state 1889 used for "new" peers. 1891 7.4 Denial of service against non-Teredo nodes 1893 There is a widely expressed concern that transition mechanisms such 1894 as Teredo can be used to mount denial of service attacks, by 1895 injecting traffic at locations where it is not expected. These 1896 attacks fall in three categories: using the Teredo servers as a 1897 reflector in a denial of service attack, using the Teredo server to 1898 carry a denial of service attack against IPv6 nodes, and using the 1899 Teredo relays to carry a denial of service attack against IPv4 1900 nodes. The analysis of these attacks follows. A common mitigating 1901 factor in all cases is the "regularity" of the Teredo traffic, which 1902 contains highly specific patterns such as the Teredo UDP port, or 1903 the Teredo IPv6 prefix. In case of attacks, these patterns can be 1904 used to quickly install filters and remove the offending traffic. 1906 7.4.1 Laundering DoS attacks from IPv4 to IPv4 1908 An attacker can use the Teredo servers as reflectors in a denial of 1909 service attack aimed at an IPv4 target. The attacker can do this in 1910 one of two ways. The first way is to construct a Router Solicitation 1911 message and post it to a Teredo server, using as IPv4 source address 1912 the spoofed address of the target; the Teredo server will then send 1913 a Router advertisement message to the target. The second way is to 1914 construct a Teredo IPv6 address using the Teredo prefix, the address 1915 of a selected server, the IPv4 of the target, and an arbitrary UDP 1916 port, and to then send packets bound to that address to the selected 1917 Teredo server. 1919 Reflector attacks are discussed in [REFLECT], which outlines various 1920 mitigating techniques against such attacks. One of these mitigations 1921 is to observe that 'the traffic generated by the reflectors [has] 1922 sufficient regularity and semantics that it can be filtered out near 1923 the victim without the filtering itself constituting a denial-of- 1924 service to the victim ("collateral damage").' The traffic reflected 1925 by the Teredo servers meets this condition: it is clearly 1926 recognizable, since it originates from the Teredo UDP port; it can 1927 be filtered out safely if the target itself is not a Teredo user. In 1928 addition, the packets relayed by servers will carry an Origin 1929 indication encapsulation, which will help determining the source of 1930 the attack. 1932 7.4.2 DOS attacks from IPv4 to IPv6 1934 An attacker may use the Teredo servers to launch a denial of service 1935 attack against an arbitrary IPv6 destination. The attacker will 1936 build an IPv6 packet bound for the target, and will send that packet 1937 to the IPv4 address and UDP port of a Teredo server, to be relayed 1938 from there to the target over IPv6. 1940 The address checks specified in section 5.3.1 provide some 1941 protection against this attack, as they ensure that the IPv6 source 1942 address will be consistent with the IPv4 source address and UDP 1943 source port used by the attacker: if the attacker cannot spoof the 1944 IPv4 source address, the target will be able to determine the origin 1945 of the attack. 1947 The address checks ensure that the IPv6 source address of packets 1948 forwarded by servers will start with the IPv6 Teredo prefix. This is 1949 a mitigating factor, as sites under attack could use this to filter 1950 out all packets sourced from that prefix during an attack. This will 1951 result in a partial loss of service, as the target will not be able 1952 to communicate with legitimate Teredo hosts that use the same 1953 prefix; however, the communication with other IPv6 hosts will remain 1954 unaffected, and the communication with Teredo hosts will be able to 1955 resume when the attack has ceased. 1957 7.4.3 DOS attacks from IPv6 to IPv4 1959 An attacker with IPv6 connectivity may use the Teredo relays to 1960 launch a denial of service attack against an arbitrary IPv4 1961 destination. The attacker will compose a Teredo IPv6 address using 1962 the Teredo prefix, a null server address, the IPv4 address of the 1963 target, an arbitrary UDP port, and an arbitrary node identifier. The 1964 attacker will send IPv6 packets to that address; the packets will be 1965 routed to the nearest Teredo relay, and forwarded from there to the 1966 target. 1968 The address checks specified in 5.4 are limited to verifying that 1969 packets are only relayed to a global IPv4 address. This rules out a 1970 class of attack in which the packets are bound to a broadcast or 1971 multicast address. It also rules out another class of attack in 1972 which the packets are bound for a private IPv4 address that would be 1973 reachable by the relay. 1975 The attack can be targeted at arbitrary UDP ports, such as for 1976 example the DNS port of a server. The UDP payload must be a well- 1977 formed IPv6 packet, and is thus unlikely to be accepted by any well- 1978 written UDP service; in most case, the only effect of the attack 1979 will be to overload the target with random traffic. 1981 A special case occurs if the attack is directed to an echo service. 1982 The service will echo the packets. Since the echo service sees the 1983 request coming from the IPv4 address of the relay, the echo replies 1984 will be sent back to the same relay. According to the rules 1985 specified in 5.4, these packets will be discarded by the Teredo 1986 relay. This is not a very efficient attack against the Teredo relays 1987 - establishing a legitimate session with an actual Teredo host would 1988 create more traffic. 1990 The IPv6 packets sent to the target contain the IPv6 address used by 1991 the attacker. If ingress filtering is used in the IPv6 network, this 1992 address will be hard to spoof. If ingress filtering is not used, the 1993 attacker can be traced if the IPv6 routers use a mechanism similar 1994 to ICMP Traceback. The ICMP messages will normally be collected by 1995 the same relays that forward the traffic from the attacker; the 1996 relays can use these messages to identify the source of an ongoing 1997 attack. The details of this solution should be specified by the 1998 ITRACE working group. 2000 8 IAB considerations 2002 The IAB has studied the problem of "Unilateral Self Address Fixing" 2003 (UNSAF), which is the general process by which a client attempts to 2004 determine its address in another realm on the other side of a NAT 2005 through a collaborative protocol reflection mechanism [RFC3424]. 2006 Teredo is an example of a protocol that performs this type of 2007 function. The IAB has mandated that any protocols developed for this 2008 purpose document a specific set of considerations. This section 2009 meets those requirements. 2011 8.1 Problem Definition 2013 From [RFC3424], any UNSAF proposal must provide a precise definition 2014 of a specific, limited-scope problem that is to be solved with the 2015 UNSAF proposal. A short term fix should not be generalized to solve 2016 other problems; this is why "short term fixes usually aren't". 2018 The specific problems being solved by Teredo is the provision of 2019 IPv6 connectivity for a host that cannot obtain IPv6 connectivity 2020 either natively or by other means, such as 6to4. 2022 8.2 Exit Strategy 2024 From [RFC3424], any UNSAF proposal must provide the description of 2025 an exit strategy/transition plan. The better short term fixes are 2026 the ones that will naturally see less and less use as the 2027 appropriate technology is deployed. 2029 Teredo comes with its own built in exit strategy: as soon as IPv6 2030 connectivity is obtained by other means, Teredo will cease to be 2031 used. In particular, we expect that the next generation of home 2032 routers will provide an IPv6 service in complement to the current 2033 IPv4 NAT service, e.g. by relaying connectivity obtained from the 2034 ISP, or by using a configured or automatic tunnel service. 2036 As long as Teredo is used, there will be a need to support Teredo 2037 relays so that the remaining Teredo hosts can communicate with 2038 native IPv6 hosts. As Teredo usage declines, the traffic load on the 2039 relays will decline. Over time, managers will observe a reduce 2040 traffic load on their relays and will turn them off, effectively 2041 increasing the pressure on the remaining Teredo hosts to upgrade to 2042 another form of connectivity. 2044 The exit strategy is facilitated by the nature of Teredo, which 2045 provides an IP level solution. IPv6 aware applications do not have 2046 to be updated to use or not use Teredo. The absence of impact on the 2047 applications makes it easier to migrate out of Teredo: network 2048 connectivity suffices. 2050 8.3 Brittleness Introduced by Teredo 2052 From [RFC3424], any UNSAF proposal must provide a discussion of 2053 specific issues that may render systems more "brittle". For 2054 example, approaches that involve using data at multiple network 2055 layers create more dependencies, increase debugging challenges, and 2056 make it harder to transition. 2058 Teredo introduces brittleness into the system in several ways: the 2059 discovery process assumes a certain classification of devices based 2060 on their treatment of UDP; the mappings need to be continuously 2061 refreshed; and addressing structure may cause some hosts located 2062 beyond a common NAT to be unreachable from each other. (There are 2063 many similarities between these points and those introduced by STUN 2064 [RFC3489].) 2066 Teredo assumes a certain classification of devices based on their 2067 treatment of UDP, e.g. cone, protected cone and symmetric. There 2068 could be devices that would not fit into one of these molds, and 2069 hence would be improperly classified by Teredo. 2071 The bindings allocated from the NAT need to be continuously 2072 refreshed. Since the timeouts for these bindings is very 2073 implementation specific, the refresh interval cannot easily be 2074 determined. When the binding is not being actively used to 2075 receive traffic, but to wait for an incoming message, the binding 2076 refresh will needlessly consume network bandwidth. 2078 The use of the Teredo server as an additional network element 2079 introduces another point of potential security attack. These 2080 attacks are largely prevented by the security measures provided by 2081 Teredo, but not entirely. 2083 The use of the Teredo server as an additional network element 2084 introduces another point of failure. If the client cannot locate a 2085 Teredo server, or if the server should be unavailable due to 2086 failure, the Teredo client will not be able to obtain IPv6 2087 connectivity. 2089 Teredo imposes some restrictions on the network topologies for 2090 proper operation. In particular, if the same NAT is on the path 2091 between two clients and the Teredo server, these clients will only 2092 be able to interoperate if they are connected to the same link, or 2093 if the common NAT is capable of "looping" packets sent by one client 2094 to another. 2096 8.4 Requirements for a Long Term Solution 2098 From [RFC3424], any UNSAF proposal must identify requirements for 2099 longer term, sound technical solutions -- contribute to the process 2100 of finding the right longer term solution. 2102 Our experience with Teredo has led to the following requirements for 2103 a long term solution to the NAT problem: the devices that implement 2104 the IPv4 NAT services should in the future also become IPv6 routers. 2106 9 IANA Considerations 2108 This memo documents a request to IANA to allocate a Teredo IPv6 2109 service prefix, and a Teredo IPv4 multicast address. 2111 10 Acknowledgements 2113 Many of the ideas in this memo are the result of discussions between 2114 the author and Microsoft colleagues, notably Brian Zill, John 2115 Miller, Mohit Talwar, Joseph Davies and Rick Rashid. Several 2116 encapsulation details are inspired from earlier work by Keith Moore. 2117 The example in section 5.1 and a number of security precautions were 2118 suggested by Pekka Savola. The local discovery procedure was 2119 suggested by Richard Draves and Dave Thaler. The document was 2120 reviewed by members of the NGTRANS and V6OPS working groups, 2121 including Brian Carpenter, Cyndi Jung, Keith Moore, Thomas Narten, 2122 Anssi Porttikivi, Pekka Savola, Eng Soo Guan, and Eiffel Wu. 2124 11 References 2126 Normative references 2128 [RFC768] J. Postel, "User Datagram Protocol", RFC 768, August 1980. 2130 [RFC791] J. Postel, "Internet Protocol", RFC 791, September 1981. 2132 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 2133 April 1992. 2135 [RFC1918] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, 2136 E. Lear, "Address Allocation for Private Internets", RFC 1918, 2137 February 1996. 2139 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 2140 Requirement Levels", RFC 2119, March 1997. 2142 [RFC2460] S. Deering, R. Hinden, "Internet Protocol, Version 6 2143 (IPv6) Specification", RFC 2460, December 1998. 2145 [RFC2461] T. Narten, E. Nordmark, W. Simpson, "Neighbor Discovery 2146 for IP Version 6 (IPv6)", RFC 2461, December 1998. 2148 [RFC2462] T. Narten, S. Thomson, "IPv6 Stateless Address 2149 Autoconfiguration", RFC 2462, December 1998. 2151 [RFC3056] B. Carpenter, K. Moore, "Connection of IPv6 Domains via 2152 IPv4 Clouds", RFC 3056, February 2001. 2154 [RFC3068] C. Huitema, "An Anycast Prefix for 6to4 Relay Routers", 2155 RFC 3068, June 2001. 2157 [RFC3424] Daigle, L., Editor, "IAB Considerations for Unilateral 2158 Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 2159 3424, November 2002. 2161 Informative references 2163 [RFC1750] D. Eastlake, S. Crocker, J. Schiller, "Randomness 2164 Recommendations for Security", RFC 1750, December 1994. 2166 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy. 2167 "STUN - Simple Traversal of User Datagram Protocol (UDP) Through 2168 Network Address Translators (NATs)", RFC 3489, March 2003. 2170 [SYNCHRO] S. Floyd, V. Jacobson, "The synchronization of periodic 2171 routing messages", ACM SIGCOMM'93 Symposium, September 1993. 2173 [REFLECT] V. Paxson, "An analysis of using reflectors for 2174 distributed denial of service attacks." Computer Communication 2175 Review, ACM SIGCOMM, Volume 31, Number 3, July 2001, pp 38-47. 2177 12 Authors' Addresses 2179 Christian Huitema 2180 Microsoft Corporation 2181 One Microsoft Way 2182 Redmond, WA 98052-6399 2183 Email: huitema@microsoft.com 2185 13 Intellectual Property Statement 2187 The IETF takes no position regarding the validity or scope of any 2188 Intellectual Property Rights or other rights that might be claimed 2189 to pertain to the implementation or use of the technology described 2190 in this document or the extent to which any license under such 2191 rights might or might not be available; nor does it represent that 2192 it has made any independent effort to identify any such rights. 2193 Information on the procedures with respect to rights in RFC 2194 documents can be found in BCP 78 and BCP 79. 2196 Copies of IPR disclosures made to the IETF Secretariat and any 2197 assurances of licenses to be made available, or the result of an 2198 attempt made to obtain a general license or permission for the use 2199 of such proprietary rights by implementers or users of this 2200 specification can be obtained from the IETF on-line IPR repository 2201 at http://www.ietf.org/ipr. 2203 The IETF invites any interested party to bring to its attention any 2204 copyrights, patents or patent applications, or other proprietary 2205 rights that may cover technology that may be required to implement 2206 this standard. Please address the information to the IETF at ietf- 2207 ipr@ietf.org. 2209 14 Copyright 2211 The following copyright notice is copied from [RFC3667], Section 2212 5.4. It describes the applicable copyright for this document. 2214 Copyright (C) The Internet Society (2004). This document is subject 2215 to the rights, licenses and restrictions contained in BCP 78, and 2216 except as set forth therein, the authors retain all their rights. 2218 This document and the information contained herein are provided on 2219 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2220 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 2221 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 2222 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2223 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR