Internet Engineering Task Force                                 J. Palet
Internet-Draft                                                   M. Diaz
Expires: April 24, 2005                                      Consulintel
                                                               M. Mackay
                                                    Lancaster University
                                                        October 24, 2004

              Evaluation of IPv6 Auto-Transition Algorithm

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
   RFC 3668.

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

   Internet-Drafts 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 24, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).


   This memo evaluates a method called "auto-transition" to ensure that
   any device can obtain IPv6 connectivity at any time and whatever
   network is attached to, even if such network is connected to Internet
   only with IPv4 or already offers IPv6 but with poor performance.

Palet, et al.            Expires April 24, 2005                 [Page 1]

Internet-Draft     Evaluation of IPv6 Auto-Transition       October 2004

   The algorithm looks for the best possible transition mechanism
   according to performance criteria information available as well as
   the scenario where the device is located.

   By implementing such auto-transition algorithm in either or both end
   nodes or middle boxes (CPEs), users could always obtain IPv6
   connectivity with no human intervention.

   The document doesn't actually provides a complete solution, just an
   evaluation of the problem and the requirements towards a future
   documented solution.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Auto-Transition Overview . . . . . . . . . . . . . . . . . . .  3
   3.  Auto-Transition Requirements . . . . . . . . . . . . . . . . .  4
     3.1   Selection of the proper transition mechanism . . . . . . .  5
     3.2   Change of transition mechanism . . . . . . . . . . . . . .  7
     3.3   New transition/tunneling mechanisms  . . . . . . . . . . .  8
       3.3.1   Layer 2 tunnels  . . . . . . . . . . . . . . . . . . .  9
       3.3.2   Layer 3 tunnels  . . . . . . . . . . . . . . . . . . .  9
       3.3.3   Layer 4 tunnels  . . . . . . . . . . . . . . . . . . . 10
     3.4   Discovery of the IPv6 End Point  . . . . . . . . . . . . . 11
   4.  Nomadicity Considerations  . . . . . . . . . . . . . . . . . . 12
   5.  Network Managed Transition . . . . . . . . . . . . . . . . . . 14
     5.1   Policy Based Networks  . . . . . . . . . . . . . . . . . . 15
     5.2   Transitioning Server . . . . . . . . . . . . . . . . . . . 15
     5.3   Host operation . . . . . . . . . . . . . . . . . . . . . . 16
     5.4   Server operation . . . . . . . . . . . . . . . . . . . . . 18
   6.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 19
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
   9.1   Normative References . . . . . . . . . . . . . . . . . . . . 20
   9.2   Informative References . . . . . . . . . . . . . . . . . . . 20
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
       Intellectual Property and Copyright Statements . . . . . . . . 23

Palet, et al.            Expires April 24, 2005                 [Page 2]

Internet-Draft     Evaluation of IPv6 Auto-Transition       October 2004

1.  Introduction

   This document evaluates a method called "auto-transition" to ensure
   that any device can obtain IPv6 connectivity at any time and whatever
   network is attached to, even if such network is connected to Internet
   only with IPv4 or already offers IPv6 but with poor performance.

   The main goal is to facilitate the IPv6 deployment in a seamless way
   for devices, users and applications.  Lots of devices and
   applications around us will benefit obtaining IPv6 connectivity
   everywhere: home automation, wearable devices, cars, PDAs, mobile
   phones, peer-to-peer applications, remote control applications, etc.
   IPv6 is suitable to solve the network requirements that those
   devices/applications will need: addressing space, end-to-end secure
   peer-to-peer communication, autoconfiguration features and so on.

   IPv6 provides autoconfiguration features, enabling devices to work
   according to the plug-and-play philosophy, that is with no manual
   intervention.  However they only can be applied once the device has
   obtained IPv6 connectivity.  On the other hand, while native IPv6
   connectivity is not available everywhere, there is not a good
   "auto-transition" algorithm to ensure this connectivity.

   While devices are located in a native IPv6 environment, no manual
   intervention is required, so non technical users can take advantage
   of IPv6.  However until all or most of the networks are IPv6 native,
   we need to ensure that the same devices and users can use a
   transition mechanism that ensures the best possible IPv6
   connectivity, without any or low technical knowledge.  Is not
   acceptable require to the users to make manual configurations in
   order to get the IPv6 connectivity, but is also possible that in the
   early IPv6 deployment stage, administrators of small and medium size
   networks (typically SOHO, SME), will not have the knowledge neither
   the service from their ISPs.

   The algorithm will deal with all the tasks required to configure
   automatically the best IPv6 connectivity at anytime, in any network
   scenario, which include native IPv6 connectivity detection and
   transition mechanism selection if required.  It can be implemented
   either in stand-alone devices (hosts, PDA, etc.) or middle boxes like
   CPE routers.

