Internet Engineering Task Force J. Palet Internet-Draft M. Diaz Expires: July 23, 2005 Consulintel P. Savola CSC/FUNET January 19, 2005 Analysis of IPv6 Tunnel End-point Discovery Mechanisms draft-palet-v6ops-tun-auto-disc-03.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 July 23, 2005. Copyright Notice Copyright (C) The Internet Society (2005). 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 Palet, et al. Expires July 23, 2005 [Page 1] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms January 2005 discovering the IPv6 tunnel endpoint on a node. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Scenarios for Tunnel Endpoint Discovery . . . . . . . . . . . 4 2.1 Scenario 1: ISP not offering any IPv6 support . . . . . . 4 2.2 Scenario 2: Initial IPv6 Support from External ISP . . . . 4 2.3 Scenario 3: Initial IPv6 Deployment Stage . . . . . . . . 4 2.4 Scenario 4: Advanced IPv6 Deployment Stage . . . . . . . . 5 2.5 Scenario 5: Nomadic Users . . . . . . . . . . . . . . . . 5 3. Network Attachment Models . . . . . . . . . . . . . . . . . . 7 3.1 Direct attachment to the ISP domain . . . . . . . . . . . 7 3.2 Indirect attachment to the ISP domain . . . . . . . . . . 7 4. Analysis of Solutions . . . . . . . . . . . . . . . . . . . . 9 4.1 Manual Configuration . . . . . . . . . . . . . . . . . . . 9 4.2 Shared-unicast-based Solutions . . . . . . . . . . . . . . 9 4.3 Centralized Broker-based Solutions . . . . . . . . . . . . 9 4.4 DNS-based Solutions . . . . . . . . . . . . . . . . . . . 10 4.5 DHCP-based Solutions . . . . . . . . . . . . . . . . . . . 20 4.6 PPP-based Solutions . . . . . . . . . . . . . . . . . . . 21 4.7 SLP-based Solutions . . . . . . . . . . . . . . . . . . . 21 4.8 Combined Solutions . . . . . . . . . . . . . . . . . . . . 23 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 24 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 9. Informative References . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30 Intellectual Property and Copyright Statements . . . . . . . . 32 Palet, et al. Expires July 23, 2005 [Page 2] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms January 2005 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. Palet, et al. Expires July 23, 2005 [Page 3] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms January 2005 2. Scenarios for Tunnel Endpoint Discovery From the point of view of the user and ISP, at least five scenarios can be identified where tunnel endpoint discovery would be useful in order to facilitate the IPv6 service deployment. 2.1 Scenario 1: ISP not offering any IPv6 support This is indeed the most often scenario currently. There are thousands of ISPs, and many certainly won't be supporting IPv6 any near time soon, neither natively nor via any transition mechanism. No resources are expected to be deployed on the ISP’s network. Even under these circumstances the discovery mechanism should work in order to let users’ applications and/or devices to obtain IPv6 connectivity automatically. Mechanisms such as 6to4, Teredo or free Tunnel Brokers are examples of how some mechanism can work in this scenario. 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, often free of charge. The discovery process could either detect the closest serving end-point, or pick the one manually configured by the user. 2.2 Scenario 2: Initial IPv6 Support from External ISP In this scenario ISP might offer IPv6 support to their customers by means of third parties. In this way only minimal resources would be deployed in its domain, basically configuration of a few existing resources (DNS servers, DHCP servers, PPP servers, others). Usually the IPv6 service offered by the third party is for free, or arranged via roaming-like agreements between ISPs and third parties. In this scenario, the users (in general their operating systems) would be redirected to the third-party ISP probably by using its own ISP facilities. 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: 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 Palet, et al. Expires July 23, 2005 [Page 4] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms January 2005 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. However on initial IPv6 deployment stage, it is not considered as a key issue, so addressing this consideration is not a priority. Nevertheless the discovery method could allow for multiple end-points within a domain or even include a load-balancing mechanism. 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. 2.5 Scenario 5: Nomadic Users Nomadic users require connectivity to Internet from everywhere, from different locations: meetings, conferences, holidays, etc. Under Palet, et al. Expires July 23, 2005 [Page 5] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms January 2005 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. Connecting to a "home ISP" to obtain a tunnel is typically a safe choice, provided that the "home ISP" allows IPv4 addresses outside its own domain to use its tunnel services. However, specially when traveling to different regions, due to packet loss and higher latencies, it may be an undesirable choice, and may be only a backup option in case other approaches fail. A local tunnel is typically a preferable choice, and could also be used as a Mobile IPv6 [7] care-of address, provided that the local ISP is providing a tunnel service. 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. If authentication with the local ISP is required (i.e., IPv6 service not for free) it would be desirable roaming agreements between the home and the local ISP, in order to facilitate the users' applications to use the same configuration data on the local ISP as they were doing in the home one. Furthermore, 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 July 23, 2005 [Page 6] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms January 2005 3. Network Attachment Models In order to facilitate the analysis of the different possible solutions, is important to realize how the users are attached, to the network, from the point of view of using a bridge or a router, which in general defines how the DNS service is provided. At least two generic models can be depicted. 3.1 Direct attachment to the ISP domain This model represents the case of users directly attached to the ISP network, so there are no intermediate devices other than CPEs working as bridges. Typical examples are home-users connected by means of dial-up connections (not only based on traditional PSTN, but also ISTD, 3GPP, etc.), xDSL/PLC/cable-modem (CPE working in bridge mode, not as router). The key element that identifies this model is that the customer belongs to the ISP domain because there is no any DNS server on the customer side other than the one provided by the ISP during the handshake connection period (typically PPP). Usually these connections are based on public IPv4 address so no NAT boxes can be found. 3.2 Indirect attachment to the ISP domain This model represents the case where a DNS server different to the one provided by the ISP is available on the user network. Depending on the particular network, connections can be based on public or private IPv4 addresses. The later means that a NAT box is deployed to reach the global Internet. Furthermore, the most usual network auto-configuration method is DHCP which not only provides the network address to the network devices but also the domain name and the DNS server address. Under theses circumstances, the user network can be assumed to belong to a domain space other than the ISP one. a) This is the typical situation for users connected on SOHO networks, hot-spots, corporate or campus networks, etc. In this case the access technology used to get connected is based on 802.xx standards (including wireless). In these situations there is usually a kind of network administrator or minimalistic management taking care of the DNS configuration. b) Home-users can be also categorized into this model in case of using xDSL (or other technologies) as the access network Palet, et al. Expires July 23, 2005 [Page 7] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms January 2005 technology and its CPE is working as a router (one interface is the upstream to the ISP network and the other ones are either 802.3, 802.11 or others). In this case a typical configuration (default configuration in most of these equipments) is the router working also as DNS server. Often the default domain provided by the DNS server (default factory configuration) is only a generic wording like "home" or "lan", so it becomes a non-real domain. Palet, et al. Expires July 23, 2005 [Page 8] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms January 2005 4. Analysis of Solutions Several possible solutions to discovering the tunnel end-point can be imagined; this section describes them in detail. 4.1 Manual Configuration Manual configuration is usually done by knowledgeable users that know where the tunnel end-point is located. Because the configuration is manual, no especial barriers on the network can be found, so this is a solution that fit in all the models enounced on section 3. The TEP discovery can be done by several ways: - users ask on specialized forums - ISP provides such information by off-line mean - ISP rolls out CD-ROMs or similar material to the (non-knowledgeable) users which will automatically reset the network connectivity settings to the values used by the ISP Advantages: - The main advantage is that this method works always, prove that the TEP server is up and running. Drawbacks: - It is not automatic at all - It requires that users have knowledge about what they are doing - It does not provide usually the nearest TEP, except the ISP is providing such information - Many deployments are expected to happen at pre-production stage, and those service providers would not yet be ready to integrate the configuration in their CD-ROM etc. material - The CD-ROM materials have mainly been targeted to the users who set up their (IPv4) connectivity which either requires software or out-of-band configuration. There is no reason to require out-of-band configuration if the discovery could be done in a feasible manner. - The resources pointed by the CD-ROM material can be changed nor moved because this means that information provided to the users would have to be updated with new CD-ROM material. - The cost of rolling out CD-ROM material can be high and it can be avoided by using automatic discovery methods. 4.2 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. Palet, et al. Expires July 23, 2005 [Page 9] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms January 2005 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. Global "anycast" might be best applicable in scenarios 1 and 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. Advantages: - It works well also in the presence of NATs and does not require any other components like DNS or DHCP, so it fits well on all the network-attachment models enounced on section 3. - It can be a global solution for TEP discovery all over the world. Drawbacks: - Setting up an internal anycast route advertisement (e.g., in an enterprise) is likely a little bit more difficult than adding a name in the DNS or configuring DHCP. - The use of non-local prefixes may require changes in firewall IP prefix, access lists, etc. - The failure modes are a bit more complex than, e.g., just looking up a domain name, as one will have to send 1-2 packets to the anycast address to see if a working tunnel server is found or not. 4.2.1 Different approaches using anycast address Anycast solution has as main advantage that it fits on all the network-attachment models enounced on section 3, but at this point, several ways to use anycast solution can be listed; some of them can be even combined to implement a particular solution: a) Anycast for the whole communications. This means that anycast address/prefix is used not only for discovery purpose but also during the whole communication process. It is the model that 6to4 uses with 192.88.99.1 anycast address. Advantages: - It simplify the TEP deployment because no handshake is required Palet, et al. Expires July 23, 2005 [Page 10] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms January 2005 Drawbacks: This model presents some operational issues that might hinder the normal TCP communication procedure like the followings: - changes on BGP routes that deliver packets belonging to a TCP communication on a different server where the TCP communication were stablished. - delivery of packets to more than one TEP server. b) Anycast only for the initial handshake. The goal is to establish communication with a stable unicast address of the end-point and to perform some initial negotiation with it (an example of such is described in [9]). The handshake could include the delivery of the TEP unicast address, user-authentication, kind of transition mechanism implemented on the TEP, etc. Advantages: - It simplifies the management of anycast address because only one is used. - It is more versatile because it is based on the use of a centralized server (the one that has the anycast address) that can implement many functions Drawbacks: - It requires the initial handshake that has to be defined and standardized in order to be used broadly. c) One anycast address for each transition mechanism. By using one anycast address for each specific TEP, that is one address for 6to4, other for teredo, etc. it simplifies the deployment of TEPs and the discovery process. Applications only have to use the address defined for every TEP to contact it. Advantages: - No handshake is needed to establish communication with a TEP Drawbacks: - Having many anycast addresses might become hard to manage. - The use of hard code for anycast address on implementations it is not a good solution for durable solutions d) One Anycast address for all the transition mechanisms. This approach means that all the transition mechanism based on TEP share the same anycast address, so it is required the initial handshake to find out the kind of TEP that is supported by a server. Advantages: - It simplifies the management of anycast addresses because only one is defined Drawbacks: - It requires the initial handshake that has to be defined and standardized in order to be used broadly. Palet, et al. Expires July 23, 2005 [Page 11] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms January 2005 e) Local anycast address. The scope of anycast address is other factor that has to be taken into account when deploying an anycast-based solution. The first choice is to be only defined within the ISP domain, so anycast address/prefix is not populated when exporting routes on other AS. Only users attached to the ISP network can benefit of the anycast address. Advantages: - It simplifies the address/routes management Drawbacks: - It is not a global solution, so users attached to ISP without TEP infrastructure will never know that their neighbour ISP has anycast TEPs. f) Global anycast address. This is the opposite choice. The anycast address/prefix is exported beyond the ISP AS. Advantages: - It is a real global solution that discover the nearest TEP Drawbacks: - The anycast address needs to be standardized to be globally used and populated by ISPs. - Issues with anycast routes will block the service and many users can be affected. 4.3 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, Palet, et al. Expires July 23, 2005 [Page 12] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms January 2005 agreements between several domains could make possible sophisticated models. In summary, the main drawbacks of this solution are: 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. 4.4 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 two ways for using DNS on this regard: forward path-tree and reverse path-tree. 4.4.1 Forward path-tree There are roughly three kinds of different approaches with forward DNS-based discovery: 1. "global name": the systems look up a globally unique name, like www.tunnel-server.net.; this could be applicable with global inter-domain broker or anycast-based solutions. As main advantage, one might consider that this is a simple solution, however some drawbacks need to be considered: * In order to make a global discovery service, one domain name for each transition mechanism should be standardized, i.e., www.tunnel-server.net, www.teredo.net, www.6to4.net, and so forth. * Who will be in charge of maintaining the global domain? May be this is the most important drawback. Palet, et al. Expires July 23, 2005 [Page 13] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms January 2005 * This solution by itself is not able to provide the nearest TEP related to the user location. It requires some additional mechanism used in combination with DNS to provide the nearest one. + DNS+BGP routes analysis to provide the nearest TEP according to the IP address of the users looking up for the service. + DNS+Anycast address. This seems a more realistic solution although it continues presenting the drawbacks already indicated along with the ones for "shared-anycast solution". 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. As main advantage we can mention that this is a feasible solution because the control of the domain is done by an already identified vendor, although there are still some drawbacks: * In order to have a globally available discovery service, the DNS query would need to be formed by appending one standardized label representing the desired TEP to the vendor domain name: 6to4.windows.microsoft.com, 6to4.cisco.com, etc. * This is typically only feasible to configure a global anycast address, or provide the address of the vendor's own service, with the drawback already indicated. * This solution will result in very biased implementations since each Operating System, hardware manufacturer, etc., will only lookup for its own TEPs. As a consequence, the resulting load balancing could be very poor. Furthermore, the discovered TEP could not be the nearest one. 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 query of "_tunnel-server.isp.example.com". This assumes that the DNS search path is provided by the ISP, and used by the user. The special string could be more complex and make reference somehow to the transition mechanism that it will accept, i.e., 6to4_tunnel-server, 6in4_tunnel-server, teredo_tunnel-server, any_tunnel-server, and so on. All these approaches are typically coupled with a manual override option, which can be used by knowledgeable users to lookup for different names or even to specify an IP address. Prefixing the search path is the most interesting approach and it is worth to be explored at more length below. Palet, et al. Expires July 23, 2005 [Page 14] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms January 2005 4.4.1.1 Prefixing the DNS Search Path Prefixing the search path bears a bit more analysis. There are 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). The question of where to store the information is in principle resolved by means of the organization DNS server which is deploying the TEP infrastructure. The most general case is the ISP DNS servers because it is expected that they are going to start the IPv6 deployment by using any kind of transition mechanism, until the access network can be upgraded to support native IPv6 access. However it might also happen that other organizations would offer IPv6 service by deploying its own TEP infrastructure on its own domain. The most important point is that the information propagated to the end nodes in the "DNS search path" is relevant to figure out the domain name of the whoever is providing the tunnel service. Regarding the question of how to store the information, there are at least four concrete possibilities: 4.4.1.1.1 A/AAAA/CNAME RRs As described in [11], one could use just the regular records for storing the end-point address or name. Records will be formed by adding the prefix related to each transition mechanism to the domain name, for example, assuming the domain name "isp.example.com", records would result in "6in4.isp.example.com", "6to4.isp.example.com", etc. Advantages: o It is extremely simple to implement and use. Applications can use simple getaddrinfo()lookups. o It offers always the nearest TEP (in terms of node hops) assuming the following: * Model 3.1: TEPs are deployed within the ISP domain so they will always be the nearest one. * Model 3.2 a): It is assumed that the DNS administrator has knowledge of the nearest TEP and consequently he has properly configured the DNS server. o It offers basic load balancing by means of DNS round-robin techniques [12]. Palet, et al. Expires July 23, 2005 [Page 15] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms January 2005 o This method could be used by users that are away from their home network. o By using wildcards and CNAME RRs it could be possible to extract a list of all the TEPs deployed by the organization. Drawbacks: o It requires the standardization of the prefix needed to build the lookup in order to allow all the ISPs (or organizations deploying its own TEP infrastructure) to use the same prefix. o It is necessary first to find out the domain name, which requires that the user belongs to the domain of the ISP (or organization) deploying the TEP infrastructure: Will not be a problem for model 3.1 and 3.2 a) because the domain name can be easily recovered by means of DHCP, PPP, etc. The only requirement is that the domain DNS server is configured properly to provide the TEP information. Could be a problem for model 3.2 a) in case the organization that has its own domain does not know anything about the TEP even if its ISP is offering such a service. The problem is due to the DNS queries being built from the domain name where the users is attached to, but in this case queries should be made to the ISP domain name because it is the organization which provides the service. The user terminal needs first to discover the ISP domain name, as this is the entity that actually is providing the service. This could be done by: 1. To find out the public IP. 2. Reverse path-tree lookup with PTR RR to extract the domain from the reply although there is no guarantee at all that the previous one it always works. Model 3.2 b) is equivalent to the previous one, so same considerations apply. o Using a commonly defined name as a service identifier (i.e. "6in4.isp.example.com") would likely lead to false positives. However it is easily avoidable by appending special characters like '_' or '-' in the prefix, resulting in RRs like "tunnel-server", "_teredo", "isatap_", etc., so it would be quite improbable that conflicts would appear in practice. It is also worth to remind that the result of a false postive (i.e., getting and address which is not a valid TEP) is not necessarily a huge problem because it is only an indicator that such service did not exist in the domain, as long as the tunneling mechanism can recover from that situation. Palet, et al. Expires July 23, 2005 [Page 16] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms January 2005 o Another inconvenient is the deployment of wildcard DNS records. If A/AAAA records were to be used, such records might create false positives quite easily. Indeed this is an improbable issue since in practice wildcards are commonly deployed only for MX records. o It does not map the physical topology. 4.4.1.1.2 SRV RR As described in [11], 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. It is a good candidate considering the advantages that this solution offers. Advantages The following advantages can be added to those already listed in the "A/AAAA/CNAME" case: o Use an additional level in the zones, such as "_tunnel-server_udp.isp.example.com", which would prevent a wildcard record "*.isp.example.com" from harassing the discovery of the end-point. o It offers better load balancing. o In case the ISP has not yet deployed any TEP infrastructure, it is assumed that the DNS administrator has knowledge regarding the nearest TEPs (third parties) and then configures the DNS server properly. Consequently the scenario 2 can be easily implemented. Drawbacks The following inconvenient can be added to the need of finding out the domain name of the organization providing the TEP infrastructure: o SRV records require slightly more implementation and possibly more round-trips, (if the results aren't cached). 4.4.1.1.3 NAPTR RR NAPTR records provide even more flexibility than SRV records because each ISP can reference its own TEPs with different names, so no standardized labels would be required. The idea behind this concept is that each application implementation can use different words/strings (not necessarily standardized) to discover the TEP that is looking for, i.e. tep, tunnel, transition-mechanism, tb, tunnel-broker, ipv6, 6in4, isatap, teredo, etc. Palet, et al. Expires July 23, 2005 [Page 17] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms January 2005 With the proper rule configuration on the ISP DNS servers, the different nodes providing such a service are delivered. For example, on the isp.com domain, the following NAPTR records might be configured: isp.com. ;; order pref flags service regexp replacement IN NAPTR 100 10 "a" "6in4" "!^.*tep\.(.*)$!tep1.isp.com!i" . IN NAPTR 100 20 "a" "6to4" "!^.*tep\.(.*)$!tep2.isp.com!i" . IN NAPTR 100 30 "a" "teredo" "!^.*tep\.(.*)$!tep3.isp.com!i" . IN NAPTR 100 40 "a" "isatap" "!^.*tep\.(.*)$!tep4.isp.com!i" . IN NAPTR 100 10 "a" "6in4" "!^.*tb\.(.*)$!tep1.isp.com!i" . IN NAPTR 110 10 "a" "6to4" "!^.*6to4\.(.*)$!tep2.isp.com!i" . IN NAPTR 120 10 "a" "teredo" "!^.*teredo\.(.*)$!tep3.isp.com!i" . IN NAPTR 130 10 "a" "isatap" "!^.*tep\.(.*)$!tep4.isp.com!i" . One application implementation might use the string "tep" to perform the query tep.isp.com to look for all the possible TEPs, while another application might use the string "tb" to look for tunnel-brokers on the same ISP network, etc. The above rules (NAPTR records) applied to the query tep.isp.com will result in a list of different TEPs: tep1.isp.com tep2.isp.com tep3.isp.com tep4.isp.com which the application would have to choose one of them according to the service field information. On the other hand, the above rules (NAPTR records) applied to the query tb.isp.com will result only in tep1.isp.com. Finally, the application would perform the last A/CNAME query according to the resulting node name (tep1.isp.com, tep2.isp.com, etc.). Advantages: o It could be used to implement the scenario 2. Palet, et al. Expires July 23, 2005 [Page 18] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms January 2005 o With the proper rules on the DNS server and by doing simple queries like "teb.isp.example.com", it could be used to discover all the kinds of TEPs (tunnel broker, 6to4, isatap, teredo, etc.) deployed into the domain as well as other domains. Drawbacks In addition to the need of finding out the domain name, the following problems can be enumerated: o Applications have to write their own DNS lookup function that correctly interpret the meaning of the NAPTR rule. o It requires even more implementation and more round-trips. o There is very few support for NAPTR records on both DNS servers and DNS resolvers. o It is too complex and rules badly configured will avoid the discovery service to work. o It does not perform load-balancing. 4.4.1.1.4 New RR A new RR could also be defined to specifically reference the type of node as TEP, but there seems to be no particular reason to do so, and a lot of drawbacks in the process like standardization, etc. 4.4.2 Reverse path-tree Reverse DNS is an interesting focus that opens new possibilities in the discovery process. With it one could build the query with the IP address that the user's terminal has and the DNS replies with the available services that the IP address has configured. This applied to the TEP discovery means that the user (rather its operating system, application, etc.), queries the DNS and it returns all the TEPs available for such an address, usually with the name referencing somehow the type of transition mechanism, i.e. teredo.isp.example.com, 6to4.isp.example.com, etc. The question of what returned RR will be taken would be resolved by the application or operating system and the resulting TEP is contacted after a second DNS query to resolve the name provided by the first query. Advantages: o It does not require standardized labels for each transition mechanism (which not necessarily will be considered as an advantage for everybody). o It provides easily all the transition mechanisms available. Palet, et al. Expires July 23, 2005 [Page 19] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms January 2005 Drawbacks: o It could not work properly if private address space is used. Partial solution could be faced for some of the modes, but not for others: * Model 3.1: The DNS administrator could include the private address space into the reverse zone. Alternatively the user's applications could find out the public IP address and then query for it instead for the private one. * Model 3.2 a): If the organization which the user is attached to is deploying the TEP infrastructure, it is assumed that will do the proper DNS configuration, so there is no difference with the previous case. However, if the organization is not deploying the TEP infrastructure and the DNS server is configured to do the reverse resolution for other services, this represents a severe issue because no TEP information will be provided to the users in spite of ISP has its own TEP infrastructure. * Model 3.2 b): The CPEs working as DNS server by default often does not get configured by users with reverse resolution. However, they reply to PTR records in case the IP address queried is present on the network, so in this case the inconvenient already indicated in the previous case is also present here. The only solution is to disable the DNS server capability of the CPE. o It is a must that the user is attached to the network of the organization (ISP or other) offering the TEP service. o It might be difficult to manage the DNS zone files in case of big domains, because the high number of entries on it. This might be partially solved using any kind of automatic application, scripts, or by using wildcards if no other QTYPE RR is on the zone because wildcars are QTYPE-agnostic. o It only provides a basic load-balancing based on round-robing techniques. o In case the ISP has a fragmented address space, that is, not a complete single range of addresses belonging to the same /x prefix, which often is the case, it means extra work for configuration, because the use of wildcards is more difficult, and is necessary to add the records for every address space fragment. As in the case of forward DNS, there are several ways to store the information. Palet, et al. Expires July 23, 2005 [Page 20] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms January 2005 4.4.2.1 PTR RR This is the most usual way to store reverse DNS information. With this approach, there would be one PTR per each TEP deployed and per each IP address, i.e.: 141.48.172.213.in-addr.arpa IN PTR teredo.isp.example.com. 141.48.172.213.in-addr.arpa IN PTR 6to4.isp.example.com. 141.48.172.213.in-addr.arpa IN PTR isatap.isp.example.com. Advantages: o There are no any special advantages. Drawbacks: o Besides the drawbacks already indicated, it might arise possible problems if other services requiring reverse resolution (like e-mail) are used on the IP address that forms the query. 4.4.2.2 SRV RR By using SRV queries in the reverse path tree one could refine the search in the sense that only TEPs using a specific protocol are resolved. For example, entires for the address 213.172.48.141 in the in-addr.arpa zone file could be as follows: 141._ipv4 IN SRV 0 1 9 6to4.isp.example.com. 141._ipv4 IN SRV 0 3 9 6in4.isp.example.com. 141._udp IN SRV 0 2 9 teredo.isp.example.com. 141._udp IN SRV 0 1 9 ayiya.isp.example.com. And a query asking for TEPs based on IPv4 would result in 6to4.isp.example.com and 6in4.isp.example.com, whereas a query asking for TEPs based on UDP would result in teredo.isp.example.com and ayiya.isp.example.com. Advantages: o It would be faster since there would be a few answers to a specific query. o Better load balancing since the implicit properties of SRV RR. o Given the fact that SRV RRs are different from PTR, the approach does not interfere with traditional applications that use reverse resolution, such as e-mail. Drawbacks: o No additional issues. Palet, et al. Expires July 23, 2005 [Page 21] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms January 2005 4.4.2.3 NAPTR RR This approach, as described in [13], presents more flexibility for refining the search. The idea is to have a NAPTR record on each address, tied to each supported TEP, in the same way as the PTR RR above. User applications choose the reply according to the information provided in the "service" field, which is bound to each transition mechanism, i.e., isatap, teredo, etc. In addition to the considerations already done for reverse path-tree, NAPTR has the following advantages and dawbacks. Advantages: o It does interfere with other applications using the PTR RR for reverse resolution. o It matches nicely the underlying topology. Drawbacks: o NAPTR record is badly supported both on DNS servers and DNS resolvers. o It requires standardized names for the service field. 4.4.2.4 New RR A new RR could also be defined to specifically reference the type of node as TEP, but there seems to be no particular reason to do so, and a lot of drawbacks in the process like standardization, etc. 4.5 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 [14]. This approach has several drawbacks: o It requires standardizing new parameters/options on this protocol and also upgrading the DHCP client/server implementations to support this feature. o It is restricted to the local ISP or organization providing the TEP infrastructure, so is only applicable to models 3.2 a) and 3.2 b). 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 Palet, et al. Expires July 23, 2005 [Page 22] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms January 2005 especially in many dial-up scenarios (model 3.1), 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 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. 4.6 PPP-based Solutions In the case of PPP-like connections (model 3.1), 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. 4.7 SLP-based Solutions The Service Location Protocol [15] 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: service:tep:6to4://6to4.domainexample.net service:tep:6in4://6in4.domainexample.net 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 Palet, et al. Expires July 23, 2005 [Page 23] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms January 2005 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 3, where users willing to get IPv6 connectivity only contact to local providers (home ISP, LAN, etc.). However, SLP presents also other drawbacks to be taken into account: o 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. o If only SA is deployed, it requires multicast support for SA discovery. o 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 [15] but users connected to their ISP often utilize PPP instead, so DA discovery become an issue. o It requires the implementation of an UA on the client's host. This is neither always possible nor feasible. o It can not offer any kind of load-balancing if more than one TEP is deployed. o It only announces TEPs belonging to the ISP scope, so it would not be possible to announce TEP deployed in third party networks. 4.7.1 Remote Service Discovery through SLP-based Solutions Remote service discovery through SLP [16] refers to discovering desired services in remote domains. By using [16], 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 3 and scenario 5, however it still has most of the SLP drawbacks, particularly previous items 1, 4, 5 and 6. Palet, et al. Expires July 23, 2005 [Page 24] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms January 2005 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 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. 4.8 Combined Solutions Several combinations are possible: reverse-forward DNS, different kinds of DNS records, etc., so only possibilities that have a particular interest are explored deeper. Combined forward DNS path-tree by using NAPTR to discover possible kinds of TEPs within the ISP network and then SRV lookups to do advanced load-balancing can be useful to avoid the need of standardizing labels for the different kinds of TEPs. However it presents as main drawback more resolution time (too many lookups), while the standardization of the labels could be an advantange, in order to make uniform the deployment across different networks. 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. Palet, et al. Expires July 23, 2005 [Page 25] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms January 2005 5. Conclusions Manual configuration is the most used method until now, but it is not suitable to make large deployments because it means that users has to have technical knowledge or it is only valid for local scopes if ISP provide information by CD-ROM material about their own TEPs. However it is a solution that can be adopted by implementations to be used if automatic discovery methods fail. DNS appears to be the simplest means to achieve end-point discovery and can be applied to all the scenarios. DHCP and PPP have drawbacks and due to attachment models restrictions, can not be applied to all the scenarios Inter-domain anycast model appears to be a good solution but it has practical issues with route propagation that prevent it to work in all the ISPs. However local anycast techniques using a shared-unicast address (or addresses) appears to be the most practical mean for redundancy and load-balancing. Anycast can also be used for the unicast address discovery. Regarding the DNS, two strategies are possible: reverse and forward resolution. Forward resolution presents resolvable problems if the user is not attached to the same domain that the organization providing the TEP infrastructure. Furthermore, it requires the standardization of the label to be used as prefix representing each kind of TEP (which can be convenient in order to make a uniform deployment). The information could be stored either in A/AAAA/CNAME, SRV or NAPTR records, being the SRV solution the one that seems to present better tradeoffs in terms of support on DNS servers, easy usage and advanced features such as load-balancing. Reverse resolution is appropriate if the standardization of the label bound to the TEP is considered as not desireable. However, it present severe problems in cases where private address space is used and/or the organization which the user is attached to has delegated its own reverse path-tree but the TEP infrastructure is provided by other organizations or ISPs. Finally other solutions such as SLD does not seem to fit properly with the TEP discovery requirements due to their strong drawbacks. The following table summarizes the different approaches versus the network attachment model, and the pros/cons presented in this memo. Palet, et al. Expires July 23, 2005 [Page 26] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms January 2005 +-----------------+---------+---------+---------+---------+---------+ | | Model | Model | Model | Pros | Cons | | | 3.1 | 3.2 a) | 3.2 b) | | | +-----------------+---------+---------+---------+---------+---------+ | Manual | Yes | Yes | Yes | * | *** | | | | | | | | | Anycast | Yes | Yes | Yes | *** | ** | | | | | | | | | Centralized | Yes | Yes | Yes | * | *** | | Broker | | | | | | | | | | | | | | Forward DNS | Yes | Yes | Yes | *** | ** | | Global Name | | | | | | | | | | | | | | F. DNS Vendor | Yes | Yes | Yes | * | *** | | Name | | | | | | | | | | | | | | F. DNS | Yes | No (1) | No (2) | ** | * | | Prefixing | | | | | | | A/AAAA/CNAME | | | | | | | | | | | | | | F. DNS | Yes | No (1) | No (2) | *** | * | | Prefixing SRV | | | | | | | RR | | | | | | | | | | | | | | F. DNS | Yes | No (1) | No (2) | * | *** | | Prefixing NAPTR | | | | | | | RR | | | | | | | | | | | | | | Reverse DNS PTR | Yes (3) | No (4) | No (5) | ** | ** | | RR | | | | | | | | | | | | | | Reverse DNS SRV | Yes (3) | No (4) | No (6) | ** | ** | | RR | | | | | | | | | | | | | | Reverse DNS | Yes (3) | No (4) | No (6) | ** | *** | | NAPTR RR | | | | | | | | | | | | | | DHCP | No | Yes | Yes | ** | *** | | | | | | | | | PPP | Yes | No | No | ** | ** | | | | | | | | | SLP | Yes | Yes | Yes | * | *** | +-----------------+---------+---------+---------+---------+---------+ Notes: 1. It does work in the case that the network to which the user is attached to (which is different than the ISP) would have its own TEP infracstructure. Palet, et al. Expires July 23, 2005 [Page 27] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms January 2005 2. It does work if the ISP domain name is recovered by any means. Possible ways have been described in the corresponding section. 3. It could not work if private address space is used. 4. It could not work if private address space is used. Furthermore it does not work if the organization which the user is attached to has not its own TEP infrastructure and it has delegated its own reverse path-tree. 5. It does not work because the CPE working as DNS server always reply with its own name when querying about the public IP address. 6. It requires manual configuration by the user, which it is not desired as main goal of the automatic discovery procedure. Qualification of pros/cons: * : Few ** : Medium *** : High Palet, et al. Expires July 23, 2005 [Page 28] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms January 2005 6. 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 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. Palet, et al. Expires July 23, 2005 [Page 29] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms January 2005 7. IANA Considerations This document requests no action for IANA. [[note to RFC-editor: this section can be removed upon publication.]] Palet, et al. Expires July 23, 2005 [Page 30] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms January 2005 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 inputs from Carl Williams, Brian Carpenter, Jeroen Massar, Alain Durand, Tim Chown, and Florent Parent. This work has been partially funded by the European Commission under the Euro6IX project. 9. Informative References [1] Parent, F., "Goals for Registered Assisted Tunneling", Internet-Draft draft-ietf-v6ops-assisted-tunneling-requirements-01 , 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", Internet-Draft draft-huitema-v6ops-teredo-04, January 2005. [6] Templin, F., Gleeson, T., Talwar, M. and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", Internet-Draft draft-ietf-ngtrans-isatap-23, December 2004. [7] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [8] Hagino, J. and K. Ettican, "An analysis of IPv6 anycast", Internet-Draft draft-ietf-ipngwg-ipv6-anycast-analysis-02, June 2003. [9] Thaler, D. and L. Vicisano, "IPv4 Automatic Multicast Without Explicit Tunnels (AMT)", Internet-Draft draft-ietf-mboned-auto-multicast-03, October 2004. [10] Faltstrom, P. and R. Austein, "Design Choices When Expanding DNS", Internet-Draft draft-iab-dns-choices-00, October 2004. [11] Palet, J., "IPv6 Tunnel End-point Automatic Discovery Palet, et al. Expires July 23, 2005 [Page 31] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms January 2005 Mechanism", Internet-Draft draft-palet-v6ops-solution-tun-auto-disc-01, October 2004. [12] Brisco, T., "DNS Support for Load Balancing", RFC 1794, April 1995. [13] Durand, A. and S. Yamamoto, "Service Discovery using NAPTR records in DNS", Internet-Draft draft-yamamoto-naptr-service-discovery-00, October 2004. [14] Kim, P. and S. Park, "DHCP Option for Configuring IPv6-in-IPv4 Tunnels", Internet-Draft draft-daniel-dhc-ipv6in4-opt-05, October 2004. [15] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999. [16] 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 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, et al. Expires July 23, 2005 [Page 32] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms January 2005 Pekka Savola CSC/FUNET Espoo Finland Email: psavola@funet.fi Palet, et al. Expires July 23, 2005 [Page 33] Internet-Draft Analysis of Tunnel End-point Discovery Mechanisms January 2005 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 (2005). 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 July 23, 2005 [Page 34]