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

Philip Homburg <pch-ipv6-ietf-7@u-1.phicoh.com> Wed, 06 January 2021 13:45 UTC

Return-Path: <pch-b9D3CB0F5@u-1.phicoh.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 2C3003A0A73; Wed, 6 Jan 2021 05:45:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.009, SPF_HELO_NONE=0.001, SPF_NONE=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 1PYCM59ZJ0eo; Wed, 6 Jan 2021 05:45:50 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43D943A0A5E; Wed, 6 Jan 2021 05:45:48 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1kx98E-0000EhC; Wed, 6 Jan 2021 14:45:46 +0100
Message-Id: <m1kx98E-0000EhC@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Cc: Fernando Gont <fgont@si6networks.com>, IPv6 Operations <v6ops@ietf.org>
Subject: Re: Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt)
From: Philip Homburg <pch-ipv6-ietf-7@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com>
In-reply-to: Your message of "Tue, 5 Jan 2021 22:20:55 -0300 ." <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com>
Date: Wed, 06 Jan 2021 14:45:43 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/gaCOATRqgFxUGl_Ty0QUdvw99FE>
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 13:45:53 -0000

>Prior to posting this document, we had some on-list discussion (on the 
>v6ops list) and also some off-list discussion with some of you (bcc'ed).
>
>The opinions have been in one of these camps:
>
>1) the current specs are coherent and there's no problem
>
>2) There's a problem with the definition of "global scope" -- so ULAs 
>*are* global scope, but global scope does not really stand for the 
>definition in RFC4007.
>
>3) The definitions in RFC4007 are correct, and thus the scope of ULAs is 
>not really global, but scopee(link-local) < scope(ULAs) < scope(global)
>
>
>While this document does propose a way out (it assumes #3 above, and 
>acts accordingly), I believe the first step is to agree on what "global 
>scope" means and, subsequently, whether ULAs are really "global scope" 
>or not. Since opinions on the topic have vary a lot (as noted above), 
>I've posted this I-D and I'm sending this note for further input from 
>the WG.

In my opinion we should leave scope the way it is. Scope has a specific
meaning for link local. In the past we tried to define local scope similar
to how link-local scope is defined and it failed.

'local' scope is an operational reality. You don't see it at the protocol
level. So we need to keep it clearly separate from link-local where we do have
quite a bit of protocol and API specification.

If I look at the problem statement in this draft, the issue seems to be that
ULAs may not work if you connect two networks that independently picked ULAs.
It is at all clear to me how giving ULAs a 'non-global' label would change
any of that.

I'm not sure this is a relevant problem. Locally anybody can make sure their 
ULAs have enough randomness. This results in a failure chance when connecting
to other networks of one in 2^40. Of all the operational problems you can
get when connecting two networks, this seems to be a very remote one.
I doubt that we can solve all operational problems that have a chance of one in
2^40 of happening.

Of cource with badly chosen ULAs, then chance is higher. But then again, does
calling ULAs 'local' solve anything?

I don't see an immediate technical problem with ULAs, certainly not one that
needs to be addressed with a standards track document.

A practical point that is mentioned in Section 5.1 is what to call ULAs.
For example, we could call them 'private'. I think there is a need to
the group of addresses that includes both rfc1918 and ULA. A short
informational draft that addresses that point could be useful.

The main technical problem is that happens if you want to connect two
networks that both use ULAs. However, in my opinion this requires operational
guidance. I.e., use ULA if you expect to never connect to another network.
Use ULA if in the one in 2^40 chance of a collision you can renumber.
Do not use ULAs for security purposes, that will come back to bite you.