diff options
Diffstat (limited to 'doc/rfc/rfc9304.txt')
| -rw-r--r-- | doc/rfc/rfc9304.txt | 237 |
1 files changed, 237 insertions, 0 deletions
diff --git a/doc/rfc/rfc9304.txt b/doc/rfc/rfc9304.txt new file mode 100644 index 0000000..238683a --- /dev/null +++ b/doc/rfc/rfc9304.txt @@ -0,0 +1,237 @@ + + + + +Internet Engineering Task Force (IETF) M. Boucadair +Request for Comments: 9304 C. Jacquenet +Obsoletes: 8113 Orange +Category: Standards Track October 2022 +ISSN: 2070-1721 + + +Locator/ID Separation Protocol (LISP): Shared Extension Message and IANA + Registry for Packet Type Allocations + +Abstract + + This document specifies a Locator/ID Separation Protocol (LISP) + shared message type for defining future extensions and conducting + experiments without consuming a LISP Packet Type codepoint for each + extension. + + This document obsoletes RFC 8113. + +Status of This Memo + + This is an Internet Standards Track document. + + 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). Further information on + Internet Standards is available in 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/rfc9304. + +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 Language + 3. LISP Shared Extension Message Type + 4. Security Considerations + 5. IANA Considerations + 5.1. LISP Packet Types + 5.2. Sub-Types + 6. Changes from RFC 8113 + 7. Normative References + Acknowledgments + Authors' Addresses + +1. Introduction + + The Locator/ID Separation Protocol (LISP) base specification, + [RFC9301], defines a set of primitives that are identified with a + packet type code. Several extensions have been proposed to add more + LISP functionalities. It is expected that additional LISP extensions + will be proposed in the future. + + The "LISP Packet Types" IANA registry (see Section 5) is used to ease + the tracking of LISP message types. + + Because of the limited type space [RFC9301] and the need to conduct + experiments to assess new LISP extensions, this document specifies a + shared LISP extension message type and describes a procedure for + registering LISP shared extension sub-types (see Section 3). + Concretely, one single LISP message type code is dedicated to future + LISP extensions; sub-types are used to uniquely identify a given LISP + extension making use of the shared LISP extension message type. + These identifiers are selected by the author(s) of the corresponding + LISP specification that introduces a new LISP extension message type. + +2. Requirements Language + + 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. LISP Shared Extension Message Type + + Figure 1 depicts the common format of the LISP shared extension + message. The type field MUST be set to 15 (see Section 5). + + 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=15| Sub-type | extension-specific | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + // extension-specific // + // // + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1: LISP Shared Extension Message Type + + The 'Sub-type' field conveys a unique identifier that MUST be + registered with IANA (see Section 5.2). + + The exact structure of the 'extension-specific' portion of the + message is specified in the corresponding specification document. + +4. Security Considerations + + This document does not introduce any additional security issues other + than those discussed in [RFC9301]. + +5. IANA Considerations + +5.1. LISP Packet Types + + IANA has created a registry titled "LISP Packet Types", numbered + 0-15. + + Values can be assigned via Standards Action [RFC8126]. Documents + that request for a new LISP Packet Type may indicate a preferred + value in the corresponding IANA sections. + + IANA has replaced the reference to RFC 8113 with the RFC number of + this document. + + Also, IANA has updated the table as follows: + + OLD: + + +===============================+======+===========+ + | Message | Code | Reference | + +===============================+======+===========+ + | LISP Shared Extension Message | 15 | [RFC8113] | + +-------------------------------+------+-----------+ + + Table 1 + + NEW: + + +===============================+======+===========+ + | Message | Code | Reference | + +===============================+======+===========+ + | LISP Shared Extension Message | 15 | RFC 9304 | + +-------------------------------+------+-----------+ + + Table 2 + +5.2. Sub-Types + + IANA has created the "LISP Shared Extension Message Type Sub-types" + registry. IANA has updated that registry by replacing the reference + to RFC 8113 with the RFC number of this document. + + The values in the range 0-1023 are assigned via Standards Action. + This range is provisioned to anticipate, in particular, the + exhaustion of the LISP Packet Types. + + The values in the range 1024-4095 are assigned on a First Come, First + Served (FCFS) basis. The registration procedure is to provide IANA + with the desired codepoint and a point of contact; providing a short + description (together with an acronym, if relevant) of the foreseen + usage of the extension message is also encouraged. + +6. Changes from RFC 8113 + + The following changes were made from RFC 8113: + + * Changed the status from Experimental to Standards Track. + + * Indicated explicitly that the shared extension is used for two + purposes: extend the type space and conduct experiments to assess + new LISP extensions. + + * Deleted pointers to some examples illustrating how the shared + extension message is used to extend the LISP protocol. + + * IANA has updated the "IANA LISP Packet Types" and "LISP Shared + Extension Message Type Sub-types" registries to point to this + document instead of RFC 8113. + +7. Normative References + + [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>. + + [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>. + + [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 + + This work is partly funded by ANR LISP-Lab project #ANR-13-INFR- + 009-X. + + Many thanks to Luigi Iannone, Dino Farinacci, and Alvaro Retana for + the review. + + Thanks to Geoff Huston, Brian Carpenter, Barry Leiba, and Suresh + Krishnan for the review. + +Authors' Addresses + + Mohamed Boucadair + Orange + 35000 Rennes + France + Email: mohamed.boucadair@orange.com + + + Christian Jacquenet + Orange + 35000 Rennes + France + Email: christian.jacquenet@orange.com |