IETF Logo Mail Archive

Re: [dhcwg] RFC 8925 on IPv6-Only Preferred Option for DHCPv4

Michael Richardson <mcr@sandelman.ca> Mon, 26 October 2020 11:08 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 094B13A00DB for <dhcwg@ietfa.amsl.com>; Mon, 26 Oct 2020 04:08:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 GQVfXThlMIQ9 for <dhcwg@ietfa.amsl.com>; Mon, 26 Oct 2020 04:08:01 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 880913A00E0 for <dhcwg@ietf.org>; Mon, 26 Oct 2020 04:08:01 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id DD76D389CC; Mon, 26 Oct 2020 07:14:33 -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 HOUoOdF2hbTZ; Mon, 26 Oct 2020 07:14:33 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8450A389CB; Mon, 26 Oct 2020 07:14:33 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5CB754BB; Mon, 26 Oct 2020 07:07:59 -0400 (EDT)
From: Michael Richardson <mcr@sandelman.ca>
To: Roy Marples <roy=40marples.name@dmarc.ietf.org>, dhcwg@ietf.org
In-Reply-To: <CAKD1Yr0j7ip7axs8Mu_jr23aj28fR5pWADSa1knPR4hVrMbo9g@mail.gmail.com>
References: <20201017125300.02DF3F40710@rfc-editor.org> <e935457a-eb2c-93a6-6ffe-959d7e358f17@marples.name> <CAKD1Yr0j7ip7axs8Mu_jr23aj28fR5pWADSa1knPR4hVrMbo9g@mail.gmail.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: Mon, 26 Oct 2020 07:07:59 -0400
Message-ID: <20765.1603710479@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/c_rUnRKH2vp_LdLrO6IiAqAtp48>
Subject: Re: [dhcwg] RFC 8925 on IPv6-Only Preferred Option for DHCPv4
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Oct 2020 11:08:03 -0000

Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org> wrote:
    >> Am I correct in thinking that RENEWING and REBINDING states pretty
    >> much ignore this option if it was absent and is now present? Or is the
    >> intent to stop using the address when in these states as they are
    >> "DHCPv6 reconfiguaration events"?  Or just wait until it naturally
    >> expires? It's not clear what the expected action here should be.

    > I think this is documented in the text that you quoted above. If the
    > client is in RENEWING or REBINDING, it SHOULD continue to use the
    > assigned IPv4 address. That means accept the DHCPACK, continue to use
    > the address, and later, when the appropriate timers fire, enter
    > RENEWING and REBINDING as specified by RFC 2131.

and if an operator wanted to prevent the node to continue to use the IPv4
assigned,  then they'd need to configure to NAK the renew and force the
device back to the beginning.

v2.23.0 | Report a Bug | By Email