idnits 2.17.00 (12 Aug 2021) /tmp/idnits54707/draft-blanchet-v6ops-tunnelbroker-tsp-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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 13 instances of too long lines in the document, the longest one being 17 characters in excess of 72. ** There are 4 instances of lines with control characters in the document. ** The abstract seems to contain references ([3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 443: '...nel. The client MUST send only an IPv...' 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 (February 9, 2004) is 6675 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) -- Looks like a reference, but probably isn't: 'RFC2222' on line 719 -- Looks like a reference, but probably isn't: 'RFC2893' on line 728 == Unused Reference: '2' is defined on line 751, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 757, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 760, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2222 (ref. '1') (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2893 (ref. '2') (Obsoleted by RFC 4213) ** Downref: Normative reference to an Informational RFC: RFC 3053 (ref. '3') -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Blanchet 3 Internet-Draft Hexago 4 Expires: August 9, 2004 February 9, 2004 6 IPv6 Tunnel Broker with the Tunnel Setup Protocol(TSP) 7 draft-blanchet-v6ops-tunnelbroker-tsp-00 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on August 9, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 A tunnel broker with the Tunnel Setup Protocol(TSP) enables the 39 establishment of tunnels of various inner protocols, such as IPv6 or 40 IPv4, inside various outer protocols packets, such as IPv4, IPv6 or 41 UDP over IPv4 for IPv4 NAT traversal. The control protocol (TSP) is 42 used by the tunnel client to negociate the tunnel with the broker. 43 The negociation involves authentication, authorization, tunnel 44 information such as IP addresses, prefixes when the client is a 45 router, DNS information such as the NS for the inverse zone 46 corresponding to the delegated prefix, etc. Some parameters may be 47 proposed by the broker, such as the transport over UDP IPv4 where an 48 IPv4 NAT is found in the path between the client and the broker. A 49 mobile node implementing TSP can be connected to both IPv4 and IPv6 50 networks whether he is on IPv4, IPv4 behind a NAT or on IPv6. A 51 tunnel broker may terminate the tunnels on remote tunnel servers or 52 on itself. This document describes the TSP protocol within the model 53 of the tunnel broker [3]. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Description of the TSP framework . . . . . . . . . . . . . . 4 59 2.1 NAT Discovery . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.2 Any encapsulation . . . . . . . . . . . . . . . . . . . . . 5 61 2.3 Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Advantages of TSP . . . . . . . . . . . . . . . . . . . . . 5 63 4. Protocol Description . . . . . . . . . . . . . . . . . . . . 6 64 4.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.2 Topology . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 4.4 Authentication phase . . . . . . . . . . . . . . . . . . . . 8 68 4.5 Command phase . . . . . . . . . . . . . . . . . . . . . . . 9 69 4.6 XML Messaging . . . . . . . . . . . . . . . . . . . . . . . 10 70 4.6.1 Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 4.6.2 Client element . . . . . . . . . . . . . . . . . . . . . . . 11 72 4.6.3 Server element . . . . . . . . . . . . . . . . . . . . . . . 11 73 4.6.4 broker element . . . . . . . . . . . . . . . . . . . . . . . 11 74 4.7 Tunnel request examples . . . . . . . . . . . . . . . . . . 11 75 4.7.1 Host Tunnel request and Reply . . . . . . . . . . . . . . . 11 76 4.7.2 Router Tunnel request with a /48 prefix delegation, and 77 reply . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 4.7.3 IPv4 in IPv6 tunnel request . . . . . . . . . . . . . . . . 13 79 4.7.4 NAT Traversal tunnel request . . . . . . . . . . . . . . . . 15 80 5. Applicability of TSP in Different Environments . . . . . . . 15 81 5.1 Applicability of TSP in Provider Networks with Enterprise 82 Customers . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 5.2 Applicability of TSP in Provider Networks with Home/Small 84 Office Customers . . . . . . . . . . . . . . . . . . . . . . 16 85 5.3 Applicability of TSP in Enterprise Networks . . . . . . . . 16 86 5.4 Applicability of TSP in Wireless Networks . . . . . . . . . 16 87 5.5 Applicability of TSP in Unmanaged networks . . . . . . . . . 16 88 5.6 Applicability of TSP for Mobile Hosts . . . . . . . . . . . 17 89 5.7 Applicability of TSP for Mobile Networks . . . . . . . . . . 17 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17 91 7. Security Considerations . . . . . . . . . . . . . . . . . . 17 92 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 18 93 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 94 References . . . . . . . . . . . . . . . . . . . . . . . . . 18 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . 18 96 A. DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 97 B. Error codes . . . . . . . . . . . . . . . . . . . . . . . . 19 98 Full Copyright Statement . . . . . . . . . . . . . . . . . . 21 100 1. Introduction 102 This document first describes the TSP framework as well as the 103 different profiles used. It then describes the applicability of TSP 104 in different environments, some were described in the v6ops scenario 105 documents. 107 2. Description of the TSP framework 109 Tunnel Setup Protocol (TSP) is a control/signaling protocol to setup 110 tunnel parameters between two tunnel end-points. TSP is implemented 111 as a tiny client code in the requesting tunnel end-point. The other 112 end-point is the TSP server. TSP uses XML basic messaging over TCP 113 or UDP. The use of XML gives extensibility and easy option 114 processing. 116 Inside a session, TSP can negociate between the two tunnel end- 117 points: 119 o authentication of the users, using any kind of authentication 120 mechanism(through SASL [1]) including anonymous 122 o IPv6 over IPv4 tunnels 124 o IPv4 over IPv6 tunnels 126 o IPv6 over UDP-IPv4 tunnels, when IPv4 NAT are in the path between 127 the two endpoints 129 o IP address allocation for the tunnel endpoints 131 o IPv6 prefix assignment when the client is a router and has a 132 network behind 134 o DNS delegation of the inverse tree, based on the ipv6 prefix 135 assignment 137 o DNS registration of the end point. 139 o Routing protocols 141 The TSP connexion can be established between two nodes, where each 142 node can control a tunnel end-point. In this context, it is possible 143 to have up to 4 parties involved: 1- the tsp client, 2- controlling 144 the requesting tunnel end-point, 3- the tsp server, 4- controlling 145 the receiving tunnel end-point. 1,3 and 4 is the Tunnel Broker 146 model. 1 and 2 can be on the same node, as well as 3 and 4 can be on 147 the same node. 149 From the point of view of an operating system, TSP is implemented as 150 a client application which is able to configure network parameters of 151 the kernel and operating system. 153 2.1 NAT Discovery 155 TSP is also used to discover if a NAT is in the path. In this 156 discovery mode, the client sends a TSP message, containing its source 157 tunnel information (such as its source IPv4 address) and the request 158 for the tunnel over UDP-IPv4 to the TSP server. The TSP server 159 compares the IPv4 source address of the packet with the IPv4 source 160 address in the TSP messaging. If they differ, a NAT was in the path. 162 If an IPv4 NAT is discovered, then UDP-IPv4 encapsulation of the IPv6 163 tunnel is used over the same UDP channel used for TSP, which enables 164 the use of the same NAT address-port mapping for both the TSP session 165 and the IPv6 traffic. A keepalive mechanism is also included to keep 166 the NAT mapping constant. If there is no IPv4 NAT in the path as 167 verified by the tunnel broker, then usual IPv6 in IPv4 encapsulation 168 is used. 170 When the TSP client moves to another network, the same discovery 171 process is done. This IPv4 NAT discovery builds the most effective 172 tunnel for all cases, including in a dynamic situation where the 173 client moves. On the IPv6 layer, if the client have used user 174 authentication, the same IPv6 address and prefix are kept and re- 175 established. On the IPv6 layer, there are no mobility seen. 177 2.2 Any encapsulation 179 TSP is used to negociate IPv6 over IPv4 tunnels, IPv6 over UDP-IPv4 180 tunnels and IPv4 over IPv6 tunnels. IPv4 in IPv6 tunnels are used in 181 the Dual Stack Transition Mechanism (DSTM) together with TSP. 183 2.3 Mobility 185 When a tunnel endpoint changes its underlying IP address (i.e. 186 change of its IPv4 address when doing IPv6 in IPv4 encapsulation), 187 the keepalive mechanism fail and the TSP client reconnects to the 188 broker to re-establish the tunnel. 190 3. Advantages of TSP 192 o A signaling protocol to establish the tunnel: no need to change 193 kernels, routing... 195 o A signaling protocol flexible and extensible 196 o one solution to many encapsulation techniques: v6 in v4, v4 in v6, 197 v6 over udp over v4, ... 199 o prefix assignment 201 o dns delegation 203 o routing negociation 205 o discovery of IPv4 NAT in the path, establishing the most optimized 206 tunnelling technique depending on the discovery. 208 o mobility of the underlying IP node. 210 o two to four tier tunnel broker model 212 o stability of the IP address and prefix, enabling applications 213 needing stable address to be deployed and used. 215 o Tunnels established by TSP are static tunnels, which are more 216 secure than automated tunnels 218 4. Protocol Description 220 4.1 Terminology 222 Tunnel Broker (TB) In a Tunnel Broker model, the broker is taking 223 charge of all communication between Tunnel Servers (TS) and Tunnel 224 Clients (TC). Tunnel clients query brokers for a tunnel and the 225 broker find a suitable tunnel server, ask the Tunnel server to 226 setup the tunnel and send the tunnel information to the Tunnel 227 Client. 229 Tunnel Server (TS) Tunnel Servers are providing the specific tunnel 230 service to a Tunnel Client. It can reveive the tunnel request 231 from a Tunnel Broker (as in the Tunnel Broker model) or directly 232 from the Tunnel Client as in the Tunnel Setup Protocol option. 233 The Tunnel Server is the tunnel end-point. 235 Tunnel Client (TC) The Tunnel Client is the entity that need a tunnel 236 for a particular service or connectivity. A Tunnel Client can be 237 either a host or a router. The tunnel client is the other tunnel 238 end-point. 240 4.2 Topology 242 The following diagrams describe typical TSP scenarios. The goal is 243 to establish a tunnel between Tunnel client and Tunnel server. 245 Tunnel Setup Protocol used on Tunnel Broker model 247 _______________ 248 | TUNNEL BROKER |--> Databases (dns, whois) 249 | | 250 | TSP TSP | 251 | SERVER CLIENT | 252 |_______________| 253 | | 254 __________ | | ________ 255 | | | | | TSP | 256 | TSP |--[TSP]-- +--[TSP]--| SERVER | 257 | CLIENT | | |--[NETWORK]-- 258 [HOST]--| |<==[CONFIGURED TUNNEL]==>| TUNNEL | 259 |___________| | SERVER | 260 |________| 262 Tunnel Setup Protocol used on Tunnel Server model 264 ___________ ________ 265 | | | TSP | 266 | TSP |-----------[TSP]---------| SERVER | 267 | CLIENT | | |--[NETWORK]-- 268 [HOST]--| |<==[CONFIGURED TUNNEL]==>| TUNNEL | 269 |___________| | SERVER | 270 |________| 272 4.3 Overview 274 The Tunnel Setup Protocol has three phases: 276 Authentication phase: The Authentication phase is when the Tunnel 277 Brokers/Servers advertises their capability to Tunnel Clients and 278 when Tunnel clients authenticate to the server. 280 Command phase: The command phase is where the client requests or 281 updates a tunnel. 283 Response phase: The response phase is where the respond to the client 285 For each command sent by a Tunnel Client their is an expected 286 response by the server. 288 4.4 Authentication phase 290 The authentication phase has 3 steps : 292 o Client's protocol version identification 294 o Server's capability advertisement 296 o Client authentication 298 When a TCP (or UDP-reliable) session is established to a Tunnel 299 Server, the Tunnel Client sends the current protocol version it is 300 supporting. The version number syntax is: 302 VERSION=2.0 CR LF 304 Version 2.0 is the version number of this specification. Version 1.0 305 was defined in earlier drafts. 307 If the server doesn't support the protocol version it sends an error 308 message and closes the session. The server can optionally send a 309 server list that may support the protocol version of the client. 311 Example of a Version not supported (without a server list) 313 -- Successful TCP Connection -- 314 C:VERSION=0.1 CR LF 315 S:302 Unsupported client version CR LF 316 -- Connection closed -- 318 Example of a Version not supported (with a server list) 320 -- Successful TCP Connection -- 321 C:VERSION=1.1 CR LF 322 S:1302 Unsupported client version CR LF 323 324 325
1.2.3.4
326 327 328
ts1.isp1.com
329 330 331 -- Connection closed -- 333 If the server supports the version sent by the client, then the 334 server sends a list of the capabilities supported for authentication 335 and tunnels. 337 CAPABILITY TUNNEL=V6V4 AUTH=DIGEST-MD5 AUTH=ANONYMOUS CR LF 339 Tunnel types must be registered with IANA and their profiles are 340 defined in other documents. Authentication is done using SASL [1]. 341 Each authentication mechanism must be a registered SASL mechanism. 342 Description of such mechanism is not in the scope of this document. 344 The Tunnel Client can then choose to close the session if none of the 345 capabilities fits its needs. If the Tunnel Client chooses to 346 continue, it must authenticate itself to the server using one of the 347 adevertised mechanism. If the authentication fails the server sends 348 an error message and closes the session. 350 Example of failed authentication 352 -- Successful TCP Connection -- 353 C:VERSION=2.0 CR LF 354 S:CAPABILITY TUNNEL=V6V4 AUTH=DIGEST-MD5 CR LF 355 C:AUTHENTICATE ANONYMOUS CR LF 356 S:300 Authentication failed CR LF 358 If the authentication succeed, the server sends a success return code 359 and the protocol enter the Command phase. 361 Successful authentication 363 -- Successful TCP Connection -- 364 C:VERSION=2.0 CR LF 365 S:CAPABILITY TUNNEL=V6V4 AUTH=DIGEST-MD5 AUTH=ANONYMOUS CR LF 366 C:AUTHENTICATE ANONYMOUS CR LF 367 S:200 Authentication successful CR LF 369 Upon successful authentication the protocol enters the command phase 370 as described in the next section. 372 4.5 Command phase 374 The Command phase is where the Tunnel Client send a tunnel request or 375 a tunnel update to the server. In this phase, commands are sent as 376 XML messages. The first line is a "Content-length" directive that 377 tells the size of the following XML message. This makes it easier 378 for protocol implementation to tell when they got the whole XML 379 message. When the server sends a response, the first line is the 380 "Content-length" directive, the second is the return code and third 381 one is the XML message if any. The size of the response for the 382 "Content-length" directive is the first character of the return code 383 line to the last character of the XML message. 385 Spaces can be inserted freely. 387 Example of a command/response sequence 389 -- Successful TCP Connection -- 390 C:VERSION=2.0 CR LF 391 S:CAPABILITY TUNNEL=V6V4 AUTH=DIGEST-MD5 AUTH=ANONYMOUS CR LF 392 C:AUTHENTICATE ANONYMOUS CR LF 393 S:200 Authentication successful CR LF 394 C: Content-length: 123 CR LF 395 396 397
1.1.1.1
398 399 CR LF 401 S: Content-length: 234 CR LF 402 200 OK CR LF 403 404 405
206.123.31.114
406
3ffe:b00:c18:ffff:0000:0000:0000:0000
407 408 409
1.1.1.1
410
3ffe:b00:c18:ffff::0000:0000:0000:0001
411
userid.domain
412 413 CR LF 414 -- TCP Connection closed -- 416 4.6 XML Messaging 418 4.6.1 Tunnel 420 The client uses the tunnel token with an action attribute. Valid 421 actions for this profile are : 'create', 'info' and 'delete'. 423 The 'create' action is used to request a new tunnel or update an 424 existing tunnel. The 'info' action is used to request current 425 properties of an existing tunnel. The 'delete' action is used to 426 remove an existing tunnel from the server. 428 The 'tunnel' message contains three elements: 430 client Client's information 431 server Server's information 433 broker List of other server's 435 4.6.2 Client element 437 The client element contains 2 elements: 'address' and 'router'. 438 These elements are used to describe the client needs and will be used 439 by the server to create the appropriate tunnel. This is the only 440 element sent by a client. 442 The 'address' element is used to identify the client IPv4 endpoint of 443 the tunnel. The client MUST send only an IPv4 address to the server. 444 The server will then return the IPv6 address endpoint and domain name 445 inside the 'client' element when the tunnel is created or updated. 447 Optionaly a client can send a 'router' element to ask for a prefix 448 delegation. 450 4.6.3 Server element 452 The 'server' element contains 2 elements: 'address' and 'router'. 453 These elements are used to describe the server's tunnel endpoint. 454 The 'address' element is used to provide both IPv4 and IPv6 addresses 455 of the server's tunnel endpoint, while the 'router' element provides 456 information for the routing method choosen by the client. 458 4.6.4 broker element 460 The 'broker' element is used by a server to provide a alternate list 461 of servers to a client in the case where the server is not able to 462 provide the requested tunnel. 464 The 'broker' element will contain a series of 'address' element. 466 4.7 Tunnel request examples 468 This section presents multiple examples of requests. 470 4.7.1 Host Tunnel request and Reply 472 A simple tunnel request consist of a 'tunnel' element which contains 473 only an 'address' element 474 Simple tunnel request made by a client. 476 -- Successful TCP Connection -- 477 C:VERSION=1.0 CR LF 478 S:CAPABILITY TUNNEL=V6V4 AUTH=ANONYMOUS CR LF 479 C:AUTHENTICATE ANONYMOUS CR LF 480 S:200 Authentication successful CR LF 481 C:Content-length: 123 CR LF 482 483 484
1.1.1.1
485 486 CR LF 487 S: Content-length: 234 CR LF 488 200 OK CR LF 489 490 491
206.123.31.114
492
3ffe:b00:c18:ffff:0000:0000:0000:0000
493 494 495
1.1.1.1
496
3ffe:b00:c18:ffff::0000:0000:0000:0001
497
userid.domain
498 499 CR LF 501 4.7.2 Router Tunnel request with a /48 prefix delegation, and reply 503 A tunnel request with prefix consist of a 'tunnel' element which 504 contains 'address' element and a 'router' element. 506 Tunnel request with prefix and static routes. 508 C: Content-length: 234 CR LF 509 510 511
1.1.1.1
512 513 514 515
2.3.4.5
516
2.3.4.6
517
3ffe:0c00::1
518 519 520 522 CR LF 523 S: Content-length: 234 CR LF 524 200 OK CR LF 525 526 527
206.123.31.114
528
3ffe:b00:c18:ffff:0000:0000:0000:0000
529 530 531
1.1.1.1
532
3ffe:b00:c18:ffff::0000:0000:0000:0001
533
userid.domain
534 535 3ffe:0b00:c18:1234:: 536 537
2.3.4.5
538
2.3.4.6
539
3ffe:0c00::1
540 541 542 543 CR LF 545 4.7.3 IPv4 in IPv6 tunnel request 547 Tunnel type is set to 'v4v6'. 549 Simple tunnel request made by a client. 551 -- Successful TCP Connection -- 552 C:VERSION=1.0 CR LF 553 S:CAPABILITY TUNNEL=V4V6 AUTH=DIGEST-MD5 AUTH=ANONYMOUS CR LF 554 C:AUTHENTICATE ANONYMOUS CR LF 555 S:OK Authentication successful CR LF 556 C:Content-length: 228 CR LF 557 558 559
fe80:0000:0000:0000:0000:0000:0000:0001
561
3ffe:0b00:0c18:ffff:0000:0000:0000:0001
563 564 CR LF 566 If the allocation request is accepted, the broker will acknowledge 567 the allocation to the client by sending a 'tunnel' element with the 568 attribute 'action' set to 'info', 'type' set to 'v4v6' and the 569 'lifetime' attribute set to the period of validity or lease time of 570 the allocation. The 'tunnel' element contains 'server' and 'client' 571 elements. 573 Server response 575 S: Content-length: 370 CR LF 576 200 OK CR LF 577 578 579
206.123.31.2
580
3ffe:b00:c18:ffff:0000:0000:0000:0002
581 582 583
206.123.31.1
584
3ffe:b00:c18:ffff::0000:0000:0000:0001
586 587 CR LF 589 4.7.4 NAT Traversal tunnel request 591 -- Successful TCP Connection -- 592 C:VERSION=1.1 CR LF 593 S:CAPABILITY TUNNEL=V6V4 TUNNEL=V6UDPV4 AUTH=DIGEST-MD5 CR LF 594 C:AUTHENTICATE ... CR LF 595 S:200 Authentication successful CR LF 596 C:Content-length: ... CR LF 597 598 599
10.1.1.1
600 601 CR LF 602 S: Content-length: ... CR LF 603 200 OK CR LF 604 605 606
206.123.31.114
607
3ffe:b00:c18:ffff:0000:0000:0000:0000
608 609 610
10.1.1.1
611
3ffe:b00:c18:ffff::0000:0000:0000:0001
612 613 CR LF 615 5. Applicability of TSP in Different Environments 617 This section describes the applicability of TSP in different 618 environments. 620 5.1 Applicability of TSP in Provider Networks with Enterprise Customers 622 In a provider network where IPv4 is dominant, a tunnelled 623 infrastructure can be used to provider IPv6 services to the 624 enterprise customers, before a full IPv6 native infrastructure is 625 built. In order to start deploying in a controlled manner and to 626 give enterprise customers a prefix, the TSP framework is used. The 627 TSP server can be put in the core, in the aggregation points or in 628 the pops to offer the service to the customers. IPv6 over IPv4 629 encapsulation can be used. If the customers are behind an IPv4 NAT, 630 then IPv6 over UDP-IPv4 encapsulation can be used. TSP can be used 631 in combination of other techniques. 633 5.2 Applicability of TSP in Provider Networks with Home/Small Office 634 Customers 636 In a provider network where IPv4 is dominant, a tunnelled 637 infrastructure can be used to provider IPv6 services to the home/ 638 small office customers, before a full IPv6 native infrastructure is 639 built. The small networks such as Home/Small offices have a non- 640 upgradable gateway with NAT. TSP with NAT traversal is used to offer 641 IPv6 connectivity and a prefix to the internal network. 643 Automation of the prefix assignment and DNS delegation, done by TSP, 644 is a very important feature for a provider in order to substantially 645 decrease support costs. The provider can use the same authentication 646 database that is used to authenticate the IPv4 users. Customers can 647 deploy home IPv6 networks without any intervention of the provider 648 support people. 650 With the NAT discovery function of TSP, providers can use the same 651 TSP infrastructure for both NAT and not-NAT parts of the network. 653 5.3 Applicability of TSP in Enterprise Networks 655 In an enterprise network where IPv4 is dominant, a tunnelled 656 infrastructure can be used to provider IPv6 services to the IPv6 657 islands (hosts or networks) inside the enterprise, before a full IPv6 658 native infrastructure is built. TSP can be used to give IPv6 659 connectivity, prefix and routing for the islands. This gives to the 660 enterprise a full control deployment of IPv6 while maintaining 661 automation and permanence of the IPv6 assignments to the islands. 663 5.4 Applicability of TSP in Wireless Networks 665 In a wireless network where IPv4 is dominant, hosts and networks move 666 and change IPv4 address. TSP enables the automatic re-establishment 667 of the tunnel when the IPv4 address change. 669 In a wireless network where IPv6 is dominant, hosts and networks 670 move. TSP enables the automatic re-establishment of the tunnel 671 together with the DSTM mechasnism. 673 5.5 Applicability of TSP in Unmanaged networks 675 An unmanaged network is where no network manager or staff is 676 available to configure network devices. TSP is particularly powerful 677 in this context where automation of all necessary information for the 678 IPv6 connectivity is handled by TSP: tunnel end-points parameters, 679 prefix assignment, dns delegation, routing. 681 An unmanaged network may be behind a NAT, maybe not. With the NAT 682 discovery function, TSP works automatically in both cases. 684 5.6 Applicability of TSP for Mobile Hosts 686 Mobile hosts are common and used. Laptops moving from wireless, 687 wired in office, home, ... are examples. They often have IPv4 688 connectivity, but not necessarily IPv6. TSP framework enables the 689 mobile hosts to have IPv6 connectivity wherever they are, by having 690 the TSP client sends updated information of the new environment to 691 the TSP server, when a change occur. Together with NAT discovery, 692 the mobile host can be always IPv6 connected wherever it is. 694 Mobile here means only the change of IPv4 address. MobileIP 695 mechanisms and fast handoff take care of additional constraints in 696 mobile environments. 698 5.7 Applicability of TSP for Mobile Networks 700 Mobile networks share the applicability of the mobile hosts. 701 Moreover, in the TSP framework, they also keep their prefix 702 assignment and can control the routing. NAT discovery can also be 703 used. 705 6. IANA Considerations 707 A tunnel type registry should be setup by IANA. The following 708 strings are defined in this document: "v6v4" for IPv6 in IPv4 709 encapsulation (using IPv4 protocol 41) "v6udpv4" for IPv6 in UDP in 710 IPv4 encapsulation "v6anyv4" for IPv6 in IPv4 or IPv6 in UDP in IPv4 711 encapsulation "v4v6" for IPv4 in IPv6 encapsulation. 713 Details on the registration procedure for new tokens TBD. 715 IANA assigned 3653 as the TSP port number. 717 7. Security Considerations 719 Authentication of the TSP session uses the SASL[RFC2222] framework, 720 where the authentication mechanism is negociated between the client 721 and the server. The framework enables to use the level of 722 authentication needed for securing the session, based on the 723 policies. 725 Static tunnels are created when the TSP negociation is terminated. 726 Static tunnels are not open gateways and exhibit less security issues 727 than automated tunnels. Static IPv6 in IPv4 tunnels security 728 considerations are described in [RFC2893]. 730 8. Conclusion 732 The Tunnel Setup Protocol (TSP) is applicable in many environments, 733 such as: providers, enterprises, wireless, unmanaged networks, mobile 734 hosts and networks. TSP gives the two tunnel end-points the ability 735 tonegociate tunnel parameters, as well as prefix assignment, dns 736 delegation and routing in an authenticated session. It also provides 737 IPv4 NAT discovery function by using the most effective 738 encapsulation. It also supports the IPv4 mobility of the nodes. 740 9. Acknowledgements 742 This draft is the merge of many previous drafts about TSP. Authors 743 who have contributed to earlier drafts are: Florent Parent and 744 Octavio Medina. 746 References 748 [1] Myers, J., "Simple Authentication and Security Layer (SASL)", 749 RFC 2222, October 1997. 751 [2] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 752 Hosts and Routers", RFC 2893, August 2000. 754 [3] Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6 Tunnel 755 Broker", RFC 3053, January 2001. 757 [4] Bound, J., "Dual Stack Transition Mechanism (DSTM)", draft-ietf- 758 ngtrans-dstm-08 (work in progress), July 2002. 760 [5] Hagino, J., "Possible abuse against IPv6 transition 761 technologies", July 2000. 763 Author's Address 765 Marc Blanchet 766 Hexago 767 2875 boul. Laurier, suite 300 768 Sainte-Foy, QC G1V 2M2 769 Canada 771 Phone: +1 418 266 5533 772 EMail: Marc.Blanchet@hexago.com 773 URI: http://www.hexago.com/ 775 Appendix A. DTD 777 778 780 781 782 783 785 787 789 791 793 794 796 797 798 ]> 800 Appendix B. Error codes 802 Error codes are sent as a numeric value followed by a text message 803 describing the code. The Tunnel Setup Protocol defines error code 804 numbers 1 through 499 and 1000 through 1499. Profile dependant error 805 codes are defined within the 500 through 999 and 1500 through 1999 806 range. 808 The predefined values are : 810 if a list of tunnel servers is following the error code as a referal 811 service, then 1000 is added to the error code. 813 200 Success 815 Successful operation 817 300 Authentication failed 819 Invalid userid, password or authentication mechanism. 821 301 No more tunnels available 823 The server has reached its capacity limit. 825 302 Unsupported client version 827 The client version is not supported by the server. 829 303 Unsupported tunnel type 831 The server does not provide the requested tunnel type. 833 306 Address Pool Exhausted 835 307 Configuration Error at TEP 837 308 Requested Address Unavailable 839 309 Invalid IPv6 address 841 501 Invalid IPv4 address 843 502 Invalid or duplicate nicname 845 504 Router function not supported 847 506 IPv4 prefix already used for existing tunnel 849 507 Requested prefix length cannot be assigned 851 509 DNS delegation setup error 853 514 Protocol error 855 517 Unsupported router protocol 857 518 Unsupported prefix length 859 520 Missing prefix length 861 Full Copyright Statement 863 Copyright (C) The Internet Society (2004). All Rights Reserved. 865 This document and translations of it may be copied and furnished to 866 others, and derivative works that comment on or otherwise explain it 867 or assist in its implementation may be prepared, copied, published 868 and distributed, in whole or in part, without restriction of any 869 kind, provided that the above copyright notice and this paragraph are 870 included on all such copies and derivative works. However, this 871 document itself may not be modified in any way, such as by removing 872 the copyright notice or references to the Internet Society or other 873 Internet organizations, except as needed for the purpose of 874 developing Internet standards in which case the procedures for 875 copyrights defined in the Internet Standards process must be 876 followed, or as required to translate it into languages other than 877 English. 879 The limited permissions granted above are perpetual and will not be 880 revoked by the Internet Society or its successors or assigns. 882 This document and the information contained herein is provided on an 883 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 884 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 885 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 886 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 887 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 889 Acknowledgement 891 Funding for the RFC Editor function is currently provided by the 892 Internet Society.