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:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EF13C1200EB for <>; Sun, 3 Nov 2019 17:01:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.497
X-Spam-Status: No, score=-0.497 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, 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 LVdFN4-LhCHT for <>; Sun, 3 Nov 2019 17:01:57 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D01DD120072 for <>; Sun, 3 Nov 2019 17:01:57 -0800 (PST)
Received: by with SMTP id r27so12694408oij.7 for <>; Sun, 03 Nov 2019 17:01:57 -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=nBmNK1XQGg6mvLBWeXWvzgXt1ImCPEDS9fZ+a/xMolc=; b=ujAglqLkN3FyeIdkIBnusLFfIAmnpeI3Pkf3BZmV0g7bssDDfAjt9iSue8lRVZB2qY lh68+B2eZJDGfgweHwf2QbMZ34TRTmC/0lS2nyKjSQIQmfCr5zz3qCbwZVHk4eKUnkY7 B7BrKXqzotMx9FhfaNDE3muVxeRDvDptX3NBFHt88w33enEC68IQbhICTXLu0LUD3Mt6 XfsjHfj/ZoclLFJv/0GpdIXxov0jFxJXlt9YarUAeA/pf/WXjF4/zhghMZiKQQhQPuQM k+loP4HAmeSR+ugxsVuVe86i+466UygG/EkeRyhL7K955MecP7EtDKiV3pFZpVmpdnV7 +gMQ==
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=nBmNK1XQGg6mvLBWeXWvzgXt1ImCPEDS9fZ+a/xMolc=; b=M0uaW/IpLIutQnj6obyBpCfmGMmd9z+Vjb960+E4nDWeMt6tQZ2O6bsYTqP0k+mzSx cUJiiJuJ1fZ0e/MrBeMzs+8Hsq17hs8vrcdbUdYGqinoIXfSJZwliNCjhsz24+ZODT3e GxugAhbqoiXzay/er/fw3udRxpRIcpm7ut/b1Hns9/WidNHEasvp4pz5ZBQH88YSVE93 Gu2l2hvT5wJoRXaNTonqQ1h1kBBBft/+5TVtWQ4cwsNfs969DUQfKmdhVzKH7RCTnbwV r6fW9BP0ElAGMYw4A2BmuRggHz7Qd4rtczY1g7Jf0S+drDvf9/JrYCzuEeWzD71UAi8o b+yA==
X-Gm-Message-State: APjAAAWoedeg07PswqW+oOOqL7Q2vIYpCSohqyY1v9tZmRrS7cVPUeAH nDS37I3DncXIzfJIQmTCEDATX3LaLjkCNMeQaFJzA87h
X-Google-Smtp-Source: APXvYqzNYqe/rrcN0puoFgQD5O0vTGE0jQQm/uztGuDz+Of84DJ7QccK4dSH6/G0sLEwmOxcmJQBf67sn7HDgEPUA/E=
X-Received: by 2002:a54:4090:: with SMTP id i16mr2168464oii.164.1572829317075; Sun, 03 Nov 2019 17:01:57 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Mark Smith <>
Date: Mon, 4 Nov 2019 12:01:30 +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: Nick Hilliard <>
Cc: 6MAN <>
Content-Type: text/plain; charset="UTF-8"
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:01:59 -0000

On Mon, 4 Nov 2019 at 10:46, Nick Hilliard <> wrote:
> Mark Smith wrote on 03/11/2019 21:51:
> > All of this suggests to me that you haven't read any of the draft at
> > all. Much if not all of this is covered.
> Mark,
> I read the draft.  It doesn't describe characteristics which couldn't be
> handled using unicast address ranges.  Scope can be handled on an ad-hoc
> basis where necessary.  Well-known addresses have been debated endlessly
> over the years without reaching any consensus about their advisability.
> The examples you provide (NTP, DNS) are already routinely provided by
> anycast using global unicast addresses, and the general consensus is
> that if you want devices to pick up this information, there are better
> ways to do this than by using well-known addresses, e.g. dhcp, DNS - for
> NTP, orchestration, etc.  Even then, all the examples you provide do not
> depend on a new addressing block due to protocol differences.

Where did I present that this was providing something that was
impossible to achieve any other way?

Realise that most human invention is improving on methods that already
exist and are being used. Very rarely is something entirely new

IPv6 is no more than an improvement over IPv4 + NAT. People don't need
IPv6 to access the Internet.

One of the factors that influence adoption, from the book "Diffusion
of Innovations", is "relative advantage" - what is the advantage of
the new in comparison to the old?

One way to increase the relative advantage of IPv6 over IPv4 is to
provide useful capabilities in IPv6 that are not, cannot be provided
or cannot be provided easily in IPv4. I assume you support increased
IPv6 adoption since you're here.

A formal IPv6 anycast address class, providing improvements over
IPv4's and IPv6's informal anycast addresses, can increase the
relative advantage of IPv6.

If "Well-known addresses have been debated endlessly over the years
without reaching any consensus about their advisability.", why is your
name on RFC6666, "A Discard Prefix for IPv6"?

That RFC invents nothing that others hadn't already done many times
before with non-well known unicast addresses, including me. It's only
a useful improvement.