RFC 7955

Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block

📅 published September 2016, from ietf

Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block 🎀

RFC 7955, bestie, and it's from September 2016 🦋

The title block tells us the basics. Four authors wrote this together: L. Iannone (Telecom ParisTech), R. Jorgensen (Bredbandsfylket Troms), D. Conrad (Virtualized, LLC), and G. Huston (APNIC). It's Informational, not Standards Track, and the ISSN is 2070-1721. The header doesn't list any document it obsoletes or updates, so there's nothing to chase there 💅

Abstract ✨

okay so this doc proposes a framework for managing the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) address block 🌸 The vibe is hierarchical distribution. Requesting organizations get temporary use of prefixes from that space, and it's giving experiment energy the whole way through 🧚

Status of This Memo 📜

This document is not an Internet Standards Track specification. It's published for informational purposes 🍓

It's still a product of the IETF, so it represents IETF community consensus. It got public review and the IESG approved it for publication. Not every IESG-approved doc is a candidate for any level of Internet Standard, though. See Section 2 of RFC 7841 for that 🙈

You can find the current status, any errata, and how to send feedback at http://www.rfc-editor.org/info/rfc7955 🫶

Copyright (c) 2016 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 they stood on the date of publication. Please actually read those, bestie, because they spell out your rights and restrictions for this doc 📚 Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, as the Simplified BSD License describes ⚖️

Table of Contents 🗂️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   3
3.  Definition of Terms . . . . . . . . . . . . . . . . . . . . .   3
4.  EID Prefix Registration Policy  . . . . . . . . . . . . . . .   3
5.  EID Prefixes Registration Requirements  . . . . . . . . . . .   4
6.  EID Prefix Request Template . . . . . . . . . . . . . . . . .   4
7.  Policy Validity Period  . . . . . . . . . . . . . . . . . . .   6
8.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
10. Procedures to be Followed by RIPE NCC . . . . . . . . . . . .   7
11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
  11.1.  Normative References . . . . . . . . . . . . . . . . . .   8
  11.2.  Informative References . . . . . . . . . . . . . . . . .   8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  10
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1. Introduction ✨

so LISP ([RFC6830]) and its related mechanisms ([RFC6831], [RFC6832], [RFC6833], [RFC6834], [RFC6835], [RFC6836], [RFC6837]) split the IP addressing space into two logical spaces 🧩 One is the Endpoint Identifier (EID) space, which identifies communication endpoints. The other is the Routing Locator (RLOC) space, which is used to locate EIDs in the Internet routing infrastructure topology. It's a whole separation of jobs and I'm obsessed 😭

[RFC7954] asks for an IPv6 address block reservation, used exclusively for EID prefixes in the LISP experiment. The rationale, intent, size, and usage of that EID address block all live in [RFC7954] 💅

This document lays out a management framework for registering EID prefixes from that block. The requesting organization gets exclusive use of those EID prefixes, but only for the duration of the LISP experiment 🦋

2. Requirements Notation 🎀

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. Definition of Terms 📖

This doc doesn't introduce any new terms for the set of LISP Specifications ([RFC6830], [RFC6831], [RFC6832], [RFC6833], [RFC6834], [RFC6835], [RFC6836], [RFC6837]). It assumes you already know LISP terminology, which is fair 🧚 If you need a refresher, [INTRO] gives an introduction to LISP technology, terminology included 💜

4. EID Prefix Registration Policy 👑

Okay, the rules for requesting a registration of EID prefixes MUST be done under these policies:

  1. EID prefixes are handed out in the reserved space on a temporary basis, for experimental uses 🧪 Whoever requests an experimental prefix MUST give a short description of the intended use or the experiment they'll run (see Section 6). If the prefix ends up being used for stuff that isn't in the original description, the renewal may be denied. Not me, not using it for vibes it wasn't approved for 💀
  2. EID prefix registrations MUST be renewed on a regular basis. That keeps them in the hands of active participants in the experiment 🌈 The registration period is 12 months. A renewal SHOULD NOT change the EID prefix from the one in the previous request ✨ The renewal conditions have to match the conditions of the first EID prefix registration request. Consistency is everything 🫶
  3. It's preferable that EID prefixes whose registrations have expired aren't reused 🍓 When an EID prefix registration gets removed from the registry, reusing that prefix in a later registration for a different end user should be avoided where possible. If overall usage of the EID block requires reusing a previously registered EID prefix, the registry operator SHOULD apply a minimum delay of at least one week between the removal and the new registration. Give it a breather, bestie 🌸
  4. When the reserved experimental LISP EID block expires, all EID prefix registrations expire too 🥀 What happens to those prefixes and their registry entries after that is supposed to be specified in the announcement that ends the experiment 📣

