Re: Question on anycast IID range(s)

[Kerry Lynn <[e-mail]>]

On Sat, Jan 5, 2019 at 7:19 AM Ole Troan <[e-mail]> 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
> 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.
>
> 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?
>
> 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


> Cheers,
> Ole