Re: Question on anycast IID range(s)

On Wed, Jan 2, 2019 at 2:57 PM Brian E Carpenter <
brian.e.carpenter@gmail.com> 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.

BTW, RFC2526 is unmotivated. Why do we *need* a convention for
> 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
>
>
> > ..
> >
> > Regards, Kerry
> >
> >
> > On Wed, Jan 2, 2019 at 12:57 PM Erik Kline <ek@loon.co> 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:
> >>
> >>     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 <kerlyn@ieee.org> wrote:
> >>
> >>> 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
> >>>
> >>> --------------------------------------------------------------------
> >>> IETF IPv6 working group mailing list
> >>> ipv6@ietf.org
> >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>> --------------------------------------------------------------------
> >>>
> >>
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>