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]