[IPv6]Re: Analysis of Ungleich ULA Registry

Ole Trøan <otroan@employees.org> Thu, 23 May 2024 20:53 UTC

Return-Path: <otroan@employees.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 DF045C14F685 for <ipv6@ietfa.amsl.com>; Thu, 23 May 2024 13:53:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=employees.org
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJW15mDrNH5q for <ipv6@ietfa.amsl.com>; Thu, 23 May 2024 13:53:23 -0700 (PDT)
Received: from proxmox01.kjsl.com (proxmox01.kjsl.com [204.87.183.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE1BCC14F5FD for <ipv6@ietf.org>; Thu, 23 May 2024 13:53:22 -0700 (PDT)
Received: from proxmox01.kjsl.com (localhost.localdomain [127.0.0.1]) by proxmox01.kjsl.com (Proxmox) with ESMTP id 877C8E48A3; Thu, 23 May 2024 20:53:22 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=employees.org; h=cc:cc:content-transfer-encoding:content-type:content-type :date:from:from:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=prox2023; bh=Y4SfEyey/jM8KR86 xbuwZ+P+sI2PFTrqsFC6kzUqRVs=; b=OUcgHHwK1oydtbOEfFuO0l+MxvD9tvJT v2/a34ikeOV85ljebHkLqukGCZhhmy/fNa4LloHP0rd/CjDqOwlC+80trHHgzhCU /wsu0ljURvYW3pRFLVQjhGXpRVlnjeolKA6XhaLcJ5Ik6ESNn8Cksbxksmadh/59 31MdUww4SjC3qANCZOP+djhycc89Yw0FKTMkhfUDh0RL1YqUwL1PEPHiTF1f+S4m PSmn1Ul4Nx4z+HC8Lo97AJ2HhNoGBWjAGwd76R+CJpH8N8UYBHKZfFSJI2RDo0dn uA9nkxb92bLdFZ6QRz+2R4y6jsVJ1+iESUh4dlYXB7gjR7BCGJPylA==
Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by proxmox01.kjsl.com (Proxmox) with ESMTPS id 68FF3E489C; Thu, 23 May 2024 20:53:22 +0000 (UTC)
Received: from smtpclient.apple (ti0389q160-2783.bb.online.no [46.9.227.254]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id E0A474E11B35; Thu, 23 May 2024 20:53:21 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Ole Trøan <otroan@employees.org>
Mime-Version: 1.0 (1.0)
Date: Thu, 23 May 2024 22:53:09 +0200
Message-Id: <B2877F84-7B07-4DC0-ABB0-2883593BDD2F@employees.org>
References: <7bcaaf7e-4564-4d76-9558-ab005aa70a30@gmail.com>
In-Reply-To: <7bcaaf7e-4564-4d76-9558-ab005aa70a30@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: iPhone Mail (21F79)
Message-ID-Hash: 2YSAQDJAMSAWXRZGUBOVEVVIH4CJRSU2
X-Message-ID-Hash: 2YSAQDJAMSAWXRZGUBOVEVVIH4CJRSU2
X-MailFrom: otroan@employees.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ipv6.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: 6man WG <ipv6@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [IPv6]Re: Analysis of Ungleich ULA Registry
List-Id: "IPv6 Maintenance Working Group (6man)" <ipv6.ietf.org>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Owner: <mailto:ipv6-owner@ietf.org>
List-Post: <mailto:ipv6@ietf.org>
List-Subscribe: <mailto:ipv6-join@ietf.org>
List-Unsubscribe: <mailto:ipv6-leave@ietf.org>


> On 23 May 2024, at 22:42, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> On 23-May-24 15:25, Lorenzo Colitti wrote:
>> On Thu, May 23, 2024 at 11:36 AM Brian E Carpenter <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote:
>>    Right. If I want to use fd00:bec0::/32 (BEC being my initials), I certainly can, and it will disturb nobody.
>> I believe Jen presented some data a few years ago on what prefixes are in use, based on backscatter. I don't have the link right now, but I remember that what emerged from the data is that people did not commonly use their initials. They commonly used fd00:: or fd01::. In other words, the chance of collision for human-picked ULA prefixes is very much larger than for randomly-assigned prefixes.
>> To use your words... will it "disturb" anyone to pick fd00::? I don't know. Networks that picked fd00:: will be disturbed if they ever interconnect with other networks that picked fd00::. Do you thik they are more likely to try to fix this using renumbering, or via NAT or NPTv6? I'd say the latter. If they do that, they will disturb application developers and users.
>> Is it "foolish" to pick fd00::? Well, I would say yes. But the people who picked it didn't think it was. Or maybe they just didn't know.
>> I don't have an issue when people make unwise or broken deployment choices. I just don't like it when people make unwise or broken deployment choices, and app developers and users end up paying the price. That's not fair.
> 
> I completely agree.

To what though? I would like to see specifics otherwise it is tempting to call FUD. 

Applications have to deal with multi-addressing, ephemeral addresses, NAT64, HE and SAS/DAS selection.
I struggle to see that the tiny probability of ULA conflict is what breaks the camel’s back. 

I’m not particularly concerned about a few networks using ULA as RFC1918, nor that many networks will end up with various forms of locator rewriting.

Cheers,
Ole