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 14:27 UTC

Return-Path: <fgont@si6networks.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 77B463A0E12; Wed, 6 Jan 2021 06:27:34 -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 7jPvMtMvwmP4; Wed, 6 Jan 2021 06:27:32 -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 857A73A0EA0; Wed, 6 Jan 2021 06:27:32 -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 157C0284F20; Wed, 6 Jan 2021 14:27:27 +0000 (UTC)
To: Philip Homburg <pch-ipv6-ietf-7@u-1.phicoh.com>, ipv6@ietf.org
Cc: IPv6 Operations <v6ops@ietf.org>
References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <m1kx98E-0000EhC@stereo.hq.phicoh.net>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <b53b5d62-0334-f791-f56a-f2122767ecdb@si6networks.com>
Date: Wed, 6 Jan 2021 11:26:57 -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: <m1kx98E-0000EhC@stereo.hq.phicoh.net>
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/v6ops/IN9kXTOjszmlhke4zuqXING3QjE>
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: Wed, 06 Jan 2021 14:27:41 -0000

Hi, Philip,

On 6/1/21 10:45, Philip Homburg wrote:
[...]
>> 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. 

The current definition of global scope as per RFC4007 doesn't match the 
definition of ULAs as being global scope. Both of them can't be right.



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

"scope" and "zone" are part of the architecture. So we have a IPv6 
Scoped Addressing Architecture, and then a definition ULAs that doesn't 
really comply with that definition.



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

Changing the formal scope of ULAs does change the expectation when it 
comes to their usage: i.e., ULAs are not expected to be globally unique. 
They are just expected to have small chances of collision if you 
connected a limited number of ULA-based networks.

Besides, this does have an impact on current libraries (such as Python's 
ipaddress) and other libraries or macros that may have been defined for 
other languages, or that may be defined in the future.

This in turn probably affects the use such apps make of a list of 
addresses, when more than one is available.



> 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 problem is that for ULAs to be marked as "non-global" (whatever we 
call that), RFC4291 needs to be updated. Also, at least a part of 
RFC4193 needs to be updated.

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