RE: [dhcwg] -20e rev of DHCPv6 spec

["Thirumalesh Bhat" <[e-mail]>]

The text for the user and vendor class options is attached below for
review:

User Class Option

	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       OPTION_USER_CLASS       |           option-len          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |	             		user class data
|
     |                             . . .                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code   TBD

option-len    Variable; If n user classes are carried by the option, the
length of the option option-len = sum of each of the user class lengths
+ 2*n.

option-data   The user classes carried by the client.

This option is used by the client to optionally identify itself as
representing a user or application. The DHCP server uses the user class
information to allocate addresses from a specific pool or select a
specific configuration option.

	
The user class option may contain one or more instances of user class
data. Each instance of the user class data is formatted as follows:

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
     |       user class1 len         |           user1 class data    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+


The user class length is two octets long and specifies the length of the
opaque user class data in network byte order. 

Servers may interpret the meanings of multiple class specifications in
an implementation dependent or configuration dependent manner, and so
the use of multiple classes by a DHCP client should be based on the
specific server implementation and configuration which will be used to
process that User class option. Servers not equipped to interpret the
user class information sent by a client MUST ignore it (although it may
be reported).


Vendor Class Option

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      OPTION_VENDOR_CLASS      |           option-len          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          option-data                          |
     |                             . . .                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code   TBD

option-len    Variable

option-data   The information is an opaque object of option-len octets,
presumably interpreted by vendor-specific code on the clients and
servers

This option is used by clients and servers to exchange vendor- specific
information. The definition of this information is vendor specific.
The vendor is indicated in the vendor class identifier option. Servers
not equipped to interpret the vendor-specific information sent by a
client MUST ignore it (although it may be reported). Clients which do
not receive desired vendor-specific information SHOULD make an attempt
to operate without it, although they may do so(and announce they are
doing so) in a degraded mode.

If a vendor potentially encodes more than one item of information in
this option, then the vendor SHOULD encode the option using
"Encapsulated vendor-specific options" as described below:

The Encapsulated vendor-specific options field SHOULD be encoded as a
sequence of code/length/value fields of identical syntax to the DHCP
options field.

When encapsulated vendor-specific extensions are used, each of the
encapsulated options is formatted as follows.

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       opt code                |                  opt len      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          option-data                          |
     |                             . . .                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


References

   [1] Stump, G., Droms, R., Y.Gu, R.Vyaghrapuri, A. Demirtjis, B.
Beser, J. Privat "The User Class Option For DHCP", RFC 3004, November
2000.
   [2] S. Alexander and R. Droms.  DHCP Options and BOOTP Vendor
Extensions.  Request for Comments (Draft Standard) 2132, Internet
Engineering Task Force, March 1997.


-----Original Message-----
From: Ralph Droms [mailto:[e-mail]] 
Sent: Monday, October 15, 2001 12:02 PM
To: [e-mail]
Subject: [dhcwg] -20e rev of DHCPv6 spec


I've posted a -20e rev to www.dhcp.org, with changes based on recent
input from the mailing list...

- Ralph




_______________________________________________
dhcwg mailing list
[e-mail]
http://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
[e-mail]
http://www1.ietf.org/mailman/listinfo/dhcwg