Re: Question on anycast IID range(s)

[David Farmer <[e-mail]>]

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.

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.


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

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.


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