lispers.net

San Jose CA United States of America farinacci@gmail.com

RTG lisp 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 .

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 () 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

• .  Introduction
• .  Requirements Language
• .  Definition of Terms
• .  Geo-Points in RLOC-Records
• .  Geo-Prefixes in EID-Records and RLOC-Records
• .  Geo-Points and Geo-Prefixes Examples
  • .  Locating a Package
  • .  Wireless Connectivity
  • .  Vehicular Networks
• .  Geo-Prefix and Geo-Point Encodings
• .  Backward-Compatibility Considerations
• .  Security Considerations
• . Privacy Considerations
• . IANA Considerations
• . References
  • .  Normative References
  • .  Informative References
• Acknowledgments
• Author's Address

Introduction 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 Identifiers (AFIs) . 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 the Geo-Coordinates encoding defined in 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 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.

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

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

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.

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 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 for IP address EIDs.

Geo-Points and Geo-Prefixes Examples

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.

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.

Vehicular Networks When assigning EIDs to vehicles , 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 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).

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:

Geo-Location LCAF Encoding 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 = 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 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

AFI:

Set to 16387 to indicate that the address is using the LCAF format from .

Type:

17

Rsvd1/Rsvd2/Flags:

See 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 for the address in the 'Address' field.

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.

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 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 . 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.

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 can be implemented with existing LISP features, for example:

• Using signatures from 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.

IANA Considerations Following the guidelines of , IANA has assigned the following value in the "LISP Canonical Address Format (LCAF) Types" registry : Geo-Location LCAF Type Assignment

Value	LISP LCAF Type Name	Reference
17	Geo-Location	RFC 10040,

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 , which this document updates.

References Normative References National Geospatial-Intelligence Agency NGA.STND.0036_1.0.0_WGS84 In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Location-based services (such as navigation applications, emergency services, and management of equipment in the field) need geographic location information about Internet hosts, their users, and other related entities. These applications need to securely gather and transfer location information for location services, and at the same time protect the privacy of the individuals involved. This document describes an architecture for privacy-preserving location-based services in the Internet, focusing on authorization, security, and privacy requirements for the data formats and protocols used by these services. This memo documents an Internet Best Current Practice. This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. This document defines a canonical address format encoding used in Locator/ID Separation Protocol (LISP) control messages and in the encoding of lookup keys for the LISP Mapping Database System. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document defines a generic geographical location YANG grouping. The geographical location grouping is intended to be used in YANG data models for specifying a location on or in reference to Earth or any other astronomical object. This document describes the data plane protocol for the Locator/ID Separation Protocol (LISP). LISP defines two namespaces: Endpoint Identifiers (EIDs), which identify end hosts; and Routing Locators (RLOCs), which identify network attachment points. With this, LISP effectively separates control from data and allows routers to create overlay networks. LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local Map-Cache. LISP requires no change to either host protocol stacks or underlay routers and offers Traffic Engineering (TE), multihoming, and mobility, among other features. This document obsoletes RFC 6830. This document describes the control plane and Mapping Service for the Locator/ID Separation Protocol (LISP), implemented by two types of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provide a simplified "front end" for one or more Endpoint IDs (EIDs) to Routing Locator mapping databases. By using this control plane service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) are not dependent on the details of mapping database systems; this behavior facilitates modularity with different database designs. Since these devices implement the "edge" of the LISP control plane infrastructure, connecting EID addressable nodes of a LISP site, the implementation and operational complexity of the overall cost and effort of deploying LISP is reduced. This document obsoletes RFCs 6830 and 6833. This memo specifies Locator/ID Separation Protocol Security (LISP-SEC), a set of security mechanisms that provides origin authentication, integrity, and anti-replay protection to the LISP's Endpoint-ID-to-Routing-Locator (EID-to-RLOC) mapping data conveyed via the mapping lookup process. LISP-SEC also enables verification of authorization on EID-Prefix claims in Map-Reply messages. This document defines how to use the Address Family Identifier (AFI) 17 "Distinguished Name" in the Locator/ID Separation Protocol (LISP). LISP introduces two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). Distinguished Names (DNs) can be used in either EID-Records or RLOC-Records in LISP control messages to convey additional information. Informative References IANA Cisco Systems Cisco Systems Bloomberg LP In this document we specify a new BGP capability - the Geo Coordinate Capability, and a new BGP attribute - the Geo Coordinate Attribute, for carrying the Geo Coordinate information in BGP. Work in Progress lispers.net Zededa Work in Progress A. Lindem A. Lindem Work in Progress Cisco Systems Cisco Systems Cisco Systems Work in Progress lispers.net Independent This specification describes a method to achieve near-zero packet loss when an EID is roaming quickly across RLOCs. Work in Progress Sungkyunkwan University Rochester Institute of Technology This document specifies the problem statement for IPv6-based vehicle- to-infrastructure networking. Dedicated Short-Range Communications (DSRC) is standardized as IEEE 802.11p for the wireless media access in vehicular networks. This document addresses the extension of IPv6 as the network layer protocol in vehicular networks and is focused on the networking issues in one-hop communication between a Road-Side Unit (RSU) and vehicle. The RSU is connected to the Internet and allows vehicles to have the Internet access if connected. The major issues of including IPv6 in vehicular networks are neighbor discovery protocol, stateless address autoconfiguration, and DNS configuration for the Internet connectivity over DSRC. Also, when a vehicle and an RSU have an internal network, respectively, the document discusses the issues of the internetworking between the vehicle's internal network and the RSU's internal network, such as prefix discovery, prefix exchange, and service discovery. Work in Progress

Acknowledgments The author would like to thank the LISP WG for their review and acceptance of this document and for shepherding the document. Special thanks goes to , , , and for collaborating on a Geo-Location encoding format that is consistent with OSPF , IS-IS , and BGP .

Author's Address lispers.net

San Jose CA United States of America farinacci@gmail.com