Locator/ID Separation Protocol (LISP) Geo-Coordinates
RFC 10040
| Document | Type |
RFC
- Experimental
(September 2026)
Updates RFC 8060
Was
draft-ietf-lisp-geo
(lisp WG)
|
|
|---|---|---|---|
| Author | D. Farinacci | ||
| Last updated | 2026-09-15 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Jim Guichard | |
| Send notices to | (None) |
RFC 10040
Internet Engineering Task Force (IETF) D. Farinacci
Request for Comments: 10040 lispers.net
Updates: 8060 September 2026
Category: Experimental
ISSN: 2070-1721
Locator/ID Separation Protocol (LISP) Geo-Coordinates
Abstract
This document describes how Geo-Coordinates can be used in the
Locator/ID Separation Protocol (LISP) and defines a new LISP
Canonical Address Format (LCAF) encoding for such Geo-Coordinates.
This document updates RFC 8060.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and
evaluation.
This document defines an Experimental Protocol for the Internet
community. This document is a product of the Internet Engineering
Task Force (IETF). It represents the consensus of the IETF
community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are candidates for any level of
Internet Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc10040.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents
1. Introduction
2. Requirements Language
3. Definition of Terms
4. Geo-Points in RLOC-Records
5. Geo-Prefixes in EID-Records and RLOC-Records
6. Geo-Points and Geo-Prefixes Examples
6.1. Locating a Package
6.2. Wireless Connectivity
6.3. Vehicular Networks
7. Geo-Prefix and Geo-Point Encodings
8. Backward-Compatibility Considerations
9. Security Considerations
10. Privacy Considerations
11. IANA Considerations
12. References
12.1. Normative References
12.2. Informative References
Acknowledgments
Author's Address
1. Introduction
The Locator/ID Separation Protocol (LISP) [RFC9300] 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
Identifiers (AFIs) [AFN].
This document defines a new LCAF encoding for Geo-Coordinates, which
deviates from the structure defined in [RFC9179], because a more
compact encoding was desired.
This document updates [RFC8060]. In particular, the use of the Geo-
Coordinates encoding defined in Section 4.3 of [RFC8060] and
identified by LCAF type 5 is deprecated. The LCAF type defined in
this document is called "Geo-Location", and a new LCAF type has been
allocated.
The Geo-Location LCAF type is used in EID-Records and RLOC-Records.
See [RFC9301] for which LISP messages contain EID-Records and RLOC-
Records.
This document is part of a development effort to include Geo-
Coordinates in LISP. It 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.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Definition of Terms
Refer to [RFC9300] for authoritative definitions for the basic terms
"EID", "RLOC", and "xTR". The terms defined in this section add to
the canonical definitions to reflect the design considerations in
this specification.
Geo-Point: A coordinate according to [GEO] that defines a point
using the latitude, longitude, and altitude parameters.
Geo-Prefix: Forms a sphere (in three 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.
4. Geo-Points in RLOC-Records
Geo-Points MAY be present in an RLOC-Record to determine the physical
location of an Egress Tunnel Router (ETR) or Re-encapsulating
Tunneling 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 Database System. The EID-to-RLOC mapping is
EID=IPv6 and RLOC=geo-point. If someone does a Mapping Database
System lookup on the IPv6 EID, the Geo-Coordinate is returned. As
the EID roams, new registrations with different Geo-Coordinates are
stored, allowing the physical tracking of the package.
5. Geo-Prefixes in EID-Records and RLOC-Records
A Geo-Prefix is defined to be a Geo-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
System, 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 [RFC9735] 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 Database 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-Requester. 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 Database System,
then all Geo-Prefixes MUST be returned. This uses the same
overlapping lookup semantics defined in [RFC9301] for IP address
EIDs.
6. Geo-Points and Geo-Prefixes Examples
6.1. Locating a Package
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 Database System:
Contents of Mapping Database System:
EID=<dist-name="san francisco">
RLOC=<geo-prefix-of-60-mile-radius-of-sf>
EID=<ipv6-package-tracking-number>
RLOC=<geo-point-of-current-location>
EID=<geo-prefix-of-60-mile-radius-of-sf>
RLOC=<dist-name="san francisco">
Map-Request for package:
EID=<ipv6-package-tracking-number>
Mapping Database System returns:
RLOC=<geo-point-of-current-location>
Map-Request for Geo-Point:
EID=<geo-point-of-current-location>
Mapping Database System longest-match lookup returns:
EID=<geo-prefix-of-60-mile-radius-of-sf>
RLOC=<dist-name="san francisco">
If the package is not in San Francisco, the second mapping table
lookup would fail.
6.2. Wireless Connectivity
Another application is concentric rings of Wi-Fi access points (APs).
The radius of each ring corresponds to the Wi-Fi signal strength. An
EID could be located in any of the inner rings and possibly on the
edge of a ring. A Wi-Fi AP RLOC can be selected to encapsulate
packets because it will have a better signal to the current EID
location. In addition, when there are intersecting spheres, a good
time to transition radios to closer Wi-Fi APs or 3GPP Radio Access
Network (RAN) base stations is when the EID is in the intersection of
the spheres.
6.3. Vehicular Networks
When assigning EIDs to vehicles [V2I-PROB], a Geo-Prefix could be
used to create a "reachability set" of Roadside 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 [PRED-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).
7. Geo-Prefix and Geo-Point Encodings
When a Geo-Prefix or a Geo-Point is 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:
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 = 17 | Rsvd2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|N|E|A|M|R|K| Reserved | Location Uncertainty |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lat Degrees | Latitude Milliseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Long Degrees | Longitude Milliseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Altitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radius | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI | Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Geo-Location LCAF Encoding Format
AFI: Set to 16387 to indicate that the address is using the LCAF
format from [RFC8060].
Type: 17
Rsvd1/Rsvd2/Flags: See [RFC8060] for details.
Length: The length in bytes, starting with and including the byte
after the 'Length' field.
U-bit: 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.
N-bit: 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.
E-bit: 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.
A-bit: 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.
M-bit: 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.
R-bit: 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 the encoding is a
Geo-Point.
K-bit: 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.
Reserved: Reserved for future addition of bit fields. These bits
MUST be set to 0 when sending protocol packets and MUST be ignored
when receiving protocol packets.
Location Uncertainty: Unsigned 16-bit integer indicating the number
of centimeters of uncertainty for the location.
Latitude Degrees: Unsigned 8-bit integer with a range of 0 to 90
degrees north or south of the Equator (northern or southern
hemisphere, respectively).
Latitude Milliseconds: Unsigned 24-bit integer with a range of 0 to
3,599,999 (i.e., less than 60 minutes).
Longitude Degrees: Unsigned 8-bit integer with a range of 0 to 180
degrees east or west of the Prime Meridian.
Longitude Milliseconds: Unsigned 24-bit integer with a range of 0 to
3,599,999 (i.e., less than 60 minutes).
Altitude: 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.
Radius: 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.
AFI/Address: The 'AFI' field indicates the Address Family Identifier
[AFN] [RFC8060] for the address in the 'Address' field.
8. Backward-Compatibility Considerations
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 Database System lookups to LISP nodes that do not
understand them. In such situations, the RLOC-Record is ignored.
9. Security Considerations
The use of Geo-Coordinates in any application must be considered
carefully to not violate any privacy concerns about physical
location. This document does take into consideration the
applicability of BCP 160 [RFC6280] 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 Database System as well as network components that make up
the Mapping Database 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-Replies
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 as described in [RFC9303].
The Map-Replies not only authenticate 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 xTR devices or other asset inventory. However, since Geo-
Coordinate-encoded RLOCs can be associated with any EID, tracking of
hosts can occur if such an EID is assigned to hosts.
10. Privacy Considerations
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 privacy guidelines in [RFC6973] can be implemented with existing
LISP features, for example:
* Using signatures from [ECDSA-AUTH] can authenticate and authorize
who can request such mapping records.
* Obfuscating a Geo-Point by using Geo-Prefixes 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 is to
describe the physical location of well-known public structures,
places, and landmarks rather than people, vehicles, and equipment.
11. IANA Considerations
Following the guidelines of [RFC8126], IANA has assigned the
following value in the "LISP Canonical Address Format (LCAF) Types"
registry [RFC8060]:
+=======+=====================+======================+
| Value | LISP LCAF Type Name | Reference |
+=======+=====================+======================+
| 17 | Geo-Location | RFC 10040, Section 7 |
+-------+---------------------+----------------------+
Table 1: Geo-Location LCAF Type Assignment
In addition, IANA has marked LCAF type 5 (Geo-Coordinates) as
deprecated in the "LISP Canonical Address Format (LCAF) Types"
registry. This type was defined in [RFC8060], which this document
updates.
12. References
12.1. Normative References
[GEO] National Geospatial-Intelligence Agency, "Department of
Defense World Geodetic System 1984: Its Definition and
Relationships with Local Geodetic Systems",
NGA.STND.0036_1.0.0_WGS84, 8 July 2014,
<https://nsgreg.nga.mil/doc/view?i=4085>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[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,
<https://www.rfc-editor.org/info/rfc6280>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>.
[RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,
February 2017, <https://www.rfc-editor.org/info/rfc8060>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9179] Hopps, C., "A YANG Grouping for Geographic Locations",
RFC 9179, DOI 10.17487/RFC9179, February 2022,
<https://www.rfc-editor.org/info/rfc9179>.
[RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos, Ed., "The Locator/ID Separation Protocol
(LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022,
<https://www.rfc-editor.org/info/rfc9300>.
[RFC9301] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos,
Ed., "Locator/ID Separation Protocol (LISP) Control
Plane", RFC 9301, DOI 10.17487/RFC9301, October 2022,
<https://www.rfc-editor.org/info/rfc9301>.
[RFC9303] Maino, F., Ermagan, V., Cabellos, A., and D. Saucez,
"Locator/ID Separation Protocol Security (LISP-SEC)",
RFC 9303, DOI 10.17487/RFC9303, October 2022,
<https://www.rfc-editor.org/info/rfc9303>.
[RFC9735] Farinacci, D. and L. Iannone, Ed., "Locator/ID Separation
Protocol (LISP) Distinguished Name Encoding", RFC 9735,
DOI 10.17487/RFC9735, February 2025,
<https://www.rfc-editor.org/info/rfc9735>.
12.2. Informative References
[AFN] IANA, "Address Family Numbers",
<http://www.iana.org/assignments/address-family-numbers>.
[BGP-GEO] Chen, E., Shen, N., and R. Raszuk, "Carrying Geo
Coordinates in BGP", Work in Progress, Internet-Draft,
draft-chen-idr-geo-coordinates-02, 31 October 2016,
<https://datatracker.ietf.org/doc/html/draft-chen-idr-geo-
coordinates-02>.
[ECDSA-AUTH]
Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA
Authentication and Authorization", Work in Progress,
Internet-Draft, draft-ietf-lisp-ecdsa-auth-17, 26 July
2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
lisp-ecdsa-auth-17>.
[ISIS-GEO] Shen, N., Ed. and E. Chen, "Carrying Geo Coordinates
Information In IS-IS", Work in Progress, Internet-Draft,
draft-shen-isis-geo-coordinates-04, 18 October 2017,
<https://datatracker.ietf.org/doc/html/draft-shen-isis-
geo-coordinates-04>.
[OSPF-GEO] Lindem, A., Ed., Shen, N., and E. Chen, "OSPF Extensions
for Advertising/Signaling Geo Location Information", Work
in Progress, Internet-Draft, draft-acee-ospf-geo-location-
05, 18 October 2017,
<https://datatracker.ietf.org/doc/html/draft-acee-ospf-
geo-location-05>.
[PRED-RLOCS]
Farinacci, D. and P. Pillay-Esnault, "LISP Predictive
RLOCs", Work in Progress, Internet-Draft, draft-ietf-lisp-
predictive-rlocs-15, 19 September 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-lisp-
predictive-rlocs-15>.
[V2I-PROB] Jeong, J. P. and T. T. Oh, "Problem Statement for Vehicle-
to-Infrastructure Networking", Work in Progress, Internet-
Draft, draft-jeong-its-v2i-problem-statement-02, 19 July
2016, <https://datatracker.ietf.org/doc/html/draft-jeong-
its-v2i-problem-statement-02>.
Acknowledgments
The author would like to thank the LISP WG for their review and
acceptance of this document and Kiran Makhijani for shepherding the
document.
Special thanks goes to Chris Hopps, Enke Chen, Acee Lindem, and
Naiming Shen for collaborating on a Geo-Location encoding format that
is consistent with OSPF [OSPF-GEO], IS-IS [ISIS-GEO], and BGP
[BGP-GEO].
Author's Address
Dino Farinacci
lispers.net
San Jose, CA
United States of America
Email: farinacci@gmail.com