[要約] RFC 5444は、MANETパケット/メッセージの汎用フォーマットを定義しています。このRFCの目的は、異なるMANETプロトコル間での相互運用性を向上させることです。
Network Working Group T. Clausen
Request for Comments: 5444 LIX, Ecole Polytechnique
Category: Standards Track C. Dearlove
BAE Systems ATC
J. Dean
Naval Research Laboratory
C. Adjih
INRIA Rocquencourt
February 2009
Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format
一般化されたモバイルアドホックネットワーク（MANET）パケット/メッセージ形式
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/ license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Abstract
概要
This document specifies a packet format capable of carrying multiple messages that may be used by mobile ad hoc network routing protocols.
このドキュメントは、モバイルアドホックネットワークルーティングプロトコルで使用できる複数のメッセージを運ぶことができるパケット形式を指定します。
Table of Contents
目次
1. Introduction ....................................................3
2. Notation and Terminology ........................................4
2.1. Notation ...................................................4
2.1.1. Elements ............................................4
2.1.2. Variables ...........................................5
2.2. Terminology ................................................5
3. Applicability Statement .........................................6
4. Protocol Overview and Functioning ...............................7
5. Syntactical Specification .......................................7
5.1. Packets ....................................................8
5.2. Messages ...................................................9
5.3. Address Blocks ............................................11
5.4. TLVs and TLV Blocks .......................................14
5.4.1. TLVs ...............................................14
5.4.2. TLV Usage ..........................................17
5.5. Malformed Elements ........................................18
6. IANA Considerations ............................................18
6.1. Expert Review: Evaluation Guidelines ......................18
6.2. Message Types .............................................20
6.2.1. Message-Type-Specific TLV Registry Creation ........20
6.3. Packet TLV Types ..........................................21
6.3.1. Packet TLV Type Extension Registry Creation ........21
6.4. Message TLV Types .........................................21
6.4.1. Message TLV Type Extension Registry Creation .......22
6.5. Address Block TLV Types ...................................22
6.5.1. Address Block TLV Type Extension Registry
Creation ...........................................23
7. Security Considerations ........................................23
7.1. Authentication and Integrity Suggestions ..................23
7.2. Confidentiality Suggestions ...............................24
8. Contributors ...................................................25
9. Acknowledgments ................................................25
10. References ....................................................26
10.1. Normative References .....................................26
10.2. Informative References ...................................27
Appendix A. Multiplexing and Demultiplexing .......................28
Appendix B. Intended Usage ........................................28
Appendix C. Examples ..............................................30
C.1. Address Block Examples ....................................30
C.2. TLV Examples ..............................................32
Appendix D. Illustrations .........................................34
D.1. Packet ....................................................34
D.2. Message ...................................................38
D.3. Message Body ..............................................44
D.4. Address Block .............................................45
D.5. TLV Block .................................................52
D.6. TLV .......................................................53
Appendix E. Complete Example ......................................57
This document specifies the syntax of a packet format designed for carrying multiple routing protocol messages for information exchange between MANET (Mobile Ad hoc NETwork) routers. Messages consist of a Message Header, which is designed for control of message dissemination, and a Message Body, which contains protocol information. Only the syntax of the packet and messages is specified.
このドキュメントは、MANET（モバイルアドホックネットワーク）ルーター間の情報交換用の複数のルーティングプロトコルメッセージを運ぶために設計されたパケット形式の構文を指定します。メッセージは、メッセージ普及の制御用に設計されたメッセージヘッダーと、プロトコル情報を含むメッセージ本文で構成されています。パケットとメッセージの構文のみが指定されています。
This document specifies:
このドキュメントは次のように指定します。
o A packet format, allowing zero or more messages to be contained within a single transmission. A packet with zero messages may be sent in case the only information to exchange is contained in the Packet Header.
o パケット形式。単一の送信にゼロ以上のメッセージを含めることができます。ゼロメッセージを備えたパケットは、交換する唯一の情報がパケットヘッダーに含まれている場合に送信できます。
o A message format, where a message is composed of a Message Header and a Message Body.
o メッセージ形式。メッセージはメッセージヘッダーとメッセージ本文で構成されています。
o A Message Header format, which contains information that may be sufficient to allow a protocol using this specification to make processing and forwarding decisions.
o この仕様を使用してプロトコルを許可するのに十分な情報を含むメッセージヘッダー形式。
o A Message Body format, containing attributes associated with the message or the originator of the message, as well as blocks of addresses, or address prefixes, with associated attributes.
o メッセージのボディ形式には、メッセージの発信元またはメッセージの原作者に関連付けられた属性、および関連する属性を持つアドレスのブロック、またはアドレスのプレフィックスが含まれています。
o An Address Block format, where an Address Block represents sets of addresses, or address prefixes, in a compact form with aggregated addresses.
o アドレスブロック形式。アドレスブロックは、アドレスのセット、またはアドレスのプレフィックスを集計されたアドレスを備えたコンパクトな形式で表します。
o A generalized type-length-value (TLV) format representing attributes. Each TLV can be associated with a packet, a message, or one or more addresses or address prefixes in a single Address Block. Multiple TLVs can be included, each associated with a packet, a message, and the same, different, or overlapping sets of addresses or address prefixes.
o 属性を表す一般化されたタイプ長値（TLV）形式。各TLVは、単一のアドレスブロック内のパケット、メッセージ、または1つ以上のアドレスまたはアドレスのプレフィックスに関連付けることができます。それぞれがパケット、メッセージ、および同じ、異なる、または重複するアドレスまたはアドレスのプレフィックスに関連付けられている複数のTLVを含めることができます。
The specification has been explicitly designed with the following properties, listed in no particular order, in mind:
この仕様は、次のプロパティで明示的に設計されており、念頭に置かれていません。
Parsing logic - The notation used in this specification facilitates generic, protocol-independent parsing logic.
解析ロジック - この仕様で使用される表記は、一般的なプロトコルに依存しない解析ロジックを容易にします。
Extensibility - Packets and messages defined by a protocol using this specification are extensible by defining new messages and new TLVs. Protocols using this specification will be able to correctly identify and skip such new messages and TLVs, while correctly parsing the remainder of the packet and message.
拡張性 - この仕様を使用してプロトコルによって定義されたパケットとメッセージは、新しいメッセージと新しいTLVを定義することにより拡張可能です。この仕様を使用したプロトコルは、そのような新しいメッセージとTLVを正しく識別してスキップし、残りのパケットとメッセージを正しく解析することができます。
Efficiency - When reported addresses share common bit sequences (e.g., address prefixes or IPv6 interface identifiers), the Address Block representation allows for a compact representation. Compact Message Headers are ensured through permitting inclusion of only required Message Header elements. The multi-message packet structure allows a reduction in the number of transmitted octets and in the number of transmitted packets. The structure of packet and message encoding allows parsing, verifying, and identifying individual elements in a single pass.
効率 - 報告されたアドレスが共通ビットシーケンス（アドレスプレフィックスまたはIPv6インターフェイス識別子など）を共有すると、アドレスブロック表現によりコンパクトな表現が可能になります。コンパクトなメッセージヘッダーは、必要なメッセージヘッダー要素のみを含めることを許可することにより保証されます。マルチメスパケット構造により、送信されたオクテットの数と送信されたパケットの数を減らすことができます。パケットとメッセージエンコードの構造により、単一のパスで個々の要素を解析、検証、および識別することができます。
Separation of forwarding and processing - A protocol using this specification can be designed such that duplicate detection and controlled-scope message forwarding decisions can be made using information contained in the Message Header, without processing the Message Body.
転送と処理の分離 - この仕様を使用したプロトコルは、メッセージ本文を処理せずにメッセージヘッダーに含まれる情報を使用して、複製検出と制御スコープメッセージ転送の決定を行うことができるように設計できます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、[RFC2119]で説明されているように解釈されます。
Additionally, this document uses the notation in Section 2.1 and the terminology in Section 2.2.
さらに、このドキュメントでは、セクション2.1の表記とセクション2.2の用語を使用します。
The following notations, for elements and variables, are used in this document.
このドキュメントでは、要素と変数の次の表記が使用されています。
This format uses network byte order (most significant octet first) for all fields. The most significant bit in an octet is numbered bit 0, and the least significant bit of an octet is numbered bit 7 [Stevens].
この形式は、すべてのフィールドにネットワークバイト順序（最も重要なOctetの最初）を使用します。オクテットの最も重要なビットはビット0に番号が付けられており、オクテットの最も重要なビットはビット7 [スティーブンス]に番号が付けられています。
This specification defines elements. An element is a group of any number of consecutive bits that together form a syntactic entity represented using the notation <element>. Each element in this document is defined as either: o a specifically sized field of bits OR
この仕様は要素を定義します。要素とは、notation <lement>を使用して表現される構文エンティティを形成する連続したビットの任意の数のグループです。このドキュメントの各要素は、次のいずれかとして定義されます。o特別なサイズのビットのフィールドまたは
o a composite element, composed of other <element>s.
o 他の<要素>で構成される複合要素。
A composite element is defined as follows:
複合要素は次のように定義されます。
<element> := specification
where, on the right hand side following :=, specification is represented using the regular expression syntax defined in [SingleUNIX]. Only the following notation is used:
ここで、右側には次のとおりです。次の表記のみが使用されます：
<element1><element2> - Indicates that <element1> is immediately followed by <element2>.
<lement1> <element2> - <lement1>の後に<lement2>が続くことを示します。
(<element1><element2>) - Indicates a grouping of the elements enclosed by the parentheses.
（<element1> <element2>） - 括弧で囲まれた要素のグループ化を示します。
? - Zero or one occurrences of the preceding element or group.
？ - 前の要素またはグループのゼロまたは1つの発生。
* - Zero or more occurrences of the preceding element or group.
* - 前の要素またはグループのゼロ以上の発生。
Variables are introduced into the specification solely as a means to clarify the description. The following two notations are used:
説明を明確にする手段としてのみ、変数が仕様に導入されます。次の2つの表記が使用されます。
<foo> - If <foo> is an unsigned integer field, then <foo> is also used to represent the value of that field.
<foo> -<foo>が署名されていない整数フィールドである場合、<foo>もそのフィールドの値を表すために使用されます。
bar - A variable, usually obtained through calculations based on the value(s) of element(s).
bar-通常、要素の値に基づいて計算によって取得される変数。
This document uses the following terminology:
このドキュメントでは、次の用語を使用しています。
Packet - The top level entity in this specification. A packet contains a Packet Header and zero or more messages.
パケット - この仕様のトップレベルエンティティ。パケットには、パケットヘッダーとゼロ以上のメッセージが含まれています。
Message - The fundamental entity carrying protocol information, in the form of address objects and TLVs.
メッセージ - アドレスオブジェクトとTLVの形でプロトコル情報を運ぶ基本エンティティ。
Address - A number of octets that make up an address of the length indicated by the encapsulating Message Header. The meaning of an address is defined by the protocol using this specification.
アドレス - カプセル化メッセージヘッダーで示される長さのアドレスを構成する多くのオクテット。アドレスの意味は、この仕様を使用してプロトコルによって定義されます。
Address Prefix - An address plus a prefix length, with the prefix length being a number of address bits measured from the left/most significant end of the address.
アドレスプレフィックス - アドレスとプレフィックスの長さ。プレフィックスの長さは、アドレスの左/最も重要な端から測定された多くのアドレスビットです。
Address Object - Either an address, or an address prefix, as specified in an Address Block in this specification.
アドレスオブジェクト - この仕様のアドレスブロックで指定されているように、アドレスまたはアドレスプレフィックスのいずれか。
TLV - A type-length-value structure. This is a generic way in which an attribute can be represented and correctly parsed without the parser having to understand the attribute.
TLV-タイプ長価値構造。これは、パーサーが属性を理解する必要なく、属性を表現し、正しく解析できる一般的な方法です。
This specification describes a generic packet format, designed for use by MANET routing protocols. The specification has been inspired by and extended from that used by the OLSR (Optimized Link State Routing) protocol [RFC3626].
この仕様では、MANETルーティングプロトコルで使用するために設計された一般的なパケット形式について説明します。この仕様は、OLSR（最適化されたリンク状態ルーティング）プロトコル[RFC3626]に触発され、拡張されています。
MANETs are, commonly though not exclusively, characterized as being able to run over wireless network interfaces of limited to moderate capacity. MANETs are therefore less tolerant of wasted transmitted octets than are most wired networks. This specification thus represents a tradeoff between sometimes competing attributes, specifically efficiency, extensibility, and ease of use.
マネは、一般的には排他的ではありませんが、制限された容量に制限されたワイヤレスネットワークインターフェイスを実行できると特徴付けられます。したがって、マネはほとんどの有線ネットワークよりも無駄な送信オクテットに対して耐性が低くなります。したがって、この仕様は、競合する属性、特に効率、拡張性、使いやすさの間のトレードオフを表しています。
Efficiency is supported by reducing packet size and by allowing multiple disjoint messages in a single packet. Reduced packet size is primarily supported by address aggregation, optional Packet Header and Message Header fields, and optional fields in Address Blocks and TLVs. Supporting multi-message packets allows a reduction in the number of packets, each of which can incur significant bandwidth costs from transport, network, and lower layers.
効率は、パケットサイズを縮小し、単一のパケットで複数の否認メッセージを許可することによりサポートされます。パケットサイズの削減は、主にアドレスの集約、オプションのパケットヘッダーとメッセージヘッダーフィールド、およびアドレスブロックとTLVのオプションのフィールドによってサポートされています。マルチメッサージパケットをサポートすると、パケットの数が減少することができ、それぞれが輸送、ネットワーク、および低層からかなりの帯域幅コストが発生する可能性があります。
This specification provides both external and internal extensibility. External extensibility is supported by the ability to add Packet TLVs and to define new Message Types. Internal extensibility is supported by the ability to add Message TLVs and Address Block TLVs to existing messages. Protocols can define new TLV Types, and hence the contents of their Value fields, and new Message Types (see Section 6.1). Protocols can also reuse TLV Type definitions from other protocols that also use this specification.
この仕様は、外部と内部の両方の拡張性を提供します。外部の拡張性は、パケットTLVを追加し、新しいメッセージタイプを定義する機能によってサポートされています。内部拡張性は、メッセージTLVを追加し、既存のメッセージにブロックTLVをアドレス指定する機能によってサポートされています。プロトコルは、新しいTLV型、したがって値フィールドの内容と新しいメッセージタイプを定義できます（セクション6.1を参照）。プロトコルは、この仕様も使用する他のプロトコルからTLVタイプ定義を再利用することもできます。
This specification aims at being sufficiently expressive and flexible to be able to accommodate different classes of MANET routing protocols (e.g., proactive, reactive, and hybrid routing protocols) as well as extensions thereto. Having a common packet and message format, and a common way of representing IP addresses and associated attributes, allows generic parsing code to be developed, regardless of the algorithm used by the routing protocol.
この仕様は、さまざまなクラスのMANETルーティングプロトコル（プロアクティブ、反応性、およびハイブリッドルーティングプロトコルなど）および拡張に対応できるように、十分に表現力豊かで柔軟であることを目的としています。共通のパケットとメッセージ形式、およびIPアドレスと関連する属性を表す共通の方法を持つことで、ルーティングプロトコルで使用されるアルゴリズムに関係なく、一般的な解析コードを開発できます。
All addresses within a message are assumed to be of the same size, specified in the Message Header. In the case of mixed IPv6 and IPv4 addresses, IPv4 addresses can be represented as IPv4-mapped IPv6 addresses as specified in [RFC4291].
メッセージ内のすべてのアドレスは、メッセージヘッダーで指定された同じサイズであると想定されています。IPv6とIPv4の混合アドレスの場合、[RFC4291]で指定されているように、IPv4アドレスをIPv4-Mapped IPv6アドレスとして表すことができます。
The messages defined by this specification are designed to carry MANET routing protocol signaling between MANET routers. This specification includes elements that can support scope-limited flooding, as well as being usable for point-to-point delivery of MANET routing protocol signaling in a multi-hop network. Packets may be unicast or multicast and may use any appropriate transport protocol or none.
この仕様で定義されたメッセージは、マネルーター間のマネールーティングプロトコルシグナル伝達を運ぶように設計されています。この仕様には、スコープ制限された洪水をサポートできる要素と、マルチホップネットワークでのMANETルーティングプロトコルシグナル伝達のポイントツーポイント配信に使用できる要素が含まれています。パケットはユニキャストまたはマルチキャストである場合があり、適切な輸送プロトコルまたはなしを使用する場合があります。
A MANET routing protocol using the message format defined by this specification can constrain the syntax (for example, requiring a specific set of Message Header fields) that the protocol will employ. Protocols with such restrictions need not be able to parse all possible message structures as defined by this document but must be coherent in message generation and reception of messages that they define. If a protocol specifies which elements are included, then direct indexing of the appropriate fields is possible, dependent on the syntax restrictions imposed by the protocol. Such protocols may have more limited extensibility.
この仕様で定義されたメッセージ形式を使用したMANETルーティングプロトコルは、プロトコルが採用する構文（たとえば、特定のメッセージヘッダーフィールドを必要とする）を制約することができます。このような制限を伴うプロトコルは、このドキュメントで定義されているすべての可能なメッセージ構造を解析することはできませんが、メッセージの生成とそれらが定義するメッセージの受信に一貫性がなければなりません。プロトコルにどの要素が含まれているかを指定する場合、プロトコルによって課される構文制限に応じて、適切なフィールドの直接インデックスが可能です。このようなプロトコルの拡張性はより限られている可能性があります。
This specification does not describe a protocol. It describes a packet format, which may be used by any mobile ad hoc network routing protocol.
この仕様では、プロトコルについては説明していません。これは、モバイルアドホックネットワークルーティングプロトコルで使用できるパケット形式について説明しています。
This section normatively provides the syntactical specification of a packet, represented by the element <packet> and the elements from which it is composed. The specification is given using the notation in Section 2.1.
このセクションは、要素<パケット>とそれが構成されている要素で表されるパケットの構文仕様を規範的に提供します。仕様は、セクション2.1の表記を使用して提供されます。
Graphical illustrations of the layout of specified elements are given in Appendix D, a graphical illustration of a complete example (a packet including a message with Address Blocks and TLVs) is given in Appendix E.
指定された要素のレイアウトのグラフィカルイラスト付録Dに示されています。完全な例のグラフィカルなイラスト（アドレスブロックとTLVを含むメッセージを含むパケット）を付録Eに示します。
This format uses network byte order, as indicated in Section 2.1.
この形式は、セクション2.1に示すように、ネットワークバイト順序を使用します。
<packet> is defined by:
<パケット>は次のように定義されています。
<packet> := <pkt-header>
<message>*
where <message> is as defined in Section 5.2. Successful parsing is terminated when all octets of the packet (as defined by the datagram containing the packet) are used.
ここで、<メッセージ>はセクション5.2で定義されています。パケットのすべてのオクテット（パケットを含むデータグラムで定義されている）が使用されると、解析が終了します。
<pkt-header> is defined by:
<pkt-header>は次のように定義されています。
<pkt-header> := <version>
<pkt-flags>
<pkt-seq-num>?
<tlv-block>?
where:
ただし：
<version> is a 4-bit unsigned integer field and specifies the version of the specification on which the packet and the contained messages are constructed. This document specifies version 0.
<バージョン>は4ビットの署名されていない整数フィールドであり、パケットと含まれるメッセージが構築される仕様のバージョンを指定します。このドキュメントは、バージョン0を指定します。
<pkt-flags> is a 4-bit field, specifying the interpretation of the remainder of the Packet Header:
<PKT-FLAGS>は4ビットフィールドで、パケットヘッダーの残りの解釈を指定します。
bit 0 (phasseqnum): If cleared ('0'), then <pkt-seq-num> is not included in the <pkt-header>. If set ('1'), then <pkt-seq-num> is included in the <pkt-header>.
ビット0（phasseqnum）：cleared（ '0'）の場合、<pkt-seq-num>は<pkt-header>に含まれていません。set（ '1'）の場合、<pkt-seq-num>が<pkt-header>に含まれています。
bit 1 (phastlv): If cleared ('0'), then <tlv-block> is not included in the <pkt-header>. If set ('1'), then <tlv-block> is included in the <pkt-header>.
ビット1（phastlv）：クリア（ '0'）の場合、<pkt-header>に<tlv-block>は含まれていません。set（ '1'）の場合、<pkt-header>に<tlv-block>が含まれています。
bits 2-3: Are RESERVED and SHOULD each be cleared ('0') on transmission and SHOULD be ignored on reception.
ビット2-3：予約されており、それぞれ伝送でクリア（ '0'）をクリアする必要があり、受信で無視する必要があります。
<pkt-seq-num> is omitted if the phasseqnum flag is cleared ('0'); otherwise, is a 16-bit unsigned integer field, specifying a Packet Sequence Number.
phasseqnumフラグがクリアされている場合、<pkt-seq-num>は省略されています（ '0'）;それ以外の場合は、パケットシーケンス番号を指定する16ビットの署名のない整数フィールドです。
<tlv-block> is omitted if the phastlv flag is cleared ('0') and is otherwise as defined in Section 5.4.
<tlv-block>は、phastlvフラグがクリアされ（ '0'）、セクション5.4で定義されている場合に省略されています。
It is assumed that the network layer is able to deliver the exact payload length, thus avoiding having to carry the packet length in the packet.
ネットワークレイヤーは正確なペイロード長を提供できると想定されているため、パケットの長さをパケットに持ち込む必要があることを避けます。
Packets may, in addition to the Packet Header, contain one or more messages. Messages contain:
パケットは、パケットヘッダーに加えて、1つ以上のメッセージを含める場合があります。メッセージが含まれています：
o A Message Header.
o メッセージヘッダー。
o A Message TLV Block that contains zero or more TLVs, associated with the whole message.
o メッセージ全体に関連付けられたゼロ以上のTLVを含むメッセージTLVブロック。
o Zero or more Address Blocks, each containing one or more address objects.
o それぞれが1つ以上のアドレスオブジェクトを含むゼロ以上のアドレスブロック。
o An Address Block TLV Block, containing zero or more TLVs and following each Address Block, through which addresses can be associated with additional attributes.
o ゼロ以上のTLVを含むアドレスブロックTLVブロック、および各アドレスブロックに続いて、アドレスを追加の属性に関連付けることができます。
<message> is defined by:
<メッセージ>は次のように定義されています。
<message> := <msg-header>
<tlv-block>
(<addr-block><tlv-block>)*
<msg-header> := <msg-type>
<msg-flags>
<msg-addr-length>
<msg-size>
<msg-orig-addr>?
<msg-hop-limit>?
<msg-hop-count>?
<msg-seq-num>?
where:
ただし：
<tlv-block> is as defined in Section 5.4.
<tlv-block>は、セクション5.4で定義されています。
<addr-block> is as defined in Section 5.3.
<addr-block>は、セクション5.3で定義されています。
<msg-type> is an 8-bit unsigned integer field, specifying the type of the message.
<MSG-Type>は、メッセージのタイプを指定する8ビットの署名されていない整数フィールドです。
<msg-flags> is a 4-bit field, specifying the interpretation of the remainder of the Message Header:
<sg-flags>は4ビットフィールドで、メッセージヘッダーの残りの残りの解釈を指定します。
bit 0 (mhasorig): If cleared ('0'), then <msg-orig-addr> is not included in the <msg-header>. If set ('1'), then <msg-orig-addr> is included in the <msg-header>.
ビット0（mhasorig）：クリア（ '0'）の場合、<sg-orig-addr>は<sg-header>に含まれていません。set（ '1'）の場合、<sg-orig-addr>が<sg-header>に含まれています。
bit 1 (mhashoplimit): If cleared ('0'), then <msg-hop-limit> is not included in the <msg-header>. If set ('1'), then <msg-hop-limit> is included in the <msg-header>.
ビット1（mhashoplimit）：クリア（ '0'）の場合、<sg-hop-limit>は<sg-header>に含まれていません。set（ '1'）の場合、<sg-hop-limit>が<sg-header>に含まれています。
bit 2 (mhashopcount): If cleared ('0'), then <msg-hop-count> is not included in the <msg-header>. If set ('1'), then <msg-hop-count> is included in the <msg-header>.
ビット2（mhashopcount）：cleared（ '0'）の場合、<sg-hop-count>は<sg-header>に含まれていません。set（ '1'）の場合、<sg-hop-count>が<sg-header>に含まれています。
bit 3 (mhasseqnum): If cleared ('0'), then <msg-seq-num> is not included in the <msg-header>. If set ('1'), then <msg-seq-num> is included in the <msg-header>.
ビット3（mhasseqnum）：クリア（ '0'）の場合、<sg-seq-num>は<sg-header>に含まれていません。set（ '1'）の場合、<sg-seq-num>が<sg-header>に含まれています。
<msg-addr-length> is a 4-bit unsigned integer field, encoding the length of all addresses included in this message (<msg-orig-addr> as well as each address included in Address Blocks as defined in Section 5.3), as follows:
<MSG-ADDR-Length>は、4ビットの署名されていない整数フィールドで、このメッセージに含まれるすべてのアドレスの長さ（<MSG-Orig-Addr>とセクション5.3で定義されているアドレスブロックに含まれる各アドレス）をエンコードすることです。次のように：
<msg-addr-length> = the length of an address in octets - 1
<msg-addr-length> is thus 3 for IPv4 addresses, or 15 for IPv6 addresses.
したがって、<MSG-ADDR-Length>は、IPv4アドレスの場合は3、IPv6アドレスの場合は15です。
address-length is a variable whose value is the length of an address in octets and is calculated as follows:
アドレスレングスは、値がオクテットのアドレスの長さであり、次のように計算される変数です。
address-length = <msg-addr-length> + 1
<msg-size> is a 16-bit unsigned integer field, specifying the number of octets that make up the <message>, including the <msg-header>.
<MSG-Size>は、<MSG-Header>を含む<メッセージ>を構成するオクテットの数を指定する16ビットの符号なし整数フィールドです。
<msg-orig-addr> is omitted if the mhasorig flag is cleared ('0'); otherwise, is an identifier with length equal to address-length that can serve to uniquely identify the MANET router that originated the message.
<msg-orig-addr>は、mhasorigフラグがクリアされている場合に省略されています（ '0'）;それ以外の場合は、メッセージを発信したMANETルーターを独自に識別するのに役立つアドレスレングスに等しい長さの識別子です。
<msg-hop-limit> is omitted if the mhashoplimit flag is cleared ('0'); otherwise, is an 8-bit unsigned integer field that can contain the maximum number of hops that the message should be further transmitted.
<msg-hop-limit>は、mhashoplimitフラグがクリアされている場合に省略されています（ '0'）;それ以外の場合は、メッセージをさらに送信する必要があるホップの最大数を含むことができる8ビットの署名のない整数フィールドです。
<msg-hop-count> is omitted if the mhashopcount flag is cleared ('0'); otherwise, is an 8-bit unsigned integer field that can contain the number of hops that the message has traveled.
<MhashopCountフラグがクリアされている場合、<MSG-HOP-Count>は省略されています（ '0'）;それ以外の場合は、メッセージが移動したホップ数を含むことができる8ビットの署名のない整数フィールドです。
<msg-seq-num> is omitted if the mhasseqnum flag is cleared ('0'); otherwise, is a 16-bit unsigned integer field that can contain a sequence number, generated by the message's originator MANET router.
<msg-seq-num>は、mhasseqnumフラグがクリアされている場合に省略されています（ '0'）;それ以外の場合は、メッセージのオリジネーターManetルーターによって生成されるシーケンス番号を含めることができる16ビットの署名のない整数フィールドです。
An Address Block can specify one or more addresses, all of which will be address-length octets long, as specified using the <msg-addr-length> in the <msg-header> of the message containing the Address Block. An Address Block can also specify prefix lengths that can be applied to all addresses in the Address Block, if appropriate. This allows an Address Block to specify either addresses or address prefixes. A protocol may specify that an address with a maximum prefix length (equal to the address length in bits, i.e., 8 * address-length) is considered to be an address, rather than an address prefix, thus allowing an Address Block to contain a mixture of addresses and address prefixes. The common term "address object" is used in this specification to cover both of these; note that an address object in an Address Block always includes the prefix length, if present.
アドレスブロックでは、1つ以上のアドレスを指定できます。これらはすべて、アドレスブロックを含むメッセージの<sg-addr-length>を使用して指定されているように、長さの長さのオクテットになります。アドレスブロックは、必要に応じて、アドレスブロック内のすべてのアドレスに適用できるプレフィックスの長さを指定することもできます。これにより、アドレスブロックがアドレスのいずれかを指定するか、アドレスのプレフィックスを指定できます。プロトコルは、最大プレフィックス長のアドレス（ビットのアドレス長に等しい、つまり8 *アドレス長に等しい）がアドレスのプレフィックスではなくアドレスと見なされることを指定する場合があるため、アドレスブロックがを含むことができるようにすることができます。アドレスとアドレスのプレフィックスの混合。共通の「アドレスオブジェクト」は、これらの両方をカバーするためにこの仕様で使用されます。アドレスブロック内のアドレスオブジェクトには、存在する場合は常にプレフィックスの長さが含まれていることに注意してください。
An address is specified as a sequence of address-length octets of the form Head:Mid:Tail. There are no semantics associated with Head, Mid, or Tail; this representation is solely to allow aggregation of addresses, which often have common parts (e.g., common prefixes or multiple IPv6 addresses on the same interface). An Address Block contains an ordered set of addresses all sharing the same Head and the same Tail, but having individual Mids. Independently, Head and Tail may be empty, allowing for representation of address objects that do not have common Heads or common Tails. Detailed examples of Address Blocks are included in Appendix C.1.
アドレスは、フォームヘッドの長さの長さのオクテットのシーケンスとして指定されています：ミッド：テール。頭、中間、または尾に関連するセマンティクスはありません。この表現は、多くの場合、一般的な部分を持つアドレスの集約を可能にするためだけです（たとえば、同じインターフェイス上の共通のプレフィックスまたは複数のIPv6アドレス）。アドレスブロックには、すべてが同じヘッドと同じ尾を共有しているが、個々のMIDSを共有するすべてのアドレスの順序付けられたセットが含まれています。独立して、頭と尾が空である可能性があり、一般的なヘッドや一般的な尾を持たないアドレスオブジェクトを表現できます。アドレスブロックの詳細な例は、付録C.1に含まれています。
An Address Block can specify address prefixes:
アドレスブロックは、アドレスプレフィックスを指定できます。
o with a single prefix length for all address prefixes OR
o すべてのアドレスのプレフィックスに単一のプレフィックスの長さがある、または
o with a prefix length for each address prefix.
o 各アドレスプレフィックスのプレフィックス長。
<address-block> is defined by:
<アドレスブロック>は次のように定義されています。
<address-block> := <num-addr>
<addr-flags>
(<head-length><head>?)?
(<tail-length><tail>?)?
<mid>*
<prefix-length>*
where:
ただし：
<num-addr> is an 8-bit unsigned integer field containing the number of addresses represented in the Address Block, which MUST NOT be zero.
<num-addr>は、アドレスブロックに表されるアドレスの数を含む8ビットの署名されていない整数フィールドであり、ゼロであってはなりません。
<addr-flags> is an 8-bit field specifying the interpretation of the remainder of the Address Block:
<addr-flags>は、アドレスブロックの残りの解釈を指定する8ビットフィールドです。
bit 0 (ahashead): If cleared ('0'), then <head-length> and <head> are not included in the <address-block>. If set ('1'), then <head-length> is included in the <address-block>, and <head> is included in the <address-block> unless <head-length> is zero.
ビット0（ahashead）：クリア（ '0'）の場合、<head-length>および<head>は<アドレスブロック>に含まれていません。set（ '1'）の場合、<head-luck>に<head-length>が含まれ、<head>が<address-block>に含まれています。
bit 1 (ahasfulltail) and bit 2 (ahaszerotail): Are interpreted according to Table 1. A combination not shown in that table MUST NOT be used.
ビット1（ahasfulltail）およびビット2（ahaszerotail）：表1に従って解釈されます。その表に示されていない組み合わせは使用してはなりません。
bit 3 (ahassingleprelen) and bit 4 (ahasmultiprelen): Are interpreted according to Table 2. A combination not shown in that table MUST NOT be used.
ビット3（ahassingleprelen）およびビット4（ahasmultiprelen）：表2に従って解釈されます。その表に示されていない組み合わせは使用してはなりません。
bits 5-7: Are RESERVED and SHOULD each be cleared ('0') on transmission and SHOULD be ignored on reception.
ビット5-7：予約されており、それぞれ伝送でクリア（ '0'）をクリアする必要があり、受信で無視する必要があります。
+--------------+--------------+---------------+---------------------+
| ahasfulltail | ahaszerotail | <tail-length> | <tail> |
+--------------+--------------+---------------+---------------------+
| 0 | 0 | not included | not included |
| 1 | 0 | included | included unless |
| | | | <tail-length> is |
| | | | zero |
| 0 | 1 | included | not included |
+--------------+--------------+---------------+---------------------+
Table 1: Interpretation of the ahasfulltail and ahaszerotail flags
表1：ahasfulltailとahaszerotailフラグの解釈
+------------+-----------+------------------+-----------------------+
| ahassingle | ahasmulti | number of | prefix length of the |
| prelen | prelen | <prefix-length> | nth address prefix, |
| | | fields | in bits |
+------------+-----------+------------------+-----------------------+
| 0 | 0 | 0 | 8 * address-length |
| 1 | 0 | 1 | <prefix-length> |
| 0 | 1 | <num-addr> | nth <prefix-length> |
+------------+-----------+------------------+-----------------------+
Table 2: Interpretation of the ahassingleprelen and ahasmultiprelen flags
表2：AhassinglprelenとAhasmultiprelenの旗の解釈
<head-length> if present, is an 8-bit unsigned integer field that contains the number of octets in the Head of all of the addresses in the Address Block, i.e., each <head> element included is <head-length> octets long.
<head-length>存在する場合、アドレスブロック内のすべてのアドレスのヘッドのオクテットの数を含む8ビットの符号なし整数フィールドです。長さ。
head-length is a variable, defined to equal <head-length>, if present, or 0 otherwise.
ヘッドレングスは変数であり、存在する場合は<ヘッドレングス>、または0それ以外の場合は0に定義されています。
<head> is omitted if head-length is equal to 0; otherwise, it is a field of the head-length leftmost octets common to all the addresses in the Address Block.
<head>ヘッドレングスが0に等しい場合は省略されています。それ以外の場合は、アドレスブロック内のすべてのアドレスに共通するヘッドレングスの左端のオクテットのフィールドです。
<tail-length> if present, is an 8-bit unsigned integer field that contains the number of octets in the Tail of all of the addresses in the Address Block, i.e., each <tail> element included is <tail-length> octets long.
<テールレングス>存在する場合、アドレスブロック内のすべてのアドレスのテールのオクテットの数を含む8ビットの符号なし整数フィールドです。長さ。
tail-length is a variable, defined to equal <tail-length>, if present, or 0 otherwise.
テールレングスは可変であり、存在する場合は<<テールレングス>、または0それ以外の場合は0に定義されています。
<tail> is omitted if tail-length is equal to 0, or if the ahaszerotail flag is set ('1'); otherwise, it is a field of the tail-length rightmost octets common to all the addresses in the Address Block. If the ahaszerotail flag is set ('1'), then the tail-length rightmost octets of all the addresses in the Address Block are 0.
<テール>は、テールレングスが0に等しい場合、またはahaszerotailフラグが設定されている場合（ '1'）。それ以外の場合は、アドレスブロック内のすべてのアドレスに共通するテールレングスの右端のオクテットのフィールドです。Ahaszerotailフラグが設定されている場合（ '1'）、アドレスブロック内のすべてのアドレスのテールレングスの右端のオクテットは0です。
mid-length is a variable that MUST be non-negative, defined by:
中間長は、以下で定義されている非陰性でなければならない変数です。
mid-length := address-length - head-length - tail-length
i.e., each <mid> element included is mid-length octets long.
つまり、含まれる各<mid>要素は、長さの長さのオクテットです。
<mid> is omitted if mid-length is equal to 0; otherwise, each <mid> is a field of length mid-length octets, representing the Mid of the corresponding address in the Address Block. When not omitted, an Address Block contains exactly <num-addr> <mid> fields.
<mid>中間長が0に等しい場合は省略されています。それ以外の場合、各<mid>は長さの長さのオクテットのフィールドであり、アドレスブロック内の対応するアドレスの中間を表します。省略されていない場合、アドレスブロックには正確に<num-addr> <mid>フィールドが含まれています。
<prefix-length> is an 8-bit unsigned integer field containing the length, in bits, of an address prefix. If the ahassingleprelen flag is set ('1'), then a single <prefix-length> field is included that contains the prefix length of all addresses in the Address Block. If the ahasmultiprelen flag is set ('1'), then <num-addr> <prefix-length> fields are included, each of which contains the prefix length of the corresponding address prefix in the Address Block (in the same order). Otherwise, no <prefix-length> fields are present; each address object can be considered to have a prefix length equal to 8 * address-length bits. The Address Block is malformed if any <prefix-length> element has a value greater than 8 * address-length.
<Prefix-Length>は、アドレスプレフィックスの長さを含む8ビットの署名されていない整数フィールドです。AhassingLeprelenフラグが設定されている場合（ '1'）、アドレスブロック内のすべてのアドレスのプレフィックス長を含む単一の<プレフィックス長>フィールドが含まれています。Ahasmultiprelenフラグが設定されている場合（ '1'）、<num-addr> <プレフィックス - レングス>フィールドが含まれています。各フィールドには、それぞれにアドレスブロックに対応するアドレスプレフィックスのプレフィックス長が含まれています（同じ順序）。それ以外の場合、<プレフィックスレングス>フィールドは存在しません。各アドレスオブジェクトは、8 *アドレスレングスビットに等しいプレフィックスの長さを持つと見なすことができます。<freix-length>要素が8 *アドレス長を超える値を持っている場合、アドレスブロックは奇形です。
A TLV allows the association of an arbitrary attribute with a message or a packet, or with a single address or a contiguous set of addresses in an Address Block. The attribute (value) is made up from an integer number of consecutive octets. Different attributes have different types; attributes that are unknown when parsing can be skipped.
TLVは、任意の属性とメッセージまたはパケット、またはアドレスブロック内の単一のアドレスまたは隣接するアドレスセットとの関連付けを可能にします。属性（値）は、連続したオクテットの整数から構成されています。異なる属性には異なるタイプがあります。解析するときに不明な属性をスキップできます。
TLVs are grouped in TLV Blocks, with all TLVs within a TLV Block associating attributes with either the packet (for the TLV Block in the Packet Header), the message (for the TLV Block immediately following the Message Header), or to addresses in the immediately preceding Address Block. Individual TLVs in a TLV Block immediately following an Address Block can associate attributes to a single address, a range of addresses, or all addresses in that Address Block. When associating an attribute with more than one address, a TLV can include one value for all addresses or one value per address. Detailed examples of TLVs are included in Appendix C.2.
TLVはTLVブロックにグループ化され、すべてのTLVは、パケット（パケットヘッダーのTLVブロック用）、メッセージ（メッセージヘッダーの直後のTLVブロック用）、またはメッセージのアドレスに関連する属性を関連付けます。アドレスブロックの直前。アドレスブロックの直後のTLVブロック内の個々のTLVは、そのアドレスブロック内の単一のアドレス、さまざまなアドレス、またはすべてのアドレスに属性を関連付けることができます。属性を複数のアドレスに関連付ける場合、TLVには、すべてのアドレスに1つの値またはアドレスごとに1つの値を含めることができます。TLVの詳細な例は、付録C.2に含まれています。
A TLV Block is defined by:
TLVブロックは次のように定義されています。
<tlv-block> := <tlvs-length>
<tlv>*
where:
ただし：
<tlvs-length> is a 16-bit unsigned integer field that contains the total number of octets in all of the immediately following <tlv> elements (<tlvs-length> not included).
<tlvs-length>は、16ビットの署名されていない整数フィールドで、<tlv>要素に続くすべてのすべてのオクテットの総数（<tlvs-length>は含まれていません）です。
<tlv> is as defined in Section 5.4.1.
<tlv>は、セクション5.4.1で定義されています。
There are three kinds of TLV, each represented by an element <tlv>:
TLVには3種類のTLVがあり、それぞれが要素<TLV>で表されます。
o A Packet TLV, included in the Packet TLV Block in a Packet Header.
o パケットヘッダーのパケットTLVブロックに含まれるパケットTLV。
o A Message TLV, included in the Message TLV Block in a message, before any Address Blocks.
o アドレスブロックの前に、メッセージのメッセージTLVブロックに含まれるメッセージTLV。
o An Address Block TLV, included in an Address Block TLV Block following an Address Block. An Address Block TLV applies to:
o アドレスブロックTLV。アドレスブロックに続くアドレスブロックTLVブロックに含まれています。アドレスブロックTLVが適用されます。
* all address objects in the Address Block, OR
* アドレスブロック内のすべてのアドレスオブジェクト、または
* any continuous sequence of address objects in the Address Block, OR
* アドレスブロック内のアドレスオブジェクトの連続シーケンス、または
* a single address object in the Address Block.
* アドレスブロック内の単一のアドレスオブジェクト。
<tlv> is defined by:
<tlv>は次のように定義されています。
<tlv> := <tlv-type>
<tlv-flags>
<tlv-type-ext>?
(<index-start><index-stop>?)?
(<length><value>?)?
where:
ただし：
<tlv-type> is an 8-bit unsigned integer field, specifying the type of the TLV, specific to the TLV kind (i.e., Packet TLV, Message TLV, or Address Block TLV).
<TLV-Type>は、TLVの種類（つまり、パケットTLV、メッセージTLV、またはアドレスブロックTLV）に固有のTLVのタイプを指定する8ビットの署名されていない整数フィールドです。
<tlv-flags> is an 8-bit field specifying the interpretation of the remainder of the TLV:
<tlv-flags>は、TLVの残りの解釈を指定する8ビットフィールドです。
bit 0 (thastypeext): If cleared ('0'), then <tlv-type-ext> is not included in the <tlv>. If set ('1'), then <tlv-type-ext> is included in the <tlv>.
ビット0（thastypeext）：クリア（ '0'）の場合、<tlv-type-ext>は<tlv>に含まれていません。set（ '1'）の場合、<tlv-type-ext>が<tlv>に含まれています。
bit 1 (thassingleindex) and bit 2 (thasmultiindex): Are interpreted according to Table 3. A combination not shown in that table MUST NOT be used. Both of these flags MUST be cleared ('0') in Packet TLVs and Message TLVs.
ビット1（thassingleindex）およびビット2（thasmultiindex）：表3に従って解釈されます。その表には示されていない組み合わせは使用してはなりません。これらのフラグは両方とも、パケットTLVとメッセージTLVでクリア（ '0'）をクリアする必要があります。
bit 3 (thasvalue) and bit 4 (thasextlen): Are interpreted according to Table 4. A combination not shown in that table MUST NOT be used.
ビット3（thasvalue）およびビット4（thasextlen）：表4に従って解釈されます。その表に示されていない組み合わせは使用してはなりません。
bit 5 (tismultivalue): This flag serves to specify how the <value> field is interpreted, as specified below. This flag MUST be cleared ('0') in Packet TLVs and Message TLVs, if the thasmultiindex flag is cleared ('0'), or if the thasvalue flag is cleared ('0').
ビット5（Tismultivalue）：このフラグは、以下に指定されているように、<value>フィールドの解釈方法を指定するのに役立ちます。このフラグは、thasmultiindexフラグがクリアされている場合（ '0'）、またはthasvalueフラグがクリアされている場合（ '0'）場合（ '0'）、パケットTLVとメッセージTLVでクリアする必要があります。
bits 6-7: Are RESERVED and SHOULD each be cleared ('0') on transmission and SHOULD be ignored on reception.
ビット6-7：予約されており、それぞれ伝送でクリア（ '0'）をクリアする必要があり、受信で無視する必要があります。
+-----------------+----------------+---------------+--------------+
| thassingleindex | thasmultiindex | <index-start> | <index-stop> |
+-----------------+----------------+---------------+--------------+
| 0 | 0 | not included | not included |
| 1 | 0 | included | not included |
| 0 | 1 | included | included |
+-----------------+----------------+---------------+--------------+
Table 3: Interpretation of the thassingleindex and thasmultiindex flags
表3：thassingleindexとthasmultiindexフラグの解釈
+-----------+------------+--------------+---------------------------+
| thasvalue | thasextlen | <length> | <value> |
+-----------+------------+--------------+---------------------------+
| 0 | 0 | not included | not included |
| 1 | 0 | 8 bits | included unless <length> |
| | | | is zero |
| 1 | 1 | 16 bits | included unless <length> |
| | | | is zero |
+-----------+------------+--------------+---------------------------+
Table 4: Interpretation of the thasvalue and thasextlen flags
表4：thasvalueとthasextlenフラグの解釈
<tlv-type-ext> is an 8-bit unsigned integer field, specifying an extension of the TLV Type, specific to the TLV Type and kind (i.e., Packet TLV, Message TLV, or Address Block TLV).
<TLV-Type-Ext>は、TLVタイプと種類（つまり、パケットTLV、メッセージTLV、またはアドレスブロックTLV）に固有のTLVタイプの拡張を指定する8ビットの署名のない整数フィールドです。
tlv-type-ext is a variable, defined to equal <tlv-type-ext>, if present, or 0 otherwise.
TLV-Type-Extは変数であり、存在する場合は<TLV-Type-Ext>、または0それ以外の場合は0に定義されています。
tlv-fulltype is a variable, defined by:
tlv-fulltypeは変数で、次のように定義されています。
tlv-fulltype := 256 * <tlv-type> + tlv-type-ext
<index-start> and <index-stop> when present, in an Address Block TLV only, are each an 8-bit unsigned integer field.
<index-start>および<index-stop>が存在する場合、アドレスブロックTLVのみに、それぞれ8ビットの署名されていない整数フィールドがあります。
index-start and index-stop are variables, defined according to Table 5. The variable end-index is defined as follows:
インデックススタートとインデックスストップは変数であり、表5に従って定義されています。変数のエンドインデックスは次のように定義されています。
* For Message TLVs and Packet TLVs:
* メッセージTLVとパケットTLVの場合：
end-index := 0
End-Index：= 0
* For Address Block TLVs:
* アドレスブロックTLVの場合：
end-index := <num-addr> - 1
An Address Block TLV applies to the address objects from position index-start to position index-stop (inclusive) in the Address Block, where the first address object has position zero.
アドレスブロックTLVは、最初のアドレスオブジェクトに位置ゼロがあるアドレスブロックの位置インデックススタートからインデックスストップ（包括的）の位置へのアドレスオブジェクトに適用されます。
+-----------------+----------------+----------------+---------------+
| thassingleindex | thasmultiindex | index-start := | index-stop := |
+-----------------+----------------+----------------+---------------+
| 0 | 0 | 0 | end-index |
| 1 | 0 | <index-start> | <index-start> |
| 0 | 1 | <index-start> | <index-stop> |
+-----------------+----------------+----------------+---------------+
Table 5: Interpretation of the thassingleindex and thasmultiindex flags
表5：thassingleindexとthasmultiindexフラグの解釈
number-values is a variable, defined by:
数値値は変数で、次のように定義されています。
number-values := index-stop - index-start + 1
<length> is omitted or is an 8-bit or 16-bit unsigned integer field according to Table 4. If the tismultivalue flag is set ('1'), then <length> MUST be an integral multiple of number-values, and the variable single-length is defined by:
<length>は省略されているか、表4に従って8ビットまたは16ビットの符号なし整数フィールドです。Tismultivalueフラグが設定されている場合（ '1'）、<length>は数値値の積分倍でなければならず、可変の単一長さは、次のように定義されます。
single-length := <length> / number-values
If the tismultivalue flag is cleared ('0'), then the variable single-length is defined by:
Tismultivalueフラグがクリアされている場合（ '0'）、変数の単一長さは以下で定義されます。
single-length := <length>
<value> if present (see Table 4), is a field of length <length> octets. In an Address Block TLV, <value> is associated with the address objects from positions index-start to index-stop, inclusive. If the tismultivalue flag is cleared ('0'), then the whole of this field is associated with each of the indicated address objects. If the tismultivalue flag is set ('1'), then this field is divided equally into number-values fields, each of length single-length octets, and these are associated, in order, with the indicated address objects.
<value>存在する場合（表4を参照）、長さ<length>オクテットのフィールドです。アドレスブロックTLVでは、<value>は、Positions Index-Startからインデックスストップまでのアドレスオブジェクトに関連付けられています。Tismultivalueフラグがクリアされている場合（ '0'）、このフィールド全体が指定された各アドレスオブジェクトに関連付けられています。Tismultivalueフラグが設定されている場合（ '1'）、このフィールドは、長さの単一長のオクテットの各数値フィールドに均等に分割され、これらは指定されたアドレスオブジェクトと関連付けられています。
A TLV associates an attribute with a packet, a message, or one or more consecutive address objects in an Address Block. The interpretation and processing of this attribute, and the relationship (including order of processing) between different attributes associated with the same entity MUST be defined by any protocol that uses this specification.
TLVは、アドレスブロック内のパケット、メッセージ、または1つ以上の連続したアドレスオブジェクトに属性を関連付けます。この属性の解釈と処理、および同じエンティティに関連付けられた異なる属性間の関係（処理の順序を含む）は、この仕様を使用するプロトコルによって定義する必要があります。
Any protocol using this specification MUST define appropriate behaviors if this associated information is inconsistent, in particular if two TLVs of the same type but with different values apply to the same entity (packet, message, or address) but this is not meaningful. The protocol MUST also specify an appropriate processing order for TLVs associated with a given entity.
この仕様を使用するプロトコルは、この関連情報が一貫性がない場合、特に同じタイプの2つのTLVが同じエンティティ（パケット、メッセージ、またはアドレス）に適用される場合、適切な動作を定義する必要がありますが、これは意味がありません。また、プロトコルは、特定のエンティティに関連付けられたTLVの適切な処理順序を指定する必要があります。
An element is malformed if it cannot be parsed according to its syntactical specification (including if there are insufficient octets available). If the malformed element is in the Packet Header, then the packet MUST be silently discarded, and contained messages MUST NOT be processed and MUST NOT be forwarded. If the malformed element is contained in a message (i.e., is in the Message TLV Block, an Address Block, or an Address Block TLV Block), then that message MUST be silently discarded; it MUST NOT be processed and MUST NOT be forwarded.
要素は、その構文仕様に応じて解析できない場合に不正されています（利用可能なオクテットが不十分な場合を含む）。不正な要素がパケットヘッダーにある場合、パケットは静かに破棄する必要があり、含まれるメッセージを処理する必要はなく、転送してはなりません。不正な要素がメッセージに含まれている場合（つまり、メッセージTLVブロック、アドレスブロック、またはアドレスブロックTLVブロックにある場合）、そのメッセージは静かに破棄する必要があります。処理してはならず、転送してはなりません。
This document introduces four namespaces that have been registered: Message Types, Packet TLV Types, Message TLV Types, and Address Block TLV Types. This section specifies IANA registries for these namespaces and provides guidance to the Internet Assigned Numbers Authority regarding registrations in these namespaces.
このドキュメントでは、登録されている4つの名前空間を紹介します：メッセージタイプ、パケットTLVタイプ、メッセージTLVタイプ、およびアドレスブロックTLVタイプ。このセクションは、これらの名前空間のIANAレジストリを指定し、これらの名前空間の登録に関する数字を割り当てられた数字の権限をインターネットに提供します。
The following terms are used with the meanings defined in [BCP26]: "Namespace", "Assigned Value", "Registration", "Unassigned", "Reserved", "Hierarchical Allocation", and "Designated Expert".
[BCP26]で定義されている意味で次の用語が使用されます：「名前空間」、「割り当てられた値」、「登録」、「未割り当て」、「予約済み」、「階層配分」、および「指定されたエキスパート」。
The following policies are used with the meanings defined in [BCP26]: "Private Use", "Expert Review", and "Standards Action".
[BCP26]で定義されている意味とともに、次のポリシーが使用されます：「私的使用」、「専門家のレビュー」、および「標準アクション」。
For registration requests where an Expert Review is required, the Designated Expert SHOULD take the following general recommendations into consideration:
専門家のレビューが必要な登録要求の場合、指定された専門家は次の一般的な推奨事項を考慮する必要があります。
o The purpose of these registries is to support Standard and Experimental MANET routing and related protocols and extensions to these protocols.
o これらのレジストリの目的は、これらのプロトコルへの標準的および実験的なマネのルーティングと関連するプロトコルと拡張をサポートすることです。
o The intention is that all registrations will be accompanied by a published RFC.
o 意図は、すべての登録に公開されたRFCが伴うことです。
o In order to allow for registration prior to the RFC being approved for publication, the Designated Expert can approve the registration once it seems clear that an RFC is expected to be published.
o RFCが公開される前に登録を許可するために、指定された専門家は、RFCが公開されると予想されることが明らかになったら登録を承認できます。
o The Designated Expert will post a request to the MANET WG mailing list, or to a successor thereto as designated by the Area Director, for comments and reviews. This request will include a reference to the Internet-Draft requesting the registration.
o 指定された専門家は、コメントとレビューのために、Manet WGメーリングリスト、またはエリアディレクターによって指定された後継者にリクエストを投稿します。このリクエストには、登録を要求するインターネットドラフトへの参照が含まれます。
o Before a period of 30 days has passed, the Designated Expert will either approve or deny the registration request and publish a note of the decision to the MANET WG mailing list or its successor, as well as inform IANA and the IESG. A denial note MUST be justified by an explanation and, in cases where it is possible, suggestions as to how the request can be modified so as to become acceptable SHOULD be provided.
o 30日間が経過する前に、指定された専門家は登録要求を承認または拒否し、決定のメモをMANET WGメーリングリストまたはその後継者に公開し、IANAとIESGに通知します。拒否ノートは説明によって正当化されなければならず、可能な場合は、受け入れられるようにリクエストをどのように変更できるかについての提案を提供する必要があります。
For the registry for Message Types, the following guidelines apply:
メッセージタイプのレジストリの場合、次のガイドラインが適用されます。
o Registration of a Message Type implies creation of two registries for Message-Type-specific Message TLVs and Message-Type-specific Address Block TLVs. The document that requests the registration of the Message Type MUST indicate how these Message-Type-specific TLV Types are to be allocated, from any options in [BCP26], and any initial allocations. The Designated Expert SHOULD take the allocation policies specified for these registries into consideration in reviewing the Message Type allocation request.
o メッセージタイプの登録は、メッセージタイプ固有のメッセージTLVとメッセージタイプ固有のアドレスブロックTLVの2つのレジストリの作成を意味します。メッセージタイプの登録を要求するドキュメントは、[BCP26]のオプションと初期割り当てから、これらのメッセージタイプ固有のTLVタイプをどのように割り当てるかを示す必要があります。指定された専門家は、メッセージタイプの割り当て要求を確認する際に、これらのレジストリに指定された割り当てポリシーを考慮に入れる必要があります。
For the registries for Packet TLV Types, Message TLV Types, and Address Block TLV Types, the following guidelines apply:
パケットTLVタイプのレジストリ、メッセージTLVタイプ、およびアドレスブロックTLVタイプの場合、次のガイドラインが適用されます。
o These are Hierarchical Allocations, i.e., allocation of a type creates a registry for the extended types corresponding to that type. The document that requests the registration of the type MUST indicate how these extended types are to be allocated, from any options in [BCP26], and any initial allocations. Normally this allocation should also undergo Expert Review, but with the possible allocation of some type extensions as Reserved, Experimental, and/or Private.
o これらは階層的な割り当てです。つまり、型の割り当ては、そのタイプに対応する拡張型のレジストリを作成します。タイプの登録を要求するドキュメントは、[BCP26]のオプションと初期割り当てから、これらの拡張タイプがどのように割り当てられるかを示す必要があります。通常、この割り当てはエキスパートレビューも受ける必要がありますが、予約済み、実験的、および/またはプライベートとして、いくつかのタイプ拡張機能が割り当てられる可能性があります。
o The request for a TLV Type MUST include the specification of the permitted size, syntax of any internal structure, and meaning, of the Value field (if any) of the TLV.
o TLVタイプの要求には、許可されたサイズの仕様、内部構造の構文、およびTLVの値フィールド（存在する場合）の意味を含める必要があります。
For the registries for Message TLV Types and Address Block TLV Types, the following additional guidelines apply:
メッセージTLVタイプのレジストリとアドレスブロックTLVタイプの場合、次の追加ガイドラインが適用されます。
o TLV Type values 0-127 are common for all Message Types. TLVs that receive registrations from the 0-127 interval SHOULD be modular in design to allow reuse among protocols.
o TLVタイプ値0-127は、すべてのメッセージタイプで一般的です。0-127間隔から登録を受け取るTLVは、プロトコル間で再利用できるように設計のモジュール式でなければなりません。
o TLV Type values 128-223 are Message-Type-specific TLV Type values, relevant only in the context of the containing Message Type. Registration of TLV Type values within the 128-223 interval requires that a registry in the 128-223 interval exists for a specific Message Type value (see Section 6.2.1), and registrations are made in accordance with the allocation policies specified for these Message-Type-specific registries. Message-Type-specific TLV Types SHOULD be registered for TLVs that the Designated Expert deems too Message-Type-specific for registration of a 0-127 value. Multiple different TLV definitions MAY be assigned the same TLV Type value within the 128-223 interval, given that they are associated with different Message-Type-specific TLV Type registries. Where possible, existing global TLV definitions and modular global TLV definitions for registration in the 0-127 range SHOULD be used.
o TLVタイプ値128-223は、メッセージタイプのコンテキストでのみ関連するメッセージタイプ固有のTLVタイプ値です。128-223間隔内のTLVタイプ値の登録には、特定のメッセージタイプ値に対して128-223間隔のレジストリが存在する必要があり（セクション6.2.1を参照）、登録はこれらのメッセージに指定された割り当てポリシーに従って行われます - タイプ固有のレジストリ。メッセージタイプ固有のTLVタイプは、指定された専門家が0-127値の登録にメッセージタイプ固有のものとみなすTLVに登録する必要があります。複数の異なるTLV定義に、異なるメッセージタイプ固有のTLVタイプレジストリに関連付けられていることを考えると、128-223間隔内で同じTLVタイプ値が割り当てられます。可能であれば、既存のグローバルTLV定義と0-127範囲での登録のモジュラーグローバルTLV定義を使用する必要があります。
A new registry for Message Types has been created, with initial assignments and allocation policies as specified in Table 6.
メッセージタイプの新しいレジストリが作成され、表6に指定されているように、初期割り当てと割り当てポリシーが作成されました。
+---------+-------------+-------------------+
| Type | Description | Allocation Policy |
+---------+-------------+-------------------+
| 0-223 | Unassigned | Expert Review |
| 224-255 | Unassigned | Experimental Use |
+---------+-------------+-------------------+
Table 6: Message Types
表6：メッセージタイプ
When a Message Type is registered, then registries MUST be specified for both Message-Type-specific Message TLVs (Table 8) and Message-Type-specific Address Block TLVs (Table 10). A document that creates a Message-Type-specific TLV registry MUST also specify the mechanism by which Message-Type-specific TLV Types are allocated, from among those in [BCP26].
メッセージタイプが登録されている場合、メッセージタイプ固有のメッセージTLV（表8）とメッセージタイプ固有のアドレスブロックTLV（表10）に対してレジストリを指定する必要があります。メッセージタイプ固有のTLVレジストリを作成するドキュメントは、[BCP26]の中で、メッセージタイプ固有のTLVタイプが割り当てられるメカニズムも指定する必要があります。
A new registry for Packet TLV Types has been created, with initial assignments and allocation policies as specified in Table 7.
パケットTLVタイプの新しいレジストリが作成され、表7に指定されているように、初期割り当てと割り当てポリシーが作成されました。
+---------+-------------+-------------------+
| Type | Description | Allocation Policy |
+---------+-------------+-------------------+
| 0-223 | Unassigned | Expert Review |
| 224-255 | Unassigned | Experimental Use |
+---------+-------------+-------------------+
Table 7: Packet TLV Types
表7：パケットTLVタイプ
When a Packet TLV Type is registered, then a new registry for type extensions of that type must be created. A document that defines a Packet TLV Type MUST also specify the mechanism by which its type extensions are allocated, from among those in [BCP26].
パケットTLVタイプが登録されている場合、そのタイプのタイプ拡張機能の新しいレジストリを作成する必要があります。パケットTLVタイプを定義するドキュメントは、[BCP26]の拡張から、そのタイプ拡張機能が割り当てられるメカニズムも指定する必要があります。
A new registry for Message-Type-independent Message TLV Types has been created, with initial assignments and allocation policies as specified in Table 8.
メッセージタイプに依存しないメッセージTLVタイプの新しいレジストリが作成され、表8に指定されているように初期割り当てと割り当てポリシーが作成されました。
+---------+-----------------------+-----------------------+
| Type | Description | Allocation Policy |
+---------+-----------------------+-----------------------+
| 0-127 | Unassigned | Expert Review |
| 128-223 | Message-Type-specific | Reserved, see Table 9 |
| 224-255 | Unassigned | Experimental Use |
+---------+-----------------------+-----------------------+
Table 8: Message TLV Types
表8：メッセージTLVタイプ
Message TLV Types 128-223 are reserved for Message-Type-specific Message TLVs, for which a new registry is created with the registration of a Message Type, and with initial assignments and allocation policies as specified in Table 9.
メッセージTLVタイプ128-223は、メッセージタイプの登録と、表9に指定された初期割り当てと割り当てポリシーを使用して、メッセージタイプ固有のメッセージTLVのために予約されています。
+---------+-----------------------------+-------------------+
| Type | Description | Allocation Policy |
+---------+-----------------------------+-------------------+
| 0-127 | Common to all Message Types | Reserved |
| 128-223 | Message-Type-specific | See Below |
| 224-255 | Common to all Message Types | Reserved |
+---------+-----------------------------+-------------------+
Table 9: Message-Type-specific Message TLV Types
表9：メッセージタイプ固有のメッセージTLVタイプ
Allocation policies for Message-Type-specific Message TLV Types MUST be specified when creating the registry associated with the containing Message Type, see Section 6.2.1.
メッセージタイプ固有のメッセージTLV型の割り当てポリシーを指定する必要があります。コンテンディングメッセージタイプに関連付けられたレジストリを作成するときは、セクション6.2.1を参照してください。
If a Message TLV Type is registered, then a new registry for type extensions of that type must be created. A document that defines a Message TLV Type MUST also specify the mechanism by which its type extensions are allocated, from among those in [BCP26].
メッセージTLVタイプが登録されている場合、そのタイプのタイプ拡張機能の新しいレジストリを作成する必要があります。メッセージTLVタイプを定義するドキュメントでは、[BCP26]の中で、そのタイプ拡張機能が割り当てられるメカニズムも指定する必要があります。
A new registry for Message-Type-independent Address Block TLV Types has been created, with initial assignments and allocation policies as specified in Table 10.
メッセージタイプに依存しないアドレスブロックTLVタイプの新しいレジストリが作成され、表10に指定されているように初期割り当てと割り当てポリシーが作成されました。
+---------+-----------------------+------------------------+
| Type | Description | Allocation Policy |
+---------+-----------------------+------------------------+
| 0-127 | Unassigned | Expert Review |
| 128-223 | Message-Type-specific | Reserved, see Table 11 |
| 224-255 | Unassigned | Experimental Use |
+---------+-----------------------+------------------------+
Table 10: Address Block TLV Types
表10：アドレスブロックTLVタイプ
Address Block TLV Types 128-223 are reserved for Message-Type-specific Address Block TLVs, for which a new registry is created with the registration of a Message Type, and with initial assignments and allocation policies as specified in Table 11.
アドレスブロックTLVタイプ128-223は、メッセージタイプの登録と、表11に指定された初期割り当てと割り当てポリシーを使用して、メッセージタイプ固有のアドレスブロックTLVのために予約されています。
+---------+-----------------------------+-------------------+
| Type | Description | Allocation Policy |
+---------+-----------------------------+-------------------+
| 0-127 | Common to all Message Types | Reserved |
| 128-223 | Message-Type-specific | See Below |
| 224-255 | Common to all Message Types | Reserved |
+---------+-----------------------------+-------------------+
Table 11: Message-Type-specific Address Block TLV Types
表11：メッセージタイプ固有のアドレスブロックTLVタイプ
Allocation policies for Message-Type-specific Address Block TLV Types MUST be specified when creating the registry associated with the containing Message Type, see Section 6.2.1.
メッセージタイプ固有のアドレスブロックTLVタイプの割り当てポリシーを指定する必要があります。コンテンディングメッセージタイプに関連付けられたレジストリを作成するときは、セクション6.2.1を参照してください。
When an Address Block TLV Type is registered, then a new registry for type extensions of that type must be created. A document that defines a Message TLV Type MUST also specify the mechanism by which its type extensions are allocated, from among those in [BCP26].
アドレスブロックTLVタイプが登録されている場合、そのタイプのタイプ拡張機能の新しいレジストリを作成する必要があります。メッセージTLVタイプを定義するドキュメントでは、[BCP26]の中で、そのタイプ拡張機能が割り当てられるメカニズムも指定する必要があります。
This specification does not describe a protocol; it describes a packet format. As such, it does not specify any security considerations; these are matters for a protocol using this specification. However, some security mechanisms are enabled by this specification and may form part of a protocol using this specification. Mechanisms that may form part of an authentication and integrity approach in a protocol using this specification are described in Section 7.1. Mechanisms that may form part of a confidentiality approach in a protocol using this specification are described in Section 7.2. There is, however, no requirement that a protocol using this specification should use either.
この仕様では、プロトコルについては説明していません。パケット形式について説明します。そのため、セキュリティ上の考慮事項は指定されていません。これらは、この仕様を使用したプロトコルの問題です。ただし、一部のセキュリティメカニズムはこの仕様によって有効になり、この仕様を使用してプロトコルの一部を形成する場合があります。この仕様を使用して、プロトコルで認証と整合性のアプローチの一部を形成する可能性のあるメカニズムは、セクション7.1で説明されています。この仕様を使用してプロトコルで機密性アプローチの一部を形成する可能性のあるメカニズムは、セクション7.2で説明されています。ただし、この仕様を使用するプロトコルがどちらかを使用する必要はありません。
The authentication and integrity suggestions made here are based on the intended usage in Appendix B, specifically that:
ここで行われた認証と整合性の提案は、付録Bの意図された使用法、特に次のように基づいています。
o Messages are designed to be carriers of protocol information and MAY, at each hop, be forwarded and/or processed by the protocol using this specification.
o メッセージはプロトコル情報のキャリアになるように設計されており、各ホップで、この仕様を使用してプロトコルによって転送および/または処理される場合があります。
o Packets are designed to carry a number of messages between neighboring MANET routers in a single transmission and over a single logical hop.
o パケットは、隣接するマネルーター間で単一の伝送と単一の論理ホップ上に多数のメッセージを運ぶように設計されています。
Consequently:
その結果：
o For forwarded messages where the message is unchanged by forwarding MANET routers, end-to-end authentication and integrity MAY be implemented, between MANET routers with an existing security association, by including a suitable Message TLV containing a cryptographic signature in the message. Since <msg-hop-count> and <msg-hop-limit> are the only fields that should be modified when such a message is forwarded in this manner, this signature can be calculated based on the entire message, including the Message Header, with the <msg-hop-count> and <msg-hop-limit> fields set to 0, if present.
o MANETルーターを転送することによりメッセージが変更されていない転送されたメッセージの場合、既存のセキュリティ協会のMANETルーター間でエンドツーエンドの認証と整合性が実装される場合があります。<sg-hop-count>および<sg-hop-limit>は、このようなメッセージがこの方法で転送されるときに変更する唯一のフィールドであるため、この署名はメッセージヘッダーを含むメッセージ全体に基づいて計算できます。<msg-hop-count>および<msg-hop-limit>フィールドが0に設定されている場合、存在する場合。
o Hop-by-hop packet level authentication and integrity MAY be implemented, between MANET routers with an existing security association, by including a suitable Packet TLV containing a cryptographic signature to the packet. Since packets are received as transmitted, this signature can be calculated based on the entire packet or on parts thereof as appropriate.
o ホップバイホップパケットレベルの認証と整合性は、パケットに暗号化署名を含む適切なパケットTLVを含めることにより、既存のセキュリティアソシエーションを持つマネートルーター間で実装できます。パケットは送信どおりに受信されるため、この署名は、パケット全体または必要に応じてその部品に基づいて計算できます。
This specification does not explicitly enable protecting packet/ message confidentiality. Such confidentiality would normally, when required, be provided hop-by-hop, either by link-layer mechanisms or at the IP layer using [RFC4301], and would apply to a packet only.
この仕様では、パケット/メッセージの機密性の保護を明示的に有効にすることはできません。このような機密性は、通常、必要に応じて、リンク層メカニズムまたは[RFC4301]を使用してIPレイヤーでホップバイホップを提供し、パケットのみに適用されます。
It is possible, however, for a protocol using this specification to protect the confidentiality of information included in a Packet, Message, or Address Block TLV by specifying that the Value field of that TLV Type be encrypted, as well as specifying the encryption mechanism.
ただし、この仕様を使用してプロトコルを使用して、そのTLVタイプの値フィールドを暗号化し、暗号化メカニズムを指定することにより、パケット、メッセージ、またはアドレスブロックTLVに含まれる情報の機密性を保護することが可能です。
In an extreme case, all information can be encrypted by defining either:
極端な場合、すべての情報は、次のいずれかを定義することで暗号化できます。
o A packet, consisting of only a Packet Header (with no messages) and containing a Packet TLV, where the Packet TLV Type indicates that its Value field contains one or more encrypted messages. Upon receipt, and once this Packet TLV is successfully decrypted, these messages may then be parsed according to this specification and processed according to the protocol using this specification.
o パケットヘッダーのみ（メッセージなし）で構成されるパケットとパケットTLVが含まれているパケットTLVタイプには、その値フィールドに1つ以上の暗号化されたメッセージが含まれていることが示されています。受領時に、このパケットTLVが正常に復号化されると、これらのメッセージはこの仕様に従って解析され、この仕様を使用してプロトコルに従って処理される場合があります。
o A message, consisting of only a Message Header and a single Message TLV, where the Message TLV Type indicates that its Value field contains an encrypted version of the message's remaining Message TLVs, Address Blocks, and Address Block TLVs. Upon receipt, and once this Message TLV is successfully decrypted, the complete message may then be parsed according to this specification and processed according to the protocol using this specification.
o メッセージヘッダーと単一のメッセージTLVのみで構成されるメッセージ。メッセージTLVタイプは、その値フィールドに、メッセージの残りのメッセージTLVの暗号化されたバージョン、アドレスブロック、およびアドレスブロックTLVを含むことを示します。受領時に、このメッセージTLVが正常に復号化されると、完全なメッセージはこの仕様に従って解析され、この仕様を使用してプロトコルに従って処理される場合があります。
In either case, the protocol MUST define the encrypted TLV Type, as well as the format of the encrypted data block contained in the Value field of the TLV.
どちらの場合でも、プロトコルは、暗号化されたTLVタイプと、TLVの値フィールドに含まれる暗号化されたデータブロックの形式を定義する必要があります。
This specification is the result of the joint efforts of the following contributors from the OLSRv2 Design Team, listed alphabetically:
この仕様は、OLSRV2設計チームからの次の貢献者の共同努力の結果であり、アルファベット順にリストされています。
o Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr>
o セドリック・アジェイ、フランス、インリア、<cedric.adjih@inria.fr>
o Emmanuel Baccelli, INRIA, France, <Emmanuel.Baccelli@inria.fr>
o エマニュエル・バッケリ、フランス、インリア、<emmanuel.baccelli@inria.fr>
o Thomas Heide Clausen, LIX, Ecole Polytechnique, France, <T.Clausen@computer.org>
o Thomas Heide Clausen、Lix、Ecole Polytechnique、France、<T.Clausen@computer.org>
o Justin W. Dean, NRL, USA, <jdean@itd.nrl.navy.mil>
o ジャスティン・W・ディーン、NRL、米国、<jdean@itd.nrl.navy.mil>
o Christopher Dearlove, BAE Systems, UK, <chris.dearlove@baesystems.com>
o Christopher Dearlove、Bae Systems、英国、<chris.dearlove@baesystems.com>
o Satoh Hiroki, Hitachi SDL, Japan, <hiroki.satoh.yj@hitachi.com>
o Satoh Hiroki、日本SDL、日本、<hiroki.satoh.yj@hitachi.com>
o Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr>
o フィリップ・ジャケット、インリア、フランス、<フィリップ。Jacquet@inria.fr>
o Monden Kazuya, Hitachi SDL, Japan, <kazuya.monden.vw@hitachi.com>
o Monden Kazuya、日立SDL、日本、<Kazuya.monden.vw@hitachi.com>
The authors would like to acknowledge the team behind OLSR [RFC3626], including Anis Laouiti (INT, France), Pascale Minet, Laurent Viennot (both at INRIA, France), and Amir Qayyum (Center for Advanced Research in Engineering, Pakistan) for their contributions. Elwyn Davies (Folly Consulting, UK), Lars Eggert (Nokia, Finland), Chris Newman (Sun Microsystems, USA), Tim Polk (NIST, USA), and Magnus Westerlund (Ericsson, Sweden) all provided detailed reviews and insightful comments.
著者は、Anis Laouiti（Int、France）、Pascale Minet、Laurent Viennot（両方ともInria、France）、Amir Qayyum（パキスタン、パキスタンの工学研究センター）など、OLSR [RFC3626]の背後にあるチーム[RFC3626]の背後にあるチームに感謝します。彼らの貢献。Elwyn Davies（Folly Consulting、UK）、Lars Eggert（Nokia、Finland）、Chris Newman（Sun Microsystems、USA）、Tim Polk（Nist、USA）、Magnus Westerlund（Sweden、Ericsson）はすべて、詳細なレビューと洞察に満ちたコメントを提供しました。
The authors would like to gratefully acknowledge the following people for intense technical discussions, early reviews, and comments on the specification and its components (listed alphabetically): o Brian Adamson (NRL)
著者は、激しい技術的な議論、早期レビュー、仕様とそのコンポーネントに関するコメント（アルファベット順）について、次の人々に感謝します：O Brian Adamson（NRL）
o Teco Boot (Infinity Networks)
o Teco Boot（Infinity Networks）
o Florent Brunneau (LIX)
o フローレントブルーノー（LIX）
o Ian Chakeres (CenGen)
o イアン・チェイカーズ（ケンゲン）
o Alan Cullen (BAE Systems)
o アラン・カレン（BAEシステム）
o Ulrich Herberg (LIX)
o ウルリッヒ・ハーバーグ（lix）
o Joe Macker (NRL)
o ジョー・マッカー（NRL）
o Yasunori Owada (Niigata University)
o Yasunori Owada（Niigata University）
o Charlie E. Perkins (WiChorus)
o チャーリーE.パーキンス（ウィチョルス）
o Henning Rogge (FGAN)
o ヘニングロッジ（fgan）
o Andreas Schjonhaug (LIX)
o アンドレアス・ションハウグ（lix）
and the entire IETF MANET working group.
およびIETFマネワーキンググループ全体。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、RFC 2119、BCP 14、1997年3月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 4291、2006年2月。
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[BCP26] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[SingleUNIX] IEEE Std 1003.1, The Open Group, and ISO/IEC JTC 1/SC22/WG15, "Single UNIX Specification, Version 3, 2004 Edition", April 2004.
[singleUnix] IEEE STD 1003.1、オープングループ、およびISO/IEC JTC 1/SC22/WG15、「Single Unix仕様、バージョン3、2004エディション」、2004年4月。
[RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State Routing Protocol", RFC 3626, October 2003.
[RFC3626] Clausen、T。およびP. Jacquet、「最適化されたリンク状態ルーティングプロトコル」、RFC 3626、2003年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[Stevens] Stevens, W., "TCP/IP Illustrated Volume 1 - The Protocols", 1994.
[スティーブンス]スティーブンス、W。、「TCP/IP Illustrated Volume 1 -The Protocols」、1994。
The packet and message format specified in this document is designed to allow zero or more messages to be contained within a single packet. Such messages may be from the same or different protocols. Thus, a multiplexing and demultiplexing process MUST be present.
このドキュメントで指定されているパケットとメッセージ形式は、ゼロ以上のメッセージを単一のパケット内に含めるように設計されています。このようなメッセージは、同じまたは異なるプロトコルからのものである場合があります。したがって、多重化および逆転換プロセスが存在する必要があります。
Multiplexing messages on a given MANET router into a single packet, rather than having each message generate its own packet, reduces the total number of octets and the number of packets transmitted by that MANET router.
各メッセージを独自のパケットに生成するのではなく、特定のMANETルーターでのメッセージを単一のパケットにマルチプレックスすると、オクテットの総数とそのMANETルーターによって送信されるパケットの数が減少します。
The multiplexing and demultiplexing process running on a given UDP port or IP protocol number, and its associated protocols, MUST:
特定のUDPポートまたはIPプロトコル番号で実行されている多重化および非複数のプロセス、およびそれに関連するプロトコルは、次のことをしなければなりません。
o For each Message Type, a protocol -- unless specified otherwise, the one making the IANA reservation for that Message Type -- MUST be designated as the "owner" of that Message Type.
o 各メッセージタイプについて、プロトコルは、特に指定されていない限り、そのメッセージタイプのIANA予約を作成しているものは、そのメッセージタイプの「所有者」として指定する必要があります。
o The Packet Header fields, including the Packet TLV Block, are used by the multiplexing and demultiplexing process, which MAY make such information available for use in its protocol instances.
o パケットTLVブロックを含むパケットヘッダーフィールドは、マルチプレックスおよび非拡張プロセスで使用され、そのような情報がそのプロトコルインスタンスで使用できるようになる可能性があります。
o The <pkt-seq-num> field, if present, contains a sequence number that is incremented by 1 for each packet generated by a node. The sequence number after 65535 is 0. In other words, the sequence number "wraps" in the usual way.
o <Pkt-seq-num>フィールドは、存在する場合、ノードで生成された各パケットに対して1で増分するシーケンス番号を含みます。65535以降のシーケンス番号は0です。つまり、シーケンス番号は通常の方法で「ラップ」します。
o Incoming messages MUST be either silently discarded or MUST be delivered to the instance of the protocol that owns the associated Message Type. Incoming messages SHOULD NOT be delivered to any other protocol instances and SHOULD NOT be delivered to more than one protocol instance.
o 着信メッセージは静かに破棄するか、関連するメッセージタイプを所有するプロトコルのインスタンスに配信する必要があります。着信メッセージは他のプロトコルインスタンスに配信されるべきではなく、複数のプロトコルインスタンスに配信されるべきではありません。
o Outgoing messages of a given type MUST be generated only by the protocol instance that owns that Message Type and be delivered to the multiplexing and demultiplexing process.
o 特定のタイプの発信メッセージは、そのメッセージタイプを所有するプロトコルインスタンスによってのみ生成され、多重化および非複数のプロセスに配信される必要があります。
o If two protocols both wish to use the same Message Type, then this interaction SHOULD be specified by the protocol that is the designated owner of that Message Type.
o 2つのプロトコルが両方とも同じメッセージタイプを使用したい場合、このインタラクションは、そのメッセージタイプの指定された所有者であるプロトコルによって指定する必要があります。
This appendix describes the intended usage of Message Header fields, including their content and use. Alternative uses of this specification are permitted.
この付録では、コンテンツと使用を含むメッセージヘッダーフィールドの意図された使用について説明しています。この仕様の代替用途は許可されています。
The message format specified in this document is designed to carry MANET routing protocol signaling between MANET routers and to support scope-limited flooding as well as point-to-point delivery.
このドキュメントで指定されているメッセージ形式は、マネールーター間のMANETルーティングプロトコルシグナル伝達を携帯し、スコープ制限された洪水とポイントツーポイント配信をサポートするように設計されています。
Messages are designed to be able to be forwarded over one or more logical hops, in a new packet for each logical hop. Each logical hop may consist of one or more IP hops.
メッセージは、論理ホップごとに新しいパケットで、1つ以上の論理ホップに転送できるように設計されています。各論理ホップは、1つ以上のIPホップで構成されている場合があります。
Specifically, scope-limited flooding is supported for messages when:
具体的には、次の場合、範囲制限の洪水はメッセージに対してサポートされています。
o The <msg-orig-addr> field, if present, contains the unique identifier of the MANET router that originated the message.
o <MSG-Orig-Addr>フィールドは、存在する場合、メッセージを発信したMANETルーターの一意の識別子が含まれています。
o The <msg-seq-num> field, if present, contains a sequence number that starts at 0 when the first message of a given type is generated by the originator node, and that is incremented by 1 for each message generated of that type. The sequence number after 65535 is 0. In other words, the sequence number "wraps" in the usual way.
o <msg-seq-num>フィールドは、存在する場合、特定のタイプの最初のメッセージがオリジネーターノードによって生成されたときに0から始まるシーケンス番号を含み、そのタイプのメッセージが生成された各メッセージに対して1によって増加します。65535以降のシーケンス番号は0です。つまり、シーケンス番号は通常の方法で「ラップ」します。
o If the <msg-orig-addr> and <msg-seq-num> fields are both present, then the Message Header provides for duplicate suppression, using the identifier consisting of the message's <msg-orig-addr>, <msg-seq-num>, and <msg-type>. These serve to uniquely identify the message in the MANET within the time period until <msg-seq-num> is repeated, i.e., wraps around to a matching value.
o <sg-orig-addr>および<msg-seq-num>フィールドが両方が存在する場合、メッセージヘッダーは、メッセージの<sg-orig-addr>、<msg-seqで構成される識別子を使用して、重複抑制を提供します。-num>、および<msg-type>。これらは、<sg-seq-num>が繰り返されるまで、つまり一致する値に包まれるまで、期間内にマネのメッセージを独自に識別するのに役立ちます。
o <msg-hop-limit> field, if present, contains the number of hops on which the packet is allowed to travel before being discarded by a MANET router. The <msg-hop-limit> is set by the message originator and is used to prevent messages from endlessly circulating in a MANET. When forwarding a message, a MANET router should decrease the <msg-hop-limit> by 1, and the message should be discarded when <msg-hop-limit> reaches 0.
o <MSG-HOP-LIMIT>フィールドには、存在する場合、マネルーターに廃棄される前に、パケットが移動できるホップ数が含まれています。<sg-hop-limit>はメッセージオリジネーターによって設定され、メッセージがマネで際限なく循環するのを防ぐために使用されます。メッセージを転送する場合、MANETルーターは<sg-hop-limit>を1で減らし、<sg-hop-limit>が0に達するとメッセージを破棄する必要があります。
o <msg-hop-count> field, if present, contains the number of hops on which the packet has traveled across the MANET. The <msg-hop-count> is set to 0 by the message originator and is used to prevent messages from endlessly circulating in a MANET. When forwarding a message, a MANET router should increase <msg-hop-count> by 1 and should discard the message when <msg-hop-count> reaches 255.
o <MSG-Hop-Count>フィールドには、存在する場合、パケットがマネを横切って移動したホップ数が含まれています。<sg-hop-count>は、メッセージオリジネーターによって0に設定され、メッセージがマネで際限なく循環するのを防ぐために使用されます。メッセージを転送する場合、MANETルーターは<msg-hop-count>を1増加し、<sg-hop-count>が255に達したときにメッセージを破棄する必要があります。
o If the <msg-hop-limit> and <msg-hop-count> fields are both present, then the Message Header provides the information to make forwarding decisions for scope-limited flooding. This may be by any appropriate flooding mechanism specified by a protocol using this specification.
o <sg-hop-limit>と<msg-hop-count>フィールドが両方が存在する場合、メッセージヘッダーは、範囲制限された洪水の転送決定を行うための情報を提供します。これは、この仕様を使用してプロトコルによって指定された適切な洪水メカニズムによるものです。
This appendix contains some examples of parts of this specification.
この付録には、この仕様の一部の例がいくつか含まれています。
The following examples illustrate how some combinations of addresses may be efficiently included in Address Blocks. These examples are for IPv4, with address-length equal to 4. a, b, c, etc. represent distinct, non-zero octet values.
次の例は、アドレスのいくつかの組み合わせがどのようにアドレスブロックに効率的に含まれるかを示しています。これらの例はIPv4のもので、アドレス長は4に等しくなります。A、B、Cなどは、異なる非ゼロオクテット値を表します。
Note that it is permissible to use a less efficient representation, in particular one in which the ahashead and ahasfulltail flags are cleared ('0'), and hence head-length = 0, tail-length = 0, mid-length = address-length, and (with no address prefixes) the Address Block consists of the number of addresses, <addr-flags> with value 0, and a list of the unaggregated addresses. This is the most efficient way to represent a single address, and the only way to represent, for example, a.b.c.d and e.f.g.h in one Address Block.
効率の低い表現、特にアハシェッドとアハサフルテールフラグがクリアされているもの（ '0'）、したがってヘッドレングス= 0、テールレングス= 0、中程度の長さ=アドレス=アドレス - を使用することは許されていることに注意してください。長さ、および（アドレスプレフィックスなし）アドレスブロックは、アドレスの数、<addr-flags>値0、および凝集していないアドレスのリストで構成されています。これは、単一のアドレスを表す最も効率的な方法であり、たとえば1つのアドレスブロックでA.B.C.DおよびE.F.G.Hを表す唯一の方法です。
Examples:
例：
o To include a.b.c.d, a.b.e.f, and a.b.g.h:
o A.B.C.D、A.B.E.F、A.B.G.Hを含める
* head-length = 2;
* ヘッドレングス= 2;
* tail-length = 0;
* テールレングス= 0;
* mid-length = 2;
* 中間長= 2;
* <addr-flags> has ahashead set (value 128);
* <tail-length> and <tail> are omitted.
* <テールレングス>および<テール>は省略されています。
The Address Block is then 3 128 2 a b c d e f g h (11 octets).
アドレスブロックは、3 128 2 A B C D E F G H（11オクテット）です。
o To include a.b.c.g and d.e.f.g:
o A.B.C.GとD.E.F.Gを含める：
* head-length = 0;
* ヘッドレングス= 0;
* tail-length = 1;
* テールレングス= 1;
* mid-length = 3;
* 中間長= 3;
* <addr-flags> has ahasfulltail set (value 64);
* <head-length> and <head> are omitted.
* <head-length>および<head>は省略されています。
The Address Block is then 2 64 1 g a b c d e f (10 octets).
アドレスブロックは、2 64 1 g a b c d e f（10オクテット）です。
o To include a.b.d.e and a.c.d.e:
o A.B.D.EとA.C.D.Eを含める：
* head-length = 1;
* ヘッドレングス= 1;
* tail-length = 2;
* テールレングス= 2;
* mid-length = 1;
* 中間長= 1;
* <addr-flags> has ahashead and ahasfulltail set (value 192).
* <AddR-Flags> AHASHEADとAHASFULLTAILセット（値192）があります。
The Address Block is then 2 192 1 a 2 d e b c (9 octets).
アドレスブロックは、2 192 1 A 2 D E B C（9オクテット）です。
o To include a.b.0.0, a.c.0.0, and a.d.0.0:
o A.B.0.0、A.C.0.0、およびA.D.0.0を含めるには：
* head-length = 1;
* ヘッドレングス= 1;
* tail-length = 2;
* テールレングス= 2;
* mid-length = 1;
* 中間長= 1;
* <addr-flags> has ahashead and ahaszerotail set (value 160);
* <tail> is omitted.
* <テール>は省略されています。
The Address Block is then 3 160 1 a 2 b c d (8 octets).
アドレスブロックは、3 160 1 A 2 B C D（8オクテット）です。
o To include a.b.0.0 and c.d.0.0:
o A.B.0.0とC.D.0.0を含めるには：
* head-length = 0;
* ヘッドレングス= 0;
* tail-length = 2;
* テールレングス= 2;
* mid-length = 2;
* 中間長= 2;
* <addr-flags> has ahaszerotail set (value 32);
* <head> and <tail> are omitted.
* <head>および<Tail>は省略されています。
The Address Block is then 2 32 2 a b c d (7 octets).
アドレスブロックは2 32 2 A B C D（7オクテット）です。
o To include a.b.0.0/n and c.d.0.0/n:
o A.B.0.0/NおよびC.D.0.0/Nを含めるには：
* head-length = 0;
* ヘッドレングス= 0;
* tail-length = 2;
* テールレングス= 2;
* mid-length = 2;
* 中間長= 2;
* <addr-flags> has ahaszerotail and ahassingleprelen set (value
48);
* <head> and <tail> are omitted.
* <head>および<Tail>は省略されています。
The Address Block is then 2 48 2 a b c d n (8 octets).
アドレスブロックは、2 48 2 a b c d n（8オクテット）です。
o To include a.b.0.0/n and c.d.0.0/m:
o A.B.0.0/NおよびC.D.0.0/Mを含める：
* head-length = 0;
* ヘッドレングス= 0;
* tail-length = 2;
* テールレングス= 2;
* mid-length = 2;
* 中間長= 2;
* <addr-flags> has ahaszerotail and ahasmultiprelen set (value
40);
* <head> and <tail> are omitted.
* <head>および<Tail>は省略されています。
The Address Block is then 2 40 2 a b c d n m (9 octets).
アドレスブロックは、2 40 2 A B C D N M（9オクテット）です。
Assume the definition of an Address Block TLV with type EXAMPLE1 (and no type extension) that has single octet values per address. There are a number of ways in which values a, a, b, and c may be associated with the four addresses in the preceding Address Block, where c is a default value that can be omitted.
アドレスごとに単一のオクテット値を持つタイプのexample1（およびタイプ拡張機能なし）のアドレスブロックTLVの定義を仮定します。値a、a、b、およびcが、前のアドレスブロックの4つのアドレスに関連付けられる方法はいくつかあります。ここで、Cは省略できるデフォルト値です。
Examples:
例：
o Using one multivalue TLV to cover all of the addresses:
o 1つのマルチバリューTLVを使用して、すべてのアドレスをカバーします。
* <tlv-flags> has thasvalue and tismultivalue set (value 20);
* <index-start> and <index-stop> are omitted;
* <length> = 4 (single-length = 1).
* <length> = 4（single-length = 1）。
* The TLV is then EXAMPLE1 20 4 a a b c (7 octets).
* TLVは例1 20 4 A a b c（7オクテット）です。
o Using one multivalue TLV and omitting the last address:
o 1つのマルチバリューTLVを使用し、最後のアドレスを省略します。
* <tlv-flags> has thasmultiindex, thasvalue, and tismultivalue
set (value 52);
* <index-start> = 0;
* <index-stop> = 2;
* <length> = 3 (single-length = 1).
* <length> = 3（single-length = 1）。
* The TLV is then EXAMPLE1 52 0 2 3 a a b (8 octets).
* TLVは、例1 52 0 2 3 A A B（8オクテット）です。
o Using two single value TLVs and omitting the last address. First:
o 2つの単一値TLVを使用し、最後のアドレスを省略します。初め：
* <tlv-flags> has thasmultiindex and thasvalue set (value 48);
* <index-start> = 0;
* <index-stop> = 1;
* <length> = 1;
* <value> = a.
* <value> = a。
* The TLV is then EXAMPLE1 48 0 1 1 a (6 octets).
* TLVは例1 48 0 1 1 A（6オクテット）です。
Second:
2番目：
* <tlv-flags> has thassingleindex and thasvalue set (value 80);
* <index-start> = 2;
* <index-stop> is omitted;
* <length> = 1;
* <value> = b.
* <値> = b。
* The TLV is then EXAMPLE1 80 2 1 b (5 octets).
* TLVは例1 80 2 1 B（5オクテット）です。
Total length of TLVs is 11 octets.
TLVの全長は11オクテットです。
In this case, the first of these is the most efficient. In other cases, patterns such as the others may be preferred. Regardless of efficiency, any of these may be used.
この場合、これらの最初のものが最も効率的です。それ以外の場合、他のパターンなどのパターンが推奨される場合があります。効率に関係なく、これらのいずれかを使用できます。
Assume the definition of an Address Block TLV with type EXAMPLE2 (and no type extension) that has no value and that is to be associated with the second and third addresses in an Address Block. This can be indicated with a single TLV: o <tlv-flags> has thasmultiindex set (value 32);
型example2（およびタイプ拡張機能なし）を備えたアドレスブロックTLVの定義を仮定します。これは、単一のTLVで示すことができます：O <TLV-Flags>にはthasmultiindexセット（値32）があります。
o <index-start> = 1;
o <index-stop> = 2;
o <length> and <value> are omitted.
o <length>および<value>は省略されています。
o The TLV is then EXAMPLE2 32 1 2 (4 octets).
o TLVは例232 1 2（4オクテット）です。
Assume the definition of a Message TLV with type EXAMPLE3 (and no type extension) that can take a Value field of any length. For such a TLV with 8 octets of data (a to h):
example3（およびタイプ拡張機能なし）を使用したメッセージTLVの定義を想定してください。8オクテットのデータ（A〜H）を持つこのようなTLVの場合：
o <tlv-flags> has thasvalue set (value 16);
o <index-start> and <index-stop> are omitted;
o <length> = 8.
o <length> = 8。
o The TLV is then EXAMPLE3 16 8 a b c d e f g h (11 octets).
o TLVは例316 8 A B C D E F G H（11オクテット）です。
If, in this example, the number of data octets were 256 or greater, then <tlv-flags> would also have thasextlen set and have value 24. The length would require two octets (most significant first). The TLV length would be 4 + N octets, where N is the number of data octets (it can be 3 + N octets if N is 255 or less).
この例では、オクテットの数が256以上の場合、<tlv-flags>にもthasextlenセットがあり、値24があります。TLVの長さは4 nオクテットで、nはデータオクテットの数です（nが255以下の場合、3 nオクテットになります）。
This informative appendix illustrates the elements that are normatively specified in Section 5.
この有益な付録は、セクション5で規範的に指定されている要素を示しています。
Bits labeled Rsv should be cleared ('0'). Bits labeled M may be cleared ('0') or set ('1').
RSVというラベルの付いたビットはクリアする必要があります（ '0'）。mとラベル付けされたビットは、クリア（ '0'）またはset（ '1'）をクリアできます。
This section illustrates possible options for the <packet> element. These are differentiated by the flags field in the first octet. The packet may include any number (zero or more) of messages. The number of messages is determined from when the packet is exhausted, given the packet length from the network layer.
このセクションでは、<パケット>要素の可能なオプションを示します。これらは、最初のオクテットのフラグフィールドによって区別されます。パケットには、任意の数（ゼロ以上）のメッセージが含まれる場合があります。メッセージの数は、ネットワークレイヤーからのパケットの長さを考慮して、パケットが排出されるときから決定されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0|0|Rsv| |
+-+-+-+-+-+-+-+-+ |
| Message |
| |
| +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|1|0|Rsv| Packet Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message |
| |
| +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0|1|Rsv| |
+-+-+-+-+-+-+-+-+ |
| |
| Packet TLV Block |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+ |
| Message |
| |
| +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|1|1|Rsv| Packet Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Packet TLV Block |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message |
| |
| +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This section illustrates possible options for the <message> element. These are differentiated by their second (flags) octet. The length of the Message Body is determined using the Message Size field, which is the combined length of all the fields shown. The field labeled MAL defines the length of all addresses (including the Originator Address, if present, and all addresses in Address Blocks) in octets, as one more than the value in the field.
このセクションでは、<メッセージ>要素の可能なオプションを示します。これらは、2番目の（フラグ）Octetによって区別されます。メッセージ本文の長さは、メッセージサイズフィールドを使用して決定されます。これは、表示されているすべてのフィールドの長さを組み合わせています。MALというラベルの付いたフィールドは、オクテットのすべてのアドレスの長さ（存在する場合はオリジネーターアドレス、およびアドレスブロック内のすべてのアドレスを含む）を、フィールドの値を超えて定義します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|0|0|0| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |1|0|0|0| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|1|0|0| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | |
+-+-+-+-+-+-+-+-+ |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |1|1|0|0| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | |
+-+-+-+-+-+-+-+-+ |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|0|1|0| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | |
+-+-+-+-+-+-+-+-+ |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |1|0|1|0| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | |
+-+-+-+-+-+-+-+-+ |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|1|1|0| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |1|1|1|0| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|0|0|1| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |1|0|0|1| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|1|0|1| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |1|1|0|1| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|0|1|1| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |1|0|1|1| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|1|1|1| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |1|1|1|1| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This section illustrates the format of a Message Body (the <message> element excluding its initial <msg-header> element). The Message Body includes one Message TLV Block (containing zero or more TLVs) and may include any number (zero or more) of Address Block and Address Block TLV Block pairs.
このセクションでは、メッセージ本文の形式（初期<sg-header>要素を除く<sessage>要素）を示します。メッセージ本文には、1つのメッセージTLVブロック（ゼロ以上のTLVを含む）が含まれており、アドレスブロックとアドレスブロックTLVブロックペアの任意の数（ゼロ以上）を含めることができます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message TLV Block |
| +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Address Block |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+ |
| Address Block TLV Block |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Address Block |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Address Block TLV Block |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This section illustrates possible options for the <addr-block> element. These are differentiated by their second (flags) octet. The number of Mid elements is equal to the number of addresses (except when mid-length is zero, when there are no Mid elements). Where a variable number of prefix length fields is shown, their number is equal to the number of addresses.
このセクションでは、<addr-block>要素の可能なオプションを示します。これらは、2番目の（フラグ）Octetによって区別されます。MID要素の数は、アドレスの数に等しくなります（ミッドレングスがゼロの場合、MID要素がない場合を除く）。変数数のプレフィックス長フィールドが表示される場合、その数はアドレスの数に等しくなります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|0|0|0|0| Rsv | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|0|0|0|0| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|1|0|0|0| Rsv | Tail Length | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail (cont) | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|1|0|0|0| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Tail Length | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|0|1|0|0| Rsv | Tail Length | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | |
+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|0|1|0|0| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Tail Length | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ... :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|0|0|1|0| Rsv | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|0|0|1|0| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|1|0|1|0| Rsv | Tail Length | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail (cont) | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|1|0|1|0| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Tail Length | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|0|1|1|0| Rsv | Tail Length | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | |
+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|0|1|1|0| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Tail Length | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ... :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|0|0|0|1| Rsv | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | Prefix Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|0|0|0|1| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|1|0|0|1| Rsv | Tail Length | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail (cont) | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|1|0|0|1| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Tail Length | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | |
+-+-+-+-+-+-+-+-+ |
: ... :
| +-+-+-+-+-+-+-+-+
| | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|0|1|0|1| Rsv | Tail Length | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | |
+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|0|1|0|1| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Tail Length | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ... :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | Prefix Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This section illustrates the format of a <tlv-block> element. There may be any number (zero or more) of TLVs, with total length of the TLVs (in octets) equal to the Length field.
このセクションでは、<tlv-block>要素の形式を示します。TLVの任意の数（ゼロ以上）があり、TLVの全長（オクテット）が長さフィールドに等しい場合があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| TLV |
| +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| TLV |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This section illustrates possible options for the <tlv> element. These are differentiated by their second (flags) octet. If there are no Index fields, then this may be a Packet TLV, Message TLV, or Address Block TLV; if there are one or two Index fields, then this must be an Address Block TLV. The Length field gives the length of the Value field (in octets).
このセクションでは、<tlv>要素の可能なオプションを示します。これらは、2番目の（フラグ）Octetによって区別されます。インデックスフィールドがない場合、これはパケットTLV、メッセージTLV、またはアドレスブロックTLVである可能性があります。1つまたは2つのインデックスフィールドがある場合、これはアドレスブロックTLVでなければなりません。長さフィールドは、値フィールドの長さ（オクテット内）を与えます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |0|0|0|0|0|0|Rsv|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |1|0|0|0|0|0|Rsv| Type Ext |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |0|1|0|0|0|0|Rsv| Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |1|1|0|0|0|0|Rsv| Type Ext | Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |0|0|1|0|0|0|Rsv| Index Start | Index Stop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |1|0|1|0|0|0|Rsv| Type Ext | Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index Stop |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |0|0|0|1|0|M|Rsv| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |1|0|0|1|0|M|Rsv| Type Ext | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |0|1|0|1|0|0|Rsv| Index Start | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |1|1|0|1|0|0|Rsv| Type Ext | Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | |
+-+-+-+-+-+-+-+-+ |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |0|0|1|1|0|M|Rsv| Index Start | Index Stop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | |
+-+-+-+-+-+-+-+-+ |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |1|0|1|1|0|M|Rsv| Type Ext | Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index Stop | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |0|0|0|0|1|M|Rsv| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |1|0|0|1|1|M|Rsv| Type Ext | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (cont) | |
+-+-+-+-+-+-+-+-+ |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |0|1|0|1|1|0|Rsv| Index Start | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (cont) | |
+-+-+-+-+-+-+-+-+ |
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |1|1|0|1|1|0|Rsv| Type Ext | Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |0|0|1|1|1|M|Rsv| Index Start | Index Stop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |1|0|1|1|1|M|Rsv| Type Ext | Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index Stop | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
The following example packet is included with the intent to exemplify how Packet Headers and Message Headers are constructed, and how addresses and attributes are encoded using Address Blocks and TLV Blocks. This example is specifically not constructed to exhibit maximum message or packet size reduction.
次の例パケットは、パケットヘッダーとメッセージヘッダーの構築方法、およびアドレスブロックとTLVブロックを使用してアドレスと属性をエンコードする方法を例示する目的で含まれています。この例は、最大のメッセージまたはパケットサイズの削減を示すために特に構築されていません。
The Packet Header has the phasseqnum flag of its flags field set (value 8), and hence has a Packet Sequence Number, but no Packet TLV Block.
パケットヘッダーには、フラグフィールドセット（値8）のphasseqnumフラグがあるため、パケットシーケンス番号がありますが、パケットTLVブロックはありません。
The packet contains a single message with length 54 octets. This message has the mhasorig, mhashoplimit, mhashopcount, and mhasseqnum flags of its four-bit flags field set (value 15), and hence includes an Originator Address, a Hop Limit, a Hop Count, and a Message Sequence Number (which is type independent). Its four-bit Message Address Length field has value 3, and hence addresses in the message have length four octets, here being IPv4 addresses. The message has a Message TLV Block with content length 9 octets, containing a single Message TLV. This TLV has the thasvalue flag of its flags octet set (value 16), and hence contains a Value field, with preceding Value Length 6 octets. The message then has two Address Blocks, each with a following Address Block TLV Block.
パケットには、長さ54オクテットの単一のメッセージが含まれています。このメッセージには、4ビットフラグフィールドセット（値15）のMhasorig、Mhashoplimit、MhashopCount、およびMhasseqnumフラグがあり、したがって、オリジネーターアドレス、ホップ制限、ホップカウント、メッセージシーケンス番号（Typeはタイプです。独立）。その4ビットメッセージアドレスの長さフィールドには値3があるため、メッセージのアドレスの長さは4オクテットで、ここではIPv4アドレスです。メッセージには、コンテンツ長9オクテットのメッセージTLVブロックがあり、単一のメッセージTLVが含まれています。このTLVには、フラグのオクテットセットのthasValueフラグがあり（値16）、したがって、値フィールドが含まれ、前の値長6オクテットがあります。メッセージには2つのアドレスブロックがあり、それぞれに次のアドレスブロックTLVブロックがあります。
The first Address Block contains 2 address prefixes. It has the ahaszerotail and ahassingleprelen flags of its flags octet set (value 48), and hence has no Head (head-length is zero octets). It has a tail-length of 2 octets, hence mid-length is two octets. The two Tail octets of each address are not included (since ahaszerotail is set) and have value zero. The Address Block has a single prefix length. The following Address Block TLV Block is empty (content length 0 octets).
最初のアドレスブロックには、2つのアドレスプレフィックスが含まれています。旗のahaszerotailとahaszerotailとahassingleprelenの旗があり、Octetセット（値48）があるため、ヘッドはありません（ヘッドレングスはゼロオクテットです）。テールレングスは2オクテットであるため、中程度の長さは2オクテットです。各アドレスの2つのテールオクテットは含まれていません（Ahaszerotailが設定されているため）、値はゼロです。アドレスブロックには単一のプレフィックス長があります。次のアドレスブロックTLVブロックは空です（コンテンツ長さ0オクテット）。
The second Address Block contains 3 addresses. It has the ahashead flag of its flags octet set (value 128), has head-length 2 octets, and no Tail (tail-length is zero octets); hence, mid-length is two octets. It is followed by an Address Block TLV Block, with content length 9 octets, containing two Address Block TLVs. The first of these TLVs has the thasvalue flag of its flags octet set (value 16), and has a single value of length 2 octets, which applies to all of the addresses in the Address Block. The second of these TLVs has the thasmultiindex flag of its flags octet set (value 32), and hence has no Value Length or Value fields. It has two Index fields (Index Start and Index Stop), which indicate those addresses this TLV applies to (inclusive range, counting from zero).
2番目のアドレスブロックには、3つのアドレスが含まれています。旗のahasheadフラグがあり、オクテットセット（値128）があり、頭の長さ2オクテットがあり、尾はありません（テールレングスはゼロオクテットです）。したがって、中間長は2オクテットです。その後、2つのアドレスブロックTLVを含むコンテンツ長9オクテットを備えたアドレスブロックTLVブロックが続きます。これらのTLVの最初のものには、フラグのオクテットセット（値16）のthasValueフラグがあり、長さ2オクテットの単一値があり、アドレスブロック内のすべてのアドレスに適用されます。これらのTLVの2番目には、フラグのOctetセット（値32）のthasmultiindexフラグがあるため、値の長さまたは値フィールドはありません。2つのインデックスフィールド（インデックス開始とインデックスストップ）があり、このTLVが適用されるアドレス（包括的範囲、ゼロからカウント）を示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0 0| Packet Sequence Number | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 0 0 1 1|0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 0| Orig Addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address (cont) | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | Message Sequence Number |0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0 1| TLV Type |0 0 0 1 0 0 0 0|0 0 0 0 0 1 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (cont) |0 0 0 0 0 0 1 0|0 0 1 1 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 0| Mid | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | Prefix Length |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 1|1 0 0 0 0 0 0 0|0 0 0 0 0 0 1 0| Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Mid | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | Mid |0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0 1| TLV Type |0 0 0 1 0 0 0 0|0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | TLV Type |0 0 1 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index Start | Index Stop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Authors' Addresses
著者のアドレス
Thomas Heide Clausen LIX, Ecole Polytechnique
Thomas Heide Clausen Lix、Ecole Polytechnique
Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org
URI: http://www.thomasclausen.org/
Christopher M. Dearlove BAE Systems ATC
クリストファー・M・ディアローブ・ベイ・システムATC
Phone: +44 1245 242194
EMail: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/
Justin W. Dean Naval Research Laboratory
ジャスティン・W・ディーン海軍研究所
Phone: +1 202 767 3397
EMail: jdean@itd.nrl.navy.mil
URI: http://pf.itd.nrl.navy.mil/
Cedric Adjih INRIA Rocquencourt
セドリックアジハインリアロックエンクール
Phone: +33 1 3963 5215
EMail: Cedric.Adjih@inria.fr
URI: http://menetou.inria.fr/~adjih/