idnits 2.17.1 draft-farinacci-lisp-geo-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 255: '... reserved. They SHOULD be set to 0 wh...' RFC 2119 keyword, line 256: '...ocol packets and MUST be ignored when ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 93 has weird spacing: '...o-Point is a ...' == Line 96 has weird spacing: '...-Prefix forms...' -- The document date (September 19, 2021) is 940 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) == Outdated reference: A later version (-15) exists of draft-farinacci-lisp-name-encoding-12 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-22 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Farinacci 3 Internet-Draft lispers.net 4 Intended status: Experimental September 19, 2021 5 Expires: March 23, 2022 7 LISP Geo-Coordinate Use-Cases 8 draft-farinacci-lisp-geo-12 10 Abstract 12 This draft describes how Geo-Coordinates can be used in the LISP 13 Architecture and Protocols. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on March 23, 2022. 32 Copyright Notice 34 Copyright (c) 2021 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 51 3. Geo-Points in RLOC-records . . . . . . . . . . . . . . . . . 3 52 4. Geo-Prefixes in EID-records and RLOC-records . . . . . . . . 4 53 5. Geo-Prefix and Geo-Point Encodings . . . . . . . . . . . . . 6 54 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 55 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 56 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 57 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 58 8.2. Informative References . . . . . . . . . . . . . . . . . 9 59 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 10 60 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 10 61 B.1. Changes to draft-farinacci-lisp-geo-12 . . . . . . . . . 10 62 B.2. Changes to draft-farinacci-lisp-geo-11 . . . . . . . . . 10 63 B.3. Changes to draft-farinacci-lisp-geo-10 . . . . . . . . . 10 64 B.4. Changes to draft-farinacci-lisp-geo-09 . . . . . . . . . 10 65 B.5. Changes to draft-farinacci-lisp-geo-08 . . . . . . . . . 10 66 B.6. Changes to draft-farinacci-lisp-geo-07 . . . . . . . . . 11 67 B.7. Changes to draft-farinacci-lisp-geo-06 . . . . . . . . . 11 68 B.8. Changes to draft-farinacci-lisp-geo-05 . . . . . . . . . 11 69 B.9. Changes to draft-farinacci-lisp-geo-04 . . . . . . . . . 11 70 B.10. Changes to draft-farinacci-lisp-geo-03 . . . . . . . . . 11 71 B.11. Changes to draft-farinacci-lisp-geo-02 . . . . . . . . . 11 72 B.12. Changes to draft-farinacci-lisp-geo-01 . . . . . . . . . 11 73 B.13. Changes to draft-farinacci-lisp-geo-00 . . . . . . . . . 12 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 76 1. Introduction 78 The LISP architecture and protocols [RFC6830] introduces two new 79 numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators 80 (RLOCs) which are intended to replace most use of IP addresses on the 81 Internet. To provide flexibility for current and future 82 applications, these values can be encoded in LISP control messages 83 using a general syntax that includes Address Family Identifier (AFI) 84 [RFC1700]. 86 This specification introduces the use of Geo-Coordinates that can be 87 used in EID-records and RLOC-records of LISP control messages. The 88 encoding format is specified in [RFC8060] as the "Geo-Coordinates 89 LCAF Type". 91 2. Definition of Terms 93 Geo-Point is a Geo-Coordinate according to [GEO] that defines a 94 point from parameters Latitude, Longitude, and Altitude. 96 Geo-Prefix forms a circle of a geographic area made up of a Geo- 97 Point and a Radius. A Geo-Point is known to be "more-specific" 98 than a Geo-Prefix when its physical location is within the 99 geographic circle. 101 3. Geo-Points in RLOC-records 103 Geo-Points can accompany an RLOC-record to determine the physical 104 location of an ETR or RTR. This can aid in determining geographical 105 distance when topological distance is inaccurate or hidden. When 106 Geo-Points are encoded in RLOC-records with RLOC addresses the LCAF 107 AFI-List Type should be used. 109 Geo-Points can be used as the sole piece of information in an RLOC- 110 record when an EID maps to a Geo-Coordinate. If it is desirable to 111 find the geographical location of any EID, this method can be 112 convienent. 114 Here is a high-level use-case where an EID that maps to a Geo- 115 Coordinate can be used. Lets say that am EID is assigned to a 116 physical shipping package by a package delivery company. And the EID 117 is encoded as an IPv6 address where the tracking number is embedded 118 in an IPv6 EID. The network has LISP nodes deployed in many 119 locations that are configured with their respective Geo-Coordinates. 120 As the package roams, the LISP node that discovers the EID, registers 121 it to the LISP mapping system. The EID-to-RLOC mapping is EID=IPv6 122 and RLOC=Geo-Coordinate. If someone does a mapping database lookup 123 on the IPv6 EID, what is returned is the Geo-Coordinate. As the EID 124 roams, new registrations with different Geo-Coordinates are stored, 125 allowing the physical tracking of the package. 127 4. Geo-Prefixes in EID-records and RLOC-records 129 A Geo-Prefix is defined to be a Geo-Coordinate point and a Radius. 130 This allows a circle to be drawn on a geographic map. The Geo-Prefix 131 can describe a coarse physical location for an RLOC when encoded in 132 an RLOC-record. So an RLOC could be registered in the mapping 133 database indicating it is in a city or country versus the exact 134 location where a Geo-Point would locate it. 136 A Geo-Prefix could allow a Distinguished-Name 137 [I-D.farinacci-lisp-name-encoding] to be registered as an EID with an 138 RLOC that contains a Geo-Prefix. For example EID="San Francisco", 139 with RLOC=geo-prefix could be stored in the mapping system. 141 A Geo-Prefix, when encoded in an EID-record, could be registered as 142 an EID-prefix and when a Geo-Point is used as an EID lookup key, a 143 sort of longest match could be looked up. If the Geo-Point is in the 144 Circle described by the Geo-Prefix, an entry is returned to the Map- 145 Requestor. 147 You could take a combination of mappings from the above examples to 148 ask the question: "Is the package in San Francisco"? This could be 149 done with two lookups to the mapping system: 151 Contents of Mapping Database: 152 EID= 153 RLOC= 155 EID= 156 RLOC= 158 EID= 159 RLOC= 161 Map-Request for package: 162 EID= 163 Mapping system returns: 164 RLOC= 166 Map-Request for geo-point: 167 EID= 168 Mapping system longest-match lookup returns: 169 EID= 170 RLOC= 172 If the package was not in San Francisco, the second mapping table 173 lookup would fail. 175 Another application is concentric rings of WiFi access-points. The 176 radius of each ring corresponds to the Wifi signal strength. An EID 177 could be located in any on the inner rings but possibly on the edge 178 of a ring. A WiFi access-point RLOC can be selected to encapsulate 179 packets to because it will have better signal to the current EID 180 location. And when there are intersecting circles, it can be 181 determined that when the EID is in the intersection of the circles, 182 it would be a good time to transition radios to closer APs or base 183 stations. 185 When assigning EIDs to vehicles 186 [I-D.jeong-its-v2i-problem-statement], a Geo-Prefix could be used to 187 create a "reachability set" of Road-Side-Units (RSUs). So an ITR 188 could encapsulate to multiple RLOCs in the Geo-Prefix to try to 189 create connectivity to the vehicle while roaming. This makes use of 190 predictive RLOCs that can be used when the direction of the roaming 191 EID is known (a train track or single direction road, but not a 192 flight path of a plane). 194 5. Geo-Prefix and Geo-Point Encodings 196 When a Geo-Prefix or a Geo-Point are encoded in an EID-record, it is 197 encoded solely with the Geo-Coordinates LCAF Type format when VPNs 198 are not in use. When VPNs are used, the Geo-Coordinate LCAF Type is 199 encoded within an Instance-ID LCAF Type. 201 0 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | AFI = 16387 | Rsvd1 | Flags | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Type = 5 | Rsvd2 | Length | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 |U|N|E|A|M|R|K| Reserved | Location Uncertainty | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Lat Degrees | Latitude Milliseconds | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Long Degrees | Longitude Milliseconds | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Altitude | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Radius | Reserved | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | AFI = x | Address ... | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 Rsvd1/Rsvd2/Flags: See [RFC8060] for details. 223 Length: length in bytes starting and including the byte after this 224 Length field. 226 U-bit: If the U-bit is set, it indicates that the "Location 227 Uncertainty" field is specified. If the U-bit is clear, it 228 indicates the "Location Uncertainty" field is unspecified. 230 N-bit: If the N-bit is set, it indicates the Latitude is north 231 relative to the Equator. If the N-bit is clear, it indicates the 232 Latitude is south of the Equator. 234 E-bit: If the E-bit is set, it indicates the Longitude is east of 235 the Prime Meridian. If the E-bit is clear, it indicates the 236 Longitude is west of the Prime Meridian. 238 A-bit: If the A-bit is set, it indicates the "Altitude" field is 239 specified. If the A-bit is clear, it indicates the "Altitude" 240 field is unspecified. 242 M-bit: If the M-bit is set, it indicates the "Altitude" is specified 243 in meters. If the M-bit is clear, it indicates the "Altitude" is 244 in centimeters. 246 R-bit: If the R-bit is set, it indicates the "Radius" field is 247 specified and the encoding is a Geo-Prefix. If the R-bit is 248 clear, it indicates the "Radius" field is unspecified and the 249 encoding is a Geo-Point. 251 K-bit: If the K-bit is set, it indicates the "Radius" is specified 252 in kilometers. If the K-bit is clear, it indicates the "Radius" 253 is in meters. 255 Reserved: These bits are reserved. They SHOULD be set to 0 when 256 sending protocol packets and MUST be ignored when receiving 257 protocol packets. 259 Location Uncertainty: Unsigned 16-bit integer indicating the number 260 of centimeters of uncertainty for the location. 262 Latitude Degrees: Unsigned 8-bit integer with a range of 0 - 90 263 degrees north or south of the Equator (northern or southern 264 hemisphere, respectively). 266 Latitude Milliseconds: Unsigned 24-bit integer with a range of 0 - 267 3,599,999 (i.e., less than 60 minutes). 269 Longitude Degrees: Unsigned 8-bit integer with a range of 0 - 180 270 degrees east or west of the Prime Meridian. 272 Longitude Milliseconds: Unsigned 24-bit integer with a range of 0 - 273 3,599,999 (i.e., less than 60 minutes). 275 Altitude: Signed 32-bit integer containing the Height relative to 276 sea level in centimeters or meters. A negative height indicates 277 that the location is below sea level. 279 Radius: Unsigned 16-bit integer containing the radius of a circle 280 (or sphere) centered at the specified coordinates. The radius is 281 specified in meters unless the K-bit is specified indicating 282 radius is in kilometers. When the radius is specified, this LCAF 283 type encodes a Geo-Prefix where the geo-coordinates define the 284 entire area of the circle defined by the radius and center point. 286 AFI = x: x can be any AFI value from [AFI] and [RFC8060]. 288 6. Security Considerations 290 The use of Geo-Coordinates in any application must be considered 291 carefully to not violate any privacy concerns about physical 292 location. This draft does take into consideration the applicability 293 of BCP160 [RFC6280] for location-based privacy protection. 295 In a LISP environment, Geo-Coordinates can be registered to the 296 Mapping Database System. When this occurs, an xTR is allowing its 297 physical location to be known to queriers of the mapping system as 298 well as network components that make up the mapping system. There 299 are various sets of trust relationships that may exist. 301 An xTR at a LISP site already has a business and trust relationship 302 with its Mapping Service Provider (MSP). When xTRs register their 303 mappings with Geo-Coordinate information, a policy is agreed upon 304 about who can access the information. Typically, the policy is 305 stored locally and processed by the xTR when the MSP forwards Map- 306 Requests to the xTRs of the LISP site. Conditionally, based on the 307 requesting xTR, the responding xTR can apply the local policy to 308 decide if a Map-Reply is sent with all RLOC-records, or perhaps, the 309 RLOC-records that do not contain Geo-Coordinate information. 311 The MSP can also be requested by LISP site xTRs to proxy Map-Reply to 312 Map-Requests. In this case, the MSP must apply the xTR policy so 313 only authorized requesters get access to Geo-Coordinate information. 315 Note that once a requester is authorized, Map-Replies are returned 316 directly to the requester and are signed with [I-D.ietf-lisp-sec]. 317 The Map-Replies not only authenticates the Map-Replier but can be 318 encrypted by the Map-Replier so no eavesdropping of Geo-Coordinate 319 information can occur. 321 7. IANA Considerations 323 At this time there are no specific requests for IANA. 325 8. References 327 8.1. Normative References 329 [GEO] Geodesy and Geophysics Department, DoD., "World Geodetic 330 System 1984", NIMA TR8350.2, January 2000, . 333 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 334 DOI 10.17487/RFC1700, October 1994, 335 . 337 [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., 338 Tschofenig, H., and H. Schulzrinne, "An Architecture for 339 Location and Location Privacy in Internet Applications", 340 BCP 160, RFC 6280, DOI 10.17487/RFC6280, July 2011, 341 . 343 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 344 Locator/ID Separation Protocol (LISP)", RFC 6830, 345 DOI 10.17487/RFC6830, January 2013, 346 . 348 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 349 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 350 February 2017, . 352 8.2. Informative References 354 [AFI] "Address Family Identifier (AFIs)", ADDRESS FAMILY 355 NUMBERS http://www.iana.org/assignments/address-family- 356 numbers/address-family-numbers.xhtml?, Febuary 2007. 358 [I-D.acee-ospf-geo-location] 359 Lindem, A., Shen, N., and E. Chen, "OSPF Extensions for 360 Advertising/Signaling Geo Location Information", draft- 361 acee-ospf-geo-location-05 (work in progress), October 362 2017. 364 [I-D.chen-idr-geo-coordinates] 365 Chen, E., Shen, N., and R. Raszuk, "Carrying Geo 366 Coordinates in BGP", draft-chen-idr-geo-coordinates-02 367 (work in progress), October 2016. 369 [I-D.farinacci-lisp-name-encoding] 370 Farinacci, D., "LISP Distinguished Name Encoding", draft- 371 farinacci-lisp-name-encoding-12 (work in progress), May 372 2021. 374 [I-D.ietf-lisp-sec] 375 Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, 376 "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-22 (work 377 in progress), January 2021. 379 [I-D.jeong-its-v2i-problem-statement] 380 Jeong, J. P. and T. (. Oh, "Problem Statement for Vehicle- 381 to-Infrastructure Networking", draft-jeong-its-v2i- 382 problem-statement-02 (work in progress), July 2016. 384 [I-D.shen-isis-geo-coordinates] 385 Shen, N. and E. Chen, "Carrying Geo Coordinates 386 Information In IS-IS", draft-shen-isis-geo-coordinates-04 387 (work in progress), October 2017. 389 Appendix A. Acknowledgments 391 The author would like to thank the LISP WG for their review and 392 acceptance of this draft. 394 A special thanks goes to Enke Chen, Acee Lindem, and Naiming Shen for 395 collaboarting on a consistent geo-location encoding format with OSPF 396 [I-D.acee-ospf-geo-location], IS-IS [I-D.shen-isis-geo-coordinates], 397 and BGP [I-D.chen-idr-geo-coordinates] protocols. 399 Appendix B. Document Change Log 401 [RFC Editor: Please delete this section on publication as RFC.] 403 B.1. Changes to draft-farinacci-lisp-geo-12 405 o Posted September 2021. 407 o Update document timer and references. 409 B.2. Changes to draft-farinacci-lisp-geo-11 411 o Posted March 2021. 413 o Update document timer and references. 415 B.3. Changes to draft-farinacci-lisp-geo-10 417 o Posted October 2020. 419 o Update document timer and references. 421 B.4. Changes to draft-farinacci-lisp-geo-09 423 o Posted April 2020. 425 o Update document timer and references. 427 B.5. Changes to draft-farinacci-lisp-geo-08 429 o Posted October 2019. 431 o Update document timer and references. 433 B.6. Changes to draft-farinacci-lisp-geo-07 435 o Posted April 2019. 437 o Update document timer and references. 439 B.7. Changes to draft-farinacci-lisp-geo-06 441 o Posted October 2018. 443 o Update document timer and references. 445 B.8. Changes to draft-farinacci-lisp-geo-05 447 o Posted April 2018. 449 o Update document timer and references. 451 B.9. Changes to draft-farinacci-lisp-geo-04 453 o Posted October 2017. 455 o Update document timer and references. 457 B.10. Changes to draft-farinacci-lisp-geo-03 459 o Posted April 2017. 461 o Update document timer. 463 B.11. Changes to draft-farinacci-lisp-geo-02 465 o Posted October 2016. 467 o Change format of the Geo-Coordinates LCAF Type to be compatible 468 with equivalent proposals for OSPF, IS-IS, and BGP. 470 o Add to the Security Considerations section to BCP160 compliance. 472 B.12. Changes to draft-farinacci-lisp-geo-01 474 o Posted October 2016. 476 o Clarify that the Geo-Coordinates LCAF type should be encoded 477 inside an Instance-ID LCAF type when VPNs are used. 479 o Indiate what the value of the Altitude field is when not included 480 in a message. Since this draft shortens the field, a new value is 481 specified in this draft for not conveying an Altitude value in a 482 message. 484 B.13. Changes to draft-farinacci-lisp-geo-00 486 o Initial draft posted April 2016. 488 Author's Address 490 Dino Farinacci 491 lispers.net 492 San Jose, CA 493 USA 495 Email: farinacci@gmail.com