Internet DRAFT - draft-gopinath-host-name-resolution-protocol-ipv6
draft-gopinath-host-name-resolution-protocol-ipv6
S.Gopinath Rao
INTERNET-DRAFT NRG, USM Malaysia
<draft-gopinath-host-name-resolution-protocol-ipv6-00.txt>
Expires: 29 February 2002 K. Ettikan
Intel ASG, Malaysia
29 August 2001
Host Name Resolution Protocol (HNRP) for IPv6 nodes
<draft-gopinath-host-name-resolution-protocol-ipv6-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes a 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
<draft-kitamura-ipv6-name-auto-reg-00.txt>
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_, <draft-kitamura-ipv6-name-auto-reg-00.txt>, 13 July 2001.
[4] M. Crawford, _IPv6 Node Information Queries_, <draft-ietf-
ipngwg-icmp-name-lookups-07.txt>, 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", <draft-ietf-
ipng-default-addr-select-05.txt>, 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]
