< draft-google-self-published-geofeeds-02.txt   draft-google-self-published-geofeeds-03.txt >
Network Working Group E. Kline Network Working Group E. Kline
Internet-Draft Google Japan Internet-Draft Google Japan
Intended status: Informational K. Duleba Intended status: Experimental K. Duleba
Expires: January 30, 2014 Z. Szamonek Expires: September 11, 2019 Z. Szamonek
Google Switzerland GmbH Google Switzerland GmbH
July 29, 2013 March 10, 2019
Self-published IP Geolocation Data A Format for Self-published IP Geolocation Feeds
draft-google-self-published-geofeeds-02 draft-google-self-published-geofeeds-03
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 ranges to simplified geolocation information, a mapping of IP address prefixes to simplified geolocation
colloquially termed a geolocation "feed". Interested parties can information, colloquially termed a geolocation "feed". Interested
poll and parse these feeds to update or merge with other geolocation parties can poll and parse these feeds to update or merge with other
data sources and procedures. geolocation data sources and procedures. This format intentionally
only allows specifying coarse level location.
Some technical organizations operating networks that move from one Some technical organizations operating networks that move from one
conference location to the next have already experimentally published conference location to the next have already experimentally published
small geolocation feeds. At least one consumer (Google) has small geolocation feeds. At least one consumer (Google) has
incorporated these ad hoc feeds into a geolocation data pipeline. incorporated these ad hoc feeds into a geolocation data pipeline, and
is using it to allow ISPs to inform them where the prefixes live.
Status of this Memo [RFC Ed - Please remove publication: The IETF Meeting network
currently publishes a feed in this format at:
https://noc.ietf.org/geo/google.csv -- this has significantly cut
down on the number of "Gah! Why does the network believe I'm in
Montreal, that was last meeting! How am I supposed to find a pub?!"
complaints. A number of other meeting networks, including RIPE and
ICANN publish this information as well, see below. ]
[ Ed note: Text inside square brackets ([]) is additional background
information, answers to frequently asked questions, general musings,
etc. They will be removed before publication.]
[ This document is being collaborated on in Github at:
https://github.com/google/self-published-geo . The most recent
version of the document, open issues, etc should all be available
here. The authors (gratefully) accept pull requests ]
Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified, provisions of BCP 78 and BCP 79.
and derivative works of it may not be created, except to format it
for publication as an RFC or to translate it into languages other
than English.
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 https://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 January 30, 2014. This Internet-Draft will expire on September 11, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2013 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 (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements notation . . . . . . . . . . . . . . . . . . 3 1.2. Requirements notation . . . . . . . . . . . . . . . . . . 4
1.3. Implications of publication . . . . . . . . . . . . . . . 3 1.3. Implications of publication . . . . . . . . . . . . . . . 4
2. Self-published IP geolocation feeds . . . . . . . . . . . . . 4 2. Self-published IP geolocation feeds . . . . . . . . . . . . . 4
2.1. Specification . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Specification . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Geolocation feed individual entry fields . . . . . . . 5 2.1.1. Geolocation feed individual entry fields . . . . . . 5
2.1.2. Prefixes with no geolocation information . . . . . . . 6 2.1.1.1. IP Prefix . . . . . . . . . . . . . . . . . . . . 5
2.1.3. Additional parsing requirements . . . . . . . . . . . 6 2.1.1.2. Country . . . . . . . . . . . . . . . . . . . . . 5
2.1.4. Looking up an IP address . . . . . . . . . . . . . . . 7 2.1.1.3. Region . . . . . . . . . . . . . . . . . . . . . 5
2.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.1.4. City . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Proposed extensions . . . . . . . . . . . . . . . . . . . 8 2.1.1.5. Postal code . . . . . . . . . . . . . . . . . . . 6
2.3.1. Delegation size . . . . . . . . . . . . . . . . . . . 8 2.1.2. Prefixes with no geolocation information . . . . . . 6
2.3.2. Alternate format . . . . . . . . . . . . . . . . . . . 8 2.1.3. Additional parsing requirements . . . . . . . . . . . 6
3. Finding self-published IP geolocation feeds . . . . . . . . . 8 2.1.4. Looking up an IP address . . . . . . . . . . . . . . 7
3.1. Ad hoc 'well known' URIs . . . . . . . . . . . . . . . . . 9 2.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Using public databases of network authority . . . . . . . 9 2.3. Proposed extensions . . . . . . . . . . . . . . . . . . . 8
3.3. Using 'reverse' DNS with NAPTR records . . . . . . . . . . 9 2.3.1. Delegation size . . . . . . . . . . . . . . . . . . . 9
4. Consuming self-published IP geolocation feeds . . . . . . . . 11 2.3.2. Alternate format . . . . . . . . . . . . . . . . . . 9
4.1. Feed integrity . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Verification of authority . . . . . . . . . . . . . . . . 11 3. Consuming self-published IP geolocation feeds . . . . . . . . 9
4.3. Verification of accuracy . . . . . . . . . . . . . . . . . 11 3.1. Feed integrity . . . . . . . . . . . . . . . . . . . . . 9
4.4. Refreshing feed information . . . . . . . . . . . . . . . 11 3.2. Verification of authority . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 3.3. Verification of accuracy . . . . . . . . . . . . . . . . 10
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 12 3.4. Refreshing feed information . . . . . . . . . . . . . . . 10
7. Relation to other work . . . . . . . . . . . . . . . . . . . . 13 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 5. Relation to other work . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 7. Finding self-published IP geolocation feeds . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 14 7.1. Ad hoc 'well known' URIs . . . . . . . . . . . . . . . . 12
Appendix A. Sample Python validation code . . . . . . . . . . . . 15 7.2. Using public databases of network authority . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 7.3. Using 'reverse' DNS with NAPTR records . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 15
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Appendix A. Sample Python validation code . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
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 3, line 25 skipping to change at page 3, line 45
When an ISP, for example, changes the location where an IP prefix is When an ISP, for example, changes the location where an IP prefix is
deployed, services which make use of geolocation information may deployed, services which make use of geolocation information may
begin to suffer degraded performance. This can lead to customer begin to suffer degraded performance. This can lead to customer
complaints, possibly to the ISP directly. Dissemination of correct complaints, possibly to the ISP directly. Dissemination of correct
geolocation data is complicated by the lack of any centralized means geolocation data is complicated by the lack of any centralized means
to coordinate and communicate geolocation information to all to coordinate and communicate geolocation information to all
interested consumers of the data. interested consumers of the data.
This document records a format whereby a network operator (an ISP, an This document records a format whereby a network operator (an ISP, an
enterprise, or any organization which deems the geolocation of its IP enterprise, or any organization which deems the geolocation of its IP
prefixes to be of concern) can publish a mapping of IP address ranges prefixes to be of concern) can publish a mapping of IP address
to simplified geolocation information, colloquially termed a prefixes to simplified geolocation information, colloquially termed a
"geolocation feed". Interested parties can poll and parse these "geolocation feed". Interested parties can poll and parse these
feeds to update or merge with other geolocation data sources and feeds to update or merge with other geolocation data sources and
procedures. procedures.
Some technical organizations operating networks that move from one Some technical organizations operating networks that move from one
conference location to the next have already experimentally published conference location to the next have already experimentally published
small geolocation feeds. At least one consumer (Google) has small geolocation feeds. At least one consumer (Google) has
incorporated these ad hoc feeds into a geolocation data pipeline. incorporated these ad hoc feeds into a geolocation data pipeline.
1.2. Requirements notation 1.2. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in RFC2119.
1.3. Implications of publication 1.3. Implications of publication
This document describes both a format and a mechanism for publishing This document describes both a format and a mechanism for publishing
data, with the implication that the owner of the data wishes it to be data, with the implication that the owner of the data wishes it to be
public. Any privacy risk is bounded by the format, and data public. Any privacy risk is bounded by the format, and feed
publishers MAY omit certain fields to further protect privacy (see publishers MAY omit any location field to further protect privacy
Section 2.1 for details about which fields exactly may be omitted). (see Section 2.1 for details about which fields exactly may be
Feed publishers assume the responsibility of determining which data omitted). Feed publishers assume the responsibility of determining
should be made public. which data should be made public.
This proposal does not incorporate a mechanism to communicate This proposal does not incorporate a mechanism to communicate
acceptable use policies for self-published data. Publication itself acceptable use policies for self-published data. Publication itself
is inferred as a desire by the publisher for the data to be usefully is inferred as a desire by the publisher for the data to be usefully
consumed, similar to the publication of information like host names, consumed, similar to the publication of information like host names,
cryptographic keys, and SPF records [RFC4408] in the DNS. cryptographic keys, and SPF records [RFC4408] in the DNS.
2. Self-published IP geolocation feeds 2. Self-published IP geolocation feeds
The format described here was developed to address the need of The format described here was developed to address the need of
skipping to change at page 4, line 42 skipping to change at page 5, line 14
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 MUST be in comma separated values format as described in
[RFC4180]. Each feed entry is a text line of the form: [RFC4180]. Each feed entry is a text line of the form:
ip_range,country,region,city,postal_code ip_prefix,country,region,city,postal_code
The IP range 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 Range 2.1.1.1. IP Prefix
REQUIRED. Each IP range field MUST be either a single IP address or REQUIRED. Each IP prefix field MUST be either a single IP address or
an IP prefix in CIDR notation in conformance with section 3.1 of an IP prefix in CIDR notation in conformance with section 3.1 [1] of
[RFC4632] for IPv4 or section 2.3 of [RFC4291] for IPv6. [RFC4632] for IPv4 or section 2.3 [2] of [RFC4291] for IPv6.
Examples include "192.0.2.1" and "192.0.2.0/24" for IPv4 and "2001: Examples include "192.0.2.1" and "192.0.2.0/24" for IPv4 and
db8::1" and "2001:db8::/32" for IPv6. "2001:db8::1" and "2001:db8::/32" for IPv6.
2.1.1.2. Country 2.1.1.2. Country
OPTIONAL. The country field, if non-empty, MUST be a 2 letter ISO OPTIONAL. The country field, if non-empty, MUST be a 2 letter ISO
country code conforming to ISO 3166-1 alpha 2 [ISO.3166.1alpha2]. country code conforming to ISO 3166-1 alpha 2 [ISO.3166.1alpha2].
Parsers SHOULD treat this field case-insensitively. Parsers SHOULD treat this field case-insensitively.
Examples include "US" for the United States, "JP" for Japan, and "PL" Examples include "US" for the United States, "JP" for Japan, and "PL"
for Poland. for Poland.
2.1.1.3. Region 2.1.1.3. Region
OPTIONAL. The region field, if non-empty, MUST be a ISO region code OPTIONAL. The region field, if non-empty, MUST be a ISO region code
conforming to ISO 3166-2 [ISO.3166.2]. Parsers SHOULD treat this conforming to ISO 3166-2 [ISO.3166.2]. Parsers SHOULD treat this
field case-insensitively. field case-insensitively.
Examples include "ID-RI" for the Riau province of Indonesia and Examples include "ID-RI" for the Riau province of Indonesia and "NG-
"NG-RI" for the Rivers province in Nigeria. RI" for the Rivers province in Nigeria.
2.1.1.4. City 2.1.1.4. City
OPTIONAL. The city field, if non-empty, SHOULD be free UTF-8 text, OPTIONAL. The city field, if non-empty, SHOULD be free UTF-8 text,
excluding the comma (',') character. excluding the comma (',') character.
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. The postal code field, if non-empty, SHOULD be free UTF-8 OPTIONAL. The postal code field, if non-empty, SHOULD be free UTF-8
text, excluding the comma (',') character. See Section 6 for some text, excluding the comma (',') character. See Section 4 for some
discussion of when this field must not be populated. discussion of when this field must not be populated.
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
skipping to change at page 7, line 24 skipping to change at page 7, line 37
Example entries using different IP address formats and describing Example entries using different IP address formats and describing
locations at country, region, city and postal code granularity level, locations at country, region, city and postal code granularity level,
respectively: respectively:
192.0.2.0/25,US,US-AL,, 192.0.2.0/25,US,US-AL,,
192.0.2.5,US,US-AL,Alabaster, 192.0.2.5,US,US-AL,Alabaster,
192.0.2.128/25,PL,PL-MZ,,02-784 192.0.2.128/25,PL,PL-MZ,,02-784
2001:db8::/32,PL,,, 2001:db8::/32,PL,,,
2001:db8:cafe::/48,PL,PL-MZ,,02-784 2001:db8:cafe::/48,PL,PL-MZ,,02-784
The IETF network publishes geolocation information for the meeting
prefixes, and generally just comment out the last meeting information
and append the new meeting information. The [GEO_IETF] at the time
of this writing contains:
# IETF 104, March 2019 - Prague, CZ.
# Note that Prague changed from CZ-PR to CZ-10 2016-11-15 - https://www.iso.org/obp/ui/#iso:code:3166:CZ
130.129.0.0/16,CZ,CZ-10,Prague,
2001:df8::/32,CZ,CZ-10,Prague,
31.133.128.0/18,CZ,CZ-10,Prague,
31.130.224.0/20,CZ,CZ-10,Prague,
2001:67c:1230::/46,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,IE,IE-D,Dublin, 193.0.24.0/21,IS,IS-1,Reykjavik,
2001:67c:64::/48,IE,IE-D,Dublin, 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,US,US-CA,Los Angeles, 199.91.192.0/21,ES,ES-CT,Barcelona
2620:f:8000::/48,US,US-CA,Los Angeles, 2620:f:8000::/48,ES,ES-CT,Barcelona
A longer example is the [GEO_Google] Google Corp Geofeed, which lists
the geo-location information for Google coroprate 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
skipping to change at page 8, line 45 skipping to change at page 9, line 32
Examples for IPv6 include "/48", "/56", "/60", and "/64". Examples for IPv6 include "/48", "/56", "/60", and "/64".
2.3.2. Alternate format 2.3.2. Alternate format
In order to more flexibly support future extensions, use of a more In order to more flexibly support future extensions, use of a more
expressive feed format has been suggested. Use of JavaScript Object expressive feed format has been suggested. Use of JavaScript Object
Notation (JSON, [RFC4627]), specifically, has been discussed. Notation (JSON, [RFC4627]), specifically, has been discussed.
However, at the time of writing no such specification nor However, at the time of writing no such specification nor
implementation exists. implementation exists.
3. Finding 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
to prefer other sources of geolocation information for any given IP
prefix. Regardless of a consumer's stance with respect to a given
published feed, there are some points of note for sensibly and
effectively consuming published feeds.
3.1. Feed integrity
The integrity of published information SHOULD be protected by
securing the means of publication, for example by using HTTP over TLS
[RFC2818]. Whenever possible, consumers SHOULD prefer retrieving
geolocation feeds in a manner that guarantees integrity of the feed.
3.2. Verification of authority
Consumers of self-published IP geolocation feeds SHOULD perform some
form of verification that the publisher is in fact authoritative for
the addresses in the feed. The actual means of verification is
likely dependent upon the way in which the feed is discovered. Ad
hoc shared URIs, for example, will likely require an ad hoc
verification process. Future automated means of feed discovery
SHOULD have an accompanying automated means of verification.
A consumer MUST only trust geolocation information for IP addresses
or prefixes for which the publisher has been verified as
administratively authoritative. All other geolocation feed entries
MUST be ignored and SHOULD be logged for further administrative
review.
3.3. Verification of accuracy
Errors and inaccuracies may occur at many levels, and publication and
consumption of geolocation data are no exceptions. To the extent
practical consumers SHOULD take steps to verify the accuracy of
published locality. Verification methodology, resolution of
discrepancies, and preference for alternative sources of data are
left to the discretion of the feed consumer.
Consumers SHOULD decide on discrepancy thresholds and SHOULD flag for
administrative review feed entries which exceed set thresholds.
3.4. Refreshing feed information
As a publisher can change geolocation data at any time and without
notification consumers SHOULD implement mechanisms to periodically
refresh local copies of feed data. In the absence of any other
refresh timing information it is recommended that consumers SHOULD
refresh feeds no less often than weekly.
For feeds available via HTTPS (or HTTP), the publisher MAY
communicate refresh timing information by means of the standard HTTP
expiration model (section 13.2 [3] of [RFC2616]). Specifically,
publishers can include either an Expires header [4] or a Cache-
Control header [5] specifying the max-age. Where practical,
consumers SHOULD refresh feed information before the expiry time is
reached.
4. Privacy Considerations
Publishers of geolocation feeds are advised to have fully considered
any and all privacy implications of the disclosure of such
information for the users of the described networks prior to
publication. A thorough comprehension of the security considerations
[6] of a chosen geolocation policy is highly recommended, including
an understanding of some of the limitations of information obscurity
[7] (see also [RFC6772]).
As noted in Section 2.1, each location field in an entry is optional,
in order to support expressing only the level of specificity which
the publisher has deemed acceptable. There is no requirement that
the level of specificity be consistent across all entries within a
feed. In particular, the Postal Code field (Section 2.1.1.5) can
provide very specific geolocation, sometimes within a building. Such
specific Postal Code values MUST NOT be published in geo feeds
without the consent of the parties being located.
5. Relation to other work
While not originally done in conjunction with the [GEOPRIV] working
group, Richard Barnes observed that this work is nevertheless
consistent with that which the group has defined, both for address
format and for privacy. The data elements in geolocation feeds are
equivalent to the following XML structure (vis. [RFC5139]):
<civicAddress>
<country>country</country>
<A1>region</A1>
<A2>city</A2>
<PC>postal_code</PC>
</civicAddress>
Providing geolocation information to this granularity is equivalent
to the following privacy policy (vis. the definition of the
'building' [8] level of disclosure):
<ruleset>
<rule>
<conditions/>
<actions/>
<transformations>
<provide-location profile="civic-transformation">
<provide-civic>building</provide-civic>
</provide-location>
</transformations>
</rule>
</ruleset>
6. Security Considerations
As there is no true security in the obscurity of the location of any
given IP address, self-publication of this data fundamentally opens
no new attack vectors. For publishers, self-published data merely
increases the ease with which such location data might be exploited.
For consumers, feed retrieval processes may receive input from
potentially hostile sources (e.g. in the event of hijacked traffic).
As such, proper input validation and defense measures MUST be taken.
Similarly, consumers who do not perform sufficient verification of
published data bear the same risks as from other forms of geolocation
configuration errors.
7. 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). Regardless, both the ad hoc mechanics and a few proposed but
not yet implemented alternatives are discussed. not yet implemented alternatives are discussed.
3.1. Ad hoc 'well known' URIs 7.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 9, line 29 skipping to change at page 12, line 45
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.
3.2. Using public databases of network authority 7.2. Using public databases of network authority
One possibility for enabling automation would be publication of feed One possibility for enabling automation would be publication of feed
URIs as a well-known attribute in public databases of network URIs as a well-known attribute in public databases of network
authority, e.g. the WHOIS service ([RFC3912]) operated by RIRs. authority, e.g. the WHOIS service ([RFC3912]) operated by RIRs.
Verification may be performed if the same or similarly authoritative Verification may be performed if the same or similarly authoritative
service provides the identical feed URI for queries for each CIDR service provides the identical feed URI for queries for each CIDR
prefix in the geolocation feed. prefix in the geolocation feed.
The burden of serving this data to all interested consumers, The burden of serving this data to all interested consumers,
especially the load imposed by any verification process, is not yet especially the load imposed by any verification process, is not yet
known. The anticipation of additional operational burden on the known. The anticipation of additional operational burden on the
public resource of record (the database of network authority) is public resource of record (the database of network authority) is
however a noted concern. however a noted concern.
3.3. Using 'reverse' DNS with NAPTR records 7.3. Using 'reverse' DNS with NAPTR records
Another possibility for automating the location and verification of a Another possibility for automating the location and verification of a
geolocation feed is to incorporate feed URIs into the DNS, geolocation feed is to incorporate feed URIs into the DNS,
specifically the in-addr.arpa and ip6.arpa portions of the DNS specifically the in-addr.arpa and ip6.arpa portions of the DNS
hierarchy. A suitably formatted query for a NAPTR ([RFC3403]) hierarchy. A suitably formatted query for a NAPTR ([RFC3403])
record, or more specifically a U-NAPTR ([RFC4848]) record, could record, or more specifically a U-NAPTR ([RFC4848]) record, could
yield a transformation to a geolocation feed URI. yield a transformation to a geolocation feed URI.
For example, assuming a purely theoretical service name of For example, assuming a purely theoretical service name of
"x-geofeed", a 'reverse' DNS zone might contain a record of the form: "x-geofeed", a 'reverse' DNS zone might contain a record of the form:
skipping to change at page 11, line 5 skipping to change at page 14, line 21
operational purposes, especially if a low-impact on-going operational purposes, especially if a low-impact on-going
verification of observed client IP addresses is implemented, to verification of observed client IP addresses is implemented, to
(eventually) catch any oversights. (eventually) catch any oversights.
This mode is untested and may prove impractical. However, the This mode is untested and may prove impractical. However, the
operational burden is more closely located with those wishing and operational burden is more closely located with those wishing and
willing to bear it, i.e. the publishers who would likely handle willing to bear it, i.e. the publishers who would likely handle
serving in-addr.arpa and ip6.arpa for the IP prefixes under their serving in-addr.arpa and ip6.arpa for the IP prefixes under their
authority. authority.
4. Consuming self-published IP geolocation feeds
Consumers MAY treat published feed data as a hint only and MAY choose
to prefer other sources of geolocation information for any given IP
range. Regardless of a consumer's stance with respect to a given
published feed, there are some points of note for sensibly and
effectively consuming published feeds.
4.1. Feed integrity
The integrity of published information SHOULD be protected by
securing the means of publication, for example by using HTTP over TLS
[RFC2818]. Whenever possible, consumers SHOULD prefer retrieving
geolocation feeds in a manner that guarantees integrity of the feed.
4.2. Verification of authority
Consumers of self-published IP geolocation feeds SHOULD perform some
form of verification that the publisher is in fact authoritative for
the addresses in the feed. The actual means of verification is
likely dependent upon the way in which the feed is discovered. Ad
hoc shared URIs, for example, will likely require an ad hoc
verification process. Future automated means of feed discovery
SHOULD have an accompanying automated means of verification.
A consumer MUST only trust geolocation information for IP addresses
or ranges for which the publisher has been verified as
administratively authoritative. All other geolocation feed entries
MUST be ignored and SHOULD be logged for further administrative
review.
4.3. Verification of accuracy
Errors and inaccuracies may occur at many levels, and publication and
consumption of geolocation data are no exceptions. To the extent
practical consumers SHOULD take steps to verify the accuracy of
published locality. Verification methodology, resolution of
discrepancies, and preference for alternative sources of data are
left to the discretion of the feed consumer.
Consumers SHOULD decide on discrepancy thresholds and SHOULD flag for
administrative review feed entries which exceed set thresholds.
4.4. Refreshing feed information
As a publisher can change geolocation data at any time and without
notification consumers SHOULD implement mechanisms to periodically
refresh local copies of feed data. In the absence of any other
refresh timing information it is recommended that consumers SHOULD
refresh feeds no less often than weekly.
For feeds available via HTTPS (or HTTP), the publisher MAY
communicate refresh timing information by means of the standard HTTP
expiration model (section 13.2 of [RFC2616]). Specifically,
publishers can include either an Expires header or a Cache-Control
header specifying the max-age. Where practical, consumers SHOULD
refresh feed information before the expiry time is reached.
5. Security Considerations
As there is no true security in the obscurity of the location of any
given IP address, self-publication of this data fundamentally opens
no new attack vectors. For publishers, self-published data merely
increases the ease with which such location data might be exploited.
For consumers, feed retrieval processes may receive input from
potentially hostile sources (e.g. in the event of hijacked traffic).
As such, proper input validation and defense measures MUST be taken.
Similarly, consumers who do not perform sufficient verification of
published data bear the same risks as from other forms of geolocation
configuration errors.
6. Privacy Considerations
Publishers of geolocation feeds are advised to have fully considered
any and all privacy implications of the disclosure of such
information for the users of the described networks prior to
publication. A thorough comprehension of the security considerations
of a chosen geolocation policy is highly recommended, including an
understanding of some of the limitations of information obscurity
(see also [RFC6772]).
As noted in Section 2.1, each location field in an entry is optional,
in order to support expressing only the level of specificity which
the publisher has deemed acceptable. There is no requirement that
the level of specificity be consistent across all entries within a
feed. In particular, the Postal Code field (Section 2.1.1.5) can
provide very specific geolocation, sometimes within a building. Such
specific Postal Code values MUST NOT be published in geo feeds
without the consent of the parties being located.
7. Relation to other work
While not originally done in conjunction with the [GEOPRIV] working
group, Richard Barnes observed that this work is nevertheless
consistent with that which the group has defined, both for address
format and for privacy. The data elements in geolocation feeds are
equivalent to the following XML structure (vis. [RFC5139]):
<civicAddress>
<country>country</country>
<A1>region</A1>
<A2>city</A2>
<PC>postal_code</PC>
</civicAddress>
Providing geolocation information to this granularity is equivalent
to the following privacy policy (vis. the definition of the
'building' level of disclosure):
<ruleset>
<rule>
<conditions/>
<actions/>
<transformations>
<provide-location profile="civic-transformation">
<provide-civic>building</provide-civic>
</provide-location>
</transformations>
</rule>
</ruleset>
8. Acknowledgements 8. 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, Warren Kumari, Menno Schepers, Justyna Sidorska, Pim van Mike Joseph, Warren Kumari, Menno Schepers, Justyna Sidorska, Pim van
Pelt, and Bjoern A. Zeeb. Richard L. Barnes in particular Pelt, and Bjoern A. Zeeb. Richard L. Barnes in particular
contributed substantial review, text, and advice. contributed substantial review, text, and advice.
9. References 9. References
9.1. Normative References 9.1. Normative References
[ISO.3166.1alpha2] [ISO.3166.1alpha2]
International Organization for Standardization, "ISO International Organization for Standardization, "ISO
3166-1 decoding table", <http://www.iso.org/iso/home/ 3166-1 decoding table",
standards/country_codes/iso-3166-1_decoding_table.htm>. <http://www.iso.org/iso/home/standards/country_codes/
iso-3166-1_decoding_table.htm>.
[ISO.3166.2] [ISO.3166.2]
International Organization for Standardization, "ISO 3166- International Organization for Standardization, "ISO
2:2007", <http://www.iso.org/iso/home/standards/ 3166-2:2007", <http://www.iso.org/iso/home/standards/
country_codes.htm#2012_iso3166-2>. country_codes.htm#2012_iso3166-2>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616,
DOI 10.17487/RFC2616, June 1999,
<https://www.rfc-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, November 2003. 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma- [RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma-
Separated Values (CSV) Files", RFC 4180, October 2005. 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, February 2006. Architecture", RFC 4291, DOI 10.17487/RFC4291, February
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, August 2006. Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
2006, <https://www.rfc-editor.org/info/rfc4632>.
9.2. Informative References 9.2. Informative References
[GEOPRIV] Internet Engineering Task Force, "IETF geopriv Working [GEO_Google]
Group", <http://datatracker.ietf.org/wg/geopriv/>. Google, LLC, "Google Corp Geofeed",
<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>.
[GEO_IETF]
Kumari, A., "IETF Meeting Network Geolocation Data",
<https://noc.ietf.org/geo/google.csv>.
[GEO_RIPE_NCC] [GEO_RIPE_NCC]
Schepers, M., "RIPE NCC Meeting Geolocation Data", Schepers, M., "RIPE NCC Meeting Geolocation Data",
<https://meetings.ripe.net/geo/google.csv>. <https://meetings.ripe.net/geo/google.csv>.
[GEO_SIXXS] [GEO_SIXXS]
van Pelt, P., "SixXS Geolocation Data", van Pelt, P., "SixXS Geolocation Data",
<https://www.sixxs.net/export/google/>. <https://www.sixxs.net/export/google/>.
[GEOPRIV] Internet Engineering Task Force, "IETF geopriv Working
Group", <http://datatracker.ietf.org/wg/geopriv/>.
[IPADDR_PY] [IPADDR_PY]
Shields, M. and P. Moody, "Python IP address manipulation Shields, M. and P. Moody, "Python IP address manipulation
library", <http://code.google.com/p/ipaddr-py/>. library", <http://code.google.com/p/ipaddr-py/>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-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, January 2001. Tunnel Broker", RFC 3053, DOI 10.17487/RFC3053, January
2001, <https://www.rfc-editor.org/info/rfc3053>.
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database", Part Three: The Domain Name System (DNS) Database",
RFC 3403, October 2002. 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,
September 2004. DOI 10.17487/RFC3912, September 2004,
<https://www.rfc-editor.org/info/rfc3912>.
[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, April 2006. RFC 4408, DOI 10.17487/RFC4408, April 2006,
<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, July 2006. JavaScript Object Notation (JSON)", RFC 4627,
DOI 10.17487/RFC4627, July 2006,
<https://www.rfc-editor.org/info/rfc4627>.
[RFC4848] Daigle, L., "Domain-Based Application Service Location [RFC4848] Daigle, L., "Domain-Based Application Service Location
Using URIs and the Dynamic Delegation Discovery Service Using URIs and the Dynamic Delegation Discovery Service
(DDDS)", RFC 4848, April 2007. (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, February 2008. Object (PIDF-LO)", RFC 5139, DOI 10.17487/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, August 2010. Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010,
<https://www.rfc-editor.org/info/rfc5952>.
[RFC6772] Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J., [RFC6772] Schulzrinne, H., Ed., Tschofenig, H., Ed., Cuellar, J.,
Morris, J., and M. Thomson, "Geolocation Policy: A Polk, J., Morris, J., and M. Thomson, "Geolocation Policy:
Document Format for Expressing Privacy Preferences for A Document Format for Expressing Privacy Preferences for
Location Information", RFC 6772, January 2013. Location Information", RFC 6772, DOI 10.17487/RFC6772,
January 2013, <https://www.rfc-editor.org/info/rfc6772>.
9.3. URIs
[1] http://tools.ietf.org/html/rfc4632#section-3.1
[2] http://tools.ietf.org/html/rfc4291#section-2.3
[3] http://tools.ietf.org/html/rfc2616#section-13.2
[4] http://tools.ietf.org/html/rfc2616#section-14.21
[5] http://tools.ietf.org/html/rfc2616#section-14.9
[6] http://tools.ietf.org/html/rfc6772#section-13
[7] http://tools.ietf.org/html/rfc6772#section-13.5
[8] http://tools.ietf.org/html/rfc6772#section-6.5.1
Appendix A. Sample Python validation code Appendix A. Sample Python validation code
Included here is a simple format validator in Python for self- Included here is a simple format validator in Python for self-
published ipgeo feeds. This tool reads CSV data in the self- published ipgeo feeds. This tool reads CSV data in the self-
published ipgeo feed format from the standard input and performs published ipgeo feed format from the standard input and performs
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
skipping to change at page 16, line 23 skipping to change at page 18, line 4
# 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.
This tool reads CSV data in the self-published ipgeo feed format from This tool reads CSV data in the self-published ipgeo feed format from
the standard input and performs basic validation. It is intended for the standard input and performs basic validation. It is intended for
use by feed publishers before launching a feed. use by feed publishers before launching a feed.
""" """
import csv import csv
import ipaddr import ipaddr
import re import re
import sys import sys
class IPGeoFeedValidator(object): class IPGeoFeedValidator(object):
def __init__(self): def __init__(self):
self.ranges = {} self.prefixes = {}
self.line_number = 0 self.line_number = 0
self.output_log = {} self.output_log = {}
self.SetOutputStream(sys.stderr) self.SetOutputStream(sys.stderr)
def Validate(self, feed): def Validate(self, feed):
"""Check validity of an IPGeo feed. """Check validity of an IPGeo feed.
Args: Args:
feed: iterable with feed lines feed: iterable with feed lines
""" """
skipping to change at page 17, line 20 skipping to change at page 18, line 47
self.output_stream = logfile self.output_stream = logfile
def CountErrors(self, severity): def CountErrors(self, severity):
"""How many ERRORs or WARNINGs were generated.""" """How many ERRORs or WARNINGs were generated."""
return len(self.output_log.get(severity, [])) return len(self.output_log.get(severity, []))
############################################################ ############################################################
def _ValidateLine(self, line): def _ValidateLine(self, line):
line = line.rstrip('\r\n') line = line.rstrip('\r\n')
self.line_number += 1 self.line_number += 1
self.line = line self.line = line.split('#')[0]
self.is_correct_line = True self.is_correct_line = True
if self._ShouldIgnoreLine(line): if self._ShouldIgnoreLine(line):
return return
fields = [field for field in csv.reader([line])][0] fields = [field for field in csv.reader([line])][0]
self._ValidateFields(fields) self._ValidateFields(fields)
self._FlushOutputStream() self._FlushOutputStream()
def _ShouldIgnoreLine(self, line): def _ShouldIgnoreLine(self, line):
line = line.strip() line = line.strip()
return len(line) == 0 or line.startswith('#') return len(line) == 0
############################################################ ############################################################
def _ValidateFields(self, fields): def _ValidateFields(self, fields):
assert(len(fields) > 0) assert(len(fields) > 0)
is_correct = self._IsIPAddressOrRangeCorrect(fields[0]) is_correct = self._IsIPAddressOrPrefixCorrect(fields[0])
if len(fields) > 1: if len(fields) > 1:
if not self._IsCountryCode2Correct(fields[1]): if not self._IsCountryCode2Correct(fields[1]):
is_correct = False is_correct = False
if len(fields) > 2 and not self._IsRegionCodeCorrect(fields[2]): if len(fields) > 2 and not self._IsRegionCodeCorrect(fields[2]):
is_correct = False is_correct = False
if len(fields) != 5: if len(fields) != 5:
self._ReportWarning('5 fields were expected (got %d).' self._ReportWarning('5 fields were expected (got %d).'
% len(fields)) % len(fields))
############################################################ ############################################################
def _IsIPAddressOrRangeCorrect(self, field): def _IsIPAddressOrPrefixCorrect(self, field):
if '/' in field: if '/' in field:
return self._IsCIDRCorrect(field) return self._IsCIDRCorrect(field)
return self._IsIPAddressCorrect(field) return self._IsIPAddressCorrect(field)
def _IsCIDRCorrect(self, cidr): def _IsCIDRCorrect(self, cidr):
try: try:
iprange = ipaddr.IPNetwork(cidr) ipprefix = ipaddr.IPNetwork(cidr)
if iprange.network._ip != iprange._ip: if ipprefix.network._ip != ipprefix._ip:
self._ReportError('Incorrect IP Network.') self._ReportError('Incorrect IP Network.')
return False return False
if iprange.is_private: if ipprefix.is_private:
self._ReportError('IP Address must not be private.') self._ReportError('IP Address must not be private.')
return False return False
except: except:
self._ReportError('Incorrect IP Network.') self._ReportError('Incorrect IP Network.')
return False return False
return True return True
def _IsIPAddressCorrect(self, ipaddress): def _IsIPAddressCorrect(self, ipaddress):
try: try:
ip = ipaddr.IPAddress(ipaddress) ip = ipaddr.IPAddress(ipaddress)
except: except:
self._ReportError('Incorrect IP Address.') self._ReportError('Incorrect IP Address.')
return False return False
if ip.is_private: if ip.is_private:
self._ReportError('IP Address must not be private.') self._ReportError('IP Address must not be private.')
return False return False
return True return True
############################################################ ############################################################
skipping to change at page 21, line 26 skipping to change at page 23, line 4
self.TestFeedLine('192.168.100.1,US,,,', 1, 0) self.TestFeedLine('192.168.100.1,US,,,', 1, 0)
self.TestFeedLine('10.0.5.9,US,,,', 1, 0) self.TestFeedLine('10.0.5.9,US,,,', 1, 0)
self.TestFeedLine('10.0.5.0/24,US,,,', 1, 0) self.TestFeedLine('10.0.5.0/24,US,,,', 1, 0)
self.TestFeedLine('fc00::/48,PL,,,', 1, 0) self.TestFeedLine('fc00::/48,PL,,,', 1, 0)
self.TestFeedLine('fe00::/48,PL,,,', 0, 0) self.TestFeedLine('fe00::/48,PL,,,', 0, 0)
print '%d tests passed, %d failed' % (self.successes, self.failures) print '%d tests passed, %d failed' % (self.successes, self.failures)
def IsOutputLogCorrectAtSeverity(self, severity, expected_msg_count): def IsOutputLogCorrectAtSeverity(self, severity, expected_msg_count):
msg_count = self.validator.CountErrors(severity) msg_count = self.validator.CountErrors(severity)
if msg_count != expected_msg_count: if msg_count != expected_msg_count:
print 'TEST FAILED: %s\nexpected %d %s[s], observed %d\n%s\n' % ( print 'TEST FAILED: %s\nexpected %d %s[s], observed %d\n%s\n' % (
self.validator.line, expected_sg_count, severity, msg_count, self.validator.line, expected_msg_count, severity, msg_count,
str(self.validator.output_log[severity])) str(self.validator.output_log[severity]))
return False return False
return True return True
def IsOutputLogCorrect(self, new_errors, new_warnings): def IsOutputLogCorrect(self, new_errors, new_warnings):
retval = True retval = True
if not self.IsOutputLogCorrectAtSeverity('ERROR', new_errors): if not self.IsOutputLogCorrectAtSeverity('ERROR', new_errors):
retval = False retval = False
if not self.IsOutputLogCorrectAtSeverity('WARNING', new_warnings): if not self.IsOutputLogCorrectAtSeverity('WARNING', new_warnings):
 End of changes. 63 change blocks. 
239 lines changed or deleted 324 lines changed or added

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