Hello, Matt,
Sorry for disturbing you so often, but if I remember correctly, I've
never seen any responses to the attached mail.
As an earlier implementer (and also a user/lover) of
icmp-name-lookups, I really want to know your opinion, too.
If you have already sent a reply to itojun or to the list, could you
kindly resend it to the list, please? Again, I apologize if I miss a
previous response.
Thanks,
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
Matt, I really need your input on this. Note that we really are
implementing code based on the document, and in a serious need for
clarification.
itojun
------- Forwarded Messages
Return-Path: <[EMAIL PROTECTED]>
Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31])
by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id AAA17608
for <[EMAIL PROTECTED]>; Wed, 10 May 2000 00:57:51 +0900 (JST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA24425;
Tue, 9 May 2000 09:57:31 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA29117;
Tue, 9 May 2000 08:53:54 -0700 (PDT)
Received: (from majordomo@localhost)
by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e49FVIp27307
for ipng-dist; Tue, 9 May 2000 08:31:18 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e49FV4727300
for <[EMAIL PROTECTED]>; Tue, 9 May 2000 08:31:05 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA12781
for <[EMAIL PROTECTED]>; Tue, 9 May 2000 08:31:00 -0700 (PDT)
Received: from lychee.itojun.org (dhcp0.itojun.org [210.160.95.106])
by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA04072
for <[EMAIL PROTECTED]>; Tue, 9 May 2000 09:30:49 -0600 (MDT)
Received: from kiwi.itojun.org (localhost [127.0.0.1])
by itojun.org (8.10.0/3.7W) with ESMTP id e49FUQE05019;
Wed, 10 May 2000 00:30:26 +0900 (JST)
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject: icmp-name-lookups-05.txt>: NOOP
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
From: Jun-ichiro itojun Hagino <[EMAIL PROTECTED]>
Date: Wed, 10 May 2000 00:30:26 +0900
Message-ID: <[EMAIL PROTECTED]>
Sender: [EMAIL PROTECTED]
Precedence: bulk
X-Filter: mailagent [version 3.0 PL68] for [EMAIL PROTECTED]
icmp-name-lookups-05 says the following.
>5.1. NOOP
>
> This NI type has no defined flags and never has a Data field. A
> Reply to a NI NOOP Query tells the Querier that a node with the
> Queried Address is up and reachable, implements the Node Information
> protocol, and incidentally happens to reveal whether the Queried
> Address was an anycast address.
However, since these seem to be no Code defined for empty Data field,
it is not possible for a Querier to transmit NOOP packet with empty
Data field. Definition of NOOP and Code seems, at least, contradictory.
Or is the evaluation of Code field dependent to Qtype field?
(i.e. we should ignore Code field if Qtype equals to NOOP or
Qtype equals to Supported Qtypes)
itojun
- --------------------------------------------------------------------
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 PROTECTED]
- --------------------------------------------------------------------
------- Message 2
Return-Path: <[EMAIL PROTECTED]>
Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31])
by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id BAA06859
for <[EMAIL PROTECTED]>; Thu, 18 May 2000 01:36:13 +0900 (JST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA28739;
Wed, 17 May 2000 10:34:53 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA03043;
Wed, 17 May 2000 07:30:43 -0700 (PDT)
Received: (from majordomo@localhost)
by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4HE2aH03546
for ipng-dist; Wed, 17 May 2000 07:02:36 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4HE2L703539
for <[EMAIL PROTECTED]>; Wed, 17 May 2000 07:02:22 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA02818
for <[EMAIL PROTECTED]>; Wed, 17 May 2000 07:02:20 -0700 (PDT)
Received: from lychee.itojun.org (dhcp0.itojun.org [210.160.95.106])
by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA12895
for <[EMAIL PROTECTED]>; Wed, 17 May 2000 08:02:18 -0600 (MDT)
Received: from kiwi.itojun.org (localhost [127.0.0.1])
by itojun.org (8.10.0/3.7W) with ESMTP id e4HDX8f04271;
Wed, 17 May 2000 22:33:08 +0900 (JST)
cc: [EMAIL PROTECTED]
to: [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: ipngwg-icmp-name-lookups-05: dns compression
From: Jun-ichiro itojun Hagino <[EMAIL PROTECTED]>
Date: Wed, 17 May 2000 22:33:08 +0900
Message-ID: <[EMAIL PROTECTED]>
Sender: [EMAIL PROTECTED]
Precedence: bulk
X-Filter: mailagent [version 3.0 PL68] for [EMAIL PROTECTED]
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 PROTECTED]
- --------------------------------------------------------------------
------- End of Forwarded Messages
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
