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