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

["jspark" <jspark@xxxxxxxxxxxxxx>]

Hi, Pekka.

>>>Pekka Savola wrote:
>> > 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.

>>Myung-Ki Shin wrote:
>>    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).

>Pekka Savola wrote:
>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..)

I understand what you mean.
So, I'd like to clarify this. 

Section 3 of our spec says:
-----------
  "Interface ID field is used to distinguish each host from others.  And 
   this value is obtained from the IEEE EUI-64 based interface 
   identifier of the link-local unicast IPv6 address."
-----------

Our method uses only  the EUI-64 based Interface ID, 
derived from Link-local unicast address. 
So, there is guarantee of uniqueness in our method. 

>> > Pekka Savola wrote:
>> > 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.

>>Myung-Ki Shin wrote: 
>>    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.

>Pekka Savola wrote:
>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.

Of course, 
I think a SSM implementation "MUST" check for FF3x::/96.

Thanks

JungSoo


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------