Re: Non routable IPv6 registry proposal

Fred Baker <fredbaker.ietf@gmail.com> Thu, 11 March 2021 22:25 UTC

Return-Path: <fredbaker.ietf@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50ADE3A0C55 for <ietf@ietfa.amsl.com>; Thu, 11 Mar 2021 14:25:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Level:
X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 VEr5Y4gn31xx for <ietf@ietfa.amsl.com>; Thu, 11 Mar 2021 14:25:49 -0800 (PST)
Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C2793A0BBC for <ietf@ietf.org>; Thu, 11 Mar 2021 14:25:49 -0800 (PST)
Received: by mail-pg1-x536.google.com with SMTP id n9so13615511pgi.7 for <ietf@ietf.org>; Thu, 11 Mar 2021 14:25:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:in-reply-to :date:cc:message-id:references:to; bh=tvNkZevxuYMc/qMS9IFK/nraKbNB3tk94y2IJPSFLyw=; b=KMkRui4cLxCpNvzzf7+ez+5QA/BN0Bw/yT2fT9MEZm08kiOlOWL5RMqGFqmsmEp6pY We2IqEaNmsTaOEG+suBQ9+K7wypCdksJpVa6swDAEzIHpNRWADymmNfEICg2FMYoyEpv xwJ9n0Nr1cTgb7O1DuppgPELfyDUKS1n4DNNqqXadYS0A/EUGqgFPtj41hvZZCfyHcoJ UfODVTYJuHJ/lz3BnYGFz+zXkXVWUPnaEAXY6w9QgcDYs/I09fBSzf5YejPArLD+YU2u aWH4RUP6VZzZ+WHHlsRyhTAneA6+bUXT1t/z3O3WILgKuO+v+ZE/sAr90rzOwKfO3GYB zawQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:in-reply-to:date:cc:message-id:references:to; bh=tvNkZevxuYMc/qMS9IFK/nraKbNB3tk94y2IJPSFLyw=; b=dFIIclmX1zXrWI00fqmgY9lyRqix9O4yudQ423+IBF2DgybE5e7Cuf3llbvMXCrlTC R8lWHKFJAzLEvdUNT8zgfDVPOP9msBH/G1pH8BOLkUCEcdEevNCsfifnt6djoiKIOjhb AY5uVrupx8PjnBRoQl1z2/AxE1C0Y0jw7uKDDzxo3pzPLXTGgCOuxmrFrf5gaBVWdXyv J10bxSmNjMERsVZdkIaHfYFb8m5X45cyapEsucpI5Krk9eRE6Z+ER7vuH2T4hMmMuqXn dl26NWLrS7CEJ1ZV3Xgu26XL3EGzODpi3w2l/OQmKdK1itmy6p0yUMaakmnXzhf0U+SY udJg==
X-Gm-Message-State: AOAM532Npl2ezpbbaVYuu2Z296XG3Zn1rEj/7p5TtdzA1PsCzBrPtvJM e1yFHcKtaHJbI1CnUCJoZIM=
X-Google-Smtp-Source: ABdhPJxXUxRzW3CotFQxr+/inLBWKP+t9VuHYH1G4YiYdGzXIBIn2vBnhjSI8NdLS+/Q5C8QaDHy+Q==
X-Received: by 2002:a63:fb11:: with SMTP id o17mr8889500pgh.282.1615501548427; Thu, 11 Mar 2021 14:25:48 -0800 (PST)
Received: from smtpclient.apple ([2600:8802:5800:567::1003]) by smtp.gmail.com with ESMTPSA id w5sm3347847pfn.51.2021.03.11.14.25.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 Mar 2021 14:25:48 -0800 (PST)
From: Fred Baker <fredbaker.ietf@gmail.com>
X-Google-Original-From: Fred Baker <FredBaker.IETF@gmail.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-40DA3BBF-50E6-4DD0-A0B5-356177A9062B
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Subject: Re: Non routable IPv6 registry proposal
In-Reply-To: <CAN-Dau3pV7y7g=QxGwipPUAQgf-TXE41MJGK47oUeSaNx5COng@mail.gmail.com>
Date: Thu, 11 Mar 2021 14:25:47 -0800
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, Keith Moore <moore@network-heretics.com>, IETF-Discussion Discussion <ietf@ietf.org>
Message-Id: <239EAA1E-DC7B-4532-8F85-AF30739AA9F1@gmail.com>
References: <CAN-Dau3pV7y7g=QxGwipPUAQgf-TXE41MJGK47oUeSaNx5COng@mail.gmail.com>
To: David Farmer <farmer=40umn.edu@dmarc.ietf.org>
X-Mailer: iPhone Mail (18E5164h)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/pLHBN4XUBcKHTYut0RO7dcf1XqE>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Mar 2021 22:25:51 -0000

