Subject: Question on anycast IID range(s)

From: Kerry Lynn <[email-masked]>
Date: Wed, 2 Jan 2019 11:51:04 -0500

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

---

From: Erik Kline <[email-masked]>
Date: Wed, 2 Jan 2019 09:57:26 -0800

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 <[email-masked]> wrote:

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Kerry Lynn <[email-masked]>
Date: Wed, 2 Jan 2019 13:15:10 -0500

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
.

Regards, Kerry

On Wed, Jan 2, 2019 at 12:57 PM Erik Kline <[email-masked]> 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:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 3 Jan 2019 08:57:11 +1300

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

But RFC7217 doesn't mention RFC2526, which might be a bug.

BTW, RFC2526 is unmotivated. Why do we *need* a convention for
anycast IIDs?

   Brian

> ..

---

From: Kerry Lynn <[email-masked]>
Date: Wed, 2 Jan 2019 15:37:00 -0500

On Wed, Jan 2, 2019 at 2:57 PM Brian E Carpenter <
[email-masked]> wrote:

> 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

>
> RFC7217 (and any other proposal for IID generation) should take RFC5453 and
its associated registry into consideration.

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

Kerry

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 3 Jan 2019 10:52:13 +1300

> 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

> 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

---

From: Fernando Gont <[email-masked]>
Date: Wed, 2 Jan 2019 21:44:19 -0300

Hi, Brian,

> is also reserved, for IIDs not in modified EUI-64 format. 

Indeed.

> But RFC7217 doesn't mention RFC2526, which might be a bug.

My recollection of writing this specific bit is that we were referencing
some RFC (certainly *not* this one), and then ended up pointing to the
IANA registry. IMO, the place to fix this is in the IANA registry,
possible with a note that such registration only applies to addresseses
not required to have an IID of 64 bits.

It would seem to me that we probably should have listed RFC2526 in the
"Updates" of RFC8064. Or, probably better, RFC7136 could/should have
updated RFC2526, too.

Essentially, RFC7136 says that IIDs have no internal structure (yeah, I
don't need to tell *you* ;-) ), and RFC7217/RFC8064 got rid of the specs
that might have created the expectation (in practical terms) for IIDs to
have some kind of internal structure.

> BTW, RFC2526 is unmotivated. Why do we *need* a convention for

I assume the motivation is actually to have "well known anycast
addresses". For that, you need:

* An IID range from which you'll pick them -- well, strictly speaking,
you don't, but if you're going to be selecting them from one specific
range, then *avoiding* them is easier and requires less code in things
like RFC7217.

* A registry where you list such well-known addresses.

RFC2526 seems to do a bit of both, but also gets into the convention for
the bits of IIDs, since it predates RFC7136/RFC7212/RFC8064.

I'd say we should probably do a clean-up of the relevant specs...
because at the time of this writing, e.g. all RFCs updated by RFC8064
still contain old text talking about Modified EUI-64 and such....

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Wed, 2 Jan 2019 21:49:09 -0300

On 2/1/19 17:37, Kerry Lynn wrote:
> On Wed, Jan 2, 2019 at 2:57 PM Brian E Carpenter
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 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

Fully agree.

> its associated registry into consideration..

That's what we did, indeed.

> denial of anycast services).  Given that any IID can be used for an
> anycast address,

I'd say yes. And probably that the other range should be removed -- or a
note added that it used to be reserved, but it shouldn't.

Thoughts?

THanks,

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 2 Jan 2019 23:01:49 -0500

<AD Hat off>

Hi Brian/Erik/Kerry,

> On Jan 2, 2019, at 4:52 PM, Brian E Carpenter <[email-masked]> wrote:
> 

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.

> have seemed like a corner case, but 2526 did actually cover it.

2526 covered this *only* for non 64-bit non EUI-64 IIDs. If we do want to cover the non 64-bit cases then the range Brian suggested above is insufficient (because the IIDs will not fit in the 64-bit range suggested) and would require a more considered change.

Thanks
Suresh

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 3 Jan 2019 17:15:29 +1300

On 2019-01-03 17:01, Suresh Krishnan wrote:
> 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.)

> If we do want to cover the non 64-bit cases then the range Brian suggested above 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. 
 
Regards
    Brian

---

From: Mark Smith <[email-masked]>
Date: Thu, 3 Jan 2019 17:19:17 +1100

The other possible give away is duplicate route announcements for a host
route from different routers in the network. This is assuming it is
intentional rather than accidental.

I think there is an argument for a formal anycast address space, identifed
by an IANA allocated prefix.

"IPv6 Formal Anycast Addresses and Functional Anycast Addresses"
https://tools.ietf.org/html/draft-smith-6man-form-func-anycast-addresses-00

---

From: Ole Troan <[email-masked]>
Date: Thu, 3 Jan 2019 16:54:54 +0100

Kerry,

> mix of EUI-64 or *other* format IIDs in the same subnet as far

The main point of 2526 is:

   "Within each subnet, the highest 128 interface identifier values are
   reserved for assignment as subnet anycast addresses.”

Is that definition not unambigiuous?

Cheers,
Ole

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 3 Jan 2019 12:18:16 -0500

