Re: Generic anycast addresses...

[Mark Smith <[e-mail]>]

On Thu, 30 May 2019 at 11:12, George Michaelson <[e-mail]> wrote:
>
> point of information. the RIR system exists, and in the ULA
> discussions it was understood that globally unique assigned address
> processes were RFC bound in RFC2050 and subsequently RFC7020.
>
> If it becomes necessary to implement the service, the RIRs already
> indicated they understood how to manage ULA distribution with
> uniqueness, and mechanisms to apply normal address services like
> WHOIS.
>
> I guess I'm saying "just because we don't, doesn't mean we can't"
>

I think the multicast well-known group address model applies here,
because anycast addresses typically represent functions or services
rather than actual nodes, so IANA would be the likely registration
authority.

Anycast services and functions are quite similar to multicast groups
representing services. From that perspective, the only fundamental
difference between anycast and multicast is that a packet sent to an
anycast service or function is only delivered to one of the set of
anycast nodes, where as a packet sent to a multicast service or
function is delivered to all of the set of multicast nodes.

IANA have already assigned some global anycast addresses:

RFC7723] reserves the IPv6 address 2001:1::1/128 for the use as the
   Port Control Protocol Anycast address.

   [RFC8155] reserves the IPv6 address 2001:1::2/128 for the use as the
   Traversal Using Relays around NAT Anycast address.

We're already down the path of formally defining global-scope
individual anycast addresses, so organising anycast addresses into
their own address class with fine grained scopes that are the same as
multicast scopes, and including other information (which is also
already similarly recorded in multicast addresses) could be more
useful than just individual global scope /128s in a number of
scenarios. I've suggested some example use cases in the draft.

Regards,
Mark.




> -G
>
> On Thu, May 30, 2019 at 11:08 AM Mark Smith <[e-mail]> wrote:
> >
> > On Thu, 30 May 2019 at 10:58, Toerless Eckert <[e-mail]> wrote:
> > >
> > > I cant brainstorm a lot more without more details of what you're
> > > trying to achieve, and  therefore what the constraints are.
> > >
> > > Worst case, you float the idea to a single ULA prefix defined
> > > by your RFCs mecanism and see how reviewers like this. At least its
> > > a lot better than trying to define a "well known" rfc1918
> > > anycast address - because your application defined ULA
> > > prefix has a very low probability of colliding with somebodies
> > > actually used ULA prefix.
> >
> > Per RFC4193 4.1 and the route propagation constraint, ULAs effectively
> > have an organisation scope by default. That may be too small or too
> > large for other anycast use cases.
> >
> > If there is a reserved well-known ULA prefix, then RFC 4193 would have
> > to be updated to exclude that value from the algorithm. We also don't
> > know if the chosen well-known ULA prefix is already in use somewhere.
> >
> > I think a better idea is a formal class of anycast addresses with fine
> > grained scopes that match (or are) the multicast address scopes.
> >
> > "IPv6 Formal Anycast Addresses and Functional Anycast Addresses"
> > https://tools.ietf.org/html/draft-smith-6man-form-func-anycast-addresses-00
> >
> >
> > > On Wed, May 29, 2019 at 05:41:04PM -0700, Ted Lemon wrote:
> > > > Indeed, the propagation pattern of a ULA would work nicely for this, but there???s no way to do this automatically.   I might have (and indeed unfortunately it???s common to have) more than one ULA on a constrained network.   How do I pick?   :)
> > > >
> > > > So what I really want is indeed something that is treated like a ULA, but that can be a constant, and not something that has to be derived.
> > >
> > > --
> > > ---
> > > [e-mail]
> > >
> > > --------------------------------------------------------------------
> > > IETF IPv6 working group mailing list
> > > [e-mail]
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > --------------------------------------------------------------------
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------