doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc6397.txt b/doc/rfc/rfc6397.txt
new file mode 100644
index 0000000..b63fb04
--- /dev/null
+++ b/doc/rfc/rfc6397.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      T. Manderson
+Request for Comments: 6397                                         ICANN
+Category: Standards Track                                   October 2011
+ISSN: 2070-1721
+
+
+   Multi-Threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP)
+     Routing Information Export Format with Geo-Location Extensions
+
+Abstract
+
+   This document updates the Multi-threaded Routing Toolkit (MRT) export
+   format for Border Gateway Protocol (BGP) routing information by
+   extending it to include optional terrestrial coordinates of a BGP
+   collector and its BGP peers.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   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 (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+Manderson                    Standards Track                    [Page 1]
+
+RFC 6397             Geo-Location Extensions in MRT         October 2011
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
+   2.  Requirements Notation . . . . . . . . . . . . . . . . . . . . . 2
+   3.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   4.  Geo-Location-Aware MRT Routing Information Subtype  . . . . . . 3
+     4.1.  GEO_PEER_TABLE  . . . . . . . . . . . . . . . . . . . . . . 3
+     4.2.  GEO_PEER_TABLE and Peer Entry Values  . . . . . . . . . . . 5
+   5.  BGP Collector Construction  . . . . . . . . . . . . . . . . . . 5
+   6.  Privacy Considerations  . . . . . . . . . . . . . . . . . . . . 6
+   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
+   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
+   9.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
+   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+     10.1. Normative References  . . . . . . . . . . . . . . . . . . . 7
+     10.2. Informative References  . . . . . . . . . . . . . . . . . . 8
+
+1.  Introduction
+
+   Researchers and engineers often wish to analyze network behavior by
+   studying routing protocol transactions and routing information base
+   snapshots in relation to geographical topologies.  Usually, the
+   Border Gateway Protocol [RFC4271] is the subject of study, and the
+   analysis can be significantly aided by the availability and extension
+   of the "Multi-Threaded Routing Toolkit (MRT) Routing Information
+   Export Format" [RFC6396].  The MRT format was originally defined in
+   the MRT Programmer's Guide [MRT-GUIDE].
+
+   The addition of geo-location coordinates (longitude and latitude)
+   pertaining to the geographical location of both the BGP collector and
+   its BGP peers to BGP export data enables a researcher or enquiring
+   individual to gain a terrestrial insight to the routes seen by a BGP
+   speaker.  Such data may ultimately aid researchers in understanding
+   any disparity between the geographical location of networks and the
+   topological location of networks in addition to the relationships
+   between geographical position and routing anomalies.  Such insight
+   could provide future input into network design and network security.
+
+   This memo documents an optional extension to the MRT format [RFC6396]
+   and introduces an additional definition of an MRT Subtype field that
+   includes the terrestrial coordinates of a BGP collector and its BGP
+   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].
+
+
+
+Manderson                    Standards Track                    [Page 2]
+
+RFC 6397             Geo-Location Extensions in MRT         October 2011
+
+
+3.  Definitions
+
+   Coordinates: The geographic latitude and longitude specifying a
+   location on the earth.
+
+   BGP Speaker: A network device that exchanges network routing
+   information using BGP.
+
+   Geo-location: Assigning a set of coordinates to a specific artifact,
+   in this case a BGP speaker.
+
+   BGP Collector: A BGP speaker (usually passive) that stores and
+   archives BGP routing data from active BGP peers for analysis.
+
+   BGP Peer: Either an internal or external BGP peer [RFC4271].
+
+   Not A Number (NAN): Numeric data type representing an undefined or
+   unrepresentable value, as defined in the IEEE Standard for Floating-
+   Point Arithmetic [IEEE754].
+
+4.  Geo-Location-Aware MRT Routing Information Subtype
+
+   An additional subtype (GEO_PEER_TABLE) is defined for the
+   TABLE_DUMP_V2 format, extending TABLE_DUMP_V2 Type.
+
+4.1.  GEO_PEER_TABLE
+
+   The GEO_PEER_TABLE Subtype updates the TABLE_DUMP_V2 Types to include
+   geo-location information in the form of the World Geodetic System
+   1984 (WGS84) [WGS-84] formatted coordinates.
+
+   The document adds the 7th subtype number and name below.  The first 6
+   subtypes are defined by the MRT format [RFC6396].
+
+   Subtype Number       Subtype Name
+   ----------------------------------
+       7               GEO_PEER_TABLE
+
+   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
+   indexed peers and their respective latitudes and longitudes in WGS84
+   [WGS-84] format.
+
+   The format and function of the Collector BGP ID and Peer Count are as
+   defined by the TABLE_DUMP_V2, PEER_INDEX_TABLE format [RFC6396].
+
+
+
+
+
+
+Manderson                    Standards Track                    [Page 3]
+
+RFC 6397             Geo-Location Extensions in MRT         October 2011
+
+
+   The Collector Latitude and Collector Longitude are the geographical
+   coordinates of the collector in WGS84 [WGS-84] datum decimal degrees
+   format stored as a single precision float in the 32 bits allocated to
+   the Collector Latitude and Collector Longitude.  The latitude and
+   longitude MAY be a Not A Number (NAN) [IEEE754] for situations where
+   the geo-location of the collector is considered private.  The
+   Collector Latitude and Collector Longitude MUST NOT be a mix of WGS84
+   [WGS-84] datum coordinates and NAN values.
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Collector BGP ID                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Collector Latitude                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Collector Longitude                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Peer Count           |  Peer Entries (variable)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                       Format of the GEO_PEER_TABLE
+
+   The format of the Peer Entries is shown below.  The Peer Type and the
+   Peer BGP ID are as defined in the TABLE_DUMP_V2 MRT, PEER_INDEX_TABLE
+   format [RFC6396].  The order of the Peer Entries in the
+   GEO_PEER_TABLE MUST match the order and number as existing in the
+   PEER_INDEX_TABLE.
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   Peer Type   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         Peer BGP ID                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         Peer Latitude                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         Peer Longitude                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                          Format of Peer Entries
+
+   The Peer Latitude and Peer Longitude are the geographical coordinates
+   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
+   Latitude and Peer Longitude.  The latitude and longitude MAY be a Not
+   A Number (NAN) [IEEE754] for situations where the geo-location of the
+
+
+
+Manderson                    Standards Track                    [Page 4]
+
+RFC 6397             Geo-Location Extensions in MRT         October 2011
+
+
+   peer is considered private.  The Peer Latitude and Peer Longitude
+   MUST NOT be a mix of WGS84 [WGS-84] datum coordinates and NAN values
+   for a single peer.
+
+4.2.  GEO_PEER_TABLE and Peer Entry Values
+
+   Collector BGP ID: Defined in the MRT format [RFC6396].
+
+   Collector Latitude: Geographic latitude of the BGP collector in WGS84
+   [WGS-84] datum decimal degrees format stored as a single precision
+   float.
+
+   Collector Longitude: Geographic longitude of the BGP collector in
+   WGS84 [WGS-84] datum decimal degrees format stored as a single
+   precision float.
+
+   Peer Count: Defined in the MRT format [RFC6396].
+
+   Peer Entries: Defined in the MRT format [RFC6396].
+
+   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]
+   datum decimal degrees format stored as a single precision float.
+
+   Peer Longitude: Geographic longitude of the BGP peer in WGS84
+   [WGS-84] datum decimal degrees format stored as a single precision
+   float.
+
+5.  BGP Collector Construction
+
+   This section aids the reader in understanding the function of a BGP
+   collector.
+
+   The BGP collector is a hardware- or software-based device that speaks
+   the Border Gateway Protocol.  Its intended function is to store (and
+   archive) the BGP routing data it receives from other BGP speakers
+   with which it has peering relationships, providing data for later
+   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
+   announce or propagate any information it knows or receives.  It
+   should be noted that this is not always the case; network operators
+   sometimes enable the collection of BGP routing data on active BGP
+   speakers to obtain a situational view of the routing system as they
+   see it at a particular point in time.
+
+
+
+
+Manderson                    Standards Track                    [Page 5]
+
+RFC 6397             Geo-Location Extensions in MRT         October 2011
+
+
+   As a fully fledged BGP speaker, the BGP collector can fit into any
+   BGP topology including Internal BGP (iBGP), External BGP (eBGP), and
+   so on.  The implementation of a BGP collector in a network topology
+   is therefore limited by that network's use of BGP.
+
+6.  Privacy Considerations
+
+   The GEOPRIV [RFC6280] architecture requires that privacy rules
+   attached to a location object be transmitted alongside the location
+   information in the object.  If a BGP collector adds location
+   coordinates to an MRT record based on GEOPRIV location objects, then
+   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 entry in an MRT object is assigned the following default
+   privacy rules [RFC4119]:
+
+   -- retransmission-allowed: True
+   -- retention-expires: 100 years from timestamp of the MRT object
+   -- ruleset-reference: Empty
+   -- note-well: Empty
+
+   Location information derived from a location object with more
+   restrictive privacy rules MUST NOT be included in an MRT geo-location
+   record unless there are non-technical measures in place that enforce
+   and communicate the constraints on the use of the location
+   information in the MRT geo-location format (e.g., contractual
+   agreements between peers).
+
+7.  Acknowledgements
+
+   Thanks to Andrew Clark, Ernest Foo, Dave Meyer, Larry Blunk, Richard
+   Barnes, and Jeffrey Haas for reviewing this document.
+
+   This document describes a small portion of the research towards the
+   author's Ph.D.
+
+8.  IANA Considerations
+
+   Per this section, the Internet Assigned Numbers Authority (IANA) has
+   registered the additional Subtype code value as:
+
+       7    GEO_PEER_TABLE
+
+   in the MRT format [RFC6396] and Subtype code values related to the
+   TABLE_DUMP_V2 Type in the MRT namespace.
+
+
+
+
+
+
+Manderson                    Standards Track                    [Page 6]
+
+RFC 6397             Geo-Location Extensions in MRT         October 2011
+
+
+9.  Security Considerations
+
+   This extension to the MRT format [RFC6396] defines fields that are of
+   a descriptive nature and provides information that is useful in the
+   analysis of routing systems.  As such, the author believes that they
+   do not constitute an additional network-based security risk.  It is
+   recommended that the operators of the BGP collector and BGP peers
+   consider their own privacy and security concerns before supplying
+   geographical coordinates to BGP data collection systems.  Special
+   attention should be given to the physical security of an organization
+   before supplying geographical coordinates, especially if the
+   resulting BGP data with geo-location extensions is made public.
+
+   Entities that operate BGP collectors, and users of data provided by
+   BGP collectors, should be aware that the geo-location data supplied
+   by a peer can only be taken at face value.  It is possible that a BGP
+   peer may supply coordinates that are purposefully misleading or
+   inaccurate.  It is therefore up to the BGP collector whether or not
+   to include this information or use its own methods to either trust or
+   validate the data provided.  It is not recommended that a BGP
+   collector use geographical coordinates not supplied by a BGP peer.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4119]    Peterson, J., "A Presence-based GEOPRIV Location Object
+                Format", RFC 4119, December 2005.
+
+   [RFC4271]    Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
+                Protocol 4 (BGP-4)", RFC 4271, January 2006.
+
+   [RFC6280]    Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
+                Tschofenig, H., and H. Schulzrinne, "An Architecture for
+                Location and Location Privacy in Internet Applications",
+                BCP 160, RFC 6280, July 2011.
+
+   [RFC6396]    Blunk, L., Karir, M., and C. Labovitz, "Multi-Threaded
+                Routing Toolkit (MRT) Routing Information Export
+                Format", RFC 6396, October 2011.
+
+
+
+
+
+
+
+
+Manderson                    Standards Track                    [Page 7]
+
+RFC 6397             Geo-Location Extensions in MRT         October 2011
+
+
+10.2.  Informative References
+
+   [IEEE754]    IEEE 754, "IEEE Standard for Floating-Point Arithmetic",
+                August 2008, <http://ieeexplore.ieee.org/servlet/
+                opac?punumber=4610933>.
+
+   [MRT-GUIDE]  Labovitz, C., "MRT Programmer's Guide", November 1999,
+                <http://www.merit.edu/networkresearch/
+                mrtprogrammer.pdf>.
+
+   [WGS-84]     Geodesy and Geophysics Department, DoD., "World Geodetic
+                System 1984", January 2000, <http://earth-info.nga.mil/
+                GandG/publications/tr8350.2/wgs84fin.pdf>.
+
+Author's Address
+
+   Terry Manderson
+   ICANN
+
+   EMail: terry.manderson@icann.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Manderson                    Standards Track                    [Page 8]
+