[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

Internet Engineering Task Force                                 J. Palet
Internet-Draft                                                   M. Diaz
Expires: April 13, 2006                                      Consulintel
                                                        October 10, 2005

                Automatic Tunneling Setup for/with IPv6

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on April 13, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).


   This document presents the basis for a procedure that enables a host
   or router to automatically setup an IPvX in IPvY tunnel.  Basically,
   the document considers several scenarios, from the most common today
   "dominant IPv4" networks to new "dominant IPv6" networks, which can
   even use multicast.

   A basic requirement is that the host or router is a dual stack node
   and it will have either native IPv4-only access (dominant IPv4

Palet & Diaz             Expires April 13, 2006                 [Page 1]

Internet-Draft                    ATS6                      October 2005

   network) or native IPv6-only access (dominant IPv6 network).
   Consequently, either IPv6 will be transported in the existing IPv4-
   only infrastructure, or IPv4 will be transported in the existing
   IPv6-only infrastructure.  Other combinations are possible, such as
   IPv6 in IPv6 (for example to support IPv6 multicast in an IPv6-
   unicast-only infrastructure).

   The procedure follows the work from [1], [2], [3] and [4], trying to
   be compliant with the requirements enumerated in those documents.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Assumptions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   5.  Protocol Description . . . . . . . . . . . . . . . . . . . . .  5
     5.1.  Start State  . . . . . . . . . . . . . . . . . . . . . . .  6
     5.2.  TEP Discovery state  . . . . . . . . . . . . . . . . . . .  6
     5.3.  Tunnel Setup Request state . . . . . . . . . . . . . . . .  6
       5.3.1.  IPv4-only infrastructure . . . . . . . . . . . . . . .  7
       5.3.2.  IPv6-only infrastructure . . . . . . . . . . . . . . .  8
     5.4.  Authenticated state  . . . . . . . . . . . . . . . . . . .  9
     5.5.  Authentication and Handshake state . . . . . . . . . . . . 10
       5.5.1.  IPv4-only infrastructure . . . . . . . . . . . . . . . 11
       5.5.2.  IPv6-only infrastructure . . . . . . . . . . . . . . . 11
       5.5.3.  A&H packet . . . . . . . . . . . . . . . . . . . . . . 12
     5.6.  End state  . . . . . . . . . . . . . . . . . . . . . . . . 13
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 16

Palet & Diaz             Expires April 13, 2006                 [Page 2]

Internet-Draft                    ATS6                      October 2005

1.  Introduction

   Today, new IPv6 deployment scenarios not initially considered are
   emerging.  The deployment of IPv6 is requiring already the use of
   automatic tunneling setup not only in existing IPv4-only
   infrastructure, but also of IPv4 tunneling in existing IPv6-only

   The case for IPv6-only infrastructures is a fact, and consequently
   IPv4-in-IPv6 tunnels are necessary to support communications of old
   application not yet ported to IPv6 in those infrastructures.

   Such scenarios could be classified basically as:

   o  Pre-authenticated user realms: Those where the user is typically
      already a customer of the network infrastructure (ISPs, enterprise
      networks, etc.).  This could apply to broadband and narrowband
      networks where the user has somehow "subscribed" or "registered"
      for the service before using it, by means of other procedures out
      of the scope of this document.  Possibly they can only use the
      network because it is authenticated by means of the physical
      attachment to the network (typically DSL, Cable, PLC, 3GPP, etc.).

   o  Non-authenticated user realms: Those where the user is not a pre-
      authenticated customer of the network, but apply for a temporary
      service, typically free of charge, such as free hot spots, free
      transition services in third party networks, guest in an
      enterprise network, etc.  This is often the case for nomadic
      users, which change their network attachment point when traveling.

   Some of the scenarios have their own requirements as stated in [1],
   [2], [3] and [4], which include among other few packet exchanges to
   setup the tunnel, low overhead, etc.  These requirements make
   necessary a new procedure or protocol to setup a tunnel in automated
   fashion.  This document presents the basis for such procedure, in
   order to make possible to a host/router the automatic setup of an

