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

Kyle Rose <krose@krose.org> Mon, 27 November 2023 16:56 UTC

Return-Path: <krose@krose.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 ACB55C15108B for <ipv6@ietfa.amsl.com>; Mon, 27 Nov 2023 08:56:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, 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, 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 (1024-bit key) header.d=krose.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 RzX4UAqsqD05 for <ipv6@ietfa.amsl.com>; Mon, 27 Nov 2023 08:56:41 -0800 (PST)
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (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 9BA13C14CE45 for <ipv6@ietf.org>; Mon, 27 Nov 2023 08:56:41 -0800 (PST)
Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-a00a9c6f283so603287766b.0 for <ipv6@ietf.org>; Mon, 27 Nov 2023 08:56:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; t=1701104200; x=1701709000; 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=2hYVPinpVxe+C8cxoQBm0Y3Lsga3Q8c098sQsmoGk5s=; b=Q5NGYBUnh3OZiFp/gDUZsKP0J3XLKj3wceeiU9UtDyhsrjljkZRjq3nmWLRFNicG0v B/jr2W7USyGFmlJAIYPiu8Ss63cTKbB5d97Kgk3l9sLpvS/R01q99YY2P947vyKhWSG6 PI5da4ADHDh5MLf3m+Grr/nK3siS9PPOGFW38=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701104200; x=1701709000; 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=2hYVPinpVxe+C8cxoQBm0Y3Lsga3Q8c098sQsmoGk5s=; b=hZehC8jglYmGg0OolcpPCw32rmYGBEYqOe2iYuWJg69ycJSalTZVCGXsSXjWNBAIwd 0/L+n7RnIP1qkNM+dAO4jqnyv5DbJr+FJncWup8pKJNrRgDh1AvIbfvUzZMyIy3Wq+6L ZQ9FVqO2Q87Id7LXPZC4qE05jWUiXvqjr1fqQPCjDytaPq5fnBFa5f/Vc9KKu4prj6Rv Z41s103h0q+g1o/3aEGW3S4ksOyDrxNwPXfWaCXX6rgUckTzZItLY+v62AD6Pvfr4loa pM4148IVdz6VvfUwThOX4FO1kDRAbYORKpbShawwVIZCINpTkr+uoy1K8zpuvqXj9lv+ AMQg==
X-Gm-Message-State: AOJu0YzAkSvHNZjg0VBK1vzXhmZPVsV1V1rt/iasILnTsucm4oVlYlfV qCOm5ecDppshDkvCVH06p669loZ+2N+6gzFqq6/BSA==
X-Google-Smtp-Source: AGHT+IF8xLMQcT8JDGUvDRbd/o9uu3kUo2oZzERuafC5pPar6xy89MFTW8xnLv9SElZUZbprNTncSTt58fIemrBdnAA=
X-Received: by 2002:a17:906:15a:b0:9e4:651f:60cf with SMTP id 26-20020a170906015a00b009e4651f60cfmr8264539ejh.1.1701104199694; Mon, 27 Nov 2023 08:56:39 -0800 (PST)
MIME-Version: 1.0
References: <170059183545.4282.16453796503536671445@ietfa.amsl.com> <CACMsEX_RhsLq1eX5d6m0w93zjLdTNOmuK1-FqVvN3DRCoQkpVQ@mail.gmail.com> <3C840B68-1C34-44C9-9803-7C9468AC98C8@jisc.ac.uk> <CAO42Z2zQORo08vFV34BAKKu+vK6t8GnHLLTSiBUsERNK0zHV8Q@mail.gmail.com> <CAJgLMKuk+_GhymY3cEJvTW+UC=Eo+xtC3dhPVhNkviT1Qg2v4A@mail.gmail.com> <CAJU8_nV4fdXHxGY2zEjW5PLeLjJ6YfU58tJ+PKt8PHQbCfKr-Q@mail.gmail.com> <CAO42Z2xYJsZ+VS0bm6C-idXDOBTdavb6NTAnNbx9SCRfbmgvpw@mail.gmail.com>
In-Reply-To: <CAO42Z2xYJsZ+VS0bm6C-idXDOBTdavb6NTAnNbx9SCRfbmgvpw@mail.gmail.com>
From: Kyle Rose <krose@krose.org>
Date: Mon, 27 Nov 2023 11:56:28 -0500
Message-ID: <CAJU8_nXFisr+hYBPvADkuWPZtKbpcAz7Pd_F4ZJ40=+eBPQR9Q@mail.gmail.com>
To: Mark Smith <markzzzsmith@gmail.com>
Cc: Timothy Winters <tim@qacafe.com>, Tim Chown <Tim.Chown=40jisc.ac.uk@dmarc.ietf.org>, 6man Chairs <6man-chairs@ietf.org>, 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008c8f6e060b252fcc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/2FH06VgoANBfxce5aYJZ8yO0DrA>
Subject: Re: [IPv6] I-D Action: draft-ietf-6man-rfc6724-update-04.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: Mon, 27 Nov 2023 16:56:45 -0000

On Mon, Nov 27, 2023 at 11:46 AM Mark Smith <markzzzsmith@gmail.com> wrote:

> I think more in an enterprise/service provider context and scale by
> default, so for robustness and end-user friendliness (technical and
> non-technical), I would put both ULA and GUA addresses for hosts in
> internal DNS for the same DNS name.
>
> Robustness means if the ULA or GUA address is unreachable, the alternative
> address becomes a fall back.
>
> End-user friendliness means end-users use the same domain name to reach a
> host regardless of if they're internal or external to the network. The less
> end-users have to remember special or different cases the better.
>

All valid justifications for offering both address classes under the same
names, but it occurs to me that what you proposed doesn't actually solve
any problems. The actual issue is the GUA PD changing: no matter what DNS
says, if the GUA prefixes change, connections using those addresses break
and need to be reestablished. If you offer only GUA, that means 100% of
such connections. If you offer ULA in addition to GUA, that means either 0%
are broken (if ULA->ULA is preferred) or 100% are broken (if GUA->GUA is
preferred). Telling operators to deprecate all ULA prefixes when a valid
GUA is available and GUA->GUA is preferred over ULA->ULA does nothing to
improve the situation.

If I misunderstood, then please help me to understand what problem you're
trying to solve with that proposed recommended practice.
Kyle