[IPv6]Re: Analysis of Ungleich ULA Registry

Mark Smith <markzzzsmith@gmail.com> Fri, 24 May 2024 04:39 UTC

Return-Path: <markzzzsmith@gmail.com>
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 B8E16C14F69D for <ipv6@ietfa.amsl.com>; Thu, 23 May 2024 21:39:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.596
X-Spam-Level:
X-Spam-Status: No, score=-1.596 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQF83zzsMF-s for <ipv6@ietfa.amsl.com>; Thu, 23 May 2024 21:39:39 -0700 (PDT)
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (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 D10B7C14F618 for <ipv6@ietf.org>; Thu, 23 May 2024 21:39:39 -0700 (PDT)
Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-a5a7d28555bso1254755166b.1 for <ipv6@ietf.org>; Thu, 23 May 2024 21:39:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716525578; x=1717130378; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=tKJH6e1UVX8nUmyLeoAr9Z6P65CBoCYq6WBsfsA3sBE=; b=lzDEKNnzXrCFbVWJMU1w6gcqE7Bb4r45r73fPvFkWWmOc0FYaV2HY16IX8OrxwkWxY jsM8Ws1GCyW3vamiLqPU/0Cff+LxTrqsaidc02WUvZxONeE03yVNSKrcdw6PbZhplLCH v8G65drnxcuqx25jP/Xk84SKsyV3bFLoX2xxWn5chlm8cKekd7tab7pQQD4bwRHK2muo qdYUkK/WmCAU1z/uoWZmqmiB1e3cr/SzsZIEaQfWfPpR0gFj4S4Uky4hMl47eP9gDYAl oXftMhVvWChn9DhQJExoUeXYNf8vSI5oJhrxC03wj6RGBOUlv3gtHL5pZ1qQUeAkpAa+ Jwaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716525578; x=1717130378; h=content-transfer-encoding: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=tKJH6e1UVX8nUmyLeoAr9Z6P65CBoCYq6WBsfsA3sBE=; b=OJEYGd4Z8C8PaIQpS4SP3pkvzAOEtbcL+U/lw54L9gfsFvvpm1qiGtJnrBGubqA6/Y IFqg6mXzF3lgGRItmKR4kEIE5sd55XAt2PKbnlTTjCmk7GqBjsrP6xhryYe9icMvJ5xC 8RZ3h4HxHaMBhiNxgaXRbRXnchwfEhXVJtVkzwFz//8k6jibpN/ZmNu8jo+JZridVLfY 7/zAyLuLF8GXlB0EzOlonw+Ov/v3QEBvnjs56miV1qzZtXekXWfDaseA/1EvTyQR7zpH 4TUsv6FUowQ2mKEI1Syl68hJS3nwsA+E9MMwNk38g07i6YEZFho8qqfS4AWs+IxWOwdq w0RA==
X-Forwarded-Encrypted: i=1; AJvYcCXET0xe5vxMBjX9vMInAEVqMa6TMVipSp28UGK71rS1BKAjznmGlspm7uSHUesMfqHVInDUL1PZwiqhSt3t
X-Gm-Message-State: AOJu0YyZG2fcjwBb8WiIyBF8q3ryKwcMnogx1GaIVtCZlvXp2rhKjR6Q RVgQirB2o5URzjs8/ND1Qps8mbFUVJMXnaVrDe13N0hbgsfiSmSGrrp+BKEJkrOrj36upzltm5j vlD3eS+rgsG8goCfgJNHvxu7eVAM=
X-Google-Smtp-Source: AGHT+IH9a+e4/r3hfOIEQVkWvODKWtnRKsfp7Ldevz92PEtDEWDpbyDoZgsqtfWEeeBDWtqaxmvREGDxsPLA/KdP3zY=
X-Received: by 2002:a17:906:50f:b0:a59:9cc1:7330 with SMTP id a640c23a62f3a-a6265259d3amr62621366b.64.1716525577926; Thu, 23 May 2024 21:39:37 -0700 (PDT)
MIME-Version: 1.0
References: <CAN-Dau0J1uqpwnRXYpeSFGUTJ532MmpeGd4BLoAqqf8HzeFTjQ@mail.gmail.com> <CAJU8_nW7Q3WphfgtgnK0E+88R1_nENCy9MBBYhG2G1bkPD9UeQ@mail.gmail.com> <CAN-Dau0Nc0VHMHdRg7MG6yf2X1S_SrYbA6YhKUzBz7XiLkR5cg@mail.gmail.com> <CAO42Z2ye16kbexYv7DB5n7qzvxv0njezXEYUqsSzbiFLYOmUDQ@mail.gmail.com> <C3ECF392-D612-4D60-BEC5-87628CDAC694@gmail.com> <CAN-Dau3pdkQjk65ET2b9v5fiwQ+m1rMZAHnR6YNfOBhh+iiYKQ@mail.gmail.com>
In-Reply-To: <CAN-Dau3pdkQjk65ET2b9v5fiwQ+m1rMZAHnR6YNfOBhh+iiYKQ@mail.gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Fri, 24 May 2024 14:39:11 +1000
Message-ID: <CAO42Z2yjhLiUndHtLsPdqjA8YbFOO7LMh_bjn49JpsfkFdr+dQ@mail.gmail.com>
To: David Farmer <farmer@umn.edu>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: DY5LGTYDHFOL7QEDWOQMT5Y5G4LCJAOF
X-Message-ID-Hash: DY5LGTYDHFOL7QEDWOQMT5Y5G4LCJAOF
X-MailFrom: markzzzsmith@gmail.com
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: Bob Hinden <bob.hinden@gmail.com>, IPv6 List <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>

Hi David,

On Fri, 24 May 2024 at 11:47, David Farmer <farmer@umn.edu> wrote:
>
>
>
> On Thu, May 23, 2024 at 8:05 PM Bob Hinden <bob.hinden@gmail.com> wrote:
>>
>> Mark,
>> > On May 22, 2024, at 8:55 PM, Mark Smith <markzzzsmith@gmail.com> wrote:
>> > I think you can only conclude that if you believe that most people are
>> > generating ULA /48s correctly. I've seen enough examples that they
>>
>> I note that it’s probably not “people” doing this, it is routers.  On my home network, the routers (eero) creates what looks to me to be a ULA /48 with a random prefix.
>
>
> I agree with Bob. Most people aren't generating them. Either their router is, or they use a tool. l\Looking at the Ungleich ULA Registry, while there are plenty that are not random, the vast majority are.
>

You were using this registry data to justify the need for people to
have shorter than /48s, meaning multiple /48s. I was pointing out that
I don't think they're realistic because I've seen too many examples of
incorrect and unrealistic ULAs.

> 581 Names with >1 Entry
> 8 Names with >10 Entries

Are you saying that more than 10% of the 4886 unique names have a
realistic need for between 131 072 /64s (2 x /48s) and 655 360 /64s
(10 x /48s)?

Or that 8 of them have a realistic need for 11 or more /48s?

How do you know that these are legitimately sized registrations rather
than just an IPv6 ULA "land grab" because ULA /48s are very cheap to
generate?

We shouldn't be miserly with IPv6 address space (I advocate and have
deployed /48s for residential ISP customers), however we also
shouldn't swing too far the other way and try to accommodate single
address space sizes that are beyond realistic or common.

