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

Ted Lemon <mellon@fugue.com> Mon, 15 February 2021 22:05 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B253A11EC for <v6ops@ietfa.amsl.com>; Mon, 15 Feb 2021 14:05:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level:
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=fugue-com.20150623.gappssmtp.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 9zOgitMpGtSd for <v6ops@ietfa.amsl.com>; Mon, 15 Feb 2021 14:05:45 -0800 (PST)
Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 826003A11EB for <v6ops@ietf.org>; Mon, 15 Feb 2021 14:05:45 -0800 (PST)
Received: by mail-qv1-xf35.google.com with SMTP id t18so3827249qvn.8 for <v6ops@ietf.org>; Mon, 15 Feb 2021 14:05:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Qd9K3rZLhwhhZKalj1+7jIh5qC1wEcEOcxdeuxXgUYQ=; b=VIGnN4kopmibtMWQoEYQwDoch2HIGGg/ARGp4kmxFK/mrIHpCmq47q+0Ud4Hg9y1Vy nCCubR0Ri2q7DN8F5yXYcTgAR0aN2/nhHJ3x0+6rIbtNBRXiug9CPz5d56otzLv4AD2x TrY3tJkMLL/sNun4DMI+G+8IgzZPjZxF71U5tPlfBOSh5NGk0qcHnnbnDqwBy5b1q5hB 69NB1DYKAtUUhDa1IGTFNf+LH2sAms2SsNcIbnSQfQJBCICzFFKD/1LBZ49ePpkhosoV s5nl64Q5rMtML7Gpz4sdGvuerUMTe1SWmrzX4mczNkfKLI46nH02Xybz1ikjkvI+ZKCI 42+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Qd9K3rZLhwhhZKalj1+7jIh5qC1wEcEOcxdeuxXgUYQ=; b=m8omaoFK9/+cSkk8CLK6RNPZudFp5yF3AeIwQlapazMCta4cdPCR01zIKTD6HCxSb/ 6Ck/VsHbUbSw7Iicm4yrGeSPRJJe2VMSbepia24z+PzA3dSaBEm6dEmluR8+f16QmdIY rBkO3fMi4oalFjyqV9OAF+IMyCMcVPeA8sOAxNkYGrznpRmBRSlTcFyQ4jkPH3Ghec5H uCzBk5R3ihzJvogO6ujeXHDl/Jbv5bKT0uP21moynH99wN03G/ipIllX+QwPz45TrpLM hcJ0JvAVEW7mFHOpw3nfA5rt/Hp5/8eAXp8SQiZkbeCRlDfgV6m4oHOGy/nC0ffJQJRi B9Xg==
X-Gm-Message-State: AOAM533CMN4/e/LfGaezF4Qobwt+x5HvVxQYfvkQH2qet6/KPcINq62W sFrLKPw66doOgH7+EK1nYRJDlA==
X-Google-Smtp-Source: ABdhPJx5mG9vGaSsSrQqY9CYmsg5IPtZBrU8A6SlbKQSPTrCzIsVClPX5hIFUxC8kto8s7k6OaG5fQ==
X-Received: by 2002:ad4:5a42:: with SMTP id ej2mr17088286qvb.60.1613426744448; Mon, 15 Feb 2021 14:05:44 -0800 (PST)
Received: from smtpclient.apple (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id z139sm13199797qkb.0.2021.02.15.14.05.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Feb 2021 14:05:43 -0800 (PST)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <98707BCB-C0BF-434A-B6F2-70CE20418CDD@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_FD61923C-A2BB-4BBF-AEEC-195528C662BA"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.32\))
Date: Mon, 15 Feb 2021 17:05:42 -0500
In-Reply-To: <d1ea3406ec70488696a091ac1d5d0ff9@boeing.com>
Cc: Fernando Gont <fgont@si6networks.com>, IPv6 Operations <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>
To: "Manfredi (US), Albert E" <albert.e.manfredi@boeing.com>
References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <F4E00812-E366-4520-AE17-7BB46E28D575@gmail.com> <CAN-Dau3iOjjU+FLpdtA7nqfKRX+sjjSanAU8U-O3pH-k5nSoig@mail.gmail.com> <a3fbfb94-90ae-961c-a2ab-33ade27e074e@si6networks.com> <672bd5e6-bdce-5915-1082-1ed30d3c5980@gmail.com> <CAN-Dau1CvbwZccq2Zyr8xBkiW1z0nKX_YcGW-y3VL7=pm+wA+w@mail.gmail.com> <227CDF8C-E929-4AA5-9D24-733381EB5C69@fugue.com> <CAN-Dau0JsMJ6Ad1pqeEKSKpRiSXDibMG4yKdVOKL4uFoqi5sAQ@mail.gmail.com> <EED3FE0C-1CE6-4472-895A-7BA6C6A998F3@fugue.com> <4cebe185-0b1b-04c1-4a89-b6c207bb82bb@si6networks.com> <b31c8eddd0c14e539f7c4fb472eb3563@boeing.com> <c0cd20f7-aa40-0053-9056-4df913716ac7@si6networks.com> <d1ea3406ec70488696a091ac1d5d0ff9@boeing.com>
X-Mailer: Apple Mail (2.3654.80.0.2.32)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/meKL-DX4zG0EJOFDOgpUflpW7MI>
Subject: Re: [v6ops] [EXTERNAL] Re: Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Feb 2021 22:05:47 -0000

On Feb 15, 2021, at 4:49 PM, Manfredi (US), Albert E <albert.e.manfredi@boeing.com> wrote:
> Your mention of birthday paradox depends on how many organizations use ULAs. If not many do, then the likelihood of global uniqueness goes up.

There are also different uses for ULA. ULA can be used for internal addressing by large orgs, and there there’s potential for overlaps, if for no other reason than that large orgs sometimes merge.

Another use for ULAs is on home networks. In this case, we don’t expect ULAs to ever need to cross the router. So the set of networks on which home network ULAs need to work is very tightly constrained, and we don’t need to worry about ambiguities.

Another use for ULAs is stub networks. In this case, again we do not expect the ULA to ever make it past the adjacent infrastructure link (the link to which the stub network is attached).

So chasing after global uniqueness is not necessary in most cases; even in the case where it is possible that there will be conflicts, /global/ uniqueness is not really the issue. In a case where two orgs are merging, the likelihood of a ULA collision, assuming they used a real RNG to generate the ULA, is small, and if it happens, the worst case scenario is that one or both of the orgs need to renumber before they merge. This is not something that’s going to just randomly cause a problem.