2.  Auto-Transition Overview

   When the device is attached to the network, either or both stateless
   [1] or stateful autoconfiguration [2] mechanism are automatically
   performed by default.  The auto-transition algorithm then must check
   if native IPv6 connectivity is available.  Otherwise, the algorithm

Palet, et al.            Expires April 24, 2005                 [Page 3]

Internet-Draft     Evaluation of IPv6 Auto-Transition       October 2004

   should try to obtain IPv6 connectivity by using the best transition
   mechanism according to the network where the devices is attached.

   Later, the conditions of the network can change, even the user/device
   can change the location while moving.  Consequently the attachment
   point to the network can be different and the previous transition
   mechanism no longer be so well-performing or available at all.  The
   auto-transition algorithm has to monitor periodically the network
   parameters (i.e.  IPv4 address, loss, delays, etc.) in order to
   detect those changes and decide if another transition mechanism
   different to the one currently being used is convenient and provides
   better performance to activate it.

   All this process should be ideally automatic in order to avoid the
   user to make any manual configuration.  At the most, users only
   should introduce some parameters by means of a wizard during the
   installation process of the application that implements the
   auto-transition algorithm, but once it is up and running, all the
   tasks should be made by the system and no manual intervention

   This approach should be available at least in two kinds of platforms.

   o  End devices: Devices that do not intend to provide IPv6
      connectivity to others.  They are typically devices that would get
      IPv6 connectivity by means of Router Advertisement if they were
      attached to a native IPv6 scenario.  Examples are hosts, PDAs,
      mobile phones, cameras, home automation devices, white goods,
      consumer electronics, etc.

   o  CPE devices: Devices that are located between two different
      networks or networks segments.  Typically routers, IPv4 NAT boxes,
      etc.  They should provide native IPv6 connectivity to the whole
      network(s) located behind them by announcing an IPv6 prefix.  With
      this approach these kind of devices will be plug-and-play, so
      users only have to attach them to the network and they will deal
      with all the tasks to get IPv6 connectivity.  A few applications
      include home networks, hotels, hot-spots and so on.

3.  Auto-Transition Requirements

   The best IPv6 connectivity, in principle, is obviously the native one
   if available, since it should not add extra delays in the
   communication neither introduce more complexity to the networks.
   Consequently the auto-transition algorithm first must check if IPv6
   native connectivity is available.  However it strongly depends on the
   ISP support and can be expected that in the early IPv6 deployment

Palet, et al.            Expires April 24, 2005                 [Page 4]

Internet-Draft     Evaluation of IPv6 Auto-Transition       October 2004

   stage, only a few ISPs will provide it.

   If native connectivity is not available the auto-transition algorithm
   must choose the right transition mechanism to be used to ensure the
   IPv6 connectivity.

   A number of transition mechanisms have been defined already: Teredo,
   TB/TS, TSP, STEP, ISATAP, 6to4, tunnels, DSTM, etc.  All of them work
   when the host willing to get IPv6 connectivity has a public IPv4
   address.  Even some of them also work when the host is located behind
   a NAT box that allows proto-41 forwarding [3].  However there are
   other kinds of NAT boxes that prevent the existing transition
   mechanisms to work, so there is a gap that could be filled with new
   kind of solutions, possibly layer 2 or layer 4 tunnels.

   The adequate selection of the proper transition mechanism is one of
   the keys of the auto-transition concept.

   The auto-transition goal is to facilitate an adequate transition to
   IPv6.  Towards that, it tries to automatically decide the most
   optimal transition solution in every given scenario, which may be not
   the perfect one.  Actually implementing a perfect auto-transition
   solution could be a very complicated, overloading and slow algorithm
   (in addition to the delay in its specification and development); in
   the case it happens, could bring us the paradigm that there is no
   anymore an incentive for native IPv6 connectivity, which clearly is
   in contradiction with the goals of this memo and in general the
   (native) IPv6 deployment one.

3.1  Selection of the proper transition mechanism

   A few scenarios with particular network requirements had been defined
   already ([4], [5], [6], [7]).  Not all the transition scenarios fit
   in such network scenarios, as being evaluated at [8], which is trying
   to make the best fit to each scenario.

   The auto-transition algorithm may take into account not only the
   results shown in [8], but also new conclusions, because it is also
   possible a wider focus to select the best transition mechanism to be
   used.  What the end user always demands is the best performance on
   the IPv6 connectivity, so it should be the main criteria to choose
   the right transition mechanism.

   Distance, delays, loss and bandwidth, are some of the related
   parameters that could be used as metrics to be measured for knowing
   the link performance.  A device can present different values of such
   metrics according to the transition mechanism that is being used even
   when attached to the same network.

Palet, et al.            Expires April 24, 2005                 [Page 5]

