Internet Engineering Task Force J. Palet
Internet-Draft M. Diaz
Expires: October 14, 2004 Consulintel
April 15, 2004
Evaluation of v6ops Auto-discovery for Tunneling Mechanisms
draft-palet-v6ops-tun-auto-disc-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 14, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
Tunneling is commonly used in several transition mechanisms. Some of
the mechanisms discover the tunnel end-point automatically by their
own means
However one of those common mecanisms, the tunnel server, often
requires the pre-registration of the user (through a tunnel broker or
similar system), not being a perfect solution since the performance
depends on his location, as the tunnel end-point is fixed during the
registration process. In addition, they also require the
pre-knowledge of the existence of the Tunnel Broker service.
Palet & Diaz Expires October 14, 2004 [Page 1]
Internet-Draft Evaluation of IPv6 Tunnel Auto-discovery April 2004
Consequently, if the process is automated, they could be improved in
order to be more friendly and more easy to locate them, choosing for
the user the best performance depending on his attachment point to
the IPv4 network. Several alternatives are evaluated in this
document, including anycast, DNS and DHCP, including possible
solutions for overcoming existing barriers for their implementation
In addition, the same auto-discovery mechanism could be used not only
for tunnel servers, but also by other transition mechanisms (6to4,
ISATAP, TSP) that could share the same end-point, facilitating the
interoperability among them.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. TS Deficiencies in Specific Scenarios . . . . . . . . . . . . 3
2.1 Scenario 1: Initial IPv6 Deployment Stage . . . . . . . . 4
2.2 Scenario 2: Nomadic Users . . . . . . . . . . . . . . . . 4
2.3 Scenario 3: Advanced IPv6 Deployment Stage . . . . . . . . 5
3. Analysis of Solutions . . . . . . . . . . . . . . . . . . . . 5
3.1 Anycast-based Solutions . . . . . . . . . . . . . . . . . 6
3.2 Centralized Server-based Solutions . . . . . . . . . . . . 6
3.3 Distributed Server-based Solutions (DNS) . . . . . . . . . 7
3.4 DHCP-based Solutions . . . . . . . . . . . . . . . . . . . 7
3.5 PPP-based Solutions . . . . . . . . . . . . . . . . . . . 8
3.6 Combined Solutions . . . . . . . . . . . . . . . . . . . . 8
4. Challenges for the Usage of Anycast for TS Auto-discovery . . 8
4.1 Anycast in Best-Effort Networks . . . . . . . . . . . . . 8
4.1.1 Delivery of datagrams to more than one anycast host . 9
4.1.2 Delivery of datagrams belonging to the same
connection to different anycast hosts . . . . . . . . 10
4.2 Routing and Load Balancing with Anycast Addresses . . . . 12
4.3 Announcement of the Anycast Addresses . . . . . . . . . . 12
4.4 Management of TB/TS with Nomadic Users . . . . . . . . . . 13
4.5 Change of Network Conditions . . . . . . . . . . . . . . . 15
5. Anycast TB Architectures . . . . . . . . . . . . . . . . . . . 17
5.1 TB with a Single TS . . . . . . . . . . . . . . . . . . . 18
5.1.1 Anycast based on the network layer . . . . . . . . . . 18
5.1.2 Anycast based on the application layer . . . . . . . . 18
5.2 TB with Anycast TS Cluster . . . . . . . . . . . . . . . . 18
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 19
9.2 Informative References . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . 21
Palet & Diaz Expires October 14, 2004 [Page 2]
Internet-Draft Evaluation of IPv6 Tunnel Auto-discovery April 2004
1. Introduction
Some transition mechanism are more used by non-experienced users,
mainly because the auto-discovery feature, even when they offer worst
performance/features than the tunnel servers.
The Tunnel Broker (TB)/Tunnel Server (TS) pair concept [1] has been
defined to help both non expert users and networks administrators to
easily setup tunnels. Because of the TB capabilities, the usage of
them is very frequent and they have become one of the most used
transition mechanisms, but mainly among experienced users.
One important advantage TS compared to other transition mechanism is
that allow users with have a private IPv4 address behind of NAT
boxes, even although this mechanism has not specifically designed for
that. This is due to the support of protocol-41 forwarding in a high
number of NAT boxes [2].
However, the TS solution could be improved in order to make them more
friendly, easy to use and increasing the IPv6 connectivity
performance, by means of auto-discovery features. The usage of
anycast, DNS, DHCP or other architectures to implement auto-discovery
for TS are possible alternatives that need to be taken into account
to address those improvements.
It seems possible to integrate the TB and the TS in a single device
that could also be the end-point for other tunneling-based mechanism.
This seems possible especially when considering non-authenticated
usage of the service, but not in the case of authenticated services
where the users database requires a more complex management, and
probably is tied to other AAA infrastructure in the ISP or network.
This document evaluates the auto-discovery possibilities for a Tunnel
Server (TS), that could be used for any mechanism that require a
tunnel end-point (TS), and the obstacles and possible solutions to
implement them.
2. TS Deficiencies in Specific Scenarios
The concept of the TS can be considered as one of the most useful
transition mechanisms due to the easy of use when users try to setup
the IPv6 tunnel by using simply a web-based interface or in an
automatic way (non-authenticated or anonymous usage), independently
of the operating system that is being used. However, the TSs cannot
be considered as the ideal transition mechanism, specially when
compared with manual tunnels (which usually are manually tuned),
because they show some inefficiencies that should be analyzed in
order to achieve a more efficient as well as a more automatic and
Palet & Diaz Expires October 14, 2004 [Page 3]
Internet-Draft Evaluation of IPv6 Tunnel Auto-discovery April 2004
even transparent mechanism.
At least three scenarios can be described where we can see some
deficiencies when users try to get IPv6 connectivity or when TSs have
to manage the connections.
2.1 Scenario 1: Initial IPv6 Deployment Stage
During the initial IPv6 deployment stage, the ISPs will not provide
native IPv6 connectivity, at least not probably in the access. On the
other hand, other ISPs or entities will offer connectivity by means
of TSs, most probably for free. In this situation, end users do not
need to be bound to a particular TS in order to get IPv6
connectivity, and they can change the TS at anytime.
In this case, there could be situations where is very likely that too
many users choose the same TS, usually because it is very well known.
This can happen in airports, highly populated areas with only one TS,
etc. It is possible also that while there exists a few TS attending
too many connections, others are not being used at all. As a result,
most of the users have poor performance in their connections.
Given the fact that the users are not commercially bound to any TS,
it would be desirable that there is some kind of load balancing in
order to uniformly distribute the IPv6 tunnel requests among all
available TS, in terms of number of users, number of connections or
actual traffic. It would also be desirable that the load balancing
mechanism is as much transparent as possible for the users for
avoiding extra difficulties while they try to get IPv6 connectivity.
2.2 Scenario 2: Nomadic Users
Nomadic users requiring connectivity to Internet at anytime,
anywhere, is today a reality: meetings, conferences, holidays, etc.
That cause very frequent location changes. Under this circumstance
obtaining native IPv6 connectivity is not easy, so users often visit
the web pages of the TSs that they already know, even if they are far
from its current location. This implies enormous inefficiencies when
users move among different countries or continents.
This is the first challenge: the user is connected to a TS that is
likely thousands of kilometers separated, while possibly a nearer TS
exists. Long distances usually mean that datagrams have to cross a
lot of routers until they arrive to the tunnel end. This also could
mean extra delays if the traversed networks are congested.
It would be desirable a mechanism that automate the process of
obtaining IPv6 connectivity from the nearest TS. Even if the nearest
Palet & Diaz Expires October 14, 2004 [Page 4]
Internet-Draft Evaluation of IPv6 Tunnel Auto-discovery April 2004
one is overloaded, it would be possible to for the next one if the
balance between congestion of the first one, and distance to the
second one is appropriate. Other factors should be possibly
considered.
The second challenge for the user, is to choose the nearest and/or
less overloaded TS. A manual solution, like a list of TSs, sorted by
geographic areas, is possibly not the best, and will not allow to
choose the less overloaded.
2.3 Scenario 3: Advanced IPv6 Deployment Stage
When the IPv6 deployment is in a more advanced stage, namely more
users in more places looking for IPv6 connectivity, it is possible
that entities providing IPv6 connectivity need to start a broader
deployment. Is feasible that they increase the performance of their
TS service by using different TS distributed in different locations.
In case of authenticated usage all of them could be managed by the
same TB, or a kind of distributed TB/database. In this situation, the
management of the tunnels assigned to each user becomes more complex
because now the TB must decide what TS has to be assigned to each
user. Once more, taking into account both the load balancing,
distance criteria, and possibly others, this management is not easy.
In principle, when the user is located in an area where the TB has a
TS, this TS should be used because it is not only the nearest one,
but also belongs to the TB which the user is already registered, so
this simplifies the tunnel management. But as in the previous
scenarios, is still possible that doesn't offer the best performance.
In any case, the whole process for having a new IPv6 tunnel with a
new TS should be as much transparent as possible in order to avoid
that users need to manually re-register or change the configuration
in their host. It would be desirable that the TS architecture makes
the users get connected and re-connected to the nearest TS without
manual intervention (for example when moving). This is also a
challenge to be solved: providing seamless connectivity.
3. Analysis of Solutions
The weakness of TS model can be summarized as:
o Difficulty to locate a TS.
o Difficulty to determine the nearest TS.
o Difficulty to determine if the nearest TS is the one that provides
Palet & Diaz Expires October 14, 2004 [Page 5]
Internet-Draft Evaluation of IPv6 Tunnel Auto-discovery April 2004
the best performance.
o Difficulty to provide load balancing to have uniform distribution
of connections.
o Difficulty to provide transparency, specially when users are
moving.
o Difficulty to provide scalability, redundancy and reliability, in
case of a TS is broken.
o Difficulty to manage users connections when providing multiple TS.
Several possible solutions can be depicted.
3.1 Anycast-based Solutions
An anycast address identify a group of hosts, usually server hosts.
When a client sends a datagram to an anycast address, it is delivered
to one of the anycast servers. According to this definition, the
anycast concept seems nicely fit as solution to the TS weakness.
With this approach the user requiring the creation of a new tunnel
would connect to either a well known address or a well known domain
name, i.e. http://www.tunnel-server.net and the connection would be
automatically redirected to the more appropriate TS.
However, because of the features of the IP networks, when an IP
datagram is sent to an anycast address, this can be delivered to one
or more hosts belonging to the anycast group [3]. In addition, there
is no guarantee that two consecutive datagrams sent from the same
host towards the same anycast address are going to be delivered to
the same server.
3.2 Centralized Server-based Solutions
A single server could coordinate a TS cluster that would accept
tunnel requests from users (if the services requires authentication).
The centralized server would have real time knowledge of the status
of all the TS associated to it, in order to realized a load balancing
of the incoming requests.
Alternatively, a simplified model could consist in a centralized
server that just inform to the user which is the nearest TS depending
on the user location. This could be done even via a well known URI
This solution presents one important drawback: it is required that
all the entities that provide TSs should be associated, even in the
Palet & Diaz Expires October 14, 2004 [Page 6]
Internet-Draft Evaluation of IPv6 Tunnel Auto-discovery April 2004
simplified model (someone to manage/update the central database in
the well known web server), in order to allow a common management of
all the resources involved, which seems to be unlikely.
3.3 Distributed Server-based Solutions (DNS)
The DNS is a system globally deployed, that could provide a
non-centralized solution, avoiding users to run new or special
applications, in order to setup the tunnel [4].
With this approach, the user only has to connect to a well known
pre-defined name and the DNS would redirect the connection to the
nearest TS to be used. This mechanism could use the more appropriate
metrics related to the routing protocols (BGP, IGP, etc.) in order to
choose the best TS, not only in accordance to a proximity criteria
but also to aspects as delay, available bandwidth, among others. The
load balancing could be made by creating a list of candidate TS and
after each request is attended the system could modify the list order
either randomly, by applying like "Round-Robin" techniques or
"hashing" ones, according to the user IPv4 address, etc.
This approach is already used for other services like distributed web
servers.
Although this solution provides interesting features like good
scalability, efficiency, etc., also has some drawbacks. For instance,
any system based on DNS usually cache the request, so will never
offer real time information, which can be a serious inconvenience
when a TS gets down. If caching capability is disabled, then DNS
requests traffic will increase, which is not insignificant.
3.4 DHCP-based Solutions
In most of the situations, the users receives the IPv4 information by
means of an IPv4 DHCP server. Consequently, one of the parameters to
be provided by the DHCP server could be the TS address (tunnel
end-point) [5].
This approach has several inconvenient's:
o Requires upgrading the DHCP client/server implementation.
o Is restricted to the local ISP (i.e., will not be effective if the
local ISP don't provide this parameter). This could be also
considered as an advantage considering that the TS will be
probably installed in the local or ISP network.
o Will not work if DHCP client is not used.
Palet & Diaz Expires October 14, 2004 [Page 7]
Internet-Draft Evaluation of IPv6 Tunnel Auto-discovery April 2004
o Requires the configuration of local DHCP servers, if not relying
those provided by the ISP.
o Requires manual configuration/update of the ISP DHCP servers when
there is a new TS or the existing one is not working, but this is
similar to the issue of updating DNS, NTP or other servers.
3.5 PPP-based Solutions
In the case of PPP-like connections, specific PPP parameters could be
passed to the clients, as part of the AAA signaling process. This
solution has the same inconvenient's as indicated for the DHCP-based
solution ... TBD.
3.6 Combined Solutions
Seems feasible to combine several of the solutions analyzed, for
example DNS and anycast ? The NAPTR thing ... TBD.
4. Challenges for the Usage of Anycast for TS Auto-discovery
As previously described, the use of anycast addresses for the
implementation of TS has some difficulties, but also several
advantages:
o Facility to locate a TS.
o Facility to determine the nearest TS.
o Facility to determine if the nearest TS is the one that provides
the best performance.
o Facility to provide load balancing to have uniform distribution of
connections.
o Facility to provide transparency, specially when users are moving.
o Facility to provide scalability, redundancy and reliability, in
case of a TS is broken.
o Facility to manage users connections when providing multiple TS.
The challenges are addressed in the following sections.
4.1 Anycast in Best-Effort Networks
Given the characteristics of the IP networks, if they do not modify
Palet & Diaz Expires October 14, 2004 [Page 8]
Internet-Draft Evaluation of IPv6 Tunnel Auto-discovery April 2004
the delivery of a datagram to an anycast address, they can cause two
different situations in which we have to analyze the implications of
using anycast an anycast architecture for TS auto-discovery.
4.1.1 Delivery of datagrams to more than one anycast host
The consequences of those situations depend on the behavior of the
protocols that are above the network layer. These can be classified
in two categories: stateless and statefull. As example of first group
we can mention TCP, whereas as example of the second one we have UDP.
In case of using a protocol like TCP, when the connection between a
client node and a server node has already established, the fact that
a datagram arrives at two or more anycast nodes does not cause any
problem, since the TCP connection will only be opened in one of them
(the first one, while the rest will receive a TCP RST), and it will
be such node the one that takes care of the datagram, whereas the
rest will discard it.
In case of using a protocol like UDP, the datagram will be processed
by all the server nodes where it arrives since there is no
information of the state of the connection. This can cause a problem
if the processing of the datagram by the corresponding application
originate in the server some type of answer that can be based on
previous datagrams.
In the case of connections with a TB, although standards do not
exist, the most usual is to use TCP connections so that once the
connection is established with a server node of the anycast group, it
does not seem that it is problematic the fact that later datagrams
can arrive at other different serves, except by the fact of the
wasted bandwidth, since these datagrams will be discarded by the
servers which do not maintain the connection with the client node and
the communication between client and TB server is not affected. This
situation does not differs with respect to any other anycast TCP
service that might be already in service.
In the case in which the architecture of a TB is designed with a TS
anycast group, the client establishes an IPv6 tunnel over IPv4 to
connect itself with one of the anycast TS. The protocol that is
immediately over IPv4 is IPv6, which due to fact that it is also a
network protocol, does not neither maintain information of the state
of the connection and its operation is similar to the case of making
a connection between client and server using UDP protocol.
In this case, a datagram using the IPv6 tunnel can reach more than
one anycast TS at the same time, nevertheless due to the preventive
measures of the TS ("address spoofing"), these only extract IPv6
Palet & Diaz Expires October 14, 2004 [Page 9]
Internet-Draft Evaluation of IPv6 Tunnel Auto-discovery April 2004
datagrams of tunnels that were configured previously. In this way
with a good tunnel management, only one of the anycast TS will be the
tunnel end for each user and all the datagrams that arrive to wrong
TS will be silently discarded [6]. On the other hand, if an erroneous
configuration exist and more than one anycast TS is configured like
tunnel end, when arriving to them the same datagrams, then these
would be processed by all the wrongly implied TSs and they would be
directed towards the IPv6 node destination through different paths.
Therefore the same IPv6 datagram can arrive duplicated to the IPv6
destination host, which is the same behavior as in the case of a
unicast communication between two IPv6 hosts, given the
characteristics of IP networks. The protocols of the higher layers,
will cope with this situation.
Therefore except for the possible multiplication of the generated
traffic, it does not seem that the fact that the datagrams arrive to
more than one anycast server become a problem, not only if we
consider the connection with anycast TBs but also if we consider the
establishment of tunnels with anycast TSs. Despite it is recommended
that only one anycast host is used in the communication.
4.1.2 Delivery of datagrams belonging to the same connection to
different anycast hosts
In this assumption, unlike the previous one, datagrams belonging to
the same connection are delivered to different anycast nodes (AN),
even without having duplicity in the delivery of the datagrams, that
is, if AN1, AN2, AN3 are nodes belonging to the same anycast group
and CN is a node that is establishing communication with the anycast
group by sending the datagrams D1, D2, D3, D4, D5, etc., it can arise
situations of this type: D1 it is delivered to AN1, D2 is given to
AN3, D3 is given to AN2, D4 is given to AN3, etc.
In case of a communication with an anycast TB, since TCP-like
connection protocols would be used, this would cause a problem that
would avoid the attainment of the connection between the client host
and the anycast TB, since the datagrams sent to the server host that
did not establish the connection with the client host would be
discarded.
In case the client makes a tunnel with the properly configured
anycast TS and without considering other issues like authentication,
security, etc., an important problem appears in case the IPv4
datagrams were fragmented, since each TS would have a different
fragment and it would not be possible to join them. The only
solutions to avoid this situation are (1) to setup the IPv6 MTU to
the minimum possible value (1280) and enable the "Don't Fragment" bit
of the IPv4 header or (2) to force that all the datagrams flowing
Palet & Diaz Expires October 14, 2004 [Page 10]
Internet-Draft Evaluation of IPv6 Tunnel Auto-discovery April 2004
through the tunnel arrive to the same TS, which can be considered as
more convenient solution.
Therefore it seems recommendable, even mandatory, that in a scenario
where either the TB or TS are based on anycast addresses, all the
communication between the client and the server hosts are always made
through the same anycast server.
Some solutions to overcome this issue are:
1. Modify the behavior of the TCP/IP stack so that when a client
node sends a message TCP SYN to contact with a anycast server
hosts, this replies with a message TCP SYN-ACK but placing in it
the unicast address that the anycast hosts has rather than the
anycast address. As well, the client instead of rejecting the
datagram coming from an unicast address different to the anycast
one which it sent the connection request, it will accept it and
will send the TCP ACK message to the anycast server hosts to
finish the connection establishment process. Nevertheless this
solution does not adapt to the anycast TB implementation since it
requires the modification of the TCP/IP stack in both the client
and server sides besides to open the doors to possible attacks to
the security of the communication
2. Modify the behavior of the TCP/IP stack at the TB/TS hosts, so
when the anycast server receives a TCP SYN message for starting
the connection, it responds with a TCP SYN-ACK message including
in the IPv4 header the "Loose Source Route" option with only its
unicast address. When the datagram arrives at the client, it
includes the same option in the rest of datagrams that it will
send. In this way, the "Loose Source Route" option will force
that all the datagrams arrive at the same anycast server host.
This solution only would require to make modifications in the
anycast TB/TS hosts. Seems a quite reasonable solution with the
only disadvantage that the communication can have a slightly
lower throughput because all the routers that are crossed by the
datagrams must examine and interpret the option field of these
datagrams.
3. Use conversion techniques from anycast addresses to unicast,
which are carried out in a separated way to TCP. The HTTP
protocol would perfectly fit in this solution: the client tries a
TCP connection with an anycast server host and when this already
has been established, the server makes an HTTP redirection
towards the most appropriate TB.
4. Controlling the anycast flows in the routers, by classifying them
according to the source and destination addresses, used
Palet & Diaz Expires October 14, 2004 [Page 11]
Internet-Draft Evaluation of IPv6 Tunnel Auto-discovery April 2004
protocols, etc. By identifying the flows, the routers could make
arrive the datagrams at the appropriate anycast hosts, although
this would cause an extraordinary load of processing in the
routers.
5. Modify the IP protocol to include a new option "Source
Identification Option" with the purpose of identifying the
unicast source of an anycast sender host. Once more, this option
is not recommendable by the fact that requires the IP stack
modification in all the nodes that take part in the
communication.
4.2 Routing and Load Balancing with Anycast Addresses
The adequate routing of the anycast addresses is fundamental to
achieve that the datagrams arrive to the more appropriated anycast
host. For that, the simplest way is to route these datagrams as if
they were unicast, using the metrics that the routing protocols
usually manage (less hops, route with less cost, etc.) to select the
proper path. This method usually is known with the name of network
layer anycast in contrast with the application layer anycast, which
is based on metrics like the available capacity, number of active
connections, delay time, etc. (calculated by means of applications
specially developed to be run in the servers). For a service like
anycast TB it seems recommendable to use a combination of both
methods. Nevertheless although the connection of the clients was made
always with the more suitable TB, it would exist no guarantee that
the anycast negative effects already described are not going to
happen due to network topology changes or routing failures. Actually,
a good routing method should be combined with some of the methods
already described, which guarantees the exclusive communication with
the more appropriate anycast TB
4.3 Announcement of the Anycast Addresses
Another important routing aspect is the consideration or not of
anycast address space within the current IPv4 space. It would be
possible to define a space of anycast addresses completely
differentiated from the rest of unicast addresses. This approach
would facilitate the identification by the client nodes about the
anycast nature of the communication to be initiated. This type of
address could also be exported by the routing protocols as network
routes, instead of nodes. Nevertheless given the fact that the node
clients already know that connections with TB are a service that
requires anycast communication and given the current restrictions in
the IPv4 address space, it does not seem advisable that anycast
addresses have its own separated space, and is out of scope of this
Palet & Diaz Expires October 14, 2004 [Page 12]
Internet-Draft Evaluation of IPv6 Tunnel Auto-discovery April 2004
document.
Therefore, for the case of anycast TB the treatment of the anycast
addresses by the routing protocols should be the same as in the
unicast case, although this supposes a greater load of processing and
increase of the routing tables. In this way, the anycast server hosts
only have to announce to the nearest routers that they can be
considered as destination for the anycast addresses that they
announce. Then, the routers will export the route to the network.
Other alternatives to this method exist, but from the point of view
of the anycast TB the differences are not significant. This approach
also means that we have to overcome two new obstacles due to the
measures that many ISP use in a preventive way: (1) with the purpose
of avoiding an extraordinary increase in the routing tables some ISPs
filter routes whose destination is not networks but nodes; (2) most
ISPs filter all the traffic whose source address, in this case the
anycast address, does not match to the network prefix that the
network has assigned.
4.4 Management of TB/TS with Nomadic Users
Since the access to an anycast TB is always made by using only one
address, which can have the corresponding DNS entry, this approach
could admit two different treatments related to both the registration
and authentication process of the user each time the user wishes to
create a new tunnel when he is away from its initial home connection:
1. Simple management. It is unlikely that all the organizations that
give the TB service want to associate each other to facilitate
the management of users. For this reason when the user willing to
create a new tunnel is redirected to a new TB in which he has not
been registered previously, the user would have to make again the
whole registration process to provide the required data that make
possible the creation of a new IPv6 tunnel with the new TB. This
situation don't creates additional hurdles compared with the use
of a TB unicast. Alternatively, anonymous users could be
supported by some TBs, but this is a commercial consideration out
of the scope of this document.
2. Advanced management. This solution tries to facilitate the user
management. In fact with this procedure all the process related
to the change of TB would be transparent for the user, but before
it would be necessary to asses at least the solution of the
following aspects:
A. To maintain, independently of the TB used for the access, the
user historical data regarding statistics, tunnels that are
up, tunnels used in the past, traffic, etc. This data is
Palet & Diaz Expires October 14, 2004 [Page 13]
Internet-Draft Evaluation of IPv6 Tunnel Auto-discovery April 2004
important to make an appropriate billing in case the service
is chargeable
B. The user should be authenticated with any AAA procedure by
the "home" TB, the one were the user is firstly registered as
a "customer". The user should provide the proper data that
identifies its original TB in order to make the
authentication process in it
C. As a new IPv6 address is assigned, the host will not be
reachable by other IPv6 nodes using the old IPv6 address, the
one provided by the "home" TB. To avoid this situation it
would be possible to use MIPv6 mechanism, that inform the new
IPv6 address to the Home Agent. The Home Agent should be
implemented and located in the "home" TB.
When the TB consists of several anycast TS, if the chosen
architecture is the "simple management", users would need to contact
with the TB to create a new tunnel and the TB would make all the
necessary configurations in the new assigned TS. The IPv6 address
that the TB would provide to the user could be the same or a
different one, depending on the networks in which the TS is located.
However, if the architecture implemented is the "advanced
management", the user does not need to contact to the TB, but the
following issues must be solved:
1. The establishment of an IPv6 over IPv4 tunnel requires the
appropriate configuration at both tunnel ends. In the client
side, the configuration will not change, even when the user
change its location. However, the TS can be different, so it
would be necessary to somehow notify the new TS that must
authorize the forwarding of the datagrams to/from the user who
has changed its location. It would be necessary to develop some
type of automatic authentication (AAA) by means of script/
application before allowing the use of the new TS
2. Once the new user has been authenticated, the tunnel end has to
be configured at the TS side
3. In order to make the change of location process absolutely
transparent for the user, he would have to maintain the same IPv6
address, which would force to all the TS serve IPv6 addresses
with the same prefix network since otherwise the IPv6 datagrams
always would be discarded in the TS when verifying that a
datagram with a different prefix network arrives to it. The
prefix aggregation considerations are relevant here. One
alternative is the use of IPv6 in IPv6 tunnels, but that means
the traffic being rerouted, and consequently is not efficient.
Palet & Diaz Expires October 14, 2004 [Page 14]
Internet-Draft Evaluation of IPv6 Tunnel Auto-discovery April 2004
TBD.
4.5 Change of Network Conditions
The change to a more suitable TB or TS could arise not only because a
user geographic location change, but also because some of the anycast
server nodes get down or the network conditions and/or topology
change. In this case the user is not conscious of it. In order to
ensure the best performing connection, it would be necessary to solve
the following issues:
1. The network would have to inform to the user that it is required
or suggested to change the TB or TS and to make a new tunnel. TBD
2. In case a TB is formed by several anycast TS, the seamless change
is possible since the user would have at anytime an IPv6 tunnel
towards a single IPv4 address (anycast). If all the TS belong to
the same TB, it can facilitate the management, however it is
necessary to solve the issues regarding to the mechanisms of
automatic authentication. Even in this case there is one more
difficulty because now on the user side any script/application
could not be ran when the tunnel is already up
The following table depicts a summary of the possibilities of the
anycast TB architecture.
+----------------------+----------------------+---------------------+
| | | Anycast TB |
+----------------------+----------------------+---------------------+
| Change of location | Manual | - Simple |
| | configuration: it is | management. User is |
| | not transparent for | registered as new |
| | the user | user and a new |
| | | tunnel is created |
| | | in the new TB - |
| | | Advanced |
| | | management: User |
| | | data is maintained |
| | | and a new tunnel is |
| | | created. Usage of |
| | | MIPv6 concepts |
| | Automatic | It is not feasible |
| | configuration: it is | if connection with |
| | transparent for the | the nearest TS is |
| | user | desirable since the |
| | | new tunnel |
| | | establishment is |
Palet & Diaz Expires October 14, 2004 [Page 15]
Internet-Draft Evaluation of IPv6 Tunnel Auto-discovery April 2004
| | | made through the |
| | | TB, so this avoids |
| | | that the management |
| | | is transparent. |
| Change of network | Manual | - Manual management |
| conditions | configuration: it is | needs to be |
| | not transparent for | previous to the |
| | the user | user notification. |
| | | - It is feasible |
| | | both types of |
| | | managements: simple |
| | | and advanced. |
| | Automatic | It is not feasible |
| | configuration: it is | if connection with |
| | transparent for the | the nearest TS is |
| | user | desirable since the |
| | | new tunnel |
| | | establishment is |
| | | made through the |
| | | TB, so this avoids |
| | | that the management |
| | | is transparent. |
+----------------------+----------------------+---------------------+
Table 1
The following table depicts a summary of the possibilities of the
anycast TS architecture.
+----------------------+----------------------+---------------------+
| | | Anycast TS |
+----------------------+----------------------+---------------------+
| Change of location | Manual | - User only has to |
| | configuration: it is | run a script to get |
| | not transparent for | the tunnel up - All |
| | the user | the TS have the |
| | | same network |
| | | prefix: if all at |
| | | he TS have all the |
| | | data regarding all |
| | | the tunnels then it |
| | | is not necessary to |
| | | contact to the TB - |
| | | All the TS have |
| | | different network |
| | | prefix: it is |
| | | necessary to |
| | | contact to the TB |
Palet & Diaz Expires October 14, 2004 [Page 16]
Internet-Draft Evaluation of IPv6 Tunnel Auto-discovery April 2004
| | | to create the new |
| | | tunnel. |
| | Automatic | - User only has to |
| | configuration: it is | run a script to get |
| | transparent for the | the tunnel up - All |
| | user | the TS have the |
| | | same network |
| | | prefix: only the |
| | | user authentication |
| | | is needed to use |
| | | the new TS - All |
| | | the TS have |
| | | different network |
| | | prefix: it is not |
| | | possible because |
| | | the IPv6 address |
| | | would be different. |
| Change of network | Manual | It is not feasible |
| conditions | configuration: it is | because if the |
| | not transparent for | management is |
| | the user | manual, after the |
| | | notification to the |
| | | user is made, the |
| | | new configuration |
| | | would be made using |
| | | the TB by the user. |
| | Automatic | - All the TS have |
| | configuration: it is | the same network |
| | transparent for the | prefix: It is only |
| | user | feasible if all the |
| | | TS have available |
| | | the data regarding |
| | | all the tunnels |
| | | created at the TB. |
| | | - All the TS have |
| | | different network |
| | | prefix: it is not |
| | | possible because |
| | | the IPv6 address |
| | | would be different. |
+----------------------+----------------------+---------------------+
Table 2
5. Anycast TB Architectures
Considering the previous sections, some architectures can be proposed
Palet & Diaz Expires October 14, 2004 [Page 17]
Internet-Draft Evaluation of IPv6 Tunnel Auto-discovery April 2004
to implement TB/TS based on anycast addresses and allow load
balancing
5.1 TB with a Single TS
5.1.1 Anycast based on the network layer
This architecture, that is shown in the figure 1, consists of several
anycast TBs belonging to the same group. They announce the anycast
address by means of the usual routing protocols. The load balancing
would be obtained equipping with "intelligence" the routers so that
they change the priority of each route to the anycast destination by
following any of the previous enumerated solutions. On the other
hand, the connection with a single TB of the anycast group would be
obtained with the addition of the option "Loose Source Option" in the
IPv4 header.
5.1.2 Anycast based on the application layer
In this architecture the concept of Intermediary TB (ITB) appears, as
shown in Figure 2. Several ITBs belongs to the same anycast group and
they have associated an unicast TB group. The ITB has real time data
about each associated TB like number of active tunnels, traffic
amount, delays and so on, in order to make the balance of the
connections. Users willing to create a new tunnel connect to the
anycast ITB which makes the redirection of the HTTP connections to
the appropriate associated TB according to the real time data. In
this case, the anycast address of the ITB can correspond to a
standardized domain name, like http://www.tunnel-broker.net or
similar in order to facilitate the user access.
5.2 TB with Anycast TS Cluster
If the TB consists of an anycast TS Cluster, a possible architecture
is shown in Figure 3.
The key in this implementation is the selection of the TS. The
procedure is based on the ICMPv4 ping requests as follows: when the
user wants to create an IPv4 tunnel he contacts to the TB which
informs to all the TS and then each anycast TS sends to the user a
sequence of pings with a code that it identifies each TS. The source
address of the ping datagrams is the anycast group. The user host
sends ICMPv4 ping replies towards the anycast address which arrive to
different TS. However, the nearest one receive the most ping replies.
By means of a complex process the TB is informed about which is the
TS that has received more ping replies and the tunnel configuration
is made on it.
Palet & Diaz Expires October 14, 2004 [Page 18]
Internet-Draft Evaluation of IPv6 Tunnel Auto-discovery April 2004
Although this architecture solves the problem to find the nearest TS
to the user, it presents some disadvantages:
o The TS assignment is not made according to load criteria.
o Does not allow a dynamic load balancing.
o It does not make possible a transparent change process of TS for
the user when the conditions of network are different.
o It is not tolerant to failures of the TS.
6. Conclusions
TBD.
7. Security Considerations
TBD.
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 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] Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6 Tunnel
Broker", RFC 3053, January 2001.
[2] Palet, J., "Forwarding Protocol 41 in NAT Boxes",
draft-palet-v6ops-proto41-nat-03 (work in progress), October
2003.
[3] Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting
Service", RFC 1546, November 1993.
[4] Brisco, T., "DNS Support for Load Balancing", RFC 1794, April
1995.
Palet & Diaz Expires October 14, 2004 [Page 19]
Internet-Draft Evaluation of IPv6 Tunnel Auto-discovery April 2004
[5] Kim, P. and S. Park, "DHCP Option for Configuring IPv6-in-IPv4
Tunnels", draft-daniel-dhc-ipv6in4-opt-02 (work in progress),
March 2004.
[6] 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
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 14, 2004 [Page 20]
Internet-Draft Evaluation of IPv6 Tunnel Auto-discovery 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 14, 2004 [Page 21]