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

Simon Kelley <simon@thekelleys.org.uk> Sat, 07 May 2005 15:54 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DURdr-0002nB-5a; Sat, 07 May 2005 11:54:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DURdp-0002mN-Kn for dhcwg@megatron.ietf.org; Sat, 07 May 2005 11:54:57 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23511 for <dhcwg@ietf.org>; Sat, 7 May 2005 11:54:55 -0400 (EDT)
Received: from cpc4-cmbg4-4-0-cust135.cmbg.cable.ntl.com ([81.108.205.135] helo=thekelleys.org.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DURsY-0004Wy-TU for dhcwg@ietf.org; Sat, 07 May 2005 12:10:11 -0400
Received: from desk.thekelleys.org.uk ([192.168.0.3] helo=thekelleys.org.uk) by thekelleys.org.uk with esmtp (Exim 3.35 #1 (Debian)) id 1DURdc-0000Tt-00; Sat, 07 May 2005 16:54:44 +0100
Message-ID: <427CE4D5.2020002@thekelleys.org.uk>
Date: Sat, 07 May 2005 16:55:01 +0100
From: Simon Kelley <simon@thekelleys.org.uk>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.6) Gecko/20040413 Debian/1.6-5
X-Accept-Language: en
MIME-Version: 1.0
To: "Bernie Volz (volz)" <volz@cisco.com>
Subject: Re: [dhcwg] DHCPv4 - definition of maximum message size.
References: <8E296595B6471A4689555D5D725EBB2122D41B@xmb-rtp-20a.amer.cisco.com>
In-Reply-To: <8E296595B6471A4689555D5D725EBB2122D41B@xmb-rtp-20a.amer.cisco.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 2.6 (++)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Content-Transfer-Encoding: 7bit
Cc: dhcwg@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org

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
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg