RFC 9304

Locator/ID Separation Protocol (LISP): Shared Extension Message and IANA Registry for Packet Type Allocations

📅 published October 2022, from ietf

RFC 9304 ✨

Okay bestie, this one is by M. Boucadair and C. Jacquenet, both at Orange 🦋 It's a Standards Track doc from the Internet Engineering Task Force (IETF), dated October 2022, with ISSN 2070-1721. It's the Locator/ID Separation Protocol (LISP) one about a Shared Extension Message and an IANA Registry for Packet Type Allocations 🎀 It obsoletes RFC 8113, so this is the new version that replaces it 🫶

Abstract 🌸

So basically, this doc creates one shared LISP message type that future extensions and experiments can all use. That way nobody has to burn a whole LISP Packet Type codepoint on every single extension 💅 It also obsoletes RFC 8113.

Status of This Memo 📜

This is an Internet Standards Track document, bestie 🌈

It's a product of the Internet Engineering Task Force (IETF), and it has the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more deets on Internet Standards, check out Section 2 of RFC 7841 🧚

For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9304 💖

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) as they stand on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no 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 🍓

Okay so, the Locator/ID Separation Protocol (LISP) base spec, [RFC9301], defines a set of primitives that are each identified with a packet type code. Several extensions have already been proposed to add more LISP functionality, and honestly it's expected that more will show up later 👑

The "LISP Packet Types" IANA registry (see Section 5) is what keeps track of LISP message types, so it's a total lifesaver for tracking 🫶

Here's the thing: the type space is limited [RFC9301], and people need to run experiments to figure out whether new LISP extensions are worth it. So 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 set aside for future LISP extensions. Sub-types are what uniquely identify a given extension that uses the shared LISP extension message type 🦋 The author(s) of the LISP specification that introduces a new LISP extension message type are the ones who pick these identifiers ✨

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 shows 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 carries a unique identifier that MUST be registered with IANA (see Section 5.2) 🍓

The exact structure of the 'extension-specific' part 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]. Those are still in play, so go read them 💀

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 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 🦋

IANA has also updated the table, like this 👑

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 too, swapping the reference to RFC 8113 for 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. Giving a short description (plus an acronym, if relevant) of the foreseen usage of the extension message is also encouraged 🫶

6. Changes from RFC 8113 🌷

Here's what changed from RFC 8113 ✨

  • Changed the status from Experimental to Standards Track.
  • Indicated explicitly that the shared extension is used for two purposes: extending the type space and conducting 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 📚

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

📦 where this page comes from