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 22:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7AEC2120043 for <>; Sun, 3 Nov 2019 14:24:42 -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 tFOjTUf3Pi6v for <>; Sun, 3 Nov 2019 14:24:39 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 97D2112000F for <>; Sun, 3 Nov 2019 14:24:39 -0800 (PST)
Received: by with SMTP id y39so21130207qty.0 for <>; Sun, 03 Nov 2019 14:24:39 -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=LBkikGnaR0RdH1QYu3xDPPJrlt8YhFL1Kd91cUsFtsI=; b=MAnGcfuvMfbeWSjN+/Ry24B6dfNoCIh61hs8ZH0cKaGDDkpcsp6iOI++TCcOwI6Wlt hd8LHGznitmpMP0A+uHuxGDFlotpuE+UnbIXibASMYNgPs6R8h0eB5JVKtP7kQ2EW/oj o+DkzzIPuBDpCoCJ42mQ68RyVPG7Zd1smYCzPpnfE/xSla8J5pdfwF5YuRKiFdWR/UY4 ToJs2hUXVmaLHgx7noE0OdvK3170UqDNtnb5Rs7inNp7mLGb7ydwYuTw0CNUKkYayI5L 2nR14jCj8U2mjvfevOidSq6DC6sj3Tk0H6cZ0x5Yq8BMkyeD5bOV/fZBagDY97FjSmcR Vm4Q==
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=LBkikGnaR0RdH1QYu3xDPPJrlt8YhFL1Kd91cUsFtsI=; b=q+TjyNksSB6dgqox2//RkZTc8SQn/lAxK8Jj67UbA9PyYHbgDtR+vzWnMurOrjaR4e i2eqEmW7kkxaYLxDGfUkApXuRVisYXTG54FeyiJ66ob96LnG0kThZ7bnqNaBUp1UCoo2 5iBX6U+8Vbn8w+p17zcWqZM3fz2TWaYh8VeeqoupvemXFNpYoHGUOpvqvB8ZDQXao7Ai yX6zTcov3CC05V6xI6zKvpRgZPrMdU+Sz3E4eCAU4tKQ6KHCfxp1XKFcAR5HM+dTQP/K EPEHNe1F6qgYhEDACeK4Yy4+Z+mOzm+AYXdyLUQzQg3uLsG5pIHXNmXUa8VCw+FbSxZZ 0SrQ==
X-Gm-Message-State: APjAAAW8zfXmAs5lZcEseWXztoDf114UeApPmWo4FkhBXVwENq9Eh0tn Ias4vQxbBdQm45/j4NkAaIQ=
X-Google-Smtp-Source: APXvYqy4uTqHBCpVxklszGGTD/Vn7J1ZYzIYVWHCnnSYbMqz0IM3/FJGot0Mfm0iTb/ujTWPvj2miQ==
X-Received: by 2002:a0c:b454:: with SMTP id e20mr19513543qvf.14.1572819878140; Sun, 03 Nov 2019 14:24:38 -0800 (PST)
Received: from ?IPv6:2620:f:8000:210:9194:789:126f:6a30? ([2620:f:8000:210:9194:789:126f:6a30]) by with ESMTPSA id h44sm7361314qtc.1.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 Nov 2019 14:24:37 -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 17:24:36 -0500
Cc: Mark Smith <>, 6MAN <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Toerless Eckert <>
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 22:24:43 -0000

Funny. It doesn't work that way in DNS. Every root server simply thinks that one of its addresses is the anycast address and so accepts the packet as "directed to it". It also responds from that address, so that the requester recognizes the response.

> On Nov 3, 2019, at 4:27 PM, Toerless Eckert <> wrote:
> It is somewhat architecturally dissatisfying that (AFAIK) we seem to need to
> resolve limitations of anycast addresses at the transport layer,
> e.g.: redirecting connection requests to an anycast address to a
> unicast address of the transport responder. If initiators would know an address is
> an anycast address, they could use some TBD network layer (ICMP) extension
> to do that resolution independent of individual transport protocols.
> And the network layer would only know it needed to do this if there was
> a way for the initiator to identify an address as an anycast address
> AFAIK (can't think of a simpler way).
> Cheers
>    toerless
> On Sun, Nov 03, 2019 at 01:59:24PM -0500, 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
>> 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.
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> Administrative Requests:
>> --------------------------------------------------------------------
> -- 
> ---