On Fri, 24 Oct 2003, jspark wrote: > 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.
First, there is typically just one link-local address. Either it uses EUI-64 based IID or not. If it doesn't, you can't generate addresses like this. Second, the EUI-64 does not guarantee the uniqueness of the method. Otherwise we would not be needing DAD with addresses that are generated with EUI-64. But it is mandated by the specs. So these addresses are *not* truly, completely, totally, unique. > >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. This is certainly one interpretation. I'm not sure everybody has made the same. This should be brought to the attention of e.g. MBONED WG to see what kind of interpretations they have. -- 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 --------------------------------------------------------------------