Internet-Draft     Evaluation of IPv6 Auto-Transition       October 2004

   A combination of all the metrics could provide a fine evaluation of
   the connection performance.  However in order to make the mechanism
   as simple as possible only delay and loss should be considered.

   According to this philosophy the auto-transition algorithm could
   operate by means of the following simple algorithm, where the
   interactions are over the time:

        if (native_IPv6_available and native_priority)
                if (first_check or performance_check_allowed)
        wait (link_check_timeout)

   Figure 1: Simple Auto-transition algorithm

   It is important to note what each task or parameter means:

   o  detect_scenario: This task deals with detecting the scenario where
      the device willing to have IPv6 connectivity is located.  It could
      check if native IPv6 is available, if a public IPv4 address is
      available, if a NAT is being used and (possibly) the type, if
      there is a proxy or firewall, or if other protocols can be

   o  native_IPv6_available: Detects if native IPv6 is available.

   o  native_priority: Detects if native IPv6 has priority, for
      instance, even in the case the performance is lower than the one
      that could be obtained with alternative transition mechanism that
      may be used (i.e.  a native IPv6 network with is attached to a
      non-native WAN link with IPv6 tunneled over IPv4 to and end-point
      which offers a bad performance while there is a much better
      TB/TS).  This condition could be set by the OS, or even under user
      or applications control.

   o  use_native_IPv6_connectivity: Configure the interface to use
      native IPv6 connectivity, using stateless or stateful
      autoconfiguration, upon their availability.

Palet, et al.            Expires April 24, 2005                 [Page 6]

Internet-Draft     Evaluation of IPv6 Auto-Transition       October 2004

   o  first_check: Defines if this is the first time this check is being
      done after an interface reset.

   o  performance_check_allowed: Defines if the performance of the
      selected mechanism can be measured after selected, for instance,
      to avoid traffic being generated in non-flat rate links (3GPP,
      ISDN, ...).

   o  check_performance: According to the detected scenario, a number of
      mechanisms could be used.  This task checks the performance that
      each of such transition mechanism provides, including native IPv6
      if available, by measuring delays and losses.  The mechanisms
      subset will be defined by taking into account [8], but others
      could be considered.

   o  use_best_mechanism: According to the measurement results, the best
      mechanism is selected.

   o  configure_connectivity: Either native IPv6 connectivity or the
      best available transition mechanism is configured.

   o  link_check_timeout: Once the IPv6 connectivity is obtained, the
      auto-transition algorithm periodically monitors the link status.
      The delay between consecutive checks is defined by this variable.

   A possible list of mechanisms to be checked, ordered by preference
   could be:

   1.  Native IPv6 Connectivity

   2.  TS with proto-41 ([3])

   3.  TS with UDP

   4.  ISATAP

   5.  STEP

   6.  6to4

   7.  Teredo

3.2  Change of transition mechanism

   Change of transition mechanism refers to the task to abandon the
   transition mechanism that is actually being used and start to use
   another one that presents better performance.  This is not an easy

Palet, et al.            Expires April 24, 2005                 [Page 7]

Internet-Draft     Evaluation of IPv6 Auto-Transition       October 2004

   task at all, since it involves at least two important issues:

   1.  To maintain the current IPv6 address.  This is very important in
       some situations, since otherwise applications with communications
       opened will not work.  Specially important is the case when the
       auto-transition algorithm is implemented in border devices that
       provide native IPv6 connectivity to the whole network.  Either
       the prefix network (i.e.  RA), or the IPv6 addresses (i.e.
       DHCPv6) that they provide, should try to keep the IPv6 addressing
       parameters.  If the auto-transition algorithm has to include the
       possibility of changing the transition mechanism used without
       discarding the current connection state, it is necessary to
       define a method that solves this issue.  MIPv6 concepts/solutions
       could be applied and possibly also those related to multihoming.

   2.  User authentication without human intervention.  The philosophy
       of the auto-transition algorithm is that all the processes are
       done automatically, with no human intervention.  So, for
       instance, if the device running the auto-transition algorithm
       needs to contact with a TB different to one being already used,
       and it requires user authentication, the process should be
       transparent to the user.  It could be based on parameters (login
       and password) configured through the wizard during the
       installation process.  AAA mechanisms should be used.

   In order to simplify the solution (i.e.  not relying on MIPv6,
   multihoming or others), it could be decided to keep using the
   initially selected transition mechanism, even when not providing the
   optimal connectivity, but instead ensuring that the IPv6 address is

   In some situations it will be possible, even interesting, to keep
   active multiple transition mechanisms, for optimization or other
   purposes, even using some of them only in one direction, etc.  TBD.

3.3  New transition/tunneling mechanisms

   A number of devices do not allow tunnel-based transition mechanisms
   to work properly.  They are either NAT boxes, proxies or firewalls.
   Even building IPv6 tunnels over UDP is not always possible since some
   middle boxes do not forward those packets.

   When this happens it is required that the auto-transition algorithm
   uses a method that cannot be rejected by the middle box.  However, is
   important to realize that this may happen actually as a consequence
   of a policy or security measure from the network, specially in
   situations like enterprise networks.

