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

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Sat, 7 May 2005 11:59:24 -0400

Yeah, if Barr doesn't want to continue work on this document, it would
be good to get someone to take it on. You willing to volunteer (assuming
Barr isn't interested)?

I do have a copy of the latest version Barr submitted (which is
attached).

- Bernie 

> -----Original Message-----
> From: Simon Kelley [mailto:[email-masked]] 
> Sent: Saturday, May 07, 2005 11:55 AM
> To: Bernie Volz (volz)
> Cc: David W. Hankins; [email-masked]
> Subject: Re: [dhcwg] DHCPv4 - definition of maximum message size.
> 
> Bernie Volz (volz) wrote:
> > It is too bad Barr Hibb's "RFC 2131 Implementation Issues" draft has
> > expired. See text below. The key part is:
> 
> That's a valuable document which I'd not come across before, thanks.
> 
> In case is ever gets revived, I have an addition to section 2.21, 
> "Option Ordering"
> 
>  >A number of clients exist that require that the DHCP message type be
>  >the first option (after the magic cookie).  We SHOULD restate that
>  >the client MUST NOT make any such assumption.  The only known
>  >ordering constraint concerns option 82, which is last.  CMTS vendors
>  >want it to be last, but suppose someone else wants their pet option
>  >to be last also -- how would we resolve this conflict?
> 
> There's at least on widely deployed client (The Intel PXE 
> client) which
> depends on option 60 (vendor class identifier) preceeding option 43
> (Vendor specific information.) So that's another constraint to add to
> the list.
> 
> 
> 
> >         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.
> > 
> 
> That's clear, I'll log a bug report against the client which sends a 
> Max. message of 548.
> 
> Cheers,
> 
> Simon.
> 
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg