[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 RFC 5572

Network Working Group                                        M. Blanchet
Internet-Draft                                                 F. Parent
Expires: December 13, 2004                                        Hexago
                                                           June 14, 2004


        IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)
                draft-blanchet-v6ops-tunnelbroker-tsp-01

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 13, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   A tunnel broker with the Tunnel Setup Protocol (TSP) enables the
   establishment of tunnels of various inner protocols, such as IPv6 or
   IPv4, inside various outer protocols packets, such as IPv4, IPv6 or
   UDP over IPv4 for IPv4 NAT traversal.  The control protocol (TSP) is
   used by the tunnel client to negotiate the tunnel with the broker.  A
   mobile node implementing TSP can be connected to both IPv4 and IPv6
   networks whether it is on IPv4 only, IPv4 behind a NAT or on IPv6
   only.  A tunnel broker may terminate the tunnels on remote tunnel
   servers or on itself.  This document describes the TSP protocol



Blanchet & Parent      Expires December 13, 2004                [Page 1]

Internet-Draft        Tunnel Setup Protocol (TSP)              June 2004


   within the model of the tunnel broker model.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Description of the TSP framework . . . . . . . . . . . . . . .  4
     2.1   NAT Discovery  . . . . . . . . . . . . . . . . . . . . . .  6
     2.2   Any encapsulation  . . . . . . . . . . . . . . . . . . . .  6
     2.3   Mobility . . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.  Advantages of TSP  . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Protocol Description . . . . . . . . . . . . . . . . . . . . .  7
     4.1   Terminology  . . . . . . . . . . . . . . . . . . . . . . .  7
     4.2   Topology . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.3   Overview . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.4   TSP signaling  . . . . . . . . . . . . . . . . . . . . . .  9
       4.4.1   Signaling transport  . . . . . . . . . . . . . . . . .  9
       4.4.2   Authentication phase . . . . . . . . . . . . . . . . . 11
       4.4.3   Command and response phase . . . . . . . . . . . . . . 13
     4.5   Tunnel establishment . . . . . . . . . . . . . . . . . . . 14
       4.5.1   IPv6-over-IPv4 tunnels . . . . . . . . . . . . . . . . 14
       4.5.2   IPv6-over-UDP tunnels  . . . . . . . . . . . . . . . . 15
     4.6   Tunnel Keep-alive  . . . . . . . . . . . . . . . . . . . . 15
     4.7   XML Messaging  . . . . . . . . . . . . . . . . . . . . . . 16
       4.7.1   Tunnel . . . . . . . . . . . . . . . . . . . . . . . . 16
       4.7.2   Client Element . . . . . . . . . . . . . . . . . . . . 17
       4.7.3   Server Element . . . . . . . . . . . . . . . . . . . . 17
       4.7.4   Broker Element . . . . . . . . . . . . . . . . . . . . 17
   5.  Tunnel request examples  . . . . . . . . . . . . . . . . . . . 17
     5.1   Host tunnel request and reply  . . . . . . . . . . . . . . 17
     5.2   Router Tunnel request with a /48 prefix delegation,
           and reply  . . . . . . . . . . . . . . . . . . . . . . . . 18
     5.3   IPv4 over IPv6 tunnel request  . . . . . . . . . . . . . . 19
     5.4   NAT Traversal tunnel request . . . . . . . . . . . . . . . 20
   6.  Applicability of TSP in Different Environments . . . . . . . . 21
     6.1   Applicability of TSP in Provider Networks with
           Enterprise Customers . . . . . . . . . . . . . . . . . . . 21
     6.2   Applicability of TSP in Provider Networks with
           Home/Small Office Customers  . . . . . . . . . . . . . . . 22
     6.3   Applicability of TSP in Enterprise Networks  . . . . . . . 22
     6.4   Applicability of TSP in Wireless Networks  . . . . . . . . 22
     6.5   Applicability of TSP in Unmanaged networks . . . . . . . . 22
     6.6   Applicability of TSP for Mobile Hosts and Mobile
           Networks . . . . . . . . . . . . . . . . . . . . . . . . . 23
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23
   9.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 24
   10.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 24



Blanchet & Parent      Expires December 13, 2004                [Page 2]

Internet-Draft        Tunnel Setup Protocol (TSP)              June 2004


   11.1  Normative References . . . . . . . . . . . . . . . . . . . . 24
   11.2  Informative References . . . . . . . . . . . . . . . . . . . 24
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
   A.  The TSP DTD  . . . . . . . . . . . . . . . . . . . . . . . . . 26
   B.  Error codes  . . . . . . . . . . . . . . . . . . . . . . . . . 26
       Intellectual Property and Copyright Statements . . . . . . . . 28













































Blanchet & Parent      Expires December 13, 2004                [Page 3]

Internet-Draft        Tunnel Setup Protocol (TSP)              June 2004


1.  Introduction

   This document first describes the TSP framework, the protocol
   details, and the different profiles used.  It then describes the
   applicability of TSP in different environments, some of which were
   described in the v6ops scenario documents.

2.  Description of the TSP framework

   Tunnel Setup Protocol (TSP) is a signaling protocol to setup tunnel
   parameters between two tunnel end-points.  TSP is implemented as a
   tiny client code in the requesting tunnel end-point.  The other
   end-point is the server that will setup the tunnel service.  TSP uses
   XML basic messaging over TCP or UDP.  The use of XML gives
   extensibility and easy option processing.

   Inside a session, TSP can negotiate between the two tunnel
   end-points:

   o  authentication of the users, using any kind of authentication
      mechanism (through SASL [RFC2222]) including anonymous

   o  Tunnel encapsulation

      *  IPv6 over IPv4 tunnels [RFC2893]

      *  IPv4 over IPv6 tunnels

      *  IPv6 over UDP-IPv4 tunnels

   o  IP address assignment for the tunnel endpoints

   o  IPv6 prefix assignment when the client is a router and has a
      network behind itself

   o  DNS delegation of the inverse tree, based on the ipv6 prefix
      assignment

   o  DNS registration of the end point.

   o  Routing protocols

   The tunnel encapsulation can be explicitly specified by the client,
   or can be determined during the TSP exchange.  The latter is used to
   detect the presence of NAT in the path and select IPv6 over UDP
   encapsulation.

   The TSP connection can be established between two nodes, where each



