Subject: Comments on draft-ietf-ipngwg-icmp-name-lookups-12.txt

From: "Pashby, Ronald W CTR NSWCDD-B35" <[email-masked]>
Date: Mon, 18 Jul 2005 14:13:54 -0500

In the second paragraph of section 5 it reads:
"Compute the MD5 hash [11] 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::/96. The resulting multicast address will be termed the "NI Group Address" for the name. A node will support an "NI Group Address" for each associated Subject Name."
This does not follow the intent of RFC3307. RFC3307 intended for dynamically assigned multicast ids be forced into the range from 0x80000000 - 0xFFFFFFFF, to avoid overlapping at the layer 2 with globally assigned addresses. Take for instance that a name hashes to 0x00000001 (there is nothing that would hinder this) then every host would receive it at the layer 2 level and would have to be processed at the IP level. Likewise, the same would occur for any other IANA assigned addresses. 
RFC3307 states that if the T bit is (transient address) the MSB shall be set. It does not state that if the T bit is not set, that the MSB shall be reset. Clearly these addresses are transient addresses and should be treated as such in creating the 32 bit multicast id.
I think it should at least set the MSB of the 32 bit hash value. There is a recommendation that the high byte be set to 0xFF to keep it in the same range as the solicited node addresses (at the layer 2 boundary) since it is achieving a similar purpose.
I understand that this change will break backward compatibility, but it is better to fix it now than cause further non-conformant issues that may cause problems later.

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

---

From: Elwyn Davies <[email-masked]>
Date: Tue, 19 Jul 2005 00:48:16 +0100

Consider:
- The primary point of RFC3307 is to make sure that you can get a unique 
IPv6 multicast address - The Layer 2 non-clash is a bonus.
- The addresses are (probably) not taken from the spaces to which 
RFC3307 applies (they are 'traditional' P=0 addresses - I believe the 
intent was that RFC3307 only applied to addresses for which the 80 bit 
reserved field is 0 as defined in the RFC2373 version of the IPv6 
address architecture  although this is not totally clear)
- All nodes have to be able to disambiguate multicast addresses at the 
IP level as there is already a risk of clashes at Layer 2 (however 
small) (e.g., between a solicited node address and an assigned dynamic 
address.)
- The chance of a Layer 2 clash with a bad case like the all-nodes 
address (asuming MD5 is any good!) is not exactly large

So I think the risk of a severe performance hit is not going to be very 
large.

Also from a logical point of view it is not clear that these are 
dynamically assigned - they exist whether any node is actually using 
them - one could therefore argue for some other MSB values if RFC3307 
applied, but I think it is fairly clear that RFC3307 does not apply to 
them. Although the relevant section of the addressing arch has now 
disappeared so exactly what the scope of 3307 ought to be  is maybe no 
longer clear.

All in all I can't see any real justification for this change.

Regards,
Elwyn

Pashby, Ronald W CTR NSWCDD-B35 wrote:

> "Compute the MD5 hash [11] 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::/96. The resulting 
> multicast address will be termed the "NI Group Address" for the name. 
> A node will support an "NI Group Address" for each associated Subject 
> Name."
>
> This does not follow the intent of RFC3307. RFC3307 intended for 
> dynamically assigned multicast ids be forced into the range from 
> 0x80000000 - 0xFFFFFFFF, to avoid overlapping at the layer 2 with 
> globally assigned addresses. Take for instance that a name hashes to 
> 0x00000001 (there is nothing that would hinder this) then every host 
> would receive it at the layer 2 level and would have to be processed 
> at the IP level. Likewise, the same would occur for any other IANA 
> assigned addresses.
>
> RFC3307 states that if the T bit is (transient address) the MSB shall 
> be set. It does not state that if the T bit is not set, that the MSB 
> shall be reset. Clearly these addresses are transient addresses and 
> should be treated as such in creating the 32 bit multicast id.
>
> I think it should at least set the MSB of the 32 bit hash value. There 
> is a recommendation that the high byte be set to 0xFF to keep it in 
> the same range as the solicited node addresses (at the layer 2 
> boundary) since it is achieving a similar purpose.
>
> I understand that this change will break backward compatibility, but 
> it is better to fix it now than cause further non-conformant issues 
> that may cause problems later.
>
>------------------------------------------------------------------------
>

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 20 Jul 2005 17:45:03 +0900

>>>>> On Mon, 18 Jul 2005 14:13:54 -0500, 
>>>>> "Pashby, Ronald W CTR NSWCDD-B35" <[email-masked]> said:

> 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::/96. The
> resulting multicast address will be termed the "NI Group Address"
> for the name. A node will support an "NI Group Address" for each
> associated Subject Name."

> at the IP level. Likewise, the same would occur for any other IANA

Hmm...when I first heard this point off-list, I didn't see the need
for it.  But after re-reading RFC3307, I tend to agree with you.  In
the literal sense, the current specification of the name-lookups
document does not break RFC3307, since the link-local multicast groups
defined for name-lookups do not set the "T" bit.  But, in my
understanding of the real intent of the RFC, those group should be
categorized as "Dynamic IPv6 Multicast Addresses" (so we may even want
to set the "T" bit for those groups).

The problem is, as you commented, that this change will break existing
implementations.  I'm not sure how serious it is: I use the
name-lookup protocol almost everyday, but I've never used the
name-to-address mapping function using the hashed multicast group.
Thus, I, for one, don't mind if we change the group range at this
stage as an end user.  As an implementor, I actually don't mind
either.  The code change would be pretty trivial.

Of course, compatibility issues generally require broader inputs.
We'll have to hear from other users or implementors of existing
implementations before making the decision.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 20 Jul 2005 11:43:45 +0100

JINMEI Tatuya / 神明達哉 wrote:

As I said in my previous posting, I don't think you ought to think of
either solicited node multicast groups or these groups as dynamically
allocated.  The groups exist statically whether any nodes are using
them or not.  The dynamically allocated ones are (IMO) those that an
application needs to create with some guarantee of uniqueness in order
to send on. No dynamic allocation is needed for the name lookup
addresses.

It occurs to me that there is another issue related to one we have
discussed for Neighbour Discovery: A node that implements the response
side of name lookup has to join the relevant multicast groups that we
are talking about and should send out the MLDv1 or MLDv2 listener
messages to ensure that the multicast messages will reach it through
any switches that happen to be in the way.  Do implementors do this
anyway?

Two points as regards the possible clash of Layer 2 addresses:

- Taking a subset of the bits of an MD5 hash obviously increases the
likelihood of a collision but the hashes will still be uniformly
distributed over [0,2^32) - there is not a disproportionate chance of
hitting (say) the all-nodes address.

- The probability of getting a clash between independently randomly
allocated groups with 32 bit identifiers does not start to get
significant (i.e. bigger than about 0.01) until you have several
thousand addresses actually in use on a link (see Mark Handley's work).

>From a practical point of view, given the low rate of packets that
would be expected from the name lookup protocol, is the impact of a low
probability Layer 2 clash *really* going to make much of an impact on
even a time sensitive application?  My understanding of the reason for
trying to spread the ND and name lookup multicasts across a wide
spectrum of groups is to reduce the number of low level interrupts
resulting from acquisition of packets that prove not to be of interest
to this node when their IP addresses are examined.  Whatever group a
name lookup packet is on, if it is intended for a given node it has to
be received and processed by that node.  Three things are going to
help: Keeping packets that are of no interest off a switched connection
to the node; if they do come past on the wire, ignoring them at the
lowest possible level; and using Ethernet QoS for the time sensitive
packets - otherwise all packets of interest (and disinterest) just get
dumped into a single queue for IP processing.

Regards,

Elwyn

JINMEI, Tatuya

---

From: Stig Venaas <[email-masked]>
Date: Wed, 20 Jul 2005 13:10:19 +0200

Please don't send HTML, hard for me to read and quote.

Clients should definitely do an MLD join for this group (just as they
should for the solicited multicast address used for ND). My experience
is also that clients do join both the "solicited" and the "name-lookup".
I would be interested to hear of any implementations that don't. If not,
the job for snooping switches will be pretty difficult. In general we
need to make it very clear that one always needs to do MLD joins, except
for ff02::1.

Stig

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 20 Jul 2005 20:24:53 +0900

>>>>> On Wed, 20 Jul 2005 11:43:45 +0100, 
>>>>> Elwyn Davies <[email-masked]> said:

> As I said in my previous posting, I don't think you ought to think
> of either solicited node multicast groups or these groups as
> dynamically allocated.  The groups exist statically whether any
> nodes are using them or not.  The dynamically allocated ones are
> (IMO) those that an application needs to create with some guarantee
> of uniqueness in order to send on. No dynamic allocation is needed
> for the name lookup addresses.

Whether it's really a 'dynamically allocated' address or not is just a
matter of definition.  I won't surprise if different people have
different views on this.  I just represented my own interpretation of
the sense of RFC3307.  Of course, I could be wrong, in which case the
author of the RFC will hopefully correct me.

In any case, I don't think the definition of 'dynamic' is a real
issue.  The issue is whether it makes sense to try avoiding layer-2
and layer-3 collisions for the multicast groups regarding the
icmp-name-lookup protocol.

In my understanding, a very rough summary of your argument against
this point is "the probability of collisions should be very rare due
to the use of MD5 hashing, so don't bother" (correct?).  I see the
point, and I can live with that.

In my undersatnding, however, the trend of the IETF is to not rely on
that type of arguments and is to try avoiding possible collisions more
and more explicitly.  In fact, we rejected the idea of "duplicate
interface-ID detection' instead of 'duplicate address detection',
based on the argument of "the probability of collisions should be rare
since the IDs should be highly unique, so why not optimize?".  Also,
RFC3307 seems to try avoiding collisions even though it recommends the
use of good random group IDs (according to the second paragraph of
Section 4.3.2).  So, it seems more consistent to me to avoid
collisions in this case despite the use of reasonably distributed IDs.

It's not a strong opinion though.  If a majority prefers keeping the
current range, I won't fight against that.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 20 Jul 2005 20:33:29 +0900

(Forgot to mention this)

> It occurs to me that there is another issue related to one we have discussed
> for Neighbour Discovery: A node that implements the response side of name
> lookup has to join the relevant multicast groups that we are talking about and
> should send out the MLDv1 or MLDv2 listener messages to ensure that the
> multicast messages will reach it through any switches that happen to be in the
> way.  Do implementors do this anyway?

I don't know how this is relevant to the particular point of the group
range, but anyway, yes, our implementation do that.  And, I don't see
any reason why implementations don't do that: it seems pretty trivial
point to me.

					JINMEI, Tatuya

p.s. (this is also forgotten in my previous response:-) it would be
nice if you could send your message in a plain text instead of html.

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 20 Jul 2005 15:09:41 +0100

>need to make it very clear that one always needs to do MLD joins, except
Agreed.  We just need a few words as per 2461bis. Something like..

Nodes intending to respond to name lookup queries MUST join the 
appropriate multicast addresses for the names to wghich they will 
respond. Joining the name lookup multicast address SHOULD be done using 
the Multicast Listener Discovery [MLD] or [MLDv2] protocols.

Elwyn

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 20 Jul 2005 16:29:22 +0100

>author of the RFC will hopefully correct me.
Indeed RFC3307 has to some extent been overtaken by events and the exact 
meaning is now unclear. As you say it doesn't really matter for the 
purposes of this discussion.

>collisions in this case despite the use of reasonably distributed IDs.
The real point I was trying to get across is that Layer 2 multicast 
address collisions are essentially unavoidable, but that they are, at 
least in the name lookup case, benign, especially as far as performance 
is concerned. So I wouldn't change the algorithm.

I agreed with the DAD decision, and making sure the layer 3 addresses 
are unique for a given purpose is clearly the right answer, because a 
collision could have disastrous effects unless nodes/applications are 
expecting it.

The name lookup and ND solicited node Layer 3 addresses are taken from 
different spaces from any of the RFC3307 addresses so there can never be 
a collision between these different types of addresses at Layer 3.
The name lookup (and ND) solution reduces the probability of multiple 
nodes using the same Layer 3 and Layer 2 addresses for this purpose but 
ensure that a collision doesn't matter, although there will be a small 
amount of wasted effort on nodes with Layer 3 collisions.

As far as I can see, there is bound to be a small residual probability 
of a Layer 2 multicast address collision on account of there being many 
less Layer 2 multicast addresses than Layer 3 multicast addresses. In 
the vast majority of cases this will not matter because nodes will 
receive and process just the packets they would have received anyway. 
There will be a small number of (relatively) pathological cases where a 
packet goes to a number of listeners that aren't interested. However, 
especially in the case of name lookup, the number of packets involved at 
any one node is likely to be very small.
Regards,
Elwyn