Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt)

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 07 January 2021 16:03 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2DC3A12C0; Thu, 7 Jan 2021 08:03:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bicmG910BXzH; Thu, 7 Jan 2021 08:03:07 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0B593A12AE; Thu, 7 Jan 2021 08:03:05 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 294EB389B1; Thu, 7 Jan 2021 11:04:14 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id v9VENTIA8t2c; Thu, 7 Jan 2021 11:04:13 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id B013A389B0; Thu, 7 Jan 2021 11:04:13 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 99BB864F; Thu, 7 Jan 2021 11:03:03 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Ted Lemon <mellon@fugue.com>, IPv6 Operations <v6ops@ietf.org>, IPv6 List <ipv6@ietf.org>
Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt)
In-Reply-To: <BE6C041F-94B2-400D-B114-A76962190660@fugue.com>
References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <m1kx98E-0000EhC@stereo.hq.phicoh.net> <b53b5d62-0334-f791-f56a-f2122767ecdb@si6networks.com> <m1kxAVC-0000KhC@stereo.hq.phicoh.net> <CAHL_VyD85e9=taY1XENf7hc=BXRyD_7JJFDCW2Oq_a0z3hYqUA@mail.gmail.com> <bc29edad-b57b-bb53-141b-8f58c5ca2526@si6networks.com> <91424EEE-EF12-4B5B-ADE4-38230E049290@isc.org> <m1kxTmy-0000KhC@stereo.hq.phicoh.net> <6F3726EE-F089-4F26-BB30-F22686617C03@fugue.com> <m1kxWh9-0000ImC@stereo.hq.phicoh.net> <BE6C041F-94B2-400D-B114-A76962190660@fugue.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Thu, 07 Jan 2021 11:03:03 -0500
Message-ID: <21510.1610035383@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/AoflnwvR2KABotI5bN_du3_z_mQ>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jan 2021 16:03:15 -0000

Ted Lemon <mellon@fugue.com> wrote:
    > On Jan 7, 2021, at 9:55 AM, Philip Homburg <pch-ipv6-ietf-7@u-1.phicoh.com> wrote:
    >> I can see a few benefits of Mark's proposal. One is that it is good to
    >> have a standard representation of information. In particular,
    >> Mark's proposal would make it possible to have a master zone file that has
    >> both public and private DNS entries. Then a split-DNS server could serve
    >> only the public data to the outside world.

    > That’s a good point, although it would still be a good point if this
    > were just a feature of the zone file and not of the wire format.

No, it has to get into the wire format, and it has to be cachable on the
client, and it has to evaluated on the client as close to the application as
possible.

Why? because caching is good, and throwing away your cache each time you have
a link up/down is dumb in my opinion.

Having said that, I think it's mostly too late to make a change like this.
Convince me wrong with deployed code :-)

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide