Re: Generic anycast addresses...

[Ted Lemon <[e-mail]>]

On May 30, 2019, at 7:36 AM, Michael Richardson <[e-mail]> wrote:
> 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.

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?

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

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

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