Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt)

Fernando Gont <fgont@si6networks.com> Wed, 06 January 2021 07:38 UTC

Return-Path: <fgont@si6networks.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 F20B63A08E7; Tue, 5 Jan 2021 23:38:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.161
X-Spam-Level:
X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 bJhZi8F01NB9; Tue, 5 Jan 2021 23:38:41 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF3763A095E; Tue, 5 Jan 2021 23:38:40 -0800 (PST)
Received: from [10.0.0.129] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id A4256283A88; Wed, 6 Jan 2021 07:38:36 +0000 (UTC)
Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt)
To: Lorenzo Colitti <lorenzo@google.com>, Mark Smith <markzzzsmith@gmail.com>
Cc: IPv6 Operations <v6ops@ietf.org>, 6MAN <6man@ietf.org>
References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <CAO42Z2wR-3vbHi-NrBBMmCTNDq5fgqvSmBUbYK7P+63QTNfxkg@mail.gmail.com> <CAKD1Yr014PzVJj9Y6O=PBGc_QSVtur-0wMpaNkFA0dqr8FHGuA@mail.gmail.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <3e8a9ff3-ac2b-988b-8517-fbbdcff9ff9e@si6networks.com>
Date: Wed, 6 Jan 2021 04:38:23 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <CAKD1Yr014PzVJj9Y6O=PBGc_QSVtur-0wMpaNkFA0dqr8FHGuA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/KJsnQ18II-gWoSnLOE19ytJBcjQ>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jan 2021 07:38:44 -0000

On 6/1/21 04:07, Lorenzo Colitti wrote:
> On Wed, Jan 6, 2021 at 11:01 AM Mark Smith <markzzzsmith@gmail.com 
> <mailto:markzzzsmith@gmail.com>> wrote:
> 
>     ULAs are intended to be globally unique addresses, but not to be
>     globally (Internet) forwardable. Their forwarding scope is limited
>     to non-global, either within a single local network, or between a
>     set of local networks that have agreed to forward their respective
>     ULA /48 prefixes between each other, overriding the default of local
>     networks only forwarding scope. (Ethernet addresses are a similar
>     example, globally unique addresses, link only forwarding scope.)
> 
> 
> IMO defining ULAs as they are was a mistake. Global scope implies 
> unique. But probabilistic uniqueness doesn't work because humans choose 
> ULAs instead of generating them manually.

Not only that. At a global scale, the Birthday problem tells you that 
the ULA prefixes will also be non-unique. ~1.2M of house-hods generating 
their ULA prefixes already gives you P~1 that you have a collision at 
the global level. Indeed, the math in 
https://tools.ietf.org/html/rfc4193#section-3.2.3 already implicitly 
acknowledges this fact, because the probability of collision is computed 
on the basis of how many networks you interconnect -- that's certainly 
not what "global scope" means.



> Registry-based uniqueness 
> doesn't work (and, to be fair, was never tried by the IETF) because 
> there is no registry that has jurisdiction. Even if there were, there is 
> no reason to keep addresses unique if they don't have global reachability.

Fully agreed.



> So I guess I'm somewhere between 1) and 3). The specs are consistent but 
> they fail to consider human behaviour, so they don't actually work in 
> practice.

If you look at the definition of scope and global scope from RFC4007, 
it's inconsistent with employing it for defining ULAs as global.

(Indeed, the *L* in ULA says it all ;-) )



> I don't know what to do about this though. If we say they're 
> non-global scope, then they are going to be the exact equivalent of 
> RFC1918 addresses, with all the problems that that causes. If we 
> continue to say they're global scope, then the specs don't match 
> reality. :-(

One can say that they are local scope, with the expectation that since 
the ULA prefix is meant to be randomly generated, then sites that comply 
with such requirement will have a small probability of prefix collisions 
if two ULA-based sites were to be merged/interconnected.

I think that's as real and factually correct as it can get.

Besides, this also means that libraries such as ipaddress match the 
specs. -- right now, they don't. And it would be hard to argue that 
libraries such as Python's ipaddress should be changed such that ULAs 
are flagged as both "global" and "public". -- something that would not 
only be wrong, but that can also not be done in a backwards compatible 
manner.  Also, if apps, for some reason, are checking such address 
attributes, it's certainly better that the attributes are set in an 
intuitive way (the current one, which doesn't match the specs), in the 
hopes that they can make something useful out of differentiating IPv6 
address properties.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492