<?xml version="1.0"?>

<?rfc compact="yes" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc2119 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
    <!ENTITY rfc2131 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml'>
    <!ENTITY rfc2132 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2132.xml'>
    <!ENTITY rfc3118 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3118.xml'>
    <!ENTITY rfc3396 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3396.xml'>
    <!ENTITY rfc3925 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3925.xml'>
]>

<rfc category="std"
     ipr="trust200902" 
     docName="<draft-ietf-dhc-dhcpv4-vendor-message-01.txt>">

<front>

<title>DHCPv4 Vendor-specific Message</title>

<author initials="B." surname="Volz" fullname="Bernard Volz">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>1414 Massachusetts Ave.</street>
<city>Boxborough</city> <region>MA</region> <code>01719</code>
<country>USA</country>
</postal>
<phone>+1 978 936 0000</phone>
<email>volz@cisco.com</email>
</address>
</author>

<date day="3" month="August" year="2009"></date>
<workgroup>DHC</workgroup>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>DHCP</keyword>
<keyword>IPv6</keyword>
<keyword>DHCPv6</keyword>

<abstract>
<t>
This document requests a vendor-specific DHCPv4 message assignment.
This message can be used for vendor specific and experimental purposes.
</t>
</abstract>

</front>

<middle>

<!--
============================INTRODUCTION-BEGIN==========================
======= -->
<section title="Introduction">

<t>
DHCPv4 <xref target="RFC2131"/> specifies a mechanism for the
assignment of addresses and configuration information to nodes. The protocol
provides for 256 possible message codes, of which a small number are
assigned (<xref target="DHCPv4Params"/>). Each of the assigned message codes
have specific purposes. New message codes are assigned through IETF Standards
Action.
</t>

<t>
There may be a need for vendors of DHCPv4 clients, relay agents, or
servers to experiment with new capabilities that require new messages
to be exchanged between these elements. Thus, this document defines
the format for and requests that a new message code be reserved for
vendor-specific and experimental purposes.
</t>

</section>
<!-- ===================INTRODUCTION-END=========================== -->

<section title="Terminology">
<t>
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 <xref target="RFC2119"/>.
</t>

</section>

<!-- =============================================================== -->
<section title="Vendor-specific Message">

<t>
The vendor-specific message may be exchanged between
clients, relay agents, and/or servers and allows multiple vendors to
make use of the message for completely different and independent
purposes.
</t>

<t>
Clients and servers MAY chose to support this message; those that do
not, MUST discard the message. Relay agents SHOULD relay these messages
as they would other DHCPv4 messages unless the relay agent understands
the specific message and knows that the message was directed at it.
</t>

<t>
Applications using these messages MUST NOT assume that all
DHCPv4 clients, relay agents, and servers support them and MUST use good
networking practices when transmitting and retransmitting these messages.
For some applications, it may be appropriate to use Vendor-Identifying
Vendor Options <xref target="RFC3925"/> in a standard DHCPv4 exchange
to negotiate whether the end-points support the vendor-specific message.
</t>

<t>
A vendor-specifc message is constructed by placing the Vendor-Specific
Message number (254) into the DHCP Message Type option <xref target="RFC2132"/>
and including the Vendor Message Option defined below. A Vendor-Specific
Message that does not contain the Vendor Message Option MUST be ignored.
A Vendor Message Option in a DHCPv4 message other than the Vendor-Specific
Message MUST be ignored.
</t>

</section>

<!-- =============================================================== -->
<section title="Vendor Message Option">
<t>
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.
</t>

<figure>
<preamble>The format of the Vendor Message Option is shown below:</preamble>
<artwork>
                        1 1 1 1 1 1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  option-code  |  option-len   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +       enterprise-number       +
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     vendor    |               |
   |    msg-type   |               |
   +-+-+-+-+-+-+-+-+               |
   /          option-data          /
   ~            ...                ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   option-code         OPTION_VENDOR_MESSAGE (TBD)

   option-len          5 plus the length of the vendor-option-data.

   enterprise-number   The vendor's 32-bit Enterprise Number as
                       registered with [EID], in network octet order.

   vendor-msg-type     The vendor's message-type. The values are
                       defined by the vendor identified in the
                       enterprise-number field and are not managed by
                       IANA.

   option-data         Vendor specific data (of length option-len
                       minus 5 octets). This is optional.
</artwork>
</figure>

<t>
The option-data field MUST be encoded as
a sequence of code/length/value fields of identical format to the
DHCP options field and is identical to the option-data field
of Vendor-Identifying Vendor Options <xref target="RFC3925"/>.
The option codes are defined by the vendor identified in the
enterprise-number field and are not
managed by IANA. Option codes 0 and 255 have no pre-defined
interpretation or format. Each of the encapsulated options is
formatted as follows:
</t>

<figure>
<artwork>
                        1 1 1 1 1 1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  subopt-code  |  subopt-len   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /        sub-option-data        /
   ~            ...                ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   subopt-code        The code for the encapsulated option.

   subopt-len         An unsigned integer giving the length of the
                      option-data field in this encapsulated option in
                      octets.

   sub-option-data    Data area for the encapsulated option.
</artwork>
</figure>

<t>Clients, relay agents, and/or servers supporting the Vendor Message Option
MUST support <xref target="RFC3396"/>.
</t>

<t>Note: Vendor-Identifying Vendor Options <xref target="RFC3925"/> are not
used to convey the vendor identification (enterprise-number) for the
vendor-specific message as the message may contain instances of those options for
other reasons.
</t>

</section>

<!-- =============================================================== -->

<section title="Security Considerations">

<t>
The Security Considerations of <xref target="RFC2131"/> apply.
</t>

<t>
This new message does potentially open up new avenues of attacking clients,
relay agents, or servers. The exact nature of these attacks will depend on
what functions and capabilities the message exposes and are thus not possible
to describe in this document. Clients and servers that have no use for these
messages SHOULD discard them and thus the threat is no different than before
this message was assigned.
</t>

<t>
Vendors using this new message should use the DHCPv4 security mechanisms
(such as <xref target="RFC3118"/> as appropriate) and carefully consider
the security implications of the functions and capabilities exposed.
</t>

</section>

<!-- ================================================================= -->

<section title="IANA Considerations" anchor="section.IANA">
<t>
IANA is requested to assign DHCPv4 Message type 254 to the Vendor-specific
Message in the registry maintained in <xref target="DHCPv4Params"/>:
</t>

<list>
<t></t>
<t>254  VENDOR-SPECIFIC</t>
</list>

<t>
IANA is requested to assign a DHCPv4 option number to the Vendor Message
Option in the registry maintained in <xref target="DHCPv4Params"/>:
</t>

<list>
<t></t>
<t>TBD  OPTION_VENDOR_MESSAGE</t>
</list>

</section>

<!-- ============================================================= -->

</middle>

<!-- ============================================================= -->

<back>
<references title="Normative References">

&rfc2119;
&rfc2131;

<reference anchor="EID">
	<front>
	<title>Private Enterprise Numbers.
        http://www.iana.org/assignments/enterprise-numbers</title>
	<author surname="IANA">
	</author>
	</front>
</reference>


</references>
<references title="Informative References">

&rfc2132;
&rfc3118;
&rfc3396;
&rfc3925;

<reference anchor="DHCPv4Params">
	<front>
	<title>Dynamic Host Configuration Protocol (DHCP) and
        Bootstrap Protocol (BOOTP) Parameters.
        http://www.iana.org/assignments/bootp-dhcp-parameters</title>
	<author surname="IANA">
	</author>
	</front>
</reference>

</references>
</back>
</rfc>
