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 <> Mon, 04 November 2019 01:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 39ACA120288 for <>; Sun, 3 Nov 2019 17:53:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.496
X-Spam-Status: No, score=-0.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AOPy9OeK6U3G for <>; Sun, 3 Nov 2019 17:53:04 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 869D1120858 for <>; Sun, 3 Nov 2019 17:53:04 -0800 (PST)
Received: by with SMTP id j7so12786025oib.3 for <>; Sun, 03 Nov 2019 17:53:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OweuRVgAi2mkwUhxZSyvcHlDKhqqblPJwByu2WWHM6Q=; b=omgY37lpHB6YCaZIlT8bAn1h92ydhTGA7cfADYSW5AjvzDupPqU6k15+6o5A7AbRNJ NND3GaGDbAWlFB1uiJU8eZLLglS6yd1nGhVPMepLiNpPA4hXtpHbJK1wOekmn9o/XRP3 sDnmLs2o06Oy6JqifGFIIgcaLIX6ZD24y9pCGfO3n2Jct/m3YcgSc4RzCOtXjmmkjXi4 5SiJ+loqFHBVeNzVZEPsBW6QojWlsHmCQztYqP8D1BJgoXOrQ9EiJtA3fD9S9DbnS0bM vB+hbl+e1mUNELc2hOlChHRdQOBb+wUpzHAkhMUNzg+6trZV94TxUHjE0cGnBX1NzY4C d7pg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OweuRVgAi2mkwUhxZSyvcHlDKhqqblPJwByu2WWHM6Q=; b=H4wIcGOg00o6fvoIcdRjYuJtutg27x+YgH3E30zKJ6jRpQs2gnuNea8/K9+XgLjVN/ G38S2BbtL3e68Hi2yhFczqNiGhMV7wbXRLrFWMxErbmNNdhQRUbfJYpbRO5dDwihdrCp 9nmBFXUwCa3nZTG4iMEw3367p/vXsmmDC0FEzhXtYYrjo95ilDkPukN3kpIbZSdchnt/ qP/4vzKP/AbtydoM5IlmYTE4jj88yrDES1Oa5gYuHFyATt8tea3PvnEFBV2hYPrDvzIj 44ZGczvSSBO62S7QRLE+oUFsAGJdA1gN/JKL53GPd32EPupcDLTYdMVUwekaQR0dsAqf AAeQ==
X-Gm-Message-State: APjAAAWHYCBmtjfEEkEIBxg/IiCjrOhOtFCeq/KZduOwxfI/qc0x/bGd KQjgphPMTFMyAsVw1KhKcGH1iA6gHQqvzuq5eT0=
X-Google-Smtp-Source: APXvYqz0mJcoMoZjiOZHSsdH4VTqoNnuhcLSMy0jpbiHiAUFtQsMsE09AcamnviJZ5FiAOwQFe/BMOl+bmQc+0PZzGM=
X-Received: by 2002:aca:b6d5:: with SMTP id g204mr6643998oif.7.1572832383717; Sun, 03 Nov 2019 17:53:03 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Mark Smith <>
Date: Mon, 4 Nov 2019 12:52:37 +1100
Message-ID: <>
Subject: Re: IPv6 Formal Anycast Addresses and Functional Anycast Addresses (Fwd: New Version Notification for draft-smith-6man-form-func-anycast-addresses-01.txt)
To: Fred Baker <>
Cc: 6MAN <>
Content-Type: multipart/alternative; boundary="00000000000085d49705967b9366"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 Nov 2019 01:53:06 -0000

On Mon, 4 Nov 2019, 05:59 Fred Baker, <> wrote:

> On Nov 3, 2019, at 9:23 AM, Nick Hilliard <> 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.
> 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.).

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

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.