Subject: Generic anycast addresses...

From: Ted Lemon <[email-masked]>
Date: Wed, 29 May 2019 15:48:22 -0700

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?

Thanks!

---

From: Dave Thaler <[email-masked]>
Date: Wed, 29 May 2019 22:58:25 +0000

See RFC 7094 (https://tools.ietf.org/html/rfc7094) for history and discussion.

Dave

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Ted Lemon
Sent: Wednesday, May 29, 2019 3:48 PM
To: [email-masked]
Subject: Generic anycast addresses...

Thanks!

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6&amp;data=02%7C01%7Cdthaler%40microsoft.com%7C6e224fa0b7b74966e80e08d6e487cf86%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636947669302316535&amp;sdata=Xl7PhIj%2FHbOEN%2BtY9oeejMJw%2BmlT5bL3Z96FiLUdQiU%3D&amp;reserved=0
--------------------------------------------------------------------

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 May 2019 15:59:43 -0700

On May 29, 2019, at 3:58 PM, Dave Thaler <[email-masked]> wrote:
> See RFC 7094 (https://tools.ietf.org/html/rfc7094 <https://tools.ietf.org/html/rfc7094>) for history and discussion.

Ah, thanks.   I knew I’d heard this discussed before.

---

From: George Michaelson <[email-masked]>
Date: Thu, 30 May 2019 09:08:35 +1000

I read that document as saying "we don't know right now, although we
suspect it doesn't scale" and "maybe in the future people could
revisit this"

So.. Is Ted's question a revisit? Is it too soon to re-visit if there
are contexts where it would be useful to have some small number of
constrained use anycast prefixes, which could be used to engineer
things between the purely local and global contexts?

The idea of being able to send a sonar-ping like "wtf" out to some TTL
constrained boundary, and find the nearest best-fit thing you would
possibly want to fulfill a role, I think thats pretty good. A local
7-11 or Lawsons on every corner is like link-local. What if I need the
nearest shop which actually has a barista? Google models this already
in maps. We're all routinely used to the idea of a somewhat loosely
defined constraint on "anywhere" which is "near" but that is definedly
NOT link-local only.

-G

On Thu, May 30, 2019 at 8:58 AM Dave Thaler
<dthaler=[email-masked]> wrote:
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 May 2019 16:10:18 -0700

> See RFC 7094 (https://tools.ietf.org/html/rfc7094 <https://tools.ietf.org/html/rfc7094>) for history and discussion.

Unfortunately this document doesn’t really talk about the use case I’m referring to.   We did talk about doing this for DNS and for PCP, but neither of those proposals ever got the point of actually wanting to do something.   I don’t think what I’m talking about is novel, but it appears that not only hasn’t it caught on, but it’s not even really talked about in the places where one might wish for it to be talked about.

RFC 7094 seems to be mostly focused on what can go wrong if you try to deploy internet-wide services using anycast, which is an interesting problem, but essentially orthogonal to what I’m describing, which is more like an automatic zero-packet service discovery mechanism, and which I would expect to be constrained to scopes on the site side of site edge routers.

---

From: Mark Smith <[email-masked]>
Date: Thu, 30 May 2019 10:24:48 +1000

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

I wasn't aware of anything like that, so, like a TV cook, I prepared
something earlier.

"IPv6 Formal Anycast Addresses and Functional Anycast Addresses"
https://tools.ietf.org/html/draft-smith-6man-form-func-anycast-addresses-00

- well known anycast address prefix - "aa00::" suggested
- scopes that match those of multicast (note there is a scope position
error throughout the above draft, the scope nibble is the 3rd rather
than the 4th i.e. the upper 16 bits are "aa<scope><subformat>::/16"
- supports subformats for the lower 112 bits
- first subformat is a functional address space which supports 24 bit
function identifiers, possibly 32 bit function identifiers, and embeds
up to a /64 prefix to identify an "anycast domain", and flags e.g.
transient or permanent function identifiers.

All very much inspired by many of the IPv6 multicast capabilities and
features - it seems to me that anycast has properties common with both
unicast and multicast, so its actually a distinct class of addresses,
rather than being an informal type of unicast address.

I've been working on another update which I can probably push out in
the next day or so:

- introduces an "Network Service Provider" scope, which is greater
than organisation scope and global scope, to suit an ISP DNS resolver
use case, protecting the DNS resolver from a DDoS from the Internet.

- suggests the use of anycast addresses for hop by hop processing of
packets as an alternative to the HbH EH - when a intermediate packet
processing node (i.e. doing more than pure IPv6 forwarding) submits
the packet for further forwarding post processing, the local instance
of the anycast address is ignored (the "is it my DA" check is
skipped), and RPF is applied on the source address so the packet keeps
moving away from the packet's origin (i.e. the multicast RPF check).
This type of forwarding probably could be applied to "informal
anycast" as well as the "formal anycast" I've suggested above, so
maybe it should be a separate ID.

Regards,
Mark.

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 30 May 2019 02:28:33 +0200

Ted:

Just because you would like for the anycast address to have a member
somehwere close to the edge so the anycast address packet does not
aimlessly roam the Internet does not mean that every edge would have
such an anycast member that captures the packet before it escapes.

At least that would be my main concern if i correctly understood
your use case intentions... which you really didn't explain in a lot
of detail. So i am just guessing.

AFAIK, all the successful deployments of anycast even across the Internet
are based on using addresses belonging to one organization, and
that organization is able to control where the member instances
are in the Internet and what apps they are used for and therefore
one org can ensure the deployment model works. Example:
anycast in DNS/CDN.

Whenever a solution attempts to go beyond this, it becomes difficult,
and thorough understanding of rfc7094 i probably useful. Alas, there
seems to be no good "great working anycast deployment recipes" RFC,
which would probably be more helpful.

So, if you have any way to design your solution to first discover
a local environment specific anycast address, then you should be
fine. If you expect that all type of software could hardcode an
Internet wide single anycast address -> probably forget about it.

Wrt to your notion of scoped addresses and IP multicast:
Anycast IMHO is just a variant of unicast, not multicast, so the
argument "this works in multicast, so it should also work in
unicast/anycast" doesn't work. In fact, in unicast, site-scoped
addresses where removed from the architecture, so AFAIK, we
are only left with LL, ULA and global.

Which makes me think that you could try to construct a ULA prefix
to use for anycast from whatever "local" information you have
(worst case the unicast prefix used), and then the resulting ULA
address would be anycast and given how its ULA, its not supposed
to go to the internet and would be filtered on Internet edges
by default UNLESS your routing system puts routes for that ULA
prefix in.  Of course, some probability analysis of hash collision
to be considered.

Toerless

On Wed, May 29, 2019 at 04:10:18PM -0700, Ted Lemon wrote:
> Unfortunately this document doesn???t really talk about the use case I???m referring to.   We did talk about doing this for DNS and for PCP, but neither of those proposals ever got the point of actually wanting to do something.   I don???t think what I???m talking about is novel, but it appears that not only hasn???t it caught on, but it???s not even really talked about in the places where one might wish for it to be talked about.
> 
> RFC 7094 seems to be mostly focused on what can go wrong if you try to deploy internet-wide services using anycast, which is an interesting problem, but essentially orthogonal to what I???m describing, which is more like an automatic zero-packet service discovery mechanism, and which I would expect to be constrained to scopes on the site side of site edge routers.
> 

-- 
---
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 May 2019 17:41:04 -0700

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.

---

From: Bob Hinden <[email-masked]>
Date: Wed, 29 May 2019 17:48:19 -0700

Ted,

> On May 29, 2019, at 5:41 PM, Ted Lemon <[email-masked]> wrote:
> 

We when ULAs were being developed, there was a notion of centrally assigned ULAs.  It’s not currently defined, but that’s was the original intent for having the “L” bit in the prefix.  See RFC4193.

Bob

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 May 2019 17:56:22 -0700

> We when ULAs were being developed, there was a notion of centrally assigned ULAs.  It’s not currently defined, but that’s was the original intent for having the “L” bit in the prefix.  See RFC4193.

Hm.   I had thought about that, but assumed there was some reason why we couldn’t do it.   But now that you mention it, since there is currently no authority other than IANA to assign these prefixes, we could in principle simply have IANA assign one of them to use for anycast addresses that anycast within the local administrative domain?

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 30 May 2019 02:57:34 +0200

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. 

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?   :)
> 

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 30 May 2019 02:59:20 +0200

Yepp. we brainstormed reviving the definition for that bit when doing ACP
in ANIMA, but felt it would be too much work.

I would have loved if some of the informal sites on the internet where
you could list your ULA prefix use would still be there, but they all
seemed to have died ;-(

On Wed, May 29, 2019 at 05:48:19PM -0700, Bob Hinden wrote:
> We when ULAs were being developed, there was a notion of centrally assigned ULAs.  It???s not currently defined, but that???s was the original intent for having the ???L??? bit in the prefix.  See RFC4193.
> 
> Bob
> 
> 
> 
>

---

From: Mark Smith <[email-masked]>
Date: Thu, 30 May 2019 10:59:04 +1000

Hi Bob,

> We when ULAs were being developed, there was a notion of centrally assigned ULAs.  It’s not currently defined, but that’s was the original intent for having the “L” bit in the prefix.  See RFC4193.

I would guess Ted is looking for well-known addresses that can be
encoded in applications, similar to how well-known multicast addresses
can be encoded in applications. That would mean they're not unique,
contrary to the U.

Having deployed anycast DNS service in the past, being a reviewer of
RFC 7094, and having thought about this sort of problem space for a
while, I came to the conclusion that there should be a formal class of
IPv6 anycast addresses that include fine grained scopes. A separate
class of addresses is also what the authors of  RFC 1546 suggested as
an option for anycast support.

Regards,
Mark.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 May 2019 17:59:28 -0700

> actually used ULA prefix.

I think if it makes sense to do this, we should probably allocate a prefix as Bob suggested, and then reserve that for this general purpose.   I don’t think we should invent this scheme in a particular document that’s being worked on in dnssd.  :)

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 30 May 2019 03:00:11 +0200

Ted: Its a big prefix space, and it would be really difficult to
argue starting to use it for just one address. 

On Wed, May 29, 2019 at 05:56:22PM -0700, Ted Lemon wrote:
> Hm.   I had thought about that, but assumed there was some reason why we couldn???t do it.   But now that you mention it, since there is currently no authority other than IANA to assign these prefixes, we could in principle simply have IANA assign one of them to use for anycast addresses that anycast within the local administrative domain?
>

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 30 May 2019 03:05:05 +0200

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

Anycast is not the issue. Scoping unicast is the issue. When you manage
to work that out, you can get scoped anycast for free. But scoped
unicast failed and was removed, except for ULA AFAIK. Go figure.

I think the pragmatic way is to actually continue to build successful
experiments with the existing ULA definitions we have.

-- 
---
[email-masked]

---

From: Mark Smith <[email-masked]>
Date: Thu, 30 May 2019 11:07:40 +1000

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

---

From: George Michaelson <[email-masked]>
Date: Thu, 30 May 2019 11:12:38 +1000

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"

-G

---

From: Mark Smith <[email-masked]>
Date: Thu, 30 May 2019 15:05:24 +1000

On Thu, 30 May 2019 at 11:05, Toerless Eckert <[email-masked]> wrote:
> Anycast is not the issue.

Ted asked for a scoped anycast solution.

> Scoping unicast is the issue. When you manage

No need to "go figure", explained why in RFC 3879.

The problem with the Site-Local unicast address space is that multiple
nodes holding the same unicast address (as in, meant to permanently
and exclusively identify one and only one node - "uni") is a fault.
The Site-Local unicast address space inadvertently created a potential
fault condition by design because it created unicast address
ambiguity.

Multiple nodes intentionally holding the same anycast address (as in,
not permanently exclusive to one and only one node) is not a fault and
is expected.

One operational problem with anycast address today is that you can't
look at the address and determine if it is intended to be an anycast
address or not, meaning you can determine if a duplicate address is a
fault or not. That is because they're assigned from within the unicast
address space, rather than from a specific formal anycast address
space. Contrast that with multicast addresses, which are assigned from
within their own formal address space.

> experiments with the existing ULA definitions we have.

ULAs don't meet the requirements. If a ULA address is globally
assigned by IANA and well known, and possibly used in multiple
different networks, it is not Unique and it is not Local anymore.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Thu, 30 May 2019 15:14:30 +1000

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

---

From: George Michaelson <[email-masked]>
Date: Thu, 30 May 2019 15:49:26 +1000

yes, if you couch it like that, its not a unique assignment, its a WKS
type centrally managed. Its not global unicast, there is no single
entity which asserts control.

Thats an IANA function as I see it.

The BGP implications for this address would be interesting because the
origin-AS would vary a lot. If nobody has it, nobody can ROA it or
route: object it, but that is probably handled in other ways in route
filtering.

btw I'm not an address policy person, I only work in RIRland, so this
isn't a binding commitment statement, its just how I think.

-G

---

From: Mark Smith <[email-masked]>
Date: Thu, 30 May 2019 16:43:11 +1000

> entity which asserts control.

Yes, IANA would be the authority for global Well-Known service or
function Anycast Function Identifiers.

Also similar to multicast, a local domain can define its own local
service AFIs, with a flag encoding that choice.

The idea of a reserved part of the number space for anycast addresses
is not new.

For example, 131 888 is the phone number for one of the closest local
pizza delivery services here in Melbourne, and in Adelaide, and in
Perth etc., where the 13 prefix (and 1800 or 1300 prefixes) indicate
anycast phone numbers. I assume similar prefixes in other countries
are different, so 13, 1800 and 1300 could be considered to have
"country scope".

> route: object it, but that is probably handled in other ways in route

If you're referring to the eBGP example, "5.7.3. Automatic eBGP
Session Establishment", I've realised that it probably isn't that
clear that I was more imagining private ASNs or the single ASN that an
ISP uses for its customers, both connected to a single ISP. That is,
not a globally unique ASN for a properly multi-ISP multihomed router.

Perhaps that could be possible with the use of an initial well-known
default ASN used to bootstrap the connection to the point where the
router can then somehow then acquire the globally unique ASN that it
switches to using. Out of scope for this ID I think.

> isn't a binding commitment statement, its just how I think.

Thanks very much for your comments.

Regards,
Mark.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 30 May 2019 09:13:54 +0200

In fact, I tried to rescue ULA-central by means of having the support in RIR policies (see pointers below). It didn't reached consensus at that time, but new arguments, new experience may change the situation (it happened already several times with other policy proposals).

After we get that, we can advance draft-ietf-ipv6-ula-central.

If we think this is a possible path, I'm happy to work again in the ULA-Central policy proposals in the 5 RIRs.

https://www.ripe.net/participate/policies/proposals/2007-05
https://www.apnic.net/community/policy/proposals/prop-048/
https://afrinic.net/policy/archive/proposal-for-ipv6-ula-central-afpub-2007-v6-003
https://www.lacnic.net/innovaportal/file/556/1/lac-2007-06-sp.pdf

I can't find the ARIN one, not sure if I presented it there as well.

Regards,
Jordi

El 30/5/19 3:13, "ipv6 en nombre de George Michaelson" <[email-masked] en nombre de [email-masked]> escribió:

    
    
    -G

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Mark Smith <[email-masked]>
Date: Thu, 30 May 2019 17:44:37 +1000

> After we get that, we can advance draft-ietf-ipv6-ula-central.

I don't really see how ULA central solves a scoped well known anycast
address problem that would support multiple forwarding domain scopes.

ULAs only have a single scope, and that is global per RFC 4193 and
https://tools.ietf.org/html/draft-carpenter-6man-whats-global-00.

However, in terms of reachability or forwarding domain scope, ULAs
effectively have an administrative scope by default, due to this text
in RFC 4193:

"The default behavior of exterior routing protocol sessions between
   administrative routing regions must be to ignore receipt of and not
   advertise prefixes in the FC00::/7 block.  A network operator may
   specifically configure prefixes longer than FC00::/7 for inter-site
   communication."

So if somebody wants to have a anycast address, well known or not,
that has a limited forwarding domain that is smaller or larger than
administrative, such as one of these,

Interface-Local scope
Link-Local scope
Realm-Local scope
Site-Local scope
Organization-Local scope
Network Service Provider scope
Global scope

ULA isn't going to suit.

A Link-Local anycast address or a GUA anycast address ticks off two of
the above, however there are no other unicast address scopes that
could suit any of the remaining ones. (That's the multicast address
scope list with the addition of a Network Service Provider scope that
would encompass its downstream customers' networks.)

Regards,
Mark.

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 30 May 2019 13:24:19 +0200

> Ted asked for a scoped anycast solution.

My point was that scoped anycast would operate on top of
scoped unicast which we deprecated.

> No need to "go figure", explained why in RFC 3879.

Right. I know. Back when this was happening i felt this was somewhat
ridiculous because scoped multicast addresses where not deprecated and
those scoped multicast addresses where/are even worse than scoped
unicast in the way they are defined in the IPv6 architecture. 

> fault condition by design because it created unicast address

"Fault" is your assesment, its not rfc3879 language. For me its really
hard to agree fully with rfc3879 because it draws a lot of justification
from comparison with rfc1918, yet rfc1918 was back in 2004 and likely is
still today the address space with the most number of host on the planet.
How bad is something you call a fault if the mayority of the planet runs 
on it ?  IMHO, the IPv6 architecture addition of (arbitrarily) locally
numbered zones was the ambitious but insufficient fail, not the concept of
scoped adresses itself. The scoped addresses where just counterintuitive
to the global peer-to-peer connectivity vision of IPv6.

> within their own formal address space.

Dedicated anycast address space would IMHO not help to magically
make network layer deployment easier or more broadly deployable than
it is today. The only benefit would be to transport layer, and i think
by now we worked out how to deal with anycast in transport or other
higher layer protocols without dedicated anycast address space. 

> different networks, it is not Unique and it is not Local anymore.

Agreed, but that was not the proposal. 

Cheers
    Toerless

---

From: Sander Steffann <[email-masked]>
Date: Thu, 30 May 2019 14:49:20 +0200

Hi Mark,

> than the 4th i.e. the upper 16 bits are "aa<scope><subformat>::/16"

I think I'd prefer "aa<subformat><scope>::/16" for consistency with multicast addresses. OTOH your format is much easier to filter at scope boundaries, but I guess it's too late to change the multicast specs ;)

> rather than being an informal type of unicast address.

I agree.

> use case, protecting the DNS resolver from a DDoS from the Internet.

Very good idea. The same scope can be used for multicast as well. It would fit things like live TV streams in a service provider network to provide them to their customers rather well.

> maybe it should be a separate ID.

I don't understand the use case for this one yet.

Anyway: I think this can be very useful! Easily recognisable addresses, explicit scope. I like it :)

Cheers,
Sander

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 May 2019 10:30:12 -0400

Ted Lemon <[email-masked]> wrote:
    > Unfortunately this document doesn’t really talk about the use case I’m
    > referring to.   We did talk about doing this for DNS and for PCP, but
    > neither of those proposals ever got the point of actually wanting to do
    > something.   I don’t think what I’m talking about is novel, but it
    > appears that not only hasn’t it caught on, but it’s not even really
    > talked about in the places where one might wish for it to be talked
    > about.

RFC7084 points out:

   Anycast addresses are syntactically indistinguishable from unicast
   addresses.  Anycast addressing is equivalent to that of unicast in
   multiple locations.

and I think you want an address which is synatically distinguishable from
unicast.  Maybe something that does not get caught by default route; although
I'm not sure about that.

Maybe we could have hacked in what you want into site-local space, but that's deprecated.
I don't think it can go into link-local space.

In the case where the service is not available in the homenet/campus, where
would the packet get discarded?   Maybe this could be done in an IANA
allocated /48 that we all agree to blackhole route on the DFZ, but this seems
like it might be a hack.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 May 2019 10:33:57 -0400

> not permanently exclusive to one and only one node) is not a fault and

So maybe site-local space can be used for scoped anycast?

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 May 2019 10:36:06 -0400

> I think if it makes sense to do this, we should probably allocate a
    > prefix as Bob suggested, and then reserve that for this general
    > purpose.   I don’t think we should invent this scheme in a particular
    > document that’s being worked on in dnssd.  :)

