Re: Generic anycast addresses...

[Toerless Eckert <[e-mail]>]

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:
> On May 29, 2019, at 3:58 PM, Dave Thaler <[e-mail]> wrote:
> > 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.
> 

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


-- 
---
[e-mail]