S.Gopinath Rao Internet Draft NRG, USM Malaysia Document : K. Ettikan Expires in six months Intel ASG, Malaysia 2 November 2001 IPv6 Hostname auto-registration Procedure 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 method [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 the Agent in the new method 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 a new procedure and also the algorithm used in the procedure. Gopinath, Ettikan [Page 1] Internet Draft IPv6 auto-registration procedure November, 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 the new auto-registration procedure . . . . . . . . . 4 3.1 Design Issue . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2 Design Method . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.1 The Agent . . . . . . . . . . . . . . . . . . . . . . . 6 3.2.2 The Resolver . . . . . . . . . . . . . . . . . . . . . 6 3.2.3 Resolver-Agent Communication . . . . . . . . . . . . . 7 3.3 Detection method . . . . . . . . . . . . . . . . . . . . . . 8 3.3.1 Algorithm for detection . . . . . . . . . . . . . . . . 10 3.3.2 Algorithm for using unicast address as destination in 10 the ICMPv6 packet . . . . . . . . . . . . . . . . . . . 3.3.3 Algorithm for using multicast address as destination in the ICMPv6 packet . . . . . . . . . . . . . . . . . . 11 3.4 Updating the DNS by the Resolver . . . . . . . . . . . . . . 11 3.4.1 Naming . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4.2 Naming Algorithm . . . . . . . . . . . . . . . . . . . 12 3.5 Location of the Agent and the Resolver in a network . . . . 12 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Security Consideration . . . . . . . . . . . . . . . . . . . . 14 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 8. Revision history . . . . . . . . . . . . . . . . . . . . . . . 16 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 method and the solutions are as follows. 1. The main factor that drives us to introduce this procedure 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 May 2002 [Page 2] Internet Draft IPv6 auto-registration procedure November, 2001 To solve this problem, a new registration procedure that 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 will be used to make sure that the host name is unique. 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, the new procedure 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 implements the dynamic update. By using this procedure, 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 procedure to dynamically handle the host names on an IPv6 LAN, which is named IPv6 Hostname DNS auto- registration procedure. This document also describes the algorithm used in the new procedure. The implementation of this procedure involves few existing methods. For example, to get the nodes information, the use of Neighbor solicitation (Duplicate Address Detection (DAD) packet) and also the ICMPv6 packet will be implemented. This new procedure supports all types of IPv6 addresses available, both the stateless [1] and statefull IPv6 addresses. This includes 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 May 2002 [Page 3] Internet Draft IPv6 auto-registration procedure November, 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. The setback of this method is that it needs to be implemented at both the client and the server site. A new Internet standard like ICMP needs to be set for this approach to work. 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. Some of the idea discussed in this approach can be shared to produce a better method and algorithm. 3. Design of the new auto-registration procedure This section describes the design of the new procedure, IPv6 Hostname auto-registration procedure [9]. The algorithm used in this procedure to solve the above mentioned problems would also be discussed in this section. 3.1 Design Issue The new auto-registration procedure can be incorporated into the existing DNS. There are few issues involved in designing this procedure. 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 that may have different reachability scope (link local, site local or global). It can get the IPv6 address using both stateless and statefull configuration method. 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 Gopinath, Ettikan May 2002 [Page 4] Internet Draft IPv6 auto-registration procedure November, 2001 must make sure that all the addresses point to the same host name, unless the system administrator wants to configure each IP addresses with different host names. To select an address that will bind to the host name, default address selection can be used [10]. The default address selection is a method to select a source address or a destination address from multiple addresses that is assigned to a single interface. 2. The implementation of a new method usually requires a lot of changes at both the server and the client. To minimize the changes on nodes, the new proposed procedure's implementation required the development at only one site. This is implemented using the existing methods available, which supports all operating systems. Some of the methods developed uses the ICMPv6 and the neighbor discovery in IPv6. 3. The locations of the entities on the network need to be decided. This is to make sure that optimum results can be achieved. If a DNS is shared between 2 LANs, the entities must be implemented so that it can detect all the nodes in both the LANs. This is because the DAD and the ICMPv6 packets used for detection of the nodes won't be able to pass through the router that separates the LANs. 3.2 Design Method To make the new procedure to work efficiently and robust, it is divided into two entities, the Agent and the Resolver. +-+-+-+-+-+-+-+ | +=========+ | | | R | | | +=========+ | | | | +=========+ | | | Agent | | | +====+====+ | +-+-+-+||-+-+-+ || || +-+-+-+||-+-+-+ | +=========+ | | | Resolver| | | +====+====+ | | | | | +====+====+ | | | DNS | | | +=========+ | +-+-+-+-+-+-+-+ Gopinath, Ettikan May 2002 [Page 5] Internet Draft IPv6 auto-registration procedure November, 2001 Fig. 1 The Overall architecture of the new procedure Figure 1 shows the overall architecture of the new procedure 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 a node. The methods are 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 placed on all the LANs in order to detect the DAD packets issued by the nodes. The best location for the Agent to be placed is the router. The Agent need to be manually configured first so that the information that it detects from the IPv6 nodes can be send to the Resolver to be updated into the DNS. It will also do periodic checking on the LAN to make sure that new changes to the nodes are updated to the DNS. 3.2.2 The Resolver This entity sets an appropriate host name for registration into the corresponding DNS server. The host name is created from the information that is sent by the Agent. It later updates the host name into the DNS. The Resolver must have a method to verify the uniqueness of the host name in the network. This is achieved by using the naming algorithm to name the nodes. This algorithm is also used to minimize the effects of misconfigured registration request by the nodes. All the names given by the Agent is kept in a specific database. This is to make sure that the information can be retrieved easily whenever necessary. The Resolver must be configured so that it directly updates the nodes' information to the DNS. The main database in the Resolver consists of all the information send by the Agents. After updating the database, it will be copied by the Agent for their reference. This is important because a same node will move from one subnet to another subnet with same information. This scenario is further described in the next section. Gopinath, Ettikan May 2002 [Page 6] Internet Draft IPv6 auto-registration procedure November, 2001 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.2.3 Resolver-Agent Communication All the Agents, which communicate to the same Resolver, will have a copy of the updated database from the Resolver. This database will be used to check if changes occur to a node as described below. The link local address of each machine will be added in a new file. This address will be bind together with the global address and the host name of the machine in the file. The link local address can be used to check the uniqueness of the machine because the link local address is unique as it is generated using the Ethernet address and it never changes wherever the node moves. This information will be compared every time the Agent receives the updated information from a node before the host name is updated to the DNS via the Resolver. In the development of the Agent and the Resolver, multi-link scenario needs to be taken into consideration. It is a situation where a node moves from one subnet to another subnet and uses a same DNS. It is possible for few scenarios to happen when a node moves from one subnet to another and when some changes happened to a node. 1. The node uses new IP address but same host name in a same subnet or in a new subnet (same NIC card). This is a complicated scenario. In this case, the link local address together with the new global address will be compared with the information in the Agent's database. Since the link local address is still in the database, the old global address associated with the link local address will be deleted from the Resolver. The new global address will be updated to the database. With this algorithm we can maintain the host name and at the same time change the global address. 2. The node uses new IP address using new NIC card but same host name This is same as 2 nodes asking the same host name. In this situation, the naming algorithm will give a new name for the node. The old data will be deleted after some time. Until then the node has to use a new name generated using the naming algorithm or change the name. This can be overcome if system administrator manually deletes the old information. 3. The node uses new host name but same IP address. Gopinath, Ettikan May 2002 [Page 7] Internet Draft IPv6 auto-registration procedure November, 2001 In this scenario, the new name will overwrite the existing host name in the DNS. 4. The node uses both new host name and IP address. The new information will be compared with the information associated with the link local address in the database. Since the link local address is already in the database, the global and the host name will be compared. If both the information is new, then the old will data be over written with the new information. The Resolver will then enter the new information of the node to the DNS after the Agent passes the new information to the Resolver. 5. Node is inactive for certain duration This is a case when a node doesn't response to Agent's query. This scenario is possible when a node is crash or not booted by the owner for some time. The Agent will check the node for 3 or 4 months before asking the Resolver to delete it from the DNS. If the owner want to keep the information after that time period, system administrator need to set a flag indicating not to delete the information from the DNS. This flag can be set as an additional field in the DNS or in the Resolver. 6. Two nodes request for a same host name Using the naming algorithm (section 3.4.1 & 3.4.2), the nodes will be given the name requested using first come first serve basis. When the nodes rebooted, the names will be maintained as given earlier. 3.3 Detection Method This is the main method in the new procedure. 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 procedure. Both the detection methods enables a mechanism to work without the introduction of a new protocol and without any functions installed into the IPv6 nodes. 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) Gopinath, Ettikan May 2002 [Page 8] Internet Draft IPv6 auto-registration procedure November, 2001 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. It is issued to ensure that all configured addresses are likely to be unique on a given link [1]. By monitoring the DAD packets on a link, the Agent will capture it and the packets will be analyzed. Then using ICMPv6 packet, the Agent will issue a query to that node for more information (see section 2 of 3.3). All the information that has been captured will be kept in a specific file for reference and send to the Resolver. It should be noted that the DAD packets could only be detected on a 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 (NI) query and node information reply. The use of ICMPv6 NI query as type 139 and ICMPv6 NI reply type 140 is already defined in [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 ICMPv6 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 for querying information. The ICMP source address should be that of the address where the Agent reside. This is to make sure that the reply is send back to the Agent. 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: Gopinath, Ettikan May 2002 [Page 9] Internet Draft IPv6 auto-registration procedure November, 2001 i) If a node has been detected by capturing 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, the Agent will use it as a destination address in the ICMPv6 NI query requesting for host name (type 2 for qtype field in the ICMPv6 NI query). ii) The Agent uses the predefined link local multicast address, which is FF02::1 as the destination address to do periodic checking on a link to detect any changes or updates to a node. This query need to be sent from time to time so that the changes can be detected earlier to make the new procedure 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. 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, which implements the ICMPv6 node information query. Upon receiving an ICMPv6 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 IPv6 Node Information Queries draft [4]. 3.3.1 Algorithm for detection The Agents continuously monitor for DAD packets in the network. The DAD packets that it captures will be analyzed. It will compare IP address with the information in the database the Agent copied from the Resolver. If the IP address is already exists in the database, the Agent will further query the host name of the node. If there is no information in the database, the Agent will further query the node using the ICMPv6 packet. After getting the necessary information, the Agent will pass the information to the Resolver. 3.3.2 Algorithm using unicast address as destination in the ICMPv6 packet The Agent sends unicast ICMPv6 query to a specific node requesting more information about the node. If there is no reply from the node, Gopinath, Ettikan May 2002 [Page 10] Internet Draft IPv6 auto-registration procedure November, 2001 the Agent will request again. The Agent will kept requesting for few times if there is no reply from the node. Once the node replied, the Agent will extract the information and send it to the Resolver if the information is new or some changes occurred the node. 3.3.3 Algorithm using multicast address as destination in the ICMPv6 packet This is algorithm is similar to unicast query. The different is the target node/s is a multicast group. Once the Agent received the reply from the node, it will queue the information and check in the database copied from the Resolver. If there are changes, then the Agent will send the updated data to the Resolver. 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 Resolver must be configured to communicate with the DNS server so that the information received will be automatically updated. The naming algorithm is used to make sure that the names are unique in link. 3.4.1 Naming The unique feature of the auto-registration procedure is the naming of the IPv6 nodes. The procedure allows the users to set their preferable name for their IPv6 node/s. Even though we don't have the control over the naming, the procedure still decides whether to use the specific name given by each user to their nodes. System administrator also has a choice 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 registered 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. The technique used in this draft is different from the approach documented in "Domain Name Auto-Registration for Plugged-in IPv6 Nodes" [3]. In that approach, the naming is still handled by system Gopinath, Ettikan May 2002 [Page 11] Internet Draft IPv6 auto-registration procedure November, 2001 administrator and no freedom given to each user. The second approach, in that draft, uses predefined name, 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 process simpler, we only use 2 ways for naming a node, which is either configured by system administrator for fix host name for an IPv6 node or use the name given by the node. Another important issue is the format of the naming. Before passing the information captured to the Resolver, the Agent should check if host name is in a valid format. If it is not, then the information given by a node will be dropped. This is to ensure that weird names are not registered into DNS. 3.4.2 Naming algorithm The Resolver first checks the IP address given by the Agent with the IP address in its database. If the IP address is new, the Resolver checks if the name given by the node exists in the database. If not, the IP address together with the host name will be registered into DNS. If the name is already exists, the Resolver will generate a similar name for the node as mentioned in the previous section. 3.5 Location of the Agent and the Resolver in a network Since the Agent must be placed to detect the appearance of IPv6 nodes, the location of the Agent is very much restricted. The best location for the Agent is to be placed together with the router while the Resolver need to be placed with the DNS. Using this method, each link will have an Agent, which is manually configured to directly communicate with the Resolver. This kind of configuration is needed for the Agent to capture the DAD packets issued by the nodes. If the Agent is not installed in every link, the DAD packets cannot be detected because the router will drop all the DAD packets from going out of it. Gopinath, Ettikan May 2002 [Page 12] Internet Draft IPv6 auto-registration procedure November, 2001 +==========+ +#########+ |+--------+| |+-------+| || DNS || || Router|| |+---+----|| |+-------+| | | | |+-------+| |+--------+| || Agent || ||Resolver|| |+-------+| |+--------+| +####+####+ +====+=====| | | | +----+------+---------+----------+-------+--------+ | | +====+====+ +====+====+ |IPv6 node| |IPv6 node| +=========+ +=========+ Fig. 2 The configuration on a single LAN with DNS located in the same LAN Figure 1 shows an example configuration of the entities on a single LAN, with the DNS in the same subnet. 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 will then update the DNS with this latest information. +==========+ |+--------+| || DNS || |+---+----|| | | | |+--------+| ||Resolver|| |+--------+| +====+=====| | +----------+--------------+---------+-----------+ | | | | +####+####+ +####+####+ |+-------+| |+-------+| || Router|| || Router|| |+-------+| |+-------+| |+-------+| |+-------+| || Agent || || Agent || |+-------+| |+-------+| +####+####+ +####+####+ | | -----+-----+--- --------+----+-- Gopinath, Ettikan May 2002 [Page 13] Internet Draft IPv6 auto-registration procedure November, 2001 | | +====+====+ +====+====+ |IPv6 node| |IPv6 node| +=========+ +=========+ Fig.2 Configuration 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 that resides on a DNS. 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 Agents accessing the Resolver at the same time, the procedure 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 the auto-registration procedure is aimed to solve two major problems discussed above. In the future the capability of this new procedure can be extended by adding more functions and make it more secure in transmitting the data. 5. Security Consideration Security is one of the main issues in developing this new procedure. Since the Agent directly sends the information to the Resolver, the information must be send securely. The other transmission that needs to be handled 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 this new technique needs to be discussed further. Gopinath, Ettikan May 2002 [Page 14] Internet Draft IPv6 auto-registration procedure November, 2001 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", Proceedings IEEE MICC2001, Kuala Lumpur, October 21-24. [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 implementation method", Proceedings APAN Conference 2001, Penang, Aug. 20-22. [10] R. Draves, "Default Address Selection for IPv6", , 4 June 2001. Gopinath, Ettikan May 2002 [Page 15] Internet Draft IPv6 auto-registration procedure November, 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 Karupiah 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 8. Revision History Changes from draft-gopinath-host-name-resolution-protocol-ipv6-00 The name has been changed from Host Name Resolution Protocol (HNRP) for IPv6 nodes to IPv6 Hostname auto-registration Procedure The entire algorithm has been modified. Added new part, Resolver-Agent Communication, 3.2.3. In the new part, the method addition and deletion of a node's information has been added. Added section on how the agent should handle the names provided by the nodes, 3.4.1. IPSec statement from the section 5 has been taken out. Reference [6] has been updated as it has been presented in international conference. Gopinath, Ettikan May 2002 [Page 16]