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

Versions: 00 01 02

Internet Engineering Task Force                                 J. Palet
Internet-Draft                                                   M. Diaz
Expires: October 20, 2004                                    Consulintel
                                                          April 21, 2004


              Evaluation of IPv6 Auto-Transition Mechanism
                  draft-palet-v6ops-auto-trans-00.txt

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on October 20, 2004.

Copyright Notice

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

Abstract

   This draft evaluates a method called "auto-transition" to ensure that
   any device can obtain IPv6 connectivity at any time and whatever
   network is attached to.

   The method looks for the best transition mechanism according to
   performance criteria as well as the scenario where the device is
   located.

   By implementing such auto-transition method in either or both end
   nodes or middle boxes (CPEs), users can always obtain IPv6



Palet & Diaz            Expires October 20, 2004                [Page 1]


Internet-Draft     Evaluation of IPv6 Auto-Transition         April 2004


   connectivity with no human intervention.

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 mechanisms  . . . . . . . . . . . . . . . .  8
       3.3.1   Layer 2 tunnels  . . . . . . . . . . . . . . . . . . .  8
       3.3.2   Layer 3 tunnels  . . . . . . . . . . . . . . . . . . .  9
       3.3.3   Layer 4 tunnels  . . . . . . . . . . . . . . . . . . . 10
     3.4   Discovery of the IPv6 End Point  . . . . . . . . . . . . . 10
   4.  Nomadicity Considerations  . . . . . . . . . . . . . . . . . . 11
   5.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 14
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   8.1   Normative References . . . . . . . . . . . . . . . . . . . . 14
   8.2   Informative References . . . . . . . . . . . . . . . . . . . 14
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
       Intellectual Property and Copyright Statements . . . . . . . . 17




























Palet & Diaz            Expires October 20, 2004                [Page 2]


Internet-Draft     Evaluation of IPv6 Auto-Transition         April 2004


1.  Introduction

   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" 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 technical knowledge. Is not acceptable
   require to the users to make manual configurations in order to get
   the IPv6 connectivity.

   The mechanism 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, the mechanism first must
   check if native IPv6 connectivity is possible. If so, either or both
   stateless [1] or stateful autoconfiguration [2] mechanism are
   performed. Otherwise, the auto-transition mechanism 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 convenient. The auto-transition mechanism
   has to monitor periodically the network parameters (i.e. IPv4



Palet & Diaz            Expires October 20, 2004                [Page 3]


Internet-Draft     Evaluation of IPv6 Auto-Transition         April 2004


   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 mechanism, but once it is up and running, all the
   tasks should be made by the system and no manual intervention
   required.

   This approach should be available at least in two kind 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 this 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 mechanism first must check if IPv6
   native connectivity is available. However it strongly depends on the
   ISP support and can be expected that in the first IPv6 deployment
   stage, only a few ISPs will provide it.

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

   A number of transition mechanism have been defined already: Teredo,
   TB/TS, TSP, STEP, ISATAP, 6to4, tunnels, etc. All of them work when



Palet & Diaz            Expires October 20, 2004                [Page 4]


Internet-Draft     Evaluation of IPv6 Auto-Transition         April 2004


   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 kind of
   NAT boxes that prevent the current 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.

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], trying to make the
   best fit to each scenario.

   The auto-transition mechanism may take into account the results shown
   in [8], although 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, bandwidth, etc., 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.

   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 mechanism could
   operate by means of the following simple algorithm:
















Palet & Diaz            Expires October 20, 2004                [Page 5]


Internet-Draft     Evaluation of IPv6 Auto-Transition         April 2004


   loop
        detect_scenario
        if (native_IPv6_available and native_priority)
                use_native_IPv6_connectivity
        else
                if (first_check or performance_check_allowed)
                        check_performance
                        use_best_mechanism
                endif
        endif
        configure_connectivity
        wait (link_check_timeout)
   endloop

   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 what type, if there is a
      proxy or firewall, or if other protocols can be operated.

   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
      alternative transition mechanism that may be used. 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.

   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 mechanism subset



Palet & Diaz            Expires October 20, 2004                [Page 6]


Internet-Draft     Evaluation of IPv6 Auto-Transition         April 2004


      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 mechanism periodically monitors the link status.
      The delay between consecutive checks is defined by this variable.

   A possible list of mechanism 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
   task at all, since it involves at least two important issues:

   1.  To maintain the current IPv6 address. This is a must since
       otherwise applications with communications opened will not work.
       Specially important is the case which the auto-transition
       mechanism 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,
       must be able to keep the IPv6 addressing parameters. If the
       auto-transition mechanism 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