I think if using the ULA space, that it should be allocated in ULA-"C" space.
It seems that we'd really be asking IANA to carve out a /48 out of ULA-C
space, give it a new name, and create a new IANA registry.
This leaves the rest of ULA-C space undefined, which is the current state.
I think that the IESG can approve such a thing.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 May 2019 10:44:49 -0400

Ted, having read through the thread, maybe you can do this with a multicast address which
typically has only one listener :-)

In ROLL, when doing the MPL work, we would up making the Admin-Local scope
multicast more precise.  We did this in RFC7732.
Probably not... but the concept you want is Admin-Local scope.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 May 2019 07:55:03 -0700

> I think that the IESG can approve such a thing.

That seems reasonable.  Even if at some point we want to have a mechanism for allocating ULAs globally, this would just be one that was allocated globally.

> So maybe site-local space can be used for scoped anycast?

How are site-local addresses routed now?   If a packet with a site-local address as a destination escapes to the backbone, does it go anywhere, or is it blackholed immediately?

> unicast.  Maybe something that does not get caught by default route; although

I don’t actually care for my application whether the address is semantically distinct from unicast.   However, I think from an internet architecture standpoint we do care, and we want the behavior to be scoped.   Mark’s proposal is quite a bit more heavyweight than what I’m looking for; not necessarily the wrong thing to do, just more than I need. I’m wary of “more than I need” solutions because it’s hard to get traction with them, as Mark has rather aptly demonstrated on this thread.

