idnits 2.17.1 draft-ietf-dhc-dhcpv6-vendor-message-00.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? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 (January 12, 2009) is 5583 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' -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 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 January 12, 2009 5 Expires: July 16, 2009 7 DHCPv6 Vendor-specific Message 8 10 Status of this Memo 11 S 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 July 16, 2009. 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 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. 45 Abstract 47 This document requests a vendor-specific DHCPv6 message assignment. 48 This message can be used for vendor specific and experimental 49 purposes. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Vendor-specific Message . . . . . . . . . . . . . . . . . . . . 3 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 58 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 60 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 1. Introduction 65 The DHCPv6 [RFC3315] protocol specifies a mechanism for the 66 assignment of addresses and configuration information to nodes. The 67 protocol provides for 256 possible message codes, of which a small 68 number are assigned ([DHCPv6Params]). Each of the assigned message 69 codes have specific purposes. New message codes are assigned through 70 IETF Standards Action as defined in [RFC2434] (see Section 24 of 71 [RFC3315]). 73 There may be a need for vendors of DHCPv6 clients, relay agents, or 74 servers to experiment with new capabilities that require new messages 75 to be exchanged between these elements. Thus, this document defines 76 the format for and requests that a new message code be reserved for 77 vendor-specific and experimental purposes. 79 2. Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119]. 85 3. Vendor-specific Message 87 The vendor-specific message may be exchanged between clients, relay 88 agents, and/or servers and allows multiple vendors to make use of the 89 message for completely different and independent purposes. 91 Clients and servers MAY chose to support this message; those that do 92 not, MUST discard the message. Relay agents SHOULD relay these 93 messages as they would other DHCPv6 messages unless the relay agent 94 understands the specific message and knows that the message was 95 directed at it. 97 Applications using these messages MUST NOT assume that all DHCPv6 98 clients, relay agents, and servers support them and MUST use good 99 networking practices when transmitting and retransmitting these 100 messages (see Section 14 of [RFC3315] for recommendations). For some 101 applications, it may be appropriate to use a Vendor Class or Vendor- 102 specific Information Option ([RFC3315]) in a standard DHCPv6 exchange 103 to negotiate whether the end-points support the vendor-specific 104 message. 106 The format of the DHCPv6 Vendor-specific Message is shown below: 108 0 1 2 3 109 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 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | msg-type | enterprise-number | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | enterprise- | vendor | | 114 | number (contd)| msg-type | . 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . 116 . options . 117 . (variable length) . 118 | | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 msg-type VENDOR-SPECIFIC (to-be-assigned) 123 enterprise-number The vendor's registered Enterprise Number as 124 registered with [EID]. 126 vendor-msg-type The vendor's message-type. The values are 127 defined by the vendor identified in the 128 enterprise-number field and are not managed 129 by IANA. 131 options The vendor specific options carried in this 132 message. 134 The options MUST be encoded as a sequence of code/length/value fields 135 of identical format to the DHCPv6 options field. The option codes 136 are defined by the vendor identified in the enterprise-number field 137 and are not managed by IANA. Each of the options is formatted as 138 follows: 140 0 1 2 3 141 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 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | opt-code | option-len | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 . . 146 . option-data . 147 . . 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 opt-code The code for the option. 152 option-len An unsigned integer giving the length of the 153 option-data field in this option in octets. 155 option-data The data area for the option. 157 4. Security Considerations 159 The Security Considerations of [RFC3315] apply. 161 This new message does potentially open up new avenues of attacking 162 clients, relay agents, or servers. The exact nature of these attacks 163 will depend on what functions and capabilities the message exposes 164 and are thus not possible to describe in this document. Clients and 165 servers that have no use for these messages SHOULD discard them and 166 thus the threat is no different than before this message was 167 assigned. 169 Vendors using this new message should use the DHCPv6 security 170 mechanisms (the Auth option or IPsec [RFC3315] as appropriate) and 171 carefully consider the security implications of the functions and 172 capabilities exposed. 174 5. IANA Considerations 176 IANA is requested to assign DHCPv6 Message type 254 to the Vendor- 177 specific Message in the registry maintained in [DHCPv6Params]: 179 254 VENDOR-SPECIFIC 181 6. References 182 6.1. Normative References 184 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 185 Requirement Levels", BCP 14, RFC 2119, March 1997. 187 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 188 and M. Carney, "Dynamic Host Configuration Protocol for 189 IPv6 (DHCPv6)", RFC 3315, July 2003. 191 [EID] IANA, "Private Enterprise Numbers. 192 http://www.iana.org/assignments/enterprise-numbers". 194 6.2. Informative References 196 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 197 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 198 October 1998. 200 [DHCPv6Params] 201 IANA, "Dynamic Host Configuration Protocol for IPv6 202 (DHCPv6). 203 http://www.iana.org/assignments/dhcpv6-parameters". 205 Author's Address 207 Bernard Volz 208 Cisco Systems, Inc. 209 1414 Massachusetts Ave. 210 Boxborough, MA 01719 211 USA 213 Phone: +1 978 936 0000 214 Email: volz@cisco.com