Re: IPv6 Formal Anycast Addresses and Functional Anycast Addresses (Fwd: New Version Notification for draft-smith-6man-form-func-anycast-addresses-01.txt)

[Mark Smith <[e-mail]>]

On Mon, 4 Nov 2019, 05:59 Fred Baker, <[e-mail]> wrote:

> On Nov 3, 2019, at 9:23 AM, Nick Hilliard <[e-mail]> wrote:
> > If you create an anycast protocol which has characteristics which are
> sufficiently different to unicast that it requires a separate addressing
> schema, then by all means it would be appropriate to create an addressing
> schema to fit in with this.  The determinant here would be that global
> unicast addresses would not be usable for this protocol. Until then, a
> separate address block is mostly a matter of aesthetics.
>
> I would agree. I did some poking around to identify anycast address
> groups. The IANA has records for three. RFC 4291 has a fourth, which is
> subnet anycast which is supposed to get a packet to a router I'm not sure I
> can say how widely deployed any of those are.
>
>
> https://www.iana.org/assignments/ipv6-anycast-addresses/ipv6-anycast-addresses.xml
> RFC 2526             Mobile IPv6 Home-Agents anycast
> ETSI EN 302 636-6-1  IPv6 over GeoNetworking geographic anycast
> RFC 4291             IPv6 Anycast Subnet-Router Anycast Address
>

There are others in the IPv6 reserved special addresses list (which I did
have as a reference, then got confused with this above list, so removed
that reference yesterday.).

https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml

2001:1::1/128   Port Control Protocol Anycast
2001:1::2/128   Traversal Using Relays around NAT Anycast


> On the other hand, there are a number of unicast addresses in daily use
> worldwide as anycast, which are the addresses one uses to access the DNS
> root. Collected statistics tell us that on the order of 10% of DNS requests
> to the root use IPv6, and the rest are IPv4. So I would say that the use of
> unicast addresses as anycast has a strong supporting case.
>
> https://www.iana.org/domains/root/servers
> https://root-servers.org/
>
> The one use case that your draft mentions that seemed to be new was that
> of a network operator that wanted to deploy an anycast service, but only to
> its customers. It, however, seemed to be hypothetical. Do you know of
> operators or services that have that requirement?
>

I wanted to do it when I setup new anycast IPv4 DNS for a residential ISP
back in 2008.

The goal was to protect the DNS resolvers from DDoS attacks, and
specifically not to have to receive DDoS traffic over transit links and
then drop it. I needed some globally unique IPv4 address space that I
wouldn't announce to the Internet that we would then use for our new
anycast DNS resolvers.

We went to APNIC for new address space, because all of our existing address
space was being advertised. We had available address space, but not that we
could stop announcing. They came back and said we weren't using enough of
our existing address space, so wouldn't give us separate new space for this
purpose.

We also tried to see if we could try to get some space that isn't
advertised through an IX allocation, however that was also refused.

In the context of IPv6, ULA would sound like the right thing to use,
however it doesn't have a big enough forwarding scope - it needs to be
bigger than a single network, yet smaller than global. An ISP's ULA space
is intended to be unreachable from a customer's network and vice-versa. The
solution would be a "Network Service Provider" forwarding scope between the
global scope of GUAs and the site/local network scope of ULAs.

So for an IPv6 anycast DNS service that can't be targeted by an Internet
DDoS attack, you need IPv6 address space that:

- doesn't fall within your GUA address space that you're announcing

- has a forwarding scope that is greater than the ULA address space
(site/local network)

- has a forwarding scope that is smaller than global

- is globally unique to so it doesn't conflict with any customers' ULA or
GUA address space

Having a scope field in these Formal Anycast addresses, and embedding a
unicast prefix, up to /64, in the Functional Anycast subformat, allows
these requirements to be met.


> In other words, I'm wondering whether there is a problem being solved, or
> an architectural preference.


Troubleshooting duplicate prefixes in a routing protocol is a problem.

If it is done intentionally, it is anycast, and therefore not a fault. If
it is done unintentionally, it is a fault.

Currently, as anycast routes/addresses are from within the unicast address
space, it isn't possible to look at an address by itself and immediately
know if there is a duplicate route/address fault, or it is an intentional
anycast configuration. Currently, troubleshooting would involve going back
to the route announcement origin devices and verifying that they're
configured correctly.


Regards,
Mark.