Re: Question on anycast IID range(s)

On 2019-01-03 07:15, Kerry Lynn wrote:
> Thanks Erik,
> 
> My question was ill-posed *and* contained a typo.  I'm really trying to
> figure out
> which range(s) of IIDs RFC 2526 is trying to reserve for anycast use.  I
> now think
> the answer is fdff:ffff:ffff:ff80-fdff:ffff:ffff:ffff based on RFC 5453 and
> https://www.iana.org/assignments/ipv6-interface-ids/ipv6-interface-ids.xhtml

If I take RFC2526 literally, ffff:ffff:ffff:ff80-ffff:ffff:ffff:ffff
is also reserved, for IIDs not in modified EUI-64 format. 

But RFC7217 doesn't mention RFC2526, which might be a bug.

BTW, RFC2526 is unmotivated. Why do we *need* a convention for
anycast IIDs?

   Brian

> ..
> 
> Regards, Kerry
> 
> 
> On Wed, Jan 2, 2019 at 12:57 PM Erik Kline <ek@loon.co> wrote:
> 
>> I think practically speaking the only to tell if an address on another
>> node is anycast or not is by the observable difference in the NA:
>>
>>     https://tools.ietf.org/html/rfc4861#section-7.2.7
>>
>> """
>>    From the perspective of Neighbor Discovery, anycast addresses are
>>    treated just like unicast addresses in most cases.  Because an
>>    anycast address is syntactically the same as a unicast address, nodes
>>    performing address resolution or Neighbor Unreachability Detection on
>>    an anycast address treat it as if it were a unicast address.  No
>>    special processing takes place.
>>
>>    Nodes that have an anycast address assigned to an interface treat
>>    them exactly the same as if they were unicast addresses with two
>>    exceptions.  First, Neighbor Advertisements sent in response to a
>>    Neighbor Solicitation SHOULD be delayed by a random time between 0
>>    and MAX_ANYCAST_DELAY_TIME to reduce the probability of network
>>    congestion.  Second, the Override flag in Neighbor Advertisements
>>    SHOULD be set to 0, so that when multiple advertisements are
>>    received, the first received advertisement is used rather than the
>>    most recently received advertisement.
>> """
>>
>>
>> On Wed, 2 Jan 2019 at 08:51, Kerry Lynn <kerlyn@ieee.org> wrote:
>>
>>> For practical purposes, particularly in light of RFC 7136, should one
>>> consider an anycast address to be any that ends in dfff:ffff:ffff:ff80-
>>> dfff:ffff:ffff:ffff OR ffff:ffff:ffff:ff80-ffff:ffff:ffff:ffff?
>>>
>>> The phrase in RFC 2526 that's causing confusion for me is
>>> "Specifically, for IPv6 address types required to have to have
>>> [sic] 64-bit interface identifiers in EUI-64 format ..."  To my
>>> knowledge, there are address types that require a 64-bit IID,
>>> but it seems we've been systematically trying to deprecate
>>> *EUI-64 format* IIDs.  In any case, there's nothing to prevent a
>>> mix of EUI-64 or *other* format IIDs in the same subnet as far
>>> as I'm aware.
>>>
>>> Thanks, Kerry
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>>
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 