[dhcwg] Re: Last call for <draft-ietf-dhc-csr-05.txt>

Ted Lemon <mellon@nominum.com> Tue, 28 August 2001 01:50 UTC

Received: from optimus.ietf.org (ietf.org [] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07235; Mon, 27 Aug 2001 21:50:54 -0400 (EDT)
Received: from optimus.ietf.org (localhost []) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA15912; Mon, 27 Aug 2001 21:49:16 -0400 (EDT)
Received: from ietf.org (odin []) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA15890 for <dhcwg@ns.ietf.org>; Mon, 27 Aug 2001 21:49:15 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07133 for <dhcwg@ietf.org>; Mon, 27 Aug 2001 21:47:53 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (user-2inic6l.dialup.mindspring.com []) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f7S1hOf10324; Mon, 27 Aug 2001 18:43:25 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost []) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f7S1mtT00420; Mon, 27 Aug 2001 21:48:55 -0400 (EDT)
Message-Id: <200108280148.f7S1mtT00420@grosse.bisbee.fugue.com>
To: Stuart Cheshire <cheshire@apple.com>
cc: "DHCP discussion list" <dhcwg@ietf.org>
In-Reply-To: Message from Stuart Cheshire <cheshire@apple.com> of "Mon, 27 Aug 2001 13:59:13 PDT." <200108272059.f7RKxEw00418@scv2.apple.com>
Date: Mon, 27 Aug 2001 21:48:55 -0400
From: Ted Lemon <mellon@nominum.com>
Subject: [dhcwg] Re: Last call for <draft-ietf-dhc-csr-05.txt>
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org

> The most common use of static routes I know is to tell a host with a 
> global address and a default gateway that Net 10/8 is local and reachable 
> via a different route.

But you can't specify that with the static routes option!   This is
why we need the CSR option - because you can't specify a CIDR route
such as the one you just mentioned using the existing static routes

> Clients can request all three options, but only use "routers" and "static 
> routes" when there's no "classless static routes" data in the packet.

The client probably won't *get* all three options!  The server will
likely leave one out due to lack of space, and there is no reason to
believe that the one it will drop will be the static routes option.

We could make it the server's responsibility to notice that both
options are requested and exclude one, but this is fairly expensive,
and servers have to handle the aggregate workload rather than the
individual workload, which is why I didn't solve the problem that way.

>     * Can anyone give any technical reason why it is          *
>     * necessary for *this* document to prohibit clients       *
>     * from requesting DHCP option number 6 (static routes)?   *

Because both options are likely not to fit in a packet.


dhcwg mailing list