Subject: Re: Generic anycast addresses...

From: Ted Lemon <[email-masked]>
Date: Fri, 12 Jul 2019 09:44:01 -0400

An update on this, in case anyone’s wondering.   It turns out that PCP does have an anycast address allocated, as do a few other protocols.   There is no explicitly designated anycast prefix, and the anycast address is just a regular global IPv6 address with no scoping rules.   It appears to be the case that the prefix 2001::1//64 has been used for this.

Ironically, I had actually put this in the SRP document a while back, and forgot about it.  This thread was sparked by my attempt to find an anycast prefix with scoping rules, which I failed to do.

FWIW, given that well-known anycast addresses are a current practice, I think it makes sense to have an explicit prefix from which they are allocated.   I do not know what would happen if I sent a PCP anycast—how far it would get before it was dropped due to lack of a route.   But it seems likely that it will escape the site.   This is probably not ideal for a lot of use cases, SRP being one of them.   So it might be worth writing a draft that addresses this and reserves a prefix with site scoping rules that we can safely assume will be followed.   Allocating a prefix out of fc00::/8 would address this problem.

I have no appetite for a general solution to this problem, and I didn’t get the sense from the (rather long) discussion we had on this that anyone else did either, with one exception.   The use case I know we need is site-scoped.

Despite being in Montreal, I will not actually be able to attend 6man because it’s opposite one of the DNS working groups.  If people are interested in talking about this, ping me and we can arrange something.

> On May 29, 2019, at 6:48 PM, Ted Lemon <[email-masked]> wrote:
> 
> I was looking through the IANA registry for anycast addresses with an idea of what I wanted, and was surprised to learn that no such thing exists.   I’m curious if what I want is something that’s already been shot down in flames, or something for which no energy has existed to do.
> 
> Right now it appears that anycast addresses either aren’t special (that is, they are just IP addresses in someone’s prefix) or are link-specific (e.g., the subnet router anycast address, which if I understand it correctly is constructed of <local-prefix>::0).
> 
> What I am looking for is an anycast address that won’t match any local prefix, so that it filters out towards an egress router and is caught somewhere along the way, or worst case, at the egress.   I can see where this would have gone down in flames, since we don’t want anycast packets to keep going toward the backbone and create congestion, so that might explain why this hasn’t happened.   But we do have the notion of scopes, e.g. for multicast, and that would seem to apply for anycast as well.   We do allow multicast in scopes larger than the local subnet, and AFAIK this has not melted the Internet.
> 
> The actual use case I have for this is wanting to be able to have a constrained device send a unicast discovery or announcement which can be assumed to be caught and handled by infrastructure.
> 
> So, is this something that’s been talked about and abandoned as a terrible idea, or abandoned because nobody wanted to do the process to make it happen, or is it (seems unlikely) an innovation on my part?   Or is it already done and I just managed to not find the document describing it?

---

From: Ted Lemon <[email-masked]>
Date: Fri, 12 Jul 2019 09:55:32 -0400

> An update on this, in case anyone’s wondering.   It turns out that PCP does have an anycast address allocated, as do a few other protocols.   There is no explicitly designated anycast prefix, and t…

Correction: 2001:1://64 (or possibly narrower, but I hope not).

---

From: Ted Lemon <[email-masked]>
Date: Fri, 12 Jul 2019 09:57:34 -0400

> Correction: 2001:1://64 (or possibly narrower, but I hope not).

Apparently I just can’t type IPv6 addresses.   Let’s try this one more time: 2001:1::/64.   But actually it looks like it’s 2001:1::/32.   This isn’t specifically stated anywhere, so we don’t really know, but the next non-/128 allocation is the next /32.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 12 Jul 2019 16:08:00 +0200

My eye says it's 2001:1::/32 not /64

Le 12/07/2019 à 15:57, Ted Lemon a écrit :
> On Jul 12, 2019, at 9:55 AM, Ted Lemon <[email-masked] 
> <mailto:[email-masked]>> wrote:
> Apparently I just can’t type IPv6 addresses.   Let’s try this one more 
> time: 2001:1::/64.   But actually it looks like it’s 2001:1::/32.   This 
> isn’t specifically stated anywhere, so we don’t really know, but the 
> next non-/128 allocation is the next /32.
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 12 Jul 2019 10:23:42 -0400

