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

"Bernie Volz (EUD)" <> Mon, 27 August 2001 22:19 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id SAA02617; Mon, 27 Aug 2001 18:19:41 -0400 (EDT)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id SAA08774; Mon, 27 Aug 2001 18:15:16 -0400 (EDT)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id SAA08746 for <>; Mon, 27 Aug 2001 18:15:15 -0400 (EDT)
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id SAA02416 for <>; Mon, 27 Aug 2001 18:13:53 -0400 (EDT)
Received: from ( []) by (8.11.3/8.11.3) with ESMTP id f7RMFEp22122 for <>; Mon, 27 Aug 2001 17:15:14 -0500 (CDT)
Received: from eamrcnt749 ( []) by (8.11.3/8.11.3) with SMTP id f7RMFET19233 for <>; Mon, 27 Aug 2001 17:15:14 -0500 (CDT)
Received: FROM BY eamrcnt749 ; Mon Aug 27 17:15:13 2001 -0500
Received: by with Internet Mail Service (5.5.2653.19) id <P4MP5VXS>; Mon, 27 Aug 2001 17:15:13 -0500
Message-ID: <>
From: "Bernie Volz (EUD)" <>
To: "'Stuart Cheshire'" <>, Ted Lemon <>, DHCP discussion list <>
Subject: RE: [dhcwg] Re: Last call for <draft-ietf-dhc-csr-05.txt>
Date: Mon, 27 Aug 2001 17:15:11 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12F45.BD396A30"
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <>

I was always wondering why it was MUST NOT. Seems to me that asking for
both options MIGHT be a good thing during the transition period. Especially
since hand encoding the CSR option is a bit tricky so without some special
server configuration support, it likely won't be widely used - or worse yet,
encoded incorrectly!. Certainly hand encoding 20 or 30 routes, especially if
they could change from time to time won't be fun very long and likely to be

As the existing static route option likely isn't used for much, having both
is not going to make packets too big. If that does happen, then I guess
a site would need to use an updated server that does not send both or they'd
need to stop using one.

Using static routes these days is kind of questionable anyway, isn't it?

So, I can't give you a technical reason for using MUST NOT and would support
changing this.

I would really like to see this draft get published!!!!!!! It seemed like such
an easy exercise!

- Bernie Volz

-----Original Message-----
From: Stuart Cheshire []
Sent: Monday, August 27, 2001 4:59 PM
To: Ted Lemon; DHCP discussion list
Subject: [dhcwg] Re: Last call for <draft-ietf-dhc-csr-05.txt>

>I find it difficult to believe that any existing, deployed network
>depends on the correct operation of the existing static routes option.
>Do you know of such a network, or are you speaking hypothetically?
>CIDR is close to a decade old now, and I find it difficult to believe
>that there exists a network where the static routes option is needed
>and where it can correctly represent the routing table that one would
>need to send to the client.


I'm not trying to impede progress on this document. On the contrary, I 
want to get it published ASAP so I can include it in the next Mac OS 
release, but I can't if it is written in such as way as to prevent me 
from doing that.

Apple ships millions of copies of Mac OS. If we change *anything*, 
there's always a non-zero number of people who will complain about it.

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.

I can't ship an update that breaks that.

>kludging this draft to support the old static routes option
>side-by-side CSR *would* break new clients.

Why would this break new clients?

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 draft already suggests exactly this mechanism for the "routers" 
option. Why not the same mechanism for "static routes" too?

>The reason for the exclusion is that these options are huge, and if
>the server is asked to send both, it is likely that one of them won't
>fit, or that some other important option won't be sent.

You've said yourself that most sites are not even using "static routes", 
so why is this going to be a problem?

Once CSR support is widespread in clients, sites that are currently using 
(or abusing) "static routes" can simply switch over to CSR instead. I 
expect most servers won't send both -- but the client has to ask for both 
because it doesn't know what the server is going to send.

>I would like to get these drafts done,
>and revising them as you have proposed will then require another long
>review period, and may introduce mistakes that actually damage the
>draft.  There is no such thing as a draft that cannot be meaningfully
>clarified - the question is, does it *need* to be clarified.

I also don't want to delay it, but the "MUST NOT request the Static 
Routes option" wasn't in the first few drafts I read, and I apologize for 
not noticing it sooner. As it is, the draft mandates that I have to break 
existing functionality if I want to support CSR. I can't do that.

I proposed new text to try to help this go smoothly. If the WG members
agree with the proposed new text, then we have consensus.

Question for the Working Group:

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

Stuart Cheshire <>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF

dhcwg mailing list