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

Versions: 00 01 02 03

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]


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