Re: Non routable IPv6 registry proposal

Keith Moore <moore@network-heretics.com> Thu, 11 March 2021 16:48 UTC

Return-Path: <moore@network-heretics.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 024D43A13D9 for <ietf@ietfa.amsl.com>; Thu, 11 Mar 2021 08:48:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=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=messagingengine.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 Tz4HjADxUWM6 for <ietf@ietfa.amsl.com>; Thu, 11 Mar 2021 08:48:54 -0800 (PST)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF2AC3A13D8 for <ietf@ietf.org>; Thu, 11 Mar 2021 08:48:54 -0800 (PST)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 3AD921B53 for <ietf@ietf.org>; Thu, 11 Mar 2021 11:48:54 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 11 Mar 2021 11:48:54 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=+gAclP OqZgQlqpnfN9Ke5vH6Hd0BjFuYhsqwZUG6Id0=; b=RbNZLYFW7GsGgUWRLO8ENK 3qrQbQqzjHLUtYzxn/AITjY+IAQyKU3Ty61KmyrEmXJvvE+TQ4LbkMYP6SbB7Y1c rvtdMHwbXm/fB4bT6ceWiQI1Zy+PCiM+BahpLo84GP7EMLFeC27H7rE0IV/ZupdA R97ycjyRLyifG1AmeBozjo50l+sooz6G1LBd4UWt5Xbe/kHzvepwH+SJmz4Rc5h+ rDUiTFtqNukE+tZecuGJLB0H7PdTQCYcsK2PLRakv4KQQY4mpnQOYBTi00x93O0+ uWuY8KLq905Ptz8vwUGBGrGCtiLE7QMQWOesrkTre8s3GGpt3HARaa6BJ7BHUV5w ==
X-ME-Sender: <xms:9UlKYA9bqemx8sGstyWwN_aZqaDnXsYwIX8YfWZFnAoDMabAD5CZJA> <xme:9UlKYMgTdODs5knuKt_CSiWak75wzwpSw5twrHamXJC0DpvrnS6g6ZiJmXSpjP8C_ mubtFANWgErnw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddvtddgleefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgesrgdtre ertdefjeenucfhrhhomhepmfgvihhthhcuofhoohhrvgcuoehmohhorhgvsehnvghtfiho rhhkqdhhvghrvghtihgtshdrtghomheqnecuggftrfgrthhtvghrnhepveefteduieegtd elvddvtddufeejjeffvdefteejieeulefgtdfggedtffektedunecukfhppeejfedruddu fedrudeiledriedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepmhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtohhm
X-ME-Proxy: <xmx:9UlKYPF739mowB3D5LLdOmVklREKrw-xXbDbgsY8vgzFFcTHXyvoaA> <xmx:9UlKYD-niEEtoQn5uypXuEhigZaWALwrnglNP9OEFiG_L0yTmYaksw> <xmx:9UlKYOzK7guhfXZJ5zT-CjfijofA6n99MXfeUWGuxIh8AlaoPwxFDQ> <xmx:9UlKYM6l0Z1n7B9cWMHVh4DnZtBd0P8XnWLGwLrBgNU6HJzYFUL8xQ>
Received: from [192.168.30.202] (c-73-113-169-61.hsd1.tn.comcast.net [73.113.169.61]) by mail.messagingengine.com (Postfix) with ESMTPA id 0D7901080066 for <ietf@ietf.org>; Thu, 11 Mar 2021 11:48:53 -0500 (EST)
Subject: Re: Non routable IPv6 registry proposal
To: ietf@ietf.org
References: <CAMm+LwjNiE0P7RAVqzKMypNbh3=9BeqiWn_hGv3E=zX7-YmSXQ@mail.gmail.com> <72F969A9-AF94-47B6-B48C-B3CD4D9A7C72@strayalpha.com> <7cc9e38c-5a00-ec59-a8c2-10503cc40d50@si6networks.com> <CB1A6DF0-8CDD-495D-9F7B-80BF72F08C1E@strayalpha.com> <53d7190a-3e1f-66b3-0574-8e8fbb3a7a5e@si6networks.com> <90718D2A-3483-45D2-A5FB-205659D4DCDB@cisco.com> <87h7li0z2t.fsf@line.ungleich.ch>
From: Keith Moore <moore@network-heretics.com>
Message-ID: <253e084c-6ced-7f94-c909-bd44f7c53529@network-heretics.com>
Date: Thu, 11 Mar 2021 11:48:52 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <87h7li0z2t.fsf@line.ungleich.ch>
Content-Type: multipart/alternative; boundary="------------B6E460B6D8903484E615D698"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/wxcqiDRclhsIELktQ4ELP9_Jl0g>
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 16:48:56 -0000

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