Re: [v6ops] I-D Action: draft-gont-v6ops-ipv6-addressing-considerations-00.txt

Brian E Carpenter <> Sat, 26 December 2020 01:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 88B503A0E80; Fri, 25 Dec 2020 17:04:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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.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 XBXrSySyDKeB; Fri, 25 Dec 2020 17:04:12 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::102b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6BA6E3A0E7F; Fri, 25 Dec 2020 17:04:12 -0800 (PST)
Received: by with SMTP id v1so2902110pjr.2; Fri, 25 Dec 2020 17:04:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=qH6mWCVJrnq22fnVP6E2yAexeZQDiUlLQrAT3e0ybNY=; b=WdRHyp+2rs6i9jIPy7YgnF5R/5gBsHw3D5DTpz/DLvNGY+ayNzSHe+2ZVNamj4Ye+v hyxzVs8GjRMzqWSmV26JsGmgPjDbT6pSx5gaOpoaJfWdO6ordk8YSjQpWuoOX416WeYX s3ZDuOqs56vGjhWbNWjGcJnYDhYvxsxT7iD+T582kZubEORQZpanxJBDEw8YbrJyeQXg bG8mrB9kFcJ7zmGRYwLiJ3MgYOwRgFUlljrugzrj51WiK5onRqrdAnJ5jRhI6W70Cmus avl6CnF5R4IUvIV+DwNVtl3x5qSD6AnohtbljGBWBWgjN3xEGHBEAkYVwJRovWbhtuod n0mg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=qH6mWCVJrnq22fnVP6E2yAexeZQDiUlLQrAT3e0ybNY=; b=ctFKkIV2rsUmO7Q8kDlVKLc2+fgBq8cFq/0Y6wgxxAWw4eXNykAD6GsXJ7Qzzt/xy8 LXyIu9dQe86NuXmNrus2ZL34I4Ie4/QZCM8NbnJN8fMwC6ZEGIgXqo07Mw//oinR5MxY PIpzRqBUn61MIN5SQj84X6F9G8ByESK1A5y2S8TjFyEUTkMwu/+2idQ+3m8k/C3p0q2E i31YwpiI1VIX3q7hIuIYIfCsS8EtNiJhS8+s+GHDHu1KzUDkUt+h2ceYSRVfUzrAXXZ7 p+yoZiRg/b3HsFj6ql9g6ZcMWKwdt5dmHzdOGxv9lrXG8pGc9uslOY6CV4crrPlmA4cg M06w==
X-Gm-Message-State: AOAM530fSlzsFwQb9dbpY9PlGF+elJPallf79NxBMXdNVnPTCes7gzk/ ilDuXM8WUSK6cCF20NaSvtYCRFHVdRlBkg==
X-Google-Smtp-Source: ABdhPJyRJ/3PgYTaoAsPJxHAi79lU7cT0BIKFp0ScJyuEb/t6UO0Xy1S3ReCEMbMvjtX5N/lPuqBkQ==
X-Received: by 2002:a17:902:ee02:b029:db:c0d6:57f9 with SMTP id z2-20020a170902ee02b02900dbc0d657f9mr35544207plb.65.1608944651114; Fri, 25 Dec 2020 17:04:11 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id 6sm15814181pgo.17.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Dec 2020 17:04:10 -0800 (PST)
To: Fernando Gont <>, IPv6 Operations <>,
References: <> <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Sat, 26 Dec 2020 14:04:05 +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: 7bit
Archived-At: <>
Subject: Re: [v6ops] I-D Action: draft-gont-v6ops-ipv6-addressing-considerations-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, 26 Dec 2020 01:04:15 -0000

There's now a better version of my diagrams at