Palet, et al.            Expires April 24, 2005                 [Page 8]

Internet-Draft     Evaluation of IPv6 Auto-Transition       October 2004

   The following sub-sections consider several alternatives.

3.3.1  Layer 2 tunnels

   By using layer 2 encapsulating methods (L2TP [9], PPTP [10], PPPoE
   [11]), the middle boxes barriers can be easily overcome since this
   kind of protocols are very used when building layer 2 VPN.
   Consequently, one of the following protocol stacks might be used.

     +--------+  +--------+
     |  IPv6  |  |  IPv6  |
     +--------+  +--------+
     |  PPP   |  |  PPP   |
     +--------+  +--------+  +--------+
     |  L2TP  |  |  PPTP  |  |  IPv6  |
     +--------+  +--------+  +--------+
     |  UDP   |  |  TCP   |  |  PPP   |
     +--------+  +--------+  +--------+
     |  IPv4  |  |  IPv4  |  |  IPv4  |
     +--------+  +--------+  +--------+

     L2TP tunnel PPTP tunnel PPPoE tunnel

   Figure 2: Layer 2 tunnels

   This kind of solution does not seem to be efficient due to the
   following drawbacks:

   o  It requires that the TS is configured as VPN L2 server.

   o  Overloaded stack.  IPv6 connection will have low performance.

   o  Complicated deployment and management due to the control plane for
      L2TP and PPTP.

   o  Authentication is a must with PPP.  It means added complexity.

3.3.2  Layer 3 tunnels

   VPN's built by mean of layer 3 tunnels can be a solution to allow
   IPv6 connections cross NAT boxes with no proto-41 forwarding
   capabilities as well as proxies and firewalls.

Palet, et al.            Expires April 24, 2005                 [Page 9]

Internet-Draft     Evaluation of IPv6 Auto-Transition       October 2004

     +--------+  +--------+
     |  IPv6  |  |  IPv6  |
     +--------+  +--------+  +--------+
     |  IPv4  |  |  IPv4  |  |  IPv6  |
     +--------+  +--------+  +--------+
     |  PPP   |  |  IPsec |  |  IPv4  |
     +--------+  +--------+  +--------+
     |  IPv4  |  |  IPv4  |  |  IPv4  |
     +--------+  +--------+  +--------+

     PPP-IPv4    IPsec       IPv4-IPv4

   Figure 3: Layer 3 tunnels

   Compared to the Layer 2 tunnels, the layer 3 tunnels have the
   following advantages:

   o  Less overloaded stacks.

   o  Tunnel management simpler.

   o  There are some implementations (VTun, cIPE, TINC).

   However it also have important drawbacks:

   o  It requires that the TS is configured as VPN L2 server.

   o  Some NAT's could not support those.

3.3.3  Layer 4 tunnels

   The last resort is to try to overcome the middle barriers by means of
   the use of frequently used application protocols.  There are two well
   known possibilities that frequently will not create difficulties with
   neither proxies nor firewalls: TLS/SSL, HTTP and SSH.  Furthermore,
   they neither have problems with NAT boxes.  The protocol stack for
   this solution is as follows:

Palet, et al.            Expires April 24, 2005                [Page 10]

Internet-Draft     Evaluation of IPv6 Auto-Transition       October 2004

      +--------+  +--------+  +--------+
      |  IPv6  |  |  IPv6  |  |  IPv6  |
      +--------+  +--------+  +--------+
      |  HTTPS |  |  HTTP  |  |  SSH   |
      +--------+  +--------+  +--------+
      |  TCP   |  |  TCP   |  |  TCP   |
      +--------+  +--------+  +--------+
      |  IPv4  |  |  IPv4  |  |  IPv4  |
      +--------+  +--------+  +--------+

   TLS/SSL tunnel HTTP tunnel SSH tunnel

   Figure 4: Layer 4 tunnels

   The main advantage of this approach is the simplicity for the
   configuration of the tunnel.  Furthermore the tunnels can be secured
   by means of either SSL (using HTTPS instead of HTTP) or SSH.

   Of course, this solutions are sub-optimal and consequently

   According to the different alternatives, it sounds reasonable that
   the better solution could be Layer 4-based tunnels, since it is
   simpler than the others and always will work, but the performance
   will not be optimal.  Instead Layer 3 and Layer 2-based tunnels
   should be taken into account in implementations of the
   auto-transition algorithm in order to guarantee the IPv6 connectivity
   by covering all the possible alternatives.

   The usage of those new mechanisms is discouraged, unless there is no
   other choice.  In any case, the standardization of those different
   tunnel options is out of the scope of this document.

