Both of the proposed changes have problems (but can be fixed).
1) FF02:0:0:0:0:2:FF::/104 is not legal since
FF02:0:0:0:0:2:FF is 112 bits long. Perhaps
FF02:0:0:0:0:2:FF00::/104 was meant? What do existing
implementations use?
2) The proposed change makes it the recommended behavior to
respond to all link-local multicast addreses of which the node
is a member, including ones which are always joined. The problem
is in the statement at the end of section 5:
"If the Query was sent to a multicast address, transmission of the
Reply MUST be delayed by a random interval between zero and
MAX_ANYCAST_DELAY_TIME, as defined by IPv6 Neighbor Discovery [9]."
There MAX_ANYCAST_DELAY_TIME is defined as 1 second, which is
reasonable
since anycast is meant for cases where only a very small number of
nodes have the address. With the proposed change, a huge number of
nodes may want to respond and using a 1 second delay is bound to
cause
major problems in some environments. A better comparison would be
to the QueryResponseInterval in MLD, which is meant for cases where
a huge number of nodes may respond, and the default is 10 seconds.
Hence I believe proposed change #2 should not be accepted unless
the random delay time is changed.
I also have two other issues:
3) The security considerations section says:
"An implementation of this protocol SHOULD provide the ability to
control the dissemination of information related to IPv6 Privacy
Addresses [17]. The default action of this policy SHOULD NOT provide
a reponse to a Query that contains a node's Privacy Addresses."
In addition to the above, the threat is that Qtype=3 (Node Addresses)
could be used to easily get the public address associated with a
given privacy address, and hence defeat the point of the privacy
addresses.
Suggest adding something like:
A node MUST NOT include Privacy Addresses in any Node Addresses
response which includes public address, or for which the source
address of the response, the destination address of the request,
or the Subject Address of the request, is a public address.
Similarly, a node MUST not include any address other than the
(single) Privacy Address in any Node Addresses response which
includes the Privacy Address, or for which the source address
of the response, the destination address of the request, or the
Subject Address of the request, is the Privacy Address.
4) Section 6.3 says:
"o C - If set to 1, IPv4-compatible and IPv4-mapped addresses [3]
are
requested. As the IPv4-compatible addresses are now deprecated,
this flag is for backwards compatibility with older
implementations,"
Since IPv4-mapped addresses are not deprecated (at least for use within
APIs like getaddrinfo), the above text is confusing. Does C=1 mean that
the
requester wants the responder's IPv4 addresses in IPv4-mapped form? Or
something else?
I also have some purely editorial comments (typos) which I will send
directly to Brian.
-Dave Thaler
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of
> Brian Haberman
> Sent: Tuesday, January 24, 2006 10:25 AM
> To: IPv6 WG
> Cc: Bob Hinden
> Subject: Re: IPv6 WG Last Call: <draft-ietf-ipngwg-icmp-name-lookups-
> 13.txt>
>
> All,
> The WG Last Call has passed on this with two substantive
comments.
> The following is the proposed changes to -13 to address them. Please
> voice
> your support or disagreement with these changes.
>
>
> 1. Length of appended MD5 hash value:
>
> OLD:
> Compute the MD5 hash [7] of the first label of the
> Subject Name -- the portion beginning with the first
one-octet
> length
> field and up to, but excluding, any subsequent length field.
> Append
> the first 32 bits of that 128-bit hash to the prefix
> FF02:0:0:0:0:2:FF::/104.
>
> NEW:
> Compute the MD5 hash [7] of the first label of the
> Subject Name -- the portion beginning with the first
one-octet
> length
> field and up to, but excluding, any subsequent length field.
> Append
> the first 24 bits of that 128-bit hash to the prefix
> FF02:0:0:0:0:2:FF::/104.
>
> 2. Default configuration text for discarding NI Queries
>
> OLD:
> A node MAY be configured to discard NI Queries to
> multicast addresses other than its NI Group Address(es) but if
> so,
> the default configuration SHOULD be not to discard them. An
> exception is made in the previous rule in the case of the
> All-Routers
> (FF02::2) and All-Nodes (FF02::1) multicast addresses. The
> default
> configuration for responding to NI Queries to these multicast
> addresses MUST be to discard them.
>
> NEW:
> A node MAY be configured to discard NI Queries to
> multicast addresses other than its NI Group Address(es) but if
> so,
> the default configuration SHOULD be not to discard them.
>
> Please respond by 01/31/06.
>
> Regards,
> Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
