Re: Question on anycast IID range(s)

[Ole Troan <[e-mail]>]

> 
> I'm saying both ranges should be reserved and not used for the creation of normal unicast IIDs, and that normally anycast IIDs should be created from ffff:ffff:ffff:ff80-ffff:ffff:ffff:ffff, not fdff:ffff:ffff:ff80-fdff:ffff:ffff:ffff.  However, in any case, the actual use of anycast is fairly limited and unicast use of an anycast IID probably isn't fatal in most situations. The difference between a single instance of an anycast address and a unicast address is mostly semantic anyway. Further, the probability of a collision with one of those two ranges by an implementation that doesn't have both ranges is fairly rare, to begin with, and the consequences of the collision are only a problem if a unicast host selects one of the reserved addresses before an anycast use is initiated. DAD on the unicast host should prevent it from selecting a reserved anycast address that is actually in use for anycast. So, as long as an anycast use of a reserved anycast address isn't initiated after a unicast use has selected the address nothing bad should happen.  That doesn't mean we shouldn't bother but in reality duplicate, MAC addresses are a bigger worry, at least in my opinion. 
> 
> They both should have been on the list originally.  Further, I believe the original intent for Modified EUI-64 is the way RFC7136 updates it to, especially if you take the paragraphs following that talk about "Modified EUI-64 format-based interface identifiers". Talking about them that way kind of implies there are interface identifiers that are not based on Modified EUI-64 format, despite the paragraph above originally said.
> 
> And yes we should assume N==64. But as Ole said, it is quite clear even if N!=64 that RFC2526 say "the highest 128 interface identifier values are reserved."
> 
> This language clearly doesn't work for prefixes longer than 120 bits (for example,
> point-to-point links).  If the consensus is to go with the existing reserved range for
> N==64, then we should change any confusing language in RFC2526.

Do we know the deployment / implementation status of the reserved anycast space?
And how costly it would be to restate the reserved state as top-most 128 addresses, and not carry with us the U/G bits?

Cheers,
Ole