I do care that the anycast be routed edge-ward, so in fact I want it to be routed toward a default route.  My expectation would be that like a ULA destination, a packet heading for this anycast destination would be discarded by a border router if it reached one, unless the border router is where it’s consumed.   In the specific application I have in mind, the constrained-network border router, which would be on the way to the edge router but would be reached first, would either consume the anycast or direct it to the right destination, which would be within the operational domain containing the originating host.

I can see value in Mark’s idea of a scope that’s wider than this, but I think it’s problematic because for a multiply-homed network, it’s not going to be clear which ISP is the correct destination for the anycast.   Could be either, neither or both.   No way to know without configuration, which is what I’m trying to avoid requiring.   So that’s why I’m not leaping enthusiastically at Mark’s proposal, interesting though it is.

> typically has only one listener :-)

I don’t know enough about non-local multicast to know whether or not this is a good idea, but it’s certainly a plausible idea.  My worry would be that it would actually be treated as a multicast.   That might produce some interesting side effects given that the application I have in mind involves DNS updates, which are not idempotent.

> Or maybe you want a more radical rethink. There's one at https://tools.ietf.org/html/draft-jiang-service-oriented-ip <https://tools.ietf.org/html/draft-jiang-service-oriented-ip>. We hadn't thought of it for constrained devices, but I don't see an issue there.

Like Mark’s proposal, this is quite a bit more ambitious than I want to be, although it would definitely address my use case.   The security/privacy implications alone of this proposal make it look like a decade or more of work to make real, even if it winds up seeing widespread deployment eventually.

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 30 May 2019 16:55:29 +0200

> unicast.  Maybe something that does not get caught by default route; although

+1

If we want to improve support for anycast, i would start figuring out
what we could do in the routing protocol domain. I am not aware of
any explicit support for anycast thats actually widely deployed.
We are still running anycast routing (for decades now) as an unexpected
bonus from the way our routing protocols work.

Indeed, it may be more difficult right now to operationally discover
what Mark called the "fault", e.g.: discovering when the same prefix
is incorrectly announced from two different originating sources than
just assuming its path redundancy or anycast. Appropriate tagging
sourced route information could help a lot to improve diagnostics
and allow more flexible anycast policies. main issue is tht routing
folks don't like to do new stuff unless their pain level is high enoug,
and "anycast routing kinda works well enough right now" (famous last words).

In any case i am a lot more a fan of solving the policies of addresses
being anycast rather than "fault" in the routing than the RIR domain.

toerless

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 30 May 2019 17:29:03 +0200

> That seems reasonable.  Even if at some point we want to have a mechanism for allocating ULAs globally, this would just be one that was allocated globally.

I still haven't seen an argument why this anycast scoped app could not
simply use an existing ULA prefix. AFAIK, there is nothing prohibiting
the author of an app using ULA to pick the randomn ULA prefix and write
it into an RFC. Of course, you want to make sure that your scheme still
works when multiple instances of that application/side do interconnect,
but th way i understand what you want to do, that would be the case.

I am not saying this is the best way, i am just saying that i hven't
seen enough evidence to try to create more RIR work.

> How are site-local addresses routed now?   If a packet with a site-local address as a destination escapes to the backbone, does it go anywhere, or is it blackholed immediately?

Not sure if any vendor products have defaults to filter ULA space.
Don't think i remember having seen default blackhole routes for
the ULA prefix. Could be wrong. Would assume that ULAs
today just stop  automatically in SPs on the first default-free-router.
Aka: most likely no different treatment from what you would get from
a globally allocated but not globally routed prefix.

> I don???t actually care for my application whether the address is semantically distinct from unicast.   However, I think from an internet architecture standpoint we do care, and we want the behavior to be scoped.

The scoping is the design problem given the experience with scoped
unicast addresses (and even more so multicast scoped addresses).

If you are defining anycast in the routing instead of RIR domain,
one could be a lot more flexible, for example tagging anycast prefix routes not
only with a flag saying "anycast", but also with some "zone"
identifier (such as AS domain-prefix or any other appropriate name space). 
That would allow to automatically build anycast-prefix specific zones
of arbitrary sizes without ending up in the same planning mess
we get whenever we tried to do this via fixed address architectures.