Palet & Diaz            Expires October 20, 2004                [Page 7]


Internet-Draft     Evaluation of IPv6 Auto-Transition         April 2004


       solves this issue. MIPv6 concepts could be applied.

   2.  User authentication without human intervention. The philosophy of
       the auto-transition mechanism is that all the processes are done
       automatically, with no human intervention. So, for instance, if
       the device running the auto-transition mechanism needs to contact
       with a TB different to the actual one, 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.


3.3  New transition mechanisms

   A number of devices do not allow tunnel-based transition mechanism to
   work properly. They are both 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 mechanism
   uses a method that cannot be rejected by the middle box. The
   following solutions could be considered:

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




Palet & Diaz            Expires October 20, 2004                [Page 8]


Internet-Draft     Evaluation of IPv6 Auto-Transition         April 2004


   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.


     +--------+  +--------+
     |  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.



Palet & Diaz            Expires October 20, 2004                [Page 9]


Internet-Draft     Evaluation of IPv6 Auto-Transition         April 2004


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: HTTP and SSH. Furthermore, they
   neither have problems with NAT boxes. The protocol stack for this
   solution is as follows:


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

     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.

   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
   mechanism in order to guarantee the IPv6 connectivity by covering all
   the possible alternatives.

   The usage of those new mechanism 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 mechanism 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 used, this TS will be obviously the link end point and
   no further work is required. This is slightly more complex when a
   transition mechanism is required to obtain the IPv6 connectivity.



Palet & Diaz            Expires October 20, 2004               [Page 10]


Internet-Draft     Evaluation of IPv6 Auto-Transition         April 2004


   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
   automatically.

   Different transition mechanisms have different IPv6 type of end
   points. 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
   [12].

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 mechanisms
   point of view, the new one can or cannot require an authentication
   process. So clearly some considerations are required regarding the
   auto-transition mechanism 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 mechanism to define as the best TS
       one of the following:




Palet & Diaz            Expires October 20, 2004               [Page 11]


Internet-Draft     Evaluation of IPv6 Auto-Transition         April 2004


       *  TSs that do not require authentication process. They are TSs
          that provide IPv6 connectivity and they do not make any
          authentication process (TEREDO, 6to4, etc.). This approach
          does not represent any innovation, so the auto-transition
          mechanism just contact to the TS and the IPv6 connectivity is
          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
          mechanism has to 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 mechanism:

       *  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 mechanism 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



Palet & Diaz            Expires October 20, 2004               [Page 12]


Internet-Draft     Evaluation of IPv6 Auto-Transition         April 2004


          (mechanisms providing static IPv6 network prefix like TB, TSP,
          ISATAP, etc.). The auto-transition mechanism 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 mechanism
          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 mechanism 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 mechanism 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 mechanism
          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
   account.






Palet & Diaz            Expires October 20, 2004               [Page 13]


Internet-Draft     Evaluation of IPv6 Auto-Transition         April 2004


5.  Conclusions

   TBD.

6.  Security Considerations

   The auto-transition mechanism should secure at least the following
   points:

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


7.  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 the European Commission
   support in the co-funding of the Euro6IX project, where this work is
   being developed.

8.  References

8.1  Normative References

8.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
         2003.

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




Palet & Diaz            Expires October 20, 2004               [Page 14]


Internet-Draft     Evaluation of IPv6 Auto-Transition         April 2004


   [5]   Lind, M., "Scenarios and Analysis for Introducing IPv6 into ISP
         Networks", draft-ietf-v6ops-isp-scenarios-analysis-01 (work in
         progress), February 2004.

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

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

   [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
         1999.

   [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-00 (work
         in progress), April 2004.

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


Authors' Addresses

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

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



Palet & Diaz            Expires October 20, 2004               [Page 15]


Internet-Draft     Evaluation of IPv6 Auto-Transition         April 2004


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

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










































Palet & Diaz            Expires October 20, 2004               [Page 16]


Internet-Draft     Evaluation of IPv6 Auto-Transition         April 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 IETF's procedures with respect to rights in IETF Documents can
   be found in BCP 78 and BCP 79.

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

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


Disclaimer of Validity

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


Copyright Statement

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


Acknowledgment

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




Palet & Diaz            Expires October 20, 2004               [Page 17]


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