On Thu, 23 Oct 2003, Myung-Ki Shin wrote: [...] > 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).
There is 32 bits worth of group ID to distinguish between the groups the different nodes use. There is about 48 bits to distinguish between the nodes on the same link. Don't you think this is already enough? There is no need to define precise external semantics (like embedding the interface ID) to what the addresses should include (i.e., the neighbor node doesn't need to know which address the other node would use for multicasting group-id X). It's just enough that they're reasonably unique. This can be done using a number of techniques, none of which warrant a Protocol Action from the IETF. > > 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). No, I think it was specifically some form of consensus that DAD is not DIID. This is true in particular with unicast prefixes. This happens with link-local prefixes as well, if you use e.g. fe81::1 and fe80::1 on the same physical link but pointing to different nodes. (Btw, does the spec say the interface-ID must be taken from the link-local address? If not, it will have problems with manually configured global addresses..) > > 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 :) .. but this doesn't nullify the usefulness of the algorithm. Just insert something probably unique (a random number, MAC-address, etc.) in the 48 bits and you're done. > > 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). Agreed. > Link scoped multicast address is more simple and convenient. Inventing an address without additional specification would be even simpler. > > 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. If an SSM implementation checks for FF3x::/32 (as described in RFC 3306 section 6), and not for FF3x::/96 (as described in RFC 3306 section 7), but will not implement this specification, there will be lots of trouble. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
