idnits 2.17.1 draft-ietf-grow-mrt-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 25, 2009) is 5539 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 4760' is mentioned on line 446, but not defined ** Downref: Normative reference to an Historic RFC: RFC 1058 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Blunk 3 Internet-Draft M. Karir 4 Intended status: Standards Track Merit Network 5 Expires: August 29, 2009 C. Labovitz 6 Arbor Networks 7 February 25, 2009 9 MRT routing information export format 10 draft-ietf-grow-mrt-09.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 29, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This document describes the MRT format for routing information 49 export. This format was developed in concert with the Multi-threaded 50 Routing Toolkit (MRT) from whence the format takes it name. The 51 format can be used to export routing protocol messages, state 52 changes, and routing information base contents. 54 Table of Contents 56 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Basic MRT Format . . . . . . . . . . . . . . . . . . . . . . . 6 59 4. MRT Informational Types . . . . . . . . . . . . . . . . . . . 8 60 4.1. START Type . . . . . . . . . . . . . . . . . . . . . . . . 8 61 4.2. I_AM_DEAD Type . . . . . . . . . . . . . . . . . . . . . . 8 62 5. MRT Routing Information Types . . . . . . . . . . . . . . . . 9 63 5.1. OSPF Type . . . . . . . . . . . . . . . . . . . . . . . . 9 64 5.2. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 9 65 5.3. TABLE_DUMP_V2 Type . . . . . . . . . . . . . . . . . . . . 11 66 5.4. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 13 67 5.4.1. BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 14 68 5.4.2. BGP4MP_MESSAGE Subtype . . . . . . . . . . . . . . . . 15 69 5.4.3. BGP4MP_STATE_CHANGE_AS4 Subtype . . . . . . . . . . . 15 70 5.4.4. BGP4MP_MESSAGE_AS4 Subtype . . . . . . . . . . . . . . 16 71 5.5. BGP4MP_ET Type . . . . . . . . . . . . . . . . . . . . . . 17 72 5.6. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 17 73 5.7. ISIS_ET Type . . . . . . . . . . . . . . . . . . . . . . . 17 74 5.8. OSPFv3 Type . . . . . . . . . . . . . . . . . . . . . . . 17 75 5.9. OSPFv3_ET Type . . . . . . . . . . . . . . . . . . . . . . 18 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 77 6.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 19 78 6.2. Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 19 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 82 8.2. Informative References . . . . . . . . . . . . . . . . . . 21 83 Appendix A. Deprecated MRT types . . . . . . . . . . . . . . . . 22 84 A.1. Deprecated MRT Informational Types . . . . . . . . . . . . 22 85 A.1.1. NULL Type . . . . . . . . . . . . . . . . . . . . . . 22 86 A.1.2. DIE Type . . . . . . . . . . . . . . . . . . . . . . . 22 87 A.1.3. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . 22 88 A.2. Deprecated MRT Routing Information Types . . . . . . . . . 22 89 A.2.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . 22 90 A.2.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . 25 91 A.2.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . 25 92 A.2.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . 25 93 A.2.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . 26 94 A.2.6. Deprecated BGP4MP Subtypes . . . . . . . . . . . . . . 26 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 97 1. Requirements notation 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 2. Introduction 105 Researchers and engineers often wish to analyze network behavior by 106 studying routing protocol transactions and routing information base 107 snapshots. To this end, the MRT format was developed to encapsulate, 108 export, and archive this information in a standardized data 109 representation. The BGP routing protocol, in particular, has been 110 the subject of extensive study and analysis which has been 111 significantly aided by the availability of the MRT format. The MRT 112 format was initially defined in the MRT Programmer's Guide [MRT PROG 113 GUIDE]. 115 This memo serves to document the MRT format as currently implemented 116 in publicly available software. The format has been extended since 117 it's original introduction in the MRT toolset and these extensions 118 are also included in this memo. Further extensions may be introduced 119 at a later date through additional definitions of the MRT Type field 120 and Subtype fields. 122 A number of MRT message types have been documented in some references 123 but are not known to have been implemented. Further, several types 124 were employed in early MRT implementations, but are no longer 125 actively being used. These types are considered to be deprecated and 126 are documented in a separate appendix at the end of this document. 127 Some of the deprecated types may of interest to researchers examining 128 historical MRT archives. 130 Fields which contain multi-octet numeric values are encoded in 131 network octet order from most significant octet to least significant 132 octet. Fields which contain routing message fields are encoded in 133 the same order as they appear in the packet contents. 135 3. Basic MRT Format 137 All MRT format messages have a common header which includes a 138 timestamp, Type, Subtype, and length field. The header is followed 139 by a message field. The MRT common header is illustrated below. 141 0 1 2 3 142 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 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Timestamp | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Type | Subtype | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Length | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Message... (variable) 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 Header Field Descriptions: 155 Timestamp: 157 Time in seconds since 1 January 1970 00:00:00 UTC 159 Type: 161 A 2-octet field that indicates the Type of information 162 contained in the message field. Types 0 through 4 are 163 informational messages pertaining to the state of an MRT 164 collector, while Types 5 and higher are used to convey routing 165 information. 167 Subtype: 169 A 2-octet field that is used to further distinguish message 170 information within a particular message Type. 172 Length: 174 A 4-octet message length field. The length field contains the 175 number of octets within the message. The length field does not 176 include the length of the MRT common header. 178 Message: 180 A variable length message. The contents of this field are 181 context dependent upon the Type and Subtype fields. 183 4. MRT Informational Types 185 The MRT format defines five Informational Type messages. These 186 messages are intended to signal the state of an MRT data collector 187 and do not contain routing information. These messages are OPTIONAL 188 and were largely intended for use when MRT messages are sent over a 189 network to a remote repository store. However, MRT message 190 repository stores have traditionally resided on the same device as 191 the collector and these Informational Types have seen limited 192 implementation. Further, transport mechanisms for MRT messages are 193 considered to be outside the scope of this document. 195 The START and I_AM_DEAD messages MAY be used to provide a time 196 reference when a data collector begins and ends the collection 197 process. The time reference is obtained from the Timestamp field in 198 the MRT message header. 200 The message field MAY contain an OPTIONAL message string for 201 diagnostic purposes. The message string encoding MUST follow the 202 UTF-8 transformation format. The Subtype field is unused for these 203 Types and SHOULD be set to 0. 205 The MRT Informational Types are defined below: 207 1 START 208 3 I_AM_DEAD 210 4.1. START Type 212 The START Type indicates a collector is about to begin generating MRT 213 messages. 215 4.2. I_AM_DEAD Type 217 An I_AM_DEAD MRT message indicates that a collector has shut down and 218 has stopped generating MRT messages. 220 5. MRT Routing Information Types 222 The following Types are currently defined for the MRT format. Types 223 11 and 12 were defined in the MRT Toolkit package. The BGP4MP Type, 224 number 16, was initially defined in the Zebra routing software 225 package. The BGP4MP_ET, ISIS, and ISIS_ET Types were initially 226 defined in the Sprint Labs Python Routing Toolkit (PyRT). The OSPFv3 227 and OSPFv3_ET Types are newly defined types created for the OSPFv3 228 routing protocol. 230 11 OSPF 231 12 TABLE_DUMP 232 13 TABLE_DUMP_V2 233 16 BGP4MP 234 17 BGP4MP_ET 235 32 ISIS 236 33 ISIS_ET 237 48 OSPFv3 238 49 OSPFv3_ET 240 5.1. OSPF Type 242 This Type supports the OSPF Protocol as defined in RFC 2328 243 [RFC2328]. The Subtype field may contain two possible values: 245 0 OSPF_STATE_CHANGE 246 1 OSPF_LSA_UPDATE 248 The format of the MRT Message field for the OSPF Type is as follows: 250 0 1 2 3 251 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 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Remote IP address | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Local IP address | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | OSPF Message Contents (variable) 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 5.2. TABLE_DUMP Type 262 The TABLE_DUMP Type is used to encode the contents of a BGP Routing 263 Information Base (RIB). Each RIB entry is encoded in a distinct 264 sequential MRT record. The Subtype field is used to encode whether 265 the RIB entry contains IPv4 or IPv6 addresses. There are two 266 possible values for the Subtype as shown below. 268 1 AFI_IPv4 269 2 AFI_IPv6 271 The format of the TABLE_DUMP Type is illustrated below. 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | View # | Sequence number | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Prefix (variable) | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Prefix Length | Status | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Originated Time | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Peer IP address (variable) | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Peer AS | Attribute Length | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | BGP Attribute... (variable) 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 The View field is normally 0 and is intended for cases where an 292 implementation may have multiple RIB views (such as a route server). 293 The Sequence field is a simple incremental counter for each RIB 294 entry. A typical RIB dump will exceed the 16-bit bounds of this 295 counter and implementation should simply wrap back to zero and 296 continue incrementing the counter in such cases. 298 The Prefix field contains the IP address of a particular RIB entry. 299 The size of this field is dependent on the value of the Subtype for 300 this message. For AFI_IPv4, this field is 4 octets, for AFI_IPv6, it 301 is 16 octets in length. The Prefix Length field indicates the length 302 in bits of the prefix mask for the preceding Prefix field. 304 The Status octet is not used in the TABLE_DUMP Type and SHOULD be set 305 to 1. 307 The Originated Time contains the 4-octet time at which this prefix 308 was heard. The value represents the time in seconds since 1 January 309 1970 00:00:00 UTC. 311 The Peer IP field is the IP address of the peer which provided the 312 update for this RIB entry. As with the Prefix field, the size of 313 this field is dependent on the Subtype. AFI_IPv4 indicates a 4 octet 314 field and an IPv4 address, while a Subtype of AFI_IPv6 requires a 16 315 octet field and an IPv6 address. The Peer AS field contains the AS 316 number of the peer. 318 Attribute length is the length of Attribute field and is 2-octets. 319 The Attribute field contains the attribute information for the RIB 320 entry. 322 5.3. TABLE_DUMP_V2 Type 324 The TABLE_DUMP_V2 Type updates the TABLE_DUMP Type to include 32BIT 325 ASN support and full support for BGP Multiprotocol extensions. It 326 also improves upon the space efficiency of the TABLE_DUMP Type by 327 employing an index table for peers and permitting a single MRT record 328 per NLRI entry. The following subtypes are used with the 329 TABLE_DUMP_V2 Type. 331 1 PEER_INDEX_TABLE 332 2 RIB_IPV4_UNICAST 333 3 RIB_IPV4_MULTICAST 334 4 RIB_IPV6_UNICAST 335 5 RIB_IPV6_MULTICAST 336 6 RIB_GENERIC 338 An initial PEER_INDEX_TABLE MRT record provides the BGP ID of the 339 collector, an optional view name, and a list of indexed peers. 340 Following the PEER_INDEX_TABLE MRT record, a series of MRT records 341 are used to encode RIB table entries. This series of MRT records use 342 subtypes 2-6 and are separate from the PEER_INDEX_TABLE MRT record 343 itself and include full MRT record headers. The header of the 344 PEER_INDEX_TABLE Subtype is shown below. The View Name is optional 345 and, if not present, the View Name Length MUST be set to 0. The View 346 Name encoding MUST follow the UTF-8 transformation format. 348 0 1 2 3 349 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 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Collector BGP ID | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | View Name Length | View Name (variable) | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Peer Count | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 The format of the peer entries is shown below. The PEER_INDEX_TABLE 359 record contains Peer Count peer entries. 361 0 1 2 3 362 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 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Peer Type | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Peer BGP ID | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Peer IP address (variable) | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Peer AS (variable) | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 The Peer Type, Peer BGP ID, Peer IP, and Peer AS fields are repeated 374 as indicated by the Peer Count field. The position of the Peer in 375 the PEER_INDEX_TABLE is used as an index in the subsequent 376 TABLE_DUMP_V2 MRT records. The index number begins with 0. 378 The Peer Type field is a bit field which encodes the type of the AS 379 and IP address as follows: 381 Bit 0 - unset for IPv4 Peer IP address, set for IPv6 382 Bit 1 - unset when Peer AS is 16 bits, set when it's 32 bits 384 The records which follow the PEER_INDEX_TABLE record constitute the 385 RIB entries and include a header which specifies a sequence number, 386 NLRI, and a count of the number of RIB entries which follow. 388 The format for the RIB_IPV4_UNICAST, RIB_IPV4_MULTICAST, 389 RIB_IPV6_UNICAST, and RIB_IPV6_MULTICAST headers are shown below. 390 The Prefix Length and Prefix fields are encoded in the same manner as 391 the BGP NLRI encoding for IPV4 and IPV6 prefixes. Namely, the Prefix 392 field contains address prefixes followed by enough trailing bits to 393 make the end of the field fall on an octet boundary. Note that the 394 value of trailing bits is irrelevant. 396 0 1 2 3 397 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 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Sequence number | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Prefix Length | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Prefix (variable) | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Entry Count | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 The RIB_GENERIC header is shown below. It includes Address Family 409 Identifier (AFI), Subsequent AFI and a single NLRI entry. The NLRI 410 information is specific to the AFI and SAFI values. An 411 implementation which does not recognize particular AFI and SAFI 412 values SHOULD discard the remainder of the MRT record. 414 0 1 2 3 415 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 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Sequence number | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Address Family Identifier |Subsequent AFI | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Network Layer Reachability Information (variable) | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Entry Count | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 The RIB entry headers are followed by a series of RIB entries which 427 are repeated Entry Count times. These entries share a common format 428 as shown below. They include a Peer Index from the PEER_INDEX_TABLE 429 MRT record, an originated time for the RIB entry, and the BGP path 430 attribute length and attributes encoded as provided in a BGP Update 431 message. 433 0 1 2 3 434 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 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Peer Index | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Originated Time | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Attribute Length | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | BGP Attributes... (variable) 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 There is one exception to the encoding of BGP attributes for the BGP 446 MP_REACH_NLRI attribute (BGP Type Code 14) [RFC 4760]. Since the 447 AFI, SAFI, and NLRI information is already encoded in the 448 MULTIPROTOCOL header, only the Next Hop Address Length and Next Hop 449 Address fields are included. The Reserved field is omitted. The 450 attribute length is also adjusted to reflect only the length of the 451 Next Hop Address Length and Next Hop Address fields. 453 5.4. BGP4MP Type 455 This Type was initially defined in the Zebra software package for the 456 BGP protocol with multiprotocol extension support as defined by RFC 457 4760 [RFC4760]. It supersedes the BGP, BGP4PLUS, BGP4PLUS_01 Types. 458 The BGP4MP Type has six Subtypes which are defined as follows: 460 0 BGP4MP_STATE_CHANGE 461 1 BGP4MP_MESSAGE 462 4 BGP4MP_STATE_CHANGE_AS4 463 5 BGP4MP_MESSAGE_AS4 465 5.4.1. BGP4MP_STATE_CHANGE Subtype 467 This record is used to encode state changes in the BGP finite state 468 machine. The BGP FSM states are encoded in the Old State and New 469 State fields to indicate the previous and current state. The format 470 is illustrated below: 472 0 1 2 3 473 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 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Peer AS number | Local AS number | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Interface Index | Address Family | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Peer IP address (variable) | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Local IP address (variable) | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Old State | New State | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 The FSM states are defined in RFC 4271 [RFC4271], Section 8.2.2. 487 Both the old state value and the new state value are encoded as 488 2-octet numbers. The state values are defined numerically as 489 follows: 491 1 Idle 492 2 Connect 493 3 Active 494 4 OpenSent 495 5 OpenConfirm 496 6 Established 498 The BGP4MP_STATE_CHANGE message also includes interface index and 499 Address Family fields. The interface index provides the interface 500 number of the peering session. The index value is OPTIONAL and MAY 501 be zero if unknown or unsupported. The Address Family indicates what 502 types of addresses are in the the address fields. At present, the 503 following AFI Types are supported: 505 1 AFI_IPv4 506 2 AFI_IPv6 508 5.4.2. BGP4MP_MESSAGE Subtype 510 This Subtype is used to encode BGP Messages. It can be used to 511 encode any Type of BGP message. In order to determine the BGP 512 message Type, the entire BGP message is included in the BGP Message 513 field. This includes the 16-octet marker, the 2-octet length, and 514 the 1-octet type fields. Note that the BGP4MP_MESSAGE Subtype does 515 not support 32BIT AS numbers. The BGP4MP_MESSAGE_AS4 Subtype updates 516 the BGP4MP_MESSAGE Subtype in order to support 32BIT AS numbers. The 517 BGP4MP_MESSAGE fields are shown below: 519 0 1 2 3 520 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 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Peer AS number | Local AS number | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | Interface Index | Address Family | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Peer IP address (variable) | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Local IP address (variable) | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | BGP Message... (variable) 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 The interface index provides the interface number of the peering 534 session. The index value is OPTIONAL and MAY be zero if unknown or 535 unsupported. The Address Family indicates what types of addresses 536 are in the the subsequent address fields. At present, the following 537 AFI Types are supported: 539 1 AFI_IPv4 540 2 AFI_IPv6 542 Note that the Address Family value only applies to the IP addresses 543 contained in the MRT header. The BGP4MP_MESSAGE Subtype is otherwise 544 transparent to the contents of the actual message which may contain 545 any valid AFI/SAFI values. Only one BGP message may be encoded in 546 the BGP4MP_MESSAGE Subtype. 548 5.4.3. BGP4MP_STATE_CHANGE_AS4 Subtype 550 This Subtype updates the BGP4MP_STATE_CHANGE Subtype to support 32BIT 551 Autonomous System numbers. As with the BGP4MP_STATE_CHANGE Subtype, 552 the BGP FSM states are encoded in the Old State and New State fields 553 to indicate the previous and current state. Aside from the extension 554 of the peer and local AS fields to 32 bits, this subtype is otherwise 555 identical to the BGP4MP_STATE_CHANGE Subtype. The 556 BGP4MP_STATE_CHANGE_AS4 fields are shown below: 558 0 1 2 3 559 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 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Peer AS number | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Local AS number | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Interface Index | Address Family | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Peer IP address (variable) | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Local IP address (variable) | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Old State | New State | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 5.4.4. BGP4MP_MESSAGE_AS4 Subtype 576 This Subtype updates the BGP4MP_MESSAGE Subtype to support 32BIT 577 Autonomous System numbers. The BGP4MP_MESSAGE_AS4 Subtype is 578 otherwise identical to the BGP4MP_MESSAGE Subtype. The 579 BGP4MP_MESSAGE_AS4 fields are shown below: 581 0 1 2 3 582 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 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Peer AS number | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | Local AS number | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Interface Index | Address Family | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Peer IP address (variable) | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Local IP address (variable) | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | BGP Message... (variable) 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 5.5. BGP4MP_ET Type 599 This Type was initially defined in the Sprint Labs Python Routing 600 Toolkit (PyRT). It extends the MRT common header field to include a 601 32BIT microsecond timestamp field. The type and subtype field 602 definitions remain as defined for the BGP4MP Type. The 32BIT 603 microsecond timestamp immediately follows the length field in the MRT 604 common header and precedes all other fields in the message. The 605 32BIT microsecond field is included in the computation of the length 606 field value. The MRT common header modification is illustrated 607 below. 609 0 1 2 3 610 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 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Timestamp | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Type | Subtype | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Length | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | microsecond timestamp | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Message... (variable) 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 5.6. ISIS Type 625 This Type was initially defined in the Sprint Labs Python Routing and 626 supports the IS-IS routing protocol as defined in RFC 1195 [RFC1195]. 627 There is no Type specific header for the ISIS Type. The Subtype code 628 for this Type is undefined. The ISIS PDU directly follows the MRT 629 common header fields. 631 5.7. ISIS_ET Type 633 The ISIS_ET Type extends the ISIS Type to support microsecond 634 timestamps. As with the BGP4MP_ET Type, a 32BIT microsecond 635 timestamp field is appended to the MRT common header after the length 636 field. The ISIS_ET Type is otherwise identical to the ISIS Type. 638 5.8. OSPFv3 Type 640 The OSPFv3 Type extends the original OSPF Type to support IPv6 641 addresses for the OSPFv3 protocol as defined in RFC 5340 [RFC5340]. 642 The format of the MRT Message field for the OSPFv3 Type is as 643 follows: 645 0 1 2 3 646 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 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | Address Family | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 | Remote IP address (variable) | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | Local IP address (variable) | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | OSPF Message Contents (variable) 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 5.9. OSPFv3_ET Type 659 The OSPFv3_ET Type extends the OSPFv3 Type to support microsecond 660 timestamps. As with the BGP4MP_ET Type, a 32BIT microsecond 661 timestamp field is appended to the MRT common header after the length 662 field and its length is included in the calculation of the length 663 field value. The OSPFv3_ET Type is otherwise identical to the OSPFv3 664 Type. 666 6. IANA Considerations 668 This section provides guidance to the Internet Assigned Numbers 669 Authority (IANA) regarding registration of values related to the MRT 670 specification, in accordance with BCP 26, RFC 5226 [RFC5226]. 672 There are two name spaces in MRT that require registration: Type 673 Codes and Subtype Codes. 675 MRT is not intended as a general-purpose specification for protocol 676 information export, and allocations should not be made for purposes 677 unrelated to routing protocol information export. 679 The following policies are used here with the meanings defined in BCP 680 26: "Specification Required", "IETF Consensus". 682 6.1. Type Codes 684 Type Codes have a range from 0 to 65535, of which 0-64 have been 685 allocated. New Type Codes MUST be allocated starting at 65. Type 686 Codes 65 - 32767 are to be assigned by IETF Consensus. Type Codes 687 32768 - 65535 are assigned based on Specification Required. 689 6.2. Subtype Codes 691 Subtype Codes have a range from 0 to 65535. Subtype definitions are 692 specific to a particular Type Code definition. New Subtype Code 693 definition must reference an existing Type Code to which the Subtype 694 belongs. As Subtype Codes are specific to Type Codes, new numbers 695 must be unique for the particular Type Code to which the Subtype 696 applies. Subtype Codes specific to the Type Codes 0 - 32767 are 697 assigned by IETF Consensus. Subtype Codes specific to Type Codes 698 32768 - 65535 are assigned based on Specification Required. 700 7. Security Considerations 702 The MRT Format utilizes a structure which can store routing protocol 703 information data. The fields defined in the MRT specification are of 704 a descriptive nature and provide information that is useful to 705 facilitate the analysis of routing data. As such, the fields 706 currently defined in the MRT specification do not in themselves 707 create additional security risks, since the fields are not used to 708 induce any particular behavior by the recipient application. 710 8. References 712 8.1. Normative References 714 [RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, 715 June 1988. 717 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 718 dual environments", RFC 1195, December 1990. 720 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 721 January 1997. 723 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 724 Requirement Levels", BCP 14, RFC 2119, March 1997. 726 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 728 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 729 Protocol 4 (BGP-4)", RFC 4271, January 2006. 731 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 732 "Multiprotocol Extensions for BGP-4", RFC 4760, 733 January 2007. 735 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 736 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 737 May 2008. 739 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 740 for IPv6", RFC 5340, July 2008. 742 8.2. Informative References 744 [MRT PROG GUIDE] 745 Labovitz, C., "MRT Programmer's Guide", November 1999, 746 . 748 Appendix A. Deprecated MRT types 750 This Appendix lists deprecated MRT types. These types are documented 751 for informational purposes only. While documented in some 752 references, they are not known to have been generally implemented. 754 A.1. Deprecated MRT Informational Types 756 The deprecated MRT Informational Types are defined below: 758 0 NULL 759 2 DIE 760 4 PEER_DOWN 762 A.1.1. NULL Type 764 The NULL Type message causes no operation. 766 A.1.2. DIE Type 768 The DIE Type signals a remote MRT repository it should stop accepting 769 messages. 771 A.1.3. PEER_DOWN Type 773 The PEER_DOWN message was intended to indicate that a collector had 774 lost association with a BGP peer. However, the MRT format provides 775 BGP state change message types which duplicate this functionality. 777 A.2. Deprecated MRT Routing Information Types 779 5 BGP 780 6 RIP 781 7 IDRP 782 8 RIPNG 783 9 BGP4PLUS 784 10 BGP4PLUS_01 786 A.2.1. BGP Type 788 The BGP Type indicates the Message field contains BGP routing 789 information. The BGP routing protocol is defined in RFC 4271 790 [RFC4271]. The information in the message is dependent on the 791 Subtype value. The BGP Type and all associated Subtypes below are 792 considered to be deprecated by the BGP4MP Type. 794 The following BGP Subtypes are defined for the MRT BGP Type. As with 795 the BGP Type itself, they are all considered to be deprecated. 797 0 BGP_NULL 798 1 BGP_UPDATE 799 2 BGP_PREF_UPDATE 800 3 BGP_STATE_CHANGE 801 4 BGP_SYNC 802 5 BGP_OPEN 803 6 BGP_NOTIFY 804 7 BGP_KEEPALIVE 806 A.2.1.1. BGP_NULL Subtype 808 The BGP_NULL Subtype is a reserved Subtype. 810 A.2.1.2. BGP_UPDATE Subtype 812 The BGP_UPDATE Subtype is used to encode BGP UPDATE messages. The 813 format of the MRT Message field for this Subtype is as follows: 815 0 1 2 3 816 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 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | Peer AS number | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 | Peer IP address | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | Local AS number | 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 | Local IP address | 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | BGP UPDATE Contents (variable) 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 The BGP UPDATE Contents include the entire BGP UPDATE message which 830 follows the BGP Message Header. The BGP Message Header itself is not 831 included. The Peer AS number and IP address fields contain the AS 832 number and IP address of the remote system which are generating the 833 BGP UPDATE messages. The Local AS number and IP address fields 834 contain the AS number and IP address of the local collector system 835 which is archiving the messages. 837 A.2.1.3. BGP_PREF_UPDATE Subtype 839 The BGP_PREF_UPDATE Subtype is not defined. 841 A.2.1.4. BGP_STATE_CHANGE Subtype 843 The BGP_STATE_CHANGE Subtype is used to record changes in the BGP 844 finite state machine. These FSM states are defined in RFC 4271 846 [RFC4271], Section 8.2.2. Both the old state value and the new state 847 value are encoded as 2-octet numbers. The state values are defined 848 numerically as follows: 850 1 Idle 851 2 Connect 852 3 Active 853 4 OpenSent 854 5 OpenConfirm 855 6 Established 857 The format of the MRT Message field is as follows: 859 0 1 2 3 860 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 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | Peer AS number | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | Peer IP address | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | Old State | New State | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 A.2.1.5. BGP_SYNC Subtype 871 The BGP_SYNC Subtype was intended to convey a system file name where 872 BGP Table Dump messages should be recorded. The View # was to 873 correspond to the View # provided in the TABLE_DUMP Type messages. 874 There are no known implementations of this subtype and it SHOULD be 875 ignored. The following format applies to this Subtype: 877 0 1 2 3 878 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 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 | View # | 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | File Name... (variable) 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 The File Name is terminated with a NULL (0) character. 887 A.2.1.6. BGP_OPEN Subtype 889 The BGP_OPEN Subtype is used to encode BGP OPEN messages. The format 890 of the MRT Message field for this Subtype is the same as the 891 BGP_UPDATE, however, the last field contains the contents of the BGP 892 OPEN message. 894 A.2.1.7. BGP_NOTIFY Subtype 896 The BGP_NOTIFY Subtype is used to encode BGP NOTIFICATION messages. 897 The format of the MRT Message field for this Subtype is the same as 898 the BGP_UPDATE, however, the last field contains the contents of the 899 BGP NOTIFICATION message. 901 A.2.1.8. BGP_KEEPALIVE Subtype 903 The BGP_KEEPALIVE Subtype is used to encode BGP KEEPALIVE messages. 904 The format of the MRT Message field for this Subtype is the same as 905 the BGP_UPDATE, however, the last field contains no information. 907 A.2.2. RIP Type 909 The RIP Type is used to export RIP protocol packets as defined in RFC 910 1058 [RFC1058]. The Subtype field is currently reserved for this 911 Type and SHOULD be set to 0. 913 The format of the MRT Message field for the RIP Type is as follows: 915 0 1 2 3 916 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 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | Peer IP address | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | Local IP address | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | RIP Message Contents (variable) 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 A.2.3. IDRP Type 927 The IDRP Type is used to export Inter-Domain-Routing Protocol (IDRP) 928 protocol information as defined in the ISO/IEC 10747 standard. The 929 Subtype field is unused. This Type is deprecated due to lack of 930 deployment of IDRP. 932 A.2.4. RIPNG Type 934 The RIPNG Type is used to export RIPNG protocol packets as defined in 935 RFC 2080 [RFC2080]. The RIPNG protocol updates the RIP protocol to 936 support IPv6. The Subtype field is currently reserved for this Type 937 and SHOULD be set to 0. 939 The format of the MRT Message field for the RIPNG Type is as follows: 941 0 1 2 3 942 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 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | | 945 ~ Peer IPv6 address ~ 946 | | 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | | 949 ~ Local IPv6 address ~ 950 | | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 | RIPNG Message Contents (variable) 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 A.2.5. BGP4PLUS and BGP4PLUS_01 Types 957 The BGP4PLUS and BGP4PLUS_01 Types were defined to support IPv6 BGP 958 routing information. The BGP4PLUS Type was specified based on the 959 initial Internet Draft for Multiprotocol Extensions to BGP-4. The 960 BGP4PLUS_01 Type was specified to correspond to the -01 revision of 961 this Internet Draft. The two Types share the same definitions in 962 terms of their MRT format specifications. 964 The Subtype field definitions are shared with the BGP Type, however, 965 the address fields in the BGP_UPDATE, BGP_OPEN, BGP_NOTIFY, 966 BGP_KEEPALIVE, and BGP_STATE_CHANGE Subtype messages are extended to 967 16 octets for IPv6 addresses. As with the BGP Type, the BGP4PLUS and 968 BGP4PLUS_01 Types are deprecated as they superseded by the BGP4MP 969 Type. 971 A.2.6. Deprecated BGP4MP Subtypes 973 The following two subtypes of the BGP4MP Type are considered to be 974 deprecated. 976 2 BGP4MP_ENTRY 977 3 BGP4MP_SNAPSHOT 979 A.2.6.1. BGP4MP_ENTRY Subtype 981 This Subtype is similar to the TABLE_DUMP Type and is used to record 982 RIB table entries. It extends the TABLE_DUMP Type to include true 983 multiprotocol support. However, this Type does not support 32BIT AS 984 numbers and has not been widely implemented. This Type is deprecated 985 in favor of the TABLE_DUMP_V2 which includes 32BIT AS number support 986 and a more compact format. 988 0 1 2 3 989 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 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 | Peer AS number | Local AS number | 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 | Interface Index | Address Family | 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 | Peer IP address (variable) | 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 | Local IP address (variable) | 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 | View # | Status | 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 | Time last change | 1002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 | Address Family | SAFI | Next-Hop-Len | 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 | Next Hop Address (variable) | 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1007 | Prefix Length | 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 | Address Prefix (variable) | 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | Attribute Length | 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | BGP Attribute... (variable) 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 A.2.6.2. BGP4MP_SNAPSHOT Subtype 1018 This Subtype was intended to convey a system file name where 1019 BGP4MP_ENTRY messages should be recorded. It is similar to the 1020 BGP_SYNC message Subtype and is deprecated. 1022 0 1 2 3 1023 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 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 | View # | 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 | File Name... (variable) 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 Authors' Addresses 1032 Larry Blunk 1033 Merit Network 1035 Email: ljb@merit.edu 1037 Manish Karir 1038 Merit Network 1040 Email: mkarir@merit.edu 1042 Craig Labovitz 1043 Arbor Networks 1045 Email: labovit@arbor.net