draft-ietf-dhc-userclass-06.txt   draft-ietf-dhc-userclass-07.txt 
Internet Engineering Task Force Glenn Stump, IBM Internet Engineering Task Force Glenn Stump, IBM
INTERNET DRAFT Ralph Droms, Bucknell University INTERNET DRAFT Ralph Droms, Bucknell University
Date: April 2000 Ye Gu, Ramesh Vyaghrapuri, Date: May 2000 Ye Gu, Ramesh Vyaghrapuri,
Expires: September 2000 Ann Demirtjis, Microsoft Expires: October 2000 Ann Demirtjis, Microsoft
Burcak Beser, 3Com Burcak Beser, 3Com
Jerome Privat, BT Jerome Privat, BT
The User Class Option for DHCP The User Class Option for DHCP
<draft-ietf-dhc-userclass-06.txt> <draft-ietf-dhc-userclass-07.txt>
Status of this Memo Status of this Memo
The document is an Internet-Draft and is in full conformance with all The document is an Internet-Draft and is in full conformance with all
of the provisions of Section 10 of RFC 2026. of the provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at line 116 skipping to change at line 116
This option is used by a DHCP client to optionally identify the This option is used by a DHCP client to optionally identify the
type or category of user or applications it represents. type or category of user or applications it represents.
A DHCP server uses the User Class option to choose the address A DHCP server uses the User Class option to choose the address
pool it allocates an address from and/or to select any other pool it allocates an address from and/or to select any other
configuration option. configuration option.
This option is a DHCP option [1, 2]. This option is a DHCP option [1, 2].
This option MAY carry multiple User Classes. This option MAY carry multiple User Classes.
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.
The code for this option is TBD. The code for this option is TBD.
Each User Class value is indicated in an opaque field and is Each User Class value is indicated in an opaque field and is
preceded by a one-byte field giving its length. preceded by a one-byte field giving its length.
The length of the option as specified in Len must be the sum Let n be the number of User Classes carried in the
of the lengths of each of the class names, starting with Len1 option. The length of the option as specified in Len must be
through to the length of the last class. the sum of the lengths of each of the class names plus n:
Len= Len1 + Len2 + ...+ Lenn + n.
Code Len Len1 Len2 Code Len Len1 Len2
+-----+-----+-----+----------+-----+--------------+---- +-----+-----+-----+----------+-----+--------------+----
| TBD | N | L1 | class 1 | L2 | class 2 |... | TBD | N | L1 | class 1 | L2 | class 2 |...
+-----+-----+-----+----------+-----+--------------+---- +-----+-----+-----+----------+-----+--------------+----
A server that is not equiped to interpret any given user class A server that is not equipped to interpret any given user class
specified by a client MUST ignore it (although it may be reported). specified by a client MUST ignore it (although it may be reported).
If a server recognizes one or more user classes specified by the If a server recognizes one or more user classes specified by the
client, but does not recognize one or more other user classes client, but does not recognize one or more other user classes
specified by the client, the server MAY use the user classes it specified by the client, the server MAY use the user classes it
recognizes. recognizes.
DHCP clients implementing this option SHOULD allow users to enter DHCP clients implementing this option SHOULD allow users to enter
one or more user class values. one or more user class values.
5. Security Considerations 5. Security Considerations
DHCP currently provides no authentication or security DHCP currently provides no authentication or security
mechanisms. Potential exposures to attack are discussed mechanisms. Potential exposures to attack are discussed
is section 7 of the protocol specification [1]. is section 7 of the protocol specification [1].
This lack of authentication mechanism means that a DHCP server
cannot check if a client or user is authorised to use a
given User Class.
6. References 6. References
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997. March 1997.
[2] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor [2] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels," RFC 2119, March 1997. Levels," RFC 2119, March 1997.
7. Acknowledgments 7. Acknowledgments
This document combines ideas from draft-ietf-dhc-userclass-03.txt This document combines ideas from draft-ietf-dhc-userclass-03.txt
(by Glenn Stump and Ralph Droms) and (by Glenn Stump and Ralph Droms) and
draft-ietf-dhc-useraddr-00.txt (by Ye Gu, Ramesh Vyaghrapuri and draft-ietf-dhc-useraddr-00.txt (by Ye Gu, Ramesh Vyaghrapuri and
Burcak Beser). It has been published as a revision to Burcak Beser). It has been published as a revision to
draft-ietf-dhc-userclass-05.txt. draft-ietf-dhc-userclass-05.txt.
Thanks to Ted Lemon, Steve Gonczi, and Barr Hibbs for their Thanks to Ted Lemon, Steve Gonczi, Kim Kinnear, Bernie Volz,
comments and suggestions. Richard Jones, Barr Hibbs for their comments and suggestions.
8. Author Information 8. Author Information
Glenn Stump Glenn Stump
IBM Networking Software IBM Networking Software
P.O. Box 12195 P.O. Box 12195
RTP, NC 27709 RTP, NC 27709
Phone: (919) 301-4277 Phone: (919) 301-4277
Email: stumpga@us.ibm.com Email: stumpga@us.ibm.com
skipping to change at line 220 skipping to change at line 230
Jerome Privat Jerome Privat
BT Advanced Communications Technology Centre BT Advanced Communications Technology Centre
Adastral Park, Martlesham Heath, IP5 3RE Adastral Park, Martlesham Heath, IP5 3RE
UK UK
Phone: +44 1473 648910 Phone: +44 1473 648910
Email: jerome.privat@bt.com Email: jerome.privat@bt.com
9. Expiration 9. Expiration
This document will expire on September 2000. This document will expire on October 2000.
Copyright Statement Copyright Statement
Copyright (c) The Internet Society (1999). All Rights Reserved. Copyright (c) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/