2.  Requirements

   The procedure described in this document is based on the requirements
   described in [1], [2], [3] and [4], but specially in:

   o  To obtain an IPv6 address in IPv4-only infrastructures or an IPv4
      address in IPv6-only infrastructures.

Palet & Diaz             Expires April 13, 2006                 [Page 3]

Internet-Draft                    ATS6                      October 2005

   o  To automatically setup an IPv6-in-IPv4, IPv4-in-IPv6 tunnel, or
      IPv6-in-IPv6 tunnel, depending on the user scenario.

   o  The provided address could only be static if both tunnel end
      points are static.  If a static address is required in other
      situations (server capabilities) the procedure described in this
      document could be revised, for example, depending on the user

   o  To automatically setup and activate the tunnel.

   o  Low overhead on communications.

   o  Low overload on the user device.

   o  Lightweight deployment (minimal infrastructure changes and

   o  NAT and Firewall traversing.

   o  To authenticate the user.

3.  Assumptions

   The solution proposed is based on the following assumptions:

   o  The TEP (Tunnel End Point) is discovered by other means before
      starting the tunnel setup.

   o  The user host/router is pre-registered within the domain by any
      valid mean.  Note that a registered user is not the same as an
      authenticated user.

   o  Registered user means in this context, that user has some kind of
      identifier (which is assigned during the registration process) in
      order to access the network, and may be other associated profile
      information (name, authentication method, etc...).  It could be an
      anonymous user, in such case the identifier could be just

   o  The TEP, either intra or inter networks will be reachable by at
      least one of the available encapsulation mechanism.  This for
      example, ensures the NAT treatment because the type of NAT
      (symmetric, full-conned, etc) is not significant.

Palet & Diaz             Expires April 13, 2006                 [Page 4]

Internet-Draft                    ATS6                      October 2005

4.  Scenarios

   The following scenarios are considered candidate targets to take
   advantage of the procedure described in this document.

   1.  Pre-authenticated user realms (from now on Pre-Auth).  Those
       realms where the user is already authenticated, typically being
       "customer" of the network infrastructure (ISPs, enterprise
       networks, etc.).  This could apply to broadband and narrowband
       networks where the user has somehow "signed on" before using the
       service, by means of other procedures out of the scope of this
       document.  Possibly can only use the network because it is
       authenticated by means of the physical attachment to the network.
       Examples of this could be:

       *  Cellular networks such as 3GPP, were IPv4-only or IPv6-only
          infrastructure is available.

       *  ISP networks (xDSL, Cable, PLC, PSTN, ISDN, etc.).

       *  Enterprise networks (could be almost equivalent to the ISP

   2.  Non-authenticated user realms (from now on Non-Auth): Realms
       where the user is registered but not authenticated yet.  This may
       be the case for users that apply for a temporary service,
       typically free of charge, such as free hot spot, free transition
       services in third party networks, guest visitors in enterprise
       network, etc.  This is often the case for nomadic users, which
       change their network attachment point when traveling.  A concrete
       example of this scenario could be:

       *  Users with IPv4 connectivity from a hot spot or ISP, which
          does not offer IPv6 support, neither a transition service.
          The user however could use a transition mechanism by means of
          a TEP located in another ISP or domain.

5.  Protocol Description

   The solution is based on the following state diagram:

Palet & Diaz             Expires April 13, 2006                 [Page 5]

Internet-Draft                    ATS6                      October 2005

                     +--------------+     Pre-Auth
           +-------->| Tunnel Setup |---------------------+
           |         |    Request   |                     |
     +-----------+   +--------------+                     |
     |    TEP    |          |                             |
     | Discovery |          | Non-Auth                    |
     +-----------+          |                             |
           ^                |       More capabilities     |
           |                |      +-----------------+    |
           |                |      |                 |    |
           |                v      v                 |    v
      +---------+   +----------------+            +---------------+
      |  Start  |   | Authentication |            | Authenticated |
      +---------+   |       &        |            +---------------+
                    |   Handshake    |               ^    |
                    +----------------+               |    |
                            |      |     NOT OK      |    |
                     NOT OK |      | (only Pre-Auth) |    |
                            |      +-----------------+    |
                            |              OK             |
                            v                             |
                       +---------+    Tunnel DOWN         |
                       |   End   |<-----------------------+

   Figure 1: ATS6 State Diagram

5.1.  Start State

   This state only represents the initial state.  The initiating device
   (host/router) is ready to start the activation of the tunnel.

5.2.  TEP Discovery state

   Discovery of the TEP is out the scope of this specification.  It is
   assumed that the TEP is discovered by other external means.  However,
   the discovery mechanism could also be integrated as part in the ATS6

   The document [5] has already analyzed this issue and [6] might be
   taken into account to be used as the TEP discovery mechanism.

5.3.  Tunnel Setup Request state

   Once the TEP has been discovered, the initiating device (host/router)
   sends a request for the automatic tunnel setup.  Depending on the
   availability of and IPv4-only or IPv6-only infrastructure, the

Palet & Diaz             Expires April 13, 2006                 [Page 6]

Internet-Draft                    ATS6                      October 2005

   following procedures will be followed.

5.3.1.  IPv4-only infrastructure

   The host/router is willing to obtain an IPv6 address, so it makes a
   link-local address which has embedded its IPv4 address where the
   "Interface Identifier" part of the IPv6 address is made from the IPv4
   address.  This will be ::XXXX:YYYY, being XXXX and YYYY the
   hexadecimal notation of the IPv4 address which the host/router is
   using for the interface where the tunnel is required.

   Then it sends an IPv6-in-IPv4 encapsulated Router Solicitation (RS)
   packet [5] to the TEP by using the link-local address just made.  The
   host/router send the RS message into the IPv4 packet, as payload and
   it sends it to the TEP.  Pre-Auth Realms

   The TEP sends a single Router Advertisement (RA) packet [8] to the
   querying device and setup the tunnel.  A transition to the
   "Authenticated" state is done.

   The host/router builds the global IPv6 address with the received
   prefix plus an Interface Identifier, which has embedded its IPv4
   address, as done previously for the link-local address.

   If the RA is received, the device knows that there is no NAT or that
   the existing one supports 6in4 or "proto-41 forwarding" [7].
   Furthermore this fact means that the tunnel has been setup on the
   server side.  Non-Auth Realms

   The TEP sends RA with the M bit set.  Furthermore it does not include
   the "Prefix Information" option on the RA and a transition to the
   "Authentication and Handshake" state is done.

   If the RA is received by the host/router, it knows that the there is
   not NAT, or the existing one supports proto-41 forwarding [7], but
   user authentication is required to continue.  This means the device
   needs to transit to the Authentication and Handshake state.

   In both cases (Pre-Auth and Non-Auth), if no RA is received before
   timeout, then it means that some barrier (such as a NAT, no proto-41
   forwarding, Firewall filtering proto-41, etc.) on the path to the TEP
   has been found.  In this case the host/router tries to setup the
   tunnel by using IPv6-in-UDP/IPv4 (note: other possibilities may be
   explored here, such as GRE, PPTP, L2TP, etc., and priority of them to

Palet & Diaz             Expires April 13, 2006                 [Page 7]

Internet-Draft                    ATS6                      October 2005

   be fixed).  The tunnel setup process is the same but packets are
   encapsulated as payload of UDP/IPv4 packets rather than payload of

5.3.2.  IPv6-only infrastructure

   Following a similar philosophy as in the case of IPv4-only
   infrastructure, the host/router that requires IPv4 access, will
   obtain the IPv4 address in the tunnel itself.  There are at least two
   candidate choices (to be fixed in a new release):

   o  DHCP: The TEP should either be the DHCP (IPv4) server or relay/
      proxy from an external one.  DHCPv6 could also be considered, as
      it could make the process much simpler, but in general DHCPv6
      support is weaker.

   o  IPv4 address derived from the IPv6 one: By using the global IPv6
      address used in this communication by the initiating host/router,
      a hash or similar algorithm could be used to create an IPv4
      address, probably in the network 10/8.  The combination of using
      the IPv6 global address and the network 10/8 provides a lower
      probability of address duplication.  Use of DHCP in IPv4-in-IPv6 tunnels

   The host/router which requires the IPv6-in-IPv6 tunnel, need to
   construct a DHCP request packet, as it would be done in a LAN.  The
   packet will be encapsulated in an IPv6 packet, which is sent to the
   TEP.  The TEP will then de-capsulate the packet and reply to the DHCP
   request (either by a built-in DHCP server or proxing/relaying it).

   This provides a better solution (for example public IPv4 addresses
   could be used as the DHCP address pool), but requires DHCP server/
   client support.  Pre-Auth Realms

   As the user is already registered, the TEP does not require any
   additional verification and delivers an IPv4 address to the
   initiating host/router, following a pre-defined policy in the DHCP
   server.  The response DHCP packet will need to be encapsulated in an
   IPv6 one and sent to the initiating host/router, which will de-
   capsulate it for configuring its IPv4 address.  Non-Auth Realms

   In this case, the initiating host/router need to be authenticated.
   Consequently the DHCP server will not reply (for example, the DHCP

Palet & Diaz             Expires April 13, 2006                 [Page 8]

Internet-Draft                    ATS6                      October 2005

   request will not be de-capsulated).  When the initiating host/router
   see no reply, after a pre-configured timeout, will understand that a
   transition to the Authentication and Handshake state is needed.  Use of IPv4 addressed derived from the IPv6 one in IPv4-in-
          IPv6 tunnels

   The IPv4 address should be generated by an algorithm (to be defined)
   from the global IPv6 address used in the communication with the TEP.
   This could be done by means of a hash function.

   In order to simplify several network considerations, such as routing,
   seems a better approach the use of a address.  The TEP
   will behave as the default gateway and also NAT for that host/router.

   Further considerations are required in order to ensure that the IPv4
   address is unique, unless this is a property already provided by the
   algorithm to be defined, but even do, is necessary to ensure that DAD
   (Duplicate Address Detection) has been used to avoid duplicate IPv6
   addresses which could cause a duplicated IPv4 one.  Pre-Auth Realms

   As the initiating host/router is already registered, the TEP does not
   require any extra verification (however the DAD issue).  In order to
   activate the tunnel up-front its use, test traffic could be used,
   i.e., ping.  Non-Auth Realms

   In this case, the TEP requires a verification of the initiating host/
   router, so no test or actual traffic should be replied.  The host/
   router will timeout and consequently will realize that needs to
   transit to the Authentication and Handshake state.

5.4.  Authenticated state

   This state represents the status on which the initiating host/router
   is already authenticated from the perspective of this protocol, so
   the tunnel is keep active (up) on the server and client sides.  The
   initiating device is ready to send/receive data.

   The initiating device send to the TEP Neighbor Solicitation (NS)
   packets [5], periodically, when the infrastructure is IPv4-only or a
   similar packet (to be defined) in IPv6-only infrastructures in order

Palet & Diaz             Expires April 13, 2006                 [Page 9]

Internet-Draft                    ATS6                      October 2005

   o  Be sure that the tunnel continues in up state.

   o  Refresh possible timeout in NAT/Firewall tables.

   o  Let the TEP doing garbage collection.

   In some cases, such as 3GPP, PSTN, ISDN, typically narrowband links,
   the period of these packets could be infinite or a very long value,
   so that network resources are not wasted (transmitted/received
   packets, radio spectrum, battery-life, etc.).

   If the initiating device will not need the tunnel anymore, it can
   transit to the "End" state.

   If there is a change on the IP address of the initiating device, then
   a "Tunnel DOWN" must be forced, implying a transit to the "End"
   state, in order to keep the server informed about the new IP address
   by means of the full ATS6 protocol re-execution, as it may happen
   that the TEP is also a different one.

5.5.  Authentication and Handshake state

   This state represents the state where the authentication and
   handshake process is done.

   In Non-Auth realms the user may need to be authenticated before
   setting-up the tunnel (but it may be an "anonymous" authentication).

   In Pre-Auth realms this state implies that the tunnel is already up
   but the initiating device might require extending the tunnel features
   (type of tunnel different to the one automatically setup, prefix
   delegation, etc.).  To do that the TEP could require extra
   authentication in order to be sure if the initiating device has the
   right to obtain the solicited extra-features.

   The actions to be done are:

   o  In both Pre-Auth and Non-Auth realms:

      *  User authentication.

      *  Handshake to obtain extra-features on the tunnel.

   o  In only Non-Auth realms:

      *  Getting the IP address on the client side to be used with the

Palet & Diaz             Expires April 13, 2006                [Page 10]

Internet-Draft                    ATS6                      October 2005

      *  Setting-up the tunnel on both the server and client sides.

   Depending on the type of the desired tunnel versus the existing
   infrastructure, the actions are different.

5.5.1.  IPv4-only infrastructure

   In this case the desired tunnel will be IPv6-in-IPv4, so the
   "Authentication and Handshake" packet (A&H) (defined below) could be
   made by means of sending new ICMPv6 packet/s (unspecified yet) to the
   server.  The packet/s will contain user identification,
   authentication and parameter information and the packet exchange
   between TEP and client will be short in time to keep the process as
   simple as possible.

   In Pre-Auth realms the initiating device starts the A&H process at
   any time from "Authenticated" State.

   In Non-Auth realms the initiating device also starts the A&H process
   but after the TEP indicated it is required in "Tunnel Setup Request"
   state, by means of the M bit in the RA.

   Once the server receives the "A&H Packet", the tunnel is activated,
   modified, or extended with the new requested features.  This
   typically only happen if the received data match the rights or policy
   on the TEP or server database.  The TEP sends to the initiating
   device an acknowledge packet with the required information.  In the
   Non-Auth case the TEP also sends the RA in order to communicate to
   the client the IPv6 address as explained before in the "Tunnel Setup
   Request" state.

   If the authentication data is wrong or does not match the necessary
   credentials, right, policy, etc., the server replies with information
   about what is wrong, in the Packet Type Field (such as
   authentication, type of query, etc.).  Then a transition to the "End"
   state is done in the Non-Auth case or to the "Authenticated" state in
   the Pre-Auth case.  In this one the tunnel continues up but the
   required extended features are not provided.

5.5.2.  IPv6-only infrastructure

   Being the infrastructure IPv6-ready, the "A&H Packet" below described
   is already directly usable, as it is already an IPv6 packet.
   Consequently, it can be used as described before to establish any
   kind of tunnels, such as IPv4-in-IPv6, IPv6-in-IPv6, etc., modify
   them, activate new features, etc.

Palet & Diaz             Expires April 13, 2006                [Page 11]

Internet-Draft                    ATS6                      October 2005

5.5.3.  A&H packet

   This IPv6 packet is used to communicate the server that the user is
   willing to build a tunnel (Non-Auth case) or modify/extend the one
   already configured with extra-features (Pre-Auth case).  The format
   of such a packet is as follows:

     |                IPv6     HEADER                |
     |               ICMPv6    HEADER                |
     +--------+-----------+--------+--------+--------+ --+
     |   ID   | Signature | Packet | Tunnel | Prefix |   |
     | Length |  Length   |  Type  |  Type  | Length |   |==> Parameters
     +--------+-----------+--------+--------+--------+   |
     |       Prefix (only sent by the server)        |   |
     +-----------------------------------------------+ --+
     |                    USER_ID                    |
     |                    RANDOM                     |
     |                   SIGNATURE                   |

   Figure 2: ATS6 A&H Packet

   The Parameters are used to define the authentication method, what
   extra-features are required, etc. and their meanings are as follows:

   o  ID Length: The length of the User_ID field.

   o  Signature Length: The length of Signature field.

   o  Packet Type: Information about the packet type (query or reply,
      A&H process succeeded or not, wrong parameter if the process
      fails, etc.).

   o  Tunnel Type: The type of encapsulation required/allowed (6in4,
      6in6, 4in6, etc.).

   o  Prefix Length: If the initiating host/router asks for prefix
      delegation, the prefix length required is indicated on this field.
      If server sends the packet it indicates the prefix length allowed.

   o  Prefix: The delegated prefix to the initiating device when prefix
      delegation is required.

Palet & Diaz             Expires April 13, 2006                [Page 12]

Internet-Draft                    ATS6                      October 2005

   The rest of the A&H packet fields are as follows:

   o  User_ID: the user login.  It can be an ASCII text, coded or
      whatever.  It is assigned during the registration process.  To be
      further defined.

   o  Random data: Data used to be included on the packet to prevent
      equal signatures.  Either a random number, date, etc.  To be
      further defined.

   o  Signature: It is the field that really authenticates the user.  It
      is the result of ciphering with the private key the result of
      hashing the packet with a hash function (MD5 or SHA1).  To be
      further defined.

   If no authentication is needed to ask for extra-features on the
   tunnel, then User_ID, Random and Signature fields are not required.

5.6.  End state

   This state represents the status on which the initiating device wants
   to shut down the tunnel.

   No messages to the TEP are required because the tunnel is discarded
   if it timeouts and no more NS (or similar) have been received.

6.  Security Considerations


7.  IANA Considerations

   This document does not have any specific IANA considerations.

8.  Acknowledgements

   The author would like to acknowledge the inputs from ...

9.  References

9.1.  Normative References

Palet & Diaz             Expires April 13, 2006                [Page 13]

Internet-Draft                    ATS6                      October 2005

9.2.  Informative References

   [1]  Nielsen, k., "Goals for Zero-Configuration Tunneling in 3GPP",
        draft-nielsen-v6ops-3GPP-zeroconf-goals-00 (work in progress),
        October 2004.

   [2]  Suryanarayanan, R., "Zero-Configuration Tunneling Requirements",
        draft-suryanarayanan-v6ops-zeroconf-reqs-00 (work in progress),
        October 2004.

   [3]  Parent, F., "Goals for Registered Assisted Tunneling",
        draft-ietf-v6ops-assisted-tunneling-requirements-01 (work in
        progress), October 2004.

   [4]  Palet, J., "Goals for Tunneling Configuration",
        draft-palet-v6tc-goals-tunneling-00 (work in progress),
        February 2005.

   [5]  Palet, J. and M. Diaz, "Analysis of IPv6 Tunnel End-point
        Discovery Mechanisms", draft-palet-v6ops-tun-auto-disc-03 (work
        in progress), January 2005.

   [6]  Palet, J., "IPv6 Tunnel End-point Automatic Discovery
        Mechanism", draft-palet-v6ops-solution-tun-auto-disc-01 (work in
        progress), October 2004.

   [7]  Palet, J., "Forwarding Protocol 41 in NAT Boxes",
        draft-palet-v6ops-proto41-nat-03 (work in progress),
        October 2003.

   [8]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
        for IP Version 6 (IPv6)", RFC 2461, December 1998.

Palet & Diaz             Expires April 13, 2006                [Page 14]

Internet-Draft                    ATS6                      October 2005

Authors' Addresses

   Jordi Palet Martinez
   San Jose Artesano, 1
   Alcobendas - Madrid
   E-28108 - Spain

   Phone: +34 91 151 81 99
   Fax:   +34 91 151 81 98
   Email: jordi.palet@consulintel.es

   Miguel Angel Diaz Fernandez
   San Jose Artesano, 1
   Alcobendas - Madrid
   E-28108 - Spain

   Phone: +34 91 151 81 99
   Fax:   +34 91 151 81 98
   Email: miguelangel.diaz@consulintel.es

Palet & Diaz             Expires April 13, 2006                [Page 15]

Internet-Draft                    ATS6                      October 2005

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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2005).  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.


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

Palet & Diaz             Expires April 13, 2006                [Page 16]

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