> Mark???s proposal is quite a bit more heavyweight than what I???m looking for; not necessarily the wrong thing to do, just more than I need. I???m wary of ???more than I need??? solutions because it???s hard to get traction with them, as Mark has rather aptly demonstrated on this thread.
> 
> I do care that the anycast be routed edge-ward, so in fact I want it to be routed toward a default route.  My expectation would be that like a ULA destination, a packet heading for this anycast destination would be discarded by a border router if it reached one, unless the border router is where it???s consumed.   In the specific application I have in mind, the constrained-network border router, which would be on the way to the edge router but would be reached first, would either consume the anycast or direct it to the right destination, which would be within the operational domain containing the originating host.

If you where just trying to make moneey out of an application product
doing this, you would simply use a global address from your
company and build out the clients so that the total number of
packets arriving at the actual official unicast location of that
address from clients deployed in networks without the appropriate
anycast function in routers enabled would still be bearable.
A simple service unreachable reply from the server in your
cloud location to shut up those clients would go a long way for
example. A more intelligent responder might even provide a helper
function for the resolution.

Now if you want to stanardize this, you just talk to IANA
if they have an address for you. We did the same thing
towards RFC7450 except that i think most people understaning
how Anycast works wouldn't necessary recommend to actually use
the default anycast numbers assigned to AMT in section 7 - primarily
because there is no single global entity guaranteeing that there
is such a fallback group member. 

Independent of those allocated global anycast prefixes for AMT<
the protocol itself is probably doing alreasdy something you want
to do to - resolving from anycast address to unicast instance
ddress. just the service offered is fixed (stream multicast
traffic through tunnels). Which i guess is where you want something
else.

> I don???t know enough about non-local multicast to know whether or not this is a good idea, but it???s certainly a plausible idea.  My worry would be that it would actually be treated as a multicast.   That might produce some interesting side effects given that the application I have in mind involves DNS updates, which are not idempotent.

Expecting support for layer 3 multicast routing deployed in networks
is a safe bet to kill the widespread adoption of the idea. 

> Like Mark???s proposal, this is quite a bit more ambitious than I want to be, although it would definitely address my use case.   The security/privacy implications alone of this proposal make it look like a decade or more of work to make real, even if it winds up seeing widespread deployment eventually.

Cheers
    Toerless

---

From: Sander Steffann <[email-masked]>
Date: Thu, 30 May 2019 17:48:15 +0200

Hi,

> it into an RFC.

Addresses in ULA space are expected to be used in a certain way, and scoped (well-known) anycast addresses in another. Let's keep things simple and use ULA space for ULA and a different (and more easily recognisable) prefix for anycast.

> Of course, you want to make sure that your scheme still

IMHO there should be well-known anycast addresses managed by IETF/IANA/etc. I agree that this is something that doesn't belong with the RIRs.

Cheers,
Sander

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 May 2019 10:02:53 -0700

Thanks, Sander (and everyone else!).   I’m somewhat inclined to just write a document that specifies a prefix to use for site-scoped anycast addresses.   This would give us a document to which to propose changes.   I think that the discussion thus far has been productive.   The point of this is not to override the work that Mark is doing.   It’s just to do a bite-sized chunk that has a clear use case.   I’m not convinced the WG will adopt it, but unless somebody has something new to add, I think what needs to be said has been said.

I think the two spaces out of which this could come would be fec0::/10 (site-local) and fc00://8 (the undefined block of the ULA prefix, fc00/7).   I don’t have a strong opinion on this; the arguments against using site-local that I can think of are:
People might still be using it (that’s okay, this is a new application)
GIven that it’s been deprecated for a long time, nobody is using it, so we should just mark it available for allocation, and then this isn’t the right use for it (I think this is a good argument against, in theory, but don’t have any personal opinion on whether it is correct).
Site-local addresses would in fact be routed onto the backbone (I think this is a bad argument against, but maybe I’m wrong).

The argument against fc00::/8 that I can think of is simply that we should leave it available for future use as originally intended.   I think you can’t argue that it shouldn’t be used because it might be routed on the backbone, because if that’s true, it’s a violation of current expected practice and should be fixed.

Of course, the other argument against this is simply that we shouldn’t do it, but I haven’t actually heard anyone say that, so that’s encouraging.

Thanks very much for the discussion!

---

From: Fred Baker <[email-masked]>
Date: Thu, 30 May 2019 10:50:01 -0700

> On May 29, 2019, at 5:28 PM, Toerless Eckert <[email-masked]> wrote:
> 

I second the observation. I'll add a bit: in anycast deployments for DNS, scope is handled using BGP, and is measured in policy hops, not router interfaces. My context here is that I am associated with ISC, which operates one of the DNS root services and is an anycast operation.

The issue I see is that not all servers are equal even within an anycast service. Without naming names (although there are many that could be named), imagine this scenario: there is an instance (call it "A") that is generally reachable through some domain, perhaps Central Asia, and there is some other instance (call it "B") that happens to be located in that domain but by policy only serves a smaller area, such as the systems located in a data center. Within the locality, the anycast instance near B announces its route with the community "No-export", meaning that it may be distributed freely in IBGP but is not to be exported in EBGP to a routing neighbor.

In that scenario, now place two users of the anycast service (which I will call "a" and "b" respectively) on either side of the dividing line between A and B. In routing, a will access the service at A, and b will access the service at B, even though they are each at most one routing hop from B and perhaps many EBGP hops from A.

From my perspective, this proposal would appear to work well in the Internet as it existed in 1983, but by acting in ignorance of the routing policy in force, fails dramatically at any time after the development of BGP.

I might suggest soliciting the comments of current operators of anycast services.
--------------------------------------------------------------------------------
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
     Sun Tzu

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 May 2019 10:57:08 -0700

On May 30, 2019, at 10:50 AM, Fred Baker <[email-masked]> wrote:
> I second the observation. I'll add a bit: in anycast deployments for DNS, scope is handled using BGP, and is measured in policy hops, not router interfaces. My context here is that I am associated with ISC, which operates one of the DNS root services and is an anycast operation. [etc]

I don’t disagree with anything you’ve said here, but let’s not get side-tracked: you are talking about a totally different use case than the one I’m trying to address.   If somebody wants to try to address the use case you are talking about, I would greatly appreciate that not becoming an obstacle to progress on the use case I’m actually trying to address.

Thanks!

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 May 2019 15:10:59 -0400

Toerless Eckert <[email-masked]> wrote:
    >> That seems reasonable.  Even if at some point we want to have a
    >> mechanism for allocating ULAs globally, this would just be one that was
    >> allocated globally.

    > simply use an existing ULA prefix. AFAIK, there is nothing prohibiting

there are three reasons I can give:
1) it won't be distinguishable
2) there is some small chance that someone will pick that /48 for it's use.
3) we won't be able to give it intelligent reverse DNS and whois (which we
   *can* with ULA-C or some other GUA space)

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 30 May 2019 20:14:48 +0000

On May 30, 2019, at 1:57 PM, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:

On May 30, 2019, at 10:50 AM, Fred Baker <[email-masked]<mailto:[email-masked]>> wrote:
I second the observation. I'll add a bit: in anycast deployments for DNS, scope is handled using BGP, and is measured in policy hops, not router interfaces. My context here is that I am associated with ISC, which operates one of the DNS root services and is an anycast operation. [etc]

I agree with Ted on this. I think he has a compelling use case for enterprise/LAN/intranet networks that would probably be solvable on its own. But trying to create a one-size-fits-all solution that also works on the Internet is probably futile. I’d like to see Ted’s more tightly-scoped use case tackled.
Barbara

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 30 May 2019 22:29:02 +0200

> Addresses in ULA space are expected to be used in a certain way, and scoped (well-known) anycast addresses in another. Let's keep things simple and use ULA space for ULA and a different (and more e…

No, thats not a real justification. I could equally say that unicast
addresses are expected to be used in a certain way an anycast addresses
in another.

I also don't see how scoping changes anything wrt. whether or not
ULA could be used.

> IMHO there should be well-known anycast addresses managed by IETF/IANA/etc. I agree that this is something that doesn't belong with the RIRs.

Well. i made my points why i think this is not a good solution.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 30 May 2019 22:32:38 +0200

Thanks Fred.

The scenario you describe is in principle what i think is the
right direction - using the routing control plane to define scope/zones
of addresses and their policies. Except that we haven't tried to
explicitly add features to routing protocols yet that are solely
for this anycast purpose. Not sure exactly what type of feature
might improve the zone boundary situation you're describing though.

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 30 May 2019 22:39:18 +0200

> 1) it won't be distinguishable

None of the current uses of anycast is and that hasn't been a problem.

> 2) there is some small chance that someone will pick that /48 for it's use.