I can tell you definitively that the DNS Root Servers use IPv6 addresses for anycast, but they are indistinguishable from unicast addresses in format. The anycast magic is in BGP.

Sent using a machine that autocorrects in interesting ways...

> On Mar 11, 2021, at 12:53 PM, David Farmer <farmer=40umn.edu@dmarc.ietf.org> wrote:
> 
> 
> 
>> On Thu, Mar 11, 2021 at 2:16 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>> David,
>> On 12-Mar-21 08:19, David Farmer wrote:
>> > On Thu, Mar 11, 2021 at 10:49 AM Keith Moore <moore@network-heretics.com <mailto:moore@network-heretics.com>> wrote:
>> > 
>> >     On 3/11/21 5:22 AM, Nico Schottelius wrote:
>> > 
>> >>>     Another question I have is whether such ULA allocations
>> >>>     will realistically remain local.
>> >>     ULAs are unlikely staying local, as we have seen with radio networks in
>> >>     Germany. Tunnels are being used to interconnect remote cities and
>> >>     non-collision (not necessarily public routing) are a primary concern.
>> > 
>> >     Despite the name, there's no reason that ULAs should stay local.   As long as they are properly chosen, it's perfectly reasonable to route them privately between cooperating networks, and IMO this is part of their design.   One of the problems with RFC 1918 addresses in IPv4 was that enterprises had a need to route traffic between networks each using that space.   The resulting address collisions generally required explicit NAT configurations to work around, and these were failure-prone and difficult to manage.  ULAs were intended in part to remedy this problem.
>> > 
>> >     Keith
>> > 
>> > The "L" for Local isn't intended to have a strict definition of Local. However, similarly, the "U" for Unique isn't intended to have a strict definition of Unique either, especially a mathematical definition of Unique. 
>> > 
>> > You can easily interconnect thousands or even tens of thousands of ULA prefixes without much chance of an address collision, as long as the random assignment process is actually used. Whereas, if you try to interconnect billions of ULA prefixes, you will probably start running into the birthday paradox.
>> > 
>> > So the interconnection of ULA prefixes, the route-ability of them, is not intended to be unlimited. There are limits to the number of ULA prefixes that SHOULD be interconnected to each other; nevertheless, this limit is extremely generous for the intended use cases.
>> > 
>> > If you disregard the intended use cases and use them outside the intended use cases, then address collisions could become an issue.
>> 
>> I'm not sure where you get your "intended" from. I don't think we've ever really written done the intended use cases in such detail. (Except for the abandoned https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ula-usage-considerations-02 )
>> 
>>     Brian
> 
> The first sentence of the Abstract for RFC4193 says;
> 
> This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site.
> 
> This is expanded upon in the first paragraph of the Introduction to RFC4193;
> 
> This document defines an IPv6 unicast address format that is globally unique and is intended for local communications [IPV6]. ...
> They are routable inside of a more limited area such as a site.  They may also be routed between a limited set of sites.
> 
> Those sound a lot like intended use cases to me, the key phrases in that for me are, "local communications", "usually ... a site", and "a limited set of sites." 
> 
> Yes, that's pretty vague, but I don't see a reasonable interpretation of those phrases that include every site on the Internet, or even every site in a country or state, maybe it could include every site in a small to modest city, but even that's a bit of a stretch in my opinion.
> 
> YMMV
> Thanks
> 
> -- 
> ===============================================
> David Farmer               Email:farmer@umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota   
> 2218 University Ave SE        Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================