[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/