Re: [v6ops] Please review the No IPv4 draft

Philip Homburg <pch-v6ops-3a@u-1.phicoh.com> Mon, 14 April 2014 17:33 UTC

Return-Path: <pch-bBB316E3E@u-1.phicoh.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8A81A06C1 for <v6ops@ietfa.amsl.com>; Mon, 14 Apr 2014 10:33:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.9
X-Spam-Level:
X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham
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 DBenfOehqazw for <v6ops@ietfa.amsl.com>; Mon, 14 Apr 2014 10:33:31 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 28F451A069E for <v6ops@ietf.org>; Mon, 14 Apr 2014 10:33:30 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1WZkky-0000BrC; Mon, 14 Apr 2014 19:33:20 +0200
Message-Id: <m1WZkky-0000BrC@stereo.hq.phicoh.net>
To: Ted Lemon <ted.lemon@nominum.com>
From: Philip Homburg <pch-v6ops-3a@u-1.phicoh.com>
Sender: pch-bBB316E3E@u-1.phicoh.com
References: <534BF5A5.5010609@viagenie.ca> <534BFA08.3030404@foobar.org> <49EA8AC9-D5C5-4FE5-9A10-0CD574782F0F@nominum.com> <534C07FC.8000907@foobar.org> <F08AF14D-22C6-4F4C-9388-670EB4CD8453@nominum.com>
In-reply-to: Your message of "Mon, 14 Apr 2014 11:36:46 -0500 ." <F08AF14D-22C6-4F4C-9388-670EB4CD8453@nominum.com>
Date: Mon, 14 Apr 2014 19:33:19 +0200
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/mcg5ji176DOckQtkJm7R43Lc3J4
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Please review the No IPv4 draft
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Mon, 14 Apr 2014 17:33:34 -0000

In your letter dated Mon, 14 Apr 2014 11:36:46 -0500 you wrote:
>It's broadcast traffic, which is expensive for everyone sharing a Wifi AP.   I
>f every host is doing it, that's a lot of traffic.
>
>Also, if I get a DHCPDISCOVER, and response with a DHCPOFFER with this option,
> is the expectation that the client will shut down at that point?   That's a s
>ubstantial protocol change, if so.   If we're going all the way to DHCPACK, no
>w the client has an IP address.   What if it tries to use it?

I wonder if such an DHCPv4 option should be called 'no-service-at-the-moment'.
This can then be returned in the DHCPOFFER.

The option contains a timeout and clients should have a maximum what they
are willing the accept.

The client DHCP will stop sending DHCPDISCOVERs until the timeout has expired
or until the user/admin manually requests a DHCP lease.

This way the option becomes independent of IPv6 and can be use in any situation
where there won't be any offers for a while.

Note that if a client receives both an actual offer from one server and
the new option from an attacker, then the client can still continue with a
REQUEST, thus reducing the DoS potential.