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

Versions: 00 01

Internet Engineering Task Force                                 J. Palet
Internet-Draft                                                   M. Diaz
Expires: July 22, 2006                                       Consulintel
                                                        January 18, 2006


                Automatic Tunneling Setup for/with IPv6
                   draft-palet-softwires-ats6-01.txt

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-
   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 July 22, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   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 support the use of 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 July 22, 2006                 [Page 1]


Internet-Draft                    ATS6                      January 2006


   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], [4] and mainly
   [5], trying to be compliant with the requirements enumerated in those
   documents.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Assumptions  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Protocol Description . . . . . . . . . . . . . . . . . . . . .  7
     5.1.  Start State  . . . . . . . . . . . . . . . . . . . . . . .  7
     5.2.  Sofwire Concentrator Discovery state . . . . . . . . . . .  8
     5.3.  Tunnel Setup Request state . . . . . . . . . . . . . . . .  8
     5.4.  Authenticated (Basic Tunnel) state . . . . . . . . . . . .  8
     5.5.  Authentication and Handshake state . . . . . . . . . . . .  9
     5.6.  Authenticated (Extended Tunnel) state  . . . . . . . . . . 10
     5.7.  End state  . . . . . . . . . . . . . . . . . . . . . . . . 10
   6.  Authentication and Handshake Options . . . . . . . . . . . . . 10
     6.1.  IPv6 Prefix  . . . . . . . . . . . . . . . . . . . . . . . 10
     6.2.  Dynamic/Static Prefix  . . . . . . . . . . . . . . . . . . 11
     6.3.  Keep-Alive Periodicity . . . . . . . . . . . . . . . . . . 11
     6.4.  NAT Type . . . . . . . . . . . . . . . . . . . . . . . . . 11
     6.5.  Cyphering Type . . . . . . . . . . . . . . . . . . . . . . 11
     6.6.  Encapsulation Type . . . . . . . . . . . . . . . . . . . . 11
   7.  Protocol Behavior in IPv4-only Infrastructures . . . . . . . . 12
     7.1.  Link-local Addresses . . . . . . . . . . . . . . . . . . . 12
     7.2.  Global IPv6 Address  . . . . . . . . . . . . . . . . . . . 13
       7.2.1.  Pre-Auth Realms  . . . . . . . . . . . . . . . . . . . 13
       7.2.2.  Non-Auth Realms  . . . . . . . . . . . . . . . . . . . 16
     7.3.  Handshake  . . . . . . . . . . . . . . . . . . . . . . . . 17
     7.4.  Extended Tunnel  . . . . . . . . . . . . . . . . . . . . . 19
     7.5.  Keep-Alive Packets . . . . . . . . . . . . . . . . . . . . 20
   8.  Protocol Behavior in IPv6-only Infrastructures . . . . . . . . 20
     8.1.  Pre-Auth Realms  . . . . . . . . . . . . . . . . . . . . . 21
       8.1.1.  Use of IPv4 addresses derived from the IPv6 one
               (Basic Tunnel) . . . . . . . . . . . . . . . . . . . . 21
       8.1.2.  Use of DHCP (Extended Tunnel)  . . . . . . . . . . . . 24
     8.2.  Non-Auth Realms  . . . . . . . . . . . . . . . . . . . . . 25
       8.2.1.  Use of IPv4 addresses derived from the IPv6 one



Palet & Diaz              Expires July 22, 2006                 [Page 2]


Internet-Draft                    ATS6                      January 2006


               (Basic Tunnel) . . . . . . . . . . . . . . . . . . . . 25
       8.2.2.  Use of DHCP (Extended Tunnel)  . . . . . . . . . . . . 25
     8.3.  The IPv6-in-IPv6 Case  . . . . . . . . . . . . . . . . . . 25
     8.4.  Keep-Alive Packets . . . . . . . . . . . . . . . . . . . . 26
       8.4.1.  IPv4 tunnel in IPv6-only infrastructures . . . . . . . 26
       8.4.2.  IPv6 tunnel in IPv6-only infrastructures . . . . . . . 26
   9.  Signaling Packets  . . . . . . . . . . . . . . . . . . . . . . 26
     9.1.  A&H Packet . . . . . . . . . . . . . . . . . . . . . . . . 26
     9.2.  ACK Packet . . . . . . . . . . . . . . . . . . . . . . . . 29
     9.3.  NO_ACK Packet  . . . . . . . . . . . . . . . . . . . . . . 31
   10. Signaling Encapsulation  . . . . . . . . . . . . . . . . . . . 33
   11. Peer-to-Peer Optimization  . . . . . . . . . . . . . . . . . . 34
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 34
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 35
   14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 35
     15.2. Informative References . . . . . . . . . . . . . . . . . . 35
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
   Intellectual Property and Copyright Statements . . . . . . . . . . 38































Palet & Diaz              Expires July 22, 2006                 [Page 3]


Internet-Draft                    ATS6                      January 2006


1.  Introduction

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

   The case for IPv6-only infrastructures is a fact, and consequently
   IPv4-in-IPv6 tunnels are necessary to support communications of old
   applications 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 that network (typically DSL, Cable, PLC, 3GPP,
      etc.).  In this case, the user will have, typically, a given
      profile in the network, which may have specific configuration
      parameters for that user.

   o  Non-authenticated user realms: Those where the user is not a pre-
      authenticated customer of the network, but apply for a (temporary)
      service, may be even free of charge, such as hot spots, 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.  In this case, the user
      will not have, a given profile in the network, so specific
      configuration parameters for that user will not be available.

   Some of the scenarios have their own requirements as stated in [1],
   [2], [3], [4] and [5], 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 an
   automated fashion.  This document presents the basis for such
   protocol, in order to make possible to a host/router the automatic
   setup of an IPvX-in-IPvY tunnel.


2.  Requirements

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



Palet & Diaz              Expires July 22, 2006                 [Page 4]


Internet-Draft                    ATS6                      January 2006


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

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

   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
      overhead).

   o  NAT/PAT and Firewall traversing.

   o  To authenticate the user.

   In addition, allows several optimizations and enhancements, such as
   the possibility to assign to the user a stable addresses or prefixes
   (by means of the embedded signaling protocol, or external protocols
   such as DHCP/DHCPv6/DHCP-PD), rebuilding the tunnel if the IP address
   changes, renumbering of the tunnel to match the delegated prefix,
   NAT/PAT auto-detection, and the support for alternative
   encapsulations.


3.  Assumptions

   The solution proposed is based on the following assumptions:

   o  The SC (Softwire Concentrator, according to the softwire
      terminology) is discovered by other means before starting the
      tunnel setup, or it is manually configured.

   o  The user host/router (SI, Softwire Initiator, client) 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 this 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 "anonymous".





Palet & Diaz              Expires July 22, 2006                 [Page 5]


