Re: [IPv6] I-D Action: draft-ietf-6man-rfc6724-update-07.txt

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 05 April 2024 20:55 UTC

Return-Path: <brian.e.carpenter@gmail.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 D959EC151531 for <ipv6@ietfa.amsl.com>; Fri, 5 Apr 2024 13:55:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Eq2kumY_YSD for <ipv6@ietfa.amsl.com>; Fri, 5 Apr 2024 13:55:31 -0700 (PDT)
Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38AD2C169506 for <ipv6@ietf.org>; Fri, 5 Apr 2024 13:55:31 -0700 (PDT)
Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-1e0b889901bso23339225ad.1 for <ipv6@ietf.org>; Fri, 05 Apr 2024 13:55:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712350531; x=1712955331; darn=ietf.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=M6hvTDv0V346eQIXs0xg5A+umppjETFzUR5TSF2RGi8=; b=OH9jw1+Xy1E80LWy567jnMgftGKBmta2LzKuSaGodWod9q4jKGcEVBzPogoMs9euC/ bpL4eBjb4FsIc3PxHVtj8AH7BFVrt9pUzLl4qxwRtBpM1hjY6lySjd0NsdHwmg4UtwTU fybGqi5gjiahEdZ12BGJKZBvQFju9rUab0T7TluXcxOJy2R75U+Ll5oDizl5jtRCtYun 0deKaKAkHOL5oT6MuzOqNLJV+pC+Ehr1YpYuT4A6VscTgg2akMRNr9/PJQS2DS9k0s2P jnhk4ecFPVZdKoiGk7x2xFonSD+e+U9Qn4qZ8jgfgs9K9MJ40BDiVNWGXvKlJ3qWLZnN EFaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712350531; x=1712955331; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=M6hvTDv0V346eQIXs0xg5A+umppjETFzUR5TSF2RGi8=; b=tamM6C+n3o0CfhUf81dplEvKRy9aDiJv//ZeCkn1ZGwzWJXFYvGpR0Fe2BVsuJ4Rtf fy59EDTZeu4uoQBp9KuBxdtzz7eOD2jmQcx/TnR0XfPWiGIABNmxgGojNOUKI5r6Tudq pBfxvoH31cUo3y+WIE8mK+RWtLUCh5unfg0weLVp3OFYhoOoaxPKqGG3UOXMr+j5zN63 rfubQgWAO6yfSJbIxL5t8QALsKPyvpFbqyc5MVFdqNJvaz0njhNve4/+sHS5I2wDGYDQ ckvDAfN2TpAVU88DhicI/c1iTyTMGN6bU3HZ5Xf/8k299FZ42e8+Bqtv8eaQUo2DnIYq 8o4g==
X-Forwarded-Encrypted: i=1; AJvYcCVt9gOayXOwP39vggNFtbR0oYlN+h3jN50rEnspgXzI6vj0NhrpBW/m88ytAhj6D25kzTJq3j5DS1ibwOa3
X-Gm-Message-State: AOJu0Yzz7EBdVWOhtq2jioxc9XyT9Fkw2w9D1LQz14NC/NoSKB0eNvpM W7RxPHSoclMY0yQP7TkdU23jEKegERXBBLZeZK+Kn/GWL1HtoPFI
X-Google-Smtp-Source: AGHT+IEg4F8DC9/Ai6UuKLfjOyamdu+fAfJGoS7DptlLXPmLC2Qon95qsAwKsHMGkF8GarjukhBbHg==
X-Received: by 2002:a17:902:f68c:b0:1e2:23b9:ead3 with SMTP id l12-20020a170902f68c00b001e223b9ead3mr2974625plg.24.1712350530532; Fri, 05 Apr 2024 13:55:30 -0700 (PDT)
Received: from ?IPV6:2404:4400:541d:a600:44b7:2c2e:2bc6:8707? ([2404:4400:541d:a600:44b7:2c2e:2bc6:8707]) by smtp.gmail.com with ESMTPSA id q5-20020a170902c74500b001e2c8f94ce7sm2041795plq.246.2024.04.05.13.55.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 Apr 2024 13:55:30 -0700 (PDT)
Message-ID: <992c1d6d-9143-419d-bf9a-dd6419df962f@gmail.com>
Date: Sat, 06 Apr 2024 09:55:25 +1300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: David Farmer <farmer@umn.edu>
Cc: Ted Lemon <mellon@fugue.com>, ipv6@ietf.org
References: <171225751716.18509.12521562864612372012@ietfa.amsl.com> <a4063219-1cd5-4e06-bf42-b0ffebd2b419@gmail.com> <CAN-Dau3VrqfRR+4Eee7TOS1L2RAWbfWv87_QJH_u5gzVU1Av7g@mail.gmail.com> <CAPt1N1nq9V4H9kq+hf4YO-T6OUdYMv8Vmsd3Vpqf264Jm7mrKg@mail.gmail.com> <CAN-Dau3nh50j6qB2WryL1tM2ktwSntDKX72v8O-_fzNRnu_C4Q@mail.gmail.com> <a1a1d964-949c-48e4-bb6c-462a81402871@gmail.com> <CAN-Dau1izfpYR=jH2DbRmf+h+LWOmACQxa-WeuW_o0ABbsJmPw@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <CAN-Dau1izfpYR=jH2DbRmf+h+LWOmACQxa-WeuW_o0ABbsJmPw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/8Rf75iU0bAA3VlghjJLMzl8xcpA>
Subject: Re: [IPv6] I-D Action: draft-ietf-6man-rfc6724-update-07.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 05 Apr 2024 20:55:32 -0000

On 06-Apr-24 09:15, David Farmer wrote:
> 
> 
> On Fri, Apr 5, 2024 at 2:37 PM Brian E Carpenter <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote:
> 
>     On 06-Apr-24 07:15, David Farmer wrote:
>      > On Fri, Apr 5, 2024 at 9:30 AM Ted Lemon <mellon@fugue.com <mailto:mellon@fugue.com> <mailto:mellon@fugue.com <mailto:mellon@fugue.com>>> wrote:
>     ...
>      >     If constrained devices already support the policy table, I do not think this additional work is onerous.
>      >
>      >
>      > How would the "known-local" ULA prefixes be populated if not dynamically updated from PIOs and RIOs?
> 
>     By the simple fact that a host actually has a ULA. This is the approach I used in three different userland hacks:
> 
>     https://github.com/becarpenter/misc/blob/main/enable_ula.py <https://github.com/becarpenter/misc/blob/main/enable_ula.py>
>     https://github.com/becarpenter/misc/blob/main/gai_wrap.py <https://github.com/becarpenter/misc/blob/main/gai_wrap.py>
>     https://github.com/becarpenter/getapr/ <https://github.com/becarpenter/getapr/>
> 
>          Brian
> 
> 
> That will work for a single ULA network, but how does that work when you merge ULA networks, as discussed in section 4.2 of RFC4193? Do all hosts have to get an address from the other network(s) to know they are local? Somehow, the host needs to know the other ULA networks to treat it as local; otherwise, effectively, you can't merge ULA networks as RFC4193 promises. I envision that coming from ROIs. If not ROIs, what?

Those would be rather strange RIOs, because they would announce a prefix that is in use in some other part of the network, not on the current LAN. In other words, RIOs with A=L=0 (as envisaged by RFC 8028, for a different purpose).

I'm not disagreeing with you, but simply observing that in the simple case, we don't need to explictly rely on RIOs.

    Brian


> 
> Thanks
> -- 
> ===============================================
> David Farmer Email:farmer@umn.edu <mailto:Email%3Afarmer@umn.edu>
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================