lispers.net

San Jose CA USA farinacci@gmail.com

This document describes how Geo-Coordinates can be used in the Locator/ID Separation Protocol (LISP). The functionality proposes a new LISP Canonical Address Format (LCAF) encoding for such Geo-Coordinate. This document updates RFC8060.

The Locator/ID Separation Protocol (LISP) introduces two new namespaces, Endpoint Identifiers (EIDs) and Routing Locators (RLOCs) which are intended to separate the semantics of identity and topological location from an IP address. To provide flexibility for current and future applications, these values can be encoded in LISP control messages using a general syntax that includes Address Family Identifier (AFI) . This document defines a new LCAF encoding for Geo-Coordinates, which deviates from the structure defined in , because a more compact encoding was desired. This document updates . In particular, the use of Geo-Coordinates encoding defined in Section 4.3 of and identified by LCAF type 5 is deprecated. The LCAF type defined in this document is called "Geo-Location" with a new LCAF type allocated. The Geo-Coordinates LCAF type is used in EID-records and RLOC-records. See for which LISP messages contain EID-records and RLOC-records. This document is part of a development effort to include Geo-Coordinates in LISP. Is not part of an "experiment", as not all experimental RFCs are necessarily part of an experiment. It is about the maturity level of the technology.

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 when, and only when, they appear in all capitals, as shown here.

Refer to for authoritative definitions for basic terms EID, RLOC, and xTRs. The terms defined in this section add to the canonical definitions to reflect the design considerations in this specification. is a Geo-Coordinate according to that defines a point from parameters Latitude, Longitude, and Altitude. forms a sphere (in 3 dimensions) of a geographic area made up of a Geo-Point and a Radius. A Geo-Point is known to be "more-specific" than a Geo-Prefix when its physical location is within the geographic sphere.

Geo-Points MAY be present in an RLOC-record to determine the physical location of an Egress Tunnel Router (ETR) or Re-encapsulating Tunnel Router (RTR). This can aid in determining geographical distance when topological distance is inaccurate or hidden. When Geo-Points are encoded in RLOC-records with RLOC addresses the LCAF AFI-List Type SHOULD be used. Geo-Points MAY be used as the sole piece of information in an RLOC-record when an EID maps to a Geo-Coordinate. If it is desirable to find the geographical location of any EID, this method can be convenient. For instance, let's say that an EID is assigned to a physical shipping package by a package delivery company. And the EID is encoded as an IPv6 address where the tracking number is embedded in an IPv6 EID. The network has LISP nodes deployed in many locations that are configured with their respective Geo-Coordinates. As the package roams, the LISP node that discovers the EID, registers it to the LISP mapping system. The EID-to-RLOC mapping is EID=IPv6 and RLOC=Geo-Coordinate. If someone does a mapping database lookup on the IPv6 EID, what is returned is the Geo-Coordinate. As the EID roams, new registrations with different Geo-Coordinates are stored, allowing the physical tracking of the package.

A Geo-Prefix is defined to be a Geo-Coordinate point and a Radius. This allows a sphere to be drawn on a geographic map. The Geo-Prefix can describe a coarse physical location for an RLOC when encoded in an RLOC-record. So an RLOC could be registered in the mapping database indicating it is in a city or country versus the exact location where a Geo-Point would locate it. For Instance, a Geo-Prefix could allow a Distinguished-Name to be registered as an EID with an RLOC that contains a Geo-Prefix. For example EID="San Francisco", with RLOC=geo-prefix could be stored in the mapping system. A Geo-Prefix, when encoded in an EID-record, could be registered as an EID-prefix and when a Geo-Point is used as an EID lookup key, a sort of longest match could be looked up. If the Geo-Point is in the Sphere described by the Geo-Prefix, the matching entry MUST be returned to the Map-Requestor. In this context, what is returned is the Geo-Prefix with the largest radius value, which corresponds to the largest physical area. If the Geo-Point supplied in a Map-Request matches several Geo-Prefixes in the mapping system, then all Geo-Prefixes MUST be returned. This uses the same overlapping lookup semantics defined in for IP address EIDs.

You could take a combination of mappings from the above examples to ask the question: "Is the package in San Francisco"? This could be done with two lookups to the mapping system:

RLOC= EID= RLOC= EID= RLOC= Map-Request for package: EID= Mapping system returns: RLOC= Map-Request for geo-point: EID= Mapping system longest-match lookup returns: EID= RLOC= ]]>

If the package was not in San Francisco, the second mapping table lookup would fail.

