>>>>> On Mon, 18 Jul 2005 14:13:54 -0500,
>>>>> "Pashby, Ronald W CTR NSWCDD-B35" <[EMAIL PROTECTED]> said:
> 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.
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 PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
