Internet Engineering Task Force (IETF) L. Blunk
Request for Comments: 6396 M. Karir
Category: Standards Track Merit Network
ISSN: 2070-1721 C. Labovitz
Deepfield Networks
October 2011
Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format
マルチスレッド・ルーティングツールキット（MRT）ルーティング情報エクスポート形式
Abstract
抽象
This document describes the MRT format for routing information export. This format was developed in concert with the Multi-threaded Routing Toolkit (MRT) from whence the format takes it name. The format can be used to export routing protocol messages, state changes, and routing information base contents.
この文書は情報のエクスポートをルーティングするためのMRTフォーマットについて説明します。このフォーマットは、フォーマットそこからマルチスレッド・ルーティングツールキット（MRT）と協力して開発された、名前を取ります。フォーマットは、ルーティング・プロトコル・メッセージ、状態の変更をエクスポートするために使用され、情報ベースのコンテンツをルーティングすることができます。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6396.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6396で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . . 4
2. MRT Common Header . . . . . . . . . . . . . . . . . . . . . . 4
3. Extended Timestamp MRT Header . . . . . . . . . . . . . . . . 5
4. MRT Types . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. OSPFv2 Type . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 7
4.3. TABLE_DUMP_V2 Type . . . . . . . . . . . . . . . . . . . . 9
4.3.1. PEER_INDEX_TABLE Subtype . . . . . . . . . . . . . . . 9
4.3.2. AFI/SAFI-Specific RIB Subtypes . . . . . . . . . . . . 11
4.3.3. RIB_GENERIC Subtype . . . . . . . . . . . . . . . . . 11
4.3.4. RIB Entries . . . . . . . . . . . . . . . . . . . . . 12
4.4. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 13
4.4.1. BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 13
4.4.2. BGP4MP_MESSAGE Subtype . . . . . . . . . . . . . . . . 14
4.4.3. BGP4MP_MESSAGE_AS4 Subtype . . . . . . . . . . . . . . 15
4.4.4. BGP4MP_STATE_CHANGE_AS4 Subtype . . . . . . . . . . . 15
4.4.5. BGP4MP_MESSAGE_LOCAL Subtype . . . . . . . . . . . . . 16
4.4.6. BGP4MP_MESSAGE_AS4_LOCAL Subtype . . . . . . . . . . . 16
4.5. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 16
4.6. OSPFv3 Type . . . . . . . . . . . . . . . . . . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
5.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2. Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 18
5.3. Defined Type Codes . . . . . . . . . . . . . . . . . . . . 18
5.4. Defined BGP, BGP4PLUS, and BGP4PLUS_01 Subtype Codes . . . 19
5.5. Defined TABLE_DUMP Subtype Codes . . . . . . . . . . . . . 19
5.6. Defined TABLE_DUMP_V2 Subtype Codes . . . . . . . . . . . 19
5.7. Defined BGP4MP and BGP4MP_ET Subtype Codes . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Normative References . . . . . . . . . . . . . . . . . . . 21
7.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. MRT Encoding Examples . . . . . . . . . . . . . . . . 23
Appendix B. Deprecated MRT Types . . . . . . . . . . . . . . . . 26
B.1. Deprecated MRT Informational Types . . . . . . . . . . . . 26
B.1.1. NULL Type . . . . . . . . . . . . . . . . . . . . . . 26
B.1.2. START Type . . . . . . . . . . . . . . . . . . . . . . 27
B.1.3. DIE Type . . . . . . . . . . . . . . . . . . . . . . . 27
B.1.4. I_AM_DEAD Type . . . . . . . . . . . . . . . . . . . . 27
B.1.5. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . 27
B.2. Other Deprecated MRT Types . . . . . . . . . . . . . . . . 27
B.2.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . 27
B.2.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . 30
B.2.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . 30
B.2.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . 31
B.2.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . 31
B.2.6. Deprecated BGP4MP Subtypes . . . . . . . . . . . . . . 32
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 34
Researchers and engineers often wish to analyze network behavior by studying routing protocol transactions and routing information base snapshots. To this end, the MRT record format was developed to encapsulate, export, and archive this information in a standardized data representation.
研究者やエンジニアは、多くの場合、ルーティングプロトコルの取引を研究し、情報ベースのスナップショットをルーティングすることにより、ネットワークの挙動を分析したいです。このため、MRTのレコード形式は、カプセル化し、輸出、および標準化されたデータ表現でこの情報をアーカイブするために開発されました。
The BGP routing protocol, in particular, has been the subject of extensive study and analysis, which have been significantly aided by the availability of the MRT format. Two examples of large-scale MRT-based BGP archival projects include the University of Oregon Route Views Project and the RIPE NCC Routing Information Service (RIS).
BGPルーティングプロトコルは、特に、著しくMRTフォーマットの可用性によって支援されている大規模な研究と分析の対象となっています。大規模MRTベースのBGPアーカイブプロジェクトの2つの例は、オレゴンルートの大学は、プロジェクトとRIPE NCCルーティング情報サービス（RIS）をビュー含まれています。
The MRT format was initially defined in the MRT Programmer's Guide [MRT_PROG_GUIDE]. Subsequent extensions were made in the GNU Zebra software routing suite and the Sprint Advanced Technology Labs Python Routing Toolkit (PyRT). Further extensions may be introduced at a later date through additional definitions of the MRT Type field and Subtype fields.
MRTフォーマットは、最初MRTプログラマーズ・ガイド[MRT_PROG_GUIDE]で定義されました。その後の拡張は、GNU Zebraのソフトウェアルーティング・スイートとSprint先端技術研究所のPythonルーティングツールキット（PyRT）で行われました。また、拡張子が追加MRT Typeフィールドの定義とサブタイプのフィールドを後日導入することができます。
A number of MRT record types listed in the MRT Programmer's Guide [MRT_PROG_GUIDE] are not known to have been implemented and, in some cases, were incompletely specified. Further, several types were employed in early MRT implementations, but saw limited use and were updated by improved versions. These types are considered to be deprecated and are documented in the Deprecated MRT Types (Appendix B) section at the end of this document. The deprecated types consist of codes 0 through 10 inclusive. Some of the deprecated types may be of interest to researchers examining historical MRT format archives.
記載されているMRTレコードタイプの数MRTプログラマーズ・ガイド[MRT_PROG_GUIDE]実装されていることが知られていないと、いくつかのケースでは、不完全に指定されました。さらに、いくつかの種類は、初期のMRTの実装に用いられますが、限られた使用を見て、改善されたバージョンによって更新されたました。これらのタイプは廃止されると考えられていると、この文書の最後に廃止さMRTタイプ（付録B）のセクションに記載されています。非推奨のタイプはコード包括10を介して0から成ります。非推奨のタイプのいくつかは、歴史的MRT形式のアーカイブを調べる研究者を対象としています。
Fields which contain multi-octet numeric values are encoded in network octet order from most significant octet to least significant octet. Fields that contain routing message fields are encoded in the same order as they appear in the packet contents.
マルチオクテットの数値を含むフィールドは、最下位オクテットに最も重要なオクテットからネットワークオクテット順に符号化されます。ルーティングメッセージ・フィールドを含むフィールドは、それらがパケットの内容に現れるのと同じ順序で符号化されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
All MRT format records have a Common Header that consists of a Timestamp, Type, Subtype, and Length field. The header is followed by a Message field. The MRT Common Header is illustrated below.
すべてのMRTフォーマットのレコードはタイムスタンプ、タイプ、サブタイプ、およびLengthフィールドで構成されて共通ヘッダを持っています。ヘッダは、メッセージ・フィールドが続きます。 MRT共通ヘッダを以下に示します。
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: MRT Common Header
図1：MRT共通ヘッダ
Header Field Descriptions:
ヘッダーフィールドの説明：
Timestamp:
タイムスタンプ：
A 4-octet field whose integer value is the number of seconds, excluding leap seconds, elapsed since midnight proleptic Coordinated Universal Time (UTC). This representation of time is sometimes called "UNIX time" [POSIX]. This time format cannot represent time values prior to January 1, 1970. The latest UTC time value that can be represented by a 4-octet integer value is 03:14:07 on January 19, 2038, which is represented by the hexadecimal value 7FFFFFFF. Implementations that wish to create MRT records after this date will need to provide an alternate EPOCH time base for the Timestamp field. Mechanisms for indicating this alternate EPOCH are currently outside the scope of this document.
その整数値うるう秒を除いた秒数である4オクテットフィールドは、深夜proleptic協定世界時（UTC）から経過しました。時間のこの表現は、時々「UNIXタイム」[POSIX]と呼ばれています。この時間形式は、4オクテットの整数値で表現することができる最新のUTC時間値は16進値で表される、2038年1月19日に午前3時14分07秒である1月1日より前、1970年に時間値を表すことができない7FFFFFFF 。この日付以降MRTレコードを作成したいの実装は、タイムスタンプフィールドの代替EPOCHタイムベースを提供する必要があります。この代替EPOCHを示すための機構は、この文書の範囲外に現在あります。
Type:
タイプ：
A 2-octet field that indicates the Type of information contained in the Message field. Types 0 through 4 are informational messages pertaining to the state of an MRT collector, while Types 5 and higher are used to convey routing information.
メッセージフィールドに含まれる情報のタイプを示す2オクテットフィールド。タイプ5以上がルーティング情報を伝達するために使用される4スルータイプ0は、MRTコレクタの状態に関連する情報メッセージです。
Subtype:
サブタイプ：
A 2-octet field that is used to further distinguish message information within a particular record Type.
さらに、特定のレコード・タイプ内のメッセージの情報を区別するために使用される2オクテットフィールド。
Length:
長さ：
A 4-octet message length field. The Length field contains the number of octets within the message. The Length field does not include the length of the MRT Common Header.
4オクテットのメッセージ長フィールド。 Lengthフィールドは、メッセージ内のオクテット数が含まれています。 Lengthフィールドは、MRT共通ヘッダの長さが含まれていません。
Message:
メッセージ：
A variable-length message. The contents of this field are context dependent upon the Type and Subtype fields.
可変長メッセージ。このフィールドの内容は、タイプとサブタイプフィールドに依存してコンテキストです。
Several MRT format record types support a variant type with an extended timestamp field. The purpose of this field is to support measurements at sub-second resolutions. This field, Microsecond Timestamp, contains an unsigned 32BIT offset value in microseconds, which is added to the Timestamp field value. The Timestamp field remains as defined in the MRT Common Header. The Microsecond Timestamp immediately follows the Length field in the MRT Common Header and precedes all other fields in the message. The Microsecond Timestamp is included in the computation of the Length field value. The Extended Timestamp MRT Header is illustrated below.
いくつかのMRTフォーマットのレコードタイプは、拡張タイムスタンプフィールドでバリアント型をサポートしています。このフィールドの目的は、サブ秒の解像度で測定をサポートすることです。このフィールドは、マイクロ秒タイムスタンプは、タイムスタンプフィールドの値に加算されるマイクロ秒で符号なしの32BITオフセット値を含みます。 MRT共通ヘッダで定義されているタイムスタンプフィールドが残っています。マイクロ秒のタイムスタンプは、すぐにMRT共通ヘッダの長さフィールドの後に続き、メッセージ内の他のすべてのフィールドを先行します。マイクロ秒タイムスタンプは、長さフィールド値の計算に含まれます。拡張タイムスタンプMRTヘッダーを以下に示します。
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Microsecond Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Extended Timestamp MRT Header
図2：拡張タイムスタンプMRTヘッダー
The following MRT Types are currently defined for the MRT format. The MRT Types that contain the "_ET" suffix in their names identify those types that use an Extended Timestamp MRT Header. The Subtype and Message fields in these types remain as defined for the MRT Types of the same name without the "_ET" suffix.
次MRTの種類は、現在、MRTフォーマットのために定義されています。名前に「_ET」サフィックスが含まれているMRTの種類は、拡張タイムスタンプMRTヘッダーを使用し、それらの種類を識別します。 「_ET」サフィックスなしで同じ名前のMRTタイプのために定義されているこれらのタイプにおけるサブタイプとメッセージのフィールドが残っています。
11 OSPFv2
12 TABLE_DUMP
13 TABLE_DUMP_V2
16 BGP4MP
17 BGP4MP_ET
32 ISIS
33 ISIS_ET
48 OSPFv3
49 OSPFv3_ET
This type supports the OSPFv2 protocol as defined in RFC 2328 [RFC2328]. It is used to encode the exchange of OSPF protocol packets.
RFC 2328 [RFC2328]で定義されるように、このタイプのOSPFv2プロトコルをサポートします。 OSPFプロトコルパケットの交換を符号化するために使用されます。
The format of the MRT Message field for the OSPFv2 Type is as follows:
次のようにOSPFv2のタイプのためのMRTのメッセージフィールドの形式は次のとおりです。
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Message Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: OSPFv2 Type
図3：OSPFv2のタイプ
The Remote IP Address field contains the Source IPv4 [RFC0791] address from the IP header of the OSPF message. The Local IP Address contains the Destination IPv4 address from the IP header. The OSPF Message Contents field contains the complete contents of the OSPF packet following the IP header.
リモートIPアドレス]フィールドには、OSPFメッセージのIPヘッダから送信元IPv4 [RFC0791]のアドレスが含まれています。ローカルIPアドレスは、IPヘッダから宛先IPv4アドレスが含まれています。 OSPFメッセージの内容欄には、IPヘッダに続くOSPFパケットの完全な内容が含まれています。
The TABLE_DUMP Type is used to encode the contents of a BGP Routing Information Base (RIB). Each RIB entry is encoded in a distinct sequential MRT record. It is RECOMMENDED that new MRT encoding implementations use the TABLE_DUMP_V2 Type (see below) instead of the TABLE_DUMP Type due to limitations in this type. However, due to the significant volume of historical data encoded with this type, MRT decoding applications MAY wish to support this type.
TABLE_DUMPタイプBGPルーティング情報ベース（RIB）の内容を符号化するために使用されます。各リブエントリは、異なるシーケンシャルMRTレコードに符号化されます。新しいMRT符号化実装はTABLE_DUMP_V2タイプ（下記参照）の代わりに、このタイプの制限に起因TABLE_DUMPタイプを使用することをお勧めします。しかし、このタイプの符号化された履歴データの有意な量のために、MRT復号化アプリケーションは、このタイプをサポートすることを望むかもしれません。
The Subtype field is used to encode whether the RIB entry contains IPv4 or IPv6 [RFC2460] addresses. There are two possible values for the Subtype as shown below.
サブタイプフィールドはRIBエントリがIPv4またはIPv6 [RFC2460]アドレスを含むかどうかを符号化するために使用されます。以下に示すようにサブタイプのための2つの値があります。
1 AFI_IPv4
2 AFI_IPv6
The format of the TABLE_DUMP Type is illustrated below.
TABLE_DUMPタイプのフォーマットを以下に示します。
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| View Number | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originated Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP Address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS | Attribute Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Attribute... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: TABLE_DUMP Type
図4：TABLE_DUMPタイプ
The View Number field is normally 0 and is intended for cases where an implementation may have multiple RIB views (such as a route server). In cases where multiple RIB views are present, an implementation MAY use the View Number field to distinguish entries from each view. The Sequence Number field is a simple incremental counter for each RIB entry. A typical RIB dump will exceed the 16-bit bounds of this counter, and an implementation SHOULD simply wrap back to zero and continue incrementing the counter in such cases.
ビュー番号フィールドは、通常は0であり、実装は、（例えば、ルート・サーバのような）複数RIBビューを有していてもよい場合のために意図されています。複数のRIBビューが存在する場合には、実装は、各ビューからエントリを区別するためにビュー番号フィールドを使用するかもしれません。シーケンス番号フィールドは、各RIBエントリーのための単純な増分カウンタです。典型的なRIBダンプは、このカウンタの16ビット境界を超える、および実装は、単にゼロにラップし、このような場合に、カウンタをインクリメント続けるべきです。
The Prefix field contains the IP address of a particular RIB entry. The size of this field is dependent on the value of the Subtype for this record. The AFI_IPv4 Subtype value specifies an Address Family Identifier (AFI) type of IPv4 [IANA-AF]. It specifies a Prefix field length of 4 octets. For AFI_IPv6, it is 16 octets in length. The Prefix Length field indicates the length in bits of the prefix mask for the preceding Prefix field.
プレフィックス]フィールドには、特定のRIBエントリのIPアドレスが含まれています。このフィールドのサイズは、このレコードのサブタイプの値に依存しています。 AFI_IPv4サブタイプ値は、IPv4 [IANA-AF]のアドレスファミリ識別子（AFI）のタイプを指定します。それは4つのオクテットのプレフィックスフィールドの長さを指定します。 AFI_IPv6の場合は、長さが16オクテットです。プレフィックス長フィールドは、前のプレフィックスフィールドのプレフィックスマスクのビットの長さを示しています。
The Status octet is unused in the TABLE_DUMP Type and SHOULD be set to 1.
ステータスオクテットはTABLE_DUMPタイプでは使用されず、1に設定する必要があります。
The Originated Time contains the 4-octet time at which this prefix was heard. The value represents the time in seconds since 1 January 1970 00:00:00 UTC.
起源の時間は、このプレフィックスが聞かれたときの4オクテットの時間が含まれています。値は、1970年1月1日00:00:00からの秒数での時間を表しています。
The Peer IP Address field is the IP address of the peer that provided the update for this RIB entry. As with the Prefix field, the size of this field is dependent on the Subtype. AFI_IPv4 indicates a 4-octet field and an IPv4 address, while a Subtype of AFI_IPv6 requires a 16-octet field and an IPv6 address. The Peer AS field contains the 2-octet Autonomous System (AS) number of the peer.
ピアIPアドレスフィールドには、このRIBエントリのアップデートを提供し、ピアのIPアドレスです。プレフィックス]フィールドと同様に、このフィールドのサイズは、サブタイプに依存しています。 AFI_IPv6のサブタイプが16オクテットフィールド及びIPv6アドレスを必要とするAFI_IPv4は、4オクテットフィールドとIPv4アドレスを示しています。フィールドASピアは、ピアの2オクテット自律システム（AS）番号を含みます。
The TABLE_DUMP Type does not permit 4-byte Peer AS numbers, nor does it allow the AFI of the peer IP to differ from the AFI of the Prefix field. The TABLE_DUMP_V2 Type MUST be used in these situations.
TABLE_DUMPタイプはAS番号を4バイトのピアを許可しません。また、ピアIPのAFIは、PrefixフィールドのAFI異なるすることができません。 TABLE_DUMP_V2タイプは、このような状況で使用する必要があります。
Attribute Length contains the length of the Attribute field and is 2 octets. The BGP Attribute field contains the BGP attribute information for the RIB entry. The AS_PATH attribute MUST only consist of 2-byte AS numbers. The TABLE_DUMP_V2 supports 4-byte AS numbers in the AS_PATH attribute.
属性の長さは、属性フィールドの長さが含まれており、2つのオクテットです。 BGPは、フィールドは、BGPはRIBエントリの属性情報を含んでいる属性。 AS_PATH属性は数字のみAS 2バイトで構成されなければなりません。 TABLE_DUMP_V2は、AS_PATH属性にAS番号4バイトをサポートしています。
The TABLE_DUMP_V2 Type updates the TABLE_DUMP Type to include 4-byte Autonomous System Number (ASN) support and full support for BGP multiprotocol extensions. It also improves upon the space efficiency of the TABLE_DUMP Type by employing an index table for peers and permitting a single MRT record per Network Layer Reachability Information (NLRI) entry. The following subtypes are used with the TABLE_DUMP_V2 Type.
TABLE_DUMP_V2タイプは4バイト自律システム番号（ASN）をサポートし、BGPマルチプロトコル拡張のためのフルサポートを含むようにTABLE_DUMPタイプを更新します。また、ピアのインデックステーブルを採用し、ネットワーク層到達可能性情報（NLRI）のエントリごとに単一のMRTの記録を可能にすることにより、TABLE_DUMPタイプのスペース効率を改善します。次のサブタイプはTABLE_DUMP_V2タイプで使用されています。
1 PEER_INDEX_TABLE
2 RIB_IPV4_UNICAST
3 RIB_IPV4_MULTICAST
4 RIB_IPV6_UNICAST
5 RIB_IPV6_MULTICAST
6 RIB_GENERIC
An initial PEER_INDEX_TABLE MRT record provides the BGP ID of the collector, an OPTIONAL view name, and a list of indexed peers. Following the PEER_INDEX_TABLE MRT record, a series of MRT records is used to encode RIB table entries. This series of MRT records uses subtypes 2-6 and is separate from the PEER_INDEX_TABLE MRT record itself and includes full MRT record headers. The RIB entry MRT records MUST immediately follow the PEER_INDEX_TABLE MRT record.
初期PEER_INDEX_TABLE MRTレコードは、コレクタのBGPのID、OPTIONALビュー名、およびインデックス付きピアのリストを提供します。 PEER_INDEX_TABLE MRTレコードに続いて、MRTの一連のレコードは、RIBテーブルエントリをエンコードするために使用されます。 MRTレコードのこのシリーズは、サブタイプ2-6を使用し、PEER_INDEX_TABLE MRTレコード自体から独立しており、フルMRTレコードヘッダーが含まれています。 RIBエントリMRTレコードは、直ちにPEER_INDEX_TABLE MRTレコードに従わなければなりません。
The header of the PEER_INDEX_TABLE Subtype is shown below. The View Name is OPTIONAL and, if not present, the View Name Length MUST be set to 0. The View Name encoding MUST follow the UTF-8 transformation format [RFC3629].
PEER_INDEX_TABLEサブタイプのヘッダを以下に示します。ビュー名はオプションで、存在しない場合は、表示名の長さが表示名のエンコーディングがUTF-8変換形式[RFC3629]を従わなければならない0に設定しなければなりませんです。
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Collector BGP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| View Name Length | View Name (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Count | Peer Entries (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: PEER_INDEX_TABLE Subtype
図5：PEER_INDEX_TABLEサブタイプ
The format of the Peer Entries is shown below. The PEER_INDEX_TABLE record contains Peer Count number of Peer Entries.
ピアエントリのフォーマットは以下に示されています。 PEER_INDEX_TABLEレコードは、ピアエントリのピアカウント数が含まれています。
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer BGP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP Address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Peer Entries
図6：ピアエントリ
The Peer Type, Peer BGP ID, Peer IP Address, and Peer AS fields are repeated as indicated by the Peer Count field. The position of the peer in the PEER_INDEX_TABLE is used as an index in the subsequent TABLE_DUMP_V2 MRT records. The index number begins with 0.
ピアCountフィールドによって示されるようにフィールドASピアタイプ、ピアのBGP ID、ピアIPアドレス、およびピアが繰り返されます。 PEER_INDEX_TABLEにおけるピアの位置は、後続TABLE_DUMP_V2 MRTレコードのインデックスとして使用されます。インデックス番号は0から始まります。
The Peer Type field is a bit field that encodes the type of the AS and IP address as identified by the A and I bits, respectively, below.
ピアTypeフィールドは、それぞれ、以下、A及びIビットによって識別されるようにASとIPアドレスのタイプをエンコードするビットフィールドです。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| | | | | | |A|I|
+-+-+-+-+-+-+-+-+
Bit 6: Peer AS number size: 0 = 16 bits, 1 = 32 bits Bit 7: Peer IP Address family: 0 = IPv4, 1 = IPv6
番号サイズASピア：ビット6 0 = 16ビット、ビット7 1 = 32ビット：ピアIPアドレスファミリー：0 =のIPv4、IPv6の1 =
Figure 7: Peer Type Field
図7：ピアタイプフィールド
The MRT records that follow the PEER_INDEX_TABLE MRT record consist of the subtypes listed below and contain the actual RIB table entries. They include a header that specifies a sequence number, an NLRI field, and a count of the number of RIB entries contained within the record.
PEER_INDEX_TABLE MRTレコードをたどるMRTレコードは、下記のサブタイプで構成されており、実際のRIBテーブルのエントリが含まれています。これらは、シーケンス番号を指定するヘッダ、NLRIフィールド、およびレコード内に含まれるRIBエントリ数のカウントを含みます。
The AFI/SAFI-specific RIB Subtypes consist of the RIB_IPV4_UNICAST, RIB_IPV4_MULTICAST, RIB_IPV6_UNICAST, and RIB_IPV6_MULTICAST Subtypes. These specific RIB table entries are given their own MRT TABLE_DUMP_V2 subtypes as they are the most common type of RIB table instances, and providing specific MRT subtypes for them permits more compact encodings. These subtypes permit a single MRT record to encode multiple RIB table entries for a single prefix. The Prefix Length and Prefix fields are encoded in the same manner as the BGP NLRI encoding for IPv4 and IPv6 prefixes. Namely, the Prefix field contains address prefixes followed by enough trailing bits to make the end of the field fall on an octet boundary. The value of trailing bits is irrelevant.
AFI / SAFI固有RIBサブタイプはRIB_IPV4_UNICAST、RIB_IPV4_MULTICAST、RIB_IPV6_UNICAST、及びRIB_IPV6_MULTICASTサブタイプから成ります。これらの具体的なRIBテーブルエントリは、彼らがRIBテーブルインスタンスの最も一般的なタイプがあるとして、独自のMRT TABLE_DUMP_V2サブタイプを与え、そしてそれらをよりコンパクトなエンコーディングが可能になるため、特定のMRTサブタイプを提供しています。これらのサブタイプは、単一のプレフィックスに対して複数のRIBテーブルエントリをエンコードするために、単一のMRTレコードを許可します。プレフィックス長とプレフィックスフィールドは、IPv4およびIPv6プレフィックスのBGP NLRI符号化と同様に符号化されます。すなわち、Prefixフィールドは、オクテット境界上のフィールドの秋の終わりを作るのに十分な末尾のビットに続くアドレスプレフィックスが含まれています。後続のビットの値は無関係です。
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Entry Count | RIB Entries (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: RIB Entry Header
図8：RIBエントリヘッダ
The RIB_GENERIC header is shown below. It is used to cover RIB entries that do not fall under the common case entries defined above. It consists of an AFI, Subsequent AFI (SAFI), and a single NLRI entry. The NLRI information is specific to the AFI and SAFI values. An implementation that does not recognize particular AFI and SAFI values SHOULD discard the remainder of the MRT record.
RIB_GENERICヘッダを以下に示します。上記で定義された一般的なケースのエントリに該当しないRIBエントリをカバーするために使用されます。これは、AFI、後続AFI（SAFI）、および単一NLRIエントリから構成されています。 NLRI情報は、AFIとSAFI値に固有のものです。特定のAFIとSAFI値を認識しない実装では、MRTのレコードの残りを捨てるべきです。
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family Identifier |Subsequent AFI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Layer Reachability Information (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Entry Count | RIB Entries (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: RIB_GENERIC Entry Header
図9：RIB_GENERICエントリのヘッダー
The RIB Entries are repeated Entry Count times. These entries share a common format as shown below. They include a Peer Index from the PEER_INDEX_TABLE MRT record, an originated time for the RIB Entry, and the BGP path attribute length and attributes. All AS numbers in the AS_PATH attribute MUST be encoded as 4-byte AS numbers.
RIBのエントリは、エントリ数回繰り返されます。以下に示すように、これらのエントリは、共通のフォーマットを共有します。彼らはPEER_INDEX_TABLE MRTレコード、RIBエントリの発祥の時間、およびBGPパス属性長と属性から、ピアのインデックスが含まれます。 AS_PATH属性のすべてのAS番号はAS番号4バイトとして符号化されなければなりません。
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originated Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Attributes... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: RIB Entries
図10：RIBエントリ
There is one exception to the encoding of BGP attributes for the BGP MP_REACH_NLRI attribute (BGP Type Code 14) [RFC4760]. Since the AFI, SAFI, and NLRI information is already encoded in the RIB Entry Header or RIB_GENERIC Entry Header, only the Next Hop Address Length and Next Hop Address fields are included. The Reserved field is omitted. The attribute length is also adjusted to reflect only the length of the Next Hop Address Length and Next Hop Address fields.
BGPのエンコーディングは、BGP MP_REACH_NLRI属性（BGPタイプコード14）[RFC4760]の属性に1つの例外があります。 AFI、サフィ、およびNLRI情報が既にRIBエントリヘッダーまたはRIB_GENERICエントリヘッダで符号化されているので、唯一の次ホップアドレス長と次ホップアドレスフィールドが含まれています。予約フィールドが省略されています。属性の長さはまた、ネクストホップアドレス長とネクストホップアドレスフィールドの長さだけを反映するように調整されます。
This type was initially defined in the Zebra software package for the BGP protocol with multiprotocol extension support as defined by RFC 4760 [RFC4760]. The BGP4MP Type has six Subtypes, which are defined as follows:
RFC 4760 [RFC4760]で定義されるように、このタイプは、最初にマルチプロトコル拡張をサポートしてBGPプロトコルのゼブラソフトウェアパッケージで定義されました。 BGP4MPタイプは、次のように定義された6つのサブタイプがあります：
0 BGP4MP_STATE_CHANGE
1 BGP4MP_MESSAGE
4 BGP4MP_MESSAGE_AS4
5 BGP4MP_STATE_CHANGE_AS4
6 BGP4MP_MESSAGE_LOCAL
7 BGP4MP_MESSAGE_AS4_LOCAL
This message is used to encode state changes in the BGP finite state machine (FSM). The BGP FSM states are encoded in the Old State and New State fields to indicate the previous and current state. In some cases, the Peer AS Number may be undefined. In such cases, the value of this field MAY be set to zero. The format is illustrated below:
このメッセージは、BGP有限状態機械（FSM）の状態変化を符号化するために使用されます。 BGP FSMの状態は以前と現在の状態を示すために、旧国家と新州立分野でエンコードされています。いくつかのケースでは、数ASピアが不定になることがあります。このような場合、このフィールドの値はゼロに設定されてもよいです。フォーマットは以下に示されています。
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS Number | Local AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP Address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP Address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old State | New State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: BGP4MP_STATE_CHANGE Subtype
図11：BGP4MP_STATE_CHANGEサブタイプ
The FSM states are defined in RFC 4271 [RFC4271], Section 8.2.2. Both the Old State value and the New State value are encoded as 2-octet numbers. The state values are defined numerically as follows:
FSMの状態は、RFC 4271 [RFC4271]、セクション8.2.2で定義されています。旧州立値と新しい状態値の両方が2オクテットの数字としてエンコードされています。次のように状態値は、数値的に定義されています。
1 Idle
2 Connect
3 Active
4 OpenSent
5 OpenConfirm
6 Established
The BGP4MP_STATE_CHANGE message also includes Interface Index and Address Family fields. The Interface Index provides the interface number of the peering session. The index value is OPTIONAL and MAY be zero if unknown or unsupported. The Address Family indicates what types of addresses are in the address fields. At present, the following AFI Types are supported:
BGP4MP_STATE_CHANGEメッセージもインターフェイスインデックスとアドレスファミリフィールドを含みます。インターフェイスインデックスは、ピアリングセッションのインターフェイス番号を提供します。インデックス値はオプションで、不明またはサポートされていない場合は0であってもよいです。アドレスファミリは、アドレスの種類は、アドレスフィールドにあるかを示しています。現時点では、以下のAFIタイプがサポートされています。
1 AFI_IPv4
2 AFI_IPv6
This subtype is used to encode BGP messages. It can be used to encode any Type of BGP message. The entire BGP message is encapsulated in the BGP Message field, including the 16-octet marker, the 2-octet length, and the 1-octet type fields. The BGP4MP_MESSAGE Subtype does not support 4-byte AS numbers. The AS_PATH contained in these messages MUST only consist of 2-byte AS numbers. The BGP4MP_MESSAGE_AS4 Subtype updates the BGP4MP_MESSAGE Subtype in order to support 4-byte AS numbers. The BGP4MP_MESSAGE fields are shown below:
このサブタイプは、BGPメッセージをエンコードするために使用されます。 BGPメッセージの任意のタイプをエンコードするために使用することができます。全体BGPメッセージは16オクテットのマーカー、2オクテットの長さ、及び1オクテットのタイプフィールドを含む、BGPメッセージフィールド内にカプセル化されています。 BGP4MP_MESSAGEサブタイプは、AS番号4バイトをサポートしていません。これらのメッセージに含まれているAS_PATHは数字だけAS 2バイトで構成されなければなりません。 BGP4MP_MESSAGE_AS4サブタイプは、AS番号4バイトをサポートするためにBGP4MP_MESSAGEサブタイプを更新します。 BGP4MP_MESSAGEフィールドは以下の通りです：
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS Number | Local AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP Address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP Address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Message... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: BGP4MP_MESSAGE Subtype
図12：BGP4MP_MESSAGEサブタイプ
The Interface Index provides the interface number of the peering session. The index value is OPTIONAL and MAY be zero if unknown or unsupported. The Address Family indicates what types of addresses are in the subsequent address fields. At present, the following AFI Types are supported:
インターフェイスインデックスは、ピアリングセッションのインターフェイス番号を提供します。インデックス値はオプションで、不明またはサポートされていない場合は0であってもよいです。アドレスファミリは、アドレスの種類は次のアドレスフィールドにあるかを示しています。現時点では、以下のAFIタイプがサポートされています。
1 AFI_IPv4
2 AFI_IPv6
The Address Family value only applies to the IP addresses contained in the MRT header. The BGP4MP_MESSAGE Subtype is otherwise transparent to the contents of the actual message that may contain any valid AFI/SAFI values. Only one BGP message SHALL be encoded in the BGP4MP_MESSAGE Subtype.
アドレスファミリ値はMRTヘッダに含まれるIPアドレスに適用されます。 BGP4MP_MESSAGEサブタイプは、任意の有効なAFI / SAFI値を含むことができる実際のメッセージの内容にそうでなければ透明です。一つだけBGPメッセージはBGP4MP_MESSAGEサブタイプで符号化されなければなりません。
This subtype updates the BGP4MP_MESSAGE Subtype to support 4-byte AS numbers. The BGP4MP_MESSAGE_AS4 Subtype is otherwise identical to the BGP4MP_MESSAGE Subtype. The AS_PATH in these messages MUST only consist of 4-byte AS numbers. The BGP4MP_MESSAGE_AS4 fields are shown below:
このサブタイプは、AS番号4バイトをサポートするためにBGP4MP_MESSAGEサブタイプを更新します。 BGP4MP_MESSAGE_AS4サブタイプはBGP4MP_MESSAGEサブタイプに他の点では同じです。これらのメッセージにAS_PATHは数字だけAS 4バイトで構成されなければなりません。 BGP4MP_MESSAGE_AS4フィールドは以下の通りです：
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP Address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP Address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Message... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: BGP4MP_MESSAGE_AS4 Subtype
図13：BGP4MP_MESSAGE_AS4サブタイプ
This subtype updates the BGP4MP_STATE_CHANGE Subtype to support 4-byte AS numbers. As with the BGP4MP_STATE_CHANGE Subtype, the BGP FSM states are encoded in the Old State and New State fields to indicate the previous and current state. Aside from the extension of the Peer and Local AS Number fields to 4 bytes, this subtype is otherwise identical to the BGP4MP_STATE_CHANGE Subtype. The BGP4MP_STATE_CHANGE_AS4 fields are shown below:
このサブタイプは、AS番号4バイトをサポートするためにBGP4MP_STATE_CHANGEサブタイプを更新します。 BGP4MP_STATE_CHANGEサブタイプと同じように、BGP FSMの状態は以前と現在の状態を示すために、旧国家と新州立分野でエンコードされています。脇4バイトのピアとローカルAS番号フィールドの拡張から、このサブタイプはBGP4MP_STATE_CHANGEサブタイプに他の点では同一です。 BGP4MP_STATE_CHANGE_AS4フィールドは以下の通りです：
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP Address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP Address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old State | New State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: BGP4MP_STATE_CHANGE_AS4 Subtype
図14：BGP4MP_STATE_CHANGE_AS4サブタイプ
Implementations of MRT have largely focused on collecting remotely generated BGP messages in a passive route collector role. However, for active BGP implementations, it can be useful to archive locally generated BGP messages in addition to remote messages. This subtype is added to indicate a locally generated BGP message. The fields remain identical to the BGP4MP_MESSAGE type including the Peer and Local IP and AS fields. The Local fields continue to refer to the local IP and AS number of the collector that generated the BGP message, and the Peer IP and AS fields refer to the recipient of the generated BGP messages.
MRTの実装は、主に受動的なルートコレクタの役割にリモートで生成されたBGPメッセージの収集に焦点を当てています。ただし、アクティブなBGPの実装のために、リモートのメッセージに加えて、局所的に生成されたBGPメッセージをアーカイブするために役立ちます。このサブタイプは、ローカルで生成されたBGPメッセージを示すために追加されます。フィールドは、ピアおよびローカルIPやフィールドなどを含むBGP4MP_MESSAGEタイプと同じまま。地元のフィールドは、ローカルIPにし、BGPメッセージを生成したコレクタの数、およびピアIP ASとフィールドが生成されたBGPメッセージの受信者を参照しているため、参照するために続けています。
As with the BGP4MP_MESSAGE_LOCAL type, this type indicates locally generated messages. The fields are identical to the BGP4MP_MESSAGE_AS4 message type.
BGP4MP_MESSAGE_LOCALタイプと同じように、このタイプは、ローカルで生成されたメッセージを示します。フィールドがBGP4MP_MESSAGE_AS4メッセージタイプと同じです。
This type supports the IS-IS routing protocol as defined in RFC 1195 [RFC1195]. There is no Type-specific header for the ISIS Type. The Subtype code for this type is undefined. The ISIS PDU directly follows the MRT Common Header fields.
RFC 1195 [RFC1195]で定義されるように、このタイプは、IS-ISルーティングプロトコルをサポートします。 ISISタイプにはタイプ固有のヘッダがありません。このタイプのサブタイプコードが定義されていません。 ISIS PDUは直接MRT共通ヘッダフィールドを次の。
The OSPFv3 Type extends the original OSPFv2 Type to support IPv6 addresses for the OSPFv3 protocol as defined in RFC 5340 [RFC5340]. The format of the MRT Message field for the OSPFv3 Type is as follows:
OSPFv3のタイプは、RFC 5340 [RFC5340]で定義されるようにOSPFv3のプロトコルのIPv6アドレスをサポートするために、元のOSPFv2タイプを拡張します。次のようにOSPFv3のタイプのためのMRTのメッセージフィールドの形式は次のとおりです。
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote IP Address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP Address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Message Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: OSPFv3 Type
図15：OSPFv3のタイプ
This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the MRT specification, in accordance with BCP 26, RFC 5226 [RFC5226].
このセクションでは、BCP 26、RFC 5226 [RFC5226]に従って、MRT仕様に関連する値の登録に関してインターネット割り当て番号機関（IANA）へのガイダンスを提供します。
There are two name spaces in MRT that have been registered: Type Codes and Subtype Codes. Type Codes and Subtype Codes are each 16 bits in length.
タイプコードとサブタイプコード：登録されているMRTで2名のスペースがあります。タイプコードとサブタイプコードの長さはそれぞれ16ビットです。
MRT is not intended as a general-purpose specification for protocol information export, and allocations should not be made for purposes unrelated to routing protocol information export.
MRTは、プロトコル情報をエクスポートするための汎用仕様として意図されていない、および割り当ては、ルーティングプロトコル情報のエクスポートに関係のない目的のために作られるべきではありません。
The following policies are used here with the meanings defined in BCP 26: "Specification Required", "IETF Consensus", "Experimental Use", "First Come First Served". Assignments consist of a name and the value.
次のポリシーは、BCP 26で定義される意味と共にここで使用されている：「仕様が必要」、「IETFコンセンサス」、「実験的使用」、「最初の最初に提供来ます」。割り当ては、名前と値で構成されています。
Type Codes have a range from 0 to 65535, of which 0-64 are reserved. New Type Codes MUST be allocated starting at 65. Type Codes 65-511 are assigned by IETF Review. Type Codes 512-2047 are assigned based on Specification Required. Type Codes 2048-64511 are available on a
タイプコードは、0〜64が予約され、0から65535までの範囲を有します。新しいタイプのコードは、IETFレビューにより割り当てられた65タイプ・コード65から511で始まる割り当てられなければなりません。タイプ・コード512から2047には仕様が必要に基づいて割り当てられます。タイプ・コード2048から64511はで利用可能です
First Come First Served policy. Type Codes 64512 - 65534 are available for Experimental Use. The Type Code Value 65535 is reserved.
まず最初にポリシーを添えてきます。タイプ・コード64512から65534までの実験使用できます。タイプコード値65535が予約されています。
Subtype Codes have a range from 0 to 65535. Subtype definitions are specific to a particular Type Code definition. New Subtype Code definitions must reference an existing Type Code to which the Subtype belongs. Subtype assignments follow the assignment rules for the Type Codes to which they belong.
サブタイプコードは、サブタイプの定義は、特定のタイプコードの定義に固有の0〜65535の範囲を持っています。新しいサブタイプコードの定義は、サブタイプが属する既存のタイプコードを参照する必要があります。サブタイプの割り当ては、彼らが属するタイプ・コードの割り当て規則に従ってください。
This document defines the following message Type Codes:
このドキュメントでは、次のメッセージ・タイプ・コードを定義します。
Name Value Definition
---- ----- ----------
NULL 0 See Appendix B.1.1
START 1 See Appendix B.1.2
DIE 2 See Appendix B.1.3
I_AM_DEAD 3 See Appendix B.1.4
PEER_DOWN 4 See Appendix B.1.5
BGP 5 See Appendix B.2.1
RIP 6 See Appendix B.2.2
IDRP 7 See Appendix B.2.3
RIPNG 8 See Appendix B.2.4
BGP4PLUS 9 See Appendix B.2.5
BGP4PLUS_01 10 See Appendix B.2.5
OSPFv2 11 See Section 4.1
TABLE_DUMP 12 See Section 4.2
TABLE_DUMP_V2 13 See Section 4.3
BGP4MP 16 See Section 4.4
BGP4MP_ET 17 See Section 4.4
ISIS 32 See Section 4.5
ISIS_ET 33 See Section 4.5
OSPFv3 48 See Section 4.6
OSPFv3_ET 49 See Section 4.6
This document defines the following message Subtype Codes for the BGP, BGP4PLUS, and BGP4PLUS_01 Types:
このドキュメントでは、次のメッセージのサブタイプのBGP、BGP4PLUSためのコード、およびBGP4PLUS_01タイプを定義します。
Name Value Definition
---- ----- ----------
BGP_NULL 0 See Appendix B.2.1
BGP_UPDATE 1 See Appendix B.2.1
BGP_PREF_UPDATE 2 See Appendix B.2.1
BGP_STATE_CHANGE 3 See Appendix B.2.1
BGP_SYNC 4 See Appendix B.2.1
BGP_OPEN 5 See Appendix B.2.1
BGP_NOTIFY 6 See Appendix B.2.1
BGP_KEEPALIVE 7 See Appendix B.2.1
This document defines the following message Subtype Codes for the TABLE_DUMP Type:
この文書では、TABLE_DUMPタイプのため、次のメッセージのサブタイプコードを定義します。
Name Value Definition
---- ----- ----------
AFI_IPv4 1 See Section 4.2
AFI_IPv6 2 See Section 4.2
This document defines the following message Subtype Codes for the TABLE_DUMP_V2 Type:
この文書では、TABLE_DUMP_V2タイプのため、次のメッセージのサブタイプコードを定義します。
Name Value Definition
---- ----- ----------
PEER_INDEX_TABLE 1 See Section 4.3
RIB_IPV4_UNICAST 2 See Section 4.3
RIB_IPV4_MULTICAST 3 See Section 4.3
RIB_IPV6_UNICAST 4 See Section 4.3
RIB_IPV6_MULTICAST 5 See Section 4.3
RIB_GENERIC 6 See Section 4.3
This document defines the following message Subtype Codes for the BGP4MP Type:
この文書では、BGP4MPタイプのため、次のメッセージのサブタイプコードを定義します。
Name Value Definition
---- ----- ----------
BGP4MP_STATE_CHANGE 0 See Section 4.4
BGP4MP_MESSAGE 1 See Section 4.4
BGP4MP_ENTRY 2 See Section 4.4
BGP4MP_SNAPSHOT 3 See Section 4.4
BGP4MP_MESSAGE_AS4 4 See Section 4.4
BGP4MP_STATE_CHANGE_AS4 5 See Section 4.4
BGP4MP_MESSAGE_LOCAL 6 See Section 4.4
BGP4MP_MESSAGE_AS4_LOCAL 7 See Section 4.4
The MRT Format utilizes a structure that can store routing protocol information data. The fields defined in the MRT specification are of a descriptive nature and provide information that is useful to facilitate the analysis of routing data. As such, the fields currently defined in the MRT specification do not in themselves create additional security risks, since the fields are not used to induce any particular behavior by the recipient application.
MRTフォーマットは、ルーティングプロトコル情報データを記憶することができる構造を利用します。 MRT仕様で定義されたフィールドは、記述的な性質のものであり、ルーティングデータの分析を容易にするために有用な情報を提供します。フィールドは、受信者の申請により、特定の行動を誘導するために使用されていないので、そのように、現在、MRTの仕様で定義されたフィールドは、自分自身で、追加のセキュリティリスクを作成しないでください。
Some information contained in an MRT data structure might be considered sensitive or private. For example, a BGP peer that sends a message to an MRT-enabled router might not expect that message to be shared beyond the AS to which it is sent.
MRTのデータ構造に含まれる一部の情報は、機密またはプライベートと見なされる可能性があります。たとえば、MRT対応ルータにメッセージを送信するBGPピアは、そのメッセージは、それが送信されるASを超えて共有されることを期待していない可能性があります。
Information that could be considered sensitive includes BGP peer IP addresses, BGP Next Hop IP addresses, and BGP Path Attributes. Such information could be useful to mount attacks against the BGP protocol and routing infrastructure. RFC 4272 [RFC4272] examines a number of weaknesses in the BGP protocol that could potentially be exploited.
敏感と考えられる情報は、BGPピアのIPアドレスが含まれてBGPネクストホップIPアドレス、およびBGPのパス属性。このような情報は、BGPプロトコルとルーティングインフラストラクチャに対する攻撃をマウントするのに有用であろう。 RFC 4272 [RFC4272]は、潜在的に悪用される可能性がBGPプロトコルの弱点の数を調べます。
An organization that intends to use the MRT structure to export routing information beyond the domain where it is normally accessible (e.g., publishing MRT dumps for use by researchers) should verify with any peers whose information might be included, and possibly remove sensitive fields.
それは通常アクセス可能であるドメインを超えてルーティング情報をエクスポートするMRT構造を使用しようとする組織（例えば、公開MRTは、研究者が使用するためにダンプ）は、その情報が含まれている場合があります任意のピアと確認し、そしておそらく敏感なフィールドを削除する必要があります。
The proposed geolocation extension to MRT could reveal the location of an MRT router's peers [GEOMRT].
MRTに提案されたジオロケーション拡張は、MRTルータのピア[GEOMRT]の位置を明らかにできました。
[IANA-AF] IANA, "Address Family Numbers", <http://www.iana.org/numbers.html>.
[IANA-AF] IANA、 "アドレスファミリ番号"、<http://www.iana.org/numbers.html>。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195] Callon、R.は、RFC 1195、1990年12月 "OSIの使用は、TCP / IPやデュアル環境でのルーティングのためIS-IS"。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、李、T.、およびS.野兎、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 4271、2006年1月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760]ベイツ、T.、チャンドラ、R.、カッツ、D.、およびY. Rekhter、 "BGP-4のためのマルチプロトコル拡張機能"、RFC 4760、2007年1月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC5340] Coltun、R.、ファーガソン、D.、モイ、J.、およびA. Lindem、 "IPv6のためのOSPF"、RFC 5340、2008年7月。
[GEOMRT] Manderson, T., "Multi-Threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) Routing Information Export Format with Geo-Location Extensions", RFC 6397, October 2011.
[GEOMRT] Manderson、T.、 "ジオロケーション拡張機能とマルチスレッド・ルーティングツールキット（MRT）ボーダーゲートウェイプロトコル（BGP）ルーティング情報エクスポート形式"、RFC 6397、2011年10月。
[MRT_PROG_GUIDE] Labovitz, C., "MRT Programmer's Guide", November 1999, <http://www.merit.edu/ networkresearch/mrtprogrammer.pdf>.
[MRT_PROG_GUIDE] Labovitz、C.、 "MRTプログラマーズ・ガイド"、1999年11月、<http://www.merit.edu/ネットワーク研究/ mrtprogrammer.pdf>。
[POSIX] Institute of Electrical and Electronics Engineers, "P1003.1, Information Technology Portable Operating System Interface (POSIX) Part 1: System Application Program Interface (API) [C Language], 1990.", IEEE Standard P1003.1.
[POSIX]電気電子技術者協会、 "P1003.1、情報技術ポータブルオペレーティングシステムインタフェース（POSIX）パート1：システム・アプリケーション・プログラム・インターフェース（API）[C言語]、1990年"、IEEE規格P1003.1。
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997.
[RFC2080]マルキン、G.およびR. Minnear、 "IPv6のためのRIPng"、RFC 2080、1997年1月。
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[RFC2453]マルキン、G.、 "RIPバージョン2"、STD 56、RFC 2453、1998年11月。
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006.
[RFC4272]マーフィー、S.、 "BGPセキュリティの脆弱性分析"、RFC 4272、2006年1月。
Appendix A. MRT Encoding Examples
付録A. MRTエンコーディング例
This appendix, which is not normative, contains MRT encoding examples.
規範的ではありません。この付録では、MRTエンコードの例が含まれています。
The following example shows the encoding for an MRT record type of BGP4MP and subtype BGP4MP_MESSAGE_AS4. The Peer AS and Local AS numbers are encoded in 4-byte fields due to the use of the BGP4MP_MESSAGE_AS4 subtype. The encoded BGP Update is shown in hexadecimal. The AS numbers in the ASPATH in the BGP Update are encoded as 4-byte values in accord with the MRT BGP4MP_MESSAGE_AS4 subtype.
次の例は、BGP4MPおよびサブタイプBGP4MP_MESSAGE_AS4のMRTレコードタイプの符号化を示しています。番号はBGP4MP_MESSAGE_AS4サブタイプを使用するための4バイトのフィールドでエンコードされているAS ASおよびローカルピア。符号化されたBGPアップデートは16進数で示されています。 BGPアップデートでASPATHでのAS番号は、MRT BGP4MP_MESSAGE_AS4サブタイプと一致して4バイトの値としてエンコードされています。
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp = 1300475700 epoch sec (2011-03-18 19:15:00) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 16 | Subtype = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length = 82 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS = 64496 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local AS = 64497 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index = 0 | Address Family = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP Address = 192.0.2.85 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP Address = 198.51.100.4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Update =
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
00 3e 02 00 00 00 1f 40 01 01 02 40 02 0e 02 03
00 00 fb f0 00 00 fb ff 00 00 fb f6 40 03 04 c6
33 64 55 c0 08 04 fb f0 00 0e 18 cb 00 71
Figure 16: MRT BGP4MP_MESSAGE_AS4 Example
図16：MRT BGP4MP_MESSAGE_AS4例
The contents of the BGP Update Message above are as follows:
次のようにBGP UPDATEメッセージの内容は上記のとおりです。
ORIGIN: INCOMPLETE ASPATH: 64496 64511 64502 NEXT_HOP: 198.51.100.188 COMMUNITY: 64496:14 NLRI: 203.0.113.0/24
ORIGIN：INCOMPLETE ASPATH：64496 64511 64502 NEXT_HOP：198.51.100.188 COMMUNITY：64496：14 NLRI：203.0.113.0/24
Figure 17: BGP Message Contents
図17：BGPメッセージの内容
The following example displays the encoding for an MRT record type of TABLE_DUMP_V2 and subtype PEER_INDEX_TABLE. The table in this example contains 2 entries.
以下の例は、TABLE_DUMP_V2のMRTレコードタイプとサブタイプPEER_INDEX_TABLEのエンコーディングを表示します。この例では、テーブルには2つのエントリが含まれています。
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp = 1300475700 epoch sec (2011-03-18 19:15:00) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 13 | Subtype = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length = 34 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Collector BGP ID = 198.51.100.4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| View Name Length = 0 | Peer Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Type = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer BGP ID = 198.51.100.5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP Address = 198.51.100.5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS = 65541 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Type = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer BGP ID = 192.0.2.33 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP Address = 192.0.2.33 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS = 65542 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: MRT PEER_INDEX_TABLE Example
図18：MRT PEER_INDEX_TABLE例
The following example displays the encoding for an MRT record type of TABLE_DUMP_V2 and subtype RIB_IPV6_UNICAST. This entry applies to the NLRI prefix of 2001:0DB8::/32. There is a single entry for this prefix. The entry applies to the peer identified by index location 15 in a preceding MRT PEER_INDEX_TABLE record.
以下の例は、TABLE_DUMP_V2のMRTレコードタイプとサブタイプRIB_IPV6_UNICASTのエンコーディングを表示します。 0DB8 :: / 32：このエントリは、2001年のNLRIプレフィックスに適用されます。このプレフィックスのための単一のエントリがあります。エントリは、先行MRT PEER_INDEX_TABLEレコードにインデックス位置15によって識別されるピアに適用されます。
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp = 1300475700 epoch sec (2011-03-18 19:15:00) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 13 | Subtype = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length = 87 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number = 42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preflen = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix = 2001:0DB8::/32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Entry Count = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Index = 15 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Originated Time = 1300475700 epoch sec (2011-03-18 19:15:00) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length = 68 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Path Attributes =
40 01 01 00 50 02 00 0e 02 03 00 00 fb f0 00 00
fb ff 00 00 fb f6 80 0e 2b 00 02 01 20 20 01 0d
b8 00 0d 00 ff 00 00 00 00 00 00 01 87 fe 80 00
00 00 00 00 00 02 12 f2 ff fe 9f 1b 00 00 00 20
20 01 0d b8
Figure 19: MRT RIB_IPV6_UNICAST Example
図19：MRT RIB_IPV6_UNICAST例
The contents of the BGP Path Attribute field above are as follows:
次のように上記のBGPパス属性フィールドの内容は以下のとおりです。
ORIGIN: IGP ASPATH: 64496 64511 64502 MP_REACH_NLRI(IPv6 Unicast) NEXT_HOP: 2001:db8:d:ff::187 NEXT_HOP: fe80::212:f2ff:fe9f:1b00 NLRI: 2001:0DB8::/32
ORIGIN：IGP ASPATH：64496 64511 64502 MP_REACH_NLRI（IPv6ユニキャスト）NEXT_HOP：2001：DB8：D：:: 187 NEXT_HOP FF：FE80 :: 212：f2ff：fe9f：1B00 NLRI：2001：0DB8 :: / 32
Figure 20: BGP Path Attribute Contents
図20：BGPのパス属性内容
Appendix B. Deprecated MRT Types
付録B.非推奨MRTタイプ
This appendix lists deprecated MRT types. These types are documented for informational purposes.
この付録は、MRTのタイプを非推奨します。これらのタイプは、情報提供の目的のために文書化されています。
B.1. Deprecated MRT Informational Types
B.1。非推奨MRT情報の種類
The initial MRT format defined five Informational Type records. These records were intended to signal the state of an MRT data collector and do not contain routing information. These records were intended for use when MRT records were sent over a network to a remote repository store. However, MRT record repository stores have traditionally resided on the same device as the collector, and these Informational Types are not known to be implemented. Further, transport mechanisms for MRT records are considered to be outside the scope of this document.
最初のMRTフォーマットは5つの情報タイプレコードを定義しました。これらのレコードは、MRTデータコレクタの状態を通知することを意図し、ルーティング情報を含んでいません。 MRTレコードがリモートリポジトリストアにネットワーク経由で送信されたときに、これらのレコードは、使用を意図していました。しかし、MRTレコードリポジトリに保存するには、伝統的にコレクタと同じデバイス上に常駐しており、これらの情報の種類が実装されることが知られていません。さらに、MRTレコードの搬送機構は、この文書の範囲外であると考えられます。
The Message field MAY contain an OPTIONAL string for diagnostic purposes. The message string encoding MUST follow the UTF-8 transformation format [RFC3629]. The Subtype field is unused for these Types and SHOULD be set to 0.
メッセージフィールドは、診断目的のためのオプションの文字列を含むかもしれません。メッセージ文字列のエンコーディングはUTF-8変換形式[RFC3629]を従わなければなりません。サブタイプフィールドには、これらのタイプのために使用されず、0に設定する必要があります。
The MRT Informational Types are defined below:
MRT情報の種類を以下のように定義されています。
0 NULL
1 START
2 DIE
3 I_AM_DEAD
4 PEER_DOWN
B.1.1. NULL Type
B.1.1。 NULLタイプ
The NULL Type message causes no operation.
NULLタイプのメッセージは、何も操作を引き起こしません。
B.1.2. START Type
B.1.2。 STARTタイプ
The START Type indicates that a collector is about to begin generating MRT records.
STARTタイプは、コレクタがMRTレコードの生成を開始しようとしていることを示しています。
B.1.3. DIE Type
B.1.3。 DIEタイプ
The DIE Type signals a remote MRT repository that it SHOULD stop accepting messages.
DIEタイプは、メッセージの受け付けを停止するリモートMRTリポジトリを知らせます。
B.1.4. I_AM_DEAD Type
B.1.4。 I_AM_DEADタイプ
An I_AM_DEAD MRT record indicates that a collector has shut down and has stopped generating MRT records.
I_AM_DEAD MRTレコードはコレクターがシャットダウンし、生成MRTの記録を停止していることを示しています。
B.1.5. PEER_DOWN Type
B.1.5。 PEER_DOWNタイプ
The PEER_DOWN message was intended to indicate that a collector had lost association with a BGP peer. However, the MRT format provides BGP state change message types that duplicate this functionality.
PEER_DOWNメッセージは、コレクタがBGPピアとの関連付けを失ったことを示すように意図されていました。しかし、MRTフォーマットは、この機能を複製BGP状態変更メッセージの種類を提供します。
B.2. Other Deprecated MRT Types
B.2。その他の非推奨MRTの種類
5 BGP
6 RIP
7 IDRP
8 RIPNG
9 BGP4PLUS
10 BGP4PLUS_01
B.2.1. BGP Type
B.2.1。 BGPタイプ
The BGP Type indicates that the Message field contains BGP routing information. The BGP routing protocol is defined in RFC 4271 [RFC4271]. The information in the message is dependent on the Subtype value. The BGP Type and all associated Subtypes below are considered to be deprecated by the BGP4MP Type.
BGPのタイプは、メッセージフィールドは、BGPルーティング情報が含まれていることを示しています。 BGPルーティングプロトコルは、RFC 4271 [RFC4271]で定義されています。メッセージ内の情報は、サブタイプの値に依存しています。 BGPタイプと以下のすべての関連するサブタイプはBGP4MPタイプによって廃止されると考えられています。
The following BGP Subtypes are defined for the MRT BGP Type. As with the BGP Type itself, they are all considered to be deprecated.
以下のBGPサブタイプは、MRT BGPタイプのために定義されています。 BGPタイプ自体と同じように、それらはすべて廃止されると考えられています。
0 BGP_NULL
1 BGP_UPDATE
2 BGP_PREF_UPDATE
3 BGP_STATE_CHANGE
4 BGP_SYNC
5 BGP_OPEN
6 BGP_NOTIFY
7 BGP_KEEPALIVE
B.2.1.1. BGP_NULL Subtype
B.2.1.1。 BGP_NULLサブタイプ
The BGP_NULL Subtype is a reserved Subtype.
BGP_NULLサブタイプは、予約済みのサブタイプです。
B.2.1.2. BGP_UPDATE Subtype
B.2.1.2。 BGP_UPDATEサブタイプ
The BGP_UPDATE Subtype is used to encode BGP UPDATE messages. The format of the MRT Message field for this subtype is as follows:
BGP_UPDATEサブタイプは、BGP UPDATEメッセージをエンコードするために使用されます。次のようにこのサブタイプのMRTのメッセージフィールドの形式は次のとおりです。
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP UPDATE Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: BGP_UPDATE Subtype
図21：BGP_UPDATEサブタイプ
The BGP UPDATE Contents include the entire BGP UPDATE message, which follows the BGP Message Header. The BGP Message Header itself is not included. The Peer AS Number and IP Address fields contain the AS number and IP address of the remote system that is generating the BGP UPDATE messages. The Local AS Number and IP Address fields contain the AS number and IP address of the local collector system that is archiving the messages.
BGPの更新内容は、BGPメッセージヘッダに続く全体BGPアップデートメッセージを含みます。 BGPメッセージヘッダ自体は含まれておりません。番号とIPアドレスのフィールドASピアは、BGP UPDATEメッセージを生成しているリモートシステムのAS番号とIPアドレスが含まれています。ローカルAS番号とIPアドレスのフィールドは、メッセージをアーカイブしているローカルコレクタシステムのAS番号とIPアドレスが含まれています。
B.2.1.3. BGP_PREF_UPDATE Subtype
B.2.1.3。 BGP_PREF_UPDATEサブタイプ
The BGP_PREF_UPDATE Subtype is not defined.
BGP_PREF_UPDATEサブタイプが定義されていません。
B.2.1.4. BGP_STATE_CHANGE Subtype
B.2.1.4。 BGP_STATE_CHANGEサブタイプ
The BGP_STATE_CHANGE Subtype is used to reflect changes in the BGP finite state machine. These FSM states are defined in RFC 4271 [RFC4271], Section 8.2.2. Both the Old State value and the New State value are encoded as 2-octet numbers. The state values are defined numerically as follows:
BGP_STATE_CHANGEサブタイプは、BGP有限状態マシンの変化を反映するために使用されます。これらのFSMの状態は、RFC 4271 [RFC4271]、セクション8.2.2で定義されています。旧州立値と新しい状態値の両方が2オクテットの数字としてエンコードされています。次のように状態値は、数値的に定義されています。
1 Idle
2 Connect
3 Active
4 OpenSent
5 OpenConfirm
6 Established
The format of the BGP_STATE_CHANGE Subtype MRT Message field is as follows:
次のようにBGP_STATE_CHANGEサブタイプMRT Messageフィールドの形式は次のとおりです。
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old State | New State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: BGP_STATE_CHANGE Subtype
図22：BGP_STATE_CHANGEサブタイプ
B.2.1.5. BGP_SYNC Subtype
B.2.1.5。 BGP_SYNCサブタイプ
The BGP_SYNC Subtype was intended to convey a system file name where BGP Table Dump messages MAY be recorded. The View Number was to correspond to the View Number provided in the TABLE_DUMP Type records. There are no known implementations of this subtype, and it SHOULD be ignored. The following format applies to this subtype:
BGP_SYNCサブタイプは、BGPテーブルダンプメッセージが記録されてもよいシステムのファイル名を伝えることを意図していました。閲覧数TABLE_DUMPタイプレコードで提供されるビュー数に対応するようにしました。そここのサブタイプの全く知ら実装はありません、それは無視されるべきです。次の形式は、このサブタイプに適用されます。
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| View Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| File Name... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: BGP_SYNC Subtype
図23：BGP_SYNCサブタイプ
The File Name is terminated with a NULL (0) character.
ファイル名はNULL（0）文字で終了します。
B.2.1.6. BGP_OPEN Subtype
B.2.1.6。 BGP_OPENサブタイプ
The BGP_OPEN Subtype is used to encode BGP OPEN messages. The format of the MRT Message field for this subtype is the same as the BGP_UPDATE; however, the last field contains the contents of the BGP OPEN message.
BGP_OPENサブタイプは、BGP OPENメッセージをエンコードするために使用されます。このサブタイプのMRTのメッセージフィールドのフォーマットはBGP_UPDATEと同じです。しかし、最後のフィールドは、BGP OPENメッセージの内容が含まれています。
B.2.1.7. BGP_NOTIFY Subtype
B.2.1.7。 BGP_NOTIFYサブタイプ
The BGP_NOTIFY Subtype is used to encode BGP NOTIFICATION messages. The format of the MRT Message field for this subtype is the same as the BGP_UPDATE; however, the last field contains the contents of the BGP NOTIFICATION message.
BGP_NOTIFYサブタイプは、BGP通知メッセージをエンコードするために使用されます。このサブタイプのMRTのメッセージフィールドのフォーマットはBGP_UPDATEと同じです。しかし、最後のフィールドは、BGP通知メッセージの内容が含まれています。
B.2.1.8. BGP_KEEPALIVE Subtype
B.2.1.8。 BGP_KEEPALIVEサブタイプ
The BGP_KEEPALIVE Subtype is used to encode BGP KEEPALIVE messages. The format of the MRT Message field for this subtype is the same as the BGP_UPDATE; however, the last field contains no information.
BGP_KEEPALIVEサブタイプは、BGPキープアライブメッセージをエンコードするために使用されます。このサブタイプのMRTのメッセージフィールドのフォーマットはBGP_UPDATEと同じです。しかし、最後のフィールドには情報が含まれていません。
B.2.2. RIP Type
B.2.2。 RIPタイプ
The RIP Type is used to export RIP packets as defined in RFC 2453 [RFC2453]. The Subtype field is currently reserved for this type and SHOULD be set to 0.
RIPタイプは、RFC 2453 [RFC2453]で定義されるようにRIPパケットをエクスポートするために使用されます。サブタイプフィールドには、現在、このタイプのために予約されており、0に設定する必要があります。
The format of the MRT Message field for the RIP Type is as follows:
次のようにRIPタイプのためのMRTのメッセージフィールドの形式は次のとおりです。
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIP Message Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: RIP Type
図24：RIPタイプ
B.2.3. IDRP Type
B.2.3。 IDRPタイプ
The IDRP Type was intended to be used to export Inter-Domain Routing Protocol (IDRP) information as defined in the ISO/IEC 10747 standard. However, this type has seen no known use, and there are no details on protocol encoding for this type.
IDRPタイプは、ISO / IEC 10747標準で定義されたドメイン間ルーティングプロトコル（IDRP）の情報をエクスポートするために使用されることを意図していました。しかし、このタイプの既知の使用を認められなかった、このタイプのプロトコル符号化には詳細は存在しません。
B.2.4. RIPNG Type
B.2.4。 RIPNGタイプ
The RIPNG Type is used to export RIPNG protocol packets as defined in RFC 2080 [RFC2080]. The RIPNG protocol updates the RIP protocol to support IPv6. The Subtype field is currently reserved for this type and SHOULD be set to 0.
RFC 2080 [RFC2080]で定義されるようRIPNGタイプRIPngプロトコルパケットをエクスポートするために使用されます。 RIPngプロトコルは、IPv6をサポートするためのRIPプロトコルを更新します。サブタイプフィールドには、現在、このタイプのために予約されており、0に設定する必要があります。
The format of the MRT Message field for the RIPNG Type is as follows:
次のようにRIPNGタイプのためのMRTのメッセージフィールドの形式は次のとおりです。
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Peer IPv6 Address ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Local IPv6 Address ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIPNG Message Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: RIPNG Type
図25：RIPNGタイプ
B.2.5. BGP4PLUS and BGP4PLUS_01 Types
B.2.5。 BGP4PLUSとBGP4PLUS_01タイプ
The BGP4PLUS and BGP4PLUS_01 Types were defined to support IPv6 BGP routing information. The BGP4PLUS Type was specified based on the initial Internet-Draft that became RFC 4760, "Multiprotocol Extensions to BGP-4". The BGP4PLUS_01 Type was specified to correspond to the -01 revision of that Internet-Draft. The two Types share the same definitions in terms of their MRT format specifications.
BGP4PLUSとBGP4PLUS_01タイプは、IPv6 BGPルーティング情報をサポートするために定義されていました。 BGP4PLUSタイプは、RFC 4760になった初期のインターネットドラフト、「BGP-4のマルチプロトコル拡張機能」に基づいて指定されました。 BGP4PLUS_01タイプは、そのインターネットドラフトの-01リビジョンに対応するように指定されました。二つのタイプは、彼らのMRTフォーマット仕様の面で同じ定義を共有しています。
The Subtype field definitions are shared with the BGP Type; however, the address fields in the BGP_UPDATE, BGP_OPEN, BGP_NOTIFY, BGP_KEEPALIVE, and BGP_STATE_CHANGE Subtype records are extended to 16 octets for IPv6 addresses. As with the BGP Type, the BGP4PLUS and BGP4PLUS_01 Types are deprecated as they were superseded by the BGP4MP Type.
サブタイプフィールドの定義は、BGPタイプと共有されています。しかし、BGP_UPDATE、BGP_OPEN、BGP_NOTIFY、BGP_KEEPALIVE、およびBGP_STATE_CHANGEサブタイプレコードのアドレスフィールドは、IPv6アドレスの16個のオクテットに拡張されています。彼らはBGP4MPタイプに取って代わられたようBGPタイプと同じように、BGP4PLUSとBGP4PLUS_01タイプは推奨されません。
B.2.6. Deprecated BGP4MP Subtypes
B.2.6。非推奨BGP4MPサブタイプ
The following two subtypes of the BGP4MP Type are considered to be deprecated.
BGP4MPタイプの以下の2つのサブタイプが廃止されると考えられています。
2 BGP4MP_ENTRY
3 BGP4MP_SNAPSHOT
B.2.6.1. BGP4MP_ENTRY Subtype
B.2.6.1。 BGP4MP_ENTRYサブタイプ
This subtype is similar to the TABLE_DUMP Type and is used to record RIB table entries. It was intended to include true multiprotocol support. However, this subtype does not support 4-byte AS numbers and has not been widely implemented.
このサブタイプは、TABLE_DUMPタイプに似ており、RIBテーブルエントリを記録するために使用されます。それは、真のマルチプロトコルサポートを含めることを意図していました。しかし、このサブタイプは、AS番号を4バイトをサポートしていませんし、広く実装されていません。
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS Number | Local AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP Address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP Address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| View Number | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Last Change |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | SAFI | Next-Hop-Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop Address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Attribute... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: BGP4MP_ENTRY Subtype
図26：BGP4MP_ENTRYサブタイプ
B.2.6.2. BGP4MP_SNAPSHOT Subtype
B.2.6.2。 BGP4MP_SNAPSHOTサブタイプ
This subtype was intended to convey a system file name where BGP4MP_ENTRY records MAY be recorded. It is similar to the BGP_SYNC Subtype and is deprecated.
このサブタイプは、BGP4MP_ENTRYレコードを記録することができるシステムのファイル名を伝えることを意図していました。それはBGP_SYNCサブタイプに似ており、推奨されていません。
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| View Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| File Name... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27: BGP4MP_SNAPSHOT Subtype
図27：BGP4MP_SNAPSHOTサブタイプ
Appendix C. Acknowledgements
付録C.謝辞
The initial MRT specification was developed by Craig Labovitz for use in the Multi-thread Routing Toolkit (MRT) project. The BGP4MP Type was introduced in the Zebra routing software project by Kunihiro Ishiguro. The BGP4MP_ET, ISIS, and ISIS_ET Types were defined in the Python Routing Toolkit (PyRT) developed by Richard Mortier while at Sprint Advanced Technology Labs.
初期MRT仕様は、マルチスレッド・ルーティングツールキット（MRT）のプロジェクトで使用するためにクレイグLabovitzによって開発されました。 BGP4MPタイプは邦弘石黒によってゼブラルーティングソフトウェアプロジェクトで導入されました。 BGP4MP_ET、ISIS、およびISIS_ETタイプは、スプリント先端技術研究所の間、リチャード・モルティエによって開発されたPythonのルーティングツールキット（PyRT）で定義されていました。
Authors' Addresses
著者のアドレス
Larry Blunk Merit Network
ラリー・ブルンクのメリットネットワーク
EMail: ljb@merit.edu
メールアドレス：ljb@merit.edu
Manish Karir Merit Network
マニッシュKhrirメリットネットワーク
EMail: mkarir@merit.edu
メールアドレス：mkarir@merit.edu
Craig Labovitz Deepfield Networks
クレイグLabovitz Deepfieldネットワーク
EMail: labovit@deepfield.net
メールアドレス：labovit@deepfield.net