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

Mark Smith <> Mon, 27 November 2023 16:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1347BC15108E; Mon, 27 Nov 2023 08:46:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.605
X-Spam-Status: No, score=-1.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_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] 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 xxpCMFERUSIm; Mon, 27 Nov 2023 08:46:06 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::62b]) (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 3E64AC15108A; Mon, 27 Nov 2023 08:46:06 -0800 (PST)
Received: by with SMTP id a640c23a62f3a-a00191363c1so655184166b.0; Mon, 27 Nov 2023 08:46:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1701103564; x=1701708364;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=cM6+Cn2gAkt4paqsXXyieNNUp8301Zn1Rs02USuqtJU=; b=k6k9hNy6mrZ14XMC/O9o3GNiCQiwPCzcPXl8Z28RVarCpjo1R5grvlLS5ak4MUGfv5 u6WNYSEoVqJ0xtYMOh0rSNRuGfJHyjuwkmaiqTZb5BTHecs97f2xT3stwc0FdaGvFKFD tr8VqTQNWpFG9+fu/HGlksyAjHwI/S/VkhQ8eihHZWlKzwbL7kRlygcRPTjVP2YTpONM 9tpF4VUUUTdFbMRdqRM2He8/VnW550iRXzACGCGjdjjKkcHetYGicIJ1+8P+HArprCAf tEDydm96padkmA5mkgucUo3JgSlJlT7yU6r/fP5MQZP+bPPi/UeyQXw9l5zcFsJkqEq+ MGDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1701103564; x=1701708364; 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=cM6+Cn2gAkt4paqsXXyieNNUp8301Zn1Rs02USuqtJU=; b=lxUOhmD4t6UTEYHCEhCtfBcgJfJBA90DqYul4w4LAnj7UdEzNpl03+2BrS+NYsSY19 85KxCRIuffe3VTPEpFIlWxzL9EOmPX21Ar2pnEwFr2KIYR3RmmNqQxCGlpd2ns0IYVky YWfpFUYhmwlAIRLrprl2OPf/5zmvu6XOO50sLzXnx4umbZqnb5vZ7YFzqhpvHpE0YxmS DV33XKm359/8Yx92jgFzVAlzk3Mcd3s54zNDZmJn6alCweq/gRENysqswzM4KG3iIDA1 5mjmuFEgFtU/kON3R0HzJOWL9trJrYMbba345wpxocbCvWjZWDYXYwqKYP+CLiRQj4Bc nY3Q==
X-Gm-Message-State: AOJu0YzXMVl4dOjfL1um6AmPLeYAQuVe37oIwu4fhIRcb7QatoFZld5H /VsiTGlN/XYvpyIM75yluVNudVopxnAQN539Do8=
X-Google-Smtp-Source: AGHT+IFRJkCp//H0F11be+etDYi2xBXLhL/kX22uKy+/95erP8MuSYuSESf7yMtDepW+Pqygf7p7kyv8k5nwko2i4dc=
X-Received: by 2002:a17:906:2d3:b0:a0c:582a:c5ad with SMTP id 19-20020a17090602d300b00a0c582ac5admr3941827ejk.77.1701103563641; Mon, 27 Nov 2023 08:46:03 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Mark Smith <>
Date: Tue, 28 Nov 2023 03:45:53 +1100
Message-ID: <>
To: Kyle Rose <>
Cc: Timothy Winters <>, Tim Chown <>, 6man Chairs <>, 6man WG <>
Content-Type: multipart/alternative; boundary="000000000000a3170e060b2509af"
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 16:46:07 -0000

On Tue, 28 Nov 2023, 02:58 Kyle Rose, <> wrote:

> I never got around to responding to Mark, so thanks for reminding me.
> Because I strongly disagree with this:
>> If it's going to put ULAs below GUAs, then both RFC 4193 (ULA RFC) and
>>> RFC 7084 (IPv6 CE (CPE) RFC) need to be updated by this draft. I don't
>>> agree with that preference of ULA below GUAs, however if that is going
>>> to be the WG's consensus, then the consequences are greater than just
>>> an update to RFC 6724.
>>> RFC 4193:
>>> The following advice and use cases need to be updated/negated/removed,
>>> as if a local network's hosts have both GUA and ULA addresses, and
>>> they're provided to a local network host via DNS, such as via
>>> multicast DNS in RFC 7084, then the ULA addresses will never be used,
>>> because the GUA addresses are preferred, making renumbering GUA
>>> prefixes impossible without disrupting local network communications.
>>> Consequently, it would be best if ULA addressing wasn't be deployed if
>>> a network has GUA addressing, or ULA addressing should be deprecated
>>> when GUA addressing is deployed, with the benefit being saving on
>>> router and host processing of an address space that is unlikely to
>>> ever be used.
>> ...
>> ULA requirements:
>>> ULA-6:
>>> "A CE SHOULD deprecate any ULA prefixes it is announcing when it
>>> commences providing GUA addressing to hosts, by announcing its ULA
>>> prefixes with a Preferred Lifetime of zero seconds, and a decrementing
>>> Valid Lifetime, and then cease announcing its ULA prefixes when the
>>> Valid Lifetime reaches zero seconds.
>>> Should a GUA address space become unavailable, the CE's ULA address
>>> space again be announced with the CE's ULA appropriate Preferred and
>>> Valid Lifetimes."
> I deploy multi-prefix, one provider-delegated GUA and one ULA, to all of
> my v6 clients via RA. I specifically don't have any hostnames with both ULA
> and GUA AAAA records to avoid the problem Mark is pointing out: internal
> services are on their own subdomain that maps exclusively to ULA and 1918
> addresses.

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.

This also goes to what I've always understood split DNS to be - you don't
need internal and external DNS names for hosts, with split DNS you set up
internal and external DNS zones that provide different answers for the same
DNS names, with the answer returned depending on if the DNS query comes
from an internal or external host.

It used to be you needed to setup different authoritative DNS servers for
the internal or external versions of the DNS zone, however BIND has been
able to do that on the same server with DNS views based on query source IP
address for at least the last 15 years.


I *want* both address schemes simultaneously in parallel, specifically so I
> can avoid the need to change DNS entries when my provider decides I've had
> a PD for too long and capriciously changes it. This scheme has been working
> great for me for 5 years, in part because the Debian gai.conf doesn't
> comply with 3484 or 6724 and (correctly, IMO) prefers ULA to IPv4. (Someone
> "fixed the glitch".)
> Kyle