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