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

Ted Lemon <> Thu, 07 January 2021 21:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C0BC43A0365 for <>; Thu, 7 Jan 2021 13:52:03 -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 0vaEDmqOnFSr for <>; Thu, 7 Jan 2021 13:52:01 -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 7F5123A0332 for <>; Thu, 7 Jan 2021 13:52:01 -0800 (PST)
Received: by with SMTP id z9so5350769qtn.4 for <>; Thu, 07 Jan 2021 13:52:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=Yah5BKzrZcY59QVoRtmh+zi4NMojLGjFgjlFn82oQ3A=; b=Q87eaywU9xqrQNb+UqMw+36lgQV2bBCxCmejCrHhFZXnk9O70TSJ8pETJFFQb9+xAO SNIxrx91IJbo6YTtmmdFkrwjddUX1EuGY+mx9t2Ksc/QFkaorgRAVoSBbG8YffoZFCIe /VM5uMZNK+IogMO6qOxowDNSqsaF1H5ORZQAoLHK+E/f8vlB6w2sTK9vUAr/Gc8DFujx fsuUGkZFB4nNUdzCqDPIMkpfRJQrheNW8n+hd5IfDMNp6Qoh7NBME2rbL5LAeRcCMjoa lI7NqAd0WYd+6YedvZIqOzbgzD2zbD9I1ugZV7rXAhdDg31C0qqYU2VG5wz+YS/AbiLF 281g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=Yah5BKzrZcY59QVoRtmh+zi4NMojLGjFgjlFn82oQ3A=; b=dDBVXyBvPg7JERq3EIyaDkkQeL/h1h8Wgfl1fieuCM+3xyaVAuqSJBTMB4+tOo9Llh bF5bFpVEiq4JblE1EtqbuJ3tITuoHmE0T0yD02mcH07te3WpcOze4kttwCCQ2BXQ60VM CwufopR8HQSJvlXxgGRa9x1Yk27enm2+RLI5X2OMqAmm+VOxviUEWUAe9y9IY8o+dDcC wvgPqy5PNFbJtNUspL2TFikRiO8904ND6fCS/iw/qA0d6i1I3qu85mBocsw0BoBmR82y fCCcfO4PWtFl3/uINa4PkOnC5gAluT9gtxTx7Kys+q9LSEEuQer5aPSRjzDnnOZwc1Qu QuSQ==
X-Gm-Message-State: AOAM532fwcVOrbdF0tenieCW69AAuAY2wifWXhNy4uw+RDcRZWh0/wPs 0f6R9UTBD6FgoGX/3XUF3sPe5YMlS7sq7w==
X-Google-Smtp-Source: ABdhPJyIOnqRjl/Wc8VgHCyPO5OHpGatbxNOvAV3koFEiN+JuAa4u9mQnBvghDcdnzBULiGccZUwmg==
X-Received: by 2002:a05:622a:195:: with SMTP id s21mr682575qtw.53.1610056320340; Thu, 07 Jan 2021 13:52:00 -0800 (PST)
Received: from mithrandir.lan ( []) by with ESMTPSA id h22sm1076805qth.55.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jan 2021 13:51:59 -0800 (PST)
From: Ted Lemon <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9B9E229B-E3CB-421A-BD3B-D84608B26E86"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt)
Date: Thu, 7 Jan 2021 16:51:57 -0500
References: <> <> <> <> <> <> <> <>
To: IPv6 Operations <>, 6MAN <>
In-Reply-To: <>
Message-Id: <>
X-Mailer: Apple Mail (2.3654.
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: Thu, 07 Jan 2021 21:52:04 -0000

On Jan 7, 2021, at 4:35 PM, Fernando Gont <> wrote:
> In order for them to have "global scope", they need to be globally unique. And you note that "they are essentially unique, gven an appropriate scope”.

I think the disconnect here is that RFC 4007’s definition of “global scope” clearly contradicts the sense in which ULAs are “global.” So that’s a real problem.

At the same time, the next question to ask is in what sense “global scope” is actionable. People have been talking about zone identifiers as a way to determine scope, but in practice the way we do this is with routing table entries. The reason you have to specify a zone ID for a link-local address is that the route to the link-local prefix is present on all interfaces, but the address is valid on only one interface.

So you specify that interface with the zone ID. I use the term interface loosely here—in principle you could have two interfaces connected to the same link, and that would notionally mean that they both have the same zone ID, but there’s no safe way to make this determination in practice, so in practice the “zone IDs” will always be different.

The same situation does not apply for ULAs. You can (almost) just use routing table entries to deliver ULAs. I say (almost) because of course if you don’t have an explicit route to the ULA prefix, you can’t send the packet. So there’s a tendency to want to send the packet to the default route, but that doesn’t work if you have two interfaces and two default routers. This is why it’s tempting to then use the “zone ID” to resolve this problem. But that doesn’t work, because the host has no way to know which zone ID to use.

So it’s the network’s responsibility to provide enough information that the ULA can be correctly routed. There are two ways to do this that spring to mind:
1. Make assumptions
2. Only send to a ULA if you have a specific non-global route that points to it.
3. Use provisioning domains (

Option 2 is probably the safest solution. If the route is present on two interfaces, and you have a collision, and not just two valid ways of reaching the same destination, then you will have a problem. This is why ULAs aren’t as fabulous as we might wish. But in practice, it’s entirely safe to do this.

Option 1 could work pretty well, e.g. on a cell phone. Not so well on a host with two network interfaces. It’s unlikely that a ULA is going to work on the global internet, so you never send it on the cellular interface. Problem solved. This is the sense in which I think it’s tempting to say that the scope of a ULA is not global, because here you can make a purely mechanical decision.

Option 3 would work quite well. Presumably if the name server for a provisioning domain gives you a ULA, then you can use the default router for that provisioning domain to reach that ULA (if it’s not on-link). So here you have effectively an explicit scope, which really doesn’t play well with the meaning of “scope” in RFC 4007.