> Apparently I just can’t type IPv6 addresses.   Let’s try this one more time: 2001:1::/64.   But actually it looks like it’s 2001:1::/32.   This isn’t specifically stated anywhere, so we don’t reall…

There’s no way to answer definitively.   Certainly the remainder of the /32 is unallocated.   However, the next thing that’s allocated is explicitly a /48, and the thing that follows that is a /32.   So 2001:2::/48 is allocated, but the rest of 2001:2::/32 is not.   If a /64 were needed, the IANA could decide to allocate 2001:1:0:1::/64 and this would not create a conflict.   But since this isn’t stated explicitly, we don’t know, and it’s entirely possible that IANA would not allocate that /64, since they probably don’t know either.

For reference, here’s the part of the table I’m talking about:

2001::/23	IETF Protocol Assignments	[RFC2928 <http://www.iana.org/go/rfc2928>]	2000-09	N/A	False [1 <https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml#note1>]	False [1 <https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml#note1>]	False [1 <https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml#note1>]	False [1 <https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml#note1>]	False
2001::/32	TEREDO	[RFC4380 <http://www.iana.org/go/rfc4380>] [RFC8190 <http://www.iana.org/go/rfc8190>]	2006-01	N/A	True	True	True	N/A [2 <https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml#note2>]	False
2001:1::1/128	Port Control Protocol Anycast	[RFC7723 <http://www.iana.org/go/rfc7723>]	2015-10	N/A	True	True	True	True	False
2001:1::2/128	Traversal Using Relays around NAT Anycast	[RFC8155 <http://www.iana.org/go/rfc8155>]	2017-02	N/A	True	True	True	True	False
2001:2::/48	Benchmarking	[RFC5180 <http://www.iana.org/go/rfc5180>][RFC Errata 1752 <http://www.rfc-editor.org/errata_search.php?eid=1752>]	2008-04	N/A	True	True	True	False	False
2001:3::/32	AMT	[RFC7450 <http://www.iana.org/go/rfc7450>]	2014-12	N/A	True	True	True	True	False
If your MUA rendered this incomprehensibly, here’s the actual URL for convenience: https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml <https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml>

---

From: Bob Hinden <[email-masked]>
Date: Fri, 12 Jul 2019 08:14:37 -0700

Ted,

> On Jul 12, 2019, at 6:44 AM, Ted Lemon <[email-masked]> wrote:
> 
> An update on this, in case anyone’s wondering.   It turns out that PCP does have an anycast address allocated, as do a few other protocols.   There is no explicitly designated anycast prefix, and the anycast address is just a regular global IPv6 address with no scoping rules.

That is, of course, the definition of IPv6 anycast addresses.

From Section 2.6. Anycast Addresses of RFC4291:

   An IPv6 anycast address is an address that is assigned to more than
   one interface (typically belonging to different nodes), with the
   property that a packet sent to an anycast address is routed to the
   "nearest" interface having that address, according to the routing
   protocols' measure of distance.

   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.

   . . . .

Bob

> It appears to be the case that the prefix 2001::1//64 has been used for this.
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 12 Jul 2019 08:19:47 -0700

>   assigned must be explicitly configured to know that it is an anycast

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.

---

From: Bob Hinden <[email-masked]>
Date: Fri, 12 Jul 2019 08:30:16 -0700

Ted,

> On Jul 12, 2019, at 8:19 AM, Ted Lemon <[email-masked]> wrote:
> 

Understood, but the way you wrote your email, it sounded like you were surprised about their properties.

I am fine if someone wanted to write a draft to define the centrally assigned ULAs, and how they would work for this purpose. The hard part is to decide how the allocations and registration work.   I would be happy to discuss this with you in Montreal.

Bob

---

From: Ted Lemon <[email-masked]>
Date: Fri, 12 Jul 2019 11:35:59 -0400

Thanks!

Sent from my iPhone

> On Jul 12, 2019, at 11:30 AM, Bob Hinden <[email-masked]> wrote:
> 
> Ted,
>

---

From: Mark Smith <[email-masked]>
Date: Sat, 13 Jul 2019 09:32:59 +1000

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, <[email-masked]> wrote:

> 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.
>

---

From: Erik Kline <[email-masked]>
Date: Fri, 12 Jul 2019 17:27:43 -0700

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

>> 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

---

From: Mark Smith <[email-masked]>
Date: Sat, 13 Jul 2019 12:34:01 +1000

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

>> <snip>
> 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.)