Internet Engineering Task Force J. Palet Internet-Draft M. Diaz Expires: April 24, 2005 Consulintel P. Savola CSC/FUNET October 24, 2004 Analysis of IPv6 Tunnel End-point Discovery Mechanisms draft-palet-v6ops-tun-auto-disc-02.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 April 24, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract Tunneling is commonly used in several IPv6 transition mechanisms. To be able to automate setting up tunnels, one critical component is being able to automatically determine the tunnel end-point for the tunneling mechanism. This memo analyses the different approaches for configuring the IPv6 tunnel endpoint on a node. Palet, et al. Expires April 24, 2005 [Page 1] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms October 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Scenarios for Tunnel Endpoint Discovery . . . . . . . . . . . 3 2.1 Scenario 1: Initial IPv6 Deployment Stage . . . . . . . . 3 2.2 Scenario 2: Initial IPv6 Support from External ISP . . . . 4 2.3 Scenario 3: Nomadic Users . . . . . . . . . . . . . . . . 4 2.4 Scenario 4: Advanced IPv6 Deployment Stage . . . . . . . . 5 3. Analysis of Solutions . . . . . . . . . . . . . . . . . . . . 5 3.1 Shared-unicast -based Solutions . . . . . . . . . . . . . 5 3.2 Centralized Broker-based Solutions . . . . . . . . . . . . 6 3.3 DNS-based Solutions . . . . . . . . . . . . . . . . . . . 7 3.3.1 Prefixing the DNS Search Path . . . . . . . . . . . . 8 3.4 DHCP-based Solutions . . . . . . . . . . . . . . . . . . . 9 3.5 PPP-based Solutions . . . . . . . . . . . . . . . . . . . 10 3.6 SLP-based Solutions . . . . . . . . . . . . . . . . . . . 10 3.6.1 Remote Service Discovery through SLP-based Solutions . . . . . . . . . . . . . . . . . . . . . . 11 3.7 Combined Solutions . . . . . . . . . . . . . . . . . . . . 12 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. Informative References . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . 16 Palet, et al. Expires April 24, 2005 [Page 2] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms October 2004 1. Introduction Tunneling is commonly used in several IPv6 transition mechanisms. It is critically important to make setting up IPv6 connectivity simpler, so that it can be done simply also by IPv6-ignorant, novice users, or even completely transparently, without the user even having to know that IPv6 connectivity has been obtained. One critical piece in the automated set-up is discovering the end-point for the IPv6-in-IPv4 (or possibly in the future, IPv4-in-IPv6) tunnel. Note that the other end-point ("tunnel server") typically also needs to have a means to configure the client's end-point, but that is assumed to be transition mechanism specific, and beyond the scope of this memo. A solution is being designed [1] based on the tunnel server/broker concept [2] which will, in particular, require this kind of discovery. Many already-specified mechanisms already include a form of auto-discovery: for example, 6to4 [3] uses global anycast [4] and/or vendor's branch of DNS, Teredo [5] uses vendor's branch of DNS, and ISATAP [6] uses search-path -prefixed DNS. 2. Scenarios for Tunnel Endpoint Discovery At least three scenarios can be identified where tunnel endpoint discovery would be useful. 2.1 Scenario 1: Initial IPv6 Deployment Stage During the initial IPv6 deployment stage, the ISPs may not provide native IPv6 connectivity, at least in the access network. However, the ISP might offer IPv6 connectivity (probably for free) through an automatically set-up tunnel. In this scenario, the users (or rather, their operating systems) need to be capable of automatically detecting whether the user's ISP is offering such service or not, and setting up the tunnel if available. If this kind of IPv6 connectivity is set up automatically, it could create a load on the ISP's equipment which is configured as the tunnel-endpoint (e.g., a tunnel server). This is particularly important if state needs to be maintained. To address this consideration, the discovery method should allow for multiple end-points within a domain or even including a load-balancing mechanism. Palet, et al. Expires April 24, 2005 [Page 3] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms October 2004 2.2 Scenario 2: Initial IPv6 Support from External ISP During the initial IPv6 deployment stage, the ISPs might not support IPv6 at all; there are thousands of ISPs, and many certainly won't be supporting IPv6 any time soon. The customers of those ISPs then have to use automatic tunneling mechanisms such as 6to4 or Teredo, or get a third-party ISP for IPv6 connectivity. In this scenario, the users (in general their operating systems) may have a capability of automatically selecting a third-party ISP which is servicing outsiders. The service is often free of charge. The discovery process could either detect the closest serving end-point, or pick the one manually configured by the user. Given the fact that IPv6 service could be offered by third parties, some kind of authentication could be required in order to allow only registered customers to use the IPv6 service. The authentication method will depend on the transition mechanism, so it is out of scope of this memo. 2.3 Scenario 3: Nomadic Users Nomadic users require connectivity to Internet from everywhere, from different locations: meetings, conferences, holidays, etc. Under this circumstance (always) obtaining native IPv6 connectivity is not feasible. The user has two choices: to discover a local tunnel (with different IPv6 addresses and prefixes) if provided by the local ISP, or to connect to the "home ISP" or "home network", implying the possibility of keeping the same addresses. A local tunnel is typically a preferable choice, and could also be used as a Mobile IPv6 [7] care-of address. However, in many cases, the local ISP may not be providing a tunnel service. Connecting to a "home provider" to obtain the tunnel is typically a safe choice, provided that the "home provider" allows IPv4 addresses outside its own domain to use its tunnel services; at the very least, typically this will require some sort of authentication. However, especially when roaming on a different continent as the home network, the latencies, etc., may be undesirable, so one might want to keep this only as a backup option in case other approaches fail. The whole process for having a new IPv6 tunnel with a new provider should be as 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 architecture enables the users to get connected and re-connected to the nearest tunnel end-point without manual intervention (for example when moving). Palet, et al. Expires April 24, 2005 [Page 4] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms October 2004 2.4 Scenario 4: 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 ISPs providing IPv6 connectivity need to start a broader deployment. For a best IPv6 service, it is feasible that they increase the performance by using a tunnel end-point cluster geographically distributed to cover a country, etc. Furthermore they could offer the users only one of the methods proposed below for accessing the IPv6 connectivity. Each time users get IPv6 connectivity, they could use the same accessing method but they could be assigned to different tunnel end-point belonging the cluster. Under this schema, some kind of load balancing could be required in order to distribute the load among the ISP resources. In order to let all the candidate tunnel end-points to know the configuration of the previous user's tunnels, some kind of tunnel management should be defined. However it is strongly dependant on the transition mechanism used, so it is out of the scope of this document. In any case, as stated before, the whole process for obtaining 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 architecture makes the users get connected and re-connected to the nearest tunnel end-point without manual intervention. 3. Analysis of Solutions Several possible solutions to discovering the tunnel end-point can be imagined; this section describes them in detail. 3.1 Shared-unicast -based Solutions An "anycast" (shared-unicast by some terminology: see [8]) address identifies a group of hosts, usually server hosts. When a client sends a datagram to a shared-unicast address, it is delivered to one of the shared-unicast servers based on the routing topology and metrics. There are two possible ways of using "anycast": as a global service (where a shared-unicast prefix is the same for everyone, and advertised in the Inter-domain routing) or as a local service, where the service provider is sharing one of its own addresses on multiple nodes for example for load-balancing or redundancy reasons. Palet, et al. Expires April 24, 2005 [Page 5] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms October 2004 Global "anycast" might be best applicable in scenario 2, to automatically discover the closest serving third party ISP. However, this raises the question of feasibility of that scenario. Local "anycast" can be combined with other solutions, described later, to seamlessly provide multiple tunnel end-points inside a single domain. A packet to a shared-unicast address may end up being delivered to more than one node. In addition, there is no guarantee that two consecutive datagrams sent from the same host towards the same shared-unicast address are going to be delivered to the same node. However, when the routing topology is stable and metrics are well-designed, the packets are regularly delivered to the same nodes. It is also possible to only use an "anycast" address only for the initial handshake, to establish a stable unicast address of the end-point and to perform some initial negotiation (an example of such is described in [9]). 3.2 Centralized Broker-based Solutions Inside a single administrative domain, it would also be possible to deploy a centralized server or a "broker", which should know, probably in real-time, the status of all the associated end-points. Furthermore, it could, by using some means, redirect the users the correct end-points. This mechanism would still need another complementary approach to find the centralized broker. This approach is highly assumptive of the tunneling set-up mechanism, and likely requires the implementation of lengthy redirection/negotiation features. As such, its applicability is not further analyzed here. The selection of the proper TEP would be based on information about TEP loads and network metrics collected by several ways, such as RTTs measured by network probes, routing protocol information, and so forth. The user will need to connect to the selected TEP either by using the DNS system, when the client tries to resolve the host name, or by mean of whatever other mechanism defined, which possibly will require an specific code implementation on both centralized server and clients. Applying a centralized model over multiple administrative domains, e.g., having a single server for the whole Internet, would be administratively and management-wise unfeasible. Nevertheless, agreements between several domains could make possible sophisticated models. In summary, the main drawbacks of this solution are: Palet, et al. Expires April 24, 2005 [Page 6] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms October 2004 1. Centralized server is a single-point-of-failure. All the discovery service depends on the reliability of the server. 2. The implementation of a method to verify the load and RTTs of TEPs can be very complex and it can require external infrastructure such as network probes. 3. It can require the installation of specific software on both centralized server and clients to negotiate the proper TEP. 4. Seems to bring additional operational and protocol complexity (more complicated model, more boxes you need to communicate with meaning more packets sent and received, etc.). Of course, it will be possible to set-up complex redundant infrastructures to cope with some of those drawbacks. The fundamental question here is what benefits the centralized broker-based model could offer compared to a simpler model. Possibly many of those things which are often attributed to tunnel brokers can be done without them, but there may be some which are not as easy. Therefore, when evaluating the solutions, it will be important to be able to contrast the real benefits of the solution vs the drawbacks. 3.3 DNS-based Solutions As DNS is globally deployed and easy to use, it could provide a means for discovering the end-point address. There are roughly three kinds of different approaches with DNS-based discovery: 1. "global name": the systems look up a globally unique name, like www.tunnel-server.net.; this could be applicable with (unfeasible) global inter-domain broker or anycast-based solutions, and is therefore not considered at more length. 2. "vendor branch": the operating system vendors may provide a DNS record which is looked up (e.g., "6to4.windows.microsoft.com."), giving the vendor some control over already deployed systems. This is typically only feasible to configure a global anycast address, or provide the address of the vendor's own service, and is not applicable in a multi-vendor environment, and is not considered further. 3. "prefixing the search path" [10]: one could look up a service-specific special string, like "_tunnel-server", appended by the DNS search path, e.g., "isp.example.com", resulting in a Palet, et al. Expires April 24, 2005 [Page 7] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms October 2004 query of "_tunnel-server.isp.example.com". This assumes that the DNS search path is provided by the ISP, and used by the user; this applies to most users (advanced users may have their own domain names, own DNS servers, etc., but those could be expected to manually configure the end-point information). This is the most interesting approach, explored at more length below. The special string could be more complex and make reference somehow to the transition mechanism it will accept, i.e. 6to4_tunnel-server, 6in4_tunnel-server, teredo_tunnel-server, any_tunnel-server and so on. All of these approaches are typically coupled with a manual override option, which can be used by the knowledgeable users to look up different names or to specify the IP address completely. 3.3.1 Prefixing the DNS Search Path Prefixing the search path bears a bit more analysis. There a couple of fundamental questions: where to store the records (i.e., the prefix to use, and what to do with the conflicts), and how to store the information (i.e., whether to use A/AAAA records, other records). There are at least three concrete possibilities for how to store the information: 1. "A/AAAA/CNAME records": one could use just the regular records for storing the end-point address or name. A drawback is that there is a slightly higher probability of collision, depending on the service identifier used. The advantage is that it's very simple to implement and use. This also doesn't offer advanced load-balancing features, beyond those already provided by DNS round-robin techniques [11]. 2. "SRV records": SRV records were created specifically for service discovery and load-balancing, mainly as a means to provide the users (also external users) knowledge of services within a domain. Quite this amount of unambiguity would not be needed if the service identifier is unique enough and only used internally. A slight drawback is that SRV records require slightly more implementation and possibly more round-trips (if the results aren't cached). However they could be assumed considering the advantages that this solution offers. 3. "NAPTR records": NAPTR records provide even more flexibility than SRV records. The drawback compared to SRV is even more implementation and more round-trips. Furthermore, additional drawbacks of this solution are its complexity and the scarcity of Palet, et al. Expires April 24, 2005 [Page 8] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms October 2004 support on both DNS servers and DNS resolvers. The question of where to store the information has a few tradeoffs, also depending on how the information is being stored. Using a commonly used name as a service identifier coupled with A/AAAA records would likely lead to false positives. On the other hand, if a prefix like '_tunnel-server' would be chosen, it would be quite improbable that conflicts would appear in practice. It is also worth remembering that the result of a false positive (i.e., getting an address which is not a valid end-point) is not necessarily a huge problem because it's only an indicator that such service didn't exist in the domain, as long as the tunneling mechanism can recover from that scenario. Another consideration is the deployment of wildcard DNS records. If A/AAAA records were to be used, such records might create false positives quite easily. Fortunately, wildcards are commonly deployed only for MX records. A benefit of using SRV records is that they use an additional level in the zones, like: _tunnel-server._udp.isp.example.com."; this would prevent a wildcard record "*.isp.example.com" from harassing the discovery of the end-point. XXX: needs to be checked. 3.4 DHCP-based Solutions In most situations, the users receive 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 tunnel end-point address, e.g., as described in [12]. This approach has several drawbacks: o It requires upgrading the DHCP client/server implementations to support this feature. o It is restricted to the local ISP. That is, it will not be effective if the local ISP doesn't provide this parameter. This could be also be an advantage considering that the this would only support the tunnels provided by the local ISP, which would probably be of good quality. o It will not work if DHCP client is not used. DHCP is omitted especially in many dial-up scenarios, where only PPP is used; DHCP is not used in some (advanced) xDSL setups which use static routing. Also, some managed networks do not use DHCP. Still, in many cases, DHCP is used between a customer and the ISP. o If a router is providing local DHCP information (e.g., an ADSL Palet, et al. Expires April 24, 2005 [Page 9] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms October 2004 router), the tunnel end-point information would have to be automatically "proxied" to the "local DHCP", or manually configured on the router to propagate to the hosts in the case that the router is not activating the tunnel itself. o It requires manual configuration/update of the ISP's DHCP servers when there are changes to the tunnel end-points, similar to updating DNS, NTP, etc., 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 drawbacks (and advantages) as indicated for the DHCP-based solution. Further, there has been resistance to making extensions to PPP (e.g., passing IPv6 prefix options), so it is an open question whether this information could be passed as a standardized PPP option at all. 3.6 SLP-based Solutions The Service Location Protocol [13] provides a framework for the discovery and selection of network services. Tunnel-End-Point for IPv6 tunnels could be defined as a network service which will have also assigned a specific service name. Given the fact that currently exists several types of transition mechanism based on IPv4 tunnels, even more ones could appear in future, the service URL defined in the SLP system should specify the specific type of TEP the network has. For instance: o service:tep:6to4://6to4.domainexample.net o service:tep:6in4://6in4.domainexample.net o service:tep:teredo://teredo.domainexample.net By using this protocol, users requiring IPv6 connectivity based on a tunneled service could easily discover the specific IPv6 TEPs deployed on its network. Although an SLP-based solution is a good approach, it is intended to function within networks under cooperative administrative control, so it does not scale for the global Internet. For this reason, this solution seems to fit only in scenario 1, where users willing to get IPv6 connectivity only contact to local providers (home ISP, LAN, etc.). Palet, et al. Expires April 24, 2005 [Page 10] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms October 2004 However, SLP presents also other drawbacks to be taken into account: 1. It requires the deployment of Service Agents (SA), or at least a Directory Agent (DA), to which the User Agent (UA), on behalf of the user, sends the queries about the TEP service. Such SA deployment is not usually done within ISP, so it would be necessary to convince them to do it. It is hard work due to no revenue is expected from such a deployment. 2. If only SA is deployed, it requires multicast support for SA discovery. 3. If DA is deployed and the network has not multicast support, some way for discovery the DA is required. DHCP could be used as pointed at [13] but users connected to their ISP often utilize PPP instead, so DA discovery become an issue. 4. It requires the implementation of an UA on the client's host. This is neither always possible nor feasible. 5. It can not offer any kind of load balancing if more than one TEP is deployed. 6. It only announces TEPs belonging to the ISP scope, so it would not be possible to announce TEP deployed in third party networks. 3.6.1 Remote Service Discovery through SLP-based Solutions Remote service discovery through SLP [14] refers to discovering desired services in remote domains. By using [14], the local domain limitation of SLP is overcome, so the SLP scope can easily be increased to scale for the global Internet. It discovers remote services deployed in remote domains by querying directly to the remote DA instead the local one. Discovery of the remote DA is done via DNS SRV queries to the remote DNS server. This solution presents more advantages than the previous one, mainly it increases the scenarios where it applies to scenario 1 and scenario 3, however it still has most of the SLP drawbacks, particularly previous items 1, 4, 5 and 6. Furthermore the use of this solution is very restricted in the sense that users requiring IPv6 connectivity must previously know the remote domain where to make the SLP discovery. In other words, if the user's home-domain is domain A, and he knows that domain B has the TEP that he is looking for, then he has to make Palet, et al. Expires April 24, 2005 [Page 11] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms October 2004 an SLP query to the domain B DA (previously he has discovered the DA address by querying a DNS SRV) to discover the TEP. However, if the user does not know that domain B is deploying an IPv6 TEP, then he will not make the SLP query to the domain B DA and he will not obtain the required IPv6 connectivity. With this solution, there is no way to automatically inform the users where to find the TEP that they are looking for. They must know where to ask and if there is one or not, which once more, excludes this as a possible solution for the auto-discovery problem. 3.7 Combined Solutions There is a particularly interesting combination: DNS-lookups with a service identifier combined with the DNS search path (particularly with A/AAAA/CNAME records), and shared-unicast. DNS lookups can provide a local IP address (or addresses) for the end-points, and the local "anycast" approach can be used for load-balancing or adding more end-points to the system transparently so that every user uses the topologically closest end-point. Similar approach to "anycasting" the end-point address obviously also work for "anycast" and DHCP or PPP -based solutions. 4. Conclusions DNS appears to be the simplest means to achieve end-point discovery; DHCP and PPP have drawbacks and due to many scenarios where only one of them is used, both the solutions would be needed. Inter-domain anycast model appears to be practically unfeasible even if it could work especially if "anycast" was only used for the unicast address discovery. In the DNS, the records could be stored either in A/AAAA/CNAME or SRV records. The former appears to be slightly advantageous, while the latter is provably correct and offers slightly better load-balancing features, rather than a simple round-robin (and whatever may be obtained using e.g., anycast). Further analysis is still needed on the tradeoffs of these approaches. Local anycasting techniques using a shared-unicast address (or addresses) appear to be the most practical means for redundancy and load-balancing. 5. Security Considerations If the tunnel end-point discovery is done in an insecure fashion, so that an attacker could influence the discovery process, the attacker Palet, et al. Expires April 24, 2005 [Page 12] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms October 2004 could be able to hijack all the IPv6 communications. This must be kept in mind when analyzing the different discovery solutions, and spelled-out explicitly in the requirements, if the threats are to be mitigated in tunneling mechanisms somehow (e.g., using a return routability procedures). In particular, the potential weaknesses of DNS bear some consideration. 6. IANA Considerations This document requests no action for IANA. [[note to RFC-editor: this section can be removed upon publication.]] 7. Acknowledgements This memo was written as a consequence of real experience using IPv6 when traveling, number of talks during IETF meetings and specially the work with the unmanaged, ISP and enterprise v6ops design teams. The authors would also like to acknowledge inputs from Carl Williams, Brian Carpenter, Jeroen Massar and the European Commission support in the co-funding of the Euro6IX project, where this work is being developed. 8 Informative References [1] Parent, F., "Goals for Registered Assisted Tunneling", draft-ietf-v6ops-assisted-tunneling-requirements-01 (work in progress), October 2004. [2] Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001. [3] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [4] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001. [5] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", draft-huitema-v6ops-teredo-02 (work in progress), June 2004. [6] Templin, F., Gleeson, T., Talwar, M. and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", draft-ietf-ngtrans-isatap-22 (work in progress), May 2004. [7] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in Palet, et al. Expires April 24, 2005 [Page 13] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms October 2004 IPv6", RFC 3775, June 2004. [8] Hagino, J. and K. Ettican, "An analysis of IPv6 anycast", draft-ietf-ipngwg-ipv6-anycast-analysis-02 (work in progress), June 2003. [9] Thaler, D. and L. Vicisano, "IPv4 Automatic Multicast Without Explicit Tunnels (AMT)", draft-ietf-mboned-auto-multicast-02 (work in progress), February 2004. [10] Faltstrom, P. and R. Austein, "Design Choices When Expanding DNS", draft-iab-dns-choices-00 (work in progress), October 2004. [11] Brisco, T., "DNS Support for Load Balancing", RFC 1794, April 1995. [12] Kim, P. and S. Park, "DHCP Option for Configuring IPv6-in-IPv4 Tunnels", draft-daniel-dhc-ipv6in4-opt-05 (work in progress), October 2004. [13] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999. [14] Zhao, W., Schulzrinne, H., Guttman, E., Bisdikian, C. and W. Jerome, "Remote Service Discovery in the Service Location Protocol (SLP) via DNS SRV", RFC 3832, 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 Palet, et al. Expires April 24, 2005 [Page 14] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms October 2004 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 Pekka Savola CSC/FUNET Espoo Finland EMail: psavola@funet.fi Palet, et al. Expires April 24, 2005 [Page 15] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms October 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, et al. Expires April 24, 2005 [Page 16]