Subject: I-D ACTION:draft-gopinath-host-name-resolution-protocol-ipv6-00.txt

From: [email-masked]
Date: Thu, 30 Aug 2001 07:14:11 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Host Name Resolution Protocol (HNRP) for IPv6 nodes
	Author(s)	: G. Sinniah et al.
	Filename	: draft-gopinath-host-name-resolution-
                          protocol-ipv6-00.txt
	Pages		: 13
	Date		: 29-Aug-01
	
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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-gopinath-host-name-resolution-protocol-ipv6-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-gopinath-host-name-resolution-protocol-ipv6-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-gopinath-host-name-resolution-protocol-ipv6-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 31 Aug 2001 13:36:39 +0300 (EEST)

On Thu, 30 Aug 2001 [email-masked] wrote:

As is pointed out in the draft, this is similar to (presented at IETF51):

     2.1 Domain Name Auto-Registration for plugged in IPv6
         <draft-kitamura-ipv6-name-auto-reg-00.txt>

The differences are mentioned along the way in the draft, but I'd like to
have certain key points mentioned in the 'Study on existing and similar
application' section; at least:

 - "push" (kitamura) vs. "pull" (this)
 - hostname/ip collisions handling
(cannot overwrite already existing entries trivially)

I think this method could actually be made workable, but there are some
tough issues with duplicate host/ip issues to resolve.

A few notes:

 - I find the name really cheesy.  Is this really a _protocol_ as such?
Resolution is often associated with the opposite kind of action, by client
hosts.

 - I'm not sure whether there should be a moral requirement not to require
changes to clients; as it is, I doubt all that many implementations
(especially those which need this most) even implement / enable by default
ICMPv6 NI queries by default...

 - When talking about ICMPv6, might it make sense to use ICMPv6 NI, at
least in a few places?  It is not part of official ICMPv6 yet, and IMO
text wasn't clear that it is _that_ part of ICMP that's going to be used
(especially chapter 2).

 - Wording in 3.1 appears to make the assumption that this would only be
used by nodes that have stateless address autoconfiguration enabled.

 - 3.2.2, First paragraph, something missing at the end.

 - 3.3, part 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).

 ==> you probably mean sec 2 of 3.3 ie. the next section?

 - what about the scenario where multi-link subnetting is being used, a
node moves from one subnet to another -- there are potentially two agents
updating the same address/hostname to DNS.  Naming algorithm suggests that
a new name will be assigned.  (or pretty much require that multi-link
subnet router provides the functionality always for all the links).

 - there should be a mechanism for scrubbing the old junk data from the
DNS and/or host files.

 - please be a little more specific with the pseudo-language, e.g.:

     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

 ==> update DNS via resolver (3.4)

 ==> if a node's IP address changes (e.g. NIC change), agent accepts the
new data, but updating it to resolver fails.  There seems to be no
procedure in agent<->resolver communication to withdraw ip
addresses/hostnames.

 - the agent probably should check that the hostname is of valid form; ie.
contains only 0-9 a-z A-Z - . or whatever.  (or else the implementation
must be really careful in case the clients send some weird names e.g. with
null-chars or whatever).

 - should hostnames be in FQDN form?  If not, this adds some comlexity to
agent/resolver side.  (from autoconfiguration point of view, the contrary
might be better, but IMO hostname is FQDN is the current naming practise,
AFAIS).

 - IPSEC security pixie dust ...

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------