Re: Generic anycast addresses...

[Toerless Eckert <[e-mail]>]

On Thu, May 30, 2019 at 07:55:03AM -0700, Ted Lemon 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.

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.

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

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.

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

> > Ted, having read through the thread, maybe you can do this with a multicast address which
> > 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.

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

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


Cheers
    Toerless