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

Brian E Carpenter <> Sat, 13 February 2021 20:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E2D383A0C74 for <>; Sat, 13 Feb 2021 12:18:38 -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 Wg9zn0AWS2_O for <>; Sat, 13 Feb 2021 12:18:37 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 53F333A0C6C for <>; Sat, 13 Feb 2021 12:18:37 -0800 (PST)
Received: by with SMTP id k13so1730511pfh.13 for <>; Sat, 13 Feb 2021 12:18:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=gH4KfcWWi8d0Sw2yb9Ev1LD6jvNPrgHMXIjdpzBUoDA=; b=WF04eVetqgHQQQA8cfPfVUomtEObtaM8ojnoLBrLWaSqhsS+pDHUlCUMn1MrVBWZqd ieMqwUFVWTRJcZyuMp17K/cc4TBRY1aB3omjKT+9XcUoJtm/v/uayMqREVYKrrhV72P6 6SDEHEtkhvWtghHxELy4VFXdGXHr9ISm7zTtMobi7QF0ti8x6hgSmn6zx9Z3zOr0eS+N E5hhkmRUWFXLeP44baiIZeauWm6bHPC4VP3ZxEw+eee6ExNzUmPP3dgb14CTYGSzrNki ZTnzKVRGATGPh4+g5C57lyt4OIGq2kU6znnudwIF5ozqYOMHtTBhHFK9+kpJy3z2IKV2 RduA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=gH4KfcWWi8d0Sw2yb9Ev1LD6jvNPrgHMXIjdpzBUoDA=; b=FAWzHuhTT1s7yQIbXqohPZWNBXKUsC5iAjQIjIHyV090Lfzuq0g3QD8Ctp3DbSh9kR 56a2ajoprb5LUObMqweEIAM41jB9+fHDK2gPrETnL2/J/47la/K317GJkMRs2C3c8V3m bxYWRNUy2DqZ3auyKytUN8gWyu2dSnsHaJqQ+MF/SCnlXcvRs758RraNzZhj/FQK/bnV onF8ho3UKeJFx8yUHxEQb7mOMkUvyU4EY8BOK5Zz7vXxsdg9XdECw9938OUo94pN/vh8 b4e+BJYV02hzfFbOaUg/6oS5yZS7d7MYMAUrmZw2hTz3dhWshYz1mapbbZh+H20uVHJv fo6w==
X-Gm-Message-State: AOAM532U1ZDLcIPa1dy7JnEi/yfJxthoIukLVQkbAo31VtK1hGzc16oj 3ghLcbBOGulMZ/ijsYEIulg=
X-Google-Smtp-Source: ABdhPJwIV891Q1geswwXJOZf8c0q1uK2RMJufU08XwfFit/ikruKnh8S6RDjlbNcjBvvrxyeCDopEw==
X-Received: by 2002:a62:1bc9:0:b029:1e6:3492:2d88 with SMTP id b192-20020a621bc90000b02901e634922d88mr8651966pfb.72.1613247516231; Sat, 13 Feb 2021 12:18:36 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id k69sm13032683pfd.4.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 Feb 2021 12:18:35 -0800 (PST)
To: Fernando Gont <>, Ted Lemon <>
Cc:, Fernando Gont <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Sun, 14 Feb 2021 09:18:32 +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: quoted-printable
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 20:18:39 -0000

On 13-Feb-21 18:11, Fernando Gont wrote:
> On 13/2/21 01:51, Ted Lemon wrote:
>> On Feb 12, 2021, at 10:13 PM, Fernando Gont < 
>> <>> wrote:
>>> You might argue that architecture is not important (I'd disagree with 
>>> that :-) ), but, at the end of the day, if it's not important, why 
>>> pretend to have one in the first place? (in particular when there's no 
>>> consistency with the actual protocols)
>>> As noted, the only practical implications I've seen have been:
>>> * Folks willing to have a registry for ULAs, on the expectations that
>>>  they are indeed unique -- whcih they are not!
>>> * Folks having a hard time understanding the addressing architecture --
>>>  in particular the scoped addressing architecture (RFC4007) and how
>>>  that applies to actual specs (e.g., definition of ULAs)
>> The thing is, the meaning of the architecture document as it pertains to 
>> ULAs is plain to me, and it’s just what Brian said.
> If by "plain" you mean "clear", then this discussion should be an 
> indication that it's not. We have a definition of scope in RFC4007 which 
> doesn't match RFC4193... and then it should be clear that we all have a 
> different understanding of what "scope" and "global scope" (in 
> particular) mean.
>> So who is confused? 
> Well, I certainly have my own take on the topic. The fact that most of 
> the folks that have participated in this thread have their own and 
> different take, probably means something.
>> Are you having operational issues, or just speculating? 
> There are certainly no operational issues that I know of. (But we also 
> don't really leverage IPv6 addressing anyway, so...)
> As noted, I believe that the confusing terminology does have concrete 
> implications. e.g. see:
> ---- cut here ----
> 5.1.  Address Attributes in Programming Languages
>     Python's ipaddress library [Python-ipaddr] defines 'IPv6Address'
>     objects that have a number of attributes, including:
>     o  'True' if the address is allocated for private networks.
>     o  'True' if the address is allocated for public networks.
>     For ULAs, the is_private attribute is 'True', while the is_global
>     attribute is 'False'.  This contradicts the definition of ULAs as
>     having "global scope" [RFC4291] [RFC4193], but is in line with the
>     specification update performed by this document (see Section 6).
> ---- cut here ----
> (this one is documented in our draft, but credit goes to Brian for 
> spotting it).

The fact is that I spotted it due to an issue with running code.
Just for fun, here is the test for ULAness according to the Python
ipaddress module's semantics:

def is_ula(a):
    """Test for ULA"""
    return (a.is_private and not a.is_link_local
             and not a.is_loopback
             and not a.is_unspecified)

> Are the is_private and is_global attributes employed by such library 
> correct? Do they match our specs? Do they match the obvious 
> interpretation of such attributes?  Should they be changed? Why, or why not?

A bit off topic, but I think the .is_private attribute is a very poor
choice, because it might be misunderstood as implying privacy properties.

>> I don’t mean to minimize your concern—just trying to get a 
>> sense of why this has come up. Do you not know how to operate in the 
>> presence of ULAs? Have you been getting questions from customers that 
>> you can’t answer to their satisfaction? 
> I have got questions from customers that I wasn't able to answer with 
> *my* own satisfaction -- let alone theirs, so to speak. :-)
> Explain the scoped addressing architecture (even the very definition of 
> "scope" means.) Then introduce ULAs, and note that they are global 
> scope. Both cannot be right.
> Somewhat related:
> in the context of draft-ietf-6man-slaac-renum, some argued that one 
> should differentiate between GUAs and ULAs. And that you should only 
> phase out stale ULAs if you have fresh ULAs. And that you should only 
> phase out stale GUAs if you know of fresher GUAs.
> The rationale of this has a lot to do with whether GUAs and ULAs are a 
> different sort of animal.
> Thanks,