Re: Question on anycast IID range(s)

On 2019-01-03 09:37, Kerry Lynn wrote:
> On Wed, Jan 2, 2019 at 2:57 PM Brian E Carpenter <
> brian.e.carpenter@gmail.com> wrote:
> 
>> 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.
>>
> That's the problem with RFC2526; at the time it was written there was a
> class of
> IPv6 address that required IIDs to be 64-bits AND in EUI-64 format.  Given
> that the
> latter requirement no longer seems to hold, it would seem the basis for the
> range
> fdff:ffff:ffff:ff80-fdff:ffff:ffff:ffff no longer exists.  Yet, this range
> is now enshrined in
> RFC5453 and
> https://www.iana.org/assignments/ipv6-interface-ids/ipv6-interface-ids.xhtml
> 
> But RFC7217 doesn't mention RFC2526, which might be a bug.
>>
> RFC7217 (and any other proposal for IID generation) should take RFC5453 and
> its associated registry into consideration.

It does. But the gap is that RFC5453 doesn't call out
ffff:ffff:ffff:ff80-ffff:ffff:ffff:ffff

> 
>> BTW, RFC2526 is unmotivated. Why do we *need* a convention for
>> anycast IIDs?
>>
> I think RFC2526 anticipated core protocols that would make use of
> anycast.  In
> the event, there are currently two protocols defined:
> https://www.iana.org/assignments/ipv6-anycast-addresses/ipv6-anycast-addresses.xhtml
> 
> RFC5453 clarifies the motivation somewhat; to de-conflict the addresses
> used for
> core anycast services from normal unicast addresses (thereby avoiding
> potential
> denial of anycast services).  Given that any IID can be used for an anycast
> address,
> I'm not sure this is a strong argument.
> 
> Should any action be taken?  For example, should the range
> ffff:ffff:ffff:ff80-
> ffff:ffff:ffff:ffff be added to RFC5453's registry?

Yes. I've posted an erratum to 5453. At the time, ffff:etc might
have seemed like a corner case, but 2526 did actually cover it.

   Brian

> 
> Kerry
> 
>    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
>>> --------------------------------------------------------------------
>>>
>>
> 