Internet-Draft                    ATS6                      January 2006


   o  The SC, either intra or inter networks, will be reachable by at
      least one of the available encapsulation mechanisms.  This for
      example, ensures the support of NAT/PAT traversal regardless of
      the type of NAT (symmetric, full-conned, etc).


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, which are 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 or similar "closed" networks (could be almost
          equivalent to the ISP case), even if they are connected to
          Internet via upstream providers.

   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, may be
       free of charge, such as a hot spot, transition services in third
       party networks, guest visitors in an 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 (via an
          hotel network), which does not offer IPv6 support, neither a
          transition service.  The user however could use a transition
          mechanism by means of a SC located in a third party (nearby)
          ISP or domain.







Palet & Diaz              Expires July 22, 2006                 [Page 6]


Internet-Draft                    ATS6                      January 2006


5.  Protocol Description

   The solution is based on the following state diagram:


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




   Figure 1: ATS6 State Diagram

5.1.  Start State

   This state only represents the initial state.  The initiating device



Palet & Diaz              Expires July 22, 2006                 [Page 7]


Internet-Draft                    ATS6                      January 2006


   (SI) is ready to start the activation of the tunnel.

5.2.  Sofwire Concentrator Discovery state

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

   The document [6] has already analyzed this issue and [7] might be
   taken into account to be used as the SC discovery mechanism.  With
   regards to those documents, the SC is equivalent to the TEP (Tunnel-
   End-Point).

5.3.  Tunnel Setup Request state

   Once the SC has been discovered, the initiating device (SI) sends a
   request for the automatic tunnel setup.

   The request will be done slightly different depending on the
   available infrastructure and the kind of required tunnel, as
   described in the next sections.

   If the device is already authenticated (Pre-Auth), then the tunnel
   request is automatically accepted and a transition to the
   Authenticated state is done.  On the other hand, if the device is not
   yet authenticated (Non-Auth), an Authentication and Handshake
   procedure is required before accepting the tunnel request.

5.4.  Authenticated (Basic Tunnel) state

   This state represents the status on which the SI is already
   authenticated from the perspective of this protocol, coming from
   either the Tunnel Setup Request state (Pre-Auth users) or the
   Authentication and Handshake state (Non-Auth users).  In this state,
   the tunnel is kept active (up) on both ends (softwire concentrator
   and initiator sides).  The SI is ready to send/receive data.

   The SI could send periodically to the SC some kind of keep-alive
   packets in order to:

   o  Be sure that the tunnel continues up.

   o  Refresh possible timeout in NAT/PAT/Firewall tables.

   o  Allow the SC to do garbage collection.

   The periodicity of the keep-alive packets could be negotiated between



Palet & Diaz              Expires July 22, 2006                 [Page 8]


Internet-Draft                    ATS6                      January 2006


   the SC and the SI.  This is especially relevant in some cases, such
   as 3GPP, PSTN, ISDN, typically narrowband links, where 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.).

   When the SI does not needs the tunnel anymore, it can transit to the
   "End" state.

   If there is a change on the IP address of the SI, then a "Tunnel
   DOWN" must be forced, implying a transit to the "End" state, in order
   to keep the SC informed about the new IP address by means of the full
   ATS6 protocol re-execution, as it may happen also that the SC is 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 basic or Extended Tunnel (but it may be an "anonymous"
   authentication) and the transition to the Authenticated state.

   In Pre-Auth realms this state implies that the tunnel is already up
   and ready to send/receive data, but the SI might require extending
   the tunnel features (type of tunnel different to the one
   automatically setup, prefix delegation, etc.).  To do that the SC
   could require extra authentication in order to ensure that the SI has
   the right to obtain the solicited extra-features, to match the user
   against its pre-defined profile, etc.

   The actions to be done are:

   o  Only in Non-Auth realms:

      *  Getting the IP address for the SI side to be used with the
         tunnel.

      *  Setting-up the tunnel on both the SC and SI sides.

   o  Both in Pre-Auth and Non-Auth realms:

      *  User authentication.

      *  Handshake to obtain extra-features on the tunnel.

   If the negotiation succeeds, the transition is done towards either



Palet & Diaz              Expires July 22, 2006                 [Page 9]


Internet-Draft                    ATS6                      January 2006


   the Authenticated (Basic Tunnel) state or the Authenticated (Extended
   Tunnel) state for Non-Auth realms, or towards Authenticated (Extended
   Tunnel) for Pre-Auth realms.

5.6.  Authenticated (Extended Tunnel) state

   This state represents the status on which the SI was successfully
   authenticated and authorized to set-up a tunnel with extended
   features, which are not available at the Authenticated (Basic Tunnel)
   state.  The device is ready to send/receive data through the tunnel
   according to such extended features.

   The initially available extended features are described in the
   following sections.

5.7.  End state

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

   No messages to the SC are required because the tunnel is discarded
   when it time-out and no more NS (or similar) have been received.
   However one END message could be sent to the SC if a change in the IP
   address is detected in order to speed up the process of discarding
   the current tunnel, doing garbage collection and setting up a new
   tunnel.


6.  Authentication and Handshake Options

   During the Authentication and Handshake state, the following options
   are defined by the protocol (other options may be further specified):

6.1.  IPv6 Prefix

   The SI could require a specific prefix length (typically /48 or
   longer) for sub-netting purposes (such as for example the case where
   the SI is an xDSL CPE).  The choices are:

   o  Using DHCPv6 once the Basic Tunnel has been configured.  This
      option assumes that a DHCPv6 client is running on the SI and a
      DHCPv6 server at the SC.

   o  Using ATS6 built-in capability to delegate the requested prefix to
      the SI.  This simplifies the implementation in the device
      requiring the tunnel, because DHCPv6 client is not required,
      saving resources such as memory, additional packet exchanges and
      so on.



Palet & Diaz              Expires July 22, 2006                [Page 10]


Internet-Draft                    ATS6                      January 2006


   This option may be requested by the SI, which also could specify the
   desired prefix length.  The SC could also specify it, regardless of
   the SI request.

6.2.  Dynamic/Static Prefix

   The SI could require that the prefix is a static one instead of
   dynamic.  A static prefix will be delegated only if the user profile
   has the capability to associate it.

6.3.  Keep-Alive Periodicity

   As stated above, the keep-alive packets are useful to find out if the
   tunnel is up or down (for example in case the IPv4 address has
   changed), garbage collection and also to refresh the NAT/PAT tables.
   However, there can be network environments where there is a need to
   minimize the traffic exchange in order to save cost or resources
   (example cost of radio resources in 3GPP networks, dial-up or ISDN
   networks, etc.).  In such networks, the periodicity of the keep-alive
   packets can be set to infinite, which in practice means that no keep-
   alive packets are delivered at all.  Otherwise the period of such
   packets is assumed to be defined by the SC, but may be also requested
   by the SI.

6.4.  NAT Type

   In some situations the NAT is at the SC side, so the type is well
   know and the same for all the devices; this is typically the case for
   3GPP, dial-up, ISDN, among others.  In other cases, the NAT type may
   depend on the device(s) at the SI side.  In the first case, there is
   no need to start a NAT auto-detection procedure, but in both cases
   the SC should provide the information about if there is a NAT and
   what type is it.

