Re: Question on anycast IID range(s)

[Kerry Lynn <[e-mail]>]

On Sun, Jan 6, 2019 at 12:45 PM David Farmer <[e-mail]> wrote:

> This is how I see it.
>
> On Sat, Jan 5, 2019 at 11:17 PM Ole Troan <[e-mail]> wrote:
>
>> Here are the options I see:
>>
>> a) Keep the ‘u’ flag for the reserved anycast block
>>
>
> For backwards compatibility with any Mobile IP implementations using ffff:
> ffff:ffff:ff7e, this still requires that block to be added to the
> reserved IIDs. If we did that, while not my prefered option, I'd be ok with
> this option.
>
> That assumes there *are* any Mobile IPv6 implementations that use ffff:
ffff:ffff:fffe for
plen == 64.  (Such an interpretation of RFC2526 for plen == 64 only seems
plausible
after RFC7136.

I think we need to hear from parties with operational experience of Mobile
IPv6, especially
commercial versions.  The successor of Mobile IPv6 for Linux (MIPL) seems
to be USAGI-
patched Mobile IPv6 for Linux (http://umip.linux-ipv6.org/), which uses
fdff:ffff:ffff:fffe for the
home agent anycast address when plen == 64 (see .../src/prefix.c).


> b) Drop the ‘u’ flag and make the block “purely” the  top-most 128
>> addresses. Would require updating at least 2526
>>
>
> This is my prefered option, deprecate the 'u' flag for the reserved
> anycast block based on a combination of RC7136 and RFC8064. Futher, update
> the reserved IIDs registry to include both blocks. Even though we are
> deprecating the 'u' flag, there could be Mobile IP implementations still
> using fdff:ffff:ffff:ff7e, therfore for backwords compatability, that
> block should remain in the reserved IIDs and the other block needs to be
> added.
>
>
I don't dispute this is the most elegant solution.  It has the added
benefit that mere mortals
would be able to read RFC2526 literally ;-)  However, as we have seen, at
least one major
OS *does* use fdff:ffff:ffff:fffe.  There's also the issue that RFC7217
(and, by extension,
RFC8064) implementations would need to be patched to avoid the (unlikely)
possibility
of results in the ffff:ffff:ffff:ff80-ff range.

RFC7136 actually provides cover for retaining 'u' == 0 for backward
compatibility; "... the
method of generating IIDs for specific for specific links types MAY define
some local
significance for certain bits."

c) Deprecate the subnet anycast block altogether
>>
>
> Even if we deprecated the subnet anycast block altogether, which I don't
> suggest we do, both blocks should remain or be added to the reserved IIDs
> for the forseeable future for backwords compatability with any Mobile IP
> implementations still using either of them.
>
> I also agree this option is unacceptable; it would break Mobile IPv6
[RFC6275] and
whatever ETSI EN 302 636-6-1 is (see
https://www.iana.org/assignments/ipv6-anycast-addresses/ipv6-anycast-addresses.xhtml).


d) Do nothing
>>
>
> Not a good option, there is a risk (although extremely small) of IID
> collision for any Mobile IP implementations using ffff:ffff:ffff:ff7e,
> therefore at the very least this bolck needs to be added to the reserved
> IIDs.
>
>
Again, it would be great to hear from someone with Mobile IPv6 operational
experience.

Regards, Kerry

>
>
Cheers,
>> Ole
>
>
> --
> ===============================================
> 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
> --------------------------------------------------------------------
>