idnits 2.17.00 (12 Aug 2021) /tmp/idnits24240/draft-thaler-v6ops-teredo-extensions-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance 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 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? -- The draft header indicates that this document updates RFC4380, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4380, updated by this document, for RFC5378 checks: 2003-06-09) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 10, 2010) is 4264 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) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Possible downref: Non-RFC (?) normative reference: ref. 'UPNPWANIP' Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations Working Group D. Thaler 3 Internet-Draft Microsoft 4 Updates: 4380 (if approved) September 10, 2010 5 Intended status: Standards Track 6 Expires: March 14, 2011 8 Teredo Extensions 9 draft-thaler-v6ops-teredo-extensions-08.txt 11 Abstract 13 This document specifies a set of extensions to the Teredo protocol. 14 These extensions provide additional capabilities to Teredo, including 15 support for more types of Network Address Translations (NATs), and 16 support for more efficient communication. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on March 14, 2011. 35 Copyright Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 3.1. Symmetric NAT Support Extension . . . . . . . . . . . . . 9 56 3.2. UPnP-Enabled Symmetric NAT Extension . . . . . . . . . . . 12 57 3.3. Port-Preserving Symmetric NAT Extension . . . . . . . . . 14 58 3.4. Sequential Port-Symmetric NAT Extension . . . . . . . . . 15 59 3.5. Hairpinning Extension . . . . . . . . . . . . . . . . . . 16 60 3.6. Server Load Reduction Extension . . . . . . . . . . . . . 18 61 4. Message Syntax . . . . . . . . . . . . . . . . . . . . . . . . 18 62 4.1. Trailers . . . . . . . . . . . . . . . . . . . . . . . . . 19 63 4.2. Nonce Trailer . . . . . . . . . . . . . . . . . . . . . . 19 64 4.3. Alternate Address Trailer . . . . . . . . . . . . . . . . 20 65 4.4. Neighbor Discovery Option Trailer . . . . . . . . . . . . 21 66 4.5. Random Port Trailer . . . . . . . . . . . . . . . . . . . 22 67 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 22 68 5.1. Common Processing . . . . . . . . . . . . . . . . . . . . 22 69 5.1.1. Refresh Interval . . . . . . . . . . . . . . . . . . . 23 70 5.1.2. Trailer Processing . . . . . . . . . . . . . . . . . . 23 71 5.2. Symmetric NAT Support Extension . . . . . . . . . . . . . 24 72 5.2.1. Abstract Data Model . . . . . . . . . . . . . . . . . 24 73 5.2.2. Timers . . . . . . . . . . . . . . . . . . . . . . . . 25 74 5.2.3. Initialization . . . . . . . . . . . . . . . . . . . . 25 75 5.2.4. Message Processing . . . . . . . . . . . . . . . . . . 25 76 5.3. UPnP-Enabled Symmetric NAT Extension . . . . . . . . . . . 26 77 5.3.1. Abstract Data Model . . . . . . . . . . . . . . . . . 26 78 5.3.2. Timers . . . . . . . . . . . . . . . . . . . . . . . . 27 79 5.3.3. Initialization . . . . . . . . . . . . . . . . . . . . 27 80 5.3.4. Message Processing . . . . . . . . . . . . . . . . . . 28 81 5.3.5. Shutdown . . . . . . . . . . . . . . . . . . . . . . . 29 82 5.4. Port-Preserving Symmetric NAT Extension . . . . . . . . . 30 83 5.4.1. Abstract Data Model . . . . . . . . . . . . . . . . . 30 84 5.4.2. Timers . . . . . . . . . . . . . . . . . . . . . . . . 31 85 5.4.3. Initialization . . . . . . . . . . . . . . . . . . . . 31 86 5.4.4. Message Processing . . . . . . . . . . . . . . . . . . 32 87 5.5. Sequential Port-Symmetric NAT Extension . . . . . . . . . 35 88 5.5.1. Abstract Data Model . . . . . . . . . . . . . . . . . 35 89 5.5.2. Timers . . . . . . . . . . . . . . . . . . . . . . . . 36 90 5.5.3. Initialization . . . . . . . . . . . . . . . . . . . . 36 91 5.5.4. Message Processing . . . . . . . . . . . . . . . . . . 36 92 5.6. Hairpinning Extension . . . . . . . . . . . . . . . . . . 38 93 5.6.1. Abstract Data Model . . . . . . . . . . . . . . . . . 38 94 5.6.2. Timers . . . . . . . . . . . . . . . . . . . . . . . . 39 95 5.6.3. Initialization . . . . . . . . . . . . . . . . . . . . 39 96 5.6.4. Message Processing . . . . . . . . . . . . . . . . . . 39 97 5.7. Server Load Reduction Extension . . . . . . . . . . . . . 40 98 5.7.1. Abstract Data Model . . . . . . . . . . . . . . . . . 40 99 5.7.2. Timers . . . . . . . . . . . . . . . . . . . . . . . . 41 100 5.7.3. Initialization . . . . . . . . . . . . . . . . . . . . 41 101 5.7.4. Message Processing . . . . . . . . . . . . . . . . . . 41 102 6. Protocol Examples . . . . . . . . . . . . . . . . . . . . . . 42 103 6.1. Symmetric NAT Support Extension . . . . . . . . . . . . . 42 104 6.2. UPnP-enabled Symmetric NAT Extension . . . . . . . . . . . 44 105 6.3. Port-Preserving Symmetric NAT Extension . . . . . . . . . 46 106 6.4. Sequential Port-Symmetric NAT Extension . . . . . . . . . 50 107 6.5. Hairpinning Extension . . . . . . . . . . . . . . . . . . 53 108 6.6. Server Load Reduction Extension . . . . . . . . . . . . . 55 109 7. Security Considerations . . . . . . . . . . . . . . . . . . . 56 110 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 57 111 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 112 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57 113 10.1. Normative References . . . . . . . . . . . . . . . . . . . 57 114 10.2. Informative References . . . . . . . . . . . . . . . . . . 58 115 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 58 117 1. Introduction 119 This document specifies extensions to the Teredo protocol, as 120 specified in [RFC4380]. These extensions provide additional 121 capabilities to Teredo, including support for more types of Network 122 Address Translations (NATs), and support for more efficient 123 communication. 125 2. Terminology 127 Because this document extends [RFC4380], it uses the following 128 terminology, for consistency with [RFC4380]. 130 Address-Restricted NAT: A restricted NAT that accepts packets from an 131 external host's IP address X and port Y if the internal host has sent 132 a packet that is destined to IP address X regardless of the 133 destination port. In the terminology of [RFC4787], this is a NAT 134 with Endpoint-Independent Mapping and Address-Dependent Filtering. 136 Address-Symmetric NAT: A symmetric NAT that has multiple external IP 137 addresses and that assigns different IP addresses and ports when 138 communicating with different external hosts. 140 Cone NAT: A NAT that maps all requests from the same internal IP 141 address and port to the same external IP address and port. 142 Furthermore, any external host can send a packet to the internal host 143 by sending a packet to the mapped external address and port. In the 144 terminology of [RFC4787], this is a NAT with Endpoint-Independent 145 Mapping and Endpoint-Independent Filtering. 147 Direct Bubble: A Teredo bubble that is sent directly to the IPv4 node 148 whose Teredo address is contained in the Destination field of the 149 IPv6 header, as specified in [RFC4380] section 2.8. The IPv4 150 Destination Address and UDP Destination Port fields contain a mapped 151 address/port. 153 Echo Test: A mechanism to predict the mapped address/port a 154 sequential port-symmetric NAT is using for a client behind it. 156 Hairpinning: A feature that is available in some NATs where two or 157 more hosts are positioned behind a NAT and each of those hosts is 158 assigned a specific external (public) address and port by the NAT. 159 Hairpinning support in a NAT allows these hosts to send a packet to 160 the external address and port that is assigned to one of the other 161 hosts, and the NAT automatically routes the packet back to the 162 correct host. The term hairpinning is derived from the behavior of 163 the packet, which arrives on, and is sent out to, the same NAT 164 interface. 166 Indirect Bubble: A Teredo bubble that is sent indirectly (via the 167 destination's Teredo server) to another Teredo client, as specified 168 in [RFC4380] section 5.2.4. 170 Local Address/Port: The IPv4 address and UDP port from which a Teredo 171 client sends Teredo packets. The local port is referred to as the 172 Teredo service port in [RFC4380]. The local address of a node may or 173 may not be globally routable because the node can be located behind 174 one or more NATs. 176 Mapped Address/Port: A global IPv4 address and a UDP port that 177 results from the translation of a node's own local address/port by 178 one or more NATs. The node learns these values through the Teredo 179 protocol as specified in [RFC4380]. For symmetric NATs, the mapped 180 address/port can be different for every peer with which a node tries 181 to communicate. 183 Network Address Translation (NAT): The process of converting between 184 IP addresses used within an intranet or other private network and 185 Internet IP addresses. 187 Nonce: A time-variant random value used in the connection setup phase 188 to prevent message replay and other types of attacks. 190 Peer: A Teredo client with which another Teredo client needs to 191 communicate. 193 Port-Preserving NAT: A NAT that translates a local address/port to a 194 mapped address/port such that the mapped port has the same value as 195 the local port, as long as that same mapped address/port has not 196 already been used for a different local address/port. 198 Port-Restricted NAT: A restricted NAT that accepts packets from an 199 external host's IP address X and port Y only if the internal host has 200 sent a packet destined to IP address X and port Y. In the terminology 201 of [RFC4787], this is a NAT with Endpoint-Independent Mapping and 202 Address and Port-Dependent Filtering. 204 Port-Symmetric NAT: A symmetric NAT that has only a single external 205 IP address and hence only assigns different ports when communicating 206 with different external hosts. 208 Private Address: An IPv4 address that is not globally routable but is 209 part of the private address space specified in [RFC1918] section 3. 211 Public Address: An external global address used by a NAT. 213 Restricted NAT: A NAT where all requests from the same internal IP 214 address and port are mapped to the same external IP address and port. 215 Unlike the cone NAT, an external host can send packets to an internal 216 host (by sending a packet to the external mapped address and port) 217 only if the internal host has first sent a packet to the external 218 host. There are two kinds of restricted NATs: address-restricted 219 NATs and port-restricted NATs. 221 Sequential Port-Symmetric NAT: A port-symmetric NAT that allocates 222 external ports sequentially for every {internal IP address and port, 223 destination IP address and port} tuple. The delta used in the 224 sequential assignment is typically 1 or 2 for most such NATs. 226 Symmetric NAT: A NAT where all requests from the same internal IP 227 address and port and to the same destination IP address and port, are 228 mapped to the same external IP address and port. Requests from the 229 same internal IP address and port to a different destination IP 230 address and port may be mapped to a different external IP address and 231 port. Furthermore, a symmetric NAT accepts packets received from an 232 external host's IP address X and port Y only if some internal host 233 has sent packets to IP address X and port Y. In the terminology of 234 [RFC4787], this is a NAT with a mapping behavior of either Address- 235 Dependent Mapping or Address- and Port-Dependent Mapping, and a 236 filtering behavior of either Address-Dependent Filtering or Address- 237 and Port-Dependent Filtering. 239 Teredo Bubble: A Teredo control message (specified in [RFC4380] 240 section 2.8) that is used to create a mapping in a NAT. There are 241 two types of Teredo bubbles: direct bubbles and indirect bubbles. 243 Teredo Client: A node that has access to the IPv4 Internet and wants 244 to gain access to the IPv6 Internet using the Teredo protocol. 246 Teredo IPv6 Address: An IPv6 address of a Teredo client, as specified 247 in [RFC4380] section 2.14. 249 Teredo Secondary Server Address: A secondary IPv4 address of a Teredo 250 server with which a Teredo client is configured, as specified in 251 [RFC4380] section 5.2. 253 Teredo Server: A node that has a globally routable address on the 254 IPv4 Internet, and is used as a helper to provide IPv6 connectivity 255 to Teredo clients. 257 Teredo Server Address: A (primary) IPv4 address of a Teredo server 258 with which a Teredo client is configured, as specified in [RFC4380] 259 section 5.2. 261 UPnP-enabled NAT: A NAT that has the UPnP device control protocol 262 enabled, as specified in [UPNPWANIP]. (Note that today, by default, 263 most UPnP-capable NATs have the UPnP device control protocol 264 disabled.) 266 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 267 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 268 document are to be interpreted as described in RFC 2119 [RFC2119]. 270 3. Overview 272 The Teredo protocol (as specified in [RFC4380]) enables nodes located 273 behind one or more IPv4 NATs to obtain IPv6 connectivity by tunneling 274 packets over UDP. 276 When a node behind a NAT needs to communicate with a peer (i.e., 277 another node) that is behind a NAT, there are four sets of IPv4 278 address/port pairs of interest: 279 o The node's own IPv4 address/port. 280 o The external IPv4 address/port to which the node's NAT translates. 281 o The peer's own IPv4 address/port. 282 o The external IPv4 address/port to which the peer's NAT translates. 284 When the node sends a packet to a peer, the node needs to send it 285 from the node's own IPv4 address/port, destined to the peer's 286 external IPv4 address/port. By the time it arrives at the peer 287 (i.e., after passing through both NATs), the peer will see the same 288 packet as coming from the node's external IPv4 address/port, destined 289 to the peer's own IPv4 address/port. 291 In this document, the term local address/port refers to a Teredo 292 client's own IPv4 address/port; and mapped address/port refers to the 293 external IPv4 address/port to which its NAT translates the local 294 address/port. That is, the mapped address/port is what the IPv4 295 Internet sees the Teredo client as. 297 A Teredo client running on a node communicates with a Teredo server 298 to discover its mapped address/port. The mapped address/port, along 299 with the Teredo server address, are used to generate an IPv6 address 300 known as a Teredo IPv6 address. This allows any peer that gets the 301 node's IPv6 address to easily determine the external IPv4 address/ 302 port to which to send IPv6 packets encapsulated in IPv4 UDP messages. 304 This document specifies extensions to the Teredo protocol. These 305 Teredo extensions are independent of each other and can be 306 implemented in isolation, except that the UPnP-Symmetric NAT 307 Extension and the Port-Preserving Symmetric NAT Extension both 308 require the Symmetric NAT Support Extension to be implemented. An 309 implementation of this specification can support any combination of 310 the Teredo extensions, subject to the above-mentioned restriction. 312 The following matrix outlines the connectivity improvements of some 313 of the extensions outlined in this document. 315 Destination NAT 316 | | | | | | Port-| | | 317 | | | | UPnP | UPnP | pres.| Seq. | | 318 | | Addr.| Port | Port | Port | Port-| Port-| Port-| Addr 319 Source NAT| Cone | rest.| rest.| rest.| symm.| symm.| symm.| symm.| symm 320 ----------+------+------+------+------+------+------+------+------+----- 321 Cone | Yes | Yes | Yes | Yes | SNS | SNS | SNS | SNS | SNS 322 ----------+------+------+------+------+------+------+------+------+----- 323 Address | Yes | Yes | Yes | Yes | SNS | SNS | SNS | SNS | No 324 restricted| | | | | | | | | 325 ----------+------+------+------+------+------+------+------+------+----- 326 Port | Yes | Yes | Yes | Yes | No | SNS+ | SNS+ | No | No 327 restricted| | | | | | PP | SS | | 328 ----------+------+------+------+------+------+------+------+------+----- 329 UPnP Port-| Yes | Yes | Yes | Yes | SNS+ | No | No | No | No 330 restricted| | | | | UPnP | | | | 331 ----------+------+------+------+------+------+------+------+------+----- 332 UPnP Port | SNS | SNS | No | SNS+ | SNS+ | No | No | No | No 333 symmetric | | | | UPnP | UPnP | | | | 334 ----------+------+------+------+------+------+------+------+------+----- 335 Port- | | | SNS | | | SNS | SNS | | 336 preserving| SNS | SNS | + | No | No | + | + | No | No 337 Port- | | | PP | | | PP | SS | | 338 symmetric | | | | | | | | | 339 ----------+------+------+------+------+------+------+------+------+----- 340 Sequential| | | SNS | | | | | | 341 Port- | SNS | SNS | + | No | No | No | No | No | No 342 symmetric | | | SS | | | | | | 343 ----------+------+------+------+------+------+------+------+------+----- 344 Port- | SNS | SNS | No | No | No | No | No | No | No 345 symmetric | | | | | | | | | 346 ----------+------+------+------+------+------+------+------+------+----- 347 Address- | SNS | No | No | No | No | No | No | No | No 348 symmetric | | | | | | | | | 349 ----------+------+------+------+------+------+------+------+------+----- 351 Yes = Supported by [RFC4380]. 353 SNS = Supported with the Symmetric NAT Support Extension. 355 SNS+UPnP = Supported with the Symmetric NAT Support Extension and UPnP 356 Symmetric NAT Extension. 358 SNS+PP = Supported with the Symmetric NAT Support Extension and Port- 359 Preserving Symmetric NAT Extension. 361 SNS+SS = Supported with the Symmetric NAT Support Extension and 362 Sequential Port-Symmetric NAT Extension. 364 No = No connectivity. 366 Matrix of Connectivity Improvements for Teredo Extensions 368 Figure 1 370 Note that as with [RFC4380], if the qualification process is not 371 successful, Teredo will not be configured with an IPv6 address, and 372 connectivity will function as if Teredo were not present. Similarly, 373 for any combination of NAT types that are not supported by Teredo and 374 the extensions defined herein, the connectivity tests between a 375 client and a peer will fail within a finite period of time, allowing 376 the client to handle this case as with any other type of unreachable 377 destination address (e.g., by trying another address of the 378 destination such as a native IPv4 address). 380 3.1. Symmetric NAT Support Extension 382 The qualification procedure (as specified in [RFC4380] section 5.2.1) 383 is a process that allows a Teredo client to determine the type of NAT 384 that it is behind, in addition to its mapped address/port as seen by 385 its Teredo server. However, [RFC4380] section 5.2.1 suggests that if 386 the client learns it is behind a symmetric NAT, the Teredo client 387 should go into an "offline state" where it is not able to use Teredo. 388 The primary reason for doing so is that it is not easy for Teredo 389 clients to connect to each other if either or both of them are 390 positioned behind a symmetric NAT. Because of the way a symmetric 391 NAT works, a peer sees a different mapped address/port in the IPv4/ 392 UDP headers of packets coming from a Teredo client than the node's 393 Teredo server sees (and hence appears in the node's Teredo IPv6 394 address). Consequently, a symmetric NAT does not allow incoming 395 packets from a peer that are addressed to the mapped address/port 396 embedded in the node's Teredo IPv6 address. Thus, the incoming 397 packets are dropped and communication with Teredo client behind 398 symmetric NATs is not established. 400 With the Symmetric NAT Support Extension, Teredo clients begin to use 401 Teredo even after they detect that they are positioned behind a 402 symmetric NAT. 404 Consider the topology shown in Figure 2. Teredo Client B uses Teredo 405 Server 2 to learn that its mapped address/port is 192.0.2.10:8192, 406 and constructs a Teredo IPv6 address, as specified in [RFC4380] 407 section 4. Hence, C633:6476 is the hexadecimal value of the address 408 of Teredo Server 2 (198.51.100.118), the mapped port is exclusive- 409 OR'ed with 0xFFFF to form DFFF, and the Mapped Address is exclusive- 410 OR'ed with 0xFFFFFFFF to form 3FFF:FDF5. 412 Teredo Client A uses Teredo Server 1 to learn that its mapped 413 address/port is 192.0.2.1:4096 and, with this extension, constructs a 414 Teredo IPv6 address (as specified in [RFC4380] section 4) even though 415 it learns that it is behind a symmetric NAT. Hence, CB00:7178 is the 416 hexadecimal value of the address of Teredo Server 1 (203.0.113.120), 417 the mapped port is exclusive-OR'ed with 0xFFFF to form EFFF, and the 418 Mapped Address is exclusive-OR'ed with 0xFFFFFFFF to form 3FFF:FDFE. 420 The Symmetric NAT Support Extension enables a Teredo client 421 positioned behind a symmetric NAT to communicate with Teredo peers 422 positioned behind a cone or address-restricted NATs as follows, 423 depending on what side initiates the communication. 425 -------------------------------------------- 426 / \ 427 < IPv6 Internet > 428 \ / 429 -|----------------------------------------|- 430 | | 431 +----------+ +----------+ 432 | Teredo | | Teredo | 433 | Server 1 | | Server 2 | 434 +----------+ +----------+ 435 203.0.113.120| 198.51.100.118| 436 -|----------------------------------------|- 437 / \ 438 < IPv4 Internet > 439 \ / 440 -|----------------------------------------|- 441 192.0.2.1| 192.0.2.10| 442 UDP port 4096| UDP port 8192| 443 +---------+ +----------+ 444 |Symmetric| |Other type| 445 | NAT | | of NAT | 446 +---------+ +----------+ 447 | | 448 +-----------------+ +-----------------+ 449 | Teredo client A | | Teredo client B | 450 +-----------------+ +-----------------+ 451 2001:0:CB00:7178:0:EFFF:3FFF:FDFE 2001:0:C633:6476:0:DFFF:3FFF:FDF5 452 Teredo Address Teredo Address 454 Symmetric NAT example 456 Figure 2 458 In the first case, assume that a Teredo Client B (B) positioned 459 behind a cone or address-restricted NATs, initiates communication 460 with Teredo Client A (A) positioned behind a symmetric NAT. B sends 461 an indirect bubble via A's server (Teredo Server 1) to A, and A 462 responds with a direct bubble. This direct bubble reaches B, because 463 it is positioned behind a cone or address-restricted NAT. However, 464 the mapped address/port in the IPv4/UDP headers of the direct bubble 465 are different from the mapped address/port embedded in A's Teredo 466 IPv6 address. B therefore remembers the mapped address/port of the 467 direct bubble and uses them for future communication with A, and thus 468 communication is established. 470 In the second case, assume that A, positioned behind a symmetric NAT, 471 initiates communication with B, positioned behind a cone or address- 472 restricted NAT. A sends an indirect bubble to B via B's server 473 (Teredo Server 2), and B responds with a direct bubble. This direct 474 bubble is dropped by A's symmetric NAT because the direct bubble is 475 addressed to the mapped address/port embedded in A's Teredo IPv6 476 address. However, communication can be established by having B 477 respond with an indirect bubble via A's server (Teredo Server 1). 478 Now the scenario is similar to the first case and communication will 479 be established. 481 3.2. UPnP-Enabled Symmetric NAT Extension 483 The UPnP-enabled Symmetric NAT Extension is dependent on the 484 Symmetric NAT Support Extension. Only if Teredo clients have been 485 enabled to acquire a Teredo IPv6 address in spite of being behind a 486 symmetric NAT, will this extension help in traversing UPnP-enabled 487 Symmetric NATs. 489 The Symmetric NAT Support Extension enables communication between 490 Teredo clients behind symmetric NATs with Teredo clients behind cone 491 NATs or address-restricted NATs. However, clients behind symmetric 492 NATs can still not communicate with clients behind port-restricted 493 NATs or symmetric NATs. 495 Referring again to Figure 2 (see Section 3.1), assume that Teredo 496 Client A is positioned behind a symmetric NAT and initiates 497 communication with Client B, which is positioned behind a port- 498 restricted NAT. Client A sends a direct bubble and an indirect 499 bubble to Client B via Client B's server (Teredo Server 2). As per 500 the characteristics of the symmetric NAT, the IPv4 source of the 501 direct bubble contains a different mapped address and/or port than 502 the one embedded in the Teredo server. This direct bubble is dropped 503 because Client B's NAT does not have state to let it pass through, 504 and Client B does not learn the mapped address/port used in the IPv4/ 505 UDP headers. In response to the indirect bubble from Client A, 506 Client B sends a direct bubble destined to the mapped address/port 507 embedded in Client A's Teredo IPv6 address. This direct bubble is 508 dropped because Client A's NAT does not have state to accept packets 509 destined to that mapped address/port. The direct bubble does, 510 however, cause Client B's NAT to set up outgoing state for the mapped 511 address/port embedded in Client A's Teredo IPv6 address. 513 As described in Section 3.1, Client B also sends an indirect bubble 514 that elicits a direct bubble from Client A. Unlike the case in 515 Section 3.1, however, the direct bubble from Client A is dropped as 516 Client B's NAT does not have state for the mapped address/port that 517 Client A's NAT uses. Note that Client B's NAT is port-restricted and 518 hence requires both the mapped address and port to be the same as in 519 its outgoing state, whereas in Section 3.1, Client A's NAT was a cone 520 or address-restricted NAT which only required the mapped address (but 521 not port) to be the same. Thus, communication between Client A and 522 Client B fails. If Client B were behind a symmetric NAT, the problem 523 is further complicated by Client B's NAT using a different outgoing 524 mapped address/port than the one embedded in Client B's Teredo IPv6 525 address. 527 If a Teredo client is separated from the global Internet by a single 528 UPnP-enabled symmetric or port-restricted NAT, it can communicate 529 with other Teredo clients that are positioned behind a single UPnP- 530 enabled symmetric or port-restricted NAT as follows: 532 Teredo clients, before communicating with the Teredo server during 533 the qualification procedure, use UPnP to reserve a local address/port 534 to mapped address/port translation. Therefore, during the 535 qualification procedure, the Teredo server reflects back the reserved 536 mapped address/port, which then is included in the Teredo IPv6 537 address. The mapping created by UPnP allows the NAT to forward 538 packets destined for the mapped address/port to the local address/ 539 port, independent of the source of the packets. It typically does 540 not, however, cause packets sourced from the local address/port to be 541 translated to have the mapped address/port as the external source and 542 hence continues to function as a symmetric NAT in this respect. 544 Thus, a Teredo client, positioned behind a UPnP-enabled symmetric 545 NAT, can receive a direct bubble sent by any Teredo peer. The Teredo 546 client compares the peer's mapped address/port as seen in the IPv4/ 547 UDP headers with the mapped address/port in the peer's Teredo IPv6 548 address. If the two mappings are different, the packet was sent by 549 another Teredo client positioned behind a symmetric NAT. The 550 Symmetric NAT Support Extension suggested that the Teredo client use 551 the peer's mapped address/port seen in the IPv4/UDP headers for 552 future communication. However, because symmetric NAT-to-symmetric 553 NAT communication would not have been possible anyway, the Teredo 554 client sends back a direct bubble to the mapped port/address embedded 555 in the peer's Teredo IPv6 address. If the peer is also situated 556 behind a UPnP-enabled NAT, the direct bubble will make it through and 557 communication will be established. 559 Even though communication is established between the two Teredo IPv6 560 addresses, the mappings will be asymmetric in the two directions of 561 data transfer. Specifically, incoming packets will be destined to 562 the reserved mapped address/port which is embedded in the Teredo IPv6 563 address. Outgoing packets will instead appear to come from a 564 different mapped address/port due to the symmetric NAT behavior. 566 3.3. Port-Preserving Symmetric NAT Extension 568 The Port-Preserving Symmetric NAT Extension is dependent on the 569 Symmetric NAT Support Extension (Section 3.1). Only if Teredo 570 clients have been enabled to acquire a Teredo IPv6 address in spite 571 of being behind a symmetric NAT will this extension help in 572 traversing port-preserving symmetric NATs. 574 The Symmetric NAT Support Extension enables communication between 575 Teredo clients behind symmetric NATs with Teredo clients behind cone 576 NATs or address-restricted NATs. However, clients behind symmetric 577 NATs can still not communicate with clients behind port-restricted or 578 symmetric NATs, as described in Section 3.2. Note that the Port- 579 Preserving Symmetric NAT Extension described here is independent of 580 the UPnP-enabled Symmetric NAT Extension, described in Section 3.2. 582 If a Teredo client is positioned behind a port-preserving symmetric 583 NAT, the client can communicate with other Teredo clients positioned 584 behind a port-restricted NAT or a port-preserving symmetric NAT as 585 follows. 587 Teredo clients compare the mapped port learned during the 588 qualification procedure with their local port to determine if they 589 are positioned behind a port-preserving NAT. If both the mapped port 590 and the local port have the same value, the Teredo client is 591 positioned behind a port-preserving NAT. At the end of the 592 qualification procedure, the Teredo client also knows if it is 593 positioned behind a symmetric NAT, as described in Section 3.1. 595 Teredo clients positioned behind port-preserving symmetric NATs can 596 also listen on randomly chosen local ports. If the randomly chosen 597 local port has not been used by the symmetric NAT as a mapped port in 598 a prior port-mapping, the NAT uses the same port number as the mapped 599 port. Thus, the challenge is to get the first direct bubble sent out 600 from the random port to be destined to a valid destination address 601 and port. When the mapped address/port is embedded in the 602 destination's Teredo IPv6 address, this is easy. 604 The communication setup is more complicated when the destination 605 Teredo client is also positioned behind a port-preserving symmetric 606 NAT. In such a case, both Teredo clients need to send their first 607 direct bubbles to the correct destination mapped address/port. Thus 608 the protocol messages, which communicate one Teredo client's random 609 port number to the other Teredo client, must be exchanged indirectly 610 (via Teredo servers). When one Teredo client has access to the other 611 Teredo client's random port number, it can send a direct bubble 612 destined to the mapped address embedded in the destination's Teredo 613 IPv6 address, and the mapped port can be the same as the 614 destination's random port number. If both NATs are port-preserving, 615 port-preserved mappings are created on both NATs and the second 616 direct bubble succeeds in reaching the destination. 618 3.4. Sequential Port-Symmetric NAT Extension 620 The Sequential Port-Symmetric NAT Extension is dependent on the 621 Symmetric NAT Support Extension (Section 3.1). This extension helps 622 in traversing a sequential port-symmetric NAT only if Teredo clients 623 are enabled to acquire a Teredo IPv6 address even when behind a 624 symmetric NAT. 626 When the Sequential Port-Symmetric NAT Extension is used, if a Teredo 627 client is positioned behind a sequential port-symmetric NAT, the 628 client can communicate with other Teredo clients that are positioned 629 behind a port-restricted NAT as follows. 631 During qualification, if the client discovers it is behind a 632 symmetric NAT that is not port-preserving, the client assumes by 633 default that it is behind a sequential port-symmetric NAT. This 634 assumption is proactive for the following reasons: 635 o There is no perfect method of discovering whether the client is 636 behind a sequential port-symmetric NAT. 637 o These kinds of NATs are notorious for changing their behavior. At 638 times they could be sequential port-symmetric and at other times 639 not. 640 o There is no other solution for symmetric NAT traversal so this is 641 a last resort. 643 Teredo clients positioned behind sequential port-symmetric NATs can 644 also listen on a randomly chosen local port when communicating with a 645 peer. To predict the external port being used for a given peer, the 646 client sends three packets: 647 o Packet 1 is a router solicitation (as specified in [RFC4380] 648 section 5.2.1) sent to the Teredo server address. 649 o Packet 2 is a direct bubble sent to the peer. 650 o Packet 3 is a router solicitation sent to the secondary Teredo 651 server address. 653 As part of the normal Teredo protocol, the Teredo server responds to 654 packets 1 and 3. Based on the information in the responses, the 655 client now knows that packet 1 was seen as coming from one external 656 port, and packet 3 was seen as coming from another external port. 657 Assuming the NAT is a sequential port-symmetric NAT, the external 658 port for packet 2 is estimated (or predicted) to be midway between 659 the external ports for packets 1 and 3. Note that because other 660 applications might also have been using the NAT between packets 1 and 661 3, the actual port might not be exactly the midpoint. 663 The Teredo client then communicates the predicted port to its peer, 664 which sends a direct bubble to the communicated port. If the 665 communicated port is indeed the external port for packet 2, the 666 direct bubble will reach the Teredo client. 668 3.5. Hairpinning Extension 670 Hairpinning support in a NAT routes packets that are sent from a 671 private (local) address destined to a public (mapped) address of the 672 NAT, back to another private (local) destination address behind the 673 same NAT. If hairpinning support is not available in a NAT, two 674 Teredo clients behind the same NAT are not able to communicate with 675 each other, as specified in [RFC4380] section 8.3. 677 The Hairpinning Extension enables two clients behind the same NAT to 678 talk to each other when the NAT does not support hairpinning. This 679 process is illustrated in the following diagram. 681 -------------------------------------------- 682 / \ 683 < IPv6 Internet > 684 \ / 685 --------------------|----------------------- 686 | 687 +----------+ 688 | Teredo | 689 | Server | 690 +----------+ 691 203.0.113.120| 692 --------------------|----------------------- 693 / \ 694 < IPv4 Internet > 695 \ / 696 --------------------|----------------------- 697 198.51.100.118| 698 NAT +-------+ 699 without | NAT | 700 hairpinning | E | 701 support +-------+ 702 | 703 +------------------+--------------------+ 704 192.168.1.0| 192.168.1.1| 705 UDP port 4095| UDP port 4096| 706 +---------+ +----------+ 707 | NAT | | NAT | 708 | F | | G | 709 +---------+ +----------+ 710 | | 711 +-----------------+ +-----------------+ 712 | Teredo client A | | Teredo client B | 713 +-----------------+ +-----------------+ 714 2001:0:CB00:7178:0:F000:39CC:9B89 2001:0:CB00:7178:0:EFFF:39CC:9B89 715 Teredo Address Teredo Address 717 Hairpinning example 719 Figure 3 721 The Teredo Client A (A) includes, as part of its indirect bubble sent 722 to Teredo Client B (B), its local address/port. B, upon receiving 723 the indirect bubble, tries to establish communication by sending 724 direct bubbles to the mapped address/port of A, and also to the local 725 address/port of B. 727 If a Teredo client is part of a multi-NAT hierarchy and the NAT to 728 which the Teredo client is connected supports the UPnP protocol (as 729 specified in [UPNPWANIP]), the Teredo client can use UPnP to 730 determine the mapped address/port assigned to it by the NAT. This 731 information can be included along with the local address/port when 732 sending the indirect bubble. The destination Teredo client now tries 733 to establish a connection by sending direct bubbles to the mapped 734 address/port in the Teredo IPv6 address, to the local address/port 735 included in the bubble, and also to the mapped address/port included 736 in the bubble. 738 Note that UPnP support is only required if the Teredo clients are 739 behind different NATs in a multi-NAT hierarchy. Without UPnP 740 support, the Hairpinning Extension still allows two hosts behind the 741 same non-hairpinning NAT to communicate using their Teredo IPv6 742 addresses. 744 3.6. Server Load Reduction Extension 746 If communication between a Teredo client and a Teredo peer was 747 successfully established but at a later stage was silent for a while, 748 for efficiency it is best to refresh the mapping state in the NATs 749 that are positioned between them. To refresh the communication 750 between itself and a Teredo peer, a Teredo client needs to solicit a 751 direct bubble response from the Teredo peer. An indirect bubble is 752 sent to solicit a direct bubble response from a Teredo peer, as 753 specified in [RFC4380] section 5.2.4. However, these indirect 754 bubbles increase the load on the Teredo server. 756 The Server Load Reduction Extension allows Teredo clients to send 757 direct bubbles most of the time instead of sending indirect bubbles 758 all of the time in the following way: 759 1. When a Teredo client tries to refresh its communication with a 760 Teredo peer, it uses a direct bubble instead of an indirect 761 bubble. However, because direct bubbles do not normally solicit 762 a response, the direct bubble format is extended to be able to 763 solicit a response. 764 2. When a Teredo client receives a direct bubble that is soliciting 765 a response, the Teredo client responds with a direct bubble. 766 3. If attempts to reestablish communication with the help of direct 767 bubbles fail, the Teredo client starts over the process of 768 establishing communication with the Teredo peer, as specified in 769 [RFC4380] section 5.2.4. 771 4. Message Syntax 773 All Teredo messages are transported over the User Datagram Protocol 774 (UDP), as specified in [RFC4380] section 3. 776 In addition, [RFC4380] section 5.2.3 states: 777 An IPv6 packet is deemed valid if it conforms to [RFC2460]: the 778 protocol identifier should indicate an IPv6 packet and the payload 779 length should be consistent with the length of the UDP datagram in 780 which the packet is encapsulated. In addition, the client should 781 check that the IPv6 destination address correspond to its own 782 Teredo address. 784 This document updates the word "consistent" above as follows. The 785 IPv6 payload length is "consistent" with the length of the UDP 786 datagram if the IPv6 packet length (i.e., the Payload Length value in 787 the IPv6 header plus the IPv6 header size) is less than or equal to 788 the UDP payload length (i.e., the Length value in the UDP header 789 minus the UDP header size). This allows the use of trailers after 790 the IPv6 packet, which are defined in the following sections. 792 4.1. Trailers 794 Teredo packets can carry a variable number of type-length-value (TLV) 795 encoded trailers, of the following format (intended to be similar to 796 the use of IPv6 options defined in [RFC2460] section 4.2): 798 1 2 3 799 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | Type | Length | Value (variable) | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 Type (1 byte): 8-bit identifier of the type of trailer. 806 Length (1 byte): 8-bit unsigned integer. Length of the Value field 807 of this trailer, in octets. 809 Value (variable): Trailer Type-specific data. 811 The trailer Type identifiers are internally encoded such that their 812 highest-order two bits specify the action that is to be taken if the 813 host does not recognize the trailer Type: 815 00, 10, 11 - skip over this trailer and continue processing the 816 packet. 817 01 - discard the packet. 819 4.2. Nonce Trailer 821 The Nonce Trailer is used by the Symmetric NAT Support Extension (and 822 therefore the UPnP-enabled Symmetric NAT Extension and Port- 823 Preserving Symmetric NAT Extension also) and the Hairpinning 824 Extension. The Nonce Trailer can be present in both indirect and 825 direct bubbles. The nonce in the Nonce Trailer helps authenticate a 826 Teredo client positioned behind a Symmetric NAT. 828 1 2 3 829 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | Type | Length | Nonce | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | ... | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 Type (1 byte): The Trailer Option type. This field MUST be set to 837 0x01. 839 Length (1 byte): The length in bytes of the rest of the option. This 840 field MUST be set to 0x04. 842 Nonce (4 bytes): The Nonce value. 844 4.3. Alternate Address Trailer 846 The Alternate Address Trailer is used by the Hairpinning Extension. 847 The Alternate Address Trailer MUST NOT be present in any packets 848 other than indirect bubbles sent by a Teredo client. The Alternate 849 Address Trailer provides another Teredo client positioned behind the 850 same NAT with more address options that it can use to connect. 852 1 2 3 853 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | Type | Length | Reserved | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | | 858 | Alternate Address/Port List (variable) | 859 | | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 Type (1 byte): The Trailer Option type. This field MUST be set to 863 0x03. 865 Length (1 byte): The length in bytes of the rest of the option. The 866 value of this field MUST be in the range 8 to 26 (i.e., 2 bytes for 867 the Reserved field, and 6 bytes for each entry in the Alternate 868 Address/Port List). This allows for a minimum of one address/port 869 mapping and a maximum of four address/port mappings to be advertised. 870 It SHOULD be at most 14 as a maximum of two address/port mappings can 871 be determined by Teredo: one local address/port and one obtained 872 using UPnP. Because the length of the alternate address/port is 6 873 bytes, the valid range of values is only 8, 14, 20 and 26. 875 Reserved (2 bytes): This field MUST be set to 0x0000 and ignored on 876 receipt. 878 Alternate Address/Port List (variable): An array of additional 879 address/port pairs that can be used by other Teredo clients to 880 communicate with the sender. Each alternate address/port entry MUST 881 be formatted as follows: 883 1 2 3 884 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | IPv4 Address | 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | Port | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 IPv4 Address (4 bytes): An IPv4 address in network byte order. This 892 field MUST contain a valid unicast address. 894 Port (2 bytes): A port number in network byte order. This field MUST 895 NOT be zero. 897 4.4. Neighbor Discovery Option Trailer 899 The Neighbor Discovery Option Trailer is used by the Server Load 900 Reduction Extension because it allows direct bubbles to encode an 901 IPv6 Neighbor Solicitation ([RFC4861] section 4.3), in addition to an 902 IPv6 Neighbor Advertisement ([RFC4861] section 4.4). This allows 903 packets to be sent without having to relay them through a Teredo 904 server. The Neighbor Discovery Option Trailer allows the receiver to 905 differentiate between a direct bubble that is soliciting a response 906 versus a regular direct bubble. This allows Teredo clients to use 907 direct bubbles to refresh inactive connections instead of using 908 indirect bubbles. 910 1 2 3 911 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | Type | Length | DiscoveryType | Reserved | 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | ... | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 Type (1 byte): The Trailer Option type. This field MUST be set to 919 0x04. 921 Length (1 byte): The length in bytes of the rest of the option. This 922 field MUST be set to 0x04. 924 DiscoveryType (1 byte): This field MUST be set to one of the 925 following values: 927 TeredoDiscoverySolicitation (0x00): The receiver is requested to 928 respond with a direct bubble of DiscoveryType 929 TeredoDiscoveryAdvertisement. 931 TeredoDiscoveryAdvertisement (0x01): The direct bubble is in response 932 to a direct bubble or an indirect bubbles containing DiscoveryType 933 TeredoDiscoverySolicitation. 935 Reserved (3 bytes): This field MUST be set to 0x000000 on 936 transmission and ignored on receipt. 938 4.5. Random Port Trailer 940 The Random Port Trailer is used by the Port-Preserving Symmetric NAT 941 Extension in both indirect and direct bubbles. 943 1 2 3 944 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | Type | Length | Random Port | 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 Type (1 byte): The Trailer Option type. This field MUST be set to 950 0x05. 952 Length (1 byte): The length in bytes of the rest of the option. This 953 field MUST be set to 0x02. 955 Random Port (2 bytes): The external port that the sender predicts 956 that its NAT has assigned it for communication with the destination. 957 This field MUST be specified in network byte order. 959 5. Protocol Details 961 5.1. Common Processing 963 The behavior in this section applies to multiple extensions. 965 Packets equivalent to those sent for a peer the first time a 966 connection is being established MAY be generated at other 967 implementation-specific times. (For example, an implementation might 968 choose to do so when its Neighbor Cache Entry for the peer is in the 969 PROBE state.) 971 5.1.1. Refresh Interval 973 [RFC4380] section 5.2 states: 974 The client must regularly perform the maintenance procedure in 975 order to guarantee that the Teredo service port remains usable. 976 The need to use this procedure or not depends on the delay since 977 the last interaction with the Teredo server. The refresh 978 procedure takes as a parameter the "Teredo refresh interval". 979 This parameter is initially set to 30 seconds; it can be updated 980 as a result of the optional "interval determination procedure". 981 The randomized refresh interval is set to a value randomly chosen 982 between 75% and 100% of the refresh interval. 984 This requirement can be problematic when the client is behind a NAT 985 that expires state in less than 30 seconds. The optional interval 986 determination procedure ([RFC4380] section 5.2.7) also does not 987 provide for intervals under 30 seconds. Hence this document refines 988 the behavior by saying the initial parameter SHOULD be configurable 989 and the default MUST be 30 seconds. An implementation MAY set the 990 randomized refresh interval to a value randomly chosen within an 991 implementation-specific range. Such a range MUST fall within 50% to 992 150% of the refresh interval. 994 [RFC4380] section 5.2.5 states that: 995 At regular intervals, the client MUST check the "date and time of 996 the last interaction with the Teredo server" to ensure that at 997 least one packet has been received in the last Randomized Teredo 998 Refresh Interval. If this is not the case, the client SHOULD send 999 a router solicitation message to the server, as specified in 1000 Section 5.2.1; 1002 This document refines the behavior as follows. A Teredo client MAY 1003 choose to send additional router solicitation messages to the server 1004 at other implementation-specific times. (For example, an 1005 implementation might choose to do so when its Neighbor Cache Entry 1006 for the router is in the PROBE state.) 1008 5.1.2. Trailer Processing 1010 A Teredo client MUST process the sequence of Trailers in the same 1011 order as they appear in the packet. If the Teredo client does not 1012 recognize the trailer Type while processing the trailers in the 1013 Teredo packet, the client MUST discard the packet if the highest- 1014 order bits of the trailer Type contain 01, or else the Teredo client 1015 MUST skip past the trailer. A Teredo client MUST stop processing the 1016 Trailers as soon as a malformed trailer appears in the sequence of 1017 Trailers in the packet. A trailer is defined as malformed if it has 1018 any of the following properties: 1020 o The length in bytes of the remainder of the UDP datagram is less 1021 than 2 (the size of the Type and Length fields of a trailer). 1022 o The length in bytes of the remainder of the UDP datagram is less 1023 than 2 + the value of the Length field of the trailer. 1025 5.2. Symmetric NAT Support Extension 1027 [RFC4380] section 5.2.1 advises that no Teredo IPv6 address be 1028 configured if the Teredo client is positioned behind a symmetric NAT. 1029 For Teredo clients positioned behind symmetric NATs, the mapped 1030 address/port used by its NAT when communicating with a Teredo peer is 1031 different from the mapped address/port embedded in the Teredo 1032 client's Teredo IPv6 address. The Symmetric NAT Support Extension 1033 provides a solution to this problem. 1035 In addition, [RFC4380] section 5.2.9 specifies a direct IPv6 1036 connectivity test to determine that the mapped address/port in the 1037 Teredo IPv6 address of a peer is not spoofed. It does this through 1038 the use of a nonce in ICMPv6 Echo Request and Response messages 1039 (which are defined in [RFC4443] section 4). However, the direct IPv6 1040 connectivity test is limited only to communication between Teredo 1041 IPv6 addresses and non-Teredo IPv6 addresses. In the following 1042 extension, we introduce the use of a nonce in direct and indirect 1043 bubbles and provide a mechanism to verify that the mapped address/ 1044 port are not spoofed. 1046 This extension is optional; an implementation SHOULD support it. 1048 5.2.1. Abstract Data Model 1050 This section describes a conceptual model of possible data 1051 organization that an implementation maintains to participate in this 1052 protocol. The described organization is provided to facilitate the 1053 explanation of how the protocol behaves. This document does not 1054 mandate that implementations adhere to this model as long as their 1055 external behavior is consistent with that described in this document. 1057 In addition to the state specified in [RFC4380] section 5.2, the 1058 following are also required: 1060 Peer Entry: The following additional state is required on a per-peer 1061 basis: 1063 o Nonce Sent: The value of the nonce sent in the last indirect 1064 bubble sent to the Teredo peer. 1065 o Nonce Received: The value of the nonce received in the last 1066 indirect bubble received from the Teredo peer. 1068 5.2.2. Timers 1070 No timers are necessary other than those in [RFC4380]. 1072 5.2.3. Initialization 1074 No initialization is necessary other than that specified in 1075 [RFC4380]. 1077 5.2.4. Message Processing 1079 Except as specified in the following sections, the rules for message 1080 processing are as specified in [RFC4380]. 1082 5.2.4.1. Sending an Indirect Bubble 1084 The rules for when indirect bubbles are sent to a Teredo peer are 1085 specified in [RFC4380] section 5.2.6. When a Teredo client sends an 1086 indirect bubble, it MUST generate a random 4-byte value, and include 1087 it in the Nonce field of a Nonce Trailer (section 2.2.1) appended to 1088 the indirect bubble, and also store it in the Nonce Sent field of its 1089 Peer Entry for that Teredo peer. 1091 5.2.4.2. Sending a Direct Bubble 1093 The rules for when direct bubbles are sent to a Teredo peer are 1094 specified in [RFC4380] section 5.2.6. When a Teredo client sends a 1095 direct bubble to a peer after receiving an indirect bubble with a 1096 Nonce Trailer, it MUST include in the direct bubble a Nonce Trailer 1097 with the same nonce value. 1099 If the Teredo client is about to send a direct bubble before it has 1100 received an indirect bubble from the Teredo peer, the Teredo client 1101 MUST NOT include a Nonce Trailer. 1103 5.2.4.3. Receiving an Indirect Bubble 1105 The rules for processing an indirect bubble are specified in 1106 [RFC4380] section 5.2.3. In addition, when a Teredo client receives 1107 an indirect bubble containing a Nonce Trailer, the Teredo client MUST 1108 store the nonce in the Nonce Received field of its Peer Entry for 1109 that Teredo peer. If an indirect bubble is received without a Nonce 1110 Trailer, and the Nonce Received field in the Peer Entry is non-zero, 1111 the Nonce Received field SHOULD be set to zero. 1113 5.2.4.4. Receiving a Direct Bubble 1115 If the mapped address/port of the direct bubble matches the mapped 1116 address/port embedded in the source Teredo IPv6 address, the direct 1117 bubble MUST be accepted, as specified in [RFC4380] section 5.2.3. 1119 In addition, if the mapped address/port does not match the embedded 1120 address/port but the direct bubble contains a Nonce Trailer with a 1121 nonce that matches the Nonce Sent field of the Teredo peer, the 1122 direct bubble MUST be accepted. 1124 If neither of the above conditions is true, the direct bubble MUST be 1125 dropped. 1127 If the direct bubble is accepted, the Teredo client MUST record the 1128 mapped address/port from which the direct bubble is received in the 1129 mapped address/port fields of the Teredo peer, as specified in 1130 [RFC4380] section 5.2. 1132 5.3. UPnP-Enabled Symmetric NAT Extension 1134 The UPnP-enabled Symmetric NAT Extension is optional; an 1135 implementation SHOULD support it. This extension has the Symmetric 1136 NAT Support Extension (Section 5.2) as a dependency. Any node that 1137 implements this extension MUST also implement the Symmetric NAT 1138 Support Extension. 1140 5.3.1. Abstract Data Model 1142 This section describes a conceptual model of possible data 1143 organization that an implementation maintains to participate in this 1144 protocol. The described organization is provided to facilitate the 1145 explanation of how the protocol behaves. This document does not 1146 mandate that implementations adhere to this model as long as their 1147 external behavior is consistent with that described in this document. 1149 This extension extends the abstract data model in Section 5.2.1 by 1150 adding the following additional fields. 1152 UPnP-Enabled NAT flag: This is a Boolean value, set to TRUE if the 1153 NAT positioned in front of the Teredo client is UPnP enabled. The 1154 default value of this flag is FALSE. 1156 UPnP-Mapped Address/Port: The mapped address/port assigned via UPnP 1157 to the Teredo client by the UPnP-enabled NAT behind which the Teredo 1158 client is positioned. Note that this field has a valid value only if 1159 the NAT to which the Teredo client is connected is UPnP enabled. 1160 Also note that if the Teredo client is positioned behind a single NAT 1161 only (as opposed to a series of nested NATs), this value is the same 1162 as the mapped address/port embedded in its Teredo IPv6 address. 1164 Symmetric NAT flag: This is a Boolean value, set to TRUE if the 1165 Teredo client is positioned behind a symmetric NAT. 1167 Peer Entry: The following state needs to be added on a per-peer 1168 basis: 1170 Symmetric Peer flag: This is a Boolean value and is TRUE if the 1171 Teredo peer is positioned behind a symmetric NAT. 1173 A Teredo client SHOULD also maintain the following state that is 1174 persisted across reboots: 1176 Persisted UPnP-Mapped Port: The mapped port assigned via UPnP to the 1177 Teredo client by the UPnP-enabled NAT behind which the Teredo client 1178 is positioned. Note that this value is the same as the UPnP-Mapped 1179 Port value when both are non-zero. The default value is all zero 1180 bytes. 1182 5.3.2. Timers 1184 No timers are necessary other than those in [RFC4380]. 1186 5.3.3. Initialization 1188 Prior to beginning the qualification procedure, the Teredo client 1189 MUST first perform the uninitialization procedure specified in 1190 Section 5.3.5.1 if the Persisted UPnP-Mapped Port is supported and 1191 non-zero. 1193 The Teredo client MUST then invoke the AddPortMapping function, as 1194 specified in [UPNPWANIP] section 2.4.16, with the following 1195 parameters: 1196 o NewRemoteHost: "" (empty string) 1197 o NewExternalPort: Local Port value 1198 o NewProtocol: UDP 1199 o NewInternalPort: Local Port value 1200 o NewInternalClient: Local Address value 1201 o NewEnabled: TRUE 1202 o NewPortMappingDescription: "TEREDO" 1203 o NewLeaseDuration: 0 1205 The successful completion of the AddPortMapping function indicates 1206 that the NAT has created a port mapping from the external port of the 1207 NAT to the internal port of the Teredo client node. The parameters 1208 are specified so that any external host should be able to send 1209 packets to the Teredo client by sending packets to the mapped 1210 address/port. If the AddPortMapping function fails, the Teredo 1211 client MUST continue without using this extension. Otherwise it MUST 1212 proceed as follows. 1214 The Teredo client MUST set the UPnP-Mapped Port (and Persisted UPnP- 1215 Mapped Port, if supported) to the Local Port value specified in 1216 AddPortMapping. The Teredo client MUST then call the 1217 GetExternalIPAddress function specified in [UPNPWANIP] section 1218 2.4.18. If the GetExternalIPAddress function fails, the Teredo 1219 client SHOULD perform the uninitialization procedure specified in 1220 section Section 5.3.5.1 and continue without using this extension. 1221 If the GetExternalIPAddress function succeeds, the Teredo client MUST 1222 proceed as follows. 1224 The Teredo client MUST set the UPnP-Mapped Address to the address 1225 returned from the GetExternalIPAddress function, and set the UPnP- 1226 Enabled NAT flag to TRUE. 1228 During the qualification procedure (as specified in [RFC4380] section 1229 5.2.1) when the Teredo client receives a response from the secondary 1230 Teredo server, the Teredo client MUST compare the mapped address/port 1231 learned from the secondary Teredo server with the mapped address/port 1232 associated with the Teredo server. If either the mapped address or 1233 the mapped port value is different, the Symmetric NAT flag MUST be 1234 set to TRUE. 1236 After the qualification procedure, the mapped address/port learned 1237 from the Teredo server MUST be compared to the UPnP-Mapped Address/ 1238 Port. If both are the same, the Teredo client is positioned behind a 1239 single NAT and the UPnP-Mapped Address/Port MUST be zeroed out. 1241 5.3.4. Message Processing 1243 Except as specified in the following sections, the rules for message 1244 processing are as specified in [RFC4380] section 5.2.3. 1246 5.3.4.1. Receiving a Direct Bubble 1248 Except as indicated below, the rules for handling a direct bubble are 1249 as specified in Section 5.2.4.4. 1251 A Teredo client positioned behind a UPnP-enabled NAT (port-restricted 1252 NAT as well as symmetric NAT) will receive all packets sent to the 1253 mapped address/port embedded in its Teredo IPv6 address. Thus when a 1254 Teredo client receives a direct bubble, it MUST compare the mapped 1255 address/port from which the packet was received with the mapped 1256 address/port embedded in the Teredo IPv6 address in the source 1257 address field of the IPv6 header. If the two are not the same, it 1258 indicates that the Teredo peer is positioned behind a symmetric NAT 1259 and it MUST set the Symmetric Peer flag in its Peer Entry. 1261 5.3.4.2. Sending a Direct Bubble 1263 The rules for sending a direct bubble are specified in [RFC4380] 1264 section 5.2.6 and in Section 5.2.4.2. These rules are further 1265 refined as follows. 1267 If the Teredo client sending the direct bubble meets all of the 1268 following criteria: 1269 o The Symmetric NAT flag is set to TRUE. 1270 o The UPnP-Enabled NAT flag is set to TRUE. 1271 o The UPnP-Mapped Address/Port are set to zero. 1272 o The peer's Symmetric Peer flag is set to TRUE. 1273 then the Teredo client MUST send the direct bubble to the mapped 1274 address/port embedded in the peer's Teredo IPv6 address. 1276 This is because Symmetric-to-Symmetric and Port-Restricted-to- 1277 Symmetric NAT communication between the Teredo client and the peer 1278 would have failed anyway. However, by taking a chance that the peer 1279 might also be positioned behind a UPnP-enabled NAT just like the 1280 Teredo client itself, the Teredo client can try sending the direct 1281 bubble to the mapped address/port in the peer's Teredo IPv6 address. 1282 If the packet does go through, communication is established. 1284 5.3.4.3. Sending a Data Packet 1286 The rules for sending a data packet are specified in [RFC4380] 1287 section 5.2.4. These rules are further refined as follows. 1289 If the Teredo client sending the data packet meets all of the 1290 following criteria: 1291 o The Symmetric NAT flag is set to TRUE. 1292 o The UPnP-Enabled NAT flag is set to TRUE. 1293 o The UPnP-Mapped Address/Port are set to zero. 1294 o The peer's Symmetric Peer flag is set to TRUE. 1295 then the Teredo client MUST send the data packet to the mapped 1296 address/port embedded in the peer's Teredo IPv6 address. 1298 5.3.5. Shutdown 1300 When Teredo client functionality is being shut down, uninitialization 1301 MUST be performed as specified in Section 5.3.5.1. 1303 5.3.5.1. Uninitialization 1305 First determine the mapped port as follows. If Persisted UPnP-Mapped 1306 Port is supported, use it as the mapped port. Otherwise, use the 1307 UPnP-Mapped Port. 1309 If the mapped port is non-zero, the Teredo Client MUST call the 1310 DeletePortMapping function, as specified in [UPNPWANIP] section 1311 2.4.17, with the following parameters: 1312 o NewRemoteHost: "" (empty string) 1313 o NewExternalPort: the mapped port 1314 o NewProtocol: UDP 1316 5.4. Port-Preserving Symmetric NAT Extension 1318 The Port-Preserving Symmetric NAT Extension is optional; an 1319 implementation SHOULD support it. This extension has the Symmetric 1320 NAT Support Extension (as specified in Section 5.2) as a dependency. 1321 Any node that implements this extension MUST also implement the 1322 Symmetric NAT Support Extension. 1324 5.4.1. Abstract Data Model 1326 This section describes a conceptual model of possible data 1327 organization that an implementation maintains to participate in this 1328 protocol. The described organization is provided to facilitate the 1329 explanation of how the protocol behaves. This document does not 1330 mandate that implementations adhere to this model as long as their 1331 external behavior is consistent with that described in this document. 1333 The Port-Preserving Symmetric NAT Extension extends the abstract data 1334 model in Section 5.2.1 by adding the following additional fields. 1336 Port-Preserving NAT flag: This is a Boolean value, set to TRUE if the 1337 Teredo client is positioned behind a port-preserving NAT. 1339 Symmetric NAT flag: This is a Boolean value, set to TRUE if the 1340 Teredo client is positioned behind a symmetric NAT. 1342 Peer Entry: The following fields need to be added on a per-peer 1343 basis: 1344 o Random Port: This field contains the value of the external port 1345 that the Teredo client predicts that its NAT has assigned it for 1346 communication with the peer. Set to zero by default. 1347 o Peer Random Port: This field contains the value of the random port 1348 that the peer is using for communication with this Teredo client. 1349 Set to zero by default. 1351 o Direct Receive on Primary Port: This is a Boolean value, set to 1352 TRUE if a packet is received from the Teredo peer on the primary 1353 local port. Set to FALSE by default. 1354 o Direct Receive on Random Port: This is a Boolean value, set to 1355 TRUE if a packet is received from the Teredo peer on the Random 1356 Port. Set to FALSE by default. 1357 o Connection Refresh Count: This field contains the number of direct 1358 bubbles that have been sent to the peer since the last time data 1359 was sent to the peer. 1360 o Last Data Packet Sent Timestamp: This field contains the time 1361 stamp of the last data packet sent to the peer. This time stamp 1362 is different from the field that stores the data and time of last 1363 transmission to the peer (as specified in [RFC4380] section 5.2) 1364 because the RFC-defined field is also updated every time a direct 1365 bubble is sent. 1367 5.4.2. Timers 1369 Other than those in [RFC4380], the Port-Preserving Symmetric NAT 1370 Extension requires the following additional timer: 1372 Peer Refresh Timer: A timer to refresh peer connections through the 1373 random port, on which no data has been sent for a while. 1375 5.4.2.1. Peer Refresh Timer Expiry 1377 When the Peer Refresh Timer expires, the Teredo client MUST go 1378 through its list of peers and for each peer to which the Teredo 1379 client is communicating through the random port, the Teredo client 1380 MUST check the Last Data Packet Sent Timestamp to determine if data 1381 has been sent to the peer in the last 30 seconds, and check the 1382 Connection Refresh Count field to determine if the count has reached 1383 the maximum allowed value of 20. If both checks are false, the 1384 Teredo client MUST send a direct bubble (as specified in 1385 Section 5.4.4.3) to the peer and increment the Connection Refresh 1386 Count. This direct bubble is sent as an attempt to keep the port 1387 mappings on all the intermediate NATs alive while the application/ 1388 user may be temporarily inactive. If on the other hand, data has 1389 been sent to the peer in the last 30 seconds, the Connection Refresh 1390 Count MUST be reset to zero. 1392 The Peer Refresh Timer MUST then be rescheduled to expire in 30 1393 seconds. 1395 5.4.3. Initialization 1397 In addition to the behavior specified in [RFC4380], the Port- 1398 Preserving NAT flag and Symmetric NAT flag MUST be set to FALSE when 1399 the Teredo client is started. The Peer Refresh Timer MUST be started 1400 and scheduled to expire in 30 seconds. 1402 During the qualification procedure (as specified in [RFC4380] section 1403 5.2.1), when the Teredo client receives a response from the Teredo 1404 server address, the Teredo client MUST compare the Port value in the 1405 origin indication, as specified in [RFC4380] section 5.1.1, with the 1406 Local Port value. If both values match, the client MUST set the 1407 Port-Preserving NAT flag to TRUE. 1409 5.4.4. Message Processing 1411 5.4.4.1. Sending a Data Packet 1413 On receiving a data packet to be transmitted to the Teredo Peer (in 1414 addition to the rules specified in [RFC4380] section 5.2.4), the 1415 Teredo client MUST update the Last Data Packet Sent Timestamp when 1416 the packet is actually sent. 1418 5.4.4.2. Sending an Indirect Bubble 1420 The rules for sending an indirect bubble are as specified in 1421 Section 5.2.4.1 and [RFC4380] section 5.2.6. In addition to those 1422 rules, if the Port-Preserving NAT flag is TRUE, the Teredo client 1423 MUST do the following: 1424 o If the Symmetric NAT flag is set, the Teredo peer is not marked as 1425 "trusted" (as specified in [RFC4380] section 5.2), and the Random 1426 Port is zero, the Teredo client MUST first select a random port 1427 number to use, and then begin listening on that port. Since the 1428 NAT is port-preserving, the Teredo client can predict that the 1429 external port assigned will be equal to the random port chosen, 1430 and hence the Teredo client MUST store the random port chosen in 1431 the Random Port field of the Peer Entry. 1432 o If the Random Port value is non-zero, the Teredo client MUST 1433 append a Random Port Trailer to the indirect bubble. 1435 5.4.4.3. Sending a Direct Bubble 1437 The rules for when direct bubbles are sent to a Teredo peer are as 1438 specified in [RFC4380] section 5.2.6. In addition, Section 5.2.4.2 1439 defines rules for enabling communication for clients positioned 1440 behind a symmetric NAT. In addition to the rules defined in both the 1441 aforementioned sections, if the Port-Preserving NAT flag is TRUE, the 1442 following rules apply also. 1444 If the Symmetric NAT flag is set, and the Teredo peer is not marked 1445 as "trusted" (as specified in [RFC4380] section 5.2) the Teredo 1446 client MUST send a direct bubble destined to the mapped address/port 1447 embedded in the Teredo IPv6 address of the Teredo peer. If the peer 1448 Random Port field is non-zero, the Teredo client MUST send another 1449 direct bubble from its own random port, destined to the peer random 1450 port. The IPv4 destination address MUST be the mapped address 1451 embedded in the Teredo IPv6 address. In addition, the Teredo client 1452 MUST include the Random Port Trailer (section 2.2.5). 1454 5.4.4.4. Receiving an Indirect Bubble 1456 The rules for processing an indirect bubble are as specified in 1457 Section 5.2.4.3 and [RFC4380] section 5.2.3. In addition to these 1458 rules, if the incoming indirect bubble has a Random Port Trailer, the 1459 following additional processing MUST be done. 1461 If the Peer Random Port field of the Peer Entry is zero, the Teredo 1462 client MUST store the port from the Random Port Trailer in the Peer 1463 Random Port field of the Peer Entry. 1465 If the Peer Random Port field is non-zero and if either the Peer 1466 Random Port field and the new advertised port have the same value, or 1467 if active data has been exchanged between the two Teredo clients in 1468 the last 30 seconds (that is, "time of last transmission" or "time of 1469 last reception," as specified in [RFC4380] section 5.2, is set to a 1470 time that is less than 30 seconds ago), the new advertised port value 1471 MUST be ignored. 1473 If the Peer Random Port field is non-zero and the new advertised port 1474 value is different from the Peer Random Port value, and it has been 1475 more than 30 seconds since the last exchange of data packets between 1476 the two Teredo clients, (that is, "time of last transmission" and 1477 "time of last reception" are set to a time that is more than 30 1478 seconds ago), the Teredo client SHOULD store the new advertised port 1479 value in the Peer Random Port field and, if the Port-Preserving NAT 1480 flag is TRUE, then clear the Random Port field, and stop listening on 1481 the old random port. This allows communication to be reestablished 1482 if either side changes the random port that it is using. 1484 5.4.4.5. Receiving a Direct Bubble 1486 The rules for handling direct bubbles are specified in 1487 Section 5.2.4.4 and [RFC4380] section 5.2.3. The rules for whether 1488 to accept a direct bubble are extended as follows, when the Port- 1489 Preserving NAT flag is TRUE: 1490 o If the direct bubble is received on the primary port and the 1491 Teredo peer is not "trusted," the status field of the Teredo 1492 client MUST be changed to "trusted" and the Direct Receive on 1493 Primary Port flag MUST be set to TRUE. The mapped address/port 1494 from which the direct bubble was received MUST be recorded in the 1495 mapped address/port fields of the Teredo peer, as specified in 1496 [RFC4380] section 5.2. The Teredo client MUST then set the Random 1497 Port field in the Peer Entry to zero and stop listening on the old 1498 random port. 1499 o If the direct bubble is received on the primary port, the Teredo 1500 peer is "trusted," and the Direct Receive on Primary flag is set 1501 to TRUE, the Teredo client MUST compare the mapped address/port of 1502 the direct bubble with the mapped address/port of the Peer Entry. 1503 If both mappings are the same, the direct bubble MUST be accepted. 1504 If the mappings are different and it has been more than 30 seconds 1505 since the last packet exchange with the Teredo peer (that is, 1506 "time of last transmission" and "time of last reception," as 1507 defined in [RFC4380] section 5.2, are set to a time that is more 1508 than 30 seconds ago), the mapping on the Teredo peer's NAT has 1509 changed and communication needs to be reestablished. This MUST be 1510 done by changing the status of the peer to "not-trusted", setting 1511 the Direct Receive on Primary Port flag to FALSE, and sending an 1512 indirect bubble to the Teredo peer via its Teredo server. 1513 o If the direct bubble is received on the primary port, the Teredo 1514 peer is "trusted," the Direct Receive on Primary Port flag is set 1515 to FALSE, and the Direct Receive on Random Port flag is set to 1516 TRUE, the mapped address/port from which the direct bubble is 1517 received MUST be stored in the mapped address/port fields of the 1518 Peer Entry. The Direct Receive on Primary Port flag MUST be set 1519 to TRUE. The Teredo client MUST then set the Random Port field in 1520 the Peer Entry to zero and stop listening on the old random port. 1521 Finally, the Direct Receive on Random Port flag MUST be set to 1522 FALSE. 1523 o If the direct bubble is received on the random port and the Teredo 1524 peer is not "trusted," the status field of the Teredo client MUST 1525 be changed to "trusted" and the Direct Receive on Random Port flag 1526 MUST be set to TRUE. The mapped address/port from which the 1527 direct bubble was received MUST be recorded in the mapped address/ 1528 port fields of the Teredo Peer Entry, as specified in [RFC4380] 1529 section 5.2. 1530 o If the direct bubble is received on the random port, the Teredo 1531 peer is "trusted," and the Direct Receive on Primary Port flag is 1532 FALSE, the Teredo client MUST compare the mapped address/port in 1533 the direct bubble with the mapped address/port in the Peer Entry. 1534 If the two mappings are the same, the direct bubble MUST be 1535 accepted. If the mappings are different, it implies that the NAT 1536 had deleted the mapping and when it reassigned the mapping, a 1537 different external port was chosen. In this instance, the Teredo 1538 client SHOULD set the Random Port field to zero, stop listening on 1539 the old random port, and send an indirect bubble to the Teredo 1540 peer as specified in Section 5.4.4.2. 1542 Note that once the Direct Receive on Primary Port flag is TRUE, the 1543 client will stop listening on the random port and hence a direct 1544 bubble cannot be received on the random port. As a result, this case 1545 is intentionally omitted above. 1547 5.5. Sequential Port-Symmetric NAT Extension 1549 The Sequential Port-Symmetric NAT Extension is optional; an 1550 implementation SHOULD support it. This extension has the Symmetric 1551 NAT Support Extension (Section 5.2) as a dependency. Any node that 1552 implements this extension MUST also implement the Symmetric NAT 1553 Support Extension, as well as the Port-Preserving NAT Extension 1554 (Section 5.4). 1556 5.5.1. Abstract Data Model 1558 This section describes a conceptual model of possible data 1559 organization that an implementation maintains to participate in this 1560 protocol. The described organization is provided to facilitate the 1561 explanation of how the protocol behaves. This document does not 1562 mandate that implementations adhere to this model as long as their 1563 external behavior is consistent with that described in this document. 1565 The Sequential Port-Symmetric NAT Extension extends the abstract data 1566 model in Section 5.4.1 by adding the following additional state. 1568 Peer Entry: The following fields need to be added on a per-peer 1569 basis: 1570 o EchoTestNonce1: The value of the nonce sent as part of the 1571 authentication encapsulation, as specified in [RFC4380] section 1572 5.1.1, in the router solicitation packet sent to the Teredo server 1573 address as part of the Echo Test. 1574 o EchoTestNonce2: The value of the nonce sent as part of the 1575 authentication encapsulation in the router solicitation packet 1576 sent to the secondary Teredo server address as part of the Echo 1577 Test. 1578 o EchoTestLowerPort: The value of the external port mapping 1579 extracted from the origin indication of the router advertisement 1580 received from the Teredo server address as part of the Echo Test. 1581 A value of 0 indicates that no such router advertisement has been 1582 received. 1583 o EchoTestUpperPort: The value of the external port mapping 1584 extracted from the origin indication of the router advertisement 1585 received from the secondary Teredo server address as part of the 1586 Echo Test. A value of 0 indicates that no such router 1587 advertisement has been received. 1588 o EchoTestRetryCounter: The number of times an Echo Test has been 1589 attempted. 1591 5.5.2. Timers 1593 In addition to the timers specified in Section 5.4.2, the following 1594 additional timer is required per Peer entry. 1596 Echo Test Failover Timer: A one-shot timer that runs whenever an Echo 1597 Test is in progress. 1599 5.5.2.1. Peer Refresh Timer Expiry 1601 The processing of the Peer Refresh Timer Expiry MUST be completed as 1602 specified in Section 5.4.2.1. In addition to those rules, the Teredo 1603 client MUST set the EchoTestLowerPort, EchoTestUpperPort, and 1604 EchoTestRetryCounter to zero. 1606 5.5.2.2. Echo Test Failover Timer Expiry 1608 If the Echo Test Failover Timer expires, the Teredo client MUST do 1609 the following. 1611 If the value of the EchoTestRetryCounter is two, then the Teredo 1612 client MUST send an indirect bubble as specified in Section 5.2.4.1. 1614 If the value of the EchoTestRetryCounter is one, then the Teredo 1615 client MUST start another Echo Test as specified in 1616 Section 5.5.4.1.1. 1618 5.5.3. Initialization 1620 No behavior changes are required beyond what is specified in 1621 Section 5.4.3. 1623 5.5.4. Message Processing 1625 Except as specified in the following sections, the rules for message 1626 processing are as specified in Section 5.4.4. 1628 5.5.4.1. Handling a Request to Send an Indirect Bubble 1630 Whenever [RFC4380] or other extensions specified in this document 1631 specify that an indirect bubble is to be sent, the following actions 1632 apply at that time instead if the Symmetric NAT flag is TRUE and the 1633 Port-Preserving NAT flag is FALSE. Note that any behavior specified 1634 by [RFC4380] or other extensions in this document still applies to 1635 how indirect bubbles are constructed, but such behavior is done at a 1636 later time as specified in Section 5.5.4.4. 1638 If the Symmetric NAT flag is TRUE, and the Port-Preserving NAT flag 1639 is FALSE, and the Teredo peer is not marked as "trusted" (as 1640 specified in [RFC4380] section 5.2) and the Random Port is zero, then 1641 the Teredo client MUST select a random port number to use, begin 1642 listening on that port, and start an Echo Test as specified below. 1644 5.5.4.1.1. Starting an Echo Test 1646 To start an Echo Test, the Teredo client MUST send the following 1647 three packets from this port: 1648 o First, a router solicitation (as specified in [RFC4380] section 1649 5.2.1) MUST be sent to the Teredo server address. The router 1650 solicitation MUST include an authentication encapsulation with a 1651 randomly-generated Nonce field, as specified in [RFC4380] section 1652 5.1.1. The nonce included in the authentication encapsulation 1653 MUST then be stored in the EchoTestNonce1 field of the Peer entry. 1654 o Second, a direct bubble MUST be sent to the peer. 1655 o Third, a router solicitation MUST be sent to the secondary Teredo 1656 server address. The router solicitation MUST include an 1657 authentication encapsulation with a randomly-generated Nonce 1658 field, as specified in [RFC4380] section 5.1.1. The nonce 1659 included in the authentication encapsulation MUST then be stored 1660 in the EchoTestNonce2 field of the Peer entry. 1662 The Teredo client MUST then increment the EchoTestRetryCounter and 1663 set the Echo Test Failover Timer to expire in a number of seconds 1664 equal to EchoTestRetryCounter. 1666 5.5.4.2. Sending an Indirect Bubble 1668 The rules for sending an indirect bubble are as specified in 1669 Section 5.2.4.1 and [RFC4380] section 5.2.6. In addition to those 1670 rules, if the Symmetric NAT flag is TRUE, and the Port-Preserving NAT 1671 flag is FALSE, and the Random Port value is nonzero, then the Teredo 1672 client MUST append a Random Port Trailer to the indirect bubble. 1674 5.5.4.3. Receiving a Direct Bubble 1676 The processing of the direct bubble MUST be completed as specified in 1677 Section 5.4.4.5, as if the Port-Preserving NAT flag were TRUE. After 1678 the processing is complete, if the Direct Bubble Received on Primary 1679 flag is TRUE, and the Echo Test Failover Timer is running, then the 1680 Echo Test Failover Timer MUST be cancelled and EchoTestLowerPort, 1681 EchoTestUpperPort, and EchoTestRetryCounter MUST be set to zero. 1683 5.5.4.4. Receiving a Router Advertisement 1685 The rules for processing a router advertisement are as specified in 1686 [RFC4380] section 5.2.1. In addition to those rules, if the router 1687 advertisement contains an authentication encapsulation, the Teredo 1688 client MUST look for a Peer entry whose EchoTestNonce1 or 1689 EchoTestNonce2 field matches the nonce in the authentication 1690 encapsulation. If a Peer entry is found, the Teredo client MUST do 1691 the following. 1693 If the received nonce is equal to EchoTestNonce1 and 1694 EchoTestLowerPort is zero, then EchoTestLowerPort MUST be set to the 1695 external port mapping extracted from the origin indication of this 1696 router advertisement. 1698 If the received nonce is equal to EchoTestNonce2 and 1699 EchoTestUpperPort is zero, then EchoTestUpperPort MUST be set to the 1700 external port mapping extracted from the origin indication of this 1701 router advertisement. 1703 If the EchoTestUpperPort and EchoTestLowerPort are now both nonzero, 1704 the Teredo client MUST then set the Random Port field of the Peer 1705 Entry to (EchoTestUpperPort + EchoTestUpperPort)/2, rounded down, and 1706 send an indirect bubble as specified in Section 5.5.4.2. 1708 5.6. Hairpinning Extension 1710 This extension is optional; an implementation SHOULD support it. 1712 5.6.1. Abstract Data Model 1714 This section describes a conceptual model of possible data 1715 organization that an implementation maintains to participate in this 1716 protocol. The described organization is provided to facilitate the 1717 explanation of how the protocol behaves. This document does not 1718 mandate that implementations adhere to this model as long as their 1719 external behavior is consistent with that described in this document. 1721 In addition to the state specified in [RFC4380] section 5.2, the 1722 following are also required: 1724 UPnP Mapped Address/Port: The mapped address/port assigned via UPnP 1725 to the Teredo client by the UPnP-enabled NAT behind which the Teredo 1726 client is positioned. This field has a valid value only if the NAT 1727 to which the Teredo client is connected is UPnP-enabled. In 1728 addition, if the Teredo client is positioned behind a single NAT only 1729 (as opposed to a series of nested NATs), this value will be the same 1730 as the mapped address/port embedded in its Teredo IPv6 address. 1732 Peer Entry: Per-peer state is extended beyond what is described in 1733 [RFC4380] by including the following: 1735 o Alternate Address/Port list: The list of alternate address/port 1736 pairs advertised by the peer. 1738 5.6.2. Timers 1740 No timers are necessary other than those in [RFC4380]. 1742 5.6.3. Initialization 1744 Behavior is as specified in [RFC4380], with the following additions. 1746 Prior to beginning the qualification procedure, the Teredo client 1747 MUST invoke the AddPortMapping function (as specified in [UPNPWANIP] 1748 section 2.4.16) with the parameters specified in Section 5.3.3. If 1749 successful, it indicates that the NAT has created a port mapping from 1750 the external port of the NAT to the internal port of the Teredo 1751 client node. If the AddPortMapping function is successful, the 1752 Teredo client MUST store the mapping assigned by the NAT in its UPnP 1753 Mapped Address/Port state. 1755 After the qualification procedure, the mapped address/port learned 1756 from the Teredo server MUST be compared to the UPnP Mapped Address/ 1757 Port. If both are the same, the Teredo client is positioned behind a 1758 single NAT and the UPnP Mapped Address/Port MUST be zeroed out. 1760 5.6.4. Message Processing 1762 5.6.4.1. Sending an Indirect Bubble 1764 The rules for when indirect bubbles are sent to a Teredo peer are as 1765 specified in [RFC4380] section 5.2.6. If communication between a 1766 Teredo client and a Teredo peer has not been established, the Teredo 1767 client MUST include the Alternate Address Trailer in the indirect 1768 bubble. The Alternate Address Trailer MUST include the node's local 1769 address/port in the Alternate Address/Port list. If the UPnP Mapped 1770 Address/Port is non-zero, the Alternate Address Trailer MUST also 1771 include it in the list. 1773 Hairpinning requires "direct IPv6 connectivity tests" (as specified 1774 in [RFC4380] section 5.2.9) to succeed before it can accept packets 1775 from an IPv4 address and port not embedded in the Teredo IPv6 1776 address. Hence the indirect bubble MUST also include a Nonce 1777 Trailer. 1779 5.6.4.2. Receiving an Indirect Bubble 1781 The rules for processing indirect bubbles are as specified in 1782 [RFC4380] section 5.2.3. In addition to those rules, when a Teredo 1783 client receives an indirect bubble with the Alternate Address 1784 Trailer, it SHOULD first verify that the Alternate Address Trailer is 1785 correctly formed (as specified in Section 4.3), and drop the bubble 1786 if not. Otherwise, it MUST set the Alternate Address/Port list in 1787 its Peer Entry to the list in the trailer. The Teredo client, 1788 besides sending direct bubbles to the mapped address/port embedded in 1789 the Teredo IPv6 address (as specified in [RFC4380] section 5.2.6), 1790 MUST also send a direct bubble to each mapped address/port advertised 1791 in the Alternate Address Trailer. 1793 In each of the direct bubbles, the Teredo client MUST include a Nonce 1794 Trailer with the nonce value received in the indirect bubble. 1796 5.6.4.3. Receiving a Direct Bubble 1798 If the mapped address/port of the direct bubble matches the mapped 1799 address/port embedded in the source Teredo IPv6 address, the direct 1800 bubble MUST be accepted, as specified in [RFC4380] section 5.2.3. 1802 If the mapped address/port does not match the embedded address/port, 1803 but the direct bubble contains a Nonce Trailer with a nonce that 1804 matches the Nonce Sent field of the Teredo peer, the direct bubble 1805 MUST be accepted. 1807 If neither of the above rules match, the direct bubble MUST be 1808 dropped. 1810 5.7. Server Load Reduction Extension 1812 This extension is optional; an implementation SHOULD support it. 1814 5.7.1. Abstract Data Model 1816 This section describes a conceptual model of possible data 1817 organization that an implementation maintains to participate in this 1818 protocol. The described organization is provided to facilitate the 1819 explanation of how the protocol behaves. This document does not 1820 mandate that implementations adhere to this model as long as their 1821 external behavior is consistent with that described in this document. 1823 In addition to the state specified in [RFC4380] section 5.2, the 1824 following are also required: 1826 Peer Entry: The following state needs to be added on a per-peer 1827 basis: 1828 o Count of Solicitations Transmitted: The number of Solicitation 1829 packets sent. 1831 5.7.2. Timers 1833 Retransmission Timer: A timer used to retransmit Teredo Neighbor 1834 Solicitation packets. 1836 When the retransmission timer expires, the Teredo client MUST 1837 retransmit a direct bubble with a Neighbor Discovery Option Trailer, 1838 and increment the Count of Solicitations Transmitted. If the count 1839 is less than three, it MUST then reset the timer to expire in two 1840 seconds. Otherwise (if the count is now three), it MUST send an 1841 indirect bubble to the Teredo peer to reestablish connectivity as if 1842 no communication between the Teredo client and the Teredo peer had 1843 been established. 1845 5.7.3. Initialization 1847 No initialization is necessary other than that specified in 1848 [RFC4380]. 1850 5.7.4. Message Processing 1852 Except as specified below, processing is the same as specified in 1853 [RFC4380]. 1855 5.7.4.1. Sending a Data Packet 1857 Upon receiving a data packet to be transmitted to the Teredo peer, 1858 the Teredo client MUST determine whether data has been exchanged 1859 between the Teredo client and peer in either direction in the last 30 1860 seconds (using the state as specified in [RFC4380] section 5.2). If 1861 not, the Teredo client MUST send a direct bubble with a Neighbor 1862 Discovery Option Trailer having the DiscoveryType field set to 1863 TeredoDiscoverySolicitation. The Count of Solicitations Transmitted 1864 field MUST be set to 1. The retransmission timer MUST be set to 1865 expire in two seconds. 1867 5.7.4.2. Receiving a Direct Bubble 1869 The rules for processing direct bubbles are as specified in [RFC4380] 1870 section 5.2.3. In addition to those rules, upon receiving a direct 1871 bubble containing a Neighbor Discovery Option Trailer with 1872 DiscoveryType field set to TeredoDiscoverySolicitation, the Teredo 1873 client MUST respond with a direct bubble with the Neighbor Discovery 1874 Option Trailer having the DiscoveryType field set to 1875 TeredoDiscoveryAdvertisement. 1877 6. Protocol Examples 1879 The following sections describe several operations as used in common 1880 scenarios to illustrate the function of Teredo Extensions. 1882 6.1. Symmetric NAT Support Extension 1884 The following protocol example illustrates the use of the Symmetric 1885 NAT Support Extension. 1887 In Figure 2 (Section 3.1), assume that Teredo Client A, which is 1888 positioned behind a port-symmetric NAT, wants to communicate with 1889 Teredo Client B, which is positioned behind an address-restricted 1890 NAT. 1892 The qualification procedure where the Teredo client determines that 1893 it is positioned behind a symmetric NAT is exactly the same as that 1894 specified in [RFC4380] section 5.2.1. Because of the Symmetric NAT 1895 Extension, Client A continues to configure a Teredo IPv6 address even 1896 after determining that the Teredo client is positioned behind a 1897 symmetric NAT. 1899 Next the following packet exchange helps Teredo Client A (A) 1900 establish communication with Teredo Client B (B). 1902 Teredo Client A's Client B's Teredo 1903 Client Teredo Teredo Client 1904 A NAT Server Server NAT B 1905 | | | | | | 1906 | | | Direct Bubble to B | | | 1907 1 |--------------------------------------------------->| | 1908 | | | | | | 1909 |Indirect Bubble to B via B's Teredo Server| | | 1910 2 |----------------------------------------->|----------------->| 1911 | | | | | | 1912 | | | Direct Bubble to A | | | 1913 | |<--------------------------------------------------| 3 1914 | | | | | | 1915 | | |Indirect Bubble to A via A's Teredo Server| 1916 |<-----------------|<-----------------------------------------| 4 1917 | | | | | | 1918 | | | Direct Bubble to B | | | 1919 5 |------------------------------------------------------------>| 1920 | | | | | | 1921 |Indirect Bubble to B via B's Teredo Server| | | 1922 6 |----------------------------------------->|----------------->| 1923 | | | | | | 1924 | | | Direct Bubble to A | | | 1925 |<------------------------------------------------------------| 7 1926 | | | | | | 1928 Port-Symmetric NAT to Address-Restricted NAT Packet Exchange 1929 1. A sends a direct bubble (Packet 1) destined to the mapped 1930 address/port embedded in B's Teredo IPv6 address. The mapped 1931 port in the source field of the packet assigned by client A's 1932 NAT is different from the mapped port embedded in A's Teredo 1933 IPv6 address. This is characteristic of the port-symmetric NAT 1934 positioned in front of A. The mapped address in the source field 1935 of the packet is the same as the mapped address embedded in the 1936 Teredo IPv6 address of A. 1937 2. The aforementioned direct bubble is dropped by B's NAT because 1938 it has not seen an outgoing packet destined to A's mapped IPv4 1939 address. 1940 3. A sends an indirect bubble (Packet 2) destined to B via client 1941 B's Teredo server. 1942 4. The above-mentioned indirect bubble is received by B. B then 1943 responds with the following packets. The first packet sent by B 1944 is a direct bubble (Packet 3) destined to the mapped address/ 1945 port embedded in A's Teredo IPv6 address. 1946 5. The above-mentioned direct bubble is dropped by A's NAT because 1947 the NAT has not seen any outgoing packet sourced from the mapped 1948 address/port embedded in A's Teredo IPv6 address and destined to 1949 the mapped address/port embedded in B's Teredo IPv6 address. 1951 6. B also sends an indirect bubble (Packet 4) destined to A via A's 1952 Teredo Server. 1953 7. The aforementioned indirect bubble is successfully received by 1954 A. A responds to the indirect bubble with its own direct bubble 1955 (Packet 5). This direct bubble is exactly the same as the first 1956 direct bubble (Packet 1) sent by A. 1957 8. This time around the aforementioned direct bubble is accepted by 1958 B's NAT because the NAT has seen an outgoing packet (Packet 3) 1959 sourced from the mapped address/port embedded in B's Teredo IPv6 1960 address and destined to the mapped address/port embedded in A's 1961 Teredo IPv6 address. It is important to remember that A's NAT 1962 is port-symmetric and therefore varies only the mapped port 1963 while the mapped address remains the same. B's NAT is address- 1964 restricted and cares only about prior communication with the 1965 IPv4 address, not the specific port. At this point, 1966 communication in one direction is now possible (B to A, but not 1967 vice versa). 1968 9. After receiving the direct bubble, B remembers the new mapped 1969 address/port that was in the source fields of the direct bubble 1970 and uses those for future communication with A instead of the 1971 mapped address/port embedded in A's Teredo IPv6 address. 1972 10. A then times out and resends an indirect bubble (Packet 6) and 1973 in response, B sends a direct bubble (Packet 7). This direct 1974 bubble is destined to the new learned mapped address/port and 1975 hence A's NAT permits the direct bubble through. Communication 1976 is now possible in the other direction (client A to B). 1978 6.2. UPnP-enabled Symmetric NAT Extension 1980 The following protocol example illustrates the use of the UPnP- 1981 Enabled Symmetric NAT Extension in addition to the Symmetric NAT 1982 Support Extension. 1984 Assume that Teredo Client A, which is positioned behind a UPnP- 1985 enabled port-symmetric NAT, wants to communicate with Teredo Client 1986 B, which is also positioned behind a UPnP-Enabled port-symmetric NAT. 1988 Before both clients start their qualification procedure, they use 1989 UPnP to reserve port mappings on their respective NATs. The UPnP 1990 operations succeed for both the clients and the clients hence know 1991 that they are positioned behind UPnP-enabled NATs. After the 1992 qualification procedure, both clients have valid Teredo IPv6 1993 addresses because they both support the Symmetric NAT Support 1994 Extension. Also, after the qualification procedure both clients will 1995 compare their mapped address/port determined through UPnP with the 1996 mapped address/port determined through the qualification procedure. 1997 Because both will be the same, the clients will zero out their UPnP 1998 mapped address/port values and conclude that they are each located 1999 behind a single UPnP-enabled NAT. 2001 The following packet exchange shows Teredo client A (A) establishing 2002 communication with Teredo client B (B). 2004 Teredo Client A's Client B's Teredo 2005 Client Teredo Teredo Client 2006 A NAT Server Server NAT B 2007 | | | | | | 2008 | | | Direct Bubble to B | | | 2009 1 |------------------------------------------------------------>| 2010 | | | | | | 2011 |Indirect Bubble to B via B's Teredo Server| | | 2012 2 |----------------------------------------->|----------------->| 2013 | | | | | | 2014 | | | Direct Bubble to A | | | 2015 |<------------------------------------------------------------| 3 2016 | | | | | | 2018 UPnP-enabled Symmetric NAT Packet Exchange 2020 1. A sends a direct bubble (Packet 1) to the mapped address/port 2021 embedded in B's Teredo IPv6 address. Because A's NAT is a 2022 symmetric NAT, the UDP source port field in the packet assigned 2023 by A's NAT is different from the mapped port embedded in A's 2024 Teredo IPv6 address, but the IPv4 source address of the packet is 2025 the same as the mapped address embedded in A's Teredo IPv6 2026 address. 2027 2. The above-mentioned direct bubble is received by B because it is 2028 destined for the UPnP mapped address/port of B and hence is let 2029 through by the NAT. At this point, B deduces that A is 2030 positioned behind a symmetric NAT because the mapped address/port 2031 from which the direct bubble is received is different from the 2032 mapped address/port that is embedded in A's Teredo IPv6 address. 2033 Hence, it remembers that the peer is positioned behind a 2034 symmetric NAT so that data packets will be sent to the mapped 2035 address/port embedded in A's Teredo IPv6 address, rather than the 2036 mapped address/port from which the direct bubble was received. 2037 At this point, communication in one direction is now possible (B 2038 to A, but not vice versa). 2039 3. A also sends an indirect bubble (Packet 2) destined to B via B's 2040 Teredo Server. 2041 4. The above indirect bubble is received by B. B then responds with 2042 a direct bubble (Packet 3) destined to the mapped address/port 2043 embedded in A's Teredo IPv6 address, as in step 2. 2044 5. Because A's NAT is also UPnP-enabled, the above-mentioned direct 2045 bubble is received by A. A also notices that B is positioned 2046 behind a Symmetric NAT because the mapped address/port from which 2047 the packet is received is different from the mapped address/port 2048 embedded in B's Teredo IPv6 address. Hence, it remembers that 2049 the peer is positioned behind a symmetric NAT so that data 2050 packets will be sent to the mapped address/port embedded in B's 2051 Teredo IPv6 address, rather than the mapped address/port from 2052 which the direct bubble was received. At this point, 2053 communication is now possible in the other direction (A to B). 2055 6.3. Port-Preserving Symmetric NAT Extension 2057 The following protocol example illustrates the use of the Port- 2058 Preserving Symmetric NAT Extension. 2060 Assume that Teredo Client A (A), which is positioned behind a port- 2061 preserving symmetric NAT, wants to communicate with Teredo Client B 2062 (B), which is also positioned behind a port-preserving symmetric NAT. 2064 The following packet exchange explains the configuration setup and 2065 communication setup between the two clients. 2067 Teredo Client A's Client B's Teredo 2068 Client Teredo Teredo Client 2069 A NAT Server Server NAT B 2070 | | | | | | 2071 | | | Direct Bubble to B | | | 2072 1 |--------------------------------------------------->| | 2073 | | | | | | 2074 |Indirect Bubble to B via B's Teredo Server| | | 2075 2 |----------------------------------------->|----------------->| 2076 | | | | | | 2077 | | | Direct Bubble to A | | | 2078 | |<--------------------------------------------------| 3 2079 | | | | | | 2080 | | | Direct Bubble to A | | | 2081 | |<--------------------------------------------------| 4 2082 | | | | | | 2083 | | |Indirect Bubble to A via A's Teredo Server| 2084 |<-----------------|<-----------------------------------------| 5 2085 | | | | | | 2086 | | | Direct Bubble to B | | | 2087 6 |--------------------------------------------------->| | 2088 | | | | | | 2089 | | | Direct Bubble to B | | | 2090 7 |------------------------------------------------------------>| 2091 | | | | | | 2092 |Indirect Bubble to B via B's Teredo Server| | | 2093 8 |----------------------------------------->|----------------->| 2094 | | | | | | 2095 | | | Direct Bubble to A | | | 2096 |<------------------------------------------------------------| 9 2097 | | | | | | 2099 Port-Preserving Symmetric NAT Packet Exchange 2101 1. During the qualification procedure, when the clients receive a 2102 response from the Teredo server, they compare the Port value in 2103 the Origin indication with the Local Port value. If both values 2104 match, the clients set the Port-Preserving NAT flag to TRUE. 2105 2. When the response is received from the secondary Teredo server, 2106 the mapped address/port value in the Origin indication is 2107 compared with the mapped address/port value learned from the 2108 response received from the primary server. If the mappings are 2109 different, the Symmetric NAT flag is set to TRUE. 2110 3. It is assumed that for both clients A and B, the Port-Preserving 2111 NAT flag and the Symmetric NAT flag are set to TRUE at the end 2112 of the qualification procedure. 2114 4. Before A sends packets to B, A checks to see if it is positioned 2115 behind a port-preserving NAT and a symmetric NAT, which in the 2116 example, it is. A also checks to see if the peer is "trusted," 2117 but it currently is not. Next, A checks if the Random Port is 2118 set to non-zero. Since it is still zero, A allocates a new 2119 random port, begins listening on it, and stores the value in the 2120 Random Port field. 2121 5. A sends a direct bubble (Packet 1) from the primary port to the 2122 mapped address/port embedded in B's Teredo IPv6 Address. This 2123 direct bubble does not have a Nonce Trailer or a Random Port 2124 Trailer attached to the end. 2125 6. The aforementioned direct bubble is dropped by B's NAT because 2126 the NAT has not seen an outgoing packet destined to A's mapped 2127 address. 2128 7. A sends an indirect bubble (Packet 2) destined to B via client 2129 B's Teredo server. This indirect bubble contains two trailers: 2130 the Nonce Trailer containing a random nonce, and the Random Port 2131 Trailer containing the random port value from the Peer Entry. 2132 The nonce used in the Nonce Trailer is also stored in the Nonce 2133 Sent field of the Peer Entry. 2134 8. The aforementioned indirect bubble is received by B. B adds the 2135 Teredo peer to its peer list. B saves the nonce value from the 2136 Nonce Trailer in the Nonce Advertised field of the Peer Entry. 2137 B stores the port value from the Random Port Trailer in the Peer 2138 Random Port field in the Peer Entry. 2139 9. B responds by sending the following packets. The first packet 2140 sent by B is a direct bubble (Packet 3) destined to the mapped 2141 address/port embedded in A's Teredo IPv6 Address. This packet 2142 is sent from the primary port. It includes the Nonce Trailer 2143 with the nonce from the Nonce Advertised field of the Peer 2144 Entry. 2145 10. The aforementioned direct bubble is dropped by A's NAT because 2146 the NAT has not seen any outgoing packet sourced from the mapped 2147 address/port embedded in A's Teredo IPv6 Address and destined to 2148 the mapped address/port embedded in B's Teredo IPv6 Address. 2149 11. B then checks if it is positioned behind a port-restricted NAT 2150 or a symmetric NAT. It also checks if the peer has already 2151 advertised a random port. In this case, B is positioned behind 2152 a port-preserving symmetric NAT and the peer has advertised a 2153 random port; hence it needs to use a random port. It checks if 2154 its Random Port field is set to non-zero. Since it is still 2155 zero, B allocates a new random port, begins listening on it, and 2156 stores it in the Random Port entry of the Peer Entry. B then 2157 sends a direct bubble (Packet 4) destined to the mapped address 2158 embedded in A's Teredo IPv6 address and the port stored in the 2159 Peer Random Port field of the Peer Entry. The direct bubble is 2160 sent from its own random port. 2162 12. The above direct bubble is dropped by A's NAT because the NAT 2163 has not seen any outgoing packet sourced from the mapped address 2164 embedded in A's Teredo IPv6 address and random port advertised 2165 by A. 2166 13. B also sends an indirect bubble (Packet 5) destined to A via A's 2167 Teredo server. This indirect bubble includes a Nonce Trailer 2168 and a Random Port Trailer. The Nonce Trailer includes a new 2169 randomly generated nonce that is also stored in the Nonce Sent 2170 field of the Peer Entry. The Random Port Trailer includes the 2171 value in the Random Port field of the Peer Entry. 2172 14. The aforementioned indirect bubble is successfully received by 2173 A. A parses the trailers and stores the nonce contained in the 2174 Nonce Trailer in the Nonce Received field of the Peer Entry. A 2175 stores the port advertised in the Random Port Trailer in the 2176 Random Port field of the Peer Entry. 2177 15. A responds with the following packets in response to the 2178 indirect bubble received. The first packet is a direct bubble 2179 (Packet 6) sent from the primary port and is destined to the 2180 mapped address/port embedded in B's Teredo IPv6 Address. 2181 16. The aforementioned direct bubble again is dropped by B's NAT 2182 because the NAT has not seen an outgoing packet with the same 2183 4-tuple as the incoming packet. 2184 17. The next packet is also a direct bubble (Packet 7) and this one 2185 is sent from A's random port. The packet is destined to the 2186 mapped address embedded in B's Teredo IPv6 address and the Peer 2187 Random Port stored in the Peer Entry. 2188 18. Because both NATs are port-preserving NATs and the random ports 2189 have not been used for any other mapping, the aforementioned 2190 direct bubble is received by B because B's NAT has seen an 2191 outgoing packet (Packet 4) with the same address/port pairs. B 2192 stores the address/port from which the direct bubble was 2193 received in the mapped address/port fields of the Peer Entry. 2194 It changes the status of the peer to "trusted" and sets the 2195 Direct Receive on Random Port field to TRUE. At this point, 2196 communication in one direction is now possible (B to A, but not 2197 vice versa). 2198 19. Because A still considers B to be "not-trusted," it times out 2199 and retransmits an indirect bubble (Packet 8). This packet 2200 contains a new nonce as part of the Nonce Trailer and also 2201 contains the value of the random port as part of the Random Port 2202 Trailer. 2203 20. B receives the aforementioned indirect bubble. The processing 2204 of this indirect bubble is similar to the processing of Packet 2205 2. Since B received a direct bubble on its random port, it does 2206 not respond with a direct bubble from its primary port. 2207 Instead, it responds with a direct bubble (Packet 9) sent from 2208 its random port, which is similar to Packet 4 mentioned above. 2210 21. A receives the direct bubble sent by B. A stores the mapped 2211 address/port from which the direct bubble was received in mapped 2212 address/port fields in the Peer Entry. A changes the status of 2213 B to "trusted" and sets the Direct Receive on Random Port field 2214 to TRUE. At this point, the communication is now possible in 2215 the other direction (A to B). 2217 6.4. Sequential Port-Symmetric NAT Extension 2219 The following protocol example illustrates the use of the Sequential 2220 Port-Symmetric NAT Extension. 2222 Assume that Teredo Client A (A), which is positioned behind a 2223 sequential port-symmetric NAT and implements the Sequential Port- 2224 Symmetric NAT Extension, wants to communicate with Teredo Client B 2225 (B), which is positioned behind a port-restricted NAT that supports 2226 the Port-Preserving Port-Symmetric NAT Extension. The following 2227 packet exchange explains the configuration setup and communication 2228 setup between the two clients. 2230 Teredo A's A's B's 2231 Client Primary Secondary Teredo Client 2232 A NAT Server Server Server NAT B 2233 | | | | | | | 2234 | Direct Bubble to B | | | | | 2235 1 |-------------------------------------------------->| | 2236 | | | | | | | 2237 |Router Solicitation | | | | | 2238 2 |------------------->| | | | | 2239 | | | | | | | 2240 |Router Advertisement| | | | | 2241 |<-------------------| 3 | | | | 2242 | | | | | | | 2243 4 | Direct Bubble to B | | | | | 2244 |-------------------------------------------------->| | 2245 | | | | | | | 2246 | Router Solicitation | | | | 2247 5 |---------------------------->| | | | 2248 | | | | | | | 2249 | Router Advertisement | | | | 2250 |<----------------------------| 6 | | | 2251 | | | | | | | 2252 | Indirect Bubble to B via B's Teredo Server | | | 2253 7 |------------------------------------------->|-------------->| 2254 | | | | | | | 2255 | | | | Direct Bubble to A | 2256 | |<-------------------------------------------------| 8 2257 | | | | | | | 2258 | | | | Indirect Bubble to A | 2259 |<-------------------|<--------------------------------------| 9 2260 | | | | | | | 2261 | | | | Direct Bubble to A | 2262 |<-----------------------------------------------------------| 10 2263 | | | | | | | 2264 | Direct Bubble to B | | | | 2265 11 |----------------------------------------------------------->| 2267 Sequential Port-Symmetric NAT Packet Exchange 2269 1. During the qualification procedure, when Client A receives a 2270 response from the Teredo server, it compares the Port value in 2271 the Origin indication with the Local Port value. Since they are 2272 different, it concludes that it is not behind a port-preserving 2273 NAT, and so assumes it is behind a sequential port-symmetric NAT. 2274 2. When A wants to communicate with B, A starts by sending a direct 2275 bubble (Packet 1) from its primary port. This occurs because 2276 Client A does not know Client B's NAT type, which could be a cone 2277 or address restricted NAT or UPnP-enabled NAT. Because Client A 2278 is behind a symmetric NAT, the external port used by A's NAT is a 2279 new port. This direct bubble will be dropped by B's NAT since 2280 Client B is behind a port-restricted NAT. 2281 3. Because Client A does not know if B is behind a port restricted 2282 NAT or some other kind of NAT, Client A proactively opens a new 2283 random internal port, say, port 1100. 2284 4. Client A then performs its Echo Test as follows: 2285 A. Client A sends a router solicitation (Packet 2) to its Teredo 2286 server address from port 1100. The server responds with a 2287 router advertisement (Packet 3). 2288 B. Client A sends a direct bubble (Packet 4) to the peer from 2289 port 1100 destined to the port advertised in Client B's 2290 Teredo address, say, port 2100. This direct bubble is 2291 dropped by Client B's port-restricted NAT. 2292 C. Client A sends a router solicitation (Packet 5) to its 2293 secondary Teredo server address from port 1100. The server 2294 responds with a router advertisement (Packet 6). 2295 D. On receiving the corresponding router advertisements for 2296 Packet 2 and Packet 4, Client A knows that port 1100 maps to, 2297 say, port 1200 for Packet 2 and port 1202 for Packet 4. 2298 E. Client A then calculates its predicted port used for Packet 2 2299 as the average (rounded down) of 1200 and 1202, i.e., 1201. 2300 5. Client A then sends out an indirect bubble (Packet 7). This 2301 indirect bubble contains a random port trailer that contains the 2302 predicted port, port 1201. This indirect bubble makes it to 2303 Client B. 2304 6. Client B sends out the following bubbles in response to the 2305 indirect bubble: 2306 A. The first direct bubble (Packet 8) is destined for the port 2307 mapping embedded in Client A's Teredo Address. (It has been 2308 observed that some NATs display symmetric NAT behavior for 2309 outgoing packets but cone NAT behavior for incoming packets. 2310 The direct bubble described is likely to succeed if Client 2311 A's NAT displays such a behavior.) Since in this example, 2312 A's NAT is a normal sequential port-symmetric NAT, this 2313 packet is dropped. 2314 B. The second packet is an indirect bubble (Packet 9) sent to 2315 Client A without any trailers since Client B is behind a 2316 port-restricted NAT. 2317 C. The next packet will be a direct bubble (Packet 10) sent to 2318 port 1201. This packet will make it in to Client A since 2319 Client A previously sent an outgoing packet (Packet 4) with 2320 the same four tuple. At this point, communication in one 2321 direction is now possible (A to B, but not vice versa). 2322 7. Client A then sends a direct bubble (Packet 11) to Client B when 2323 it receives Packet 10. This time, the bubble makes it through to 2324 B because it previously sent an outgoing packet (Packet 10) with 2325 the same four tuple. At this point, communication is now 2326 possible in the other direction (B to A). 2328 6.5. Hairpinning Extension 2330 The following protocol example illustrates the use of the Hairpinning 2331 Extension. 2333 In Figure 3 (Section 3.5), Teredo Client A (A) and Teredo Client B 2334 (B) are positioned behind different immediate NATs in a two-layer NAT 2335 topology; that is, the outermost NAT (NAT E) is common to both A and 2336 B but the immediate NATs that they are connected to are different (A 2337 is connected to NAT F while B is connected to NAT G). Further assume 2338 that the immediate NATs that A and B are connected to are UPnP- 2339 enabled (NAT F and NAT G are UPnP-enabled). We assume that NAT E 2340 does not support hairpinning; that is, the NAT does not relay packets 2341 originating from the private address space and destined for the 2342 public address of the NAT, back to the private address of the NAT. 2344 Before starting the qualification procedure, both A and B use UPnP to 2345 reserve port mappings on their respective NATs. They observe that 2346 the UPnP operation succeeds and both clients obtain valid UPnP Mapped 2347 Address/Port values. 2349 Next, both client A and client B implement the qualification 2350 procedure where they determine their mapped address/port values, as 2351 specified in [RFC4380] section 5.2.1. 2353 A and B both compare their UPnP Mapped Address/Port values with the 2354 mapped address/port values obtained through the qualification 2355 procedure. Because both A and B are part of a two-layer NAT 2356 topology, these values will be different. Hence both A and B 2357 continue to hold on to their UPnP Mapped Address/Port. 2359 The following packet exchange shows client A establishing 2360 communication with client B. 2362 Teredo Teredo Client A's Client B's 2363 Client NAT Client NAT NAT Teredo Teredo 2364 A F B G E Server Server 2365 | | | | | | | 2366 | | Direct Bubble to B | | | | 2367 1 |-------------------------------------->| | | 2368 | | | | | | | 2369 | Indirect Bubble to B via B's Teredo Server | 2370 2 |----------------------------------------------------------->| 2371 | | |<----------------------------------------| 2372 | | | | | | | 2373 | | | Direct Bubble to A | | | 2374 3 | | |------------------->| | | 2375 | | | | | | | 2376 | | | Direct | | | | 2377 | | |Bubble to A| | | | 2378 4 | | |---------->| | | | 2379 | | | | | | | 2380 | | | Direct | | | | 2381 | | |Bubble to A| | | | 2382 5 | | |---------->| | | | 2383 |<-----------------------------| | | | 2384 | | | | | | | 2385 | | | Indirect Bubble to A | | 2386 6 | | |---------------------------->| | 2387 |<-----------------------------------------------| | 2388 | | | | | | | 2389 |Direct Bubble to B| | | | | 2390 7 |----------------->| | | | | 2391 | | | | | | | 2393 Hairpinning-based Packet Exchange 2395 1. A sends a direct bubble (Packet 1) to the mapped address/port 2396 embedded in B's Teredo IPv6 address. 2397 2. The aforementioned direct bubble is dropped by NAT E, because it 2398 does not support Hairpinning. 2399 3. A sends out an indirect bubble (Packet 2) destined to B via B's 2400 Teredo Server. In this indirect bubble, A includes an Alternate 2401 Address Trailer that includes both the local address/port and 2402 the UPnP mapped address/port. 2403 4. The aforementioned indirect bubble is received by B. After 2404 parsing the Alternate Address Trailer, B has a total of three 2405 addresses to communicate with: two from the Alternate Address 2406 Trailer and one from the mapped address/port embedded in A's 2407 Teredo IPv6 address. B then responds with the following 2408 packets. The first packet sent by B is a direct bubble (Packet 2409 3) destined to the mapped address/port embedded in A's Teredo 2410 IPv6 address. 2411 5. The aforementioned direct bubble will be dropped by the NAT E 2412 because it does not support Hairpinning. 2413 6. Because the local address/port was the first mapping in the 2414 Alternate Address Trailer, the second direct bubble (Packet 4) 2415 sent by B is destined to the local address/port. 2416 7. The aforementioned direct bubble is dropped because A and B are 2417 positioned behind different NATs and hence have their own 2418 private address space. A's local address is not reachable from 2419 B. 2420 8. The next direct bubble (Packet 5) is sent by B destined to A's 2421 UPnP mapped address/port, which is the second mapping in the 2422 Alternate Address Trailer sent by A. 2423 9. The aforementioned direct bubble is received by A because A's 2424 UPnP-mapped address is reachable from B. A stores the source 2425 address from which the direct bubble was received in the mapped 2426 address/port fields of the Peer Entry, as defined in [RFC4380] 2427 section 5.2. Also, the mapped address status field (as 2428 specified in [RFC4380] section 5.2.3) is changed to "trusted." 2429 At this point, communication in one direction (A to B) is now 2430 possible, but not vice versa because B has not yet marked A as 2431 trusted. 2432 10. B also sends an indirect bubble (Packet 6) to A via A's Teredo 2433 server. As part of the indirect bubble, B also includes an 2434 Alternate Address Trailer, which contains the local address/port 2435 and the UPnP mapped address/port of B. 2436 11. The aforementioned indirect bubble is received by A. After 2437 parsing the Alternate Address Trailer, A adds the two addresses 2438 in the Alternate Address Trailer to the Alternate Address List 2439 in the Peer Entry. Because the peer's mapping is "trusted" 2440 (point 9), A responds with only one direct bubble (Packet 7) 2441 that is sent to the mapped address/port stored in the Peer 2442 Entry. 2443 12. The aforementioned direct bubble is received by B. B records the 2444 mapped address/port from which the direct bubble was received in 2445 the mapped address/port field in its Peer Entry, and changes the 2446 status of the mapped address to "trusted." At this point, 2447 communication is now possible in the other direction (B to A). 2449 6.6. Server Load Reduction Extension 2451 The following protocol example illustrates the use of the Server Load 2452 Reduction Extension. 2454 Assume that Teredo client A (A) has established communication with 2455 Teredo Client B (B). Also assume that at some later point when no 2456 data packets have been exchanged between both clients for more than 2457 30 seconds, the communication needs to be reestablished because A 2458 wants to send a data packet to B. 2460 The following packet exchange helps A reestablish communication with 2461 B. 2463 Teredo Client A's Client B's Teredo 2464 Client Teredo Teredo Client 2465 A NAT Server Server NAT B 2466 | | | | | | 2467 | | | Direct Bubble to B | | | 2468 1 |------------------------------------------------------------>| 2469 | | | | | | 2470 | | | Direct Bubble to A | | | 2471 |<------------------------------------------------------------| 2 2472 | | | | | | 2474 Server Load Reduction Packet Exchange 2476 1. A sends a direct bubble (Packet 1) with the Neighbor Discovery 2477 Option Trailer, with the DiscoveryType field set to 2478 TeredoDiscoverySolicitation. 2479 2. If the mapping on either of the NATs has not expired, the direct 2480 bubble is received by B. B parses the Neighbor Discovery Option 2481 and because the DiscoveryType was set to 2482 TeredoDiscoverySolicitation, B responds with a direct bubble 2483 (Packet 2). B's direct bubble also contains the Neighbor 2484 Discovery Option and the DiscoveryType is set to 2485 TeredoDiscoveryAdvertisement. 2486 3. The aforementioned direct bubble is received by A and at this 2487 point, communication between the Teredo clients is reestablished. 2489 7. Security Considerations 2491 Security considerations are the same as those specified in [RFC4380] 2492 section 7. 2494 In addition, the Hairpinning Extension introduces the possibility of 2495 an amplification attack if a malicious user could advertise a large 2496 number of port mappings in the Alternate Address Trailer, resulting 2497 in a large number of direct bubbles sent in response. Because of 2498 this, Section 4.3 explicitly limits the number of addresses that a 2499 Teredo client will accept. 2501 Because the nonce in the Nonce Trailer is used (as specified in 2502 Section 5.2.4.4) to prevent spoofing of bubbles that would result in 2503 directing traffic to the wrong place, it is important that the nonce 2504 be random so that attackers cannot predict its value. See [RFC4086] 2505 for further discussion of randomness requirements. 2507 8. Acknowledgements 2509 Thanks to Gurpreet Virdi and Poorna Gaddehosur for technical 2510 contributions to this document, and to the V6OPS WG and Jari Arkko 2511 for their helpful reviews. 2513 9. IANA Considerations 2515 IANA will create a new Trailer Type registry. Requests for new 2516 Trailer Type values are made through Specification Required 2517 [RFC5226]. Initial values are listed below. 2519 Trailer Type Usage Reference 2520 ------------ --------------------------------- --------- 2521 0x01 Nonce Trailer RFC 2522 0x02 Random Port Trailer RFC 2523 0x03 Alternate Address Trailer RFC 2524 0x04 Neighbor Discovery Option Trailer RFC 2526 -- RFC Editor to replace with this RFC number 2528 10. References 2530 10.1. Normative References 2532 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 2533 E. Lear, "Address Allocation for Private Internets", 2534 BCP 5, RFC 1918, February 1996. 2536 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2537 Requirement Levels", BCP 14, RFC 2119, March 1997. 2539 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2540 (IPv6) Specification", RFC 2460, December 1998. 2542 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 2543 Network Address Translations (NATs)", RFC 4380, 2544 February 2006. 2546 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2547 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2548 September 2007. 2550 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2551 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2552 May 2008. 2554 [UPNPWANIP] 2555 UPnP Forum, "WANIPConnection:1", November 2001, . 2559 10.2. Informative References 2561 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 2562 Requirements for Security", BCP 106, RFC 4086, June 2005. 2564 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 2565 Message Protocol (ICMPv6) for the Internet Protocol 2566 Version 6 (IPv6) Specification", RFC 4443, March 2006. 2568 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 2569 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 2570 RFC 4787, January 2007. 2572 Author's Address 2574 Dave Thaler 2575 Microsoft Corporation 2576 One Microsoft Way 2577 Redmond, WA 98052 2578 USA 2580 Phone: +1 425 703 8835 2581 Email: dthaler@microsoft.com