A Format for Self-Published IP Geolocation Feeds
RFC 8805
Document | Type |
RFC - Informational
(August 2020; No errata)
Was draft-google-self-published-geofeeds (individual)
|
|
---|---|---|---|
Authors | Erik Kline , Krzysztof Duleba , Zoltan Szamonek , Stefan Moser , Warren Kumari | ||
Last updated | 2020-08-06 | ||
Stream | Independent Submission | ||
Formats | plain text html xml pdf htmlized (tools) htmlized bibtex | ||
IETF conflict review | conflict-review-google-self-published-geofeeds | ||
Stream | ISE state | Published RFC | |
Consensus Boilerplate | Unknown | ||
Document shepherd | Adrian Farrel | ||
Shepherd write-up | Show (last changed 2020-01-19) | ||
IESG | IESG state | RFC 8805 (Informational) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | Adrian Farrel <rfc-ise@rfc-editor.org> | ||
IANA | IANA review state | Version Changed - Review Needed |
Independent Submission E. Kline Request for Comments: 8805 Loon LLC Category: Informational K. Duleba ISSN: 2070-1721 Google Z. Szamonek S. Moser Google Switzerland GmbH W. Kumari Google August 2020 A Format for Self-Published IP Geolocation Feeds Abstract This document records a format whereby a network operator can publish a mapping of IP address prefixes to simplified geolocation information, colloquially termed a "geolocation feed". Interested parties can poll and parse these feeds to update or merge with other geolocation data sources and procedures. This format intentionally only allows specifying coarse-level location. Some technical organizations operating networks that move from one conference location to the next have already experimentally published small geolocation feeds. This document describes a currently deployed format. At least one consumer (Google) has incorporated these feeds into a geolocation data pipeline, and a significant number of ISPs are using it to inform them where their prefixes should be geolocated. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not 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/rfc8805. Copyright Notice Copyright (c) 2020 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. Table of Contents 1. Introduction 1.1. Motivation 1.2. Requirements Notation 1.3. Assumptions about Publication 2. Self-Published IP Geolocation Feeds 2.1. Specification 2.1.1. Geolocation Feed Individual Entry Fields 2.1.1.1. IP Prefix 2.1.1.2. Alpha2code (Previously: 'country') 2.1.1.3. Region 2.1.1.4. City 2.1.1.5. Postal Code 2.1.2. Prefixes with No Geolocation Information 2.1.3. Additional Parsing Requirements 2.2. Examples 3. Consuming Self-Published IP Geolocation Feeds 3.1. Feed Integrity 3.2. Verification of Authority 3.3. Verification of Accuracy 3.4. Refreshing Feed Information 4. Privacy Considerations 5. Relation to Other Work 6. Security Considerations 7. Planned Future Work 8. Finding Self-Published IP Geolocation Feeds 8.1. Ad Hoc 'Well-Known' URIs 8.2. Other Mechanisms 9. IANA Considerations 10. References 10.1. Normative References 10.2. Informative References Appendix A. Sample Python Validation Code Acknowledgements Authors' Addresses 1. Introduction 1.1. Motivation Providers of services over the Internet have grown to depend on best- effort geolocation information to improve the user experience. Locality information can aid in directing traffic to the nearest serving location, inferring likely native language, and providing additional context for services involving search queries. When an ISP, for example, changes the location where an IP prefix is deployed, services that make use of geolocation information may begin to suffer degraded performance. This can lead to customer complaints, possibly to the ISP directly. Dissemination of correct geolocation data is complicated by the lack of any centralized means to coordinate and communicate geolocation information to all interested consumers of the data. This document records a format whereby a network operator (an ISP, an enterprise, or any organization that deems the geolocation of its IP prefixes to be of concern) can publish a mapping of IP addressShow full document text