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

Brian E Carpenter <> Sun, 20 December 2020 04:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6EE493A0AC5; Sat, 19 Dec 2020 20:44:39 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 KFO__vkbr_Qb; Sat, 19 Dec 2020 20:44:37 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::62e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0D5AC3A0B45; Sat, 19 Dec 2020 20:44:32 -0800 (PST)
Received: by with SMTP id q4so3827739plr.7; Sat, 19 Dec 2020 20:44:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=1HqHpr4F/gSJBX5O1VNwxJMyC9k606lttGrphiyfY20=; b=sn7+SPfs/yDPDJNHVWF8VzKPU+kyQ8bGfmyoJUHKq7k1PlGF+ZV7hVb4vJGZpxMD65 IiTcNv+X8gBC8qv/sqcw5/E4DJ4SYEirsULjQCKsbZnntbEuUUF43+KpJuYS2wnsF+T4 GSmw3zd701wGQkh+UZNVeBn/khw9J+ZaiG8ti+C+8WhK8yVoYAUuDVe+69qZqZsYkpfx MQn2NScnvPvaPLZopN32O4ZWD3btK7+5YcQ8YPRbXa6nB+SvUirXnc3y5WTLvG/6N0B2 Zptt/trr0B4HexfwOvjGln9aiGM8jR8BoAtKafhS6mN9SfDOV76A7W662HjdDT2FC/9m sg4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1HqHpr4F/gSJBX5O1VNwxJMyC9k606lttGrphiyfY20=; b=NPIYbnCvYHGzy9D1EKYMeFnoZQvEX503XW8XYrAe1V8Z7N+q6YnsC2KInxSjX5KUSP glsaXTghESvkM+KOpwlntICee9t5RGS1uR6N/V5dz1TcpT7uUAvyidR2KvzgVHyrLi7J k+hJVdgVMWu42RdAUSsu0L6NFzTBfg6Jskt0BkXsaScRe+qRCbz+ycdh1bXbmTS178kC 39xhh81WehgXamQpG8KEdW3zvimtzk67+r2LJt1tqDHIlH7MQrMOiJ2rr4v6N/SPfLi/ smlZEwo9Q0BgBRGq5BJdP4MnRxtDswu3iAhNAbC6dsktPZhXkmLzyj56csq+BgBDKQSL HS7Q==
X-Gm-Message-State: AOAM53301lTD8n4bODtSytQEFeKyDIqWTvTh7bR6yidjK3BbIrZNc9hn ZsCECFbxsxTS4lzDFImaxy3V2g39fK3Ydw==
X-Google-Smtp-Source: ABdhPJzBJ//A6SQZPveIQA4d/3KTZl6BctQYkJ275QTgRUV4QU1ATAm6PjSp+LLIrFVBs6PLjHSZhw==
X-Received: by 2002:a17:90b:1087:: with SMTP id gj7mr11436951pjb.41.1608439471938; Sat, 19 Dec 2020 20:44:31 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id w22sm12363120pfu.33.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 Dec 2020 20:44:31 -0800 (PST)
To: IPv6 Operations <>,
References: <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Sun, 20 Dec 2020 17:44:27 +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: Sun, 20 Dec 2020 04:44:45 -0000


Thanks for this draft.

> 3.1.  Legacy Specifications and Schemes

I don't think that section is complete without mentioning site-local and why it was scrapped (RFC3879).

> 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. 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. 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.

>    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. 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.

(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.")

>    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.

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. They are global in protocol terms, but not globally routed in operational terms. These are orthogonal properties.


On 12-Dec-20 05:00, wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>         Title           : IPv6 Addressing Considerations
>         Authors         : Fernando Gont
>                           Guillermo Gont
> 	Filename        : draft-gont-v6ops-ipv6-addressing-considerations-00.txt
> 	Pages           : 27
> 	Date            : 2020-12-11
> Abstract:
>    IPv6 addresses can differ in a number of properties, such as scope,
>    stability, and intended usage type.  This document analyzes the
>    impact of these properties on aspects such as security, privacy,
>    interoperability, and network operations.  Additionally, it
>    identifies challenges and gaps that currently prevent systems and
>    applications from leveraging the increased flexibility and
>    availability of IPv6 addresses.
> The IETF datatracker status page for this draft is:
> There are also htmlized versions available at:
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> I-D-Announce mailing list
> Internet-Draft directories:
> or