idnits 2.17.1 draft-gundavelli-6man-ipv6-nd-vendor-spec-options-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 13, 2010) is 5184 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 informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man WG S. Gundavelli 3 Internet-Draft O. Troan 4 Intended status: Standards Track W. Dec 5 Expires: August 17, 2010 Cisco 6 S. Krishnan 7 Ericsson 8 February 13, 2010 10 IPv6 ND Vendor-Specific Information Option 11 draft-gundavelli-6man-ipv6-nd-vendor-spec-options-00.txt 13 Abstract 15 The current IPv6 Neighbor Discovery specification does not provide 16 semantics for carrying vendor-specific options in the IPv6 Neighbor 17 Discovery messages. With the anticipated wide scale deployment of 18 IPv6 networks, it is useful for organizations and vendors to have the 19 ability to carry organization/vendor specific information in the IPv6 20 Neighbor Discovery messages. This will facilitate the vendors and 21 organizations to make deployment specific extensions as needed in 22 system deployment. This document defines a new vendor-specific 23 information option that can be carried in IPv6 Neighbor Discovery 24 messages exchanged between IPv6 nodes on a link. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on August 17, 2010. 49 Copyright Notice 51 Copyright (c) 2010 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 70 3. Vendor-Specific Information Option . . . . . . . . . . . . . . 5 72 4. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 7 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 82 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 86 1. Introduction 88 Support for Vendor-specific options in protocol messages have proven 89 to be extremely useful in the development and the deployments of 90 protocols. The Mobile IPv6 [RFC3775], DHCPv6 [RFC3315], IKEv2 91 [RFC4306] and many other protocols have provided the needed semantics 92 for constructing and carrying vendor-specific options in their 93 respective protocol messages. These options have allowed vendors to 94 implement customary extensions to protocols and distinguish 95 themselves from other vendors. These extensions with proper name 96 space ensured interoperability and coexistence with other 97 implementations. A given implementation always had the option to 98 simply skip a vendor specific option when it did not recognize the 99 vendor ID present in the received option. 101 Enabling this capability does not take away the fact that vendors are 102 encouraged to bring their extensions to IETF and move it through the 103 standards process. However, it is also important to provide the 104 needed tools for vendors to extend protocols when the extensions are 105 very much local to a given deployment and global standardization of 106 those extensions are not needed. 108 The IPv6 Neighbor Discovery specification [RFC4861] defines various 109 messages for communication between IPv6 nodes on a link. However, 110 the protocol does not currently support vendor specific options. 111 This document defines a new vendor-specific information option that 112 can be carried in IPv6 Neighbor Discovery messages exchanged between 113 IPv6 nodes on a link. 115 2. Requirements Language 117 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 118 "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as 119 described in [RFC2119]. 121 3. Vendor-Specific Information Option 123 A new option, Vendor-Specific Information Option is defined. This 124 option is used by IPv6 Neighbor Discovery peers to exchange vendor- 125 specific information. This option can be included in any of the IPv6 126 Neighbor Discovery messages. 128 The definition of the information carried in this option is vendor 129 specific. The vendor is indicated in the enterprise-number field. 130 Use of vendor-specific information allows enhanced operation, 131 utilizing additional features in a vendor's IPv6 Neighbor Discovery 132 implementation. Multiple instances of the option can be present in a 133 Neighbor Discovery message. The option should be padded to ensure it 134 ends on a natural 64-bit boundary. 136 0 1 2 3 137 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 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | Type | Length | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Vendor ID | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Sub-Type | Data....... 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 Figure 1: Vendor-Specific Information Option 148 Type 150 An 8-bit field indicating that it is a Neighbor Discovery 151 Vendor-Specific option. The value to be assigned by IANA. 153 Length 155 8-bit unsigned integer. The length of the option (including 156 the type and length fields) in units of 8 octets. 158 Vendor Id 160 The SMI Network Management Private Enterprise Code of the IANA- 161 maintained Private Enterprise Numbers registry [IANA- 162 Enterprise-Numbers]. 164 Sub-Type 166 An 8-bit field identifies the specific vendor extension. Each 167 vendor will manage their respective name space. 169 4. Processing Rules 171 The following considerations MUST be applied by all IPv6 nodes when 172 sending and receiving any Neighbor Discovery messages with Vendor- 173 Specific Information option. 175 o When including a Vendor-Specific Information option in a Neighbor 176 Discovery message, general considerations from [RFC4861] MUST be 177 applied on the rules of inclusion of options in Neighbor Discovery 178 messages. Additionally, if the node is a SEND [RFC3971] node, the 179 Vendor-Specific Information option MUST precede the RSA Signature 180 option [RFC3971]. 182 o If there is a Vendor-Specific Information option present in the 183 received Neighbor Discovery message, but if the vendor Id is 184 unknown, the option SHOULD be silently ignored and the rest of the 185 message must be processed. 187 5. IANA Considerations 189 This specification defines a new Neighbor Discovery option, Vendor- 190 Specific Information Option. This is defined in Section 3.0. The 191 type value for this option needs to be assigned from the registry, 192 IPv6 Neighbor Discovery Option Formats, defined in [RFC4861]. 194 6. Security Considerations 196 The Vendor-Specific Information option defined in this specification 197 is carried in the IPv6 Neighbor Discovery messages, like any other 198 IPv6 Neighbor Discovery option and does not require any special 199 security considerations. However, Neighbor Discovery messages are 200 vulnerable to threats mentioned in [RFC3756]. These threats can be 201 mitigated by the use Secure Neighbor Discovery [RFC3971]. 203 7. Acknowledgements 205 The authors would like to acknowledge Mark Townsley, Ralph Droms and 206 Eric Voit for all the discussions on this topic. 208 8. References 210 8.1. Normative References 212 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 213 Requirement Levels", BCP 14, RFC 2119, March 1997. 215 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 216 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 217 September 2007. 219 8.2. Informative References 221 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 222 and M. Carney, "Dynamic Host Configuration Protocol for 223 IPv6 (DHCPv6)", RFC 3315, July 2003. 225 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 226 Discovery (ND) Trust Models and Threats", RFC 3756, 227 May 2004. 229 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 230 in IPv6", RFC 3775, June 2004. 232 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 233 Neighbor Discovery (SEND)", RFC 3971, March 2005. 235 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 236 RFC 4306, December 2005. 238 Authors' Addresses 240 Sri Gundavelli 241 Cisco 242 170 West Tasman Drive 243 San Jose, CA 95134 244 USA 246 Email: sgundave@cisco.com 248 Ole Troan 249 Cisco 250 Skoyen Atrium, Drammensveien 145A 251 Oslo, N-0277 252 Norway 254 Email: otroan@cisco.com 256 Wojciech Dec 257 Cisco 258 Haarlerbergweg 13-19 259 Amsterdam, Noord-Holland 1101 CH 260 Netherlands 262 Email: wdec@cisco.com 264 Suresh Krishnan 265 Ericsson 266 8400 Blvd Decarie 267 Town of Mount Royal, Quebec 268 Canada 270 Email: suresh.krishnan@ericsson.com