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, 03 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
- IPv6 Formal Anycast Addresses and Functional Anyc… Mark Smith
- Re: IPv6 Formal Anycast Addresses and Functional … Nick Hilliard
- Re: IPv6 Formal Anycast Addresses and Functional … Fred Baker
- Re: IPv6 Formal Anycast Addresses and Functional … JORDI PALET MARTINEZ
- Re: IPv6 Formal Anycast Addresses and Functional … Toerless Eckert
- Re: IPv6 Formal Anycast Addresses and Functional … Mark Smith
- Re: IPv6 Formal Anycast Addresses and Functional … Fred Baker
- Re: IPv6 Formal Anycast Addresses and Functional … Toerless Eckert
- Re: IPv6 Formal Anycast Addresses and Functional … Mark Smith
- Re: IPv6 Formal Anycast Addresses and Functional … Nick Hilliard
- Re: IPv6 Formal Anycast Addresses and Functional … Nick Hilliard
- Re: IPv6 Formal Anycast Addresses and Functional … Michael Richardson
- Re: IPv6 Formal Anycast Addresses and Functional … Mark Smith
- Re: IPv6 Formal Anycast Addresses and Functional … Mark Smith
- Re: IPv6 Formal Anycast Addresses and Functional … Mark Smith
- Re: IPv6 Formal Anycast Addresses and Functional … Toerless Eckert
- Re: IPv6 Formal Anycast Addresses and Functional … Toerless Eckert
- Re: IPv6 Formal Anycast Addresses and Functional … Ole Troan
- Re: IPv6 Formal Anycast Addresses and Functional … Michael Richardson
- Re: IPv6 Formal Anycast Addresses and Functional … Toerless Eckert
- Re: IPv6 Formal Anycast Addresses and Functional … Erik Kline
- Re: IPv6 Formal Anycast Addresses and Functional … Gyan Mishra
- Re: IPv6 Formal Anycast Addresses and Functional … Mark Smith
- Re: IPv6 Formal Anycast Addresses and Functional … Gyan Mishra