Subject: I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-08.txt

From: [email-masked]
Date: Wed, 25 Jul 2001 06:31:58 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPNG Working Group of the IETF.

	Title		: IPv6 Node Information Queries
	Author(s)	: M. Crawford
	Filename	: draft-ietf-ipngwg-icmp-name-lookups-08.txt
	Pages		: 15
	Date		: 24-Jul-01
	
This document describes a protocol for asking an IPv6 node to supply
certain network information, such as its hostname or fully-qualified
domain name.  IPv6 implementation experience has shown that direct
queries for a hostname are useful, and a direct query mechanism for
other information has been found useful in serverless environments
and for debugging.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-08.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-ietf-ipngwg-icmp-name-lookups-08.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-ietf-ipngwg-icmp-name-lookups-08.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: Thu, 26 Jul 2001 23:37:39 +0300 (EEST)

On Wed, 25 Jul 2001 [email-masked] wrote:

Some comments:

--8<--
                   IPv6 implementation experience has shown that direct
    queries for a hostname are useful, and a direct query mechanism for
    other information has been found useful in serverless environments
    and for debugging.
--8<--

Some reference to an usefulness report (if one exists) would be nice; I
don't think that many implementations implement, or enable, NI queries by
default, and we've survived..

I'm not saying NI queries would be useless, but I'm asking whether they're
really _all_ that useful, other than as a nifty trick or in heavy
debugging..

(In any case I think this is probably experimental track material)

--8<--
4.  Message Processing

    If true communication security is required, IPsec [2401] must be
    used.
--8<--

I'd probably say "IPsec [2401] or a similar mechanism must be used."
(unless it's viewed that IPsec will always be the one and the only method
to gain security like this)

Further in the same chapter:

--8<--
    Next, if Qtype is unknown to the Responder, it must return a NI
    Reply with ICMPv6 Code = 2 and no Reply Data.  The Responder should
    rate-limit such replies as it would ICMPv6 error replies [2463,
    2.4(f)].

    Next, the Responder should decide whether to refuse an answer, based
    on local policy.  (See "Security Considerations" for recommended
    default behavior.)  If an answer is refused, the Responder may send
    a NI Reply with ICMPv6 Code = 1 and no Reply Data.  Again, the
    Responder should rate-limit such replies as it would ICMPv6 error
    replies [2463, 2.4(f)].
--8<--

There are reasons for these to be in this order; however, depending on how
strict security policies are assumed to be, this order might expose too
much of the local implementation (which query types are understood etc.)
with no real way of stopping it (as security checks are only done for
packets for which the reply is valid).

Is this an issue worth considering at this "layer", or something to be
done by filtering particular ICMP6 types?

--8<--
5.3.  Node Name

    TTL         The number of seconds that the name may be cached.  For
                compatibility with DNS [1035], this is a 32-bit signed,
                2's-complement number, which must not be negative.
--8<--

If the number _is_ negative, the behaviour of the recipient at so TTL'ed
message appears to be unspecified?  This is one thing that might create
some hassle if the value was just blindly copied without checking.  Is
this the intent?

--8<--
7.  Security Considerations

    In a large Internet with relatively frequent renumbering, the
    maintenance of of KEY and SIG records [2535] in the zones used for
    address-to-name translations will be no easier [....]
--8<--

will -> would (same for the other instances); real needs for "relatively
frequent renumbering" are still under some dispute I think.

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