This proposal opens up a huge can of worms which might be better left closed.
A host can have multiple interfaces, mutiple addresses on an interface,
multiple interfaces with the same address, multiple domain names for
an address, and there can also be multiple addresses for a domain.
A single domain can apply to multiple hosts, either via multiple addresses
or via a single address and an IP fanout device. A host inherently
knows about its interfaces and the addresses assigned to them, but the
relationship between DNS names and addresses is maintained elsewhere.
So the whole notion of "a node's domain name[s]" gets pretty sticky,
even if you restrict that query to the names corresponding to a single
IP address.
My biggest concern about this proposal is that it doesn't specify the
purposes for which this service can be used. To put it another way,
what services can rely on this information, and what services are
allowed to break if the result from the ICMPv6 query doesn't correspond
to what can be obtained from DNS (or to what applications running on
that host believe)?
For instance, might an application assume that if it obtains multiple
addresses for a host using this service that it can communicate with
an application on that host using any of those addresses ?
(which would fail given the quite common practice of virtual hosting)
or if it obtains multiple domain names for an address, can an application
assume that the domain names are equivalent? (they're not, because either
of those domain names could also reach other hosts, and the two sets of
hosts might not be the same)
There should be only one authoritative source of the binding betweeen
a DNS name and any addresses associated with that name, and it should
probably be DNS. The notion that "sometimes DNS is right, and sometimes
the host is right" makes it hard to write code that behaves reliably.
Another concern I have is that this proposal seems to push DNS names
into a lower layer of the protocol stack and thereby embeds them
more deeply in the Internet architecture. I believe it is highly
desirable to keep these as completely separate layers. The
separation of function between IP and DNS allows us to evolve each
of them separately, even to the point of replacing IP (which we
are doing) or providing alternate lookup services to DNS (which
is necessary if we want those lookup services to work efficiently)
The separation also allows problems with IP networks and/or
applications to be diagnosed separately from DNS - it allows us
to debug such problems with the DNS layer out of the picture.
On a different level this proposal exposes a conflict between various
autoconfiguration architectures which has been brewing for some time -
does the host assert its name and/or address to the network or does the
network tell the host its name and/or address? It does this by creating
an alternate way to find a name-to-address bindings when in the
past the only publically available source of such information
(and hence, the assumed authority for such information) was DNS.
It would be good to sort out this conflict, because sorting this out
is needed before autoconfiguration can really work effectively on a large
scale. But sorting this out is probably needed before people start
building things which depend on this ICMPv6 service. And sorting this
issue out probably also means answering the question of what is a
reasonable lifetime for the binding between a host and an IP address.
These will not be easy questions to answer, particularly because people's
assumptions about what is reasonable (and where to distribute the pain
of changing these things) vary widely. But IMHO we need to answer
them before we start embedding DNS names more deeply into network
stacks, and especially before we start relying on this service.
There's also a security problem with defining a means by which hosts
can be expected to expose information about their DNS names, the
addresses they use, the networks they are on, etc. This is yet
another source of information that would need to be filtered by
networks that didn't want to expose such information to external sites.
In a nutshell, my recommendations are:
- document the intended use (diagnostics?) and clearly specify
that the authoritative source of these mappings is in DNS
- make this Experimental rather than Proposed
- document the security issues wrt inappropriate exposure
- require that implementations be able to turn off this feature,
and that it be disabled by default. actually hosts should probably
require explicit configuration regarding which domain names and
which addresses to advertise by this method.
Keith
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
