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

Mark Smith <> Mon, 27 November 2023 17:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 18546C151081; Mon, 27 Nov 2023 09:24:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.605
X-Spam-Status: No, score=-6.605 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tHh8yvjjNRW2; Mon, 27 Nov 2023 09:24:53 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::62d]) (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 (Postfix) with ESMTPS id 72FEAC151090; Mon, 27 Nov 2023 09:24:49 -0800 (PST)
Received: by with SMTP id a640c23a62f3a-a00a9c6f283so607516966b.0; Mon, 27 Nov 2023 09:24:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1701105887; x=1701710687;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=3AcBkDyvqCFMrCOJNO9y9k0/w6zxJ8742rnAO0BGLCU=; b=VvjlSsmI9y62nt0TEtjwc7K2p+1xuIXcAsj+D1Q5D42txUcN8xDp1bE4U6i0fp5Tig xHZ5fyNQJFiumZ651QHd2SGSGacHlDkqt96lFHE3FiSIkjSQ3+fm8EURJJMTWAw13vOj 8JuYcwWzMp5jJ3GWqUeluMbren8A2cHaUrKPuCZcFe50Q+G0lyPhaYBCN+cNa2j4HG8A eNNSqJyo5PSJb/Kw6gzT5hAavl89Q6iphQYz2bH5h/tq3D7pw0a8Fc7ISyDNDApmI6Dj zbhZLQl7WDA7M7Z4VIk0aREpLLx8AGR9V5QBIq2hEKVhAffGAGqgEgCSDiRXFosqdZ7f 2SPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1701105887; x=1701710687; 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=3AcBkDyvqCFMrCOJNO9y9k0/w6zxJ8742rnAO0BGLCU=; b=TYCpVasc7DYj9vnEKWBcCcku0gk5md4wKnzcAcMsYV4CBrBnNuCu8mdpwUIczdWSde 4+gCxSOzJxaNLGGsMz7yEfszxi8Qzs7rgqsr8fRu21gS0XXOtMR+/Y1HjbL1gzs3YJpI wy7ixmQXIiANnWmAo1ZM8bEuepOi+23EIHJiU8+sVVIAJr7FO4x0WDrqnyyiwVVK8ZQ/ HNgD3p3jMhBi68j+iDdyXlVdTThhL6KToq+h7OlgZ4DcGrYSoiVi/eIEjaiAxen+hNAX JIBypVZ1Znqlkob90SIhNXBPa5WZd6DR5BpJOs2gAFOPkBcsLDalzyijabhKMjX0NWGn 0Wsw==
X-Gm-Message-State: AOJu0YxBo3hoHJ5LjHhhEnycPEjWfacVbfJ/Erls/q1tCbOQX3vtSk4O S5I6D13zYCC6RebF+vhxT8HuzYOQaD1hNENteu0=
X-Google-Smtp-Source: AGHT+IGrSsTDupb0IUZulARbpvV92kK/MVnH31lQkDHTW4EJk/JDIUw3pytUrMVwykZwu4eyy0WLpwjK2HNQeaMXuDE=
X-Received: by 2002:a17:906:3754:b0:9da:ee00:a023 with SMTP id e20-20020a170906375400b009daee00a023mr8845360ejc.30.1701105886871; Mon, 27 Nov 2023 09:24:46 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Mark Smith <>
Date: Tue, 28 Nov 2023 04:24:37 +1100
Message-ID: <>
To: Kyle Rose <>
Cc: Timothy Winters <>, Tim Chown <>, 6man Chairs <>, 6man WG <>
Content-Type: multipart/alternative; boundary="0000000000001cc4e6060b2594e1"
Archived-At: <>
Subject: Re: [IPv6] I-D Action: draft-ietf-6man-rfc6724-update-04.txt
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Nov 2023 17:24:54 -0000

On Tue, 28 Nov 2023, 03:56 Kyle Rose, <> wrote:

> On Mon, Nov 27, 2023 at 11:46 AM Mark Smith <>
> 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)

Which is why I say ULAs need to be preferred over GUAs

Which is why RFC 4193 implies ULAs are preferred over GUAs.

Which was why site-locals were preferred over GUAs.

or 100% are broken (if GUA->GUA is preferred).

Yes, which is why I have such a big problem with preferring GUAs over ULAs.

If GUAs end up being preferred over ULAs, then I'm going to write up a
draft that ultimately will remove a huge amount of complexity from SA and
DA selection.

- LLAs can only be used for ICMPv6 and DHCPv6, not any applications (sorry

- ULAs are only for private, isolated, non-Internet connected networks such
as IoT networks e.g. electricity smart meter networks.

GUAs are used for networks that are connected to the Internet.

A much simpler model of IPv6 addressing would have saved months of
discussion about this ULA preference update and 100s of emails.

Given some recent IPv6 deployment experiences, it'll also be easier for
people coming from IPv4 to understand.

It would have also likely avoided the issue that RFC 6724 created because
it would have been even more obvious that ULA addresses should not be put
in global DNS, and nor would people now be trying to optimise for an error
case of ULA in global DNS - the only reason to prefer GUA over ULA.

It will also simplify RFCs that have had to deal with multiple candidate
SAs or DAs e.g. ND if I recall correctly.


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