Re: [dhcwg] [v6ops] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt

Ted Lemon <mellon@fugue.com> Thu, 12 December 2019 16:16 UTC

Return-Path: <mellon@fugue.com>
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 E84C1120996 for <dhcwg@ietfa.amsl.com>; Thu, 12 Dec 2019 08:16:31 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 mRsvLwctUwp9 for <dhcwg@ietfa.amsl.com>; Thu, 12 Dec 2019 08:16:30 -0800 (PST)
Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 24D48120995 for <dhcwg@ietf.org>; Thu, 12 Dec 2019 08:16:30 -0800 (PST)
Received: by mail-io1-xd2f.google.com with SMTP id c16so3381877ioh.6 for <dhcwg@ietf.org>; Thu, 12 Dec 2019 08:16:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=Of2o7wDf8AR/eAavqZNmiZ4xOtqYMk63fgsnD8xq82k=; b=18HVU0M/lfWRvfhq55B1KXNPCEbyH2luHyJBpS87gjTBYmaf42C0H96R/IC9OayWKy o9Ja+a7wz8tpNHSa3ocDIXeUTrFzXGnPimlIBQ+fqJRbHAOX7vO9cWb4ENZxewCnwIkd momJdk8sqD6kic/uKJRx5Dpip5RECJ71HUcopwMFknXP1t2DQyCW1WDTQvXzZjGy2nsD RyKllt8Fat+ofDieCIh2tBQaADSn/rmBNL169KyxpX1xoYAAskll/3URNUFfGGUdboA0 TbrB9ep6/VlSqAxvoYVlbrCJqosc4eLXHY1MY+sjzKBtHu5vM6rDAppLio46BVCoph10 yjWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=Of2o7wDf8AR/eAavqZNmiZ4xOtqYMk63fgsnD8xq82k=; b=pHCM+wFJR6JVMOV+1DRTJh5XbZ//8x0GmthDMdggVUbHXnvzr8C/Rp1PJr6xrAca+I xxpaCcfbeAcZh1fjbLd2B40+KMIH2SiobHzGna/EFaGfF/SDDbmoqm6rozzZdgGLGhfy rrmorpbC3JuM7SCCKDb/cGTrQ6PwTV0T6k8j8ZyjsVLnhsv7+tJZk6H/DEcHmUMUjbn1 1rTyH6HSSZLtnxHDkAPzwmDxPL/pR+d+XZJomuCLeAVs/tqs0ZogbkogxynGHRmH4HTJ JfTgkNdmFzLmA5amIRU7Xik2wv7YPjcz8dbaZTebLktYclA+EX748c+slygMZJgSpWtU tckQ==
X-Gm-Message-State: APjAAAUHe/SS84CvsVJ79u3ByYCREYxOap4fc8Ve/x0BoBLfjpso+D/s s9Yv19W/nu6B94J7NhtvxXnrBUM/YeU=
X-Google-Smtp-Source: APXvYqwuZRRbaCTi8A0bi95x3+tzliBQiBrLKpQvnjoaBqMj6a+Y3H2kTZyY58r5CQQWZB/q5Ugn7w==
X-Received: by 2002:a5d:9701:: with SMTP id h1mr3360452iol.12.1576167389418; Thu, 12 Dec 2019 08:16:29 -0800 (PST)
Received: from [172.19.0.149] ([75.104.90.76]) by smtp.gmail.com with ESMTPSA id k7sm1829020ilg.49.2019.12.12.08.16.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Dec 2019 08:16:28 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Ted Lemon <mellon@fugue.com>
Mime-Version: 1.0 (1.0)
Date: Thu, 12 Dec 2019 08:16:23 -0800
Message-Id: <C81ACD24-32DC-4114-80A7-81C3DDF66E1E@fugue.com>
References: <DM6PR11MB413778A43012050E9CB0502BCF550@DM6PR11MB4137.namprd11.prod.outlook.com>
Cc: David Farmer <farmer@umn.edu>, "dhcwg@ietf.org" <dhcwg@ietf.org>
In-Reply-To: <DM6PR11MB413778A43012050E9CB0502BCF550@DM6PR11MB4137.namprd11.prod.outlook.com>
To: "Bernie Volz (volz)" <volz@cisco.com>
X-Mailer: iPad Mail (17E177)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/XjNvk7TcLex6nFL6B7jEsppq48g>
Subject: Re: [dhcwg] [v6ops] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt
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: Thu, 12 Dec 2019 16:16:32 -0000

On Dec 12, 2019, at 8:05 AM, Bernie Volz (volz) <volz@cisco.com> wrote:
> Just to add one additional point regarding middleboxes … I did confirm (not by actual testing but checking with developers) that at least one middlebox will not pass the DHCPOFFER if the address in the yiaddr field is not appropriate to the network segment the client is on. So, it would not let the DHCPOFFER with yiaddr of 0.0.0.0 go to the client. This is exactly the reason I think this is a bad idea and we MUST NOT do it; the address in the yiaddr must be a “normal” address that the client COULD use. (And asking the middlebox to change to allow an “invalid” address if the IPv6-only option is present in the DHCPOFFER would require a software/firmware update which is not desirable.)

Can you tell us what brand of middlebox this is?   What software version?   How long ago this behavior was last seen?

What you are saying here is effectively that for all eternity, we must configure this broken middlebox to believe that some IPv4 address that will never be assigned on a link is valid on the link, and configure the DHCP server to know what IPv4 subnet is valid on a particular link, even when IPv4 is no longer in use on that link.

This is, frankly, ridiculous.   If software is broken, we should not design our protocols around that brokenness.  Remember back when we did that for Microsoft’s broken implementation of ASCII strings in their DHCP client back in ~Windows 95?   And now that code is still in every DHCP server?  This is a similar situation.

The reality is that if a network operator wants to be able to disable IPv4 for clients that can use IPv6, they are going to be motivated to fix brokenness on their network.   If they don’t care to do that, they probably aren’t going to bother with this anyway.   And if they don’t care to do that, it’s really not our problem.

You, as a Cisco employee, can perfectly well configure your DHCP server to always send an IP address that works on the link, and this middlebox will still work.   But if we say that DHCP servers MUST not use a fixed address (e.g. 0.0.0.0), then we are saying not that you can choose to do this, but that we are all forced to do this.   That’s the wrong call.