rfc-6396

Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format

L. Blunk, M. Karir, C. Labovitz
date2011-10 streamIETF areaops wggrow statusPROPOSED STANDARD pages33 canonicalhttps://www.rfc-editor.org/rfc/rfc6396 doi10.17487/RFC6396 errataview
This document describes the MRT format for routing information export. This format was developed in concert with the Multi-threaded Routing Toolkit (MRT) from whence the format takes it name. The format can be used to export routing protocol messages, state changes, and routing information base contents. [STANDARDS-TRACK]

Extracted elements (31)

design-rationale §2

The 4-octet MRT Timestamp is a UNIX epoch value and cannot represent times before January 1, 1970 or after 03:14:07 on January 19, 2038 (0x7FFFFFFF). Implementations creating MRT records after that date will need an alternate EPOCH base; mechanisms for indicating this are currently out of scope.

routing, measurement

design-rationale §4.3

The TABLE_DUMP_V2 Type was introduced to overcome two key limitations of TABLE_DUMP: lack of 4-byte AS number support and inability to have different AFIs for peer IP and prefix. It also improves space efficiency by using a shared PEER_INDEX_TABLE and allowing multiple RIB entries per NLRI in a single MRT record.

routing, bgp

interoperability-note §B

MRT Type Codes 0-10 are deprecated. Types 0-4 are informational collector-state signals never known to be implemented; types 5-10 (BGP, RIP, IDRP, RIPNG, BGP4PLUS, BGP4PLUS_01) are superseded by BGP4MP and TABLE_DUMP_V2. Historical MRT archives may contain these types, and researchers may need to support them for backward compatibility.

routing, bgp

normative-requirement §4.3.4 MUST

All AS numbers in the AS_PATH attribute within TABLE_DUMP_V2 RIB Entries MUST be encoded as 4-byte AS numbers.

routing, bgp

normative-requirement §4.3.3 SHOULD

An implementation that does not recognize particular AFI and SAFI values in a RIB_GENERIC record SHOULD discard the remainder of that MRT record.

routing, bgp

normative-requirement §4.2 SHOULD

New MRT encoding implementations SHOULD use the TABLE_DUMP_V2 Type instead of the TABLE_DUMP Type due to limitations in TABLE_DUMP (no 4-byte AS numbers, no mixed AFI for peer and prefix). MRT decoding applications MAY support the older TABLE_DUMP Type.

routing, bgp

normative-requirement §4.4.2 MUST

The BGP4MP_MESSAGE Subtype does not support 4-byte AS numbers; the AS_PATH MUST only consist of 2-byte AS numbers. Only one BGP message SHALL be encoded per BGP4MP_MESSAGE record. BGP4MP_MESSAGE_AS4 MUST be used for 4-byte AS numbers, where the AS_PATH MUST only consist of 4-byte AS numbers.

routing, bgp

normative-requirement §4.3.1 MUST

The RIB entry MRT records MUST immediately follow the PEER_INDEX_TABLE MRT record. The View Name encoding MUST follow the UTF-8 transformation format (RFC 3629), and when no View Name is present, the View Name Length MUST be set to 0.

routing, bgp

normative-requirement §4.2 MUST

The TABLE_DUMP Type MUST be superseded by TABLE_DUMP_V2 when 4-byte Peer AS numbers are needed or when the AFI of the peer IP differs from the AFI of the Prefix field. The AS_PATH attribute in TABLE_DUMP MUST only consist of 2-byte AS numbers.

routing, bgp

protocol-element §4.4.5

BGP4MP_MESSAGE_LOCAL and BGP4MP_MESSAGE_AS4_LOCAL subtypes indicate locally generated BGP messages rather than remotely received ones. The Local fields refer to the collector that generated the message, and the Peer fields refer to the recipient.

routing, bgp

protocol-element §4

MRT defines nine active Type codes: OSPFv2 (11), TABLE_DUMP (12), TABLE_DUMP_V2 (13), BGP4MP (16), BGP4MP_ET (17), ISIS (32), ISIS_ET (33), OSPFv3 (48), and OSPFv3_ET (49). Types with _ET suffix use the Extended Timestamp MRT Header.

routing, bgp, measurement

protocol-element §4.3

TABLE_DUMP_V2 adds 4-byte ASN support, full BGP multiprotocol extension support, a PEER_INDEX_TABLE for space efficiency, and allows a single MRT record per NLRI entry. Subtypes are: PEER_INDEX_TABLE (1), RIB_IPV4_UNICAST (2), RIB_IPV4_MULTICAST (3), RIB_IPV6_UNICAST (4), RIB_IPV6_MULTICAST (5), RIB_GENERIC (6).

routing, bgp

protocol-element §4.5

The ISIS Type (32) and ISIS_ET (33) support the IS-IS routing protocol (RFC 1195). There is no Type-specific header; the ISIS PDU directly follows the MRT Common Header. The Subtype code is undefined for this type.

routing

registry §5.2

IANA maintains MRT Subtype Codes (0-65535) specific to each Type Code. Subtype assignments follow the same allocation rules as the Type Code to which the Subtype belongs. New Subtype definitions must reference an existing Type Code.

registry, routing

registry §5.1

IANA maintains MRT Type Codes (0-65535) with the following allocation policy: 0-64 reserved; 65-511 assigned by IETF Review; 512-2047 by Specification Required; 2048-64511 by First Come First Served; 64512-65534 for Experimental Use; 65535 reserved. New Type Codes MUST be allocated starting at 65.

registry, routing

registry §5.6

