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

From: "Pashby, Ronald W CTR NSWCDD-B35" <[email-masked]>
Date: Tue, 19 Jul 2005 06:51:52 -0500

- I disagree that RFC3307 was only for Layer 3. It is clearly stated in the Abstract and Introduction that: 
   "The purpose of these guidelines is to reduce the
   probability of IPv6 multicast address collision, not only at the IPv6
   layer, but also at the link-layer of media that encode portions of
   the IP layer address into the link-layer address."
If layer 2 was not the main reason not so much effort would be placed in defining the behavior in the lower 32 bits. In fact the whole document addresses the lower 32 bits that is mapped to layer 2.

- RFC3307 is clear that it is for all multicast addresses. In the Applicability section it states:
   "These guidelines are designed to be used in any environment in which
   IPv6 multicast addresses are delegated, assigned, or selected."

- In some environments it is critical to avoid collisions if at all possible. Even the processing at the IP layer to discard the packet might cause a problem in time sensitive applications. There is some work being proposed to disambiguate the solicited node addresses from other dynamically assigned addresses.

- I'm not a cryptologist, but MD5 was defined to minimize the collision of 2 "valid" messages that are both hashed and it produces 128 bit value. Here we are only taking 32 of those bits and we are not hashing 2 "valid" messages and comparing the result. Therefore I would not make any statements into the possibility of collisions. I agree that it would seem on the surface that the probability is low. However, would you bet your life or finances on that probability.

- Now is the time to fix possible problems, not wait for them to become problems after it becomes an RFC.

-----Original Message-----
From: Elwyn Davies [mailto:[email-masked]]
Sent: Monday, July 18, 2005 19:48
To: Pashby, Ronald W CTR NSWCDD-B35
Cc: [email-masked]
Subject: Re: Comments on draft-ietf-ipngwg-icmp-name-lookups-12.txt

 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:

> 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
>--------------------------------------------------------------------
>  
>

--------------------------------------------------------------------
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: Thu, 21 Jul 2005 06:31:02 -0500

Actually, my proposal to Brian on the draft was exactly what you suggested, mapping the name queries into the Solicited Node Address (SNA) range. I think that is the best solution. I have another draft that suggests that the "dynamic range" gets broken into 2 major sections: Global (DAG) scoped and Non-Global (DANG) scoped. The non-global range is further broken down into Link-Local and Reserved. Link-Local is the range 0xF0000000 - 0xFFFFFFFFF, which includes the SNAs plus some room for expansion for things like the name queries if overloading the SNAs is deemed harmful. The reserved range is for possible use of Organization scoped and Site scope. 

-----Original Message-----
From: Elwyn Davies [mailto:[email-masked]]
Sent: Wednesday, July 20, 2005 18:56
To: Pashby, Ronald W CTR NSWCDD-B35
Cc: [email-masked]; [email-masked]
Subject: Re: Comments on draft-ietf-ipngwg-icmp-name-lookups-12.txt

Fair point about the possible problems - thanks for the explanation.  I 
understand what you mean there now.

Unfortunately since there are several independent dynamic and 
pseudo-dynamic allocation mechanisms in play, you are only going to get 
absolute guarantees if you partition the group id space further. 
(RFC2809 has some words on this).  Just making the name lookup addresses 
somewhere in the dynamic area still risks collisions.  If you want to go 
down this path I think one solution would be to overload the group space 
which is already used for ND OxFFxxxxxx.  ND and name lookups would not 
find occasional clashes a big problem as the Layer 3 addresses differ 
and the packet rates are low.  Name lookups could just use the top 24 
bits instead of the top 32 bits of the MD5 hash, and collisions would 
start to be likely with a few hundred nodes on a link.  Applications 
that have a problem can try to avoid this part of the space.

The alternative is to turn the problem around and tell applications that 
are worried to test if anybody else is using the group (check with the 
MLD queries or send a name lookup NOOP?)  and get a different address if 
there is a collision. The problem is what happens when new nodes arrive 
- so maybe not?

Regards,
Elwyn

Pashby, Ronald W CTR NSWCDD-B35 wrote:

>I disagree that layer2 collisions are unavoidable. If you follow RFC3307 then collisions between dynamically assigned and permanent assigned addresses are totally avoidable (like they are intended). The issue here is that this draft does not follow the intent of 3307.
>
>As far as benign goes, everyone considers the effect of sending "Name Queries" and because of a collision a host that joined "another" group gets those queries. But the opposite case is the major one. Take for instance that a multicast group is being used to send large amounts of packets per second. Another host is running a real-time mission critical application that it not designed to receive a large number of packets per second.  The second host just happens to join the same (layer 2) group because of the MD5 hash on its name. Then the host will be flooded with multicast traffic and may cause it to fail to perform its real-time task.
>
>The solution is to insure that certain ranges of address can be used to guarantee that collision will not happen.
>
>Sent: Wednesday, July 20, 2005 11:29
>To: [email-masked]
>Cc: Elwyn Davies; [email-masked]; Pashby, Ronald W CTR NSWCDD-B35
>JINMEI Tatuya / 神明達哉 wrote:
>
>  
>
>>>>>>>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.
>> 
>>
>>    
>>
>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.
>
>  
>
>>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.
>>
>> 
>>
>>    
>>
>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
>
>  
>
>>It's not a strong opinion though.  If a majority prefers keeping the
>>current range, I won't fight against that.
>>
>>					JINMEI, Tatuya
>>					Communication Platform Lab.
>>					Corporate R&D Center, Toshiba Corp.
>>					[email-masked]
>> 
>>
>>    
>>