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