INTERNET-DRAFT Alain Durand, SUN NGTRANS WG November 2000 Storing tunnel endpoint in the DNS Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Distribution of this memo is unlimited. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. 1. Introduction Tunnels in various forms (IPv6 in IPv4, IPv4 in IPv6,...) are key elements in many IPv6 transition scenarios. Tunnels can be either dynamically managed or manually configured. In this later case, managing tunnel endpoint is critical. This document describe a simple mechanism to store and retrieve those endpoint in the DNS. The 6to4 mechanism depend on the discovery of 6to4 gateways. The author suggests to use the mechanism describe below to address this problem. 6to4 gateways could be considered as tunnel end-points serving a prefix, a set of prefixes, or the entire IPv6 address space. 2. Architecture This proposal is architectured around several pieces: - a dedicated tree in the reverse path DNS: TEP.arpa. - DNAME delegations - wildcard PTR records - a query mechanism - a caching mechanism Tunnels are viewed as access links to a network. They are associated with the prefix and prefix length of the network they are 'serving'. Note that, in IPv6, this prefix length is in the range [0..128], where 0 can be associated with the global Internet and 128 being a tunnel to a single host. In IPv4 the prefix length is in the range [0..32]. Tunnel endpoint are stored in a pseudo reverse path DNS tree within PTR records. Those records contains fully qualified donain names. To get the actual IP address of the tunnel endpoint (IPv4 or IPv6) a second DNS query of the relevant type (A or A6) must be issued. 2.1 DNAME delegation TEP.arpa. represent a pseudo-root. DNAME degegations are made from the this pseudo-root to the site/domain where the tunnel endpoint belongs to. Those delegations should follow address space delegation. The right hand side of the DNAME delegations MUST be composed of the folowing labels: - a numeric label - the label TEP - any other valid DNS labels - a DNS domain name. The numeric label is the length of the prefix delegated so far in decimal format. 2.2 Wildcard PTR The pseudo reverse tree does not need to be completely populated up to the last bit of all the IP addresses the tunnel is responsible for. Wildcard entries can be used to match a complete prefix. 2.3 Query mechanism When a client want to retrieve the tunnel endpoint associated with either a host or a network, it issues a PTR query to the DNS in the pseudo-root TEP.arpa for the IP address of the host or the prefix of the network. In this later case, it MUST pad the network prefix with the corresponding number of zero. 2.4 caching mechanism Clients issuing DNS request to get the tunnel end-point associated with a particular IP address MAY cache some information so that a subsequent query for another IP address within the same network will not be necessary. However, the client has no way to know a priori if 2 IP addresses are part of the same network. Thus, the answer from the DNS includes a hint which is the prefix length of the prefix the tunnel is in charge of. This hint is located left to the TEP label in the left hand side of the DNS reply. 3. Tunnel endpoint example In this example, the network associated with the prefix 3ffe:FED0::/24 is served by the tunnel endpoint 1.2.3.4. The delegations are as followed. The 6bone prexix is delegated by the pseudo root to the 6bone: \[x3ffe/16].TEP.arpa. IN DNAME 16.TEP.6bone.net. Then 12 mores bis are delegated to organization OrgX. \[xFED/12].16.TEP.6bone.net. IN DNAME 28.TEP.OrgX.org. Then a wildcard entry match the whole /28 prefix: *.28.TEP.OrgX.org. IN PTR tunnel.OrgX.org Additional data complete this set up: tunnel.OrgX.org IN A 1.2.3.4 4. DNS query example In this example, an external node is looking for a tunnel endpoint to reach host 3ffe:FED0:1:2::1. It issues a PTR query for: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2. 0.0.0.1.0.0.0.0.D.E.F.E.3.TEP.arpa. The response will be: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2. 0.0.0.1.0.0.0.0.28.TEP.OrgX.org. IN PTR tunnel.OrgX.org. tunnel.OrgX.org. IN A 1.2.3.4 By looking at the 28.TEP labels on the left hand side of the DNS response, the external node will know that the prefix length of the network this tunnel endpoint is in charge of is 28. Applying this result to the original IP address it was querying, it will conclude that the tunnel is actually in charge of the prefix 3ffe:fede0::/28. 5. Author's address Alain Durand SUN Microsystem, Inc. 901 San Antonio road UMPK17-202 PALO ALTO, CA 94303-4900 USA EMail: Alain.Durand@sun.com Tel: +1 650 786 7503 6. Security considerations This proposal simply uses DNS techniques to store and retrieve tunnel endpoints and thus does not have any security issues in itself. However, a client performing a DNS query MAY require to use DNS authentication techniques to validate the retrieved information.