idnits 2.17.1 draft-ietf-grow-mrt-06.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, updated by RFC 4748 on line 996. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1007. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1014. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1020. 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 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 (November 19, 2007) is 5974 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 622, but not defined ** Downref: Normative reference to an Historic RFC: RFC 1058 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2740 (Obsoleted by RFC 5340) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 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: May 22, 2008 C. Labovitz 6 Arbor Networks 7 November 19, 2007 9 MRT routing information export format 10 draft-ietf-grow-mrt-06.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 May 22, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 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 46 format can be used to export routing protocol messages, state 47 changes, and routing information base contents. 49 Table of Contents 51 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 3. Basic MRT Format . . . . . . . . . . . . . . . . . . . . . . . 6 54 4. MRT Informational Types . . . . . . . . . . . . . . . . . . . 8 55 4.1. NULL Type . . . . . . . . . . . . . . . . . . . . . . . . 8 56 4.2. START Type . . . . . . . . . . . . . . . . . . . . . . . . 8 57 4.3. DIE Type . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 4.4. I_AM_DEAD Type . . . . . . . . . . . . . . . . . . . . . . 8 59 4.5. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . . . 9 60 5. MRT Routing Information Types . . . . . . . . . . . . . . . . 10 61 5.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 5.1.1. BGP_NULL Subtype . . . . . . . . . . . . . . . . . . . 10 63 5.1.2. BGP_UPDATE Subtype . . . . . . . . . . . . . . . . . . 11 64 5.1.3. BGP_PREF_UPDATE Subtype . . . . . . . . . . . . . . . 11 65 5.1.4. BGP_STATE_CHANGE Subtype . . . . . . . . . . . . . . . 11 66 5.1.5. BGP_SYNC Subtype . . . . . . . . . . . . . . . . . . . 12 67 5.1.6. BGP_OPEN Subtype . . . . . . . . . . . . . . . . . . . 12 68 5.1.7. BGP_NOTIFY Subtype . . . . . . . . . . . . . . . . . . 12 69 5.1.8. BGP_KEEPALIVE Subtype . . . . . . . . . . . . . . . . 12 70 5.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 5.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . . . 13 72 5.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . . . 13 73 5.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . . . 13 74 5.6. OSPF Type . . . . . . . . . . . . . . . . . . . . . . . . 14 75 5.7. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 14 76 5.8. TABLE_DUMP_V2 Type . . . . . . . . . . . . . . . . . . . . 16 77 5.9. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 18 78 5.9.1. BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 19 79 5.9.2. BGP4MP_MESSAGE Subtype . . . . . . . . . . . . . . . . 20 80 5.9.3. BGP4MP_ENTRY Subtype . . . . . . . . . . . . . . . . . 20 81 5.9.4. BGP4MP_SNAPSHOT Subtype . . . . . . . . . . . . . . . 21 82 5.9.5. BGP4MP_STATE_CHANGE_AS4 Subtype . . . . . . . . . . . 21 83 5.9.6. BGP4MP_MESSAGE_AS4 Subtype . . . . . . . . . . . . . . 22 84 5.10. BGP4MP_ET . . . . . . . . . . . . . . . . . . . . . . . . 22 85 5.11. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 23 86 5.12. ISIS_ET Type . . . . . . . . . . . . . . . . . . . . . . . 23 87 5.13. OSPFv3 Type . . . . . . . . . . . . . . . . . . . . . . . 23 88 5.14. OSPFv3_ET Type . . . . . . . . . . . . . . . . . . . . . . 24 89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 90 6.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 25 91 6.2. Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 25 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 93 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 94 8.1. Normative References . . . . . . . . . . . . . . . . . . . 27 95 8.2. Informative References . . . . . . . . . . . . . . . . . . 27 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 97 Intellectual Property and Copyright Statements . . . . . . . . . . 29 99 1. Requirements notation 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 2. Introduction 107 Researchers and engineers often wish to analyze network behavior by 108 studying routing protocol transactions and routing information base 109 snapshots. To this end, the MRT format was developed to encapsulate, 110 export, and archive this information in a standardized data 111 representation. The BGP routing protocol, in particular, has been 112 the subject of extensive study and analysis which has been 113 significantly aided by the availability of the MRT format. The MRT 114 format was initially defined in the MRT Programmer's Guide [MRT PROG 115 GUIDE]. 117 This memo serves to document the MRT format as currently implemented 118 in publicly available software. The format has been extended since 119 it's original introduction in the MRT toolset and these extensions 120 are also included in this memo. Further extensions may be introduced 121 at a later date through additional definitions of the MRT Type field 122 and Subtype fields. 124 3. Basic MRT Format 126 All MRT format messages have a common header which includes a 127 timestamp, Type, Subtype, and length field. The header is followed 128 by a message field. The MRT common header is illustrated below. 130 0 1 2 3 131 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 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Timestamp | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Type | Subtype | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Length | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | Message... (variable) 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 Header Field Descriptions: 144 Timestamp: 146 Time in seconds since 1 January 1970 00:00:00 UTC 148 Type: 150 A 2-octet field that indicates the Type of information 151 contained in the message field. Types 0 through 4 are 152 informational messages pertaining to the state of an MRT 153 collector, while Types 5 and higher are used to convey routing 154 information. 156 Subtype: 158 A 2-octet field that is used to further distinguish message 159 information within a particular message Type. 161 Length: 163 A 4-octet message length field. The length field contains the 164 number of bytes within the message. The length field does not 165 include the length of the MRT common header. 167 Message: 169 A variable length message. The contents of this field are 170 context dependent upon the Type and Subtype fields. 172 4. MRT Informational Types 174 The MRT format defines five Informational Type messages. These 175 messages are intended to signal the state of an MRT data collector 176 and do not contain routing information. These messages are OPTIONAL 177 and were largely intended for use when MRT messages are sent over a 178 network to a remote repository store. However, MRT message 179 repository stores have traditionally resided on the same device as 180 the collector and these Informational Types have seen limited 181 implementation. Further, transport mechanisms for MRT messages are 182 considered to be outside the scope of this document. 184 Two of these messages are considered potentially useful in 185 implementations with a local repository. In particular, the START 186 and I_AM_DEAD messages MAY be used to provide a time reference when a 187 data collector begins and ends the collection process. 189 The message field MAY contain an OPTIONAL message string for 190 diagnostic purposes. The message string encoding MUST follow the 191 UTF-8 transformation format. The Subtype field is unused for these 192 Types and SHOULD be set to 0. 194 The MRT Informational Types are defined below: 196 0 NULL *DEPRECATED* 197 1 START 198 2 DIE *DEPRECATED* 199 3 I_AM_DEAD 200 4 PEER_DOWN *DEPRECATED* 202 4.1. NULL Type 204 The NULL Type message causes no operation and is deprecated. 206 4.2. START Type 208 The START Type indicates a collector is about to begin generating MRT 209 messages. 211 4.3. DIE Type 213 The DIE Type signals a remote MRT repository it should stop accepting 214 messages. This Type is deprecated. 216 4.4. I_AM_DEAD Type 218 An I_AM_DEAD MRT message indicates that a collector has shut down and 219 has stopped generating MRT messages. 221 4.5. PEER_DOWN Type 223 The PEER_DOWN message was intended to indicate that a collector had 224 lost association with a BGP peer. However, the MRT format provides 225 BGP state change message types which duplicate this functionality. 226 This Type is deprecated. 228 5. MRT Routing Information Types 230 The following Types are currently defined for the MRT format. Types 231 5-12 were defined in the MRT Toolkit package. The BGP4MP Type, 232 number 16, was initially defined in the Zebra routing software 233 package. The BGP4MP_ET, ISIS, and ISIS_ET Types were initially 234 defined in the Sprint Labs Python Routing Toolkit (PyRT). 236 5 BGP *DEPRECATED* 237 6 RIP 238 7 IDRP *DEPRECATED* 239 8 RIPNG 240 9 BGP4PLUS *DEPRECATED* 241 10 BGP4PLUS_01 *DEPRECATED* 242 11 OSPF 243 12 TABLE_DUMP 244 13 TABLE_DUMP_V2 245 16 BGP4MP 246 17 BGP4MP_ET 247 32 ISIS 248 33 ISIS_ET 249 48 OSPFv3 250 49 OSPFv3_ET 252 5.1. BGP Type 254 The BGP Type indicates the Message field contains BGP routing 255 information. The BGP routing protocol is defined in RFC 4271 256 [RFC4271]. The information in the message is dependent on the 257 Subtype value. The BGP Type and all associated Subtypes are 258 considered to be DEPRECATED by the BGP4MP Type. 260 The following BGP Subtypes are defined for the MRT BGP Type. 262 0 BGP_NULL 263 1 BGP_UPDATE 264 2 BGP_PREF_UPDATE 265 3 BGP_STATE_CHANGE 266 4 BGP_SYNC *DEPRECATED* 267 5 BGP_OPEN 268 6 BGP_NOTIFY 269 7 BGP_KEEPALIVE 271 5.1.1. BGP_NULL Subtype 273 The BGP_NULL Subtype is a reserved Subtype. 275 5.1.2. BGP_UPDATE Subtype 277 The BGP_UPDATE Subtype is used to encode BGP UPDATE messages. The 278 format of the MRT Message field for this Subtype is as follows: 280 0 1 2 3 281 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 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Source AS number | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Source IP address | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Destination AS number | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Destination IP address | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | BGP UPDATE Contents (variable) 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 The BGP UPDATE contents include the entire BGP UPDATE message which 295 follows the BGP Message Header. The BGP Message Header itself is not 296 included. 298 5.1.3. BGP_PREF_UPDATE Subtype 300 The BGP_PREF_UPDATE Subtype is not defined. 302 5.1.4. BGP_STATE_CHANGE Subtype 304 The BGP_STATE_CHANGE Subtype is used to record changes in the BGP 305 finite state machine. These FSM states and their numeric encodings 306 are defined in RFC 4271 [RFC4271], Appendix 1. Both the old state 307 value and the new state value are encoded as 2-octet numbers. The 308 format of the MRT Message field is as follows: 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Source AS number | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Source IP address | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Old State | New State | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 5.1.5. BGP_SYNC Subtype 322 The BGP_SYNC Subtype was intended to convey a system file name where 323 BGP Table Dump messages should be recorded. The View # was to 324 correspond to the View # provided in the TABLE_DUMP Type messages. 325 This Type is considered to be deprecated. The following format 326 applies to this Subtype: 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | View # | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | File Name... (variable) 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 The File Name is terminated with a NULL (0) character. 338 5.1.6. BGP_OPEN Subtype 340 The BGP_OPEN Subtype is used to encode BGP OPEN messages. The format 341 of the MRT Message field for this Subtype is the same as the 342 BGP_UPDATE, however, the last field contains the contents of the BGP 343 OPEN message. 345 5.1.7. BGP_NOTIFY Subtype 347 The BGP_NOTIFY Subtype is used to encode BGP NOTIFICATION messages. 348 The format of the MRT Message field for this Subtype is the same as 349 the BGP_UPDATE, however, the last field contains the contents of the 350 BGP NOTIFICATION message. 352 5.1.8. BGP_KEEPALIVE Subtype 354 The BGP_KEEPALIVE Subtype is used to encode BGP KEEPALIVE messages. 355 The format of the MRT Message field for this Subtype is the same as 356 the BGP_UPDATE, however, the last field contains no information. 358 5.2. RIP Type 360 The RIP Type is used to export RIP protocol packets as defined in RFC 361 1058 [RFC1058]. The Subtype field is currently reserved for this 362 Type and SHOULD be set to 0. 364 The format of the MRT Message field for the RIP Type is as follows: 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Source IP address | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Destination IP address | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | RIP Message Contents (variable) 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 5.3. IDRP Type 378 The IDRP Type is used to export Inter-Domain-Routing Protocol (IDRP) 379 protocol information as defined in the ISO/IEC 10747 standard. The 380 Subtype field is unused. This Type is deprecated due to lack of 381 deployment of IDRP. 383 5.4. RIPNG Type 385 The RIPNG Type is used to export RIPNG protocol packets as defined in 386 RFC 2080 [RFC2080]. The Subtype field is currently reserved for this 387 Type and SHOULD be set to 0. 389 The format of the MRT Message field for the RIPNG Type is as follows: 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Source IP address | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Destination IP address | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | RIPNG Message Contents (variable) 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 5.5. BGP4PLUS and BGP4PLUS_01 Types 403 The BGP4PLUS and BGP4PLUS_01 Types were defined to support IPv6 BGP 404 routing information. The BGP4PLUS Type was specified based on the 405 initial Internet Draft for Multiprotocol Extensions to BGP-4. The 406 BGP4PLUS_01 Type was specified to correspond to the -01 revision of 407 this Internet Draft. The two Types share the same definitions in 408 terms of their MRT format specifications. 410 The Subtype field definitions are shared with the BGP Type, however, 411 the address fields in the BGP_UPDATE, BGP_OPEN, BGP_NOTIFY, 412 BGP_KEEPALIVE, and BGP_STATE_CHANGE Subtype messages are extended to 413 16 octets for IPv6 addresses. As with the BGP Type, the BGP4PLUS and 414 BGP4PLUS_01 Types are deprecated as they superseded by the BGP4MP 415 Type. 417 5.6. OSPF Type 419 This Type supports the OSPF Protocol as defined in RFC 2328 420 [RFC2328]. The Subtype field may contain two possible values: 422 0 OSPF_STATE_CHANGE 423 1 OSPF_LSA_UPDATE 425 The format of the MRT Message field for the OSPF Type is as follows: 427 0 1 2 3 428 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 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Source IP address | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Destination IP address | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | OSPF Message Contents (variable) 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 5.7. TABLE_DUMP Type 439 The TABLE_DUMP Type is used to encode the contents of a BGP Routing 440 Information Base (RIB). Each RIB entry is encoded in a distinct 441 sequential MRT record. The Subtype field is used to encode whether 442 the RIB entry contains IPv4 or IPv6 addresses. There are two 443 possible values for the Subtype as shown below. 445 1 AFI_IPv4 446 2 AFI_IPv6 448 The format of the TABLE_DUMP Type is illustrated below. 450 0 1 2 3 451 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 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | View # | Sequence number | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Prefix (variable) | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Prefix Length | Status | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Originated Time | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Peer IP address (variable) | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Peer AS | Attribute Length | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | BGP Attribute... (variable) 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 The View field is normally 0 and is intended for cases where an 469 implementation may have multiple RIB views (such as a route server). 470 The Sequence field is a simple incremental counter for each RIB 471 entry. A typical RIB dump will exceed the 16-bit bounds of this 472 counter and implementation should simply wrap back to zero and 473 continue incrementing the counter in such cases. 475 The Prefix field contains the IP address of a particular routing RIB 476 entry. The size of this field is dependent on the value of the 477 Subtype for this message. For AFI_IPv4, this field is 4 octets, for 478 AFI_IPv6, it is 16 octets in length. The Prefix Length field 479 indicates the length in bits of the prefix mask for the preceding 480 Prefix field. 482 The Status octet is not used in the TABLE_DUMP Type and SHOULD be set 483 to 1. 485 The Originated Time contains the 4-octet time at which this prefix 486 was heard. The value represents the time in seconds since 1 January 487 1970 00:00:00 UTC. 489 The Peer IP field is the IP address of the peer which provided the 490 update for this RIB entry. As with the Prefix field, the size of 491 this field is dependent on the Subtype. AFI_IPv4 indicates a 4 octet 492 field and an IPv4 address, while a Subtype of AFI_IPv6 requires a 16 493 octet field and an IPv6 address. The Peer AS field contains the AS 494 number of the peer. 496 Attribute length is the length of Attribute field and is 2-octets. 497 The Attribute field contains the attribute information for the RIB 498 entry. 500 5.8. TABLE_DUMP_V2 Type 502 The TABLE_DUMP_V2 Type updates the TABLE_DUMP Type to include 32-bit 503 ASN support and full support for BGP Multiprotocol extensions. It 504 also improves upon the space efficiency of the TABLE_DUMP Type by 505 employing an index table for peers and permitting a single MRT record 506 per NLRI entry. The following subtypes are used with the 507 TABLE_DUMP_V2 Type. 509 1 PEER_INDEX_TABLE 510 2 RIB_IPV4_UNICAST 511 3 RIB_IPV4_MULTICAST 512 4 RIB_IPV6_UNICAST 513 5 RIB_IPV6_MULTICAST 514 6 RIB_GENERIC 516 An initial PEER_INDEX_TABLE MRT record provides the BGP ID of the 517 collector, an optional view name, and a list of indexed peers. 518 Following the PEER_INDEX_TABLE MRT record, a series of MRT records 519 are used to encode RIB table entries. The header of the 520 PEER_INDEX_TABLE Subtype is shown below. The View Name is optional 521 and, if not present, the View Name Length MUST be set to 0. The View 522 Name encoding MUST follow the UTF-8 transformation format. 524 0 1 2 3 525 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 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Collector BGP ID | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | View Name Length | View Name (variable) | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Peer Count | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 The format of the peer entries is shown below. The PEER_INDEX_TABLE 535 record contains Peer Count peer entries. 537 0 1 2 3 538 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 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Peer Type | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Peer BGP ID | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | Peer IP address (variable) | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Peer AS (variable) | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 The Peer Type, Peer BGP ID, Peer IP, and Peer AS fields are repeated 550 as indicated by the Peer Count field. The position of the Peer in 551 the PEER_INDEX_TABLE is used as an index in the subsequent 552 TABLE_DUMP_V2 MRT records. The index number begins with 0. 554 The Peer Type field is a bit field which encodes the type of the AS 555 and IP address as follows: 557 Bit 0 - unset for IPv4 Peer IP address, set for IPv6 558 Bit 1 - unset when Peer AS field is 16 bits, set when it's 32 bits 560 The records which follow the PEER_INDEX_TABLE record constitute the 561 RIB entries and include a header which specifies a sequence number, 562 NLRI, and a count of the number of RIB entries which follow. 564 The format for the RIB_IPV4_UNICAST, RIB_IPV4_MULTICAST, 565 RIB_IPV6_UNICAST, and RIB_IPV6_MULTICAST headers are shown below. 566 The Prefix Length and Prefix fields are encoded in the same manner as 567 the BGP NLRI encoding for IPV4 and IPV6 prefixes. Namely, the Prefix 568 field contains address prefixes followed by enough trailing bits to 569 make the end of the field fall on an octet boundary. Note that the 570 value of trailing bits is irrelevant. 572 0 1 2 3 573 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 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Sequence number | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | Prefix Length | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Prefix (variable) | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | Entry Count | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 The RIB_GENERIC header is shown below. It includes Address Family 585 Identifier (AFI), Subsequent AFI and a single NLRI entry. The NLRI 586 information is specific to the AFI and SAFI values. An 587 implementation which does not recognize particular AFI and SAFI 588 values SHOULD discard the remainder of the MRT record. 590 0 1 2 3 591 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 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Sequence number | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Address Family Identifier |Subsequent AFI | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Network Layer Reachability Information (variable) | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Entry Count | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 The RIB entry headers are followed by a series of RIB entries which 603 are repeated Entry Count times. These entries share a common format 604 as shown below. They include a Peer Index from the PEER_INDEX_TABLE 605 MRT record, an originated time for the RIB entry, and the BGP path 606 attribute length and attributes encoded as provided in a BGP Update 607 message. 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 | Peer Index | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Originated Time | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Attribute Length | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | BGP Attributes... (variable) 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 There is one exception to the encoding of BGP attributes for the BGP 622 MP_REACH_NLRI attribute (BGP Type Code 14) [RFC 4760]. Since the 623 AFI, SAFI, and NLRI information is already encoded in the 624 MULTIPROTOCOL header, only the Next Hop Address Length and Next Hop 625 Address fields are included. The Reserved field is omitted. The 626 attribute length is also adjusted to reflect only the length of the 627 Next Hop Address Length and Next Hop Address fields. 629 5.9. BGP4MP Type 631 This Type was initially defined in the Zebra software package for the 632 BGP protocol with multiprotocol extension support as defined by RFC 633 4760 [RFC4760]. It supersedes the BGP, BGP4PLUS, BGP4PLUS_01 Types. 634 The BGP4MP Type has four Subtypes which are defined as follows: 636 0 BGP4MP_STATE_CHANGE 637 1 BGP4MP_MESSAGE 638 2 BGP4MP_ENTRY *DEPRECATED* 639 3 BGP4MP_SNAPSHOT *DEPRECATED* 640 4 BGP4MP_STATE_CHANGE_AS4 641 5 BGP4MP_MESSAGE_AS4 643 5.9.1. BGP4MP_STATE_CHANGE Subtype 645 This record is used to encode state changes in the BGP finite state 646 machine. As with the BGP_STATE_CHANGE Subtype, the BGP FSM states 647 are encoded in the Old State and New State fields to indicate the 648 previous and current state. The format is illustrated below: 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 | Source AS number | Destination AS number | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Interface Index | Address Family | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Source IP address (variable) | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | Destination IP address (variable) | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | Old State | New State | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 While BGP4MP_STATE_CHANGE message is similar to the BGP_STATE_CHANGE 665 message, it also includes interface index and Address Family fields. 666 As with the BGP_STATE_CHANGE message, the FSM states and their 667 numeric encodings are defined in RFC 4271 [RFC4271], Appendix 1. The 668 interface index provides the interface number of the peering session. 669 The index value is OPTIONAL and MAY be zero if unknown or 670 unsupported. The Address Family indicates what types of addresses 671 are in the the address fields. At present, the following AFI Types 672 are supported: 674 1 AFI_IPv4 675 2 AFI_IPv6 677 5.9.2. BGP4MP_MESSAGE Subtype 679 This Subtype is used to encode BGP Messages. It is similar to the 680 BGP_UPDATE Subtype, except that is can be used to encode any Type of 681 message (not just BGP UPDATES). In order to determine the BGP 682 message Type, the entire BGP message, including the BGP header, is 683 included in the BGP Message field. The BGP4MP_MESSAGE fields are 684 shown below: 686 0 1 2 3 687 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 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | Source AS number | Destination AS number | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | Interface Index | Address Family | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Source IP address (variable) | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | Destination IP address (variable) | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | BGP Message... (variable) 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 The interface index provides the interface number of the peering 701 session. The index value is OPTIONAL and MAY be zero if unknown or 702 unsupported. The Address Family indicates what types of addresses 703 are in the the subsequent address fields. At present, the following 704 AFI Types are supported: 706 1 AFI_IPv4 707 2 AFI_IPv6 709 Note that the Address Family value only applies to the IP addresses 710 contained in the MRT header. The BGP4MP_MESSAGE Subtype is otherwise 711 transparent to the contents of the actual message which may contain 712 any valid AFI/SAFI values. Only one BGP message may be encoded in 713 the BGP4MP_MESSAGE Subtype. 715 5.9.3. BGP4MP_ENTRY Subtype 717 This Subtype is similar to the TABLE_DUMP Type and is used to record 718 RIB table entries. It extends the TABLE_DUMP Type to include true 719 multiprotocol support. However, this Type does not support 32-bit AS 720 numbers and has not been widely implemented. This Type is deprecated 721 in favor of the TABLE_DUMP_V2 which includes 32-bit AS number support 722 and a more compact format. 724 0 1 2 3 725 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 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | Source AS number | Destination AS number | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | Interface Index | Address Family | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | Source IP address (variable) | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | Destination IP address (variable) | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | View # | Status | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | Time last change | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | Address Family | SAFI | Next-Hop-Len | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | Next Hop Address (variable) | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | Prefix Length | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | Address Prefix (variable) | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | Attribute Length | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | BGP Attribute... (variable) 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 5.9.4. BGP4MP_SNAPSHOT Subtype 754 This Subtype was intended to convey a system file name where 755 BGP4MP_ENTRY messages should be recorded. It is similar to the 756 BGP_SYNC message Subtype and is deprecated. 758 0 1 2 3 759 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 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | View # | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | File Name... (variable) 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 5.9.5. BGP4MP_STATE_CHANGE_AS4 Subtype 768 This Subtype updates the BGP4MP_STATE_CHANGE Subtype to support 32BIT 769 Autonomous System numbers. As with the BGP4MP_STATE_CHANGE Subtype, 770 the BGP FSM states are encoded in the Old State and New State fields 771 to indicate the previous and current state. Aside from the extension 772 of the source and destination AS fields to 32 bits, this subtype is 773 otherwise identical to the BGP4MP_STATE_CHANGE Subtype. The 774 BGP4MP_STATE_CHANGE_AS4 fields are shown below: 776 0 1 2 3 777 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 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Source AS number | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | Destination AS number | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | Interface Index | Address Family | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | Source IP address (variable) | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | Destination IP address (variable) | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | Old State | New State | 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 5.9.6. BGP4MP_MESSAGE_AS4 Subtype 794 This Subtype updates the BGP4MP_MESSAGE Subtype to support 32BIT 795 Autonomous System numbers. The BGP4MP_MESSAGE_AS4 fields are shown 796 below: 798 0 1 2 3 799 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 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | Source AS number | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 | Destination AS number | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | Interface Index | Address Family | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | Source IP address (variable) | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | Destination IP address (variable) | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | BGP Message... (variable) 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 5.10. BGP4MP_ET 816 This Type was initially defined in the Sprint Labs Python Routing 817 Toolkit (PyRT). It extends the MRT common header field to include a 818 32-bit microsecond timestamp field. The type and subtype field 819 definitions remain as defined for the BGP4MP Type. The 32-bit 820 microsecond timestamp immediately follows the length field in the MRT 821 common header and precedes all other fields in the message. The 32- 822 bit microsecond field is included in the computation of the length 823 field value. The MRT common header modification is illustrated 824 below. 826 0 1 2 3 827 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 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | Timestamp | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | Type | Subtype | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | Length | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | microsecond timestamp | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | Message... (variable) 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 5.11. ISIS Type 842 This Type was initially defined in the Sprint Labs Python Routing and 843 supports the IS-IS routing protocol as defined in RFC 1195 [RFC1195]. 844 There is no Type specific header for the ISIS Type. The Subtype code 845 for this Type is undefined. The ISIS PDU directly follows the MRT 846 common header fields. 848 5.12. ISIS_ET Type 850 The ISIS_ET Type extends the the ISIS Type to support microsecond 851 timestamps. As with the BGP4MP_ET Type, a 32-bit microsecond 852 timestamp field is appended to the MRT common header after the length 853 field. The ISIS_ET Type is otherwise identical to the ISIS Type. 855 5.13. OSPFv3 Type 857 The OSPFv3 Type extends the original OSPF Type to support IPv6 858 addresses for the OSPFv3 protocol as defined in RFC 2740 [RFC2740]. 859 The format of the MRT Message field for the OSPFv3 Type is as 860 follows: 862 0 1 2 3 863 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 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | Address Family | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | Source IP address (variable) | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | Destination IP address (variable) | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | OSPF Message Contents (variable) 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 5.14. OSPFv3_ET Type 876 The OSPFv3_ET Type extends the the OSPFv3 Type to support microsecond 877 timestamps. As with the BGP4MP_ET Type, a 32-bit microsecond 878 timestamp field is appended to the MRT common header after the length 879 field and its length is included in the calculation of the length 880 field value. The OSPFv3_ET Type is otherwise identical to the OSPFv3 881 Type. 883 6. IANA Considerations 885 This section provides guidance to the Internet Assigned Numbers 886 Authority (IANA) regarding registration of values related to the MRT 887 specification, in accordance with BCP 26, RFC 2434 [RFC2434]. 889 There are two name spaces in MRT that require registration: Type 890 Codes and Subtype Codes. 892 MRT is not intended as a general-purpose specification for protocol 893 information export, and allocations should not be made for purposes 894 unrelated to routing protocol information export. 896 The following policies are used here with the meanings defined in BCP 897 26: "Specification Required", "IETF Consensus". 899 6.1. Type Codes 901 Type Codes have a range from 0 to 65535, of which 0-64 have been 902 allocated. New Type Codes MUST be allocated starting at 65. Type 903 Codes 65 - 32767 are to be assigned by IETF Consensus. Type Codes 904 32768 - 65535 are assigned based on Specification Required. 906 6.2. Subtype Codes 908 Subtype Codes have a range from 0 to 65535. Subtype definitions are 909 specific to a particular Type Code definition. New Subtype Code 910 definition must reference an existing Type Code to which the Subtype 911 belongs. As Subtype Codes are specific to Type Codes, new numbers 912 must be unique for the particular Type Code to which the Subtype 913 applies. Subtype Codes specific to the Type Codes 0 - 32767 are 914 assigned by IETF Consensus. Subtype Codes specific to Type Codes 915 32768 - 65535 are assigned based on Specification Required. 917 7. Security Considerations 919 The MRT Format utilizes a structure which can store routing protocol 920 information data. The fields defined in the MRT specification are of 921 a descriptive nature and provide information that is useful to 922 facilitate the analysis of routing data. As such, the fields 923 currently defined in the MRT specification do not in themselves 924 create additional security risks, since the fields are not used to 925 induce any particular behavior by the recipient application. 927 8. References 929 8.1. Normative References 931 [RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, 932 June 1988. 934 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 935 dual environments", RFC 1195, December 1990. 937 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 938 January 1997. 940 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 941 Requirement Levels", BCP 14, RFC 2119, March 1997. 943 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 945 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 946 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 947 October 1998. 949 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 950 RFC 2740, December 1999. 952 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 953 Protocol 4 (BGP-4)", RFC 4271, January 2006. 955 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 956 "Multiprotocol Extensions for BGP-4", RFC 4760, 957 January 2007. 959 8.2. Informative References 961 [MRT PROG GUIDE] 962 Labovitz, C., "MRT Programmer's Guide", November 1999, 963 . 965 Authors' Addresses 967 Larry Blunk 968 Merit Network 970 Email: ljb@merit.edu 972 Manish Karir 973 Merit Network 975 Email: mkarir@merit.edu 977 Craig Labovitz 978 Arbor Networks 980 Email: labovit@arbor.net 982 Full Copyright Statement 984 Copyright (C) The IETF Trust (2007). 986 This document is subject to the rights, licenses and restrictions 987 contained in BCP 78, and except as set forth therein, the authors 988 retain all their rights. 990 This document and the information contained herein are provided on an 991 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 992 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 993 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 994 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 995 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 996 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 998 Intellectual Property 1000 The IETF takes no position regarding the validity or scope of any 1001 Intellectual Property Rights or other rights that might be claimed to 1002 pertain to the implementation or use of the technology described in 1003 this document or the extent to which any license under such rights 1004 might or might not be available; nor does it represent that it has 1005 made any independent effort to identify any such rights. Information 1006 on the procedures with respect to rights in RFC documents can be 1007 found in BCP 78 and BCP 79. 1009 Copies of IPR disclosures made to the IETF Secretariat and any 1010 assurances of licenses to be made available, or the result of an 1011 attempt made to obtain a general license or permission for the use of 1012 such proprietary rights by implementers or users of this 1013 specification can be obtained from the IETF on-line IPR repository at 1014 http://www.ietf.org/ipr. 1016 The IETF invites any interested party to bring to its attention any 1017 copyrights, patents or patent applications, or other proprietary 1018 rights that may cover technology that may be required to implement 1019 this standard. Please address the information to the IETF at 1020 ietf-ipr@ietf.org. 1022 Acknowledgment 1024 Funding for the RFC Editor function is provided by the IETF 1025 Administrative Support Activity (IASA).