Re: [v6ops] IPv6-Only Preferred DHCPv4 option

Ted Lemon <mellon@fugue.com> Fri, 06 December 2019 16:02 UTC

Return-Path: <mellon@fugue.com>
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 5637B12004F for <v6ops@ietfa.amsl.com>; Fri, 6 Dec 2019 08:02:08 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
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 bMR0Xtf6R52X for <v6ops@ietfa.amsl.com>; Fri, 6 Dec 2019 08:02:05 -0800 (PST)
Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D78E120020 for <v6ops@ietf.org>; Fri, 6 Dec 2019 08:02:05 -0800 (PST)
Received: by mail-pj1-x1032.google.com with SMTP id w5so2901064pjh.11 for <v6ops@ietf.org>; Fri, 06 Dec 2019 08:02:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=4wuAXSpam1y+5kPi3mKVjS09Lmuhuw3ddXZqgv6siv0=; b=KjOU+haxedidBQqviy0Cnab+z9p8jCSRE3ZYcZCi4QChTSAqSOEQdFYmwyGGAePvHa 7ZqLzdzCDh+xH9juOn231blB1EBjAX2Sftav6UA0favhx3Kr1w5Xl4mkRBifdvG4Y6O5 LiUsW7yEo21lsMtWE28dmjcdWRY7AkNcf0BMTUx6nLrztL4I2E8PjGQtYQakHuT7t1a8 mJmtKTIPpaqIbnBwn3qgVUbrnofH4CRq7BGkOtE8ihEQqmHDCK1ezDzx4BCUiJRFmJAY 7e3v5BDtm2gHygnB7P2IhlzNgNMVMBuaDMOG0e9oe9Xq8WaqipzD0ixkCeecS5F/nx43 U52Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=4wuAXSpam1y+5kPi3mKVjS09Lmuhuw3ddXZqgv6siv0=; b=oJBRjuqgA8TkxuQ/FuT/zD5R/bAjpZ+SB4wVZoxSNu5f8dremIfVcISTKT5sPRRR7S gdlv0zmVY8eLedp2QHk8hbbqB0oEVUobHnak6jTkaWVWJB0ptqmRYpfgVN5Nc2idPrAY ECnnTdLxnhxqctjLBjj7bIpbrumPfFEYjNfim8xBOXC4j+Xjsaay2MaEOQ/LA4yIhGEI D5cz4BDQFDig6mw+6i+bbWHwFKBDeB05zVQDKbnZRuOgwmdALkAPqcpFdOyvRwVjTcOg M38bAzi7CnQr4QW8no9T7ognaaERbj9UsNAApa2bLXPUePD84NxsYbFwFxtRlAbw5Vz1 phQw==
X-Gm-Message-State: APjAAAUjnFkQovjWc84cJc5Z1CNLFuvPQd9FapJFBej4j09AG03olHvU 37SeAbSIXmslV9mJTll2206mCQ==
X-Google-Smtp-Source: APXvYqxSaPc3eh8YZ182s1e7csUS1YlDcqCR2u9KTn13zuVI2iMrnKfkL16Sj07W/PusDIg8kFzyhQ==
X-Received: by 2002:a17:902:6803:: with SMTP id h3mr14323490plk.319.1575648124842; Fri, 06 Dec 2019 08:02:04 -0800 (PST)
Received: from encantada.scv.apple.com ([17.192.138.54]) by smtp.gmail.com with ESMTPSA id i4sm3867272pjw.28.2019.12.06.08.02.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Dec 2019 08:02:03 -0800 (PST)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <8FD2BAAB-96D1-41F0-97A2-2D16CDAF999E@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_52BD073E-5C44-4C97-A606-9A4489660E12"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3600\))
Date: Fri, 06 Dec 2019 08:02:02 -0800
In-Reply-To: <DM6PR11MB413793BCC3AFF44F7B8E101DCF5F0@DM6PR11MB4137.namprd11.prod.outlook.com>
Cc: Philip Homburg <pch-v6ops-9@u-1.phicoh.com>, "v6ops@ietf.org" <v6ops@ietf.org>, "dhcwg@ietf.org" <dhcwg@ietf.org>
To: "Bernie Volz (volz)" <volz@cisco.com>
References: <m1idEJQ-0000KPC@stereo.hq.phicoh.net> <EF1F2FB2-4FA0-4BCC-82B8-948EBE7915A6@fugue.com> <DM6PR11MB413793BCC3AFF44F7B8E101DCF5F0@DM6PR11MB4137.namprd11.prod.outlook.com>
X-Mailer: Apple Mail (2.3600)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/XEwjjJat5BisZrdyJuuEI1h0rfE>
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 16:02:08 -0000

On Dec 6, 2019, at 6:45 AM, Bernie Volz (volz) <volz@cisco.com> wrote:
> which requires fewer changes on the DHCP server implementation

This is almost certainly not true.  In order for this to work, you’re going to have to have some special-purpose code to support it.  Better to do the clean solution than a hack that minimizes changes to the server at the expense of more complication in the client-server interaction.

> Existing servers can deploy this without ANY changes (provided you have a means to configure the server with whatever option number is finally assigned).

I think it’s okay to require changes to the server.   This is a significant new feature.

> Personally, I would NOT recommend breaking the semantics of a DHCPOFFER and always include an address because you never know how intermediate devices that may be "snooping" this traffic will handle this; for example, the intermediate device might drop what it feels is an invalid packet.

This is definitely not an issue, though, because the network operator is choosing to deploy this.  They can be responsible for ensuring correct behavior if there are any middleboxes intercepting the DHCPv4 traffic and doing stuff with it.   Expecting this to Just Work with no infrastructure changes seems unnecessary.

>> There is a reason why DHCP includes a parameter request list option.  If the client doesn’t ask for this newfangled option, it shouldn’t see it.  And so we can know for sure that the client supports this capability, because it asked for it.
> 
> Even if a DHCP server sent the option without it being requested, why would the client use it if it didn't ask for it?

If the DHCP server knows the client supports the feature, it can assume that when it sends the option, the client will implement the specified behavior.   If it doesn’t know for sure that the client supports the feature, then you have to deal with a much more complex set of possible behaviors.   Why add that complexity?

And that’s assuming that the client behaves correctly.  If you just send the new option, another possibility is that the client crashes when it doesn’t recognize the option, as we used to see with certain printers I the manufacturer of which I will not mention.   Or that it does some other random thing.  Why chance it?