Re: [v6ops] 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> Sun, 14 February 2021 19:57 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 7ED1B3A08F9 for <v6ops@ietfa.amsl.com>; Sun, 14 Feb 2021 11:57:23 -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=unavailable 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 YCUywhFNEJUQ for <v6ops@ietfa.amsl.com>; Sun, 14 Feb 2021 11:57:21 -0800 (PST)
Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) (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 C87193A08C5 for <v6ops@ietf.org>; Sun, 14 Feb 2021 11:57:20 -0800 (PST)
Received: by mail-qv1-xf2d.google.com with SMTP id f18so2309936qvm.9 for <v6ops@ietf.org>; Sun, 14 Feb 2021 11:57:20 -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=NhOP1VHvIBB5d28T2tT3GxzBfy+VaYz2/HetJUpGVaw=; b=FNhUn+fUXa2UsnFrbNFTKupLGSl4+yRA3ap6K5Z7ieQ18kGdzFgqFWyRo01u3e3MWm wqB86ALR++qN9LpSV6LorX+FKMiAVYndExuoK72DmTtZka/r/q7eE0garW/JWVjT9ihh 1lH/AAKiHdQeORdkPAHiyrfifUzDww6eE73k0PCOu4StFx6aB8kmnlE/tyTUIn/QPkZh 1AliQFfryfBawSV8ljkUmA3+fRqJTn9SIIA5hbH66+jnlY8UqUU7a43kaa4+pFdnNI3/ 85/GKJ5+0Qsy87ASZaetULm+pbD9fNAlxOYk6T5V52spr9a9BEsTiRGIwYCytKhjMopm JWQg==
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=NhOP1VHvIBB5d28T2tT3GxzBfy+VaYz2/HetJUpGVaw=; b=QPIsgm9bSgpW6E/lRUKOe9rUdEJWRtBWQ8qCJmU7NIu3WkZf2Zx0GjMi39/FLn+bws tK3e+1gl9TT7iDLl2iqI+XCl3/QHWhdKEEBL0hNB/3PnjhhbqwbeXZ24qCKqXcTzKO76 tUxtBvIVPBME62fNHB9gUnbfhhNKh4zL8Ak5bOEj4wmhSTnMqdkuCu/Sate5feCY8KUi gfhfVge+X71CiQP7eM2y/Hzpdps0qwTmbkwbMrRbJ4Jnn+4tQDBX5WKQKY3Ez8WhG/NN RQoy4hIHKkK8imT6pmy3TPmgzRbDOPPp3h7N9lU7C4rqhXOL5HKqCr4pkCRcx/Uh4kW6 TIRQ==
X-Gm-Message-State: AOAM5322/O4rc6b20gv2UTRA99UoRyrg8k+2yudbY6gAOtbiCPWztrvy NOeaQuTeJQK/2e30WDUSQ1Sxuw==
X-Google-Smtp-Source: ABdhPJx6MEY6Ccjwdp8DpFfhfXwGNKL5OOsh68s2sleqbYBIv7VQnxc4OlNkyQ2kVbx20PNacOJtdw==
X-Received: by 2002:a05:6214:118d:: with SMTP id t13mr3909610qvv.33.1613332639702; Sun, 14 Feb 2021 11:57:19 -0800 (PST)
Received: from smtpclient.apple (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id s14sm9711330qtq.97.2021.02.14.11.57.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Feb 2021 11:57:19 -0800 (PST)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <227CDF8C-E929-4AA5-9D24-733381EB5C69@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2090D8CF-0B6F-4620-97BB-D761CD801644"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.32\))
Date: Sun, 14 Feb 2021 14:57:18 -0500
In-Reply-To: <CAN-Dau1CvbwZccq2Zyr8xBkiW1z0nKX_YcGW-y3VL7=pm+wA+w@mail.gmail.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, Fernando Gont <fgont@si6networks.com>, IPv6 Operations <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>
To: David Farmer <farmer=40umn.edu@dmarc.ietf.org>
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>
X-Mailer: Apple Mail (2.3654.80.0.2.32)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/R3eVpGKGNvHpygx1TU-E1C165es>
Subject: Re: [v6ops] 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: Sun, 14 Feb 2021 19:57:24 -0000

On Feb 13, 2021, at 7:45 PM, David Farmer <farmer=40umn.edu@dmarc.ietf.org> wrote:
> I think I'm hearing, 
> 
> 1. Rewrite RFC4007 to only discuss zone indexes for the Link-Local address on an interface, maybe rename then too. Junk the rest, it only confuses things.
> 
> 2. Rewrite RFC4291 to only refer to Link Scope (for Link-Local Addresses and the Loop-Back Address) and Global Scope for all other Unicast addresses except the unspecified address, eliminate all inference to other unicast scopes and the size of scopes. All uniqueness for Link-Local address comes from IID uniqueness provided by DAD, and there should be no discussion of uniqueness regarding Global Scope in RFC4291, it is only discussed in RFC4007. Also, eliminate the discussion of IID scope. Leaving Multicast scope alone.
> 
> However, unless we can agree on how to deal with the 64-bit boundary, or not to touch it, touching RFC4291 will only end in flames.
> 
> Is it possible to do anything with RFC4007 without ending in flames?


From my perspective at least, this conversation has been really useful, but I don’t see a cause to rewrite any documents. Being forced to confront my assumptions as a result of Fernando’s questions resulted in me discovering that a lot of things I hadn’t realized were clearly specified are actually clearly specified. The dissonance between RFC 4193 and RFC 4007 is interesting, but RFC 6724 addresses this dissonance quite satisfactorily. It’s possible that there’s an opportunity to write a small ops document here to make clear how to populate the policy table automatically based on prefixes seen on an interface, but I don’t think we have a Really Big Problem to solve here.

If people are confused, it’s probably because they haven’t read these documents.