Re: Question on anycast IID range(s)

[Kerry Lynn <[e-mail]>]

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

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.

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