6.5.  Cyphering Type

   All the handshake packets have to be signed in order to guarantee the
   identity of both, the SC and the SI.  This option specify the hash
   function that need to be used (MD5, SHA1, ...).

6.6.  Encapsulation Type

   Different encapsulations are possible (IPv6-in-IPv4, IPv6-in-UDP-
   IPv4, IPv4-in-IPv6, etc.).  The one to be actually used will be
   defined by the SC (it may depend on the existence of NAT).






Palet & Diaz              Expires July 22, 2006                [Page 11]


Internet-Draft                    ATS6                      January 2006


7.  Protocol Behavior in IPv4-only Infrastructures

7.1.  Link-local Addresses

   The SI is willing to obtain an IPv6 address, so it makes a link-local
   address which has embedded both its public IPv4 address and the MAC
   address, as follows:


                     16 bits      64 bits        32 bits
                     <----> <----------------> <-------->
             +------+------+------------------+----------+
             | FE80 | 0000 | YYYYYYYYYYYYYYYY | XXXXXXXX |
             +------+------+------------------+----------+

   Figure 2: IPv6 Link-local Address Format for the SI

   XXXXXXXX and YYYYYYYYYYYYYYYY are, respectively, the hexadecimal
   notation of the IPv4 public address (the one being used by the SI for
   the interface where the tunnel is required) and the Interface
   Identifier based on the MAC address, as generated by stateless auto-
   configuration.

   If a NAT box is used, the public IPv4 address can be discovered by
   using STUN [8], which should be available at the SC.  At this way the
   NAT type is also detected, as it will be required in the next steps.

   Embedding the public IPv4 address into the IPv6 link-local address
   has the advantage of allowing the SC to know where the IPv6 tunnel
   should be terminated, without needing to check other internal tables,
   and consequently there is no need to maintain any new table relating
   the IPv6 tunnels with the IPv4 addresses, and save the related
   resources.

   On the other hand, embedding the MAC address into the link-local has
   the advantage of allowing identifying each specific node behind a NAT
   box when each of them is a SI.

   The SC will also create its own IPv6 link-local address, which will
   be assumed by the SI to be already setup.  The SC link-local is built
   by embedding the IPv4 address of the SC, which is the only data known
   by the SI, as follows:









Palet & Diaz              Expires July 22, 2006                [Page 12]


Internet-Draft                    ATS6                      January 2006


                              80 bits         32 bits
                     <--------------------> <-------->
             +------+----------------------+----------+
             | FE80 | 00000000000000000000 | XXXXXXXX |
             +------+----------------------+----------+

   Figure 3: IPv6 Link-local Address Format for the SC

7.2.  Global IPv6 Address

   The basic IPv6 tunnel that the SI builds is automatic in the sense
   that it does not require manual configuration and it is built by
   using only a link-local address at each end of the tunnel.  On the
   other hand the global IPv6 address is obtained by means of stateless
   auto-configuration, once the link-local address of the SI is already
   setup.

   Then the SI sends an IPv6-in-IPv4 Router Solicitation (RS) packet [9]
   to the SC by using the link-local address just made.  The RS message
   is sent as payload, properly encapsulated so it can reach the SC
   link-local address.

   From now on, the process follows depending on the type of user's
   realm.

7.2.1.  Pre-Auth Realms

   In this case, the user is already authenticated, so there is no need
   to handshake for a Basic Tunnel.  Once the SC receives the IPv4-
   encapsulated RS from the SI, a transition to the Authenticated (Basic
   Tunnel) state is done and it replies with a single IPv4-encapsulated
   Router Advertisement (RA) packet [9] to the querying device and setup
   the tunnel.  A transition to the "Authenticated" state is done.

   The SI builds the global IPv6 address with the received prefix plus
   an Interface Identifier, which is taken from the 64 low-order bits of
   the link-local address, which have embedded its public IPv4 address.
   In this way, by observing the global IPv6 address, the SC knows where
   it has to forward the packets sent to such global IPv6 address.  The
   management of the routing table is hence simplified.

   If the IPv6 address changes, the global IPv6 address has to be
   changed also, which is not a problem because the IPv6 tunnel will
   transition to a down state.

   Note: Alternatively to this approach, it could be also possible to
   build the global IPv6 address by means of the stateless auto-
   configuration, by making the Interface Identifier based on the MAC



Palet & Diaz              Expires July 22, 2006                [Page 13]


Internet-Draft                    ATS6                      January 2006


   address of the interface being used.  In this way, the IPv4 address
   will not be embedded into the global IPv6 address, so if there is a
   change in the IPv4 address, only the link-local address corresponding
   to the IPv6 tunnel would change, but not the global one.  However
   this approach has the drawback that more routing management has to be
   used on the SC to update the routing table.

   Once the RA is received, the SI knows that there is no NAT or that
   the existing one supports 6in4 or "proto-41" forwarding [11].
   Furthermore this fact means that the tunnel has been setup on the SC
   side.

   At this point the SI is ready to send/receive data by using its IPv6
   global address on the Basic Tunnel.  If extended capabilities are
   required, a transition to the Authenticated (Extended Tunnel) state
   is required, as described in the following sections.

   If the RA is not received before timing out, the SI will send a new
   RS and even a third one if required.  This will avoid preventing the
   tunnel creation because either or both RS/RA are lost, for example
   because bad network conditions.

   After the third RS, if no RA is returned, the SI understands that
   some network elements prevent the use of IPv6-in-IPv4 tunneling from
   the SI to the SC.  In this case, the SI starts the detection of the
   NAT type and public IPv4 address, by means of STUN [8] and repeats
   the process by using UDP-in-IPv4 encapsulation (i.e., RS_ICMPv6-IPv6-
   UDP-IPv4).  The port number for receiving the packets at the SC needs
   to be defined, while the port number for receiving packets at the SI
   is taken from the received packets at the SC.  The tunnel setup
   process is the same, but packets are encapsulated as payload of UDP/
   IPv4.

   Note: It may be explored using the same UDP port as Teredo [10], for
   certain compatibility.  Also other possibilities may be explored
   here, such as GRE, PPTP, L2TP, etc. priority needs to be fixed.

   On the other hand, if the SC detects that there is already another
   tunnel associated to the same public IPv4 address, it means that
   several SIs are located behind a NAT, and should force an alternative
   encapsulation to IPv6-in-IPv4 (i.e., IPv6-UDP-IPv4), as this one will
   be only valid for the first user behind the NAT.

   This is done, as showed in Figure 7, by forcing the transition to the
   Authentication and Handshake state.  To do that, the SC sends one
   IPv4-encapsulated RA with the M bit set and it does not include the
   "Prefix Information" option on the RA.  The complete handshake
   procedure is explained in section 7.3.



Palet & Diaz              Expires July 22, 2006                [Page 14]


