On Mon, Apr 28, 2008 at 07:28:11PM -0400, Bernie Volz (volz) wrote: > If we were really concerned about option numbers being hijacked, we > should request that IANA randomly pick option numbers from the full > range - as then you'd never know what the next value from IANA would be. > (The issue exists for the messages - someone could use message 255 as it > is unlikely IANA would assign that message number for a long time.) Well, I'm concerned about people hijacking options, but I still don't think I'd direct IANA to allocate options randomly. First, more work for them, second, I can see an implementation case where DHCP software allocates a fixed array (compiled in probably) for option code definitions. Allocating options randomly deselects the ability to index this array directly by option code (as was done in e.g. ISC DHCP 3.0.x). We used to do something like this, we might have done something much more like this (but I decided to go a different route), but we don't do either method anymore, largely in order to support the Vendor- Identified spaces as 32-bit option code spaces (where the enterprise- id is just an option code). I don't knowFrom dhcwg-bounces at ietf.org Mon Apr 28 18:52:59 2008 Return-Path: <dhcwg-bounces at ietf.org> X-Original-To: dhcwg-archive at megatron.ietf.org Delivered-To: ietfarch-dhcwg-archive at core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80B8D3A6AE4; Mon, 28 Apr 2008 18:52:59 -0700 (PDT) X-Original-To: dhcwg at core3.amsl.com Delivered-To: dhcwg at core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8F8A3A6A7B for <dhcwg at core3.amsl.com>; Mon, 28 Apr 2008 18:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.3 X-Spam-Level: X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[AWL=3.299, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Lt55OmNmYFHI for <dhcwg at core3.amsl.com>; Mon, 28 Apr 2008 18:52:47 -0700 (PDT) Received: from hankinsfamily.info (the.hankinsfamily.info [204.152.186.148]) by core3.amsl.com (Postfix) with ESMTP id 7CE9E3A6971 for <dhcwg at ietf.org>; Mon, 28 Apr 2008 18:52:47 -0700 (PDT) Received: from navarre.mercenary.net (c-24-6-89-32.hsd1.ca.comcast.net [24.6.89.32]) (authenticated bits=0) by hankinsfamily.info (8.13.8/8.13.8) with ESMTP id m3T1qoGd028775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO) for <dhcwg at ietf.org>; Mon, 28 Apr 2008 18:52:50 -0700 Received: by navarre.mercenary.net (Postfix, from userid 1000) id 822CD56624; Mon, 28 Apr 2008 18:52:52 -0700 (PDT) Date: Mon, 28 Apr 2008 18:52:52 -0700 From: "David W. Hankins" <David_Hankins at isc.org> To: dhcwg at ietf.org Message-ID: <20080429015252.GD11894 at isc.org> References: <200804281706.32908.budm at weird-solutions.com> <8E296595B6471A4689555D5D725EBB210726EBC6 at xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 In-Reply-To: <8E296595B6471A4689555D5D725EBB210726EBC6 at xmb-rtp-20a.amer.cisco.com> User-Agent: Mutt/1.5.9i Subject: Re: [dhcwg] DHCPv6 message type X-BeenThere: dhcwg at 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 at ietf.org?subject=unsubscribe> List-Post: <mailto:dhcwg at ietf.org> List-Help: <mailto:dhcwg-request at ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request at ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="==============05831869==" Sender: dhcwg-bounces at ietf.org Errors-To: dhcwg-bounces at ietf.org
On Mon, Apr 28, 2008 at 07:28:11PM -0400, Bernie Volz (volz) wrote: > If we were really concerned about option numbers being hijacked, we > should request that IANA randomly pick option numbers from the full > range - as then you'd never know what the next value from IANA would be. > (The issue exists for the messages - someone could use message 255 as it > is unlikely IANA would assign that message number for a long time.) Well, I'm concerned about people hijacking options, but I still don't think I'd direct IANA to allocate options randomly. First, more work for them, second, I can see an implementation case where DHCP software allocates a fixed array (compiled in probably) for option code definitions. Allocating options randomly deselects the ability to index this array directly by option code (as was done in e.g. ISC DHCP 3.0.x). We used to do something like this, we might have done something much more like this (but I decided to go a different route), but we don't do either method anymore, largely in order to support the Vendor- Identified spaces as 32-bit option code spaces (where the enterprise- id is just an option code). I don't know if such if such deselection is universal, but I think at least minimalistic software is likely to benefit from having the "used" option codes in as compact a binary space as possible, if for no other reason than to make it possible to index an array of 'dhcp options' directly by option code. > I asked at the DHC WG meeting when I presented the draft if it would > help if I removed the reserved options section, but people still didn't > like the draft even if it had just the vendor-specific message. I don't > think we *need* the reserved options, it just made life a bit easier. We could check the minutes, but my memory of the WG meeting is that, after some discussion of many of these talking points, we left the discussion after an objection was raised that if one were to put this mechanism in an RFC, then hypothetical people might believe it to be a good idea, implying this to be an undesirable end result. I thought this was rather remarkable at the time as, although I am not terribly experienced in IETF matters, I can think of several RFCs that were not, are not, and probably never will be good ideas, and many drafts (such as draft-ietf-wrec-wpad) that would have served the network much better as an RFC standard despite its marked lack of visitation by the good idea fairy. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
Attachment:
pgpE5yqTbvXbk.pgp
Description: PGP signature
_______________________________________________ dhcwg mailing list dhcwg at ietf.org https://www.ietf.org/mailman/listinfo/dhcwg