Another application is concentric rings of WiFi access-points. The radius of each ring corresponds to the Wifi signal strength. An EID could be located in any of the inner rings but possibly on the edge of a ring. A WiFi access-point (AP) RLOC can be selected to encapsulate packets because it will have better signal to the current EID location. And when there are intersecting spheres, it can be determined that when the EID is in the intersection of the spheres, it would be a good time to transition radios to closer WiFi APs or 3GPP RAN base-stations.

When assigning EIDs to vehicles , a Geo-Prefix could be used to create a "reachability set" of Road-Side-Units (RSUs). So an Ingress Tunnel Router (ITR) could encapsulate to multiple RLOCs in the Geo-Prefix to try to create connectivity to the vehicle while roaming. This makes use of predictive RLOCs that can be used when the direction of the roaming EID is known (a train track or single direction road, but not a flight path of a plane).

When a Geo-Prefix or a Geo-Point are encoded in an EID-record, it is encoded solely with the Geo-Location LCAF Type format when VPNs are not in use. When VPNs are used, the Geo-Location LCAF Type is encoded in the AFI field of the Instance-ID LCAF Type. This document has no provision to validate the Geo-Location values. The Geo-Location format is:

Set to 16387 to indicate that the address is using the LCAF format from . 17 (suggested) See for details. length in bytes starting and including the byte after this Length field. If the U-bit is set, it indicates that the "Location Uncertainty" field is used. If the U-bit is clear, it indicates the "Location Uncertainty" field sent as 0 and ignored on receipt. If the N-bit is set, it indicates the Latitude is North relative to the Equator. If the N-bit is clear, it indicates the Latitude is South of the Equator. If the E-bit is set, it indicates the Longitude is East of the Prime Meridian. If the E-bit is clear, it indicates the Longitude is West of the Prime Meridian. If the A-bit is set, it indicates the "Altitude" field is used. If the A-bit is clear, it indicates the "Altitude" field is sent as 0 and ignored on receipt. If the M-bit is set, it indicates the "Altitude" is specified in meters. If the M-bit is clear, it indicates the "Altitude" is in centimeters. If the R-bit is set, it indicates the "Radius" field is used and the encoding is a Geo-Prefix. If the R-bit is clear, it indicates the "Radius" field is set to 0 and and the encoding is a Geo-Point. If the K-bit is set, it indicates the "Radius" is specified in kilometers. If the K-bit is clear, it indicates the "Radius" is in meters. These bits are reserved for future use for the addition of bit fields from the previous field. They MUST be set to 0 when sending protocol packets and MUST be ignored when receiving protocol packets. Unsigned 16-bit integer indicating the number of centimeters of uncertainty for the location. Unsigned 8-bit integer with a range of 0 - 90 degrees North or South of the Equator (northern or southern hemisphere, respectively). Unsigned 24-bit integer with a range of 0 - 3,599,999 (i.e., less than 60 minutes). Unsigned 8-bit integer with a range of 0 - 180 degrees east or west of the Prime Meridian. Unsigned 24-bit integer with a range of 0 - 3,599,999 (i.e., less than 60 minutes). Signed 32-bit integer containing the Height relative to sea level in centimeters or meters. A negative height indicates that the location is below sea level. Unsigned 16-bit integer containing the radius of a sphere (or circle if altitude not specified) centered at the specified coordinates. The radius is specified in meters unless the K-bit is specified indicating radius is in kilometers. When the radius is specified, this LCAF type encodes a Geo-Prefix where the Geo-Coordinates define the entire area of the sphere or circle defined by the radius and center point. The AFI field indicates the Address Family Identifier for the following address from from and .

EID-records encoded with the Geo-Location LCAF are supported only by LISP nodes that support them for registration and lookup purposes. RLOC-records encoded with the Geo-Location LCAF can be returned from the mapping system lookups to LISP nodes that do not understand them. In such situations, the RLOC-record is ignored.

The use of Geo-Coordinates in any application must be considered carefully to not violate any privacy concerns about physical location. This draft does take into consideration the applicability of BCP160 for location-based privacy protection. In a LISP environment, Geo-Coordinates can be registered to the Mapping Database System. When this occurs, any Tunnel Router (xTR) is allowing its physical location to be known to queriers of the mapping system as well as network components that make up the mapping system. There are various sets of trust relationships that may exist. When xTRs register their mappings with Geo-Coordinate information, a policy is associated about who can access the information. Typically, the policy is stored locally on the xTR and applied when the Mapping Service Provider (MSP) forwards Map-Requests to the xTRs of the LISP site. Conditionally, based on the requesting xTR, the responding xTR can apply the local policy to decide if a Map-Reply is sent with all RLOC-records, or perhaps, the RLOC-records that do not contain Geo-Coordinate information. The MSP can also be requested by LISP site xTRs to proxy Map-Reply to Map-Requests. In this case, the MSP MUST apply the xTR policy so only authorized requesters get access to Geo-Coordinate information. Note that once a requester is authorized, Map-Replies are returned directly to the requester and are signed with . The Map-Replies not only authenticates the Map-Replier but can be encrypted by the Map-Replier so no eavesdropping of Geo-Coordinate information can occur. In most deployment cases, there is no tracking of EID host-based systems since Geo-Coordinate assignment is typically registered for LISP xTRs devices or other asset inventory. However, since Geo-Coordinate encoded RLOCs can be associated with any EID, and if such EID is assigned to hosts, tracking of hosts can occur.

