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

Ted Lemon <mellon@fugue.com> Mon, 15 April 2024 13:02 UTC

Return-Path: <mellon@fugue.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 BE2B3C14F71E for <ipv6@ietfa.amsl.com>; Mon, 15 Apr 2024 06:02:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20230601.gappssmtp.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 hSKnuYjjn0o9 for <ipv6@ietfa.amsl.com>; Mon, 15 Apr 2024 06:02:29 -0700 (PDT)
Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 CB91FC14F680 for <ipv6@ietf.org>; Mon, 15 Apr 2024 06:02:29 -0700 (PDT)
Received: by mail-qv1-xf2b.google.com with SMTP id 6a1803df08f44-69b5ece41dfso8184876d6.2 for <ipv6@ietf.org>; Mon, 15 Apr 2024 06:02:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20230601.gappssmtp.com; s=20230601; t=1713186148; x=1713790948; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ysEzCkPZa/Ao9I68sIaU1s04CuvipuoB3Ln2yrFAbNU=; b=F2PhQF7m2cxi/jCBgkTJz9P4lV8zrczsEoBXwKNBIT7jG4zVR1jvQz6170KISss2Hf 3evAUdGz+HwBACKMSW18oy9lt0+V1hzNMFS3Dtw5C8ozV5lQtTB97mRfsZWTd2nYjB5p hJ1Bwm3VgCme3Fv604WSNuVm0Z9A9hXhNOdXLBRJGgKfsbSd+4FkmmWxEnOLG/xWJY9f eBZuA5bWNq9bz3Ms2aZ/mWpJwz1xHVJDQHrh/xxp9FD3cYNTOFvB2HxitKjXn9MgY05t C2vVE7gIjFWiQ+BJOsYXfUYKMwJTycaacKkaHN8mh6nenrF+2L8bzfrOTNGjz/Raclwj TStA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713186148; x=1713790948; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ysEzCkPZa/Ao9I68sIaU1s04CuvipuoB3Ln2yrFAbNU=; b=DRpHhP2dGFBujPn2Q0Nuv85oYvMP54WFvEUM4d99GxdKrm/ZngEnlgYZZNaoCyoLVX p5jvOEBFrZe6uBmncEeMvjHuBaYpWrPEJs7tpPbrIMWproWcegoAKmCnhTr/RM4mcJ73 5VtmsGni48KTb2z26MhkWtUwtIQkGwbWpj1m+vwkEuPtl01OyvoZYBYBPt34gXJnIo5I ufFo1yeTDuEjkVsxirKydBAFg2YUen5C/BrZgbpdneLUwXyosYUwJtuMA510x4Vj3IFH jlSMaqcm8wsotHCgEnoval2eDs+sFkY9QxULNyUPXFAImm4HOyPVK+q8e22A7O2vHjGO HK5w==
X-Gm-Message-State: AOJu0YxWI4xSU2waGLRqvWvXLY8CU3JmboFfYxfOAEpC4guCKw7kbr5g MUAurutVGLd89pKuTl+lO3aLJQrgKN7Xe4JtsNhasEo0gb2+evrAJ463d6PcY8G+hC86vf6TDIz ybdAXAtw+VujWeLt8Ut7f4lTa1f0cTZRPEcm2dRFwbrpW5YPD
X-Google-Smtp-Source: AGHT+IEENKOdJ1PnLfmSB7j9GhWufPVNh7aQCQTLOIVjdwppuRFcEB7vn8jdoUraagXcjPLb5gdKhLXRiWSZw1ZSq6o=
X-Received: by 2002:ad4:4050:0:b0:69b:59c1:f259 with SMTP id r16-20020ad44050000000b0069b59c1f259mr9403102qvp.17.1713186148280; Mon, 15 Apr 2024 06:02:28 -0700 (PDT)
MIME-Version: 1.0
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> <1EFB11CD-544F-4AD7-B414-6A626075975D@employees.org>
In-Reply-To: <1EFB11CD-544F-4AD7-B414-6A626075975D@employees.org>
From: Ted Lemon <mellon@fugue.com>
Date: Mon, 15 Apr 2024 09:02:17 -0400
Message-ID: <CAPt1N1kJFgu6FhFaVhhkPnEY2dofcLF2ZuKDBHJFF5UU6R+x2g@mail.gmail.com>
To: Ole Troan <otroan@employees.org>
Cc: 6man WG <ipv6@ietf.org>, Bob Hinden <bob.hinden@gmail.com>, Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000cd8fdf0616223b6a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Es60RydKf3mPsoG8z8W8yCVkVtk>
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 13:02:37 -0000

What should says is the the behavior is not optional—we don’t think there
is a good reason for an implementation not to do the behavior.  Which is
true here.

It’s also true, as you say, that not all prefixes will be identifiable as
local in all cases.  In these cases, we will get the old behavior, which
works well enough.

Op ma 15 apr 2024 om 04:06 schreef Ole Troan <otroan@employees.org>

>
>
> > 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.
>