On Thu, Jan 3, 2019 at 10:55 AM Ole Troan <[email-masked]> wrote:

> It's ambiguous if 254 IID values meet the definitions further down in
RFC2526
or for prefix > /120

I have to credit my colleague Mike Zhukovskiy for bringing this problem to
our
attention.  When he read RFC2526, he didn't get why the quote above applied
to the range fdff:ffff:ffff:ff80-fdff:ffff:ffff:ffff.  I then told him
about the "u" bit,
RFC7136, and eventually ended up confused myself as I re-read RFC2526.

Thinking about this overnight, I'm not sure that adding an errata to RFC5453
to simply include the range ffff:ffff:ffff:ff80-ffff:ffff:ffff:ffff is the
correct solution;
we'd probably need to widen its scope to include all 64-bit IIDs.

I think it's clear from re-reading RFC2526 that the range
ffff:ffff:ffff:ff80-ffff:ffff:ffff:ffff
COULD be the reserved range, even for /64 prefixes.  Mike points out at
least
one widely-deployed implementation that assumes this:
https://community.cisco.com/t5/ipv6/reserved-anycast-address/td-p/2765408

OTOH, let's say you actually want to deploy Mobile IPv6 home-agents.  Should
you advertise this service at <prefix>:fdff:ffff:ffff:fffe,
<prefix>:ffff:ffff:ffff:fffe, or both?
I agree with Suresh that we may need a more considered solution.

Regards, Kerry

Cheers,

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 3 Jan 2019 18:56:39 -0500

Hi Brian,

> On Jan 2, 2019, at 11:15 PM, Brian E Carpenter <[email-masked]> wrote:
> 

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

So if we want to add the omitted range, we need to restrict it to non ::/3 prefixes as well.

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

Thanks
Suresh

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 3 Jan 2019 19:15:40 -0500

Hi Suresh,

On Thu, Jan 3, 2019 at 6:56 PM Suresh Krishnan <[email-masked]>
wrote:

> the answer is fdff:ffff:ffff:ff80-fdff:ffff:ffff:ffff based on RFC 5453
>
> and
>
>
>
> 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
>
> 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.
>
> As amended by  RFC7136, RFC 4291 Section 2.5.1 now reads:
"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."

The more I think about this, the more I think the correct approach may be
to patch RFC2526.  The premise that some prefixes *require* Modified
EUI-64 IIDs is no longer valid.

One approach would be to replace the language in RFC2526 that says
"Within each subnet, the highest 128 interface identifier values are
reserved
 for assignment as subnet anycast addresses." with something like "Within
each subnet having a /64 prefix, the range of interface identifier values
from
fdff:ffff:ffff:ff80-fdff:ffff:ffff:ffff are reserved for assignment as
subnet anycast
addresses." or words to that effect.

We could then leave alone RFC5453 and its associated registry, as well as
existing implementations of RFC7217.

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
> above is insufficient (because the IIDs will not fit in the 64-bit range
> suggested) and would require a more considered change.
>
>
> 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.
>
> The only other case I'm aware of at present are /127 prefixes, and clearly
these
won't support reserved anycast addresses (other than the all-zeros address).

Regards, Kerry

Thanks

---

From: David Farmer <[email-masked]>
Date: Thu, 3 Jan 2019 18:35:44 -0600

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

