idnits 2.17.1 draft-parent-blanchet-ngtrans-tsp-teredo-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** The abstract seems to contain references ([2], [3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 210: '...'client' element MUST contain one or m...' RFC 2119 keyword, line 214: '...'client' element MAY contain one 'rout...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 24, 2002) is 7970 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) == Unused Reference: '1' is defined on line 451, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 462, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-vg-ngtrans-tsp-v6v4profile-00 -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-01) exists of draft-vg-ngtrans-tsp-00 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-08) exists of draft-ietf-ngtrans-shipworm-05 -- Possible downref: Normative reference to a draft: ref. '3' ** Downref: Normative reference to an Informational RFC: RFC 3053 (ref. '4') ** Obsolete normative reference: RFC 2893 (ref. '5') (Obsoleted by RFC 4213) Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Parent 3 Internet-Draft M. Blanchet 4 Expires: December 23, 2002 Viagenie inc. 5 June 24, 2002 7 TSP-TEREDO: Stateful IPv6 over IPv4 Tunnels with NAT using TSP and 8 TEREDO 9 draft-parent-blanchet-ngtrans-tsp-teredo-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 23, 2002. 34 Copyright Notice 36 Copyright (C) The Internet Society (2002). All Rights Reserved. 38 Abstract 40 Teredo [3] is a stateless mechanism to encapsulate IPv6 traffic in 41 IPv4 when there is an IPv4 NAT between the tunnel endpoints. This 42 document enhances Teredo by providing a stateful IPv6 in IPv4 43 connexion which enables additional features to be used, like 44 permanent IPv6 address or prefixes. It uses the Tunnel Setup 45 Protocol (TSP) [2] to negociate the parameters of the tunnel and 46 identify the NAT translation map. TSP also enables negociation and 47 establishment of prefixes, routing, DNS delegation and other 48 parameters related to the tunnel. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. TSP-Teredo Operation . . . . . . . . . . . . . . . . . . . . 3 54 3. TSP Profile for Teredo . . . . . . . . . . . . . . . . . . . 4 55 3.1 Element 'tunnel' . . . . . . . . . . . . . . . . . . . . . . 4 56 3.1.1 Attribute 'action' . . . . . . . . . . . . . . . . . . . . . 5 57 3.1.2 Attribute 'type' . . . . . . . . . . . . . . . . . . . . . . 5 58 3.1.3 Attribute 'lifetime' . . . . . . . . . . . . . . . . . . . . 5 59 3.2 Element 'server' . . . . . . . . . . . . . . . . . . . . . . 5 60 3.3 Element 'client' . . . . . . . . . . . . . . . . . . . . . . 5 61 3.4 Element 'router' . . . . . . . . . . . . . . . . . . . . . . 6 62 3.5 Element 'dns_server' . . . . . . . . . . . . . . . . . . . . 6 63 3.6 Element 'prefix' . . . . . . . . . . . . . . . . . . . . . . 6 64 3.7 Element 'address' . . . . . . . . . . . . . . . . . . . . . 6 65 4. Tunnel encapsulation negociation . . . . . . . . . . . . . . 7 66 5. Teredo/TSP client and server negociation examples . . . . . 8 67 6. Differences between TSP-Teredo and Teredo . . . . . . . . . 11 68 7. Security considerations . . . . . . . . . . . . . . . . . . 12 69 References . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13 71 A. IPv6 over UDPv4 tunnel DTD . . . . . . . . . . . . . . . . . 13 72 Full Copyright Statement . . . . . . . . . . . . . . . . . . 15 74 1. Introduction 76 Teredo [3] describes a service that enables nodes located behind one 77 or several IPv4 NATs to obtain IPv6 connectivity by tunneling packets 78 over UDP. 80 This document describes how Teredo and TSP can be used together to 81 provide new services to nodes behind an IPv4 NAT such as permanent 82 IPv6 address or prefixes allocation, routing services, DNS delegation 83 and other parameters related to the tunnel. 85 2. TSP-Teredo Operation 87 In order to offer services such as permanent IPv6 address or prefix 88 to clients, the Teredo server must work in stateful mode, where 89 authentication phase is required prior to allocating a prefix to the 90 client. This allows to tie an IPv6 prefix to an identity chosen by 91 the client. This is the scheme proposed in TSP [2] and this document 92 describes how TSP can be used in the Teredo context. 94 In stateless Teredo [3], the initial traffic sent by the client is an 95 IPv6 router solicitation to the Teredo server. By its stateless 96 nature, the Teredo server offers IPv6 connectivity to any client. 98 In the first phase of Teredo operation, the server obtains the IPv4 99 mapped (by NAT) address and UDP port of the client from the IPv6 100 router solicitation received from that client. Using this 101 information, the client prefix is created from the Teredo global 102 prefix space. 104 This document proposes using TSP to allocate the IPv6 address to the 105 client. The address allocated is taken from the global IPv6 address 106 space available to the TSP-Teredo server. 108 The syntax of the protocol is given in Section 3. Tunnel Setup 109 Protocol [2] proposes a two phase process: In the first phase, the 110 client authenticates to the tunnel server. If the authentication is 111 successful, the client can request a tunnel establishement with a 112 permanent (or temporary) prefix. The client prefix assignment is 113 done during the TSP session. 115 In TSP-Teredo mode, the TSP protocol is transported using UDP over 116 IPv4, and the UDP port is the Teredo/TSP server port (to be defined). 117 Upon successful authentication and address allocation, the IPv4 118 mapped (by NAT) address and UDP port of the client from the TSP 119 packet are used to establish an IPv6 over UDP over IPv4 tunnel 120 between the server and client. 122 --------------------------------------------------------------------- 124 Client TSP/UDP/IPv4 Teredo/TSP server 126 | TSP AUTH | 127 | --------------> | 128 | <-------------- | 129 | TSP COMMAND | 130 | --------------> | 131 | <-------------- | 132 | Use IPv4 client address 133 | and UDP client port for 134 | tunnel establishment 135 | | 136 | IPv6/UDP/IPv4 | 137 | <=============> | 138 | tunnel | 140 Figure 1: Client to server initial negociation 142 --------------------------------------------------------------------- 144 3. TSP Profile for Teredo 146 The TSP profile uses a defined DTD (Appendix A) for the XML format of 147 the message. The DTD contains the description of the tunnel XML 148 message. This message is used by the TSP Teredo compliant host and 149 server to provide the necessary information to establish an IPv6 in 150 UDPv4 tunnel. 152 A complete description of the protocol syntax can be found in TSP 153 [2]. Examples of the client/server exchange are given in Section 5. 155 3.1 Element 'tunnel' 157 The TSP message is composed of a 'tunnel' element that contains 0 or 158 one server, client or broker elements. The 'tunnel' element is 159 defined with 3 attributes which describes the 'action' requested in 160 the message, the 'type' of tunnel requested, and the 'lifetime' of 161 that tunnel. 163 The following sections define the different 'tunnel' element 164 attributes 166 3.1.1 Attribute 'action' 168 Three values are possible for this attribute: create, delete and 169 info. 171 create: Sent by the client to request a new tunnel or update an 172 existing tunnel. 174 info: Sent by the client to request current properties of an existing 175 tunnel. Also contains tunnel information sent by server to client 177 delete: Sent by client to remove an existing tunnel on the server. 179 3.1.2 Attribute 'type' 181 Identifies the type of tunnel requested. 183 v6v4: request/allocate an IPv6 in IPv4 [5] tunnel 185 v6udpv4: request/allocate an IPv6 in UDPv4 tunnel 187 v6any: request a tunnel of any type supported. Can only be used when 188 requesting a tunnel 190 3.1.3 Attribute 'lifetime' 192 Length of time (minutes) when the tunnel is valid. This is not the 193 prefix valid or preferred lifetime. Default is 1440 minutes, or 24 194 hours. 196 3.2 Element 'server' 198 This element is used to describe the server tunnel endpoint. The 199 'server' element contains 2 elements: 'address' and 'router'. The 200 'address' element is used to send both IPv4 and IPv6 addresses of the 201 server's tunnel endpoint. The 'router' element may be present to 202 provide information for the routing method choosen by the client. 204 3.3 Element 'client' 206 This element is used to describe the client parameters and will be 207 used by the server to create the appropriate tunnel. This is the 208 only element sent by a client to the server. 210 The 'client' element MUST contain one or more 'address' elements. 211 The server will then return the IPv6 address endpoint and domain name 212 inside the 'client' element when the tunnel is created or updated. 214 The 'client' element MAY contain one 'router' element to ask for a 215 prefix delegation. The 'router' element contains the 'protocol' 216 attribute which specify the routing method to be use between the 217 server and the client. If no attribute is specified the the routing 218 will use static routes. 220 3.4 Element 'router' 222 This element is used by the client to request a prefix delegation. 223 The 'router' element can be specified with an attribute to specify 224 the routing protocol to be used between the client and server. 226 The 'router' element may contain the following elements: 228 prefix: Used by the client to request a prefix length. Used by the 229 server to specify the prefix allocated. 231 dns_server: Used by the client to request DNS delegation for the 232 requestd prefix. 234 as: Used when BGP routing is negociated. 236 3.5 Element 'dns_server' 238 This element is used for DNS delegation of the allocated prefix. The 239 'dns_server' is composed of one or more 'address' elements that 240 specify the name servers used for the delegation. 242 3.6 Element 'prefix' 244 The 'prefix' element has a 'length' attribute that indicates the 245 prefix length. When sent by the client, this element is used to 246 specify the desired prefix length to the server. When sent by the 247 server, both the prefix and prefix length are specified for the 248 client configuration. 250 3.7 Element 'address' 252 In this element, the attribute 'type' is used to specify whether this 253 element represents an IPv4 address, an IPv6 address or a domain name. 254 The attribute 'length' represent the prefix length or netmask of the 255 address, if applicable. 257 4. Tunnel encapsulation negociation 259 Assuming that the Teredo/TSP server supports IPv6 in IPv4 tunnels [5] 260 in addition to IPv6 in UDPv4 , the TSP-Teredo server can negociate 261 with the client on the tunnel that will be established. 263 During the TSP command phase, the Teredo/TSP server is able to detect 264 if the client is behind a NAT by comparing the IPv4 address of the 265 client inside the TSP protocol and the source address of the IPv4 266 header. 268 As shown in Figure 2, the client sends its IPv4 address and the 269 tunnel type requested to the server when requesting a tunnel (command 270 phase). In the example here, the client requested a tunnel type of 271 'v6any' (did not specify the encapsulation type). 273 The server is then able to compare the client IPv4 address from the 274 received packet to the client IPv4 address in the TSP protocol. The 275 server will offer a IPv6 in UDPv4 277 --------------------------------------------------------------------- 279 Client NAT Teredo/TSP server 280 10.0.0.1 10.0.0.1<>9.0.0.1 282 | | | 283 |
10.0.0.1
| 284 | ------------------------------------>| 285 | | 286 | | IPv4 address in packet (9.0.0.1) 287 | | different from IPv4 address 288 | | in TSP protocol (10.0.0.1): 289 | Offer "v6udpv4" tunnel 290 | | 291 | | 292 | <------------------------------------ | 293 ... 295 Figure 2: Server detecting if client behind NAT 297 --------------------------------------------------------------------- 299 5. Teredo/TSP client and server negociation examples 301 The following example demonstrates a client connecting to a Teredo/ 302 TSP server to request a tunnel creation. 304 In the first phase, the server announces its capabilities (can 305 provide both IPv6 in IPv4 and IPv6 in UDP in IPv4 tunnels) and the 306 client authenticates. 308 In the second phase, the client requests a tunnel creation to 309 transport IPv6 inside IPv4 without specifing the exact encapsulation 310 (v6any) (the client may not know if it is behind a NAT or not). The 311 client also sends its IPv4 address to the server. At this stage, the 312 server is able to determine whether the client is behind a NAT by 313 comparing the IPv4 address of the client inside the TSP protocol and 314 the source address of the IPv4 header. 316 In the example below, the server detected that the client is behind a 317 NAT so a v6 over UDPv4 tunnel is negociated to the client (offered 318 tunnel type is v6udpv4). 320 -- Successful TCP Connection -- 321 C:VERSION=1.1 CR LF 323 remove attribute. add tunnel=v6udpv4 324 S:CAPABILITY TUNNEL=V6V4 TUNNEL=V6UDPV4 AUTH=DIGEST-MD5 CR LF 325 C:AUTHENTICATE ... CR LF 326 S:200 Authentication successful CR LF 328 C:Content-length: ... CR LF 329 330 331
10.1.1.1
332 333 CR LF 334 S: Content-length: ... CR LF 335 200 OK CR LF 336 337 338
206.123.31.114
339
3ffe:b00:c18:ffff:0000:0000:0000:0000
340 341 342
10.1.1.1
343
3ffe:b00:c18:ffff::0000:0000:0000:0001
344 345 CR LF 347 In the next example, the server determines that the client is not 348 behind a NAT so the client is offered a standard IPv6 in IPv4 tunnel 349 [ref]. 351 -- Successful TCP Connection -- 352 C:VERSION=1.1 CR LF 353 S:CAPABILITY TUNNEL=V6V4 TUNNEL=V6UDPV4 AUTH=DIGEST-MD5 CR LF 354 C:AUTHENTICATE ... CR LF 355 S:200 Authentication successful CR LF 357 C:Content-length: ... CR LF 358 359 360
9.1.1.1
361 362 CR LF 363 S: Content-length: ... CR LF 364 200 OK CR LF 365 366 367
206.123.31.114
368
3ffe:b00:c18:ffff:0000:0000:0000:0000
369 370 371
9.1.1.1
372
3ffe:b00:c18:ffff::0000:0000:0000:0001
373 374 CR LF 376 This example shows a client requesting a tunnel and an 48-bit IPv6 377 prefix. The server detected that the client is behind a NAT so a 378 Teredo tunnel is negociated to the client (offered tunnel type is 379 v6udpv4). 381 -- Successful TCP Connection -- 382 C:VERSION=1.1 CR LF 383 S:CAPABILITY TUNNEL=V6V4 TUNNEL=V6UDPV4 AUTH=DIGEST-MD5 CR LF 384 C:AUTHENTICATE ... CR LF 385 S:200 Authentication successful CR LF 387 C:Content-length: ... CR LF 388 389 390
10.1.1.1
391 392 393 394 395 CR LF 396 S: Content-length: ... CR LF 397 200 OK CR LF 398 399 400
206.123.31.114
401
3ffe:b00:c18:ffff:0000:0000:0000:0000
402 403 404
10.1.1.1
405
3ffe:b00:c18:ffff::0000:0000:0000:0001
406 407 3ffe:0b00:c18:1234:: 408 409 410 CR LF 412 6. Differences between TSP-Teredo and Teredo 414 This proposal describes how Teredo can use TSP to provide new 415 services to clients. This section describes some of the new features 416 and differences in Teredo with TSP: 418 o Client can be a host or a router. As a router, the client can 419 receive an IPv6 prefix from the server. 421 o The IPv6 address (and prefix) assigned to the client is taken from 422 the global address space available to the service provider. There 423 is no need to embed the IPv4 and the UDP port number inside the 424 IPv6 address assigned to the client. 426 o The client IPv6 address and prefix are fixed. This has many 427 benefits such as permitting the client to deploy services that 428 require stable IPv6 addresses. 430 o If the NAT mapping for the client change, the tunnel needs to be 431 re-established through TSP. But the client IPv6 address does not 432 change. 434 o The client IPv6 address doesn't contain information that can be 435 considered sensitive (NAT mapping of the client, firewall state). 437 o Client IPv6 traffic is always routed to its associated TSP/Teredo 438 server. This is similar to an environment where clients dialup to 439 the enterprise NAS. This may lead to sub-optimal IPv6 routing 440 compared with stateless Teredo where the IPv6 traffic is routed to 441 the closest Teredo relay. 443 o Client is authenticated. 445 7. Security considerations 447 TBD 449 References 451 [1] Blanchet, M., "IPv6 over IPv4 profile for Tunnel Setup Protocol 452 (TSP)", draft-vg-ngtrans-tsp-v6v4profile-00 (work in progress), 453 July 2001. 455 [2] Blanchet, M., "Tunnel Setup Protocol (TSP)", draft-vg-ngtrans- 456 tsp-00 (work in progress), July 2001. 458 [3] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", 459 draft-ietf-ngtrans-shipworm-05 (work in progress), February 460 2002. 462 [4] Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6 Tunnel 463 Broker", RFC 3053, January 2001. 465 [5] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 466 Hosts and Routers", RFC 2893, August 2000. 468 Authors' Addresses 470 Florent Parent 471 Viagenie inc. 472 2875 boul. Laurier, bureau 300 473 Sainte-Foy, QC G1V 2M2 474 Canada 476 Phone: +1 418 656 9254 477 EMail: Florent.Parent@viagenie.qc.ca 478 URI: http://www.viagenie.qc.ca/ 480 Marc Blanchet 481 Viagenie inc. 482 2875 boul. Laurier, bureau 300 483 Sainte-Foy, QC G1V 2M2 484 Canada 486 Phone: +1 418 656 9254 487 EMail: Marc.Blanchet@viagenie.qc.ca 488 URI: http://www.viagenie.qc.ca/ 490 Appendix A. IPv6 over UDPv4 tunnel DTD 491 493 497 498 499 501 503 505 507 508 510 512 513 515 516 518 519 520 522 ]> 524 Full Copyright Statement 526 Copyright (C) The Internet Society (2002). All Rights Reserved. 528 This document and translations of it may be copied and furnished to 529 others, and derivative works that comment on or otherwise explain it 530 or assist in its implementation may be prepared, copied, published 531 and distributed, in whole or in part, without restriction of any 532 kind, provided that the above copyright notice and this paragraph are 533 included on all such copies and derivative works. However, this 534 document itself may not be modified in any way, such as by removing 535 the copyright notice or references to the Internet Society or other 536 Internet organizations, except as needed for the purpose of 537 developing Internet standards in which case the procedures for 538 copyrights defined in the Internet Standards process must be 539 followed, or as required to translate it into languages other than 540 English. 542 The limited permissions granted above are perpetual and will not be 543 revoked by the Internet Society or its successors or assigns. 545 This document and the information contained herein is provided on an 546 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 547 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 548 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 549 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 550 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 552 Acknowledgement 554 Funding for the RFC Editor function is currently provided by the 555 Internet Society.