RE: [dhcwg] "Options" field

"Kostur, Andre" <Andre@incognito.com> Thu, 16 May 2002 14:57 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27013 for <dhcwg-archive@odin.ietf.org>; Thu, 16 May 2002 10:57:14 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA17321 for dhcwg-archive@odin.ietf.org; Thu, 16 May 2002 10:57:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16979; Thu, 16 May 2002 10:52:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16959 for <dhcwg@optimus.ietf.org>; Thu, 16 May 2002 10:52:50 -0400 (EDT)
Received: from portal.incognito.com (PORTAL.INCOGNITO.COM [207.102.214.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26855 for <dhcwg@ietf.org>; Thu, 16 May 2002 10:52:36 -0400 (EDT)
Received: from homerdmz.incognito.com ([207.102.214.106] helo=homer.incognito.com.) by portal.incognito.com with smtp (Exim 3.33 #1) id 178MTo-0002K5-00; Thu, 16 May 2002 07:43:44 -0700
Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id <2ZV8SSX3>; Thu, 16 May 2002 07:58:30 -0700
Message-ID: <4FB49E60CFBA724E88867317DAA3D1984958A3@homer.incognito.com.>
From: "Kostur, Andre" <Andre@incognito.com>
To: 'Ted Lemon' <Ted.Lemon@nominum.com>, "Kostur, Andre" <Andre@incognito.com>
Cc: DHCP IETF mailing list <dhcwg@ietf.org>, 'Katia Linker' <KatiaL@radlan.com>
Subject: RE: [dhcwg] "Options" field
Date: Thu, 16 May 2002 07:58:20 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FCEA.1E2C96B0"
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org

> > I don't agree with your interpretation.  Quoting from the RFC:
> >
> > "A DHCP client must be prepared to receive DHCP messages 
> with an 'options'
> >  field of at least length 312 octets"
>                                                                ^^^^^^
> 
> This section of the document says _nothing_ about sending 
> messages.   It 
> specifies what a client must be prepared to receive.   This is not an 
> interpretation - it's what the text says.   It says that a 
> DHCP client must 
> be able to handle _at least_ a 576-byte packet on input.   
> This means that 
> a DHCP server cannot assume that any client can accept a 
> packet larger than 
> 576 bytes unless the client says it can by sending the 
> maximum message size 
> option.

I don't disagree that in the absence of information to the contrary, the
largest packet that a server can expect the client to handle is 576 bytes.
However, if the client sends option 57 specifying that the largest DHCP
packet that it is willing to handle is 1400 bytes, then the options field is
1400 - 286 = 1136 bytes.  Thus, the maximum size that the options field may
be is much larger than the 312 bytes mentioned in RFC 2131.  (The data
within the options field may not take up the entire field).