Re: IPv6 w.g. Last Call on "Link Scoped IPv6 Multicast Addresses"

[Pekka Savola <pekkas@netcore.fi>]

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
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------