Thats the problem between any two independent ssignments of ULA space,
but that hasn't stopped ULA space to be defined.

>    *can* with ULA-C or some other GUA space)

AFAIK you can not have multiple zones with the same address(es) if you
want reverse DNS lookup. So you can not use well-known/hard-coded
anycast addresses but need again to first do another
lookup/resolution/algo to figure out your local sites Anycast address(/prefix).

Cheers
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 May 2019 09:19:47 +1200

On 31-May-19 05:02, Ted Lemon wrote:
>   * People might still be using it (that’s okay, this is a new application)
>   * GIven that it’s been deprecated for a long time, nobody is using it, so we should just mark it available for allocation, and then this isn’t the right use for it (I think this is a good argument against, in theory, but don’t have any personal opinion on whether it is correct).
>   * Site-local addresses would in fact be routed onto the backbone (I think this is a bad argument against, but maybe I’m wrong).
> 
> 

I just looked at RFC3879 for the first time in many years.
Especially https://tools.ietf.org/html/rfc3879#section-2 "Adverse Effects of Site Local Addresses". I think the arguments there are still interesting.

Ted, please do think about the main point: "the fuzzy nature of the site concept". (And, shameless plug, see https://tools.ietf.org/html/draft-carpenter-limited-domains). Limited scope anycast needs a non-fuzzy scope boundary.

   Brian

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 May 2019 14:59:33 -0700

On May 30, 2019, at 2:19 PM, Brian E Carpenter <[email-masked]> wrote:
> Ted, please do think about the main point: "the fuzzy nature of the site concept". (And, shameless plug, see https://tools.ietf.org/html/draft-carpenter-limited-domains <https://tools.ietf.org/html/draft-carpenter-limited-domains>). Limited scope anycast needs a non-fuzzy scope boundary.

Do ULAs have a non-fuzzy scope boundary?   Serious question—I actually do not know how this is handled in the network.

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 31 May 2019 00:08:38 +0200

To me, a non-fuzzy boundary is one where you do something like ACL on
a set of links completely isolating some area of the network. Fuzzy
could vbe absence of default route causing ULA to stop. Not sure if
these are good examples of any actual definition, but both ae possible with
ULA.

I'd mostly be concerned about non-fuzzy boundaries wrt. security,
so not sure if i'd always want to avoid non-fuzzy boundaries.

On Thu, May 30, 2019 at 02:59:33PM -0700, Ted Lemon wrote:
> Do ULAs have a non-fuzzy scope boundary?   Serious question???I actually do not know how this is handled in the network.
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 May 2019 15:15:59 -0700

> so not sure if i'd always want to avoid non-fuzzy boundaries.

The question is, what’s different about the proposed application versus typical ULA usage?

---

From: Sander Steffann <[email-masked]>
Date: Fri, 31 May 2019 00:53:44 +0200

Hi Ted,

> The question is, what’s different about the proposed application versus typical ULA usage?

I like the scope aspect of Mark's draft. ULA is always organisation or site scoped, and should be filtered as such. Anycast that have a different scope should have different boundaries. Anycast addresses that have ISP scope can cross from the customer's network to the ISP's network, while there should be a boundary between that customer's ULA addresses and that ISP's ULA addresses (let's assume they both use ULA for this example).

Cheers,
Sander

---

From: George Michaelson <[email-masked]>
Date: Fri, 31 May 2019 08:58:55 +1000

Scope beyond your own administrative boundary is ill-defined. in
Routing constraints, NOEXPORT and NOPEER are not well deployed always.
path length limits are also not in your own control: you are trying to
seed behaviour into the routing framework which demands others accede
to your requests, but thats all they are: requests.

TTL in actual packets in flight is a different matter. But the hop is
not respecting of the boundaries here its about the elements the
actual IP packet takes, not the AS adjacencies along the path. It
doesn't relate sensibly to anything beyond the immediate link.

So.. I think this stuff is heading to a place where the "scope" is
well understood, albiet not exactly wired down, between local and the
edge of the AS containing the (mixture of) local links, but beyond
that, is ill-defined or un-defined.

Is that ok? Is that what you want?

-G

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 May 2019 16:04:19 -0700

> I like the scope aspect of Mark's draft. ULA is always organisation or site scoped, and should be filtered as such. Anycast that have a different scope should have different boundaries. Anycast add…

I agree that this makes sense in principle.   But I think it’s a lot fuzzier than you’re at least allowing for.   As I pointed out previously, what “ISP scope means” when you are at a site that’s multi-homed is impossible to specify, because there is more than one scope that could be called “ISP scope,” and the scopes are disjoint.

Therefore I would prefer not to wait for this seemingly intractable problem to be solved before solving the problem that I’m actually trying to solve.

---

From: Mark Smith <[email-masked]>
Date: Fri, 31 May 2019 09:21:13 +1000

On Fri., 31 May 2019, 08:54 Sander Steffann, <[email-masked]> wrote:

> I like the scope aspect of Mark's draft. ULA is always organisation or
> site scoped, and should be filtered as such. Anycast that have a different
> scope should have different boundaries. Anycast addresses that have ISP
> scope can cross from the customer's network to the ISP's network, while
> there should be a boundary between that customer's ULA addresses and that
> ISP's ULA addresses (let's assume they both use ULA for this example).
>

An example use case for a Network Service Provider scope is anycast DNS
resolvers.

You can't use ULA because customers don't send their ULA prefixes to you,
and you don't really want them to, as that makes your ISP network part of
their network.

Ideally you don't want to use GUA DNS resolver anycast addresses because
that makes the DNS resolver vulnerable to DoS attacks from the Internet.

When I first ran up anycast DNS resolvers, I ideally wanted to use IPv4
addresses that had these property of globally unique, not globally
reachable, yet reachable from all customers' networks. Internet DoS attacks
on DNS resolvers were common at the time.

RFC1918 didn't suit, nor did normal RIR public address space, because APNIC
expected it to be globally reachable. IX space suites, but we weren't an
IX. We could have probably lobbied harder for it, however we needed to get
them going.

This is also part of my realisation that the forwarding scopes of our
unicast address spaces are quite coarse - global (GUA), organisation (ULA)
and link (Link-Local), and that's it.

The much more fine grained multicast scopes used with anycast addresses
would be much more flexible for anycast scenarios.

I think reintroducing the Site-Locals as a unicast address space, just to
create Site-Local scope anycast addresses, isn't really properly solving
the problem in a general enough way.

People will also use them for unicast addressing because they're more
similar to RFC1918s that ULAs - and we also have problems with people not
making ULA unique, despite the word Unique in the name.

No mention of generating unique ULAs, so people are being trained to use
ULAs that are not unique:

https://github.com/leblancd/kube-v6/blob/master/README.md#set-up-node-ip-addresses

A CPE vendor got this wrong too in the past:

Residential IPv6 CPE - What Not To Do and Other Observations
https://www.ausnog.net/sites/default/files/ausnog-05/presentations/ausnog-05-d02p02-mark-smith.pdf

Regards,
Mark.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 May 2019 16:37:55 -0700

On May 30, 2019, at 4:21 PM, Mark Smith <[email-masked]> wrote:
> An example use case for a Network Service Provider scope is anycast DNS resolvers.

And how does this work if you are multihomed?

---

From: Mark Smith <[email-masked]>
Date: Fri, 31 May 2019 09:43:22 +1000

On Fri., 31 May 2019, 09:04 Ted Lemon, <[email-masked]> wrote:

> I agree that this makes sense in principle.   But I think it’s a lot
> fuzzier than you’re at least allowing for.   As I pointed out previously,
> what “ISP scope means” when you are at a site that’s multi-homed is
> impossible to specify, because there is more than one scope that could be
> called “ISP scope,” and the scopes are disjoint.
>
> Therefore I would prefer not to wait for this seemingly intractable
> problem to be solved before solving the problem that I’m actually trying to
> solve.
>

I don't think a Network Service Provider scope is too ambiguous. Network
Service Provider/customer relationship is a child/parent relationship.

So a customer attached to two different NSPs has two different parents. An
anycast service could be provided by either of them or both e.g. DNS
resolver service.

As with multicast, some scopes can be autoconfigured, others have to be
manually configured when and where the operator considers the boundary to
be. A network service provider knows they are one, and a customer usually
knows clearly that they're not a network service provider.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 May 2019 11:46:47 +1200

On 31-May-19 11:04, Ted Lemon wrote:
> On May 30, 2019, at 3:53 PM, Sander Steffann <[email-masked] <mailto:[email-masked]>> wrote:

