RFC 8113

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

📅 published March 2017, from ietf

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

okay bestie, this is RFC 8113 and it's giving experimental energy 🔬✨ Here's the title block tea:

  • Series: Internet Engineering Task Force (IETF) Request for Comments, RFC 8113
  • Authors: M. Boucadair and C. Jacquenet, both at Orange 💅
  • Category: Experimental
  • Date: March 2017
  • Updates: RFC 6830
  • Obsoletes: none listed
  • ISSN: 2070-1721

Abstract 🌸

okay so this doc specifies a shared message type for LISP (Locator/ID Separation Protocol) 🌈 The whole point is that future extensions and experiments can happen without burning a brand new LISP packet type codepoint every single time. It also creates a registry for LISP Packet Type allocations, and it updates RFC 6830 while doing it. the way that's so efficient 😭

Status of This Memo 📜

this one is not an Internet Standards Track spec. it's published for examination, experimental implementation, and evaluation 🧪

it does define an Experimental Protocol for the Internet community. it's a product of the IETF and it represents IETF community consensus. it got public review and was approved for publication by the IESG. not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 for the deets ✨

for current status, errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc8113 🎀

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. 🔒

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the publication date. read those carefully, because they spell out your rights and restrictions 🙈 Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License.

Table of Contents 🗺️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
3.  LISP Shared Extension Message Type  . . . . . . . . . . . . .   3
4.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
  5.1.  LISP Packet Types . . . . . . . . . . . . . . . . . . . .   4
  5.2.  Sub-Types . . . . . . . . . . . . . . . . . . . . . . . .   4
6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
  6.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
  6.2.  Informative References  . . . . . . . . . . . . . . . . .   5
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   6
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1. Introduction ✨

okay so the LISP base spec, [RFC6830], defines a bunch of primitives that are each identified by a packet type code 💖 People have proposed several extensions to add more LISP functionality. for example, new message types have been proposed in [LISP-DDT], [LISP-MN-EXT], [LISP-BULK], [NAT-LISP], or [LISP-SUBSCRIBE]. and it's expected that even more LISP extensions will show up in the future 🚀

so to make LISP message types easier to track, this doc proposes creating a "LISP Packet Types" IANA registry (see Section 5) 📋

the type space is limited [RFC6830], and people need to run experiments to figure out new LISP extensions. so this doc specifies a shared LISP extension message type and proposes a procedure for registering shared extension sub-types (see Section 3) 🦋

basically, one single LISP message type code is set aside for future LISP extensions. sub-types are what uniquely identify a specific extension that uses the shared message type. those identifiers get picked by the author(s) of the LISP spec that introduces the new extension message type 🫶

2. Requirements Language 💅

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🎀

3. LISP Shared Extension Message Type 🧚

so this figure 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 defined in the corresponding specification document 💜

4. Security Considerations 💀

okay, the serious part 🙈 this document does not introduce any additional security issues other than the ones discussed in [RFC6830]. so go read that one for the security stuff 🔐

5. IANA Considerations 📋

5.1. LISP Packet Types 🍓

IANA has created a new protocol registry for LISP Packet Types, numbered 0-15. the registry starts out populated with these values:

Message                           Code    Reference
================================= ==== ===============
Reserved                           0      [RFC6830]
LISP Map-Request                   1      [RFC6830]
LISP Map-Reply                     2      [RFC6830]
LISP Map-Register                  3      [RFC6830]
LISP Map-Notify                    4      [RFC6830]
LISP Encapsulated Control Message  8      [RFC6830]
LISP Shared Extension Message     15      [RFC8113]

the values in the ranges 5-7 and 9-14 can be assigned via Standards Action [RFC5226]. documents that request a new LISP packet type may indicate a preferred value in the corresponding IANA sections 🌸

5.2. Sub-Types 🌷

IANA has created the "LISP Shared Extension Message Type Sub-types" registry. no initial values are assigned when the registry is created, and (0-4095) are available for future assignments 🦋

the values in the range 0-1023 are assigned via Standards Action. this range is set up 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 should provide IANA with the desired codepoint and a point of contact. giving a short description (plus an acronym, if relevant) of the planned usage of the extension message is also encouraged ✨

6. References 📚

6.1. Normative References 💖

6.2. Informative References 🧚

  • [LISP-BULK] Boucadair, M. and C. Jacquenet, "LISP Mapping Bulk Retrieval", Work in Progress, draft-boucadair-lisp-bulk-04, February 2017.
  • [LISP-DDT] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. Smirnov, "LISP Delegated Database Tree", Work in Progress, draft-ietf-lisp-ddt-09, January 2017.
  • [LISP-MN-EXT] Wang, J., Meng, Y., and N. Zhao, "LISP Mobile Node extension", Work in Progress, draft-zhao-lisp-mn-extension-02, October 2011.
  • [LISP-SUBSCRIBE] Boucadair, M. and C. Jacquenet, "LISP Subscription", Work in Progress, draft-boucadair-lisp-subscribe-04, February 2017.
  • [NAT-LISP] Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, F., and C. White, "NAT traversal for LISP", Work in Progress, draft-ermagan-lisp-nat-traversal-11, August 2016.

Acknowledgments 🫶

this work is partly funded by ANR LISP-Lab project #ANR-13-INFR-009-X 💜

huge thanks to Luigi Iannone, Dino Farinacci, and Alvaro Retana for the review 👑 and thanks to Geoff Huston for the RtgDir directorate review 🌟

Authors' Addresses 🎀

Mohamed Boucadair Orange Rennes 35000 France

Email: mohamed.boucadair@orange.com

Christian Jacquenet Orange Rennes 35000 France

Email: christian.jacquenet@orange.com

📦 where this page comes from