draft-ietf-grow-geomrt-07.txt		rfc6397.txt
	Global Routing Operations Working Group T. Manderson		Internet Engineering Task Force (IETF) T. Manderson
	Internet-Draft ICANN		Request for Comments: 6397 ICANN
	Intended status: Standards Track August 26, 2011		Category: Standards Track October 2011
	Expires: February 27, 2012		ISSN: 2070-1721
	Multi-threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP)		Multi-Threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP)
	routing information export format with geo-location extensions		Routing Information Export Format with Geo-Location Extensions
	draft-ietf-grow-geomrt-07.txt
	Abstract		Abstract
	This document updates the Multi-threaded Routing Toolkit (MRT) export		This document updates the Multi-threaded Routing Toolkit (MRT) export
	format for Border Gateway Protocol (BGP) routing information by		format for Border Gateway Protocol (BGP) routing information by
	extending it to include optional terrestrial coordinates of a BGP		extending it to include optional terrestrial coordinates of a BGP
	Collector and its BGP Peers.		collector and its BGP peers.
	Status of this Memo
	This Internet-Draft is submitted in full conformance with the		Status of This Memo
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		This is an Internet Standards Track document.
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 5741.
	This Internet-Draft will expire on February 27, 2012.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			http://www.rfc-editor.org/info/rfc6397.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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
	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. Requirements notation . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 2
	3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Geo-location aware MRT Routing Information Subtype . . . . . . 6		4. Geo-Location-Aware MRT Routing Information Subtype . . . . . . 3
	4.1. GEO_PEER_TABLE . . . . . . . . . . . . . . . . . . . . . . 6		4.1. GEO_PEER_TABLE . . . . . . . . . . . . . . . . . . . . . . 3
	4.2. GEO_PEER_TABLE and peer entry values. . . . . . . . . . . 7		4.2. GEO_PEER_TABLE and Peer Entry Values . . . . . . . . . . . 5
	5. BGP Collector Construction . . . . . . . . . . . . . . . . . . 9		5. BGP Collector Construction . . . . . . . . . . . . . . . . . . 5
	6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 10		6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 6
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 13		9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 14		10.1. Normative References . . . . . . . . . . . . . . . . . . . 7
	10.2. Informative References . . . . . . . . . . . . . . . . . . 14		10.2. Informative References . . . . . . . . . . . . . . . . . . 8
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Requirements notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].
	2. Introduction		1. Introduction
	Researchers and engineers often wish to analyze network behavior by		Researchers and engineers often wish to analyze network behavior by
	studying routing protocol transactions and routing information base		studying routing protocol transactions and routing information base
	snapshots in relation to geographical topologies. Usually the Border		snapshots in relation to geographical topologies. Usually, the
	Gateway Protocol [RFC4271] is the subject of study and the analysis		Border Gateway Protocol [RFC4271] is the subject of study, and the
	can be significantly aided by the availability and extension of the		analysis can be significantly aided by the availability and extension
	"Multi-threaded Routing Toolkit (MRT) format" [I-D.ietf-grow-mrt].		of the "Multi-Threaded Routing Toolkit (MRT) Routing Information
	The MRT format was originally defined in the Multi-threaded Routing		Export Format" [RFC6396]. The MRT format was originally defined in
	Toolkit Programmer's Guide [MRT-GUIDE].		the MRT Programmer's Guide [MRT-GUIDE].
	The addition of geo-location coordinates (longitude and latitude)		The addition of geo-location coordinates (longitude and latitude)
	pertaining to the geographical location of both the BGP collector and		pertaining to the geographical location of both the BGP collector and
	its BGP peers to BGP export data enables a researcher or enquiring		its BGP peers to BGP export data enables a researcher or enquiring
	individual to gain a tererestrial insight to the routes seen by a BGP		individual to gain a terrestrial insight to the routes seen by a BGP
	speaker. Such data may ultimately aid reserachers in understanding		speaker. Such data may ultimately aid researchers in understanding
	any disparity between the geographical location of networks and the		any disparity between the geographical location of networks and the
	topological location of networks in addition to the relationships		topological location of networks in addition to the relationships
	between geographical position and routing anomolies. Such insight		between geographical position and routing anomalies. Such insight
	could provide future input into network design or network security.		could provide future input into network design and network security.
	This memo documents an optional extension to the "MRT format"		This memo documents an optional extension to the MRT format [RFC6396]
	[I-D.ietf-grow-mrt] and introduces an additional definition of a MRT		and introduces an additional definition of an MRT Subtype field that
	subtype field that includes the terestrial coordinates of a BGP		includes the terrestrial coordinates of a BGP collector and its BGP
	Collector and its BGP Peers.		peers.
			2. Requirements Notation
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in [RFC2119].
	3. Definitions		3. Definitions
	Coordinates: A set of geographic latitude and longitude specifying a		Coordinates: The geographic latitude and longitude specifying a
	location on the Earth.		location on the earth.
	BGP Speaker: A network device which exchanges network routing		BGP Speaker: A network device that exchanges network routing
	information using BGP.		information using BGP.
	Geo-location: Assigning a set of coordinates to a specific artifact,		Geo-location: Assigning a set of coordinates to a specific artifact,
	in this case a BGP speaker.		in this case a BGP speaker.
	BGP Collector: A BGP speaker (usually passive) that stores and		BGP Collector: A BGP speaker (usually passive) that stores and
	archives BGP routing data from active BGP peers for analysis.		archives BGP routing data from active BGP peers for analysis.
	BGP Peer: Either an internal or external BGP peer [RFC4271].		BGP Peer: Either an internal or external BGP peer [RFC4271].
	Not A Number (NAN): numeric data type representing an undefined or		Not A Number (NAN): Numeric data type representing an undefined or
	unrepresentable value. As defined in IEEE Standard for Floating-		unrepresentable value, as defined in the IEEE Standard for Floating-
	Point Arithmetic [IEEE754].		Point Arithmetic [IEEE754].
	4. Geo-location aware MRT Routing Information Subtype		4. Geo-Location-Aware MRT Routing Information Subtype
	An additional subtype (GEO_PEER_TABLE) is defined for the		An additional subtype (GEO_PEER_TABLE) is defined for the
	TABLE_DUMP_v2 format, extending TABLE_DUMP_V2 Type.		TABLE_DUMP_V2 format, extending TABLE_DUMP_V2 Type.
	4.1. GEO_PEER_TABLE		4.1. GEO_PEER_TABLE
	The GEO_PEER_TABLE Subtype updates the TABLE_DUMP_v2 Types to include		The GEO_PEER_TABLE Subtype updates the TABLE_DUMP_V2 Types to include
	Geo-location information in the form of WGS84 [WGS-84] formatted		geo-location information in the form of the World Geodetic System
	coordinates.		1984 (WGS84) [WGS-84] formatted coordinates.
	The document adds the 7th subtype number and name below. The first 6		The document adds the 7th subtype number and name below. The first 6
	subtypes are defined by the "MRT format" [I-D.ietf-grow-mrt].		subtypes are defined by the MRT format [RFC6396].
	Subtype Number Subtype Name		Subtype Number Subtype Name
	----------------------------------		----------------------------------
	7 GEO_PEER_TABLE		7 GEO_PEER_TABLE
	The GEO_PEER_TABLE MRT record provides the BGP ID of the collector,		The GEO_PEER_TABLE MRT record provides the BGP ID of the collector,
	its latitude and longitude in WGS84 [WGS-84] format, and a list of		its latitude and longitude in WGS84 [WGS-84] format, and a list of
	indexed peers and their respective latitudes and longitudes in WGS84		indexed peers and their respective latitudes and longitudes in WGS84
	[WGS-84] format.		[WGS-84] format.
	The format and function of the Collector BGP ID, Peer Count are as		The format and function of the Collector BGP ID and Peer Count are as
	defined by the TABLE_DUMP_V2 PEER_INDEX_TABLE format.		defined by the TABLE_DUMP_V2, PEER_INDEX_TABLE format [RFC6396].
	[I-D.ietf-grow-mrt].
	The Collector Latitude and Collector Longitude are the geographical		The Collector Latitude and Collector Longitude are the geographical
	coordinates of the collector in WGS84 [WGS-84] datum decimal degrees		coordinates of the collector in WGS84 [WGS-84] datum decimal degrees
	format stored as a single precision float in the 32 bits allocated to		format stored as a single precision float in the 32 bits allocated to
	the Collector Latitude and Collector Longitude. The latitude and		the Collector Latitude and Collector Longitude. The latitude and
	longitude MAY be a Not A Number (NAN) [IEEE754] for situations where		longitude MAY be a Not A Number (NAN) [IEEE754] for situations where
	the geo-location of the collector is considered private. The		the geo-location of the collector is considered private. The
	Collector Latitude and Collector Longitude MUST NOT be a mix of WGS84		Collector Latitude and Collector Longitude MUST NOT be a mix of WGS84
	[WGS-84] datum coordinate and NAN values.		[WGS-84] datum coordinates and NAN values.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Collector BGP ID |		| Collector BGP ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Collector Latitude |		| Collector Latitude |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Collector Longitude |		| Collector Longitude |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Peer Count | Peer entries (variable)		| Peer Count | Peer Entries (variable)
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Format of the GEO_PEER_TABLE		Format of the GEO_PEER_TABLE
	The format of the peer entries is shown below. The Peer Type and the		The format of the Peer Entries is shown below. The Peer Type and the
	Peer BGP ID is as defined in the TABLE_DUMP_V2 MRT		Peer BGP ID are as defined in the TABLE_DUMP_V2 MRT, PEER_INDEX_TABLE
	[I-D.ietf-grow-mrt] PEER_INDEX_TABLE format. The order of the Peer		format [RFC6396]. The order of the Peer Entries in the
	entries in GEO_PEER_TABLE MUST match the order and number as existing		GEO_PEER_TABLE MUST match the order and number as existing in the
	in the PEER_INDEX_TABLE.		PEER_INDEX_TABLE.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Peer Type |		| Peer Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Peer BGP ID |		| Peer BGP ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Peer Latitude |		| Peer Latitude |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Peer Longitude |		| Peer Longitude |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Format of peer entries		Format of Peer Entries
	The Peer Latitude and Peer Longitude are the geographical coordinates		The Peer Latitude and Peer Longitude are the geographical coordinates
	of the peer in WGS84 [WGS-84] datum decimal degrees format stored as		of the peer in WGS84 [WGS-84] datum decimal degrees format stored as
	a single precision float in the 32 bits allocated to the Peer		a single precision float in the 32 bits allocated to the Peer
	Latitude and Peer Longitude. The latitude and longitude MAY be a Not		Latitude and Peer Longitude. The latitude and longitude MAY be a Not
	A Number (NAN) [IEEE754] for situations where the geo-location of the		A Number (NAN) [IEEE754] for situations where the geo-location of the
	peer is considered private. The Peer Latitude and Peer Longitude		peer is considered private. The Peer Latitude and Peer Longitude
	MUST NOT be a mix of WGS84 [WGS-84] datum coordinate and NAN values		MUST NOT be a mix of WGS84 [WGS-84] datum coordinates and NAN values
	for a single Peer.		for a single peer.
	4.2. GEO_PEER_TABLE and peer entry values.		4.2. GEO_PEER_TABLE and Peer Entry Values
	Collector BGP ID: Defined in the MRT format [I-D.ietf-grow-mrt]		Collector BGP ID: Defined in the MRT format [RFC6396].
	Collector Latitude: Geographic latitude of the BGP collector in WGS84		Collector Latitude: Geographic latitude of the BGP collector in WGS84
	[WGS-84] datum decimal degrees format stored as a single precision		[WGS-84] datum decimal degrees format stored as a single precision
	float.		float.
	Collector Longitude: Geographic Longitude of the BGP collector in		Collector Longitude: Geographic longitude of the BGP collector in
	WGS84 [WGS-84] datum decimal degrees format stored as a single		WGS84 [WGS-84] datum decimal degrees format stored as a single
	precision float.		precision float.
	Peer Count: Defined in the MRT format [I-D.ietf-grow-mrt]		Peer Count: Defined in the MRT format [RFC6396].
	Peer entries: Defined in the MRT format [I-D.ietf-grow-mrt]		Peer Entries: Defined in the MRT format [RFC6396].
	Peer Type: Defined in the MRT format [I-D.ietf-grow-mrt]
	Peer BGP ID: Defined in the MRT format [I-D.ietf-grow-mrt]		Peer Type: Defined in the MRT format [RFC6396].
			Peer BGP ID: Defined in the MRT format [RFC6396].
	Peer Latitude: Geographic latitude of the BGP peer in WGS84 [WGS-84]		Peer Latitude: Geographic latitude of the BGP peer in WGS84 [WGS-84]
	datum decimal degrees format stored as a single precision float.		datum decimal degrees format stored as a single precision float.
	Peer Longitude: Geographic Longitude of the BGP peer in WGS84		Peer Longitude: Geographic longitude of the BGP peer in WGS84
	[WGS-84] datum decimal degrees format stored as a single precision		[WGS-84] datum decimal degrees format stored as a single precision
	float.		float.
	5. BGP Collector Construction		5. BGP Collector Construction
	This section is to aid the reader in understanding the function of a		This section aids the reader in understanding the function of a BGP
	BGP collector.		collector.
	The BGP Collector is a device (hardware or software based) which		The BGP collector is a hardware- or software-based device that speaks
	speaks the Border Gateway Protocol and its intended function is to		the Border Gateway Protocol. Its intended function is to store (and
	store (and archive) the BGP routing data it receives from other BGP		archive) the BGP routing data it receives from other BGP speakers
	speakers it has peering relationships with, providing data for later		with which it has peering relationships, providing data for later
	analysis. The general nature of a BGP Collector is that it is a		analysis. The general nature of a BGP collector is that it is a
	passive device in that it listens to route updates, and does not		passive device in that it listens to route updates and does not
	announce nor propagate any information it knows or receives. It		announce or propagate any information it knows or receives. It
	should be noted that this is not always the case, network operators		should be noted that this is not always the case; network operators
	sometimes enable the collection of BGP routing data on active BGP		sometimes enable the collection of BGP routing data on active BGP
	speakers to obtain a situational view of the routing system as they		speakers to obtain a situational view of the routing system as they
	see it at a particular point in time.		see it at a particular point in time.
	As a fully fledged BGP speaker the BGP Collector can fit into any BGP		As a fully fledged BGP speaker, the BGP collector can fit into any
	topology including iBGP, eBGP, and so on. The implementation of a		BGP topology including Internal BGP (iBGP), External BGP (eBGP), and
	BGP collector in a network topology is therefore limited by that		so on. The implementation of a BGP collector in a network topology
	network's use of BGP.		is therefore limited by that network's use of BGP.
	6. Privacy Considerations		6. Privacy Considerations
	The GEOPRIV [RFC6280] architecture requires that privacy rules		The GEOPRIV [RFC6280] architecture requires that privacy rules
	attached to a location object be transmitted alongside the location		attached to a location object be transmitted alongside the location
	information in the object. If a BGP Collector adds location		information in the object. If a BGP collector adds location
	coordinates to an MRT record based on GEOPRIV location objects, then		coordinates to an MRT record based on GEOPRIV location objects, then
	it would have to include privacy rules as well. Since the MRT geo-		it would have to include privacy rules as well. Since the MRT geo-
	location format does not support the provision of privacy rules, each		location format does not support the provision of privacy rules, each
	location entry in an MRT object is assigned the following default		location entry in an MRT object is assigned the following default
	privacy rules [RFC4119]:		privacy rules [RFC4119]:
	-- retransmission-allowed: True		-- retransmission-allowed: True
	-- retention-expires: 100 years from timestamp of the MRT object		-- retention-expires: 100 years from timestamp of the MRT object
	-- ruleset-reference: Empty		-- ruleset-reference: Empty
	-- note-well: Empty		-- note-well: Empty
	Location information derived from a location object with more		Location information derived from a location object with more
	restrictive privacy rules MUST NOT be included in a MRT geo-location		restrictive privacy rules MUST NOT be included in an MRT geo-location
	record unless there are non-technical measures in place that enforce		record unless there are non-technical measures in place that enforce
	and communicate the constraints on the use of the location		and communicate the constraints on the use of the location
	information in the MRT geo-location format (e.g., contractual		information in the MRT geo-location format (e.g., contractual
	agreements between peers).		agreements between peers).
	7. Acknowledgements		7. Acknowledgements
	Thanks to Andrew Clark, Ernest Foo, Dave Meyer, Larry Bluck, Richard		Thanks to Andrew Clark, Ernest Foo, Dave Meyer, Larry Blunk, Richard
	Barnes, and Jeffrey Haas for reviewing this document.		Barnes, and Jeffrey Haas for reviewing this document.
	This document describes a small portion of the research towards the		This document describes a small portion of the research towards the
	author's Ph.D.		author's Ph.D.
	8. IANA Considerations		8. IANA Considerations
	This section requests the Internet Assigned Numbers Authority (IANA)		Per this section, the Internet Assigned Numbers Authority (IANA) has
	register the additional Subtype code value as:		registered the additional Subtype code value as:
	7 GEO_PEER_TABLE		7 GEO_PEER_TABLE
	in the "MRT format" [I-D.ietf-grow-mrt] and Subtype code values		in the MRT format [RFC6396] and Subtype code values related to the
	related to the TABLE_DUMP_v2 type in the MRT namespace.		TABLE_DUMP_V2 Type in the MRT namespace.
	9. Security Considerations		9. Security Considerations
	This extension to the "MRT format" [I-D.ietf-grow-mrt] defines fields		This extension to the MRT format [RFC6396] defines fields that are of
	that are of a descriptive nature and provide information that is		a descriptive nature and provides information that is useful in the
	useful in the analysis of routing systems. As such, the author		analysis of routing systems. As such, the author believes that they
	believes that they do not constitute an additional network based		do not constitute an additional network-based security risk. It is
	security risk. It is recommended that the operators of the BGP		recommended that the operators of the BGP collector and BGP peers
	collector and BGP peers consider their own privacy and security		consider their own privacy and security concerns before supplying
	concerns before supplying geographical coordinates to BGP data		geographical coordinates to BGP data collection systems. Special
	collection systems. Special attention should be given to the		attention should be given to the physical security of an organization
	physical security of an organisation before supplying geographical		before supplying geographical coordinates, especially if the
	coordinates, especially if the resulting BGP data with geo-location		resulting BGP data with geo-location extensions is made public.
	extensions is made public.
	Entities that operate BGP Collectors, and users of data provided by		Entities that operate BGP collectors, and users of data provided by
	BGP Collectors, should be aware that the geolocation data supplied by		BGP collectors, should be aware that the geo-location data supplied
	a peer can only be taken at face value. It is possible that a BGP		by a peer can only be taken at face value. It is possible that a BGP
	peer may supply coordinates that is purposefully misleading or		peer may supply coordinates that are purposefully misleading or
	inaccurate. It is therefore up to the BGP Collector to include this		inaccurate. It is therefore up to the BGP collector whether or not
	information or not, or use its own methods to either trust or		to include this information or use its own methods to either trust or
	validate the data provided. It is not recommended that a BGP		validate the data provided. It is not recommended that a BGP
	Collector use geographical coordinates not supplied by a BGP peer.		collector use geographical coordinates not supplied by a BGP peer.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[I-D.ietf-grow-mrt]		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Blunk, L., Karir, M., and C. Labovitz, "MRT routing		Requirement Levels", BCP 14, RFC 2119, March 1997.
	information export format", draft-ietf-grow-mrt-17 (work
	in progress), August 2011.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Format", RFC 4119, December 2005.
	[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object		[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
	Format", RFC 4119, December 2005.		Protocol 4 (BGP-4)", RFC 4271, January 2006.
	[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway		[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
	Protocol 4 (BGP-4)", RFC 4271, January 2006.		Tschofenig, H., and H. Schulzrinne, "An Architecture for
			Location and Location Privacy in Internet Applications",
			BCP 160, RFC 6280, July 2011.
	[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J.,		[RFC6396] Blunk, L., Karir, M., and C. Labovitz, "Multi-Threaded
	Tschofenig, H., and H. Schulzrinne, "An Architecture for		Routing Toolkit (MRT) Routing Information Export
	Location and Location Privacy in Internet Applications",		Format", RFC 6396, October 2011.
	BCP 160, RFC 6280, July 2011.
	10.2. Informative References		10.2. Informative References
	[IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic",		[IEEE754] IEEE 754, "IEEE Standard for Floating-Point Arithmetic",
	August 2008,		August 2008, <http://ieeexplore.ieee.org/servlet/
	<http://ieeexplore.ieee.org/servlet/		opac?punumber=4610933>.
	opac?punumber=4610933>.
	[MRT-GUIDE]		[MRT-GUIDE] Labovitz, C., "MRT Programmer's Guide", November 1999,
	Labovitz, C., "MRT Programmer's Guide", November 1999,		<http://www.merit.edu/networkresearch/
	<http://www.merit.edu/networkresearch/mrtprogrammer.pdf>.		mrtprogrammer.pdf>.
	[WGS-84] Geodesy and Geophysics Department, DoD., "World Geodetic		[WGS-84] Geodesy and Geophysics Department, DoD., "World Geodetic
	System 1984", January 2000, <http://earth-info.nga.mil/		System 1984", January 2000, <http://earth-info.nga.mil/
	GandG/publications/tr8350.2/wgs84fin.pdf>.		GandG/publications/tr8350.2/wgs84fin.pdf>.
	Author's Address		Author's Address
	Terry Manderson		Terry Manderson
	ICANN		ICANN
	Email: terry.manderson@icann.org		EMail: terry.manderson@icann.org
End of changes. 54 change blocks.
	152 lines changed or deleted		145 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/