Internet-Draft                    ATS6                      January 2006


   Below some timing charts depict the packet exchanges in order to
   clarify the tunnel creation in Pre-Auth realms under different
   situations.


             SI                      SC
                         RS
              | -------------------> |   (Tunnel Request state)
              |                      |
              |    RA with prefix    |
              | <------------------- |   (Authenticated Basic Tunnel state)
              |                      |

   Figure 4: Basic Tunnel request in Pre-Auth realms with IPv6-in-IPv4
   support


             SI                      SC
                         RS
         ^    | -------------------> | \
      T1 |    |                      | |
         |    |                      | |
         v    |          RS          | |
         ^    | -------------------> | |  (Tunnel Request state)
      T2 |    |                      | |
         |    |                      | |
         v    |          RS          | |
              | -------------------> | |
              |                      | /
              |    RA with prefix    |
              | <------------------- |   (Authenticated Basic Tunnel state)
              |                      |

   Figure 5: Basic Tunnel request in Pre-Auth realms with IPv6-in-IPv4
   support (RAs lost)

   Tx: Timeout for waiting the RA once the RS has been sent.  This may
   be variable and configurable by the implementation.  Good values seem
   to be 1 second for the first and second timeouts (T1 and T2) and 3
   seconds for the last one (T3).











Palet & Diaz              Expires July 22, 2006                [Page 15]


Internet-Draft                    ATS6                      January 2006


             SI                      SC
                         RS
         ^    | -------------------> | \
      T1 |    |                      | |
         |    |                      | |
         v    |          RS          | |
         ^    | -------------------> | |
      T2 |    |                      | |
         |    |                      | |  (Tunnel Request state)
         v    |          RS          | |
         ^    | -------------------> | |
         |    |                      | |
         |    |                      | |
      T3 |    |                      | |
         |    |                      | |
         |    |                      | |
         v    |  RS (IPv6-UPD-IPv4)  | |
              | -------------------> | |
              |                      | /
              |    RA with prefix    |
              |    (IPv6-UPD-IPv4)   |
              | <------------------- |   (Authenticated Basic Tunnel state)
              |                      |

   Figure 6: Basic Tunnel request in Pre-Auth realms with no IPv6-in-
   IPv4 support


             SI                      SC
                         RS*
              | -------------------> |   (Tunnel Request state)
              |                      |
              |   RA, M=1, no prefix |
              | <------------------- |   (A&H state)
              |                      |

   Figure 7: Basic Tunnel request in Pre-Auth realms with more than one
   SI behind the same NAT

   (*) This RS can be IPv6-in-IPv4 or IPv6-UDP-IPv4, according to the
   type of IPv6-in-IPv4 support or not, as in previous figures.

7.2.2.  Non-Auth Realms

   In this case, the users have to be authenticated before being
   authorized to use the SC, so the SC sends one IPv4-encapsulated RA
   with the M bit set.  Furthermore it does not include the "Prefix
   Information" option on the RA and a transition to the "Authentication



Palet & Diaz              Expires July 22, 2006                [Page 16]


Internet-Draft                    ATS6                      January 2006


   and Handshake" state is done as shown in Figure 7.  The complete
   handshake procedure is explained in section 7.3.

   If there are more than one SI behind the same NAT, it is mandatory to
   build the IPv6 tunnel by means of UDP encapsulation, as far the Pre-
   Auth case above.  This negotiation is also done during the A&H state.

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

   If the RA is not received before timing out, the SI send again the RS
   a second and a third time if required.  This will prevent that the
   tunnel is not created because either or both lost RS/RA due to bad
   network conditions.  As for the Pre-Auth case, timeouts may be
   variable and configurable by the implementation.  Good values seem to
   be 1 second for the first and second timeouts (T1 and T2), and 3
   seconds for the last one (T3).  After the third RS, if no RA is
   received back, the SI understands that IPv6-in-IPv4 is not supported
   on the path to the SC.  In this case, the SI starts the detection of
   the NAT type and public IPv4 address, by means of STUN [8] and
   repeats the process by using UDP encapsulation (i.e., RS_ICMPv6-IPv6-
   UDP-IPv4).  The port number for receiving the packets at the SC needs
   to be defined, while the port number for receiving packets at the SI
   is taken from the received packets at the SC.

   Note: It may be explored using the same UDP port as Teredo [10], for
   certain compatibility.  Also other possibilities may be explored
   here, such as GRE, PPTP, L2TP, etc. priority needs to be fixed.

   During the handshake, the SI can request for extending the tunnel
   capabilities, so a transition to the Authenticated (Extended Tunnel)
   can be done already, if the authentication succeeds.  The transit to
   the Authenticated (Basic Tunnel) state is only done in case the SI
   does not request for extended features.

7.3.  Handshake

   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
   SC.  The packet/s will contain user identification, authentication
   and parameter information.  The packet exchange between SC and SI
   will be short in time to keep the process as simple as possible.

   In Non-Auth realms the SI starts the A&H process but after the SC
   indicate it is required in "Tunnel Setup Request" state, by means of



Palet & Diaz              Expires July 22, 2006                [Page 17]


Internet-Draft                    ATS6                      January 2006


   the M bit in the RA (without Prefix Information), as depicted in
   Figure 7.

   In Pre-Auth realms the SI also starts the A&H process at any time
   from "Authenticated" state.  Also it might be possible for the SC to
   force the A&H from the Tunnel Request state if it detects more than
   one device behind the same NAT, when it receives the first IPv4-
   encapsulated RS from a new SI.  The A&H process is indicated by means
   of the M bit being set in the RA (without "Prefix Information"), as
   shown in Figure 7 above.  In this case the SI is not forced to
   include user's login information because he is already authenticated
   within the realm.

   The A&H packet sent by the SI indicates the options that the SI
   wishes for setting-up the tunnel (i.e., IPv6 tunnel in an IPv4-only
   infrastructure, IPv4 tunnel in an IPv6-only infrastructure, etc.).

   Once the SC receives the "A&H Packet", it checks the right or policy
   of the user at the SC or associated database.  If the data match the
   required policy, the tunnel is activated, modified, or extended with
   the new requested features.  Then the SC sends to the SI an
   acknowledge (ACK) packet with the setup that is granted (i.e., IPv6-
   in-IPv4 tunnel, IPv6-UDP-IPv4 tunnel with DHCPv6-PD, etc.).  When
   needed, the SC also sends the RA in order to communicate to the SI
   the IPv6 prefix needed to build the global IPv6 address (Basic
   Tunnel) as explained before.

   If the authentication data is wrong or does not match the necessary
   credentials, rights, policy, etc., the SC replies with information
   about what is wrong by means of a NO_ACK packet, 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 the later one, the
   tunnel continues up but the required extended features are not
   provided.

   The following diagram summarized the steps during the Authentication
   & Handshake phase:













Palet & Diaz              Expires July 22, 2006                [Page 18]


