Re: [dhcwg] Question about RFC 3396 Encoding Long Options in DHCPv4

David Hankins <dhankins@google.com> Tue, 30 November 2010 21:16 UTC

Return-Path: <dhankins@google.com>
X-Original-To: dhcwg@core3.amsl.com
Delivered-To: dhcwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF1C23A6C16 for <dhcwg@core3.amsl.com>; Tue, 30 Nov 2010 13:16:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.976
X-Spam-Level:
X-Spam-Status: No, score=-109.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoceMRtcjmW9 for <dhcwg@core3.amsl.com>; Tue, 30 Nov 2010 13:16:26 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 3853A3A6C30 for <dhcwg@ietf.org>; Tue, 30 Nov 2010 13:16:25 -0800 (PST)
Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id oAULHaAd003304 for <dhcwg@ietf.org>; Tue, 30 Nov 2010 13:17:37 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1291151857; bh=CJhPQsLksZlWj19BMFrXPXQ3TIY=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Content-Type; b=JrShhINjrUF8m1Cu8uDgHwezFlU873y3ApxkFscImJl2jxaOUe8BFAgEd0uhAlJS3 +/dt+6GdecTI5XG5UAWQw==
Received: from yxm34 (yxm34.prod.google.com [10.190.4.34]) by kpbe12.cbf.corp.google.com with ESMTP id oAULH7T8004937 for <dhcwg@ietf.org>; Tue, 30 Nov 2010 13:17:35 -0800
Received: by yxm34 with SMTP id 34so4005381yxm.22 for <dhcwg@ietf.org>; Tue, 30 Nov 2010 13:17:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=fUu4d6khiBjYmP3rLxV0ffXZwBpoKOo14cacXZg4+54=; b=UyHwLQ93/n4KF3SjNq30wG2CMZY12ea6bvf7N4SGNt96gXzLk8Se7LPFfdPZPF1+vO e1Uw+zKz7xYJfngxVFNA==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=oqtOmSH0KjOBLSwwN8mDPhI+Wb3zqj1njiAOm/bB4JlLRDjidI0FMl3ypM7+17DbWp UBYMDtMJH3LNCm7/sq9A==
MIME-Version: 1.0
Received: by 10.101.85.3 with SMTP id n3mr4892258anl.267.1291151855446; Tue, 30 Nov 2010 13:17:35 -0800 (PST)
Received: by 10.100.208.18 with HTTP; Tue, 30 Nov 2010 13:17:35 -0800 (PST)
In-Reply-To: <AANLkTikVS2M=knDfEib4PbCoKCu+E_VBL99jyevkshjR@mail.gmail.com>
References: <AANLkTikVS2M=knDfEib4PbCoKCu+E_VBL99jyevkshjR@mail.gmail.com>
Date: Tue, 30 Nov 2010 13:17:35 -0800
Message-ID: <AANLkTinY_4yg5mj+1d2M-v9h-nVVF8SqTDrVGc3yGMUb@mail.gmail.com>
From: David Hankins <dhankins@google.com>
To: dhcwg@ietf.org
Content-Type: multipart/alternative; boundary=001636ed67f2b1eb3104964bb709
X-System-Of-Record: true
Subject: Re: [dhcwg] Question about RFC 3396 Encoding Long Options in DHCPv4
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Nov 2010 21:16:27 -0000

On Mon, Nov 29, 2010 at 10:51 PM, VithalPrasad Gaitonde
<gvithal@gmail.com>wrote;wrote:

> As documented in RFC 3396, the sname and file fields of the DHCP packet can
> be used for option values longer than 255 octets.
> Using sname (64 octets) and file (128 octets) gets additionals 192 octets
> of space in addition to 255 octets in the options field.
> Is my understanding correct ?
>

No - option overloading doesn't specifically enable option concatenation.
 It only makes these fields available to carry options in addition to the
options space.  Single options may appear in these fields, and long options
may be divided but still contained entirely in the main options space (if
all the fragments fit).

If yes, for options such as option 119 (Domain Search Option RFC 3397),
> there would be situations when the option value is longer then 447 octets
> (255+ 192). Are there any solutuions to these cases - RFC 3396 does not seem
> to solve this problem completely.
>

RFC 3396 does not solve this problem completely, but not for the reason you
state.  Theoretically, RFC 3396 permits any number of instances of a given
option code, so there is no strict upper limit to option content size except
that it must be able to fit within the packet.

So how big is a packet?  This is where things get confusing.  The short
version of the story is that there is a 512 octet limitation (which was
intended as a minimum in RFC 2131) on DHCPv4 packet size, and that although
clients can advertise larger capabilities by including a max-message-size
option in their requests, relay agents have no similar way to signal their
own limitations (and relay agents are the most problematic case anyway)...so
the 512 octet limitation sticks.

This means the 'options' field can be at most 248 octets (less 4 octets for
the MAGIC value).  So there are a series of 244, 128, 64 octet fields for
option storage, and your options (of whatever sizes and fragmentation) must
fit within these fields in order.  If you have a DHCPv4 option longer than
(244 + 128 + 64 - (2 + 2 + 2 + 3)) = 427 octets, then DHCPv4 cannot
practically carry it.  The 2's in the subtraction refer to the TL part of
the TLV's, the '3' refers to the TLV of the dhcp-message-type option.  If
you also needed to deliver other options, this '3' value would get
considerably larger, further reducing the available space for a maximally
sized option payload.