>> > .... I don't think
>> > shorter than /48 ULA is actually a common requirement at all.
>>
>> I agree with that.
>>
>> I would go further and say that organizations that require shorter prefixes, should probably just get Global addresses from their ISPs or from the RIRs.
>
>
> I agree they are not common. Even the Ungleich ULA Registry shows that, but it also seems to demonstrate their existence. However, my primary argument for short prefixes is that the known-local ULA change we are making puts a practical limit on the number of ULA prefixes of about 10. Again, this is not a problem for most networks; they seem to exist.
>
> Your answer seems to be don't use ULA for your internal addressing.
>

Not at all. There are security and renumbering benefits to deploying
ULAs in parallel with GUAs in any network (internal services/servers
that only have ULA addresses cannot be an Internet DoS target because
the Internet traffic can't reach them).

In a network large enough, e.g., with an supposed need for 1 048 576
/64s, I'd quite happily use 16 x random ULA /48s rather than a single
/44 "ULA".

The usefulness and time/cost savings of having a single /44 rather
than 16 x /48s would be trivial in a large network for an internal
address space.

Experience with running a network with multiple aggregate address
spaces isn't rare, ISPs have been doing it for decades with multiple
IPv4 assignments from RIRs.

Regards,
Mark.


> --
> ===============================================
> 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
> ===============================================