Re: Generic anycast addresses...

When there are multiple use cases, global anycast (PCP, TURN), and now site
scope, then a more general solution should be developed that accommodates
other future forseeable use cases (admin scope, enterprise scope, ISP scope
etc.)

You're already discovering the problems with ad hoc allocation and no
formal scheme. A formal address space was identified in RFC 1546 as one of
the ways to support anycast.

A reminder that the U in ULA stands for Unique. If the ULA-C address space
is used to define globally well known anycast addresses, that are to be
duplicated across different networks, then the you would now have
Non-Unique Unique Local Addresses.

I've spent more than 2 years thinking about this topic and 10s of hours
writing a 25 page draft about this topic. People can save time by reading
it. Even if people don't agree with the proposal, the considerations and
similar topics should still be useful.

IPv6 Formal Anycast Addresses and Functional Anycast Addresses

https://tools.ietf.org/id/draft-smith-6man-form-func-anycast-addresses-00.txt

(Given recent experiences here with IDs, where people have kept asking
about things already covered in the draft under discussion (the IPv6 only
flag ID), and during IETF last call for rfc4291bis,
I'm starting to think writing drafts is a waste of time, because people
would much rather send an email than spend the time reading the draft.)

On Sat., 13 Jul. 2019, 01:20 Ted Lemon, <mellon@fugue.com> wrote:

> On Jul 12, 2019, at 8:14 AM, Bob Hinden <bob.hinden@gmail.com> wrote:
>
>   Anycast addresses are allocated from the unicast address space, using
>   any of the defined unicast address formats.  Thus, anycast addresses
>   are syntactically indistinguishable from unicast addresses.  When a
>   unicast address is assigned to more than one interface, thus turning
>   it into an anycast address, the nodes to which the address is
>   assigned must be explicitly configured to know that it is an anycast
>   address.
>
>
> Sorry, the distinction here is that we’re talking about well-known anycast
> addresses being used for resource discovery or edge probing, not anycast
> addresses generally.
>
> So yes, of course anycast addresses can just be unicast addresses, and can
> come either from an org’s delegated prefix or from a global IANA prefix.
> However, this isn’t always what we want; in the case of SRP, it’s better if
> it doesn’t leave the site, for example, so a unique local address would be
> a better choice than something in 2001::/16.   But we don’t have a
> mechanism for allocating well-known anycast addresses out of the unique
> local address space.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>