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

bind-3.2.

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


   Since a Detector must be placed where appearances of new plugged-in
   IPv6 nodes can be detected, the Detector location is restricted.

   In typical cases, appearances are detected by watching for DAD
   packets that are issued from plugged-in IPv6 nodes (see section 3.4).
   So, the Detector must be placed where it can listen to link-local
   scope multicast packets. In other words, a Detector must be placed on
   each link to achieve the mechanism.

   The Detector function can be implemented on routers, because its
   operations are simple and lightweight and routers are located at
   suitable places for listening to link-local scope multicast packets
   that are issued from plugged-in IPv6 nodes.

   In order to identify Detectors, each Detector must have its own
   Detector ID. Since a Detector is placed on each link, the Detector's
   IP address that is connected to its watching link can be used for the
   Detector ID. (Default Address Selection for IPv6 [DEF-ADDR] algorithm
   is also applied here.) When a Detector sends detected information to
   a Registrar, the Detector ID is attached to it.

   In order to meet "temporary address" [RFC3041] issues (see section
   5), a link-layer address of a detected IP address is also attached to
   detected information.

   Some simple protocol is necessary to send detected information from
   the Detector to the Registrar. In Appendix A, [HTTP]-based or [TLS-
   HTTP]-based simple protocol is shown.

3.3 Registrar Function

   The role of a "Registrar" is to prepare appropriate domain name
   information for registration and to register it by sending Dynamic
   Update messages to the corresponding "DNS servers".

   Appropriate domain name information for registration is created from
   detected information that is sent from the Detector. Some sort of
   intelligent algorithm is necessary in such procedures. One of the
   roles of the algorithm is to minimize the effects of malicious or
   misconfigured registration requests.

   Registrars are required to perform "intelligent" operations.

   By using some sort of algorithm, the Registrar verifies (checks)
   whether detected information must be registered (see section 3.5).
   After the verification procedures are completed, the Registrar
   selects a "default domain name" for the detected information.




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


   In order to prepare appropriate domain name information, the
   Registrar must know the appropriate DNS zone suffix for detected
   information. (The suffix is configured manually.) The DNS zone suffix
   depends on the Detector ID information.

   A Registrar must know the locations of "DNS servers" that correspond
   to detected information for registration (both regular DNS zone
   prefix and its inverse zone). Registrars must be trusted nodes of the
   DNS servers and Dynamic Update messages must be sent securely from
   the Registrar to the DNS servers by using some sort of secure
   communication methods. The [TSIG] technique would be suitable for
   authenticating the messages.

   A Registrar has a database table to manage such knowledge. The
   following elements are managed in the database table:
   Detector IDs, DNS zone suffixes, locations of DNS servers, applied
   algorithms (naming rules, how to deal with link-local or site-local
   scope addresses, etc.) and keys for secure communications.

   A Registrar can be placed anywhere in the IPv6 network, because the
   Registrar communicates only with Detectors and DNS servers, all
   communications are unicast.

   In order to optimize the communication path for packets between them,
   the Registrar is usually placed in the network upstream from the
   Detectors (see Fig.2).

   Detected information that is sent from Detectors is aggregated at the
   Registrar.

   The Registrar may frequently execute inverse DNS name resolving
   procedures to verify (check) whether detected information must be
   registered. It is recommended to put a DNS cache server function on
   the same node where the Registrar is placed to reduce inverse DNS
   name resolving traffic (see section 3.5).

3.4 Methods of Detecting Appearances of New Plugged-in IPv6 Nodes

   In order to detect appearances of new plugged-in IPv6 nodes, the
   Detector must watch or receive packets from new plugged-in nodes.
   Accordingly, detection methods on the Detector are categorized into
   two types.

   One is detection of the appearance of "standard" plugged-in nodes
   that do not issue special packets to show their appearance. The other
   is detection of the appearance of "active" plugged-in nodes that
   issue special packets to show their appearance.




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


   We can assume there will be complex cases in which standard and
   active plugged-in nodes are mixed together. For purposes of
   simplification, such cases are not discussed here.

3.4.1 Detecting Appearance of "Standard" Plugged-in IPv6 Nodes

   In this case, plugged-in nodes do NOT issue special dedicated packets
   to show their appearance. (Current standard networks are composed of
   such nodes.)  So, the Detector must watch for packets that are issued
   somewhere from new plugged-in nodes.

   The initial procedure for a standard plugged-in IPv6 node is to auto-
   configure its address and do DAD (Duplicate Address Detection) [ADDR-
   AUTO].

   DAD packets have sufficient characteristics for an appearance-
   detection method, because they are issued only when IPv6 nodes are
   plugged in, and address information for the plugged-in IPv6 nodes is
   included in DAD packets.

   By watching for only DAD packets, the Detector can detect appearances
   of new plugged-in IPv6 nodes, and DAD packets become triggers to
   start Domain Name Auto-Registration.

   This method enables the mechanism to function without introducing new
   protocols and without installing new functions into plugged-in IPv6
   nodes.


   DAD packets are issued not only for global addresses but also for
   link-local or site-local scope addresses. All detected information is
   sent to the Registrar, and the manner of dealing with information for
   non-global addresses is determined by Registrar algorithms that are
   indicated by Detector IDs of the detected information.


   This method works effectively on ordinary IPv6 links where DAD
   packets are issued. However, on extraordinary IPv6 links where DAD
   packets are not issued, it does not work. On such links, there must
   be another initial procedure that substitutes the DAD function.  Such
   a procedure can be used as a trigger for a detection method on
   extraordinary IPv6 links.

   (IP addresses can be assigned by other methods (e.g., DHCP). Domain
   name registration mechanisms for such cases will be discussed further
   in other documents.)





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


3.4.2 Detecting Appearance of "Active" Plugged-in Nodes

   In this case, plugged-in nodes issue special dedicated packets to
   show their appearance. The Detector must listen for and receive
   packets from the new plugged-in nodes.

   Since plugged-in nodes do not know the location of the Detector,
   anycast or multicast packets are used for the special dedicated
   packets.

   In this method, plugged-in nodes can actively show their preference
   for their domain names. However, it will be difficult to show their
   preference under plug and play situations.

   In order to achieve the method, new protocols must be defined and new
   functions must be installed into plugged-in IPv6 nodes.
   (This will be discussed further in other documents.)

3.5 Methods of Controlling Registration

   If received Dynamic Update messages are correctly formatted and
   authenticated, the DNS server accepts them without checking for any
   duplication, because the DNS server can not distinguish overwrite
   (update) registrations from duplicate registrations. It is difficult
   to achieve a mechanism for avoiding duplicated registrations on the
   DNS server side.

   Therefore, registrations by the Dynamic Update messages must be
   controlled on the Registrar side. This control mechanism also helps
   to minimize the effects of malicious or misconfigured registration
   requests.

   Plugged-in nodes may switch on and off frequently and issue DAD
   packets frequently. Since the Detector sends detected information
   without applying any selection rules to it, all detected information
   is sent to the Registrar. Thus, the Registrar must have some
   information verification mechanism to avoid duplicated registrations.

   All candidate information (detected addresses) for registration is
   checked by using inverse DNS resolving queries of them. If there is
   FQDN information that matches the detected address, such registration
   candidates are not registered.

   Only when FQDN information for it is NOT found and it is verified
   that the detected information is based on first appearance of the
   plugged-in node, appropriate domain name information for registration
   is prepared and both regular and inverse domain name information for
   it are registered to the DNS servers by the Dynamic Update messages.



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


   By using this verification mechanism, the Registrar does not have to
   have a local database to maintain the status of the detected
   information and no DNS registration inconsistency problems are
   caused.

   By restricting the number of Dynamic Update messages that are sent
   from the Registrar per unit of time, the effects of malicious or
   misconfigured registration requests are minimized.


