idnits 2.17.1 draft-ietf-grow-mrt-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 787. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 764. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 771. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 777. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([9]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (June 26, 2006) is 6506 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1771 (ref. '1') (Obsoleted by RFC 4271) ** Downref: Normative reference to an Historic RFC: RFC 1058 (ref. '2') ** Obsolete normative reference: RFC 2858 (ref. '5') (Obsoleted by RFC 4760) ** Obsolete normative reference: RFC 2740 (ref. '7') (Obsoleted by RFC 5340) ** Obsolete normative reference: RFC 2434 (ref. '8') (Obsoleted by RFC 5226) Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 8 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 Expires: December 28, 2006 Merit Network 5 C. Labovitz 6 Arbor Networks 7 June 26, 2006 9 MRT routing information export format 10 draft-ietf-grow-mrt-03.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 28, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This document describes the MRT format for routing information 44 export. This format was developed in concert with the Multi-threaded 45 Routing Toolkit (MRT) from whence the format takes it name. The MRT 46 format was initially defined in the MRT Programmer's Guide [9]. The 47 format can be used to export routing protocol messages, state 48 changes, and routing information base contents. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Basic MRT Format . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. MRT Control Types . . . . . . . . . . . . . . . . . . . . . . 6 55 3.1. NULL Type . . . . . . . . . . . . . . . . . . . . . . . . 6 56 3.2. START Type . . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.3. DIE Type . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 3.4. I_AM_DEAD Type . . . . . . . . . . . . . . . . . . . . . . 6 59 3.5. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . . . 6 60 4. MRT Routing Information Types . . . . . . . . . . . . . . . . 7 61 4.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 4.1.1. BGP_NULL Subtype . . . . . . . . . . . . . . . . . . . 7 63 4.1.2. BGP_UPDATE Subtype . . . . . . . . . . . . . . . . . . 7 64 4.1.3. BGP_PREF_UPDATE Subtype . . . . . . . . . . . . . . . 8 65 4.1.4. BGP_STATE_CHANGE Subtype . . . . . . . . . . . . . . . 8 66 4.1.5. BGP_SYNC Subtype . . . . . . . . . . . . . . . . . . . 8 67 4.1.6. BGP_OPEN . . . . . . . . . . . . . . . . . . . . . . . 9 68 4.1.7. BGP_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 9 69 4.1.8. BGP_KEEPALIVE . . . . . . . . . . . . . . . . . . . . 9 70 4.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 4.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . . . 10 72 4.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . . . 10 73 4.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . . . 10 74 4.6. OSPF Type . . . . . . . . . . . . . . . . . . . . . . . . 10 75 4.7. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 11 76 4.8. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 12 77 4.8.1. BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 12 78 4.8.2. BGP4MP_MESSAGE Subtype . . . . . . . . . . . . . . . . 13 79 4.8.3. BGP4MP_ENTRY Subtype . . . . . . . . . . . . . . . . . 14 80 4.8.4. BGP4MP_SNAPSHOT Subtype . . . . . . . . . . . . . . . 14 81 4.8.5. BGP4MP_MESSAGE_32BIT_AS Subtype . . . . . . . . . . . 15 82 4.9. BGP4MP_ET . . . . . . . . . . . . . . . . . . . . . . . . 15 83 4.10. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 16 84 4.11. ISIS_ET Type . . . . . . . . . . . . . . . . . . . . . . . 16 85 4.12. OSPF_ET Type . . . . . . . . . . . . . . . . . . . . . . . 16 86 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 87 5.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 18 88 5.2. Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 18 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 90 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 91 7.1. Normative References . . . . . . . . . . . . . . . . . . . 20 92 7.2. Informative References . . . . . . . . . . . . . . . . . . 20 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 94 Intellectual Property and Copyright Statements . . . . . . . . . . 22 96 1. Introduction 98 Researchers and engineers often wish to analyze network behavior by 99 studying routing protocol transactions and routing information base 100 snapshots. To this end, the MRT format was developed to encapsulate, 101 export, and archive this information in a standardized data 102 representation. The BGP routing protocol, in particular, has been 103 the subject of extensive study and analysis which has been 104 significantly aided by the availability of the MRT format. 106 This memo serves to document the MRT format as currently implemented 107 in publicly available software. The format has been extended since 108 it's original introduction in the MRT toolset and these extensions 109 are also included in this memo. Further extensions may be introduced 110 at a later date through additional definitions of the MRT Type field 111 and Subtype fields. 113 2. Basic MRT Format 115 All MRT format messages have a common header which includes a 116 timestamp, Type, Subtype, and length field. The header is followed 117 by a message field. The basic MRT format is illustrated below. 119 0 1 2 3 120 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 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Timestamp | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Type | Subtype | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Length | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | Message... (variable) 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 Header Field Descriptions: 133 Timestamp: 135 Time in seconds since 1 January 1970 00:00:00 UTC 137 Type: 139 A 2-octet field that indicates the Type of information 140 contained in the message field. Types 1 through 5 are used for 141 MRT control information while Types 6 and higher are used for 142 routing information. 144 Subtype: 146 A 2-octet message Subtype field 148 Length: 150 A 4-octet message length field. The length does not include 151 the header. 153 Message: 155 A variable length message. The contents of this field are 156 context dependent on the Type and Subtype fields. 158 3. MRT Control Types 160 The MRT format defines five Control Type messages. These messages 161 are using to relay the current state of MRT message source. The 162 message field may contain an optional ASCII text string for 163 diagnostic purposes. These control messages are unidirectional in 164 nature and there is no form of an acknowledgment or response from the 165 receiver to the sender. The Subtype field is unused for these Types 166 and should be set to 0. 168 The MRT Control Types are defined below: 170 0 NULL 171 1 START 172 2 DIE 173 3 I_AM_DEAD 174 4 PEER_DOWN 176 3.1. NULL Type 178 The NULL Type message causes no operation, A sender may wish to send 179 these for synchronization or keep-alive purposes. 181 3.2. START Type 183 The START Type indicates a sender is about to begin sending MRT 184 messages 186 3.3. DIE Type 188 A DIE Type signals that the receiver should shut down. 190 3.4. I_AM_DEAD Type 192 A I_AM_DEAD indicates that the sender is shutting down. 194 3.5. PEER_DOWN Type 196 A PEER_DOWN is sent when the sender's peer is down. In practice, a 197 sender will likely have multiple peers. It is recommended that the 198 sender use the Message field to convey the IP address of the peer 199 represented in US-ASCII. 201 4. MRT Routing Information Types 203 The following Types are currently defined for the MRT format. Types 204 5-12 were defined in the initial MRT Toolkit package. The BGP4MP 205 Type, number 16, was initially defined in the Zebra routing software 206 package. 208 5 BGP 209 6 RIP 210 7 IDRP 211 8 RIPNG 212 9 BGP4PLUS 213 10 BGP4PLUS_01 214 11 OSPF 215 12 TABLE_DUMP 216 16 BGP4MP 217 17 BGP4MP_ET 218 32 ISIS 219 33 ISIS_ET 220 64 OSPF_ET 222 4.1. BGP Type 224 The BGP Type indicates the Message field contains BGP routing 225 information. The BGP routing protocol is defined in RFC 1771 [1]. 226 The information in the message is dependent on the Subtype value. 227 The BGP Type is considered to be deprecated by the BGP4MP Type. 229 The following BGP Subtypes are defined for the MRT BGP Type. 231 0 BGP_NULL 232 1 BGP_UPDATE 233 2 BGP_PREF_UPDATE 234 3 BGP_STATE_CHANGE 235 4 BGP_SYNC 236 5 BGP_OPEN 237 6 BGP_NOTIFY 238 7 BGP_KEEPALIVE 240 4.1.1. BGP_NULL Subtype 242 The BGP_NULL Subtype is a reserved Subtype. 244 4.1.2. BGP_UPDATE Subtype 246 The BGP_UPDATE Subtype is used to encode BGP UPDATE messages. The 247 format of the MRT Message field for this Subtype is as follows: 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Source AS number | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Source IP address | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Destination AS number | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Destination IP address | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | BGP UPDATE Contents (variable) 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 The BGP UPDATE contents include the entire BGP UPDATE message which 264 follows the BGP Message Header. The BGP Message Header itself is not 265 included. 267 4.1.3. BGP_PREF_UPDATE Subtype 269 The BGP_PREF_UPDATE Subtype is not defined. 271 4.1.4. BGP_STATE_CHANGE Subtype 273 The BGP_STATE_CHANGE Subtype is used to record changes in the BGP 274 finite state machine. These FSM states and their numeric encodings 275 are defined in RFC 1771 [1], Appendix 1. Both the old state value 276 and the new state value are encoded as 2-octet numbers. The format 277 of the MRT Message field is as follows: 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 | Source AS number | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Source IP address | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Old State | New State | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 4.1.5. BGP_SYNC Subtype 291 The BGP_SYNC Subtype is used to indicate a File Name where BGP Table 292 Dump messages should be recorded. The View # corresponds to the View 293 # provided in the TABLE_DUMP Type messages. The following format 294 applies to this Subtype: 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | View # | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | File Name... (variable) 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 The File Name is terminated with a NULL (0) character. 306 4.1.6. BGP_OPEN 308 The BGP_OPEN Subtype is used to encode BGP OPEN messages. The format 309 of the MRT Message field for this Subtype is the same as the 310 BGP_UPDATE, however, the last field contains the contents of the BGP 311 OPEN message. 313 4.1.7. BGP_NOTIFY 315 The BGP_NOTIFY Subtype is used to encode BGP NOTIFICATION messages. 316 The format of the MRT Message field for this Subtype is the same as 317 the BGP_UPDATE, however, the last field contains the contents of the 318 BGP NOTIFICATION message. 320 4.1.8. BGP_KEEPALIVE 322 The BGP_KEEPALIVE Subtype is used to encode BGP KEEPALIVE messages. 323 The format of the MRT Message field for this Subtype is the same as 324 the BGP_UPDATE, however, the last field contains no information. 326 4.2. RIP Type 328 The RIP Type is used to export RIP protocol packets as defined in RFC 329 1058 [2]. The Subtype field is currently reserved for this Type and 330 should be set to 0. 332 The format of the MRT Message field for the RIP Type is as follows: 334 0 1 2 3 335 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 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Source IP address | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Destination IP address | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | RIP Message Contents (variable) 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 4.3. IDRP Type 346 The IDRP Type is used to export Inter-Domain-Routing Protocol (IDRP) 347 protocol information as defined in the ISO/IEC 10747 standard. The 348 Subtype field is unused. This Type is deprecated due to lack of 349 deployment of IDRP. 351 4.4. RIPNG Type 353 The RIPNG Type is used to export RIPNG protocol packets as defined in 354 RFC 2080 [3]. The Subtype field is currently reserved for this Type 355 and should be set to 0. 357 The format of the MRT Message field for the RIPNG Type is as follows: 359 0 1 2 3 360 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 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Source IP address | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Destination IP address | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | RIPNG Message Contents (variable) 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 4.5. BGP4PLUS and BGP4PLUS_01 Types 371 The BGP4PLUS and BGP4PLUS_01 Types were defined to support IPv6 BGP 372 routing information. The BGP4PLUS Type was specified based on the 373 initial Internet Draft for Multiprotocol Extensions to BGP-4. The 374 BGP4PLUS_01 Type was specified to correspond to the -01 revision of 375 this Internet Draft. The two Types share the same definitions in 376 terms of their MRT format specifications. 378 The Subtype field definitions are shared with the BGP Type, however, 379 the address fields in the BGP_UPDATE, BGP_OPEN, BGP_NOTIFY, 380 BGP_KEEPALIVE, and BGP_STATE_CHANGE Subtype messages are extended to 381 16 octets for IPv6 addresses. As with the BGP Type, the BGP4PLUS and 382 BGP4PLUS_01 Types are deprecated as they superseded by the BGP4MP 383 Type. 385 4.6. OSPF Type 387 This Type supports the OSPF Protocol as defined in RFC 2328 [4]. The 388 Subtype field may contain two possible values: 390 0 OSPF_STATE_CHANGE 391 1 OSPF_LSA_UPDATE 393 The format of the MRT Message field for the OSPF Type is as follows: 395 0 1 2 3 396 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 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Source IP address | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Destination IP address | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | OSPF Message Contents (variable) 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 4.7. TABLE_DUMP Type 407 The TABLE_DUMP Type is used to encode routing table dumps. The 408 Subtype is used to encode whether the table entry contains IPv4 or 409 IPv6 addresses. There are currently two possible values for the 410 Subtype as shown below. 412 1 AFI_IPv4 413 2 AFI_IPv6 415 The format of the TABLE_DUMP Type is illustrated below. 417 0 1 2 3 418 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 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | View # | Sequence number | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Prefix (variable) | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Prefix Length | Status | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Originated Time | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Peer IP address (variable) | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Peer AS | Attribute Length | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | BGP Attribute... (variable) 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 The View field is normally 0 and is intended for cases where an 436 implementation may have multiple RIB views (such as a route server). 437 The Sequence field is a simple incremental counter for a concatenated 438 series of TABLE_DUMP Type messages. 440 The Prefix field contains the IP address of a particular routing 441 table dump entry. The size of this field is dependent on the value 442 of the Subtype for this message. For AFI_IPv4, this field is 4 443 octets, for AFI_IPv6, it is 16 octets in length. The Prefix Length 444 field indicates the length in bits of the prefix mask for the 445 preceding Prefix field. 447 The Status octet is not used in the TABLE_DUMP Type and should be set 448 to 1. 450 The Originated Time contains the 4-octet time at which this prefix 451 was heard. The value represents the time in seconds since 1 January 452 1970 00:00:00 UTC. 454 The Peer ID field is the IP address of the peer which provided the 455 update for this routing table entry. As with the Prefix field, the 456 size of this field is dependent on the Subtype. AFI_IPv4 indicates a 457 4 octet field and an IPv4 address, while a Subtype of AFI_IPv6 458 requires a 16 octet field and an IPv6 address. The Peer AS field 459 contains the AS number of the peer. 461 Attribute length is the length of Attribute field and is 2-octets. 462 The Attribute field contains the attribute information for the route 463 table entry. 465 4.8. BGP4MP Type 467 This Type was initially defined in the Zebra software package for the 468 BGP protocol with multiprotocol extension support as defined by RFC 469 2858 [5]. It supersedes the BGP, BGP4PLUS, BGP4PLUS_01 Types. The 470 BGP4MP Type has four Subtypes which are defined as follows: 472 0 BGP4MP_STATE_CHANGE 473 1 BGP4MP_MESSAGE 474 2 BGP4MP_ENTRY 475 3 BGP4MP_SNAPSHOT 476 4 BGP4MP_MESSAGE_32BIT_AS 478 4.8.1. BGP4MP_STATE_CHANGE Subtype 480 This record is used to encode state changes in the BGP finite state 481 machine. As with the BGP_STATE_CHANGE Subtype, the BGP FSM states 482 are encoded in the Old State and New State fields to indicate the 483 previous and current state. The format is illustrated below: 485 0 1 2 3 486 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 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Source AS number | Destination AS number | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Interface Index | Address Family | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Source IP address (variable) | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Destination IP address (variable) | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Old State | New State | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 While BGP4MP_STATE_CHANGE message is similar to the BGP_STATE_CHANGE 500 message, however, it also includes interface index and Address Family 501 fields. As with the BGP_STATE_CHANGE message, the FSM states and 502 their numeric encodings are defined in RFC 1771 [1], Appendix 1. 503 Future updates to the BGP protocol specification will introduce a new 504 state machine and thus render this message Type obsolete. The 505 interface index provides the interface number of the peering session 506 and the Address Family indicates what Types of addresses are in the 507 the address fields. At present, only the following AFI Types are 508 supported: 510 1 AFI_IPv4 511 2 AFI_IPv6 513 4.8.2. BGP4MP_MESSAGE Subtype 515 This Subtype is used to encode BGP Messages. It is similar to the 516 BGP_UPDATE Subtype, except that is can be used to encode any Type of 517 message (not just BGP UPDATES). In order to determine the BGP 518 message Type, the entire BGP message, including the BGP header, is 519 included in the BGP Message field. The BGP4MP_MESSAGE fields are 520 shown below: 522 0 1 2 3 523 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 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Source AS number | Destination AS number | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Interface Index | Address Family | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Source IP address (variable) | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Destination IP address (variable) | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | BGP Message... (variable) 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 4.8.3. BGP4MP_ENTRY Subtype 538 This Subtype is used to record routing table entries. It is similar 539 to the TABLE_DUMP Type. The primary difference being that the 540 Address Family is encoded in the Message itself. Further, a 541 Subsequence Address Family field (SAFI) is included as well. 543 0 1 2 3 544 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 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | View # | Status | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Time last change | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Address Family | SAFI | Next-Hop-Len | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | Next Hop Address (variable) | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Prefix Length | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | Address Prefix (variable) | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Attribute Length | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | BGP Attribute... (variable) 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 4.8.4. BGP4MP_SNAPSHOT Subtype 565 This Subtype is used to indicate a filename containing BGP4MP_ENTRY 566 records. It is similar to the BGP_SYNC message Subtype and shares 567 the same fields. 569 0 1 2 3 570 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 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | View # | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | File Name... (variable) 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 4.8.5. BGP4MP_MESSAGE_32BIT_AS Subtype 579 This Subtype updates the BGP4MP_MESSAGE Subtype to support 32BIT 580 Autonomous System numbers. As the current 16 bit Autonomous System 581 number space nears exhaustion, the introduction of 32 bit numbers 582 will be required to support future Autonomous System number 583 allocations. The BGP4MP_MESSAGE_32BIT_AS fields are shown below: 585 0 1 2 3 586 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 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Source AS number | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Destination AS number | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Interface Index | Address Family | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Source IP address (variable) | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Destination IP address (variable) | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | BGP Message... (variable) 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 4.9. BGP4MP_ET 603 This Type was initially defined in the Sprint Labs Python Routing 604 Toolkit (PyRT). It extends the header field of the BGP4MP Type to 605 include a 32-bit microsecond timestamp field. The Subtypes and other 606 field definitions remain as defined for the BGP4MP Type. The 32-bit 607 microsecond timestamp immediately follows the length field in the 608 BGP4MP Type and precedes all other fields in the message. The header 609 modification is illustrated below. 611 0 1 2 3 612 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 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Timestamp | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Type | Subtype | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Length | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | microsecond timestamp | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Message... (variable) 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 4.10. ISIS Type 627 This Type was initially defined in the Sprint Labs Python Routing and 628 supports the IS-IS routing protocol as defined in RFC 1195 [6]. 629 There is no Type specific header for the ISIS Type. The Subtype code 630 for this Type is undefined. The ISIS PDU directly follows the MRT 631 common header fields. 633 4.11. ISIS_ET Type 635 The ISIS_ET Type extends the the ISIS Type to support microsecond 636 timestamps. As with the BGP4MP_ET Type, a 32-bit microsecond 637 timestamp field is appended to the MRT common header after the length 638 field. The ISIS_ET Type is otherwise identical to the ISIS Type. 640 4.12. OSPF_ET Type 642 The OSPF_ET Type extends the the OSPF Type to support microsecond 643 timestamps. As with the BGP4MP_ET and ISIS_ET Types, a 32-bit 644 microsecond timestamp field is appended to the MRT common header 645 after the length field. The OSPF_ET Type also extends the OSPF Type 646 to support IPv6 addresses for the OSPFv3 protocol as defined in RFC 647 2740 [7]. The format of the MRT Message field for the OSPF_ET Type 648 is as follows: 650 0 1 2 3 651 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 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | Address Family | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Source IP address (variable) | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Destination IP address (variable) | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | OSPF Message Contents (variable) 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 5. IANA Considerations 664 This section provides guidance to the Internet Assigned Numbers 665 Authority (IANA) regarding registration of values related to the MRT 666 specification, in accordance with BCP 26, RFC 2434 [8]. 668 There are two name spaces in MRT that require registration: Type 669 Codes and Subtype Codes. 671 MRT is not intended as a general-purpose specification for protocol 672 information export, and allocations should not be made for purposes 673 unrelated to routing protocol information export. 675 The following policies are used here with the meanings defined in BCP 676 26: "Specification Required", "IETF Consensus". 678 5.1. Type Codes 680 Type Codes have a range from 0 to 65535, of which 0-64 have been 681 allocated. New Type Codes should be allocated starting at 65. Type 682 Codes 65 - 32767 are to be assigned by IETF Consensus. Type Codes 683 32768 - 65535 are assigned based on Specification Required. 685 5.2. Subtype Codes 687 Subtype Codes have a range from 0 to 65535. Subtype definitions are 688 specific to a particular Type Code definition. New Subtype Code 689 definition must reference an existing Type Code to which the Subtype 690 belongs. As Subtype Codes are specific to Type Codes, new numbers 691 must be unique for the particular Type Code to which the Subtype 692 applies. Subtype Codes specific to the Type Codes 0 - 32767 are 693 assigned by IETF Consensus. Suptype Codes specific to Type Codes 694 32768 - 65535 are assigned based on Specification Required. 696 6. Security Considerations 698 The MRT Format utilizes a structure which can store routing protocol 699 information data. The fields defined in the MRT specification are of 700 a descriptive nature and provide information that is useful to 701 facilitate the analysis of routing data. As such, the fields 702 currently defined in the MRT specification do not in themselves 703 create additional security risks, since the fields are not used to 704 induce any particular behavior by the recipient application. 706 7. References 708 7.1. Normative References 710 [1] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 711 RFC 1771, March 1995. 713 [2] Hedrick, C., "Routing Information Protocol", RFC 1058, 714 June 1988. 716 [3] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 717 January 1997. 719 [4] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 721 [5] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol 722 Extensions for BGP-4", RFC 2858, June 2000. 724 [6] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual 725 environments", RFC 1195, December 1990. 727 [7] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, 728 December 1999. 730 [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 731 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 733 7.2. Informative References 735 [9] "MRT Programmer's Guide", November 1999, 736 . 738 Authors' Addresses 740 Larry Blunk 741 Merit Network 743 Email: ljb@merit.edu 745 Manish Karir 746 Merit Network 748 Email: mkarir@merit.edu 750 Craig Labovitz 751 Arbor Networks 753 Email: labovit@arbor.net 755 Intellectual Property Statement 757 The IETF takes no position regarding the validity or scope of any 758 Intellectual Property Rights or other rights that might be claimed to 759 pertain to the implementation or use of the technology described in 760 this document or the extent to which any license under such rights 761 might or might not be available; nor does it represent that it has 762 made any independent effort to identify any such rights. Information 763 on the procedures with respect to rights in RFC documents can be 764 found in BCP 78 and BCP 79. 766 Copies of IPR disclosures made to the IETF Secretariat and any 767 assurances of licenses to be made available, or the result of an 768 attempt made to obtain a general license or permission for the use of 769 such proprietary rights by implementers or users of this 770 specification can be obtained from the IETF on-line IPR repository at 771 http://www.ietf.org/ipr. 773 The IETF invites any interested party to bring to its attention any 774 copyrights, patents or patent applications, or other proprietary 775 rights that may cover technology that may be required to implement 776 this standard. Please address the information to the IETF at 777 ietf-ipr@ietf.org. 779 Disclaimer of Validity 781 This document and the information contained herein are provided on an 782 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 783 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 784 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 785 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 786 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 787 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 789 Copyright Statement 791 Copyright (C) The Internet Society (2006). This document is subject 792 to the rights, licenses and restrictions contained in BCP 78, and 793 except as set forth therein, the authors retain all their rights. 795 Acknowledgment 797 Funding for the RFC Editor function is currently provided by the 798 Internet Society.