RFC 8060
LISP Canonical Address Format (LCAF)
RFC 8060: LISP Canonical Address Format (LCAF) 💖
Request for Comments: 8060 🎀 Title: LISP Canonical Address Format (LCAF) 🦋 Authors: D. Farinacci (lispers.net), D. Meyer (Brocade), and J. Snijders (NTT) 👑 Category: Experimental 🧪 Date: February 2017 📅 ISSN: 2070-1721 ✨ Publisher: Internet Engineering Task Force (IETF) 🌈
Okay bestie, this title block doesn't list anything it obsoletes or updates, so there's no older RFC being replaced here 🙈
Abstract
okay so this doc defines a canonical address format encoding 💅 It gets used in Locator/ID Separation Protocol (LISP) control messages, and also when encoding lookup keys for the LISP Mapping Database System 🧚 It's giving organized addresses, fr fr ✨
Status of This Memo
ngl this one is not an Internet Standards Track spec 🙈 It's published so people can examine it, try it out in experimental implementations, and evaluate it 🔬
It's an Experimental Protocol for the Internet community 🧪 It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑 Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the deets 💅
Current status, errata, and feedback info live at http://www.rfc-editor.org/info/rfc8060 🦋
Copyright Notice
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 📜 Please read these carefully, bestie, because they explain your rights and restrictions for this doc 🙏 Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License ⚖️
Table of Contents 📚
1. Introduction ....................................................4
2. Terminology .....................................................5
2.1. Requirements Language ......................................5
2.2. Definition of Terms ........................................5
3. LISP Canonical Address Format Encodings .........................6
4. LISP Canonical Address Applications .............................8
4.1. Segmentation Using LISP ....................................8
4.2. Carrying AS Numbers in the Mapping Database ................9
4.3. Assigning Geo-Coordinates to Locator Addresses ............10
4.4. NAT Traversal Scenarios ...................................11
4.5. Multicast Group Membership Information ....................13
4.6. Traffic Engineering Using Re-encapsulating Tunnels ........15
4.7. Storing Security Data in the Mapping Database .............16
4.8. Source/Destination 2-Tuple Lookups ........................17
4.9. Replication List Entries for Multicast Forwarding .........18
4.10. Applications for AFI List LCAF Type ......................19
4.10.1. Binding IPv4 and IPv6 Addresses ...................19
4.10.2. Layer 2 VPNs ......................................20
4.10.3. ASCII Names in the Mapping Database ...............21
4.10.4. Using Recursive LISP Canonical Address Encodings ..22
4.10.5. Compatibility Mode Use Case .......................23
5. Experimental LISP Canonical Address Applications ...............24
5.1. Convey Application-Specific Data ..........................24
5.2. Generic Database Mapping Lookups ..........................25
5.3. PETR Admission Control Functionality ......................26
5.4. Data Model Encoding .......................................27
5.5. Encoding Key/Value Address Pairs ..........................28
5.6. Multiple Data-Planes ......................................29
6. Security Considerations ........................................31
7. IANA Considerations ............................................31
8. References .....................................................32
8.1. Normative References ......................................32
8.2. Informative References ....................................33
Acknowledgments ...................................................35
Authors' Addresses ................................................361. Introduction ✨
The LISP architecture and protocol [RFC6830] brings in two brand-new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs) 🦋 To stay flexible for current and future apps, these values can be encoded in LISP control messages with a general syntax that has Address Family Identifier (AFI), length, and value fields 💅
Currently defined AFIs include IPv4 and IPv6 addresses 🌈 They're formatted according to code-points assigned in the "Address Family Numbers" registry [AFN], and they look like this:
IPv4-Encoded Address: 🌸
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 = 1 | IPv4 Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IPv6-Encoded Address: 🍓
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 = 2 | IPv6 Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... IPv6 Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... IPv6 Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... IPv6 Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... IPv6 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+This doc describes the AFIs LISP currently uses, along with their encodings 🧁 It also introduces the LISP Canonical Address Format (LCAF), which can be used to define LISP-specific encodings for arbitrary AFI values 💜
Specific detailed uses for the LCAF Types defined here can be found in the use-case docs that implement them 📖 The same LCAF Type can be used by more than one use-case doc 🫶 As an Experimental spec, this work is, by definition, incomplete 🙈 Plot twist, but it's on purpose! 💀
The LCAF Types defined in this doc are there to support experimentation 🔬 They're meant for cautious use in self-contained environments, supporting the matching use-case docs ⚠️ This doc assigns an initial set of approved LCAF Types (registered with IANA), plus additional unapproved LCAF Types [RFC6830] 👑 The unapproved LCAF encodings are defined so they can support further study and experimentation 🧪
2. Terminology 🎀
2.1. 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] 💖
2.2. Definition of Terms 💅
Address Family Identifier (AFI): this is the term for an address encoding in a packet 🌸 Address families are defined for IPv4 and IPv6, and you can check [AFN] and [RFC3232] for details 🦋 In this spec, the reserved AFI value of 0 means an unspecified encoded address, where the length of the address is 0 bytes after the 16-bit AFI value of 0 🙈
Unspecified Address Format: ✨
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 = 0 | <no address follows>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Endpoint ID (EID): this is a 32-bit (for IPv4) or 128-bit (for IPv6) value 🧚 It's used in the source and destination address fields of the first (most inner) LISP header of a packet 💜 A host gets a destination EID the same way it gets a destination address today, like through a DNS lookup or a SIP exchange 📞 The source EID comes from the existing mechanisms that set a host's "local" IP address 🫶 An EID is allocated to a host from an EID-prefix block tied to the site where the host is located 🏠 And hosts can use an EID to refer to other hosts 👯♀️
Routing Locator (RLOC): this is the IPv4 or IPv6 address of an Egress Tunnel Router (ETR) 🌈 It's the output of an EID-to-RLOC mapping lookup 🔍 An EID maps to one or more RLOCs 🌟 Typically, RLOCs are numbered from topologically aggregatable blocks that get assigned to a site at each point where it attaches to the global Internet 🌐 Where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as Provider-Assigned (PA) addresses 🍰 Multiple RLOCs can be assigned to the same ETR device, or to multiple ETR devices at a site 🎀
okay that's the first chunk, bestie 🦋 We're stopping right in the middle of the RLOC definition for now, so part 2 picks up from there 💖✨
3. LISP Canonical Address Format Encodings ✨
okay so IANA gave AFI value 16387 (0x4003) to the LISP Canonical Address Format (LCAF) 🎀 this section is where we define how the LISP Canonical Address (LCA) is encoded, and it covers every Type that's requesting an initial allocation in the LISP-LCAF registry. the full list lives in Section 7 if you want the whole picture 🧚
bestie, the AFI definitions in [AFN] only give you a code point for the AFI value itself. they don't say how long the address or entity after it is supposed to be. that length is just kind of implied by conventional experience 🙈 so when LISP uses the LCAF definitions in this document, the AFI-based address lengths are spelled out right here. when other use-case documents define new LCAF stuff, they're the ones who specify lengths for any new AFI-encoded addresses 💅
the first 6 bytes of a LISP Canonical Address are followed by a variable number of fields, and each of those fields is also variable length:
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 | Rsvd2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the bits and pieces, explained:
- Rsvd1/Rsvd2 🔒: these 8-bit fields are reserved for future use. they MUST be transmitted as
0and ignored on receipt. don't touch them, babe. - Flags 🚩: this 8-bit field is saved for future definition and use. for now, set it to
0when you transmit and ignore it when you receive. - Type 🍓: this 8-bit field is specific to LCAF encodings. both approved and unapproved values are listed below. the unapproved ones are flagged, and Section 5 has the deets on those.
the Types, in order:
Type 0: Null BodyType 1: AFI ListType 2: Instance IDType 3: AS NumberType 4: Application Data (unapproved; see Section 5)Type 5: Geo-CoordinatesType 6: Opaque Key (unapproved; see Section 5)Type 7: NAT-TraversalType 8: Nonce Locator (unapproved; see Section 5)Type 9: Multicast InfoType 10: Explicit Locator PathType 11: Security KeyType 12: Source/Dest KeyType 13: Replication List EntryType 14: JSON Data Model (unapproved; see Section 5)Type 15: Key/Value Address Pair (unapproved; see Section 5)Type 16: Encapsulation Format (unapproved; see Section 5)- Length 📏: this 16-bit field counts bytes and covers the whole LISP Canonical Address payload, starting at the byte right after the Length field (and including it). when the AFI is part of the encoding, an LCAF-encoded address has a minimum length of 8 bytes when Length is 0. those 8 bytes are the AFI, Flags, Type, Rsvd1, Rsvd2, and Length fields. when the AFI is not next to an encoded address in a control message, the minimum drops to 6 bytes when Length is 0. those 6 bytes are Flags, Type, Rsvd1, Rsvd2, and Length 🥹
⚠️ the AFI-included and AFI-not-included minimums are different, so double-check which case you're in before you measure anything!
ok this next bit is so satisfying ✨ [RFC6830] says RLOC-records based on an IP address get sorted when they're encoded in control messages. that's how the locator-set ends up in the same order across every xTR for a given EID 🫶 the sort order is based on the sort-key {afi, RLOC-address}. when an RLOC based on an IP address is LCAF-encoded, the sort-key becomes {afi, LCAF-Type} instead. so if a locator-set has a mix of AFI records and LCAF records, they're ordered from smallest to largest AFI value. literally so clean 💜
4. LISP Canonical Address Applications
the following sections define the LCAF for the currently approved initial set of Type values. this is where the Types get their hands dirty 💅
4.1. Segmentation Using LISP
okay the main reason this matters: when multiple organizations inside a LISP site are using private addresses [RFC1918] as EID prefixes, their address spaces must stay segregated, because the addresses could end up duplicated 😭 an Instance ID in the address encoding helps make the whole AFI-based address unique. that's the big save here 🦋
the other use for the Instance ID LCAF is creating multiple segmented VPNs inside a LISP site, especially when keeping EID-prefix-based subnets is something you actually want 🌈
Instance ID LISP Canonical Address Format:
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 = 2 | IID mask-len | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the fields, decoded:
- IID mask-len 🎭: if the AFI is set to
0, this format isn't encoding an extended EID prefix. it's encoding an Instance ID range, andIID mask-lentells you how many high-order bits in the Instance ID field are used for that range. the low-order bits of the Instance ID field must be0. - Length 📏: length in bytes, starting at the byte right after this Length field (and including it).
- Instance ID 🪪: this is the low-order 24 bits that can go into a LISP data header when the I bit is set. check [RFC6830] for the full details. the reason the length is different is so the max number of instances per mapping system is 2^32, while still saving space in the LISP data header. the trade-off is that each xTR is limited to 2^24 instances. if an xTR is configured with multiple Instance IDs where the high-order 8 bits are the same, then the low-order 24 bits MUST be unique.
- AFI = x 🌸:
xcan be any AFI value from [AFN].
this LISP Canonical Address Type can be used to encode either EID or RLOC addresses 🧚
Usage: when it's used as a lookup key, the EID is treated as an extended-EID in the mapping system. this encoding shows up in EID-records in Map-Request, Map-Reply, Map-Register, and Map-Notify messages. when LISP Delegated Database Tree (LISP-DDT) [LISP-DDT] is the mapping system mechanism, extended EIDs show up in Map-Referral messages too 💖
4.2. Carrying AS Numbers in the Mapping Database
when an Autonomous System (AS) number gets stored in the LISP Mapping Database System, whether it's for policy or documentation reasons, it can be encoded in a LISP Canonical Address 📚
AS Number LISP Canonical Address Format:
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 = 3 | Rsvd2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Length 📏: length in bytes, starting at the byte right after this Length field (and including it).
- AS Number 👑: the 32-bit AS number of the autonomous system that's been assigned to either the EID or RLOC that follows.
- AFI = x 🌸:
xcan be any AFI value from [AFN].
the AS Number LCAF Type can be used to encode either EID or RLOC addresses 🦋 the EID version describes the LISP-ALT AS number that the site's EID prefix is being carried for. the RLOC version describes the AS that's carrying RLOC-based prefixes in the underlying routing system.
Usage: this encoding can be used in EID-records or RLOC-records in Map-Request, Map-Reply, Map-Register, and Map-Notify messages. when LISP-DDT [LISP-DDT] is the mapping system mechanism, extended EIDs show up in Map-Referral messages 🫶
4.3. Assigning Geo-Coordinates to Locator Addresses 🌍
Okay so if an ETR wants to send a Map-Reply describing the Geo-Coordinates for every locator in its locator-set, it can use the Geo-Coordinates LCAF Type to share the physical location 📍
The coordinates are written using the WGS 84 (World Geodetic System 1984) reference coordinate system [WGS-84] 🗺️
Geo-Coordinates LISP Canonical Address Format:
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 = 5 | Rsvd2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| Latitude Degrees | Minutes | Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Longitude Degrees | Minutes | Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Altitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's the breakdown, bestie 🎀
- Length: the number of bytes, counted in bytes starting with the byte right after this Length field and including it.
- N: when set to 1 it means north; otherwise it means south. 🧭
- Latitude Degrees: valid values go from 0 to 90 degrees above or below the equator (northern or southern hemisphere, respectively).
- Latitude Minutes: valid values range from 0 to 59.
- Latitude Seconds: valid values range from 0 to 59.
- E: when set to 1 it means east; otherwise, west.
- Longitude Degrees: valid values are from 0 to 180 degrees right or left of the Prime Meridian.
- Longitude Minutes: valid values range from 0 to 59.
- Longitude Seconds: valid values range from 0 to 59.
- Altitude: height relative to sea level, in meters. It's a two's complement signed integer, so the altitude can be below sea level 🌊 A value of
0x7fffffffmeans no Altitude value is encoded. - AFI = x: x can be any AFI value from [AFN].
The Geo-Coordinates LCAF Type can be used to encode either EID or RLOC addresses. When it's used for EID encodings, you can figure out an EID's physical location as well as its topological location just by looking at the locator-set 🔍✨
Usage: this encoding can be used in EID-records or RLOC-records in Map-Request, Map-Reply, Map-Register, and Map-Notify messages. When LISP-DDT [LISP-DDT] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. 💅
🚨 Privacy alert, bestie: location info is privacy sensitive, and you might end up sharing more than you expected. For example, the location info could point to a router sitting in someone's home 🏠 So this encoding should not be used unless it's needed for a LISP deployment to operate. Before you turn it on, make sure the EID is using the right policies to control what info gets shared. Protect yourself 🫶
4.4. NAT Traversal Scenarios 🧱
When a LISP system is passing along a global address and a mapped port while going through a NAT device, the NAT-Traversal LCAF Type is the one to use. Check out [NAT-LISP] for the full details 🦋
NAT-Traversal Canonical Address Format:
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 = 7 | Rsvd2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MS UDP Port Number | ETR UDP Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Global ETR RLOC Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | MS RLOC Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Private ETR RLOC Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | RTR RLOC Address 1 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | RTR RLOC Address k ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The field rundown 📋
- Length: the number of bytes, counted in bytes starting with the byte right after this Length field and including it.
- MS UDP Port Number: the UDP port number of the Map-Server. It's set to 4342. 🔢
- ETR UDP Port Number: the port number handed back to a LISP system. It was copied from the source port of a packet that flowed through a NAT device.
- AFI = x: x can be any AFI value from [AFN].
- Global ETR RLOC Address: an address known to be globally unique, built by the NAT-traversal functionality in a LISP router. 🌐
- MS RLOC Address: the address of the Map-Server used in the destination RLOC of a packet that flowed through a NAT device.
- Private ETR RLOC Address: an address known to be private, inserted into this LCAF by a LISP router sitting on the private side of a NAT device. 🔒
- RTR RLOC Address: an encapsulation address used by an Ingress Tunnel Router (ITR) or Proxy Ingress Tunnel Router (PITR) that sits behind a NAT device. This address is known to have state in a NAT device, so packets can flow from it to the LISP ETR behind the NAT. There can be one or more NAT Re-encapsulating Tunnel Router (RTR) [NAT-LISP] addresses in these fields. The number of RTRs encoded is determined by parsing each field. When there are no RTRs supplied, the RTR fields can be omitted and reflected by the LCAF length field, or an AFI of 0 can be used to indicate zero RTRs encoded. 🔁
Usage: this encoding can be used in Info-Request and Info-Reply messages. The mapping system does not store this information. The information is used by an xTR and Map-Server to convey private and public address information when traversing NAT and firewall devices. 🛡️
🙈 Privacy check: be careful about protecting privacy against the bad use of a Global or Private ETR RLOC Address. Make sure policy controls are used during EID registrations that use this LCAF Type in RLOC-records. Refer to the use-case documents for additional information. Don't skip this part, it's serious 💀
4.5. Multicast Group Membership Information 👯
Multicast group information can be published in the mapping database. So a lookup on a group address EID can return a replication list of RLOC group addresses or RLOC unicast addresses. The point of this kind of unicast replication is to deliver packets to multiple ETRs at receiver LISP multicast sites 📡 The locator-set encoding for this EID-record Type can be a list of ETRs when they each register with "Merge Semantics". The encoding can be a typical AFI-encoded locator address. When an RTR list is being registered (with multiple levels according to [LISP-RE]), the Replication List Entry LCAF Type is used for locator encoding.
This LCAF encoding can also be used to send broadcast packets to all members of a subnet when an EID is away from its home subnet location 🏡✈️
Multicast Info Canonical Address Format:
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 = 9 | Rsvd2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Source MaskLen| Group MaskLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Source/Subnet Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Group Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The field breakdown 🧩
- Length: the number of bytes, counted in bytes starting with the byte right after this Length field and including it.
- Reserved: must be set to zero and ignored on receipt.
- Instance ID: the low-order 24 bits that can go into a LISP data header when the I bit is set. See [RFC6830] for details. In this LCAF Type, the Instance ID is used to tie a multicast forwarding entry to a given VPN. The Instance ID describes the VPN and is registered to the mapping database system as a 3-tuple of (Instance ID, S-prefix, G-prefix). 🎀
- Source MaskLen: the mask length of the source prefix that follows. The length is the number of high-order mask bits set.
- Group MaskLen: the mask length of the group prefix that follows. The length is the number of high-order mask bits set.
- AFI = x: x can be any AFI value from [AFN]. When a specific address family has a multicast address semantic, this field must be either a group address or a broadcast address.
- Source/Subnet Address: the source address or prefix for encoding an (S,G) multicast entry. 📍
- Group Address: the group address or group prefix for encoding (S,G) or (*,G) multicast entries. 🦋
Usage: this encoding can be used in EID-records in Map-Request, Map-Reply, Map-Register, and Map-Notify messages. When LISP-DDT [LISP-DDT] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. ✨
4.6. Traffic Engineering Using Re-encapsulating Tunnels 🦋
okay so bestie, for a given EID lookup into the mapping database, this LCAF can be returned to hand you a list of locators in an explicit re-encapsulation path. 🗺️ For the full tea, check out [LISP-TE] ✨
Here's the Explicit Locator Path (ELP) Canonical Address Format 💅
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 = 10 | Rsvd2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd3 |L|P|S| AFI = x |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reencap Hop 1 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd3 |L|P|S| AFI = x |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reencap Hop k ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length: length in bytes starting and including the byte after this Length field. 📏
Rsvd3: this field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. 🔒
Lookup bit (L): this is the Lookup bit, and it tells the user of the ELP not to use this address for encapsulation. Instead, they should look it up in the mapping database system to get an encapsulating RLOC address. 🔍
RLOC Probe bit (P): this is the RLOC Probe bit, which means the Reencap Hop allows RLOC-probe messages to be sent to it. When the R bit is set to 0, RLOC-probes must not be sent. 🚫 When a Reencap Hop is an anycast address, multiple physical Reencap Hops are using the same RLOC address. In this case RLOC-probes aren't needed, because when the closest RLOC address is not reachable, another RLOC address can be reachable. 🌸
Strict bit (S): this is the Strict bit, which means the associated Reencap Hop is required to be used. 👑 If this bit is 0, the re-encapsulator can skip this Reencap Hop and move on to the next one in the list. 🦘
AFI = x: x can be any AFI value from [AFN]. When a specific AFI has its own encoding of a multicast address, this field must be either a group address or a broadcast address. 📡
Usage: this encoding can be used in RLOC-records in Map-Request, Map-Reply, Map-Register, and Map-Notify messages. 💌 It doesn't need to be understood by the mapping system for mapping database lookups, since this LCAF Type is not a lookup key. 🙅♀️
4.7. Storing Security Data in the Mapping Database 🔐
ok so when a locator in a locator-set has a security key attached to it, this LCAF is the one that gets used to encode the key material. 🗝️ For details, see [LISP-DDT] ✨
Here's the Security Key Canonical Address Format 💖
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 = 11 | Rsvd2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Count | Rsvd3 | Key Algorithm | Rsvd4 |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Length | Key Material ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Key Material |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Locator Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length: length in bytes starting and including the byte after this Length field. 📏
Key Count: the Key Count field declares how many Key sections are included in this LCAF. 🔢 A Key section is made up of Key Length and Key Material fields. 🧩
Rsvd3: this field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. 🔒
Key Algorithm: the Key Algorithm field identifies the key's cryptographic algorithm and specifies the format of the Public Key field. 🧮 For definitions of this field, refer to the [LISP-DDT] and [RFC8061] use cases. 📚
Rsvd4: this field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. 🔒
R bit: this is the Revoke bit. If it's set, the key is being revoked. 💀
Key Length: this field determines the length in bytes of the Key Material field. 📐
Key Material: the Key Material field stores the key material. ✨ The format of the stored key material depends on the Key Algorithm field. 🎀
AFI = x: x can be any AFI value from [AFN]. This is the locator address that owns the encoded security key. 🏠
Usage: this encoding can be used in EID-records or RLOC-records in Map-Request, Map-Reply, Map-Register, and Map-Notify messages. 💌 When LISP-DDT [LISP-DDT] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. 🧭
4.8. Source/Destination 2-Tuple Lookups 🎯
so when both a source and a destination address of a flow need to be considered for different locator-sets, this 2-tuple key gets used in EID fields in LISP control messages. 🌈 When the Source/Dest key is registered to the mapping database, it can be encoded as a source-prefix and a destination-prefix. 🧱 When the Source/Dest is used as a key for a mapping database lookup, the source and destination come from a data packet. 📦
Here's the Source/Dest Key Canonical Address Format 🦄
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 = 12 | Rsvd2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Source-ML | Dest-ML |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Source-Prefix ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = y | Destination-Prefix ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length: length in bytes starting and including the byte after this Length field. 📏
Reserved: must be set to zero and ignored on receipt. 🧹
Source-ML: the mask length of the source prefix that follows. 🎭 The length is the number of high-order mask bits set. 💪
Dest-ML: the mask length of the destination prefix that follows. 🎯 The length is the number of high-order mask bits set. 💪
AFI = x: x can be any AFI value from [AFN]. 🌍
AFI = y: y can be any AFI value from [AFN]. When a specific address family has a multicast address semantic, this field must be either a group address or a broadcast address. 📡
Usage: this encoding can be used in EID-records in Map-Request, Map-Reply, Map-Register, and Map-Notify messages. 💌 When LISP-DDT [LISP-DDT] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. 🧭 For usage details of this LCAF Type, refer to [LISP-TE]. 🗺️
4.9. Replication List Entries for Multicast Forwarding 📣
the Replication List Entry LCAF Type is an encoding for a locator that's used for unicast replication, following the specification in [LISP-RE]. 🔁 This locator encoding is pointed to by a Multicast Info LCAF Type, and it's registered by Re-encapsulating Tunnel Routers (RTRs) that are taking part in an overlay distribution tree. 🌳 Each RTR registers its locator address and its configured level in the distribution tree. 🪜
Here's the Replication List Entry Canonical Address Format 🧁
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 = 13 | Rsvd2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd3 | Rsvd4 | Level Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | RTR/ETR #1 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd3 | Rsvd4 | Level Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | RTR/ETR #n ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length: length in bytes starting and including the byte after this Length field. 📏
Rsvd3/Rsvd4: must be set to zero and ignored on receipt. 🧹
Level Value: this value is tied to the level within the overlay distribution tree hierarchy where the RTR lives. 🏡 The level numbers go from the lowest value, which is closest to the ITR (meaning ITRs replicate to level-0 RTRs), up to higher levels that are further downstream on the distribution tree, closer to the ETRs of multicast receiver sites. 📶
AFI = x: x can be any AFI value from [AFN]. A specific AFI has its own encoding of either a unicast or multicast locator address. 🌐 For efficiency reasons, all RTR/ETR entries for the same level should be combined by a Map-Server, so you don't have to search the entire multilevel list of locator entries in a Map-Reply message. 🧠✨
Usage: this encoding can be used in RLOC-records in Map-Request, Map-Reply, Map-Register, and Map-Notify messages. 💌
4.10. Applications for AFI List LCAF Type 🌟
4.10.1. Binding IPv4 and IPv6 Addresses
okay bestie, this one is giving translator 🦋. when you need header translation between IPv4 and IPv6, the AFI List LCAF Type lets one LCAF AFI carry a whole variable-length list of AFIs. main character energy ✨
Address Binding LISP Canonical Address Format:
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 = 1 | Rsvd2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 1 | IPv4 Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... IPv4 Address | AFI = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... IPv6 Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... IPv6 Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... IPv6 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length: the length in bytes, starting with and including the byte right after this Length field. 📏
this address format can show up in a Map-Request when the address is being used as an EID, but the LISP Mapping Database System lookup destination can only use the IPv4 address. the reason is so a Mapping Database Service Transport System, like LISP-ALT [RFC6836], can use the Map-Request destination address to route the control message to the right LISP site 🗺️
Usage: this encoding can be used in EID-records or RLOC-records in Map-Request, Map-Reply, Map-Register, and Map-Notify messages. check the other subsections in this section for the specific use cases 💅
4.10.2. Layer 2 VPNs
ok this one is so cute 🥹 when MAC addresses are stored in the LISP Mapping Database System, the AFI List LCAF Type can carry AFI 6.
MAC Address LISP Canonical Address Format:
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 = 1 | Rsvd2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 6 | Layer 2 MAC Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Layer 2 MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length: the length in bytes, starting with and including the byte right after this Length field.
this format can be used to link Layer 2 domains together over an IPv4 or IPv6 core network using LISP, which builds a Layer 2 VPN 🌐 here a MAC address is being used as an EID, and the locator-set it maps to can be an IPv4 or IPv6 RLOC, or even another MAC address being used as an RLOC. the way Layer 2 VPNs work when EID mobility is involved is in [EID-MOBILITY] 🦋
Careful, bestie 🙈 privacy matters here! a Layer 2 MAC address can be misused, so policy controls should be used during EID registrations that use AFI=6 encodings in RLOC-records. the use-case documents have more info.
4.10.3. ASCII Names in the Mapping Database
if DNS names [RFC1035] or URIs [RFC3986] are stored in the LISP Mapping Database System, the AFI List LCAF Type can carry an ASCII string 🔤
ASCII LISP Canonical Address Format:
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 = 1 | Rsvd2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 17 | DNS Name or URI ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length: the length in bytes, starting with and including the byte right after this Length field.
an example with DNS names: an ETR registers a mapping with an EID-record encoded as (AFI=1, 10.0.0.0/8) and an RLOC-record (AFI=17, "router.abc.com") 💖
4.10.4. Using Recursive LISP Canonical Address Encodings
when you want any combo of the above, the AFI List LCAF Type value can carry another LCAF AFI inside its own LCAF AFI. for example, Application-Specific Data in Section 5.1 🧩
Recursive LISP Canonical Address Format:
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 = 1 | Rsvd2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 16387 | Rsvd1 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 4 | Rsvd2 | Length2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP TOS, IPv6 TC or Flow Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Port (lower-range) | Local Port (upper-range) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Port (lower-range) | Remote Port (upper-range) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 1 | IPv4 Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length: the length in bytes, starting with and including the byte right after this Length field.
Length2: the length in bytes, starting with and including the byte right after this Length2 field.
this format could be used by a Mapping Database Service Transport System, like LISP-ALT [RFC6836], where the AFI=1 IPv4 address is used as an EID and goes in the Map-Request destination address from the sending LISP system. the ALT system can deliver the Map-Request to the LISP destination site no matter what the Application Data LCAF Type AFI payload values are 🚚 once the destination LISP site processes this AFI, it can return different locator-sets based on the type of application or level of service being requested. level-up service, iconic 👑
4.10.5. Compatibility Mode Use Case
a LISP system should use the AFI List LCAF Type format when it's sending to LISP systems that don't support a particular LCAF Type used to encode locators. this lets the receiving system parse a locator address for encapsulation purposes 📦 the AFIs in an AFI List LCAF Type have no semantic ordering, so a receiver should parse each AFI element no matter what order they come in 🔀
Compatibility Mode Address Format:
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 = 1 | Rsvd2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 16387 | Rsvd1 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 5 | Rsvd2 | Length2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| Latitude Degrees | Minutes | Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Longitude Degrees | Minutes | Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Altitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 0 | AFI = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length: the length in bytes, starting with and including the byte right after this Length field.
Length2: the length in bytes, starting with and including the byte right after this Length2 field.
if a system doesn't recognized the Geo-Coordinates LCAF Type that comes with a locator address, an encoder can put the Geo-Coordinates LCAF Type inside an AFI List LCAF Type. the AFI in the Geo-Coordinates LCAF Type is set to 0, and the AFI encoded next in the list gets a valid AFI value to identify the locator address 🌍
a LISP system is required to support the AFI List LCAF Type to use this procedure. it would skip over 10 bytes of the Geo-Coordinates LCAF Type to reach the locator address encoding (an IPv4 locator address). a LISP system that does support the Geo-Coordinates LCAF Type can parse the locator address either inside the Geo-Coordinates LCAF Type encoding or in the locator encoding that follows in the AFI List LCAF Type ✨
5. Experimental LISP Canonical Address Applications
okay, this section is the experimental zone 🧪 the following sections describe experimental LCAF encodings. these LCAF Types are not approved (aka not registered with IANA). they're included here to support further study and experimentation: figuring out whether these encodings actually work, whether anyone wants these use cases, and what deployment looks like in practice. as noted earlier, these LCAF Types are restricted to cautious use in self-contained environments that support the matching use-case documents. play it safe out there, bestie 🫶
5.1. Convey Application-Specific Data ✨
okay so when a locator-set needs to change based on the type of application or the Per-Hop Behavior (PHB) of a packet, the Application Data LCAF Type is the one you reach for 🎀
Application Data LISP Canonical Address Format:
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 = 4 | Rsvd2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP TOS, IPv6 TC, or Flow Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Port (lower-range) | Local Port (upper-range) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Port (lower-range) | Remote Port (upper-range) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length 📏: the length in bytes, starting from and including the byte right after this Length field.
IP TOS, IPv6 TC, or Flow Label 🦋: this field holds the 8-bit IPv4 TOS field from an IPv4 header, or the 8-bit IPv6 Traffic Class or Flow Label from an IPv6 header.
Local Port/Remote Port Ranges 🌸: these come from the TCP, UDP, or Stream Control Transmission Protocol (SCTP) transport header. You can describe a range by giving a lower value and an upper value. When you only need one port, the lower and upper value fields are the same.
AFI = x 🧚: x can be any AFI value from [AFN].
So the Application Data LCAF Type is used for an EID encoding when an ITR wants a locator-set for one specific application 🎯 When it's used for an RLOC encoding, the ETR is handing over a locator-set for each specific application it has been configured to advertise. iconic behavior ngl 💅
Usage 💖: this encoding can go in EID-records in Map-Request, Map-Reply, Map-Register, and Map-Notify messages. When LISP-DDT [LISP-DDT] is the mapping system mechanism, extended EIDs are used in Map-Referral messages. This LCAF Type works as a lookup key for the mapping system, which can return a longest-match or exact-match entry.
5.2. Generic Database Mapping Lookups 🔑
so when the LISP Mapping Database System stores info that gets looked up with a generic formatted key (aka the key is not the usual IPv4 or IPv6 address), an opaque key can be super useful 🫶
Opaque Key LISP Canonical Address Format:
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 = 6 | Rsvd2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Field Num | Key Wildcard Fields | Key . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length 📏: the length in bytes, starting from and including the byte right after this Length field.
Key Field Num 🧩: the value here is the number of "Key" sub-fields minus 1 that the Key field can be split into. So if this field is 0, the "Key" has one sub-field. The sub-fields are fixed length. So for an 8-byte key with a Key Field Num of 3, you get four sub-fields that are 2 bytes each. Allowing for a reasonable number of 16 sub-field separators, valid values run from 0 to 15.
Key Wildcard Fields 🙈: this describes which fields in the key aren't used in the key lookup. It's a bitfield, and each bit is a don't-care bit for the matching field in the key. Bit 0 (the low-order bit) lines up with the first field, the low-order field in the key. Bit 1 lines up with the second field, and so on. When a bit is set, it's a don't-care bit and should not be considered as part of the database lookup. When all 16 bits are set to 0, every bit of the key is used for the database lookup.
Key 🔐: the variable-length key used for a LISP Mapping Database System lookup. The length of the key is the value n (as shown above).
Usage 🧪: this is an experimental Type, and its usage hasn't been defined yet.
5.3. PETR Admission Control Functionality 🚪
okay so when a public Proxy Egress Tunnel Router (PETR) wants to check who's encapsulating to it, it can look for a specific nonce value in the LISP-encapsulated packet 👀 To pass that nonce along to admitted ITRs or PITRs, this LCAF is used in a Map-Register or Map-Reply locator-record.
Nonce Locator Canonical Address Format:
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 = 8 | Rsvd2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length 📏: the length in bytes, starting from and including the byte right after this Length field.
Reserved 🛡️: must be set to zero and ignored on receipt.
Nonce 🎲: a nonce value that an ETR returns in a Map-Reply locator-record, for an ITR or PITR to use when it encapsulates to the locator address in the AFI field of this LCAF Type. This nonce value goes into the nonce field of the LISP header encapsulation.
AFI = x 🧚: x can be any AFI value from [AFN].
Usage 🧪: this is an experimental Type, and its usage hasn't been defined yet.
5.4. Data Model Encoding 🧾
this Type lets a JSON data model get encoded as either an EID or an RLOC, which is lowkey so cool 🤓
JSON Data Model Type Address Format:
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 = 14 | Rsvd2 |B| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| JSON length | JSON binary/text encoding ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Optional Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length 📏: the length in bytes, starting from and including the byte right after this Length field.
B bit 🔢: when this bit is set to 1, the JSON field is binary encoded according to [JSON-BINARY]. Otherwise, the encoding is text based, according to [RFC7159].
JSON length 📐: the length in octets of the JSON binary/text encoding field that follows.
JSON binary/text encoding 🧃: a variable-length field that holds either a binary or a text encoding.
AFI = x 🧚: x can be any AFI value from [AFN]. A specific AFI has its own encoding for either a unicast or multicast locator address. All RTR/ETR entries for the same level should be combined by a Map-Server, so you don't have to search through the entire multilevel list of locator entries in a Map-Reply message 🧠
Usage 🧪: this is an experimental Type, and its usage hasn't been defined yet. An example mapping is an EID-record encoded as a distinguished-name "cpe-router", and an RLOC-record encoded as a JSON string { "router-address" : "1.1.1.1", "router-mask" : "8" }. 🌈
5.5. Encoding Key/Value Address Pairs 🗝️
the Key/Value pair is useful for attaching attributes to other LISP packet elements, like EIDs or RLOCs. When you attach attributes to EIDs or RLOCs, you need to be able to tell which element is the EID or RLOC, and so which one works as the key for lookups and extra attributes. This matters most when the Types of the elements can't tell you that, like when two IP addresses are being used 😤
Key/Value Address Pair Address Format:
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 = 15 | Rsvd2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Address as Key ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = y | Address as Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length 📏: the length in bytes, starting from and including the byte right after this Length field.
AFI = x 🧚: x is the "Address as Key" AFI, and it can have any value from [AFN]. A specific AFI has its own encoding for either a unicast or a multicast locator address. All RTR/ETR entries for the same level should be combined by a Map-Server, so you don't have to search through the entire multilevel list of locator entries in a Map-Reply message.
Address as Key 🔑: an AFI-encoded address that gets the attributes encoded in "Address as Value", which comes right after this field.
AFI = y 🧚: y is the "Address of Value" AFI, and it can have any value from [AFN]. A specific AFI has its own encoding for either a unicast or a multicast locator address. All RTR/ETR entries for the same level should be combined by a Map-Server, so you don't have to search through the entire multilevel list of locator entries in a Map-Reply message.
Address as Value 💎: an AFI-encoded address that serves as the attribute address going along with "Address as Key", which comes right before this field.
Usage 🧪: this is an experimental Type, and its usage hasn't been defined yet. 🌸
5.6. Multiple Data-Planes 🦋
okay so overlays are literally everywhere rn, and that has caused a whole explosion of data-plane encapsulation headers 💀 The LISP mapping system can hold lots of different address formats, so it can store the encapsulation format an RLOC supports too 🧚 When an encapsulator gets a Map-Reply with an Encapsulation Format LCAF Type in an RLOC-record, it gets to pick an encapsulation format it can actually support from any of the encapsulation protocols whose bit is set to 1 in this LCAF Type ✨
Here's the Encapsulation Format Address Format 💖
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 = 16 | Rsvd2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved-for-Future-Encapsulations |U|G|N|v|V|l|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's the breakdown of each piece 🎀
Length: the length in bytes, starting and including the byte right after thisLengthfield 📏Reserved-for-Future-Encapsulations: this one must be set to zero and ignored on receipt. It's where bits get handed out to future encapsulations as they're created 🌈U: the RLOCs listed in the AFI-encoded addresses in the next longword can accept Generic UDP Encapsulation (GUE) using destination UDP port 6080 [GUE] 🦋G: the RLOCs listed in the AFI-encoded addresses in the next longword can accept Geneve encapsulation using destination UDP port 6081 [GENEVE] 💜N: the RLOCs listed in the AFI-encoded addresses in the next longword can accept NV-GRE (Network Virtualization - Generic Routing Encapsulation) using IPv4/IPv6 protocol number 47 [RFC7637] 🌸v: the RLOCs listed in the AFI-encoded addresses in the next longword can accept VXLAN-GPE (Generic Protocol Extension) encapsulation using destination UDP port 4790 [GPE-VXLAN] ✨V: the RLOCs listed in the AFI-encoded addresses in the next longword can accept Virtual eXtensible Local Area Network (VXLAN) encapsulation using destination UDP port 4789 [RFC7348] 🍓l: the RLOCs listed in the AFI-encoded addresses in the next longword can accept Layer 2 LISP encapsulation using destination UDP port 8472 [LISP-L2] 🫶L: the RLOCs listed in the AFI-encoded addresses in the next longword can accept Layer 3 LISP encapsulation using destination UDP port 4341 [RFC6830] 👑
Usage: this encoding can be used in RLOC-records in Map-Request, Map-Reply, Map-Register, and Map-Notify messages 💅
6. Security Considerations 🔥
okay bestie, this part is serious 😭 This document is classified as Experimental. The LCAF encodings defined here are meant to be used with their matching use cases and in self-contained environments. Users should really think hard about how the [LISP-SEC] threat model applies to their own use case 🙈
The Geo-Coordinates LCAF Type can raise physical privacy issues, so be careful 🚨 Take care when you set up the mapping system with specific policy parameters, so geolocation info doesn't get handed out gratuitously. Any documents that specify the use of the Geo-Coordinates LCAF Type are recommended to consider how RFC 6280 (BCP 160) [RFC6280] applies to location-based privacy protection 🔒
Privacy concerns have come up since BCP 160 was published, so future LISP work should look at threats beyond BCP 160 and work on improving privacy and security for LISP deployments 💜
7. IANA Considerations 🎀
this section is all about the registry 📋 This document defines a canonical address format encoding that's used in LISP control messages and in encoding lookup keys for the LISP Mapping Database System. That address format is based on a fixed AFI (16387) and a LISP LCAF Type field ✨
The LISP LCAF Type field is an 8-bit field specific to the LISP Canonical Address Format encodings. IANA has created a new registry (as outlined in [RFC5226]) called "LISP Canonical Address Format (LCAF) Types". The initial values for that registry are in the table below. Future assignments are to be made using the Specification Required policy [RFC5226]. Each assignment consists of a LISP LCAF Type Name and its associated value 🌈
+-------+------------------------+-----------+
| Value | LISP LCAF Type Name | Reference |
+-------+------------------------+-----------+
| 0 | Null Body | Section 3 |
| 1 | AFI List | Section 3 |
| 2 | Instance ID | Section 3 |
| 3 | AS Number | Section 3 |
| 5 | Geo-Coordinates | Section 3 |
| 7 | NAT-Traversal | Section 3 |
| 9 | Multicast Info | Section 3 |
| 10 | Explicit Locator Path | Section 3 |
| 11 | Security Key | Section 3 |
| 12 | Source/Dest Key | Section 3 |
| 13 | Replication List Entry | Section 3 |
+-------+------------------------+-----------+
Table 1: Initial Values in the
"LISP Canonical Address Format (LCAF) Types" Registry8. References 📚
8.1. Normative References 💖
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, DOI 10.17487/RFC3232, January 2002, <http://www.rfc-editor.org/info/rfc3232>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, DOI 10.17487/RFC6280, July 2011, <http://www.rfc-editor.org/info/rfc6280>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, <http://www.rfc-editor.org/info/rfc6830>.
[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, January 2013, <http://www.rfc-editor.org/info/rfc6836>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, <http://www.rfc-editor.org/info/rfc7348>.
[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network Virtualization Using Generic Routing Encapsulation", RFC 7637, DOI 10.17487/RFC7637, September 2015, <http://www.rfc-editor.org/info/rfc7637>.
8.2. Informative References 🦋
[AFN] IANA, "Address Family Numbers", <http://www.iana.org/assignments/address-family-numbers/>.
[EID-MOBILITY] Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a Unified Control Plane", Work in Progress, draft-portoles-lisp-eid-mobility-01, October 2016.
[GENEVE] Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic Network Virtualization Encapsulation", Work in Progress, draft-ietf-nvo3-geneve-03, September 2016.
[GPE-VXLAN] Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol Extension for VXLAN", Work in Progress, draft-ietf-nvo3-vxlan-gpe-03, October 2016.
[GUE] Herbert, T., Yong, L., and O. Zia, "Generic UDP Encapsulation", Work in Progress, draft-ietf-nvo3-gue-05, October 2016.
[JSON-BINARY] "Universal Binary JSON Specification", <http://ubjson.org>.
[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-L2] Smith, M., Dutt, D., Farinacci, D., and F. Maino, "Layer 2 (L2) LISP Encapsulation Format", Work in Progress, draft-smith-lisp-layer2-03, September 2013.
[LISP-RE] Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., Maino, F., and D. Farinacci, "LISP Replication Engineering", Work in Progress, draft-coras-lisp-re-08, November 2015.
[LISP-SEC] Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, "LISP-Security (LISP-SEC)", Work in Progress, draft-ietf-lisp-sec-12, November 2016.
[LISP-TE] Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic Engineering Use-Cases", Work in Progress, draft-farinacci-lisp-te-11, September 2016.
[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.
[RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality", RFC 8061, DOI 10.17487/RFC8061, February 2017, <http://www.rfc-editor.org/info/rfc8061>.
[WGS-84] National Imagery and Mapping Agency, "Department of Defense World Geodetic System 1984", NIMA TR8350.2, January 2000, <http://earth-info.nga.mil/GandG/publications/tr8350.2/wgs84fin.pdf>.
Acknowledgments ✨
okay bestie, the authors wanted to give a shoutout to everyone who helped make this happen 🫶 Vince Fuller, Gregg Schudel, Jesper Skriver, Luigi Iannone, Isidor Kouvelas, and Sander Steffann gave technical and editorial commentary, which was literally so important 💖
Victor Moreno got a big thank you for the discussions that led to the Multicast Info LCAF Type 🦋
Parantap Lahiri and Michael Kowal were also thanked for the chats that led to the Explicit Locator Path (ELP) LCAF Type 🌸
Fabio Maino and Vina Ermagan get love for the discussions that led to the Security Key LCAF Type 🔐
Albert Cabellos-Aparicio and Florin Coras were thanked for the talks that led to the Replication List Entry LCAF Type 💜
Michiel Blokzijl and Alberto Rodriguez-Natal get props for suggesting new LCAF Types 🧚
Terry Manderson got thanked for helping the team get a LISP AFI value from IANA 👑
And finally, the authors thanked Stephen Farrell (Security Area Director) and Deborah Brungard (Routing Area Director) for their suggested text that got the document through IESG review. Iconic behaviour from the reviewers 💅✨
Authors' Addresses 🎀
Here's where you can find the authors, bestie 🦋
Dino Farinacci
lispers.net
San Jose, CA
United States of AmericaEmail: farinacci@gmail.com
Dave Meyer
Brocade
San Jose, CA
United States of AmericaEmail: dmm@1-4-5.net
Job Snijders
NTT Communications
Theodorus Majofskistraat 100
Amsterdam 1065 SZ
The NetherlandsEmail: job@ntt.net 💜
📦 where this page comes from
- ietf: rfc8060 2017-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms