RE: [dhcwg] DHCPv4 - definition of maximum message size.

["Bernie Volz \(volz\)" <[e-mail]>]

It is too bad Barr Hibb's "RFC 2131 Implementation Issues" draft has
expired. See text below. The key part is:
        o  Clients SHOULD communicate their link-layer frame size to the

           DHCP server via the DHCP MTU option. 

So, this is *LINK-LAYER* frame size.

I believe this 576 size comes from RFC 791:

  Total Length:  16 bits

    Total Length is the length of the datagram, measured in octets,
    including internet header and data.  This field allows the length of
    a datagram to be up to 65,535 octets.  Such long datagrams are
    impractical for most hosts and networks.  All hosts must be prepared
    to accept datagrams of up to 576 octets (whether they arrive whole
    or in fragments).  It is recommended that hosts only send datagrams
    larger than 576 octets if they have assurance that the destination
    is prepared to accept the larger datagrams.

    The number 576 is selected to allow a reasonable sized data block to
    be transmitted in addition to the required header information.  For
    example, this size allows a data block of 512 octets plus 64 header
    octets to fit in a datagram.  The maximal internet header is 60
    octets, and a typical internet header is 20 octets, allowing a
    margin for headers of higher level protocols.

So, it should be treated as the "IP + UDP + DHCP" packet size.

---

     2.19. Size of a BOOTP/DHCP frame 

        The description in RFC 2131 relating to the size constraints of
DHCP 
        packets (Page 10, first paragraph after Table 1, section 2) is 
        inadequate. 


     2.19.1. Minimum size. 

        RFC 951 states that a minimum BOOTP frame is 300 octets in
length.  
        Some BOOTP relay agents have been known to drop frames of less
than 
        300 octets.  RFC 951 is explicit on this point, but RFC 2131
just 
        refers to RFC 951.  Since DHCP is intended to be backward
compatible 
        with BOOTP, the protocol should continue to observe this lower
bound. 

        RECOMMENDATIONS: 

        o  Text should be added stating explicitly that the minimum size

           of a DHCP frame is 300 octets. 


     2.19.2. Maximum Size, MTU, and Message Size option 

        It has been thought necessary to avoid fragmentation of the IP 
        packets in DHCP/BOOTP due to concerns that some clients would be

        unable to reassemble fragments before the IP stack is properly 
        configured.  RFC 951 states "For simplicity it is assumed that
the 
        BOOTP packet is never fragmented". Regardless of theoretical 
        limitations in IP stack implementations, it is certain that
there are     
        several DHCP/BOOTP implementations, at both ends of the
protocol, 
        which will not reassemble. 

        Various comments in the WORKING GROUP imply that fragmentation
could 
        be avoided were the client consistently to include the MTU of
the 
        link layer interface. But clients cannot be expected to be
omniscient 
        about other media over which packets travel en route to servers.

        Servers that must be endowed with this knowledge, which they
MUST use 
        to avoid packet fragmentation. 

        Once the IP stack is configured, and the IP stack is fully 
        configured, the aforementioned limitation ceases to exist, and
later 
        stages of the protocol could allow larger packets (up to the UDP

        limit).  DHCPINFORMs, especially, could benefit from this
relaxation.  
        There probably should be explicit text to allow larger packets 
        (presumably up to the maximum PDU size) for later stages of the 
        protocol. 

        A number of clients send small packets with the assumption that 
        servers will not return a packet that is any larger than the one

        received from the client.  The client MUST NOT make this
assumption. 
        If the client cannot process a response larger than a certain
size, 
        the client MUST use the message size option to inform servers of
this 
        size. Note that this is NOT the same option as the MTU. 

        RECOMMENDATIONS: 

        o  Servers and relay agents MUST ensure that IP datagram 
           fragmentation does not occur at any stage in the protocol 
           before the client IP stack is fully configured. 

        o  Clients SHOULD communicate their link-layer frame size to the

           DHCP server via the DHCP MTU option. 

        o  Clients MUST NOT assume that servers will return a packet no 
           larger than the one they send. If the client has a limit on
the 
           size of the packet that it can process it MUST convey that 
           limit to the server in the "maximum message size" option (57)


        o  Page 21, second paragraph, section 3.5, the first sentence 
           SHOULD be changed to "The client SHOULD include the 'maximum 
           DHCP message size' option to let the server know how large
the 
           server may make its DHCP messages, and the value of this
option 
           SHOULD be the MTU of the [client] network interface being 
           configured." 

        o  The WORKING GROUP SHOULD consider whether to allow 
           fragmentation of packets after the client is fully
configured, 
           and how servers can divine this fact (e.g. a non-zero 
           "ciaddr").  

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> On Behalf Of David W. Hankins
> Sent: Friday, May 06, 2005 2:53 PM
> To: [e-mail]
> Subject: Re: [dhcwg] DHCPv4 - definition of maximum message size.
> 
> On Fri, May 06, 2005 at 12:09:31PM +0100, Simon Kelley wrote:
> > Does the value in "maximum message size" option (option 
> code 56) include 
> > the IP and UDP headers?
> > 
> > Neither RFC2131 or RFC2132 ever state this explicitly, but they are 
> > self-consistent if it's the case. RFC2132 states that the 
> minimum legal 
> > value is 576 octets, which equals IP header + UDP header + 
> fixed DHCP 
> > fields + the minimum 312 octet options field specified in RFC2131.
> 
> To add to your confusion, ISC DHCP calculates this as:
> 
> 	'mms' - (ethernet + ip + udp + dhcp header sizes)
> 
> Should the 'mms' be less than 576, we use 576.
> 
> I suspect our inclusion of the ethernet header size in this 
> calculation
> is incorrect, since as you mention it doesn't add up if you 
> use a 312 byte
> options field.
> 
> > I ask because I've just come across a client which 
> advertises a maximum 
> > message size of 548. Presumably this is broken, and there's 
> a chance 
> > that the client is also misinterpreting a "576" maximum 
> message size 
> > option _from_ a DHCP server  and could potentially try and 
> use 28 bytes 
> > that the server cannot receive.
> 
> As I mentioned above, I believe our DHCP server would simply 
> not observe
> this mms, and pretend as though it was not supplied.
> 
> > If the wise ones here can confirm that this really is an 
> RFC violation, 
> > I'll submit a bug report to the vendor of the client.
> 
> I have no such wisdom.
> 
> -- 
> David W. Hankins		"If you don't do it right the 
> first time,
> Software Engineer			you'll just have to do 
> it again."
> Internet Systems Consortium, Inc.		-- Jack T. Hankins
> 

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg