Re: Generic anycast addresses...

[Sander Steffann <[e-mail]>]

Hi Mark,

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

I think I'd prefer "aa<subformat><scope>::/16" for consistency with multicast addresses. OTOH your format is much easier to filter at scope boundaries, but I guess it's too late to change the multicast specs ;)

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

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

Very good idea. The same scope can be used for multicast as well. It would fit things like live TV streams in a service provider network to provide them to their customers rather well.

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

I don't understand the use case for this one yet.

Anyway: I think this can be very useful! Easily recognisable addresses, explicit scope. I like it :)

Cheers,
Sander