6man WG S. Gundavelli Internet-Draft O. Troan Intended status: Standards Track W. Dec Expires: August 17, 2010 Cisco S. Krishnan Ericsson February 13, 2010 IPv6 ND Vendor-Specific Information Option draft-gundavelli-6man-ipv6-nd-vendor-spec-options-00.txt Abstract The current IPv6 Neighbor Discovery specification does not provide semantics for carrying vendor-specific options in the IPv6 Neighbor Discovery messages. With the anticipated wide scale deployment of IPv6 networks, it is useful for organizations and vendors to have the ability to carry organization/vendor specific information in the IPv6 Neighbor Discovery messages. This will facilitate the vendors and organizations to make deployment specific extensions as needed in system deployment. This document defines a new vendor-specific information option that can be carried in IPv6 Neighbor Discovery messages exchanged between IPv6 nodes on a link. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 17, 2010. Gundavelli, et al. Expires August 17, 2010 [Page 1] Internet-Draft IPv6 ND Vendor-Specific Option February 2010 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Vendor-Specific Information Option . . . . . . . . . . . . . . 5 4. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Gundavelli, et al. Expires August 17, 2010 [Page 2] Internet-Draft IPv6 ND Vendor-Specific Option February 2010 1. Introduction Support for Vendor-specific options in protocol messages have proven to be extremely useful in the development and the deployments of protocols. The Mobile IPv6 [RFC3775], DHCPv6 [RFC3315], IKEv2 [RFC4306] and many other protocols have provided the needed semantics for constructing and carrying vendor-specific options in their respective protocol messages. These options have allowed vendors to implement customary extensions to protocols and distinguish themselves from other vendors. These extensions with proper name space ensured interoperability and coexistence with other implementations. A given implementation always had the option to simply skip a vendor specific option when it did not recognize the vendor ID present in the received option. Enabling this capability does not take away the fact that vendors are encouraged to bring their extensions to IETF and move it through the standards process. However, it is also important to provide the needed tools for vendors to extend protocols when the extensions are very much local to a given deployment and global standardization of those extensions are not needed. The IPv6 Neighbor Discovery specification [RFC4861] defines various messages for communication between IPv6 nodes on a link. However, the protocol does not currently support vendor specific options. This document defines a new vendor-specific information option that can be carried in IPv6 Neighbor Discovery messages exchanged between IPv6 nodes on a link. Gundavelli, et al. Expires August 17, 2010 [Page 3] Internet-Draft IPv6 ND Vendor-Specific Option February 2010 2. Requirements Language In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC2119]. Gundavelli, et al. Expires August 17, 2010 [Page 4] Internet-Draft IPv6 ND Vendor-Specific Option February 2010 3. Vendor-Specific Information Option A new option, Vendor-Specific Information Option is defined. This option is used by IPv6 Neighbor Discovery peers to exchange vendor- specific information. This option can be included in any of the IPv6 Neighbor Discovery messages. The definition of the information carried in this option is vendor specific. The vendor is indicated in the enterprise-number field. Use of vendor-specific information allows enhanced operation, utilizing additional features in a vendor's IPv6 Neighbor Discovery implementation. Multiple instances of the option can be present in a Neighbor Discovery message. The option should be padded to ensure it ends on a natural 64-bit boundary. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Type | Data....... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Vendor-Specific Information Option Type An 8-bit field indicating that it is a Neighbor Discovery Vendor-Specific option. The value to be assigned by IANA. Length 8-bit unsigned integer. The length of the option (including the type and length fields) in units of 8 octets. Vendor Id The SMI Network Management Private Enterprise Code of the IANA- maintained Private Enterprise Numbers registry [IANA- Enterprise-Numbers]. Gundavelli, et al. Expires August 17, 2010 [Page 5] Internet-Draft IPv6 ND Vendor-Specific Option February 2010 Sub-Type An 8-bit field identifies the specific vendor extension. Each vendor will manage their respective name space. Gundavelli, et al. Expires August 17, 2010 [Page 6] Internet-Draft IPv6 ND Vendor-Specific Option February 2010 4. Processing Rules The following considerations MUST be applied by all IPv6 nodes when sending and receiving any Neighbor Discovery messages with Vendor- Specific Information option. o When including a Vendor-Specific Information option in a Neighbor Discovery message, general considerations from [RFC4861] MUST be applied on the rules of inclusion of options in Neighbor Discovery messages. Additionally, if the node is a SEND [RFC3971] node, the Vendor-Specific Information option MUST precede the RSA Signature option [RFC3971]. o If there is a Vendor-Specific Information option present in the received Neighbor Discovery message, but if the vendor Id is unknown, the option SHOULD be silently ignored and the rest of the message must be processed. Gundavelli, et al. Expires August 17, 2010 [Page 7] Internet-Draft IPv6 ND Vendor-Specific Option February 2010 5. IANA Considerations This specification defines a new Neighbor Discovery option, Vendor- Specific Information Option. This is defined in Section 3.0. The type value for this option needs to be assigned from the registry, IPv6 Neighbor Discovery Option Formats, defined in [RFC4861]. Gundavelli, et al. Expires August 17, 2010 [Page 8] Internet-Draft IPv6 ND Vendor-Specific Option February 2010 6. Security Considerations The Vendor-Specific Information option defined in this specification is carried in the IPv6 Neighbor Discovery messages, like any other IPv6 Neighbor Discovery option and does not require any special security considerations. However, Neighbor Discovery messages are vulnerable to threats mentioned in [RFC3756]. These threats can be mitigated by the use Secure Neighbor Discovery [RFC3971]. Gundavelli, et al. Expires August 17, 2010 [Page 9] Internet-Draft IPv6 ND Vendor-Specific Option February 2010 7. Acknowledgements The authors would like to acknowledge Mark Townsley, Ralph Droms and Eric Voit for all the discussions on this topic. Gundavelli, et al. Expires August 17, 2010 [Page 10] Internet-Draft IPv6 ND Vendor-Specific Option February 2010 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. 8.2. Informative References [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. Gundavelli, et al. Expires August 17, 2010 [Page 11] Internet-Draft IPv6 ND Vendor-Specific Option February 2010 Authors' Addresses Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: sgundave@cisco.com Ole Troan Cisco Skoyen Atrium, Drammensveien 145A Oslo, N-0277 Norway Email: otroan@cisco.com Wojciech Dec Cisco Haarlerbergweg 13-19 Amsterdam, Noord-Holland 1101 CH Netherlands Email: wdec@cisco.com Suresh Krishnan Ericsson 8400 Blvd Decarie Town of Mount Royal, Quebec Canada Email: suresh.krishnan@ericsson.com Gundavelli, et al. Expires August 17, 2010 [Page 12]