Re: Question on anycast IID range(s)

[David Farmer <[e-mail]>]

On Fri, Jan 4, 2019 at 7:44 AM Kerry Lynn <[e-mail]> wrote:

> Hi David,
>
> On Thu, Jan 3, 2019 at 7:36 PM David Farmer <[e-mail]> wrote:
>
>>
>>
>> On Thu, Jan 3, 2019 at 5:56 PM Suresh Krishnan <[e-mail]>
>> wrote:
>>
>>> Hi Brian,
>>>
>>> On Jan 2, 2019, at 11:15 PM, Brian E Carpenter <
>>> [e-mail]> wrote:
>>>
>>> On 2019-01-03 17:01, Suresh Krishnan wrote:
>>>
>>> <AD Hat off>
>>>
>>> Hi Brian/Erik/Kerry,
>>>
>>> On Jan 2, 2019, at 4:52 PM, Brian E Carpenter <
>>> [e-mail]> wrote:
>>>
>>> On 2019-01-03 09:37, Kerry Lynn wrote:
>>>
>>> On Wed, Jan 2, 2019 at 2:57 PM Brian E Carpenter <
>>> [e-mail]> 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
>>>
>>>
>>> Looking back at my notes on what became RFC5453, this is not a gap but
>>> something I had intentionally left out of RFC5453 based on the addressing
>>> usage then. I will try to explain my reason why and we can see if this
>>> still makes sense or not.
>>>
>>> According to RFC2526, "for IPv6 address types required to have to have
>>> 64-bit interface identifiers in EUI-64 format” the reserved anycast range
>>> was only
>>>
>>> FDFF:FFFF:FFFF:FF80-FDFF:FFFF:FFFF:FFFF
>>>
>>> Since RFC4291 defined all the space other than ::/3 to be used only with
>>> 64-bit IIDs, and the goal of RFC5453 was to avoid address conflicts for
>>> SLAAC (which used 64 bit IIDs due to reasons explored in great detail in
>>> RFC7421), this is the range that was put into RFC5453.
>>>
>>> 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.
>>>
>>>
>>> 2526 covered this *only* for non 64-bit non EUI-64 IIDs.
>>>
>>>
>>> That's not how I read it. IMHO, it covered it for non-EUI-64 IIDs
>>> of length N, and there's nothing to say that N may not be 64.
>>> (In fact, our current addressing architecture states that N==64,
>>> as we all know only too well.)
>>>
>>>
>>> :-). Yes, we do. The addressing architecture also states in Section
>>> 2.5.1. that
>>>
>>> "  For all unicast addresses, except those that start with the binary
>>>    value 000, Interface IDs are required to be 64 bits long and to be
>>>    constructed in Modified EUI-64 format."
>>>
>>
>> Well, after the RFC7136 update it says;
>>
>>       For all unicast addresses, except those that start with the binary
>>       value 000, Interface IDs are required to be 64 bits long.  If
>>       derived from an IEEE MAC-layer address, they must be constructed
>>       in Modified EUI-64 format.
>>
>> And RFC8064 effective makes Modified EUI-64 format OPTIONAL, or a MAY at
>> best, one could even argue it depercated Modified EUI-64, A.K.A. NOT
>> RECOMMENDED.
>>
>>
>>> So if we want to add the omitted range, we need to restrict it to non
>>> ::/3 prefixes as well.
>>>
>>> If we do want to cover the non 64-bit cases then the range Brian
>>> suggested ave is insufficient (because the IIDs will not fit in the 64-bit
>>> range suggested) and would require a more considered change.
>>>
>>> For the specific case of N==64 I don't see that as necessary.
>>>
>>> Agree that the N==64 case works fine but I was talking about whether the
>>> WG wanted to cover the non-64-bit cases as well.
>>>
>>
>> So, I believe ffff:ffff:ffff:ff80-ffff:ffff:ffff:ffff should be added to
>> the reserved list and RECOMMENDED for use as Anycast addresses.
>> And, fdff:ffff:ffff:ff80-fdff:ffff:ffff:ffff should remain on
>> the reserved list, but NOT RECOMMENDED for use as Anycast addresses, as a
>> result of RFC8064.
>>
>> The practical problem is that RFC8064 specifies RFC7217 as the default
> method for
> generating stable IIDs, and current implementations of RFC7217 take into
> account
> the fdff:ffff:ffff:ff80-fdff:ffff:ffff:ffff range, based on RFC5453 and
> its associated registry.
> We could declare the existing range to be wrong, but it would be less
> disruptive to
> retain it "for historical reasons".
>

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

Well again, N==64 and even if it isn't the use of a reserved anycast
address for unicast probably isn't going to be a problem especially since
you are manually configuring all the addresses anyway. And, if you assign
the same address for a unicast host and an anycast use, you messed up plain
and simple.


> Regards, Kerry
>
> Thanks.
>>
>>
>>> Thanks
>>> Suresh
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [e-mail]
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>>
>>
>> --
>> ===============================================
>> David Farmer               Email:[e-mail]
>> Networking & Telecommunication Services
>> Office of Information Technology
>> University of Minnesota
>> 2218 University Ave SE        Phone: [phone]
>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
>> ===============================================
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>

-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================