That is probably wise. But anyway, if the desired scope of your anycast
address is set by routing policy, it surely doesn't matter what the prefix
is? If you support 2001:0db8:f000:baaa:f000:baaa:f000:baaa as an anycast
address, it's up to you to determine exactly how far out from the user
that address is filtered (site boundary, ISP boundary, or further).
Even for multihomed sites, that remains true.

Either that or specify a maximum allowed hop limit.

BTW we did perform a long term experiment with the anycast prefix
2002::/16, and some would say that it showed the risk of such things.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 May 2019 11:48:52 +1200

On 31-May-19 09:59, Ted Lemon wrote:
> On May 30, 2019, at 2:19 PM, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:

All we have is a strong recommendation to filter at site boundaries.

That site boundaries are ill-defined is of course part of my "limited domains" hobby horse.

   Brian

---

From: Mark Smith <[email-masked]>
Date: Fri, 31 May 2019 10:05:22 +1000

> And how does this work if you are multihomed?

Other email I just sent.

Adding, even if both upsream/parent NSPs are providing DNS resolver service
with the same NSP scoped anycast address (because it will be a generic NSP
scoped DNS resolver address), the downstream customers' routing will pick
only one of them to use.

Similar to multicast, what I've proposed supports embedding a unicast /64
prefix. The all-zeros /64 is used as "unspecified".

So in this scenario, both NSPs would advertising the same generic NSP
scoped anycast DNS resolver address with an all zeros /64 part - and likely
such a well-known anycast address that it could be a factory default for
devices. They may also each advertise an NSP scoped anycast DNS address
which embeds one of their GUA /64s.

So a customer could leave the choice of which NSP's DNS resolver they use
entirely up to their routing system by using the generic DNS anycast
address, which would be the default, or they could prefer only one of their
NSP's DNS anycast resolver services by configuring their hosts to use that
NSP's specific anycast DNS address that includes the NSP's chosen GUA /64.

They could go further and configure the second NSP's specific NSP scope
anycast DNS resolver address as a second DNS entry on a host to get NSP
independent DNS redundancy, if the first and preferred NSP's DNS anycast
resolution service isn't considered reliable enough.

Regards,
Mark.

---

From: Fred Baker <[email-masked]>
Date: Thu, 30 May 2019 17:14:42 -0700

> On May 30, 2019, at 2:59 PM, Ted Lemon <[email-masked]> wrote:
> 
> Do ULAs have a non-fuzzy scope boundary?

The recommendation of RFC 4193, if I understand it, is that advertisements of ULA prefixes in EBGP are "not announced", and if they happen to be announced by accident, are refused. https://tools.ietf.org/html/rfc4193#section-4.1.

That is in no sense a default. My primary expertise is with my former employer's equipment, but I believe this to be generally true: EBGP only advertises what it is told to, and refuses only what it is told to. Hence, I would guess that the typical configuration will not advertise a ULA in anything resembling a normal case, but will not refuse one that is advertised to it.

But the intended scope-boundary is "EBGP".
--------------------------------------------------------------------------------
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
     Sun Tzu

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 May 2019 17:18:05 -0700

> But the intended scope-boundary is "EBGP".

Makes sense, thanks for the detailed explanation.

---

From: Mark Smith <[email-masked]>
Date: Fri, 31 May 2019 10:52:39 +1000

Hi Sander,

> I think I'd prefer "aa<subformat><scope>::/16" for consistency with multicast addresses. OTOH your format is much easier to filter at scope boundaries, but I guess it's too late to change the multi…

I originally started with the multicast structure, however being much
easier to filter at scope boundaries was why I changed it.

Multicast address structure evolved over time, and I though that if
there was time to do it over again, then there would be some different
decisions made. Since this would be a separate /8 specifically for
anycast addresses, and similar but fundamentally different to
multicast, there was an opportunity to make those decisions.

Support for up to 16 subformats hasn't been a strong requirement, it
was more that the bits were available in a convenient location, and
that if multicast addressing structure evolved over time, anycast may
too. So formally accommodating and encoding different lower 112 bit
formats could be useful.

I'm also mindful that asking for a /8 is a big ask, so some
flexibility in formatting of the lower 112 bits if possible is much
better than having to ask for another /8 if it was a total screw up.
Unlikely I think, but an affordable safety parachute when the bits
were available in the address format.

(The draft started out as "IPv6 Functional Anycast Addresses", using
an fa::/8 prefix. I like "aa::/8" for "anycast address" much better,
however "fa::/8" also suits Formal Anycast too." Mnemonics in
addresses certainly aren't essential, but are quite useful if
possible.)

> > rather than being an informal type of unicast address.

I'm generally curious to know why a formal class for anycast wasn't
chosen as RFC 1546 suggested, although perhaps it was because the idea
was much more experiemental than today, as the IRTF published it. I
was tempted to look into it but thought that might take a lot of time
better spent on the draft itself. I was thinking it could have been
lack of IPv4 address space, however perhaps the Class E address space
could have been used for anycast addresses.

> Very good idea. The same scope can be used for multicast as well. It would fit things like live TV streams in a service provider network to provide them to their customers rather well.

Yes, that is exactly the multicast use case I though of for an Network
Service Provider scope.

> I don't understand the use case for this one yet.

Somewhat of a replacement for or better version of HbH EH.

Advantage is that processing of destination addresses isn't optional
in forwarding, as DAs are elementary to forwarding. There whould be no
specific forwarding performance concerns with this recognising these
types of to-be-HbH processed packets, unlike the HbH EH. The packet's
DA and the device's FIB dictates pushes the packet to the HbH
processing. HbH wouldn't be special case packet processing by the
forwarding plane anymore.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Fri, 31 May 2019 11:04:52 +1000

>From memory, I suggested that at the time, and the motivation was to
try to avoid by default ULA private address space route leaks we've
seen with the RFC 1918 address space, more recently with 100.64/10,
and other non-global address spaces.

The idea was to facilitate trading ULA routes through more specifics
if e.g. two ULA domains were to be joined together after a company
merger, but to not have it occur automatically upon bringing up eBGP.

BCP38 would also be another cause of ULA packet drops at customer/ISP
network boundaries.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Fri, 31 May 2019 11:06:49 +1000

> 2002::/16, and some would say that it showed the risk of such things.

Well that is a global scope anycast so there is no limit to both the
availability or consequences.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 May 2019 18:18:18 -0700

On May 30, 2019, at 5:05 PM, Mark Smith <[email-masked]> wrote:
> Adding, even if both upsream/parent NSPs are providing DNS resolver service with the same NSP scoped anycast address (because it will be a generic NSP scoped DNS resolver address), the downstream customers' routing will pick only one of them to use.

This might be dysfunctional.  Sometimes if you query the DNS server for one upstream and then use the answer on the other upstream, the results will not be the same, and might be quite suboptimal.   That said, this isn’t likely a problem with the real point you are making, so I only mention it for completeness.

> Similar to multicast, what I've proposed supports embedding a unicast /64 prefix. The all-zeros /64 is used as "unspecified".
> 
> So in this scenario, both NSPs would advertising the same generic NSP scoped anycast DNS resolver address with an all zeros /64 part - and likely such a well-known anycast address that it could be a factory default for devices. They may also each advertise an NSP scoped anycast DNS address which embeds one of their GUA /64s.
> 
> So a customer could leave the choice of which NSP's DNS resolver they use entirely up to their routing system by using the generic DNS anycast address, which would be the default, or they could prefer only one of their NSP's DNS anycast resolver services by configuring their hosts to use that NSP's specific anycast DNS address that includes the NSP's chosen GUA /64.
> 
> They could go further and configure the second NSP's specific NSP scope anycast DNS resolver address as a second DNS entry on a host to get NSP independent DNS redundancy, if the first and preferred NSP's DNS anycast resolution service isn't considered reliable enough. 

This isn’t actually the use case that I’m talking about—I’m a bit puzzled.  Here you are configuring the anycast address just like a regular IP address.  The use case I need is for a well-defined anycast address that does not need to be discovered.   So while what you are doing may be useful, it doesn’t have anything to do with my use case.   The reason I was pointing out that your scoping model didn’t work is that I didn’t understand that you intended to use different anycast addresses for different ISPs.   For that use case, there’s no need for a special scoped anycast address—each ISP can simply allocate an IP address or IP addresses and configure their routing to treat them as anycast addresses.   There are problems with this, but these problems are already discussed e.g. in RFC 7094.

---

From: Mark Smith <[email-masked]>
Date: Fri, 31 May 2019 12:25:03 +1000

> This might be dysfunctional.  Sometimes if you query the DNS server for one upstream and then use the answer on the other upstream, the results will not be the same, and might be quite suboptimal.…

It's a fault you report to the ISP as they're not providing a properly
working DNS resolution service.

> This isn’t actually the use case that I’m talking about—I’m a bit puzzled.  Here you are configuring the anycast address just like a regular IP address.

