Re: [IPv6] Second Working Group Last Call for <draft-ietf-6man-rfc6724-update>

Ole Troan <otroan@employees.org> Mon, 15 April 2024 08:06 UTC

Return-Path: <otroan@employees.org>
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 282A0C14F71A for <ipv6@ietfa.amsl.com>; Mon, 15 Apr 2024 01:06:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=employees.org
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 PSZfRVyn6rjl for <ipv6@ietfa.amsl.com>; Mon, 15 Apr 2024 01:06:08 -0700 (PDT)
Received: from proxmox01.kjsl.com (proxmox01.kjsl.com [IPv6:2607:7c80:54:6::6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 5CFE7C14F712 for <ipv6@ietf.org>; Mon, 15 Apr 2024 01:06:08 -0700 (PDT)
Received: from proxmox01.kjsl.com (localhost.localdomain [127.0.0.1]) by proxmox01.kjsl.com (Proxmox) with ESMTP id D951DE2582; Mon, 15 Apr 2024 08:06:07 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=employees.org; h=cc:cc:content-transfer-encoding:content-type:content-type :date:from:from:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=prox2023; bh=9oqbtytFSGZJJ6j4 HkJi8gtA3ytvQlP/yMNreJKWui4=; b=Kd8diiKJxTJdHxLiGWUFx83arbtsYkkL jXATbN4eZ2BcLDliMBOrxhGnOiW4DTVOSlpJJMMXurYAF/tuY755iZDx46fJ9MlM UgFp4AldlhTZXZ9C/h5hie4NBq7KaK40mVKdvxKnEdFgbs7M8sHsDm/9Zi7hkNou zxgzz7ESGfSDHG3z+lwc/ngkoTDJ/cIdtoxlfvmnqEMDl4xKK9IhlzasBb8wf0mn jhPS1OSgOUfiG9tsIrhws7jf3XQ4Ar4PYf7nuLZCzkh68EiCmOMQt0ypdHoaaEmO /ZtCrwuhIsUmLcFbDe8HgmWt8ye9VqqnXmWDcOPxjZ95d9LbkQdxhA==
Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by proxmox01.kjsl.com (Proxmox) with ESMTPS id B6334E255D; Mon, 15 Apr 2024 08:06:07 +0000 (UTC)
Received: from smtpclient.apple (unknown [IPv6:2a02:2121:6a7:73c:44d8:afa1:6140:7a9a]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 92A7D4E13E5F; Mon, 15 Apr 2024 08:06:06 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <CAKD1Yr1NTvFj0zB0=+nnUKck7TBtwHFz2XoFkD1smx4yCuZohQ@mail.gmail.com>
Date: Mon, 15 Apr 2024 10:05:54 +0200
Cc: Ted Lemon <mellon@fugue.com>, Bob Hinden <bob.hinden@gmail.com>, 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1EFB11CD-544F-4AD7-B414-6A626075975D@employees.org>
References: <6A5E5F35-B35F-4358-8EE1-3BD82329141E@jisc.ac.uk> <6FBC1B5A-BF28-4B05-B2B2-A60DA4707755@gmail.com> <CAPt1N1m-Ye8vfOVnsPesFshLMV5QuVoxWqM=HVZiJ37zaBg6AA@mail.gmail.com> <CAKD1Yr1NTvFj0zB0=+nnUKck7TBtwHFz2XoFkD1smx4yCuZohQ@mail.gmail.com>
To: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3774.500.171.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/VXSYy0xYZn-jtgq336_MOcfnh4M>
Subject: Re: [IPv6] Second Working Group Last Call for <draft-ietf-6man-rfc6724-update>
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: Mon, 15 Apr 2024 08:06:12 -0000


> On 11 Apr 2024, at 05:30, Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org> wrote:
> 
> On Thu, Apr 11, 2024 at 1:04 AM Ted Lemon <mellon@fugue.com> wrote:
> I continue to think that section 3,  "Operational Issues Regarding Preference for IPv4 addresses over ULAs," should make the new proposed ULA behavior mandatory rather than optional. I don't see a downside to making it mandatory. Hosts will come into compliance when they can; older implementations will not implement this new behavior, but I don't see any point in perpetuating that.
> 
> Absolutely agree. This document should not proceed without that MUST. Preferring non-local ULA over IPv4 is incorrect because IPv4 implies global reachability, and ULA does not offer global reachability. So publishing this document without the MUST is harmful: an implementation that does not implement the SHOULD will cause regressions and break use cases that work today.

A host should not make those assumptions.
A RFC1918 IPv4 address may or may not have global reachability.
A ULA may (or may not) have global reachability.

In essence SA/DA combination can be assumed to provide reachability. It has to be probed.
The _only_ thing SAS/DAS selection should be used for is ordering of the candidate list.

> Also, MUST allows us to make ULA more useful than it is today. It is *desirable* to be able to publish non-local ULAs and have hosts know what is local and what is not. As a simple example: once all hosts implement the MUST, it will be safe to publish local ULAs in the global DNS, because hosts won't try to use them unless they are local.

That’s likely a simplification. As they are certainly going to be networks where there will not be possible to signal all ULA prefixes to every host.
The IETF conviction that as long as we make something a MUST then every implementor will implement it is flawed. The only thing it does is to water out the value of the MUST. Any MUST/SHOULD debate motivated by this (as opposed to a real interoperability breaking issue) is bike-shedding.

O.