> ave is insufficient (because the IIDs will not fit in the 64-bit range

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.

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

Thanks.

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

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 4 Jan 2019 08:44:20 -0500

Hi David,

On Thu, Jan 3, 2019 at 7:36 PM David Farmer <[email-masked]> wrote:

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

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

---

From: David Farmer <[email-masked]>
Date: Fri, 4 Jan 2019 14:28:55 -0600

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

>>> Given
>> 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 fdff:ffff:ffff:ff80-fdff:ffff:ffff:ffff range, based on RFC5453 and
> its associated registry.

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.

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

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.

---

From: Ole Troan <[email-masked]>
Date: Sat, 5 Jan 2019 13:19:43 +0100

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

Do we know the deployment / implementation status of the reserved anycast space?
And how costly it would be to restate the reserved state as top-most 128 addresses, and not carry with us the U/G bits?

Cheers,
Ole

---

From: Kerry Lynn <[email-masked]>
Date: Sat, 5 Jan 2019 11:28:26 -0500

On Sat, Jan 5, 2019 at 7:19 AM Ole Troan <[email-masked]> wrote:

> >
> > 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
> > 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,
> And how costly it would be to restate the reserved state as top-most 128
> addresses, and not carry with us the U/G bits?
>
> I do not have direct knowledge, but I'm thinking about the possible impact
on
current Mobile IPv6 implementations.  RFC3775  defines functionality of the
mobile
node, e.g. "The mobile node sends the Home Agent Discovery Request message
to
the Mobile IPv6 Home-Agents anycast address ... for its own subnet prefix",
and of
the home agent, e.g. "Every home agent MUST be able to accept packets
addressed
to the Mobile IPv6 Home-Agents anycast address ... for the subnet on which
it is
serving as a home agent ..."

If we now recommend the range of IID values ffff:ffff:ffff:ff80-ff, would
existing Mobile
IPv6 implementations need to be modified to send to or receive from the
reserved
Mobile IPv6 Home-Agents anycast address in both the new and legacy ranges?
I
agree that it is not the most elegant solution to retain just the current
fdff:ffff:ffff:ff80-ff
range (along with revising RFC2526), but it may be the least disruptive.

Regards, Kerry

---

From: Ole Troan <[email-masked]>
Date: Sat, 5 Jan 2019 21:41:34 +0100

Kerry,

> I do not have direct knowledge, but I'm thinking about the possible impact on
> current Mobile IPv6 implementations.  RFC3775  defines functionality of the mobile
> node, e.g. "The mobile node sends the Home Agent Discovery Request message to
> the Mobile IPv6 Home-Agents anycast address ... for its own subnet prefix", and of
> the home agent, e.g. "Every home agent MUST be able to accept packets addressed
> to the Mobile IPv6 Home-Agents anycast address ... for the subnet on which it is
> serving as a home agent …"

Doesn’t the mobile agent already need to know the type of home-link, if it is on a link-type using modified EUI-64 (and it’s prefix length)?

> If we now recommend the range of IID values ffff:ffff:ffff:ff80-ff, would existing Mobile
> IPv6 implementations need to be modified to send to or receive from the reserved
> Mobile IPv6 Home-Agents anycast address in both the new and legacy ranges?  I
> agree that it is not the most elegant solution to retain just the current fdff:ffff:ffff:ff80-ff

I must admit I’m quite attracted to the simplicity of:
"The subnet anycast address range is the top-most 128 addresses on any link with prefix length <= 120."

Best regards,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 6 Jan 2019 10:45:30 +1300

A comment right at the end:

> "The subnet anycast address range is the top-most 128 addresses on any link with prefix length <= 120."

Yes, but in that case the fdff: range was an error from the beginning (compounding what I always thought was an error: the inversion of the IEEE "u" bit). If not an error, it was in any case an exception to the "top-most 128" rule.

     Brian

---

From: Ole Troan <[email-masked]>
Date: Sun, 6 Jan 2019 02:51:11 +0100

> Yes, but in that case the fdff: range was an error from the beginning (compounding what I always thought was an error: the inversion of the IEEE "u" bit). If not an error, it was in any case an exc…

Right, it all was consistent and logical until we deprecated modified EUI-64 /  U/L bit.

Here are the options I see:

a) Keep the ‘u’ flag for the reserved anycast block
b) Drop the ‘u’ flag and make the block “purely” the  top-most 128 addresses. Would require updating at least 2526
c) Deprecate the subnet anycast block altogether
d) Do nothing

Cheers,
Ole

---

From: Sander Steffann <[email-masked]>
Date: Sun, 6 Jan 2019 14:53:06 +0100

Hi,

> c) Deprecate the subnet anycast block altogether

What would be the reason to keep it?

Cheers,
Sander

---

From: David Farmer <[email-masked]>
Date: Sun, 6 Jan 2019 10:21:29 -0600

Comments inline;

On Sat, Jan 5, 2019 at 3:45 PM Brian E Carpenter <
[email-masked]> wrote:

> >> And how costly it would be to restate the reserved state as top-most
> 128 addresses, and not carry with us the U/G bits?
> >>
> > Doesn’t the mobile agent already need to know the type of home-link, if
> it is on a link-type using modified EUI-64 (and it’s prefix length)?
>

To be safe, if I were implementing a Moblie node I would probably try both
anycast addresses [Home subnet]:ffff:ffff:ffff:ff7e and [Home
subnet]:fdff:ffff:ffff:ff7e, and if implementing a Home-Agent I would
probably bind to both addresses as well. But, I have no idea what
implementations actually do.

> >> range (along with revising RFC2526), but it may be the least disruptive.

You seem to assume Moblie IP implementation are using fdff:ffff:ffff:ff7e,
if they are then your assumption about what is easier holds, but if any
Moblie IP implementations use ffff:ffff:ffff:ff7e then your assumption
doesn't hold.

> link with prefix length <= 120."

+1

> Yes, but in that case the fdff: range was an error from the beginning
> (compounding what I always thought was an error: the inversion of the IEEE
> "u" bit). If not an error, it was in any case an exception to the "top-most
> 128" rule.
>

+1

---

From: David Farmer <[email-masked]>
Date: Sun, 6 Jan 2019 10:37:25 -0600

> What would be the reason to keep it?

Well the only reason I can think of is RFC6275 Mobile IPv6 Home-Agents, and
according to RFC7094 it is the only use of the Reserved IPv6 Subnet Anycast
Addresses, and I couldn't find anything else in my looking.

---

From: David Farmer <[email-masked]>
Date: Sun, 6 Jan 2019 11:44:23 -0600

This is how I see it.

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

---

From: Kerry Lynn <[email-masked]>
Date: Sun, 6 Jan 2019 17:20:02 -0500

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

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

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

> 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
> therefore at the very least this bolck needs to be added to the reserved
Again, it would be great to hear from someone with Mobile IPv6 operational
experience.

Regards, Kerry

Cheers,