Subject: Comments on draft-ietf-dhc-csr-03.txt

From: Stuart Cheshire <[email-masked]>
Date: Wed, 29 Nov 2000 16:48:47 -0800

>   When an IP host (the source host) wishes to transmit a
>   packet to another IP host (the destination), it first checks the IP
>   address of the destination host to see if it is on a subnet to
>   which the source host is connected.  If the destination host's IP
>   address is not on a subnet to which the source host is connected,
>   then the source host consults its routing table to determine the IP
>   address of the router that should be used to forward the packet to
>   the destination host.

This is a minor detail, but this is not true on many systems, such as 
Linux, for example. Linux simply consults the routing table, and the 
kernel obeys the instructions there about whether to send the packet 
directly on an attached link or via a gateway. For example, here's the 
routing table from my Linux machine:

>[cheshire@chesh2 cheshire]$ route
>Kernel IP routing table
>Destination    Gateway    Genmask         Flags Metric Ref  Use Iface
>17.201.20.0    *          255.255.252.0   U     0      0      0 eth0
>127.0.0.0      *          255.0.0.0       U     0      0      0 lo
>default        nathanf2   0.0.0.0         UG    0      0      0 eth0

The reason that it sends packets directly to hosts on 17.201.20/22 is 
because the routing table tells it to, not because it "first checks the 
IP address of the destination host to see if it is on a subnet to which 
the source host is connected." I could quite easily change the routing 
table to tell the kernel to do something different if I wanted, and it 
would obey those instructions. Sometimes for debugging it can be useful 
to send packets via some gateway machine, even when the destination is on 
the same Ethernet.

I suggest we just delete that paragraph, since it is purely explanatory 
background material, and not central to explaining the DHCP CSR option.

-----

>   The Static Routes option does not provide a subnet mask for each

To avoid reader confusion, why not say "The old Static Routes option" or 
"The original Static Routes option" to make it totally clear that this is 
describing the flaw in the old option.

-----

>   DHCP clients that support ARPing
>   as described here MUST ignore the Router option (option code 3) if
>   the Router option contains the client's own IP address.

>   If the DHCP server returns a Router option, clients that support
>   the Classless Static Routes option MUST use the default route(s)
>   listed in the Router option in addition to the routes listed
>   in the Classless Static Routes option.

These two statements (from different parts of the draft) seem 
contradictory. If the DHCP server returns a Router option, the client 
MUST use it, unless it is the magic "enable all-ARP mode" address, in 
which case the client MUST NOT use it. If that's what we mean, perhaps we 
should say so explicitly in a single sentence. What if the address in the 
Router option is 0.0.0.0? That's a synonym for the client's own IP 
address, right, and also enables "all-ARP mode". Should the client ignore 
that as well?

This case of sometimes you use the option and sometimes you don't seems 
potentially confusing. Might it be simpler to say that the CSR option 
completely replaces BOTH the old Static Route Option and the old Router 
option? If you use CSR, then you use it for all routes, including the 
default one. We could then change the following text:

>   DHCP
>   clients that support this option MUST NOT install the routes
>   specified in the Static Routes option (option code 33) if both a
>   Static Routes option and the Classless Static Routes option are
>   provided.
>
>   DHCP clients that support this option and that send a DHCP
>   Parameter Request List option MUST request both this option and the
>   Router option [2] in the DHCP Parameter Request List.  DHCP clients
>   that support this option and send a parameter request list MUST NOT
>   request the Static Routes option.
>
>   If the DHCP server returns a Router option, clients that support
>   the Classless Static Routes option MUST use the default route(s)
>   listed in the Router option in addition to the routes listed
>   in the Classless Static Routes option.

To:

>   If the Classless Static Routes option is provided, DHCP clients
>   that support this option MUST ignore all Static Routes options
>   (option code 33) and Router options (option code 3), if any,
>   appearing in the packet.
>
>   DHCP clients that support this option and that send a DHCP
>   Parameter Request List option MUST request this option and
>   MUST NOT request the Router option or the Static Routes option.

A DHCP server administrator who has to support both old and new clients 
can then simply use the Router and Static Routes options to configure the 
old clients, and the CSR option to configure the new clients, and there's 
no confusing overlap between the two.

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