Internet-Draft                    ATS6                      January 2006


             SI                      SC
                        RS*
              | -------------------> |  (Tunnel Request state)
              |                      |
              |   RA, M=1, no prefix |
              | <------------------- |  (A&H state)
              |                      |
              |      A&H packet      |
              | -------------------> |
              |                      |
              |          ACK         | \
              | <------------------- | |
              |                      | | Handshake succeeded
              |    RA (if needed)    | |
              | <------------------- | /
              |                      |
              |       NO_ACK         |
              | <------------------- | => Handshake failed

   Figure 8: Handshake for Non-Auth realms and Pre-Auth realms with more
   than one SI behind a NAT

   (*) This RS can be IPv6-in-IPv4 or IPv6-UDP-IPv4, according to the
   type of NAT as depicted in Figures 5 and 6.

   The following diagram summarizes the steps during the Authentication
   & Handshake phase for authenticated users (Pre-Auth or Non-Auth after
   authentication) willing to extend the Basic Tunnel:


          SI                      SC
                  A&H packet
           | -------------------> |
           |                      |
           |          ACK         |
           | <------------------- | ==> Handshake succeeded
           |                      |
           |       NO_ACK         |
           | <------------------- | ==> Handshake failed

   Figure 9: Handshake for Authenticated users requesting for Extended
   Tunnel

7.4.  Extended Tunnel

   The Basic Tunnel might not be enough for the SI because might need to
   arrange sub-nets or even might require a predefined prefix.  For this
   reason, the SI could initiate the handshake for extending the tunnel



Palet & Diaz              Expires July 22, 2006                [Page 19]


Internet-Draft                    ATS6                      January 2006


   capabilities at any time according to the figure 9.

   One important option available for Extended Tunnels is the prefix
   delegation.  Towards this, during the handshake stage, the SI request
   a delegated prefix (shorter than 64 bits, typically a /48 one) and
   the way how it expects to receive it (DHCPv6 or ACK packet which is
   simpler).

   Also the SI can request for a dynamic prefix or a static one,
   according to its needs.  If the user has rights to ask for such a
   feature the SC replies with an ACK packet.  Otherwise the SC sends a
   NO_ACK packet and the process stops.

   Once the new prefix is received by the SI, the Basic Tunnel which is
   based on the link-local addresses is renumbered.  The tunnel will use
   the first /64 from the delegated prefix in order to simplify the
   routing table (I-D.palet-v6ops-point2point) at the SC.

7.5.  Keep-Alive Packets

   Once the tunnel is up and running, in IPv4-only infrastructures, the
   keep-alive packet will be the ICMPv6 Neighbor Solicitation packets
   [9], being the SC IPv6 link-local address the target and the SI IPv6
   link-local address the source.  The SC must reply with the proper
   ICMPv6 Neighbor Advertisement packet [9] in order to let know to the
   SI that the tunnel is still up and also to refresh a possible NAT/PAT
   table.

   The default keep-alive periodicity will be 60 seconds.  If not keep-
   alive packets are received at the SC within the configured keep-alive
   period, the SC will bring down the tunnel and do garbage collection.


8.  Protocol Behavior in IPv6-only Infrastructures

   Being the infrastructure IPv6-ready, the "A&H Packet" below described
   is already directly usable, as it is 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.

   Following a similar philosophy as in the case of IPv4-only
   infrastructure, the SI 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  IPv4 address derived from the IPv6 one: By using the global IPv6
      address used in this communication by the SI, a hash or similar



Palet & Diaz              Expires July 22, 2006                [Page 20]


Internet-Draft                    ATS6                      January 2006


      algorithm could be used to create an IPv4 address, probably in the
      network 10/8.  Even if the combination of using the IPv6 global
      address and the network 10/8 provides a lower probability of
      address duplication, However it might occur that Duplicate
      Addresses are generated, it may be necessary/convenient to run a
      Duplicate Address Detection algorithm at the SC.

   o  DHCP: The SC should either be the DHCP (IPv4) server or relay/
      proxy for an external one.  DHCPv6 could also be considered, as it
      could make the process much simpler, but in general DHCPv6 support
      is weaker.  This option is preferred over the previous one,
      because it avoids the existence of Duplicate Addresses.

   The procedure in IPv4-only infrastructures is simpler because the
   native IPv6 infrastructure is already available at the SI, so there
   is no need to built artificial link-local address like in the case of
   IPv4-only infrastructure (as they will be already available at every
   interface).

   The Basic Tunnel for this case is considered as an IPv4 tunnel where
   the IPv4 address is derived from the global IPv4 one.  If the SI is
   willing to use and address provided by the SC (either via DHCP or ACK
   packet), then it will use an IPv4 link-local address [12] to start
   the Tunnel Request and then will transition to the A&H state to
   request an address by means of DHCP, as explained below.

   All the handshake process is done by using the ATS6-ICMPv6 packets
   because native IPv6 support is available, so there is no need for
   looking for other protocols in this case.  However, it is possible to
   use other protocols like UDP, TCP, PPP, etc. rather than ICMPv6 to
   perform the handshake process.

8.1.  Pre-Auth Realms

8.1.1.  Use of IPv4 addresses derived from the IPv6 one (Basic Tunnel)

   The IPv4 address should be generated by an algorithm (to be defined)
   from the global IPv6 address used in the communication with the SC.
   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 10.0.0.0/8 address.  The SC will
   behave as the default gateway and also NAT for that SI, being the
   first IPv4 address of the pool (10.0.0.1) the one assigned to the SC.

   The Tunnel Request is indicated to the SC as a sequence of three
   predefined-length ICMPv4 ping request packets (6 bytes for the first
   ping request packet, 7 bytes for the second one and 8 bytes for the



Palet & Diaz              Expires July 22, 2006                [Page 21]


Internet-Draft                    ATS6                      January 2006


   third one) as shown in Figure 10.  Such ping request packets have as
   source the IPv4 address extracted from the global IPv6 one (hashing
   function) and they are directly encapsulated into IPv6 packets (with
   IPv6 global address as source).

   Because the user is already authenticated, after receiving the tunnel
   request, the SC will reply with one ICMPv4 ping reply packet to every
   ping request, indicating with the last one that the tunnel is already
   up in the SC side.  The SC will extract the SI IPv4 address from the
   received ICMPv4 ping request packets.  When receiving the third
   ICMPv4 ping reply, the SI understands that the tunnel is ready to
   send/receive packets and a transition to the Authenticated (Basic
   Tunnel) state is done.


             SI                      SC
                ICMPv4 ping req. seq.
              | ------------------->  |   (Tunnel Request state)
              |                       |
              | ICMPv4 ping rep. seq. |
              | <-------------------  |   (Authenticated Basic Tunnel state)
              |                       |

   Figure 10: Basic Tunnel request in Pre-Auth realms for IPv6-only
   infrastructures

   If three ICMPv4 ping replies are not received, either because any of
   them has been lost or not send, the SI will send again the complete
   sequence of ICMPv4 ping requests, up to two more times, in a similar
   fashion as for the tunnel request for the IPv4-only infrastructure.
   The timeouts for the whole ICMPv4 ping reply sequence may be variable
   and configurable by the implementation.  Good values seem to be 1
   second for the first and second sequence timeouts (T1 and T2) and 3
   seconds for the last one (T3).

