Blanchet & Parent      Expires December 13, 2004                [Page 4]

Internet-Draft        Tunnel Setup Protocol (TSP)              June 2004


   node can control a tunnel end-point.

   The nodes involved in the framework are:

   1.  the TSP client

   2.  client tunnel end-point

   3.  the TSP server

   4.  server tunnel end-point

   1,3 and 4 form the tunnel broker model [RFC3053], where 3 is the
   tunnel broker and 4 is the tunnel server (Figure 1).  The tunnel
   broker may control one or many tunnel servers.

   In its simplest model, one node is the client configured as a tunnel
   end-point (1 and 2 on same node), and the second node is the server
   configured as the other tunnel end-point (3 and 4 on same node).
   This model is shown in Figure 2

                              _______________
                             | TUNNEL BROKER |--> Databases (DNS)
                             |               |
                             |  TSP    TSP   |
                             | SERVER CLIENT |
                             |_______________|
                                 |     |
            __________           |     |          ________
           |           |         |     |         |  TSP   |
           |   TSP     |--[TSP]--      +--[TSP]--| SERVER |
           |  CLIENT   |                         |        |--[NETWORK]--
   [HOST]--|           |<==[CONFIGURED TUNNEL]==>| TUNNEL |
           |___________|                         | SERVER |
                                                 |________|

      Figure 1: Tunnel Setup Protocol used on Tunnel Broker model














Blanchet & Parent      Expires December 13, 2004                [Page 5]

Internet-Draft        Tunnel Setup Protocol (TSP)              June 2004


            ___________                           ________
           |           |                         |  TSP   |
           |   TSP     |-----------[TSP]---------| SERVER |
           |  CLIENT   |                         |        |--[NETWORK]--
   [HOST]--|           |<==[CONFIGURED TUNNEL]==>| TUNNEL |
           |___________|                         | SERVER |
                                                 |________|

      Figure 2: Tunnel Setup Protocol used on Tunnel Server model

   From the point of view of an operating system, TSP is implemented as
   a client application which is able to configure network parameters of
   the operating system.

2.1  NAT Discovery

   TSP is also used to discover if a NAT is in the path.  In this
   discovery mode, the client sends a TSP message over UDP, containing
   its tunnel request information (such as its source IPv4 address) to
   the TSP server.  The TSP server compares the IPv4 source address of
   the packet with the address in the TSP message.  If they differ, an
   IPv4 NAT is in the path.

   If an IPv4 NAT is discovered, then IPv6 over UDP-IPv4 tunnel
   encapsulation is selected.  Once the TSP signaling is done, the
   tunnel is established over the same UDP channel used for TSP, so the
   same NAT address-port mapping is used for both the TSP session and
   the IPv6 traffic.  If there is no IPv4 NAT is detected in the path by
   the TSP server, then IPv6 over IPv4 encapsulation is used.

   A keep-alive mechanism is also included to keep the NAT mapping
   active.

   The IPv4 NAT discovery builds the most effective tunnel for all
   cases, including in a dynamic situation where the client moves.  On
   the IPv6 layer, if the client uses user authentication, the same IPv6
   address and prefix are kept and re-established.  On the IPv6 layer,
   there is no change of address.

2.2  Any encapsulation

   TSP is used to negotiate IPv6 over IPv4 tunnels, IPv6 over UDP-IPv4
   tunnels and IPv4 over IPv6 tunnels.  IPv4 over IPv6 tunnels are used
   in the Dual Stack Transition Mechanism (DSTM) together with TSP
   [I-D.ietf-ngtrans-dstm].






Blanchet & Parent      Expires December 13, 2004                [Page 6]

Internet-Draft        Tunnel Setup Protocol (TSP)              June 2004


2.3  Mobility

   When a tunnel endpoint changes its underlying IP address (i.e.
   change of its IPv4 address when doing IPv6 over IPv4 encapsulation),
   the keep-alive mechanism detects a failure and the TSP client
   reconnects automatically to the broker to re-establish the tunnel.

3.  Advantages of TSP

   o  signaling protocol to establish a configured tunnel.  No 3rd party
      relay required.

   o  signaling protocol flexible and extensible (XML, SASL)

   o  one solution to many encapsulation techniques: v6 in v4, v4 in v6,
      v6 over UDP over v4, ...

   o  prefix assignment

   o  DNS delegation

   o  discovery of IPv4 NAT in the path, establishing the most optimized
      tunnelling technique depending on the discovery.

   o  mobility of the underlying IP node.

   o  stability of the IP address and prefix, enabling applications
      needing stable address to be deployed and used.  For example, when
      tunneling IPv6, there is no dependency on the underlying IPv4
      address.

   o  tunnels established by TSP are static tunnels, which are more
      secure than automated tunnels


4.  Protocol Description

4.1  Terminology

   Tunnel Broker (TB): In a tunnel broker model, the broker is taking
      charge of all communication between tunnel servers (TS) and tunnel
      clients (TC).  Tunnel clients query brokers for a tunnel and the
      broker finds a suitable tunnel server, asks the Tunnel server to
      setup the tunnel and sends the tunnel information to the Tunnel
      Client.






Blanchet & Parent      Expires December 13, 2004                [Page 7]

Internet-Draft        Tunnel Setup Protocol (TSP)              June 2004


   Tunnel Server (TS): Tunnel Servers are providing the specific tunnel
      service to a Tunnel Client.  It can receive the tunnel request
      from a Tunnel Broker (as in the Tunnel Broker model) or directly
      from the Tunnel Client.  The Tunnel Server is the tunnel
      end-point.

   Tunnel Client (TC): The tunnel client is the entity that needs a
      tunnel for a particular service or connectivity.  A tunnel client
      can be either a host or a router.  The tunnel client is the other
      tunnel end-point.

   v6v4: IPv6-over-IPv4 tunnel encapsulation

   v6udpv4: IPv6-over-UDP-over-IPv4 tunnel encapsulation

   v4v6: IPv4-over-IPv6 tunnel encapsulation


