Re: [v6ops] 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 16:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 425EE3A0FAF; Wed, 6 Jan 2021 08:13:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 HXlLUhk0x8KV; Wed, 6 Jan 2021 08:13:58 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D8B423A0F9D; Wed, 6 Jan 2021 08:13:56 -0800 (PST)
Received: from (localhost [::ffff:]) by with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1kxBRZ-0000INC; Wed, 6 Jan 2021 17:13:53 +0100
Message-Id: <>
Cc: Fernando Gont <>, IPv6 Operations <>
Subject: Re: [v6ops] 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 12:42:13 -0300 ." <>
Date: Wed, 06 Jan 2021 17:13:50 +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 16:13:59 -0000

>And, as noted, there are concrete implications:
>RFC4007 says ULAs are non-global, RFC4193 says that ULAs are global, and 
>a Python library says ULAs are non-global. I don't think we want that.

RFC 4007 does not mention ULA. I don't see why python libraries are
relevant for what we do.

>> We need to redefine zone IDs as interface IDs and clean up a lot of that
>> stuff.
>You mean use interface IDs as zone IDs?

No, rewrite RFC 4007 and get rid of zone IDs. And the introduce interface IDs
to select the interface of an outgoing packet, whether link-local or global.

It doesn't change anything in practice, because that is what existing code

>It must be clear what ULAs are, and what they are not. Part of that is 
>acknowledging that their scope is not global.

ULAs are not link-local addressses. That's the only thing we need to know.

Yes, we could update the definition of global scope in RFC 4007 such that
ULAs are included, but it strikes me as a waste of time. Unless, we are doing
a bis document.

>We don't need to change the scope of ULAs to accommodate them. We need 
>to change the scope of ULAs such that we don't have specs that 
>contradict with each other (consistency). Most likely, when we have 
>that, we'll end up accommodating the Python library as a side effect.
>They got it right, and we didn't.

Like I said, the definition of global scope in RFC 4007 can be fixed if we
would care enough. 

>... and you don't mean to fix that, but still expect devolopers from 
>multiple languages to get that right, and programmers to make sense out 
>of the outcome?

Developers should not use scope to mean anything. Maybe some applications
need to do something special when they encouter certain addresses. In that
case they can directly list the prefixes that need special treatment.

There is no need to come up with convoluted library schemes that try to
classify addresses. That only causes operational nightmares.

>> We have policy tables for source and destination address selection. Those
>> should be used to decide what to do.
>That's a "one size fits all". There are valid reasons for which you 
>mihgt *not* want to do that, (including using ULAs for services that are 
>expected to be local-only, not binding temporary addresses to listening 
>sockets, etc., etc., etc.)

Do you propose to introduce new scopes for temporary addresses?

The I-D we are discussion doesn't describe these issues in the problem

Maybe you want to go back to the problem statement and describe what you
really want to solve.