LISP Geo-Coordinate Use-Cases
draft-farinacci-lisp-geo-12
|
| Document |
Type |
|
Active Internet-Draft (candidate for lisp WG)
|
|
Author |
|
Dino Farinacci
|
|
Last updated |
|
2021-09-19
|
|
Stream |
|
Internet Engineering Task Force (IETF)
|
|
Intended RFC status |
|
(None)
|
|
Formats |
|
pdf
htmlized
bibtex
|
| Stream |
WG state
|
|
Call For Adoption By WG Issued
Polled for WG adoption but not adopted
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
I-D Exists
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group D. Farinacci
Internet-Draft lispers.net
Intended status: Experimental September 19, 2021
Expires: March 23, 2022
LISP Geo-Coordinate Use-Cases
draft-farinacci-lisp-geo-12
Abstract
This draft describes how Geo-Coordinates can be used in the LISP
Architecture and Protocols.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 23, 2022.
Copyright Notice
Copyright (c) 2021 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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Farinacci Expires March 23, 2022 [Page 1]
Internet-Draft LISP Geo-Coordinate Use-Cases September 2021
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3
3. Geo-Points in RLOC-records . . . . . . . . . . . . . . . . . 3
4. Geo-Prefixes in EID-records and RLOC-records . . . . . . . . 4
5. Geo-Prefix and Geo-Point Encodings . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 10
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 10
B.1. Changes to draft-farinacci-lisp-geo-12 . . . . . . . . . 10
B.2. Changes to draft-farinacci-lisp-geo-11 . . . . . . . . . 10
B.3. Changes to draft-farinacci-lisp-geo-10 . . . . . . . . . 10
B.4. Changes to draft-farinacci-lisp-geo-09 . . . . . . . . . 10
B.5. Changes to draft-farinacci-lisp-geo-08 . . . . . . . . . 10
B.6. Changes to draft-farinacci-lisp-geo-07 . . . . . . . . . 11
B.7. Changes to draft-farinacci-lisp-geo-06 . . . . . . . . . 11
B.8. Changes to draft-farinacci-lisp-geo-05 . . . . . . . . . 11
B.9. Changes to draft-farinacci-lisp-geo-04 . . . . . . . . . 11
B.10. Changes to draft-farinacci-lisp-geo-03 . . . . . . . . . 11
B.11. Changes to draft-farinacci-lisp-geo-02 . . . . . . . . . 11
B.12. Changes to draft-farinacci-lisp-geo-01 . . . . . . . . . 11
B.13. Changes to draft-farinacci-lisp-geo-00 . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
The LISP architecture and protocols [RFC6830] introduces two new
numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators
(RLOCs) which are intended to replace most use of IP addresses on the
Internet. 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)
[RFC1700].
This specification introduces the use of Geo-Coordinates that can be
used in EID-records and RLOC-records of LISP control messages. The
encoding format is specified in [RFC8060] as the "Geo-Coordinates
LCAF Type".
Farinacci Expires March 23, 2022 [Page 2]
Internet-Draft LISP Geo-Coordinate Use-Cases September 2021
2. Definition of Terms
Geo-Point is a Geo-Coordinate according to [GEO] that defines a
point from parameters Latitude, Longitude, and Altitude.
Geo-Prefix forms a circle 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 circle.
3. Geo-Points in RLOC-records
Geo-Points can accompany an RLOC-record to determine the physical
location of an ETR or 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.
Farinacci Expires March 23, 2022 [Page 3]
Internet-Draft LISP Geo-Coordinate Use-Cases September 2021
Geo-Points can 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
convienent.
Here is a high-level use-case where an EID that maps to a Geo-
Coordinate can be used. Lets say that am 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.
4. Geo-Prefixes in EID-records and RLOC-records
A Geo-Prefix is defined to be a Geo-Coordinate point and a Radius.
This allows a circle 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.
A Geo-Prefix could allow a Distinguished-Name
[I-D.farinacci-lisp-name-encoding] 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
Circle described by the Geo-Prefix, an entry is returned to the Map-
Requestor.
Farinacci Expires March 23, 2022 [Page 4]
Internet-Draft LISP Geo-Coordinate Use-Cases September 2021
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:
Contents of Mapping Database:
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 system returns:
RLOC=<geo-point-of-current-location>
Map-Request for geo-point:
EID=<geo-point-of-current-location>
Mapping system longest-match lookup returns:
EID=<geo-prefix-of-60-mile-radius-of-sf>
RLOC=<dist-name="san francisco">
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 on the inner rings but possibly on the edge
of a ring. A WiFi access-point RLOC can be selected to encapsulate
packets to because it will have better signal to the current EID
location. And when there are intersecting circles, it can be
determined that when the EID is in the intersection of the circles,
it would be a good time to transition radios to closer APs or base
stations.
When assigning EIDs to vehicles
[I-D.jeong-its-v2i-problem-statement], a Geo-Prefix could be used to
create a "reachability set" of Road-Side-Units (RSUs). So an 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).
Farinacci Expires March 23, 2022 [Page 5]
Internet-Draft LISP Geo-Coordinate Use-Cases September 2021
5. Geo-Prefix and Geo-Point Encodings
When a Geo-Prefix or a Geo-Point are encoded in an EID-record, it is
encoded solely with the Geo-Coordinates LCAF Type format when VPNs
are not in use. When VPNs are used, the Geo-Coordinate LCAF Type is
encoded within an Instance-ID LCAF Type.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|N|E|A|M|R|K| Reserved | Location Uncertainty |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lat Degrees | Latitude Milliseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Long Degrees | Longitude Milliseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Altitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radius | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rsvd1/Rsvd2/Flags: See [RFC8060] for details.
Length: length in bytes starting and including the byte after this
Length field.
U-bit: If the U-bit is set, it indicates that the "Location
Uncertainty" field is specified. If the U-bit is clear, it
indicates the "Location Uncertainty" field is unspecified.
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
specified. If the A-bit is clear, it indicates the "Altitude"
field is unspecified.
Farinacci Expires March 23, 2022 [Page 6]
Internet-Draft LISP Geo-Coordinate Use-Cases September 2021
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
specified and the encoding is a Geo-Prefix. If the R-bit is
clear, it indicates the "Radius" field is unspecified 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: These bits are reserved. They SHOULD 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 - 90
degrees north or south of the Equator (northern or southern
hemisphere, respectively).
Latitude Milliseconds: Unsigned 24-bit integer with a range of 0 -
3,599,999 (i.e., less than 60 minutes).
Longitude Degrees: Unsigned 8-bit integer with a range of 0 - 180
degrees east or west of the Prime Meridian.
Longitude Milliseconds: Unsigned 24-bit integer with a range of 0 -
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 circle
(or sphere) 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 circle defined by the radius and center point.
AFI = x: x can be any AFI value from [AFI] and [RFC8060].
Farinacci Expires March 23, 2022 [Page 7]
Internet-Draft LISP Geo-Coordinate Use-Cases September 2021
6. Security Considerations
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 [RFC6280] for location-based privacy protection.
In a LISP environment, Geo-Coordinates can be registered to the
Mapping Database System. When this occurs, an 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.
An xTR at a LISP site already has a business and trust relationship
with its Mapping Service Provider (MSP). When xTRs register their
mappings with Geo-Coordinate information, a policy is agreed upon
about who can access the information. Typically, the policy is
stored locally and processed by the xTR when the 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 [I-D.ietf-lisp-sec].
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.
7. IANA Considerations
At this time there are no specific requests for IANA.
8. References
8.1. Normative References
[GEO] Geodesy and Geophysics Department, DoD., "World Geodetic
System 1984", NIMA TR8350.2, January 2000, <http://earth-
info.nga.mil/GandG/publications/tr8350.2/wgs84fin.pdf>.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
DOI 10.17487/RFC1700, October 1994,
<https://www.rfc-editor.org/info/rfc1700>.
Farinacci Expires March 23, 2022 [Page 8]
Internet-Draft LISP Geo-Coordinate Use-Cases September 2021
[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>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013,
<https://www.rfc-editor.org/info/rfc6830>.
[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>.
8.2. Informative References
[AFI] "Address Family Identifier (AFIs)", ADDRESS FAMILY
NUMBERS http://www.iana.org/assignments/address-family-
numbers/address-family-numbers.xhtml?, Febuary 2007.
[I-D.acee-ospf-geo-location]
Lindem, A., Shen, N., and E. Chen, "OSPF Extensions for
Advertising/Signaling Geo Location Information", draft-
acee-ospf-geo-location-05 (work in progress), October
2017.
[I-D.chen-idr-geo-coordinates]
Chen, E., Shen, N., and R. Raszuk, "Carrying Geo
Coordinates in BGP", draft-chen-idr-geo-coordinates-02
(work in progress), October 2016.
[I-D.farinacci-lisp-name-encoding]
Farinacci, D., "LISP Distinguished Name Encoding", draft-
farinacci-lisp-name-encoding-12 (work in progress), May
2021.
[I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos, A., and D. Saucez,
"LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-22 (work
in progress), January 2021.
[I-D.jeong-its-v2i-problem-statement]
Jeong, J. P. and T. (. Oh, "Problem Statement for Vehicle-
to-Infrastructure Networking", draft-jeong-its-v2i-
problem-statement-02 (work in progress), July 2016.
Farinacci Expires March 23, 2022 [Page 9]
Internet-Draft LISP Geo-Coordinate Use-Cases September 2021
[I-D.shen-isis-geo-coordinates]
Shen, N. and E. Chen, "Carrying Geo Coordinates
Information In IS-IS", draft-shen-isis-geo-coordinates-04
(work in progress), October 2017.
Appendix A. Acknowledgments
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
[I-D.acee-ospf-geo-location], IS-IS [I-D.shen-isis-geo-coordinates],
and BGP [I-D.chen-idr-geo-coordinates] protocols.
Appendix B. Document Change Log
[RFC Editor: Please delete this section on publication as RFC.]
B.1. Changes to draft-farinacci-lisp-geo-12
o Posted September 2021.
o Update document timer and references.
B.2. Changes to draft-farinacci-lisp-geo-11
o Posted March 2021.
o Update document timer and references.
B.3. Changes to draft-farinacci-lisp-geo-10
o Posted October 2020.
o Update document timer and references.
B.4. Changes to draft-farinacci-lisp-geo-09
o Posted April 2020.
o Update document timer and references.
B.5. Changes to draft-farinacci-lisp-geo-08
o Posted October 2019.
o Update document timer and references.
Farinacci Expires March 23, 2022 [Page 10]
Internet-Draft LISP Geo-Coordinate Use-Cases September 2021
B.6. Changes to draft-farinacci-lisp-geo-07
o Posted April 2019.
o Update document timer and references.
B.7. Changes to draft-farinacci-lisp-geo-06
o Posted October 2018.
o Update document timer and references.
B.8. Changes to draft-farinacci-lisp-geo-05
o Posted April 2018.
o Update document timer and references.
B.9. Changes to draft-farinacci-lisp-geo-04
o Posted October 2017.
o Update document timer and references.
B.10. Changes to draft-farinacci-lisp-geo-03
o Posted April 2017.
o Update document timer.
B.11. Changes to draft-farinacci-lisp-geo-02
o Posted October 2016.
o Change format of the Geo-Coordinates LCAF Type to be compatible
with equivalent proposals for OSPF, IS-IS, and BGP.
o Add to the Security Considerations section to BCP160 compliance.
B.12. Changes to draft-farinacci-lisp-geo-01
o Posted October 2016.
o Clarify that the Geo-Coordinates LCAF type should be encoded
inside an Instance-ID LCAF type when VPNs are used.
o Indiate what the value of the Altitude field is when not included
in a message. Since this draft shortens the field, a new value is
Farinacci Expires March 23, 2022 [Page 11]
Internet-Draft LISP Geo-Coordinate Use-Cases September 2021
specified in this draft for not conveying an Altitude value in a
message.
B.13. Changes to draft-farinacci-lisp-geo-00
o Initial draft posted April 2016.
Author's Address
Dino Farinacci
lispers.net
San Jose, CA
USA
Email: farinacci@gmail.com
Farinacci Expires March 23, 2022 [Page 12]