Re: Generic anycast addresses...

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=40microsoft.com@dmarc.ietf.org> wrote:
>
> See RFC 7094 (https://tools.ietf.org/html/rfc7094) for history and discussion.
>
> Dave
>
> -----Original Message-----
> From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Ted Lemon
> Sent: Wednesday, May 29, 2019 3:48 PM
> To: 6man@ietf.org
> Subject: Generic anycast addresses...
>
> 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!
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> 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
> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------