[IPv6]Re: Analysis of Ungleich ULA Registry

Kyle Rose <krose@krose.org> Thu, 23 May 2024 01:36 UTC

Return-Path: <krose@krose.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 241ADC14F6EF for <ipv6@ietfa.amsl.com>; Wed, 22 May 2024 18:36:21 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 (1024-bit key) header.d=krose.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 Ri7MxMq-VD1j for <ipv6@ietfa.amsl.com>; Wed, 22 May 2024 18:36:17 -0700 (PDT)
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 25C80C14F6B4 for <ipv6@ietf.org>; Wed, 22 May 2024 18:36:16 -0700 (PDT)
Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-574b3d6c0f3so11905348a12.0 for <ipv6@ietf.org>; Wed, 22 May 2024 18:36:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; t=1716428175; x=1717032975; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=B3yPeSGRI6gW5NileSNh6fIbJoacZIy/f9npQ5JU5mE=; b=Uo5f2VEW9UAY6u56QNBkBLVkTc97JULeWQIXMQqH0SBFVy7TOw0VZsSdm0nNndurOU ggKoRwYuEBPN4AGM3h9mRmxcpW3rlGl5kooO9KaSV0zPJf4INffCE5Y3EHRDls2HKC/D gNRYygdU+YAJC5vM1bl2KYNRxgbcW1brWdl6M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716428175; x=1717032975; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=B3yPeSGRI6gW5NileSNh6fIbJoacZIy/f9npQ5JU5mE=; b=fKTCPElXVT4ZjUnsZvVZJ4uloQ9Ki4tAm3/qYPE7ICJJZFVrAC1ChrB5w0qpDxep8m D4c6sPP8ieungRYqZWcPDI/B0jiEjVyIvJ5+up+/PS8hwDxsyms/MG6nHa3Xam+mGfQm SopNvmGt1OEgkpuGLJbIlEj82Jajj4gDxOuepJhSB/WppvncemO/V5CVUkw5rMZMJja3 Qn5XOrL58qnKwi+eIl6xsEcbPQRvzSf7JV0N4MJ5eM/ZU3CFotER70Q5jsXa0GMNSHhM s28vfulqOEbslpNVr4YpZF4qAJmWyzh/XCMYZpaL3dv1ZaIMEfeYrATyzMnHMJ3VjjPJ qdkA==
X-Gm-Message-State: AOJu0YwN76T2BhyT9xQTuw3fxOsJunG/SxapexC1o+Qqp+XS0V4ydawj skVyLkflMaQ3eMFtxSA3xOLeqPf/i319nUgDUC6dAhrDyJ6G34RfJ5PjhwZFPCjp8bh3NT/cAQx dwBFpW4sLAgwJ21bMOIj+AhgGVaM+iqeZ2eXnQhcoSivECuFU
X-Google-Smtp-Source: AGHT+IHflVKfiLxHFKUKleVQz/5qRTGw8RPpAo7PLcbrbq9EPsgstTWRYI3c2Da2B3mZgmE/gJapKxMm2PcraUCZ/jg=
X-Received: by 2002:a50:d4d2:0:b0:56e:238e:372c with SMTP id 4fb4d7f45d1cf-57832c1a8b2mr1900498a12.26.1716428175094; Wed, 22 May 2024 18:36:15 -0700 (PDT)
MIME-Version: 1.0
References: <CAN-Dau0J1uqpwnRXYpeSFGUTJ532MmpeGd4BLoAqqf8HzeFTjQ@mail.gmail.com>
In-Reply-To: <CAN-Dau0J1uqpwnRXYpeSFGUTJ532MmpeGd4BLoAqqf8HzeFTjQ@mail.gmail.com>
From: Kyle Rose <krose@krose.org>
Date: Wed, 22 May 2024 21:36:04 -0400
Message-ID: <CAJU8_nW7Q3WphfgtgnK0E+88R1_nENCy9MBBYhG2G1bkPD9UeQ@mail.gmail.com>
To: David Farmer <farmer=40umn.edu@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a8d91f06191513ae"
Message-ID-Hash: 2PTTFPJPHTIKBC5GFE3DZGT3JYE5VE7V
X-Message-ID-Hash: 2PTTFPJPHTIKBC5GFE3DZGT3JYE5VE7V
X-MailFrom: krose@krose.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 Wed, May 22, 2024 at 9:21 PM David Farmer <farmer=
40umn.edu@dmarc.ietf.org> wrote:

> Many of the names and organizations with the largest number of entries are
> generic entries. For example, there are 135 name entries with some version
> of "Admin" or "Administrator" and 52 organization entries with some version
> of "Private."
>
> Nevertheless, at least a handful of what seem to be real organizations in
> the registry purport to use more than 10 ULA prefixes. The limitations of
> the new known-local ULA list in draft-ietf-6man-rfc6724-update could be
> problematic for these organizations.
>
> Also, given the number of names and organizations with multiple entries,
> there seems to be some evidence for the need for ULA-C prefixes shorter
> than /48, especially if an organization's justification for shorter
> prefixes can be evaluated.
>

We are not the protocol police.

Organizations are de facto free to do whatever they want with ULA-R space,
including choosing prefixes shorter than /48 or choosing those prefixes in
a non-random way. The key distinction from many other protocol violations
is that the only possible harm is to themselves, should they in the future
need to merge with, or use ULA to route to, some other organization that
happens to use overlapping address space. I won't cry for them, but I might
chuckle.

I don't see how these use cases justify ULA-C or central assignment. I
might even suggest we go the other way and soften the language on ULA-R
prefix generation to make it clear that while they REALLY SHOULD NOT*
self-assign short prefixes or ones not generated at random, all operational
considerations resulting from making that choice are on them. It's purely a
foot-gun: you can't draw it from the holster or point it at anyone else.

Kyle

* Q.v. RFC 6919. This is a case for which one of those keywords might
actually be appropriate.