4.2  Topology

   The following diagrams describe typical TSP scenarios.  The goal is
   to establish a tunnel between Tunnel client and Tunnel server.

4.3  Overview

   The Tunnel Setup Protocol is initiated from a client node to a tunnel
   broker.  The Tunnel Setup Protocol has three phases:

   Authentication phase: The Authentication phase is when the tunnel
      broker/server advertises its capability to a tunnel client and
      when a tunnel client authenticate to the broker/server.

   Command phase: The command phase is where the client requests or
      updates a tunnel.

   Response phase: The response phase is where the tunnel client
      receives the request response from the tunnel broker/server, and
      the client accepts or rejects the tunnel offered.

   For each command sent by a Tunnel Client there is an expected
   response by the server.

   After the response phase is completed, a tunnel is established as
   requested by the client.  If requested, periodic keep-alive packets
   can be sent from the client to the server.






Blanchet & Parent      Expires December 13, 2004                [Page 8]

Internet-Draft        Tunnel Setup Protocol (TSP)              June 2004


           tunnel                              tunnel
           client                              broker
             +|         Send version              +
             ||---------------------------------> ||
             ||         Send capabilities         ||
             ||<--------------------------------- +| Authentication
             ||         SASL authentication       || phase
             ||<--------------------------------> ||
    TSP      ||         Authentication OK         ||
    signaling||<--------------------------------- +
             ||         Tunnel request            || Command
             ||---------------------------------> || phase
             ||         Tunnel response           +
             ||<--------------------------------- || Response
             ||         Tunnel acknowledge        || phase
             ||---------------------------------> +
             +|                                   |
             ||         Tunnel established        |
    Data     ||===================================|
    phase    ||                                   |
             +|           (keep-alive)            |




                Figure 3: Tunnel Setup Protocol exchange


4.4  TSP signaling

   The following sections describes in detail the TSP protocol and the
   different phases in the TSP signaling.

4.4.1  Signaling transport

   TSP signaling can be transported over TCP or UDP, and over IPv4 or
   IPv6.  The tunnel client selects the transport according to the
   tunnel encapsulation to be requested.  For example, if a v6 over UDP
   over IPv4 (v6udpv4) tunnel is to be requested, the TSP signaling will
   be sent over UDP/v4.

   Figure 4 shows the transport used for TSP signaling with possible
   tunnel encapsulation requested.








Blanchet & Parent      Expires December 13, 2004                [Page 9]

Internet-Draft        Tunnel Setup Protocol (TSP)              June 2004


       Tunnel
       Encapsulation   Valid       Valid
       Requested       Transport   Address family
       ------------------------------------------
       v6v4            TCP UDP     IPv4
       v6udpv4             UDP     IPv4
       v4v6            TCP UDP     IPv6


                   Figure 4: TSP signaling transport

   Note that the TSP framework allows for other type of encapsulation to
   be defined, such as IPv6 over GRE.

4.4.1.1  TSP signaling over TCP/v4

   TSP over TCP/v4 is sent over port number 3653 (IANA assigned).  TSP
   data used during signaling is detailed in the next sections.


                   +------+-----------+----------+
                   | IPv4 | TCP       | TSP data |
                   |      | port 3653 |          |
                   +------+-----------+----------+


          Figure 5: Tunnel Setup Protocol packet format (TCP)


4.4.1.2  TSP signaling over UDP/v4

   While TCP provides the connection-oriented and reliable data delivery
   features required during the TSP signaling session, UDP does not
   offer any reliability.  This reliability is added inside the TSP
   session as an extra header at the beginning of the UDP payload.

                   +------+-----------+------------+----------+
                   | IPv4 | UDP       | TSP header | TSP data |
                   |      | port 3653 |            |          |
                   +------+-----------+------------+----------+

          Figure 6: Tunnel Setup Protocol packet format (UDP)

   The algorithm used to add reliability to TSP packets sent over UDP is
   described in section 22.5 in [UNP].






Blanchet & Parent      Expires December 13, 2004               [Page 10]

Internet-Draft        Tunnel Setup Protocol (TSP)              June 2004


      0                   1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  0xF  |                 Sequence Number                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Timestamp                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            TSP data                           |
     ...


                 Figure 7: TSP header for reliable UDP

      The four bit field (0-3) is set to 0xF.  This marker is used by
      the tunnel broker to identify a TSP signaling packets that is sent
      after an IPv6 over UDP is established.  This is explained in
      section Section 4.5.2

   Sequence Number: 28 bit field.  Set by the tunnel client.  Value is
      increased by one for every new packet sent to the tunnel broker.
      The return packet from the broker contains the unaltered sequence
      number.

   Timestamp: 32 bit field.  Set by the tunnel client.  Generated from
      the client local time value.  The return packet from the broker
      contains the unaltered timestamp.

   TSP data: Same as in the TCP/v4 case.  Content described in latter
      sections.


4.4.2  Authentication phase

   The authentication phase has 3 steps :

   o  Client's protocol version identification

   o  Server's capability advertisement

   o  Client authentication

   When a TCP or UDP session is established to a tunnel broker, the
   tunnel client sends the current protocol version it is supporting.
   The version number syntax is:

      VERSION=2.0.0 CR LF

   Version 2.0.0 is the version number of this specification.  Version



Blanchet & Parent      Expires December 13, 2004               [Page 11]

