Re: Generic anycast addresses...

[Mark Smith <[e-mail]>]

Hi Sander,

On Thu, 30 May 2019 at 22:49, Sander Steffann <[e-mail]> wrote:
>
> 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 ;)
>

I originally started with the multicast structure, however being much
easier to filter at scope boundaries was why I changed it.

Multicast address structure evolved over time, and I though that if
there was time to do it over again, then there would be some different
decisions made. Since this would be a separate /8 specifically for
anycast addresses, and similar but fundamentally different to
multicast, there was an opportunity to make those decisions.

Support for up to 16 subformats hasn't been a strong requirement, it
was more that the bits were available in a convenient location, and
that if multicast addressing structure evolved over time, anycast may
too. So formally accommodating and encoding different lower 112 bit
formats could be useful.

I'm also mindful that asking for a /8 is a big ask, so some
flexibility in formatting of the lower 112 bits if possible is much
better than having to ask for another /8 if it was a total screw up.
Unlikely I think, but an affordable safety parachute when the bits
were available in the address format.

(The draft started out as "IPv6 Functional Anycast Addresses", using
an fa::/8 prefix. I like "aa::/8" for "anycast address" much better,
however "fa::/8" also suits Formal Anycast too." Mnemonics in
addresses certainly aren't essential, but are quite useful if
possible.)


> > - 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'm generally curious to know why a formal class for anycast wasn't
chosen as RFC 1546 suggested, although perhaps it was because the idea
was much more experiemental than today, as the IRTF published it. I
was tempted to look into it but thought that might take a lot of time
better spent on the draft itself. I was thinking it could have been
lack of IPv4 address space, however perhaps the Class E address space
could have been used for anycast addresses.

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

Yes, that is exactly the multicast use case I though of for an Network
Service Provider scope.


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

Somewhat of a replacement for or better version of HbH EH.

Advantage is that processing of destination addresses isn't optional
in forwarding, as DAs are elementary to forwarding. There whould be no
specific forwarding performance concerns with this recognising these
types of to-be-HbH processed packets, unlike the HbH EH. The packet's
DA and the device's FIB dictates pushes the packet to the HbH
processing. HbH wouldn't be special case packet processing by the
forwarding plane anymore.


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

Thanks very much for your comments.

Regards,
Mark.

> Cheers,
> Sander
>