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

From: [email-masked]
Date: Wed, 23 Jun 1999 08:02:18 -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-04.txt
	Pages		: 11
	Date		: 22-Jun-99
	
This document describes an experimental protocol for asking an IPv6
node to supply certain network information, such as its fully-
qualified domain name.  IPv6 implementation experience has shown
that direct queries for FQDN are useful, and a direct query
mechanism for other information has been requested.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-04.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-04.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-04.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: Randy Bush <[email-masked]>
Date: Wed, 23 Jun 1999 06:39:41 -0700 (PDT)

Upon receiving an NI Query, the Responder must check the Query's
    IPv6 destination address and discard the Query without further
    processing if it is not one of the Responder's unicast or anycast
    addresses.  A Responder must also silently discard a Query whose
    subject address or name (in the Data field) does belong to that
    node.

/does belong/does not belong/?

randy
--------------------------------------------------------------------
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: "Matt Crawford" <[email-masked]>
Date: Wed, 23 Jun 1999 09:23:21 -0500

> /does belong/does not belong/?

Right.  That's one.

---

From: Randy Bush <[email-masked]>
Date: Wed, 23 Jun 1999 07:52:52 -0700 (PDT)

the nWord and nSkip stuff seems to add complexity to the protocol and hence
the code.  it can not break-even until there are more than 96 qtypes, and
there are currently only four.  so this all seems to be an escape for user-
defined etc. qtypes.  is this *really* worth the complexity?

in 5.3.1. Discussion

    Because a node can only answer a FQDN Request when it is up and
    reachable, it may be useful to create a proxy responder for a group
    of nodes, for example a subnet or a site.  Such a mechanism is not
    addressed here.

in fact, it would seem to be specifically precluded by

    A Responder must also silently discard a Query whose subject address
    or name (in the Data field) does belong to that node.
                                    ^ not

in 5.4. Node Addresses

there seems to be no way to indicate that the reply set of addresses is
incomplete for reasons other than space, e.g. security through obscurity.

in 5.4.A, i am having trouble parsing the plurality of the last part of

    If 0, only those addresses are requested which belong to the interface
    (or any one interface) which has the Subject Address.

randy

---

From: "Matt Crawford" <[email-masked]>
Date: Wed, 23 Jun 1999 13:29:04 -0500

> defined etc. qtypes.  is this *really* worth the complexity?

It breaks even at the first non-standards-track Qtype.  Is it worth
it?  OK, that question is now on the floor.

> in fact, it would seem to be specifically precluded by [...]

OK, that's two.  Change to:

     A Responder must also silently discard a Query whose subject
     address or name (in the Data field) does not belong to that node,
     unless it is providing proxy service for that subject.

> incomplete for reasons other than space, e.g. security through obscurity.

Do those who want to lie by omission want to draw attention to the
fact?  I could change " for space reasons" to ", for example, for
space reasons" but I'd rather have the Querier able to decide cleanly
whether to start probing interface-by-interface if it wants to build
a complete list.

>     (or any one interface) which has the Subject Address.

It's supposed to be saying that if the A flag is zero, the Querier
wants only addresses belong to the interface that has the subject
address, but if there's more than one such interface, answer about
any one of them.  Can there be more than one?  Yes.  Is this the most
useful thing to do if there is more than one?  Maybe.  Another choice
would be to answer about all such interfaces.

				Matt