--- 1/draft-ietf-grow-mrt-07.txt 2008-07-15 00:12:28.000000000 +0200 +++ 2/draft-ietf-grow-mrt-08.txt 2008-07-15 00:12:28.000000000 +0200 @@ -1,20 +1,20 @@ Network Working Group L. Blunk Internet-Draft M. Karir Intended status: Standards Track Merit Network -Expires: August 28, 2008 C. Labovitz +Expires: January 15, 2009 C. Labovitz Arbor Networks - February 25, 2008 + July 14, 2008 MRT routing information export format - draft-ietf-grow-mrt-07.txt + draft-ietf-grow-mrt-08.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,81 +25,75 @@ 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 August 28, 2008. + This Internet-Draft will expire on January 15, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). 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. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Basic MRT Format . . . . . . . . . . . . . . . . . . . . . . . 6 4. MRT Informational Types . . . . . . . . . . . . . . . . . . . 8 - 4.1. NULL Type . . . . . . . . . . . . . . . . . . . . . . . . 8 - 4.2. START Type . . . . . . . . . . . . . . . . . . . . . . . . 8 - 4.3. DIE Type . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 4.4. I_AM_DEAD Type . . . . . . . . . . . . . . . . . . . . . . 8 - 4.5. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . . . 9 - 5. MRT Routing Information Types . . . . . . . . . . . . . . . . 10 - 5.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 5.1.1. BGP_NULL Subtype . . . . . . . . . . . . . . . . . . . 10 - 5.1.2. BGP_UPDATE Subtype . . . . . . . . . . . . . . . . . . 11 - 5.1.3. BGP_PREF_UPDATE Subtype . . . . . . . . . . . . . . . 11 - 5.1.4. BGP_STATE_CHANGE Subtype . . . . . . . . . . . . . . . 11 - 5.1.5. BGP_SYNC Subtype . . . . . . . . . . . . . . . . . . . 12 - 5.1.6. BGP_OPEN Subtype . . . . . . . . . . . . . . . . . . . 12 - 5.1.7. BGP_NOTIFY Subtype . . . . . . . . . . . . . . . . . . 12 - 5.1.8. BGP_KEEPALIVE Subtype . . . . . . . . . . . . . . . . 12 - 5.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 5.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . . . 13 - 5.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . . . 13 - 5.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . . . 13 - 5.6. OSPF Type . . . . . . . . . . . . . . . . . . . . . . . . 14 - 5.7. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 14 - 5.8. TABLE_DUMP_V2 Type . . . . . . . . . . . . . . . . . . . . 16 - 5.9. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 18 - 5.9.1. BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 19 - 5.9.2. BGP4MP_MESSAGE Subtype . . . . . . . . . . . . . . . . 20 - 5.9.3. BGP4MP_ENTRY Subtype . . . . . . . . . . . . . . . . . 20 - 5.9.4. BGP4MP_SNAPSHOT Subtype . . . . . . . . . . . . . . . 21 - 5.9.5. BGP4MP_STATE_CHANGE_AS4 Subtype . . . . . . . . . . . 22 - 5.9.6. BGP4MP_MESSAGE_AS4 Subtype . . . . . . . . . . . . . . 22 - 5.10. BGP4MP_ET Type . . . . . . . . . . . . . . . . . . . . . . 23 - 5.11. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 23 - 5.12. ISIS_ET Type . . . . . . . . . . . . . . . . . . . . . . . 23 - 5.13. OSPFv3 Type . . . . . . . . . . . . . . . . . . . . . . . 23 - 5.14. OSPFv3_ET Type . . . . . . . . . . . . . . . . . . . . . . 24 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 - 6.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 25 - 6.2. Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 25 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 27 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 27 + 4.1. START Type . . . . . . . . . . . . . . . . . . . . . . . . 8 + 4.2. I_AM_DEAD Type . . . . . . . . . . . . . . . . . . . . . . 8 + 5. MRT Routing Information Types . . . . . . . . . . . . . . . . 9 + 5.1. OSPF Type . . . . . . . . . . . . . . . . . . . . . . . . 9 + 5.2. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 9 + 5.3. TABLE_DUMP_V2 Type . . . . . . . . . . . . . . . . . . . . 11 + 5.4. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 13 + 5.4.1. BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 14 + 5.4.2. BGP4MP_MESSAGE Subtype . . . . . . . . . . . . . . . . 15 + 5.4.3. BGP4MP_STATE_CHANGE_AS4 Subtype . . . . . . . . . . . 15 + 5.4.4. BGP4MP_MESSAGE_AS4 Subtype . . . . . . . . . . . . . . 16 + 5.5. BGP4MP_ET Type . . . . . . . . . . . . . . . . . . . . . . 17 + 5.6. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 17 + 5.7. ISIS_ET Type . . . . . . . . . . . . . . . . . . . . . . . 17 + 5.8. OSPFv3 Type . . . . . . . . . . . . . . . . . . . . . . . 17 + 5.9. OSPFv3_ET Type . . . . . . . . . . . . . . . . . . . . . . 18 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 + 6.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 19 + 6.2. Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 19 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 21 + Appendix A. Deprecated MRT types . . . . . . . . . . . . . . . . 22 + A.1. Deprecated MRT Informational Types . . . . . . . . . . . . 22 + A.1.1. NULL Type . . . . . . . . . . . . . . . . . . . . . . 22 + A.1.2. DIE Type . . . . . . . . . . . . . . . . . . . . . . . 22 + A.1.3. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . 22 + A.2. Deprecated MRT Routing Information Types . . . . . . . . . 22 + A.2.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . 22 + A.2.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . 25 + A.2.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . 25 + A.2.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . 25 + A.2.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . 26 + A.2.6. Deprecated BGP4MP Subtypes . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Intellectual Property and Copyright Statements . . . . . . . . . . 29 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 @@ -179,287 +173,85 @@ The MRT format defines five Informational Type messages. These messages are intended to signal the state of an MRT data collector and do not contain routing information. These messages are OPTIONAL and were largely intended for use when MRT messages are sent over a network to a remote repository store. However, MRT message repository stores have traditionally resided on the same device as the collector and these Informational Types have seen limited implementation. Further, transport mechanisms for MRT messages are considered to be outside the scope of this document. - Two of these messages are considered potentially useful in - implementations with a local repository. In particular, the START - and I_AM_DEAD messages MAY be used to provide a time reference when a - data collector begins and ends the collection process. + The START and I_AM_DEAD messages MAY be used to provide a time + reference when a data collector begins and ends the collection + process. The message field MAY contain an OPTIONAL message string for diagnostic purposes. The message string encoding MUST follow the UTF-8 transformation format. The Subtype field is unused for these Types and SHOULD be set to 0. The MRT Informational Types are defined below: - 0 NULL *DEPRECATED* 1 START - 2 DIE *DEPRECATED* 3 I_AM_DEAD - 4 PEER_DOWN *DEPRECATED* -4.1. NULL Type - - The NULL Type message causes no operation and is deprecated. - -4.2. START Type +4.1. START Type The START Type indicates a collector is about to begin generating MRT messages. -4.3. DIE Type - - The DIE Type signals a remote MRT repository it should stop accepting - messages. This Type is deprecated. - -4.4. I_AM_DEAD Type +4.2. I_AM_DEAD Type An I_AM_DEAD MRT message indicates that a collector has shut down and has stopped generating MRT messages. -4.5. PEER_DOWN Type - - The PEER_DOWN message was intended to indicate that a collector had - lost association with a BGP peer. However, the MRT format provides - BGP state change message types which duplicate this functionality. - This Type is deprecated. - 5. MRT Routing Information Types The following Types are currently defined for the MRT format. Types - 5-12 were defined in the MRT Toolkit package. The BGP4MP Type, + 11 and 12 were defined in the MRT Toolkit package. The BGP4MP Type, number 16, was initially defined in the Zebra routing software package. The BGP4MP_ET, ISIS, and ISIS_ET Types were initially - defined in the Sprint Labs Python Routing Toolkit (PyRT). + defined in the Sprint Labs Python Routing Toolkit (PyRT). The OSPFv3 + and OSPFv3_ET Types are newly defined types created for the OSPFv3 + routing protocol. - 5 BGP *DEPRECATED* - 6 RIP - 7 IDRP *DEPRECATED* - 8 RIPNG - 9 BGP4PLUS *DEPRECATED* - 10 BGP4PLUS_01 *DEPRECATED* 11 OSPF 12 TABLE_DUMP 13 TABLE_DUMP_V2 16 BGP4MP 17 BGP4MP_ET 32 ISIS 33 ISIS_ET 48 OSPFv3 49 OSPFv3_ET -5.1. BGP Type - - The BGP Type indicates the Message field contains BGP routing - information. The BGP routing protocol is defined in RFC 4271 - [RFC4271]. The information in the message is dependent on the - Subtype value. The BGP Type and all associated Subtypes are - considered to be DEPRECATED by the BGP4MP 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 - -5.1.1. BGP_NULL Subtype - - The BGP_NULL Subtype is a reserved Subtype. - -5.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: - - 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 AS number | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Peer IP address | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Local AS number | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Local 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. The Peer AS number and IP address fields contain the AS - number and IP address of the remote system which are generating the - BGP UPDATE messages. The Local AS number and IP address fields - contain the AS number and IP address of the local collector system - which is archiving the messages. - -5.1.3. BGP_PREF_UPDATE Subtype - - The BGP_PREF_UPDATE Subtype is not defined. - -5.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 are defined in RFC 4271 - [RFC4271], Section 8.2.2. Both the old state value and the new state - value are encoded as 2-octet numbers. The state values are defined - numerically as follows: - - 1 Idle - 2 Connect - 3 Active - 4 OpenSent - 5 OpenConfirm - 6 Established - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Peer AS number | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Peer IP address | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Old State | New State | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -5.1.5. BGP_SYNC Subtype - - The BGP_SYNC Subtype was intended to convey a system file name where - BGP Table Dump messages should be recorded. The View # was to - correspond to the View # provided in the TABLE_DUMP Type messages. - There are no known implementations of this subtype and it SHOULD be - ignored. 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. - -5.1.6. BGP_OPEN Subtype - - 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 - BGP_UPDATE, however, the last field contains the contents of the BGP - OPEN message. - -5.1.7. BGP_NOTIFY Subtype - - 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 BGP_UPDATE, however, the last field contains the contents of the - BGP NOTIFICATION message. - -5.1.8. BGP_KEEPALIVE Subtype - - 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 BGP_UPDATE, however, the last field contains no information. - -5.2. RIP Type - - The RIP Type is used to export RIP protocol packets as defined in RFC - 1058 [RFC1058]. 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Peer IP address | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Local IP address | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | RIP Message Contents (variable) - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -5.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 - deployment of IDRP. - -5.4. RIPNG Type - - The RIPNG Type is used to export RIPNG protocol packets as defined in - RFC 2080 [RFC2080]. 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Peer IP address | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Local IP address | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | RIPNG Message Contents (variable) - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -5.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 - 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 - 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. - -5.6. OSPF Type +5.1. OSPF Type This Type supports the OSPF Protocol as defined in RFC 2328 [RFC2328]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OSPF Message Contents (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -5.7. TABLE_DUMP Type +5.2. TABLE_DUMP Type The TABLE_DUMP Type is used to encode the contents of a BGP Routing Information Base (RIB). Each RIB entry is encoded in a distinct sequential MRT record. The Subtype field is used to encode whether the RIB entry contains IPv4 or IPv6 addresses. There are two possible values for the Subtype as shown below. 1 AFI_IPv4 2 AFI_IPv6 @@ -507,21 +299,21 @@ update for this RIB 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 RIB entry. -5.8. TABLE_DUMP_V2 Type +5.3. TABLE_DUMP_V2 Type The TABLE_DUMP_V2 Type updates the TABLE_DUMP Type to include 32BIT ASN support and full support for BGP Multiprotocol extensions. It also improves upon the space efficiency of the TABLE_DUMP Type by employing an index table for peers and permitting a single MRT record per NLRI entry. The following subtypes are used with the TABLE_DUMP_V2 Type. 1 PEER_INDEX_TABLE 2 RIB_IPV4_UNICAST @@ -638,79 +430,85 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ There is one exception to the encoding of BGP attributes for the BGP MP_REACH_NLRI attribute (BGP Type Code 14) [RFC 4760]. Since the AFI, SAFI, and NLRI information is already encoded in the MULTIPROTOCOL header, only the Next Hop Address Length and Next Hop Address fields are included. The Reserved field is omitted. The attribute length is also adjusted to reflect only the length of the Next Hop Address Length and Next Hop Address fields. -5.9. BGP4MP Type +5.4. BGP4MP Type This Type was initially defined in the Zebra software package for the BGP protocol with multiprotocol extension support as defined by RFC 4760 [RFC4760]. It supersedes the BGP, BGP4PLUS, BGP4PLUS_01 Types. The BGP4MP Type has six Subtypes which are defined as follows: 0 BGP4MP_STATE_CHANGE 1 BGP4MP_MESSAGE - 2 BGP4MP_ENTRY *DEPRECATED* - 3 BGP4MP_SNAPSHOT *DEPRECATED* 4 BGP4MP_STATE_CHANGE_AS4 5 BGP4MP_MESSAGE_AS4 -5.9.1. BGP4MP_STATE_CHANGE Subtype +5.4.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: + machine. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer AS number | Local AS number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Index | Address Family | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer IP address (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local 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. - As with the BGP_STATE_CHANGE message, the FSM states are defined in - RFC 4271 [RFC4271], Section 8.2.2 with the numeric values for these - states defined inthe BGP_STATE_CHANGE section. The interface index - provides the interface number of the peering session. The index - value is OPTIONAL and MAY be zero if unknown or unsupported. The - Address Family indicates what types of addresses are in the the - address fields. At present, the following AFI Types are supported: + The FSM states are defined in RFC 4271 [RFC4271], Section 8.2.2. + Both the old state value and the new state value are encoded as + 2-octet numbers. The state values are defined numerically as + follows: + + 1 Idle + 2 Connect + 3 Active + 4 OpenSent + 5 OpenConfirm + 6 Established + + The BGP4MP_STATE_CHANGE message also includes interface index and + Address Family fields. The interface index provides the interface + number of the peering session. The index value is OPTIONAL and MAY + be zero if unknown or unsupported. The Address Family indicates what + types of addresses are in the the address fields. At present, the + following AFI Types are supported: 1 AFI_IPv4 2 AFI_IPv6 -5.9.2. BGP4MP_MESSAGE Subtype +5.4.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 - message (not simply BGP UPDATES). In order to determine the BGP + This Subtype is used to encode BGP Messages. It can be used to + encode any Type of BGP message. In order to determine the BGP message Type, the entire BGP message is included in the BGP Message field. This includes 16-octet marker, 2-ocet length, and 1-octet type fields. Note that the BGP4MP_MESSAGE Subtype does not support - 32BIT AS numbers nor IPv6 addresses. The BGP4MP_MESSAGE_AS4 Subtype - updates the BGP4MP_MESSAGE Subtype in order to support these. The - BGP4MP_MESSAGE fields are shown below: + 32BIT AS numbers. The BGP4MP_MESSAGE_AS4 Subtype updates the + BGP4MP_MESSAGE Subtype in order to support these. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer AS number | Local AS number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Index | Address Family | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer IP address (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -727,72 +525,21 @@ 1 AFI_IPv4 2 AFI_IPv6 Note that the Address Family value only applies to the IP addresses contained in the MRT header. The BGP4MP_MESSAGE Subtype is otherwise transparent to the contents of the actual message which may contain any valid AFI/SAFI values. Only one BGP message may be encoded in the BGP4MP_MESSAGE Subtype. -5.9.3. BGP4MP_ENTRY Subtype - - This Subtype is similar to the TABLE_DUMP Type and is used to record - RIB table entries. It extends the TABLE_DUMP Type to include true - multiprotocol support. However, this Type does not support 32BIT AS - numbers and has not been widely implemented. This Type is deprecated - in favor of the TABLE_DUMP_V2 which includes 32BIT AS number support - and a more compact format. - - 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 AS number | Local AS number | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Interface Index | Address Family | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Peer IP address (variable) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Local IP address (variable) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | View # | Status | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Time last change | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Address Family | SAFI | Next-Hop-Len | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Next Hop Address (variable) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Prefix Length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Address Prefix (variable) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Attribute Length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | BGP Attribute... (variable) - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -5.9.4. BGP4MP_SNAPSHOT Subtype - - This Subtype was intended to convey a system file name where - BGP4MP_ENTRY messages should be recorded. It is similar to the - BGP_SYNC message Subtype and is deprecated. - - 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) - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -5.9.5. BGP4MP_STATE_CHANGE_AS4 Subtype +5.4.3. BGP4MP_STATE_CHANGE_AS4 Subtype This Subtype updates the BGP4MP_STATE_CHANGE Subtype to support 32BIT Autonomous System numbers. As with the BGP4MP_STATE_CHANGE Subtype, the BGP FSM states are encoded in the Old State and New State fields to indicate the previous and current state. Aside from the extension of the peer and local AS fields to 32 bits, this subtype is otherwise identical to the BGP4MP_STATE_CHANGE Subtype. The BGP4MP_STATE_CHANGE_AS4 fields are shown below: 0 1 2 3 @@ -804,21 +551,21 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Index | Address Family | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer IP address (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local IP address (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Old State | New State | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -5.9.6. BGP4MP_MESSAGE_AS4 Subtype +5.4.4. BGP4MP_MESSAGE_AS4 Subtype This Subtype updates the BGP4MP_MESSAGE Subtype to support 32BIT Autonomous System numbers. The BGP4MP_MESSAGE_AS4 Subtype is otherwise identical to the BGP4MP_MESSAGE Subtype. The BGP4MP_MESSAGE_AS4 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer AS number | @@ -827,21 +574,21 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Index | Address Family | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer IP address (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local IP address (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BGP Message... (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -5.10. BGP4MP_ET Type +5.5. BGP4MP_ET Type This Type was initially defined in the Sprint Labs Python Routing Toolkit (PyRT). It extends the MRT common header field to include a 32BIT microsecond timestamp field. The type and subtype field definitions remain as defined for the BGP4MP Type. The 32BIT microsecond timestamp immediately follows the length field in the MRT common header and precedes all other fields in the message. The 32BIT microsecond field is included in the computation of the length field value. The MRT common header modification is illustrated below. @@ -853,55 +600,55 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | microsecond timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message... (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -5.11. ISIS Type +5.6. 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 [RFC1195]. 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. -5.12. ISIS_ET Type +5.7. ISIS_ET Type The ISIS_ET Type extends the ISIS Type to support microsecond timestamps. As with the BGP4MP_ET Type, a 32BIT 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. -5.13. OSPFv3 Type +5.8. OSPFv3 Type The OSPFv3 Type extends the original OSPF Type to support IPv6 addresses for the OSPFv3 protocol as defined in RFC 2740 [RFC2740]. The format of the MRT Message field for the OSPFv3 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote IP address (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local IP address (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OSPF Message Contents (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -5.14. OSPFv3_ET Type +5.9. OSPFv3_ET Type The OSPFv3_ET Type extends the OSPFv3 Type to support microsecond timestamps. As with the BGP4MP_ET Type, a 32BIT microsecond timestamp field is appended to the MRT common header after the length field and its length is included in the calculation of the length field value. The OSPFv3_ET Type is otherwise identical to the OSPFv3 Type. 6. IANA Considerations @@ -978,20 +725,301 @@ [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. 8.2. Informative References [MRT PROG GUIDE] Labovitz, C., "MRT Programmer's Guide", November 1999, . +Appendix A. Deprecated MRT types + + This Appendix lists deprecated MRT types. These types are documented + for informational purposes only. While documented in some + references, they are not known to have been generally implemented. + +A.1. Deprecated MRT Informational Types + + The deprecated MRT Informational Types are defined below: + + 0 NULL + 2 DIE + 4 PEER_DOWN + +A.1.1. NULL Type + + The NULL Type message causes no operation. + +A.1.2. DIE Type + + The DIE Type signals a remote MRT repository it should stop accepting + messages. + +A.1.3. PEER_DOWN Type + + The PEER_DOWN message was intended to indicate that a collector had + lost association with a BGP peer. However, the MRT format provides + BGP state change message types which duplicate this functionality. + +A.2. Deprecated MRT Routing Information Types + + 5 BGP + 6 RIP + 7 IDRP + 8 RIPNG + 9 BGP4PLUS + 10 BGP4PLUS_01 + +A.2.1. BGP Type + + The BGP Type indicates the Message field contains BGP routing + information. The BGP routing protocol is defined in RFC 4271 + [RFC4271]. The information in the message is dependent on the + Subtype value. The BGP Type and all associated Subtypes below are + considered to be deprecated by the BGP4MP Type. + + The following BGP Subtypes are defined for the MRT BGP Type. As with + the BGP Type itself, they are all considered to be deprecated. + + 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 + +A.2.1.1. BGP_NULL Subtype + + The BGP_NULL Subtype is a reserved Subtype. + +A.2.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: + + 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 AS number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Peer IP address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Local AS number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Local 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. The Peer AS number and IP address fields contain the AS + number and IP address of the remote system which are generating the + BGP UPDATE messages. The Local AS number and IP address fields + contain the AS number and IP address of the local collector system + which is archiving the messages. + +A.2.1.3. BGP_PREF_UPDATE Subtype + + The BGP_PREF_UPDATE Subtype is not defined. + +A.2.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 are defined in RFC 4271 + [RFC4271], Section 8.2.2. Both the old state value and the new state + value are encoded as 2-octet numbers. The state values are defined + numerically as follows: + + 1 Idle + 2 Connect + 3 Active + 4 OpenSent + 5 OpenConfirm + 6 Established + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Peer AS number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Peer IP address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Old State | New State | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +A.2.1.5. BGP_SYNC Subtype + + The BGP_SYNC Subtype was intended to convey a system file name where + BGP Table Dump messages should be recorded. The View # was to + correspond to the View # provided in the TABLE_DUMP Type messages. + There are no known implementations of this subtype and it SHOULD be + ignored. 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. + +A.2.1.6. BGP_OPEN Subtype + + 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 + BGP_UPDATE, however, the last field contains the contents of the BGP + OPEN message. + +A.2.1.7. BGP_NOTIFY Subtype + + 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 BGP_UPDATE, however, the last field contains the contents of the + BGP NOTIFICATION message. + +A.2.1.8. BGP_KEEPALIVE Subtype + + 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 BGP_UPDATE, however, the last field contains no information. + +A.2.2. RIP Type + + The RIP Type is used to export RIP protocol packets as defined in RFC + 1058 [RFC1058]. 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Peer IP address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Local IP address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RIP Message Contents (variable) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +A.2.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 + deployment of IDRP. + +A.2.4. RIPNG Type + + The RIPNG Type is used to export RIPNG protocol packets as defined in + RFC 2080 [RFC2080]. The RIPNG protocol updates the RIP protocol to + support IPv6. 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Peer IPv6 address ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Local IPv6 address ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RIPNG Message Contents (variable) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +A.2.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 + 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 + 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. + +A.2.6. Deprecated BGP4MP Subtypes + + The following two subtypes of the BGP4MP Type are considered to be + deprecated. + + 2 BGP4MP_ENTRY + 3 BGP4MP_SNAPSHOT + +A.2.6.1. BGP4MP_ENTRY Subtype + + This Subtype is similar to the TABLE_DUMP Type and is used to record + RIB table entries. It extends the TABLE_DUMP Type to include true + multiprotocol support. However, this Type does not support 32BIT AS + numbers and has not been widely implemented. This Type is deprecated + in favor of the TABLE_DUMP_V2 which includes 32BIT AS number support + and a more compact format. + + 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 AS number | Local AS number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Interface Index | Address Family | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Peer IP address (variable) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Local IP address (variable) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | View # | Status | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Time last change | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Address Family | SAFI | Next-Hop-Len | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Next Hop Address (variable) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Prefix Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Address Prefix (variable) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attribute Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | BGP Attribute... (variable) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +A.2.6.2. BGP4MP_SNAPSHOT Subtype + + This Subtype was intended to convey a system file name where + BGP4MP_ENTRY messages should be recorded. It is similar to the + BGP_SYNC message Subtype and is deprecated. + + 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) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Authors' Addresses Larry Blunk Merit Network Email: ljb@merit.edu Manish Karir Merit Network