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

["Barr Hibbs" <[e-mail]>]

funny you should bring that up, Bernie...  I was just thinking the other day
that I ought to poll Rob again to see if he's up to the task of finishing
the work on this draft, since I believe that it's still needed to complete
the standardization process of DHCPv4....

--Barr


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf Of
> Bernie Volz (volz)
> Sent: Friday, May 06, 2005 12:06
> To: David W. Hankins; Simon Kelley
> Cc: [e-mail]
> Subject: RE: [dhcwg] DHCPv4 - definition of maximum message size.
>
>
> 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


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