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