Enclosed are the comments Bob collected and my response. A revised
draft has been submitted to the i-d editor.
Date: Mon, 11 Dec 2000 10:49:39 -0800
From: Bob Hinden <[EMAIL PROTECTED]>
Subject: Comments on "IPv6 Node Information Queries"
To: Matt Crawford <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Message-id: <[EMAIL PROTECTED]>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=us-ascii
Matt,
I will forward you the comments I found on the "IPv6 Node Information
Queries" IETF last call.
Let me know what you think.
Bob
------- =_aaaaaaaaaa0
Date: Mon, 11 Dec 2000 10:50:28 -0800
From: Bob Hinden <[EMAIL PROTECTED]>
Subject: Fwd: Re: Last Call: IPv6 Node Information Queries to Proposed Standard
X-Sender: [EMAIL PROTECTED]
To: Matt Crawford <[EMAIL PROTECTED]>
Message-id: <[EMAIL PROTECTED]>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=us-ascii
From: Keith Moore <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject: Re: Last Call: IPv6 Node Information Queries to Proposed Standard
X-SUBJECT-MSG-FROM: The IESG <[EMAIL PROTECTED]>
Date: Thu, 31 Aug 2000 14:48:45 -0400
Sender: [EMAIL PROTECTED]
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
------- =_aaaaaaaaaa0
Date: Mon, 11 Dec 2000 10:54:46 -0800
From: Bob Hinden <[EMAIL PROTECTED]>
Subject: Fwd: Re: Last Call: IPv6 Node Information Queries to Proposed Standard
X-Sender: [EMAIL PROTECTED]
To: Matt Crawford <[EMAIL PROTECTED]>
Message-id: <[EMAIL PROTECTED]>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=us-ascii
Date: Mon, 11 Sep 2000 02:19:31 +0900
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
<[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Last Call: IPv6 Node Information Queries to Proposed Standard
User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.7 Mule/4.0 (HANANOEN)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
X-Dispatcher: imput version 980905(IM100)
Lines: 55
>>>>> On Thu, 31 Aug 2000 12:36:10 -0400,
>>>>> The IESG <[EMAIL PROTECTED]> said:
> 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 PROTECTED] or [EMAIL PROTECTED] mailing lists by September 13, 2000.
I admit that I should've made comments on the draft earlier, but
please let me add a final (I hope this is final) comment.
The 07 draft defines TTL of an address used in the node information
messages as follows:
The Responder must fill in the TTL field of the Reply with a
meaningful value if possible. That value should be one of the
following.
The remaining lifetime of a DHCP lease on the Subject Address;
The remaining Valid Lifetime of a prefix from which the Subject
Address was derived through Stateless Autoconfiguration [2461,
2462];
The TTL of an existing AAAA or A6 record which associates the
Subject Address with the DNS Name being returned.
(page 8, Section 4.3)
Possible range of those TTLs are different:
According to draft-ietf-dhc-v6exts-12.txt defines, the Valid (lease)
lifetime of an IPv6 address configured by DHCPv6 is a 32bits integer
(in seconds). (I'm not sure if the value is signed or not, and if it
has some range only by the draft).
According to RFC 2461, the Valid lifetime of an IPv6 address through
stateless autoconfiguration is an unsigned 32bits integer (in
seconds), and the "all-1 value (0xffffffff)" has a special meaning,
i.e. infinity.
According to RFC 2181, the TTL value for a DNS record is an unsigned
integer from 0 to 2^31 - 1.
The easiest way to solve the ambiguity would be introduding an
additional field for the TTL field to specify the type of
TTL. However, this would break backward compatibility (again!)...
Currently, I'm not sure the best way, but we'll surely need some
clarification here.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
------- =_aaaaaaaaaa0
Date: Mon, 11 Dec 2000 10:51:52 -0800
From: Bob Hinden <[EMAIL PROTECTED]>
Subject: Fwd: Re: Last Call: IPv6 Node Information Queries to Proposed Standard
X-Sender: [EMAIL PROTECTED]
To: Matt Crawford <[EMAIL PROTECTED]>
Message-id: <[EMAIL PROTECTED]>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=us-ascii
From: Robert Elz <[EMAIL PROTECTED]>
To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
<[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Last Call: IPv6 Node Information Queries to Proposed Standard
Date: Mon, 11 Sep 2000 17:40:28 +1100
Sender: [EMAIL PROTECTED]
Date: Mon, 11 Sep 2000 02:19:31 +0900
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| The easiest way to solve the ambiguity would be introduding an
| additional field for the TTL field to specify the type of
| TTL. However, this would break backward compatibility (again!)...
| Currently, I'm not sure the best way, but we'll surely need some
| clarification here.
Actually, the easiest way is just to define it as an unsigned integer
(values 0 .. 2^32 - 1) - with 0xffffffff defined specially if needed.
A negative TTL has no useful meaning, so even if the dhcpv6exts (the version
with the '-' instead of the 'p' in the draft name expired ages ago) draft is
intending to allow a negative value for the valid lease lifetime for some
reason, sending 0 in the node information query would be reasonable if given
negative input (though what a negative value would mean I have no idea ..
"you should have returned this address I am just giving you 30 minutes
ago" ?).
That draft needs a better definition of this field.
Then all rational TTL values can be included - the DNS can only handle half
of what can be in the node information reply, but that's OK, what matters is
that the DNS response can be loaded into the node info field, not the other
way.
kre
------- =_aaaaaaaaaa0
Date: Mon, 11 Dec 2000 10:50:40 -0800
From: Bob Hinden <[EMAIL PROTECTED]>
Subject: Fwd: Re: Last Call: IPv6 Node Information Queries to Proposed Standard
X-Sender: [EMAIL PROTECTED]
To: Matt Crawford <[EMAIL PROTECTED]>
Message-id: <[EMAIL PROTECTED]>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=us-ascii
To: Keith Moore <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Last Call: IPv6 Node Information Queries to Proposed Standard
From: [EMAIL PROTECTED]
Date: Tue, 05 Sep 2000 18:17:52 +0900
>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)?
at IETF48 zeroconf WG and dnsext WG, I heard some comment on making
distinction between full qualified domain name (which is on the DNS
database), and hostname (which is configured onto each of the host,
and do not necessarily the same as FQDN). Not sure if it has wide
concensus, but it made some sense to me.
- we look up FQDN through DNS database
- we look up hostname through /etc/hosts
(i'm not sure if it is really correct)
- gethostname(3) returns hostname, not FQDN
it is kind of confusing, but this gave me a way to understand the
current situation. if we are okay with the distinction,
we may be able to state the following:
- if we are to lookup some name via ICMPv6 name lookup, it would
be hostname, not FQDN.
we need to update name-lookup draft again, though.
of course, the above distinction could be very wrong. but then,
how should we understand the current situation with gethostname(3)?
itojun
------- =_aaaaaaaaaa0
Date: Mon, 11 Dec 2000 10:54:41 -0800
From: Bob Hinden <[EMAIL PROTECTED]>
Subject: Fwd: Re: Last Call: IPv6 Node Information Queries to Proposed Standard
X-Sender: [EMAIL PROTECTED]
To: Matt Crawford <[EMAIL PROTECTED]>
Message-id: <[EMAIL PROTECTED]>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=us-ascii
From: Keith Moore <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc: Keith Moore <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Last Call: IPv6 Node Information Queries to Proposed Standard
Date: Tue, 05 Sep 2000 06:54:46 -0400
Sender: [EMAIL PROTECTED]
> >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)?
>
> at IETF48 zeroconf WG and dnsext WG, I heard some comment on making
> distinction between full qualified domain name (which is on the DNS
> database), and hostname (which is configured onto each of the host,
> and do not necessarily the same as FQDN). Not sure if it has wide
> concensus, but it made some sense to me.
> - we look up FQDN through DNS database
> - we look up hostname through /etc/hosts
> (i'm not sure if it is really correct)
> - gethostname(3) returns hostname, not FQDN
my experience is more like:
- hostname is set as part of system configuration (during boot)
(you can't look it up in /etc/hosts because you need to know
what to look for)
- hostname can either be an alias (usually just a label) or an FQDN
- you can sometimes look up hostname in local DNS and get back an
FQDN
- the mapping from hostname to FQDN might or might not involve
adding a domain suffix to the hostname.
> it is kind of confusing, but this gave me a way to understand the
> current situation. if we are okay with the distinction,
> we may be able to state the following:
> - if we are to lookup some name via ICMPv6 name lookup, it would
> be hostname, not FQDN.
> we need to update name-lookup draft again, though.
okay, but this still doesn't answer the question. what is the purpose of
this service, and what things are allowed to depend on it?
Keith
------- =_aaaaaaaaaa0
Date: Mon, 11 Dec 2000 10:54:46 -0800
From: Bob Hinden <[EMAIL PROTECTED]>
Subject: Fwd: Re: Last Call: IPv6 Node Information Queries to Proposed Standard
X-Sender: [EMAIL PROTECTED]
To: Matt Crawford <[EMAIL PROTECTED]>
Message-id: <[EMAIL PROTECTED]>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=us-ascii
To: Keith Moore <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
X-Template-Reply-To: [EMAIL PROTECTED]
X-Template-Return-Receipt-To: [EMAIL PROTECTED]
X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2
Subject: Re: Last Call: IPv6 Node Information Queries to Proposed Standard
From: [EMAIL PROTECTED]
Date: Tue, 05 Sep 2000 23:29:53 +0900
>> it is kind of confusing, but this gave me a way to understand the
>> current situation. if we are okay with the distinction,
>> we may be able to state the following:
>> - if we are to lookup some name via ICMPv6 name lookup, it would
>> be hostname, not FQDN.
>> we need to update name-lookup draft again, though.
>okay, but this still doesn't answer the question. what is the purpose of
>this service, and what things are allowed to depend on it?
under zeroconf situation, you may want to lookup:
- an address from a hostname, using ICMPv6 name lookup (query type =
node addresses) toward ff02::1 (or NI group address)
- an address to a hostname, using ICMPv6 name lookup (query type =
DNS name/hostname) toward the address
the message type can be used just like mDNS proposals (see
draft-aboba-dnsext-mdns-01.txt).
also, it has been really useful for debugging.
not 100% sure if the use of icmp6 is a good idea or not. also,
as you
noted, icmp6 may seem like a layer violation. if you have better
suggestion, please let me know.
(NOTE: I understand the security issues by giving away more
information to bad guys)
itojun
------- =_aaaaaaaaaa0--
Response to comments on "IPv6 Node Information Queries"
In response to Keith's comments I am expanding the abstract to say
more about the environments in which this is expected to be used, and
to disclaim any intent to override DNS authority when DNS is
available. I'm also referring to the names which may be the subjects
or results of NI queries as simply "names" rather than "domain
names", and when necessary for clarity, adding the words "either
fully-qualified or single-component".
His comment
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)
resolves itself if one notes that the subject of a query is never "a
host" but only "a name" or "an address". If you find multiple
addresses for a name then, yes, you may reasonably expect to find
the same service instance at as many of those addresses as the
routing system lets you reach. I think we're all in agreement there.
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.
In a perfect world this would be so. But we already left that world
some time ago when ISPs stopped (or failed to start) registering the
names preferred by the end users. We also have operating systems
which let the user assign a name which may never be registered in
DNS.
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.
This is exaggeration. This new mechanism doesn't route any packets
or provide a new way to fill in the IP header. It's a new name and
address information scheme, yes, but it doesn't mix naming up with
packet delivery in any way.
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?
That conflict is not new with this protocol. The DHCP hostname
extension flows in either direction, and some servers register the
name you choose, and others pick you one. Still others stay out of
the naming game altogether.
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.
It's easy for the FNAFH (fascist network admin from hell) to block
this all at the border, or at each link. But it certainly is worth
adding some guidance about configuring each node's "refuse to answer"
option which is already there (ICMPv6 Code=1 in a reply). A
SHOULD-level default setting of "refuse queries from global addresses"
sounds about right. (And change the "MUST send a Reply with TTL=0 and
no names"" in section 4.3 to allow the refusal.) I'm also adding
that responders SHOULD rate limit replies.
Tatuya's point is a good one and I will simply add text saying that
the TTL field is limited to 2^31-1, even if the node's idea of the
lifetime is longer. That also cover's kre's comment.
Itojun's comment, which brings input from zeroconf and dnsext, is
accepted through the change of making a clear distinction between the
names in Node Information and "DNS Names".
The last pair of messages between Keith and Itojun are addressed by
the expanded introduction added in response to Keith's first comment.
I include that intruction here:
Introduction
This docment specifies a mechanism for discovering information about
names and addresses (and is extensible to deal with other
information). In the global internet, the Domain Name System [1034,
1035] is the authoritative source of such information and this
specifcation is not intended to supplant or supersede it. And in
fact, in a well-supported network the names and addresses dealt with
by this mechanism will be the same ones, and with the same
relationships, as those listed in the DNS.
This new Node Information protocol does provide facilities which are
not found in the DNS - for example discovering relationships between
addresses without reference to names. And the functions that do
overlap with the DNS may be useful in serverless environments, for
debugging, or in regard to link-local and site-local addresses [2373]
which often will not be listed in the DNS.
