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

From: Ralph Droms <[email-masked]>
Date: Mon, 15 Oct 2001 15:01:53 -0400 (EDT)

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

- Ralph

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

---

From: "Thirumalesh Bhat" <[email-masked]>
Date: Mon, 15 Oct 2001 18:52:56 -0700

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:[email-masked]] 
Sent: Monday, October 15, 2001 12:02 PM
To: [email-masked]
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

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Tue, 16 Oct 2001 16:22:57 -0500

We don't have a vendor class identifier option specified for DHCPv6:

	"The vendor is indicated in the vendor class identifier option. "

So, that option will be required as well.

I would assume we'd just take the existing DHCPv4 option (see RFC 2132,
section 9.13) changing it to be in the 16-bit option format?

- Bernie

-----Original Message-----
From: Thirumalesh Bhat [mailto:[email-masked]]
Sent: Monday, October 15, 2001 9:53 PM
To: Ralph Droms; [email-masked]
Subject: RE: [dhcwg] -20e rev of DHCPv6 spec

User Class Option

option-code   TBD

Vendor Class Option

option-code   TBD

option-len    Variable

References

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

- Ralph

---

From: "Thirumalesh Bhat" <[email-masked]>
Date: Tue, 16 Oct 2001 15:08:20 -0700

Thanks for your comments. You are right - we are just porting the V4
options to V6. I will change the wording to indicate that the vendor is
indicated by the client to the server and the server replies with the
encapsulated options.
 
thx

	-----Original Message-----
	From: Bernie Volz (EUD) [mailto:[email-masked]] 
	Sent: Tuesday, October 16, 2001 2:23 PM
	To: Thirumalesh Bhat; Ralph Droms; [email-masked]
	Subject: RE: [dhcwg] -20e rev of DHCPv6 spec

	We don't have a vendor class identifier option specified for
DHCPv6: 

	        "The vendor is indicated in the vendor class identifier
option. " 

	I would assume we'd just take the existing DHCPv4 option (see
RFC 2132, 
	section 9.13) changing it to be in the 16-bit option format? 

	- Bernie 

	-----Original Message----- 
	From: Thirumalesh Bhat [mailto:[email-masked]] 
	Sent: Monday, October 15, 2001 9:53 PM 
	To: Ralph Droms; [email-masked] 
	Subject: RE: [dhcwg] -20e rev of DHCPv6 spec 

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

	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. 

	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:[email-masked]] 
	Sent: Monday, October 15, 2001 12:02 PM 
	To: [email-masked] 
	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

---

From: Ralph Droms <[email-masked]>
Date: Tue, 16 Oct 2001 21:24:36 -0400

Oops - I missed the requirement for the vendor class ID option.  We'll put 
it in the -21 rev...

- Ralph

At 04:22 PM 10/16/2001 -0500, Bernie Volz (EUD) wrote:

>From: Thirumalesh Bhat 
>[<mailto:[email-masked]>mailto:[email-masked]]
>From: Ralph Droms [<mailto:[email-masked]>mailto:[email-masked]]
><http://www1.ietf.org/mailman/listinfo/dhcwg>http://www1.ietf.org/mailman/listinfo/dhcwg 
>
>
><http://www1.ietf.org/mailman/listinfo/dhcwg>http://www1.ietf.org/mailman/listinfo/dhcwg 
>

---

From: "Thirumalesh Bhat" <[email-masked]>
Date: Tue, 16 Oct 2001 19:16:51 -0700

Bernie/Ralph - I changed the message slightly to make it clear that the
same option ( for vendor specific option ) can be used when the client
communicates with the server and the server communicates with the
client. 

--

User Class Option

option-code   TBD

Vendor Class Option

option-code   TBD

option-len    Variable

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

The vendor specific data sent by the client to the server is formatted
in the  OPTION_VENDOR_CLASS as indicated below.

    +-+-+-+-...-+-+-+-+-+-+-+
    |       vendor data     |
    +-+-+-+-...-+-+-+-+-+-+-+

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

References

-----Original Message-----
From: Bernie Volz (EUD) [mailto:[email-masked]] 
Sent: Tuesday, October 16, 2001 2:23 PM
To: Thirumalesh Bhat; Ralph Droms; [email-masked]
Subject: RE: [dhcwg] -20e rev of DHCPv6 spec

        "The vendor is indicated in the vendor class identifier option.
" 
-----Original Message----- 
From: Thirumalesh Bhat [mailto:[email-masked]] 
Sent: Monday, October 15, 2001 9:53 PM 
To: Ralph Droms; [email-masked] 
Subject: RE: [dhcwg] -20e rev of DHCPv6 spec 

        

Vendor Class Option 

References