- 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 PROTECTED] Sent: Monday, July 18, 2005 19:48 To: Pashby, Ronald W CTR NSWCDD-B35 Cc: ipv6@ietf.org 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 >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
