Subject: ipngwg-icmp-name-lookups-05: dns compression

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 17 May 2000 22:33:08 +0900

Hello, again I have couple of questions about name-lookups-05.
	if we (as ipngwg) are more likely to go to multicast DNS than 
	icmp name lookup, please tell us so - we at KAME are very interested
	in zeroconf-oriented configurations and love to provide/test
	common local name lookup mechanisms without config twists.

itojun

1. DNS compression
	the draft uses DNS wire format (as defined in RFC1035) in two
	places; subject DNS name in queries (very last paragraph in section 3),
	and DNS names in replies (5.3).  My question is: if we are to use
	DNS message compression (RFC1035 4.1.4), where should we count
	offset from?  Will it be the beginning of ICMPv6 message,
	or beginning of the part formatted by DNS wire format?
	or is DNS message compression is not permitted at all?

2. restriction on IPv6 destination address
	for validation on receiving side, section 4 says like the folloing:

>   Upon receiving a NI Query, the Responder must check the Query's IPv6
>   destination address and discard the Query without further processing
>   unless it is one of the Responder's unicast or anycast addresses, a
>   NI Group Address for a name belonging to the Responder, or a NI
>   Group Address for a name for which the Responder is providing proxy
>   service.

	considering that ICMPv6 specification recommends a node to reply to
	ICMPv6 echo request toward multicast destination, I'm not sure if
	the above restriction buys us much protection.  I can query hostnames
	for all nodes in the site, by the following steps:
	- ping6 ff05::1
	- for all nodes answered, send node information query, with subject
	  address (equal to IPv6 destination)

	I agree that icmp6 to wide-area multicast would be insecure, however,
	at least name-lookup draft is not very consistent with ICMPv6 RFC.
	Also, we find name lookup queries to ff02::1 very useful as debugging
	tool.  How about permitting these?
	- unicast address
	- anycast address
	- link-local multicast addresses the node joins
	the last item is less strict than 05 draft.  sender rule needs to
	be changed too if we take this route.

4. Subject address validation
	for validation on receiving side, section 4 says like the folloing:

>   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.  A
>   single-component Subject Name matches any fully-qualified name whose
>   first label matches the Subject.  All name matching is done in a
>   case-independent manner.

	What defines "address belongs to node"?  for example, is "::1"
	valid as subject address?  all IPv6 nodes supposed to have
	::1 on loopback interface, so ::1 is valid for all nodes.

	Is a query packet with empty Subject valid?  what should the code
	field be?

	also, we may have scope issue here.  What should happen in the
	following cases:
	- if you got node information query from/to global IPv6 address,
	  with link-local subject address for your node
	- if we got query from/to link-local address on interface A, with
	  link-local subject address for interface B
	- if your (receiving) node node offers proxy service, and you've got
	  scoped subject address in a query packet, how should we interpret
	  the subject address?
	what is the suggested behavior?

5. code field on queries
	again, I don't understand how should a responding node must validate
	code field and subject field in the query message.  (this is a recap)

	I'm not sure about the following:
	- what should be put into code field when subject part needs to
	  be empty (NOOP, supported qtypes)
	- if it is legal to leave Subject portion of query empty,
	  what should be put into code field? 

	Basically, I think we'd need a table of valid combinations.  the
	text leaves many cases unanswered.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------