< draft-google-self-published-geofeeds-04.txt   draft-google-self-published-geofeeds-05.txt >
Network Working Group E. Kline Network Working Group E. Kline
Internet-Draft Loon LLC Internet-Draft Loon LLC
Intended status: Experimental K. Duleba Intended status: Informational K. Duleba
Expires: November 28, 2019 Z. Szamonek Expires: February 17, 2020 Z. Szamonek
S. Moser S. Moser
Google Switzerland GmbH Google Switzerland GmbH
W. Kumari W. Kumari
Google Google
May 27, 2019 August 16, 2019
A Format for Self-published IP Geolocation Feeds A Format for Self-published IP Geolocation Feeds
draft-google-self-published-geofeeds-04 draft-google-self-published-geofeeds-05
Abstract Abstract
This document records a format whereby a network operator can publish This document records a format whereby a network operator can publish
a mapping of IP address prefixes to simplified geolocation a mapping of IP address prefixes to simplified geolocation
information, colloquially termed a geolocation "feed". Interested information, colloquially termed a geolocation "feed". Interested
parties can poll and parse these feeds to update or merge with other parties can poll and parse these feeds to update or merge with other
geolocation data sources and procedures. This format intentionally geolocation data sources and procedures. This format intentionally
only allows specifying coarse level location. only allows specifying coarse level location.
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 28, 2019. This Internet-Draft will expire on February 17, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 6 skipping to change at page 3, line 6
2.1.1. Geolocation feed individual entry fields . . . . . . 5 2.1.1. Geolocation feed individual entry fields . . . . . . 5
2.1.1.1. IP Prefix . . . . . . . . . . . . . . . . . . . . 5 2.1.1.1. IP Prefix . . . . . . . . . . . . . . . . . . . . 5
2.1.1.2. Country . . . . . . . . . . . . . . . . . . . . . 5 2.1.1.2. Country . . . . . . . . . . . . . . . . . . . . . 5
2.1.1.3. Region . . . . . . . . . . . . . . . . . . . . . 5 2.1.1.3. Region . . . . . . . . . . . . . . . . . . . . . 5
2.1.1.4. City . . . . . . . . . . . . . . . . . . . . . . 6 2.1.1.4. City . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1.5. Postal code . . . . . . . . . . . . . . . . . . . 6 2.1.1.5. Postal code . . . . . . . . . . . . . . . . . . . 6
2.1.2. Prefixes with no geolocation information . . . . . . 6 2.1.2. Prefixes with no geolocation information . . . . . . 6
2.1.3. Additional parsing requirements . . . . . . . . . . . 7 2.1.3. Additional parsing requirements . . . . . . . . . . . 7
2.1.4. Looking up an IP address . . . . . . . . . . . . . . 7 2.1.4. Looking up an IP address . . . . . . . . . . . . . . 7
2.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Proposed extensions . . . . . . . . . . . . . . . . . . . 8 3. Consuming self-published IP geolocation feeds . . . . . . . . 8
2.3.1. Delegation size . . . . . . . . . . . . . . . . . . . 9 3.1. Feed integrity . . . . . . . . . . . . . . . . . . . . . 9
2.3.2. Alternate format . . . . . . . . . . . . . . . . . . 9 3.2. Verification of authority . . . . . . . . . . . . . . . . 9
3. Consuming self-published IP geolocation feeds . . . . . . . . 9 3.3. Verification of accuracy . . . . . . . . . . . . . . . . 9
3.1. Feed integrity . . . . . . . . . . . . . . . . . . . . . 10 3.4. Refreshing feed information . . . . . . . . . . . . . . . 9
3.2. Verification of authority . . . . . . . . . . . . . . . . 10 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10
3.3. Verification of accuracy . . . . . . . . . . . . . . . . 10 5. Relation to other work . . . . . . . . . . . . . . . . . . . 10
3.4. Refreshing feed information . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 7. Planned future work . . . . . . . . . . . . . . . . . . . . . 11
5. Relation to other work . . . . . . . . . . . . . . . . . . . 11 8. Finding self-published IP geolocation feeds . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8.1. Ad hoc 'well known' URIs . . . . . . . . . . . . . . . . 12
7. Finding self-published IP geolocation feeds . . . . . . . . . 12 8.2. Other mechanisms . . . . . . . . . . . . . . . . . . . . 12
7.1. Ad hoc 'well known' URIs . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7.2. Using public databases of network authority . . . . . . . 13 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
7.3. Using 'reverse' DNS with NAPTR records . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 15 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Sample Python validation code . . . . . . . . . . . 15
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
Appendix A. Sample Python validation code . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
1.1. Motivation 1.1. Motivation
Providers of services over the Internet have grown to depend on best- Providers of services over the Internet have grown to depend on best-
effort geolocation information to improve the user experience. effort geolocation information to improve the user experience.
Locality information can aid in directing traffic to the nearest Locality information can aid in directing traffic to the nearest
serving location, inferring likely native language, and providing serving location, inferring likely native language, and providing
additional context for services involving search queries. additional context for services involving search queries.
skipping to change at page 5, line 17 skipping to change at page 5, line 17
For operational simplicity, every feed should contain data about all For operational simplicity, every feed should contain data about all
IP addresses the provider wants to publish. Alternatives, like IP addresses the provider wants to publish. Alternatives, like
publishing only entries for IP addresses whose geolocation data has publishing only entries for IP addresses whose geolocation data has
changed or differ from current observed geolocation behavior "at changed or differ from current observed geolocation behavior "at
large", are likely to be too operationally complex. large", are likely to be too operationally complex.
Feeds MUST use UTF-8 [RFC3629] character encoding. Text after a '#' Feeds MUST use UTF-8 [RFC3629] character encoding. Text after a '#'
character is treated as a comment only and ignored. Blank lines are character is treated as a comment only and ignored. Blank lines are
similarly ignored. similarly ignored.
Feeds MUST be in comma separated values format as described in Feeds lines that are not comments MUST be in comma separated value
[RFC4180]. Each feed entry is a text line of the form: (CSV) format as described in [RFC4180]. Each feed entry is a text
line of the form:
ip_prefix,country,region,city,postal_code ip_prefix,country,region,city,postal_code
The IP prefix field is REQUIRED, all others are OPTIONAL (can be The IP prefix field is REQUIRED, all others are OPTIONAL (can be
empty), though the requisite minimum number of commas SHOULD be empty), though the requisite minimum number of commas SHOULD be
present. present.
2.1.1. Geolocation feed individual entry fields 2.1.1. Geolocation feed individual entry fields
2.1.1.1. IP Prefix 2.1.1.1. IP Prefix
skipping to change at page 6, line 22 skipping to change at page 6, line 22
Examples include "Dublin", "New York", and "Sao Paulo" (specifically Examples include "Dublin", "New York", and "Sao Paulo" (specifically
"S" followed by 0xc3, 0xa3, and "o Paulo"). "S" followed by 0xc3, 0xa3, and "o Paulo").
2.1.1.5. Postal code 2.1.1.5. Postal code
OPTIONAL, DEPRECATED. The postal code field, if non-empty, SHOULD be OPTIONAL, DEPRECATED. The postal code field, if non-empty, SHOULD be
free UTF-8 text, excluding the comma (',') character. The use of free UTF-8 text, excluding the comma (',') character. The use of
this field is deprecated; consumers of feeds should be able to parse this field is deprecated; consumers of feeds should be able to parse
feeds containing these fields, but new feeds SHOULD NOT include this feeds containing these fields, but new feeds SHOULD NOT include this
field, due to the granularity of this information. See See Section 4 field, due to the granularity of this information. See Section 4 for
for additional discussion. additional discussion.
Examples include "106-6126" (in Minato ward, Tokyo, Japan). Examples include "106-6126" (in Minato ward, Tokyo, Japan).
2.1.2. Prefixes with no geolocation information 2.1.2. Prefixes with no geolocation information
Feed publishers may indicate that some IP prefixes should not have Feed publishers may indicate that some IP prefixes should not have
any associated geolocation information. It may be that some prefixes any associated geolocation information. It may be that some prefixes
under their administrative control are reserved, not yet allocated or under their administrative control are reserved, not yet allocated or
deployed, or are in the process of being redeployed elsewhere and deployed, or are in the process of being redeployed elsewhere and
existing geolocation information can, from the perspective of the existing geolocation information can, from the perspective of the
publisher, safely be discarded. publisher, safely be discarded.
This special case can be indicated by explicitly leaving blank all This special case can be indicated by explicitly leaving blank all
fields which specify any degree of geolocation information. For fields which specify any degree of geolocation information. For
example: example:
127.0.0.0/8,,,, 192.0.2.0/24,,,,
224.0.0.0/4,,,, 2001:db8:1::/48,,,,
240.0.0.0/4,,,, 2001:db8:2::/48,,,,
Historically, the user-assigned country identifier of "ZZ" had be Historically, the user-assigned country identifier of "ZZ" had be
used for this same purpose. This is not necessarily preferred, and used for this same purpose. This is not necessarily preferred, and
no specific interpretation of any of the other user-assigned country no specific interpretation of any of the other user-assigned country
codes is currently defined. codes is currently defined.
2.1.3. Additional parsing requirements 2.1.3. Additional parsing requirements
Feed entries missing required fields, or having a required field Feed entries missing required fields, or having a required field
which fails to parse correctly MUST be discarded. It is RECOMMENDED which fails to parse correctly MUST be discarded. It is RECOMMENDED
skipping to change at page 8, line 5 skipping to change at page 8, line 5
192.0.2.5,US,US-AL,Alabaster, 192.0.2.5,US,US-AL,Alabaster,
192.0.2.128/25,PL,PL-MZ,, 192.0.2.128/25,PL,PL-MZ,,
2001:db8::/32,PL,,, 2001:db8::/32,PL,,,
2001:db8:cafe::/48,PL,PL-MZ,, 2001:db8:cafe::/48,PL,PL-MZ,,
The IETF network publishes geolocation information for the meeting The IETF network publishes geolocation information for the meeting
prefixes, and generally just comment out the last meeting information prefixes, and generally just comment out the last meeting information
and append the new meeting information. The [GEO_IETF] at the time and append the new meeting information. The [GEO_IETF] at the time
of this writing contains: of this writing contains:
# IETF 104, March 2019 - Prague, CZ. # IETF 104, March 2019 - Prague, CZ.
# Note that Prague changed from CZ-PR to CZ-10 2016-11-15 # Note that Prague changed from CZ-PR to CZ-10 2016-11-15
# https://www.iso.org/obp/ui/#iso:code:3166:CZ # https://www.iso.org/obp/ui/#iso:code:3166:CZ
130.129.0.0/16,CZ,CZ-10,Prague, 130.129.0.0/16,CZ,CZ-10,Prague,
2001:df8::/32,CZ,CZ-10,Prague, 2001:df8::/32,CZ,CZ-10,Prague,
31.133.128.0/18,CZ,CZ-10,Prague, 31.133.128.0/18,CZ,CZ-10,Prague,
31.130.224.0/20,CZ,CZ-10,Prague, 31.130.224.0/20,CZ,CZ-10,Prague,
2001:67c:1230::/46,CZ,CZ-10,Prague, 2001:67c:1230::/46,CZ,CZ-10,Prague,
2001:67c:370::/48,CZ,CZ-10,Prague, 2001:67c:370::/48,CZ,CZ-10,Prague,
Experimentally, RIPE has published geolocation information for their Experimentally, RIPE has published geolocation information for their
conference network prefixes, which change location in accordance with conference network prefixes, which change location in accordance with
each new event. [GEO_RIPE_NCC] at the time of writing contains: each new event. [GEO_RIPE_NCC] at the time of writing contains:
193.0.24.0/21,IS,IS-1,Reykjavik, 193.0.24.0/21,IS,IS-1,Reykjavik,
2001:67c:64::/48,IS,IS-1,Reykjavik, 2001:67c:64::/48,IS,IS-1,Reykjavik,
Similarly, ICANN has published geolocation information for their Similarly, ICANN has published geolocation information for their
portable conference network prefixes. [GEO_ICANN] at the time of portable conference network prefixes. [GEO_ICANN] at the time of
writing contains: writing contains:
199.91.192.0/21,ES,ES-CT,Barcelona 199.91.192.0/21,ES,ES-CT,Barcelona
2620:f:8000::/48,ES,ES-CT,Barcelona 2620:f:8000::/48,ES,ES-CT,Barcelona
A longer example is the [GEO_Google] Google Corp Geofeed, which lists A longer example is the [GEO_Google] Google Corp Geofeed, which lists
the geo-location information for Google corporate offices. the geo-location information for Google corporate offices.
Furthermore, it is worth noting that the geolocation data of SixXS Furthermore, it is worth noting that the geolocation data of SixXS
users, already available at whois.sixxs.net, is now also accessible users, already available at whois.sixxs.net, is now also accessible
in the format described here (see [GEO_SIXXS]). This can be in the format described here (see [GEO_SIXXS]). This can be
particularly useful where tunnel broker networks [RFC3053] are particularly useful where tunnel broker networks [RFC3053] are
concerned as: concerned as:
o the geolocation attributes of users with neighboring prefixes can o the geolocation attributes of users with neighboring prefixes can
be quite different and therefore not easily aggregated, and be quite different and therefore not easily aggregated, and
o attempting to learn this data by statistical analysis can be o attempting to learn this data by statistical analysis can be
complicated by the likely low number of samples for any given complicated by the likely low number of samples for any given
user, making satisfactory statistical confidence difficult to user, making satisfactory statistical confidence difficult to
achieve. achieve.
2.3. Proposed extensions
Already some discussions have resulted in proposed extensions. While
the purpose of this document is principally to record existing
implementation details, it may be that there is a larger desire to
publish other "network attributes" in a similar manner. One such
network attribute, "delegation size", is not currently implemented,
but the state of the proposed extension is recorded here to
demonstrate the flexibility required of parser implementations.
The following have been only informally discussed and are not in use
at the time of writing.
2.3.1. Delegation size
OPTIONAL. A publisher may optionally communicate the average
delegated prefix size for subnetworks within the IP prefix of this
entry. For a network operator this can be used to help consumers
distinguish IP prefixes among various use types such as residential
prefixes, allocations to businesses, or data center customer
allocations.
Non-empty strings MUST be of the form required for CIDR notation
suffixes, i.e. "/" followed by the integer prefix length of the
expected allocation to the subnetworks from within the entry's
prefix. In the absence of data to the contrary, it is common to
assume that leaf networks may be delegated a prefix ranging from /24
to /32 in IPv4 and /48 to /64 in IPv6. Default assumptions about
delegation size are left to the consumer's implementation.
Examples for IPv6 include "/48", "/56", "/60", and "/64".
2.3.2. Alternate format
In order to more flexibly support future extensions, use of a more
expressive feed format has been suggested. Use of JavaScript Object
Notation (JSON, [RFC4627]), specifically, has been discussed.
However, at the time of writing no such specification nor
implementation exists.
The authors are planning on writing a new document describing such a
new format. The current document describes a currently deployed and
used format.
3. Consuming self-published IP geolocation feeds 3. Consuming self-published IP geolocation feeds
Consumers MAY treat published feed data as a hint only and MAY choose Consumers MAY treat published feed data as a hint only and MAY choose
to prefer other sources of geolocation information for any given IP to prefer other sources of geolocation information for any given IP
prefix. Regardless of a consumer's stance with respect to a given prefix. Regardless of a consumer's stance with respect to a given
published feed, there are some points of note for sensibly and published feed, there are some points of note for sensibly and
effectively consuming published feeds. effectively consuming published feeds.
3.1. Feed integrity 3.1. Feed integrity
skipping to change at page 12, line 32 skipping to change at page 11, line 32
increases the ease with which such location data might be exploited. increases the ease with which such location data might be exploited.
For consumers, feed retrieval processes may receive input from For consumers, feed retrieval processes may receive input from
potentially hostile sources (e.g. in the event of hijacked traffic). potentially hostile sources (e.g. in the event of hijacked traffic).
As such, proper input validation and defense measures MUST be taken. As such, proper input validation and defense measures MUST be taken.
Similarly, consumers who do not perform sufficient verification of Similarly, consumers who do not perform sufficient verification of
published data bear the same risks as from other forms of geolocation published data bear the same risks as from other forms of geolocation
configuration errors. configuration errors.
7. Finding self-published IP geolocation feeds Validation of a feed's contents includes verifying that the publisher
is authoritative for the IP prefixes included in the feed. Failure
to verify IP prefix authority would, for example, allow ISP Bob to
make geolocation statements about IP space held by ISP Alice. At
this time only out-of-band verification methods are implemented (i.e.
an ISP's feed may be verified against publicly available IP
allocation data).
7. Planned future work
In order to more flexibly support future extensions, use of a more
expressive feed format has been suggested. Use of JavaScript Object
Notation (JSON, [RFC4627]), specifically, has been discussed.
However, at the time of writing no such specification nor
implementation exists. Nevertheless, work on extensions is deferred
until a more suitable format has been selected
The authors are planning on writing a document describing such a new
format. The current document describes a currently deployed and used
format.
8. Finding self-published IP geolocation feeds
The issue of finding, and later verifying, geolocation feeds is not The issue of finding, and later verifying, geolocation feeds is not
formally specified in this document. At this time, only ad hoc feed formally specified in this document. At this time, only ad hoc feed
discovery and verification has a modicum of established practice (see discovery and verification has a modicum of established practice (see
below). Regardless, both the ad hoc mechanics and a few proposed but below); discussion of other mechanisms has been removed for clarity.
not yet implemented alternatives are discussed.
7.1. Ad hoc 'well known' URIs 8.1. Ad hoc 'well known' URIs
To date, geolocation feeds have been shared informally in the form of To date, geolocation feeds have been shared informally in the form of
HTTPS URIs exchanged in email threads. The two example URIs HTTPS URIs exchanged in email threads. The two example URIs
documented above describe networks that change locations documented above describe networks that change locations
periodically, the operators and operational practices of which are periodically, the operators and operational practices of which are
well known within their respective technical communities. well known within their respective technical communities.
The contents of the feeds are verified by a similarly ad hoc process The contents of the feeds are verified by a similarly ad hoc process
including: including:
skipping to change at page 13, line 15 skipping to change at page 12, line 36
prefixes of Autonomous System Numbers known to be operated by the prefixes of Autonomous System Numbers known to be operated by the
publishers. publishers.
Ad hoc mechanisms, while useful for early experimentation by Ad hoc mechanisms, while useful for early experimentation by
producers and consumers, are unlikely to be adequate for long-term, producers and consumers, are unlikely to be adequate for long-term,
widespread use by multiple parties. Future versions of any such widespread use by multiple parties. Future versions of any such
self-published geolocation feed mechanism SHOULD address scalability self-published geolocation feed mechanism SHOULD address scalability
concerns by defining a means for automated discovery and verification concerns by defining a means for automated discovery and verification
of operational authority of advertised prefixes. of operational authority of advertised prefixes.
7.2. Using public databases of network authority 8.2. Other mechanisms
One possibility for enabling automation would be publication of feed
URIs as a well-known attribute in public databases of network
authority, e.g. the WHOIS service ([RFC3912]) operated by RIRs.
Verification may be performed if the same or similarly authoritative
service provides the identical feed URI for queries for each CIDR
prefix in the geolocation feed.
The burden of serving this data to all interested consumers,
especially the load imposed by any verification process, is not yet
known. The anticipation of additional operational burden on the
public resource of record (the database of network authority) is
however a noted concern.
7.3. Using 'reverse' DNS with NAPTR records
Another possibility for automating the location and verification of a
geolocation feed is to incorporate feed URIs into the DNS,
specifically the in-addr.arpa and ip6.arpa portions of the DNS
hierarchy. A suitably formatted query for a NAPTR ([RFC3403])
record, or more specifically a U-NAPTR ([RFC4848]) record, could
yield a transformation to a geolocation feed URI.
For example, assuming a purely theoretical service name of
"x-geofeed", a 'reverse' DNS zone might contain a record of the form:
;; order pref flags
IN NAPTR 200 10 "u" "x-geofeed" ( ; service
; regexp
"!.*!https://example.com/ipgeo.csv!"
"" ; replacement
)
Attempts to locate the geolocation feed for a given IP address would
begin by querying directly for a NAPTR record associated with the
address's PTR-style name. For example, 192.0.2.4 and 2001:db8::6
would cause a NAPTR record request to be issued for "4.2.0.192.in-
addr.arpa" and "6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d
.0.1.0.0.2.ip6.arpa", respectively.
If no such record exists, one further NAPTR query for the fully
qualified domain name of the SOA record in the authority section of
the response to the previous query would be performed ("2.0.192.in-
addr.arpa" and "d.0.1.0.0.2.ip6.arpa" in the examples above).
If one or more NAPTR records exist for the full PTR-style name but
none of them are for the required service name (e.g. "x-geofeed"),
then likely no SOA will be returned as a hint for subsequent queries.
In this case, implementations would need to first explicitly query
for an SOA record for the full PTR-style name, and then query for a
NAPTR record of the SOA in the response (assuming it differs from the
previously queried name).
Any successfully located feed URIs could then be processed as Previous versions of this document referenced use of the WHOIS
outlined by this document. service ([RFC3912]) operated by RIRs as well as possible DNS-based
schemes to discover and validate geofeeds. To the authors' knowledge
support for such mechanisms has never been implemented, and this
speculative text has been removed to avoid ambiguity.
Verification of the contents of a feed would proceed in essentially 9. IANA Considerations
the same way. CIDR prefixes may be verified by constructing a query
for any single address (at random) within the prefix and proceeding
as above. While not strictly provably correct (in cases where a
publisher has delegated some portion of the advertised prefix but not
excluded it from its feed), it may nevertheless suffice for
operational purposes, especially if a low-impact on-going
verification of observed client IP addresses is implemented, to
(eventually) catch any oversights.
This mode is untested and may prove impractical. However, the This document makes no requests of the IANA.
operational burden is more closely located with those wishing to bear
it, i.e. the publishers who would likely handle serving in-addr.arpa
and ip6.arpa for the IP prefixes under their authority.
8. Acknowledgements 10. Acknowledgements
The authors would like to express their gratitude to reviewers and The authors would like to express their gratitude to reviewers and
early implementers, including but not limited to Mikael Abrahamsson, early implementers, including but not limited to Mikael Abrahamsson,
Ray Bellis, John Bond, Alissa Cooper, Andras Erdei, Marco Hogewoning, Ray Bellis, John Bond, Alissa Cooper, Andras Erdei, Marco Hogewoning,
Mike Joseph, Maciej Kuzniar, Menno Schepers, Justyna Sidorska, Pim Mike Joseph, Maciej Kuzniar, Menno Schepers, Justyna Sidorska, Pim
van Pelt, and Bjoern A. Zeeb. Richard L. Barnes in particular van Pelt, and Bjoern A. Zeeb. Richard L. Barnes and Andy Newton in
contributed substantial review, text, and advice. particular contributed substantial review, text, and advice.
9. References 11. References
9.1. Normative References 11.1. Normative References
[ISO.3166.1alpha2] [ISO.3166.1alpha2]
International Organization for Standardization, "ISO International Organization for Standardization, "ISO
3166-1 decoding table", 3166-1 decoding table",
<http://www.iso.org/iso/home/standards/country_codes/ <http://www.iso.org/iso/home/standards/country_codes/
iso-3166-1_decoding_table.htm>. iso-3166-1_decoding_table.htm>.
[ISO.3166.2] [ISO.3166.2]
International Organization for Standardization, "ISO International Organization for Standardization, "ISO
3166-2:2007", <http://www.iso.org/iso/home/standards/ 3166-2:2007", <http://www.iso.org/iso/home/standards/
skipping to change at page 15, line 30 skipping to change at page 13, line 33
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, Transfer Protocol -- HTTP/1.1", RFC 2616,
DOI 10.17487/RFC2616, June 1999, <https://www.rfc- DOI 10.17487/RFC2616, June 1999, <https://www.rfc-
editor.org/info/rfc2616>. editor.org/info/rfc2616>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma-
Separated Values (CSV) Files", RFC 4180,
DOI 10.17487/RFC4180, October 2005, <https://www.rfc-
editor.org/info/rfc4180>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>. 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation (CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
2006, <https://www.rfc-editor.org/info/rfc4632>. 2006, <https://www.rfc-editor.org/info/rfc4632>.
9.2. Informative References 11.2. Informative References
[GEO_Google] [GEO_Google]
Google, LLC, "Google Corp Geofeed", Google, LLC, "Google Corp Geofeed",
<https://www.gstatic.com/geofeed/corp_external>. <https://www.gstatic.com/geofeed/corp_external>.
[GEO_ICANN] [GEO_ICANN]
Internet Corporation For Assigned Names and Numbers, Internet Corporation For Assigned Names and Numbers,
"ICANN Meeting Geolocation Data", "ICANN Meeting Geolocation Data",
<https://registration.icann.org/geo/google.csv>. <https://registration.icann.org/geo/google.csv>.
skipping to change at page 16, line 37 skipping to change at page 14, line 32
library", <http://code.google.com/p/ipaddr-py/>. library", <http://code.google.com/p/ipaddr-py/>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, <https://www.rfc- DOI 10.17487/RFC2818, May 2000, <https://www.rfc-
editor.org/info/rfc2818>. editor.org/info/rfc2818>.
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6
Tunnel Broker", RFC 3053, DOI 10.17487/RFC3053, January Tunnel Broker", RFC 3053, DOI 10.17487/RFC3053, January
2001, <https://www.rfc-editor.org/info/rfc3053>. 2001, <https://www.rfc-editor.org/info/rfc3053>.
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database",
RFC 3403, DOI 10.17487/RFC3403, October 2002,
<https://www.rfc-editor.org/info/rfc3403>.
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
DOI 10.17487/RFC3912, September 2004, <https://www.rfc- DOI 10.17487/RFC3912, September 2004, <https://www.rfc-
editor.org/info/rfc3912>. editor.org/info/rfc3912>.
[RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma-
Separated Values (CSV) Files", RFC 4180,
DOI 10.17487/RFC4180, October 2005, <https://www.rfc-
editor.org/info/rfc4180>.
[RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
for Authorizing Use of Domains in E-Mail, Version 1", for Authorizing Use of Domains in E-Mail, Version 1",
RFC 4408, DOI 10.17487/RFC4408, April 2006, RFC 4408, DOI 10.17487/RFC4408, April 2006,
<https://www.rfc-editor.org/info/rfc4408>. <https://www.rfc-editor.org/info/rfc4408>.
[RFC4627] Crockford, D., "The application/json Media Type for [RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, JavaScript Object Notation (JSON)", RFC 4627,
DOI 10.17487/RFC4627, July 2006, <https://www.rfc- DOI 10.17487/RFC4627, July 2006, <https://www.rfc-
editor.org/info/rfc4627>. editor.org/info/rfc4627>.
[RFC4848] Daigle, L., "Domain-Based Application Service Location
Using URIs and the Dynamic Delegation Discovery Service
(DDDS)", RFC 4848, DOI 10.17487/RFC4848, April 2007,
<https://www.rfc-editor.org/info/rfc4848>.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for Presence Information Data Format Location Format for Presence Information Data Format Location
Object (PIDF-LO)", RFC 5139, DOI 10.17487/RFC5139, Object (PIDF-LO)", RFC 5139, DOI 10.17487/RFC5139,
February 2008, <https://www.rfc-editor.org/info/rfc5139>. February 2008, <https://www.rfc-editor.org/info/rfc5139>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010, <https://www.rfc- DOI 10.17487/RFC5952, August 2010, <https://www.rfc-
editor.org/info/rfc5952>. editor.org/info/rfc5952>.
[RFC6772] Schulzrinne, H., Ed., Tschofenig, H., Ed., Cuellar, J., [RFC6772] Schulzrinne, H., Ed., Tschofenig, H., Ed., Cuellar, J.,
Polk, J., Morris, J., and M. Thomson, "Geolocation Policy: Polk, J., Morris, J., and M. Thomson, "Geolocation Policy:
A Document Format for Expressing Privacy Preferences for A Document Format for Expressing Privacy Preferences for
Location Information", RFC 6772, DOI 10.17487/RFC6772, Location Information", RFC 6772, DOI 10.17487/RFC6772,
January 2013, <https://www.rfc-editor.org/info/rfc6772>. January 2013, <https://www.rfc-editor.org/info/rfc6772>.
9.3. URIs 11.3. URIs
[1] http://tools.ietf.org/html/rfc4632#section-3.1 [1] http://tools.ietf.org/html/rfc4632#section-3.1
[2] http://tools.ietf.org/html/rfc4291#section-2.3 [2] http://tools.ietf.org/html/rfc4291#section-2.3
[3] http://tools.ietf.org/html/rfc2616#section-13.2 [3] http://tools.ietf.org/html/rfc2616#section-13.2
[4] http://tools.ietf.org/html/rfc2616#section-14.21 [4] http://tools.ietf.org/html/rfc2616#section-14.21
[5] http://tools.ietf.org/html/rfc2616#section-14.9 [5] http://tools.ietf.org/html/rfc2616#section-14.9
skipping to change at page 18, line 20 skipping to change at page 16, line 5
basic validation. It is intended for use by feed publishers before basic validation. It is intended for use by feed publishers before
launching a feed. Note that this validator does not verify the launching a feed. Note that this validator does not verify the
uniqueness of every IP prefix entry within the feed as a whole, but uniqueness of every IP prefix entry within the feed as a whole, but
only verifies the syntax of each single line from within the feed. A only verifies the syntax of each single line from within the feed. A
complete validator MUST also ensure IP prefix uniqueness. complete validator MUST also ensure IP prefix uniqueness.
The main source file "ipgeo_feed_validator.py" follows. It requires The main source file "ipgeo_feed_validator.py" follows. It requires
use of the open source ipaddr Python library for IP address and CIDR use of the open source ipaddr Python library for IP address and CIDR
parsing and validation [IPADDR_PY]. parsing and validation [IPADDR_PY].
<CODE BEGINS>
#!/usr/bin/python #!/usr/bin/python
# #
# Copyright (c) 2012 IETF Trust and the persons identified as authors of # Copyright (c) 2012 IETF Trust and the persons identified as authors of
# the code. All rights reserved. Redistribution and use in source and # the code. All rights reserved. Redistribution and use in source and
# binary forms, with or without modification, is permitted pursuant to, # binary forms, with or without modification, is permitted pursuant to,
# and subject to the license terms contained in, the Simplified BSD # and subject to the license terms contained in, the Simplified BSD
# License set forth in Section 4.c of the IETF Trust's Legal Provisions # License set forth in Section 4.c of the IETF Trust's Legal Provisions
# Relating to IETF Documents (http://trustee.ietf.org/license-info). # Relating to IETF Documents (http://trustee.ietf.org/license-info).
"""Simple format validator for self-published ipgeo feeds. """Simple format validator for self-published ipgeo feeds.
skipping to change at page 24, line 20 skipping to change at page 22, line 5
if not self.IsOutputLogCorrect(warning_count, error_count): if not self.IsOutputLogCorrect(warning_count, error_count):
self.failures += 1 self.failures += 1
return False return False
self.successes += 1 self.successes += 1
return True return True
if __name__ == '__main__': if __name__ == '__main__':
IPGeoFeedValidatorTest().Run() IPGeoFeedValidatorTest().Run()
<CODE ENDS>
Authors' Addresses Authors' Addresses
Erik Kline Erik Kline
Loon LLC Loon LLC
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, California 94043 Mountain View, California 94043
United States of America United States of America
Email: ek@loon.com Email: ek@loon.com
 End of changes. 31 change blocks. 
185 lines changed or deleted 93 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/