idnits 2.17.1 draft-huitema-v6ops-teredo-05.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 3978, Section 5.5 on line 2530. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2500. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2507. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2513. ** 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. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** 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 34 instances of lines with control characters in the document. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances 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 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == 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 (April 5, 2005) is 6959 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 1000, but not defined == Missing Reference: 'RFC3566' is mentioned on line 1003, but not defined == Missing Reference: 'RFC3947' is mentioned on line 1821, but not defined == Unused Reference: 'RFC1321' is defined on line 2408, but no explicit reference was found in the text == Unused Reference: 'RFC3068' is defined on line 2430, but no explicit reference was found in the text == Unused Reference: 'RFC1750' is defined on line 2443, but no explicit reference was found in the text == Unused Reference: 'RFC3497' is defined on line 2465, but no explicit reference was found in the text == Unused Reference: 'SYNCHRO' is defined on line 2475, 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 -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180' -- Obsolete informational reference (is this intentional?): RFC 1750 (Obsoleted by RFC 4086) -- Obsolete informational reference (is this intentional?): RFC 2402 (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2406 (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 3330 (Obsoleted by RFC 5735) -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) -- Obsolete informational reference (is this intentional?): RFC 3667 (Obsoleted by RFC 3978) Summary: 12 errors (**), 0 flaws (~~), 14 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT C. Huitema 2 Microsoft 3 Expires October 5, 2005 April 5, 2005 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.6 Global Teredo IPv6 service prefix ............................. 5 53 2.7 Teredo UDP port ............................................... 5 54 2.8 Teredo bubble ................................................. 5 55 2.9 Teredo service port ........................................... 5 56 2.10 Teredo server address ........................................ 6 57 2.11 Teredo mapped address and Teredo mapped port ................. 6 58 2.12 Teredo IPv6 client prefix .................................... 6 59 2.13 Teredo node identifier ....................................... 6 60 2.14 Teredo IPv6 address .......................................... 6 61 2.15 Teredo Refresh Interval ...................................... 6 62 2.16 Teredo secondary port ........................................ 6 63 2.17 Teredo IPv4 Discovery Address ................................ 6 64 3 Design goals, requirements, and model of operation .............. 7 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? ......................................... 9 68 3.2.2 Autonomous deployment ....................................... 9 69 3.2.3 Minimal load on servers ..................................... 9 70 3.2.4 Automatic sunset ............................................ 9 71 3.3 Operational Requirements ...................................... 10 72 3.3.1 Robustness requirement ...................................... 10 73 3.3.2 Minimal support cost ........................................ 10 74 3.3.3 Protection against denial of service attacks ................ 10 75 3.3.4 Protection against distributed denial of service attacks .... 10 76 3.3.5 Compatibility with ingress filtering ........................ 10 77 3.4 Model of operation ............................................ 11 78 4 Teredo Addresses ................................................ 12 79 5 Specification of clients, servers and relays .................... 13 80 5.1 Message formats ............................................... 13 81 5.1.1 Teredo IPv6 packet encapsulation ............................ 13 82 5.1.2 Maximum Transmission Unit ................................... 15 83 5.2 Teredo Client specification ................................... 16 84 5.2.1 Qualification procedure ..................................... 17 85 5.2.2 Secure qualification ........................................ 20 86 5.2.3 Packet reception ............................................ 21 87 5.2.4 Packet transmission ......................................... 23 88 5.2.5 Maintenance ................................................. 24 89 5.2.6 Sending Teredo Bubbles ...................................... 25 90 5.2.7 Optional Refresh Interval Determination Procedure ........... 26 91 5.2.8 Optional local client discovery procedure ................... 27 92 5.2.9 Direct IPv6 connectivity test ............................... 28 93 5.2.10 Working around symmetric NAT ............................... 29 95 Huitema [Page 2] 96 5.3 Teredo Server specification ................................... 29 97 5.3.1 Processing of Teredo IPv6 packets ........................... 30 98 5.3.2 Processing of router solicitations .......................... 31 99 5.4 Teredo Relay specification .................................... 32 100 5.4.1 Transmission by relays to Teredo clients .................... 32 101 5.4.2 Reception from Teredo clients ............................... 34 102 5.4.3 Difference between Teredo Relays and Teredo Servers ......... 34 103 5.5 Implementation of automatic sunset ............................ 35 104 6 Further study, use of Teredo to implement a tunnel service ...... 35 105 7 Security Considerations ......................................... 36 106 7.1 Opening a hole in the NAT ..................................... 37 107 7.2 Using the Teredo service for a man-in-the-middle attack ....... 37 108 7.2.1 Attacker spoofing the Teredo Server ......................... 37 109 7.2.2 Attacker spoofing a Teredo relay ............................ 39 110 7.2.3 End-to-end security ......................................... 39 111 7.3 Denial of the Teredo service .................................. 40 112 7.3.1 Denial of service by a rogue relay .......................... 40 113 7.3.2 Denial of service by server spoofing ........................ 40 114 7.3.3 Denial of service by exceeding the number of peers .......... 40 115 7.3.4 Attacks against the local discovery procedure ............... 40 116 7.3.5 Attacking the Teredo servers and relays ..................... 41 117 7.4 Denial of service against non-Teredo nodes .................... 41 118 7.4.1 Laundering DoS attacks from IPv4 to IPv4 .................... 41 119 7.4.2 DOS attacks from IPv4 to IPv6 ............................... 42 120 7.4.3 DOS attacks from IPv6 to IPv4 ............................... 42 121 8 IAB considerations .............................................. 44 122 8.1 Problem Definition ............................................ 44 123 8.2 Exit Strategy ................................................. 44 124 8.3 Brittleness Introduced by Teredo .............................. 45 125 8.4 Requirements for a Long Term Solution ......................... 47 126 9 IANA Considerations ............................................. 47 127 10 Acknowledgements ............................................... 47 128 11 References ..................................................... 47 129 12 Authors' Addresses ............................................. 49 130 13 Intellectual Property Statement ................................ 49 131 14 Copyright ...................................................... 50 133 Huitema [Page 3] 134 1 Introduction 136 Classic tunneling methods envisaged for IPv6 transition operate by 137 sending IPv6 packets as payload of IPv4 packets; the 6to4 proposal 138 [RFC3056] proposes automatic discovery in this context. A problem 139 with these methods is that they don't work when the IPv6 candidate 140 node is isolated behind a Network Address Translator (NAT) device: 141 NATs are typically not programmed to allow the transmission of 142 arbitrary payload types; even when they are, the local address 143 cannot be used in a 6to4 scheme. 6to4 will work with a NAT if the 144 NAT and 6to4 router functions are in the same box; we want to cover 145 the relatively frequent case when the NAT cannot be readily upgraded 146 to provide a 6to4 router function. 148 A possible way to solve the problem is to rely on a set of "tunnel 149 brokers." There are however limits to any solution that is based on 150 such brokers: the quality of service may be limited, since the 151 traffic follows a "dog leg" route from the source to the broker and 152 then the destination; the broker has to provide sufficient 153 transmission capacity to relay all packets and thus suffers a high 154 cost. For these two reasons, it may be desirable to have solutions 155 that allow for "automatic tunneling", i.e. let the packets follow a 156 direct path to the destination. 158 The automatic tunneling requirement is indeed at odds with some of 159 the specificities of NATs. Establishing a direct path supposes that 160 the IPv6 candidate node can retrieve a "globally routable" address 161 that results from the translation of its local address by one or 162 more NATs; it also supposes that we can find a way to bypass the 163 various "per destination protections" that many NATs implement. In 164 this memo, we will explain how IPv6 candidates located behind NATs 165 use "Teredo servers" to learn their "global address" and to obtain 166 connectivity, exchange packets with native IPv6 hosts through 167 "Teredo relays", and how clients, servers and relays can be 168 organized in Teredo networks. 170 The specification is organized as follows. Section 2 contains the 171 definition of the terms used in the memo. Section 3 presents the 172 hypotheses on NAT behavior used in the design, as well as the 173 operational requirements that the design should meet. Section 4 174 presents the IPv6 address format used by Teredo. Section 5 contains 175 the format of the messages and the specification of the protocol. 176 Section 6 presents guidelines for further work on configured tunnels 177 that would be complementary to the current approach. Section 7 178 contains a security discussion, section 8 a discussion of the so 179 called "UNSAF" issues, and section 9 contains IANA considerations. 181 2 Definitions 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in [RFC2119]. 187 Huitema [Page 4] 188 This specification uses the following definitions: 190 2.1 Teredo service 192 The transmission of IPv6 packets over UDP, as defined in this memo. 194 2.2 Teredo Client 196 A node that has some access to the IPv4 Internet and wants to gain 197 access to the IPv6 Internet. 199 2.3 Teredo Server 201 A node that has access to the IPv4 Internet through a globally 202 routable address, and is used as a helper to provide IPv6 203 connectivity to Teredo clients. 205 2.4 Teredo Relay 207 An IPv6 router that can receive traffic destined to Teredo clients 208 and forward it using the Teredo service. 210 2.5 Teredo IPv6 service prefix 212 An IPv6 addressing prefix which is used to construct the IPv6 213 address of Teredo clients. 215 2.6 Global Teredo IPv6 service prefix 217 An IPv6 addressing prefix whose value is XXXX:XXXX:/32. 218 (TBD IANA; experiments use the value 3FFE:831F::/32, taken from a 219 range of experimental IPv6 prefixes assigned to Microsoft.) 221 2.7 Teredo UDP port 223 The UDP port number at which Teredo Servers are waiting for packets. 224 The value of this port is 3544. 226 2.8 Teredo bubble 228 A Teredo bubble is a minimal IPv6 packet, made of an IPv6 header and 229 a null payload - the payload type is set to 59, No Next Header, as 230 per [RFC2460]. The Teredo clients and relays may send bubbles in 231 order to create a mapping in a NAT. 233 2.9 Teredo service port 235 The port from which the Teredo client sends Teredo packets. This 236 port is attached to one of the client's IPv4 addresses. The IPv4 237 address may or may not be globally routable, as the client may be 238 located behind one or more NAT. 240 Huitema [Page 5] 241 2.10 Teredo server address 243 The IPv4 address of the Teredo server selected by a particular 244 client. 246 2.11 Teredo mapped address and Teredo mapped port 248 A global IPv4 address and a UDP port that results from the 249 translation of the IPv4 address and UDP port of a client's Teredo 250 service port by one or more NATs. The client learns these values 251 through the Teredo protocol described in this memo. 253 2.12 Teredo IPv6 client prefix 255 A global scope IPv6 prefix composed of the Teredo IPv6 service 256 prefix and the Teredo server address. 258 2.13 Teredo node identifier 260 A 64 bit identifier that contains the UDP port and IPv4 address at 261 which a client can be reached through the Teredo service, as well 262 as a flag indicating the type of NAT through which the client 263 accesses the IPv4 Internet. 265 2.14 Teredo IPv6 address 267 A Teredo IPv6 address obtained by combining a Teredo IPv6 client 268 prefix and a Teredo node identifier. 270 2.15 Teredo Refresh Interval 272 The interval during which a Teredo IPv6 Address is expected to 273 remain valid in the absence of "refresh" traffic. For a client 274 located behind a NAT, the interval depends on configuration 275 parameters of the local NAT, or the combination of NATs in the path 276 to the Teredo server. By default, clients assume an interval value 277 of 30 seconds; a longer value may be determined by local tests, as 278 described in section 5. 280 2.16 Teredo secondary port 282 A UDP port used to send or receive packets in order to determine the 283 appropriate value of the refresh interval, but not used to carry any 284 Teredo traffic. 286 2.17 Teredo IPv4 Discovery Address 288 An IPv4 multicast address used to discover other Teredo clients on 289 the same IPv4 subnet. The value of this address is X.X.X.X. 290 (TBD IANA; experiments use the value 224.0.0.252.) 292 Huitema [Page 6] 293 3 Design goals, requirements, and model of operation 295 The proposed solution transports IPv6 packets as the payload of UDP 296 packets. This is based on the observation that TCP and UDP are the 297 only protocols guaranteed to cross the majority of NAT devices. 298 Tunneling packets over TCP would be possible, but would result in a 299 poor quality of service; encapsulation over UDP is a better choice. 301 The design of our solution is based on a set of hypotheses and 302 observations on the behavior of NATs, our desire to provide an "IPv6 303 provider of last resort", and a list of operational requirements. It 304 results in a model of operation in which the Teredo service is 305 enabled by a set of servers and relays. 307 3.1 Hypotheses about NAT behavior 309 NAT devices typically incorporate some support for UDP, in order to 310 enable users in the natted domain to use UDP based applications. The 311 NAT will typically allocate a "mapping" when it sees a UDP packet 312 coming through for which there is not yet an existing mapping. The 313 handling of UDP "sessions" by NAT devices differs by two important 314 parameters, the type and the duration of the mappings. 316 The type of mappings is analyzed in [RFC3489], which distinguishes 317 between "Cone NAT", "restricted cone NAT", "port restricted cone 318 NAT" and "symmetric NAT". The Teredo solution ensures connectivity 319 for clients located behind cone NATs, restricted cone NATs or port- 320 restricted cone NATs. 322 Transmission of regular IPv6 packets only takes places after an 323 exchange of "bubbles" between the parties. This exchange would often 324 fail for clients behind symmetric NAT, because their peer cannot 325 predict the UDP port number that the NAT expect. 326 Clients located behind a symmetric NAT will only be able to use 327 Teredo if they can somehow program the NAT and reserve a Teredo 328 service port for each client, for example using the DMZ functions of 329 the NAT. This is obviously an onerous requirement, at odds with the 330 design goal of an automatic solution. However, measurement campaigns 331 and studies of documentations have shown that, at least in simple 332 "unmanaged" networks, symmetric NATs are a small minority; moreover, 333 it seems that new NAT models or firmware upgrades avoid the 334 "symmetric" design. 336 Investigations on the performance of [RFC3489] have shown the 337 relative frequency of a particular NAT design, which we might call 338 "port conserving". In this design, the NAT tries to keep the same 339 port number inside and outside, unless the "outside" port number is 340 already in use for another mapping with the same host. Port 341 conserving NAT appear as "cone" or "restricted cone NAT" most of the 342 time, but they will behave as "symmetric NAT" when multiple internal 343 hosts use the same port number to communicate to the same server. 345 Huitema [Page 7] 346 The Teredo design minimizes the risk of encountering the "symmetric" 347 behavior by asking multiple hosts located behind the same NAT to use 348 different Teredo service ports. 350 Other investigation in the behavior of NAT also outlined the 351 "probabilistic rewrite" behavior. Some brands of NAT will examine 352 all packets for "embedded addresses", IP addresses and port numbers 353 present in application payloads. They will systematically replace 32 354 bits value that match a local address by the corresponding mapped 355 address. The Teredo specification includes an "obfuscation" 356 procedure in order to avoid this behavior. 358 Regardless of their types, UDP mappings are not kept forever. The 359 typical algorithm is to remove the mapping if no traffic is observed 360 on the specified port for a "lifetime" period. The Teredo client 361 that wants to maintain a mapping open in the NAT will have to send 362 some "keep alive" traffic before the lifetime expires. For that, it 363 needs an estimate of the "lifetime" parameter used in the NAT. We 364 observed that the implementation of lifetime control can vary in 365 several ways. 367 Most NATs implement a "minimum lifetime" which is set as a parameter 368 of the implementation. Our observations of various boxes showed that 369 this parameter can vary between about 45 seconds and several 370 minutes. 372 In many NATs, mappings can be kept for a duration that exceeds this 373 minimum, even in the absence of traffic. We suspect that many 374 implementation perform "garbage collection" of unused mappings on 375 special events, e.g. when the overall number of mappings exceeds 376 some limit. 378 In some cases, e.g. NATs that manage ISDN or dial-up connections, 379 the mappings will be released when the connection is released, i.e. 380 when no traffic is observed on the connection for a period of a few 381 minutes. 383 Any algorithm used to estimate the lifetime of mapping will have to 384 be robust against these variations. 386 In some cases, clients are located behind multiple NAT. The Teredo 387 procedures will ensure communications between clients between 388 multiple NATs and clients "on the other side" of these NAT. They 389 will also ensure communication when clients are located in a single 390 subnet behind the same NAT. 392 The procedures do not make any hypothesis about the type of IPv4 393 address used behind a NAT, and in particular do not assume that 394 these are private addresses defined in [RFC1918]. 396 3.2 IPv6 provider of last resort 398 Huitema [Page 8] 399 Teredo is designed to provide an "IPv6 access of last resort" to 400 nodes that need IPv6 connectivity but cannot use any of the other 401 IPv6 transition schemes. This design objective has several 402 consequences on when to use Teredo, how to program clients, and what 403 to expect of servers. Another consequence is that we expect to see a 404 point in time at which the Teredo technology ceases to be used. 406 3.2.1 When to use Teredo? 408 Teredo is designed to robustly enable IPv6 traffic through NATs, and 409 the price of robustness is a reasonable amount of overhead, due to 410 UDP encapsulation and transmission of bubbles. Nodes that want to 411 connect to the IPv6 Internet SHOULD only use the Teredo service as a 412 "last resort" option: they SHOULD prefer using direct IPv6 413 connectivity if it is locally available, if it is provided by a 6to4 414 router co-located with the local NAT, or if it is provided by a 415 configured tunnel service; and they SHOULD prefer using the less 416 onerous "6to4" encapsulation if they can use a global IPv4 address. 418 3.2.2 Autonomous deployment 420 In an IPv6-enabled network, the IPv6 service is configured 421 automatically, by using mechanisms such as IPv6 Stateless Address 422 Autoconfiguration [RFC2462] and Neighbor Discovery [RFC2461]. A 423 design objective is to configure the Teredo service as automatically 424 as possible. In practice, it is however required that the client 425 learn the IPv4 address of a server that is willing to serve them; 426 some servers may also require some form of access control. 428 3.2.3 Minimal load on servers 430 During the peak of the transition, there will be a requirement to 431 deploy Teredo servers supporting a large number of Teredo clients. 432 Minimizing the load on the server is a good way to facilitate this 433 deployment. To achieve this goal, servers should be as stateless as 434 possible, and they should also not be required to carry any more 435 traffic than necessary. To achieve this objective, we require only 436 that servers enable the packet exchange between clients, but we 437 don't require servers to carry the actual data packets: these 438 packets will have to be exchanged directly between the Teredo 439 clients, or through a destination-selected relay for exchanges 440 between Teredo clients and other IPv6 clients. 442 3.2.4 Automatic sunset 444 Teredo is meant as a short-term solution to the specific problem of 445 providing IPv6 service to nodes located behind a NAT. The problem is 446 expected to be resolved over time by transforming the "IPv4 NAT" 447 into an "IPv6 router". This can be done in one of two ways: 448 upgrading the NAT to provide 6to4 functions, or upgrading the 449 Internet connection used by the NAT to a native IPv6 service, and 450 then adding IPv6 router functionality in the NAT. In either case, 452 Huitema [Page 9] 453 the former NAT can present itself as an IPv6 router to the systems 454 behind it. These systems will start receiving the "router 455 advertisements"; they will notice that they have IPv6 connectivity, 456 and will stop using Teredo. 458 3.3 Operational Requirements 460 3.3.1 Robustness requirement 462 The Teredo service is designed primarily for robustness: packets are 463 carried over UDP in order to cross as many NAT implementations as 464 possible. The servers are designed to be stateless, which means that 465 they can easily be replicated. We expect indeed to find many such 466 servers replicated at multiple Internet locations. 468 3.3.2 Minimal support cost 470 The service requires the support of Teredo servers and Teredo 471 relays. In order to facilitate the deployment of these servers and 472 relays, the Teredo procedures are designed to minimize the amount of 473 coordination required between servers and relays. 475 Meeting this objective implies that the Teredo addresses will 476 incorporate the IPv4 address and UDP port through which a Teredo 477 client can be reached. This creates an implicit limit on the 478 stability of the Teredo addresses, which can only remain valid as 479 long as the underlying IPv4 address and UDP port remains valid. 481 3.3.3 Protection against denial of service attacks 483 The Teredo clients obtain mapped addresses and ports from the Teredo 484 servers. The service must be protected against denial of service 485 attacks in which a third party spoofs a Teredo server and sends 486 improper information to the client. 488 3.3.4 Protection against distributed denial of service attacks 490 Teredo relays will act as a relay for IPv6 packets. Improperly 491 designed packet relays can be used by denial of service attackers to 492 hide their address, making the attack untraceable. The Teredo 493 service must include adequate protection against such misuse. 495 3.3.5 Compatibility with ingress filtering 497 Routers may perform ingress filtering by checking that the source 498 address of the packets received on a given interface is 499 "legitimate", i.e. belongs to network prefixes from which traffic is 500 expected at a network interface. Ingress filtering is a recommended 501 practice, as it thwarts the use of forged source IP addresses by 502 malfeasant hackers, notably to cover their tracks during denial of 503 service attacks. The Teredo specification must not force networks to 504 disable ingress filtering. 506 3.4 Model of operation 508 The operation of Teredo involves four types of nodes: Teredo 509 clients, Teredo servers, Teredo relays, and "plain" IPv6 nodes. 511 Teredo clients start operation by interacting with a Teredo server, 512 performing a "qualification procedure". During this procedure, the 513 client will discover whether it is behind a cone, restricted cone or 514 symmetric NAT. If the client is not located behind a symmetric NAT, 515 the procedure will be successful and the client will configure a 516 "Teredo address". 518 The Teredo IPv6 address embeds the "mapped address and port" through 519 which the client can receive IPv4/UDP packets encapsulating IPv6 520 packets. If the client is not located behind a cone NAT, 521 transmission of regular IPv6 packets must be preceded by an exchange 522 of "bubbles" that will install a mapping in the NAT. This document 523 specifies how the bubbles can be exchanged between Teredo clients in 524 order to enable transmission along a direct path. 526 Teredo clients can exchange IPv6 packets with plain IPv6 nodes (e.g. 527 native nodes or 6to4 nodes) through Teredo relays. Teredo relays 528 advertise reachability of the Teredo prefix to a certain subset of 529 the IPv6 Internet: a relay set up by an ISP will typically serve 530 only the IPv6 customers of this ISP; a relay set-up for a site will 531 only serve the IPv6 hosts of this site. Dual-stack hosts may 532 implement a "local relay", allowing them to communicate directly 533 with Teredo hosts by sending IPv6 packets over UDP and IPv4 without 534 having to advertise a Teredo IPv6 address. 536 Teredo clients have to discover the relay that is closest to each 537 native IPv6 or 6to4 peer. They have to perform this discovery for 538 each native IPv6 or 6to4 peer with which they communicate. In order 539 to prevent spoofing, the Teredo clients perform a relay discovery 540 procedure by sending an ICMP echo request to the native host. This 541 message is a regularly formatted IPv6 ICMP packet, which is 542 encapsulated in UDP and sent by te client to its Teredo server; the 543 server decapsulates the IPv6 message and forwards it to the intended 544 IPv6 destination. The payload of the echo request contains a large 545 random number. The echo reply is sent by the peer to the IPv6 546 address of the client, and is forwarded through standard IPv6 547 routing mechanisms. It will naturally reach the Teredo relay closest 548 to the native or 6to4 peer, and will be forwarded by this relay 549 using the Teredo mechanisms. The Teredo client will discover the 550 IPv4 address and UDP port used by the relay to send the echo reply, 551 and will send further IPv6 packets to the peer by encapsulating them 552 in UDP packets sent to this IPv4 address and port. In order to 553 prevent spoofing, the Teredo client verifies that the payload of the 554 echo reply contains the proper random number. 556 The procedures are designed so that the Teredo server only 557 participates in the qualification procedure and in the exchange of 558 bubbles and ICMP echo requests. The Teredo server never carries 559 actual data traffic. There are two rationales for this design: 560 reduce the load on the server in order to enable scaling; and avoid 561 privacy issues that could occur if a Teredo server kept copies of 562 the client's data packets. 564 4 Teredo Addresses 566 The Teredo addresses are composed of 5 components: 568 +-------------+-------------+-------+------+-------------+ 569 | Prefix | Server IPv4 | Flags | Port | Client IPv4 | 570 +-------------+-------------+-------+------+-------------+ 572 - Prefix: the 32 bit Teredo service prefix. 573 - Server IPv4: the IPv4 address of a Teredo server. 574 - Flags: a set of 16 bits that document type of address and NAT. 575 - Port: the obfuscated "mapped UDP port" of the Teredo service at 576 the client 577 - Client IPv4: the obfuscated "mapped IPv4 address" of the client 579 In this format, both the "mapped UDP port" and "mapped IPv4 address" 580 of the client are obfuscated. Each bit in the address and port 581 number is reversed; this can be done by an exclusive OR of the 16- 582 bit port number with the hexadecimal value 0xFFFF, and an exclusive 583 OR of the 32-bit address with the hexadecimal value 0xFFFFFFFF. 585 The IPv6 addressing rules specify that "for all unicast addresses, 586 except those that start with binary value 000, Interface IDs are 587 required to be 64 bits long and to be constructed in Modified EUI-64 588 format." This dictates the encoding of the flags, 16 intermediate 589 bits which should correspond to valid values of the most significant 590 16 bits of a Modified EUI-64 ID: 592 0 0 0 1 593 |0 7 8 5 594 +----+----+----+----+ 595 |Czzz|zzUG|zzzz|zzzz| 596 +----+----+----+----+ 598 In this format: 600 - The bits "UG" should be set to the value "00", indicating a non- 601 global unicast identifier; 602 - The bit "C" (cone) should be set to 1 if the client believes it is 603 behind a cone NAT, to 0 otherwise; these values determine 604 different server behavior during the qualification procedure, as 605 specified in section 5.2.1, as well as different bubble processing 606 by clients and relays. 607 - The bits indicated with "z" must be set to sent as zero and 608 ignored on receipt. 610 There are thus two currently specified values of the Flags field: 611 "0x0000" (all null) if the cone bit is set to 0, and "0x8000" if the 612 cone bit is set to 1. (Further versions of this specification may 613 assign new values to the reserved bits.) 615 In some cases, Teredo nodes use link-local addresses. These 616 addresses contain a link local prefix (FE80::/64) and a 64 bit 617 identifier, constructed using the same format as presented above. A 618 difference between link-local addresses and global addresses is that 619 the identifiers used in global addresses MUST include a global scope 620 unicast IPv4 address, while the identifiers used in link-local 621 addresses MAY include a private IPv4 address. 623 5 Specification of clients, servers and relays 625 The Teredo service is realized by having clients interact with 626 Teredo servers through the Teredo service protocol. The clients will 627 also receive IPv6 packets through Teredo relays. The client behavior 628 is specified in section 5.2. 630 The Teredo server is designed to be stateless. It waits for Teredo 631 requests and for IPv6 packets on the Teredo UDP port; it processes 632 the requests by sending a response to the appropriate address and 633 port; it forwards some Teredo IPv6 packets to the appropriate IPv4 634 address and UDP port, or to native IPv6 peers of Teredo clients. The 635 precise behavior of the server is specified in section 5.3. 637 The Teredo relay advertises reachability of the Teredo service 638 prefix over IPv6. The scope of advertisement may be the entire 639 Internet, or a smaller subset such as an ISP network or an IPv6 640 site; it may even be as small as a single host in the case of "local 641 relays". The relay forwards Teredo IPv6 packets to the appropriate 642 IPv4 address and UDP port. The relay behavior is specified in 643 section 5.3. 645 Teredo clients, servers and relays must implement the sunset 646 procedure defined in section 5.5. 648 5.1 Message formats 650 5.1.1 Teredo IPv6 packet encapsulation 652 Teredo IPv6 packets are transmitted as UDP packets [RFC768] within 653 IPv4 [RFC791]. The source and destination IP addresses and UDP 654 ports take values that are specified in this section. Packets can 655 come in one of two formats, simple encapsulation and encapsulation 656 with origin indication. 658 When simple encapsulation is used, the packet will have a simple 659 format, in which the IPv6 packet is carried as the payload of a UDP 660 datagram: 662 +------+-----+-------------+ 663 | IPv4 | UDP | IPv6 packet | 664 +------+-----+-------------+ 666 When relaying some packets received from third parties, the server 667 may insert an origin indication in the first bytes of the UDP 668 payload: 670 +------+-----+-------------------+-------------+ 671 | IPv4 | UDP | Origin indication | IPv6 packet | 672 +------+-----+-------------------+-------------+ 674 The origin indication encapsulation is an 8-octet element, with the 675 following content: 677 +--------+--------+-----------------+ 678 | 0x00 | 0x00 | Origin port # | 679 +--------+--------+-----------------+ 680 | Origin IPv4 address | 681 +-----------------------------------+ 683 The first two octets of the origin indication are set to a null 684 value; this is used to discriminate between the simple 685 encapsulation, in which the first 4 bits of the packet contain the 686 indication of the IPv6 protocol, and the origin indication. 688 The following 16 bits contain the obfuscated value of the port 689 number from which the packet was received, in network byte order. 690 The next 32 bits contain the obfuscated IPv4 address from which the 691 packet was received, in network byte order. In this format, both the 692 original "IPv4 address" and "UDP port" of the client are obfuscated. 693 Each bit in the address and port number is reversed; this can be 694 done by an exclusive OR of the 16-bit port number with the 695 hexadecimal value 0xFFFF, and an exclusive OR of the 32-bit address 696 with the hexadecimal value 0xFFFFFFFF. 698 For example, if the original UDP port number was 337 (hexadecimal 699 0151) and original IPv4 address was 1.2.3.4 (hexadecimal: 01020304), 700 the origin indication would contain the value "0000FEAEFEFDFCFB". 702 When exchanging Router Solicitation and Router Advertisement 703 messages between a client and its server, the packets may include an 704 authentication parameter: 706 +------+-----+----------------+-------------+ 707 | IPv4 | UDP | Authentication | IPv6 packet | 708 +------+-----+----------------+-------------+ 709 The authentication encapsulation is a variable length-element, 710 containing a client identifier, an authentication value, a nonce 711 value, and a confirmation byte. 713 +--------+--------+--------+--------+ 714 | 0x00 | 0x01 | ID-len | AU-len | 715 +--------+--------+--------+--------+ 716 | Client identifier (ID-len | 717 +-----------------+-----------------+ 718 | octets) | Authentication | 719 +-----------------+--------+--------+ 720 | value (AU-len octets) | Nonce | 721 +--------------------------+--------+ 722 | value (8 octets) | 723 +--------------------------+--------+ 724 | | Conf. | 725 +--------------------------+--------+ 727 The first octet of the authentication encapsulation is set to a null 728 value, and the second octet is set to the value 1; this enables 729 differentiation from IPv6 packets and from origin information 730 indication encapsulation. The third octet indicates the length in 731 bytes of the client identifier; the fourth octet indicates the 732 length in bytes of the authentication value. The computation of the 733 authentication value is specified in section 5.2.2. The 734 authentication value is followed by an 8-octet nonce, and by a 735 confirmation byte. 737 Both ID-len and AU-len can be set to null values if the server does 738 not require an explicit authentication of the client. 740 Authentication and origin indication encapsulations may sometimes be 741 combined, for example in the RA responses sent by the server. In 742 this case, the authentication encapsulation MUST be the first 743 element in the UDP payload: 745 +------+-----+----------------+--------+-------------+ 746 | IPv4 | UDP | Authentication | Origin | IPv6 packet | 747 +------+-----+----------------+--------+-------------+ 749 5.1.2 Maximum Transmission Unit 751 Since Teredo uses UDP as an underlying transport, a Teredo 752 Maximum Transmission Unit (MTU) could potentially be as large as the 753 payload of the largest valid UDP datagram (65507 bytes). However, 754 since Teredo packets can travel on unpredictable paths over the 755 Internet, it is best to contain this MTU to a small size, in order 756 to minimize the effect of IPv4 packet fragmentation and reassembly. 757 The default link MTU assumed by a host, and the link MTU supplied by 758 a Teredo server during router advertisement SHOULD normally be set 759 to the minimum IPv6 MTU size of 1280 bytes [RFC2460]. 761 Teredo implementations SHOULD NOT set the Don't Fragment (DF) bit of 762 the encapsulating IPv4 header. 764 5.2 Teredo Client specification 766 Before using the Teredo service, the client must be configured with: 768 - the IPv4 address of a server. 769 - a secondary IPv4 address of that server. 771 If secure discovery is required, the client must also be configured 772 with: 774 - a client identifier, 775 - a secret value, shared with the server, 776 - an authentication algorithm, shared with the server. 778 A Teredo client expects to exchange IPv6 packets through a UDP port, 779 the Teredo service port. To avoid problems when operating behind a 780 "port conserving" NAT, different clients operating behind the same 781 NAT should use different service port numbers. This can be achieved 782 through explicit configuration or, in the absence of configuration, 783 by picking the service port number at random. 785 The client will maintain the following variables that reflect the 786 state of the Teredo service: 788 - Teredo connectivity status, 789 - Mapped address and port number associated with the Teredo service 790 port, 791 - Teredo IPv6 prefix associated with the Teredo service port, 792 - Teredo IPv6 address or addresses derived from the prefix, 793 - Link local address, 794 - Date and time of the last interaction with the Teredo server, 795 - Teredo Refresh Interval, 796 - Randomized Refresh Interval, 797 - List of recent Teredo peers. 799 Before sending any packets, the client must perform the Teredo 800 qualification procedure, which determines the Teredo connectivity 801 status, the mapped address and port number, and the Teredo IPv6 802 prefix; it should then perform the cone NAT determination procedure, 803 which determines the cone NAT status and may alter the value of the 804 prefix. If the qualification is successful, the client may use the 805 Teredo service port to transmit and receive IPv6 packets, according 806 to the transmission and reception procedures. These procedures use 807 the "list of recent peers". For each peer, the list contains: 809 - The IPv6 address of the peer, 810 - The mapped IPv4 address and mapped UDP port of the peer, 811 - The status of the mapped address, i.e. trusted or not, 812 - The value of the last "nonce" sent to the peer, 813 - The date and time of the last reception from the peer, 814 - The date and time of the last transmission to the peer, 815 - The number of bubbles transmitted to the peer. 817 The list of peers is used to enable the transmission of IPv6 packets 818 by using a "direct path" for the IPv6 packets. The list of peers 819 could grow over time. Clients should implement a list management 820 strategy, for example deleting the least recently used entries. 821 Clients should make sure that the list has a sufficient size, to 822 avoid unnecessary exchanges of bubbles. 824 The client must regularly perform the maintenance procedure in order 825 to guarantee that the Teredo service port remains usable; the need 826 to use this procedure or not depends on the delay since the last 827 interaction with the Teredo server. The refresh procedure takes as a 828 parameter the "Teredo refresh interval". This parameter is initially 829 set to 30 seconds; it can be updated as a result of the optional 830 "interval determination procedure." The randomized refresh interval 831 is set to a value randomly chosen between 75% and 100% of the 832 refresh interval. 834 In order to avoid triangle routing for stations that are located 835 behind the same NAT, the Teredo clients MAY use the optional local 836 client discovery procedure defined in section 5.2.8. Using this 837 procedure will also enhance connectivity when the NAT cannot do 838 "hairpin" routing, i.e. cannot redirect a packet sent from one 839 internal host to the mapped address and port of another internal 840 host. 842 5.2.1 Qualification procedure 844 The purpose of the qualification procedure is to establish the 845 status of the local IPv4 connection, and to determine the Teredo 846 IPv6 client prefix of the local Teredo interface. The procedure 847 starts when the service is in the "initial" state, and results in a 848 "qualified" state if successful, and in an "off-line" state if 849 unsuccessful. 851 /---------\ 852 | Initial | 853 \---------/ 854 | 855 +----+----------+ 856 | Set ConeBit=1 | 857 +----+----------+ 858 | 859 +<-------------------------------------------+ 860 | | 861 +----+----+ | 862 | Start |<------+ | 863 +----+----+ | +----------+----+ 864 | | | Set ConeBit=0 | 865 v | +----------+----+ 866 /---------\ Timer | N ^ 867 |Starting |-------+ attempts /----------------\Yes| 868 \---------/----------------->| ConeBit == 1 ? |---+ 869 | Response \----------------/ 870 | | No 871 V V 872 /---------------\ Yes /----------\ 873 | ConeBit == 1? |-----+ | Off line | 874 \---------------/ | \----------/ 875 No | v 876 | /----------\ 877 | | Cone NAT | 878 +-----+-----+ \----------/ 879 | New Server| 880 +-----+-----+ 881 | 882 +----+----+ 883 | Start |<------+ 884 +----+----+ | 885 | | 886 v | 887 /---------\ Timer | 888 |Starting |-------+ N attempts /----------\ 889 \---------/------------------->| Off line | 890 | Response \----------/ 891 | 892 V 893 /------------\ No /---------------\ 894 | Same port? |-------->| Symmetric NAT | 895 \------------/ \---------------/ 896 | Yes 897 V 898 /----------------------\ 899 | Restricted Cone NAT | 900 \----------------------/ 902 Initially, the Teredo connectivity status is set to "Initial". 904 When the interface is initialized, the system first performs the 905 "start action" by sending a Router Solicitation message, as defined 906 in [RFC2461]. The client picks a link-local address and uses it as 907 the IPv6 source of the message; the "cone" bit in the address is set 908 to 1 (see section 4 for the address format); the IPv6 destination of 909 the RS is the all-routers multicast address; the packet will be sent 910 over UDP from the service port to the Teredo server's IPv4 address 911 and Teredo UDP port. The connectivity status moves then to 912 "Starting". 914 In the starting state, the client waits for a router advertisement 915 from the Teredo server. If no response comes within a time-out T, 916 the client should repeat the start action, by resending the Router 917 Solicitation message. If no response has arrived after N 918 repetitions, the client concludes that it is not behind a cone NAT. 919 It sets the "cone" bit to 0, and repeats the procedure. If after N 920 other timer expirations and retransmissions there is still no 921 response, the client concludes that it cannot use UDP, and that the 922 Teredo service is not available; the status is set to "Off-line." In 923 accordance with [RFC2461], the default time-out value is set to T=4 924 seconds, and the maximum number of repetitions is set to N=3. 926 If a response arrives, the client checks that the response contains 927 an origin indication and a valid router advertisement as defined in 928 [RFC2461], that the IPv6 destination address is equal to the link- 929 local address used in the router solicitation, and that the router 930 advertisement contains exactly one advertised Prefix Information 931 option. This prefix should be a valid Teredo IPv6 server prefix: the 932 first 32 bits should contain the global Teredo IPv6 service prefix, 933 and the next 32 bits should contain the server's IPv4 address. If 934 this is the case, the client learns the Teredo mapped address and 935 Teredo mapped port from the origin indication. The IPv6 source 936 address of the Router Advertisement is a link-local server address 937 of the Teredo server. (Responses that are not valid advertisements 938 are simply discarded.) 940 If the client has received an RA with the "Cone" bit in the IPv6 941 destination address set to 1, it is behind a cone NAT and is fully 942 qualified. If the RA is received with the Cone bit set to 0, the 943 client does not know whether the local NAT is restricted or 944 symmetric. The client selects the secondary IPv4 server address, and 945 repeats the procedure, the cone bit remaining to the value zero. If 946 the client does not receive a response, it detects that the service 947 is not usable. If the client receives a response, it compares the 948 mapped address and mapped port in this second response to the first 949 received values. If the values are different, the client detects a 950 symmetric NAT: it cannot use the Teredo service. If the values are 951 the same, the client detects a port-restricted or restricted cone 952 NAT: the client is qualified to use the service. (Teredo operates 953 the same way for restricted and port-restricted NAT.) 955 If the client is qualified, it builds a Teredo IPv6 address using 956 the Teredo IPv6 server prefix learned from the RA and the obfuscated 957 values of the UDP port and IPv4 address learned from the origin 958 indication. The cone bit should be set to the value used to receive 959 the RA, i.e. 1 if the client is behind a cone NAT, 0 otherwise. The 960 client can start using the Teredo service. 962 5.2.2 Secure qualification 964 The client may be required to perform secured qualification. The 965 client will perform exactly the algorithm described in 5.2.1, but it 966 will incorporate an authentication encapsulation in the UDP packet 967 carrying the router solicitation message, and it will verify the 968 presence of a valid authentication parameter in the UDP message that 969 carries the router advertisement provided by the sender. 971 In these packets, the nonce value is chosen by the client, and is 972 repeated in the response from the server; the client identifier is a 973 value with which the client was configured. 975 A first level of protection is provided by just checking that the 976 value of the nonce in the response matches the value initially sent 977 by the client; if they don't match, the packet MUST be discarded. If 978 no other protection is used, the authentication payload does not 979 contain any identifier or authentication field; the ID-len and AU- 980 len fields are set to a null value. When stronger protection is 981 required, the authentication payload contains the identifier and 982 location fields, as explained in the following paragraphs. 984 The confirmation byte is set to 0 by the client. A null value 985 returned by the server indicates that the client's key is still 986 valid; a non-null value indicates that the client should obtain a 987 new key. 989 When stronger authentication is provided, the client and the server 990 are provisioned with a client identifier, a shared secret, and the 991 identification of an authentication algorithm. Before transmission, 992 the authentication value is computed according to the specified 993 algorithm; on reception, the same algorithm is used to compute a 994 target value from the content of the receive packet. The receiver 995 deems the authentication successful if the two values match. If hey 996 don't, the packet MUST be discarded. 998 To maximize interoperability, this specification defines a default 999 algorithm in which the authentication value is computed according 1000 the HMAC specification [RFC2104] and the SHA1 function [FIPS-180]. 1001 Clients and servers may agree to use HMAC combined with a different 1002 function, or to use a different algorithm altogether, such as for 1003 example AES-XCBC-MAC-96 [RFC3566]. 1005 The default authentication algorithm is based on the HMAC algorithm 1006 according to the following specifications: 1008 - the hash function shall be the SHA1 function [FIPS-180]. 1009 - the secret value shall be the shared secret with which the client 1010 was configured 1012 The clear text to be protected includes: 1014 - the nonce value, 1015 - the confirmation byte, 1016 - the origin indication encapsulation, if it is present, 1017 - the IPv6 packet. 1019 The HMAC procedure is applied to the concatenation of these four 1020 components, without any additional padding. 1022 5.2.3 Packet reception 1024 The Teredo client receives packets over the Teredo interface. The 1025 role of the packet reception procedure, besides receiving packets, 1026 is to maintain the date and time of the last interaction with the 1027 Teredo server, and the "list of recent peers." 1029 When a UDP packet is received over the Teredo service port, the 1030 Teredo client checks that it is encoded according to the packet 1031 encoding rules defined in 5.1.1, and that it contains either a valid 1032 IPv6 packet, or the combination of a valid origin indication 1033 encapsulation and a valid IPv6 packet, possibly protected by a valid 1034 authentication encapsulation. If this is not the case, the packet is 1035 silently discarded. 1037 An IPv6 packet is deemed valid if it conforms to [RFC2460]: the 1038 protocol identifier should indicate an IPv6 packet and the payload 1039 length should be consistent with the length of the UDP datagram in 1040 which the packet is encapsulated. In addition, the client should 1041 check that the IPv6 destination address correspond to its own Teredo 1042 address. 1044 Then, the Teredo client examines the IPv4 source address and UDP 1045 port number from which the packet is received. If these values match 1046 the IPv4 address of the server and the Teredo port, the client 1047 updates the "date and time of the last interaction with the Teredo 1048 server" to the current date and time; if an origin indication is 1049 present, the client should perform the "direct IPv6 connectivity 1050 test" described in section 5.2.9. 1052 If the IPv4 source address and UDP port number are different from 1053 the IPv4 address of the server and the Teredo port, the client 1054 examines the IPv6 source address of the packet: 1056 1) If there is an entry for the source IPv6 address in the list of 1057 peers whose status is trusted, the client compares the mapped IPv4 1058 address and mapped port in the entry with the source IPv4 address 1059 and source port of the packet. If the values match, the packet is 1060 accepted; the date and time of the last reception from the peer is 1061 updated. 1063 2) If there is an entry for the source IPv6 address in the list of 1064 peers whose status is not trusted, the client checks whether the 1065 packet is an ICMPv6 echo reply. If this is the case, and if the 1066 ICMPv6 data of the reply matches the "nonce" stored in the peer 1067 entry, the packet should be accepted; the status of the entry should 1068 be changed to "trusted", the mapped IPv4 and mapped port in the 1069 entry should be set to the source IPv4 address and source port from 1070 which the packet was received, and the date and time of the last 1071 reception from the peer should be updated; any packet queued for 1072 this IPv6 peer (as specified in 5.2.4) should be de-queued and 1073 forwarded to the newly learned IPv4 address and UDP port. 1075 3) If the source IPv6 address is a Teredo address, the client 1076 compares the mapped IPv4 address and mapped port in the source 1077 address with the source IPv4 address and source port of the packet. 1078 If the values match, the client MUST create a peer entry for the 1079 IPv6 source address in the list of peers; it should update the entry 1080 if one already existed; the mapped IPv4 address and mapped port in 1081 the entry should be set to the value from which the packet was 1082 received, and the status should be set to "trusted". If a new entry 1083 is created, the last transmission date is set to 30 seconds before 1084 the current date, and the number of bubbles to zero. If the packet 1085 is a bubble, it should be discarded after this processing; 1086 otherwise, the packet should be accepted. In all cases, the client 1087 must de-queue and forward any packet queued for that destination. 1089 4) If the IPv4 destination address through which the packet was 1090 received is the Teredo IPv4 Discovery Address, the source address is 1091 a valid Teredo address, and the destination address is the "all 1092 nodes on link" multicast address, the packet should be treated as a 1093 local discovery bubble. If no local entry already existed for the 1094 source address, a new one is created, but its status is set to "not 1095 trusted". The client SHOULD reply with a unicast Teredo bubble, sent 1096 to the source IPv4 address and source port of the local discovery 1097 bubble; the IPv6 source address of the bubble will be set to local 1098 Teredo IPv6 address; the IPv6 destination address of the bubble 1099 should be set to the IPv6 source address of the local discovery 1100 bubble. (Clients that do not implement the optional local discovery 1101 procedure will not process local discovery bubbles.) 1103 5) If the source IPv6 address is a Teredo address, and the mapped 1104 IPv4 address and mapped port in the source address do not match the 1105 source IPv4 address and source port of the packet, the client checks 1106 whether there is an existing "local" entry for that IPv6 address. If 1107 there is such an entry, and if the local IPv4 address and local port 1108 indicated in that entry match the source IPv4 address and source 1109 port of the packet, the client updates the "local" entry, whose 1110 status should be set to "trusted". If the packet is a bubble, it 1111 should be discarded after this processing; otherwise, the packet 1112 should be accepted. In all cases, the client must de-queue and 1113 forward any packet queued for that destination. 1115 6) In the other cases, the packet may be accepted, but the client 1116 should be conscious that the source address may be spoofed; before 1117 processing the packet, the client should perform the "direct IPv6 1118 connectivity test" described in section 5.2.9. 1120 Whatever the IPv4 source address and UDP source port, the client 1121 that receives an IPv6 packet MAY send a Teredo bubble towards that 1122 target, as specified in section 5.2.6. 1124 5.2.4 Packet transmission 1126 When a Teredo client has to transmit a packet over a Teredo 1127 interface, it examines the destination IPv6 address. The client 1128 checks first if there is an entry for this IPv6 address in the list 1129 of recent Teredo peers, and if the entry is still valid: an entry 1130 associated with a local peer is valid if the last reception date and 1131 time associated with that list entry is less that 30 seconds from 1132 the current time; an entry associated with a non-local peer is valid 1133 if the last reception date and time associated with that list entry 1134 is less that 30 seconds from the current time. (Local peer entries 1135 can only be present if the client uses the local discovery procedure 1136 discussed in section 5.2.8.) 1138 The client then performs the following: 1140 1) If there is an entry for that IPv6 address in the list of peers, 1141 and if the status of the entry is set to "trusted", the IPv6 packet 1142 should be sent over UDP to the IPv4 address and UDP port specified 1143 in the entry. The client updates the date of last transmission in 1144 the peer entry. 1146 2) If the destination is not a Teredo IPv6 address, the packet is 1147 queued, and the client performs the "direct IPv6 connectivity test" 1148 described in section 5.2.9. The packet will be de-queued and 1149 forwarded if this procedure completes successfully. If the direct 1150 IPv6 connectivity test fails to complete within a 2 second time-out, 1151 it should be repeated up to 3 times. 1153 3) If the destination is the Teredo IPv6 address of a local peer 1154 (i.e. a Teredo address from which a local discovery bubble has been 1155 received in the last 600 seconds), the packet is queued. The client 1156 sends a unicast Teredo bubble to the local IPv4 address and local 1157 port specified in the entry, and a local Teredo bubble to the Teredo 1158 IPv4 discovery address. 1160 4) If the destination is a Teredo IPv6 address in which the cone bit 1161 is set to 1, the packet is sent over UDP to the mapped IPv4 address 1162 and mapped UDP port extracted from that IPv6 address. 1164 5) If the destination is a Teredo IPv6 address in which the cone bit 1165 is set to 0, the packet is queued. If the client is not located 1166 behind a cone NAT, it sends a direct bubble to the Teredo 1167 destination, i.e. to the mapped IP address and mapped port of the 1168 destination. In all cases, the client sends an indirect bubble to 1169 the Teredo destination, sending it over UDP to the server address 1170 and to the Teredo port. The packet will be de-queued and forwarded 1171 when the client receives a bubble or another packet directly from 1172 this Teredo peer. If no bubble is received within a 2 second time- 1173 out, the bubble transmission should be repeated up to 3 times. 1175 In cases 4 and 5, before sending a packet over UDP, the client MUST 1176 check that the IPv4 destination address is in the format of a global 1177 unicast address; if this is not the case, the packet MUST be 1178 silently discarded. (Note that a packet can legitimately be sent to 1179 a non-global unicast address in case 1, as a result of the local 1180 discovery procedure.) 1182 The global unicast address check is designed to thwart a number of 1183 possible attacks in which an attacker tries to us a Teredo host to 1184 attack either a single local IPv4 target, or a set of such targets. 1185 For the purpose of this specification, and IPv4 address is deemed to 1186 be a global unicast address if it does not belong to or match: 1187 - the "local" subnet 0.0.0.0/8, 1188 - the "loopback" subnet 127.0.0.0/8, 1189 - the local addressing ranges 10.0.0.0/8, 1190 - the local addressing ranges 172.16.0.0/12, 1191 - the local addressing ranges 192.168.0.0/16, 1192 - the link local block 169.254.0.0/16, 1193 - the block reserved for 6to4 anycast addresses 192.88.99.0/24, 1194 - the multicast address block 224.0.0.0/4, 1195 - the "limited broadcast" destination address 255.255.255.255, 1196 - the directed broadcast addresses corresponding to the subnets to 1197 which the host is attached. 1198 A list of special-use IPv4 addresses is provided in [RFC3330]. 1200 For reliability reasons, clients MAY decide to ignore the value of 1201 the "cone" bit in the flag, skip the "case 4" test and always 1202 perform the "case 5", i.e. treat all Teredo peers as if they were 1203 located behind non-cone NAT. This will result in some increase in 1204 traffic, but may avoid reliability issues if the determination of 1205 the NAT status was for some reason erroneous. For the same reason, 1206 clients MAY also decide to always send a direct bubble in case 5, 1207 even if they do not believe that they are located behind a non-cone 1208 NAT. 1210 5.2.5 Maintenance 1211 The Teredo client must ensure that the mappings that it uses remain 1212 valid. It does so by checking that packets are regularly received 1213 from the Teredo server. 1215 At regular intervals, the client MUST check the "date and time of 1216 the last interaction with the Teredo server", to ensure that at 1217 least one packet has been received in the last Randomized Teredo 1218 Refresh Interval. If this is not the case, the client SHOULD send a 1219 router solicitation message to the server, as specified in 5.2.1; 1220 the client should use the same value of the "cone" bit that resulted 1221 in the reception of an RA during the qualification procedure. 1223 When the router advertisement is received, the client SHOULD check 1224 its validity as specified in 5.2.1; invalid advertisements are 1225 silently discarded. If the advertisement is valid, the client MUST 1226 check that the mapped address and port correspond to the current 1227 Teredo address. If this is not the case, the mapping has changed; 1228 the client must mark the old address as invalid, and start using the 1229 new address. 1231 5.2.6 Sending Teredo Bubbles 1233 The Teredo client may have to send a bubble towards another Teredo 1234 client, either after a packet reception or after a transmission 1235 attempt, as explained in sections 5.2.3 and 5.2.4. There are two 1236 kinds of bubbles: direct bubbles, that are sent directly to the 1237 mapped IPv4 address and mapped UDP port of the peer, and indirect 1238 bubbles that are sent through the Teredo server of the peer. 1240 When a Teredo client attempts to send a direct bubble, it extracts 1241 the mapped IPv4 address and mapped UDP port from the Teredo IPv6 1242 address of the target. It then checks whether there is already an 1243 entry for this IPv6 address in the current list of peers. If there 1244 is no entry, the client MUST create a new list entry for the 1245 address, setting the last reception date and the last transmission 1246 date to 30 seconds before the current date, and the number of 1247 bubbles to zero. 1249 When a Teredo client attempts to send an indirect bubble, it 1250 extracts the Teredo server IPv4 address from the Teredo prefix of 1251 the IPv6 address of the target (different clients may be using 1252 different servers); the bubble will be sent to that IPv4 address and 1253 the Teredo UDP port. 1255 Bubbles may be lost in transit, and it is reasonable to enhance the 1256 reliability of the Teredo service by allowing multiple 1257 transmissions; however, bubbles will also be lost systematically in 1258 certain NAT configurations. In order to strike a balance between 1259 reliability and unnecessary retransmissions, we specify the 1260 following: 1262 - The client MUST NOT send a bubble if the last transmission date 1263 and time is less than 2 seconds before the current date and time; 1265 - The client MUST NOT send a bubble if it has already sent 4 bubbles 1266 to the peer in the last 300 seconds without receiving a direct 1267 response. 1269 In the other cases, the client MAY proceed with the transmission of 1270 the bubble. When transmitting the bubble, the client MUST update the 1271 last transmission date and time to that peer, and must also 1272 increment the number of transmitted bubbles. 1274 5.2.7 Optional Refresh Interval Determination Procedure 1276 In addition to the regular client resources described in the 1277 beginning of this section, the refresh interval determination 1278 procedure uses an additional UDP port, the Teredo secondary port, 1279 and the following variables: 1281 - Teredo secondary connectivity status, 1282 - Mapped address and port number of the Teredo secondary port, 1283 - Teredo secondary IPv6 prefix associated with the secondary port, 1284 - Teredo secondary IPv6 address derived from this prefix, 1285 - Date and time of the last interaction on the secondary port, 1286 - Maximum Teredo Refresh Interval. 1287 - Candidate Teredo Refresh Interval. 1289 The secondary connectivity status, mapped address and prefix are 1290 determined by running the qualification procedure on the secondary 1291 port. When the client uses the interval determination procedure, the 1292 qualification procedure MUST be run for the secondary port 1293 immediately after running it on the service port. If the secondary 1294 qualification fails, the interval determination procedure will not be 1295 used, and the interval value will remain to the default value, 30 1296 seconds. If the secondary qualification succeeds, the maximum refresh 1297 interval is set to 120 seconds, and the candidate Teredo refresh 1298 interval is set to 60 seconds, i.e. twice the Teredo refresh 1299 interval. The procedure is then performed at regular intervals, until 1300 it concludes: 1302 1) wait until the candidate refresh interval is elapsed after the 1303 last interaction on the secondary port; 1305 2) send a Teredo bubble to the Teredo secondary IPv6 address, through 1306 the service port. 1308 3) wait for reception of the bubble on the secondary port. If a timer 1309 of 2 seconds elapses without reception, repeat step 2 at most three 1310 times. If there is still no reception, the candidate has failed; if 1311 there is a reception, the candidate has succeeded. 1313 4) if the candidate has succeeded, set the Teredo refresh interval to 1314 the candidate value, and set a new candidate value to the minimum of 1315 twice the new refresh interval, or the average of the refresh 1316 interval and the maximum refresh interval. 1318 5) if the candidate has failed, set the maximum refresh interval to 1319 the candidate value. If the current refresh interval is larger than 1320 or equal to 75% of the maximum, the determination procedure has 1321 concluded; otherwise, set a new candidate value to the average of the 1322 refresh interval and the maximum refresh interval. 1324 6) if the procedure has not concluded, perform the maintenance 1325 procedure on the secondary port, which will reset the date and time 1326 of the last interaction on the secondary port, and may result in the 1327 allocation of a new Teredo secondary IPv6 address; this would not 1328 affect the values of the refresh interval, candidate interval or 1329 maximum refresh interval. 1331 The secondary port MUST NOT be used for any other purpose than the 1332 interval determination procedure. It should be closed when the 1333 procedure ends. 1335 5.2.8 Optional local client discovery procedure 1337 It is desirable to enable direct communication between Teredo 1338 clients that are located behind the same NAT, without forcing a 1339 systematic relay through a Teredo server. It is hard to design a 1340 general solution to this problem, but we can design a partial 1341 solution when the Teredo clients are connected through IPv4 to the 1342 same link. 1344 A Teredo client who wishes to enable local discovery SHOULD join the 1345 IPv4 multicast group identified by Teredo IPv4 Discovery Address. 1346 The client SHOULD wait for discovery bubbles to be received on the 1347 Teredo IPv4 Discovery Address. The client SHOULD send local 1348 discovery bubbles to the Teredo IPv4 Discovery Address at random 1349 intervals, uniformly distributed between 200 and 300 seconds. A 1350 local Teredo bubble has the following characteristics: 1352 - IPv4 source address: the IPv4 address of the sender 1354 - IPv4 destination address: the Teredo IPv4 Discovery Address 1356 - IPv4 ttl: 1 1358 - UDP source port: the Teredo service port of the sender 1360 - UDP destination port: the Teredo UDP port 1362 - UDP payload: a minimal IPv6 packet, as follows 1364 - IPv6 source: the global Teredo IPv6 address of the sender 1366 - IPv6 destination: the all-nodes on-link multicast address 1367 - IPv6 payload type: 59 (No Next Header, as per [RFC2460]) 1369 - IPv6 payload length: 0 1371 - IPv6 hop limit: 1 1373 The local discovery procedure carries a denial of service risk, as 1374 malevolent nodes could send fake bubbles to unsuspecting parties, 1375 and thus capture the traffic originating from these parties. The 1376 risk is mitigated by the filtering rules described in section 5.2.5, 1377 and also by "link only" multicast scope of the Teredo IPv4 Discovery 1378 Address, which implies that packets sent to this address will not be 1379 forwarded across routers. 1381 To benefit from the "link only multicast" protection, the clients 1382 should silently discard all local discovery bubbles that are 1383 received over a unicast address. To further mitigate the denial of 1384 service risk, the client MUST silently discard all local discovery 1385 bubbles whose IPv6 source address is not a well-formed Teredo IPv6 1386 address, or whose IPv4 source address does not belong to the local 1387 IPv4 subnet; the client MAY decide to silently discard all local 1388 discovery bubbles whose Teredo IPv6 address do not include the same 1389 mapped IPv4 address as its own. 1391 If the bubble is accepted, the client checks whether there is an 1392 entry in the list of recent peers that correspond to the mapped IPv4 1393 address and mapped UDP port associated with the source IPv6 address 1394 of the bubble. If there is such an entry, the client MUST update the 1395 local peer address and local peer port parameters to reflect the 1396 IPv4 source address and UDP source port of the bubble. If there is 1397 no entry, the client MUST create one, setting the local peer address 1398 and local peer port parameters to reflect the IPv4 source address 1399 and UDP source port of the bubble, the last reception date to the 1400 current date and time, the last transmission date to 30 seconds 1401 before the current date, and the number of bubbles to zero; the 1402 state of the entry is set to "not trusted". 1404 Upon reception of a discovery bubble, clients reply with a unicast 1405 bubble as specified in section 5.2.3. 1407 5.2.9 Direct IPv6 connectivity test 1409 The Teredo procedures are designed to enable direct connections 1410 between a Teredo host and a Teredo relay. Teredo hosts located 1411 behind a cone NAT will receive packets directly from relays; other 1412 Teredo hosts will learn the original addresses and UDP ports of 1413 third parties through the local Teredo server. In all of these 1414 cases, there is a risk that the IPv6 address of the source be 1415 spoofed by a malevolent party. Teredo hosts must make two decisions, 1416 whether to accept the packet for local processing, and whether to 1417 transmit further packets to the IPv6 address through the newly 1418 learned IPv4 address and UDP port. The basic rule is that the hosts 1419 should be generous in what they accept, and careful in what they 1420 send. Refusing to accept packets due to spoofing concerns would 1421 compromise connectivity, and should only be done when there is a 1422 near certainty that the source address is spoofed; on the other 1423 hand, sending packets to the wrong address should be avoided. 1425 When the client wants to send a packet to a native IPv6 node or a 1426 6to4 node, it should check whether a valid peer entry already exists 1427 for the IPv6 address of the destination. If this is not the case, 1428 the client will pick a random number (a nonce) and format an ICMPv6 1429 Echo Request message whose source is the local Teredo address, whose 1430 destination is the address of the IPv6 node, and whose Data field is 1431 set to the nonce. (It is recommended to use a random number at least 1432 64 bit long.) The nonce value and the date at which the packet was 1433 sent will be documented in a provisional peer entry for the IPV6 1434 destination. The ICMPv6 packet will then be sent encapsulated in a 1435 UDP packet destined to the Teredo server IPv4 address, and to the 1436 Teredo port. The rules of section 5.2.3 specify how the reply to 1437 this packet will be processed. 1439 5.2.10 Working around symmetric NAT 1441 The client procedures are designed to enable IPv6 connectivity 1442 through the most common types of NAT, which are commonly called 1443 "Cone NAT" and "restricted cone NAT" [RFC3489]. Some NAT employ a 1444 different design; they are often called "symmetric NAT". The 1445 qualification algorithm in section 5.2.1 will not succeed when the 1446 local NAT is a symmetric NAT. 1448 In many cases, it is possible to work around the limitations of 1449 these NAT by explicitly reserving a UDP port for Teredo service on a 1450 client, using a function often called "DMZ" in the NAT's manual. 1451 This port will become the "service port" used by the Teredo hosts. 1452 The implementers of Teredo functions in hosts must make sure that 1453 the value of the service port can be explicitly provisioned, so that 1454 user can provision the same value in the host and in the NAT. 1456 The reservation procedure guarantees that the port mapping will 1457 remain the same for all destinations. After the explicit 1458 reservation, the qualification algorithm in section 5.2.1 will 1459 succeed, and the Teredo client will behave as if behind a "cone 1460 NAT". 1462 When different clients use Teredo behind a single symmetric NAT, 1463 each of these clients must reserve and use a different service port. 1465 5.3 Teredo Server specification 1467 The Teredo server is designed to be stateless. The Teredo server 1468 waits for incoming UDP packets at the Teredo Port, using the IPv4 1469 address that has been selected for the service. In addition, the 1470 server is able to receive and transmit some packets using a 1471 different IPv4 address and a different port number. 1473 The Teredo server acts as an IPv6 router. As such, it will receive 1474 Router Solicitation messages, to which it will respond with Router 1475 Advertisement messages as explained in section 5.3.2; it may also 1476 receive other packets, for example ICMPv6 messages and Teredo 1477 bubbles, which are processed according to the IPv6 specification. 1479 By default, the routing functions of the Teredo server are limited. 1480 Teredo servers are expected to relay Teredo bubbles, ICMPv6 Echo 1481 requests and ICMPv6 Echo replies, but they are not expected to relay 1482 other types of IPv6 packets. Operators may however decide to combine 1483 the functions of "Teredo server" and "Teredo relay", as explained in 1484 section 5.4. 1486 5.3.1 Processing of Teredo IPv6 packets 1488 Before processing the packet, the Teredo server MUST check the 1489 validity of the encapsulated IPv6 source address, the IPv4 source 1490 address and the UDP source port: 1492 1) If the UDP content is not a well formed Teredo IPv6 packet, as 1493 defined in section 5.1.1, the packet MUST be silently discarded. 1495 2) If the UDP packet is not a Teredo bubble or an ICMPv6 message, it 1496 SHOULD be discarded. (The packet may be processed if the Teredo 1497 server also operates as a Teredo relay, as explained in section 1498 5.4.) 1500 3) If the IPv4 source address is not in the format of a global 1501 unicast address, the packet MUST be silently discarded (see 1502 section 5.2.4 for a definition of global unicast addresses). 1504 4) If the IPv6 source address is an IPv6 link-local address, the 1505 IPv6 destination address is the link-local scope all routers 1506 multicast address (FF02::2), and the packet contains an ICMPv6 1507 Router Solicitation message, the packet MUST be accepted; it MUST 1508 be discarded if the server requires secure qualification and the 1509 authentication encapsulation is absent or verification fails. 1511 5) If the IPv6 source address is a Teredo IPv6 address, and if the 1512 IPv4 address and UDP port embedded in that address match the IPv4 1513 source address and UDP source port, the packet SHOULD be 1514 accepted. 1516 6) If the IPv6 source address is not a Teredo IPv6 address, and if 1517 the IPv6 destination address is a Teredo address allocated 1518 through this server, the packet SHOULD be accepted. 1520 7) In all other cases, the packet MUST be silently discarded. 1522 The Teredo server will then check the IPv6 destination address of 1523 the encapsulated IPv6 packet: 1525 If the IPv6 destination address is the link-local scope all routers 1526 multicast address (FF02::2), or the link-local address of the 1527 server, the Teredo server processes the packet; it may have to 1528 process Router Solicitation messages and ICMPv6 Echo Request 1529 messages. 1531 If the destination IPv6 address is not a global scope IPv6 address, 1532 the packet MUST NOT be forwarded. 1534 If the destination address is not a Teredo IPv6 address the packet 1535 should be relayed to the IPv6 Internet using regular IPv6 routing. 1537 If the IPv6 destination address is a valid Teredo IPv6 address as 1538 defined in 2.13, the Teredo Server MUST check that the IPv4 address 1539 derived from this IPv6 address is in the format of a global unicast 1540 address; if this is not the case, the packet MUST be silently 1541 discarded. 1543 If the address is valid, the Teredo server encapsulates the IPv6 1544 packet in a new UDP datagram, in which the following parameters are 1545 set: 1547 - The destination IPv4 address is derived from the IPv6 destination. 1549 - The source IPv4 address is the Teredo server IPv4 address. 1551 - The destination UDP port is derived from the IPv6 destination. 1553 - The source UDP port is set to the Teredo UDP Port. 1555 If the destination IPv6 address is a Teredo client whose address is 1556 serviced by this specific server, the server should insert an origin 1557 indication in the first bytes of the UDP payload, as specified in 1558 section 5.1.1. (To verify that the client is served by this server, 1559 the server compares bits 32-63 of the client's Teredo IPv6 address 1560 to the server's IPv4 address.) 1562 5.3.2 Processing of router solicitations 1564 When the Teredo server receives a Router Solicitation message (RS, 1565 [RFC2461]), it retains the IPv4 address and UDP port from which the 1566 solicitation was received; these become the Teredo mapped address 1567 and Teredo mapped port of the client. The router uses these values 1568 to compose the origin indication encapsulation that will be sent 1569 with the response to the solicitation. 1571 The Teredo server responds to the router solicitation by sending a 1572 Router Advertisement message [RFC2461]. The router advertisement 1573 MUST advertise the Teredo IPv6 prefix composed from the service 1574 prefix and the server's IPv4 address. The IPv6 source address should 1575 be set to a Teredo link-local server address associated to the local 1576 interface; this address is derived from the IPv4 address of the 1577 server and from the Teredo port, as specified in section 4; the C 1578 bit is set to 1. The IPv6 destination address is set to the IPv6 1579 source address of the RS. The Router Advertisement message must be 1580 sent over UDP to the Teredo mapped address and Teredo mapped port of 1581 the client; the IPv4 source address and UDP source port should be 1582 set to the server's IPv4 address and Teredo Port. If the cone bit of 1583 the client's IPv6 address is set to 1, the RA must be sent from a 1584 different IPv4 source address than the server address over which the 1585 RS was received; if the cone bit is set to zero, the response must 1586 be sent back from the same address. 1588 Before sending the packet, the Teredo server MUST check that the 1589 IPv4 destination address is in the format of a global unicast 1590 address; if this is not the case, the packet MUST be silently 1591 discarded (see section 5.2.4 for a definition of global unicast 1592 addresses). 1594 If secure qualification is required, the server MUST insert a valid 1595 authentication parameter in the UDP packet carrying the router 1596 advertisement. The client identifier and the nonce value used in the 1597 authentication parameter MUST be the same identifier and nonce as 1598 received in the router solicitation; the confirmation byte MUST be 1599 set to zero if the client identifier is still valid, and a non-null 1600 value otherwise; the authentication value SHOULD be computed using 1601 the secret that corresponds to the client identifier. 1603 5.4 Teredo Relay specification 1605 Teredo relays are IPv6 routers that advertise reachability of the 1606 Teredo service IPv6 prefix through the IPv6 routing protocols. (A 1607 minimal Teredo relay may serve just a local host, and would not 1608 advertise the prefix beyond this host.) Teredo relays will receive 1609 IPv6 packets bound to Teredo clients. Teredo relays should be able 1610 to receive packets sent over IPv4 and UDP by Teredo clients; they 1611 may apply filtering rules, e.g. only accept packets from Teredo 1612 clients if they have previously sent traffic to these Teredo 1613 clients. 1615 The receiving and sending rules used by Teredo relays are very 1616 similar to those of Teredo clients. Teredo relays must use a Teredo 1617 service port to transmit packets to Teredo clients; they must 1618 maintain a "list of peers", identical to the list of peers 1619 maintained by Teredo clients. 1621 5.4.1 Transmission by relays to Teredo clients 1623 When a Teredo relay has to transmit a packet to a Teredo client, it 1624 examines the destination IPv6 address. By definition, the Teredo 1625 relays will only send over UDP IPv6 packets whose IPv6 destination 1626 address is a valid Teredo IPv6 address. 1628 Before processing these packets, the Teredo Relay MUST check that 1629 the IPv4 destination address embedded in the Teredo IPv6 address is 1630 in the format of a global unicast address; if this is not the case, 1631 the packet MUST be silently discarded (see section 5.2.4 for a 1632 definition of global unicast addresses). 1634 The relay then checks if there is an entry for this IPv6 address in 1635 the list of recent Teredo peers, and if the entry is still valid. 1636 The relay then performs the following: 1638 1) If there is an entry for that IPv6 address in the list of peers, 1639 and if the status of the entry is set to "trusted", the IPv6 packet 1640 should be sent over UDP to the mapped IPv4 address and mapped UDP 1641 port of the entry. The relay updates the date of last transmission 1642 in the peer entry. 1644 2) If there is no trusted entry in the list of peers, and if the 1645 destination is a Teredo IPv6 address in which the cone bit is set to 1646 1, the packet is sent over UDP to the mapped IPv4 address and mapped 1647 UDP port extracted from that IPv6 address. 1649 3) If there is no trusted entry in the list of peers, and if the 1650 destination is a Teredo IPv6 address in which the cone bit is set to 1651 0, the Teredo relay creates a bubble whose source address is set to 1652 a local IPv6 address, and whose destination address is set to the 1653 Teredo IPv6 address of the packet's destination. The bubble is sent 1654 to the server address corresponding to the Teredo destination. The 1655 entry becomes trusted when a bubble or another packet is received 1656 from this IPv6 address; if no such packet is received before a time- 1657 out of 2 seconds, the Teredo relay may repeat the bubble, up to 1658 three times. If the relay fails to receive a bubble after these 1659 repetitions, the entry is removed from the list of peers. The relay 1660 MAY queue packets bound to untrusted entries; the queued packets 1661 SHOULD be de-queued and forwarded when entry become trusted; they 1662 SHOULD be deleted if the entry is deleted. To avoid denial of 1663 service attacks, the relays SHOULD limit the number of packets in 1664 such queues. 1666 In cases 2 and 3, the Teredo relay should create a peer entry for 1667 the IPv6 address; the entry status is marked as trusted in case 2 1668 (cone NAT), not trusted in case 3. In case 3, if the Teredo relay 1669 happens to be located behind a non-cone NAT, it should also send a 1670 bubble directly to the mapped IPv4 address and mapped port number of 1671 the Teredo destination; this will "open the path" for the return 1672 bubble from the Teredo client. 1674 For reliability reasons, relays MAY decide to ignore the value of 1675 the "cone" bit in the flag, and always perform the "case 3", i.e. 1676 treat all Teredo peers as if they were located behind non-cone NAT. 1677 This will result in some increase in traffic, but may avoid 1678 reliability issues if the determination of the NAT status was for 1679 some reason erroneous. For the same reason, relays MAY also decide 1680 to always send a direct bubble to the mapped IPv4 address and mapped 1681 port number of the Teredo destination, even if they do not believe 1682 that they are located behind a non-cone NAT. 1684 5.4.2 Reception from Teredo clients 1686 The Teredo relay may receive packets from Teredo clients; the 1687 packets should normally only be sent by clients to which the relay 1688 previously transmitted packets, i.e. clients whose IPv6 address is 1689 present in the list of peers. Relays, like clients, use the packet 1690 reception procedure to maintain the date and time of the last 1691 interaction with the Teredo server, and the "list of recent peers." 1693 When a UDP packet is received over the Teredo service port, the 1694 Teredo relay checks that it contains a valid IPv6 packet as 1695 specified in [RFC2460]. If this is not the case, the packet is 1696 silently discarded. 1698 Then, the Teredo relay examines whether the IPv6 source address is a 1699 valid Teredo address, and if the mapped IPv4 address and mapped port 1700 match the IPv4 source address and port number from which the packet 1701 is received. If this is not the case, the packet is silently 1702 discarded. 1704 The Teredo relay then examines whether there is an entry for the 1705 IPv6 source address in the list of recent peers. If this is not the 1706 case, the packet may be silently discarded. If this is the case, the 1707 entry status is set to "trusted"; the relay updates the "date and 1708 time of the last interaction" to the current date and time. 1710 Finally, the relay examines the destination IPv6 address. If the 1711 destination belongs to a range of IPv6 addresses served by the 1712 relay, the packet SHOULD be accepted and forwarded to the 1713 destination. In the other cases, the packet SHOULD be silently 1714 discarded. 1716 5.4.3 Difference between Teredo Relays and Teredo Servers 1718 Because Teredo servers can relay Teredo packets over IPv6, all 1719 Teredo servers must be capable of behaving as Teredo relays. There 1720 is however no requirement that Teredo relays behave as Teredo 1721 servers. 1723 The dual-role of server and relays implies an additional complexity 1724 for the programming of servers: the processing of incoming packets 1725 should be a combination of the server processing rules defined in 1726 5.3.1, and the relay processing rules defined in 5.4.2. (Section 5.3 1727 only specifies the rules implemented by a pure server, not a 1728 combination relay+server.) 1730 5.5 Implementation of automatic sunset 1732 Teredo is designed as an interim transition mechanism, and it is 1733 important that it should not be used any longer than necessary. The 1734 "sunset" procedure will be implemented by Teredo clients, servers 1735 and relays, as specified in this section. 1737 The Teredo-capable nodes MUST NOT behave as Teredo clients if they 1738 already have IPv6 connectivity through any other means, such as 1739 native IPv6 connectivity; in particular, nodes that have a global 1740 IPv4 address SHOULD obtain connectivity through the 6to4 service 1741 rather than through the Teredo service. The classic reason why a 1742 node that does not need connectivity would still enable the Teredo 1743 service is to guarantee good performance when interacting with 1744 Teredo clients; however, a Teredo-capable node that has IPv4 1745 connectivity and that has obtained IPv6 connectivity outside the 1746 Teredo service MAY decide to behave as a Teredo relay, and still 1747 obtain good performance when interacting with Teredo clients. 1749 The Teredo servers are expected to participate in the sunset 1750 procedure by announcing a date at which they will stop providing the 1751 service. This date depends on the availability of alternative 1752 solutions to their clients, such as "dual-mode" gateways that behave 1753 simultaneously as IPv4 NATs and IPv6 routers. Most Teredo servers 1754 will not be expected to operate more than a few years. 1755 Teredo relays are expected to have the same life span as Teredo 1756 servers. 1758 6 Further study, use of Teredo to implement a tunnel service 1760 Teredo defines a NAT traversal solution that can be provided using 1761 very little resource at the server. Ongoing IETF discussions have 1762 outlined the need for both a solution like Teredo and a more 1763 controlled NAT traversal solution, using configured tunnels to a 1764 service provider [RFC3904]. This section provides a tentative 1765 analysis of how Teredo could be extended to also support a 1766 configured tunnel service. 1768 It may be possible to design a tunnel server protocol that is 1769 compatible with Teredo, in the sense that the same client could be 1770 used either in the Teredo service or with a tunnel service. In fact, 1771 this could be done by configuring the client with: 1773 - The IPv4 address of a Teredo server that acts as a tunnel broker 1774 - A client identifier 1775 - A shared secret with that server 1776 - An agreed upon authentication algorithm. 1778 The Teredo client would use the secure qualification procedure, as 1779 specified in section 5.2.2. Instead of returning a Teredo prefix in 1780 the router advertisement, the server would return a globally 1781 routable IPv6 prefix; this prefix could be permanently assigned to 1782 the client, which would provide the client with a stable address. 1783 The server would have to keep state, i.e. memorize the association 1784 between the prefix assigned to the client and the mapped IPv4 1785 address and mapped UDP port of the client. 1787 The Teredo server would advertise reachability of the client prefix 1788 to the IPv6 Internet. Any packet bound to that prefix would be 1789 transmitted to the mapped IPv4 address and mapped UDP port of the 1790 client. 1792 The Teredo client, when it receives the prefix, would notice that 1793 this prefix is a global IPv6 prefix, not in the form of a Teredo 1794 prefix. The client would at that point recognize that it should 1795 operate in tunnel mode. A client that operates in tunnel mode would 1796 execute a much simpler transmission procedure: it would forward any 1797 packet sent to the Teredo interface to the IPv4 address and Teredo 1798 UDP port of the server. 1800 The Teredo client would have to perform the maintenance procedure 1801 described in section 5.2.5. The server would receive the router 1802 solicitation, and could notice a possible change of mapped IPv4 1803 address and mapped UDP port that could result from the 1804 reconfiguration of the mappings inside the NAT. The server should 1805 continue advertising the same IPv6 prefix to the client, and should 1806 update the mapped IPv4 address and mapped UDP port associated to 1807 this prefix, if necessary. 1809 There is yet no consensus that a tunnel-mode extension to Teredo 1810 should be developed. This section is only intended to provide 1811 suggestions to the future developers of such services. Many details 1812 would probably have to be worked out before a tunnel-mode extension 1813 would be agreed upon. 1815 7 Security Considerations 1817 The main objective of Teredo is to provide nodes located behind a 1818 NAT with a globally routable IPv6 address. The Teredo nodes can use 1819 IP security (IPsec) services such as IKE, AH or ESP [RFC2409, 1820 RFC2402, RFC2406], without the configuration restrictions still 1821 present in the Negotiation of NAT-Traversal in IKE [RFC3947]. As 1822 such, we can argue that the service has a positive effect on network 1823 security. However, the security analysis must also envisage the 1824 negative effects of the Teredo services, which we can group in four 1825 categories: security risks of directly connecting a node to the IPv6 1826 Internet, spoofing of Teredo servers to enable a man-in-the-middle 1827 attack, potential attacks aimed at denying the Teredo service to a 1828 Teredo client, and denial of service attacks against non-Teredo 1829 participating nodes that would be enabled by the Teredo service. 1831 In the following, we review in detail these four types of issues, 1832 and we present mitigating strategies for each of them. 1834 7.1 Opening a hole in the NAT 1836 The very purpose of the Teredo service is to make a machine 1837 reachable through IPv6. By definition, the machine using the service 1838 will give up whatever "firewall" service was available in the NAT 1839 box, however limited this service may be [RFC2993]. The services 1840 that listen to the Teredo IPv6 address will become potential target 1841 of attacks from the entire IPv6 Internet. This may sound scary, but 1842 there are three mitigating factors. 1844 The first mitigating factor is the possibility to restrict some 1845 services to only accept traffic from local neighbors, e.g. using 1846 link local addresses. Teredo does not support communication using 1847 link local addresses. This implies that link-local services will not 1848 be accessed through Teredo, and will be restricted to whatever other 1849 IPv6 connectivity may be available, e.g. direct traffic with 1850 neighbors on the local link, behind the NAT. 1852 The second mitigating factor is the possible use of a "local 1853 firewall" solution, i.e. a piece of software that performs locally 1854 the kind of inspection and filtering that is otherwise performed in 1855 a perimeter firewall. Using such software is recommended. 1857 The third mitigating factor, is the availability of IP security 1858 (IPsec) services such as IKE, AH or ESP [RFC2409, RFC2402, RFC2406]. 1859 Using these services in conjunction with Teredo is a good policy, as 1860 it will protect the client from possible attacks in intermediate 1861 servers such as the NAT, the Teredo server, or the Teredo relay. 1862 (These services can however only be used if the parties in the 1863 communication can negotiate a key, which requires agreeing on some 1864 credentials; this is known to be a hard problem.) 1866 7.2 Using the Teredo service for a man-in-the-middle attack 1868 The goal of the Teredo service is to provide hosts located behind a 1869 NAT with a globally reachable IPv6 address. There is a possible 1870 class of attacks against this service in which an attacker somehow 1871 intercepts the router solicitation, responds with a spoofed router 1872 advertisement, and provides a Teredo client with an incorrect 1873 address. The attacker may have one of two objectives: it may try to 1874 deny service to the Teredo client by providing it with an address 1875 that is in fact unreachable, or it may try to insert itself as a 1876 relay for all client communications, effectively enabling a variety 1877 of "man-in-the-middle" attack. 1879 7.2.1 Attacker spoofing the Teredo Server 1881 The simple nonce verification procedure described in section 5.2.2 1882 provides a first level of protection against attacks in which a 1883 third party tries to spoof the server. In practice, the nonce 1884 procedure can only be defeated if the attacker is "on path". 1886 If client and server share a secret and agree on an authentication 1887 algorithm, the secure qualification procedure described in section 1888 5.2.2 provides further protection. To defeat this protection, the 1889 attacker could try to obtain a copy of the secret shared between 1890 client and server. The most likely way to obtain the shared secret 1891 is to listen to the traffic and mount an offline dictionary attack; 1892 to protect against this attack, the secret shared between client and 1893 server should contain sufficient entropy. (This probably requires 1894 some automated procedure for provisioning the shared secret and the 1895 algorithm.) 1897 If the shared secret contains sufficient entropy, the attacker would 1898 have to defeat the one-way function used to compute the 1899 authentication value. This specification suggests a default 1900 algorithm combining HMAC and MD5. If the protection afforded by MD5 1901 was not deemed sufficient, clients and servers can be agree to use a 1902 different algorithm, e.g. SHA1. 1904 Another way to defeat the protection afforded by the authentication 1905 procedure is to mount a complex attack, as follows: 1907 1) Client prepares router solicitation, including authentication 1908 encapsulation. 1910 2) Attacker intercepts the solicitation, and somehow manages to 1911 prevent it from reaching the server, for example by mounting a short 1912 duration DoS attack against the server. 1914 3) Attacker replaces the source IPv4 address and source UDP port of 1915 the request by one of its own addresses and port, and forwards the 1916 modified request to the server. 1918 4) Server dutifully notes the IPv4 address from which the packet is 1919 received, verifies that the Authentication encapsulation is correct, 1920 prepares a router advertisement, signs it, and sends it back to the 1921 incoming address, i.e. the attacker. 1923 5) Attacker receives the advertisement, takes note of the mapping, 1924 replaces the IPv4 address and UDP port by the original values in the 1925 intercepted message, and sends the response to the client. 1927 6) Client receives the advertisement, notes that the authentication 1928 header is present and is correct, and uses the proposed prefix and 1929 the mapped addresses in the origin indication encapsulation. 1931 The root cause of the problem is that the NAT is, in itself, a man- 1932 in-the-middle attack. The Authentication encapsulation covers the 1933 encapsulated IPv6 packet, but does not cover the encapsulating IPv4 1934 header and UDP header. It is very hard to devise an effective 1935 authentication scheme, since the attacker does not do anything else 1936 than what the NAT legally does! 1937 There are however several mitigating factors that lead us to avoid 1938 worrying too much about this attack. In practice, the gain from the 1939 attack is to either deny service to the client, or obtain a "man-in- 1940 the-middle" position; however, in order to mount the attack, the 1941 attacker must be able to suppress traffic originating from the 1942 client, i.e. have denial of service capability; the attacker must 1943 also be able to observe the traffic exchanged between client and 1944 inject its own traffic in the mix, i.e. have man-in-the-middle 1945 capacity. In summary, the attack is very hard to mount, and the gain 1946 for the attacker in terms of "elevation of privilege" is minimal. 1948 A similar attack is described in detail in the security section of 1949 [RFC3489]. 1951 7.2.2 Attacker spoofing a Teredo relay 1953 An attacker may try to use Teredo to either pass itself for another 1954 IPv6 host, or place itself as a man-in-the-middle between a Teredo 1955 host and a native IPv6 host. The attacker will mount such attacks by 1956 spoofing a Teredo relay, i.e. by convincing the Teredo host that 1957 packets bound to the native IPv6 host should be relayed to the IPv4 1958 address of the attacker. 1960 The possibility of the attack derives from the lack of any 1961 algorithmic relation between the IPv4 address of a relay and the 1962 native IPv6 addresses served by these relay. A Teredo host cannot 1963 decide just by looking at the encapsulating IPv4 and UDP header 1964 whether a relay is legitimate or not. If a Teredo host decided to 1965 simply trust the incoming traffic, it would easily fall prey to a 1966 relay-spoofing attack. 1968 The attack is mitigated by the "Direct IPv6 connectivity test" 1969 specified in section 5.2.9. The test specifies a relay discovery 1970 procedure secured by a nonce. The nonce is transmitted from the 1971 Teredo host to the destination through Teredo server, which the 1972 client normally trusts. The response arrives through the "natural" 1973 relay, i.e. the relay closest to the IPv6 destination. Sending 1974 traffic to this relays will place it out of reach of attackers that 1975 are not on the direct path between the Teredo host and its IPv6 1976 peer. 1978 End-to-end security protections are required to defend against 1979 spoofing attacks if the attacker is on the direct path between the 1980 Teredo host and its peer. 1982 7.2.3 End-to-end security 1984 The most effective line of defense of a Teredo client is probably 1985 not to try to secure the Teredo service itself: even if the mapping 1986 can be securely obtained, the attacker would still be able to listen 1987 to the traffic and send spoofed packets. Rather, the Teredo client 1988 should realize that, because it is located behind a NAT, it is in a 1989 situation of vulnerability; it should systematically try to encrypt 1990 its IPv6 traffic, using IPsec. Even if the IPv4 and UDP headers are 1991 vulnerable, the use of IPsec will effectively prevent spoofing and 1992 listening of the IPv6 packets by third parties. By providing each 1993 client with a global IPv6 address, Teredo enables the use of IPsec 1994 without the configuration restrictions still present in the 1995 Negotiation of NAT-Traversal in IKE [RFC3947]and ultimately enhances 1996 the security of these clients. 1998 7.3 Denial of the Teredo service 2000 Our analysis outlines five ways to attack the Teredo service. There 2001 are counter-measures for each of these attacks. 2003 7.3.1 Denial of service by a rogue relay 2005 An attack can be mounted on the IPv6 side of the service by setting 2006 up a rogue relay, and letting that relay advertise a route to the 2007 Teredo IPv6 prefix. This is an attack against IPv6 routing, which 2008 can also be mitigated by the same kind of procedures used to 2009 eliminate spurious route advertisements. Dual stack nodes that 2010 implement "host local" Teredo relays are impervious to this attack. 2012 7.3.2 Denial of service by server spoofing 2014 In section 7.2, we discussed the use of spoofed router 2015 advertisements to insert an attacker in the middle of a Teredo 2016 conversation. The spoofed router advertisements can also be used to 2017 provision a client with an incorrect address, pointing to either a 2018 non-existing IPv4 address or to the IPv4 address of a third party. 2020 The Teredo client will detect the attack when it fails to receive 2021 traffic through the newly acquired IPv6 address. The attack can be 2022 mitigated by using the authentication encapsulation. 2024 7.3.3 Denial of service by exceeding the number of peers 2026 A Teredo client manages a cache of recently-used peers, which makes 2027 it stateful. It is possible to mount an attack against the client by 2028 provoking it to respond to packets that appear to come from a large 2029 number of Teredo peers, thus trashing the cache and effectively 2030 denying the use of direct communication between peers. The effect 2031 will only last as long as the attack is sustained. 2033 7.3.4 Attacks against the local discovery procedure 2035 There is a possible denial of service attack against the local peer 2036 discovery procedure, if attackers can manage to send spoofed local 2037 discovery bubbles to a Teredo client. The checks described in 2038 section 5.2.8 mitigate this attack. Clients who are more interested 2039 in security than in performance could decide to disable the local 2040 discovery procedure; however, if local discovery is disabled, 2041 traffic between local nodes will end up being relayed through a 2042 server external to the local network, which has questionable 2043 security implications. 2045 7.3.5 Attacking the Teredo servers and relays 2047 It is possible to mount a brute force denial of service attack 2048 against the Teredo servers by sending them a very large number of 2049 packets. This attack will have to be "brute force", since the 2050 servers are stateless, and can be designed to process all the 2051 packets that are sent on their access line. 2053 The brute force attack against the Teredo servers is mitigated if 2054 clients are ready to "failover" to another server. Bringing down the 2055 servers will however force the clients that change servers to 2056 renumber their Teredo address. 2058 It is also possible to mount a brute force attack against a Teredo 2059 relay. This attack is mitigated if the relay under attack stops 2060 announcing the reachability of the Teredo service prefix to the IPv6 2061 network: the traffic will be picked up by the next relay. 2063 An attack similar to 7.3.2 can be mounted against a relay. An IPv6 2064 host can send IPv6 packets to a large number of Teredo destinations, 2065 forcing the relay to establish state for each of these destinations. 2066 Teredo relays can obtain some protection by limiting the range of 2067 IPv6 clients that they serve, and by limiting the amount of state 2068 used for "new" peers. 2070 7.4 Denial of service against non-Teredo nodes 2072 There is a widely expressed concern that transition mechanisms such 2073 as Teredo can be used to mount denial of service attacks, by 2074 injecting traffic at locations where it is not expected. These 2075 attacks fall in three categories: using the Teredo servers as a 2076 reflector in a denial of service attack, using the Teredo server to 2077 carry a denial of service attack against IPv6 nodes, and using the 2078 Teredo relays to carry a denial of service attack against IPv4 2079 nodes. The analysis of these attacks follows. A common mitigating 2080 factor in all cases is the "regularity" of the Teredo traffic, which 2081 contains highly specific patterns such as the Teredo UDP port, or 2082 the Teredo IPv6 prefix. In case of attacks, these patterns can be 2083 used to quickly install filters and remove the offending traffic. 2085 We should also note that none of the listed possibilities offer any 2086 noticeable amplification. 2088 7.4.1 Laundering DoS attacks from IPv4 to IPv4 2090 An attacker can use the Teredo servers as reflectors in a denial of 2091 service attack aimed at an IPv4 target. The attacker can do this in 2092 one of two ways. The first way is to construct a Router Solicitation 2093 message and post it to a Teredo server, using as IPv4 source address 2094 the spoofed address of the target; the Teredo server will then send 2095 a Router advertisement message to the target. The second way is to 2096 construct a Teredo IPv6 address using the Teredo prefix, the address 2097 of a selected server, the IPv4 of the target, and an arbitrary UDP 2098 port, and to then send packets bound to that address to the selected 2099 Teredo server. 2101 Reflector attacks are discussed in [REFLECT], which outlines various 2102 mitigating techniques against such attacks. One of these mitigations 2103 is to observe that 'the traffic generated by the reflectors [has] 2104 sufficient regularity and semantics that it can be filtered out near 2105 the victim without the filtering itself constituting a denial-of- 2106 service to the victim ("collateral damage").' The traffic reflected 2107 by the Teredo servers meets this condition: it is clearly 2108 recognizable, since it originates from the Teredo UDP port; it can 2109 be filtered out safely if the target itself is not a Teredo user. In 2110 addition, the packets relayed by servers will carry an Origin 2111 indication encapsulation, which will help determining the source of 2112 the attack. 2114 7.4.2 DOS attacks from IPv4 to IPv6 2116 An attacker may use the Teredo servers to launch a denial of service 2117 attack against an arbitrary IPv6 destination. The attacker will 2118 build an IPv6 packet bound for the target, and will send that packet 2119 to the IPv4 address and UDP port of a Teredo server, to be relayed 2120 from there to the target over IPv6. 2122 The address checks specified in section 5.3.1 provide some 2123 protection against this attack, as they ensure that the IPv6 source 2124 address will be consistent with the IPv4 source address and UDP 2125 source port used by the attacker: if the attacker cannot spoof the 2126 IPv4 source address, the target will be able to determine the origin 2127 of the attack. 2129 The address checks ensure that the IPv6 source address of packets 2130 forwarded by servers will start with the IPv6 Teredo prefix. This is 2131 a mitigating factor, as sites under attack could use this to filter 2132 out all packets sourced from that prefix during an attack. This will 2133 result in a partial loss of service, as the target will not be able 2134 to communicate with legitimate Teredo hosts that use the same 2135 prefix; however, the communication with other IPv6 hosts will remain 2136 unaffected, and the communication with Teredo hosts will be able to 2137 resume when the attack has ceased. 2139 7.4.3 DOS attacks from IPv6 to IPv4 2141 An attacker with IPv6 connectivity may use the Teredo relays to 2142 launch a denial of service attack against an arbitrary IPv4 2143 destination. The attacker will compose a Teredo IPv6 address using 2144 the Teredo prefix, a "cone" flag set to 1, the IPv4 address of the 2145 target, and an arbitrary UDP port. 2147 In the simplest variation of this attack, the attacker sends IPv6 2148 packets to the Teredo destination using regular IPv6 routing. The 2149 packets are picked by the nearest relay, which will forward them to 2150 the IPv4 address of the target. In a more elaborate variant, the 2151 attacker tricks a Teredo into sending packets to the target, either 2152 by sending a first packet with a spoofed IPv6 address and letting 2153 the Teredo host reply, or by publishing a spoofed IPv6 address in a 2154 name service. 2156 There are three types of IPv4 addresses that an attacker may embed 2157 in the spoofed Teredo address. It may embed a multicast or broadcast 2158 address, an local unicast address, or a global unicast address. 2160 With multicast or broadcast addresses, the attacker can use the 2161 multiplying effect of multicast routing. By sending a single packet, 2162 it can affect a large number of hosts, in a way reminiscent of the 2163 "smurf" attack. 2165 By using local addresses, the attacker can reach hosts that are not 2166 normally reachable from the Internet, for example hosts connected to 2167 the a Teredo relay by a private subnet. This creates an exposure 2168 for, at a minimum, a denial of service attack against these 2169 otherwise protected host. This is similar to attack variants using 2170 source routing to breach a perimeter. 2172 The address checks specified in 5.2.4, 5.3.1 and 5.4.1 are verify 2173 that packets are only relayed to a global IPv4 address. They are 2174 designed to eliminate the possibility of using broadcast, multicast 2175 or local addresses in denial of service or other attacks. In what 2176 follows, we will only consider attacks targeting globally reachable 2177 unicast addresses. 2179 The attacks can be targeted at arbitrary UDP ports, such as for 2180 example the DNS port of a server. The UDP payload must be a well- 2181 formed IPv6 packet, and is thus unlikely to be accepted by any well- 2182 written UDP service; in most case, the only effect of the attack 2183 will be to overload the target with random traffic. 2185 A special case occurs if the attack is directed to an echo service. 2186 The service will echo the packets. Since the echo service sees the 2187 request coming from the IPv4 address of the relay, the echo replies 2188 will be sent back to the same relay. According to the rules 2189 specified in 5.4, these packets will be discarded by the Teredo 2190 relay. This is not a very efficient attack against the Teredo relays 2191 - establishing a legitimate session with an actual Teredo host would 2192 create more traffic. 2194 The IPv6 packets sent to the target contain the IPv6 address used by 2195 the attacker. If ingress filtering is used in the IPv6 network, this 2196 address will be hard to spoof. If ingress filtering is not used, the 2197 attacker can be traced if the IPv6 routers use a mechanism similar 2198 to ICMP Traceback. The ICMP messages will normally be collected by 2199 the same relays that forward the traffic from the attacker; the 2200 relays can use these messages to identify the source of an ongoing 2201 attack. The details of this solution will have to be developed in 2202 further research. 2204 8 IAB considerations 2206 The IAB has studied the problem of "Unilateral Self Address Fixing" 2207 (UNSAF), which is the general process by which a client attempts to 2208 determine its address in another realm on the other side of a NAT 2209 through a collaborative protocol reflection mechanism [RFC3424]. 2210 Teredo is an example of a protocol that performs this type of 2211 function. The IAB has mandated that any protocols developed for this 2212 purpose document a specific set of considerations. This section 2213 meets those requirements. 2215 8.1 Problem Definition 2217 From [RFC3424], any UNSAF proposal must provide a precise definition 2218 of a specific, limited-scope problem that is to be solved with the 2219 UNSAF proposal. A short term fix should not be generalized to solve 2220 other problems; this is why "short term fixes usually aren't". 2222 The specific problem being solved by Teredo is the provision of IPv6 2223 connectivity for hosts that cannot obtain IPv6 connectivity natively 2224 and cannot make use of 6to4 because of the presence of a NAT between 2225 them and the 6to4 relays. 2227 8.2 Exit Strategy 2229 From [RFC3424], any UNSAF proposal must provide the description of 2230 an exit strategy/transition plan. The better short term fixes are 2231 the ones that will naturally see less and less use as the 2232 appropriate technology is deployed. 2234 Teredo comes with its own built in exit strategy: as soon as a 2235 client obtains IPv6 connectivity by other means, either 6to4 or 2236 native IPv6, it can cease using the Teredo service. In particular, 2237 we expect that the next generation of home routers will provide an 2238 IPv6 service in complement to the current IPv4 NAT service, e.g. by 2239 relaying connectivity obtained from the ISP, or by using a 2240 configured or automatic tunnel service. 2242 As long as Teredo is used, there will be a need to support Teredo 2243 relays so that the remaining Teredo hosts can communicate with 2244 native IPv6 hosts. As Teredo usage declines, the traffic load on the 2245 relays will decline. Over time, managers will observe a reduce 2246 traffic load on their relays and will turn them off, effectively 2247 increasing the pressure on the remaining Teredo hosts to upgrade to 2248 another form of connectivity. 2250 The exit strategy is facilitated by the nature of Teredo, which 2251 provides an IP level solution. IPv6 aware applications do not have 2252 to be updated to use or not use Teredo. The absence of impact on the 2253 applications makes it easier to migrate out of Teredo: network 2254 connectivity suffices. 2256 There would appear to be reasons why a Teredo implementation might 2257 decide to continue usage of the Teredo service even if it already 2258 has obtained connectivity by some other means, for example: 2260 1. When a client is dual homed, and it wishes to improve the service 2261 when communicating with other teredo hosts that are "nearby" on the 2262 IPv4 network. If the client only used its native IPv6 service, the 2263 teredo hosts would be reached only through the relay. By maintaining 2264 teredo, the teredo hosts can be reached by direct transmission over 2265 IPv4. 2267 2. If, for some reason, the Teredo link is providing the client 2268 with better service than the native IPv6 link, in terms of 2269 bandwidth, packet loss, etc. 2271 The design of Teredo mitigates the dual-homing reason. A host that 2272 wishes to communicate with Teredo peers can implement an "host based 2273 relay", which is effectively an un-numbered Teredo interface. As 2274 such, the dual-homed host will obtain Teredo connectivity with those 2275 hosts that must use Teredo, but will not inadvertently encourage 2276 other dual homed hosts to keep using the Teredo service. 2278 The bubbles and the UDP encapsulation used by Teredo introduce a 2279 significant overhead. It would take exceptional circumstances for 2280 native technologies to provide a lesser service than Teredo. These 2281 exceptional circumstances, or other unforeseen reasons, may induce 2282 hosts to keep using the Teredo service despite the availability of 2283 native IPv6 connectivity. However, these circumstances are likely to 2284 be rare and transient. Moreover, if the primary reason to use Teredo 2285 fades away, one can expect that Teredo relays will be progressively 2286 turned off, and that the quality of the Teredo service will 2287 progressively degrade, reducing the motivation to use the Teredo 2288 service. 2290 8.3 Brittleness Introduced by Teredo 2292 From [RFC3424], any UNSAF proposal must provide a discussion of 2293 specific issues that may render systems more "brittle". For 2294 example, approaches that involve using data at multiple network 2295 layers create more dependencies, increase debugging challenges, and 2296 make it harder to transition. 2298 Teredo introduces brittleness into the system in several ways: the 2299 discovery process assumes a certain classification of devices based 2300 on their treatment of UDP; the mappings need to be continuously 2301 refreshed; and addressing structure may cause some hosts located 2302 behind a common NAT to be unreachable from each other. 2304 There are many similarities between these points and those 2305 introduced by STUN [RFC3489]; however, Teredo is probably somewhat 2306 less brittle than STUN. The reason is that all Teredo packets are 2307 sent from the local IPv4 teredo service port, including discovery, 2308 bubbles and actual encapsulated packets. This is different from 2309 STUN, where NAT type detection and binding allocation use different 2310 local ports (ephemeral, in both cases). 2312 Teredo assumes a certain classification of devices based on their 2313 treatment of UDP, e.g. cone, protected cone and symmetric. There 2314 could be devices that would not fit into one of these molds, and 2315 hence would be improperly classified by Teredo. 2317 The bindings allocated from the NAT need to be continuously 2318 refreshed. Since the timeouts for these bindings is very 2319 implementation specific, the refresh interval cannot easily be 2320 determined. When the binding is not being actively used to 2321 receive traffic, but to wait for an incoming message, the binding 2322 refresh will needlessly consume network bandwidth. 2324 The use of the Teredo server as an additional network element 2325 introduces another point of potential security attack. These 2326 attacks are largely prevented by the security measures provided by 2327 Teredo, but not entirely. 2329 The use of the Teredo server as an additional network element 2330 introduces another point of failure. If the client cannot locate a 2331 Teredo server, or if the server should be unavailable due to 2332 failure, the Teredo client will not be able to obtain IPv6 2333 connectivity. 2335 The communication with non Teredo hosts relies on the availability 2336 of Teredo relays. The Teredo design assumes that there are multiple 2337 Teredo relays; the Teredo service will discover the relay closest to 2338 the non-Teredo peer. If that relay becomes unavailable, or 2339 misbehaving, communication between the Teredo hosts and the peers 2340 close to that relay will fail. This reliability issue is somewhat 2341 mitigated by the possibility to deploy many relays, arbitrarily 2342 close from the native IPv6 hosts that require connectivity with 2343 Teredo peers. 2345 Teredo imposes some restrictions on the network topologies for 2346 proper operation. In particular, if the same NAT is on the path 2347 between two clients and the Teredo server, these clients will only 2348 be able to interoperate if they are connected to the same link, or 2349 if the common NAT is capable "hairpinning", i.e. "looping" packets 2350 sent by one client to another. 2352 There are also additional points of brittleness that are worth 2353 mentioning: 2355 - Teredo service will not work through NATs of the symmetric 2356 variety. 2358 - Teredo service depends on the Teredo server running on a network 2359 that is a common ancestor to all Teredo clients; typically this is 2360 the public Internet. If the teredo server is itself behind a NAT, 2361 teredo service will not work to certain peers 2363 - Teredo introduces jitter into the IPv6 service it provides, due to 2364 the queuing of packets while bubble exchanges take place. This 2365 jitter can negatively impact applications, particularly latency 2366 sensitive ones, such as VoIP. 2368 8.4 Requirements for a Long Term Solution 2370 From [RFC3424], any UNSAF proposal must identify requirements for 2371 longer term, sound technical solutions -- contribute to the process 2372 of finding the right longer term solution. 2374 Our experience with Teredo has led to the following requirements for 2375 a long term solution to the NAT problem: the devices that implement 2376 the IPv4 NAT services should in the future also become IPv6 routers. 2378 9 IANA Considerations 2380 This memo documents a request to IANA to allocate a 32 bit Teredo 2381 IPv6 service prefix, as specified in section 2.6, and a Teredo IPv4 2382 multicast address, as specified in section 2.17. 2384 10 Acknowledgements 2386 Many of the ideas in this memo are the result of discussions between 2387 the author and Microsoft colleagues, notably Brian Zill, John 2388 Miller, Mohit Talwar, Joseph Davies and Rick Rashid. Several 2389 encapsulation details are inspired from earlier work by Keith Moore. 2390 The example in section 5.1 and a number of security precautions were 2391 suggested by Pekka Savola. The local discovery procedure was 2392 suggested by Richard Draves and Dave Thaler. The document was 2393 reviewed by members of the NGTRANS and V6OPS working groups, 2394 including Brian Carpenter, Cyndi Jung, Keith Moore, Thomas Narten, 2395 Anssi Porttikivi, Pekka Savola, Eng Soo Guan, and Eiffel Wu. Eric 2396 Klein, Karen Nielsen, Francis Dupont, Markku Ala-Vannesluoma, Henrik 2397 Levkowetz and Jonathan Rosenberg provided detailed reviews during 2398 the IETF last call. 2400 11 References 2402 Normative references 2404 [RFC768] J. Postel, "User Datagram Protocol", RFC 768, August 1980. 2406 [RFC791] J. Postel, "Internet Protocol", RFC 791, September 1981. 2408 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 2409 April 1992. 2411 [RFC1918] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, 2412 E. Lear, "Address Allocation for Private Internets", RFC 1918, 2413 February 1996. 2415 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 2416 Requirement Levels", RFC 2119, March 1997. 2418 [RFC2460] S. Deering, R. Hinden, "Internet Protocol, Version 6 2419 (IPv6) Specification", RFC 2460, December 1998. 2421 [RFC2461] T. Narten, E. Nordmark, W. Simpson, "Neighbor Discovery 2422 for IP Version 6 (IPv6)", RFC 2461, December 1998. 2424 [RFC2462] T. Narten, S. Thomson, "IPv6 Stateless Address 2425 Autoconfiguration", RFC 2462, December 1998. 2427 [RFC3056] B. Carpenter, K. Moore, "Connection of IPv6 Domains via 2428 IPv4 Clouds", RFC 3056, February 2001. 2430 [RFC3068] C. Huitema, "An Anycast Prefix for 6to4 Relay Routers", 2431 RFC 3068, June 2001. 2433 [RFC3424] Daigle, L., Editor, "IAB Considerations for Unilateral 2434 Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 2435 3424, November 2002. 2437 [FIPS-180] "Secure Hash Standard", Computer Systems Laboratory, 2438 National Institute of Standards and Technology, U.S. Department Of 2439 Commerce, May 1993. 2441 Informative references 2443 [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 2444 Recommendations for Security", RFC 1750, December 1994. 2446 [RFC2402] Kent, S. and R. Atkinson. "IP Authentication Header", RFC 2447 2402, November 1998. 2449 [RFC2406] Kent, S. and R. Atkinson. "IP Encapsulating Security 2450 Payload (ESP)", RFC 2406, November 1998. 2452 [RFC2409] Harkins, D. and D. Carrel. "The Internet Key Exchange 2453 (IKE)", RFC 2409, November 1998. 2455 [RFC2993] T. Hain. "Architectural Implications of NAT", RFC 2993, 2456 November 2000. 2458 [RFC3330] IANA. "Special-Use IPv4 Addresses", RFC 3330, 2459 September 2002 2461 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy. 2462 "STUN - Simple Traversal of User Datagram Protocol (UDP) Through 2463 Network Address Translators (NATs)", RFC 3489, March 2003. 2465 [RFC3497] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe. 2466 "Negotiation of NAT-Traversal in the IKE", RFC 3497, January 2005 2468 [RFC3667] S. Bradner. "IETF Rights in Contributions", RFC 3667, 2469 February 2004 2471 [RFC3904] Huitema, C., Austein, R., Satapati, S. and R. van der Pol, 2472 "Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks", 2473 RFC 3905, September 2004. 2475 [SYNCHRO] S. Floyd, V. Jacobson, "The synchronization of periodic 2476 routing messages", ACM SIGCOMM'93 Symposium, September 1993. 2478 [REFLECT] V. Paxson, "An analysis of using reflectors for 2479 distributed denial of service attacks." Computer Communication 2480 Review, ACM SIGCOMM, Volume 31, Number 3, July 2001, pp 38-47. 2482 12 Authors' Addresses 2484 Christian Huitema 2485 Microsoft Corporation 2486 One Microsoft Way 2487 Redmond, WA 98052-6399 2489 Email: huitema@microsoft.com 2491 13 Intellectual Property Statement 2493 The IETF takes no position regarding the validity or scope of any 2494 Intellectual Property Rights or other rights that might be claimed 2495 to pertain to the implementation or use of the technology described 2496 in this document or the extent to which any license under such 2497 rights might or might not be available; nor does it represent that 2498 it has made any independent effort to identify any such rights. 2499 Information on the procedures with respect to rights in RFC 2500 documents can be found in BCP 78 and BCP 79. 2502 Copies of IPR disclosures made to the IETF Secretariat and any 2503 assurances of licenses to be made available, or the result of an 2504 attempt made to obtain a general license or permission for the use 2505 of such proprietary rights by implementers or users of this 2506 specification can be obtained from the IETF on-line IPR repository 2507 at http://www.ietf.org/ipr. 2509 The IETF invites any interested party to bring to its attention any 2510 copyrights, patents or patent applications, or other proprietary 2511 rights that may cover technology that may be required to implement 2512 this standard. Please address the information to the IETF at ietf- 2513 ipr@ietf.org. 2515 14 Copyright 2517 The following copyright notice is copied from [RFC3667], Section 2518 5.4. It describes the applicable copyright for this document. 2520 Copyright (C) The Internet Society (2005). This document is subject 2521 to the rights, licenses and restrictions contained in BCP 78, and 2522 except as set forth therein, the authors retain all their rights. 2524 This document and the information contained herein are provided on 2525 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2526 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 2527 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 2528 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2529 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2530 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.