Re: [dns-privacy] [dhcwg] WGLC started -- draft-ietf-homenet-naming-architecture-dhc-options-12

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 05 May 2021 16:36 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C890D3A1832; Wed, 5 May 2021 09:36:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 qrLmE323yqIG; Wed, 5 May 2021 09:36:20 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F93D3A1830; Wed, 5 May 2021 09:36:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 97CCA38EE4; Wed, 5 May 2021 12:44:51 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dRUG4_ppK9oS; Wed, 5 May 2021 12:44:49 -0400 (EDT)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id B23D13956D; Wed, 5 May 2021 11:52:46 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A91388F6; Wed, 5 May 2021 11:44:11 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Bernie Volz \(volz\)" <volz=40cisco.com@dmarc.ietf.org>, "STARK\, BARBARA H" <bs7652@att.com>, "'homenet\@ietf.org'" <homenet@ietf.org>, "'dhcwg\@ietf.org'" <dhcwg@ietf.org>, "'dns-privacy\@ietf.org'" <dns-privacy@ietf.org>, "'int-area\@ietf.org'" <int-area@ietf.org>
In-Reply-To: <BN7PR11MB25479A9DA04F1D961A2A33ADCF599@BN7PR11MB2547.namprd11.prod.outlook.com>
References: <BN7PR11MB25479A9DA04F1D961A2A33ADCF599@BN7PR11MB2547.namprd11.prod.outlook.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: Wed, 05 May 2021 11:44:11 -0400
Message-ID: <8746.1620229451@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/C7nrWWhvkL0sooyGwgZHYe8vmG0>
Subject: Re: [dns-privacy] [dhcwg] WGLC started -- draft-ietf-homenet-naming-architecture-dhc-options-12
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 May 2021 16:36:26 -0000

Bernie Volz \(volz\) <volz=40cisco.com@dmarc.ietf.org> wrote:
    > And, something to ponder: - In 5.3, is there any value in potentially
    > allowing a Relay Agent to supply these options to a server to
    > potentially return to a client via the RSOO option (RFC6422)?
    > I raise this question as it seems no documents have mentioned this and there
    > was a case that recently came up where this was useful for another
    > option, so just want to remind folks that it exists and to consider
    > whether it could be used for these options.

We expect that most of the time, these options will be returned for the
reverse zone at the time that a IPv6 PD is initially done.
(And the rest of the time, it will be because forward zone is *also* configured
by the ISP)

Do Relay Agents delegated PD?  Alas, no.
So I can't see a use case for putting those options there.

One thing that I just thought of, and I don't remember if we discussed it at
all, was whether there was a need to synchonize these returned options with
the IA_PD lifetimes.    I think not: because if the ISP renumbers the end
user (whether a flash number or controlled), then they can also just stop
synchronizing the reverse zone, and that effectively kills the reverse zone
content.   The end user might suffer slightly by having locally served
reverse names that are no longer connected: they should obsolete that zone
when they realize that their PD hasn't been renewed, until such time,
(if it was a flash renumber), they would be right to think that they
legitimately control them.

(I'm still miffed that Relay Agents have to snoof to learn PD, and nobody
seems to think this a problem)

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