INTERNET-DRAFT H. Kitamura <draft-ietf-dnsext-ipv6-name-auto-reg-01.txt> NEC Corporation Expires in six months 23 July 2003 Domain Name Auto-Registration for Plugged-in IPv6 Nodes <draft-ietf-dnsext-ipv6-name-auto-reg-01.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 July 2003 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 July 2003 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 July 2003 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 July 2003 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 July 2003 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 July 2003 +------------+ | 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]). H. Kitamura [Page 7]
INTERNET-DRAFT Domain Name Auto-Registration July 2003 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 July 2003 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 July 2003 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 July 2003 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 July 2003 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 July 2003 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 July 2003 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]
INTERNET-DRAFT Domain Name Auto-Registration July 2003 The Detector watches (a) and (b), and detects the appearance of new plugged-in IPv6 nodes. (c) is a procedure for sending the detected information, to which the Detector ID is attached. The scope of the detected address is not checked at the Detector. After the Registrar receives the detected information by the procedure (c), the scope of the detected address and the decision algorithm (which depends on the Detector ID) are checked on the Registrar. In typical cases, the decision algorithm shows that link-local addresses are not candidates for registration. In such cases, the detected information for the link-local address is discarded at this point. (d)(e)(f) and (g) are DAD procedures for the global address of the Plugged-in Node. (d) is an optional procedure. (g) is a procedure to verify that there is no NA (reply to NS) and that the global address is not duplicated. The Detector watches (f) and (g), and detects the appearance of new plugged-in IPv6 nodes. (h) is a procedure for sending the detected information, to which the Detector ID is attached. After the Registrar receives the detected information by the procedure (h), the scope of the detected address and decision algorithm (which depends on Detector ID) are checked on the Registrar. In typical cases, the decision algorithm shows that global addresses are candidates for registration. In such cases, check procedures to avoid duplicated registrations are started at this point. (i) and (j) are check procedures to verify that the detected address is must be registered to the DNS. The Registrar checks for the existence of FQDN information for the detected address by executing "inverse DNS name resolving" procedures with the detected address argument. If the existence of FQDN information for the detected address is verified, such detected address information for registration is canceled and discarded at this point. If the existence is not verified, the Registrar starts preparing "default domain name" information for the candidate IPv6 address. DNS zone suffix information that depends on the Detector ID is taken from the Registrar's manually configured database table, and the naming rule algorithm that depends on the Detector ID is also taken from it. H. Kitamura [Page 15]
INTERNET-DRAFT Domain Name Auto-Registration July 2003 By following the defined naming rule algorithm, the plugged-in node's prefix name is selected. (k) and (l) are optional procedures for preparing "default domain name." If the naming rule that is applied for the detected address stipulates inquiring the preference or property of the node, (k) and (l) are executed and such information is obtained by the Registrar. The obtained information is used as a hint to select the prefix name of the plugged-in node. A candidate "default domain name" for the detected address is prepared here. (m) and (n) are check procedures to verify that the candidate "default domain name" is not used by anyone. The Registrar checks for the existence of the candidate "default domain name" by executing "regular DNS name resolving" procedures with the candidate "default domain name." If the existence is not verified, it becomes fully qualified "default domain name." If the existence is verified, the Registrar restarts and repeats preparing a candidate "default domain name" for the detected address. After fully qualified "default domain name" information to register is prepared, (o)(p)(q) and (r) are executed to register both regular and inverse domain name information to the DNS servers by the Dynamic Update messages. (Under manual configuration situations, (o)(p)(q) and (r) procedures are replaced by the administrators' manual registration (not by the Dynamic Updates).) 5. Treatment of "Temporary Addresses" in the Mechanism "Temporary address" is defined in [RFC3041]. Temporary addresses are detected in this mechanism, because DAD packets are issued when temporary address are generated. There are two views whether domain names for temporary addresses should be registered to the DNS or not. One view is that domain names for temporary addresses should NOT be registered to the DNS, because temporary addresses are temporary and they are introduced to lessen privacy concerns. H. Kitamura [Page 16]
INTERNET-DRAFT Domain Name Auto-Registration July 2003 The other view is domain names for temporary addresses should be registered to the DNS. [RFC3041] discusses on this issue at section 4 of [RFC3041]. In order to meet conventional inverse-DNS-based "authentication," nodes could register temporary addresses in the DNS using random names. The Domain Name Auto-Registration mechanism can provide a solution for this issue. Since there are two views for domain names registration of temporary addresses, which view should be chosen is depends on site policies. 5.1 How to Distinguish "Temporary Addresses" from Public Addresses In order to apply above discussed policies, it is necessary to distinguish "temporary addresses" from public addresses. Only with IP address information, it is difficult to tell that a detected address is a temporary address or a public addresses. So, link-layer address information is utilized to achieve this operation (see section 3.2). By utilizing link-layer address information, we can easily tell that a detected address is a EUI64-based address or not. (This operation is called a "EUI64 check" operation.) If a detected address is a EUI64-based, it is not a temporary address. It is a normal target address for the Domain Name Auto- Registration mechanism. If not, it must be a either temporary address or manually configured address. We can assume that a domain name for a manually configured address must have been registered in the DNS manually. In the mechanism, an IP address whose domain name has been already registered does not become a candidate. It is verified by "inverse DNS name resolving" check procedures (see (i) and (j) procedures in Figure 3). By applying a "EUI64 check" operation after "inverse DNS name resolving" check procedures, we can assume that non EUI64-based address must be a temporary address. Since temporary addresses are distinguished from public addresses, we can apply above discussed policies to temporary addresses. H. Kitamura [Page 17]
INTERNET-DRAFT Domain Name Auto-Registration July 2003 6. Security Considerations After the Address Autoconfiguration [ADDR-AUTO] has been executed, the Domain Name Auto-Registration works as a succeeding of the plug and play mechanism. The plugged-in IPv6 nodes' appearances detection method is depend on the Address Autoconfiguration. Thus, the items that are described in the Security Considerations section of the Address Autoconfiguration [ADDR-AUTO] are also applicable to this document. In addition, the following security issues are considered. Since the Detector must send detected information to the Registrar securely, some sort of secure communication method (e.g., [TSIG]-like authentication, IPsec (AH, ESP), [TLS]) must be used. The 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 method. The [TSIG] technique would be suitable for authenticating the messages. In order to minimize the effects of malicious or misconfigured registration requests, the Registrar restricts the number of Dynamic Update messages that are sent from the Registrar per unit of time. H. Kitamura [Page 18]
INTERNET-DRAFT Domain Name Auto-Registration July 2003 Appendix A. HTTP-based simple protocol between Detector and Registrar a. Design of HTTP parameters - Request Parameters method = <registration protocol> detectorID = <detector identifier(address)> IP-address = <detected IP address> link-layer-address = <detected link-layer address> source = <source type> time-detected = <detected time> - Response Parameters result = <result> address = <registered address> hostname = <registered hostname> namehint = <name hint> error = <error> time-accepted = <accepted time> b. Message Examples - Request message POST /cgi-bin/registrar.cgi HTTP/1.1 Host: registrar-host Content-Length: mmm User-Agent: DAD-detector Content-type: application/x-pnp-dnar method=register/2.0 detectorID=3ffe:xxxx::2a0:c9ff:fea6:7ff1 IP-address=3ffe:yyyy::202:b3ff:fe2d:68c0 link-layer-address=00:00:4c:zz:zz:zz source=DAD-detector time-detected=1013078377 - Response message HTTP/1.1 200 OK Content-Type : text/plain Content-Length : nnn Connection : close result=REGISTER address=3ffe:yyyy::202:b3ff:fe2d:68c0 hostname=host.example.com namehint=none time-accepted=1013078378 H. Kitamura [Page 19]
INTERNET-DRAFT Domain Name Auto-Registration July 2003 References [IPv6] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification," RFC2460, December 1998. [ND] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)," RFC 2461, December 1998. [ADDR-AUTO] S. Thomson, T. Narten, "IPv6 Stateless Address Autoconfiguration," RFC2462, December 1998. [DYN-DNS] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound, "Dynamic Updates in the Domain Name System," RFC 2136, April 1997. [TSIG] P. Vixie, O. Gudmundsson, D. Eastlake, D. and B. Wellington, "Secret Key Transaction Signatures for DNS (TSIG)," RFC 2845, May 2000. [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC2246, January 1999 [DNS-SIG0] D. Eastlake, "DNS Request and Transaction Signatures ( SIG(0)s)," RFC2931, September 2000. [DYN-DNSSEC] B. Wellington, "Secure Domain Name System (DNS) Dynamic Update," RFC3007, November 2000. [DNSSEC] B. Wellington, "Domain Name System Security (DNSSEC) Signing Authority," RFC 3008, November 2000. [SNMP] J. Case, K. McCloghrie, M. Rose, S.Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)," RFC1905, January 1996. [RFC3041] T. Narten, R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6," RFC3041, January 2001 [HTTP] R. Fielding, et al, "Hypertext Transfer Protocol -- HTTP/1.1" RFC2616, June 1999 [TLS-HTTP] R. Khare, S. Lawrence, "Upgrading to TLS Within HTTP/1.1" RFC2817, May 2000 [DEF-ADDR] R. Draves, "Default Address Selection for Internet Protocol version 6 (IPv6)," RFC3484, February 2003 H. Kitamura [Page 20]
INTERNET-DRAFT Domain Name Auto-Registration July 2003 [NIQ] M. Crawford, "IPv6 Node Information Queries," <draft-ietf-ipngwg-icmp-name-lookups-10.txt>, June 2003 "work in progress" [DNS-DISC] A. Durand, J. Hagino, D. Thaler, "Well known site local unicast addresses to communicate with recursive DNS servers," <draft-ietf-ipv6-dns-discovery-07.txt>, October 2002 "work in progress" Author's Address: Hiroshi Kitamura Network Development Laboratories, NEC Corporation (Igarashi Building 4F) 11-5, Shibaura 2-Chome, Minato-Ku, Tokyo 108-8557, JAPAN Phone: +81 (3) 5476-1071 Fax: +81 (3) 5476-1005 Email: kitamura@da.jp.nec.com H. Kitamura [Page 21]