Palet & Diaz              Expires July 22, 2006                [Page 22]


Internet-Draft                    ATS6                      January 2006


             SI                      SC
                ICMPv4 ping req. seq.
         ^    | --------------------> | \
      T1 |    |                       | |
         |    |                       | |
         v    | ICMPv4 ping req. seq. | |
         ^    | --------------------> | |  (Tunnel Request state)
      T2 |    |                       | |
         |    |                       | |
         v    | ICMPv4 ping req. seq. | |
              | --------------------> | |
              |                       | /
              | ICMPv4 ping rep. seq. |
              | <-------------------- |   (Authenticated Basic Tunnel state)
              |                       |

   Figure 11: Basic Tunnel request in Pre-Auth realms for IPv6-only
   infrastructures with lost ping replies

   If the SC detects that the IPv4 address used by the SI is already
   used by another one, it will not send any ICMPv4 ping reply.  After
   the third ICMPv4 ping request sequence that has not been replied, the
   SI understands that there is some trouble with the tunnel request
   (i.e., duplicate IPv4 address) and it transitions to the A&H state to
   request a tunnel as shown in Figure 12 below.


























Palet & Diaz              Expires July 22, 2006                [Page 23]


Internet-Draft                    ATS6                      January 2006


             SI                      SC
                ICMPv4 ping req. seq.
         ^    | --------------------> | \
      T1 |    |                       | |
         |    |                       | |
         v    | ICMPv4 ping req. seq. | |
         ^    | --------------------> | |
      T2 |    |                       | |
         |    |                       | |  (Tunnel Request state)
         v    | ICMPv4 ping req. seq. | |
         ^    | --------------------> | |
         |    |                       | |
         |    |                       | |
      T3 |    |                       | |
         |    |                       | |
         |    |                       | |
         v    |          A&H          | /
              | --------------------> | \
              |                       | |  (A&H state)
              |           ACK         | |
              | <-------------------- | | Handshake successful
              |                       | |
              |                       | |
              |          NO_ACK       | |
              | <-------------------- | | Handshake unsuccessful
              |                       | /

   Figure 12: Basic Tunnel request in Pre-Auth realms for IPv6-only
   infrastructures with duplicate IPv4 address

   With the ACK packet the SC communicates to the SI how the IPv4
   address is provided (DHCP or ACK packet).

8.1.2.  Use of DHCP (Extended Tunnel)

   If the SI is willing to use an IPv4 address provided from the SC pool
   rather than using the one derived from the IPv6 global address, the
   tunnel request process is done by using an IPv4 link-local address
   (169.254.0.0/16) [12].  After receiving the first ICMPv4 ping request
   packet, the SC will realize that it has not to send ping replies and
   a transition to the A&H state is done as shown in Figure 12.

   Because the user is already authenticated in the network, there is no
   need to include in the A&H packet information about the user's login,
   but optionally it could be included.

   Once the ACK packet coming from the SC is received, the SI which is
   requesting an IPv6-in-IPv4 tunnel, need to construct a DHCP request



Palet & Diaz              Expires July 22, 2006                [Page 24]


Internet-Draft                    ATS6                      January 2006


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

   As the user is already authenticated, the SC delivers an IPv4 address
   to the SI, 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 SI, which will de-capsulate it for configuring its IPv4
   address.

   This provides a better solution (for example public IPv4 addresses
   could be used as the DHCP address pool), but requires DHCP client
   support at the SI and DHCP server a the SC side.

   Once the process of having a pre-defined IPv4 address if completed, a
   transition to the Authenticated (Extended Tunnel) state is done.

8.2.  Non-Auth Realms

8.2.1.  Use of IPv4 addresses derived from the IPv6 one (Basic Tunnel)

   In this case, the SI needs to be authenticated, so a transition to
   the A&H state is done by not replying to any ICMPv4 ping request
   packet as shown in Figure 12.

   Once the ACK is received, the authentication succeeded, and the
   tunnel can be considered as activated in both, the SC and the SI
   sides, so there is no need for further ICMPv4 reply packets from the
   SC.  In this case, the IPv4 address is not provided neither via DHCP
   nor the ACK packet.

8.2.2.  Use of DHCP (Extended Tunnel)

   In this case, the SI uses one IPv4 link-local address to initiate the
   tunnel request as explained for the IPv4-DCHP/Pre-Auth case.  However
   it needs to be authenticated, so a transition to the A&H state is
   done by not replying to any ICMPv4 ping request packet as shown in
   Figure 12.

   Once the authentication succeeded, the SC will reply with an ACK
   packet indicating that it is ready to receive the a DHCP IPv6-
   encapsulated packet from the SI and the process is then continued the
   same way as in the Pre-Auth realms case.

8.3.  The IPv6-in-IPv6 Case

   In IPv6-only infrastructures, it could be needed and IPv6-in-IPv6



Palet & Diaz              Expires July 22, 2006                [Page 25]


Internet-Draft                    ATS6                      January 2006


   tunnel, for example when the infrastructure does not natively support
   IPv6 multicast.

   In this case the procedure would be as explained in the case of IPv4-
   only infrastructures, with the only difference being in the no need
   to build the link-local address of the tunnel, as this is already
   natively available in this case.  Figures 4, 7 and 8 show details
   about the tunnel request procedure.

8.4.  Keep-Alive Packets

   Once the tunnel is up and running in IPv6-only infrastructures, the
   type of keep-alive packet will depend on the type of tunnel.

   The default keep-alive periodicity will be 60 seconds.  If no keep-
   alive packets are received at the SC within the configured keep-alive
   period, the SC will shut down the tunnel and will do garbage
   collection.

8.4.1.  IPv4 tunnel in IPv6-only infrastructures

   In this type of tunnels the keep-alive will be ICMPv4 ping request
   packets, being the destination the SC IPv4 address and the source the
   SI IPv4 address configured with the tunnel.  The SC must reply in
   order to let know the SI that the tunnel is still up.

8.4.2.  IPv6 tunnel in IPv6-only infrastructures

   In this type of tunnels the keep-alive will be ICMPv6 Neighbor
   Solicitation packets [9], being the SC IPv6 link-local address the
   target and the SI IPv6 link-local address the source one.  The SC
   must reply with the ICMPv6 Neighbor Advertisement packet [9] in order
   to let know to the SI that the tunnel is still up.


9.  Signaling Packets

   For signaling the authentication and tunnel setup process, three
   types of packets are defined: A&H packet, ACK packet and NO_ACK
   packet.  These packets are described in the following sections.

9.1.  A&H Packet

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




Palet & Diaz              Expires July 22, 2006                [Page 26]


