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]