One document matched: draft-durand-ngtrans-tunnel-endpoint-00.txt

INTERNET-DRAFT                                   Alain Durand,       SUN
NGTRANS WG
July 2000






                 Storing tunnel endpoint in the DNS

           <draft-durand-ngtrans-tunnel-endpoint-00.txt>


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.


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.