Re: Generic anycast addresses...

[Mark Smith <[e-mail]>]

On Thu, 30 May 2019 at 08:48, Ted Lemon <[e-mail]> wrote:
>
> 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?
>

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.






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