Re: Comments on draft-ietf-ipngwg-icmp-name-lookups-12.txt

[Elwyn Davies]

JINMEI Tatuya / 神明達哉 wrote: 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). As I said in my previous posting, I don't think you ought to think of either solicited node multicast groups or these groups as dynamically allocated.  The groups exist statically whether any nodes are using them or not.  The dynamically allocated ones are (IMO) those that an application needs to create with some guarantee of uniqueness in order to send on. No dynamic allocation is needed for the name lookup addresses. It occurs to me that there is another issue related to one we have discussed for Neighbour Discovery: A node that implements the response side of name lookup has to join the relevant multicast groups that we are talking about and should send out the MLDv1 or MLDv2 listener messages to ensure that the multicast messages will reach it through any switches that happen to be in the way.  Do implementors do this anyway? Two points as regards the possible clash of Layer 2 addresses: - Taking a subset of the bits of an MD5 hash obviously increases the likelihood of a collision but the hashes will still be uniformly distributed over [0,2^32) - there is not a disproportionate chance of hitting (say) the all-nodes address. - The probability of getting a clash between independently randomly allocated groups with 32 bit identifiers does not start to get significant (i.e. bigger than about 0.01) until you have several thousand addresses actually in use on a link (see Mark Handley's work). >From a practical point of view, given the low rate of packets that would be expected from the name lookup protocol, is the impact of a low probability Layer 2 clash *really* going to make much of an impact on even a time sensitive application?  My understanding of the reason for trying to spread the ND and name lookup multicasts across a wide spectrum of groups is to reduce the number of low level interrupts resulting from acquisition of packets that prove not to be of interest to this node when their IP addresses are examined.  Whatever group a name lookup packet is on, if it is intended for a given node it has to be received and processed by that node.  Three things are going to help: Keeping packets that are of no interest off a switched connection to the node; if they do come past on the wire, ignoring them at the lowest possible level; and using Ethernet QoS for the time sensitive packets - otherwise all packets of interest (and disinterest) just get dumped into a single queue for IP processing. Regards, Elwyn 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 --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------