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

Fred Baker <> Sun, 03 November 2019 18:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1974E12008C for <>; Sun, 3 Nov 2019 10:59:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aTvVA_EnRj0E for <>; Sun, 3 Nov 2019 10:59:27 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E5674120018 for <>; Sun, 3 Nov 2019 10:59:26 -0800 (PST)
Received: by with SMTP id r22so10485619qtt.2 for <>; Sun, 03 Nov 2019 10:59:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=60JgWjcuUBY2oif+GCXWdyU6rsgDGVkU4S1vGg4kG1U=; b=IuFdeOGrRU+fY57Xbd37WKmyf0PvTTAKZvXU/KeCEX4NCO8zAJzcxYFP7gJVUeXhoM NNc5QbDybz7DKukXRVOxwU+C2lnorwSOsVfWoi8Y1JCY6U3Vaum5nD+PwSmew8kCxD+T Unc7AgZjgMOHRpj60SREZrwSqrDvgV7p7hJUs9DnCnULB1l6qFcfWBf4+yGqMQIVyoHB kMHHwdLmfhB0Nczq8bQa8ECH0dFygLNtiVGMNDp0vd0DY7EC5MG2i0VML1Ua5u81OIwR +hIlRoQ06yfsqnABzegy77OLQW9wajQ4ygdpj25XFc82oPlNrVYdl5EVfKw6f3mrWWbW L1xQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=60JgWjcuUBY2oif+GCXWdyU6rsgDGVkU4S1vGg4kG1U=; b=baE+8WyNQjPmn7qNuWIOxKbLinWemu0/X6PBfp0foXcSmvlh6+4NnNnh2+egdoC8Gb DmELDg2MZUvBPXzklX5i/EbsVl69rCHtY1PpH/SLIlg2BlPYz8OqcwQtsUnjSO72EX4V 3ZWunAYX8GdrMhfkSp6H3MZAgA8Yys99NLhhRlB5zoG+w+KHG/9Nox4OHwMg1g+EnYyq TORb8uNa5LP8zGVS9RnuUPsPxqAxm8iGh65WoM2E4LA2TiO0Oyo3FxapgOxBuCfDJ4gd wL/xTmEPFC19cYBGldO4yimLSZYLIbnU+scRHTrzlp/QE/XibtNqDq2mmuwiNAHJ9wPI b++A==
X-Gm-Message-State: APjAAAVwRkLpm84wmjNkw3l76LNcOxIxoj7/GOkxCEZifHixuGaXudz8 yt1wH5d/5o+6gPaA32N13qc=
X-Google-Smtp-Source: APXvYqx2eYRjfugMFn9Qn5jUUv+OS6/eSoeAEu69NGoSeJvrtxWGobOqVB8xbSWTjL+xyMnij7n1MQ==
X-Received: by 2002:ac8:2fba:: with SMTP id l55mr9551873qta.167.1572807566008; Sun, 03 Nov 2019 10:59:26 -0800 (PST)
Received: from ?IPv6:2620:f:8000:210:4932:a635:38cb:7031? ([2620:f:8000:210:4932:a635:38cb:7031]) by with ESMTPSA id m5sm5843305qtp.97.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 Nov 2019 10:59:25 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Subject: Re: IPv6 Formal Anycast Addresses and Functional Anycast Addresses (Fwd: New Version Notification for draft-smith-6man-form-func-anycast-addresses-01.txt)
From: Fred Baker <>
In-Reply-To: <>
Date: Sun, 3 Nov 2019 13:59:24 -0500
Cc: 6MAN <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Mark Smith <>
X-Mailer: Apple Mail (2.3601.0.10)
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: Sun, 03 Nov 2019 18:59:29 -0000

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

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?

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