Re: Generic anycast addresses...

[Mark Smith <[e-mail]>]

On Sat., 13 Jul. 2019, 10:27 Erik Kline, <[e-mail]> wrote:

>
>
> On Fri, 12 Jul 2019 at 16:33, Mark Smith <[e-mail]> 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.)
>>
>> <snip>
>>
>> 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. =)
>

Well, there is only going be either zero or one anycast instances of that
anycast service to send to, within the node. That's a limitation of the
node local scope if you want a single node to somehow provide multiple
different anycast service instances, listening on the same anycast address.
Multicast within a node local scope has the same limitation.

While a limitation of the node-local scope, I don't think only zero or one
instances stops it being anycast. Anycasting is about sending to one of any
number of instances, which could be zero, one or more instances at any
particular time. That's similar to multicast, a multicast group can have
only one member.

(There's an address example error in that version of the draft, I moved
where the scope nibble was to the 3rd position, so the above would be
aa10::/16. It's corrected in the next version, although I can't submit it
right now.)


> (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, <[e-mail]> wrote:
>>
>>> On Jul 12, 2019, at 8:14 AM, Bob Hinden <[e-mail]> 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
>>> [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
>> --------------------------------------------------------------------
>>
>