Internet-Draft        Tunnel Setup Protocol (TSP)              June 2004


   1.0.0 was defined in earlier drafts.

   If the server doesn't support the protocol version it sends an error
   message and closes the session.  The server can optionally send a
   server list that may support the protocol version of the client.

   Example of a Version not supported (without a server list)

         -- Successful TCP Connection --
         C:VERSION=0.1 CR LF
         S:302 Unsupported client version CR LF
         -- Connection closed --

                                Figure 8

   Example of a Version not supported (with a server list)

         -- Successful TCP Connection --
         C:VERSION=1.1 CR LF
         S:1302 Unsupported client version CR LF
           <tunnel action="list" type="broker">
              <broker>
                 <address type="ipv4">1.2.3.4</address>
           </broker>
           <broker>
              <address type="dn">ts1.isp1.com</address>
           </broker>
           </tunnel>
         -- Connection closed --

                                Figure 9

   If the server supports the version sent by the client, then the
   server sends a list of the capabilities supported for authentication
   and tunnels.

      CAPABILITY TUNNEL=V6V4 TUNNEL=V6UDPV4 AUTH=ANONYMOUS AUTH=PLAIN
      AUTH=DIGEST-MD5 CR LF

   Tunnel types must be registered with IANA and their profiles are
   defined in Section 7.  Authentication is done using SASL [RFC2222].
   Each authentication mechanism must be a registered SASL mechanism.
   Description of such mechanism is not in the scope of this document.

   The tunnel client can then choose to close the session if none of the
   capabilities fits its needs.  If the tunnel client chooses to
   continue, it authenticates to the server using one of the advertised
   mechanism.  If the authentication fails the server sends an error



Blanchet & Parent      Expires December 13, 2004               [Page 12]

Internet-Draft        Tunnel Setup Protocol (TSP)              June 2004


   message and closes the session.

   The example in Figure 10 shows a failed authentication where the
   tunnel client requests an anonymous authentication which is not
   supported by the server.  The following example in Figure 11 shows a
   successful anonymous authentication.

         -- Successful TCP Connection --
         C:VERSION=2.0.0 CR LF
         S:CAPABILITY TUNNEL=V6V4 AUTH=DIGEST-MD5 CR LF
         C:AUTHENTICATE ANONYMOUS CR LF
         S:300 Authentication failed CR LF

              Figure 10: Example of failed authentication


         -- Successful TCP Connection --
         C:VERSION=2.0.0 CR LF
         S:CAPABILITY TUNNEL=V6V4 TUNNEL=V6UDPV4 AUTH=ANONYMOUS AUTH=PLAIN AUTH=DIGEST-MD5 CR LF
         C:AUTHENTICATE ANONYMOUS CR LF
         S:200 Success CR LF

                  Figure 11: Successful authentication

   If the authentication succeeds, the server sends a success return
   code and the protocol enters the Command phase.

4.4.3  Command and response phase

   The Command phase is where the tunnel client send a tunnel request or
   a tunnel update to the server.  In this phase, commands are sent as
   XML messages.  The first line is a "Content-length" directive that
   indicates the size of the following XML message.  When the server
   sends a response, the first line is the "Content-length" directive,
   the second is the return code and third one is the XML message if
   any.  The "Content-length" is calculated from the first character of
   the return code line to the last character of the XML message,
   inclusively.

   Spaces can be inserted freely.

         -- UDP session established --
         C:VERSION=2.0.0 CR LF
         S:CAPABILITY TUNNEL=V6V4 TUNNEL=V6UDPV4 AUTH=ANONYMOUS AUTH=PLAIN AUTH=DIGEST-MD5 CR LF
         C:AUTHENTICATE ANONYMOUS CR LF
         S:200 Success CR LF

         C:Content-length: 205 CR LF



Blanchet & Parent      Expires December 13, 2004               [Page 13]

Internet-Draft        Tunnel Setup Protocol (TSP)              June 2004


         <tunnel action="create" type="v6udpv4">
          <client>
           <address type="ipv4">206.123.31.135</address>
         <keepalive interval="30"></keepalive>
         </client>
         </tunnel> CR LF

         S:Content-length: 501 CR LF
         200 Success CR LF
         <tunnel action="info" type="v6udpv4" lifetime="604800">
           <server>
             <address type="ipv4">206.123.31.115</address>
             <address type="ipv6">3ffe:0bc0:8000:0000:0000:0000:0000:38b2</address>
           </server>
           <client>
             <address type="ipv4">206.123.31.135</address>
             <address type="ipv6">3ffe:0bc0:8000:0000:0000:0000:0000:38b3</address>
             <keepalive interval="30">
               <address type="ipv6">3ffe:0bc0:8000:0000:0000:0000:0000:38b2</address>
             </keepalive>
           </client>
         </tunnel> CR LF

         C:Content-length: 35 CR LF
         <tunnel action="accept"></tunnel> CR LF


           Figure 12: Example of a command/response sequence

   The example in Figure 12 shows a client requesting an anonymous
   v6udpv4 tunnel, indicating that a keep-alive packet will be sent
   every 30 seconds.  The tunnel broker responds with the tunnel
   parameters and indicates its acceptance of the keepalive period.
   Finally, the client sends an accept message to the server.

   Once the accept message has been sent, the server and client
   configure their tunnel endpoint based on the negotiated tunnel
   parameters.

4.5  Tunnel establishment

4.5.1  IPv6-over-IPv4 tunnels

   Once the TSP signaling is completed, a tunnel can be established on
   the tunnel server and client node.  If a v6v4 tunnel has been
   negotiated, then an IPv6-over-IPv4 tunnel [RFC2893] is established
   using the operating system tunneling interface.  On the client node,
   this is accomplished by the TSP client calling the appropriate OS



Blanchet & Parent      Expires December 13, 2004               [Page 14]

Internet-Draft        Tunnel Setup Protocol (TSP)              June 2004


   commands or system calls.

