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 15E383A0332 for <>; Thu, 7 Jan 2021 13:52:04 -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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q0ZugQX5tlKj 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 AFF453A033F for <>; Thu, 7 Jan 2021 13:52:01 -0800 (PST)
Received: by with SMTP id v5so5334724qtv.7 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=I7r/qVfRLC8ty1royD3yW5WswXyoNTuhtIoxpV/N5NF1JcEib0NVJhg750wDVIUsBq uZOnNAvWphB+BX5BbjXuz0pHu4ozd1c1Kvq2roVnEtZpc7IArPBR90KIJqREX4wSmsIA bC15xEpmupHzcGk22sVZS0fc+jtWyJt+MXOdzKgj9cCVAkKw1GUYU8DyRAA3Bz6zdTrB T5cNBf2XWhJRjcTAawfl/rqNhJ09snNRUd0aVgQEB5E3zWxrtQX1HAyUBtAlp3Uwtuhs AeCjP+HSfORfs0krQinoKR/Kb/2aK23m1XfUkKTd8yNoqcm8pxS8lOGxoaYTrzdCN40B EfdA==
X-Gm-Message-State: AOAM532Gw0uWIuq1ElF6M80phUTd3luiOeabS0NC05Z3B8dmTgqRYp/b fI2k9kcgO+z7r3ARkxEHMEn+3OwlbgsmtA==
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.\))
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: <>
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: 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.