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

[Thomas Narten <[e-mail]>]

Ralph Droms <[e-mail]> 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
[e-mail]
http://www1.ietf.org/mailman/listinfo/dhcwg