On 25-Dec-20 11:15, Brian E Carpenter wrote:
> Hi Fernando,
> On 24-Dec-20 18:50, Fernando Gont wrote:
>> Hello, Brian,
>> Thanks for your comments! In-line....
>> On 20/12/20 01:44, Brian E Carpenter wrote:
>> [....]
>>>> 3.1.  Legacy Specifications and Schemes
>>> I don't think that section is complete without mentioning site-local 
>>> and why it was scrapped (RFC3879).
>> Will do.
>> Comment/question (since I wasn't participating in 6man when RFC3879 was 
>> published, and I've never used site-locals myself):
>> There seem to be two main issues with site-locals:
>> 1) use of the zone index ("%___")
>> 2) "ambiguitiy" of the addresses.
>> Regarding #1:
>> My understanding is that site-locals where expected to be used with a 
>> zone index (as we normally do for e.g. link-locals) in the case the same 
>> prefix is employed on two different networks.
>> Now, my question is: why do this in the first place? What I would expect 
>> is that you simply use the address. Then, if the same node attaches to 
>> two networks that employ the same prefix, that's a configuration 
>> problem. Period. *If* in such scenario, *and for debugging purposes* you 
>> want to be able to specify which interface to use to send packets to a 
>> site-local address (that looks like "on-link" on two different 
>> interfaces), then you use the zone index -- but that's for *debugging* 
>> purposes, since having two subnets employ the same site-local prefix 
>> would be an error.
> If you read RFC4007 you will *not* find that a zone index is formally
> equated to an interface index. The "zone" terminology is confusing since
> it did originally assume a nested scope model, link-local inside site-local
> inside global. By some magic the host was supposed to understand enough
> of the network topology to use a single value "zone index" to capture
> the topology and tell the drivers which interface to use. See diagrams
> at . 
> Slides 3 and 4 show scenarios that simply can't be captured
> by a one-dimensional zone index. In practice, of course, the zone index
> is only meaningful within the host. So the whole concept of a zone
> index for nested scopes was a mistake. With hindsight, we should
> have cleaned that up more definitively in RFC4007.
> (And this problem is still a problem:
> was opened
> 9 years ago and still gets traffic despite being formally "closed"
> 5 years ago.)
>> Regarding #2:
>> Modulo the above, for the most part non-global addresses *are* 
>> ambiguous. So this is kind of a feature.
> Yes, but not a *good* feature since it leads to the problems
> in my slides 3 and 4.
>> With the minor consideration in #1, site-locals do not seem to be a lot 
>> different than ULAs. -- Yes, you are supposed to randomize the ULA 
>> prefix ( which I don't when using them in labs, since I don't want 
>> ugly-looking addresses :-) ).. but you might also argue than when using 
>> site-locals you better made sure that you didn't  employ the same 
>> site-local prefix in to interconnected networks, anyway.
> But the design didn't provide for that, whereas the ULA design does
> (and no, using pretty ULA prefixes is not OK).
> RFC3513 was seriously broken, because it suggests using "the same
> subnet IDs for site-local and global prefixes", which doesn't
> make much sense and certainly doesn't provide a high probability
> of uniqueness.
>> Am I missing something?
>>>> 3.2.  Unique Local IPv6 Unicast Addresses (ULAs)
>>> ...
>>>> However, the only reasons for which these addresses are considered 
>>>> to have "global scope" are:
>>>> o  given two different networks that employ ULAs, it's unlikely 
>>>> that they will employ the same ULA prefix
>>> Not at all. The reason they formally have global scope is because 
>>> when site-local was scrapped (as being meaningless and unenforcable, 
>>> see RFC3879), only two scopes were left: link-local and global.
>>> There was no other choice.
>> Why not, say, "IPv6 Private Address Space"? -- Yes, in the light of 
>> "ipv6 is all about the global addresses", mimicking IPv4's private 
>> addresses probably wasn't "sexy", but IMO the concept is useful, and 
>> well understood.
> I think that adds confusion. They are only private because of the
> requirement to block them in border routers; it's not a property
> of the address itself. (Thumbs down to the Python ipaddress module
> by the way, which has invented an "is_private" property and gets
> "is_global" wrong for ULAs.)
>>> What that means is that protocols treat
>>> them *exactly the same* as RIR-assigned prefixes. That applies to
>>> all protocols: ND, RA, DHCPv6, and every routing protocol. They are
>>> only treated differently by policy, such as address selection policy
>>> or boundary router policy. 
>> Wouldn't this also be the case if they were redefined as "IPv6 private 
>> address space"?  i.e., from the point of routing, modulo the link-local 
>> prefixes, you simply have prefixes that you distribute information 
>> about.  i.e. "Private address space" (i.e., non-global) shouldn't be 
>> treated differently by routing protocols.
> It's true, but that's what the "global" property means, and it's different
> from "globally reachable". It's not ideal terminology, of course, since the
> design process had a false start with "site-local".
> Happy holidays!
>      Brian
>>> And, if you like, the pseudo-random
>>> prefix assignment mechanism is also a policy, by making prefix
>>> collision highly unlikely. ULA-C would be a different policy, by
>>> making prefix registration compulsory.
>> Comment/question (rather than "objection"): since the "scope" is
>> essentially defined as the region of the network topology where an
>> address is meaningful, it would seem to me that claiming "ULAs" are
>> global-scope is at odds with the fact that ULAs prefixes are
>> locally-generated.
>> Put another way: when you analyze what "scope" means, ULAs really have 
>> nothing of "global scope". ULAs are not centrally managed, and as such 
>> are ambiguous.
>> (I guess you could argue that ULA-C could be global for some meaning of 
>> the concept. But then I don't see much of a point for such a thing. -- 
>> just use global addresses, and filter where appropriate.)
>>>> o  the ULA address block formally belongs to the Global Unicast 
>>>> Address (GUA) address block
>>> ...
>>>> The ULA address block has been carved out of the GUA address 
>>>> block,
>>> This statement seems misleading to me. GUA is not actually defined 
>>> very well in RFC4291. True, the table in section 2.4 says "Global 
>>> Unicast (everything else)" and none of the formal updates to RFC4291 
>>> change that.
>> Yes, that was my rationale.
>>> But the choice of fc00::/7 by RFC4193 makes it clear 
>>> that these are not normal GUAs; by definition they are not assigned 
>>> by the RIRs or announced on the public Internet. They are listed in 
>>> the IANA Special-Purpose IP Address registry and discussed
>>> explicitly in RFC8190, so the claim that they are part of the GUA
>>> block seems very dubious.
>> FWIW, I think that RFC4193 should have formally updated RFC4291 (or, 
>> well, since probably they were published together, RFC4291 could have 
>> marked the ULA space in the addressing architecture, and point to 
>> RFC4193 for further details).
>> BTW, there are no macros that would distinguish ULAs them from regular 
>> global addresses:
>>> (I think it's a bug in RFC4193 that it didn't make an update to 
>>> RFC3513, the predecessor of RFC4291, which actually foresaw such a 
>>> case: "Future specifications may redefine one or more sub-ranges of 
>>> the global unicast space for other purposes, but unless and until 
>>> that happens, implementations must treat all addresses that do not 
>>> start with any of the above-listed prefixes as global unicast 
>>> addresses.")
>> Ok, it looks like we are on the same page. :-)
>>>> Therefore, ULAs are not globally meaningful and thus, for most (if
>>>>  not all) practical purposes, ULAs can be considered to have non- 
>>>> global scope.  For this reason, ULAs are treated as non-global 
>>>> scope addresses, even when from a specifications point of view
>>>> they have global scope.
>>> I don't accept that. I believe we've had that discussion and the 
>>> consensus is in RFC8190 and the IANA registry already.
>> Sorry: what we *meant* here is that, throughout our document, when we 
>> refer to "non-global addresses" we are also thinking about ULAs.
>> (e.g., the "possible isolation provided by the address scope" applies 
>> (to different degrees) to both e.g. link-locals and ULAs...)
>>> Later in the draft you say:
>>>> In the same light, a ULA prefix generated by a local router will 
>>>> be, by definition, provider independent.  However, a router might 
>>>> also be leased an ULA sub- prefix from its upstream, in which case 
>>>> this prefix would be "provider dependent".
>>> Exactly. This illustrates that as far as protocols go, ULA prefixes 
>>> behave exactly like RIR-assigned prefixes.
>> Couldn't one also argue that ULAs are, e.g., "IPv6 private address 
>> space" and that, as with the RFC1918 space,  no special provisions are 
>> needed in routing protocols -- other than one filtering prefixes 
>> when/where deemed appropriate?
>>> They are global in 
>>> protocol terms, but not globally routed in operational terms. These 
>>> are orthogonal properties.
>> Sorry for insisting on this one -- I'm bringing up this issues because I 
>> found myself trying to provide an explanation for "global in protocol 
>> terms", without a lot of success. :-)
>> It would seem to me that virtually every use of "global" for ULAs 
>> (modulo ULA-C, I guess) is, conceptually speaking, kind of cumbersome 
>> and incorrect. -- and creates expectations that, at the end of the day, 
>> are probably not going to be fulfilled.
>> Wouldn't the most natural thing be to flag ULAs as "IPv6 Private Address 
>> Space", where e.g. from the point of view of protocols, the same 
>> considerations as for RFC1918 apply (no, I wouldn't *say* this in a 
>> spec), and we simply have the additional feature in the spec that we 
>> recommend how to generate the ULAs prefixes to avoid possible hassles 
>> when merging two different networks?
>> Or, to put in a different way: RFC1918 is private address space, and we 
>> don't need to call it "global" in any way to flag the fact that 
>> addresses from that private address space are not treated in any special 
>> way by e.g. routing protocols     -- for instance, why should they?
>> Thanks!
>> Regards, and Merry Christmas!