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

From: Bernie Volz <[email-masked]>
Date: Tue, 1 Feb 2000 15:22:09 -0400

Ted:

>From: Ted Lemon <[email-masked]>
>
>> 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.
>
>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?

OK. Would be interesting to hear some feedback on this, but I do believe
most everyone uses contiguous masks.

>> 4. Should there be something said about host routes? Subnet mask of
>> 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.

I think it would be useful to say something (and you did in the revised
text - thanks).

>> 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.
>
>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.

OK.

>> 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).
>
>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.

Personally, I think it best to say:
1) An administrator SHOULD NOT do this.
2) A client MUST clean the destination before installing the route
(unless the "stack" will do it for the client).

>> 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.
>
>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.

Sure - the DHCP Server already has this knowledge for proper operation.

This may be manually configured for a subnet/shared network. Or, a
server could determine some of this information automatically from
its configuration data.

The issues here are:
1) Do we allow these kinds of routes?
2) If so, the 0.0.0.0 for the router makes it easier for the
administrator to configure (since they can do it on a subnet or shared
network basis) or for the server to automically construct. If you use
the traditional mention of using the client's local IP address, then the
server would have to customize this option for each client.

- Bernie Volz
  Process Software