Subject: [dhcwg] DHCPv6 - Experimental Message (& Option) Codes?

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 2 Feb 2007 21:43:05 -0500

Before I write up the draft (individual submission), what do folks think
about having IANA allocate a number of DHCPv6 message codes for
experimental use.

Each of these messages would be encoded as <1-octet msg-type><4-octet
enterprise-id><enterprise-specific>.

This would allow the same message codes to be used by multiple
enterprises (and within an enterprise) without collisions.

While technically 1 message code would do (and I'd be happy with that),
it might be best to allocate 16 codes?

These should be relayed by relay agents.

---

A second proposal (part of the same draft) is to also have IANA reserve
a number of option codes for experimental use. These could *ONLY* be
used within the experimental messages codes mentioned above (never in
"normal" DHCPv6 messages).

The reason for this is that it would allow the experimental messages to
contain both "normal" DHCPv6 options and these experimental options.
This would avoid the need for these messages to encode private option
codes in Vendor-Specific messages or use other techniques to separate
the "official" option space from the private space.

With 65,535 option codes available, I can't see that allocating say
1,024 for this purpose would cause much hardship for us down the road.
Perhaps 1,024 is way to much and 256 would do.

Again, these experimental option codes MUST NOT appear in the "normal"
DHCPv6 messages - they may only be used in the experimental messages --
but the important point is that they would never conflict with IANA
assigned numbers.

So, let me know if you would be strongly opposed to these ideas or
whether you might support them (subject to the I-D being acceptable
...). Don't ask for me to give you a use at this time.

- Bernie

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 9 Feb 2007 19:40:49 -0500

Second try to solicit some feedback ... write draft or bad idea?

- Bernie

-----Original Message-----
From: Bernie Volz (volz) 
Sent: Friday, February 02, 2007 9:43 PM
To: [email-masked]
Subject: [dhcwg] DHCPv6 - Experimental Message (& Option) Codes?

---

- Bernie

---

From: "Andre Kostur" <[email-masked]>
Date: Fri, 9 Feb 2007 16:55:31 -0800

I'm not sold on the idea yet.  Particularly, I'm concerned about
"experimental" options that end up getting used in some vendor's
products, and they become "standard" options simply because they're used
everywhere.  Kind of like the PXE (PXElinux?) options.  They were
defined in the site-local space,  but since they have become used in so
many different sites, they effectively became standard options.

Regards,
 
Andre Kostur
Incognito Software Inc.
Senior Software Design Engineer
T: +1(604)678-2864
F: +1(604)688-4339
E: [email-masked]
 
www.incognito.com

-----Original Message-----
From: Bernie Volz (volz) [mailto:[email-masked]] 
Sent: Friday, February 09, 2007 4:41 PM
To: [email-masked]
Subject: RE: [dhcwg] DHCPv6 - Experimental Message (& Option) Codes?

- Bernie

-----Original Message-----
From: Bernie Volz (volz)
Sent: Friday, February 02, 2007 9:43 PM
To: [email-masked]
Subject: [dhcwg] DHCPv6 - Experimental Message (& Option) Codes?

---

- Bernie

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 9 Feb 2007 20:51:18 -0500

That indeed is my biggest concern. And, sadly there is no good way to
prevent this from happening and why I too am reluctant to do it. All we
can offer is words such as MUST NOT appear in anything but experimental
messages. A bigger stick would be to require clients and servers to
discard any non-experimental messages with these options in them, but
that adds to the burden of clients and servers.

On the flip side there's nothing from preventing someone from picking a
high option number today and using it. It is unlikely that it will
collide for a long time (if ever)! Perhaps we should have IANA use a
random number generator to assign option numbers -- that means the risk
of a collision is the same as any other number.

- Bernie

-----Original Message-----
From: Andre Kostur [mailto:[email-masked]] 
Sent: Friday, February 09, 2007 7:56 PM
To: Bernie Volz (volz); [email-masked]
Subject: RE: [dhcwg] DHCPv6 - Experimental Message (& Option) Codes?

Regards,
 
Andre Kostur
Incognito Software Inc.
 
www.incognito.com

-----Original Message-----
From: Bernie Volz (volz) [mailto:[email-masked]] 
Sent: Friday, February 09, 2007 4:41 PM
To: [email-masked]
Subject: RE: [dhcwg] DHCPv6 - Experimental Message (& Option) Codes?

- Bernie

-----Original Message-----
From: Bernie Volz (volz)
Sent: Friday, February 02, 2007 9:43 PM
To: [email-masked]
Subject: [dhcwg] DHCPv6 - Experimental Message (& Option) Codes?

---

- Bernie

---

From: Ted Lemon <[email-masked]>
Date: Sat, 10 Feb 2007 12:49:30 -0700

> Second try to solicit some feedback ... write draft or bad idea?

Seems fine.

---

From: "David W. Hankins" <[email-masked]>
Date: Sun, 11 Feb 2007 05:27:01 +0000

> Second try to solicit some feedback ... write draft or bad idea?

Run the risk of Balkanizing DHCPv6?  Why not.  Might do it some good.

Write the draft, but two comments.  I don't see why it needs
experimental option codes since its uses an enterprise ID in the
packet header...why not just use VSIO?

Second, I don't see why you need a range of experimental message
codes.  We can't predict how many will be neccessary.  Best just
allocate one message, and if a particular enterprise wants multiple
messages, they can do so with their enterprise-id specific
formatting after the break.

Or if some specific use case comes up where multiple message types
are the best way to do it...

-- 
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

---

From: "David W. Hankins" <[email-masked]>
Date: Sun, 11 Feb 2007 05:48:33 +0000

On Fri, Feb 09, 2007 at 08:51:18PM -0500, Bernie Volz (volz) wrote:
> Perhaps we should have IANA use a

In DHCPv4, ISC DHCP used tables of 256 buckets to map option spaces.

So although a lot of DHCPv4 option codes weren't allocated (such as
in the NWIP sub-space, or similar...256 buckets of NWIP sub-options,
of which a dozen were used), we had a lot of "unknown-xxx"'s in
static config in tables in C code.  A frightening number of them.

Quite probably "too many".

Now obviously that doesn't scale for DHCPv6...there are fewer DHCPv6
options than there ever were DHCPv4 options, and the table would be
256 times as large...65536 buckets.  That's just over-the-top waste.

Before we updated software for DHCPv6 (this is in 3.1.0, downloadable
today), we chose to use a method where we only had to enumerate the
codes that were in use, without having to list the gaps inbetween.
The unknown-xxx's became dynamically manufactured upon demand.  This
was somewhat easy for us for the non-intuitive reason that our array
structure already had a field for the option code within each array
bucket (even though the code was also its index into the array), and
existing option-processing software used this field generally.  Without
that field there and in use, I wonder how much we would have had to
rewrite...and hence we might have done this differently.

Because we had another choice, one that we intentionally decided
against.  We could have chosen to simply use a smaller array, merely
adding an upper bounds so that attempts aren't made to check for options
off the end of the array.  For all I know, that might make more sense
in some DHCP software architectures.

In that case, we would have had to make an array that is as big
as the highest numbered option code.  If we assign code 65535
tomorrow...that dooms such an implementation to code rewrites
(or accepting a table that large).

So, random codes work for me, and I'm certainly in favor of giving
people a reason to get their codes allocated properly, but I wonder
if it's too clever...as it may hurt some software implementors.