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