Internet Engineering Task Force J. Palet Internet-Draft M. Diaz Expires: March 6, 2005 Consulintel September 5, 2004 IPv6 Tunnel End-point Automatic Discovery Mechanism draft-palet-v6ops-solution-tun-auto-disc-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 6, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract Tunneling is commonly used by several IPv6 transition mechanisms. To be able to automate setting up tunnels, one critical component is a solution to automatically discover the tunnel end-point (TEP) for the transition mechanism. This memo proposes a solution for discovering the IPv6 TEP in a simple an efficient way. Palet & Diaz Expires March 6, 2005 [Page 1] Internet-Draft IPv6 Tunnel End-point Auto-Discovery Mechanism September 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview and Rationale . . . . . . . . . . . . . . . . . . . . 4 3. Solution Implementation . . . . . . . . . . . . . . . . . . . 4 3.1 SRV RR . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2 A/CNAME RR for Unicast . . . . . . . . . . . . . . . . . . 5 3.3 Shared Anycast . . . . . . . . . . . . . . . . . . . . . . 5 4. Solution Description . . . . . . . . . . . . . . . . . . . . . 6 5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1 ISP offering transition service(s) with SRV support on its DNS server . . . . . . . . . . . . . . . . . . . . . . 8 5.2 ISP offering transition service(s) without SRV support on its DNS server . . . . . . . . . . . . . . . . . . . . 8 5.3 ISP offering transition service(s) by means of third parties . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.4 ISP offering transition service(s) only to own customers . . . . . . . . . . . . . . . . . . . . . . . . 9 5.5 ISP offering transition service(s) to external users . . . 10 5.6 ISP does not offer transition service at all . . . . . . . 10 6. Increased Scalability and Automation . . . . . . . . . . . . . 10 7. Alternative DHCP-based Solution . . . . . . . . . . . . . . . 11 8. Service Names for Transition Mechanisms . . . . . . . . . . . 11 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . 12 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 13.1 Normative References . . . . . . . . . . . . . . . . . . . . 12 13.2 Informative References . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 14 Palet & Diaz Expires March 6, 2005 [Page 2] Internet-Draft IPv6 Tunnel End-point Auto-Discovery Mechanism September 2004 1. Introduction During the IPv6 transition stage, it is foreseen that different transition mechanisms are used. Most of them are tunnel-based and it is critically important to ensure that the setup of the IPv6 connectivity is simple, so that it can be done also by non-technical users, or even completely transparently, without the user recognizing that IPv6 connectivity has been obtained. A critical piece in the automated set-up is discovering the tunnel end-point (TEP), also known as tunnel-server (TS), for the transition mechanism that will be used by the client (or rather, their operating system). Note that the tunnel end-point at the server side (TS) typically also needs to have a mean to configure the client (tunnel) end-point, but that is assumed to be transition mechanism specific, and beyond the scope of this memo. In this memo an elegant and simple solution for the TEP auto-discovery is described, which fits in all the scenarios analyzed in [1]. The solution offers the following features: 1. It is simple. 2. It can be easily deployed. 3. It is scalable. 4. It is topologically correct: Provides the nearest TEP to the user in terms of hops. 5. Applies to all the existing transition mechanisms (and possibly future ones), without any need for modifying them. 6. It is based on a combination of DNS and anycast (shared unicast according to some terminology [2]) approach. 7. It offers certain degree of redundancy: It would work if either the DNS or the anycast support fail. 8. It offers load balancing capability in order to share all the known TEPs among all the clients willing to get IPv6 connectivity through them. 9. It is fast and does not add significant overhead into the transition mechanism setup process. Palet & Diaz Expires March 6, 2005 [Page 3] Internet-Draft IPv6 Tunnel End-point Auto-Discovery Mechanism September 2004 2. Overview and Rationale As pointed out at [1], the DNS is globally deployed and easy to use. By means of prefixing the search path one can look up for a specific service that is a specific TEP or transition mechanism server [3]. On the other hand, shared anycast is also a very useful approach since it can globally identify a specific service (TEP or transition mechanism). It is even easier and simpler than the DNS approach. However anycast routes not always are well configured and stable, so connection with the server belonging to an anycast group could not be always possible, which means that is not necessarily the most topologically correct. Moreover, consecutive datagrams sent from the same host towards the same anycast address have no guarantee at all that they are going to be delivered to the same anycast node. For this reason, the anycast approach is only considered as a complementary backup solution when prefixing the search path on DNS has negative replies. In addition, both approaches offer the possibility of pointing directly to the TEP or alternatively to an intermediate node (i.e. Tunnel Broker, TB) where to start the signaling handshake for setting up the tunnel. The idea that the auto-discovery solution exploits is that the client willing to use a transition mechanism will first make one or several DNS queries. The DNS will redirect to a TEP (or alternatively a TB more sophistication is required) located within the ISP or a third party (other near ISP, roaming TEP service, etc.), if possible. Alternatively, the DNS could also reply with an anycast address for the searched TEP. The solution consequently, makes use of existing protocols, not requiring modifications or any new protocol. Details of how the DNS queries are made and how the prefix search path is used are presented below. 3. Solution Implementation The solution requires the implementation, at the ISP willing to offer the service, of one or several of the following: 3.1 SRV RR The DNS server of the ISP deploying a specific transition mechanism should use SRV RR to announce the transition mechanism service. Palet & Diaz Expires March 6, 2005 [Page 4] Internet-Draft IPv6 Tunnel End-point Auto-Discovery Mechanism September 2004 According to [4] the SRV RR for a specific transition mechanism should have the following format: _Service._Proto.Name TTL Class SRV Priority Weight Port Target The service name for the auto-discovery purpose should be standardized for each transition mechanism. transition-mechanism_srv.ispname.com (assuming that the domain name of a ISP is ispname.com). For example the records for 6in4, tsp, teredo, isatap and 6to4 would result: 6in4_srv.ispname.com, tsp_srv.ispname.com, teredo_srv.ispname.com, isatap_srv.ispname.com, 6to4_srv.ispname.com, etc. Some illustrative examples of specific transition mechanisms SRV RR are: _6to4_srv._ipv4 SRV 0 1 10000 server1.ispname.com _tsp_srv._tcp SRV 1 2 80 server2.ispname.com _teredo_srv._udp SRV 2 1 3456 server3.ispname.com 3.2 A/CNAME RR for Unicast A standardized A/CNAME RR for each supported transition mechanisms within the domain of the ISP, using the same nomenclature as introduced in the previous section, in the form: transition-mechanism_srv.ispname.com (assuming that the domain name of a ISP is ispname.com). For example the records for 6in4, tsp, teredo, isatap and 6to4 would result: 6in4_srv.ispname.com, tsp_srv.ispname.com, teredo_srv.ispname.com, isatap_srv.ispname.com, 6to4_srv.ispname.com, etc. 3.3 Shared Anycast Each transition mechanism could have assigned and implemented a shared anycast address, such as in the case of the 6to4 transition mechanism [5]. The anycast prefix/address for each transition mechanism is listed below (TBD by IANA): Palet & Diaz Expires March 6, 2005 [Page 5] Internet-Draft IPv6 Tunnel End-point Auto-Discovery Mechanism September 2004 Transition Mechanism Anycast Prefix/Adddress TBD Note: The use of the underscore character minimizes the probability of conflict with DNS names already defined. 4. Solution Description The ideal situation is to implement all the points indicated in the previous section. Under that scenario, the auto-discovery mechanism would offer the best functionality and all the features described above. However, it is not mandatory that all them are fulfilled in order to provide a functional auto-discovery mechanism, but at least one must be implemented. In this way the auto-discovery mechanism will work during all the deployment stages (auto-discovery not yet standardized, auto-discovery already standardized but less deployed, auto-discovery highly deployed). As many are implemented, more functional the auto-discovery mechanism is. When looking for a specific TEP within the ISP the user belongs to, the first step is always the same because the user does not know (and neither has to know) which is the transition mechanism deployment status within its ISP, so the user always query firstly for a DNS SRV RR to its ISP DNS server. To do that, the ISP's domain name is essential for prefixing the DNS search path, so the client (or rather the operating system) firstly learns the domain name of the ISP. There are several ways to do it, but in general it will be learned by making NS RR queries to the DNS. The ISP's domain name will be the base string for the prefixing of the DNS search path. Once the client has discovered it, a first attempt to find the TEP of the specific transition mechanism is made by building a SRV RR query (i.e. _tsp_srv._tcp.ispname.com) to the DNS server belonging to the ISP. Next it is shown an example of how the DNS SRV RRs would be used to query the ISP DNS server. To discover the specific TEP within the ISP domain (say, ispname.com), the client (rather the operating system) makes a DNS query [6][7] for QNAME=_teredo_srv._udp.ispname.com, QCLASS=IN, and QTYPE=SRV If the DNS server matches the query, it returns the proper reply with all the possible targets defined for that query, so the client will receive a list of DNS SRV RRs in a DNS reply, which gives all the Palet & Diaz Expires March 6, 2005 [Page 6] Internet-Draft IPv6 Tunnel End-point Auto-Discovery Mechanism September 2004 teredo TEPs in the ISP domain ispname.com, such as: ;; Priority Weight Port Target _teredo_srv._udp.ispname.com IN SRV 0 0 4500 tep1.ispname.com _teredo_srv._udp.ispname.com IN SRV 0 1 4000 tep2.ispname.com _teredo_srv._udp.ispname.com IN SRV 1 0 5000 host.other_ispname.com _teredo_srv._udp.ispname.com IN SRV 2 0 5000 tepnode.other-domain.com When there are more than one TEP, all of them could be assigned with different priority and weight parameters in order to do load balancing. Even some of them could be located outside the ISP. The client will try all the obtained TEP according to the SRV RR information (priority and weight) until it gets connected to one of them. At this point the auto-discovery function ends. If no DNS SRV RR reply is obtained (either because the DNS administrator did not created DNS SRV RR entries for the requested transition mechanism or either the DNS server or client resolver has not SRV RR support), then an A/CNAME query is built by the client by appending the standardized service name to the ISP domain name in accordance with the what has been indicated at the "A/CNAME RR for Anycast" section (i.e. teredo_srv.ispname.com). Follows an example of how the DNS A/CNAME RRs would be used to query the ISP DNS server. To discover the specific TEP within the ISP’s domain (say, ispname.com), the client (rather the operating system) makes a DNS query [6][7] for QNAME=teredo_srv.ispname.com, QCLASS=IN, and QTYPE=A or QTYPE=CNAME. If there is a TEP deployed within the ISP (or a third party one), then the DNS reply redirects the client to it and the auto-discovery function ends in this point. Finally if there is not a valid A/CNAME RR matching the client query, then the client will directly refer to the standardized "Shared Anycast" address regarding the searched TEP. This allows the provision of the service, for free, by third parties, when the own ISP does not provide it (i.e. nomadic users), and doesn't require any configuration in the ISP infrastructure. In this point the auto-discovery function ends. Although by using the standardized shared anycast address the client always will contact to one TEP (assuming BGP routes are well configured, it could be within the own-ISP infrastructure), the use of the shared anycast address is preferred as the last option after DNS SRV RR and DNS A/CNAME RR fails. This is because by means of DNS RR, administrators will always configure nearest TEP hosts (within the client ISP) for own-customers and load balancing can be better Palet & Diaz Expires March 6, 2005 [Page 7] Internet-Draft IPv6 Tunnel End-point Auto-Discovery Mechanism September 2004 done (in case of DNS SRV RR). Consequently, the shared anycast option is used only as backup solution and also to provide service to external users. 5. Case Studies In order to clarify the behavior of this solution, some case studies are presented below. It also shows how flexible is the solution and how it can be used depending on the deployment stage at the ISP or even its willingness to provide service only to own-customers or external ones. 5.1 ISP offering transition service(s) with SRV support on its DNS server Many ISPs could offer IPv6 transition service(s) by deploying one or several TEPs in its own infrastructure. It is also possible that ISPs are interested to offer IPv6 transition mechanisms by means of third party agreements or even through well know and convenient near TEPs which are for free. In this case, the ISP could setup the DNS server with SRV RRs with the "Target" parameter pointing be the TEPs deployed either inside that ISP or the third party one. Several SRV RRs can be configured for each specific transition mechanism service available. If the ISP DNS server has SRV RRs matching the client query, then it will reply with all the SRV records matching that query. The "Priority" parameter of the SRV record could be used to prioritize the own TEPs. If the higher priority TEP does not respond, the client will attempt the next one, and so on. Some load balancing among TEPs is possible by using the "Weight" field as suggested by [4]. The standardized shared anycast address for each specific mechanism TEP could be added as target to the DNS SRV RR. In that case it should have the lowest priority in order to redirect the client always to local TEP as a first option. 5.2 ISP offering transition service(s) without SRV support on its DNS server Even if unusual is possible that the DNS servers doesn't support SRV RR or that the ISP does not wish to configure SRV RR, for whatever reason. Even do, the ISP may be interested in offering transition services to its customers, and several TEPs, for different transition Palet & Diaz Expires March 6, 2005 [Page 8] Internet-Draft IPv6 Tunnel End-point Auto-Discovery Mechanism September 2004 mechanism will be deployed. In this case the best solution for announcing local TEPs within the ISP is by means of DNS A/CNAME RR. Clients will always try to get a valid DNS SRV RR reply, but once it fails a valid DNS SRV A/CNAME will be queried. However, in this case the load balancing feature is somehow limited, based only on round-robin RR techniques, according to the capabilities of the DNS server. 5.3 ISP offering transition service(s) by means of third parties In initial early deployment stages, it is possible that ISPs can not offer this service by themselves (either because bussiness considerations or because lack of resources, knowledge, etc.). However, they can agree with third parties for offering the service to theirs customers. They can even facilitate their customers the auto-discovery of free TEPs located in other domains. In this case, they can proceed as already indicated in the previous cases which mention how a third party TEP can be announced by the DNS. 5.4 ISP offering transition service(s) only to own customers The solution indicated in the previous cases is available to any client that use the a DNS server which has been configured to advertise the TEPs, even to external users (non-customers) using that DNS server. If an ISP wants to ensure that only own-customers automatically discover the advertised TEPs, it could configure the DNS server(s) to send different replies (views), either DNS SRV or A/CNAME RRs, based on the IP address of the incoming queries. According to this, a SRV or A/CNAME RR query coming from a customer (the IP will belong to the ISP allocations), could have a reply containing the information regarding the requested TEPs deployed within the ISP, the TEPs deployed by associated third parties, the anycast address of the TEP or any combination of these options. On the other hand, if the same query is coming from outside the ISP network, then the DNS reply could only contain the TEPs deployed by associated third parties or the anycast TEP or nothing. Unlimited configurations are possible. This view functionality strongly depends on the DNS server implementation that is being used within the ISP. Palet & Diaz Expires March 6, 2005 [Page 9] Internet-Draft IPv6 Tunnel End-point Auto-Discovery Mechanism September 2004 Similarly the anycast advertising can be limited by proper configuration of BGP, in order to avoid the TEPs being automatically discovered by non-customers. Avoiding the automatic discovery of the TEPs (by means of either DNS or anycast) will actually not avoid them being used, but only its auto-discovery, because they can be manually discovered/configured by the users. But is also possible to limit the access to the TEPs by means of filtering options, for example, to avoid any communication being initiated to them by IP addresses not belonging to that ISP. 5.5 ISP offering transition service(s) to external users If an ISP is willing to offer transition service(s) to external customers, the best option for facilitating the auto-discovery of the TEPs, is the configuration of the "Shared Anycast" as already previously described, for each of the transition mechanism supported. 5.6 ISP does not offer transition service at all In case an ISP does not deploy any transition mechanisms, and wish no support their customers for using external services, they may auto-discover available TEPs as indicated in the previous case. In this case, the client willing to use a specific TEP firstly will try to get a valid DNS SRV RR reply. However it will fail because the ISP DNS server will not have any entry for it. Once it fails, a DNS SRV A/CNAME will be also queried, which also will fail due to the same reason. This is the expected behavior of the auto-discovery mechanism and the reason for the Shared Anycast option. So, after both types of DNS queries have failed, client will try the standardized shared anycast address to get connected to the required TEP, which will be located out the ISP network. The only requirement for this to actually work, is that the ISP routes to the standardized shared anycast addresses have to be allowed within the ISP, so the foreign TEPs are reachable. This is currently a the normal situation, fulfilled by most of the ISPs, as proven with the 6to4 anycast address [5]. 6. Increased Scalability and Automation In order to provide a more automated service, or even increased scalability, a "Tunnel end-broker" (TEB) service could be defined and deployed. The basic idea is to have a broker server (teb_srv.ispname.com) that will add more sophistication to the system, but also increase the Palet & Diaz Expires March 6, 2005 [Page 10] Internet-Draft IPv6 Tunnel End-point Auto-Discovery Mechanism September 2004 complexity of the implementation. In this case, the transition mechanism will require a signaling higher layer, that could also provide authenticated transition services and enhanced roaming features. In this scenario, the client will always try first teb_srv (SRV, A/ CNAME) or the corresponding anycast address, automatically discover the adequate transition mechanism and the correct TEP, and then pass the information to the transition mechanism itself to establish the tunnel. At this way, the auto-discovery may be complemented with the auto-transition as described in [8]. 7. Alternative DHCP-based Solution Although the use of DHCP options to provide the TEP [9] has some drawbacks, as analyzed in [1], it is proven that in some scenarios it is useful, so it could be considered as a backup solution under certain scenarios when communication with the specific TEP is not possible due to whatever reason. Scenarios where DHCP applies are typically within enterprise networks, and users could use the information provided by the DHCP server to contact a 6in4 TEP. In this way, DHCP is an alternative basically when the enterprise wish to ensure a managed transition related to the DHCP usage, instead of the ISP provision, and has no control over DNS and/or BGP configurations. 8. Service Names for Transition Mechanisms This section list de transition mechanisms and the service names to be used: Transition Mechanism Service Name 6in4 (RFCxxxx) 6in4 tsp (RFCxxxx) tsp teredo (RFCxxxx) teredo isatap (RFCxxxx) isatap 6to4 (RFCxxxx) 6to4 ... ... TBD. Palet & Diaz Expires March 6, 2005 [Page 11] Internet-Draft IPv6 Tunnel End-point Auto-Discovery Mechanism September 2004 9. Conclusions In order to take advantage of the auto-discovery solution, the configuration scripts of the transition mechanisms should use the DNS RRs introduced in this document, always preferring SRV versus A/ CNAME. Anycast could be used as the last option. DNS views and filtering can be configured by ISPs to avoid the auto-discovery working for non-customers and to avoid the access to the TEPs by clients using IP addresses not belonging to the ISP. Those ISPs willing to provide service to external users, should properly configure Shared Anycast. Can/should we use this document also for auto-discovering IPv4 in IPv6 tunnels ? TBD. 10. Security Considerations TBD. 11. IANA Considerations Can we assign an anycast address for each transition mechanism ? TBD. 12. Acknowledgements The authors would like to acknowledge inputs from Alvaro Vives, Pekka Savola and the European Commission support in the co-funding of the Euro6IX project, where this work is being developed. 13. References 13.1 Normative References 13.2 Informative References [1] Palet, J. and M. Diaz, "Evaluation of v6ops Auto-discovery for Tunneling Mechanisms", draft-palet-v6ops-tun-auto-disc-01 (work in progress), June 2004. [2] Hagino, J. and K. Ettican, "An analysis of IPv6 anycast", draft-ietf-ipngwg-ipv6-anycast-analysis-02 (work in progress), June 2003. [3] Faltstrom, P., "Design Choices When Expanding DNS", draft-ymbk-dns-choices-00 (work in progress), May 2004. Palet & Diaz Expires March 6, 2005 [Page 12] Internet-Draft IPv6 Tunnel End-point Auto-Discovery Mechanism September 2004 [4] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [5] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001. [6] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [7] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [8] Palet, J. and M. Diaz, "Evaluation of IPv6 Auto-Transition Algorithm", draft-palet-v6ops-auto-trans-01 (work in progress), July 2004. [9] Kim, P. and S. Park, "DHCP Option for Configuring IPv6-in-IPv4 Tunnels", draft-daniel-dhc-ipv6in4-opt-04 (work in progress), July 2004. Authors' Addresses Jordi Palet Martinez Consulintel San Jose Artesano, 1 Alcobendas - Madrid E-28108 - Spain Phone: +34 91 151 81 99 Fax: +34 91 151 81 98 EMail: jordi.palet@consulintel.es Miguel Angel Diaz Fernandez Consulintel San Jose Artesano, 1 Alcobendas - Madrid E-28108 - Spain Phone: +34 91 151 81 99 Fax: +34 91 151 81 98 EMail: miguelangel.diaz@consulintel.es Palet & Diaz Expires March 6, 2005 [Page 13] Internet-Draft IPv6 Tunnel End-point Auto-Discovery Mechanism September 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Palet & Diaz Expires March 6, 2005 [Page 14]