Subject: Re: Last call for <draft-ietf-dhc-csr-05.txt>

From: Stuart Cheshire <[email-masked]>
Date: Fri, 24 Aug 2001 18:17:41 -0700

Some minor suggestions:

1. The document contains some tab characters, which mess up formatting on 
systems where tabs are not necessarily eight spaces.

2. Classless Route Option Format

>   Destination descriptors describe the IP subnet number and subnet
>   mask of a particular destination using a compact encoding.   This
>   encoding consists of one octet describing the width of the subnet
>   mask, followed by all the non-zero octets of the subnet number.

You don't mean, "non-zero octets of the subnet number." Suppose I want to 
set a static route to 10.0.127/22. Do I only include the non-zero octets?

I suggest:

   mask, followed by all significant octets of the subnet number.

Similarly:

>   The non-zero portion of the subnet number is simply all of the
>   octets of the subnet number, with the least significant octets that
>   are zero omitted.   For a subnet mask width of between 25 and 32,
>   the subnet number will be four octets.   Mask widths of between 17
>   and 24 indicate a three-octet subnet number; between 9 and 16
>   indicate a two-octet subnet number, between 1 and 8 indicate a
>   one-octet number.

This text suggests an optimization which doesn't actually work. Omitting 
the "least significant octets that are zero" suggests that you can encode 
the destination "10.0.0.0/24" as just "24.10". This works only so long as 
the receiver has some other way to detect the end of the destination 
descriptor, which it does not. If the sender encodes "10.0.0.0/24" as 
just "24.10", the receiver would have no way to know where the 
destination descriptor ends and the IP address of the router begins.

I suggest:

   The significant portion of the subnet number is simply all of the
   octets of the subnet number where the corresponding octet in the
   subnet mask is non-zero. The number of significant octets is the
   width of the subnet mask divided by eight, rounding up, as shown
   in the following table:

        Width of subnet mask     Number of significant octets
                     0                     0
                  1- 8                     1
                  9-16                     2
                 17-24                     3
                 25-32                     4

3. DHCP Client Behavior

>   DHCP clients
>   that support this option and send a parameter request list MUST NOT
>   request the Static Routes option.

Can you explain the rationale for this?

If I change the Mac OS DHCP client to NOT request the Static Routes 
option, then Macs will stop working on certain networks that rely on this.

It is important to Apple to have one DHCP client which works on all
networks -- making the user configure a 'mode' for the DHCP client is 
contrary to the spirit of DHCP, which is to automate network 
configuration. (We'd need a DHCP option to automatically set that 
configuration option for the client :-)

I suggest:

   DHCP clients that support this option and send a parameter
   request list MAY also request the Static Routes option, for
   compatibility with older servers that don't support Classless
   Static Routes.

Also:

>   The Classless Static Routes
>   option code SHOULD appear in the parameter request list prior to
>   the Router option code.

This should say, "MUST", or should be removed. If it says "MUST" then 
server implementers can rely on it, so it is useful. If it says "SHOULD", 
then server implementers cannot rely on it, so what's the point?

I suggest:

   The Classless Static Routes option code MUST appear in the
   parameter request list prior to both the Router option code
   and the Static Routes option code, if present.

4. Requirements to avoid sizing constraints

>   clients implementing the Classless Static Route option SHOULD send
>   a Maximum DHCP Message Size [2] option if the DHCP client's TCP/IP
>   stack is capable of reassembling fragmented IP datagrams.   In this
>   case, the client SHOULD set the value of this option to the MTU of
>   the interface that the client is configuring.   If the client
>   supports UDP fragmentation, it MAY set the value of this option to
>   the size of the largest UDP packet it is prepared to accept.

There's no such thing as UDP fragmentation. Fragmentation and 
defragmentation is an IP-layer function. The only question is if the UDP 
software has some size limitation.

I suggest:

   clients implementing the Classless Static Route option SHOULD
   send a Maximum DHCP Message Size [2] option if the DHCP
   client's TCP/IP stack is capable of reassembling fragmented
   IP datagrams.   In this case, the client SHOULD set the value
   of this option to at least the MTU of the interface that the
   client is configuring. If the client is able to receive UDP
   packets larger than the MTU of the interface, then the client
   MAY set the value of this option higher, up to the size of
   the largest UDP packet it is prepared to accept. (Note that the
   value specified in the Maximum DHCP Message Size option is the
   total maximum packet size, including IP and UDP headers.)

5. DHCP Server Considerations

>   When a DHCP client requests both the Router option and the
>   Classless Static Routes option, and the DHCP server is configured
>   with both a Classless Static Routes option and a Router option
>   that applies to the client, the DHCP server MAY exclude the Router
>   option from its response.

Add text about Static Routes option too:

   When a DHCP client requests the Classless Static Routes
   option and also requests either or both of the Router option
   and the Static Routes option, and the DHCP server is
   sending Classless Static Routes options to that client,
   the server MAY choose to save space in the reply packet
   by not including Router or Static Routes options.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org

---

From: Ted Lemon <[email-masked]>
Date: Sat, 25 Aug 2001 11:25:36 -0400

> option, then Macs will stop working on certain networks that rely on this.

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 don't find it hard to believe that someone is abusing the old static
routesoption in a way that happens to work in some cases, but that's
not the same thing.  I don't know of any DHCP servers that can't be
configured to use CSR right now - the ISC and Microsoft servers can
both be configured to send binary data in an option.  I don't envision
first-class support for CSR in servers lagging behind support for it
in clients.  So this seems like a non-issue.

If people _are_ able to kludge the old static routes option to work,
that will continue to work for clients that don't support CSR, but
kludging this draft to support the old static routes option
side-by-side CSR *would* break new clients.

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.   I see no
other way to avoid this - I don't think that RFC2131/2132 specify an
order for dropping options if they don't all fit, and I don't think it
would be appropriate to specify such an ordering in this draft.

You do make a number of good points in your criticism, but I wonder if
it is necessary that I make the changes you have proposed in order for
the draft to be usable, or if they are clarifications of perfectly
understandable language that will not actually result in
misunderstandings.

The reason that I ask is that 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 have at the request of a variety of different people in the WG made
changes and clarifications to the draft over time, and the result is
that we still don't have a CSR option, some three years after the
first draft was written.   If we'd just released the draft three years
ago, in a perhaps somewhat less clear state, I believe that CSR would
be deployed now, and would be working just fine.

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Fri, 31 Aug 2001 13:24:13 -0400

After arguing at length so as to avoid making major changes to the
draft, I reread your message, and I think that all your proposed
changes are actually good ones.  So I will be putting them in a new
version of the draft and submitting it to the RFC editor.  Sorry for
being stubborn - I'm just paranoid about delaying this draft any
further.  Thanks very much for your careful read of the draft, and for
your well-thought-out suggestions for improving it.  I'll try to be
less churlish next time.  :'}

			       _MelloN_

_______________________________________________
dhcwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/dhcwg