draft-ietf-dnsext-ipv6-name-auto-reg-00.txt

bind-3.2.

INTERNET-DRAFT                                             H. Kitamura
<draft-ietf-dnsext-ipv6-name-auto-reg-00.txt>          NEC Corporation
Expires in six months                                  2 December 2002

        Domain Name Auto-Registration for Plugged-in IPv6 Nodes
             <draft-ietf-dnsext-ipv6-name-auto-reg-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.

Abstract

   This document describes a scheme of "Domain Name Auto-Registration
   for Plugged-in IPv6 Nodes" mechanism that makes it possible to
   register both regular and inverse domain name information of plugged-
   in IPv6 nodes to DNS servers automatically.

   Since IPv6 addresses are too long to remember and EUI64-based
   addresses are too complicated to remember, there are strong
   requirements to use logical names that are easy to remember instead
   of IPv6 addresses to specify IPv6 nodes and to register domain name
   information of plugged-in IPv6 nodes automatically.

   In order to meet the requirements, a mechanism is proposed as one of
   the IPv6 auto-configuration (plug and play) functions. After the
   Address Autoconfiguration [ADDR-AUTO] has been executed, it works as
   a succeeding plug and play mechanism.

   This document clarifies problems that we meet when we apply the
   Dynamic Updates in the DNS [DYN-DNS] to automatic domain name
   information registration mechanisms. This document describes the
   Domain Name Auto-Registration mechanism as a solution to these
   problems.



H. Kitamura                                                     [Page 1]

INTERNET-DRAFT        Domain Name Auto-Registration        December 2002


   The Domain Name Auto-Registration mechanism, in addition to its main
   functionality, provides two types of additional benefits.

   One is that IP address information that should be registered to the
   DNS is collected automatically. The mechanism can also be used under
   (non plug and play) manual configuration situations in a different
   manner from its main functionality. Under such situations, network
   administrators meet a problem that it is not easy to collect IP
   address information to register to the DNS. The mechanism solves it.

   The other is that a plugged-in IPv6 node can obtain its domain name
   information (FQDN and DNS zone suffix) without having new functions
   installed into it. By simply executing inverse DNS name resolving
   procedures with its IPv6 address argument, the plugged-in IPv6 node
   can obtain its FQDN and DNS zone suffix with ease.


1. Introduction

   This document describes a scheme of "Domain Name Auto-Registration
   for Plugged-in IPv6 Nodes" mechanism that makes it possible to
   register both regular and inverse domain name information of plugged-
   in IPv6 nodes to DNS servers automatically.

   In order to specify destination nodes to communicate, SOME
   identifiers are necessary for users. Since IPv6 addresses are too
   long to remember and EUI64-based addresses are too complicated to
   remember, they are not suitable for such identifiers. Logical names
   are suitable identifiers because they are easy to remember.
   Therefore, there are strong requirements to use logical names instead
   of IPv6 addresses to specify IPv6 destination nodes and to register
   domain name information of plugged-in IPv6 nodes automatically.

   In order to meet the requirements, a mechanism is proposed as one of
   the IPv6 auto-configuration (plug and play) functions. After the
   Address Autoconfiguration [ADDR-AUTO] has been executed, it works as
   a succeeding plug and play mechanism.

   It is known that the Dynamic Updates in the DNS [DYN-DNS] have
   already been defined and that they can help automatic domain name
   information registration mechanisms. However, some problems need to
   be solved to apply this idea to actual situations.

   This document clarifies problems that we meet when we apply the
   Dynamic Updates in the DNS [DYN-DNS] to automatic domain name
   information registration mechanisms. This document describes the
   Domain Name Auto-Registration mechanism as a solution to these
   problems.



H. Kitamura                                                     [Page 2]

