draft-ietf-dhc-vendor-suboption-00.txt		rfc4243.txt
	DHC Working Group M. Stapp		Network Working Group M. Stapp
	Internet-Draft R. Johnson		Request for Comments: 4243 R. Johnson
	Expires: February 7, 2005 T. Palaniappan		Category: Standards Track T. Palaniappan
	Cisco Systems, Inc.		Cisco Systems, Inc.
	August 9, 2004		December 2005
	Vendor-Specific Information Suboption for the DHCP Relay Agent Option
	<draft-ietf-dhc-vendor-suboption-00.txt>
	Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable
	patent or other IPR claims of which I am aware have been disclosed,
	and any of which I become aware will be disclosed, in accordance with
	RFC 3667.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at http://		Vendor-Specific Information Suboption for the
	www.ietf.org/ietf/1id-abstracts.txt.		Dynamic Host Configuration Protocol (DHCP) Relay Agent Option
	The list of Internet-Draft Shadow Directories can be accessed at		Status of This Memo
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on February 7, 2005.		This document specifies an Internet standards track protocol for the
			Internet community, and requests discussion and suggestions for
			improvements. Please refer to the current edition of the "Internet
			Official Protocol Standards" (STD 1) for the standardization state
			and status of this protocol. Distribution of this memo is unlimited.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	This memo defines a new Vendor-Specific Information suboption for the		This memo defines a new Vendor-Specific Information suboption for the
	Dynamic Host Configuration Protocol's (DHCP) relay agent information		Dynamic Host Configuration Protocol's (DHCP) relay agent information
	option. The suboption allows a DHCP relay agent to include		option. The suboption allows a DHCP relay agent to include vendor-
	vendor-specific information in DHCP messages it forwards, as		specific information in the DHCP messages it forwards, as configured
	configured by its administrator.		by its administrator.
	Table of Contents		Table of Contents
	1. Requirements Terminology . . . . . . . . . . . . . . . . . . . . 3		1. Introduction ....................................................2
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Requirements Terminology ........................................2
	3. The Vendor-Specific Suboption . . . . . . . . . . . . . . . . . 3		3. The Vendor-Specific Suboption ...................................2
	4. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . . . 4		4. Relay Agent Behavior ............................................4
	5. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . . 5		5. DHCP Server Behavior ............................................4
	6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5		6. Security Considerations .........................................4
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6		7. IANA Considerations .............................................5
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6		8. Acknowledgements ................................................5
	Normative References . . . . . . . . . . . . . . . . . . . . . . 7		Normative References ...............................................5
	Informative References . . . . . . . . . . . . . . . . . . . . . 7		Informative References .............................................5
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
	Intellectual Property and Copyright Statements . . . . . . . . . 9
	1. Requirements Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [1].
	2. Introduction		1. Introduction
	DHCP (RFC 2131 [2]) provides IP addresses and configuration		DHCP (RFC 2131 [2]) provides IP addresses and configuration
	information for IPv4 clients. It includes a relay agent capability,		information for IPv4 clients. It includes a relay agent capability,
	in which processes within the network infrastructure receive		in which processes within the network infrastructure receive
	broadcast messages from clients and forward them to DHCP servers as		broadcast messages from clients and forward them to DHCP servers as
	unicast messages. In network environments like DOCSIS data-over-cable		unicast messages. In network environments like DOCSIS data-over-
	and xDSL, for example, it has proven useful for the relay agent to		cable and xDSL, for example, it has proven useful for the relay agent
	add information to the DHCP message before forwarding it, using the		to add information to the DHCP message before forwarding it, using
	relay agent information option (RFC 3046 [3]).		the relay agent information option (RFC 3046 [3]).
	Servers that recognize the relay agent option echo it back in their		Servers that recognize the relay agent option echo it back in their
	replies, and some of the information that relays add may be used to		replies, and some of the information that relays add may be used to
	help an edge device efficiently return replies to clients. The		help an edge device efficiently return replies to clients. The
	information that relays supply can also be used in the server's		information that relays supply can also be used in the server's
	decision making about the addresses and configuration parameters that		decision making about the addresses and configuration parameters that
	the client should receive.		the client should receive.
	In many environments it's desirable to associate some vendor- or		In many environments, it's desirable to associate some vendor- or
	provider-specific information with clients' DHCP messages. This is		provider-specific information with the clients' DHCP messages. This
	often done using the relay agent information option. RFC 3046 defines		is often done using the relay agent information option. RFC 3046
	Remote-ID and Circuit-ID sub-options that are used to carry such		defines Remote-ID and Circuit-ID sub-options that are used to carry
	information. The values of those suboptions, however, are usually		such information. The values of those suboptions, however, are
	based on some network resource, such as an IP address of a network		usually based on some network resource, such as an IP address of a
	access device, an ATM Virtual Circuit identifier, or a DOCSIS		network access device, an ATM Virtual Circuit identifier, or a DOCSIS
	cable-modem identifier. As a result, the values carried in these		cable-modem identifier. As a result, the values carried in these
	suboptions are dependent on the physical network configuration. The		suboptions are dependent on the physical network configuration. The
	Vendor-Specific suboption allows administrators to associate other		Vendor-Specific suboption allows administrators to associate other
	useful data with relayed DHCP messages.		useful data with relayed DHCP messages.
			2. Requirements Terminology
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in RFC 2119 [1].
	3. The Vendor-Specific Suboption		3. The Vendor-Specific Suboption
	This memo defines a new DHCP relay agent option suboption that		This memo defines a new DHCP relay agent option suboption that
	carries vendor-defined data. The suboption takes a form similar to		carries vendor-defined data. The suboption takes a form similar to
	the Vendor-Identifying Vendor-Specific Option [8].		the Vendor-Identifying, Vendor-Specific Option [7].
	0 1 2 3		0 1 2 3
	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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Code | Length | Enterprise Number1 |		| Code | Length | Enterprise Number1 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| | DataLen1 | |		| | DataLen1 | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
	\ Suboption Data1 \		\ Suboption Data1 \
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Enterprise Number2 |		| Enterprise Number2 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| DataLen2 | Suboption Data2 |		| DataLen2 | Suboption Data2 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\ \		\ \
	. .		. .
	. .		. .
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The Code for the suboption is <TBD> (to be assigned by IANA).		The Code for the suboption is 9.
	The one-byte Length field is the length of the data carried in the		The one-byte Length field is the length of the data carried in the
	suboption, in bytes. The length includes the length of the first		suboption, in bytes. The length includes the length of the first
	Enterprise Number; the minimum length is 4 bytes.		Enterprise Number; the minimum length is 4 bytes.
	"Enterprise NumberN" is a vendor's Enterprise Number as registered		"Enterprise NumberN" is a vendor's Enterprise Number as registered
	with IANA [4]. It is a four-byte integer value in network byte-order.		with IANA [4]. It is a four-byte integer value in network byte-
			order.
	DataLenN is the length of the data associated with the Enterprise		DataLenN is the length of the data associated with the Enterprise
	Number.		Number.
	The Suboption Data is an opaque sequence of bytes.		The Suboption Data is an opaque sequence of bytes.
	The Vendor-Specific suboption includes at least one Enterprise Number		The Vendor-Specific suboption includes at least one Enterprise Number
	and carries opaque data defined by the organization identified by the		and carries opaque data defined by the organization identified by the
	Enterprise Number. A relay may include data associated with more than		Enterprise Number. A relay may include data associated with more
	one vendor's Enterprise Number within a single instance of the		than one vendor's Enterprise Number within a single instance of the
	Suboption.		Suboption.
	The Vendor-Specific data are of course provider-specific. This		Of course, the Vendor-Specific data are vendor-specific. This
	specification does not establish any requirements on the data in the		specification does not establish any requirements on the data in the
	suboption. Vendors who make use of this suboption are encouraged to		suboption. Vendors who make use of this suboption are encouraged to
	document their usage in order to make interoperability possible.		document their usage in order to make interoperability possible.
	4. Relay Agent Behavior		4. Relay Agent Behavior
	DHCP relay agents MAY be configured to include Vendor-Specific		DHCP relay agents MAY be configured to include Vendor-Specific
	suboptions if they include a relay agent information option in		suboptions if they include a relay agent information option in
	relayed DHCP messages. The suboptions' types and data are assigned		relayed DHCP messages. The suboptions' types and data are assigned
	and configured through mechanisms that are outside the scope of this		and configured through mechanisms that are outside the scope of this
	memo.		memo.
	Relay implementors are encouraged to offer their administrators some		Relay implementors are encouraged to offer their administrators a
	means of configuring what data can be included in this suboption, and		means of configuring what data can be included in this suboption, and
	to document what they are capable of.		to document what they are capable of.
	5. DHCP Server Behavior		5. DHCP Server Behavior
	This suboption provides additional information to the DHCP server.		This suboption provides additional information to the DHCP server.
	The DHCP server, if it is configured to support this suboption, may		The DHCP server, if it is configured to support this suboption, may
	use this information in addition to other relay agent option data and		use this information, in addition to other relay agent option data
	other options included in the DHCP client messages in order to assign		and other options included in the DHCP client messages, in order to
	an IP address and/or other configuration parameters to the client.		assign an IP address and/or other configuration parameters to the
	There is no special additional processing for this suboption.		client. There is no special additional processing for this
			suboption.
	DHCP server vendors are encouraged to offer their administrators some
	means of configuring the use of data from incoming Vendor-Specific
	suboptions in DHCP decision-making.
	6. Security Considerations		6. Security Considerations
	Message authentication in DHCP for intradomain use where the		Message authentication in DHCP for intradomain use, where the out-
	out-of-band exchange of a shared secret is feasible is defined in RFC		of-band exchange of a shared secret is feasible, is defined in RFC
	3118 [5]. Potential exposures to attack are discussed in section 7 of		3118 [5]. Potential exposures to attack are discussed in section 7
	the DHCP protocol specification in RFC 2131 [2].		of the DHCP protocol specification in RFC 2131 [2].
	The DHCP relay agent option depends on a trusted relationship between		The DHCP relay agent option depends on a trusted relationship between
	the DHCP relay agent and the server, as described in section 5 of RFC		the DHCP relay agent and the server, as described in section 5 of RFC
	3046. Fraudulent relay agent option data could potentially lead to		3046. Fraudulent relay agent option data could potentially lead to
	theft-of-service or exhaustion of limited resources (like IP		theft-of-service or exhaustion of limited resources (like IP
	addresses) by unauthorized clients. A host that tampered with relay		addresses) by unauthorized clients. A host that tampered with relay
	agent data associated with another host's DHCP messages could deny		agent data associated with another host's DHCP messages could deny
	service to that host, or interfere with its operation by leading the		service to that host, or interfere with its operation by leading the
	DHCP server to assign it inappropriate configuration parameters.		DHCP server to assign it inappropriate configuration parameters.
	While the introduction of fraudulent relay agent options can be		While the introduction of fraudulent relay agent options can be
	prevented by a perimeter defense that blocks these options unless the		prevented by a perimeter defense that blocks these options unless the
	relay agent is trusted, a deeper defense using authentication for		relay agent is trusted, a deeper defense using authentication for
	relay agent options via the Authentication Suboption [6] or IPSEC [7]		relay agent options via the Authentication Suboption [6] SHOULD be
	SHOULD be deployed as well.		deployed as well.
	There are several data in a DHCP message that convey information that		There are several data in a DHCP message that convey information that
	may identify an individual host on the network. These include the		may identify an individual host on the network. These include the
	chaddr, the client-id option, and the hostname and client-fqdn		chaddr, the client-id option, and the hostname and client-fqdn
	options. Depending on the type of data included, the Vendor-Specific		options. Depending on the type of data included, the Vendor-Specific
	suboption may also convey information that identifies a specific host		suboption may also convey information that identifies a specific host
	or a specific user on the network. In practice, this information		or a specific user on the network. In practice, this information
	isn't exposed outside the internal service-provider network, where		isn't exposed outside the internal service-provider network, where
	DHCP messages are usually confined. Administrators who configure data		DHCP messages are usually confined. Administrators who configure
	that's going to be used in DHCP Vendor-Specific suboptions should be		data that will be used in DHCP Vendor-Specific suboptions should be
	careful to use data that are appropriate for the types of networks		careful to use data that are appropriate for the types of networks
	they administer. If DHCP messages travel outside the		they administer. If DHCP messages travel outside the service-
	service-provider's own network, or if the suboption values may become		provider's own network, or if the suboption values may become visible
	visible to other users, that may raise privacy concerns for the		to other users, it may raise privacy concerns for the access provider
	access provider or service provider.		or service provider.
	7. IANA Considerations		7. IANA Considerations
	IANA is requested to assign a suboption number for the		The IANA has assigned the suboption number 9 for the Vendor-Specific
	Vendor-Specific Information Suboption from the DHCP Relay Agent		Information Suboption from the DHCP Relay Agent Information Option
	Information Option [3] suboption number space.		[3] suboption number space.
	8. Acknowledgements		8. Acknowledgements
	The authors are grateful to Andy Sudduth, Josh Littlefield, and Kim		The authors are grateful to Andy Sudduth, Josh Littlefield, and Kim
	Kinnear for their review and comments.		Kinnear for their review and comments.
	Normative References		Normative References
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,		[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
	March 1997.		March 1997.
	[3] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046,		[3] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046,
	January 2001.		January 2001.
	[4] IANA, "Private Enterprise Numbers (http://www.iana.org/		[4] IANA, "Private Enterprise Numbers (http://www.iana.org/
	assignments/enterprise-numbers.html)".		assignments/enterprise-numbers.html)".
	Informative References		Informative References
	[5] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",		[5] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
	RFC 3118, June 2001.		RFC 3118, June 2001.
	[6] Stapp, M., "The Authentication Suboption for the DHCP Relay		[6] Stapp, M. and T. Lemon, "The Authentication Suboption for the
	Agent Option", draft-ietf-dhc-auth-suboption-04.txt (work in		Dynamic Host Configuration Protocol (DHCP) Relay Agent Option",
	progress), October 2003.		RFC 4030, March 2005.
	[7] Droms, R., "Authentication of Relay Agent Options Using IPsec",
	draft-ietf-dhc-relay-agent-ipsec-01.txt (work in progress),
	November 2003.
	[8] Littlefield, J., "Vendor-Identifying Vendor Options for DHCPv4",		[7] Littlefield, J., "Vendor-Identifying Vendor Options for Dynamic
	draft-ietf-dhc-vendor-03.txt (work in progress), June 2004.		Host Configuration Protocol version 4 (DHCPv4)", RFC 3925,
			October 2004.
	Authors' Addresses		Authors' Addresses
	Mark Stapp		Mark Stapp
	Cisco Systems, Inc.		Cisco Systems, Inc.
	1414 Massachusetts Ave.		1414 Massachusetts Ave.
	Boxborough, MA 01719		Boxborough, MA 01719
	USA		USA
	Phone: 978.936.0000		Phone: 978.936.0000
	skipping to change at page 9, line 5		skipping to change at page 7, line 5
	Theyn Palaniappan		Theyn Palaniappan
	Cisco Systems, Inc.		Cisco Systems, Inc.
	170 W. Tasman Dr.		170 W. Tasman Dr.
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	Phone: 408.526.4000		Phone: 408.526.4000
	EMail: athenmoz@cisco.com		EMail: athenmoz@cisco.com
	Intellectual Property Statement		Full Copyright Statement
			Copyright (C) The Internet Society (2005).
			This document is subject to the rights, licenses and restrictions
			contained in BCP 78, and except as set forth therein, the authors
			retain all their rights.
			This document and the information contained herein are provided on an
			"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
			OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
			ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
			INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
			INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
			WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the IETF's procedures with respect to rights in IETF Documents can		on the procedures with respect to rights in RFC documents can be
	be found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any		Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an		assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at ietf-
	ietf-ipr@ietf.org.		ipr@ietf.org.
	Disclaimer of Validity
	This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement
	Copyright (C) The Internet Society (2004). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.
	Acknowledgment		Acknowledgement
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 31 change blocks.
	124 lines changed or deleted		101 lines changed or added
This html diff was produced by rfcdiff 1.28, available from http://www.levkowetz.com/ietf/tools/rfcdiff/