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

Fernando Gont <fgont@si6networks.com> Sat, 13 February 2021 22:08 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D97E3A1036; Sat, 13 Feb 2021 14:08:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 STDIRy6P1ARU; Sat, 13 Feb 2021 14:08:20 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9FDD3A1010; Sat, 13 Feb 2021 14:08:20 -0800 (PST)
Received: from [IPv6:2800:810:464:2b9:1c77:acfc:e6a8:1311] (unknown [IPv6:2800:810:464:2b9:1c77:acfc:e6a8:1311]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 13F6A280204; Sat, 13 Feb 2021 22:08:13 +0000 (UTC)
Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt)
To: Ted Lemon <mellon@fugue.com>
Cc: David Farmer <farmer@umn.edu>, Fred Baker <fredbaker.ietf@gmail.com>, IPv6 Operations <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>
References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <F4E00812-E366-4520-AE17-7BB46E28D575@gmail.com> <CAN-Dau3iOjjU+FLpdtA7nqfKRX+sjjSanAU8U-O3pH-k5nSoig@mail.gmail.com> <a3fbfb94-90ae-961c-a2ab-33ade27e074e@si6networks.com> <5D1FBC37-1024-4300-AFA5-19F329E9F1D1@fugue.com> <CAN-Dau02FHbrWghcYXEGURFreT0JnY_QpVu2btpj94im3K30PQ@mail.gmail.com> <2DFE5AFF-82AF-4519-93AA-9E78D134AB68@fugue.com> <1213fb18-5e89-1f35-d095-6cc67b5f0102@si6networks.com> <776FA1FA-E0A7-4449-ACAA-ECA0E24D5465@fugue.com> <c0d928e1-f2be-52be-75a5-e4ba01a15811@si6networks.com> <4D63780F-0EC5-43A9-BF5E-24081CE91C0E@fugue.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <988e3743-3632-d480-72c7-ab64583d4c38@si6networks.com>
Date: Sat, 13 Feb 2021 19:08:06 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <4D63780F-0EC5-43A9-BF5E-24081CE91C0E@fugue.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/QhiEFuCAWpek5qD5kLejKFsiuqM>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Feb 2021 22:08:23 -0000

On 13/2/21 18:52, Ted Lemon wrote:
> On Feb 13, 2021, at 4:11 PM, Fernando Gont <fgont@si6networks.com 
> <mailto:fgont@si6networks.com>> wrote:
>> I think the change you propose makes things way more complicated that 
>> simply keeping the scope definitions from RFC4007, and simply 
>> reclassifying ULAs et al.
> 
> We seem to be talking in circles. There are two scopes: global and 
> link-local. ULAs are currently global. I am not proposing to change 
> this. We can’t reclassify ULAs as link-local—they would no longer work. 
> The problem is that the definition of global doesn’t match the other 
> details of the definition of ULA, despite that ULAs are defined to be 
> global.

We can introduce a new scope, "admin local" (or whatever), and mark the 
ULA space as such. -- That's what David and myself propose.




>>> On Feb 13, 2021, at 3:18 PM, Fernando Gont <fgont@si6networks.com 
>>> <mailto:fgont@si6networks.com> <mailto:fgont@si6networks.com>> wrote:
>>>> BUt that's again ULAs being special. And they usually have 
>>>> properties of "private" addresses -- e.g., can generally be expected 
>>>> to be valid if your link to your ISP goes down, are more unlikely of 
>>>> being renumbered, etc.
>>> If your link is numbered with ULAs, then you’ll choose a ULA whenever 
>>> you’re communicating with another ULA, because of the longest match rule.
>> Scope rule is # 2.Longest match rule is #8.
>> So you don't necessarily get the same outcome.
> 
> But ULAs are global in scope, so the scope doesn’t come into play if you 
> are choosing between a ULA and a GUA. It only comes into play if your 
> destination is link-local.

The scope definition for ULAs is flawed. It doesn't follow RFC4007.



>> For Dst Addr selection, the scope comparison is, again, rule #2 & rule 
>> #8, while longest-matching prefix is rule #9.
>>
>> The proper scopes would probably also benefit the other address 
>> "types" that David pointed out….
> 
> Again, though, ULA is the same scope as GUA, so if there’s a LLA<->LLA 
> choice, you’ll pick that, but otherwise the priority rule (rule 6) 
> prefers a GUA to a ULA as a destination address absent a policy table entry.

You had asked if there was any use in fixing the scope definition (i.e., 
whether there'd would be any practical implications from it). My answer 
was "yes, if you fix it, it will be considered by RFC6724, which 
compares the scope of addresses).



> This is actually the part that could be problematic, since if we want 
> connections to survive the lost of the ISP uplink, we want to use ULAs 
> for on-network communication (for a single link, LLA will be preferred, 
> so this is only a problem for a multi-subnet home).

If a new scope was created such that scope(LL) < scope(ULA) < 
scope(GUA),  this rule in Dest Address selection would prefer ULAs:


    Rule 8: Prefer smaller scope.
    If Scope(DA) < Scope(DB), then prefer DA.  Similarly, if Scope(DA) >
    Scope(DB), then prefer DB.


> It’s perhaps worth noticing that in the presence of Happy Eyeballs and 
> gethostbyname(), I don’t know how many applications are actually using 
> the destination address sorting rules.

All but browsers? Or am I missing something?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492