Hi, On Tue, 21 Oct 2003, Bob Hinden wrote: > This is a IPv6 working group last call for comments on advancing the > following document as an Proposed Standard: > > Title : Link Scoped IPv6 Multicast Addresses > Author(s) : J. Park, et al. > Filename : draft-ietf-ipv6-link-scoped-mcast-03.txt > Pages : 5 > Date : 2003-7-2 [...]
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. It should be replaced by Informational guidance how to use "vanilla" RFC3306 to generate the addresses the nodes want, or by the a specification of link-scoped multicast DAD. Further, as currently written, the addresses generated are from Source Specific Multicast range, rendering them practically useless for the purposes of the memo. 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. 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. Ergo, there seems to be zero need to specify an update for RFC3306, it can already provide for a mechanism to allocate the link-local multicast addresses. 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. 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. The problem with this is that the SSM implementations need to have new special code for the treatment of scope=2 and plen != 60. This will result in inconsistent behaviour, and is counter-productive. -- 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 --------------------------------------------------------------------
