Re: Generic anycast addresses...

On Fri, 12 Jul 2019 at 16:33, Mark Smith <markzzzsmith@gmail.com> wrote:

> 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
>
>
I admit I find the "interface-local" text in in 4291#2.7 somewhat confusing
(as it compares to link-local), but the possibility of using aa01::/16 for,
if I may, node-local anycast seems like it might be fun. =)

(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
>> --------------------------------------------------------------------
>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>