Internet-Draft                    ATS6                      January 2006


   0                                    16                                31
   +-----------------------------------+-----------------------------------+
   |            ID Length              |           Signature Length        |
   +--------+-------------+------------+-----------------+--------+--------+
   | Packet |   Tunnel    |                              | Signat.| Encaps.|
   | Type   |    Type     |           Reserved           |  Type  |  Type  |
   +--------+-------------+------------------------------+--------+--------+
   |                               USER_ID                                 |
   +-----------------------------------------------------------------------+
   |                                Random                                 |
   +-----------------------------------------------------------------------+
   |                               Signature                               |
   +-----------------------------------------------------------------------+

   Figure 13: 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 (16 bits): The length of the USER_ID field.

   o  Signature Length (16 bits): The length of Signature field.

   o  Packet Type (4 bits): Information about the packet type (A&H, ACK
      or NO_ACK).

   o  Tunnel Type (5 bits): The required tunnel type is indicated by
      setting-up every flag in this field, as follows (from most
      significant to least significant bits):

      *  I: Type of native infrastructure (set for IPv4, unset for
         IPv6).

      *  O: Type of overlay infrastructure (set for IPv4, unset for
         IPv6).

      *  T: Type of tunnel (set for Basic, unset for Extended).

      *  D: Type of desired IPv6/IPv4 prefix/address (set for Dynamic,
         unset for Static).

      *  P: Type of IPv6/IPv4 prefix/address provision (set for DHCP,
         unset ACK packet).

      *  Some examples provided below:

      *  I O T D P




Palet & Diaz              Expires July 22, 2006                [Page 27]


Internet-Draft                    ATS6                      January 2006


      *  1 0 1 x x -> Basic IPv6 tunnel in IPv4-only infrastructure

      *  1 0 0 0 1 -> Extended IPv6 tunnel in IPv4-only infrastructure,
         with DHCPv6-PD

      *  0 1 1 x x -> Basic IPv4 tunnel in IPv6-only infrastructure

      *  0 0 1 x x -> Basic IPv6 tunnel in IPv6-only infrastructure

      *  0 0 0 0 0 -> Tunnel is down, either because the SI does not
         need any more the tunnel, or the native infrastructure IP
         address has changed.  In any case, a transition to the END
         state is forced in both, the SI and SC.

   o  Reserved (13 bits): Reserved bits for future use.

   o  Signature Type (4 bits): The type of signature to be used in the
      handshake process.

   o  Encapsulation Type (6 bits): The required encapsulation type is
      indicated by setting-up every flag in this field.  The meaning of
      the flags (from most significant to least significant bits) are as
      follow (set for required, unset not required):

      *  G: GRE

      *  I: IP

      *  L: L2TP

      *  P: PPP

      *  T: PPTP

      *  U: UDP

      *  Some examples provided below (Type of Tunnel indicated by the
         Tunnel Type field above):

      *  G I L P T U

      *  0 1 1 0 1 1 -> Tunnel using L2TP/PPTP/UDP (example, IPv6/L2TP/
         PPTP/UDP/IPv4)

      *  0 1 0 0 0 0 -> Tunnel using only IP-in-IP (example, IPv6/IPv4)

      *  0 1 0 0 0 1 -> Tunnel using UDP (example IPv6-UDP-IPv4)




Palet & Diaz              Expires July 22, 2006                [Page 28]


Internet-Draft                    ATS6                      January 2006


   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
      duplicate signatures.  Either a random number, date, etc.  To be
      further defined.

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

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

9.2.  ACK Packet

   This packet acknowledges the SI request and indicates the options
   that have been accepted.  Also the SC can inform by means of this
   packet, about some parameters to the SI.  The format is as follows:


      0                                    16                                31
      +-----------------------------------+-----------------------------------+
      |            ID Length              |           Signature Length        |
      +--------+-------------+------------------+-----+-----+--------+--------+
      | Packet |   Tunnel    |      Prefix      |Keep.| NAT | Signat.| Encaps.|
      | Type   |    Type     |      Length      |Peri.| Typ.|  Type  |  Type  |
      +--------+-------------+------------------+-----+-----+--------+--------+
      |                           Prefix/IPv4 Address                         |
      +-----------------------------------------------------------------------+
      |                                 USER_ID                               |
      +-----------------------------------------------------------------------+
      |                                 Random                                |
      +-----------------------------------------------------------------------+
      |                                Signature                              |
      +-----------------------------------------------------------------------+

   Figure 14: ATS6 ACK packet

   o  ID Length (16 bits): The length of the USER_ID field.

   o  Signature Length (16 bits): The length of Signature field.

   o  Packet Type (4 bits): Information about the packet type (ACK in
      this case).




Palet & Diaz              Expires July 22, 2006                [Page 29]


Internet-Draft                    ATS6                      January 2006


   o  Tunnel Type (5 bits): The tunnel type that has been accepted.
      Same meaning for the flags as above for the A&H packet.

   o  Prefix Length (7 bits): If the SI request for a prefix delegation,
      indicates the desired prefix length.  If the SC responds,
      indicates the delegated prefix length.

   o  Keep-Alive Periodicity (3 bits): The periodicity defined by the SC
      for the keep-alive packets.  Possible values as follows:

      *  000: One every minute

      *  001: One every 3 minutes

      *  010: One every 10 minutes

      *  011: One every 20 minutes

      *  100: One every 30 minutes

      *  101: One every 60 minutes

      *  110: One every 240 minutes

      *  111: No keep-alive packets are required at all

      *  Note: It may be considered as convenient to random the keep-
         alive packets delivery, within the maximum periodicity
         indicated by this field, in order to statistically lower the
         simultaneous number of packets from the SIs to the SC (and SC
         to SIs), increasing the scalability of the system (do be
         further analyzed).

   o  NAT Type (3 bits): The SC confirms to the SI if a NAT has been
      detected and the type:

      *  000 - no NAT or proto-41 compliant.

      *  001 - full-conned NAT.

      *  010 - symmetric NAT.

      *  011 - asymmetric NAT.

      *  1xx - Reserved for future use.






Palet & Diaz              Expires July 22, 2006                [Page 30]


Internet-Draft                    ATS6                      January 2006


   o  Signature Type (4 bits): The type of signature that has been
      accepted.

   o  Encapsulation Type (6 bits): The type of encapsulation that has
      been accepted.  Same meaning for the flags as above for the A&H
      packet.

   o  Prefix/IPv4 address (64 bits): If the prefix or IPv4 address is
      provided by means of the ACK package, this field contains such
      parameter.  The field is zero-left-padded.

   o  USER_ID: The user login.  It can be an ASCII text, coded or
      whatever.  It is assigned during the registration process, and
      should match the one sent in the A&H packet.

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

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

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

9.3.  NO_ACK Packet

   This packet does not acknowledge the SI request and indicates the
   failure of the requested options.  The format is as follows:




















Palet & Diaz              Expires July 22, 2006                [Page 31]