3.6 Naming Rules for Default Domain Names

   This section describes a method of setting "default domain names" for
   plugged-in nodes.

   A fully qualified "default domain name" is composed of a node's
   original prefix part and a DNS zone suffix part that is the same for
   each site or link.

   Since a DNS zone suffix is given to the Registrar manually, only the
   naming rules for a node's original prefix are discussed here. A
   naming rule algorithm for a node's prefix is given to the Registrar
   manually.

   It is not necessary to define naming rules for a node's prefix
   explicitly in this document. Each site can define its own naming
   rules (algorithms) per link according to site policy.

   This document shows some example naming rules for a node's prefix
   name.

   1. Prefix Letter(s) + Number

      This is the easiest rule. First, prefix letter(s) that depends on
      each link (Detector ID) is/are selected, and the following number
      is selected after that.

      The following numbers comprise sequential numbers. In order to
      achieve this, the Registrar must remember the last selected
      number.

      There are some situations where using sequential numbers is not
      favorable because the next number could be easily predicted. In
      those cases, random numbers can be used, which makes it necessary
      to implement the Registrar with a duplicate number check
      mechanism.





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


   2. Predefined Names

      The Registrar prepares predefined names (e.g., names of flowers)
      that are used for prefix names for plugged-in nodes. Random or
      sequential numbers can be used to prepare predefined names.

      This method can be used for an environment where the number of
      plugged-in nodes can be estimated and the number is not
      excessively large.

   3. Use Preferences of Plugged-in Nodes.

      The Registrar inquires the preference or property of a plugged-in
      node, and uses the obtained information as a hint to define a
      prefix name for the plugged-in node.

      There are two types of methods for plugged-in nodes to indicate
      their preference or property.


      One is "passive" indication. Plugged-in nodes do NOT become an
      initiator to indicate their preferences. The Registrar becomes an
      initiator and issues query packets to plugged-in nodes. Existing
      protocol (e.g., Node Information Query [NIQ], SNMP) is used for
      it.

      For a detected global address, the Registrar can use Node
      Information Query [NIQ] to obtain hint information to define a
      name for the plugged-in node.

      By using [SNMP], the Registrar can also obtain hint information to
      define a name for the plugged-in node. Plugged-in nodes use parts
      of MIB to indicate their preferences or properties. It is possible
      to define a special MIB for this purpose. Also, some parts of
      currently existing MIB can be used for it. Most plugged-in nodes
      have already set some property information (OS type, version,
      etc.) to their MIB when they are plugged in. Such information can
      be used for a hint to define a prefix name. (The Registrar must
      have an appropriate read access right to such MIB information.)

      The other is "active" indication. Plugged-in nodes become an
      initiator to indicate their preferences and issue special
      dedicated packets for it. Since plugged-in nodes do not know the
      location of the Detector or Registrar, anycast or multicast
      packets are used for them. It is possible to attach name
      preference information to packets that are used for showing the
      appearance of plugged-in nodes. The Registrar can receive such
      information via the Detector.



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


      In order to achieve the "active" indication method, new protocols
      must be defined and new functions must be installed into plugged-
      in IPv6 nodes.
      (This will be discussed further in other documents.)


4. Procedures of the Domain Name Auto-Registration

   Figure 3 shows an example of typical Domain Name Auto-Registration
   procedures at IPv6 links where DAD packets are issued. DAD packets
   are used for the appearance detection method (for standard plugged-in
   IPv6 nodes).

        Plugged-in   Router       Detector     Registrar    DNS servers
        IPv6 Node
          | link local |            |            |            |
       (a)|---DAD NS--->----------->|            |            |
       (b)|    no NA   |            |            |            |
       (c)|            |            |----------->|            |
          |            |            |            |            |
          |   global   |            |            |            |
       (d)|(----RS--->)|            |            |            |
       (e)|<----RA-----|            |            |            |
       (f)|---DAD NS--->----------->|            |            |
       (g)|    no NA   |            |            |            |
       (h)|            |            |----------->|            |
          |            |            |            |            |
       (i)|            |            |            |----------->|
       (j)|            |            |            |<-----------|
          |            |            |            |            |
       (k)|(<-----------------------------------)|            |
       (l)|(----------------------------------->)|            |
          |            |            |            |            |
       (m)|            |            |            |----------->|
       (n)|            |            |            |<-----------|
          |            |            |            |            |
       (o)|            |            |            |----------->|
       (p)|            |            |            |<-----------|
       (q)|            |            |            |----------->|
       (r)|            |            |            |<-----------|
          |            |            |            |            |

          Fig. 3 Example of Typical Auto-Registration Procedures

   (a) and (b) are DAD procedures for the link-local address of the
   Plugged-in Node. (b) is a procedure to verify that there is no NA
   (reply to NS) and the link-local address is not duplicated on the
   link.



H. Kitamura                                                    [Page 14]