One document matched: draft-palet-v6ops-auto-trans-01.txt
Differences from draft-palet-v6ops-auto-trans-00.txt
Internet Engineering Task Force J. Palet
Internet-Draft M. Diaz
Expires: January 17, 2005 Consulintel
July 19, 2004
Evaluation of IPv6 Auto-Transition Algorithm
draft-palet-v6ops-auto-trans-01.txt
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.
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 January 17, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
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.
The algorithm looks for the best possible transition mechanism
according to performance criteria information available as well as
Palet & Diaz Expires January 17, 2005 [Page 1]
Internet-Draft Evaluation of IPv6 Auto-Transition July 2004
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 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 . . . . . . . . . . . . . 11
4. Nomadicity Considerations . . . . . . . . . . . . . . . . . . 12
5. Network Managed Transition . . . . . . . . . . . . . . . . . . 14
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 17
9.2 Informative References . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . 19
Palet & Diaz Expires January 17, 2005 [Page 2]
Internet-Draft Evaluation of IPv6 Auto-Transition July 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 (tipically 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 & Diaz Expires January 17, 2005 [Page 3]
Internet-Draft Evaluation of IPv6 Auto-Transition July 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
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 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 & Diaz Expires January 17, 2005 [Page 4]
Internet-Draft Evaluation of IPv6 Auto-Transition July 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 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.
We should understand that the auto-transition goal is to facilitate
an adecuate 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. Actualy
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 this
memo goal and in general the 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], 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 & Diaz Expires January 17, 2005 [Page 5]
Internet-Draft Evaluation of IPv6 Auto-Transition July 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:
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 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.
o first_check: Defines if this is the first time this check is being
Palet & Diaz Expires January 17, 2005 [Page 6]
Internet-Draft Evaluation of IPv6 Auto-Transition July 2004
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. DSTM
8. 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
Palet & Diaz Expires January 17, 2005 [Page 7]
Internet-Draft Evaluation of IPv6 Auto-Transition July 2004
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 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 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.
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 transitio mechanism, even when not providing the
optimal connectivity, but instead ensuring that the IPv6 address is
stable.
3.3 New transition mechanisms
A number of devices do not allow tunnel-based transition mechanisms
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 algorithm
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.
Palet & Diaz Expires January 17, 2005 [Page 8]
Internet-Draft Evaluation of IPv6 Auto-Transition July 2004
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 & Diaz Expires January 17, 2005 [Page 9]
Internet-Draft Evaluation of IPv6 Auto-Transition July 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 & Diaz Expires January 17, 2005 [Page 10]
Internet-Draft Evaluation of IPv6 Auto-Transition July 2004
+--------+ +--------+ +--------+
| IPv6 | | IPv6 | | IPv6 |
+--------+ +--------+ +--------+
| HTTP | | 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
discouraged.
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 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.
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.
Palet & Diaz Expires January 17, 2005 [Page 11]
Internet-Draft Evaluation of IPv6 Auto-Transition July 2004
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 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
authentication process (TEREDO, 6to4, etc.). This approach
does not represent any innovation, so the auto-transition
algorithm just contact to the TS and the IPv6 connectivity is
obtained.
Palet & Diaz Expires January 17, 2005 [Page 12]
Internet-Draft Evaluation of IPv6 Auto-Transition July 2004
* 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 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 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
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
Palet & Diaz Expires January 17, 2005 [Page 13]
Internet-Draft Evaluation of IPv6 Auto-Transition July 2004
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
account.
5. Network Managed Transition
The algorithm described in this memo to get automatically the best
possible IPv6 connectivity follows 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 ISP point of view,
if the network presents services that could help the auto-transition
Palet & Diaz Expires January 17, 2005 [Page 14]
Internet-Draft Evaluation of IPv6 Auto-Transition July 2004
algorithm. Following this approach, Policy Based Networks (PBN) [14]
can offer a candidate solution (not an exclusive one) to offer
facilities to the auto-transition algorithm.
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 ISP, or those enabled by the ISP
policy.
In a more advanced behaviour 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 [14], based on this approach the user device will
act as a Policy Enforcement Point (PEP) as well as implementing the
auto-transition algorithm.
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.
Whether the network provides this type of transition facilities or
not, the auto-transition algorithm, when present, must always work
and it will provide the best possible IPv6 connectivity. We can
envisage the following alternatives:
o Only auto-transition algorithm present. Depending on the network,
the transition could not be "optimal", but the auto-transition
algorithm in the user device must be capable of provide IPv6
connectivity.
o Only network managed transition present. The user device doesn't
incorporate the auto-transition algorithm, but just a set of
transition mechanisms and the network will be capable of offering
Palet & Diaz Expires January 17, 2005 [Page 15]
Internet-Draft Evaluation of IPv6 Auto-Transition July 2004
possibly a good alternative for the IPv6 connectivity, not
necessarily the optimal one.
o Both, auto-transition algorithm and network managed transition are
present. The user device possibly will get working the more
optimal transition mechanism in such scenario.
o None of both is present. This is the case of a user device with
the operating system has not been upgraded, but already includes
some transition mechanisms. The network is also not offering
managed transition. Consequently if the operating system is not
capable of offering an automatic transition mechanism selection,
could require manual user intervention or even not be able to
offer IPv6 connectivity at all.
[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.
6. Conclusions
TBD.
7. Security Considerations
The auto-transition algorithm 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].
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, Michael Mackay and
the European Commission support in the co-funding of the Euro6IX
Palet & Diaz Expires January 17, 2005 [Page 16]
Internet-Draft Evaluation of IPv6 Auto-Transition July 2004
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
2003.
[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.
[7] Bound, J., "IPv6 Enterprise Network Scenarios",
draft-ietf-v6ops-ent-scenarios-04 (work in progress), July
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
Palet & Diaz Expires January 17, 2005 [Page 17]
Internet-Draft Evaluation of IPv6 Auto-Transition July 2004
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] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for
IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-03 (work in
progress), June 2004.
[14] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for
Policy-based Admission Control", RFC 2753, January 2000.
[15] Morelli, M., "Advanced IPv6 Internet Exchange model",
draft-morelli-v6ops-ipv6-ix-00 (work in progress), July 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
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 January 17, 2005 [Page 18]
Internet-Draft Evaluation of IPv6 Auto-Transition July 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Palet & Diaz Expires January 17, 2005 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-23 22:12:11 |