idnits 2.17.1 draft-ietf-grow-mrt-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 17, 2011) is 4629 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-AF' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 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: February 18, 2012 C. Labovitz 6 Deepfield Networks 7 August 17, 2011 9 MRT routing information export format 10 draft-ietf-grow-mrt-17.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 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). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on February 18, 2012. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1. Specification of Requirements . . . . . . . . . . . . . . 4 68 2. MRT Common Header . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Extended Timestamp MRT Header . . . . . . . . . . . . . . . . 7 70 4. MRT Types . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 4.1. OSPFv2 Type . . . . . . . . . . . . . . . . . . . . . . . 8 72 4.2. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 9 73 4.3. TABLE_DUMP_V2 Type . . . . . . . . . . . . . . . . . . . . 10 74 4.3.1. PEER_INDEX_TABLE Subtype . . . . . . . . . . . . . . . 11 75 4.3.2. AFI/SAFI specific RIB Subtypes . . . . . . . . . . . . 12 76 4.3.3. RIB_GENERIC Subtype . . . . . . . . . . . . . . . . . 13 77 4.3.4. RIB Entries . . . . . . . . . . . . . . . . . . . . . 13 78 4.4. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 14 79 4.4.1. BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 15 80 4.4.2. BGP4MP_MESSAGE Subtype . . . . . . . . . . . . . . . . 16 81 4.4.3. BGP4MP_MESSAGE_AS4 Subtype . . . . . . . . . . . . . . 17 82 4.4.4. BGP4MP_STATE_CHANGE_AS4 Subtype . . . . . . . . . . . 17 83 4.4.5. BGP4MP_MESSAGE_LOCAL Subtype . . . . . . . . . . . . . 18 84 4.4.6. BGP4MP_MESSAGE_AS4_LOCAL Subtype . . . . . . . . . . . 18 85 4.5. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 18 86 4.6. OSPFv3 Type . . . . . . . . . . . . . . . . . . . . . . . 19 87 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 88 5.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 20 89 5.2. Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 20 90 5.3. Defined Type Codes . . . . . . . . . . . . . . . . . . . . 20 91 5.4. Defined BGP, BGP4PLUS, and BGP4PLUS_01 Subtype Codes . . . 21 92 5.5. Defined TABLE_DUMP Subtype Codes . . . . . . . . . . . . . 21 93 5.6. Defined TABLE_DUMP_V2 Subtype Codes . . . . . . . . . . . 22 94 5.7. Defined BGP4MP and BGP4MP_ET Subtype Codes . . . . . . . . 22 95 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 96 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 97 7.1. Normative References . . . . . . . . . . . . . . . . . . . 24 98 7.2. Informative References . . . . . . . . . . . . . . . . . . 24 99 Appendix A. MRT Encoding Examples . . . . . . . . . . . . . . . . 26 100 Appendix B. Deprecated MRT Types . . . . . . . . . . . . . . . . 29 101 B.1. Deprecated MRT Informational Types . . . . . . . . . . . . 29 102 B.1.1. NULL Type . . . . . . . . . . . . . . . . . . . . . . 29 103 B.1.2. START Type . . . . . . . . . . . . . . . . . . . . . . 29 104 B.1.3. DIE Type . . . . . . . . . . . . . . . . . . . . . . . 29 105 B.1.4. I_AM_DEAD Type . . . . . . . . . . . . . . . . . . . . 29 106 B.1.5. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . 30 107 B.2. Other Deprecated MRT Types . . . . . . . . . . . . . . . . 30 108 B.2.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . 30 109 B.2.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . 33 110 B.2.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . 33 111 B.2.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . 33 112 B.2.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . 34 113 B.2.6. Deprecated BGP4MP Subtypes . . . . . . . . . . . . . . 34 114 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 36 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 117 1. Introduction 119 Researchers and engineers often wish to analyze network behavior by 120 studying routing protocol transactions and routing information base 121 snapshots. To this end, the MRT record format was developed to 122 encapsulate, export, and archive this information in a standardized 123 data representation. 125 The BGP routing protocol, in particular, has been the subject of 126 extensive study and analysis which has been significantly aided by 127 the availability of the MRT format. Two examples of large-scale MRT 128 based BGP archival projects include the University of Oregon Route 129 Views Project and the RIPE NCC Routing Information Service (RIS). 131 The MRT format was initially defined in the MRT Programmer's Guide 132 [MRT PROG GUIDE]. Subsequent extensions were made in the the GNU 133 Zebra software routing suite and the Sprint Advanced Technology Labs 134 Python Routing Toolkit (PyRT). Further extensions may be introduced 135 at a later date through additional definitions of the MRT Type field 136 and Subtype fields. 138 A number of MRT record types listed in the MRT Programmer's Guide 139 [MRT PROG GUIDE] are not known to have been implemented and, in some 140 cases, were incompletely specified. Further, several types were 141 employed in early MRT implementations, but saw limited use and were 142 updated by improved versions. These types are considered to be 143 deprecated and are documented in the Deprecated MRT Types 144 (Appendix B) section at the end of this document. The deprecated 145 types consist of codes 0 through 10 inclusive. Some of the 146 deprecated types may be of interest to researchers examining 147 historical MRT format archives. 149 Fields which contain multi-octet numeric values are encoded in 150 network octet order from most significant octet to least significant 151 octet. Fields which contain routing message fields are encoded in 152 the same order as they appear in the packet contents. 154 1.1. Specification of Requirements 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in [RFC2119]. 160 2. MRT Common Header 162 All MRT format records have a Common Header which consists of a 163 Timestamp, Type, Subtype, and Length field. The header is followed 164 by a Message field. The MRT Common Header is illustrated below. 166 0 1 2 3 167 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 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Timestamp | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Type | Subtype | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Length | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Message... (variable) 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 Figure 1: MRT Common Header 180 Header Field Descriptions: 182 Timestamp: 184 A 4-octet field whose integer value is the number of seconds, 185 excluding leap seconds, elapsed since midnight proleptic 186 Coordinated Universal Time (UTC). This representation of time 187 is sometimes called "UNIX time" POSIX [IEEE.P1003.1-1990]. 188 This time format cannot represent time values prior to January 189 1, 1970. The latest UTC time value that can be represented by 190 a four-octet integer value is 03:14:07 on January 19, 2038, 191 which is represented by the hexadecimal value 7FFFFFFF. 192 Implementations which wish to create MRT records after this 193 date will need to provide an alternate EPOCH time base for the 194 Timestamp field. Mechanisms for indicating this alternate 195 EPOCH are currently outside the scope of this document. 197 Type: 199 A 2-octet field that indicates the Type of information 200 contained in the message field. Types 0 through 4 are 201 informational messages pertaining to the state of an MRT 202 collector, while Types 5 and higher are used to convey routing 203 information. 205 Subtype: 207 A 2-octet field that is used to further distinguish message 208 information within a particular record Type. 210 Length: 212 A 4-octet message length field. The length field contains the 213 number of octets within the message. The length field does not 214 include the length of the MRT Common Header. 216 Message: 218 A variable length message. The contents of this field are 219 context dependent upon the Type and Subtype fields. 221 3. Extended Timestamp MRT Header 223 Several MRT format record types support a variant type with an 224 extended timestamp field. The purpose of this field is to support 225 measurements at sub-second resolutions. This field, Microsecond 226 Timestamp, contains an unsigned 32BIT offset value in microseconds 227 which is added to the Timestamp field value. The Timestamp field 228 remains as defined in the MRT Common Header. The Microsecond 229 Timestamp immediately follows the length field in the MRT Common 230 Header and precedes all other fields in the message. The Microsecond 231 Timestamp is included in the computation of the length field value. 232 The Extended Timestamp MRT Header is illustrated below. 234 0 1 2 3 235 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 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Timestamp | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Type | Subtype | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Length | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Microsecond Timestamp | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Message... (variable) 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Figure 2: Extended Timestamp MRT Header 250 4. MRT Types 252 The following MRT Types are currently defined for the MRT format. 253 The MRT Types which contain the "_ET" suffix in their names identify 254 those types which use an Extended Timestamp MRT Header. The subtype 255 and message fields in these types remain as defined for the MRT Types 256 of the same name without the "_ET" suffix. 258 11 OSPFv2 259 12 TABLE_DUMP 260 13 TABLE_DUMP_V2 261 16 BGP4MP 262 17 BGP4MP_ET 263 32 ISIS 264 33 ISIS_ET 265 48 OSPFv3 266 49 OSPFv3_ET 268 4.1. OSPFv2 Type 270 This Type supports the OSPFv2 Protocol as defined in RFC 2328 271 [RFC2328]. It is used to encode the exchange of OSPF protocol 272 packets. 274 The format of the MRT Message field for the OSPFv2 Type is as 275 follows: 277 0 1 2 3 278 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 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Remote IP address | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Local IP address | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | OSPF Message Contents (variable) 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Figure 3: OSPFv2 Type 289 The Remote IP address field contains Source IPv4 [RFC0791] address 290 from the IP header of the OSPF message. The Local IP address 291 contains the Destination IPv4 address from the IP header. The OSPF 292 Message Contents field contains the complete contents of the OSPF 293 packet following the IP header. 295 4.2. TABLE_DUMP Type 297 The TABLE_DUMP Type is used to encode the contents of a BGP Routing 298 Information Base (RIB). Each RIB entry is encoded in a distinct 299 sequential MRT record. It is RECOMMENDED that new MRT encoding 300 implementations use the TABLE_DUMP_V2 Type (see below) instead of the 301 TABLE_DUMP Type due to limitations in this type. However, due to the 302 significant volume of historical data encoded with this type, MRT 303 decoding applications MAY wish to support this type. 305 The Subtype field is used to encode whether the RIB entry contains 306 IPv4 or IPv6 [RFC2460] addresses. There are two possible values for 307 the Subtype as shown below. 309 1 AFI_IPv4 310 2 AFI_IPv6 312 The format of the TABLE_DUMP Type is illustrated below. 314 0 1 2 3 315 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 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | View # | Sequence number | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Prefix (variable) | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Prefix Length | Status | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Originated Time | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Peer IP address (variable) | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Peer AS | Attribute Length | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | BGP Attribute... (variable) 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 Figure 4: TABLE_DUMP Type 334 The View field is normally 0 and is intended for cases where an 335 implementation may have multiple RIB views (such as a route server). 336 In cases where multiple RIB views are present, an implementation MAY 337 use the the view field to distinguish entries from each view. The 338 Sequence field is a simple incremental counter for each RIB entry. A 339 typical RIB dump will exceed the 16-bit bounds of this counter and 340 implementation SHOULD simply wrap back to zero and continue 341 incrementing the counter in such cases. 343 The Prefix field contains the IP address of a particular RIB entry. 344 The size of this field is dependent on the value of the Subtype for 345 this record. The AFI_IPv4 Subtype value specifies an Address Family 346 [IANA-AF] Identifier (AFI) type of IPv4. It specifies a prefix field 347 length of 4 octets. For AFI_IPv6, it is 16 octets in length. The 348 Prefix Length field indicates the length in bits of the prefix mask 349 for the preceding Prefix field. 351 The Status octet is unused in the TABLE_DUMP Type and SHOULD be set 352 to 1. 354 The Originated Time contains the 4-octet time at which this prefix 355 was heard. The value represents the time in seconds since 1 January 356 1970 00:00:00 UTC. 358 The Peer IP field is the IP address of the peer which provided the 359 update for this RIB entry. As with the Prefix field, the size of 360 this field is dependent on the Subtype. AFI_IPv4 indicates a 4 octet 361 field and an IPv4 address, while a Subtype of AFI_IPv6 requires a 16 362 octet field and an IPv6 address. The Peer AS field contains the 2 363 octet Autonomous System (AS) number of the peer. 365 The TABLE_DUMP Type does not permit 4-Byte Peer AS numbers. Nor does 366 it allow the AFI of the peer IP to differ from the AFI of the Prefix 367 field. The TABLE_DUMP_V2 Type MUST be used in these situations. 369 Attribute Length contains the length of Attribute field and is 370 2-octets. The BGP Attribute field contains the BGP attribute 371 information for the RIB entry. The AS_PATH attribute MUST only 372 consist of 2-Byte AS numbers. The TABLE_DUMP_V2 supports 4-Byte AS 373 numbers in the AS_PATH attribute. 375 4.3. TABLE_DUMP_V2 Type 377 The TABLE_DUMP_V2 Type updates the TABLE_DUMP Type to include 4-Byte 378 Autonomous System Number (ASN) support and full support for BGP 379 Multiprotocol extensions. It also improves upon the space efficiency 380 of the TABLE_DUMP Type by employing an index table for peers and 381 permitting a single MRT record per Network Layer Reachability 382 Information (NLRI) entry. The following subtypes are used with the 383 TABLE_DUMP_V2 Type. 385 1 PEER_INDEX_TABLE 386 2 RIB_IPV4_UNICAST 387 3 RIB_IPV4_MULTICAST 388 4 RIB_IPV6_UNICAST 389 5 RIB_IPV6_MULTICAST 390 6 RIB_GENERIC 392 4.3.1. PEER_INDEX_TABLE Subtype 394 An initial PEER_INDEX_TABLE MRT record provides the BGP ID of the 395 collector, an OPTIONAL view name, and a list of indexed peers. 396 Following the PEER_INDEX_TABLE MRT record, a series of MRT records 397 are used to encode RIB table entries. This series of MRT records use 398 subtypes 2-6 and are separate from the PEER_INDEX_TABLE MRT record 399 itself and include full MRT record headers. The RIB entry MRT 400 records MUST immediately follow the PEER_INDEX_TABLE MRT record. 402 The header of the PEER_INDEX_TABLE Subtype is shown below. The View 403 Name is OPTIONAL and, if not present, the View Name Length MUST be 404 set to 0. The View Name encoding MUST follow the UTF-8 405 transformation format [RFC3629]. 407 0 1 2 3 408 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 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Collector BGP ID | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | View Name Length | View Name (variable) | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Peer Count | Peer Entries (variable) 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 Figure 5: PEER_INDEX_TABLE Subtype 419 The format of the Peer Entries is shown below. The PEER_INDEX_TABLE 420 record contains Peer Count number of Peer Entries. 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 | Peer Type | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Peer BGP ID | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Peer IP address (variable) | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Peer AS (variable) | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 Figure 6: Peer Entries 436 The Peer Type, Peer BGP ID, Peer IP, and Peer AS fields are repeated 437 as indicated by the Peer Count field. The position of the Peer in 438 the PEER_INDEX_TABLE is used as an index in the subsequent 439 TABLE_DUMP_V2 MRT records. The index number begins with 0. 441 The Peer Type field is a bit field which encodes the type of the AS 442 and IP address as identified by the A and I bits, respectively, 443 below. 445 0 1 2 3 4 5 6 7 446 +-+-+-+-+-+-+-+-+ 447 | | | | | | |A|I| 448 +-+-+-+-+-+-+-+-+ 450 Bit 6: Peer AS number size: 0 = 16 bits, 1 = 32 bits 451 Bit 7: Peer IP Address family: 0 = IPv4, 1 = IPv6 453 Figure 7: Peer Type Field 455 The MRT records which follow the PEER_INDEX_TABLE MRT record consist 456 of the subtypes listed below and contain the actual RIB table 457 entries. They include a header which specifies a sequence number, a 458 NLRI field, and a count of the number of RIB entries contained within 459 the record. 461 4.3.2. AFI/SAFI specific RIB Subtypes 463 The AFI/SAFI specific RIB Subtypes consist of the RIB_IPV4_UNICAST, 464 RIB_IPV4_MULTICAST, RIB_IPV6_UNICAST, and RIB_IPV6_MULTICAST 465 Subtypes. These specific RIB table entries are given their own MRT 466 TABLE_DUMP_V2 subtypes as they are the most common type of RIB table 467 instances and providing specific MRT subtypes for them permits more 468 compact encodings. These subtypes permit a single MRT record to 469 encode multiple RIB table entries for a single prefix. The Prefix 470 Length and Prefix fields are encoded in the same manner as the BGP 471 NLRI encoding for IPV4 and IPV6 prefixes. Namely, the Prefix field 472 contains address prefixes followed by enough trailing bits to make 473 the end of the field fall on an octet boundary. The value of 474 trailing bits is irrelevant. 476 0 1 2 3 477 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 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Sequence number | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Prefix Length | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Prefix (variable) | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Entry Count | RIB Entries (variable) 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 Figure 8: RIB Entry Header 490 4.3.3. RIB_GENERIC Subtype 492 The RIB_GENERIC header is shown below. It is used to cover RIB 493 entries which do not fall under the common case entries defined 494 above. It consists of an AFI, Subsequent AFI (SAFI) and a single 495 NLRI entry. The NLRI information is specific to the AFI and SAFI 496 values. An implementation which does not recognize particular AFI 497 and SAFI values SHOULD discard the remainder of the MRT record. 499 0 1 2 3 500 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 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Sequence number | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Address Family Identifier |Subsequent AFI | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Network Layer Reachability Information (variable) | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Entry Count | RIB Entries (variable) 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 Figure 9: RIB_GENERIC Entry Header 513 4.3.4. RIB Entries 515 The RIB Entries are repeated Entry Count times. These entries share 516 a common format as shown below. They include a Peer Index from the 517 PEER_INDEX_TABLE MRT record, an originated time for the RIB Entry, 518 and the BGP path attribute length and attributes. All AS numbers in 519 the AS_PATH attribute MUST be encoded as 4-Byte AS numbers. 521 0 1 2 3 522 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 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | Peer Index | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Originated Time | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Attribute Length | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | BGP Attributes... (variable) 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 Figure 10: RIB Entries 535 There is one exception to the encoding of BGP attributes for the BGP 536 MP_REACH_NLRI attribute (BGP Type Code 14) RFC 4760 [RFC4760]. Since 537 the AFI, SAFI, and NLRI information is already encoded in the 538 MULTIPROTOCOL header, only the Next Hop Address Length and Next Hop 539 Address fields are included. The Reserved field is omitted. The 540 attribute length is also adjusted to reflect only the length of the 541 Next Hop Address Length and Next Hop Address fields. 543 4.4. BGP4MP Type 545 This Type was initially defined in the Zebra software package for the 546 BGP protocol with multiprotocol extension support as defined by RFC 547 4760 [RFC4760]. The BGP4MP Type has six Subtypes which are defined 548 as follows: 550 0 BGP4MP_STATE_CHANGE 551 1 BGP4MP_MESSAGE 552 4 BGP4MP_MESSAGE_AS4 553 5 BGP4MP_STATE_CHANGE_AS4 554 6 BGP4MP_MESSAGE_LOCAL 555 7 BGP4MP_MESSAGE_AS4_LOCAL 557 4.4.1. BGP4MP_STATE_CHANGE Subtype 559 This message is used to encode state changes in the BGP finite state 560 machine. The BGP Finite State Machine (FSM) states are encoded in 561 the Old State and New State fields to indicate the previous and 562 current state. In some cases, the Peer AS number may be undefined. 563 In such cases, the value of this field MAY be set to zero. The 564 format is illustrated below: 566 0 1 2 3 567 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 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Peer AS number | Local AS number | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Interface Index | Address Family | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Peer IP address (variable) | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Local IP address (variable) | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | Old State | New State | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 Figure 11: BGP4MP_STATE_CHANGE Subtype 582 The FSM states are defined in RFC 4271 [RFC4271], Section 8.2.2. 583 Both the old state value and the new state value are encoded as 584 2-octet numbers. The state values are defined numerically as 585 follows: 587 1 Idle 588 2 Connect 589 3 Active 590 4 OpenSent 591 5 OpenConfirm 592 6 Established 594 The BGP4MP_STATE_CHANGE message also includes interface index and 595 Address Family fields. The interface index provides the interface 596 number of the peering session. The index value is OPTIONAL and MAY 597 be zero if unknown or unsupported. The Address Family indicates what 598 types of addresses are in the the address fields. At present, the 599 following AFI Types are supported: 601 1 AFI_IPv4 602 2 AFI_IPv6 604 4.4.2. BGP4MP_MESSAGE Subtype 606 This Subtype is used to encode BGP messages. It can be used to 607 encode any Type of BGP message. The entire BGP message is 608 encapsulated in the BGP Message field, including the 16-octet marker, 609 the 2-octet length, and the 1-octet type fields. The BGP4MP_MESSAGE 610 Subtype does not support 4-Byte AS numbers. The AS_PATH contained in 611 these messages MUST only consist of 2-Byte AS numbers. The 612 BGP4MP_MESSAGE_AS4 Subtype updates the BGP4MP_MESSAGE Subtype in 613 order to support 4-Byte AS numbers. The BGP4MP_MESSAGE fields are 614 shown below: 616 0 1 2 3 617 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 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Peer AS number | Local AS number | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Interface Index | Address Family | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Peer IP address (variable) | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | Local IP address (variable) | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | BGP Message... (variable) 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 Figure 12: BGP4MP_MESSAGE Subtype 631 The interface index provides the interface number of the peering 632 session. The index value is OPTIONAL and MAY be zero if unknown or 633 unsupported. The Address Family indicates what types of addresses 634 are in the the subsequent address fields. At present, the following 635 AFI Types are supported: 637 1 AFI_IPv4 638 2 AFI_IPv6 640 The Address Family value only applies to the IP addresses contained 641 in the MRT header. The BGP4MP_MESSAGE Subtype is otherwise 642 transparent to the contents of the actual message which may contain 643 any valid AFI/SAFI values. Only one BGP message SHALL be encoded in 644 the BGP4MP_MESSAGE Subtype. 646 4.4.3. BGP4MP_MESSAGE_AS4 Subtype 648 This Subtype updates the BGP4MP_MESSAGE Subtype to support 4-Byte AS 649 numbers. The BGP4MP_MESSAGE_AS4 Subtype is otherwise identical to 650 the BGP4MP_MESSAGE Subtype. The AS_PATH in these messages MUST only 651 consist of 4-Byte AS numbers. The BGP4MP_MESSAGE_AS4 fields are 652 shown below: 654 0 1 2 3 655 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 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Peer AS number | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | Local AS number | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | Interface Index | Address Family | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Peer IP address (variable) | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Local IP address (variable) | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | BGP Message... (variable) 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 Figure 13: BGP4MP_MESSAGE_AS4 Subtype 672 4.4.4. BGP4MP_STATE_CHANGE_AS4 Subtype 674 This Subtype updates the BGP4MP_STATE_CHANGE Subtype to support 675 4-Byte AS numbers. As with the BGP4MP_STATE_CHANGE Subtype, the BGP 676 FSM states are encoded in the Old State and New State fields to 677 indicate the previous and current state. Aside from the extension of 678 the peer and local AS fields to 4-Bytes, this subtype is otherwise 679 identical to the BGP4MP_STATE_CHANGE Subtype. The 680 BGP4MP_STATE_CHANGE_AS4 fields are shown below: 682 0 1 2 3 683 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 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Peer AS number | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | Local AS number | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | Interface Index | Address Family | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | Peer IP address (variable) | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Local IP address (variable) | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | Old State | New State | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 Figure 14: BGP4MP_STATE_CHANGE_AS4 Subtype 700 4.4.5. BGP4MP_MESSAGE_LOCAL Subtype 702 Implementations of MRT have largely focused on collecting remotely 703 generated BGP messages in a passive route collector role. However, 704 for active BGP implementations, it can be useful to archive locally 705 generated BGP messages in addition to remote messages. This subtype 706 is added to indicated a locally generated BGP message. The fields 707 remain identical to the BGP4MP_MESSAGE type including the Peer and 708 Local IP and AS fields. The Local fields continue to refer to the 709 local IP and AS number of the collector which generated the BGP 710 message and the Peer IP and AS fields refer to the recipient of the 711 generated BGP messages. 713 4.4.6. BGP4MP_MESSAGE_AS4_LOCAL Subtype 715 As with the BGP4MP_MESSAGE_LOCAL type, this type indicate locally 716 generated messages. The fields are identical to the 717 BGP4MP_MESSAGE_AS4 message type. 719 4.5. ISIS Type 721 This Type supports the IS-IS routing protocol as defined in RFC 1195 722 [RFC1195]. There is no Type specific header for the ISIS Type. The 723 Subtype code for this Type is undefined. The ISIS PDU directly 724 follows the MRT Common Header fields. 726 4.6. OSPFv3 Type 728 The OSPFv3 Type extends the original OSPFv2 Type to support IPv6 729 addresses for the OSPFv3 protocol as defined in RFC 5340 [RFC5340]. 730 The format of the MRT Message field for the OSPFv3 Type is as 731 follows: 733 0 1 2 3 734 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 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | Address Family | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Remote IP address (variable) | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Local IP address (variable) | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | OSPF Message Contents (variable) 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 Figure 15: OSPFv3 Type 747 5. IANA Considerations 749 This section provides guidance to the Internet Assigned Numbers 750 Authority (IANA) regarding registration of values related to the MRT 751 specification, in accordance with BCP 26, RFC 5226 [RFC5226]. 753 There are two name spaces in MRT that require registration: Type 754 Codes and Subtype Codes. Type Codes and Subtype Codes are each 16 755 bits in length. 757 MRT is not intended as a general-purpose specification for protocol 758 information export, and allocations should not be made for purposes 759 unrelated to routing protocol information export. 761 The following policies are used here with the meanings defined in BCP 762 26: "Specification Required", "IETF Consensus", "Experimental Use", 763 "First Come First Served". Assignments consist of a name and the 764 value. 766 5.1. Type Codes 768 Type Codes have a range from 0 to 65535, of which 0-64 are reserved. 769 New Type Codes MUST be allocated starting at 65. Type Codes 65 - 511 770 are to be assigned by IETF Review. Type Codes 512 - 2047 are 771 assigned based on Specification Required. Type Codes 2048 - 64511 772 are available on a First Come First Served policy. Type Codes 64512 773 - 65534 are available for Experimental Use. The Type Code Value 65535 774 is reserved. 776 5.2. Subtype Codes 778 Subtype Codes have a range from 0 to 65535. Subtype definitions are 779 specific to a particular Type Code definition. New Subtype Code 780 definitions must reference an existing Type Code to which the Subtype 781 belongs. Subtype assignments follow the assignment rules for the 782 Type Codes to which they belong. 784 5.3. Defined Type Codes 786 This document defines the following message Type Codes: 788 Name Value Definition 789 ---- ----- ---------- 790 NULL 0 See Section B.1.1 791 START 1 See Section B.1.2 792 DIE 2 See Section B.1.3 793 I_AM_DEAD 3 See Section B.1.4 794 PEER_DOWN 4 See Section B.1.5 795 BGP 5 See Section B.2.1 796 RIP 6 See Section B.2.2 797 IDRP 7 See Section B.2.3 798 RIPNG 8 See Section B.2.4 799 BGP4PLUS 9 See Section B.2.5 800 BGP4PLUS_01 10 See Section B.2.5 801 OSPFv2 11 See Section 4.1 802 TABLE_DUMP 12 See Section 4.2 803 TABLE_DUMP_v2 13 See Section 4.3 804 BGP4MP 16 See Section 4.4 805 BGP4MP_ET 17 See Section 4.4 806 ISIS 32 See Section 4.5 807 ISIS_ET 33 See Section 4.5 808 OSPFv3 48 See Section 4.6 809 OSPFv3_ET 49 See Section 4.6 811 5.4. Defined BGP, BGP4PLUS, and BGP4PLUS_01 Subtype Codes 813 This document defines the following message Subtype Codes for the 814 BGP, BGP4PLUS, and BGP4PLUS_01 Types: 816 Name Value Definition 817 ---- ----- ---------- 818 BGP_NULL 0 See Section B.2.1 819 BGP_UPDATE 1 See Section B.2.1 820 BGP_PREF_UPDATE 2 See Section B.2.1 821 BGP_STATE_CHANGE 3 See Section B.2.1 822 BGP_SYNC 4 See Section B.2.1 823 BGP_OPEN 5 See Section B.2.1 824 BGP_NOTIFY 6 See Section B.2.1 825 BGP_KEEPALIVE 7 See Section B.2.1 827 5.5. Defined TABLE_DUMP Subtype Codes 829 This document defines the following message Subtype Codes for the 830 TABLE_DUMP Type: 832 Name Value Definition 833 ---- ----- ---------- 834 AFI_IPv4 1 See Section 4.2 835 AFI_IPv6 2 See Section 4.2 837 5.6. Defined TABLE_DUMP_V2 Subtype Codes 839 This document defines the following message Subtype Codes for the 840 TABLE_DUMP_V2 Type: 842 Name Value Definition 843 ---- ----- ---------- 844 PEER_INDEX_TABLE 1 See Section 4.3 845 RIB_IPV4_UNICAST 2 See Section 4.3 846 RIB_IPV4_MULTICAST 3 See Section 4.3 847 RIB_IPV6_UNICAST 4 See Section 4.3 848 RIB_IPV6_MULTICAST 5 See Section 4.3 849 RIB_GENERIC 6 See Section 4.3 851 5.7. Defined BGP4MP and BGP4MP_ET Subtype Codes 853 This document defines the following message Subtype Codes for the 854 BGP4MP Type: 856 Name Value Definition 857 ---- ----- ---------- 858 BGP4MP_STATE_CHANGE 0 See Section 4.4 859 BGP4MP_MESSAGE 1 See Section 4.4 860 BGP4MP_ENTRY 2 See Section 4.4 861 BGP4MP_SNAPSHOT 3 See Section 4.4 862 BGP4MP_MESSAGE_AS4 4 See Section 4.4 863 BGP4MP_STATE_CHANGE_AS4 5 See Section 4.4 864 BGP4MP_MESSAGE_LOCAL 6 See Section 4.4 865 BGP4MP_MESSAGE_AS4_LOCAL 7 See Section 4.4 867 6. Security Considerations 869 The MRT Format utilizes a structure which can store routing protocol 870 information data. The fields defined in the MRT specification are of 871 a descriptive nature and provide information that is useful to 872 facilitate the analysis of routing data. As such, the fields 873 currently defined in the MRT specification do not in themselves 874 create additional security risks, since the fields are not used to 875 induce any particular behavior by the recipient application. 877 Some information contained in an MRT data structure might be 878 considered sensitive or private. For example, a BGP peer that sends 879 a message to an MRT-enabled router might not expect that message to 880 be shared beyond the AS to which it is sent. 882 Information that could be considered sensitive include BGP peer IP 883 addresses, BGP Next Hop IP addresses, and BGP Path Attributes. Such 884 information could be useful to mount attacks against the BGP protocol 885 and routing infrastructure. RFC 4272 [RFC4272] examines a number of 886 weaknesses in the BGP protocol which could potentially be exploited. 888 An organization that intends to use the MRT structure to export 889 routing information beyond the domain where it normally accessible 890 (e.g., publishing MRT dumps for use by researchers) should verify 891 with any peers whose information might be included, and possibly 892 remove sensitive fields. 894 The proposed geolocation extension to MRT could reveal the location 895 of an MRT router's peers [I- D.ietf-grow-geomrt]. 897 7. References 899 7.1. Normative References 901 [IANA-AF] "Address Family Numbers", 902 . 904 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 905 September 1981. 907 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 908 dual environments", RFC 1195, December 1990. 910 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 911 Requirement Levels", BCP 14, RFC 2119, March 1997. 913 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 915 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 916 (IPv6) Specification", RFC 2460, December 1998. 918 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 919 10646", STD 63, RFC 3629, November 2003. 921 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 922 Protocol 4 (BGP-4)", RFC 4271, January 2006. 924 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 925 "Multiprotocol Extensions for BGP-4", RFC 4760, 926 January 2007. 928 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 929 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 930 May 2008. 932 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 933 for IPv6", RFC 5340, July 2008. 935 7.2. Informative References 937 [IEEE.P1003.1-1990] 938 Institute of Electrical and Electronics Engineers, 939 "P1003.1, Information Technology Portable Operating System 940 Interface (POSIX) Part 1: System Application Program 941 Interface (API) [C Language], 1990.", IEEE Standard 942 P1003.1. 944 [MRT PROG GUIDE] 945 Labovitz, C., "MRT Programmer's Guide", November 1999, 946 . 948 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 949 January 1997. 951 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, 952 November 1998. 954 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 955 RFC 4272, January 2006. 957 Appendix A. MRT Encoding Examples 959 This appendix, which is not a normative reference, contains MRT 960 encoding examples. 962 The following example shows the encoding for a MRT record type of 963 BGP4MP and subtype BGP4MP_MESSAGE_AS4. The Peer AS and Local AS 964 numbers are encoded in 4 bytes fields due to the use of the 965 BGP4MP_MESSAGE_AS4 subtype. The encoded BGP Update is shown in 966 hexadecimal. The AS numbers in the ASPATH in the BGP Update are 967 encoded as 4 byte values in accord with the MRT BGP4MP_MESSAGE_AS4 968 subtype. 970 0 1 2 3 971 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 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | Timestamp = 1300475700 epoch sec (2011-03-18 19:15:00) | 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 | Type = 16 | Subtype = 4 | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | Length = 82 | 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | Peer AS = 64496 | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | Local AS = 64497 | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | Interface Index = 0 | Address Family = 1 | 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 | Peer IP address = 192.0.2.85 | 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 | Local IP address = 198.51.100.4 | 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | BGP Update = 991 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 992 00 3e 02 00 00 00 1f 40 01 01 02 40 02 0e 02 03 993 00 00 fb f0 00 00 fb ff 00 00 fb f6 40 03 04 c6 994 33 64 55 c0 08 04 fb f0 00 0e 18 cb 00 71 996 Figure 16: MRT BGP4MP_MESSAGE_AS4 Example 998 The contents of the BGP Update Message above are as follows: 1000 ORIGIN: INCOMPLETE 1001 ASPATH: 64496 64511 64502 1002 NEXT_HOP: 198.51.100.188 1003 COMMUNITY: 64496:14 1004 NLRI: 203.0.113.0/24 1006 Figure 17: BGP Message Contents 1008 The following example displays the encoding for a MRT record type of 1009 TABLE_DUMP_V2 and subtype PEER_INDEX_TABLE. The table in this 1010 example contains 2 entries. 1012 0 1 2 3 1013 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 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | Timestamp = 1300475700 epoch sec (2011-03-18 19:15:00) | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | Type = 13 | Subtype = 1 | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | Length = 34 | 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 | Collector BGP ID = 198.51.100.4 | 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 | View Name Length = 0 | Peer Count = 2 | 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 | Peer Type = 2 | 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 | Peer BGP ID = 198.51.100.5 | 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 | Peer IP address = 198.51.100.5 | 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 | Peer AS = 65541 | 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 | Peer Type = 2 | 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 | Peer BGP ID = 192.0.2.33 | 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 | Peer IP address = 192.0.2.33 | 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 | Peer AS = 65542 | 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 Figure 18: MRT PEER_INDEX_TABLE Example 1044 The following example displays the encoding for a MRT record type of 1045 TABLE_DUMP_V2 and subtype RIB_IPV6_UNICAST. This entry applies to 1046 the NLRI prefix of 2001:0DB8::/32. There is a single entry for this 1047 prefix. The entry applies to the peer identified by index location 1048 15 in a preceding MRT PEER_INDEX_TABLE record. 1050 0 1 2 3 1051 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 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | Timestamp = 1300475700 epoch sec (2011-03-18 19:15:00) | 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | Type = 13 | Subtype = 4 | 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 | Length = 87 | 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 | Sequence number = 42 | 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 | Preflen = 32 | 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 | Prefix = 2001:0DB8::/32 | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | Entry Count = 1 | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 | Peer Index = 15 | 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 |Originated Time = 1300475700 epoch sec (2011-03-18 19:15:00) | 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 | Attribute Length = 68 | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | BGP Path Attributes = 1075 40 01 01 00 50 02 00 0e 02 03 00 00 fb f0 00 00 1076 fb ff 00 00 fb f6 80 0e 2b 00 02 01 20 20 01 0d 1077 b8 00 0d 00 ff 00 00 00 00 00 00 01 87 fe 80 00 1078 00 00 00 00 00 02 12 f2 ff fe 9f 1b 00 00 00 20 1079 20 01 0d b8 1081 Figure 19: MRT RIB_IPV6_UNICAST Example 1083 The contents of the BGP Path Attribute field above are as follows: 1085 ORIGIN: IGP 1086 ASPATH: 64496 64511 64502 1087 MP_REACH_NLRI(IPv6 Unicast) 1088 NEXT_HOP: 2001:db8:d:ff::187 1089 NEXT_HOP: fe80::212:f2ff:fe9f:1b00 1090 NLRI: 2001:0DB8::/32 1092 Figure 20: BGP Path Attribute contents 1094 Appendix B. Deprecated MRT Types 1096 This Appendix lists deprecated MRT types. These types are documented 1097 for informational purposes. 1099 B.1. Deprecated MRT Informational Types 1101 The initial MRT format defined five Informational Type records. 1102 These records were intended to signal the state of an MRT data 1103 collector and do not contain routing information. These records were 1104 intended for use when MRT records were sent over a network to a 1105 remote repository store. However, MRT record repository stores have 1106 traditionally resided on the same device as the collector and these 1107 Informational Types are not known to be implemented. Further, 1108 transport mechanisms for MRT records are considered to be outside the 1109 scope of this document. 1111 The message field MAY contain an OPTIONAL string for diagnostic 1112 purposes. The message string encoding MUST follow the UTF-8 1113 transformation format [RFC3629]. The Subtype field is unused for 1114 these Types and SHOULD be set to 0. 1116 The MRT Informational Types are defined below: 1118 0 NULL 1119 1 START 1120 2 DIE 1121 3 I_AM_DEAD 1122 4 PEER_DOWN 1124 B.1.1. NULL Type 1126 The NULL Type message causes no operation. 1128 B.1.2. START Type 1130 The START Type indicates a collector is about to begin generating MRT 1131 records. 1133 B.1.3. DIE Type 1135 The DIE Type signals a remote MRT repository it SHOULD stop accepting 1136 messages. 1138 B.1.4. I_AM_DEAD Type 1140 An I_AM_DEAD MRT record indicates that a collector has shut down and 1141 has stopped generating MRT records. 1143 B.1.5. PEER_DOWN Type 1145 The PEER_DOWN message was intended to indicate that a collector had 1146 lost association with a BGP peer. However, the MRT format provides 1147 BGP state change message types which duplicate this functionality. 1149 B.2. Other Deprecated MRT Types 1151 5 BGP 1152 6 RIP 1153 7 IDRP 1154 8 RIPNG 1155 9 BGP4PLUS 1156 10 BGP4PLUS_01 1158 B.2.1. BGP Type 1160 The BGP Type indicates the Message field contains BGP routing 1161 information. The BGP routing protocol is defined in RFC 4271 1162 [RFC4271]. The information in the message is dependent on the 1163 Subtype value. The BGP Type and all associated Subtypes below are 1164 considered to be deprecated by the BGP4MP Type. 1166 The following BGP Subtypes are defined for the MRT BGP Type. As with 1167 the BGP Type itself, they are all considered to be deprecated. 1169 0 BGP_NULL 1170 1 BGP_UPDATE 1171 2 BGP_PREF_UPDATE 1172 3 BGP_STATE_CHANGE 1173 4 BGP_SYNC 1174 5 BGP_OPEN 1175 6 BGP_NOTIFY 1176 7 BGP_KEEPALIVE 1178 B.2.1.1. BGP_NULL Subtype 1180 The BGP_NULL Subtype is a reserved Subtype. 1182 B.2.1.2. BGP_UPDATE Subtype 1184 The BGP_UPDATE Subtype is used to encode BGP UPDATE messages. The 1185 format of the MRT Message field for this Subtype is as follows: 1187 0 1 2 3 1188 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 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 | Peer AS number | 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 | Peer IP address | 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 | Local AS number | 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 | Local IP address | 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 | BGP UPDATE Contents (variable) 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1201 Figure 21: BGP_UPDATE Subtype 1203 The BGP UPDATE Contents include the entire BGP UPDATE message which 1204 follows the BGP Message Header. The BGP Message Header itself is not 1205 included. The Peer AS number and IP address fields contain the AS 1206 number and IP address of the remote system which are generating the 1207 BGP UPDATE messages. The Local AS number and IP address fields 1208 contain the AS number and IP address of the local collector system 1209 which is archiving the messages. 1211 B.2.1.3. BGP_PREF_UPDATE Subtype 1213 The BGP_PREF_UPDATE Subtype is not defined. 1215 B.2.1.4. BGP_STATE_CHANGE Subtype 1217 The BGP_STATE_CHANGE Subtype is used to reflect changes in the BGP 1218 finite state machine. These FSM states are defined in RFC 4271 1219 [RFC4271], Section 8.2.2. Both the old state value and the new state 1220 value are encoded as 2-octet numbers. The state values are defined 1221 numerically as follows: 1223 1 Idle 1224 2 Connect 1225 3 Active 1226 4 OpenSent 1227 5 OpenConfirm 1228 6 Established 1230 The format of the BGP_STATE_CHANGE Subtype MRT Message field is as 1231 follows: 1233 0 1 2 3 1234 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 1235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1236 | Peer AS number | 1237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1238 | Peer IP address | 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 | Old State | New State | 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1243 Figure 22: BGP_STATE_CHANGE Subtype 1245 B.2.1.5. BGP_SYNC Subtype 1247 The BGP_SYNC Subtype was intended to convey a system file name where 1248 BGP Table Dump messages MAY be recorded. The View # was to 1249 correspond to the View # provided in the TABLE_DUMP Type records. 1250 There are no known implementations of this subtype and it SHOULD be 1251 ignored. The following format applies to this Subtype: 1253 0 1 2 3 1254 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 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 | View # | 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 | File Name... (variable) 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 Figure 23: BGP_SYNC Subtype 1263 The File Name is terminated with a NULL (0) character. 1265 B.2.1.6. BGP_OPEN Subtype 1267 The BGP_OPEN Subtype is used to encode BGP OPEN messages. The format 1268 of the MRT Message field for this Subtype is the same as the 1269 BGP_UPDATE, however, the last field contains the contents of the BGP 1270 OPEN message. 1272 B.2.1.7. BGP_NOTIFY Subtype 1274 The BGP_NOTIFY Subtype is used to encode BGP NOTIFICATION messages. 1275 The format of the MRT Message field for this Subtype is the same as 1276 the BGP_UPDATE, however, the last field contains the contents of the 1277 BGP NOTIFICATION message. 1279 B.2.1.8. BGP_KEEPALIVE Subtype 1281 The BGP_KEEPALIVE Subtype is used to encode BGP KEEPALIVE messages. 1282 The format of the MRT Message field for this Subtype is the same as 1283 the BGP_UPDATE, however, the last field contains no information. 1285 B.2.2. RIP Type 1287 The RIP Type is used to export RIP protocol packets as defined in RFC 1288 2453 [RFC2453]. The Subtype field is currently reserved for this 1289 Type and SHOULD be set to 0. 1291 The format of the MRT Message field for the RIP Type is as follows: 1293 0 1 2 3 1294 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 1295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1296 | Peer IP address | 1297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1298 | Local IP address | 1299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1300 | RIP Message Contents (variable) 1301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1303 Figure 24: RIP Type 1305 B.2.3. IDRP Type 1307 The IDRP Type was intended to be used to export Inter-Domain-Routing 1308 Protocol (IDRP) protocol information as defined in the ISO/IEC 10747 1309 standard. However, this Type has seen no known use and there are no 1310 details on protocol encoding for this Type. 1312 B.2.4. RIPNG Type 1314 The RIPNG Type is used to export RIPNG protocol packets as defined in 1315 RFC 2080 [RFC2080]. The RIPNG protocol updates the RIP protocol to 1316 support IPv6. The Subtype field is currently reserved for this Type 1317 and SHOULD be set to 0. 1319 The format of the MRT Message field for the RIPNG Type is as follows: 1321 0 1 2 3 1322 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 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 | | 1325 ~ Peer IPv6 address ~ 1326 | | 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1328 | | 1329 ~ Local IPv6 address ~ 1330 | | 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1332 | RIPNG Message Contents (variable) 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 Figure 25: RIPNG Type 1337 B.2.5. BGP4PLUS and BGP4PLUS_01 Types 1339 The BGP4PLUS and BGP4PLUS_01 Types were defined to support IPv6 BGP 1340 routing information. The BGP4PLUS Type was specified based on the 1341 initial Internet Draft for Multiprotocol Extensions to BGP-4. The 1342 BGP4PLUS_01 Type was specified to correspond to the -01 revision of 1343 this Internet Draft. The two Types share the same definitions in 1344 terms of their MRT format specifications. 1346 The Subtype field definitions are shared with the BGP Type, however, 1347 the address fields in the BGP_UPDATE, BGP_OPEN, BGP_NOTIFY, 1348 BGP_KEEPALIVE, and BGP_STATE_CHANGE Subtype records are extended to 1349 16 octets for IPv6 addresses. As with the BGP Type, the BGP4PLUS and 1350 BGP4PLUS_01 Types are deprecated as they superseded by the BGP4MP 1351 Type. 1353 B.2.6. Deprecated BGP4MP Subtypes 1355 The following two subtypes of the BGP4MP Type are considered to be 1356 deprecated. 1358 2 BGP4MP_ENTRY 1359 3 BGP4MP_SNAPSHOT 1361 B.2.6.1. BGP4MP_ENTRY Subtype 1363 This Subtype is similar to the TABLE_DUMP Type and is used to record 1364 RIB table entries. It was intended to include true multiprotocol 1365 support. However, this Subtype does not support 4-Byte AS numbers 1366 and has not been widely implemented. 1368 0 1 2 3 1369 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 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1371 | Peer AS number | Local AS number | 1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 | Interface Index | Address Family | 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 | Peer IP address (variable) | 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 | Local IP address (variable) | 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 | View # | Status | 1380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1381 | Time last change | 1382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1383 | Address Family | SAFI | Next-Hop-Len | 1384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1385 | Next Hop Address (variable) | 1386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1387 | Prefix Length | 1388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1389 | Address Prefix (variable) | 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1391 | Attribute Length | 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1393 | BGP Attribute... (variable) 1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1396 Figure 26: BGP4MP_ENTRY Subtype 1398 B.2.6.2. BGP4MP_SNAPSHOT Subtype 1400 This Subtype was intended to convey a system file name where 1401 BGP4MP_ENTRY records MAY be recorded. It is similar to the BGP_SYNC 1402 Subtype and is deprecated. 1404 0 1 2 3 1405 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 1406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1407 | View # | 1408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 | File Name... (variable) 1410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 Figure 27: BGP4MP_SNAPSHOT Subtype 1414 Appendix C. Acknowledgements 1416 The initial MRT specification was developed by Craig Labovitz for use 1417 in the Multi-thread Routing Toolkit (MRT) project. The BGP4MP Type 1418 was introduced in the Zebra routing software project by Kunihiro 1419 Ishiguro. The BGP4MP_ET, ISIS, and ISIS_ET Types were defined in the 1420 Python Routeing Toolkit (PyRT) developed by Richard Mortier while at 1421 Sprint Advanced Technology Labs. 1423 Authors' Addresses 1425 Larry Blunk 1426 Merit Network 1428 Email: ljb@merit.edu 1430 Manish Karir 1431 Merit Network 1433 Email: mkarir@merit.edu 1435 Craig Labovitz 1436 Deepfield Networks 1438 Email: labovit@deepfield.net