idnits 2.17.1 draft-ietf-grow-mrt-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 (March 8, 2010) is 5162 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 454, 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: September 9, 2010 C. Labovitz 6 Arbor Networks 7 March 8, 2010 9 MRT routing information export format 10 draft-ietf-grow-mrt-11.txt 12 Abstract 14 This document describes the MRT format for routing information 15 export. This format was developed in concert with the Multi-threaded 16 Routing Toolkit (MRT) from whence the format takes it name. The 17 format can be used to export routing protocol messages, state 18 changes, and routing information base contents. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on September 9, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 Table of Contents 60 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Basic MRT Format . . . . . . . . . . . . . . . . . . . . . . . 6 63 4. MRT Informational Types . . . . . . . . . . . . . . . . . . . 8 64 4.1. START Type . . . . . . . . . . . . . . . . . . . . . . . . 8 65 4.2. I_AM_DEAD Type . . . . . . . . . . . . . . . . . . . . . . 8 66 5. MRT Routing Information Types . . . . . . . . . . . . . . . . 9 67 5.1. OSPF Type . . . . . . . . . . . . . . . . . . . . . . . . 9 68 5.2. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 10 69 5.3. TABLE_DUMP_V2 Type . . . . . . . . . . . . . . . . . . . . 11 70 5.4. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 14 71 5.4.1. BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 14 72 5.4.2. BGP4MP_MESSAGE Subtype . . . . . . . . . . . . . . . . 15 73 5.4.3. BGP4MP_MESSAGE_AS4 Subtype . . . . . . . . . . . . . . 16 74 5.4.4. BGP4MP_STATE_CHANGE_AS4 Subtype . . . . . . . . . . . 16 75 5.4.5. BGP4MP_MESSAGE_LOCAL Subtype . . . . . . . . . . . . . 17 76 5.4.6. BGP4MP_MESSAGE_AS4_LOCAL Subtype . . . . . . . . . . . 17 77 5.5. BGP4MP_ET Type . . . . . . . . . . . . . . . . . . . . . . 17 78 5.6. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 18 79 5.7. ISIS_ET Type . . . . . . . . . . . . . . . . . . . . . . . 18 80 5.8. OSPFv3 Type . . . . . . . . . . . . . . . . . . . . . . . 18 81 5.9. OSPFv3_ET Type . . . . . . . . . . . . . . . . . . . . . . 19 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 83 6.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 20 84 6.2. Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 20 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 87 8.1. Normative References . . . . . . . . . . . . . . . . . . . 22 88 8.2. Informative References . . . . . . . . . . . . . . . . . . 22 89 Appendix A. Deprecated MRT types . . . . . . . . . . . . . . . . 23 90 A.1. Deprecated MRT Informational Types . . . . . . . . . . . . 23 91 A.1.1. NULL Type . . . . . . . . . . . . . . . . . . . . . . 23 92 A.1.2. DIE Type . . . . . . . . . . . . . . . . . . . . . . . 23 93 A.1.3. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . 23 94 A.2. Deprecated MRT Routing Information Types . . . . . . . . . 23 95 A.2.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . 23 96 A.2.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . 26 97 A.2.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . 26 98 A.2.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . 26 99 A.2.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . 27 100 A.2.6. Deprecated BGP4MP Subtypes . . . . . . . . . . . . . . 27 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 103 1. Requirements notation 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 2. Introduction 111 Researchers and engineers often wish to analyze network behavior by 112 studying routing protocol transactions and routing information base 113 snapshots. To this end, the MRT format was developed to encapsulate, 114 export, and archive this information in a standardized data 115 representation. The BGP routing protocol, in particular, has been 116 the subject of extensive study and analysis which has been 117 significantly aided by the availability of the MRT format. The MRT 118 format was initially defined in the MRT Programmer's Guide [MRT PROG 119 GUIDE]. 121 This memo serves to document the MRT format as currently implemented 122 in publicly available software. The format has been extended since 123 it's original introduction in the MRT toolset and these extensions 124 are also included in this memo. Further extensions may be introduced 125 at a later date through additional definitions of the MRT Type field 126 and Subtype fields. 128 A number of MRT message types have been documented in some references 129 but are not known to have been implemented. Further, several types 130 were employed in early MRT implementations, but are no longer 131 actively being used. These types are considered to be deprecated and 132 are documented in a separate appendix at the end of this document. 133 Some of the deprecated types may of interest to researchers examining 134 historical MRT archives. 136 Fields which contain multi-octet numeric values are encoded in 137 network octet order from most significant octet to least significant 138 octet. Fields which contain routing message fields are encoded in 139 the same order as they appear in the packet contents. 141 3. Basic MRT Format 143 All MRT format messages have a common header which includes a 144 timestamp, Type, Subtype, and length field. The header is followed 145 by a message field. The MRT common header is illustrated below. 147 0 1 2 3 148 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 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Timestamp | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Type | Subtype | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Length | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Message... (variable) 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 Header Field Descriptions: 161 Timestamp: 163 Time in seconds since 1 January 1970 00:00:00 UTC 165 Type: 167 A 2-octet field that indicates the Type of information 168 contained in the message field. Types 0 through 4 are 169 informational messages pertaining to the state of an MRT 170 collector, while Types 5 and higher are used to convey routing 171 information. 173 Subtype: 175 A 2-octet field that is used to further distinguish message 176 information within a particular message Type. 178 Length: 180 A 4-octet message length field. The length field contains the 181 number of octets within the message. The length field does not 182 include the length of the MRT common header. 184 Message: 186 A variable length message. The contents of this field are 187 context dependent upon the Type and Subtype fields. 189 4. MRT Informational Types 191 The MRT format defines five Informational Type messages. These 192 messages are intended to signal the state of an MRT data collector 193 and do not contain routing information. These messages are OPTIONAL 194 and were largely intended for use when MRT messages are sent over a 195 network to a remote repository store. However, MRT message 196 repository stores have traditionally resided on the same device as 197 the collector and these Informational Types have seen limited 198 implementation. Further, transport mechanisms for MRT messages are 199 considered to be outside the scope of this document. 201 The START and I_AM_DEAD messages MAY be used to provide a time 202 reference when a data collector begins and ends the collection 203 process. The time reference is obtained from the Timestamp field in 204 the MRT message header. 206 The message field MAY contain an OPTIONAL message string for 207 diagnostic purposes. The message string encoding MUST follow the 208 UTF-8 transformation format. The Subtype field is unused for these 209 Types and SHOULD be set to 0. 211 The MRT Informational Types are defined below: 213 1 START 214 3 I_AM_DEAD 216 4.1. START Type 218 The START Type indicates a collector is about to begin generating MRT 219 messages. 221 4.2. I_AM_DEAD Type 223 An I_AM_DEAD MRT message indicates that a collector has shut down and 224 has stopped generating MRT messages. 226 5. MRT Routing Information Types 228 The following Types are currently defined for the MRT format. Types 229 11 and 12 were defined in the MRT Toolkit package. The BGP4MP Type, 230 number 16, was initially defined in the Zebra routing software 231 package. The BGP4MP_ET, ISIS, and ISIS_ET Types were initially 232 defined in the Sprint Labs Python Routing Toolkit (PyRT). The OSPFv3 233 and OSPFv3_ET Types are newly defined types created for the OSPFv3 234 routing protocol. 236 11 OSPF 237 12 TABLE_DUMP 238 13 TABLE_DUMP_V2 239 16 BGP4MP 240 17 BGP4MP_ET 241 32 ISIS 242 33 ISIS_ET 243 48 OSPFv3 244 49 OSPFv3_ET 246 5.1. OSPF Type 248 This Type supports the OSPF Protocol as defined in RFC 2328 249 [RFC2328]. The Subtype field may contain two possible values: 251 0 OSPF_STATE_CHANGE 252 1 OSPF_LSA_UPDATE 254 The format of the MRT Message field for the OSPF Type is as follows: 256 0 1 2 3 257 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 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Remote IP address | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Local IP address | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | OSPF Message Contents (variable) 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 5.2. TABLE_DUMP Type 268 The TABLE_DUMP Type is used to encode the contents of a BGP Routing 269 Information Base (RIB). Each RIB entry is encoded in a distinct 270 sequential MRT record. The Subtype field is used to encode whether 271 the RIB entry contains IPv4 or IPv6 addresses. There are two 272 possible values for the Subtype as shown below. 274 1 AFI_IPv4 275 2 AFI_IPv6 277 The format of the TABLE_DUMP Type is illustrated below. 279 0 1 2 3 280 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 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | View # | Sequence number | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Prefix (variable) | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Prefix Length | Status | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Originated Time | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Peer IP address (variable) | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Peer AS | Attribute Length | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | BGP Attribute... (variable) 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 The View field is normally 0 and is intended for cases where an 298 implementation may have multiple RIB views (such as a route server). 299 In cases where multiple RIB views are present, an implementation may 300 use the the view field to distinguish entries from each view. The 301 Sequence field is a simple incremental counter for each RIB entry. A 302 typical RIB dump will exceed the 16-bit bounds of this counter and 303 implementation should simply wrap back to zero and continue 304 incrementing the counter in such cases. 306 The Prefix field contains the IP address of a particular RIB entry. 307 The size of this field is dependent on the value of the Subtype for 308 this message. For AFI_IPv4, this field is 4 octets, for AFI_IPv6, it 309 is 16 octets in length. The Prefix Length field indicates the length 310 in bits of the prefix mask for the preceding Prefix field. 312 The Status octet is not used in the TABLE_DUMP Type and SHOULD be set 313 to 1. 315 The Originated Time contains the 4-octet time at which this prefix 316 was heard. The value represents the time in seconds since 1 January 317 1970 00:00:00 UTC. 319 The Peer IP field is the IP address of the peer which provided the 320 update for this RIB entry. As with the Prefix field, the size of 321 this field is dependent on the Subtype. AFI_IPv4 indicates a 4 octet 322 field and an IPv4 address, while a Subtype of AFI_IPv6 requires a 16 323 octet field and an IPv6 address. The Peer AS field contains the AS 324 number of the peer. 326 Attribute length is the length of Attribute field and is 2-octets. 327 The Attribute field contains the attribute information for the RIB 328 entry. 330 5.3. TABLE_DUMP_V2 Type 332 The TABLE_DUMP_V2 Type updates the TABLE_DUMP Type to include 4-Byte 333 ASN support and full support for BGP Multiprotocol extensions. It 334 also improves upon the space efficiency of the TABLE_DUMP Type by 335 employing an index table for peers and permitting a single MRT record 336 per NLRI entry. The following subtypes are used with the 337 TABLE_DUMP_V2 Type. 339 1 PEER_INDEX_TABLE 340 2 RIB_IPV4_UNICAST 341 3 RIB_IPV4_MULTICAST 342 4 RIB_IPV6_UNICAST 343 5 RIB_IPV6_MULTICAST 344 6 RIB_GENERIC 346 An initial PEER_INDEX_TABLE MRT record provides the BGP ID of the 347 collector, an optional view name, and a list of indexed peers. 348 Following the PEER_INDEX_TABLE MRT record, a series of MRT records 349 are used to encode RIB table entries. This series of MRT records use 350 subtypes 2-6 and are separate from the PEER_INDEX_TABLE MRT record 351 itself and include full MRT record headers. The header of the 352 PEER_INDEX_TABLE Subtype is shown below. The View Name is optional 353 and, if not present, the View Name Length MUST be set to 0. The View 354 Name encoding MUST follow the UTF-8 transformation format. 356 0 1 2 3 357 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 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Collector BGP ID | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | View Name Length | View Name (variable) | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Peer Count | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 The format of the peer entries is shown below. The PEER_INDEX_TABLE 367 record contains Peer Count peer entries. 369 0 1 2 3 370 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 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Peer Type | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Peer BGP ID | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Peer IP address (variable) | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Peer AS (variable) | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 The Peer Type, Peer BGP ID, Peer IP, and Peer AS fields are repeated 382 as indicated by the Peer Count field. The position of the Peer in 383 the PEER_INDEX_TABLE is used as an index in the subsequent 384 TABLE_DUMP_V2 MRT records. The index number begins with 0. 386 The Peer Type field is a bit field which encodes the type of the AS 387 and IP address as follows: 389 Bit 0 - unset for IPv4 Peer IP address, set for IPv6 390 Bit 1 - unset when Peer AS is 16 bits, set when it's 32 bits 392 The records which follow the PEER_INDEX_TABLE record constitute the 393 RIB entries and include a header which specifies a sequence number, 394 NLRI, and a count of the number of RIB entries which follow. 396 The format for the RIB_IPV4_UNICAST, RIB_IPV4_MULTICAST, 397 RIB_IPV6_UNICAST, and RIB_IPV6_MULTICAST headers are shown below. 398 The Prefix Length and Prefix fields are encoded in the same manner as 399 the BGP NLRI encoding for IPV4 and IPV6 prefixes. Namely, the Prefix 400 field contains address prefixes followed by enough trailing bits to 401 make the end of the field fall on an octet boundary. Note that the 402 value of trailing bits is irrelevant. 404 0 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Sequence number | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Prefix Length | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Prefix (variable) | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Entry Count | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 The RIB_GENERIC header is shown below. It includes Address Family 417 Identifier (AFI), Subsequent AFI and a single NLRI entry. The NLRI 418 information is specific to the AFI and SAFI values. An 419 implementation which does not recognize particular AFI and SAFI 420 values SHOULD discard the remainder of the MRT record. 422 0 1 2 3 423 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 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Sequence number | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Address Family Identifier |Subsequent AFI | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Network Layer Reachability Information (variable) | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Entry Count | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 The RIB entry headers are followed by a series of RIB entries which 435 are repeated Entry Count times. These entries share a common format 436 as shown below. They include a Peer Index from the PEER_INDEX_TABLE 437 MRT record, an originated time for the RIB entry, and the BGP path 438 attribute length and attributes encoded as provided in a BGP Update 439 message. 441 0 1 2 3 442 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 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Peer Index | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Originated Time | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Attribute Length | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | BGP Attributes... (variable) 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 There is one exception to the encoding of BGP attributes for the BGP 454 MP_REACH_NLRI attribute (BGP Type Code 14) [RFC 4760]. Since the 455 AFI, SAFI, and NLRI information is already encoded in the 456 MULTIPROTOCOL header, only the Next Hop Address Length and Next Hop 457 Address fields are included. The Reserved field is omitted. The 458 attribute length is also adjusted to reflect only the length of the 459 Next Hop Address Length and Next Hop Address fields. 461 5.4. BGP4MP Type 463 This Type was initially defined in the Zebra software package for the 464 BGP protocol with multiprotocol extension support as defined by RFC 465 4760 [RFC4760]. It supersedes the BGP, BGP4PLUS, BGP4PLUS_01 Types. 466 The BGP4MP Type has six Subtypes which are defined as follows: 468 0 BGP4MP_STATE_CHANGE 469 1 BGP4MP_MESSAGE 470 4 BGP4MP_MESSAGE_AS4 471 5 BGP4MP_STATE_CHANGE_AS4 472 6 BGP4MP_MESSAGE_LOCAL 473 7 BGP4MP_MESSAGE_AS4_LOCAL 475 5.4.1. BGP4MP_STATE_CHANGE Subtype 477 This record is used to encode state changes in the BGP finite state 478 machine. The BGP FSM states are encoded in the Old State and New 479 State fields to indicate the previous and current state. In some 480 cases, the Peer AS number may be undefined. In such cases, the value 481 of this field may be set to zero. The format is illustrated below: 483 0 1 2 3 484 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 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Peer AS number | Local AS number | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Interface Index | Address Family | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Peer IP address (variable) | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Local IP address (variable) | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Old State | New State | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 The FSM states are defined in RFC 4271 [RFC4271], Section 8.2.2. 498 Both the old state value and the new state value are encoded as 499 2-octet numbers. The state values are defined numerically as 500 follows: 502 1 Idle 503 2 Connect 504 3 Active 505 4 OpenSent 506 5 OpenConfirm 507 6 Established 509 The BGP4MP_STATE_CHANGE message also includes interface index and 510 Address Family fields. The interface index provides the interface 511 number of the peering session. The index value is OPTIONAL and MAY 512 be zero if unknown or unsupported. The Address Family indicates what 513 types of addresses are in the the address fields. At present, the 514 following AFI Types are supported: 516 1 AFI_IPv4 517 2 AFI_IPv6 519 5.4.2. BGP4MP_MESSAGE Subtype 521 This Subtype is used to encode BGP Messages. It can be used to 522 encode any Type of BGP message. The entire BGP message is 523 encapsulated in the BGP Message field, including the 16-octet marker, 524 the 2-octet length, and the 1-octet type fields. Note that the 525 BGP4MP_MESSAGE Subtype does not support 4-Byte AS numbers. Further, 526 the AS_PATH contained in these messages MUST only consist of 2-Byte 527 AS numbers. The BGP4MP_MESSAGE_AS4 Subtype updates the 528 BGP4MP_MESSAGE Subtype in order to support 4-Byte AS numbers. The 529 BGP4MP_MESSAGE fields are shown below: 531 0 1 2 3 532 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 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Peer AS number | Local AS number | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Interface Index | Address Family | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Peer IP address (variable) | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Local IP address (variable) | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | BGP Message... (variable) 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 The interface index provides the interface number of the peering 546 session. The index value is OPTIONAL and MAY be zero if unknown or 547 unsupported. The Address Family indicates what types of addresses 548 are in the the subsequent address fields. At present, the following 549 AFI Types are supported: 551 1 AFI_IPv4 552 2 AFI_IPv6 554 Note that the Address Family value only applies to the IP addresses 555 contained in the MRT header. The BGP4MP_MESSAGE Subtype is otherwise 556 transparent to the contents of the actual message which may contain 557 any valid AFI/SAFI values. Only one BGP message may be encoded in 558 the BGP4MP_MESSAGE Subtype. 560 5.4.3. BGP4MP_MESSAGE_AS4 Subtype 562 This Subtype updates the BGP4MP_MESSAGE Subtype to support 4-Byte 563 Autonomous System numbers. The BGP4MP_MESSAGE_AS4 Subtype is 564 otherwise identical to the BGP4MP_MESSAGE Subtype. The AS_PATH in 565 these messages MUST only consist of 4-Byte AS numbers. The 566 BGP4MP_MESSAGE_AS4 fields are shown below: 568 0 1 2 3 569 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 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Peer AS number | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Local AS number | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Interface Index | Address Family | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | Peer IP address (variable) | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Local IP address (variable) | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | BGP Message... (variable) 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 5.4.4. BGP4MP_STATE_CHANGE_AS4 Subtype 586 This Subtype updates the BGP4MP_STATE_CHANGE Subtype to support 587 4-Byte Autonomous System numbers. As with the BGP4MP_STATE_CHANGE 588 Subtype, the BGP FSM states are encoded in the Old State and New 589 State fields to indicate the previous and current state. Aside from 590 the extension of the peer and local AS fields to 4-Bytes, this 591 subtype is otherwise identical to the BGP4MP_STATE_CHANGE Subtype. 592 The BGP4MP_STATE_CHANGE_AS4 fields are shown below: 594 0 1 2 3 595 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 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Peer AS number | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Local AS number | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Interface Index | Address Family | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Peer IP address (variable) | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Local IP address (variable) | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | Old State | New State | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 5.4.5. BGP4MP_MESSAGE_LOCAL Subtype 612 Implementations of MRT have largely focused on collecting remotely 613 generated BGP messages in a passive route collector role. However, 614 for active BGP implementations, it can be useful to archive locally 615 generated BGP messages in addition to remote messages. This subtype 616 is added to indicated a locally generated BGP message. The fields 617 remain identical to the BGP4MP_MESSAGE type including the Peer and 618 Local IP and AS fields. The Local fields continue to refer to the 619 local IP and AS number of the collector which generated the message 620 and the Peer IP and AS fields refer to the receipient of the 621 generated BGP messages. 623 5.4.6. BGP4MP_MESSAGE_AS4_LOCAL Subtype 625 As with the BGP4MP_MESSAGE_LOCAL type, this type indicate locally 626 generated messages. The fields are identical to the 627 BGP4MP_MESSAGE_AS4 message type. 629 5.5. BGP4MP_ET Type 631 This Type was initially defined in the Sprint Labs Python Routing 632 Toolkit (PyRT). It extends the MRT common header field to include a 633 32BIT microsecond timestamp field. The type and subtype field 634 definitions remain as defined for the BGP4MP Type. The 32BIT 635 microsecond timestamp immediately follows the length field in the MRT 636 common header and precedes all other fields in the message. The 637 32BIT microsecond field is included in the computation of the length 638 field value. The MRT common header modification is illustrated 639 below. 641 0 1 2 3 642 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 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | Timestamp | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | Type | Subtype | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | Length | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 | microsecond timestamp | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | Message... (variable) 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 5.6. ISIS Type 657 This Type was initially defined in the Sprint Labs Python Routing and 658 supports the IS-IS routing protocol as defined in RFC 1195 [RFC1195]. 659 There is no Type specific header for the ISIS Type. The Subtype code 660 for this Type is undefined. The ISIS PDU directly follows the MRT 661 common header fields. 663 5.7. ISIS_ET Type 665 The ISIS_ET Type extends the ISIS Type to support microsecond 666 timestamps. As with the BGP4MP_ET Type, a 32BIT microsecond 667 timestamp field is appended to the MRT common header after the length 668 field. The ISIS_ET Type is otherwise identical to the ISIS Type. 670 5.8. OSPFv3 Type 672 The OSPFv3 Type extends the original OSPF Type to support IPv6 673 addresses for the OSPFv3 protocol as defined in RFC 5340 [RFC5340]. 674 The format of the MRT Message field for the OSPFv3 Type is as 675 follows: 677 0 1 2 3 678 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 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | Address Family | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | Remote IP address (variable) | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | Local IP address (variable) | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | OSPF Message Contents (variable) 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 5.9. OSPFv3_ET Type 691 The OSPFv3_ET Type extends the OSPFv3 Type to support microsecond 692 timestamps. As with the BGP4MP_ET Type, a 32BIT microsecond 693 timestamp field is appended to the MRT common header after the length 694 field and its length is included in the calculation of the length 695 field value. The OSPFv3_ET Type is otherwise identical to the OSPFv3 696 Type. 698 6. IANA Considerations 700 This section provides guidance to the Internet Assigned Numbers 701 Authority (IANA) regarding registration of values related to the MRT 702 specification, in accordance with BCP 26, RFC 5226 [RFC5226]. 704 There are two name spaces in MRT that require registration: Type 705 Codes and Subtype Codes. 707 MRT is not intended as a general-purpose specification for protocol 708 information export, and allocations should not be made for purposes 709 unrelated to routing protocol information export. 711 The following policies are used here with the meanings defined in BCP 712 26: "Specification Required", "IETF Consensus", "Experimental Use", 713 "First Come First Served". 715 6.1. Type Codes 717 Type Codes have a range from 0 to 65535, of which 1-64 have been 718 allocated. New Type Codes MUST be allocated starting at 65. Type 719 Codes 65 - 511 are to be assigned by IETF Review. Type Codes 512 - 720 2047 are assigned based on Specification Required. Type Codes 2048 - 721 64511 are available on a First Come First Served policy. Type Codes 722 64512 - 65534 are available for Experimental Use. The Type Code 723 Values of 0 and 65535 are reserved. 725 6.2. Subtype Codes 727 Subtype Codes have a range from 0 to 65535. Subtype definitions are 728 specific to a particular Type Code definition. New Subtype Code 729 definition must reference an existing Type Code to which the Subtype 730 belongs. Subtype assignmnents to Type Codes 0 - 511 are to be 731 assigned by IETF Review. Subtype assignments for the remaning Type 732 Codes follow the assignment rules for the Type Codes to which they 733 belong. 735 7. Security Considerations 737 The MRT Format utilizes a structure which can store routing protocol 738 information data. The fields defined in the MRT specification are of 739 a descriptive nature and provide information that is useful to 740 facilitate the analysis of routing data. As such, the fields 741 currently defined in the MRT specification do not in themselves 742 create additional security risks, since the fields are not used to 743 induce any particular behavior by the recipient application. 745 8. References 747 8.1. Normative References 749 [RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, 750 June 1988. 752 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 753 dual environments", RFC 1195, December 1990. 755 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 756 January 1997. 758 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 759 Requirement Levels", BCP 14, RFC 2119, March 1997. 761 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 763 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 764 Protocol 4 (BGP-4)", RFC 4271, January 2006. 766 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 767 "Multiprotocol Extensions for BGP-4", RFC 4760, 768 January 2007. 770 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 771 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 772 May 2008. 774 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 775 for IPv6", RFC 5340, July 2008. 777 8.2. Informative References 779 [MRT PROG GUIDE] 780 Labovitz, C., "MRT Programmer's Guide", November 1999, 781 . 783 Appendix A. Deprecated MRT types 785 This Appendix lists deprecated MRT types. These types are documented 786 for informational purposes only. While documented in some 787 references, they are not known to have been generally implemented. 789 A.1. Deprecated MRT Informational Types 791 The deprecated MRT Informational Types are defined below: 793 0 NULL 794 2 DIE 795 4 PEER_DOWN 797 A.1.1. NULL Type 799 The NULL Type message causes no operation. 801 A.1.2. DIE Type 803 The DIE Type signals a remote MRT repository it should stop accepting 804 messages. 806 A.1.3. PEER_DOWN Type 808 The PEER_DOWN message was intended to indicate that a collector had 809 lost association with a BGP peer. However, the MRT format provides 810 BGP state change message types which duplicate this functionality. 812 A.2. Deprecated MRT Routing Information Types 814 5 BGP 815 6 RIP 816 7 IDRP 817 8 RIPNG 818 9 BGP4PLUS 819 10 BGP4PLUS_01 821 A.2.1. BGP Type 823 The BGP Type indicates the Message field contains BGP routing 824 information. The BGP routing protocol is defined in RFC 4271 825 [RFC4271]. The information in the message is dependent on the 826 Subtype value. The BGP Type and all associated Subtypes below are 827 considered to be deprecated by the BGP4MP Type. 829 The following BGP Subtypes are defined for the MRT BGP Type. As with 830 the BGP Type itself, they are all considered to be deprecated. 832 0 BGP_NULL 833 1 BGP_UPDATE 834 2 BGP_PREF_UPDATE 835 3 BGP_STATE_CHANGE 836 4 BGP_SYNC 837 5 BGP_OPEN 838 6 BGP_NOTIFY 839 7 BGP_KEEPALIVE 841 A.2.1.1. BGP_NULL Subtype 843 The BGP_NULL Subtype is a reserved Subtype. 845 A.2.1.2. BGP_UPDATE Subtype 847 The BGP_UPDATE Subtype is used to encode BGP UPDATE messages. The 848 format of the MRT Message field for this Subtype is as follows: 850 0 1 2 3 851 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 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | Peer AS number | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | Peer IP address | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | Local AS number | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | Local IP address | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | BGP UPDATE Contents (variable) 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 The BGP UPDATE Contents include the entire BGP UPDATE message which 865 follows the BGP Message Header. The BGP Message Header itself is not 866 included. The Peer AS number and IP address fields contain the AS 867 number and IP address of the remote system which are generating the 868 BGP UPDATE messages. The Local AS number and IP address fields 869 contain the AS number and IP address of the local collector system 870 which is archiving the messages. 872 A.2.1.3. BGP_PREF_UPDATE Subtype 874 The BGP_PREF_UPDATE Subtype is not defined. 876 A.2.1.4. BGP_STATE_CHANGE Subtype 878 The BGP_STATE_CHANGE Subtype is used to record changes in the BGP 879 finite state machine. These FSM states are defined in RFC 4271 881 [RFC4271], Section 8.2.2. Both the old state value and the new state 882 value are encoded as 2-octet numbers. The state values are defined 883 numerically as follows: 885 1 Idle 886 2 Connect 887 3 Active 888 4 OpenSent 889 5 OpenConfirm 890 6 Established 892 The format of the MRT Message field is as follows: 894 0 1 2 3 895 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 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | Peer AS number | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | Peer IP address | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 | Old State | New State | 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 A.2.1.5. BGP_SYNC Subtype 906 The BGP_SYNC Subtype was intended to convey a system file name where 907 BGP Table Dump messages should be recorded. The View # was to 908 correspond to the View # provided in the TABLE_DUMP Type messages. 909 There are no known implementations of this subtype and it SHOULD be 910 ignored. The following format applies to this Subtype: 912 0 1 2 3 913 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 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | View # | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | File Name... (variable) 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 The File Name is terminated with a NULL (0) character. 922 A.2.1.6. BGP_OPEN Subtype 924 The BGP_OPEN Subtype is used to encode BGP OPEN messages. The format 925 of the MRT Message field for this Subtype is the same as the 926 BGP_UPDATE, however, the last field contains the contents of the BGP 927 OPEN message. 929 A.2.1.7. BGP_NOTIFY Subtype 931 The BGP_NOTIFY Subtype is used to encode BGP NOTIFICATION messages. 932 The format of the MRT Message field for this Subtype is the same as 933 the BGP_UPDATE, however, the last field contains the contents of the 934 BGP NOTIFICATION message. 936 A.2.1.8. BGP_KEEPALIVE Subtype 938 The BGP_KEEPALIVE Subtype is used to encode BGP KEEPALIVE messages. 939 The format of the MRT Message field for this Subtype is the same as 940 the BGP_UPDATE, however, the last field contains no information. 942 A.2.2. RIP Type 944 The RIP Type is used to export RIP protocol packets as defined in RFC 945 1058 [RFC1058]. The Subtype field is currently reserved for this 946 Type and SHOULD be set to 0. 948 The format of the MRT Message field for the RIP Type is as follows: 950 0 1 2 3 951 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 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 | Peer IP address | 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 | Local IP address | 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 | RIP Message Contents (variable) 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 A.2.3. IDRP Type 962 The IDRP Type is used to export Inter-Domain-Routing Protocol (IDRP) 963 protocol information as defined in the ISO/IEC 10747 standard. The 964 Subtype field is unused. This Type is deprecated due to lack of 965 deployment of IDRP. 967 A.2.4. RIPNG Type 969 The RIPNG Type is used to export RIPNG protocol packets as defined in 970 RFC 2080 [RFC2080]. The RIPNG protocol updates the RIP protocol to 971 support IPv6. The Subtype field is currently reserved for this Type 972 and SHOULD be set to 0. 974 The format of the MRT Message field for the RIPNG Type is as follows: 976 0 1 2 3 977 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 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | | 980 ~ Peer IPv6 address ~ 981 | | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | | 984 ~ Local IPv6 address ~ 985 | | 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 | RIPNG Message Contents (variable) 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 A.2.5. BGP4PLUS and BGP4PLUS_01 Types 992 The BGP4PLUS and BGP4PLUS_01 Types were defined to support IPv6 BGP 993 routing information. The BGP4PLUS Type was specified based on the 994 initial Internet Draft for Multiprotocol Extensions to BGP-4. The 995 BGP4PLUS_01 Type was specified to correspond to the -01 revision of 996 this Internet Draft. The two Types share the same definitions in 997 terms of their MRT format specifications. 999 The Subtype field definitions are shared with the BGP Type, however, 1000 the address fields in the BGP_UPDATE, BGP_OPEN, BGP_NOTIFY, 1001 BGP_KEEPALIVE, and BGP_STATE_CHANGE Subtype messages are extended to 1002 16 octets for IPv6 addresses. As with the BGP Type, the BGP4PLUS and 1003 BGP4PLUS_01 Types are deprecated as they superseded by the BGP4MP 1004 Type. 1006 A.2.6. Deprecated BGP4MP Subtypes 1008 The following two subtypes of the BGP4MP Type are considered to be 1009 deprecated. 1011 2 BGP4MP_ENTRY 1012 3 BGP4MP_SNAPSHOT 1014 A.2.6.1. BGP4MP_ENTRY Subtype 1016 This Subtype is similar to the TABLE_DUMP Type and is used to record 1017 RIB table entries. It extends the TABLE_DUMP Type to include true 1018 multiprotocol support. However, this Type does not support 4-Byte AS 1019 numbers and has not been widely implemented. This Type is deprecated 1020 in favor of the TABLE_DUMP_V2 which includes 4-Byte AS number support 1021 and a more compact format. 1023 0 1 2 3 1024 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 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 | Peer AS number | Local AS number | 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 | Interface Index | Address Family | 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 | Peer IP address (variable) | 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 | Local IP address (variable) | 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 | View # | Status | 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | Time last change | 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 | Address Family | SAFI | Next-Hop-Len | 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 | Next Hop Address (variable) | 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 | Prefix Length | 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 | Address Prefix (variable) | 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 | Attribute Length | 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 | BGP Attribute... (variable) 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 A.2.6.2. BGP4MP_SNAPSHOT Subtype 1053 This Subtype was intended to convey a system file name where 1054 BGP4MP_ENTRY messages should be recorded. It is similar to the 1055 BGP_SYNC message Subtype and is deprecated. 1057 0 1 2 3 1058 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 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 | View # | 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 | File Name... (variable) 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 Authors' Addresses 1067 Larry Blunk 1068 Merit Network 1070 Email: ljb@merit.edu 1072 Manish Karir 1073 Merit Network 1075 Email: mkarir@merit.edu 1077 Craig Labovitz 1078 Arbor Networks 1080 Email: labovit@arbor.net