doc: Add RFC documents

1 files changed, 255 insertions, 0 deletions

diff --git a/doc/rfc/rfc9306.txt b/doc/rfc/rfc9306.txt
new file mode 100644
index 0000000..7b1bc37
--- /dev/null
+++ b/doc/rfc/rfc9306.txt
@@ -0,0 +1,255 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                A. Rodriguez-Natal
+Request for Comments: 9306                                         Cisco
+Updates: 8060                                                 V. Ermagan
+Category: Experimental                                      Google, Inc.
+ISSN: 2070-1721                                               A. Smirnov
+                                                           V. Ashtaputre
+                                                                   Cisco
+                                                            D. Farinacci
+                                                             lispers.net
+                                                            October 2022
+
+
+          Vendor-Specific LISP Canonical Address Format (LCAF)
+
+Abstract
+
+   This document describes a new Locator/ID Separation Protocol (LISP)
+   Canonical Address Format (LCAF), the Vendor-Specific LCAF.  This LCAF
+   enables organizations to have implementation-specific encodings for
+   LCAF addresses.  This document updates RFC 8060.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  This document is a product of the Internet Engineering
+   Task Force (IETF).  It represents the consensus of the IETF
+   community.  It has received public review and has been approved for
+   publication by the Internet Engineering Steering Group (IESG).  Not
+   all documents approved by the IESG are candidates for any level of
+   Internet Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9306.
+
+Copyright Notice
+
+   Copyright (c) 2022 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
+   (https://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 Revised BSD License text as described in Section 4.e of the
+   Trust Legal Provisions and are provided without warranty as described
+   in the Revised BSD License.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Requirements Notation
+   3.  Unrecognized LCAF Types
+   4.  Vendor-Specific LCAF
+   5.  Security Considerations
+   6.  IANA Considerations
+   7.  Normative References
+   Acknowledgments
+   Authors' Addresses
+
+1.  Introduction
+
+   The LISP Canonical Address Format (LCAF) [RFC8060] defines the format
+   and encoding for different address types that can be used on
+   deployments of the Locator/ID Separation Protocol (LISP) [RFC9300]
+   [RFC9301].  However, certain deployments require specific format
+   encodings that may not be applicable outside of the use case for
+   which they are defined.  This document extends [RFC8060] to introduce
+   a Vendor-Specific LCAF that defines how organizations can create LCAF
+   addresses to be used only on particular LISP implementations.  This
+   document also updates [RFC8060] to specify the behavior when
+   receiving unrecognized LCAF types.
+
+2.  Requirements Notation
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+3.  Unrecognized LCAF Types
+
+   [RFC8060] does not explain how an implementation should handle an
+   unrecognized LCAF type.  This document updates [RFC8060] to specify
+   that any unrecognized LCAF type received in a LISP control plane
+   message MUST be ignored.  If all Locators are ignored, this is
+   equivalent to a LISP control message with Locator Count = 0, as
+   described in [RFC9301].  If an EID-Prefix only contains unrecognized
+   LCAF types, the LISP control message MUST be dropped and the event
+   MUST be logged.  (Here, "EID" refers to Endpoint Identifier.)
+
+4.  Vendor-Specific LCAF
+
+   The Vendor-Specific LCAF relies on using the IEEE Organizationally
+   Unique Identifier (OUI) [IEEE.802] to prevent collisions across
+   vendors or organizations using the LCAF.  The format of the Vendor-
+   Specific LCAF is provided below.
+
+
+      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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |           AFI = 16387         |     Rsvd1     |     Flags     |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |   Type = 255  |     Rsvd2     |            Length             |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |      Rsvd3    |    Organizationally Unique Identifier (OUI)   |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                        Internal format...                     |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                       Figure 1: Vendor-Specific LCAF
+
+   The fields in the first 8 octets of the above Vendor-Specific LCAF
+   are actually the fields defined in the general LCAF format specified
+   in [RFC8060].  The Type field MUST be set 255, the value assigned by
+   IANA to indicate that this is a Vendor-Specific LCAF; see Section 6.
+   The Length field has to be set accordingly to the length of the
+   internal format, plus the OUI, plus the Rsvd3 fields, as for
+   [RFC8060].  The fields defined by the Vendor-Specific LCAF are as
+   follows:
+
+   Rsvd3:  This 8-bit field is reserved for future use.  It MUST be set
+      to 0 on transmit and MUST be ignored on receipt.
+
+   Organizationally Unique Identifier (OUI):  This is a 24-bit field
+      that carries an OUI or Company ID (CID) assigned by the IEEE
+      Registration Authority (RA) as defined by the IEEE Std 802
+      [IEEE.802]
+
+   Internal format:  This is a variable-length field that is left
+      undefined on purpose.  Each vendor or organization can define its
+      own internal format(s) to use with the Vendor-Specific LCAF.
+
+   The Vendor-Specific LCAF type SHOULD NOT be used in deployments where
+   different organizations interoperate.  However, there may be cases
+   where two (or more) organizations share a common deployment on which
+   they explicitly and mutually agree to use a particular Vendor-
+   Specific LCAF.  In that case, the organizations involved need to
+   carefully assess the interoperability concerns for that particular
+   deployment.  It is NOT RECOMMENDED to use an OUI not assigned to an
+   organization.
+
+   If a LISP device receives a LISP message containing a Vendor-Specific
+   LCAF with an OUI that it does not understand, it MUST drop the
+   message and it SHOULD create a log message.
+
+5.  Security Considerations
+
+   This document enables organizations to define new LCAFs for their
+   internal use.  It is the responsibility of these organizations to
+   properly assess the security implications of the formats they define.
+   Security considerations from [RFC8060] apply to this document.
+
+6.  IANA Considerations
+
+   Following the guidelines of [RFC8126], IANA has assigned the
+   following value for the Vendor-Specific LCAF from the "LISP Canonical
+   Address Format (LCAF) Types" registry (defined in [RFC8060]):
+
+           +=======+=====================+=====================+
+           | Value | LISP LCAF Type Name |      Reference      |
+           +=======+=====================+=====================+
+           |  255  |   Vendor Specific   | RFC 9306, Section 4 |
+           +-------+---------------------+---------------------+
+
+                  Table 1: Vendor-Specific LCAF Assignment
+
+7.  Normative References
+
+   [IEEE.802] IEEE, "IEEE Standard for Local and Metropolitan Area
+              Networks: Overview and Architecture",
+              DOI 10.1109/IEEESTD.2014.6847097, IEEE Std 802, July 2014,
+              <https://ieeexplore.ieee.org/document/6847097>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC8060]  Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
+              Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,
+              February 2017, <https://www.rfc-editor.org/info/rfc8060>.
+
+   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+              Writing an IANA Considerations Section in RFCs", BCP 26,
+              RFC 8126, DOI 10.17487/RFC8126, June 2017,
+              <https://www.rfc-editor.org/info/rfc8126>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC9300]  Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
+              Cabellos, Ed., "The Locator/ID Separation Protocol
+              (LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022,
+              <https://www.rfc-editor.org/info/rfc9300>.
+
+   [RFC9301]  Farinacci, D., Maino, F., Fuller, V., and A. Cabellos,
+              Ed., "Locator/ID Separation Protocol (LISP) Control
+              Plane", RFC 9301, DOI 10.17487/RFC9301, October 2022,
+              <https://www.rfc-editor.org/info/rfc9301>.
+
+Acknowledgments
+
+   The authors would like to thank Joel Halpern, Luigi Iannone, and
+   Alvaro Retana for their suggestions and guidance regarding this
+   document.
+
+Authors' Addresses
+
+   Alberto Rodriguez-Natal
+   Cisco
+   Spain
+   Email: natal@cisco.com
+
+
+   Vina Ermagan
+   Google, Inc.
+   1600 Amphitheatre Parkway
+   Mountain View, CA 94043
+   United States of America
+   Email: ermagan@gmail.com
+
+
+   Anton Smirnov
+   Cisco
+   Diegem
+   Belgium
+   Email: asmirnov@cisco.com
+
+
+   Vrushali Ashtaputre
+   Cisco
+   San Jose, CA
+   United States of America
+   Email: vrushali@cisco.com
+
+
+   Dino Farinacci
+   lispers.net
+   San Jose, CA
+   United States of America
+   Email: farinacci@gmail.com