4.5.2  IPv6-over-UDP tunnels

   If a v6udpv4 tunnel is configured, the same source/destination
   address and port used during the TSP signaling are used to configure
   the v6udpv4 tunnel.  If a NAT is in the path between the TSP client
   and tunnel broker, the TSP signaling session will have created a UDP
   state in the NAT.  By reusing the same UDP socket parameters to
   transport IPv6, the traffic will flow across the NAT using the same
   state.

                   +------+-----------+--------+
                   | IPv4 | UDP       |  IPv6  |
                   |      | port 3653 |        |
                   +------+-----------+--------+

                   Figure 13: IPv6 transport over UDP

   At any time, a client may re-establish a TSP signaling session.  The
   client disconnects the current tunnel and starts a new TSP signaling
   session as described in Section 4.4.1.2.  If a NAT is present and the
   new TSP session uses the same UDP mapping in the NAT as for the
   tunnel, the tunnel broker will need to disconnect the client tunnel
   before a new TSP session can be established.

4.6  Tunnel Keep-alive

   A TSP client may select to send periodic keep-alive messages to the
   server in order to maintain its tunnel connectivity.  This allows the
   client to detect network changes and enable automatic tunnel
   re-establishment.  In the case of IPv6-over-UDP tunnels, periodic
   keep-alive can help refresh the connection state in a NAT if such
   device is in the tunnel path.

   For IPv6-over-IPv4 and IPv6-over-UDP tunnels, the keep-alive message
   is an ICMPv6 echo request [RFC2463] sent from the client to the
   tunnel server.  The IPv6 destination address of the echo message MUST
   be the address from the 'keepalive' element sent in the tunnel
   response during the TSP signaling (Section 4.4.3).  The echo message
   is sent over the configured tunnel.

   The tunnel server responds to the ICMPv6 echo requests and can keep
   track of which tunnel is active.  This can be used to disconnect
   tunnels that are no longer in use.

   The server can send a different keep-alive interval from the value
   specified in the client request.  The client MUST conform to the



Blanchet & Parent      Expires December 13, 2004               [Page 15]

Internet-Draft        Tunnel Setup Protocol (TSP)              June 2004


   server specified keep-alive interval.  The client should apply a
   random "jitter" value to avoid synchronization of keep-alive messages
   from many clients to the server [FJ93].

