Subject: draft-ietf-dhc-csr-00.txt

From: Bernie Volz <[email-masked]>
Date: Tue, 1 Feb 2000 10:33:52 -0400

Ted:

Thanks for producing this draft.

Some comments:

1. In the option format diagram, you used 33 (the Static Routes option
number). You should put in XX or something like that.

2. While I think we'd all assume that the subnet mask is supposed to
have the NETWORK bits set, how about explicitly specifying that. In
other words for a class C network, is it 255.255.255.0 or 0.0.0.255
(Cisco favors the 0.0.0.255 syntax in router configuration, so this is
kind of important to specify, IMHO).

3. What about considering removing the subnet mask and instead 
specifying a subnet-mask-length. This would make each entry 9 bytes
intead of 12. And, non-contiguous subnet masks are really not favored
these days.

4. Should there be something said about host routes? Subnet mask of
255.255.255.255 (or subnet mask length of 32)?

5. Should there be something said about default routes (destination of
0.0.0.0)? This likely should be illegal, as it is for static routes,
since these should be specified by the Router Option. [Or, should we
also consider depreciating that and suggesting that these are placed in
this new option - though at a significant byte expense - 8 extra
bytes/route). I'd favor saying they are not allowed.

6. Should there be something said about a destination that has HOST bits
set when applying the subnet mask? Should a DHCP client IGNORE that
entry or treat the packet in error or should it install the "cleaned"
route (by clearing the host bits).

7. Do we allow the router to be the DHCP Client itself? In which case,
the client should assume that this is a "shared network" and there are
multiple subnets on that physical cable. MIGHT we want to specify a
shorthand for this to make DHCP Server configuration and option
generation easier - if the Router is 0.0.0.0, the DHCP Client should
assume that it is the router and hence that the subnet is directly
reachable.

8. It is kind of odd that you do not reference any of the CIDR
documents, such as RFC 1519.

I think that's about it for now. Gee, and you thought that this would be
quick and easy! Sorry.

- Bernie Volz
  Process Software

---

From: Ted Lemon <[email-masked]>
Date: Tue, 01 Feb 2000 13:06:13 -0500

> number). You should put in XX or something like that.

D'oh!   Ralph pointed this out to me, and I forgot to fix it.   :'(

> kind of important to specify, IMHO).

Good point.

> intead of 12. And, non-contiguous subnet masks are really not favored

Hm.   Interesting.   I guess I'd have to say that I'd rather have the
mask, because the fact that non-contiguous subnet masks aren't favored
now doesn't mean nobody has a use for them.   Can other folks comment
on this point?

> 255.255.255.255 (or subnet mask length of 32)?

I don't know if it's necessary to say anything about this, but if you
think it is, I'll add a paragraph.

> bytes/route). I'd favor saying they are not allowed.

I spent a bunch of time thinking about this.   I don't like saying
that a default route is illegal in the option, because this places a
requirement on the server.   I also don't like saying you shouldn't
use default route and static routes together, because this also places
a requirement on the server.   I don't want the server to have to
check this, and I particularly don't want a client to reject an offer
because the author decided to be persnickety about this.   So I kind
of prefer leaving the behaviour undefined.   I wouldn't mind putting a
note in saying the server administrator SHOULD NOT configure a default
route in the static route option.

> route (by clearing the host bits).

Again, I think the best thing to do here would be to say that the
server administrator SHOULD NOT do this, and leave the behaviour
resulting from a violation of this SHOULD NOT unspecified.

> assume that it is the router and hence that the subnet is directly

Wow.   You want to put this knowledge in the DHCP server?   This is a
scary can of worms - if you want to do something like this, I think it
needs to be a seperate draft, although it might be worthwhile to
mention the possibility of a special meaning for 0.0.0.0 here.   We'd
have to be careful not to specify something in a way that would cause
trouble later, though, or prevent this draft from advancing.

> documents, such as RFC 1519.

I read them over, and decided that they weren't relevant.  They don't
really talk about the mechanics of variable-width subnet masks - they
just talk about an Internet backbone implementation strategy.  I don't
think you get any useful information that's germane to the topic of
this option by reading them.  I did actually reference the documents
that specifically describe variable-width subnet masks.

> I think that's about it for now. Gee, and you thought that this would be

Not at all - you came up with some excellent comments!   Thanks!
I've included context diffs for the changes I've made based on your
comments below.

			       _MelloN_

*** draft-ietf-dhc-csr-00.txt~	Mon Jan 24 12:46:37 2000
--- draft-ietf-dhc-csr-00.txt	Tue Feb  1 13:04:49 2000
***************
*** 117,125 ****
     destination.
  
      Code Len Destination 1       Subnet Mask 1       Router 1
!    +----+---+----+----+----+----+----+----+----+----+----+----+----+----+
!    | 33 | n | d1 | d2 | d3 | d4 | m1 | m2 | m3 | m4 | r1 | r2 | r3 | r4 |
!    +----+---+----+----+----+----+----+----+----+----+----+----+----+----+
  
      Destination 2       Subnet Mask 2       Router 2
     +----+----+----+----+----+----+----+----+----+----+----+----+
--- 117,125 ----
     destination.
  
      Code Len Destination 1       Subnet Mask 1       Router 1
!    +-----+---+----+----+----+----+----+----+----+----+----+----+----+----+
!    | TBD | n | d1 | d2 | d3 | d4 | m1 | m2 | m3 | m4 | r1 | r2 | r3 | r4 |
!    +-----+---+----+----+----+----+----+----+----+----+----+----+----+----+
  
      Destination 2       Subnet Mask 2       Router 2
     +----+----+----+----+----+----+----+----+----+----+----+----+
***************
*** 128,139 ****
--- 128,167 ----
  
     In the above example, two static routes are specified.
  
+    Subnet masks specified in the Classless Static Routes option have
+    the one bit set for every bit in the mask that corresponds to the
+    network portion of IP addresses on the subnet being specified.   So
+    for example, if a subnet has a network number of 10.17.64.0 and is
+    divided into 22 bits of network number and 10 bits of host number,
+    then the subnet mask would be 255.255.252.0.   Host routes are
+    specified by a subnet mask of 255.255.255.255.
+ 
  DHCP Client Behavior
  
     The DHCP client MAY use this option to install a set of static
     routes in its routing table.   A DHCP client that implements this
     option SHOULD use this option in preference to the Static routes
     option if both are present in a reply from the DHCP server.
+ 
+ DHCP Server administrator responsibilities
+ 
+    The client's behaviour if both a Routers option and a Classless
+    Static Routes option default route (network number 0.0.0.0, network
+    mask 0.0.0.0) are specified is not defined in this document, so as
+    to avoid placing onerous requirements on the client and server
+    implementations.   Therefore, the DHCP server administrator SHOULD
+    NOT configure the DHCP server so that it sends both a Routers
+    option and a Classless Static Routes option containing a default
+    route.   Either no Routers option should be configured (this is
+    probably preferable in the near term, since only newer DHCP clients
+    will implement this option), or the Classless Static Routes option
+    should not contain a default route.
+ 
+    The client's behaviour is also not defined in the case where the
+    server sends a classless static route in which some bits in the
+    network number are 1, and corresponding bits in the subnet mask are
+    zero.   Therefore, DHCP server administrators SHOULD NOT configure
+    the DHCP server to send such a route.
  
  Security Considerations