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

Brian E Carpenter <> Wed, 06 January 2021 21:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BB4053A1320; Wed, 6 Jan 2021 13:30:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.36
X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qWsUfmKOqwEG; Wed, 6 Jan 2021 13:30:42 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B2DED3A1332; Wed, 6 Jan 2021 13:30:41 -0800 (PST)
Received: by with SMTP id x12so2199860plr.10; Wed, 06 Jan 2021 13:30:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=sDkEyE+FbLEVswaEdAeRtvWNY5jlhRPI34LVCkuErN0=; b=qrUDy0PF9T2NyNbe6hnDXRibVufsKsQ7HMWlif1BchBBJUY7pAc6FkY4Eq/xwi14AB ZZfnYiGLAOrF8KPsNSC792KzWrxrsWYKEIiGNhuhxwRaNRRF6F8orLQAlcfFUlufPXuT o29PYJaZ7aIMccMPqmKEuyb6A6bMEas24J7ybbPqI7jUiZjDYD714HsnsjLLw2WKvnAi PtBkPmeAsXm4/Tys0PkNuw2vlFSiDXwIGPIsusDYdAePrSP6PzQK2qLgtRy2DYRAl8j+ 486sPM59UgeFMahHWIUIewMAoLwrEHJX2dX7bdQ3pGPZpOmq/awlF3vikuB31IodkdWX TvVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=sDkEyE+FbLEVswaEdAeRtvWNY5jlhRPI34LVCkuErN0=; b=iOnjeRr4OzulSVq3fwzt9sOOc8CEAhKgcX/D78wGhvwcKJP8mbix4MYX3QJoM7jZu5 lKYCvmMgQEYMETl34so1FfqDelXgYBL1g7xJPLaRY6JPX7Tu4ffGM4Gm+fFqLtWlF8v9 GhnbwsbXGx2hIvaXryY4k2st6HYQ1YTJ3a2Ri/yybyVlB8qQ31glMpIJYSEp3+mcDnnA 0uDsrgx7J8xADVTLwMmfpZhFOciuxFC3Eh/BBcS5r2hXFkkoyWxwCq6GotnbDFc3zynY TDn+wdNN+owEpFUV7rPicbiHLewKufYp33LMLj2+TOw0YLUSR9pNVqYpWn97aSLJJwli Raqw==
X-Gm-Message-State: AOAM532fQ+owaCKcZjkryMHSF+vr08C3q2b9STxl9pdN2VoUloovGmbq Xr2Hke35kNLuF+0psQRnRbPy3SOt4XBOAQ==
X-Google-Smtp-Source: ABdhPJzL0elJfnYbv+Ik5uRx+JzATNfkKiiqF9YhLMzIEoaeL+uYQiE9K/MhwJh/9U2cmeAPQ2H9tA==
X-Received: by 2002:a17:902:8483:b029:dc:3e69:4095 with SMTP id c3-20020a1709028483b02900dc3e694095mr6188436plo.66.1609968640690; Wed, 06 Jan 2021 13:30:40 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id q6sm3109412pfu.23.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jan 2021 13:30:39 -0800 (PST)
To: Lorenzo Colitti <>, Mark Smith <>
Cc: Fernando Gont <>, IPv6 Operations <>, 6MAN <>
References: <> <> <> <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Thu, 7 Jan 2021 10:30:35 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 Jan 2021 21:30:50 -0000

Portmanteau reply to multiple messages:

On 06-Jan-21 20:07, Lorenzo Colitti wrote:
> So I guess I'm somewhere between 1) and 3). The specs are consistent but they fail to consider human behaviour, so they don't actually work in practice.

I disagree. They work fine in practice.  The smart meter example is a good one. The ANIMA autonomic control plane is another. My TV has a ULA address. I have no idea whether it's used when I control it from my Android phone, because address selection does its job.

The problem is largely theoretical, and educational for people who train IPv4 users in IPv6 terminology and practices. As Fernando has pointed out, the use of the word "global" is confusing for something that has L for "local" in its name.

On 06-Jan-21 20:30, Christopher Morrow wrote:
> option 4, deprecate ULA.
> the best option (tm).

I can't see the least argument for that (no proven damage) and very strong arguments against (running code and operational deployments).

On 07-Jan-21 01:17, Ted Lemon wrote:
> GUA: “valid everywhere on the internet scope”
> ULA: “not valid everywhere scope”
> LLA: “valid only on this link scope”

Friendly amendment:

GUA: valid everywhere
ULA: Unique Limited-domain Address
LLA: valid only on this link

("scope" is really a noise word, and "Internet" is too restrictive.)

On 07-Jan-21 02:45, Philip Homburg wrote:
> '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.

That's why using "scope" is a noise word. It isn't an abstract property. Try to draw it and you get a mess. This really hasn't changed since Or see

On 07-Jan-21 04:13, Philip Homburg wrote:
> Some things don't need fixing even if they are not 100% correct.


On 07-Jan-21 04:29, Richard Patterson wrote:
>>     Applications should not do widely different things if they encouter a ULA.
> But they do.
> Some OSes will see the presence of a ULA address on an interface, and start sending AAAA queries, some will not.
> Some applications will see a ULA destination address and simply ignore it, preferring the IPv4 destination address returned. 
> We need to ask the question why this is happening, and if the answer is "They're doing it wrong", great, let's point them at the existing RFCs and educate them, but if not...... we need to do something, and I think this I-D is a good starting point for WG discussion at least.

FYI, we tried 6 years ago, but draft-ietf-v6ops-ula-usage-recommendations stalled.

On 07-Jan-21 05:13, Philip Homburg wrote:
>> 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.

Effectively that's what RFC3879 did. RFC4007 was a bit behind the curve. As far as I know, zone IDs and interface IDs are exactly equivalent (at least in POSIX and WinSock environments). IMHO this is *only* a terminology question.

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

Really? Using the interface ID for non-link-local addresses?

On 07-Jan-21 05:26, Gert Doering wrote:
> Why should applications, or anything that is not an admin, care if an
> address is a ULA or a GUA?

It depends on what you mean by "application". I've written code that explicitly prefers a ULA, and I could imagine a security spec saying "prefer ULA". But anyway, it's not really a problem, is it? (It's annoying to me that in Python, a ULA has .is_global == False, but I managed to code round that error.)

On 07-Jan-21 06:06, Ted Lemon wrote:
>> or rename the scopes to be 0 (link-local), 5 (mid-range), 10 (global)…
> This implies concentric circles, which isn’t really valid.

It really, really, really isn't valid. That's where we went wrong in 1995. Once the mid-range scopes start to overlap, the concentric circles model fails completely. That's the main reason we scrapped site-local.

On 07-Jan-21 07:04, Ted Lemon wrote:
>> There are potentially many GUA (2000::/3) addresses that could be in DNS,
>> which would not work for some originators due to ACLs, and yet a different
>> entry might work just fine.  Why would ULA be any different?
> The usual case here would be through a VPN; in that case the VPN will specify some set of domains that should be resolved through the VPN’s name servers. You really don’t want the ULA advertised globally.

But neither do you want private-use 2000::/3 addresses advertised globally. I really don't see a difference between RIR-assigned and self-assigned (ULA) prefixes in this respect.