Re: Question on anycast IID range(s)

[Brian E Carpenter <[e-mail]>]

A comment right at the end:

On 2019-01-06 09:41, Ole Troan wrote:
> Kerry,
> 
>>> 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?
>>
>> I do not have direct knowledge, but I'm thinking about the possible impact on
>> current Mobile IPv6 implementations.  RFC3775  defines functionality of the mobile
>> node, e.g. "The mobile node sends the Home Agent Discovery Request message to
>> the Mobile IPv6 Home-Agents anycast address ... for its own subnet prefix", and of
>> the home agent, e.g. "Every home agent MUST be able to accept packets addressed
>> to the Mobile IPv6 Home-Agents anycast address ... for the subnet on which it is
>> serving as a home agent …"
> 
> Doesn’t the mobile agent already need to know the type of home-link, if it is on a link-type using modified EUI-64 (and it’s prefix length)?
> 
>> If we now recommend the range of IID values ffff:ffff:ffff:ff80-ff, would existing Mobile
>> IPv6 implementations need to be modified to send to or receive from the reserved
>> Mobile IPv6 Home-Agents anycast address in both the new and legacy ranges?  I
>> agree that it is not the most elegant solution to retain just the current fdff:ffff:ffff:ff80-ff
>> range (along with revising RFC2526), but it may be the least disruptive.
> 
> I must admit I’m quite attracted to the simplicity of:
> "The subnet anycast address range is the top-most 128 addresses on any link with prefix length <= 120."

Yes, but in that case the fdff: range was an error from the beginning (compounding what I always thought was an error: the inversion of the IEEE "u" bit). If not an error, it was in any case an exception to the "top-most 128" rule.

     Brian