INTERNET-DRAFT        Domain Name Auto-Registration        December 2002


   Basic target situations for the mechanism are plug and play
   situations. Accordingly, it has been designed for plugged-in IPv6
   nodes under plug and play situations.

   We have to consider the following issues to design the "Domain Name
   Auto-Registration for Plugged-in IPv6 Nodes" mechanism.

   1. Plugged-in IPv6 nodes do not have sufficient capability to show
      their preferences. In most cases, it is difficult for plugged-in
      IPv6 nodes to show their preferences for their domain names.

   2. Since it is not easy to install new function to all IPv6 nodes, it
      is desirable to achieve the mechanism without installing new
      functions into plugged-in IPv6 nodes.

   3. It is essential to have (register) SOME domain name for a
      plugged-in node. It is NOT main concern for a plugged-in node
      which actual name is assigned to it.

   Thus, the idea of "default domain name" is introduced. When a new
   plugged-in IPv6 node appears, its appearance is automatically
   detected and a default domain name is selected for it, and both
   regular and inverse information of the default domain name are
   registered to appropriate DNS servers.

   This document does not deal with cases where IPv6 nodes want to
   register domain names that they absolutely prefer. Such cases do not
   fall within the target range of plug and play situations; they will
   be supported under manual configuration situations.

   There are various types of plugged-in IPv6 nodes that can/cannot show
   their preferences for their domain names. In order to meet various
   plug and play situations, this document considers several cases.

   The Domain Name Auto-Registration mechanism is basically designed for
   domain name registrations for global unicast addresses. By setting
   the query scope of the target DNS server appropriately, the mechanism
   will be able to be applied to domain name registrations for site-
   local and link-local scope unicast addresses.

   The Domain Name Auto-Registration mechanism, in addition to its main
   functionality, provides two types of additional benefits.

   One is that IP address information that should be registered to the
   DNS is collected automatically. The mechanism can also be used under
   (non plug and play) manual configuration situations in a different
   manner from its main functionality. Under such situations where
   network is maintained by administrators manually, administrators meet



H. Kitamura                                                     [Page 3]

INTERNET-DRAFT        Domain Name Auto-Registration        December 2002


   a problem that it is not easy to collect IP address information to
   register to the DNS. The mechanism solves the problem, and IP address
   information to register to the DNS is collected automatically.

   Under manual configuration situations, the automatic DNS registration
   procedure that is the last procedure of the mechanism can be replaced
   by the administrators' manual registration (not by the Dynamic
   Updates).


   The other is that a plugged-in IPv6 node can obtain its domain name
   information (FQDN and DNS zone suffix) with ease. The plugged-in IPv6
   nodes know its IPv6 address that are automatically configured by the
   Address Autoconfiguration [ADDR-AUTO]. By simply executing inverse
   DNS name resolving procedures with the IPv6 address argument, the
   plugged-in IPv6 node can obtain information on its domain names (FQDN
   and DNS zone suffix) easily. Since all IPv6 nodes have DNS name
   resolving functions for both regular and inverse queries, this
   procedure can be achieved without installing new functions into IPv6
   nodes.


2. Problems in applying the Dynamic Updates mechanism

   This section clarifies problems that we meet when we apply the
   Dynamic Updates in the DNS [DYN-DNS] to automatic domain name
   information registration mechanisms.

   1: Ordinary DNS servers accept Dynamic Updates messages only from
      trusted nodes.

      Since it is difficult for plugged-in IPv6 nodes to become trusted
      nodes of the DNS servers, Dynamic Updates messages from plugged-in
      IPv6 nodes are usually not accepted by the DNS servers.

   2: It is difficult for plugged-in IPv6 nodes to know the location of
      the appropriate DNS server to register their domain name
      information to.
      ([DNS-DISC] discusses on issues of this type.)

   3: It is difficult for plugged-in IPv6 nodes to prepare sufficient
      domain name information to register. They need to know their DNS
      zone suffix information to prepare FQDN for registration, but it
      is difficult for them to acquire it.
      ([DNS-DISC] also discusses on issues of this type.)

   4: There is no explicit method to avoid duplicated, conflicting name
      registrations.



H. Kitamura                                                     [Page 4]

INTERNET-DRAFT        Domain Name Auto-Registration        December 2002


      When a DNS server receives Dynamic Updates messages that are
      correctly formatted and authenticated, the server accepts them and
      updates DNS database with them without checking for duplication.
      (It is essentially difficult for a DNS server to distinguish
      overwrite (update) registrations from duplicate registrations.)

   5: Basically, there is no mechanism to control (restrict) the number
      of issued Dynamic Updates messages for plugged-in nodes.

      In order to minimize the effects of malicious or misconfigured
      registration requests, it is necessary to control them.

   6: It is not clear when domain name registration requests must be
      issued. It is necessary to define trigger timings to start
      registrations.


