idnits 2.17.1 draft-ietf-dhc-dhcpv6-vendor-message-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 3, 2009) is 5373 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) -- Possible downref: Non-RFC (?) normative reference: ref. 'EID' Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC B. Volz 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track August 3, 2009 5 Expires: February 4, 2010 7 DHCPv6 Vendor-specific Message 8 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on February 4, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document requests a vendor-specific DHCPv6 message assignment. 47 This message can be used for vendor specific and experimental 48 purposes. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Vendor-specific Message . . . . . . . . . . . . . . . . . . . . 3 55 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 56 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 57 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 59 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 1. Introduction 64 DHCPv6 [RFC3315] specifies a mechanism for the assignment of 65 addresses and configuration information to nodes. The protocol 66 provides for 256 possible message codes, of which a small number are 67 assigned ([DHCPv6Params]). Each of the assigned message codes have 68 specific purposes. New message codes are assigned through Standards 69 Action (see Section 24 of [RFC3315]). 71 There may be a need for vendors of DHCPv6 clients, relay agents, or 72 servers to experiment with new capabilities that require new messages 73 to be exchanged between these elements. Thus, this document defines 74 the format for and requests that a new message code be reserved for 75 vendor-specific and experimental purposes. 77 2. Terminology 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in [RFC2119]. 83 3. Vendor-specific Message 85 The vendor-specific message may be exchanged between clients, relay 86 agents, and/or servers and allows multiple vendors to make use of the 87 message for completely different and independent purposes. 89 Clients and servers MAY chose to support this message; those that do 90 not, MUST discard the message. Relay agents SHOULD relay these 91 messages as they would other DHCPv6 messages unless the relay agent 92 understands the specific message and knows that the message was 93 directed at it. 95 Applications using these messages MUST NOT assume that all DHCPv6 96 clients, relay agents, and servers support them and MUST use good 97 networking practices when transmitting and retransmitting these 98 messages (see Section 14 of [RFC3315] for recommendations). For some 99 applications, it may be appropriate to use a Vendor Class or Vendor- 100 specific Information Option ([RFC3315]) in a standard DHCPv6 exchange 101 to negotiate whether the end-points support the vendor-specific 102 message. 104 The format of the DHCPv6 Vendor-specific Message is shown below: 106 0 1 2 3 107 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 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | msg-type | enterprise-number | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | enterprise- | vendor | | 112 | number (contd)| msg-type | . 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . 114 . options . 115 . (variable length) . 116 | | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 msg-type VENDOR-SPECIFIC (TBD) 121 enterprise-number The vendor's registered Enterprise Number as 122 registered with [EID]. 124 vendor-msg-type The vendor's message-type. The values are 125 defined by the vendor identified in the 126 enterprise-number field and are not managed 127 by IANA. 129 options The vendor specific options carried in this 130 message. 132 The options MUST be encoded as a sequence of code/length/value fields 133 of identical format to the DHCPv6 options field. The option codes 134 are defined by the vendor identified in the enterprise-number field 135 and are not managed by IANA. Each of the options is formatted as 136 follows: 138 0 1 2 3 139 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 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | opt-code | option-len | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 . . 144 . option-data . 145 . . 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 opt-code The code for the option. 150 option-len An unsigned integer giving the length of the 151 option-data field in this option in octets. 153 option-data The data area for the option. 155 4. Security Considerations 157 The Security Considerations of [RFC3315] apply. 159 This new message does potentially open up new avenues of attacking 160 clients, relay agents, or servers. The exact nature of these attacks 161 will depend on what functions and capabilities the message exposes 162 and are thus not possible to describe in this document. Clients and 163 servers that have no use for these messages SHOULD discard them and 164 thus the threat is no different than before this message was 165 assigned. 167 Vendors using this new message should use the DHCPv6 security 168 mechanisms (the Auth option or IPsec [RFC3315] as appropriate) and 169 carefully consider the security implications of the functions and 170 capabilities exposed. 172 5. IANA Considerations 174 IANA is requested to assign DHCPv6 Message type 254 to the Vendor- 175 specific Message in the registry maintained in [DHCPv6Params]: 177 254 VENDOR-SPECIFIC 179 6. References 180 6.1. Normative References 182 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 183 Requirement Levels", BCP 14, RFC 2119, March 1997. 185 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 186 and M. Carney, "Dynamic Host Configuration Protocol for 187 IPv6 (DHCPv6)", RFC 3315, July 2003. 189 [EID] IANA, "Private Enterprise Numbers. 190 http://www.iana.org/assignments/enterprise-numbers". 192 6.2. Informative References 194 [DHCPv6Params] 195 IANA, "Dynamic Host Configuration Protocol for IPv6 196 (DHCPv6). 197 http://www.iana.org/assignments/dhcpv6-parameters". 199 Author's Address 201 Bernard Volz 202 Cisco Systems, Inc. 203 1414 Massachusetts Ave. 204 Boxborough, MA 01719 205 USA 207 Phone: +1 978 936 0000 208 Email: volz@cisco.com