Re: [v6ops] IPv6-Only Preferred DHCPv4 option

Lorenzo Colitti <lorenzo@google.com> Fri, 06 December 2019 16:35 UTC

Return-Path: <lorenzo@google.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 433BF1209B4 for <v6ops@ietfa.amsl.com>; Fri, 6 Dec 2019 08:35:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level:
X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 wwAXG-ru6Pzk for <v6ops@ietfa.amsl.com>; Fri, 6 Dec 2019 08:35:45 -0800 (PST)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 DCEE112098F for <v6ops@ietf.org>; Fri, 6 Dec 2019 08:35:44 -0800 (PST)
Received: by mail-io1-xd35.google.com with SMTP id x1so7923742iop.7 for <v6ops@ietf.org>; Fri, 06 Dec 2019 08:35:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zd/hUNSkoK1AQoXMZ3WnJWCRwm2het/B6ZgPRKMXI98=; b=YzIydATb4F8HsMOGnE5nB23jTStYWusXmNibhQye5qiTg3YRZxRZMIS6ecUwYv9UpI t/Y090WJOGGIa0wW0CvKem8I29GgV1rJ/tBSy4gqKmUVrXUZdmUbcb+oMsdvCZzvIa88 lFdqEWZsYcDZASWn58EUQnxzmvdkbNDmWmFsEUJGMHwVWQh/MK+T21m5tQ5ib/UqZG3O 2FENTv2SXz1zIxM9xkr2tTTnWd8GhwOpyONTJyAtS11sfttPAlycqW6qrv+kbQzZ1RUn 0JjjkfogfWyrHYz+zk8o12KnGkOtR4MisCFv+FOcEqlyR6uvuGGUX+9XXRaLQpsAbVgR 3rrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zd/hUNSkoK1AQoXMZ3WnJWCRwm2het/B6ZgPRKMXI98=; b=FcWIb99P9jn/U4CWsqvdaQ5W1ijwkOOctRmn40L1F8IEB2aqO41O0JdMujMgu5Nd6e 2LP9zxQEok8JTEGQDSWl0FKWqWEJL00AvqII+0pd4kIdzZ6hOshxsXih47vt66FHXHSR EtyIUz9NmIQC2UHMNxtOUNMtsgFtP3vIGjDOi5jXJFhgsHAsRlKAMhIKUqV8pZ11ss69 aD8lfLoU5fFQLDwPIvEM1bMaKyUaSnNvpclKFPkKhAnw958IfJwLJHlgZDcW03bbUMuy TSQOaTLZYoQO+IAO/89VqA9n3TOYpQpCRDr2xBXyju3a+GiMol35yHUR4by0xj5h4Ysi 8QzQ==
X-Gm-Message-State: APjAAAXeRIvvL8n05b1rVl4lsuK8t8CUg0WHAxs0uh3gpUII471yWTA/ JxlcV39vs7lHQsUA8VJaopG9H/12f8+h6P8wz0R7YvNjWgw=
X-Google-Smtp-Source: APXvYqzasGEieAJ3u0pYBbkaexLLXVR99OcZ3lmcEIGeo6Jj/q6kG2LxNSbOo9IPh2K7e3GUT8v7mXBYe5jtxoSWNGk=
X-Received: by 2002:a02:2909:: with SMTP id p9mr14542164jap.59.1575650143811; Fri, 06 Dec 2019 08:35:43 -0800 (PST)
MIME-Version: 1.0
References: <m1idEJQ-0000KPC@stereo.hq.phicoh.net> <EF1F2FB2-4FA0-4BCC-82B8-948EBE7915A6@fugue.com> <DM6PR11MB413793BCC3AFF44F7B8E101DCF5F0@DM6PR11MB4137.namprd11.prod.outlook.com> <8FD2BAAB-96D1-41F0-97A2-2D16CDAF999E@fugue.com>
In-Reply-To: <8FD2BAAB-96D1-41F0-97A2-2D16CDAF999E@fugue.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Sat, 07 Dec 2019 01:35:30 +0900
Message-ID: <CAKD1Yr2Vo4Q+q=kAhAcr4F2Xn6u3uMNRWZ+AHBo4jw7VVoPxXg@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
Cc: "Bernie Volz (volz)" <volz@cisco.com>, "dhcwg@ietf.org" <dhcwg@ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001d6e7705990ba3d1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/TFZ5wiAD9sTpp_aFZWsEVwgMZ8w>
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:35:53 -0000

On Sat, Dec 7, 2019 at 1:02 AM Ted Lemon <mellon@fugue.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.
>

I don't think this option requires any server changes other than the code
to parse and serialize the option. That the server doesn't even need to
know or care whether the client supports the option or not. At worst, it
can simply blindly include the option on any pool that is configured to
send it. Obviously, in the presence of buggy clients, the server should
only send the option if it was requested, but servers typically already do
that. The offer behaviour can stay the same: if the server gets a discover,
it picks an address and responds with an offer from the pool. Per RFC 2131
section 3.1, that address need not be reserved, but it could be reserved
for a brief time as well. Either works. If the client gets the option and
decides it doesn't need IPv4, it won't send a request; after a while, the
server can free the address if it had briefly reserved it. If the client
wants IPv4, it will send a request and get an ack.

As Bernie says, if the pool is too small for the number of clients (which
it will be, if this option is to be useful), and too many clients send
discovers simultaneously (e.g., they're rebooted all at the same time),
then the server will either not respond with offers to some of them, or
will respond with offers and be forced to nak if two clients request the
same address. Things continue to work.

The current text in the draft proposes an optimization on top of that:

   If the pool is explicitly configured with a dedicated IPv4
   address to be returned to IPv6-only capable clients the server MUST
   specify that address as the client's network address and MUST NOT
   verify its uniqueness.  Otherwise the server SHOULD follow the
   recommendations in [RFC2131].  The client is not expected to use that
   IPv4 address so if the client responds with the DHCPREQUEST message
   for that address the server SHOULD respond with DHCPNAK.

This does indeed require code changes on the server side. But I think it
would be good if such changes were optional. Additionally, this
optimization creates the problem that if the client and responds to the nak
with a discover, and the server replies with the same offer as before, then
the client could gets stuck in a loop.

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.
>

I don't think this is a good justification for doing things that could
break compatibility. It's true that the network operator is choosing to
deploy this. But the network operator may not fully control all the devices
on the network, and even if they do, fixing bugs is expensive: the bug
needs to be reported, the vendor (assuming they're still around) might need
to be convinced that it's a bug, code changes need to be made, the device
may need to be updated to a substantially newer version, software needs to
be re-qualified, etc. I agree with Bernie that if we can avoid changing the
observed behaviour, that would be better.