3.4  Discovery of the IPv6 End Point

   Devices running the auto-transition algorithm need to know where to
   find the IPv6 (tunnel) end point or tunnel server (TS) that provides
   them the IPv6 connectivity.  If native IPv6 connectivity is provided
   by the ISP and is being used used, then this TS will be obviously the
   link end point and no further discovery work is required.  This is
   slightly more complex when a transition mechanism is required to
   obtain the IPv6 connectivity.

   Having in mind that users want plug-and-play devices/services and
   that most of them do not have any knowledge about how the transition
   mechanism works or where the nearest Tunnel Broker/Tunnel Sever, 6to4
   relay, etc., are located, it is required considering the
   auto-discovery of the IPv6 TS, so the device can find it

Palet, et al.            Expires April 24, 2005                [Page 11]

Internet-Draft     Evaluation of IPv6 Auto-Transition       October 2004


   Different transition mechanisms have different ways to encapsulate
   IPv6 packets, so servers implementing different transition mechanisms
   can be considered like different types of IPv6 end points (which of
   course, can perfectly sit in a single server).  For example, the
   Tunnel Broker/Tunnel Server uses mainly 6in4 tunnels; TSP can used
   either 6in4 or IPv6 over UDP tunnels; Teredo uses IPv6 over UDP
   tunnel, etc.  Furthermore, each transition mechanism has its own
   tunnel setup handshake, so it is not only important to know where the
   nearest IPv6 TS is located but also what type of transition
   mechanism/s is able to manage.

   On the other hand, there are situations where people are crowded,
   i.e.  either conferences, airports, urban areas with high population
   density, etc.  In this scenario is very likely that most of the users
   choose a particular IPv6 TS, usually because it is nearer or more
   well known.  It is possible that while there exist a few IPv6 TS
   attending many connections, there can exist a lot of them that are
   not being used.  In this way, most of the users have poor performance
   in their connections while users using TS without congestion will
   have good performance.  It would be desirable that there were some
   kind of load balancing in order to uniformly distribute the IPv6
   tunnel requests among all available IPv6 TS.

   The different approaches to cope with this issue are analysed in

4.  Nomadicity Considerations

   When users move across networks, several situations are possible.
   From the network point of view, users can or cannot maintain the IPv6
   address assigned from their home TS.  From the transition mechanism
   point of view, the new one can or cannot require an authentication
   process.  So clearly some considerations are required regarding the
   auto-transition algorithm behavior while user is moving.

   1.  Nodes that do not need to maintain the IPv6 address assigned from
       their home TS.  They are typically nomadic users who get
       connectivity to "passive" Internet users (browsing, emailing,
       etc.), but do not need to be "identified" from Internet
       (nevertheless this situation is changing with next generation p2p
       applications, VoIP, etc.).  Looking for the best IPv6
       connectivity can lead the auto-transition algorithm to define as
       the best TS one of the following:

       *  TSs that do not require authentication process.  They are TSs
          that provide IPv6 connectivity and they do not make any

Palet, et al.            Expires April 24, 2005                [Page 12]

Internet-Draft     Evaluation of IPv6 Auto-Transition       October 2004

          authentication process (TEREDO, 6to4, etc.).  The
          auto-transition approach does not offer any advantage in this
          case, so the auto-transition algorithm will just contact to
          the TS and the IPv6 connectivity will be obtained.

       *  TSs that require authentication process.  They are TSs that
          only provide IPv6 connectivity to authenticated users (users
          that previously were somehow registered in the entity
          providing the IPv6 TS service or some related entity).
          Automatic AAA mechanism must be defined, in order to ensure
          the no-human intervention requirement.  The TS can or cannot
          belong to the entity which the user was registered.  If so,
          authentication process is simpler.  However, a global
          authentication only will be possible if there are roaming
          agreements between the entity that is selected to obtain IPv6
          connectivity and the "home" entity which the user is
          registered.  These roaming agreements could be used for
          billing purposes among others.  If there are not such
          agreements, automatic connectivity is not possible and the
          auto-transition algorithm has two options:

          +  To choose an alternative transition mechanism, even
             although it does not offer the best performance.

          +  To inform to the user that the best IPv6 connection is only
             possible if a new manual registration/authentication
             process is done.

       *  The behavior should be defined during the wizard installation
          process of the auto-transition implementation.

   2.  Nodes that need to maintain the IPv6 address assigned from their
       home TS.  Users belonging to this group are typically users with
       either server or peer-to-peer applications, devices that need to
       be tracked (cars, suitcases, etc.), etc.  MIPv6 should be applied
       to this kind of nodes, but the following considerations must to
       taken into account by the auto-transition algorithm:

       *  Mobility capability should be an option that should be
          configured by means of the installation wizard.  If chosen,
          the first time that the auto-transition algorithm is run, it
          must check if a Home Agent (HA) exists either in the current
          IPv6 network or in the TS.  In fact, this option should
          condition the order of searching for the best transition
          mechanism to get IPv6 connectivity.  In this way, only
          mechanisms compatible with the presence of HA should be taken
          into account (mechanisms providing static IPv6 network prefix
          like TB, TSP, ISATAP, etc.).  The auto-transition algorithm

