draft-ietf-dhc-userclass-07.txt   draft-ietf-dhc-userclass-08.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: May 2000 Ye Gu, Ramesh Vyaghrapuri, Date: June 2000 Ye Gu, Ramesh Vyaghrapuri,
Expires: October 2000 Ann Demirtjis, Microsoft Expires: November 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-07.txt> <draft-ietf-dhc-userclass-08.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 123 skipping to change at line 123
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 Servers may interpret the meanings of multiple class
specifications in an implementation dependent or specifications in an implementation dependent or
configuration dependent manner, and so the use of multiple configuration dependent manner, and so the use of multiple
classes by a DHCP client should be based on the specific server classes by a DHCP client should be based on the specific server
implementation and configuration which will be used to process implementation and configuration which will be used to process
that User class option. that User class option.
The code for this option is TBD. The format of this option is as follows:
Each User Class value is indicated in an opaque field and is
preceded by a one-byte field giving its length.
Let n be the number of User Classes carried in the
option. The length of the option as specified in Len must be
the sum of the lengths of each of the class names plus n:
Len= Len1 + Len2 + ...+ Lenn + n.
Code Len Len1 Len2 Code Len Value
+-----+-----+-----+----------+-----+--------------+---- +-----+-----+--------------------- . . . --+
| TBD | N | L1 | class 1 | L2 | class 2 |... | 77 | N | User Class Data ('Len' octets) |
+-----+-----+-----+----------+-----+--------------+---- +-----+-----+--------------------- . . . --+
where Value consists of zero or more instances of User Class Data.
Each instance of User Class Data is formatted as follows:
UC_Len_i User_Class_Data_i
+--------+------------------------ . . . --+
| L_i | Opaque-Data ('UC_Len_i' octets) |
+--------+------------------------ . . . --+
Each User Class value (User_Class_Data_i) is indicated as an opaque
field.
The value in UC_Len_i does not include the length field itself
and MUST be non-zero.
Let m be the number of User Classes carried in the option. The
length of the option as specified in Len must be the sum of the
lengths of each of the class names plus m:
Len= UC_Len_1 + UC_Len_2 + ... + UC_Len_m + m.
If any instances of User Class Data are present, the minimum
value of Len is two (Len = UC_Len_1 + 1 = 1 + 1 = 2).
The Code for this option is 77.
A server that is not equipped 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. IANA Considerations
Option 77, which IANA has already assigned for this purpose,
should be used as the User Class Option for DHCP.
6. 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 This lack of authentication mechanism means that a DHCP server
cannot check if a client or user is authorised to use a cannot check if a client or user is authorised to use a
given User Class. given User Class.
This introduces an obvious vulnerability when using the User
Class option. For example, if the User Class is used to give
out special IP addresses that have better QoS associated with
them (as described in section 1), there is no way to authenticate
a client and it is therefore impossible to check if a client is
authorised to use such an IP address.
6. References 7. 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 8. Acknowledgments
This document combines ideas from draft-ietf-dhc-userclass-03.txt This document is based on earlier drafts by Glenn Stump,
(by Glenn Stump and Ralph Droms) and Ralph Droms, Ye Gu, Ramesh Vyaghrapuri and Burcak Beser.
draft-ietf-dhc-useraddr-00.txt (by Ye Gu, Ramesh Vyaghrapuri and
Burcak Beser). It has been published as a revision to
draft-ietf-dhc-userclass-05.txt.
Thanks to Ted Lemon, Steve Gonczi, Kim Kinnear, Bernie Volz, Thanks to Ted Lemon, Steve Gonczi, Kim Kinnear, Bernie Volz,
Richard Jones, Barr Hibbs for their comments and suggestions. Richard Jones, Barr Hibbs and Thomas Narten for their comments
and suggestions.
8. Author Information 9. 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
Ralph Droms Ralph Droms
Computer Science Department Computer Science Department
skipping to change at line 228 skipping to change at line 252
Phone: 425-705-2254 Phone: 425-705-2254
Email: annd@microsoft.com Email: annd@microsoft.com
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 10. Expiration
This document will expire on October 2000. This document will expire on November 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/