IETF Logo Mail Archive

Re: [dhcwg] [Last-Call] Iotdir last call review of draft-ietf-dhc-v6only-03

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 29 June 2020 03:25 UTC

Return-Path: <mcr+ietf@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 B266D3A079D; Sun, 28 Jun 2020 20:25:58 -0700 (PDT)
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 dK__9ugLB5hG; Sun, 28 Jun 2020 20:25:57 -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 08B1D3A079B; Sun, 28 Jun 2020 20:25:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id A81F538996; Sun, 28 Jun 2020 23:23:10 -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 qB3YnM-sf7qN; Sun, 28 Jun 2020 23:23:09 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 80CF838995; Sun, 28 Jun 2020 23:23:09 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E1C00F11; Sun, 28 Jun 2020 23:25:54 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Jen Linkova <furry13@gmail.com>, "iot-directorate@ietf.org" <iot-directorate@ietf.org>, "dhcwg@ietf.org" <dhcwg@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
In-Reply-To: <CAFU7BASf5B-bNrP4RThjFFk1vZyVv8KYP2RM0epFZ1xCWtm7oQ@mail.gmail.com>
References: <159290613429.20258.90107321879676135@ietfa.amsl.com> <CAKD1Yr0m637ft_H43r8kw3868X51OcUE+gUZPQ7OvgEbosL8VQ@mail.gmail.com> <MN2PR11MB356540C90067D188E624CA3FD8940@MN2PR11MB3565.namprd11.prod.outlook.com> <CAKD1Yr0cExR2hNcFPG1jf2_m+owcj36PjBo5K2AfkbQbbBu4bQ@mail.gmail.com> <20606.1592969356@localhost> <858B9014-1274-495C-BB68-A05BB8D1918C@employees.org> <CAKD1Yr20YRP+MxXG80ucceKykXHUkzgUACX=iCsRpHC9jVn8YQ@mail.gmail.com> <m1jo1Ug-0000J7C@stereo.hq.phicoh.net> <CAFU7BAS4r4H78hod6WJCrTv5fiaZx9hM+ELGEv7yVrG8ZSkiAg@mail.gmail.com> <m1jomvC-0000N2C@stereo.hq.phicoh.net> <CAFU7BASf5B-bNrP4RThjFFk1vZyVv8KYP2RM0epFZ1xCWtm7oQ@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: Sun, 28 Jun 2020 23:25:54 -0400
Message-ID: <17993.1593401154@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/QJFNQ8641Wm-kTTnxgpdPYIh0wU>
Subject: Re: [dhcwg] [Last-Call] Iotdir last call review of draft-ietf-dhc-v6only-03
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, 29 Jun 2020 03:25:59 -0000

Jen Linkova <furry13@gmail.com> wrote:
    > - check if making host a dual-stack solves the issue (either by moving
    > the host to a dual-stack segment or by changing DHCPv4 client config)

I think, if the DHCPv4-server can be told to selectively ignore the
dhc-v6only option for that host, that we can make it dual-stack without
touching the client config.

The host would think it's on a network that doesn't offer IPv6-only.

So I think that the option makes troubleshooting easier :-)

    > If an engineer is not willing to diagnose such a complex issue they
    > are welcome to configure their DHCP servers so they do not respond
    > with the option.
    > Problem solved.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email