Subject: [dhcwg] draft-ietf-dhc-csr-05.txt

From: Thomas Narten <[email-masked]>
Date: Fri, 28 Sep 2001 11:39:00 -0400

Ralph Droms <[email-masked]> writes:

> The Classless Static Route Option for DHCP
>    <draft-ietf-dhc-csr-05.txt>
>    Changes suggested in WG response, revision to be submitted

Here are my comments on this document.

NIT: The term "classed" (as in classed routing) isn't the common one,
I think. "classful" is more common.

>   Subnet number   Subnet mask      Destination descriptor

under destination descriptor, I think it would be potentially less
confusing to NOT use the dotted terminology -- the first byte is not
an address, for instance.

I.e., just say something like:

   Subnet number   Subnet mask      Destination descriptor
				    (octets in decimal)
   0		   0		    0
   10.0.0.0	   255.0.0.0	    8 10
   10.229.0.128	   255.255.255.128  25 10 229 0 128

>    In some cases more than one IP subnet may be configured within a
>    given network broadcast domain.  In such cases, a host whose IP
>    address is in one IP subnet in the broadcast domain could communicate
>    directly with a host whose IP address is in a different IP subnet in
>    the same broadcast domain.  In cases where a client is being
>    assigned an IP address on an IP subnet in such a broadcast domain,

Is the term "broadcast domain" the common terminology? I.e, in IPv6,
one would say "multiple subnets on the same link". In IPv4, one might
say "multiple subnets on the same physical network" or something else,
I think. What terminology do other RFCs use (I'm pretty sure this is
described somewhere)? It would be better to be consistent.

>    DHCP clients that do not support this option MUST ignore it if it
>    is received from a DHCP server.  DHCP clients that support this

Presumably they already ignore the option per existing RFCs? I.e, it
seems odd to make it a requirement of *this* spec to specify behavior
on an implementation that "does not support" the option...

>    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

seems like MUST is too strong, and SHOULD would suffice. I.e, it might
be that a client understands the option, but doesn't actually want the
DHCP server to return such an option because it will ignore it or
something.

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

Why this SHOULD? I.e., if it is not a MUST, the server can't count on
this being the case, so what is the benefit?

>    After deriving a subnet number and subnet mask from each
>    destination descriptor, the DHCP client SHOULD check the
>    combination of the network number and the subnet mask for validity.
>    If the network number contains nonzero bits beyond the subnet mask,
>    the client SHOULD discard that route.  For example, the client
>    should not install a route with a destination of 129.210.377.4 and
>    a subnet mask of 255.255.255.128.

I again am uncomfortable with SHOULDs here. I.e, they should be MUSTs
or don't bother. The reasoning is that I assume the reason for
specifying the above is to get consistent and predicatable
behavior. I.e, if a server inserts an option with extra bits, either
all clients should process the route, or all should ignore it. Having
some clients do it one way, and others another does not promote
interoperability.

My personal preference would be to allow extra the bits. It's not that
uncommon to provide a host address and a netmask to indicate a subnet
number. I.e., it's work to figure out which bits should be chopped off
and to actually set them to zero.

But overall, the way clients process this case should be consistent
across all implementations.

>    Because a full routing table can be quite large, the standard 576
>    octet maximum size for a DHCP message may be too short to contain
>    some legitimate Classless Static Route options.   Because of this,
>    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.

This text could use a bit of tweaking. Note that whether an
implementation supports reassembly isn't relevant. The key issue is
what is the largest IP packet that a receiving host is guaranteed to
be able to accept, whether fragemented or not. One would expect it to
be at least as big as the MTU of the interface, but it could be
larger. The text should say something more like:

    client SHOULD set the value of this option to the value of the
    maximum length DHCP message it is willing to accept.

Actually, the above text is rather ambiguous. I.e., does this value
include the DHCP headers (yes, I'd guess). Does it include the IP/UDP
header (I don't know).  The above text comes from 2132, which I'd
argue is unclear. I kind of doubt that this document is the one that
should clarify this language, but if there is agreement on what the
right thing to do is here, perhaps include it here? or writeup a 1
paragraph ID that specifies the right behavior?

>    DHCP servers sending this option MUST use the technique described
>    in [10] for sending options larger than 255 bytes when storing this
>    option in outgoing DHCP packets.   DHCP clients supporting this
>    option MUST support the technique described in [10] when reading
>    this option from incoming DHCP packets.

As written, this document too has a normative reference to the concat
ID.

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

Seems like MAY should be SHOULD. There is no reason to include it in
this case. Right?

Needs an IANA considerations section so that IANA knows to assign a
code point.

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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 28 Sep 2001 11:10:42 -0700

> I think. "classful" is more common.

Classful is not a common english word, so I'm reluctant to use it in
an RFC, even if it's common in the vernacular of network
administrators.  I could change it to "class-based", but I think
"classed" conveys the meaning, plus it's a real word, so my
inclination is to keep it.  I can't see how this can create confusion
- the relevant RFCs are referenced, and a brief definition of the term
is given.

> described somewhere)? It would be better to be consistent.

I like the term "link", but as you say, it's not in common usage for
IPv4.   Physical network has the problem that it's not very
descriptive - what precisely is a physical network?

I've added the following definition:

      "link"

      	   Any set of all network attachment points that will recieve
	   a link-layer broadcast sent on any one of the attachment
	   points.  This term is used in DHCP because in some cases
	   more than one IP subnet may be configured on a link.  DHCP
	   uses a local-network (all-ones) broadcast, which is not
	   subnet-specific, and will therefore reach all nodes
	   connected to the link, regardless of the IP subnet or
	   subnets on which they are configured.

	   A "link" is sometimes referred to as a broadcast domain or
	   physical network segment.

...and I've adjusted the cases where the term "broadcast domain" is
used to use "link" instead.

> on an implementation that "does not support" the option...

I just copied that.   It makes a certain amount of sense to say it -
some implementations of DHCP clients log errors if they receive
unknown options.   Obviously this draft is not the place to fix that
problem, but I don't think this wording causes any problems.

> DHCP server to return such an option because it will ignore it or

The wording here has been changed per Stuart Cheshire's request.   His
concern was that the current wording meant his client had to stop
supporting the Static Routes option (which was my intention).   So
this is no longer recommended.

> this being the case, so what is the benefit?

True.   Stuart pointed this out as well.   It is now a MUST:

   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.

> and to actually set them to zero.

Okay, I've changed the wording to read as follows:

   After deriving a subnet number and subnet mask from each
   destination descriptor, the DHCP client MUST set any bits in the
   subnet number that are zero in the subnet mask to zero.  For
   example, if the server sends a route with a destination of
   129.210.177.132 (hexadecimal 81D4B184) and a subnet mask of
   255.255.255.128 (hexadecimal FFFFFF80), the client will install a
   route with a destination of 129.210.177.128 (hexadecimal
   81D4B180).

> implementation supports reassembly isn't relevant.

I've reworded it a bit (partially at Stuart's request):

   Because a full routing table can be quite large, the standard 576
   octet maximum size for a DHCP message may be too short to contain
   some legitimate Classless Static Route options.  Because of this,
   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.   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.)

> Seems like MAY should be SHOULD. There is no reason to include it in

Okay.   I'd already changed the wording somewhat at Stuart's request -
this represents a somewhat larger change, which Stuart may wish to
contest:

   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 SHOULD NOT include the
   Router or Static Routes options.

> Needs an IANA considerations section so that IANA knows to assign a

Okay:

IANA Considerations

   This DHCP option will require the allocation of an option code in
   the list DHCP option codes that the IANA maintains.

Thanks for all the comments!

			       _MelloN_