JINMEI Tatuya / 神明達哉 wrote:
On Wed, 20 Jul 2005 11:43:45 +0100,
Elwyn Davies <[EMAIL PROTECTED]> said:
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.
Whether it's really a 'dynamically allocated' address or not is just a
matter of definition. I won't surprise if different people have
different views on this. I just represented my own interpretation of
the sense of RFC3307. Of course, I could be wrong, in which case the
author of the RFC will hopefully correct me.
Indeed RFC3307 has to some extent been overtaken by events and the exact
meaning is now unclear. As you say it doesn't really matter for the
purposes of this discussion.
In any case, I don't think the definition of 'dynamic' is a real
issue. The issue is whether it makes sense to try avoiding layer-2
and layer-3 collisions for the multicast groups regarding the
icmp-name-lookup protocol.
In my understanding, a very rough summary of your argument against
this point is "the probability of collisions should be very rare due
to the use of MD5 hashing, so don't bother" (correct?). I see the
point, and I can live with that.
In my undersatnding, however, the trend of the IETF is to not rely on
that type of arguments and is to try avoiding possible collisions more
and more explicitly. In fact, we rejected the idea of "duplicate
interface-ID detection' instead of 'duplicate address detection',
based on the argument of "the probability of collisions should be rare
since the IDs should be highly unique, so why not optimize?". Also,
RFC3307 seems to try avoiding collisions even though it recommends the
use of good random group IDs (according to the second paragraph of
Section 4.3.2). So, it seems more consistent to me to avoid
collisions in this case despite the use of reasonably distributed IDs.
The real point I was trying to get across is that Layer 2 multicast
address collisions are essentially unavoidable, but that they are, at
least in the name lookup case, benign, especially as far as performance
is concerned. So I wouldn't change the algorithm.
I agreed with the DAD decision, and making sure the layer 3 addresses
are unique for a given purpose is clearly the right answer, because a
collision could have disastrous effects unless nodes/applications are
expecting it.
The name lookup and ND solicited node Layer 3 addresses are taken from
different spaces from any of the RFC3307 addresses so there can never be
a collision between these different types of addresses at Layer 3.
The name lookup (and ND) solution reduces the probability of multiple
nodes using the same Layer 3 and Layer 2 addresses for this purpose but
ensure that a collision doesn't matter, although there will be a small
amount of wasted effort on nodes with Layer 3 collisions.
As far as I can see, there is bound to be a small residual probability
of a Layer 2 multicast address collision on account of there being many
less Layer 2 multicast addresses than Layer 3 multicast addresses. In
the vast majority of cases this will not matter because nodes will
receive and process just the packets they would have received anyway.
There will be a small number of (relatively) pathological cases where a
packet goes to a number of listeners that aren't interested. However,
especially in the case of name lookup, the number of packets involved at
any one node is likely to be very small.
Regards,
Elwyn
It's not a strong opinion though. If a majority prefers keeping the
current range, I won't fight against that.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
