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

Nick Buraglio <> Mon, 27 November 2023 18:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B3237C14CE4D for <>; Mon, 27 Nov 2023 10:04:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.105
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_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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MTnHD583citR for <>; Mon, 27 Nov 2023 10:04:46 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::830]) (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 92A5AC151081 for <>; Mon, 27 Nov 2023 10:04:09 -0800 (PST)
Received: by with SMTP id d75a77b69052e-41cba6e8e65so23733741cf.2 for <>; Mon, 27 Nov 2023 10:04:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1701108248; x=1701713048;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=oyfAPe1vGXsMYKBsJIs/LDyZ0cPGpOkFn8cdw/vW5bs=; b=da+w8mbdaR+uOIHYd7iaJx4dSSj2XrTOnqTnOCmm3lWOha9BNWEAQD5Xqf/pQ7XQKT 45rAnDH7IfnoYfK0fJhrLYs07F8E3LJM+Pk01jUe/yZMpy9R0Z8lzEGfig0aOTZZsv62 mXAleyo90hddGXMM0ssULdBlIj2HJzkk7gxOM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1701108248; x=1701713048; 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=oyfAPe1vGXsMYKBsJIs/LDyZ0cPGpOkFn8cdw/vW5bs=; b=BJXKmGw8wSnWtW2kYc0TemTaxUkQ28mbBxfcaT56NE0B4uZtLxzynwQATr13Bbk/6N RKOeQPaafxVDKYv6K7PASOxNDXTHfJLbl9KYxokpVy6cw+VF18T+KSLf1E/1PWoQOmgX tBB6IqqHDKuTcwDfNNEfJ4i/lXjOklncK3D86W6U0Tk0ZOHBzETbJ8BGMCjzwAFaW4pH 0+LUh/Wqet8z+mmSmf11oJrndA9AMhzeGExUfWdO7ZpqnS9f0gX3iM5BoneI1UrxVNg6 qkRRDW9gf1BA5tJyrBzNW6nTjeW25si3JXrXgoRKBOUW0iWL+jjIk1aa7IEgWEqJOS/X IYHQ==
X-Gm-Message-State: AOJu0YxwaluV0+kak27vh6gIDQwsNsRs9PPmqGhAevLMYN9UQSVUNFox 997YM0iWmvMqIqOe2t3/mZA8m3cwH9pK2DihyIgYww==
X-Google-Smtp-Source: AGHT+IGJWYRAwiRfT0vU2B3nRx0itsMMJDL9sWeVgu7ATYt2L/Hfx7ib+rNiGiirKo+aN0Mov04AvyLCeY9GsIXvbVc=
X-Received: by 2002:ac8:5882:0:b0:41c:bad9:6045 with SMTP id t2-20020ac85882000000b0041cbad96045mr15642188qta.14.1701108248322; Mon, 27 Nov 2023 10:04:08 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Nick Buraglio <>
Date: Mon, 27 Nov 2023 12:03:56 -0600
Message-ID: <>
To: Mark Smith <>
Cc: Kyle Rose <>, 6man WG <>, Tim Chown <>, 6man Chairs <>
Content-Type: multipart/alternative; boundary="000000000000ddb590060b26207a"
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 18:04:49 -0000

On Mon, Nov 27, 2023 at 11:24 AM Mark Smith <> wrote:

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

This I agree with, there should be a smarter SA/DA selection process and we
should work on that, for sure. This change is far more tactical and
opportunistic. Anything more is a very large lift outside of the scope for
this draft (by design). In whatever this next selection process becomes, it
should appropriately and elegantly address the addressing differences in a
less rigid way allowing for "best value" rather than class based

Circling back to the draft, much of this discussion seems to come down to
how DNS is implemented in a given network, which I strongly believe is a
parallel problem space, and even more subjective than the address selection

Under the proposed model in the update:

* Operator deploys ULA and GUA
** Operator chooses to use split DNS - no problems. All works as designed
internal hosts use ULA, external connections use GUA as those are the only
options presented to them
** Operator uses the same names *internally* for GUA and ULA. Source tries
w/ IPv6 ULA -> ULA first. All works.
** Operator uses different domain names for ULA and GUA on the same server
/ resource. Either user chooses manually or a search domain fills in per
policy. Clients connect as designed.
** Operator puts ULA and GUA in global DNS. - External connectivity will
fail to either GUA or IPv4. I assert this is a broken model and a
misconfiguration and we should not try to policy around edge case
** Operator forces all users to use IPv4/IPv6 literals - all works as
** Operator has only GUA on hosts and only ULA on servers / resources -
works as designed host resolves AAAA and connects from GUA to ULA

Obviously all of these problems are solved by using GUA everywhere, which
for whatever reason may simply not be an option. Perhaps I am
mis-understanding, but I don't believe we should be trying to solve DNS
policy here.

> Regards,
> Mark.
> 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
>> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------