S.Gopinath Rao INTERNET-DRAFT NRG, USM Malaysia Expires: 29 February 2002 K. Ettikan Intel ASG, Malaysia 29 August 2001 Host Name Resolution Protocol (HNRP) for IPv6 nodes 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 new method, which will automatically acquire the host name of active IPv6 nodes and register it to the local Domain Name System (DNS) server. Active IPv6 nodes are nodes that are connected to a network. Our proposed new protocol, which is called Host Name Resolution Protocol (HNRP) [6], will automatically learn some useful information from all the IPv6 nodes, such as the host name and the IP address. All the information will be kept by HRRP and the host name together with the IPv6 address will be added to the DNS. This will be implemented without the need for any changes at the clients' site. The objective of this document is to specify the new Host Name Resolution Protocol and also the algorithm used in the protocol. Gopinath, Ettikan [Page 1] Internet Draft HNRP For IPv6 nodes August, 2001 Table of Content 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Study on Existing and similar application . . . . . . . . . . . 3 2.1 Domain Name Auto-Registration for plugged in IPv6 . . . . . 4 3. Design of Host Name Resolution Protocol . . . . . . . . . . . . 4 3.1 Design Issue . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2 Design Method . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.1 The Agent . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.2 The Resolver . . . . . . . . . . . . . . . . . . . . . 6 3.3 Detection method . . . . . . . . . . . . . . . . . . . . . . 6 3.3.1 Algorithm for detection . . . . . . . . . . . . . . . . 8 3.3.2 Algorithm for using unicast address as destination in the ICMPv6 packet . . . . . . . . . . . . . . . . . . . 8 3.3.3 Algorithm for using multicast address as destination in the ICMPv6 packet . . . . . . . . . . . . . . . . . . . 8 3.4 Updating the DNS by the resolver . . . . . . . . . . . . . . 9 3.4.1 Naming . . . . . . . . . . . . . . . . . . . . . . . . 9 3.4.2 Naming Algorithm . . . . . . . . . . . . . . . . . . . 9 3.5 Location of Host Name Resolution Protocol (HNRP). . . . . . 10 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Security Consideration . . . . . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction Domain Name System has long been used for resolving host name to IP address and vice versa. The need of automatically sensing the host name and IP addresses on a network by DNS does not arise because IPv4 addresses are easy to remember. The improvement of DNS with the introduction of DNSv6 should have included this new feature so that it would be an intelligent application. The reason for the proposed protocol and the solutions are as follows. 1. The main factor that drives us to introduce this protocol is the IPv6 addressing scheme. 128 bits IPv6 address is indeed very long to remember compared to IPv4. This hexadecimal representation makes unit of network difficult to be identified and remembered based on this IP address. Instead of remembering one's IP address, it will be easier for us to just use the host name. Gopinath, Ettikan February 2002 [Page 2] Internet Draft HNRP For IPv6 nodes August, 2001 To solve this problem, the Host Name Resolution protocol will automatically sense all the IPv6 nodes on a specific link and add all the names of the nodes within that domain to its DNS. This will also give the users the freedom to choose their own host name for their node/s. An algorithm in the protocol will check the uniqueness of the host name of each node. 2. Maintenance of these addresses is another hassle for system administrator. In current DNS, system administrators manually enter the host name and the IP address associated with it into the host name file. Whenever there is a change to a node in the domain, system administrator must manually edit the host name file to make sure that the new node's information is updated to the list. To solve the above-mentioned problem, HNRP will periodically check and update the nodes' information into the host name file, if there are changes to the nodes. Even though we can use dynamic update [8] to send updated information to the DNS, this is restricted to certain operating system that implemented the dynamic update. By using this protocol, cost of handling and maintaining the host names can be reduced in huge amount. The amount of time spend by system administrator on setting up the host names will also be reduced. This document proposes a new protocol to dynamically handle the host names on an IPv6 LAN, which is named Host Name Resolution Protocol. This document also describes the algorithm used in Host Name Resolution Protocol. The implementation of this protocol involves few existing methods. For example, to get the nodes information, the use the Neighbor solicitation (Duplicate Address Detection (DAD) packet) and also the ICMPv6 packet will be implemented. This protocol supports all types of IPv6 addresses available, which are link local addresses, site local addresses and global unicast addresses. 2. Study on existing and similar application [6] The dynamic naming of host name was not implemented in IPv4 because IPv4 are easy to remember compared to IPv6 addresses. The only proposed method was discussed in a draft titled Domain Name Auto- Registration for plugged in IPv6 [3]. Gopinath, Ettikan February 2002 [Page 3] Internet Draft HNRP For IPv6 nodes August, 2001 2.1 Domain Name Auto-Registration for plugged in IPv6 This draft has proposed to use a method for domain name auto- registration for plugged in IPv6 nodes. The method is divided into 2 functions, which are _detector_ function and _registrar_ function. The _detector_ is used to detect the appearance of new IPv6 nodes and send it to a _Registrar_. The _Registrar_ is used to prepare appropriate domain name information for registration and to register it by sending dynamic update messages to the corresponding request. Two approaches are used in the draft to detect the nodes. One of the methods is by detecting the DAD packets. The other approach is by using the SNMP procedure. Our proposed protocol is similar to the above draft except that our protocol uses the DAD together with the ICMPv6 packet to get the host name. 3. Design of Host Name Resolution Protocol This section describes the design of the new protocol, Host Name Resolution Protocol (HNRP) [9]. The algorithm used in this protocol to solve the above mentioned problems would also be discussed in this section. 3.1 Design Issue The Host Name Resolution Protocol can be incorporated into DNS. There are few issues involved in designing this protocol. 1. Assignment of multiple IPv6 addresses to a single interface makes names assignment a complex problem. Each IPv6 active nodes is capable of having multiple IP addresses. The IPv6 nodes will have a default link local address, which is configured automatically using the autoconfiguration method [1]. Each node would also be able to construct it's own global address using the prefix advertised by a router on the same link. Beside that we can also manually assign a global IPv6 address to that same interface. So, we must make sure that all the addresses point to the same host name, unless the system administrator wants to configure the IP addresses with different host names. To solve this problem, default address selection can be used [10]. 2. To minimize the changes on nodes, HNRP's implementation required the development at one site. This will make the HNRP to use the existing methods to implement and it would also support all operating systems. Gopinath, Ettikan February 2002 [Page 4] Internet Draft HNRP For IPv6 nodes August, 2001 3. The location of the HNRP on the network needs to be decided. If a DNS is shared between 2 LANs, HNRP must be implemented so that it can detect all the nodes in both the LANs. This is because DAD and ICMPv6 packets used for detection of nodes won't go through the router that separates the LANs. 3.2 Design Method To make HNRP an efficient protocol and robust, we divided the protocol into two entities, the agent and the resolver. +-+-+ +-+-+-+-+ | +=========+ | | | R | | | +=========+ | | | | +=========+ | | | Agent | | | +====+====+ | +-+ +-+||-+-+-+ || || +-+-+-+||-+-+-+ | +=========+ | | | Resolver| | | +====+====+ | | | | | +====+====+ | | | DNS | | | +=========+ | +-+-+-+-+-+-+-+ Figure 1 shows the HNRP protocol and the communication between the two entities. 3.2.1 The Agent The Agent's function is to detect all the nodes on a link and keep the information in a specific file. It uses two detection methods for getting the information from the node by using the DAD packet and the ICMPv6 packet. The detection of DAD packets is restricted on a single LAN because the router won't allow the DAD packets to pass through. So, the Agent must be places on all the LANs to detect the DAD packets. The best place for the agent is the router. Gopinath, Ettikan February 2002 [Page 5] Internet Draft HNRP For IPv6 nodes August, 2001 The Agent need to be manually configured first so that the information that it detects can be send to the resolver to be updated into the DNS. It also will do periodic check on the LAN to make sure that new changes on nodes are updated to the DNS. 3.2.2 The Resolver This entity receives the information from the agent and updates the information to the DNS. It also has the naming algorithm to name the nodes. The resolver must be configured so that it directly update the nodes' information to the DNS. It In order to make the resolver to work effectively, it must be placed together with the DNS. This will make sure that the information is updated as soon as the resolver received it from the agent. 3.3 Detection Method This is the main method in HNRP protocol. In this method, the agent will detect any new IPv6 nodes on a link, check the uniqueness of that node on that link and then update the information in the DNS. There are 2 kinds of detection method used in the protocol. This two methods need to be combined to make sure that the nodes are configured correctly with the host name in the DNS. 1. Duplicate Address Detection (DAD) The nodes can be detected by monitoring the duplicate address detection (DAD) packet issued by nodes that has been activated. The DAD packet is issued as part of neighbor solicitation in neighbor discovery [2]. The implementation of duplicate address detection is compulsory on all IPv6 nodes, regardless of whether they are obtained through stateful, stateless or manual configuration. DAD has the same functions as the ARP packet in IPv4 but DAD provides more information. The DAD algorithm is issued to ensure that all configured addresses are likely to be unique on a given link [1]. Once an IPv6 node issues a DAD packet to a link, the agent will capture it and the packet will be analyzed. Then using ICMPv6 packet, the agent will issue a query to that node for more information (see section 2 of 3.4). All the information that has been captured will be kept in a specific file for reference. It should be noted that the DAD packets could only be detected on a Gopinath, Ettikan February 2002 [Page 6] Internet Draft HNRP For IPv6 nodes August, 2001 link-local, thus the agent must be positioned on a specific location to detect the packets (see section 3.4). 2. ICMPv6 _ node information query and node information reply This is the most important part in the agent. ICMPv6 type that will be in the agent are node information query and node information reply. Matt Crawford already defined the use of NI query as type 139 and NI reply type 140 [4]. Currently the ICMPv6 packet type for querying nodes information is still in the process of upgrading. Node information query and node information reply are information-based messages. NI query packet is sent by the _Querier_ node to ask some information from the _Responder_ node. The _Responder_ node, upon receiving the NI query packet, replies to the querier with the information requested by the _Querier_ node. This will be an exact method that will be used by the agent to query IPv6 nodes on a link. The ICMPv6 packet can be addressed to a unicast address, a link local multicast address or an anycast address depending on the scope of the information required. In this implementation we will skip the use of anycast and only use the unicast and the multicast address. The ICMP source address should be that of the address where the agent reside. In this case it is the DNS or the router or any nodes IP address where the agent reside. This is to make sure that the reply is send back to HNRP. The destination address can be chosen from the 2 types of addresses according to the algorithm. There will be 2 scenarios for choosing the destination address: i) If a node has been detected using the DAD packet, then the destination address will be the unicast address of the detected node. After getting the IPv6 address from the DAD packet, HNRP will use it as a destination address in the NI query requesting for host name (type 2 for qtype field). ii) The Agent uses the link local multicast address as the destination address to do periodic checking on a link to detect any changes or updates to a node. The predefined all node link local multicast address is FF02::1. This packet need to be sent from time to time so that the changes can be detected earlier to make HNRP efficient. The frequency of sending this type of packets will also need to be considered. Even though the ICMPv6 packets send are small, if it is send too frequent, it might flood the network. For it to work efficiently the internal time taken for sending the ICMPv6 packet need to be acceptable. Gopinath, Ettikan February 2002 [Page 7] Internet Draft HNRP For IPv6 nodes August, 2001 The content of qtype in the ICMPv6 packet that will be used by the agent is either type 2 (DNS names) or 3 (Node Addresses) and the implementation of the agent is done with an assumption that all the nodes are configured with the latest ICMPv6. Upon receiving a NI query, the nodes must check the query's IPv6 destination address and discard it if it is not intended for the node. The destination address of the query should be either the IP address of the receiving node or the multicast address that the receiving node joined earlier. The use of these ICMPv6 type is described is detail in the draft by Crawford [4]. 3.3.1 Algorithm for detection Agent continuously monitors for DAD packets Agent captures the DAD packet Compare the IP address with the IP in host name file If exists Ignore the info Else if does not exist Use ICMPv6 packet to request the information from the node 3.3.2 Algorithm using unicast address as destination in the ICMPv6 packet Agent sends the ICMPv6 packets request for information for unicast Agent captures the reply from the node If no reply in a time frame Send the request again Else if received the reply Extract the information and update the DNS 3.3.3 Algorithm using multicast address as destination in the ICMPv6 packet Agent sends multicast query requesting information Agent queues the reply Check the information with the existing host name file If info is new Update the file Else if it exist and information are different Update with new information Else if information are same Ignore Set the next time frame to send the multicast query again Gopinath, Ettikan February 2002 [Page 8] Internet Draft HNRP For IPv6 nodes August, 2001 3.4 Updating the DNS by the Resolver The resolver's function is to update the DNS with the information received from the agent/s. It will receive the information from the agent/s and will activate the naming algorithm before updating it to the DNS. The naming algorithm is used to make sure that the names are unique in link. 3.4.1 Naming The unique feature of HNRP protocol is the naming of the IPv6 nodes. HNRP allows the users to set their preferable name for their IPv6 node/s. Even though we don't have the control for the naming, HNRP still decides whether to use the specific name given by each user to their nodes. System administrator also has a choice whether to use this algorithm or manually configure the names. He also can use both manual and the approach described in this document. The resolver uses first come first serve basis in the naming algorithm. If there is a conflict of names between 2 IPv6 nodes, the node that register first will be given the name. For the second node, a new name will be generated using the name given by the node. For example if the conflict name is _ipv6-dns_, then the algorithm will assign a new name for the second node based on that conflict name such as _ipv6-dns-2_. In this way the each node will still have a unique name. This is different from the approach by Kitamura [3]. In the approach by Kitamura, the naming is still handled by system administrator and no freedom given to each user. The second approach, in the document uses predefined named which the registrar randomly generates. He also uses a method to detect the names automatically but in the method described, all the nodes must define a special MIB. This is difficult because it involve both the server and the client (nodes). To make the protocol simpler, we only use 2 methods, which is either configured by system administrator for fix name for an IPv6 node or use the name given by the node. 3.4.2 Naming algorithm Resolver Check the Host name file given by the agent Check IP address in file If IP is new Check name in file If name is new Update name and IP to the DNS Else if it is already exists Gopinath, Ettikan February 2002 [Page 9] Internet Draft HNRP For IPv6 nodes August, 2001 Generate a similar name Update to the DNS Else if it is already exist Compare name If it is not same Update with the new one Else Ignore 3.5 Location of Host Name Resolution Protocol (HNRP) The resolver need to be placed together with the DNS while the agent need to be placed with the router. Using this method, each link will have an agent, which is manually configured to directly communicate with the resolver. This kind of implementation is important because the router will drop the DAD packet from going out of it. +==========+ +#########+ |+--------+| |+-------+| || DNS || || Router|| |+---+----+| |+-------+| | | | |+-------+| |+--------+| || Agent || ||Resolver|| |+-------+| |+--------+| +####+####+ +====+=====| | | | +----+------+---------+----------+-------+--------+ | | +====+====+ +====+====+ |IPv6 node| |IPv6 node| +=========+ +=========+ Fig. 1 HNRP on a single LAN with DNS located in the same LAN Figure 1 shows an example of HNRP on a single LAN, which is placed together with the DNS. In this case, the agent will directly communicate with the resolver to update the host name file. The agent will dynamically get all the names and update the resolver from time to time. The resolver using will update the DNS with this latest information. Gopinath, Ettikan February 2002 [Page 10] Internet Draft HNRP For IPv6 nodes August, 2001 +==========+ |+--------+| || DNS || |+---+----|| | | | |+--------+| ||Resolver|| |+--------+| +====+=====| | +----------+--------------+---------+-----------+ | | | | +####+####+ +####+####+ |+-------+| |+-------+| || Router|| || Router|| |+-------+| |+-------+| |+-------+| |+-------+| || Agent || || Agent || |+-------+| |+-------+| +####+####+ +####+####+ | | -----+-----+--- --------+----+-- | | +====+====+ +====+====+ |IPv6 node| |IPv6 node| +=========+ +=========+ Fig.2 HNRP on 2 different LANs sharing one DNS Figure 2 shows the implementation where one DNS is shared among nodes from different LANs. In this scenario, each LAN will have an agent that will communicate directly with the resolver. To avoid the conflict of names from different LAN, each agent will make a copy of host name files from the resolver. In the case of multiple agent accessing the resolver at the same time, the protocol will allow the first agent to update the changes to the resolver. It will be first come first server basis. In this case the naming of nodes will be organized without the names conflicting with other nodes from different LAN/s. 4. Conclusion The implementation of Host Name Resolution Protocol is aimed to solve two major problems discussed above. In the future the capability of HNRP by adding more function and make it more secure in transmitting the data. Gopinath, Ettikan February 2002 [Page 11] Internet Draft HNRP For IPv6 nodes August, 2001 5. Security Consideration Security is one of the main issues in developing HNRP. Since the agent directly sends the information to the resolver, the information must be send securely (e.g., IPsec). The other communication part that needs to be sent securely is between the resolver and the DNS. It also must make sure that the message send by the agent are from the agent that is registered with the resolver. If not the data should be ignored. This is to make sure that no malicious data being send to the resolver. The security issue for HNRP is need to be discussed further. 6. References [1] S. Thompson, T. Narten, _IPv6 Stateless Address Autoconfiguration_, RFC 2462, December 1998. [2] T. Narten, E. Nordmark, _Neighbor Discovery for IP Version 6 (IPv6)_, RFC 2462, December 1998. [3] H. Kitamura, _Domain Name Auto-Registration for Plugged-in IPv6 Nodes_, , 13 July 2001. [4] M. Crawford, _IPv6 Node Information Queries_, , 28 August 2000. [5] IEEE, _Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority_, http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, March 1997 [6] Gopinath Rao Sinniah, Ettikan Kandasamy Karuppiah and R. Sureswaran, _Host Name Resolution Protocol (HNRP) _ The existing implementation and the need for a new protocol_, IEEE MICC2001, October 21-24, in press. Paper submission date: July 1 2001. [7] R. Hinden, S. Deering, _IP Version 6 Addressing Architecture_, RFC 2373, July 1998. [8] P. Vixie, S. Thompson, Y. Rekhter and J. Bound, _Dynamic Updates in the Domain Name System_, RFC 2136, April 1997. [9] Gopinath Rao Sinniah, Ettikan Kandasamy Karuppiah and R. Sureswaran, _Host Name Resolution Protocol (HNRP) _ The Gopinath, Ettikan February 2002 [Page 12] Internet Draft HNRP For IPv6 nodes August, 2001 implementation method_, Proceedings APAN Conference 2001, Penang, Aug. 20-22. [10] R. Draves, "Default Address Selection for IPv6", , 4 June 2001. 7. Authors' Addresses Gopinath Rao Sinniah Network Research Group, School Of Computer Science, University Science Malaysia, 11800 Minden, Penang, Malaysia. Tel: +604-8602488 Fax: +604-6504757 Email: gopi@nrg.cs.usm.my Ettikan Kandasamy Karuppiah ASG Penang & Shannon Operations, Intel Microelectronis (M) Sdn. Bhd., Bayan Lepas Free Trade Zone III, Penang, Malaysia. Tel: +60-4-859-2591 Fax: +60-4-859-7899 Email: ettikan.kandasamy.karuppiah@intel.com Gopinath, Ettikan February 2002 [Page 13]