IETF Logo Mail Archive

Re: [v6ops] IPv6-Only Preferred DHCPv4 option

Simon Hobson <linux@thehobsons.co.uk> Fri, 06 December 2019 21:42 UTC

Return-Path: <linux@thehobsons.co.uk>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561E1120074 for <v6ops@ietfa.amsl.com>; Fri, 6 Dec 2019 13:42:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 awzKAmQ0NOcd for <v6ops@ietfa.amsl.com>; Fri, 6 Dec 2019 13:42:09 -0800 (PST)
Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BEC412002F for <v6ops@ietf.org>; Fri, 6 Dec 2019 13:42:09 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk
Received: from simons-macbookpro.thehobsons.co.uk (Simons-MacBookPro.thehobsons.co.uk [192.168.137.111]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 66A1B1A071 for <v6ops@ietf.org>; Fri, 6 Dec 2019 21:42:05 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Simon Hobson <linux@thehobsons.co.uk>
In-Reply-To: <1D60C687-E163-4C66-874C-1349F7219740@fugue.com>
Date: Fri, 06 Dec 2019 21:42:03 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <DC72CE4D-157E-4129-8AD5-E72E318035E9@thehobsons.co.uk>
References: <CAKD1Yr2Vo4Q+q=kAhAcr4F2Xn6u3uMNRWZ+AHBo4jw7VVoPxXg@mail.gmail.com> <1D60C687-E163-4C66-874C-1349F7219740@fugue.com>
To: "v6ops@ietf.org" <v6ops@ietf.org>
X-Mailer: Apple Mail (2.2104)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Uq47zv8H3mO9ibtfyEFnalQtxRU>
Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Dec 2019 21:42:12 -0000

Mark Smith <markzzzsmith@gmail.com> wrote:

> - IPv6 only applications clearly indicate they're IPv6 only, by only
> opening IPv6 sockets.

I think "IPv6 only" applications are a rare thing, and will remain so for a long time. Applications that can use IPv4 or IPv6, and which can work fine in IPv6 if IPv4 isn't available, are likely to be the norm for some time.

For an application to signal such compatibility modes to the OS would need substantial changes to the interaction model between application and OS. In the general case, that's just not going to happen.



> Ted Lemon <mellon@fugue.com> wrote:

> Lorenzo, it might help for you to make explicit why you do not want to require changes on the server. This seems like a short sicher choice for a solution that’s going to be deployed for a long time. Why not do it right given we’re going to have to live with it for decades?

As previously described in terms of identifying bugs in intermediate equipment, raising bug reports, persuading the vendor (if they are still around and the kit is still in support) to fix it, and then rolling out the fix ...
Why require changes in DHCP servers when it can be done without any code changes at all ?

Perhaps define the option such that DHCP server vendors can, if they so desire, code in some optimisations - but I would say that allowing it to work without code changes would be much better.

There is one thought that comes to mind ... In effect, where this option is deployed, then (native) IPv4 is considered a legacy protocol that's being deprecated - why invest more effort than needed in supporting it.

v2.23.0 | Report a Bug | By Email