4.7  XML Messaging

   This section describes the XML messaging used in the TSP signaling
   during the command and response phase.  The XML elements and
   attributes are listed in the DTD (Appendix A

4.7.1  Tunnel

   The client and server use the tunnel token with an action attribute.
   Valid actions for this profile are : 'create', 'delete', 'info',
   'accept' and 'reject'.

   create: action used to request a new tunnel or update an existing
      tunnel.  Sent from the tunnel client.

   delete: action used to remove an existing tunnel from the server.
      Sent from the tunnel client.

   info: action used to request current properties of an existing
      tunnel.  This action is also used by the tunnel broker to send
      tunnel parameters following a client 'create' action.

   accept: action used by the client to acknowledge the server that the
      tunnel parameters are accepted.  The client will establish a
      tunnel.

   reject: action used by the client to signal the server that the
      tunnel parameters offered are rejected and no tunnel will be
      established.

   The tunnel 'lifetime' attribute is set by the tunnel broker and
   specifies the lifetime of the tunnel in minutes.The lifetime is an
   administratively set value.  When a tunnel lifetime is expired, it is
   disconnected on the tunnel server.

   The 'tunnel' message contains three elements:

   client Client's information

   server Server's information

   broker List of other server's





Blanchet & Parent      Expires December 13, 2004               [Page 16]

Internet-Draft        Tunnel Setup Protocol (TSP)              June 2004


4.7.2  Client Element

   The client element contains 2 elements: 'address' and 'router'.
   These elements are used to describe the client request and will be
   used by the server to create the appropriate tunnel.  This is the
   only element sent by a client.

   The 'address' element is used to identify the client IP endpoint of
   the tunnel.  When tunneling over IPv4, the client MUST send only an
   IPv4 address to the server.  When tunneling over IPv6, the client
   MUST only send an IPv6 address to the server.

   The server then returns the assigned IPv6 or IPv4 address endpoint
   and domain name inside the 'client' element when the tunnel is
   created or updated.  If supported by the server, the 'client' element
   may contain the registered DNS name for the address endpoint assigned
   to the client.

   Optionally a client can send a 'router' element to ask for a prefix
   delegation.

4.7.3  Server Element

   The 'server' element contains 2 elements: 'address' and 'router'.
   These elements are used to describe the server's tunnel endpoint.
   The 'address' element is used to provide both IPv4 and IPv6 addresses
   of the server's tunnel endpoint, while the 'router' element provides
   information for the routing method chosen by the client.

4.7.4  Broker Element

   The 'broker' element is used by a tunnel broker to provide a
   alternate list of brokers to a client in the case where the server is
   not able to provide the requested tunnel.

   The 'broker' element contains a series of 'address' element(s).

5.  Tunnel request examples

   This section presents multiple examples of requests.

5.1  Host tunnel request and reply

   A simple tunnel request consist of a 'tunnel' element which contains
   only an 'address' element.  The tunnel action is 'create', specifying
   a 'v6v4' tunnel encapsulation type.  The response sent by the tunnel
   broker is an 'info' action.  Note that the registered FQDN of the
   assigned client IPv6 address is also returned to the tunnel client.



Blanchet & Parent      Expires December 13, 2004               [Page 17]

Internet-Draft        Tunnel Setup Protocol (TSP)              June 2004


         -- Successful TCP Connection --
         C:VERSION=2.0.0 CR LF
         S:CAPABILITY TUNNEL=V6V4 AUTH=ANONYMOUS CR LF
         C:AUTHENTICATE ANONYMOUS CR LF
         S:200 Authentication successful CR LF
         C:Content-length: 123 CR LF
           <tunnel action="create" type="v6v4">
              <client>
                  <address type="ipv4">1.1.1.1</address>
              </client>
           </tunnel> CR LF
         S: Content-length: 234 CR LF
            200 OK CR LF
            <tunnel action="info" type="v6v4" lifetime="1440">
              <server>
                 <address type="ipv4">206.123.31.114</address>
                 <address type="ipv6">3ffe:b00:c18:ffff:0000:0000:0000:0000</address>
              </server>
              <client>
                 <address type="ipv4">1.1.1.1</address>
                 <address type="ipv6">3ffe:b00:c18:ffff::0000:0000:0000:0001</address>
                 <address type="dn">userid.domain</address>
              </client>
            </tunnel> CR LF
         C: Content-length: 35 CR LF
            <tunnel action="accept"></tunnel> CR LF

           Figure 14: Simple tunnel request made by a client


5.2  Router Tunnel request with a /48 prefix delegation, and reply

   A tunnel request with prefix consist of a 'tunnel' element which
   contains 'address' element and a 'router' element.  The 'router'
   element also contains the 'dns_server' element which is used to
   request DNS delegation of the assigned IPv6 prefix.  The 'dns_server'
   element lists the IP address of the DNS servers to be registered for
   the reverse-mapping zone.

   Tunnel request with prefix and static routes.

   C: Content-length: 234 CR LF
      <tunnel action="create" type="v6v4">
       <client>
        <address type="ipv4">1.1.1.1</address>
        <router>
         <prefix length="48"/>
         <dns_server>



Blanchet & Parent      Expires December 13, 2004               [Page 18]

Internet-Draft        Tunnel Setup Protocol (TSP)              June 2004


          <address type="ipv4">2.3.4.5</address>
          <address type="ipv4">2.3.4.6</address>
          <address type="ipv6">3ffe:0c00::1</address>
         </dns_server>
        </router>
       </client>
      </tunnel> CR LF
   S: Content-length: 234 CR LF
      200 OK CR LF
      <tunnel action="info" type="v6v4" lifetime="1440">
       <server>
        <address type="ipv4">206.123.31.114</address>
        <address type="ipv6">3ffe:b00:c18:ffff:0000:0000:0000:0000</address>
       </server>
       <client>
        <address type="ipv4">1.1.1.1</address>
        <address type="ipv6">3ffe:b00:c18:ffff::0000:0000:0000:0001</address>
        <address type="dn">userid.domain</address>
        <router>
         <prefix length="48">3ffe:0b00:c18:1234::</prefix>
         <dns_server>
          <address type="ipv4">2.3.4.5</address>
          <address type="ipv4">2.3.4.6</address>
          <address type="ipv6">3ffe:0c00::1</address>
         </dns_server>
        </router>
       </client>
      </tunnel> CR LF
   C: Content-length: 35 CR LF
      <tunnel action="accept"></tunnel> CR LF

                               Figure 15


5.3  IPv4 over IPv6 tunnel request

   This is similar to the previous 'create' action, but with the tunnel
   type is set to 'v4v6'.













Blanchet & Parent      Expires December 13, 2004               [Page 19]

Internet-Draft        Tunnel Setup Protocol (TSP)              June 2004


             -- Successful TCP Connection --
             C:VERSION=1.0 CR LF
             S:CAPABILITY TUNNEL=V4V6 AUTH=DIGEST-MD5 AUTH=ANONYMOUS CR LF
             C:AUTHENTICATE ANONYMOUS CR LF
             S:OK Authentication successful CR LF
             C:Content-length: 228 CR LF
               <tunnel action="create" type="v4v6">
                  <client>
                      <address
   type="ipv6">3ffe:0b00:0c18:ffff:0000:0000:0000:0001</address>
                  </client>
               </tunnel> CR LF

   If the allocation request is accepted, the broker will acknowledge
   the allocation to the client by sending a 'tunnel' element with the
   attribute 'action' set to 'info', 'type' set to 'v4v6' and the
   'lifetime' attribute set to the period of validity or lease time of
   the allocation.  The 'tunnel' element contains 'server' and 'client'
   elements.


             S: Content-length: 370 CR LF
                200 OK CR LF
                <tunnel action="info" type="v4v6" lifetime="1440">
                  <server>
                     <address type="ipv4" length="30">206.123.31.2</address>
                     <address type="ipv6">3ffe:b00:c18:ffff:0000:0000:0000:0002</address>
                  </server>
                  <client>
                     <address type="ipv4" length="30">206.123.31.1</address>
                     <address
   type="ipv6">3ffe:b00:c18:ffff::0000:0000:0000:0001</address>
                  </client>
                </tunnel> CR LF

   In DSTM [I-D.ietf-ngtrans-dstm] terminology, the DSTM server is the
   TSP broker and the TEP is the tunnel server.

5.4  NAT Traversal tunnel request

   When a client is capable of both IPv6 over IPv4 and IPv6 over UDP
   over IPv4 encapsulation, it can request the broker, by using the
   "v6anyv4" tunnel mode, to determine if it is behind a NAT and to send
   the appropriate tunnel encapsulation mode as part of the response.
   The client can also explicitly request an IPv6 over UDP over IPv4
   tunnel by specifying "v6udpv4" in its request.

   In the following example, the client informs the server that it



Blanchet & Parent      Expires December 13, 2004               [Page 20]

Internet-Draft        Tunnel Setup Protocol (TSP)              June 2004


   requests to send keep-alives every 30 seconds.  Its its response, the
   server accepted the client suggested keep-alive interval, and the
   IPv6 destination address for the keep-alive packets is specified.


     -- Successful TCP Connection --
     C:VERSION=2.0.0 CR LF
     S:CAPABILITY TUNNEL=V6V4 TUNNEL=V6UDPV4 AUTH=DIGEST-MD5 CR LF
     C:AUTHENTICATE ... CR LF
     S:200 Authentication successful CR LF
     C:Content-length: ... CR LF
       <tunnel action="create" type="v6anyv4">
          <client>
              <address type="ipv4">10.1.1.1</address>
              <keepalive interval="30"></keepalive>
          </client>
       </tunnel> CR LF
     S: Content-length: ... CR LF
        200 OK CR LF
        <tunnel action="info" type="v6udpv4" lifetime="1440">
          <server>
             <address type="ipv4">206.123.31.114</address>
             <address type="ipv6">3ffe:b00:c18:ffff:0000:0000:0000:0002</address>
          </server>
          <client>
             <address type="ipv4">10.1.1.1</address>
             <address type="ipv6">3ffe:b00:c18:ffff::0000:0000:0000:0003</address>
             <keepalive interval="30">
                <address type="ipv6">3ffe:b00:c18:ffff:0000:0000:0000:0002</address>
             </keepalive>
          </client>
        </tunnel> CR LF


6.  Applicability of TSP in Different Environments

   This section describes the applicability of TSP in different
   environments.

6.1  Applicability of TSP in Provider Networks with Enterprise Customers

   In a provider network where IPv4 is dominant, a tunnelled
   infrastructure can be used to provide IPv6 services to the enterprise
   customers, before a full IPv6 native infrastructure is built.  In
   order to start deploying in a controlled manner and to give
   enterprise customers a prefix, the TSP framework is used.  The TSP
   server can be in the core, in the aggregation points or in the PoPs
   to offer the service to the customers.  IPv6 over IPv4 encapsulation



Blanchet & Parent      Expires December 13, 2004               [Page 21]

Internet-Draft        Tunnel Setup Protocol (TSP)              June 2004


   can be used.  If the customers are behind an IPv4 NAT, then IPv6 over
   UDP-IPv4 encapsulation can be used.  TSP can be used in combination
   of other techniques.

6.2  Applicability of TSP in Provider Networks with Home/Small Office
    Customers

   In a provider network where IPv4 is dominant, a tunnelled
   infrastructure can be used to provider IPv6 services to the home/
   small office customers, before a full IPv6 native infrastructure is
   built.  The small networks such as Home/Small offices have a
   non-upgradable gateway with NAT.  TSP with NAT traversal is used to
   offer IPv6 connectivity and a prefix to the internal network.

   Automation of the prefix assignment and DNS delegation, done by TSP,
   is a very important feature for a provider in order to substantially
   decrease support costs.  The provider can use the same AAA database
   that is used to authenticate the dial in or IPv4 users.  Customers
   can deploy home IPv6 networks without any intervention of the
   provider support people.

   With the NAT discovery function of TSP, providers can use the same
   TSP infrastructure for both NAT and non-NAT parts of the network.

6.3  Applicability of TSP in Enterprise Networks

   In an enterprise network where IPv4 is dominant, a tunnelled
   infrastructure can be used to provider IPv6 services to the IPv6
   islands (hosts or networks) inside the enterprise, before a full IPv6
   native infrastructure is built.  TSP can be used to give IPv6
   connectivity, prefix and routing for the islands.  This gives to the
   enterprise a full control deployment of IPv6 while maintaining
   automation and permanence of the IPv6 assignments to the islands.

6.4  Applicability of TSP in Wireless Networks

   In a wireless network where IPv4 is dominant, hosts and networks move
   and change IPv4 address.  TSP enables the automatic re-establishment
   of the tunnel when the IPv4 address change.

   In a wireless network where IPv6 is dominant, hosts and networks
   move.  TSP enables the automatic re-establishment of the tunnel
   together with the DSTM mechanism.

6.5  Applicability of TSP in Unmanaged networks

   An unmanaged network is where no network manager or staff is
   available to configure network devices.  TSP is particularly powerful



Blanchet & Parent      Expires December 13, 2004               [Page 22]

Internet-Draft        Tunnel Setup Protocol (TSP)              June 2004


   in this context where automation of all necessary information for the
   IPv6 connectivity is handled by TSP: tunnel end-points parameters,
   prefix assignment, dns delegation, routing.

   An unmanaged network may be behind a NAT, maybe not.  With the NAT
   discovery function, TSP works automatically in both cases.

6.6  Applicability of TSP for Mobile Hosts and Mobile Networks

   Mobile hosts are common and used.  Laptops moving from wireless,
   wired in office, home, ...  are examples.  They often have IPv4
   connectivity, but not necessarily IPv6.  TSP framework enables the
   mobile hosts to have IPv6 connectivity wherever they are, by having
   the TSP client send updated information of the new environment to the
   TSP server, when a change occurs.  Together with NAT discovery and
   traversal, the mobile host can be always IPv6 connected wherever it
   is.

   Mobile here means only the change of IPv4 address.  Mobile-IP
   mechanisms and fast hand-off take care of additional constraints in
   mobile environments.

   Mobile networks share the applicability of the mobile hosts.
   Moreover, in the TSP framework, they also keep their prefix
   assignment and can control the routing.  NAT discovery can also be
   used.

7.  IANA Considerations

   A tunnel type registry should be setup by IANA.  The following
   strings are defined in this document: "v6v4" for IPv6 in IPv4
   encapsulation (using IPv4 protocol 41) "v6udpv4" for IPv6 in UDP in
   IPv4 encapsulation "v6anyv4" for IPv6 in IPv4 or IPv6 in UDP in IPv4
   encapsulation "v4v6" for IPv4 in IPv6 encapsulation.

   Details on the registration procedure for new tokens TBD.

   IANA assigned 3653 as the TSP port number.

8.  Security Considerations

   Authentication of the TSP session uses the SASL[RFC2222] framework,
   where the authentication mechanism is negotiated between the client
   and the server.  The framework enables to use the level of
   authentication needed for securing the session, based on the
   policies.

   Static tunnels are created when the TSP negotiation is terminated.



Blanchet & Parent      Expires December 13, 2004               [Page 23]

Internet-Draft        Tunnel Setup Protocol (TSP)              June 2004


   Static tunnels are not open gateways and exhibit less security issues
   than automated tunnels.  Static IPv6 in IPv4 tunnels security
   considerations are described in [RFC2893].

9.  Conclusion

   The Tunnel Setup Protocol (TSP) is applicable in many environments,
   such as: providers, enterprises, wireless, unmanaged networks, mobile
   hosts and networks.  TSP gives the two tunnel end-points the ability
   to negotiate tunnel parameters, as well as prefix assignment, dns
   delegation and routing in an authenticated session.  It also provides
   IPv4 NAT discovery function by using the most effective
   encapsulation.  It also supports the IPv4 mobility of the nodes.

10.  Acknowledgements

   This draft is the merge of many previous drafts about TSP.  Octavio
   Medina has contributed to an earlier draft.  The authors would like
   to thank Pekka Savola for his comments.

11.  References

11.1  Normative References

   [RFC2222]  Myers, J., "Simple Authentication and Security Layer
              (SASL)", RFC 2222, October 1997.

   [RFC2463]  Conta, A. and S. Deering, "Internet Control Message
              Protocol (ICMPv6) for the Internet Protocol Version 6
              (IPv6) Specification", RFC 2463, December 1998.

   [RFC2893]  Gilligan, R. and E. Nordmark, "Transition Mechanisms for
              IPv6 Hosts and Routers", RFC 2893, August 2000.

   [W3C.REC-xml-1998]
              Bray, T., Paoli, J. and C. Sperberg-McQueen, "Extensible
              Markup Language (XML) 1.0", W3C REC-xml-1998, February
              1998, <http://www.w3.org/TR/1998/REC-xml-19980210/>.

11.2  Informative References

   [FJ93]     Floyd, S. and V. Jacobson, "The Synchronization of
              Periodic Routing Messages", Proceedings of ACM SIGCOMM
              '93, September 1993.

   [I-D.ietf-ngtrans-dstm]
              Bound, J., "Dual Stack Transition Mechanism (DSTM)",
              draft-ietf-ngtrans-dstm-08 (work in progress), July 2002.



Blanchet & Parent      Expires December 13, 2004               [Page 24]

Internet-Draft        Tunnel Setup Protocol (TSP)              June 2004


   [I-D.ietf-v6ops-3gpp-cases]
              Soininen, J., "Transition Scenarios for 3GPP Networks",
              draft-ietf-v6ops-3gpp-cases-03 (work in progress), April
              2003.

   [I-D.ietf-v6ops-isp-scenarios-analysis]
              Lind, M., Ksinant, V., Park, S., Baudot, A. and P. Savola,
              "Scenarios and Analysis for Introducing IPv6 into ISP
              Networks", draft-ietf-v6ops-isp-scenarios-analysis-02
              (work in progress), April 2004.

   [I-D.ietf-v6ops-unmaneval]
              Huitema, C., "Evaluation of Transition Mechanisms for
              Unmanaged Networks", draft-ietf-v6ops-unmaneval-02 (work
              in progress), May 2004.

   [RFC3053]  Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6
              Tunnel Broker", RFC 3053, January 2001.

   [UNP]      Stevens, R., Fenner, B. and A. Rudoff, "Unix Network
              Programming, 3rd edition", Addison Wesley ISBN
              0-13-141155-1, 2004.


