On Thu, 30 Aug 2001 [EMAIL PROTECTED] 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 PROTECTED]
--------------------------------------------------------------------
