Subject: FW: IPv6 WG Last Call: <draft-ietf-ipngwg-icmp-name-lookups-13.txt>

From: "Pashby, Ronald W CTR NSWCDD-B35" <[email-masked]>
Date: Fri, 6 Jan 2006 06:43:33 -0600

I was confused when I read the draft about the change to the multicast address. I reread the draft and realized where the confusion arrises in the second paragraph of section 5 it states:
	"Append the first 32 bits of that 128-bit hash to the prefix FF02:0:0:0:0:2:FF::/104." 

Should this read: 
	"Append the first 24 bits of that 128-bit hash to the prefix FF02:0:0:0:0:2:FF::/104."

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Bob Hinden
Sent: Thursday, January 05, 2006 18:34
To: IPv6 WG
Subject: IPv6 WG Last Call: <draft-ietf-ipngwg-icmp-name-lookups-13.txt>

This starts a two week IPv6 working group last call on publishing

	Title		: IPv6 Node Information Queries
	Author(s)	: M. Crawford, B. Haberman
	Filename	: draft-ietf-ipngwg-icmp-name-lookups-13.txt
	Pages		: 15
	Date		: 2006-1-4

as an Experimental RFC.  Please send substantive comments to the IPv6  
mailing list.  Editorial comments can be sent to the authors.  Also,  
note the current discussion on the IPv6 mailing list started by David  
Malone.

This last call will end on January 19, 2005.

Regards,
Bob

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Pashby, Ronald W CTR NSWCDD-B35" <[email-masked]>
Date: Wed, 25 Jan 2006 07:24:31 -0600

I agree with the changes too
Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
David Malone
Sent: Wednesday, January 25, 2006 5:33
To: Brian Haberman
Cc: Bob Hinden; IPv6 WG
Subject: Re: IPv6 WG Last Call:
<draft-ietf-ipngwg-icmp-name-lookups-13.txt>

On Tue, Jan 24, 2006 at 01:24:59PM -0500, Brian Haberman wrote:
>      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.

Looks good to me too.

	David.

---

From: "Dave Thaler" <[email-masked]>
Date: Wed, 25 Jan 2006 15:29:37 -0800

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

> From: [email-masked] [mailto:[email-masked]] 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,
> 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