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

Philip Homburg <> Wed, 06 January 2021 15:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D6C2C3A0FD0; Wed, 6 Jan 2021 07:13:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.889
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XxZDyELjCJ_6; Wed, 6 Jan 2021 07:13:38 -0800 (PST)
Received: from ( [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 (Postfix) with ESMTPS id 5B5D53A0FBF; Wed, 6 Jan 2021 07:13:35 -0800 (PST)
Received: from (localhost [::ffff:]) by with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1kxAVC-0000KhC; Wed, 6 Jan 2021 16:13:34 +0100
Message-Id: <>
Cc: Fernando Gont <>, IPv6 Operations <>
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 <>
References: <> <> <> <>
In-reply-to: Your message of "Wed, 6 Jan 2021 11:26:57 -0300 ." <>
Date: Wed, 06 Jan 2021 16:13:31 +0100
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 Jan 2021 15:13:45 -0000

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

Some things don't need fixing even if they are not 100% correct.

Yes, we can define global scope (in the context of unicast) as anything that
is not link-local. And that would be nice for a bis document. But why

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

Effectively we have only two scopes: link-local and 'other'. What we need to
do is simply things, not create a bigger mess.

We don't need zone IDs that try to identify the scope of a ULA. All of this
was part of attempts to define local addresses. It didn't work.

We need to redefine zone IDs as interface IDs and clean up a lot of that

(It is possible that multicast is different, I haven't done multicast beyond
a single subnet for ages)

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

Networks don't just connect by themselves. Networks admins who connect two
networks are not going the read RFC 4007 and conclude from the definition of
scope that is safe to connect the networks.

People also connect RFC 1918 networks and have to deal with the consequences.
This is why operational documents could help.

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

The IETF does not define APIs for Python libraries, so I don't see why we would
need to change the scope of ULA to accomodate them.

We could call ULA 'private' if that would help python devs. But they can just
well call ULA 'private' without involving the IETF.

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

Applications should not do widely different things if they encouter a ULA.

We have policy tables for source and destination address selection. Those
should be used to decide what to do. 

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

They don't need to be marked 'non-global'. Changing the scope of ULA serves
no purpose.