Only if you want or need to.

>  The use case I need is for a well-defined anycast address that does not need to be discovered.   So while what you are doing may be useful, it doesn’t have anything to do with my use case.

https://tools.ietf.org/html/draft-smith-6man-form-func-anycast-addresses-00#section-5.1

5.1.  Features

   o  Provides separate globally well known and local network defined
      anycast function or service identifier spaces.  Globally well
      known identifiers can be encoded in applications during their
      development as constants, avoiding the need for them to be
      specified and configured during deployment of the application.

>  The reason I was pointing out that your scoping model didn’t work is that I didn’t understand that you intended to use different anycast addresses for different ISPs.

It's both.

There is a generic one that all are likely to ISPs would provide.

Using the draft's format (note there is an error with the scope
position in the draft, fixed in next revision),

- 0xaa - 8 bit Formal Anycast Prefix
- 0xb - 4 bit Vislble Scope: Network Service Provider
- 0x0 - 4 bit Anycast Identifier Format: Functional Anycast
- 0x:: - 64 bits Anycast Domain Prefix: 64 bits of all zeros,
indicating unspecified prefix
- 00b - 2 bits reserved, set to zero
- 00 0000b - Prefix-Length: 6 bit prefix length, all zeros having
special meaning of 64 bit prefix length
- 0000 0000b - Flags: 8 bit flags, 1 defined, T meaning Transient in
high order position i.e. non-IANA assigned (i.e. same as multicast
flag T meaning)
- 0x0 - Local Instance: 8 bit field available to local anycast domain
to allow instances or versions of the service to be included in the
address. zero by default. Can be used to extend following Anycast
Function Identifier to 32 bits in the anycast domain identified by the
Anycast Domain Prefix.
- 0x000053 - Anycast Function Identifier: 24 bit function identifier.
IANA assigned in this case because the T bit is not switched on.
Assume 53 (actually 83 in decimal).

Compressing all the zeros (common default values chosen to be zero for
that purpose), an ISPs would announce into their routing domain (and
to customers via eBGP):

aab0::53/128

This would be the default embedded in the code of DNS resolvers.
Following the formula, ISPs should all arrive at that value, however
there probably would be value in an IANA registry or similar
documenting it to minimise formula following errors.

The ISPs might also respectively provide their own unique Functional
Anycast addresses by embedding one of their GUA /64s as the Anycast
Domain prefix:

So ISP A also announces:

aab0:2001:db8:0:a::53/128

ISP B also announces:

aab0:2001:db8:0:b::53/128

With each of the following customers being multihomed to both ISP A and ISP B:

Customer A might be happy with the default, so they leave hosts' DNS
resolver clients address as the default of aab0::53. It's
plug-and-play, no configuration required.

Customer B might want to always use ISP A's DNS resolver, so they
replace the default of aab0::53 with aab0:2001:db8:0:a::53.

Customer C might want to use ISP B's DNS resolver, but fall back to
ISP A's if ISP B's fails, so they replace the default of aab0::53 with
two entries in order, aab0:2001:db8:0:b::53, aab0:2001:db8:0:a::53.

(Instead of announcing specific anycast /128s, an ISP could announce
an aggregate route for all of their specific anycast domain services
e.g. ISP A above would announce aab0:2001:db8:0:a::/80).

So ISPs announcing both the generic well-known DNS anycast address,
and their own specific versions, allows their customers to leave the
default in the DNS resolver client code, or override it to suit their
preferences as to who they get the anycast DNS service from.

Is that clearer?

Regards,
Mark.

> For that use case, there’s no need for a special scoped anycast address—each ISP can simply allocate an IP address or IP addresses and configure their routing to treat them as anycast addresses.   There are problems with this, but these problems are already discussed e.g. in RFC 7094.
>
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 31 May 2019 11:11:24 +0200 (CEST)

On Thu, 30 May 2019, Ted Lemon wrote:

I tried to read up on this thread, and I don't think I understand the 
use-case still.

However, since I didn't see anyone mention it in the discussion yet we do 
have a WKP from another somewhat similar deployment case (unless I didn't 
understand correctly):

https://tools.ietf.org/html/rfc6052#section-2.1 , the 64:ff9b::/96 prefix 
for NAT64, out of global scope. However, you typically need the traffic to 
only hit one of these (because of state), so I guess they will not be BGP 
anycasted.

For AFTRs for LW4o6 and MAP-E (which are stateless and thus works nicely 
with BGP anycast), people will deploy these using BGP anycast in their 
networks, numbered out of their own LIR allocated GUA global scope address 
space.

So... again, I'm not sure I didn't miss just everything in the discussion, 
so if I'm completely off above, could someone please sum up the discussion 
again with what you've agreed on?

Numerous times in the discussion the term "scoped address" was used, but I 
never understood what scope was intended in the statement.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 31 May 2019 13:33:32 +0200

On Fri, May 31, 2019 at 12:25:03PM +1000, Mark Smith wrote:
> > This might be dysfunctional.  Sometimes if you query the DNS server for one upstream and then use the answer on the other upstream, the results will not be the same, and might be quite suboptimal.   That said, this isn???t likely a problem with the real point you are making, so I only mention it for completeness.
> 

Consider you have a CDN RR www.example.com hosting video clips.
I look it up across my two ISP connections and get two different IP addrs,
each being the CDN instance supposed to be serving a specific area.
If i now attempt to access IP 2 via link 1, i may simply get service
denial on the basis of my source IP address because the whole setup
to provide different CDN server addresses is to manage bandwidth and
serve from each instance only client IP addresses that are in a part
of the Internet to which bandwidth and cost of that server are
considered optimum by example.com.

I could not find the section "how www.example.com will make more money
with this memo" in Marks draft. Would be interesting to understand
if/how he proposes to achieve this, because this is about the financially
biggest use case of "anycast DNS" in the Internet i can think of and
there is a whole industry building this and another to work around it.

The part of using one IP address learned across one (VPN tunnel) link to
access content you're not supposed to have across that second (native
ISP) link is of course one of the key examples of this. Because in
many CDN cases that denial-of-service based on originator IP address is
not implemented.

Cheers
    Toerless

> > For that use case, there???s no need for a special scoped anycast address???each ISP can simply allocate an IP address or IP addresses and configure their routing to treat them as anycast addresses.   There are problems with this, but these problems are already discussed e.g. in RFC 7094.
> >
> >
> 

-- 
---
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Fri, 31 May 2019 06:58:49 -0700

On May 31, 2019, at 2:11 AM, Mikael Abrahamsson <[email-masked]> wrote:
> https://tools.ietf.org/html/rfc6052#section-2.1 <https://tools.ietf.org/html/rfc6052#section-2.1> , the 64:ff9b::/96 prefix for NAT64, out of global scope. However, you typically need the traffic to only hit one of these (because of state), so I guess they will not be BGP anycasted.

That’s a similar idea, but not anycast.   There you’re hoping the packets reach an edge router that does NAT64.   So a lot of the work in the infrastructure is the same—if you have the server at the edge and only one egress, you don’t really have to do anything except make sure that the edge router forwards the packet to the right host.  If you want something fancier, you set up the right route—in the case of 64:ff9b, if you want your NAT to be somewhere other than the edge, you just arrange your internal routing so that the packets get to the network address translator.   You could do the same thing for these anycasts.

One disadvantage of allocating well-known anycast addresses out of the same address is that if your anycast servers are actually in different places, you need to have host routes in your routing fabric, or use tunnels, so that’s a downside that doesn’t exist for the NAT64 WKP.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 31 May 2019 10:26:36 -0400

> and link (Link-Local), and that's it.

If you are arguing for having another pool of address space, "unique,
non-global scope" or some such, then I'm all for it.

We didn't like site-local because they weren't unique.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 31 May 2019 16:32:50 +0200 (CEST)

On Fri, 31 May 2019, Ted Lemon wrote:

> That’s a similar idea, but not anycast.  There you’re hoping the packets 
> reach an edge router that does NAT64.  So a lot of the work in the 
> infrastructure is the same—if you have the server at the edge and only 
> one egress, you don’t really have to do anything except make sure that 
> the edge router forwards the packet to the right host.  If you want 
> something fancier, you set up the right route—in the case of 64:ff9b, if 
> you want your NAT to be somewhere other than the edge, you just arrange 
> your internal routing so that the packets get to the network address 
> translator.  You could do the same thing for these anycasts.
>
> One disadvantage of allocating well-known anycast addresses out of the 
> same address is that if your anycast servers are actually in different 
> places, you need to have host routes in your routing fabric, or use 
> tunnels, so that’s a downside that doesn’t exist for the NAT64 WKP.

