Subject: Last Call: IPv6 Node Information Queries to Proposed Standard

From: The IESG <[email-masked]>
Date: Thu, 31 Aug 2000 12:36:10 -0400

The IESG has received a request from the IPNG Working Group to consider
IPv6 Node Information Queries
<draft-ietf-ipngwg-icmp-name-lookups-07.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by September 13, 2000.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-07.txt

--------------------------------------------------------------------
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]
--------------------------------------------------------------------

---

From: Keith Moore <[email-masked]>
Date: Thu, 31 Aug 2000 14:48:45 -0400

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