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

Mark Smith <> Tue, 28 November 2023 00:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 46F21C15108F; Mon, 27 Nov 2023 16:29:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.603
X-Spam-Status: No, score=-1.603 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, 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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2WRviZqvgk7V; Mon, 27 Nov 2023 16:29:16 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::52e]) (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 1E5FBC151536; Mon, 27 Nov 2023 16:29:15 -0800 (PST)
Received: by with SMTP id 4fb4d7f45d1cf-5441305cbd1so6358860a12.2; Mon, 27 Nov 2023 16:29:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1701131353; x=1701736153;; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=/ylHZJaUujrmONi+/RN9pdPY1y8asANrVkV6WyxqcHk=; b=kaAGSE8SMSmmV3QWuKLPt1geEWOVUMZTl24LQbR30kBU42GDC+1kcH1amo1HRIPuYy RQNYj+/oQIu8o66ukCyCTlnLfH982y+MjDCNSSaXjyoQ7iZpOu46axMNfzrpm3zQTV6J t7j8enO+s4do5qZbEm2syH0k3ouGomYGOHhdu8YCfMPN5qjiN+it1sYS5UcCF4N97RfZ h1p9aJETqeb/YdHC+tRXFa3hhWM/QJMlgACsstNAmxhrdM17luIQuXwsodRBsOT0DySA yog9rcrSW9KmAPZ7B9d9aMdMQjJ3S+FUL9TW0suqrDsPVMnJQu/nSDV4j1gXve8LxBPX bhQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1701131353; x=1701736153; h=content-transfer-encoding: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=/ylHZJaUujrmONi+/RN9pdPY1y8asANrVkV6WyxqcHk=; b=xETkOa4l/ktTMn9h0CAYFSIFt3HlBp7TZ74zwhbbfE27EROBsHr6sOvPuyMFh7mWFH cr8YXKbldwhD+jYQu8ioTL7WnNJLpgtp8TsZzz5hSE1/ndjP7d5fMteOV/+cOy4Q+ZC8 RnHbIOUSuOr2EJh1jT5Tkx+5u5VHFao+tVef6+i9LYjMGx3KgsbJckUXQhv+QT09wPjY bFpsiTetdZv3ov5lidDk7ER1Bnvc+48YZ8slU3sOhbn+PsdSr07DcKvcUKFLk02SMM7n 6F3//PJbYagqE1hXNyOUSRuo4RAO7hDz6u6zMJbmuFq8pwhs9vWt3SSGbynhNiShps9W 0PKQ==
X-Gm-Message-State: AOJu0YxHRd/lmQKgXWuR9plw2xA4PSUgWMmm0SlqhejuyYIPa8o1hYa2 wDxL0pAh3Uw2g8Rrk21LNuwz8+ZvM3MzWV7zMbBaCVuUlak=
X-Google-Smtp-Source: AGHT+IHiGxTgVabnE8YUSaE7UElKC2SDitWxwVwWK1MAo9r73gxiqWjtt+VLxtGoRDw0M06sPaL4VQG7c8MfxREJCPI=
X-Received: by 2002:a17:906:530b:b0:a0b:d4f4:ef0f with SMTP id h11-20020a170906530b00b00a0bd4f4ef0fmr6714109ejo.43.1701131353369; Mon, 27 Nov 2023 16:29:13 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Mark Smith <>
Date: Tue, 28 Nov 2023 11:28:46 +1100
Message-ID: <>
To: Kyle Rose <>
Cc: Timothy Winters <>, Tim Chown <>, 6man Chairs <>, 6man WG <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Tue, 28 Nov 2023 00:29:21 -0000

On Tue, 28 Nov 2023 at 06:20, Kyle Rose <> wrote:
> On Mon, Nov 27, 2023 at 12:24 PM Mark Smith <> wrote:
>>> or 100% are broken (if GUA->GUA is preferred).
>> Yes, which is why I have such a big problem with preferring GUAs over ULAs.
> That's fine, and a good discussion point.
>> 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 Dentists).
>> - ULAs are only for private, isolated, non-Internet connected networks such as IoT networks e.g. electricity smart meter networks.
> This doesn't follow at all. If rough consensus has it that GUA > ULA > IPv4, then if the implications of combined GUA/ULA multi-prefix bother you, then just don't deploy ULAs. I don't see why you need to normatively recommend that others do the same.

Well I normally wouldn't in particular since I'm the author of this
blog article on how to get ULA deployments right (apparently the most
read IPv6 article in 2020, and at least 137 people have read it
because that's how many ratings of it there are. I'll have to update
it if it ends up being incorrect after this RFC 6724 update.)

However, if default address selection requires a very specific DNS
deployment models to work (either different internal and external DNS
names, or ULA only addresses for internal versions of names, and GUA
only addresses for the external versions of names), tightly coupling
the operation of default address selection to DNS configuration and
operation, then I'd much rather people not be mislead about a level of
independence between what DNS/getaddrinfo() returns, and it is hosts'
responsibility to deal with unreachable DAs, that both RFC 3484/6724
and RFC 4193 currently imply.

If default address selection relies on specific DNS deployment models,
then that must be documented in the default address selection RFC.

Ultimately it seems people think it is possible for default address
selection to return the first DA in the set that always works. I know
that it is impossible because packet switched networks don't and can't
make an assurance that a DA is always reachable. An unreachable DA,
provided via DNS, is really just a form of transient packet loss.

I'm happy for the any of the DA returned by default address selection
to work most but not all of the time, and then use the traditional
timeout and reattempt model to deal with the occasional failures,
which is also the advice in RFC 6724:

   Well-behaved applications SHOULD NOT simply use the first address
   returned from an API such as getaddrinfo() and then give up if it
   fails.  For many applications, it is appropriate to iterate through
   the list of addresses returned from getaddrinfo() until a working
   address is found.  For other applications, it might be appropriate to
   try multiple addresses in parallel (e.g., with some small delay in
   between) and use the first one to succeed.

> I honestly can't imagine a series of events in which any such proposal wouldn't be DOA, so I frankly wouldn't even bother. Or write an informational draft and send it to the ISE.
>> 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.
> I agree on the latter point, which is why I don't have much preference either way. Nonetheless, these kinds of misconfigurations are a "you can lead a horse to water" situation: as long as there have been standards, people have violated them, sometimes in error, sometimes out of ignorance, and sometimes intentionally.

One interpretation I have for the second part of Postel's law (be
liberal in what you accept) is to tolerate, up to a point, operational
failures and misconfiguration in the interests of trying to provide
useful connectivity when possible.

The "Well-behaved applications SHOULD NOT simply use the first address
returned from an API such as getaddrinfo() and then give up if it
fails. ..." text is a manifestation of that.

I think expecting the first DA returned by default address selection
to work 100% of the time is not being liberal with what you accept,
and denying the reality of packet switched networks never being able
to assure 100% the reachability of any particular DA (because a host
could fail a moment before the packet arrives at the DA - the DA
became unreachable while the packet was in-flight.)


> My starting point with most of them is just not to make any concession to easily-fixed errors and instead try to make the errors obvious so implementors fix them. (The end point is something like GREASE.)
> Kyle