Palet, et al.            Expires April 24, 2005                [Page 13]

Internet-Draft     Evaluation of IPv6 Auto-Transition       October 2004

          should record the mechanism used to get IPv6 connectivity.
          Some transition mechanisms like ISATAP, allow the HA
          deployment into the home network which the nomadic device is
          initially attached.  Others, like TB, could be deployed in
          different networks from the one where the device is physically
          attached, but the HA could be implemented into the TS that
          provides the IPv6 connectivity.  On the other hand, the
          auto-transition algorithm should discard transition mechanisms
          that build the IPv6 network prefix from the IPv4 address
          (6to4, TEREDO, etc.).  This is required because it is no
          possible the deployment of the HA into the same IPv6 network,
          so no mobility features would be possible.  If no HA is
          discovered the first time that the auto-transition algorithm
          is run, then no MIPv6 support is possible, so the user should
          be informed and the usual auto-transition algorithm must be
          applied to get IPv6 connectivity.

       *  Once the node is away from home network, it needs to get IPv6
          connectivity.  The auto-transition algorithm should first
          check if it possible to maintain the same IPv6 home address,
          according to the mechanism used, before moving for getting the
          home address.  There are some kinds of transition mechanisms
          that allow this operation like a TB with several TS
          associated.  In this scenario, the node first gets the IPv6
          home address from a TS.  After the node move to other
          location, it could get IPv6 connectivity from a different TS
          that is associated to the same TB.  It is possible that either
          the new TS has the same /64 network prefix that the old TS or
          it can be configured by the TB to forward/send tunneled
          packets coming/going from/to the nomadic node.  In this way
          the nomadic device could maintain the IPv6 home address.  Even
          if the new TS does not belong to the same TB but there are
          roaming agreements between the involved entities, the
          maintenance of the IPv6 address/prefix could be possible.  How
          to do this configuration is out of scope of this document.

       *  If the IPv6 home address can not be maintained, then once the
          nomadic device has a new IPv6 address by means of any
          transition mechanism, it must contact to the HA to communicate
          the care of address following MIPv6.

   Other considerations pointed out in [12] should be taken into

5.  Network Managed Transition

   The algorithm described in this memo attempts to automatically and
   autonomously provide the best possible IPv6 connectivity and follows

Palet, et al.            Expires April 24, 2005                [Page 14]

Internet-Draft     Evaluation of IPv6 Auto-Transition       October 2004

   an approach based on the role of the user device Operating System.
   However the algorithm and in general the transition, could be
   improved and/or even more easily managed from the service provider
   (SP) point of view, if the network provided services that could help
   the auto-transition algorithm.  Following this approach, we propose a
   transitioning management architecture that in addition to providing
   network management functionality to the providers' network can also
   better support auto-transitioning hosts.

   There are two basic alternatives for the network managed transition:
   The use of Policy Based Networks (PBN) [13] or using a "transitioning

   [This section needs more text in order to explain how the
   communication between PDP and PEPs will be done, interaction among
   policies, how the different parameters like link, user identity and
   so on can influence the transition mechanism chosen.  Also other
   options rather than just PBN, such as SNMP, can be further
   described.] TBD.

5.1  Policy Based Networks

   Policies stored on the network repository might include information
   about the type of transition mechanisms implemented into the network
   to which the user device is attached to, so the auto-transition
   algorithm implemented into the user device would have more
   information to choose a better one or directly those possible in that
   network, or those suggested by the SP, or those enabled by the SP

   In a more advanced behavior the auto-transition algorithm implemented
   into the user device would inform to the Policy Decision Point (PDP),
   about features such as type of connection, date/time, user privileges
   and/or whatever other relevant information.  Then, the PDP might
   interact with other policies stored on the repository such as QoS
   Policies, Security Policies and so on, in order to propose the more
   adequate transition mechanism to be used by the device willing to get
   IPv6 connectivity.

   In accordance with [13], based on this approach the user device will
   act as a Policy Enforcement Point (PEP) as well as implementing the
   auto-transition algorithm.

5.2  Transitioning Server

   Essentially, the architecture will provide a 'transitioning server'
   which the host should automatically detect and register with to be
   provided with the optimum IPv6 transitioning solution for its current

Palet, et al.            Expires April 24, 2005                [Page 15]