TABLE_DUMP_V2 Subtype Codes registered: PEER_INDEX_TABLE (1), RIB_IPV4_UNICAST (2), RIB_IPV4_MULTICAST (3), RIB_IPV6_UNICAST (4), RIB_IPV6_MULTICAST (5), RIB_GENERIC (6). BGP4MP Subtype Codes registered: BGP4MP_STATE_CHANGE (0), BGP4MP_MESSAGE (1), BGP4MP_MESSAGE_AS4 (4), BGP4MP_STATE_CHANGE_AS4 (5), BGP4MP_MESSAGE_LOCAL (6), BGP4MP_MESSAGE_AS4_LOCAL (7).

registry, routing, bgp

registry §5.3

This document registers MRT Type Codes including: OSPFv2 (11), TABLE_DUMP (12), TABLE_DUMP_V2 (13), BGP4MP (16), BGP4MP_ET (17), ISIS (32), ISIS_ET (33), OSPFv3 (48), OSPFv3_ET (49), plus deprecated types 0-10.

registry, routing, bgp

security-consideration §6

MRT data may contain sensitive information including BGP peer IP addresses, BGP Next Hop IP addresses, and BGP Path Attributes that could facilitate attacks against BGP routing infrastructure as described in RFC 4272. Organizations exporting MRT data beyond its normal domain (e.g., publishing for research) should obtain peer consent and possibly scrub sensitive fields.

security, bgp, routing

security-consideration §6

The MRT format fields are descriptive and do not induce behavior by recipient applications, so they do not themselves create additional security risks. However, a proposed geolocation extension could reveal the physical location of an MRT router's peers.

security, privacy, routing

state-machine §4.4.1

The BGP4MP_STATE_CHANGE subtype records BGP FSM state transitions. States are encoded as 2-octet numbers: Idle (1), Connect (2), Active (3), OpenSent (4), OpenConfirm (5), Established (6). Old State and New State fields capture the transition trigger.

routing, bgp

wire-format §4.3.2

AFI/SAFI-specific RIB subtypes (RIB_IPV4_UNICAST, RIB_IPV4_MULTICAST, RIB_IPV6_UNICAST, RIB_IPV6_MULTICAST) encode a 4-octet Sequence Number, 1-octet Prefix Length, variable Prefix, 2-octet Entry Count, and repeated variable RIB Entries. The Prefix encoding matches BGP NLRI with trailing bits padded to octet boundary.

routing, bgp

wire-format §4.3.4

For RIB Entries containing the BGP MP_REACH_NLRI attribute (Type Code 14), only the Next Hop Address Length and Next Hop Address fields are included; the AFI, SAFI, NLRI, and Reserved fields are omitted since they are already encoded in the RIB Entry Header. The attribute length is adjusted accordingly.

routing, bgp

wire-format §4.4.2

The BGP4MP_MESSAGE subtype encodes a complete BGP message including the 16-octet marker, 2-octet length, and 1-octet type. The message contains 2-octet Peer AS Number, 2-octet Local AS Number, 2-octet Interface Index, 2-octet Address Family, variable Peer IP and Local IP addresses, followed by the full BGP Message.

routing, bgp

wire-format §3

The Extended Timestamp MRT Header adds a 4-octet Microsecond Timestamp field (unsigned 32-bit microsecond offset) immediately after the Length field, before the Message. This value is added to the Timestamp field and is included in the Length computation.

routing, measurement

wire-format §2

The MRT Common Header consists of a 4-octet Timestamp (seconds since UNIX epoch), 2-octet Type, 2-octet Subtype, and 4-octet Length field (number of octets in the message, excluding the header), followed by a variable-length Message field.

routing, bgp, measurement

wire-format §4.1

The OSPFv2 Type message contains a 4-octet Remote IP Address (source IPv4 from IP header), a 4-octet Local IP Address (destination IPv4 from IP header), followed by the variable-length OSPF Message Contents.

routing

wire-format §4.6

The OSPFv3 Type extends OSPFv2 to support IPv6 by prepending a 2-octet Address Family field before the variable-length Remote IP Address, Local IP Address, and OSPF Message Contents fields.

routing

wire-format §4.3.1

The PEER_INDEX_TABLE subtype header contains a 4-octet Collector BGP ID, 2-octet View Name Length, optional variable View Name (UTF-8 encoded), 2-octet Peer Count, and repeated Peer Entries. Each Peer Entry has a 1-octet Peer Type, 4-octet Peer BGP ID, variable Peer IP Address, and variable Peer AS.

routing, bgp

wire-format §4.3.1

The Peer Type field is a 1-octet bit field: bit 6 (A) encodes Peer AS number size (0=16-bit, 1=32-bit) and bit 7 (I) encodes Peer IP Address family (0=IPv4, 1=IPv6). This determines the variable-length encoding of subsequent Peer IP Address and Peer AS fields.

routing, bgp

wire-format §4.3.3

The RIB_GENERIC subtype header contains a 4-octet Sequence Number, 2-octet Address Family Identifier, 1-octet Subsequent AFI, variable NLRI, 2-octet Entry Count, and variable RIB Entries. It handles RIB entries not covered by the specific AFI/SAFI subtypes.

routing, bgp

wire-format §4.2

The TABLE_DUMP Type encodes RIB entries with fields: 2-octet View Number, 2-octet Sequence Number, variable Prefix (4 octets for IPv4, 16 for IPv6), 1-octet Prefix Length, 1-octet Status (SHOULD be 1), 4-octet Originated Time, variable Peer IP Address, 2-octet Peer AS, 2-octet Attribute Length, and variable BGP Attribute.

routing, bgp