Subject: [dhcwg] VIV*O options.

From: "David W. Hankins" <[email-masked]>
Date: Wed, 17 May 2006 11:57:46 -0700

Does anyone know of a client or server that has implemented VIV*O (RFC3925)?
I'm looking for targets for interoperability testing.

RFC4243 relay agents would be interesting too.

While looking at this, I had to come to grips with a minor code reuse
problem I'd like to solicit opinions on.

We currently use the same code to dissect the options buffer as we do
any encapsulated space (so, VIV*O would use this as well).

This loop that traverses options looks for PAD and END options, which
RFC 3925 explicitly states are not special cases, with no special
handling.  Unless I'm mistaken, RFC 4243 makes no mention.

That means I get to add more instructions to this loop, or write a new
loop, neither of which I particularly fancy.

However, enterprise id 0 is reserved according to IANA, which I take to
mean is an illegal value, so it shouldn't appear in packets at all.

My most-code-reused solution, then, is to use 0x00000000 as both PAD
and END options for this encapsulated space (END trumps PAD, so this
causes the server to stop processing the buffer if it's encountered -
a zero is effectively an error condition).

That would be true for any encapsulated space with no defined END option.

What are folks opinions on this approach, not just for VIV*O, but for
encapsulated spaces in general?

-- 
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
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Andre Kostur <[email-masked]>
Date: Wed, 17 May 2006 12:17:26 -0700

> any encapsulated space (so, VIV*O would use this as well).

As long as you start after the Enterprise OID (and data length), that 
shouldn't be an issue.

> handling.  Unless I'm mistaken, RFC 4243 makes no mention.

I'd interpret 42423 to align with 3925.  Sub-options 0 and 255 have no 
special meaning.

> mean is an illegal value, so it shouldn't appear in packets at all.

I'm a little confused... what does the Enterprise OID have to do with 
parsing the sub-optioned space?

> a zero is effectively an error condition).

Even more confused... where's that 4-byte value coming from (in the 
context of this discussion)?  And, what PAD option?  There is no pad.  
No END either.

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 17 May 2006 13:12:04 -0700

> As long as you start after the Enterprise OID (and data length), that 

That's precisely the rub: this would use the same loop to process
VIV*O options (and also their contents, but that's not the point).

That is, VIV*O options (DHCP codes 124 and 125) are merely an
encapsulated space whose tag width is 4, and whose length width is
1, and which generally contain different encapsulated spaces.  Compare
DHCP which is 1/1, DHCPv6 which is 2/2.

I'm suggesting that the generic functions which implement that would
merely accept widths of 1, 2, 4 for code fields, and 1, 2 for length
fields - any combination.  1/2 is legal, 2/1 is legal.

> I'd interpret 42423 to align with 3925.  Sub-options 0 and 255 have no 

I agree, except that it is IANA that defines enterprise-id 0 to be
reserved (so I expect it will never be used).  I guess I mean that
RFC3925 defers to IANA in my opinion.

---

From: Bud Millwood <[email-masked]>
Date: Thu, 18 May 2006 08:44:46 +0200

> fields - any combination.  1/2 is legal, 2/1 is legal.

What you suggest is how we do it. The width of the tag, len and type fields 
are primarily defined by a "Protocol Attributes" class, but the meta-data for 
any given option can override those (individually) if need be.

So I'd describe the option in 3925 as a regular DHCPv4 option, meaning 1/1, 
but then provide these settings for the option's meta-data:

     type = subencoded
     subtag_width = 4
     sublen_width = 1

This allows us to iterate over the same loop, reading tag/len fields of any 
size.

Using a default of 1/1 or 2/2, but providing option-specific overrides seems 
to work well in practice.

- Bud

Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687
mailto:[email-masked]