Internet-Draft                    ATS6                      January 2006


      0                                    16                                31
      +-----------------------------------+-----------------------------------+
      |            ID Length              |           Signature Length        |
      +--------+-------------+------------+-----------------+--------+--------+
      | Packet |   Tunnel    |  Reserved  |      Error      | Signat.| Encaps.|
      | Type   |    Type     |            |      Code       |  Type  |  Type  |
      +--------+-------------+------------+-----------------+--------+--------+
      |                                USER_ID                                |
      +-----------------------------------------------------------------------+
      |                                 Random                                |
      +-----------------------------------------------------------------------+
      |                                Signature                              |
      +-----------------------------------------------------------------------+

   Figure 15: ATS6 NO_ACK packet

   o  ID Length (16 bits): The length of the USER_ID field.

   o  Signature Length (16 bits): The length of Signature field.

   o  Packet Type (4 bits): Information about the packet type (NO_ACK in
      this case).

   o  Tunnel Type (6 bits): The tunnel type that has been requested.

   o  Reserved (6 bits): Bits reserved for future use.

   o  Error Code (8 bits): The reason of the "no acknowledgment".

   o  Signature Type (4 bits): The type of signature requested by the
      SI.

   o  Encapsulation Type (4 bits): The type of encapsulation requested
      by the SI.

   o  USER_ID: The user login.  It can be an ASCII text, coded or
      whatever.  It is assigned during the registration process.

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

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

   If no authentication is needed to request for extra-features on the



Palet & Diaz              Expires July 22, 2006                [Page 32]


Internet-Draft                    ATS6                      January 2006


   tunnel, then USER_ID, Random and Signature fields are not required.


10.  Signaling Encapsulation

   It is important to note that at the time being, the signaling packets
   are chosen to be encapsulated as ICMPv6 ones (type to be
   standardized), assuming that the networks will tend to have, over the
   time, more native IPv6 support, so this will allow a more simpler
   support of IPv4-in-IPv6 encapsulation.  Furthermore, using ICMPv6
   packets simplifies both the resources and the implementation of ATS6
   capable SCs and SIs.

   However, other choices are also possible, such as ICMPv6 packets
   encapsulated in UDP ones, UDP packets with the same format as the
   ICMPv6 here described, TCP, etc.  The way how the signaling packets
   are encapsulated is not as important as the signaling itself.  It
   will be also possible to support several of them, in order to ensure
   the success of the tunnel setup under any infrastructure conditions.

   The following are examples showing some of these alternatives:


        +-----------------------------------------------+
        |               SIGNALING PACKET                |
        +-----------------------------------------------+
        |                 ICMPv6 HEADER                 |
        |                 (to be defined)               |
        +-----------------------------------------------+
        |                  IP  HEADER                   |
        +-----------------------------------------------+

   Figure 16: ATS6 Signaling packets in ICMPv6 packets


        +-----------------------------------------------+
        |               SIGNALING PACKET                |
        +-----------------------------------------------+
        |                 ICMPv6 HEADER                 |
        |                 (to be defined)               |
        +-----------------------------------------------+
        |                   UDP HEADER                  |
        +-----------------------------------------------+
        |                   IP HEADER                   |
        +-----------------------------------------------+

   Figure 17: ATS6 Signaling packets in ICMPv6-UDP packets




Palet & Diaz              Expires July 22, 2006                [Page 33]


Internet-Draft                    ATS6                      January 2006


        +-----------------------------------------------+
        |               SIGNALING PACKET                |
        +-----------------------------------------------+
        |                   UDP HEADER                  |
        +-----------------------------------------------+
        |                   IP HEADER                   |
        +-----------------------------------------------+

   Figure 18: ATS6 Signaling packets as payload of UDP packets


11.  Peer-to-Peer Optimization

   In case direct peer-to-peer among SIs is wanted, when they are
   connected in the same IPv4-only infrastructure, ATS6 provides a way
   to avoid all the encapsulated traffic being handled by the SC.

   An specific IPv6 prefix could be reserved for that purpose, so SIs
   would have one additional IPv6 address, which is built by appending
   to such prefix the same Interface Identifier used for the global IPv6
   address in the Basic Tunnel case described before.

   In this way, communication packets between peers do not need to be
   forwarded to the SC and then back to the peer, but instead, they can
   travel directly from one peer to the other one and vice-versa.

   Lots of resources (network, memory, CPU load, etc.) are saved at the
   SC by this means, in addition to the lower RTT, which improves the
   scalability of the protocol.

   Given the fact that SIs could be most probably behind a NAT box when
   trying to use this peer-to-peer optimization, all them will use UDP
   packets for building the tunnel, so in order to use the peer-to-peer
   optimization, the encapsulation should be IPv6-in-UDP-in-IPv4.  It
   could be explored using the same prefix as Teredo [10] in order to
   allow also compatibility with that protocol and consequently allow
   peer-to-peer among Teredo [10] and ATS6 nodes.

   This optimization needs further detailed analysis.


12.  Security Considerations

   Threats on the tunnel data can be minimized by doing address-ingress
   filtering at the SC of both outer IPvX and inner IPvY protocols (i.e.
   in the IPv6-in-IPv4 tunnel case, the outer protocol is IPv6 and the
   inner one is IPv4).  In this way spoofed address attacks are
   prevented not only for the inner address but also for the outer ones.



Palet & Diaz              Expires July 22, 2006                [Page 34]


Internet-Draft                    ATS6                      January 2006


   If more security is required, the guidelines pointed by [13] to
   secure the tunnels should be followed.


13.  IANA Considerations

   TBD.


14.  Acknowledgements

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


15.  References

15.1.  Normative References

15.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]   Li, X., "Softwire Problem Statement",
         draft-ietf-softwire-problem-statement-00 (work in progress),
         December 2005.

   [6]   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.

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




Palet & Diaz              Expires July 22, 2006                [Page 35]


Internet-Draft                    ATS6                      January 2006


   [8]   Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN
         - Simple Traversal of User Datagram Protocol (UDP) Through
         Network Address Translators (NATs)", RFC 3489, March 2003.

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

   [10]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs",
         draft-huitema-v6ops-teredo-05 (work in progress), April 2005.

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

   [12]  Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration
         of IPv4 Link-Local Addresses", RFC 3927, May 2005.

   [13]  Savola, P., "Using IPsec to Secure IPv6-in-IPv4 Tunnels",
         draft-ietf-v6ops-ipsec-tunnels-01 (work in progress),
         August 2005.































Palet & Diaz              Expires July 22, 2006                [Page 36]


Internet-Draft                    ATS6                      January 2006


Authors' Addresses

   Jordi Palet Martinez
   Consulintel
   Molino de la Navata, 75
   La Navata - Galapagar - Madrid
   E-28420 - Spain

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


   Miguel Angel Diaz Fernandez
   Consulintel
   Molino de la Navata, 75
   La Navata - Galapagar - Madrid
   E-28420 - Spain

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





























Palet & Diaz              Expires July 22, 2006                [Page 37]


Internet-Draft                    ATS6                      January 2006


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 (2006).  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.




Palet & Diaz              Expires July 22, 2006                [Page 38]


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