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

Nick Hilliard <nick@foobar.org> Sun, 03 November 2019 14:23 UTC

Return-Path: <nick@foobar.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700B1120089 for <ipv6@ietfa.amsl.com>; Sun, 3 Nov 2019 06:23:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icnGv_qp2oI1 for <ipv6@ietfa.amsl.com>; Sun, 3 Nov 2019 06:23:11 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4178F120033 for <6man@ietf.org>; Sun, 3 Nov 2019 06:23:11 -0800 (PST)
X-Envelope-To: 6man@ietf.org
Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id xA3EN895001613 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Nov 2019 14:23:08 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local
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: Mark Smith <markzzzsmith@gmail.com>
Cc: 6MAN <6man@ietf.org>
References: <157277906705.13535.345852921709779212.idtracker@ietfa.amsl.com> <CAO42Z2wSU-puDaQq-PzTCTE=S3qyqUNrPhH0pgOEO_d3=StnHA@mail.gmail.com>
From: Nick Hilliard <nick@foobar.org>
Message-ID: <b97c15c0-b1fe-0d78-0897-5fc4bb6a9a34@foobar.org>
Date: Sun, 3 Nov 2019 14:23:07 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:52.0) Gecko/20100101 PostboxApp/7.0.8
MIME-Version: 1.0
In-Reply-To: <CAO42Z2wSU-puDaQq-PzTCTE=S3qyqUNrPhH0pgOEO_d3=StnHA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/N2ErROC0I31kgmqa6HmxNBdzhAk>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 Nov 2019 14:23:13 -0000

Mark Smith wrote on 03/11/2019 11:46:
> I think there are advantages to having a formal IPv6 anycast address
> class and space. For example, similar to multicast addresses, it could
> be very useful to be able to look at an address and immediately know
> it is an anycast address.

Mark,

multicast addresses have different protocol characteristics to unicast / 
anycast, so it's not really valid to draw a comparison between the two.

Regarding your draft, an addressing schema is a supporting part of a 
protocol requirement, and if you create an addressing schema without a 
corresponding protocol different, you're putting the cart before the horse.

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.

Nick