Internet-Draft     Evaluation of IPv6 Auto-Transition       October 2004

   location within the network.  This has a number of advantages both
   from the administrators and auto-transitioning hosts point-of-view,
   the primary one being that this will act as a single point of contact
   for all auto-transitioning hosts within the network regardless of
   their location and circumstances and so by default gives a degree of
   control over this service to the administrator.  A summary of the
   advantages this provides are:

   o  Host

      *  Simplifies mechanism detection and configuration by explicitly
         providing the host with mechanism location and configuration

      *  Capable of supporting host roaming within the network (improves
         hand-off procedure).

      *  Will act as a centralised authentication point for the
         auto-transitioning host.

   o  Administrator

      *  Introduces administrative control to the auto-transitioning

      *  Allows administrator to determine mechanism availability to

      *  Provides admin with fine-grained control over host access

      *  Can easily be extended to support performance provisioning to
         user groups dependant upon privileges or service agreements.

   This component also introduces a significant security consideration
   to the process as adequate security precautions must be made to
   protect the server from abuse.  The server must be adequately
   protected from both DoS-type attacks and exploitation/hacking.

   The following sub-sections describe the auto-transition algorithm
   modifications required for the host and server operation, in case the
   network managed transition is being used.

5.3  Host operation

   The host auto-transitioning algorithm will need minor modification in
   order to make use of the transitioning management architecture.  This
   should reflect the fact that it represents an optimum solution when

Palet, et al.            Expires April 24, 2005                [Page 16]

Internet-Draft     Evaluation of IPv6 Auto-Transition       October 2004

   compared to the host attempting to detect the transitioning
   infrastructure individually but is less desirable than native IPv6
   connectivity.  Whether the network provides this type of transition
   facilities or not, the auto-transition algorithm, when present, must
   always attempt to provide the 'best' possible IPv6 connectivity.  The
   term 'best' is perhaps misleading as it actually represents the
   optimum solution based on a number of criteria ranging from host or
   auto-transitioning priorities, provider policies etc.  We can
   envisage the following alternatives:

   o  Both auto-transition algorithm and network managed transition are
      present.  The user device should be provided with the optimal
      transition mechanism in this scenario.

   o  Only auto-transition algorithm present.  Depending on the network,
      the transition might not be "optimal", but the auto-transition
      algorithm in the user device must be capable of providing some
      level of "good enough" IPv6 connectivity.

   o  Only network managed transition present.  The user device doesn't
      support the auto-transition algorithm, but a set of managed
      transition mechanisms in the network will be capable of offering
      possibly a good alternative for IPv6 connectivity, again not
      necessarily the optimal one.

   o  Neither mechanism is present.  This is the case where a user
      device has not been upgraded, but does include some transition
      mechanisms.  The provider is also not offering managed transition
      and so if the operating system is not capable of offering an
      automatic transition mechanism selection, the user device may
      require manual user intervention or even not offer IPv6
      connectivity at all.

   The key aspect of this process will be in making the host capable of
   detecting the presence of the PDP or transitioning server in the
   network.  In many ways, this is similar to the tunneling mechanism
   auto-detection procedure described in [12] and so a similar approach
   could be adopted here.  Essentially it identifies a number of
   approaches that could be used to automatically detect services
   including DHCP, DNS names or shared unicast addresses and describes
   the potential advantages and disadvantages of using each solution.
   It concludes that due to the weaknesses of the other solutions, DNS
   is the best solution here and recommends it for use in this case.
   Due to the similarities of that problem and the one described here,
   this solution could also be adopted for transitioning server
   auto-detection, this would also serve to simplify the
   auto-transitioning host algorithm if similar approaches are used.
   This aspect is not described in more detail here but see the solution

Palet, et al.            Expires April 24, 2005                [Page 17]

Internet-Draft     Evaluation of IPv6 Auto-Transition       October 2004

   document [14] for a more detailed explanation.

   The modifications to the auto-transition algorithm to incorporate the
   network managed transition architecture will be inserted in between
   the native IPv6 availability and host auto-detection sections.  This
   is shown in the following algorithm:

        if (native_IPv6_available and native_priority)
                if (network_managed_transition available)
                        if (first_check or performance_check_allowed)
        wait (link_check_timeout)

   Figure 2: Auto-Transition using Network Managed Transition

   As you can see, the host will now check for native connectivity first
   before attempting to find a network manager transition service and
   only falling back on host detection if that too fails.

5.4  Server operation

   One of the more interesting aspects of the introduction of the
   network managed transition service will be the registration procedure
   that hosts follow in order to make use of the service.  This will
   allow the service provider to keep track of the auto-transitioning
   hosts within its network and to assign certain privileges or
   priorities to the transitioning hosts, depending on administrative
   policies.  For example, hosts native to the network may receive a
   better level of service (either through access to a better-performing
   mechanisms or prioritised load-balancing) than 'foreign' hosts.

   The introduction of the network managed transition service
   essentially removes the transitioning mechanism selection procedure
   from the hosts and unifies it within the server.  This makes the
   server responsible for determining which mechanisms to supply to the