3. Basic Design of the Domain Name Auto-Registration

   This section describes the basic design of the Domain Name Auto-
   Registration mechanism. The mechanism solves all of the above-
   mentioned problems.


3.1 Design Policies

   The Domain Name Auto-Registration mechanism is composed of two new
   functions. One is the "Detector" function, which detects appearances
   of new plugged-in IPv6 nodes. The other is the "Registrar" function,
   which registers detected domain name information to DNS servers.
   These functions are introduced into the IPv6 network system to
   achieve the mechanism.

   There are several reasons why the mechanism is implemented as two
   functions.

   1. To make the mechanism easy to control

      By concentrating administrative operations only on the Registrar
      side, administrative costs are reduced and the mechanism is
      basically maintained by administering only Registrars.

      The number of DNS servers' trusted nodes that require much
      administrative operation is reduced.

      Since registration information is aggregated at Registrars, it
      becomes easy to control registrations and minimize the effects of
      malicious or misconfigured registration requests.



H. Kitamura                                                     [Page 5]

INTERNET-DRAFT        Domain Name Auto-Registration        December 2002


   2. To make Detector easy to implement

      There are certain constraints in placing Detectors on the IPv6
      network. Thus, it is necessary for Detectors to be simple enough
      to be installed on IPv6 nodes of any type.

      This need is filled by putting all the intelligent operations into
      Registrars.

      Furthermore, the system becomes well balanced since intelligent
      operations are not placed on each end link.

   3. To make the mechanism flexible and enable it to be applied
      to various environments (office networks, home networks, etc.)

      If the mechanism is applied to home networks, Registrars can be
      placed at the Provider side, and Detectors can be placed at the
      User side.


   Figure 1 and 2 show typical examples that indicate locations where
   Detector and Registrar functions are placed on the IPv6 network.

   Figure 1 shows a case for a single link, and Figure 2 shows a case
   for multiple links.




               |                                 +------------+
               |                                 | DNS Server |
             +-+-+  %%%%%%%%%%%%  #############  +------+-----+
             | R |  % Detector %  # Registrar #        /
             +-+-+  %%%%%%%%%%%%  #############       +---+
               |         |              |                /
           ----+---------+-------+------+---------------+-----
                                 |
                           +===========+
                           | Plugged-in|
                           | IPv6 Node |
                           +===========+

                      Fig. 1 Single-Link Case Example








H. Kitamura                                                     [Page 6]

INTERNET-DRAFT        Domain Name Auto-Registration        December 2002


                                         +------------+
                                         | DNS Server |
                     #############       +------+-----+
                     # Registrar #             /
                     #############            +---+
                           |                     /
           ----+-----------+------------+-------+------
               |                        |
             +-+-+   %%%%%%%%%%%%%    +-+-+   %%%%%%%%%%%%%
             | R1|   % Detector1 %    | R2|   % Detector2 %
             +-+-+   %%%%%%%%%%%%%    +-+-+   %%%%%%%%%%%%%
               |           |            |           |
           ----+-----+-----+-----   ----+-----+-----+-----
                     |                        |
               +===========+            +===========+
               | Plugged-in|            | Plugged-in|
               | IPv6 Node |            | IPv6 Node |
               +===========+            +===========+

                     Fig. 2 Multiple-Link Case Example


   One Registrar can take charge of multiple Detectors, and one
   Registrar can cover multiple DNS zones.

   Multiple Detectors can provide detected information for one DNS zone.
   If the corresponding Registrars of these Detectors are different,
   multiple Registrars can cover one DNS zone.

   Therefore, Registrars must be designed to support both cases.



3.2 Detector Function

   The role of a "Detector" is to detect appearances of new plugged-in
   IPv6 nodes and to send the detected information to a "Registrar"
   without applying any selection rules to it.

   Detectors are NOT required to perform any "intelligent" operations.

   A Detector knows the location of its corresponding Registrar. (This
   location is configured manually.) Detected information must be sent
   securely from the Detector to the Registrar by using some kind of
   secure communication method (e.g., [TSIG]-like authentication, IPsec
   (AH, ESP), [TLS]).