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

Kyle Rose <> Mon, 27 November 2023 19:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C4D9BC15109E for <>; Mon, 27 Nov 2023 11:20:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Status: No, score=-7.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, 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, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j3uYib-eWMah for <>; Mon, 27 Nov 2023 11:20:43 -0800 (PST)
Received: from ( [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 (Postfix) with ESMTPS id BE143C151096 for <>; Mon, 27 Nov 2023 11:20:43 -0800 (PST)
Received: by with SMTP id a640c23a62f3a-a03a900956dso878737466b.1 for <>; Mon, 27 Nov 2023 11:20:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1701112842; x=1701717642;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=srG1dmQPbD9C5Wza3P4tYs6yVOW/P9uOSSzaS3Ejr4s=; b=S/HPPaB1H/DhhJY0feGpVNNugfiCxzIa23E+K39NBZjDa3hByuj3SY0wER0iA1uk4W aKi7pszEmzVn58Sq2NONspCHBJvknxxsbJ8++XoRxXeJG8vD26xBvGHf0X8sbcIVPBzW eiOxnvNbsCEw31Dr/qJf5xOKxXCEEi9EMaJsw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1701112842; x=1701717642; 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=srG1dmQPbD9C5Wza3P4tYs6yVOW/P9uOSSzaS3Ejr4s=; b=PAQ217khqJ3F0sLdip9y6bopeIHmY9J5uyOZSvRSP8ot7Q3Paf6BBbCtY6CKp8TQJW wTcjoeF2nujRm/Q6NI2ltm5ytDQmuAP4oT98IdKrS1d8hpU0U6jatJSbWNXDvFGLc9Qq S1HYQ6XNiNnVTsQfdizM6I+GEHE+xQT5Ra3lYiJLjz1Ln/nZqMhF+QYg6AH/2In55AUs XuGv97vhVaVH6ZJdjHGoS7+SGkcc0Siu3s2OcywB2WP9AnRjukWnsizmgmbXBqfMRyVO BrcMi3SbWKkalL07k7Iwz0eoqc7sPGdv6EpaWvm80+LO5MbggBYPII/tswfUAE9aJlsj 4bdg==
X-Gm-Message-State: AOJu0YxFezXI1FdFrm+zmA7IPy6BnV7ZE8lnE165OZb4HMARbsWeQsLf mM7glu0cFYGGGfKTvAtdo680yys7jrIRrJA4ItlS7Q==
X-Google-Smtp-Source: AGHT+IEFAzwkSS31hlkNWOtZRRDCG++MgnGh2AgRAyREBQD4/+PUFiVFH4OyfQIAiLuvfe7CdIT56jagzH0E2PuG7eA=
X-Received: by 2002:a17:907:2d88:b0:a00:76b1:7d9a with SMTP id gt8-20020a1709072d8800b00a0076b17d9amr15226541ejc.38.1701112841839; Mon, 27 Nov 2023 11:20:41 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Kyle Rose <>
Date: Mon, 27 Nov 2023 14:20:30 -0500
Message-ID: <>
To: Mark Smith <>
Cc: Timothy Winters <>, Tim Chown <>, 6man Chairs <>, 6man WG <>
Content-Type: multipart/alternative; boundary="000000000000a936a3060b2732d9"
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 19:20:47 -0000

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.

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