5. EID Prefixes Registration Requirements 💅

Every EID prefix registration MUST satisfy the following requirements, no exceptions, periodt:

  1. Every EID prefix registration MUST use a globally unique EID prefix 🌍
  2. The EID prefix registration information, as specified in Section 6, MUST be collected at initial registration and at renewal. It also has to be publicly available, through interfaces that allow both retrieving specific registration details (search) and listing the entire registry contents. Examples of those access methods are RDAP ([RFC7481]), WHOIS, HTTP, or something similar 🔍
  3. The registry operator MUST allow holders of registered EID prefixes to delegate those prefixes in the reverse DNS space 🔁
  4. Anyone can get an entry in the EID prefix registry 🙌 The deal is that the prefix registered is for exclusive use in the LISP experimental network, and that the registration details (as specified in Section 6) are openly published in the EID prefix registry. Transparency is the whole tea ☕
⚠️ Heads up: the registration details in Section 6 are published openly, so don't put anything in there you're not okay with the whole internet seeing.
🧵 Part 1 ends here, bestie. Part 2 picks up with Section 6 and runs through the rest of the document, including Section 6 onward, Security Considerations, IANA Considerations, References, and the rest 💖

Okay so, this is the home stretch, bestie, and we are going OUT with a bang 💅✨ Here's the rest of the doc, including the IANA stuff, the RIPE NCC procedures, and the reference lists 🫶

9. IANA Considerations ✨

IANA gave the following IPv6 address block to the LISP EID prefix experiment, and it's for experimental use only 🦋 [RFC7954]:

  • Address Block: 2001:5::/32
  • Name: EID Space for LISP
  • RFC: [RFC7954]
  • Further details are at: www.iana.org/assignments/iana-ipv6-special-registry

Okay so here's the thing 🧚 to let orgs and individuals have exclusive use of EID prefixes out of this reserved block (and only for as long as the LISP experiment runs, see Section 7), we need an operational EID registration service. Like, it's giving necessary infrastructure 💀

As long as the policies and requirements in Sections 4, 5, and 6 are met, EID prefix registration is handed out on a "First Come First Served" basis 🍓

There's no hard limit on how many registrations an org or person can submit, as long as the info described in Section 6 is included, especially point 4: "Experiment Description" 🌈

For the duration defined in [RFC7954], RIPE NCC will manage the LISP EID prefix as described here. So, bestie, this document has no IANA actions 🙈

10. Procedures to be Followed by RIPE NCC 💖

RIPE NCC is the one running the registration service 👑, and it has to follow the EID Prefix Registration Policy (Section 4) and the EID Prefix Registration Requirements (Section 5) in this document. The request form RIPE NCC provides has to include at least the info from the template in Section 6 📝. RIPE NCC will make every received request publicly available 🌸. This document doesn't suggest any minimum allocation size, but RIPE NCC is allowed to bring in one for management purposes 💅

11. References 🎀

11.1. Normative References

11.2. Informative References

Acknowledgments 🫶

Thanks to A. Retana, J. Arkko, P. Yee, A. de la Haye, A. Cima, A. Pawlik, J. Curran, A. Severin, B. Haberman, T. Manderson, D. Lewis, D. Farinacci, M. Binderberger, D. Saucez, E. Lear, for their helpful comments 💜

The work of Luigi Iannone has been partially supported by the ANR-13-INFR-0009 LISP-Lab Project <www.lisp-lab.org> and the EIT KIC ICT-Labs SOFNETS Project. 🌈

Authors' Addresses 🦋

Luigi Iannone Telecom ParisTech France

Email: ggx@gigix.net

Roger Jorgensen Bredbandsfylket Troms Norway

Email: rogerj@gmail.com

David Conrad Virtualized, LLC United States

Email: drc@virtualized.org

Geoff Huston Asia Pacific Network Information Centre (APNIC) Australia

Email: gih@apnic.net

📦 where this page comes from