--- 1/draft-ietf-grow-mrt-01.txt 2006-03-09 22:12:14.000000000 +0100 +++ 2/draft-ietf-grow-mrt-02.txt 2006-03-09 22:12:14.000000000 +0100 @@ -1,20 +1,20 @@ Network Working Group L. Blunk Internet-Draft M. Karir -Expires: April 27, 2006 Merit Network +Expires: September 7, 2006 Merit Network C. Labovitz Arbor Networks - October 24, 2005 + March 6, 2006 MRT routing information export format - draft-ietf-grow-mrt-01.txt + draft-ietf-grow-mrt-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -25,96 +25,101 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on April 27, 2006. + This Internet-Draft will expire on September 7, 2006. Copyright Notice - Copyright (C) The Internet Society (2005). + Copyright (C) The Internet Society (2006). Abstract 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Basic MRT Format . . . . . . . . . . . . . . . . . . . . . . . 4 3. MRT Control Types . . . . . . . . . . . . . . . . . . . . . . 6 - 3.1 NULL Type . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.2 START Type . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.3 DIE Type . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.4 I_AM_DEAD Type . . . . . . . . . . . . . . . . . . . . . . 6 - 3.5 PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . . . 6 + 3.1. NULL Type . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.2. START Type . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.3. DIE Type . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.4. I_AM_DEAD Type . . . . . . . . . . . . . . . . . . . . . . 6 + 3.5. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . . . 6 4. MRT Routing Information Types . . . . . . . . . . . . . . . . 7 - 4.1 BGP Type . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 4.1.1 BGP_NULL Subtype . . . . . . . . . . . . . . . . . . . 7 - 4.1.2 BGP_UPDATE Subtype . . . . . . . . . . . . . . . . . . 7 - 4.1.3 BGP_PREF_UPDATE Subtype . . . . . . . . . . . . . . . 8 - 4.1.4 BGP_STATE_CHANGE Subtype . . . . . . . . . . . . . . . 8 - 4.1.5 BGP_SYNC Subtype . . . . . . . . . . . . . . . . . . . 8 - 4.1.6 BGP_OPEN . . . . . . . . . . . . . . . . . . . . . . . 9 - 4.1.7 BGP_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 9 - 4.1.8 BGP_KEEPALIVE . . . . . . . . . . . . . . . . . . . . 9 - 4.2 RIP Type . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 4.3 IDRP Type . . . . . . . . . . . . . . . . . . . . . . . . 10 - 4.4 RIPNG Type . . . . . . . . . . . . . . . . . . . . . . . . 10 - 4.5 BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . . . 10 - 4.6 OSPF Type . . . . . . . . . . . . . . . . . . . . . . . . 10 - 4.7 TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 11 - 4.8 BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 12 - 4.8.1 BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 12 - 4.8.2 BGP4MP_MESSAGE Subtype . . . . . . . . . . . . . . . . 13 - 4.8.3 BGP4MP_ENTRY Subtype . . . . . . . . . . . . . . . . . 14 - 4.8.4 BGP4MP_SNAPSHOT Subtype . . . . . . . . . . . . . . . 14 - 4.9 BGP4MP_ET . . . . . . . . . . . . . . . . . . . . . . . . 14 - 4.10 ISIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 4.11 ISIS_ET . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 4.12 OSPF_ET . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 6.1 Normative References . . . . . . . . . . . . . . . . . . . 18 - 6.2 Informative References . . . . . . . . . . . . . . . . . . 18 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 - Intellectual Property and Copyright Statements . . . . . . . . 19 + 4.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 4.1.1. BGP_NULL Subtype . . . . . . . . . . . . . . . . . . . 7 + 4.1.2. BGP_UPDATE Subtype . . . . . . . . . . . . . . . . . . 7 + 4.1.3. BGP_PREF_UPDATE Subtype . . . . . . . . . . . . . . . 8 + 4.1.4. BGP_STATE_CHANGE Subtype . . . . . . . . . . . . . . . 8 + 4.1.5. BGP_SYNC Subtype . . . . . . . . . . . . . . . . . . . 8 + 4.1.6. BGP_OPEN . . . . . . . . . . . . . . . . . . . . . . . 9 + 4.1.7. BGP_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 9 + 4.1.8. BGP_KEEPALIVE . . . . . . . . . . . . . . . . . . . . 9 + 4.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 4.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . . . 10 + 4.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . . . 10 + 4.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . . . 10 + 4.6. OSPF Type . . . . . . . . . . . . . . . . . . . . . . . . 10 + 4.7. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 11 + 4.8. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 12 + 4.8.1. BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 12 + 4.8.2. BGP4MP_MESSAGE Subtype . . . . . . . . . . . . . . . . 13 + 4.8.3. BGP4MP_ENTRY Subtype . . . . . . . . . . . . . . . . . 14 + 4.8.4. BGP4MP_SNAPSHOT Subtype . . . . . . . . . . . . . . . 14 + 4.8.5. BGP4MP_MESSAGE_32BIT_AS Subtype . . . . . . . . . . . 15 + 4.9. BGP4MP_ET . . . . . . . . . . . . . . . . . . . . . . . . 15 + 4.10. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 16 + 4.11. ISIS_ET Type . . . . . . . . . . . . . . . . . . . . . . . 16 + 4.12. OSPF_ET Type . . . . . . . . . . . . . . . . . . . . . . . 16 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 + 5.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 18 + 5.2. Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 18 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 20 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 20 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 + Intellectual Property and Copyright Statements . . . . . . . . . . 22 1. Introduction Researchers and engineers often wish to analyze network behavior by studying routing protocol transactions and routing information base snapshots. To this end, the MRT format was developed to encapsulate, export, and archive this information in a standardized data representation. The BGP routing protocol, in particular, has been the subject of extensive study and analysis which has been significantly aided by the availability of the MRT format. This memo serves to document the MRT format as currently implemented in publicly available software. The format has been extended since it's original introduction in the MRT toolset and these extensions are also included in this memo. Further extensions may be introduced - at a later date through additional definitions of the MRT Type field. + at a later date through additional definitions of the MRT Type field + and Subtype fields. 2. Basic MRT Format All MRT format messages have a common header which includes a - timestamp, type, subtype, and length field. The header is followed + timestamp, Type, Subtype, and length field. The header is followed by a message field. The basic MRT format is illustrated below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | @@ -123,273 +128,273 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header Field Descriptions: Timestamp: Time in seconds since 1 January 1970 00:00:00 UTC Type: - A 2-octet field that indicates the type of information + A 2-octet field that indicates the Type of information contained in the message field. Types 1 through 5 are used for MRT control information while Types 6 and higher are used for routing information. Subtype: - A 2-octet message subtype field + A 2-octet message Subtype field Length: A 4-octet message length field. The length does not include the header. Message: A variable length message. The contents of this field are - context dependent on the type and subtype fields. + context dependent on the Type and Subtype fields. 3. MRT Control Types - The MRT format defines five control type messages. These messages + The MRT format defines five Control Type messages. These messages are using to relay the current state of MRT message source. The message field may contain an optional ASCII text string for diagnostic purposes. These control messages are unidirectional in nature and there is no form of an acknowledgment or response from the - receiver to the sender. The subtype field is unused for these types + receiver to the sender. The Subtype field is unused for these Types and should be set to 0. The MRT Control Types are defined below: 0 NULL 1 START 2 DIE 3 I_AM_DEAD 4 PEER_DOWN -3.1 NULL Type +3.1. NULL Type The NULL Type message causes no operation, A sender may wish to send these for synchronization or keep-alive purposes. -3.2 START Type +3.2. START Type The START Type indicates a sender is about to begin sending MRT messages -3.3 DIE Type +3.3. DIE Type A DIE Type signals that the receiver should shut down. -3.4 I_AM_DEAD Type +3.4. I_AM_DEAD Type A I_AM_DEAD indicates that the sender is shutting down. -3.5 PEER_DOWN Type +3.5. PEER_DOWN Type A PEER_DOWN is sent when the sender's peer is down. In practice, a sender will likely have multiple peers. It is recommended that the sender use the Message field to convey the IP address of the peer represented in US-ASCII. 4. MRT Routing Information Types - The following types are currently defined for the MRT format. Types + The following Types are currently defined for the MRT format. Types 5-12 were defined in the initial MRT Toolkit package. The BGP4MP - type, number 16, was defined in the Zebra routing software package. + Type, number 16, was initially defined in the Zebra routing software + package. 5 BGP 6 RIP 7 IDRP 8 RIPNG 9 BGP4PLUS 10 BGP4PLUS_01 11 OSPF 12 TABLE_DUMP 16 BGP4MP 17 BGP4MP_ET 32 ISIS 33 ISIS_ET 64 OSPF_ET -4.1 BGP Type +4.1. BGP Type The BGP Type indicates the Message field contains BGP routing information. The BGP routing protocol is defined in RFC 1771 [1]. The information in the message is dependent on the Subtype value. The BGP Type is considered to be deprecated by the BGP4MP Type. - The following BGP subtypes are defined for the MRT BGP Type. + The following BGP Subtypes are defined for the MRT BGP Type. 0 BGP_NULL 1 BGP_UPDATE 2 BGP_PREF_UPDATE 3 BGP_STATE_CHANGE 4 BGP_SYNC 5 BGP_OPEN 6 BGP_NOTIFY 7 BGP_KEEPALIVE -4.1.1 BGP_NULL Subtype +4.1.1. BGP_NULL Subtype - The BGP_NULL Subtype is a reserved subtype. + The BGP_NULL Subtype is a reserved Subtype. -4.1.2 BGP_UPDATE Subtype +4.1.2. BGP_UPDATE Subtype The BGP_UPDATE Subtype is used to encode BGP UPDATE messages. The - format of the MRT Message field for this subtype is as follows: + format of the MRT Message field for this Subtype is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source AS number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination AS number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BGP UPDATE Contents (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The BGP UPDATE contents include the entire BGP UPDATE message which follows the BGP Message Header. The BGP Message Header itself is not included. -4.1.3 BGP_PREF_UPDATE Subtype +4.1.3. BGP_PREF_UPDATE Subtype The BGP_PREF_UPDATE Subtype is not defined. -4.1.4 BGP_STATE_CHANGE Subtype +4.1.4. BGP_STATE_CHANGE Subtype The BGP_STATE_CHANGE Subtype is used to record changes in the BGP finite state machine. These FSM states and their numeric encodings are defined in RFC 1771 [1], Appendix 1. Both the old state value and the new state value are encoded as 2-octet numbers. The format of the MRT Message field is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source AS number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Old State | New State | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -4.1.5 BGP_SYNC Subtype +4.1.5. BGP_SYNC Subtype The BGP_SYNC Subtype is used to indicate a File Name where BGP Table Dump messages should be recorded. The View # corresponds to the View # provided in the TABLE_DUMP Type messages. The following format applies to this Subtype: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | View # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | File Name... (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The File Name is terminated with a NULL (0) character. -4.1.6 BGP_OPEN +4.1.6. BGP_OPEN The BGP_OPEN Subtype is used to encode BGP OPEN messages. The format - of the MRT Message field for this subtype is the same as the + of the MRT Message field for this Subtype is the same as the BGP_UPDATE, however, the last field contains the contents of the BGP OPEN message. -4.1.7 BGP_NOTIFY +4.1.7. BGP_NOTIFY The BGP_NOTIFY Subtype is used to encode BGP NOTIFICATION messages. - The format of the MRT Message field for this subtype is the same as + The format of the MRT Message field for this Subtype is the same as the BGP_UPDATE, however, the last field contains the contents of the BGP NOTIFICATION message. -4.1.8 BGP_KEEPALIVE +4.1.8. BGP_KEEPALIVE The BGP_KEEPALIVE Subtype is used to encode BGP KEEPALIVE messages. - The format of the MRT Message field for this subtype is the same as + The format of the MRT Message field for this Subtype is the same as the BGP_UPDATE, however, the last field contains no information. -4.2 RIP Type +4.2. RIP Type The RIP Type is used to export RIP protocol packets as defined in RFC - 1058 [2]. The Subtype field is currently reserved for this type and + 1058 [2]. The Subtype field is currently reserved for this Type and should be set to 0. The format of the MRT Message field for the RIP Type is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RIP Message Contents (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -4.3 IDRP Type +4.3. IDRP Type The IDRP Type is used to export Inter-Domain-Routing Protocol (IDRP) protocol information as defined in the ISO/IEC 10747 standard. The - Subtype field is unused. This type is deprecated due to lack of + Subtype field is unused. This Type is deprecated due to lack of deployment of IDRP. -4.4 RIPNG Type +4.4. RIPNG Type The RIPNG Type is used to export RIPNG protocol packets as defined in - RFC 2080 [3]. The Subtype field is currently reserved for this type + RFC 2080 [3]. The Subtype field is currently reserved for this Type and should be set to 0. The format of the MRT Message field for the RIPNG Type is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RIPNG Message Contents (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -4.5 BGP4PLUS and BGP4PLUS_01 Types +4.5. BGP4PLUS and BGP4PLUS_01 Types The BGP4PLUS and BGP4PLUS_01 Types were defined to support IPv6 BGP routing information. The BGP4PLUS Type was specified based on the initial Internet Draft for Multiprotocol Extensions to BGP-4. The BGP4PLUS_01 Type was specified to correspond to the -01 revision of - this Internet Draft. The two types share the same definitions in + this Internet Draft. The two Types share the same definitions in terms of their MRT format specifications. The Subtype field definitions are shared with the BGP Type, however, the address fields in the BGP_UPDATE, BGP_OPEN, BGP_NOTIFY, - BGP_KEEPALIVE, and BGP_STATE_CHANGE subtype messages are extended to + BGP_KEEPALIVE, and BGP_STATE_CHANGE Subtype messages are extended to 16 octets for IPv6 addresses. As with the BGP Type, the BGP4PLUS and BGP4PLUS_01 Types are deprecated as they superseded by the BGP4MP Type. -4.6 OSPF Type +4.6. OSPF Type - This type supports the OSPF Protocol as defined in RFC 2328 [4]. The + This Type supports the OSPF Protocol as defined in RFC 2328 [4]. The Subtype field may contain two possible values: 0 OSPF_STATE_CHANGE 1 OSPF_LSA_UPDATE - The format of the MRT Message field for the OSPF Type is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OSPF Message Contents (variable) @@ -388,21 +393,21 @@ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OSPF Message Contents (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -4.7 TABLE_DUMP Type +4.7. TABLE_DUMP Type The TABLE_DUMP Type is used to encode routing table dumps. The Subtype is used to encode whether the table entry contains IPv4 or IPv6 addresses. There are currently two possible values for the Subtype as shown below. 1 AFI_IPv4 2 AFI_IPv6 The format of the TABLE_DUMP Type is illustrated below. @@ -448,33 +453,34 @@ update for this routing table entry. As with the Prefix field, the size of this field is dependent on the Subtype. AFI_IPv4 indicates a 4 octet field and an IPv4 address, while a Subtype of AFI_IPv6 requires a 16 octet field and an IPv6 address. The Peer AS field contains the AS number of the peer. Attribute length is the length of Attribute field and is 2-octets. The Attribute field contains the attribute information for the route table entry. -4.8 BGP4MP Type +4.8. BGP4MP Type - This type was initially defined in the Zebra software package for the - BGP protocol with multiprotocol extension support. It supersedes the - BGP, BGP4PLUS, BGP4PLUS_01 Types. The BGP4MP Type has four subtypes - which are defined as follows: + This Type was initially defined in the Zebra software package for the + BGP protocol with multiprotocol extension support as defined by RFC + 2858 [5]. It supersedes the BGP, BGP4PLUS, BGP4PLUS_01 Types. The + BGP4MP Type has four Subtypes which are defined as follows: 0 BGP4MP_STATE_CHANGE 1 BGP4MP_MESSAGE 2 BGP4MP_ENTRY 3 BGP4MP_SNAPSHOT + 4 BGP4MP_MESSAGE_32BIT_AS -4.8.1 BGP4MP_STATE_CHANGE Subtype +4.8.1. BGP4MP_STATE_CHANGE Subtype This record is used to encode state changes in the BGP finite state machine. As with the BGP_STATE_CHANGE Subtype, the BGP FSM states are encoded in the Old State and New State fields to indicate the previous and current state. The format is illustrated below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source AS number | Destination AS number | @@ -482,53 +488,57 @@ | Interface Index | Address Family | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP address (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP address (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Old State | New State | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ While BGP4MP_STATE_CHANGE message is similar to the BGP_STATE_CHANGE - message, it also includes interface index and Address Family fields. - The interface index provides the interface number of the peering - session and the Address Family indicates what types of addresses are - in the the address fields. At present, only the following AFI types - are supported: + message, however, it also includes interface index and Address Family + fields. As with the BGP_STATE_CHANGE message, the FSM states and + their numeric encodings are defined in RFC 1771 [1], Appendix 1. + Future updates to the BGP protocol specification will introduce a new + state machine and thus render this message Type obsolete. The + interface index provides the interface number of the peering session + and the Address Family indicates what Types of addresses are in the + the address fields. At present, only the following AFI Types are + supported: 1 AFI_IPv4 2 AFI_IPv6 -4.8.2 BGP4MP_MESSAGE Subtype +4.8.2. BGP4MP_MESSAGE Subtype This Subtype is used to encode BGP Messages. It is similar to the - BGP_UPDATE subtype, except that is can be used to encode any type of + BGP_UPDATE Subtype, except that is can be used to encode any Type of message (not just BGP UPDATES). In order to determine the BGP - message type, the entire BGP message, including the BGP header, is + message Type, the entire BGP message, including the BGP header, is included in the BGP Message field. The BGP4MP_MESSAGE fields are shown below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source AS number | Destination AS number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Index | Address Family | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP address (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP address (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BGP Message... (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -4.8.3 BGP4MP_ENTRY Subtype +4.8.3. BGP4MP_ENTRY Subtype This Subtype is used to record routing table entries. It is similar to the TABLE_DUMP Type. The primary difference being that the Address Family is encoded in the Message itself. Further, a Subsequence Address Family field (SAFI) is included as well. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | View # | Status | @@ -541,132 +551,193 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Prefix (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BGP Attribute... (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -4.8.4 BGP4MP_SNAPSHOT Subtype +4.8.4. BGP4MP_SNAPSHOT Subtype This Subtype is used to indicate a filename containing BGP4MP_ENTRY - records. It is similar to the BGP_SYNC message subtype and shares + records. It is similar to the BGP_SYNC message Subtype and shares the same fields. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | View # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | File Name... (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -4.9 BGP4MP_ET +4.8.5. BGP4MP_MESSAGE_32BIT_AS Subtype - This type was initially defined in the Sprint Labs Python Routing + This Subtype updates the BGP4MP_MESSAGE Subtype to support 32BIT + Autonomous System numbers. As the current 16 bit Autonomous System + number space nears exhaustion, the introduction of 32 bit numbers + will be required to support future Autonomous System number + allocations. The BGP4MP_MESSAGE_32BIT_AS fields are shown below: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Source AS number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Destination AS number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Interface Index | Address Family | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Source IP address (variable) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Destination IP address (variable) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | BGP Message... (variable) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +4.9. BGP4MP_ET + + This Type was initially defined in the Sprint Labs Python Routing Toolkit (PyRT). It extends the header field of the BGP4MP Type to - include a 32-bit microsecond timestamp field. The subtypes and other + include a 32-bit microsecond timestamp field. The Subtypes and other field definitions remain as defined for the BGP4MP Type. The 32-bit microsecond timestamp immediately follows the length field in the BGP4MP Type and precedes all other fields in the message. The header modification is illustrated below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | microsecond timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message... (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -4.10 ISIS +4.10. ISIS Type - This type was initially defined in the Sprint Labs Python Routing and - supports the IS-IS routing protocol as defined in RFC 1195 [5]. - There is no type specific header for the ISIS Type. The subtype code - for this type is undefined. The ISIS PDU directly follows the MRT + This Type was initially defined in the Sprint Labs Python Routing and + supports the IS-IS routing protocol as defined in RFC 1195 [6]. + There is no Type specific header for the ISIS Type. The Subtype code + for this Type is undefined. The ISIS PDU directly follows the MRT common header fields. -4.11 ISIS_ET +4.11. ISIS_ET Type The ISIS_ET Type extends the the ISIS Type to support microsecond timestamps. As with the BGP4MP_ET Type, a 32-bit microsecond timestamp field is appended to the MRT common header after the length field. The ISIS_ET Type is otherwise identical to the ISIS Type. -4.12 OSPF_ET +4.12. OSPF_ET Type The OSPF_ET Type extends the the OSPF Type to support microsecond timestamps. As with the BGP4MP_ET and ISIS_ET Types, a 32-bit microsecond timestamp field is appended to the MRT common header after the length field. The OSPF_ET Type also extends the OSPF Type to support IPv6 addresses for the OSPFv3 protocol as defined in RFC - 2740 [6]. The format of the MRT Message field for the OSPF_ET Type + 2740 [7]. The format of the MRT Message field for the OSPF_ET Type is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP address (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP address (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OSPF Message Contents (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -5. Security Considerations +5. IANA Considerations + + This section provides guidance to the Internet Assigned Numbers + Authority (IANA) regarding registration of values related to the MRT + specification, in accordance with BCP 26, RFC 2434 [8]. + + There are two name spaces in MRT that require registration: Type + Codes and Subtype Codes. + + MRT is not intended as a general-purpose specification for protocol + information export, and allocations should not be made for purposes + unrelated to routing protocol information export. + + The following terms are used here with the meanings defined in BCP + 26: "name space", "assigned value", "registration". + + The following policies are used here with the meanings defined in BCP + 26: "First Come First Served", "Specification Required". + +5.1. Type Codes + + Type Codes have a range from 0 to 65535, of which 0-64 have been + allocated. New Type Codes should be allocated starting at 65 with + Specification Required. + +5.2. Subtype Codes + + Subtype Codes have a range from 0 to 65535. Subtype definitions are + specific to a particular Type Code definition. New Subtype Code + definition must reference an existing Type Code to which the Subtype + belongs. As Subtype Codes are specific to Type Codes, new numbers + must be unique for the particular Type Code to which the Subtype + applies with Specification Required for the Subtype code. + +6. Security Considerations The MRT Format utilizes a structure which can store routing protocol information data. The fields defined in the MRT specification are of a descriptive nature and provide information that is useful to facilitate the analysis of routing data. As such, the fields currently defined in the MRT specification do not in themselves create additional security risks, since the fields are not used to induce any particular behavior by the recipient application. -6. References +7. References -6.1 Normative References +7.1. Normative References [1] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [2] Hedrick, C., "Routing Information Protocol", RFC 1058, June 1988. [3] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997. [4] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. - [5] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual + [5] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol + Extensions for BGP-4", RFC 2858, June 2000. + + [6] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. - [6] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, + [7] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999. - [7] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol - Extensions for BGP-4", RFC 2858, June 2000. + [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. -6.2 Informative References +7.2. Informative References - [8] "The MRT Programmers Manual", November 1999. + [9] "The MRT Programmers Manual", November 1999. Authors' Addresses Larry Blunk Merit Network Email: ljb@merit.edu Manish Karir Merit Network @@ -707,18 +778,18 @@ This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement - Copyright (C) The Internet Society (2005). This document is subject + Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.