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.