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

Ted Lemon <> Sat, 13 February 2021 21:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 13C503A0FE5 for <>; Sat, 13 Feb 2021 13:52:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id g7BXGORM_-ag for <>; Sat, 13 Feb 2021 13:52:45 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 11D8C3A0FD8 for <>; Sat, 13 Feb 2021 13:52:44 -0800 (PST)
Received: by with SMTP id h16so2334453qth.11 for <>; Sat, 13 Feb 2021 13:52:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=vO7ow+0sBXnv+7+cHGhuD4n4arMoC7N+w2aKQOsUfYU=; b=B7HuFbJdzGrNw8iJi4lQfE70xf1gU/YDtsr75aND6DgwZ8pW0JIt0FOAEDepV4OVMQ b0Acl/+YKah3HYUUc2xltl46FI/A3DNKzP7k2f6Z9oeJkV7grZRxvK44z7rdJ5aemb+5 KKLjnRidqlAJzkI0VunPtZhkccfbsx221yd1nOI4cz+otfmSmmgbgGRAJbdNVmoC0oFB uAAEKl0XNxoqNbaqfkYzMEEZqVQgtOsDPUa6H3oJQy/YFO3q1P1THPiK8oh3oZsi6Fpu 9/qWOJPWncQtJCCUB/fHwL/A+Gn5C6kuoh2vretSbpk4+8YmIFGA1dFQ0DKmOVRr3SF9 IyWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=vO7ow+0sBXnv+7+cHGhuD4n4arMoC7N+w2aKQOsUfYU=; b=PpP3X4qJZmAUpSU4LTFJ12M0dMpcBFqIEh4YBYZ+hCLK1t5GksM5uhF+5W2fLYpzpB Uh6cqo3VKd6byKIN3XNs4GztE2lBw85GRzL0VHqhEvtglrE8M4wpPNd5g/A6tFQ5XUyN KeOUQBa8lmyRqO1GJiZsVnliAMc/knvpz2gaON0bh6JXZWaZsgen2FEAaWpLZ3N8Oefn W47LLlNk6z8M1VbvMWAODCNxDzsK90yeIfpzR8ROOZBT3tvR/kqWyGtDQ6LEPKnfeoYC AdF3Z4tfrR+dM3thbBMFEC7FlZxrxbNtCJ9p7NagkDMcEYf5AAcbb/JW5rCkOgE4p4iC Tmyw==
X-Gm-Message-State: AOAM530ypWJQE+zVFFqY19O+nO+NNRlWObiN9cBKqsz9whZo3B31OrvH 4ASFjt9tgWZXvmMCd61Df2eTUA==
X-Google-Smtp-Source: ABdhPJyZ9j3D8kKI1niHG/wdop9nk6ExHp2GzcIKT/dwgyfuwMIjkAfQvufgbT7KJuzLKePi4e6nYw==
X-Received: by 2002:ac8:70d7:: with SMTP id g23mr8381839qtp.25.1613253163929; Sat, 13 Feb 2021 13:52:43 -0800 (PST)
Received: from ( []) by with ESMTPSA id 199sm9268097qkj.9.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 Feb 2021 13:52:43 -0800 (PST)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_95EA60C9-D00A-46B5-9B7C-56966CF71C4E"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Sat, 13 Feb 2021 16:52:42 -0500
In-Reply-To: <>
Cc: David Farmer <>, Fred Baker <>, IPv6 Operations <>, "" <>
To: Fernando Gont <>
References: <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3654.
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: Sat, 13 Feb 2021 21:52:47 -0000

On Feb 13, 2021, at 4:11 PM, Fernando Gont <> wrote:
> I think the change you propose makes things way more complicated that simply keeping the scope definitions from RFC4007, and simply reclassifying ULAs et al.

We seem to be talking in circles. There are two scopes: global and link-local. ULAs are currently global. I am not proposing to change this. We can’t reclassify ULAs as link-local—they would no longer work. The problem is that the definition of global doesn’t match the other details of the definition of ULA, despite that ULAs are defined to be global.

>> On Feb 13, 2021, at 3:18 PM, Fernando Gont < <> < <>>> wrote:
>>> BUt that's again ULAs being special. And they usually have properties of "private" addresses -- e.g., can generally be expected to be valid if your link to your ISP goes down, are more unlikely of being renumbered, etc.
>> If your link is numbered with ULAs, then you’ll choose a ULA whenever you’re communicating with another ULA, because of the longest match rule.
> Scope rule is # 2.Longest match rule is #8.
> So you don't necessarily get the same outcome.

But ULAs are global in scope, so the scope doesn’t come into play if you are choosing between a ULA and a GUA. It only comes into play if your destination is link-local.

> For Dst Addr selection, the scope comparison is, again, rule #2 & rule #8, while longest-matching prefix is rule #9.
> The proper scopes would probably also benefit the other address "types" that David pointed out….

Again, though, ULA is the same scope as GUA, so if there’s a LLA<->LLA choice, you’ll pick that, but otherwise the priority rule (rule 6) prefers a GUA to a ULA as a destination address absent a policy table entry.

This is actually the part that could be problematic, since if we want connections to survive the lost of the ISP uplink, we want to use ULAs for on-network communication (for a single link, LLA will be preferred, so this is only a problem for a multi-subnet home). However, the RFC actually addresses this by suggesting that if a ULA is valid on-link, a policy table entry could be added for that specific ULA /48. The document is not as clear as I’d like about what that policy table entry should look like, and I have to admit that I haven’t thought this through, so I don’t know either.

It’s perhaps worth noticing that in the presence of Happy Eyeballs and gethostbyname(), I don’t know how many applications are actually using the destination address sorting rules.