Palet, et al.            Expires April 24, 2005                [Page 18]

Internet-Draft     Evaluation of IPv6 Auto-Transition       October 2004

   hosts as they register and this could be done according to the
   following algorithm:

        receive request from auto-transitioning host + authenticate
        determine available mechanism(s)
        if (more than one available)
                rank mechanisms according to scoring algorithm
                select 'best' mechanism
        reply to host
        supply necessary configuration information to host

   Figure 3: Determination of Auto-Transition using Network Managed

   The interesting part of this procedure is the algorithm that is
   applied to determine the most appropriate mechanism for the host in
   the event that more than one solution is available.  It is obviously
   important that the administrator has control over this algorithm to
   the extent that they will be able to determine who has access to
   which services within their network.  At a simple level, this could
   be a 'default' list of mechanisms as described earlier in this draft
   but has the potential to be expanded to take into account, for
   example, the performance required by the host, host privileges and/or
   administrative preferences.

   Considering that most of the ISP will not necessarily deploy
   transition mechanisms in the early stage, advanced IPv6 Internet
   Exchanges could provide this kind of services [15] and in general
   policy-based capabilities.  The IX is not just a central peering
   point which facilitates any new service deployment, but also a place
   where lots useful information (routes, QoS, link conditions, etc.)
   about several domains is available.  With this philosophy, the
   transition policies will be one more facility provided by this type
   of IXs.

6.  Conclusions


7.  Security Considerations

   The auto-transition algorithm should secure at least the following

Palet, et al.            Expires April 24, 2005                [Page 19]

Internet-Draft     Evaluation of IPv6 Auto-Transition       October 2004

   1.  Communication with TS for administrative purposes.

   2.  Communication with TS for authentication purposes.

   3.  Tunnel building is according to the chosen TS.

   4.  General tunnel security consideration pointed at [16].

8.  Acknowledgements

   This memo was written as a consequence of real experience using IPv6
   when traveling, number of talks during IETF meetings and specially
   the work with the unmanaged, ISP and enterprise v6ops design teams.
   The authors would also like to acknowledge inputs from Brian
   Carpenter, Alvaro Vives, Cesar Olvera, Jim Bound, Stig Venaas and the
   European Commission support in the co-funding of the Euro6IX project,
   where this work is being developed.

9.  References

9.1  Normative References

9.2  Informative References

   [1]   Thomson, S. and T. Narten, "IPv6 Stateless Address
         Autoconfiguration", RFC 2462, December 1998.

   [2]   Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
         Carney, "Dynamic Host Configuration Protocol for IPv6
         (DHCPv6)", RFC 3315, July 2003.

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

   [4]   Huitema, C., "Evaluation of Transition Mechanisms for Unmanaged
         Networks", draft-ietf-v6ops-unmaneval-03 (work in progress),
         June 2004.

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

   [6]   Wiljakka, J., "Analysis on IPv6 Transition in 3GPP Networks",
         draft-ietf-v6ops-3gpp-analysis-10 (work in progress), May 2004.

Palet, et al.            Expires April 24, 2005                [Page 20]

Internet-Draft     Evaluation of IPv6 Auto-Transition       October 2004

   [7]   Bound, J., "IPv6 Enterprise Network Scenarios",
         draft-ietf-v6ops-ent-scenarios-05 (work in progress), July

   [8]   Savola, P. and J. Soininen, "Evaluation of v6ops Tunneling
         Scenarios and Mechanisms", draft-savola-v6ops-tunneling-01
         (work in progress), April 2004.

   [9]   Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and
         B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661,
         August 1999.

   [10]  Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and
         G. Zorn, "Point-to-Point Tunneling Protocol", RFC 2637, July

   [11]  Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. and
         R. Wheeler, "A Method for Transmitting PPP Over Ethernet
         (PPPoE)", RFC 2516, February 1999.

   [12]  Palet, J. and M. Diaz, "Evaluation of v6ops Auto-discovery for
         Tunneling Mechanisms", draft-palet-v6ops-tun-auto-disc-01 (work
         in progress), June 2004.

   [13]  Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for
         Policy-based Admission Control", RFC 2753, January 2000.

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

   [15]  Morelli, M., "Advanced IPv6 Internet Exchange model",
         draft-morelli-v6ops-ipv6-ix-00 (work in progress), July 2004.

   [16]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for
         IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-06 (work in
         progress), September 2004.

Palet, et al.            Expires April 24, 2005                [Page 21]

Internet-Draft     Evaluation of IPv6 Auto-Transition       October 2004

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

   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

   Michael Mackay
   Lancaster University
   United Kingdom


Palet, et al.            Expires April 24, 2005                [Page 22]

Internet-Draft     Evaluation of IPv6 Auto-Transition       October 2004

Intellectual Property Statement

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

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

   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 (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


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

Palet, et al.            Expires April 24, 2005                [Page 23]