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

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

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:[e-mail]] 
> Sent: Saturday, May 07, 2005 11:55 AM
> To: Bernie Volz (volz)
> Cc: David W. Hankins; [e-mail]
> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg