draft-ietf-dhc-dhcpv4-vendor-message-00.txt   draft-ietf-dhc-dhcpv4-vendor-message-01.txt 
DHC B. Volz DHC B. Volz
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track January 12, 2009 Intended status: Standards Track August 3, 2009
Expires: July 16, 2009 Expires: February 4, 2010
DHCPv4 Vendor-specific Message DHCPv4 Vendor-specific Message
<draft-ietf-dhc-dhcpv4-vendor-message-00.txt> <draft-ietf-dhc-dhcpv4-vendor-message-01.txt>
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 16, 2009. This Internet-Draft will expire on February 4, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
Abstract Abstract
This document requests a vendor-specific DHCPv4 message assignment. This document requests a vendor-specific DHCPv4 message assignment.
This message can be used for vendor specific and experimental This message can be used for vendor specific and experimental
purposes. purposes.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Vendor-specific Message . . . . . . . . . . . . . . . . . . . . 3 3. Vendor-specific Message . . . . . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 4. Vendor Message Option . . . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
The DHCPv4 [RFC2131] protocol specifies a mechanism for the DHCPv4 [RFC2131] specifies a mechanism for the assignment of
assignment of addresses and configuration information to nodes. The addresses and configuration information to nodes. The protocol
protocol provides for 256 possible message codes, of which a small provides for 256 possible message codes, of which a small number are
number are assigned ([DHCPv4Params]). Each of the assigned message assigned ([DHCPv4Params]). Each of the assigned message codes have
codes have specific purposes. New message codes are assigned through specific purposes. New message codes are assigned through IETF
IETF Standards Action. Standards Action.
There may be a need for vendors of DHCPv4 clients, relay agents, or There may be a need for vendors of DHCPv4 clients, relay agents, or
servers to experiment with new capabilities that require new messages servers to experiment with new capabilities that require new messages
to be exchanged between these elements. Thus, this document defines to be exchanged between these elements. Thus, this document defines
the format for and requests that a new message code be reserved for the format for and requests that a new message code be reserved for
vendor-specific and experimental purposes. vendor-specific and experimental purposes.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 4, line 6 skipping to change at page 4, line 6
exchange to negotiate whether the end-points support the vendor- exchange to negotiate whether the end-points support the vendor-
specific message. specific message.
A vendor-specifc message is constructed by placing the Vendor- A vendor-specifc message is constructed by placing the Vendor-
Specific Message number (254) into the DHCP Message Type option Specific Message number (254) into the DHCP Message Type option
[RFC2132] and including the Vendor Message Option defined below. A [RFC2132] and including the Vendor Message Option defined below. A
Vendor-Specific Message that does not contain the Vendor Message Vendor-Specific Message that does not contain the Vendor Message
Option MUST be ignored. A Vendor Message Option in a DHCPv4 message Option MUST be ignored. A Vendor Message Option in a DHCPv4 message
other than the Vendor-Specific Message MUST be ignored. other than the Vendor-Specific Message MUST be ignored.
4. Vendor Message Option
The Vendor Message Option serves three purposes. It specifies the
Enterprise Number to identify the vendor, it specifies the vendor's
message type, and optionally contains vendor options related to the
message.
The format of the Vendor Message Option is shown below: The format of the Vendor Message Option is shown below:
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len | | option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ enterprise-number + + enterprise-number +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| vendor | | | vendor | |
| msg-type | | | msg-type | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
/ vendor-option-data / / option-data /
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_VENDOR_MESSAGE (TBD) option-code OPTION_VENDOR_MESSAGE (TBD)
option-len 5 plus the length of the vendor-option-data. option-len 5 plus the length of the vendor-option-data.
enterprise-number The vendor's 32-bit Enterprise Number as enterprise-number The vendor's 32-bit Enterprise Number as
registered with [EID], in network octet order. registered with [EID], in network octet order.
vendor-msg-type The vendor's message-type. The values are vendor-msg-type The vendor's message-type. The values are
defined by the vendor identified in the defined by the vendor identified in the
enterprise-number field and are not managed by enterprise-number field and are not managed by
IANA. IANA.
vendor-option-data Vendor specific data (of length option-len option-data Vendor specific data (of length option-len
minus 5 octets). This is optional. minus 5 octets). This is optional.
The vendor-option-data field MUST be encoded as a sequence of code/ The option-data field MUST be encoded as a sequence of code/length/
length/value fields of identical format to the DHCP options field. value fields of identical format to the DHCP options field and is
The option codes are defined by the vendor identified in the identical to the option-data field of Vendor-Identifying Vendor
enterprise-number field and are not managed by IANA. Option codes 0 Options [RFC3925]. The option codes are defined by the vendor
and 255 have no pre-defined interpretation or format. Each of the identified in the enterprise-number field and are not managed by
encapsulated options is formatted as follows: IANA. Option codes 0 and 255 have no pre-defined interpretation or
format. Each of the encapsulated options is formatted as follows:
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| subopt-code | subopt-len | | subopt-code | subopt-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ sub-option-data / / sub-option-data /
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 5, line 30 skipping to change at page 5, line 33
sub-option-data Data area for the encapsulated option. sub-option-data Data area for the encapsulated option.
Clients, relay agents, and/or servers supporting the Vendor Message Clients, relay agents, and/or servers supporting the Vendor Message
Option MUST support [RFC3396]. Option MUST support [RFC3396].
Note: Vendor-Identifying Vendor Options [RFC3925] are not used to Note: Vendor-Identifying Vendor Options [RFC3925] are not used to
convey the vendor identification (enterprise-number) for the vendor- convey the vendor identification (enterprise-number) for the vendor-
specific message as the message may contain instances of those specific message as the message may contain instances of those
options for other reasons. options for other reasons.
4. Security Considerations 5. Security Considerations
The Security Considerations of [RFC2131] apply. The Security Considerations of [RFC2131] apply.
This new message does potentially open up new avenues of attacking This new message does potentially open up new avenues of attacking
clients, relay agents, or servers. The exact nature of these attacks clients, relay agents, or servers. The exact nature of these attacks
will depend on what functions and capabilities the message exposes will depend on what functions and capabilities the message exposes
and are thus not possible to describe in this document. Clients and and are thus not possible to describe in this document. Clients and
servers that have no use for these messages SHOULD discard them and servers that have no use for these messages SHOULD discard them and
thus the threat is no different than before this message was thus the threat is no different than before this message was
assigned. assigned.
Vendors using this new message should use the DHCPv4 security Vendors using this new message should use the DHCPv4 security
mechanisms (such as [RFC3118] as appropriate) and carefully consider mechanisms (such as [RFC3118] as appropriate) and carefully consider
the security implications of the functions and capabilities exposed. the security implications of the functions and capabilities exposed.
5. IANA Considerations 6. IANA Considerations
IANA is requested to assign DHCPv4 Message type 254 to the Vendor- IANA is requested to assign DHCPv4 Message type 254 to the Vendor-
specific Message in the registry maintained in [DHCPv4Params]: specific Message in the registry maintained in [DHCPv4Params]:
254 VENDOR-SPECIFIC 254 VENDOR-SPECIFIC
IANA is requested to assign a DHCPv4 option number to the Vendor IANA is requested to assign a DHCPv4 option number to the Vendor
Message Option in the registry maintained in [DHCPv4Params]: Message Option in the registry maintained in [DHCPv4Params]:
TBD OPTION_VENDOR_MESSAGE TBD OPTION_VENDOR_MESSAGE
6. References 7. References
6.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997. RFC 2131, March 1997.
[EID] IANA, "Private Enterprise Numbers. [EID] IANA, "Private Enterprise Numbers.
http://www.iana.org/assignments/enterprise-numbers". http://www.iana.org/assignments/enterprise-numbers".
6.2. Informative References 7.2. Informative References
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001. Messages", RFC 3118, June 2001.
[RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the
Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396,
November 2002. November 2002.
 End of changes. 15 change blocks. 
34 lines changed or deleted 42 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/