RFC6724-bis?

Tim Chown <tjc.ietf@gmail.com> Tue, 20 September 2022 16:06 UTC

Return-Path: <tjc.ietf@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 3B3E4C14F728 for <ipv6@ietfa.amsl.com>; Tue, 20 Sep 2022 09:06:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=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 vCFkaXx19vAI for <ipv6@ietfa.amsl.com>; Tue, 20 Sep 2022 09:06:49 -0700 (PDT)
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 A38DDC14F5E1 for <ipv6@ietf.org>; Tue, 20 Sep 2022 09:06:49 -0700 (PDT)
Received: by mail-wm1-x32e.google.com with SMTP id d12-20020a05600c3acc00b003b4c12e47f3so1987059wms.4 for <ipv6@ietf.org>; Tue, 20 Sep 2022 09:06:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:cc:date:message-id:subject:mime-version :content-transfer-encoding:from:from:to:cc:subject:date; bh=4YwISF+2l+qTC2UkQCJRj0MoBmPJhtYOKqwf/v2LlMo=; b=K/BI883255t7cd4ji2G2smHyIp57IUwnKjKu2beGzBXulmJC1814RV8IDKKpzxS3DN EJRE1pp653nVMpJBRS1j4RULl+ZGvGr6o6Zh+sM7iFXr5SQv73sHhRZsUlipdwmUZ6Xp ZPgPvHnY0PfBM2gW6r3SA65RadtXFaWUNwRunIUROA0dqNoYo9bBDAcSvGVBK/LHty4E f4MTMfowJ6U1dwJaJfcQ0a4HmfLnM0BvfEelJZKynQKv5F3tuBkbvyAmXLGVm3mXmCll hb9eQIt+kK0ptPB3rMcqteyfn1ppnR0cxBj+Ff+yGaOLF5eekfs9gIu4/iA129lg9ID6 52hg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:cc:date:message-id:subject:mime-version :content-transfer-encoding:from:x-gm-message-state:from:to:cc :subject:date; bh=4YwISF+2l+qTC2UkQCJRj0MoBmPJhtYOKqwf/v2LlMo=; b=wsw5AFl4qiwS/g8FpWJEKNbLAtb7Oeko25Gxxuat8dIg0lhDS8/H5lzDN8jULm2WOF 1lNEkdeGaiPHoXzK5k8GRyyNXMRaK5/ohN35O3ie4YCQ4I4x+48S1iWea7qcOz+lkcz+ CXtjJvB8BarilsB5xo1k+BO3gi6BOHM+MKs2oadUJpxK+nA1CNQLkdrQgW/CicxgQIkU IZQLiVKMq70Jn1fbkvyPUk5mYrwLYNpdIuZjRo0/aRy3XpNZMmIGHQ58rxX4VgMb/JwJ sw0GPIjaiFIWS83pIE3lAmtnfZmoRfhSKCvEUghuTui84Z8I71vp4NRAMObw3YMf4uiU yElw==
X-Gm-Message-State: ACrzQf0v3oNCa1R9wkmCD9F2XfyPEV/AVumJrdv5Wkm9yTDDwOY60gvk LbbiVr1v6SBXF1KjFTKNucCKvjw0IK8=
X-Google-Smtp-Source: AMsMyM7BXs12lmjV3ms6jlClh9DKjzqp2m8q761sek+RywC7SFqbjP2hp74mmS/ovhnLYX2HD8BM9A==
X-Received: by 2002:a05:600c:2f9a:b0:3b4:9bd5:1472 with SMTP id t26-20020a05600c2f9a00b003b49bd51472mr2973483wmn.171.1663690007509; Tue, 20 Sep 2022 09:06:47 -0700 (PDT)
Received: from smtpclient.apple ([2001:a88:d510:1101:b9c1:f62b:39a8:414b]) by smtp.gmail.com with ESMTPSA id fc7-20020a05600c524700b003b47ff3807fsm395878wmb.5.2022.09.20.09.06.46 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Sep 2022 09:06:47 -0700 (PDT)
From: Tim Chown <tjc.ietf@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Subject: RFC6724-bis?
Message-Id: <66892DC8-6DA4-4DC8-85B0-E1E1647CD9F7@gmail.com>
Date: Tue, 20 Sep 2022 17:06:45 +0100
To: ipv6@ietf.org
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/tGYV3jeKDOKH-BcQu7uRXIJcaY8>
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: Tue, 20 Sep 2022 16:06:50 -0000

Hi,

As an author of RFC6724 I’ve had the discussions about a possible update of RFC6724 brought to my attention.

An example thread over on v6ops is https://mailarchive.ietf.org/arch/msg/v6ops/W6HjHc11JX364soq3t3gFMHSawE/, but there are others.

Nick Buraglio has documented the problem in draft-ietf-v6ops-ula-00.  The short of it is that RFC1918 IPv4 addresses may be preferred to IPv6 ULAs in certain circumstances, which I would agree is not desired behaviour.

There are a few ways we might look to address this.  There is a proposal from Nick (not yet published outside a git repo) to address it by changing wording in section 2.1, with a couple of MAYs becoming MUSTs, and adding an extra explaining paragraph.  This basically firms up the requirement to follow 6.10 on adding an extra precedence line for local ULA prefix(es).

Now, that may or may not be the preferred solution of the WG, but I think there’s a few questions to consider:

1. Is there agreement we should address the problem?  I’d assume so because Nick's problem draft was adopted by v6ops.

2. If so, is 6man the place to do it?  I think it has to be.  RFC6724 was born here.

3. How do we determine the best solution to the problem?  I suspect there are nuances in play that will make a one size fit all ’simple’ fix tricky, but I look forward to the discussion.  Nick has one proposal that counts to a couple of word changes and an extra paragraph, which I’d encourage him to share here, but there are other approaches proposed on v6ops.  I think either way, it will require some update to or for RFC6724.

4. Does this work warrant a full -bis or would a separate RFC that updates 6724 be better?  A separate Updating draft might better highlight the issue to implementors.  But then RFC6724 is now ten years old, and RFC3484 which it replaced was nine years before that.

5. If we choose to open up a full -bis, are there any other worms in this can?  I have a feeling also here I know the likely answer….

Anyway, over to the WG… thoughts?

Tim