Hi, Pekka.
Pekka Savola wrote:
> There are a large number of things to be said, but I'll just stick to two
> main points. I've never seen much use for this specification, and I do
> not believe this specification is useful as is.
As Erik said, I think that this draft has benefits over unicast-prefix for
scope <=2.
Each node can allocate group ID (32 bits) independently (without any user
input, without a fear of collision or any additional mechanisms).
> 1) I've never seen a justified reason why this is useful. Apparently,
> the document aims to allow a node to generate unique link-scoped multicast
> addresses autonomously, without any user input, without a fear of
> collision or any additional mechanisms.
>
> First, there is no guarantee of uniqueness in the first place, as DAD on
> the IPv6 link-local unicast address was performed on the address, not the
> Interface-ID. In practice, the collisions should be very rare, though.
I don't think so.
DAD on the IPv6 link-local unicast address also guarantees the uniqueness
of Interface-ID in the link-local unicast address.
I beleive that there was a consensus on that (when the draft was
published).
> Second, considering that there is no guaranteed uniqueness, what harm is
> there to generate the addresses as currently specified in RFC3306, like:
>
> - take the prefix of a link-local address (e.g. fe80::/64, or fe80::/10)
> - put it in RFC3306 address, like FF32:40:fe80:<stuff>:<group-id> or
> FF32:A:fe80:<stuff>:<group-id>.
> this would leave 64 bits space to generate an address, assuming the
> group-id is 32.
> - the 64 bits (<stuff>) could be the interface ID of the link-local
> address, or something else completely, like a random number.
As you said, this is wrong calculation :)
> Third, if we want to go down this particular path, a better solution would
> probably be to create a generic "multicast DAD" mechanism to verify the
> uniqueness of a group either on a link, or within a multicast scope. If
> the applicability would be on the link, even unicast DAD mechanisms could
> be reused.
I think "multicast DAD" is an another mechanism.
I (and many folks) don't want to make a new mechanism for this goal
(link-scoped).
Link scoped multicast address is more simple and convenient.
> 2) the current spec uses the reserved field in such a fashion that plen=0
> and the other nodes not implementing this spec will interpret the
> link-local multicast addresses generated using this spec as SSM addresses.
In unicast-prefix,
to accomplish SSM, a node MUST: [RFC 3306]
o Set P = 1.
o Set plen = 0.
o Set network prefix = 0.
Thus, the "network prefix" should be mentioned to distinguished the
conflict.
In this draft, "Interface ID" of link-scoped mcast address != 0.
I think this clarification should be added in current document.
Thanks,
Myung-Ki.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
