Re: [dhcwg] WGLC on draft-ietf-dhc-v4configuration-04 - respond by Jan. 31

Ole Troan <> Tue, 28 January 2014 13:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 39A611A03F9 for <>; Tue, 28 Jan 2014 05:56:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bt0N-ESf6XKc for <>; Tue, 28 Jan 2014 05:56:18 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DEB571A03F6 for <>; Tue, 28 Jan 2014 05:56:17 -0800 (PST)
X-Files: signature.asc : 496
X-IronPort-AV: E=Sophos; i="4.95,736,1384300800"; d="asc'?scan'208"; a="3633018"
Received: from ([]) by with ESMTP; 28 Jan 2014 13:56:14 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s0SDuDvD029356 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 Jan 2014 13:56:14 GMT
Content-Type: multipart/signed; boundary="Apple-Mail=_83477F95-409A-49E9-A9D7-C1E2F844AA88"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ole Troan <>
In-Reply-To: <>
Date: Tue, 28 Jan 2014 14:56:12 +0100
Message-Id: <>
References: <>
To: "Bernie Volz (volz)" <>
X-Mailer: Apple Mail (2.1827)
Cc: DHC WG <>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-v4configuration-04 - respond by Jan. 31
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Jan 2014 13:56:19 -0000

> One other point regarding Ole's comments below - Ole, I don't think it would be possible to handle IPv4 configuration by just adding a DHCPv6 DHCPv4 container option to encode the various v4 options as some of the information is conveyed in non-option fields in the DHCPv4 (BOOTP) packet. Yes, you could have an option that has those fixed fields followed by a variable length option encoding area, but that seems much more complex than just encoding the DHCPv4 packet (as we are proposing to do with the new DHCPv6 messages). Also, encoding as an option of options would also require piggybacking the request with DHCPv6 requests themselves which has other implications -- so I think that design, while possible, is much less optimum (though we can certainly disagree on this point).

just to make it clear; I do not in any way want to give the impression that I'm in favour of this mode. I'm not.