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

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Sun, 03 November 2019 20:42 UTC

Return-Path: <prvs=121079e0a6=jordi.palet@consulintel.es>
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 E37BC120073 for <ipv6@ietfa.amsl.com>; Sun, 3 Nov 2019 12:42:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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, SPF_HELO_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es
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 DBosEaEzveII for <ipv6@ietfa.amsl.com>; Sun, 3 Nov 2019 12:42:50 -0800 (PST)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 474BA12002E for <6man@ietf.org>; Sun, 3 Nov 2019 12:42:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1572813767; x=1573418567; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=ssKNSDTVEAF5CWTjla9FGzzfdX4tkUN2cY3IB7lcYlA=; b=iiSaVQ5J1uesG Hnx2jcrCtgHWyjarSLnWY8RJQMTI+Ro5CT2j8lD+8fa1hTVuvbtN6+rxjis3V6lh reVJ0Yq1LJ6pXmrv0IGKG8/rJBnXSbCJl13Mg+Rtr2F8dLu+/AQKuf09P+XkPxz/ J2dGvl+OuEXuS9H8QpZxYE+WhcW5lA=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Sun, 03 Nov 2019 21:42:47 +0100
X-Spam-Processed: mail.consulintel.es, Sun, 03 Nov 2019 21:42:47 +0100
Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006451819.msg for <6man@ietf.org>; Sun, 03 Nov 2019 21:42:46 +0100
X-MDRemoteIP: 2001:470:1f09:495:550f:425e:d72f:461e
X-MDHelo: [10.10.10.130]
X-MDArrival-Date: Sun, 03 Nov 2019 21:42:46 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=121079e0a6=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: 6man@ietf.org
User-Agent: Microsoft-MacOutlook/10.10.f.191014
Date: Sun, 03 Nov 2019 21:42:44 +0100
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: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: Fred Baker <fredbaker.ietf@gmail.com>, Mark Smith <markzzzsmith@gmail.com>
CC: 6MAN <6man@ietf.org>
Message-ID: <107C1C84-012B-41EA-AC0D-88BDC56D3D08@consulintel.es>
Thread-Topic: IPv6 Formal Anycast Addresses and Functional Anycast Addresses (Fwd: New Version Notification for draft-smith-6man-form-func-anycast-addresses-01.txt)
References: <157277906705.13535.345852921709779212.idtracker@ietfa.amsl.com> <CAO42Z2wSU-puDaQq-PzTCTE=S3qyqUNrPhH0pgOEO_d3=StnHA@mail.gmail.com> <b97c15c0-b1fe-0d78-0897-5fc4bb6a9a34@foobar.org> <B42E6EED-5620-49BE-BB3D-B1CF6F04A1CC@gmail.com>
In-Reply-To: <B42E6EED-5620-49BE-BB3D-B1CF6F04A1CC@gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ZkG9sGEAgqTg-8RR-JRzsufXe0g>
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 20:42:53 -0000

I actually had the same thought (not yet read the document, it may be already answered there): one of the features of anycast is that because is the same unicast space, we can do things like root DNS servers, in a transparent way (clients don't notice it).

Regards,
Jordi
@jordipalet
 
 

´╗┐El 3/11/19 19:59, "ipv6 en nombre de Fred Baker" <ipv6-bounces@ietf.org en nombre de fredbaker.ietf@gmail.com>; escribi├│:

    On Nov 3, 2019, at 9:23 AM, Nick Hilliard <nick@foobar.org>; 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. 
    
    https://www.iana.org/assignments/ipv6-anycast-addresses/ipv6-anycast-addresses.xml
    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.
    
    https://www.iana.org/domains/root/servers
    https://root-servers.org/
    
    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
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.