I also forgot to mention: 
https://tools.ietf.org/html/draft-ietf-mboned-driad-amt-discovery-06

This one uses SRV records to find the relay.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 31 May 2019 07:42:57 -0700

> This one uses SRV records to find the relay.

The point of a well-known address is that it doesn’t have to be discovered—that’s actually what I’m trying to accomplish.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 31 May 2019 11:48:58 -0400

Ted Lemon <[email-masked]> wrote:
    >> Ted, please do think about the main point: "the fuzzy nature of the
    >> site concept". (And, shameless plug, see
    >> https://tools.ietf.org/html/draft-carpenter-limited-domains
    >> <https://tools.ietf.org/html/draft-carpenter-limited-domains>). Limited
    >> scope anycast needs a non-fuzzy scope boundary.

    > Do ULAs have a non-fuzzy scope boundary?   Serious question—I actually
    > do not know how this is handled in the network.

I'm not sure I a non-fuzzy definition of a non-fuzzy boundary ;-)

When I ping/traceroute ULAs from my home network, they die !N at my ISP's DFZ
machine:

   lando-[~] mcr 10005 %traceroute6 fd2e:82a1:f3c4::1
   traceroute to fd2e:82a1:f3c4::1 (fd2e:82a1:f3c4::1), 30 hops max, 80 byte packets
   1  2abc:efgh:f:2::241 (2abc:efgh:f:2::241)  0.521 ms  0.517 ms  0.508 ms
   2  2abc:efgh:9:8:209:87:239:232 (2abc:efgh:9:8:209:87:239:232)  13.113 ms
   3  2001:550:2:8::ab:1 (2001:550:2:8::ab:1)  32.078 ms !N  32.618 ms !N

hop 1 is the router at home, and hope 2 is the access router at my ISP, and
hop 3 is my ISP's core router connect to upstream peers.

Should hop 1 (home router) or hop 2 (access node) were to blackhole route
fc00::/6 (ULA-R and ULA-C), would that affect your use case?  Or could the
anycast service possibly be at the ISP?

On a campus situation, I would assume that ULA, if used, should be routed to
the all edges, but not beyond.   Or alternatively, consider an ISP+plus it's
customers to be a "campus", or "admin-scope".

Should home routers install routes to 2000::/3 when they see "default" rather
than "::/0"?  I have made that argument, but I see the other point about
how limiting it could be in the future.

---

From: joel jaeggli <[email-masked]>
Date: Fri, 31 May 2019 09:34:53 -0700

On 5/30/19 16:21, Mark Smith wrote:
> 
> 
> On Fri., 31 May 2019, 08:54 Sander Steffann, <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Hi Ted,
> 
>     I like the scope aspect of Mark's draft. ULA is always organisation
>     or site scoped, and should be filtered as such. Anycast that have a
>     different scope should have different boundaries. Anycast addresses
>     that have ISP scope can cross from the customer's network to the
>     ISP's network, while there should be a boundary between that
>     customer's ULA addresses and that ISP's ULA addresses (let's assume
>     they both use ULA for this example).
> 
> 
> You can't use ULA because customers don't send their ULA prefixes to
> you, and you don't really want them to, as that makes your ISP network
> part of their network.
> 

 It is straight forward enough to use a gua prefix which you do not
announce to the internet as a whole. we do this with internal
anycast(s), address space used for point-to-point links management
networks and so forth.

> reachable, yet reachable from all customers' networks. Internet DoS
> attacks on DNS resolvers were common at the time.
> 
> RFC1918 didn't suit, nor did normal RIR public address space, because
> APNIC expected it to be globally reachable. IX space suites, but we
> weren't an IX. We could have probably lobbied harder for it, however we
> needed to get them going..
> 
> 
> unicast address spaces are quite coarse - global (GUA), organisation
> (ULA) and link (Link-Local), and that's it.

We have really bad historical experiences with attempts to define scopes.

> I think reintroducing the Site-Locals as a unicast address space, just
> to create Site-Local scope anycast addresses, isn't really properly
> solving the problem in a general enough way.
> 
> similar to RFC1918s that ULAs - and we also have problems with people
> not making ULA unique, despite the word Unique in the name. 
> 
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 31 May 2019 09:54:17 -0700

> anycast service possibly be at the ISP?

That’s the desired behavior.   There is no wish to have this stuff escape to the ISP.

> customers to be a "campus", or "admin-scope”.

I don’t think the ISP use case is addressable in a general way using WKA.

> how limiting it could be in the future.

I don’t know.   I can see pros and cons to that.

---

From: Fred Baker <[email-masked]>
Date: Fri, 31 May 2019 10:17:48 -0700

> On May 31, 2019, at 9:54 AM, Ted Lemon <[email-masked]> wrote:
> 

To my way of thinking, the issues in that could be resolved by a software update (to install 2000::/3 and 4000::/3) when it needs to happen - we get software updates for other reasons, why not that as well?

---

From: Ted Lemon <[email-masked]>
Date: Fri, 31 May 2019 11:55:05 -0700

> To my way of thinking, the issues in that could be resolved by a software update (to install 2000::/3 and 4000::/3) when it needs to happen - we get software updates for other reasons, why not that…

Indeed, perhaps it’s for the best if routers that don’t get regular updates stop working. :)

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 31 May 2019 21:10:47 +0100

Fred Baker wrote on 31/05/2019 18:17:
> To my way of thinking, the issues in that could be resolved by a
> software update (to install 2000::/3 and 4000::/3) when it needs to
> happen - we get software updates for other reasons, why not that as
> well?

2000::/3 will be hard-coded into configurations, not just software. 
This makes it more difficult because configurations are harder to change 
than software.

Ted's idea has plenty of merit.

Nick

---

From: Mark Smith <[email-masked]>
Date: Sat, 1 Jun 2019 08:14:33 +1000

> I look it up across my two ISP connections and get two different IP addrs,

That's not how anycast works.

Only one of the two ISPs will receive the DNS query, and there will
only be one answer.

Using multicast for your DNS queries (assuming the multicast
infrastructure exists) would cause the problems you describe.

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 1 Jun 2019 00:21:03 +0200

> Only one of the two ISPs will receive the DNS query, and there will

Yes, for an individual query. I was referring to the case where i have
for example 8.8.8.8 as my DNS server, and depending on which ISP link
i use to reach that DNS anycast address, i can get a different answer.
Might involve more than one DNS resolution step of course.

> infrastructure exists) would cause the problems you describe.

Just talking normal unicast DNS request to anycast DNS server address.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Mark Smith <[email-masked]>
Date: Sat, 1 Jun 2019 08:27:31 +1000

> anycast(s), address space used for point-to-point links management

Sounds like it isn't a requirement to advertise RIR space globally
anymore so that RIRs can check if you're using it.

However, this is just one example of how a scoped formal anycast
address space could be used. There are others I'm working on in the
draft.

> We have really bad historical experiences with attempts to define scopes.

Can you elaborate?

Multicast scopes don't seem to have caused any issues, and I think it
is because they're much more fine grained than the total of 3 coarse
unicast ones. Multicast scopes better fit the domains people want.

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 31 May 2019 19:05:39 -0700

Sent from my iPhone

> On May 31, 2019, at 15:27, Mark Smith <[email-masked]> wrote:
> 

It has never been a requirement. 

RIRs will happily allocate GUA space which is  not intended to appear in the DFZ.

---

From: Mark Smith <[email-masked]>
Date: Sat, 1 Jun 2019 16:56:38 +1000

> anycast service possibly be at the ISP?

I'm guessing you don't have internal ULA address space, which is why you're
more successful than if you did.

> customers to be a "campus", or "admin-scope".

Those scopes are conceptually smaller than an organisation, because
organisations can have multiple campuses and can have multiple internal
network adminstrative domains.

An ISP has multiple organisations as customers, so you need a scope bigger
than organisation, yet smaller than global, to cover an ISP and its
customers. A Network Service Provider scope.

The multicast scopes in RFC 7346 provides a conceptual hierarchy. I think a
Network Service Provider scope would fit between Organization-Local and
Global.

> how limiting it could be in the future.

A ULA address at an ISP would only be reachable to customers who only have
GUA addresses.

If a customer has ULA internally, a ULA source address would be preferred
over a GUA source to reach an ISP ULA (anycast) destination. That ULA
source address would cause the packet to be dropped by a BCP38 filter at
the ISP access router, assuming they have them, as they should.

Even if the ISP doesn't have BCP 38 filters, the ISP's routing is very
unlikely to have routes back to all customers' ULA address spaces.

So you need global scope anycast addresses for working source address
selection. Except that defeats the goal of having anycast destined packets'
travel being restricted to a domain smaller than global when that is
required or desirable.

Regards,
Mark.