idnits 2.17.1 draft-blanchet-v6ops-tunnelbroker-tsp-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1325. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1336. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1343. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1349. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (May 6, 2008) is 5833 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2831 (Obsoleted by RFC 6331) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Blanchet 3 Internet-Draft Viagenie 4 Intended status: Experimental F. Parent 5 Expires: November 7, 2008 Beon Solutions 6 May 6, 2008 8 IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP) 9 draft-blanchet-v6ops-tunnelbroker-tsp-04 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on November 7, 2008. 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 negotiate the tunnel with the broker. A 43 mobile node implementing TSP can be connected to both IPv4 and IPv6 44 networks whether it is on IPv4 only, IPv4 behind a NAT or on IPv6 45 only. A tunnel broker may terminate the tunnels on remote tunnel 46 servers or on itself. This document describes the TSP protocol 47 within the model of the tunnel broker model. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2. Description of the TSP framework . . . . . . . . . . . . . . . 4 53 2.1. NAT Discovery . . . . . . . . . . . . . . . . . . . . . . 6 54 2.2. Any encapsulation . . . . . . . . . . . . . . . . . . . . 6 55 2.3. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 3. Advantages of TSP . . . . . . . . . . . . . . . . . . . . . . 7 57 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 7 58 4.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 59 4.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 4.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 4.4. TSP signaling . . . . . . . . . . . . . . . . . . . . . . 9 62 4.4.1. Signaling transport . . . . . . . . . . . . . . . . . 9 63 4.4.2. Authentication phase . . . . . . . . . . . . . . . . . 11 64 4.4.3. Command and response phase . . . . . . . . . . . . . . 14 65 4.5. Tunnel establishment . . . . . . . . . . . . . . . . . . . 16 66 4.5.1. IPv6-over-IPv4 tunnels . . . . . . . . . . . . . . . . 16 67 4.5.2. IPv6-over-UDP tunnels . . . . . . . . . . . . . . . . 16 68 4.6. Tunnel Keep-alive . . . . . . . . . . . . . . . . . . . . 16 69 4.7. XML Messaging . . . . . . . . . . . . . . . . . . . . . . 17 70 4.7.1. Tunnel . . . . . . . . . . . . . . . . . . . . . . . . 17 71 4.7.2. Client Element . . . . . . . . . . . . . . . . . . . . 18 72 4.7.3. Server Element . . . . . . . . . . . . . . . . . . . . 18 73 4.7.4. Broker Element . . . . . . . . . . . . . . . . . . . . 19 74 5. Tunnel request examples . . . . . . . . . . . . . . . . . . . 19 75 5.1. Host tunnel request and reply . . . . . . . . . . . . . . 19 76 5.2. Router Tunnel request with a /48 prefix delegation, 77 and reply . . . . . . . . . . . . . . . . . . . . . . . . 20 78 5.3. IPv4 over IPv6 tunnel request . . . . . . . . . . . . . . 22 79 5.4. NAT Traversal tunnel request . . . . . . . . . . . . . . . 23 80 6. Applicability of TSP in Different Networks . . . . . . . . . . 24 81 6.1. Provider Networks with Enterprise Customers . . . . . . . 24 82 6.2. Provider Networks with Home/Small Office Customers . . . . 25 83 6.3. Enterprise Networks . . . . . . . . . . . . . . . . . . . 25 84 6.4. Wireless Networks . . . . . . . . . . . . . . . . . . . . 25 85 6.5. Unmanaged networks . . . . . . . . . . . . . . . . . . . . 26 86 6.6. Mobile Hosts and Mobile Networks . . . . . . . . . . . . . 26 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 89 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 27 90 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 92 11.1. Normative References . . . . . . . . . . . . . . . . . . . 28 93 11.2. Informative References . . . . . . . . . . . . . . . . . . 28 94 Appendix A. The TSP DTD . . . . . . . . . . . . . . . . . . . . . 29 95 Appendix B. Error codes . . . . . . . . . . . . . . . . . . . . . 30 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 97 Intellectual Property and Copyright Statements . . . . . . . . . . 32 99 1. Introduction 101 This document first describes the TSP framework, the protocol 102 details, and the different profiles used. It then describes the 103 applicability of TSP in different environments, some of which were 104 described in the v6ops scenario documents. 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 2. Description of the TSP framework 112 Tunnel Setup Protocol (TSP) is a signaling protocol to setup tunnel 113 parameters between two tunnel end-points. TSP is implemented as a 114 tiny client code in the requesting tunnel end-point. The other end- 115 point is the server that will setup the tunnel service. TSP uses XML 116 [W3C.REC-xml-20040204] basic messaging over TCP or UDP. The use of 117 XML gives extensibility and easy option processing. 119 TSP negotiates tunnel parameters between the two tunnel end-points. 120 Parameters that are always negociated are: 122 o authentication of the users, using any kind of authentication 123 mechanism (through SASL [RFC4422]) including anonymous 125 o Tunnel encapsulation 127 * IPv6 over IPv4 tunnels [RFC4213] 129 * IPv4 over IPv6 tunnels [RFC2473] 131 * IPv6 over UDP-IPv4 tunnels for NAT traversal 133 o IP address assignment for the tunnel endpoints 135 o DNS registration of the IP end point address (AAAA) 137 Other tunnel parameters that may be negotiated are: 139 o Tunnel keep-alive 141 o IPv6 prefix assignment when the client is a router 143 o DNS delegation of the inverse tree, based on the IPv6 prefix 144 assigned 146 o Routing protocols 148 The tunnel encapsulation can be explicitly specified by the client, 149 or can be determined during the TSP exchange by the broker. The 150 latter is used to detect the presence of NAT in the path and select 151 IPv6 over UDP-IPv4 encapsulation. 153 The TSP connection can be established between two nodes, where each 154 node can control a tunnel end-point. 156 The nodes involved in the framework are: 158 1. the TSP client 160 2. client tunnel end-point 162 3. the TSP server 164 4. server tunnel end-point 166 1,3 and 4 form the tunnel broker model [RFC3053], where 3 is the 167 tunnel broker and 4 is the tunnel server (Figure 1). The tunnel 168 broker may control one or many tunnel servers. 170 In its simplest model, one node is the client configured as a tunnel 171 end-point (1 and 2 on same node), and the second node is the server 172 configured as the other tunnel end-point (3 and 4 on same node). 173 This model is shown in Figure 2 175 _______________ 176 | TUNNEL BROKER |--> Databases (DNS) 177 | | 178 | TSP | 179 | SERVER | 180 |_______________| 181 | | 182 __________ | | ________ 183 | | | | | | 184 | TSP |--[TSP]-- +---------| | 185 | CLIENT | | TUNNEL |--[NETWORK]-- 186 [HOST]--| |<==[CONFIGURED TUNNEL]==>| SERVER | 187 |___________| | | 188 |________| 190 Figure 1: Tunnel Setup Protocol used on Tunnel Broker model 191 ___________ ________ 192 | | | TSP | 193 | TSP |-----------[TSP]---------| SERVER | 194 | CLIENT | | |--[NETWORK]-- 195 [HOST]--| |<==[CONFIGURED TUNNEL]==>| TUNNEL | 196 |___________| | SERVER | 197 |________| 199 Figure 2: Tunnel Setup Protocol used on Tunnel Server model 201 From the point of view of an operating system, TSP is implemented as 202 a client application which is able to configure network parameters of 203 the operating system. 205 2.1. NAT Discovery 207 TSP is also used to discover if a NAT is in the path. In this 208 discovery mode, the client sends a TSP message over UDP, containing 209 its tunnel request information (such as its source IPv4 address) to 210 the TSP server. The TSP server compares the IPv4 source address of 211 the packet with the address in the TSP message. If they differ, one 212 or many IPv4 NAT is in the path. 214 If an IPv4 NAT is discovered, then IPv6 over UDP-IPv4 tunnel 215 encapsulation is selected. Once the TSP signaling is done, the 216 tunnel is established over the same UDP channel used for TSP, so the 217 same NAT address-port mapping is used for both the TSP session and 218 the IPv6 traffic. If no IPv4 NAT is detected in the path by the TSP 219 server, then IPv6 over IPv4 encapsulation is used. 221 A keep-alive mechanism is also included to keep the NAT mapping 222 active. 224 The IPv4 NAT discovery builds the most effective tunnel for all 225 cases, including in a dynamic situation where the client moves. 227 2.2. Any encapsulation 229 TSP is used to negotiate IPv6 over IPv4 tunnels, IPv6 over UDP-IPv4 230 tunnels and IPv4 over IPv6 tunnels. IPv4 over IPv6 tunnels are used 231 in the Dual Stack Transition Mechanism (DSTM) together with TSP 232 [I-D.bound-dstm-exp]. 234 2.3. Mobility 236 When a node moves to a different IP network (i.e. change of its IPv4 237 address when doing IPv6 over IPv4 encapsulation), the TSP client 238 reconnects automatically to the broker to re-establish the tunnel 239 (keep-alive mechanism). On the IPv6 layer, if the client uses user 240 authentication, the same IPv6 address and prefix are kept and re- 241 established, even if the IPv4 address or tunnel encapsulation type 242 changes. 244 3. Advantages of TSP 246 o Tunnels established by TSP are static tunnels, which are more 247 secure than automated tunnels ([RFC3964]). No 3rd party relay 248 required. 250 o Stability of the IP address and prefix, enabling applications 251 needing stable address to be deployed and used. For example, when 252 tunneling IPv6, there is no dependency on the underlying IPv4 253 address. 255 o Prefix assignment supported. Can use provider address space. 257 o Signaling protocol flexible and extensible (XML, SASL) 259 o One solution to many encapsulation techniques: v6 in v4, v4 in v6, 260 v6 over UDP over v4. Can be extended to other encapsulation 261 types, such as v6 in v6. 263 o Discovery of IPv4 NAT in the path, establishing the most optimized 264 tunnelling technique depending on the discovery. 266 4. Protocol Description 268 4.1. Terminology 270 Tunnel Broker (TB): In a tunnel broker model, the broker is taking 271 charge of all communication between tunnel servers (TS) and tunnel 272 clients (TC). Tunnel clients query brokers for a tunnel and the 273 broker finds a suitable tunnel server, asks the Tunnel server to 274 setup the tunnel and sends the tunnel information to the Tunnel 275 Client. 277 Tunnel Server (TS): Tunnel Servers are providing the specific tunnel 278 service to a Tunnel Client. It can receive the tunnel request 279 from a Tunnel Broker (as in the Tunnel Broker model) or directly 280 from the Tunnel Client. The Tunnel Server is the tunnel end- 281 point. 283 Tunnel Client (TC): The tunnel client is the entity that needs a 284 tunnel for a particular service or connectivity. A tunnel client 285 can be either a host or a router. The tunnel client is the other 286 tunnel end-point. 288 v6v4: IPv6-over-IPv4 tunnel encapsulation 290 v6udpv4: IPv6-over-UDP-over-IPv4 tunnel encapsulation 292 v4v6: IPv4-over-IPv6 tunnel encapsulation 294 4.2. Topology 296 The following diagrams describe typical TSP scenarios. The goal is 297 to establish a tunnel between Tunnel client and Tunnel server. 299 4.3. Overview 301 The Tunnel Setup Protocol is initiated from a client node to a tunnel 302 broker. The Tunnel Setup Protocol has three phases: 304 Authentication phase: The Authentication phase is when the tunnel 305 broker/server advertises its capability to a tunnel client and 306 when a tunnel client authenticate to the broker/server. 308 Command phase: The command phase is where the client requests or 309 updates a tunnel. 311 Response phase: The response phase is where the tunnel client 312 receives the request response from the tunnel broker/server, and 313 the client accepts or rejects the tunnel offered. 315 For each command sent by a Tunnel Client there is an expected 316 response by the server. 318 After the response phase is completed, a tunnel is established as 319 requested by the client. If requested, periodic keep-alive packets 320 can be sent from the client to the server. 322 tunnel tunnel 323 client broker 324 +| Send version + 325 ||---------------------------------> || 326 || Send capabilities || 327 ||<--------------------------------- +| Authentication 328 || SASL authentication || phase 329 ||<--------------------------------> || 330 TSP || Authentication OK || 331 signaling||<--------------------------------- + 332 || Tunnel request || Command 333 ||---------------------------------> || phase 334 || Tunnel response + 335 ||<--------------------------------- || Response 336 || Tunnel acknowledge || phase 337 ||---------------------------------> + 338 +| | 339 || Tunnel established | 340 Data ||===================================| 341 phase || | 342 +| (keep-alive) | 344 Figure 3: Tunnel Setup Protocol exchange 346 4.4. TSP signaling 348 The following sections describes in detail the TSP protocol and the 349 different phases in the TSP signaling. 351 4.4.1. Signaling transport 353 TSP signaling can be transported over TCP or UDP, and over IPv4 or 354 IPv6. The tunnel client selects the transport according to the 355 tunnel encapsulation to be requested. Figure 4 shows the transport 356 used for TSP signaling with possible tunnel encapsulation requested. 358 TSP signaling over UDP/v4 MUST be used if a v6 over UDP over IPv4 359 (v6udpv4) tunnel is to be requested (e.g., for NAT traversal). 361 Tunnel 362 Encapsulation Valid Valid 363 Requested Transport Address family 364 ------------------------------------------ 365 v6anyv4 TCP UDP IPv4 366 v6v4 TCP UDP IPv4 367 v6udpv4 UDP IPv4 368 v4v6 TCP UDP IPv6 370 Figure 4: TSP signaling transport 372 Note that the TSP framework allows for other type of encapsulation to 373 be defined, such as IPv6 over GRE or IPv6 over IPv6. 375 4.4.1.1. TSP signaling over TCP 377 TSP over TCP is sent over port number 3653 (IANA assigned). TSP data 378 used during signaling is detailed in the next sections. 380 +------+-----------+----------+ 381 | IP | TCP | TSP data | 382 | | port 3653 | | 383 +------+-----------+----------+ 384 where IP is IPv4 or IPv6 386 Figure 5: Tunnel Setup Protocol packet format (TCP) 388 4.4.1.2. TSP signaling over UDP/v4 390 While TCP provides the connection-oriented and reliable data delivery 391 features required during the TSP signaling session, UDP does not 392 offer any reliability. This reliability is added inside the TSP 393 session as an extra header at the beginning of the UDP payload. 395 +------+-----------+------------+----------+ 396 | IPv4 | UDP | TSP header | TSP data | 397 | | port 3653 | | | 398 +------+-----------+------------+----------+ 400 Figure 6: Tunnel Setup Protocol packet format (UDP) 402 The algorithm used to add reliability to TSP packets sent over UDP is 403 described in section 22.5 in [UNP]. 405 0 1 2 3 406 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 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | 0xF | Sequence Number | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Timestamp | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | TSP data | 413 ... 415 Figure 7: TSP header for reliable UDP 417 The four bit field (0-3) is set to 0xF. This marker is used by 418 the tunnel broker to identify a TSP signaling packets that is sent 419 after an IPv6 over UDP is established. This is explained in 420 section Section 4.5.2 422 Sequence Number: 28 bit field. Set by the tunnel client. Value is 423 increased by one for every new packet sent to the tunnel broker. 424 The return packet from the broker contains the unaltered sequence 425 number. 427 Timestamp: 32 bit field. Set by the tunnel client. Generated from 428 the client local time value. The return packet from the broker 429 contains the unaltered timestamp. 431 TSP data: Same as in the TCP/v4 case. Content described in latter 432 sections. 434 The TSP client builds its UDP packet as described above and sends it 435 to the tunnel broker. When the tunnel broker responds, the same 436 values for the sequence number and timestamp MUST be sent back to the 437 client. The TSP client can use the timestamp to determine the 438 retransmission timeout (current time minus the packet timestamp). 439 The client SHOULD retransmit the packet when the retransmission 440 timeout is reached. The retransmitted packet MUST use the same 441 sequence number as the original packet so that the server can detect 442 duplicate packets. The client SHOULD use exponential backoff when 443 retransmitting packets to avoid network congestion. 445 4.4.2. Authentication phase 447 The authentication phase has 3 steps : 449 o Client's protocol version identification 450 o Server's capability advertisement 452 o Client authentication 454 When a TCP or UDP session is established to a tunnel broker, the 455 tunnel client sends the current protocol version it is supporting. 456 The version number syntax is: 458 VERSION=2.0.0 CR LF 460 Version 2.0.0 is the version number of this specification. Version 461 1.0.0 was defined in earlier drafts. 463 If the server doesn't support the protocol version it sends an error 464 message and closes the session. The server can optionally send a 465 server list that may support the protocol version of the client. 467 Example of an unsupported client version (without a server list) 469 -- Successful TCP Connection -- 470 C:VERSION=0.1 CR LF 471 S:302 Unsupported client version CR LF 472 -- Connection closed -- 474 Figure 8: Example of unsupported client version 476 Example of a version not supported (with a server list) 478 -- Successful TCP Connection -- 479 C:VERSION=1.1 CR LF 480 S:1302 Unsupported client version CR LF 481 482 483
1.2.3.4
484 485 486
ts1.isp1.com
487 488 489 -- Connection closed -- 491 Figure 9: Example of unsupported client version, with server 492 redirection 494 If the server supports the version sent by the client, then the 495 server sends a list of the capabilities supported for authentication 496 and tunnels. 498 CAPABILITY TUNNEL=V6V4 TUNNEL=V6UDPV4 AUTH=ANONYMOUS AUTH=PLAIN 499 AUTH=DIGEST-MD5 CR LF 501 Tunnel types must be registered with IANA and their profiles are 502 defined in Section 7. Authentication is done using SASL [RFC4422]. 503 Each authentication mechanism should be a registered SASL mechanism. 504 Description of such mechanisms is not in the scope of this document. 506 The tunnel client can then choose to close the session if none of the 507 capabilities fits its needs. If the tunnel client chooses to 508 continue, it authenticates to the server using one of the advertised 509 mechanism using SASL. If the authentication fails, the server sends 510 an error message and closes the session. 512 The example in Figure 10 shows a failed authentication where the 513 tunnel client requests an anonymous authentication which is not 514 supported by the server. 516 Note that linebreaks and indentation within a "C:" or "S:" are 517 editorial and not part of the protocol. 519 -- Successful TCP Connection -- 520 C:VERSION=2.0.0 CR LF 521 S:CAPABILITY TUNNEL=V6V4 AUTH=DIGEST-MD5 CR LF 522 C:AUTHENTICATE ANONYMOUS CR LF 523 S:300 Authentication failed CR LF 525 Figure 10: Example of failed authentication 527 Figure 11 shows a successful anonymous authentication. 529 -- Successful TCP Connection -- 530 C:VERSION=2.0.0 CR LF 531 S:CAPABILITY TUNNEL=V6V4 TUNNEL=V6UDPV4 AUTH=ANONYMOUS AUTH=PLAIN 532 AUTH=DIGEST-MD5 CR LF 533 C:AUTHENTICATE ANONYMOUS CR LF 534 S:200 Success CR LF 536 Figure 11: Successful anonymous authentication 538 Digest-MD5 authentication with SASL follows [RFC2831]. Figure 12 539 shows a successgul digest-md5 SASL authentication. 541 -- Successful TCP Connection -- 542 C:VERSION=2.0.0 CR LF 543 S:CAPABILITY TUNNEL=V6V4 TUNNEL=V6UDPV4 AUTH=ANONYMOUS AUTH=PLAIN 544 AUTH=DIGEST-MD5 CR LF 545 C:AUTHENTICATE DIGEST-MD5 CR LF 546 S:cmVhbG09aGV4b3Msbm9uY2U9MTExMzkwODk2OCxxb3A9YXV0aCxhbGdvcml0aG09bWQ 547 1LXNlc3MsY2hhcnNldD11dGY4 548 C:Y2hhcnNldD11dGY4LHVzZXJuYW1lPSJ1c2VybmFtZTEiLHJlYWxtPSJoZXhvcyIsbm9 549 uY2U9IjExMTM5MDg5NjgiLG5jPTAwMDAwMDAxLGNub25jZT0iMTExMzkyMzMxMSIsZG 550 lnZXN0LXVyaT0idHNwL2hleG9zIixyZXNwb25zZT1mOGU0MmIzYzUwYzU5NzcxODUzZ 551 jYyNzRmY2ZmZDFjYSxxb3A9YXV0aA== 552 S:cnNwYXV0aD03MGQ1Y2FiYzkyMzU1NjhiZTM4MGJhMmM5MDczODFmZQ== 553 S:200 Success CR LF 555 Figure 12: Successful Digest-MD5 authentication 557 The base64-decoded version of the SASL exchange is: 559 S:realm="hexos",nonce="1113908968",qop="auth",algorithm=md5-sess, 560 charset=utf8 561 C:charset=utf8,username="username1",realm="hexos",nonce="1113908968", 562 nc=00000001,cnonce="1113923311",digest-uri="tsp/hexos", 563 response=f8e42b3c50c59771853f6274fcffd1ca,qop=auth 564 S:rspauth=70d5cabc9235568be380ba2c907381fe 566 Once the authentication succeeds, the server sends a success return 567 code and the protocol enters the Command phase. 569 4.4.3. Command and response phase 571 The Command phase is where the tunnel client send a tunnel request or 572 a tunnel update to the server. In this phase, commands are sent as 573 XML messages. The first line is a "Content-length" directive that 574 indicates the size of the following XML message. When the server 575 sends a response, the first line is the "Content-length" directive, 576 the second is the return code and third one is the XML message if 577 any. The "Content-length" is calculated from the first character of 578 the return code line to the last character of the XML message, 579 inclusively. 581 Spaces can be inserted freely. 583 -- UDP session established -- 584 C:VERSION=2.0.0 CR LF 585 S:CAPABILITY TUNNEL=V6V4 TUNNEL=V6UDPV4 AUTH=ANONYMOUS 586 AUTH=PLAIN AUTH=DIGEST-MD5 CR LF 587 C:AUTHENTICATE ANONYMOUS CR LF 588 S:200 Success CR LF 590 C:Content-length: 205 CR LF 591 592 593
192.0.2.135
594 595 596 CR LF 598 S:Content-length: 501 CR LF 599 200 Success CR LF 600 601 602
192.0.2.115
603
604 2001:db8:8000:0000:0000:0000:0000:38b2 605
606 607 608
192.0.2.135
609
610 2001:db8:8000:0000:0000:0000:0000:38b3 611
612 613
614 2001:db8:8000:0000:0000:0000:0000:38b2 615
616 617 618 CR LF 620 C:Content-length: 35 CR LF 621 CR LF 623 Figure 13: Example of a command/response sequence 625 The example in Figure 13 shows a client requesting an anonymous 626 v6udpv4 tunnel, indicating that a keep-alive packet will be sent 627 every 30 seconds. The tunnel broker responds with the tunnel 628 parameters and indicates its acceptance of the keepalive period 629 (Section 4.6). Finally, the client sends an accept message to the 630 server. 632 Once the accept message has been sent, the server and client 633 configure their tunnel endpoint based on the negotiated tunnel 634 parameters. 636 4.5. Tunnel establishment 638 4.5.1. IPv6-over-IPv4 tunnels 640 Once the TSP signaling is completed, a tunnel can be established on 641 the tunnel server and client node. If a v6v4 tunnel has been 642 negotiated, then an IPv6-over-IPv4 tunnel [RFC4213] is established 643 using the operating system tunneling interface. On the client node, 644 this is accomplished by the TSP client calling the appropriate OS 645 commands or system calls. 647 4.5.2. IPv6-over-UDP tunnels 649 If a v6udpv4 tunnel is configured, the same source/destination 650 address and port used during the TSP signaling are used to configure 651 the v6udpv4 tunnel. If a NAT is in the path between the TSP client 652 and tunnel broker, the TSP signaling session will have created a UDP 653 state in the NAT. By reusing the same UDP socket parameters to 654 transport IPv6, the traffic will flow across the NAT using the same 655 state. 657 +------+-----------+--------+ 658 | IPv4 | UDP | IPv6 | 659 | hdr. | port 3653 | | 660 +------+-----------+--------+ 662 Figure 14: IPv6 transport over UDP 664 At any time, a client may re-establish a TSP signaling session. The 665 client disconnects the current tunnel and starts a new TSP signaling 666 session as described in Section 4.4.1.2. If a NAT is present and the 667 new TSP session uses the same UDP mapping in the NAT as for the 668 tunnel, the tunnel broker will need to disconnect the client tunnel 669 before the client can establish a new TSP session. 671 4.6. Tunnel Keep-alive 673 A TSP client may select to send periodic keep-alive messages to the 674 server in order to maintain its tunnel connectivity. This allows the 675 client to detect network changes and enable automatic tunnel re- 676 establishment. In the case of IPv6-over-UDP tunnels, periodic keep- 677 alive can help refresh the connection state in a NAT if such device 678 is in the tunnel path. 680 For IPv6-over-IPv4 and IPv6-over-UDP tunnels, the keep-alive message 681 is an ICMPv6 echo request [RFC4443] sent from the client to the 682 tunnel server. The IPv6 destination address of the echo message MUST 683 be the address from the 'keepalive' element sent in the tunnel 684 response during the TSP signaling (Section 4.4.3). The echo message 685 is sent over the configured tunnel. 687 The tunnel server responds to the ICMPv6 echo requests and can keep 688 track of which tunnel is active. Any client traffic can also be used 689 to verify if the tunnel is active. This can be used by the broker to 690 disconnect tunnels that are no longer in use. 692 The broker can send a different keep-alive interval from the value 693 specified in the client request. The client MUST conform to the 694 broker specified keep-alive interval. The client SHOULD apply a 695 random "jitter" value to avoid synchronization of keep-alive messages 696 from many clients to the server [FJ93]. This is achieved by using an 697 interval value in the range of [0.75T - T], where T is the keep-alive 698 interval specified by the server. 700 4.7. XML Messaging 702 This section describes the XML messaging used in the TSP signaling 703 during the command and response phase. The XML elements and 704 attributes are listed in the DTD (Appendix A). 706 4.7.1. Tunnel 708 The client and server use the tunnel token with an action attribute. 709 Valid actions for this profile are : 'create', 'delete', 'info', 710 'accept' and 'reject'. 712 create: action used to request a new tunnel or update an existing 713 tunnel. Sent by the tunnel client. 715 delete: action used to remove an existing tunnel from the server. 716 Sent by the tunnel client. 718 info: action used to request current properties of an existing 719 tunnel. This action is also used by the tunnel broker to send 720 tunnel parameters following a client 'create' action. 722 accept: action used by the client to acknowledge the server that the 723 tunnel parameters are accepted. The client will establish a 724 tunnel. 726 reject: action used by the client to signal the server that the 727 tunnel parameters offered are rejected and no tunnel will be 728 established. 730 The tunnel 'lifetime' attribute is set by the tunnel broker and 731 specifies the lifetime of the tunnel in minutes. The lifetime is an 732 administratively set value. When a tunnel lifetime is expired, it is 733 disconnected on the tunnel server. 735 The 'tunnel' message contains three elements: 737 : Client's information 739 : Server's information 741 : List of other server's 743 4.7.2. Client Element 745 The client element contains 3 sub-elements: 'address', 'router' and 746 'keepalive'. These elements are used to describe the client request 747 and will be used by the server to create the appropriate tunnel. The 748 client element is the only element sent by a client. 750 The 'address' element is used to identify the client IP endpoint of 751 the tunnel. When tunneling over IPv4, the client MUST send only its 752 IPv4 address to the server. When tunneling over IPv6, the client 753 MUST only send its IPv6 address to the server. 755 The broker then returns the assigned IPv6 or IPv4 address endpoint 756 and domain name inside the 'client' element when the tunnel is 757 created or updated. If supported by the broker, the 'client' element 758 MAY contain the registered DNS name for the address endpoint assigned 759 to the client. 761 Optionally a client MAY send a 'router' element to ask for a prefix 762 delegation. 764 Optionally, a client MAY send a 'keepalive' element which contains 765 the keep-alive time interval requested by the client. 767 4.7.3. Server Element 769 The 'server' element contains 2 elements: 'address' and 'router'. 770 These elements are used to describe the server's tunnel endpoint. 771 The 'address' element is used to provide both IPv4 and IPv6 addresses 772 of the server's tunnel endpoint, while the 'router' element provides 773 information for the routing method chosen by the client. 775 4.7.4. Broker Element 777 The 'broker' element is used by a tunnel broker to provide a 778 alternate list of brokers to a client in the case where the server is 779 not able to provide the requested tunnel. 781 The 'broker' element contains a series of 'address' element(s). 783 5. Tunnel request examples 785 This section presents multiple examples of requests. 787 5.1. Host tunnel request and reply 789 A simple tunnel request consist of a 'tunnel' element which contains 790 only an 'address' element. The tunnel action is 'create', specifying 791 a 'v6v4' tunnel encapsulation type. The response sent by the tunnel 792 broker is an 'info' action. Note that the registered FQDN of the 793 assigned client IPv6 address is also returned to the tunnel client. 795 -- Successful TCP Connection -- 796 C:VERSION=2.0.0 CR LF 797 S:CAPABILITY TUNNEL=V6V4 AUTH=ANONYMOUS CR LF 798 C:AUTHENTICATE ANONYMOUS CR LF 799 S:200 Authentication successful CR LF 800 C:Content-length: 123 CR LF 801 802 803
1.1.1.1
804 805 CR LF 806 S: Content-length: 234 CR LF 807 200 OK CR LF 808 809 810
192.0.2.114
811
812 2001:db8:c18:ffff:0000:0000:0000:0000 813
814 815 816
1.1.1.1
817
818 2001:db8:c18:ffff::0000:0000:0000:0001 819
820
userid.domain
821 822 CR LF 823 C: Content-length: 35 CR LF 824 CR LF 826 Figure 15: Simple tunnel request made by a client 828 5.2. Router Tunnel request with a /48 prefix delegation, and reply 830 A tunnel request with prefix consist of a 'tunnel' element which 831 contains 'address' element and a 'router' element. The 'router' 832 element also contains the 'dns_server' element which is used to 833 request DNS delegation of the assigned IPv6 prefix. The 'dns_server' 834 element lists the IP address of the DNS servers to be registered for 835 the reverse-mapping zone. 837 Tunnel request with prefix and static routes. 839 C: Content-length: 234 CR LF 840 841 842
192.0.2.9
843 844 845 846
192.0.2.5
847
192.0.2.4
848
2001:db8::1
849 850 851 852 CR LF 853 S: Content-length: 234 CR LF 854 200 OK CR LF 855 856 857
192.0.2.114
858
859 2001:db8:c18:ffff:0000:0000:0000:0000 860
861 862 863
192.0.2.9
864
865 2001:db8:c18:ffff::0000:0000:0000:0001 866
867
userid.domain
868 869 2001:db8:c18:1234:: 870 871
192.0.2.5
872
192.0.2.4
873
2001:db8::1
874 875 876 877 CR LF 878 C: Content-length: 35 CR LF 879 CR LF 881 Figure 16: Tunnel request with prefix and DNS delegation 883 5.3. IPv4 over IPv6 tunnel request 885 This is similar to the previous 'create' action, but with the tunnel 886 type is set to 'v4v6'. 888 -- Successful TCP Connection -- 889 C:VERSION=1.0 CR LF 890 S:CAPABILITY TUNNEL=V4V6 AUTH=DIGEST-MD5 AUTH=ANONYMOUS 891 CR LF 892 C:AUTHENTICATE ANONYMOUS CR LF 893 S:OK Authentication successful CR LF 894 C:Content-length: 228 CR LF 895 896 897
898 2001:db8:0c18:ffff:0000:0000:0000:0001 899
900 901 CR LF 903 Simple tunnel request made by a client 905 If the allocation request is accepted, the broker will acknowledge 906 the allocation to the client by sending a 'tunnel' element with the 907 attribute 'action' set to 'info', 'type' set to 'v4v6' and the 908 'lifetime' attribute set to the period of validity or lease time of 909 the allocation. The 'tunnel' element contains 'server' and 'client' 910 elements. 912 S: Content-length: 370 CR LF 913 200 OK CR LF 914 915 916
917 192.0.2.2 918
919
920 2001:db8:c18:ffff:0000:0000:0000:0002 921
922 923 924
925 192.0.2.1 926
927
928 2001:db8:c18:ffff::0000:0000:0000:0001 929
930 931 CR LF 933 IPv4 over IPv6 tunnel response 935 In DSTM [I-D.bound-dstm-exp] terminology, the DSTM server is the TSP 936 broker and the TEP is the tunnel server. 938 5.4. NAT Traversal tunnel request 940 When a client is capable of both IPv6 over IPv4 and IPv6 over UDP 941 over IPv4 encapsulation, it can request the broker, by using the 942 "v6anyv4" tunnel mode, to determine if it is behind a NAT and to send 943 the appropriate tunnel encapsulation mode as part of the response. 944 The client can also explicitly request an IPv6 over UDP over IPv4 945 tunnel by specifying "v6udpv4" in its request. 947 In the following example, the client informs the broker that it 948 requests to send keep-alives every 30 seconds. In its response, the 949 broker accepted the client suggested keep-alive interval, and the 950 IPv6 destination address for the keep-alive packets is specified. 952 C:VERSION=2.0.0 CR LF 953 S:CAPABILITY TUNNEL=V6V4 TUNNEL=V6UDPV4 AUTH=DIGEST-MD5 CR LF 954 C:AUTHENTICATE ... CR LF 955 S:200 Authentication successful CR LF 956 C:Content-length: ... CR LF 957 958 959
10.1.1.1
960 961 962 CR LF 963 S: Content-length: ... CR LF 964 200 OK CR LF 965 966 967
192.0.2.114
968
969 2001:db8:c18:ffff:0000:0000:0000:0002 970
971 972 973
10.1.1.1
974
975 2001:db8:c18:ffff::0000:0000:0000:0003 976
977 978
979 2001:db8:c18:ffff:0000:0000:0000:0002 980
981 982 983 CR LF 985 Tunnel request using v6anyv4 mode 987 6. Applicability of TSP in Different Networks 989 This section describes the applicability of TSP in different 990 networks. 992 6.1. Provider Networks with Enterprise Customers 994 In a provider network where IPv4 is dominant, a tunnelled 995 infrastructure can be used to provide IPv6 services to the enterprise 996 customers, before a full IPv6 native infrastructure is built. In 997 order to start deploying in a controlled manner and to give 998 enterprise customers a prefix, the TSP framework is used. The TSP 999 server can be in the core, in the aggregation points or in the PoPs 1000 to offer the service to the customers. IPv6 over IPv4 encapsulation 1001 can be used. If the customers are behind an IPv4 NAT, then IPv6 over 1002 UDP-IPv4 encapsulation can be used. TSP can be used in combination 1003 of other techniques. 1005 6.2. Provider Networks with Home/Small Office Customers 1007 In a provider network where IPv4 is dominant, a tunnelled 1008 infrastructure can be used to provider IPv6 services to the home/ 1009 small office customers, before a full IPv6 native infrastructure is 1010 built. The small networks such as Home/Small offices have a non- 1011 upgradable gateway with NAT. TSP with NAT traversal is used to offer 1012 IPv6 connectivity and a prefix to the internal network. 1014 Automation of the prefix assignment and DNS delegation, done by TSP, 1015 is a very important feature for a provider in order to substantially 1016 decrease support costs. The provider can use the same AAA database 1017 that is used to authenticate the IPv4 broadband users. Customers can 1018 deploy home IPv6 networks without any intervention of the provider 1019 support people. 1021 With the NAT discovery function of TSP, providers can use the same 1022 TSP infrastructure for both NAT and non-NAT parts of the network. 1024 6.3. Enterprise Networks 1026 In an enterprise network where IPv4 is dominant, a tunnelled 1027 infrastructure can be used to provider IPv6 services to the IPv6 1028 islands (hosts or networks) inside the enterprise, before a full IPv6 1029 native infrastructure is built [RFC4057]. TSP can be used to give 1030 IPv6 connectivity, prefix and routing for the islands. This gives to 1031 the enterprise a full control deployment of IPv6 while maintaining 1032 automation and permanence of the IPv6 assignments to the islands. 1034 6.4. Wireless Networks 1036 In a wireless network where IPv4 is dominant, hosts and networks move 1037 and change IPv4 address. TSP enables the automatic re-establishment 1038 of the tunnel when the IPv4 address change. 1040 In a wireless network where IPv6 is dominant, hosts and networks 1041 move. TSP enables the automatic re-establishment of the IPv4 over 1042 IPv6 tunnel. 1044 6.5. Unmanaged networks 1046 An unmanaged network is where no network manager or staff is 1047 available to configure network devices [RFC3904]. TSP is 1048 particularly useful in this context where automation of all necessary 1049 information for the IPv6 connectivity is handled by TSP: tunnel end- 1050 points parameters, prefix assignment, dns delegation, routing. 1052 An unmanaged network may be behind a NAT, maybe not. With the NAT 1053 discovery function, TSP works automatically in both cases. 1055 6.6. Mobile Hosts and Mobile Networks 1057 Mobile hosts are common and used. Laptops moving from wireless, 1058 wired in office, home, ... are examples. They often have IPv4 1059 connectivity, but not necessarily IPv6. TSP framework enables the 1060 mobile hosts to have IPv6 connectivity wherever they are, by having 1061 the TSP client send updated information of the new environment to the 1062 TSP server, when a change occurs. Together with NAT discovery and 1063 traversal, the mobile host can be always IPv6 connected wherever it 1064 is. 1066 Mobile here means only the change of IPv4 address. Mobile-IP 1067 mechanisms and fast hand-off take care of additional constraints in 1068 mobile environments. 1070 Mobile networks share the applicability of the mobile hosts. 1071 Moreover, in the TSP framework, they also keep their prefix 1072 assignment and can control the routing. NAT discovery can also be 1073 used. 1075 7. IANA Considerations 1077 A tunnel type registry should be setup by IANA. The following 1078 strings are defined in this document: 1080 o "v6v4" for IPv6 in IPv4 encapsulation (using IPv4 protocol 41) 1082 o "v6udpv4" for IPv6 in UDP in IPv4 encapsulation 1084 o "v6anyv4" for IPv6 in IPv4 or IPv6 in UDP in IPv4 encapsulation 1086 o "v4v6" for IPv4 in IPv6 encapsulation. 1088 Registration of a new tunnel type can be obtained on a first come 1089 first served policy [RFC2434]. A new registration should provide a 1090 point of contact, the tunnel type string, and a brief description on 1091 the applicability. 1093 IANA assigned 3653 as the TSP port number. 1095 8. Security Considerations 1097 Authentication of the TSP session uses the SASL [RFC4422] framework, 1098 where the authentication mechanism is negotiated between the client 1099 and the server. The framework uses the level of authentication 1100 needed for securing the session, based on the policies. 1102 Static tunnels are created when the TSP negotiation is terminated. 1103 Static tunnels are not open gateways and exhibit less security issues 1104 than automated tunnels. Static IPv6 in IPv4 tunnels security 1105 considerations are described in [RFC4213]. 1107 In order to help ensure that the traffic is traceable to its correct 1108 source network, a tunnel server implementation should allow ingress 1109 filtering on the user tunnel [RFC3704]. 1111 A customer A behind a NAT can use a large number of (private) IPv4 1112 addresses and/or source ports and request multiple v6udpv4 tunnels. 1113 That would quickly saturate the tunnel server capacity. The tunnel 1114 broker implementation should offer a way to throttle and limit the 1115 number of tunnel established to the same IPv4 address. 1117 9. Conclusion 1119 The Tunnel Setup Protocol (TSP) is applicable in many environments, 1120 such as: providers, enterprises, wireless, unmanaged networks, mobile 1121 hosts and networks. TSP gives the two tunnel end-points the ability 1122 to negotiate tunnel parameters, as well as prefix assignment, dns 1123 delegation and routing in an authenticated session. It also provides 1124 IPv4 NAT discovery function by using the most effective 1125 encapsulation. It also supports the IPv4 mobility of the nodes. 1127 10. Acknowledgements 1129 This draft is the merge of many previous drafts about TSP. Octavio 1130 Medina has contributed to an earlier draft (IPv4 in IPv6). Thanks to 1131 the following people for comments on improving and clarifying this 1132 document: Pekka Savola, Alan Ford, Jeroen Massar and Jean-Francois 1133 Tremblay. 1135 11. References 1137 11.1. Normative References 1139 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1140 Requirement Levels", BCP 14, RFC 2119, March 1997. 1142 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1143 IPv6 Specification", RFC 2473, December 1998. 1145 [RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a 1146 SASL Mechanism", RFC 2831, May 2000. 1148 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1149 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1151 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 1152 Security Layer (SASL)", RFC 4422, June 2006. 1154 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1155 Message Protocol (ICMPv6) for the Internet Protocol 1156 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1158 [W3C.REC-xml-20040204] 1159 Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T., 1160 and E. Maler, "Extensible Markup Language (XML) 1.0 (Third 1161 Edition)", W3C REC REC-xml-20040204, February 2004. 1163 11.2. Informative References 1165 [FJ93] Floyd, S. and V. Jacobson, "The Synchronization of 1166 Periodic Routing Messages", Proceedings of ACM SIGCOMM 1167 '93, September 1993. 1169 [I-D.bound-dstm-exp] 1170 Bound, J., Toutain, L., and JL. Richier, "Dual Stack IPv6 1171 Dominant Transition Mechanism", draft-bound-dstm-exp-04 1172 (work in progress), October 2005. 1174 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1175 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1176 October 1998. 1178 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 1179 Tunnel Broker", RFC 3053, January 2001. 1181 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1182 Networks", BCP 84, RFC 3704, March 2004. 1184 [RFC3904] Huitema, C., Austein, R., Satapati, S., and R. van der 1185 Pol, "Evaluation of IPv6 Transition Mechanisms for 1186 Unmanaged Networks", RFC 3904, September 2004. 1188 [RFC3964] Savola, P. and C. Patel, "Security Considerations for 1189 6to4", RFC 3964, December 2004. 1191 [RFC4057] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, 1192 June 2005. 1194 [UNP] Stevens, R., Fenner, B., and A. Rudoff, "Unix Network 1195 Programming, 3rd edition", Addison Wesley ISBN 0-13- 1196 141155-1, 2004. 1198 Appendix A. The TSP DTD 1200 1201 1203 1205 1207 1209 1211 1213 1215 1217 1219 1220 1222 1223 1224 1226 1227 1228 ]> 1230 Figure 17: TSP DTD 1232 Appendix B. Error codes 1234 Error codes are sent as a numeric value followed by a text message 1235 describing the code, similar to SMTP. The codes are sent from the 1236 broker to the client. The currently defined error codes are showned 1237 below. Upon receiving an error, the client will display the 1238 appropriate message to the user. 1240 New error messages may be defined in the future. For 1241 interoperability purpose, the error code range to use should be from 1242 300 to 599. 1244 The reply code 200 is used to inform the client that an action 1245 successfully completed. For example, this reply code is used in 1246 response to an authentication request and a tunnel creation request. 1248 The server may redirect the client to another broker. The details on 1249 how these brokers are knowned or discovered is beyond the scope of 1250 this document. When a list of tunnel brokers follows the error code 1251 as a referal service, then 1000 is added to the error code. 1253 The predefined values are : 1255 200 Success: Successful operation 1257 300 Authentication failed: Invalid userid, password or 1258 authentication mechanism. 1260 301 No more tunnels available: The server has reached its capacity 1261 limit. 1263 302 Unsupported client version: The client version is not supported 1264 by the server. 1266 303 Unsupported tunnel type: The server does not provide the 1267 requested tunnel type. 1269 310 Server side error: Undefined server error. 1271 500 Invalid request format or specified length: Received request has 1272 invalid syntax or truncated 1274 501 Invalid IPv4 address: IPv4 address specified by the client is 1275 invalid 1277 502 Invalid IPv6 address: IPv6 address specified by the client is 1278 invalid 1280 506 IPv4 address already used for existing tunnel A IPv6-over-IPv4 1281 tunnel already exists using the same IPv4 address endpoints. 1283 507 Requested prefix length cannot be assigned The requested prefix 1284 length cannot be allocated on the server 1286 521 Request already in progress The client tunnel request is being 1287 processed by the server. Temporary error. 1289 530 Server too busy Request cannot be process, insufficient 1290 resources. Temporary error. 1292 Authors' Addresses 1294 Marc Blanchet 1295 Viagenie 1296 2600 boul. Laurier, suite 625 1297 Quebec, QC G1V 4W1 1298 Canada 1300 Phone: +1-418-656-9254 1301 Email: Marc.Blanchet@viagenie.ca 1303 Florent Parent 1304 Beon Solutions 1305 Quebec, QC 1306 Canada 1308 Phone: +1 418 353 0857 1309 Email: Florent.Parent@beon.ca 1311 Full Copyright Statement 1313 Copyright (C) The IETF Trust (2008). 1315 This document is subject to the rights, licenses and restrictions 1316 contained in BCP 78, and except as set forth therein, the authors 1317 retain all their rights. 1319 This document and the information contained herein are provided on an 1320 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1321 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1322 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1323 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1324 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1325 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1327 Intellectual Property 1329 The IETF takes no position regarding the validity or scope of any 1330 Intellectual Property Rights or other rights that might be claimed to 1331 pertain to the implementation or use of the technology described in 1332 this document or the extent to which any license under such rights 1333 might or might not be available; nor does it represent that it has 1334 made any independent effort to identify any such rights. Information 1335 on the procedures with respect to rights in RFC documents can be 1336 found in BCP 78 and BCP 79. 1338 Copies of IPR disclosures made to the IETF Secretariat and any 1339 assurances of licenses to be made available, or the result of an 1340 attempt made to obtain a general license or permission for the use of 1341 such proprietary rights by implementers or users of this 1342 specification can be obtained from the IETF on-line IPR repository at 1343 http://www.ietf.org/ipr. 1345 The IETF invites any interested party to bring to its attention any 1346 copyrights, patents or patent applications, or other proprietary 1347 rights that may cover technology that may be required to implement 1348 this standard. Please address the information to the IETF at 1349 ietf-ipr@ietf.org.