Authors' Addresses

   Marc Blanchet
   Hexago
   2875 boul. Laurier, suite 300
   Sainte-Foy, QC  G1V 2M2
   Canada

   Phone: +1 418 266 5533
   EMail: Marc.Blanchet@hexago.com


   Florent Parent
   Hexago
   2875 boul. Laurier, suite 300
   Sainte-Foy, QC  G1V 2M2
   Canada

   Phone: +1 418 266 5533
   EMail: Florent.Parent@hexago.com







Blanchet & Parent      Expires December 13, 2004               [Page 25]

Internet-Draft        Tunnel Setup Protocol (TSP)              June 2004


Appendix A.  The TSP DTD

   <?xml version="1.0"?>
   <!DOCTYPE tunnel  [
   <!ELEMENT tunnel        (server?,client?,broker?)>
     <!ATTLIST tunnel action   (create|delete|info|accept|reject) #REQUIRED >
     <!ATTLIST tunnel type     (v6v4|v4v6|v6anyv4|v6udpv4|broker) #REQUIRED >
     <!ATTLIST tunnel lifetime CDATA              "1440"    >

   <!ELEMENT server        (address+,router?)>

   <!ELEMENT client        (address+,router?)>

   <!ELEMENT broker        (adress+)>

   <!ELEMENT router        (prefix?,dns_server?,as?)>

   <!ELEMENT dns_server    (address+)>

   <!ELEMENT prefix        (#PCDATA)>
     <!ATTLIST prefix length CDATA #REQUIRED>

   <!ELEMENT address       (#PCDATA)>
     <!ATTLIST address type (ipv4|ipv6|dn) #REQUIRED>
     <!ATTLIST address length CDATA "">

   <!ELEMENT keepalive (address+)>
     <!ATTLIST keepalive interval CDATA #REQUIRED>
   ]>

                               Figure 19


Appendix B.  Error codes

   Error codes are sent as a numeric value followed by a text message
   describing the code.  The Tunnel Setup Protocol defines error code
   numbers 1 through 499 and 1000 through 1499.  Profile dependant error
   codes are defined within the 500 through 999 and 1500 through 1999
   range.

   The predefined values are :


   if a list of tunnel servers is following the error code as a referal
   service, then 1000 is added to the error code.





Blanchet & Parent      Expires December 13, 2004               [Page 26]

Internet-Draft        Tunnel Setup Protocol (TSP)              June 2004


   200 Success:  Successful operation

   300 Authentication failed: Invalid userid, password or authentication
      mechanism.

   301 No more tunnels available: The server has reached its capacity
      limit.

   302 Unsupported client version: The client version is not supported
      by the server.

   303 Unsupported tunnel type: The server does not provide the
      requested tunnel type.

   310 Server side error: Undefined server error

   500 Invalid request format or specified length: Received request has
      invalid syntax or truncated

   501 Invalid IP address: IP address specified by the client is invalid

   502 Invalid or duplicate nicname

   504 Router function not supported

   506 IPv4 prefix already used for existing tunnel

   507 Requested prefix length cannot be assigned

   509 DNS delegation setup error

   514 Protocol error

   517 Unsupported router protocol

   518 Unsupported prefix length

   520 Missing prefix length













Blanchet & Parent      Expires December 13, 2004               [Page 27]

Internet-Draft        Tunnel Setup Protocol (TSP)              June 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Blanchet & Parent      Expires December 13, 2004               [Page 28]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/