In addition to controlling where LISP Geo-Coordinate mapping records go and applying policies (see Security Considerations section) for who can access them, there are additional steps that can be taken to protect against threats. The suggestions from can be implemented by existing LISP features, such as: Using signatures from can authenticate and authorize who can request such mapping records. Obfuscating a Geo-Point by using Geo-Prefixes instead uses data minimization techniques. Using short TTLs so the Geo-Coordinate mapping records are ephemeral reduces the attack window. The typical applicability for the use of Geo-Coordinates will be to describe physical location for well known public structures, places, and landmarks versus people, vehicles, and equipment.

Following the guidelines of , IANA is asked to assign a value (17 is suggested) for the Geo-Coordinates LCAF from the "LISP Canonical Address Format (LCAF) Types" registry (defined in as follows:

This document updates the format of LCAF Type value 5 in , IANA is asked to deprecate type value 5.

Geodesy and Geophysics Department, DoD.

The author would like to thank the LISP WG for their review and acceptance of this draft. A special thanks goes to Enke Chen, Acee Lindem, and Naiming Shen for collaboarting on a consistent geo-location encoding format with OSPF , IS-IS , and BGP protocols.

[RFC Editor: Please delete this section on publication as RFC.]

Posted March 2026 by Dino. Luigi made changes to reflect Deb's comments. Thanks Luigi.

Posted February 2026 by Dino. Luigi made changes to reflect Ketan's comments. Thanks Luigi.

Posted July 2025. Added text to indicate why the encoding deviates from .

Posted June 2025. Made remaining changes with text from Luigi to satisfy Deb, Ketan, and Med comments.

Posted June 2025. Made changes to reflect comments from Med, Ketan, Deb, Gunter, and Eric in one document revision pass.

Posted May 2025. Made changes to reflect Internet AD (Erik Kline) and Med Boucadiar reviews.

Posted May 2025. Made changes to reflect Genart (Jouni Korhonen) review.

Posted May 2025. Made changes to reflect Opsdir (Tim Wicinski) and Secdir (Prachi Jain) reviews.

Posted May 2025. Made changes to reflect Rtgdir review by Yingzhen.

Posted April 2025. Made changes to fix IDNITs and Jim's editorial comments.

Posted February 2025. Made editorial changes to address Alvaro comments.

Posted January 2025. Update document timer and references.

Posted July 2024. Made changes to reflect review by Kiran Makhijani.

Posted June 2024. Made changes to reflect Rtgdir review by Ines Robles.

Posted May 2024. Modify the abstract and change requesting 17 to suggesting type 17.

Posted April 2024. Made more changes to allocate new type for the Geo-Coordinates LCAF.

Posted April 2024. Make changes to reflect comments from Luigi which indicate to be more explicit about consitentcy of geo encodings with IGPs. Update document timer and references.

Posted November 2023. Update document timer and references.

Posted June 2023. Update document timer and references.

Posted December 2022. Changes made to reflect comments from Luigi.

Posted November 2022. Renamed draft-farinacci-lisp-geo-15 to make working group draft.

Posted November 2022. Made change to reflect last call comments. First sentence of intro and added a Privacy Considerations section.

Posted September 2022. Update document timer and references.

Posted March 2022. Update document timer and references.

Posted September 2021. Update document timer and references.

Posted March 2021. Update document timer and references.

Posted October 2020. Update document timer and references.

Posted April 2020. Update document timer and references.

Posted October 2019. Update document timer and references.

Posted April 2019. Update document timer and references.

Posted October 2018. Update document timer and references.

Posted April 2018. Update document timer and references.

Posted October 2017. Update document timer and references.

Posted April 2017. Update document timer.

Posted October 2016. Change format of the Geo-Coordinates LCAF Type to be compatible with equivalent proposals for OSPF, IS-IS, and BGP. Add to the Security Considerations section to BCP160 compliance.

Posted October 2016. Clarify that the Geo-Coordinates LCAF type should be encoded inside an Instance-ID LCAF type when VPNs are used. Indicate what the value of the Altitude field is when not included in a message. Since this draft shortens the field, a new value is specified in this draft for not conveying an Altitude value in a message.

Initial draft posted April 2016.