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 <brian.e.carpenter@gmail.com> Sat, 13 February 2021 20:18 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D383A0C74 for <v6ops@ietfa.amsl.com>; Sat, 13 Feb 2021 12:18:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wg9zn0AWS2_O for <v6ops@ietfa.amsl.com>; Sat, 13 Feb 2021 12:18:37 -0800 (PST)
Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53F333A0C6C for <v6ops@ietf.org>; Sat, 13 Feb 2021 12:18:37 -0800 (PST)
Received: by mail-pf1-x435.google.com with SMTP id k13so1730511pfh.13 for <v6ops@ietf.org>; Sat, 13 Feb 2021 12:18:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id k69sm13032683pfd.4.2021.02.13.12.18.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 Feb 2021 12:18:35 -0800 (PST)
To: Fernando Gont <fgont@si6networks.com>, Ted Lemon <mellon@fugue.com>
Cc: v6ops@ietf.org, Fernando Gont <fernando@gont.com.ar>
References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <F4E00812-E366-4520-AE17-7BB46E28D575@gmail.com> <b2e51a89-e8a7-9ddb-643d-63a98569b03c@si6networks.com> <CB9EA5F4-A241-46A4-A371-B2A1BFB8C72F@fugue.com> <dff93a2e-f4f8-01c9-ce88-c2dbb20a04f1@si6networks.com> <759637FF-77C7-41EA-8671-73988AD48873@fugue.com> <6ab2d348-6220-6744-9585-1f99e23a7ee0@gont.com.ar> <EFF8F0BB-D147-4D99-B17A-892825835590@fugue.com> <dd7c8d97-3f1c-e82e-4b7a-431f727adeec@si6networks.com> <B7E3D476-C4AE-425A-945E-FBCBAE1E4037@fugue.com> <9a5c8db7-3d6f-060d-33f2-1f63499a2c8e@si6networks.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <971635b5-81c9-594a-0200-23a71d3b1f4b@gmail.com>
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: <9a5c8db7-3d6f-060d-33f2-1f63499a2c8e@si6networks.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/-XU_mYYK6y6jXwAkfRgQeUlLnVw>
Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=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 <fgont@si6networks.com 
>> <mailto:fgont@si6networks.com>> 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.

   Brian
>> 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,
>