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
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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/ライセンス情報）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD"、 "ないもの"、 "推奨" "ない（SHOULD NOT）"、 "MAY"、 "推奨NOT"、および「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].
この形式は、すべてのフィールドにネットワークバイト順（最上位オクテット）を使用しています。オクテットの最上位ビットはビット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
この仕様は、要素を定義します。要素は、一緒に構文エンティティ表記<要素>を使用して表さ形成する連続ビットの任意の数のグループです。ビットの具体的なサイズフィールドOまたはこの文書の各要素は、いずれかとして定義されています
o a composite element, composed of other <element>s.
複合素子O、他の<要素> Sから成ります。
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:
ここで、右次側：=、仕様は[SingleUNIX]で定義された正規表現構文を使用して表されています。のみ、次の表記が使用されます。
<element1><element2> - Indicates that <element1> is immediately followed by <element2>.
<要素1> <エレメント2> - <要素1>は、すぐに<要素2>が続いていることを示します。
(<element1><element2>) - Indicates a grouping of the elements enclosed by the parentheses.
（<エレメント1> <エレメント2>） - 括弧で囲まれている要素のグループ化を示します。
? - Zero or one occurrences of the preceding element or group.
？ - 先行する要素またはグループの0または1の出現。
* - Zero or more occurrences of the preceding element or group.
* - 直前の要素またはグループの0回以上の繰り返し。
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).
バー - 変数は、通常素子（S）の値（S）に基づいた計算により得られました。
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.
パケット - 本明細書のトップレベル・エンティティ。パケットは、パケットヘッダと0個以上のメッセージが含まれています。
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アドレスの場合、IPv4アドレスは[RFC4291]で指定されるようにIPv4マップ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ルータ間のシグナリングMANETルーティングプロトコルを運ぶように設計されています。この仕様は、マルチホップネットワークにおけるMANETルーティングプロトコルシグナリングのポイントツーポイント配信のために利用可能であるとしても、範囲が制限されたフラッディングをサポートすることができる要素を含みます。パケットは、ユニキャストまたはマルチキャストであってもよく、任意の適切なトランスポートプロトコルまたはnoneを使用してもよいです。
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ヘッダは>によって定義されます。
<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.
<version>は4ビットの符号なし整数フィールドであり、パケットと含まれるメッセージが構築されている仕様のバージョンを指定します。このドキュメントでは、バージョン0を指定します。
<pkt-flags> is a 4-bit field, specifying the interpretation of the remainder of the Packet Header:
<PKT-フラグ>パケットヘッダの残りの部分の解釈を指定する、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）：（ '0'）がクリアならば、<PKT-SEQ-NUM>が<PKTヘッダ>に含まれていません。 （ '1'）に設定した場合、その後は、<PKT-SEQ-NUM> <PKTヘッダ>に含まれています。
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'）がクリアならば、<TLVブロック>は、<PKTヘッダ>に含まれていません。 （「1」）に設定した場合、<TLVブロック>は、<PKTヘッダ>に含まれています。
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.
<PKT-SEQ-NUM> phasseqnumフラグが（ '0'）がクリアされている場合は省略されています。そうでない場合、パケットシーケンス番号を指定する16ビット符号なし整数フィールドです。
<tlv-block> is omitted if the phastlv flag is cleared ('0') and is otherwise as defined in Section 5.4.
<TLVブロック> 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.
全体のメッセージに関連付けられたゼロ個以上のTLVを含むメッセージTLVブロックO。
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>?
<MSG-ヘッダ>：= <MSG型> <MSG-フラグ> <MSG-ADDR-長> <MSGサイズ> <MSG-ORIG-ADDR>？ <MSG-ホップリミット>？ <MSG-ホップカウント>？ <MSG-seqの-num>は？
where:
どこ：
<tlv-block> is as defined in Section 5.4.
<TLVブロック>セクション5.4で定義される通りです。
<addr-block> is as defined in Section 5.3.
<ADDRブロック>セクション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:
<MSG-フラグ>メッセージヘッダーの残りの部分の解釈を指定する、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'）がクリアならば、<MSG-ORIG-ADDR>は、<MSG-ヘッダ>に含まれていません。 （ '1'）に設定した場合、<MSG-ORIG-ADDR> <MSG-ヘッダ>に含まれています。
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'）がクリアならば、<MSGホップリミット>が<MSG-ヘッダ>に含まれていません。 （ '1'）に設定した場合、<MSGホップリミット> <MSG-ヘッダ>に含まれています。
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）：（ '0'）がクリアならば、<MSGのホップカウント>は、<MSG-ヘッダ>に含まれていません。 （ '1'）に設定した場合、<MSGのホップカウント> <MSG-ヘッダ>に含まれています。
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'）がクリアならば、<MSG-SEQ-NUM>が<MSG-ヘッダ>に含まれていません。 （ '1'）に設定した場合、その後は、<MSG-SEQ-NUM> <MSG-ヘッダ>に含まれています。
<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-長さ>は、4ビットの符号なし整数フィールドであり、すべてのアドレスの長さを符号化すると、このメッセージに含まれている（<MSG-ORIG-ADDR>並びにセクション5.3で定義されるように各アドレスは、アドレスブロックに含まれます）、次のように：
<msg-addr-length> = the length of an address in octets - 1
<MSG-ADDR-長さ> =オクテットのアドレスの長さ - 1
<msg-addr-length> is thus 3 for IPv4 addresses, or 15 for IPv6 addresses.
<MSG-ADDR-長>こうして3 IPv4アドレスのための、または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-ADDR-長> + 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-サイズが> <MSG-ヘッダ>を含む<メッセージ>を構成するオクテットの数を指定する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.
mhasorigフラグがクリアされた場合、<MSG-ORIG-ADDR>（ '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.
mhashoplimitフラグがクリアされた場合、<MSGホップリミット>省略されている（「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ホップカウント>省略されている（「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.
アドレスブロックを含むメッセージの<MSG-ヘッダ>で<MSG-ADDR-長さ>を使用して、指定されたように、アドレスブロックは、アドレス長のオクテット長であろうすべてが1つ以上のアドレスを指定することができます。アドレスブロックは、適切な場合には、アドレスブロック内のすべてのアドレスに適用することができ、プレフィックス長を指定することができます。これは、アドレスブロックは、アドレスまたはアドレスプレフィックスのいずれかを指定することができます。プロトコルは、このようにアドレスブロックを含有することができ、（ビットのアドレスの長さに等しい、すなわち、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アドレス）を有するアドレスの集合を可能にするのみです。アドレスブロックはすべて同じヘッド、同じテールを共有するが、個々の中音域を持つアドレスの順序付きセットが含まれています。独立して、頭と尾は、共通のヘッドや、共通の尾を持っていないアドレスオブジェクトの表現を可能にし、空でもよいです。アドレスブロックの詳細な例は、付録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-フラグ>は、アドレスブロックの残りの部分の解釈を指定する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」）、その後<ヘッドの長さ>と<ヘッド> <アドレスブロック>に含まれていません。 （「1」）に設定した場合、<HEAD長>は、<アドレスブロック>に含まれており、<HEAD>は、<アドレスブロック>に含まれる<HEAD長>ない限りゼロです。
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
<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.
<ヘッド長>存在する場合、アドレスブロック内のアドレスのすべてのヘッドのオクテットの数を含んで8ビットの符号なし整数フィールドであり、すなわち、それぞれ、<head>要素が含まれる<HEAD長>オクテット長いです。
head-length is a variable, defined to equal <head-length>, if present, or 0 otherwise.
ヘッド長は、そうでなければ同じ<ヘッド長>に定義された変数は、存在する場合、または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.
ヘッド長さが0に等しい場合、<HEAD>が省略されています。それ以外の場合は、アドレスブロック内のすべてのアドレスに共通のヘッド長左端のオクテットのフィールドです。
<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です。
<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.
<尾> ahaszerotailフラグが設定されている場合、テール長が0に等しい場合、または省略されている（「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> 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.
<中間>中間長さが0に等しい場合、省略されています。そうでない場合、各<中間>アドレスブロックに対応するアドレスの中間を示す、長さの中間長さオクテットのフィールドです。省略しない場合は、アドレスブロックは正確に<NUM-addrに> <中期>フィールドが含まれています。
<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.
<プレフィックス長>はアドレスプレフィックスのビットの長さを含む8ビット符号なし整数フィールドです。 ahassingleprelenフラグが設定されている場合（「1」）、単一<プレフィックス長>フィールドは、アドレスブロック内のすべてのアドレスのプレフィックス長が含まれて含まれています。 ahasmultiprelenフラグが設定されている場合（「1」）、次に<NUM-ADDR> <プレフィックス長>フィールドが（同じ順序で）アドレスブロックに対応するアドレスプレフィックスのプレフィックス長が含まれているそれぞれが、含まれています。そうでない場合は、<プレフィックス長>フィールドが存在しません。各アドレスオブジェクトは、8×アドレス長のビットに等しいプレフィックス長を有すると考えることができます。任意の<プレフィックス長>要素がより大きい値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。複数のアドレスを持つ属性を関連付ける場合は、TLVはすべてのアドレスに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).
<TLVの長さは、>直後<TLV>要素のすべてのオクテットの総数（<TLVの長>含まれていない）を含んでいる16ビットの符号なし整数のフィールドです。
<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>によって表されるTLVの3種類、それぞれがあります。
o A Packet TLV, included in the Packet TLV Block in a Packet Header.
パケットTLV O、パケットヘッダー内のパケットTLVブロックに含まれます。
o A Message TLV, included in the Message TLV Block in a message, before any Address Blocks.
メッセージTLV O、任意のアドレスブロックの前に、メッセージにメッセージ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
*すべてのアドレスは、アドレスブロック内のオブジェクト、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型>種別TLVに特定TLVのタイプを指定する8ビット符号なし整数フィールドである（すなわち、パケットTLV、メッセージTLV、またはアドレスブロックTLV）。
<tlv-flags> is an 8-bit field specifying the interpretation of the remainder of the TLV:
<TLV-フラグが> 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型-EXT>が<TLV>に含まれていません。 （ '1'）に設定した場合、<TLV型-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）：このフラグは、以下に規定のように<値>フィールドは、どのように解釈されるかを指定するのに役立ちます。このフラグはthasmultiindexフラグが（「0」）がクリアされた場合、パケットのTLVおよびメッセージのTLVに（「0」）がクリアされなければならない、又はthasvalueフラグがクリアされた場合（「0」）。
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
+-----------+------------+--------------+---------------------------+
| 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型-extは>種類TLVタイプに特定及びTLVタイプの拡張子を指定する8ビット符号なし整数フィールドである（すなわち、パケットTLV、メッセージTLV、またはアドレスブロックTLV）。
tlv-type-ext is a variable, defined to equal <tlv-type-ext>, if present, or 0 otherwise.
TLVタイプ-EXTは、存在する場合に等しい<TLV型-EXT>に定義された変数は、であるか、またはそうでなければ0。
tlv-fulltype is a variable, defined by:
TLV-fulltypeは、によって定義された変数、次のとおりです。
tlv-fulltype := 256 * <tlv-type> + tlv-type-ext
TLV-fulltype：= 256 * <TLVタイプ> + TLV型-EXT
<index-start> and <index-stop> when present, in an Address Block TLV only, are each an 8-bit unsigned integer field.
<インデックススタート>と<インデックスストップ>存在する場合、アドレスブロック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
エンドインデックス：= 0
* For Address Block TLVs:
*アドレスブロックのTLVの場合：
end-index := <num-addr> - 1
エンドインデックス：= <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は、第1のアドレスオブジェクトが位置ゼロを有するアドレスブロックに位置指標ストップ（含む）に位置インデックス開始からアドレスオブジェクトに適用されます。
+-----------------+----------------+----------------+---------------+
| 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
number-values is a variable, defined by:
数値によって定義された、可変です。
number-values := index-stop - index-start + 1
数値：=索引ストップ - インデックススタート+ 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>は省略またはtismultivalueフラグが設定されている場合は、表4によれば、8ビットまたは16ビットの符号なし整数フィールド（「1」）、その後<長さ>数値の整数倍である必要があり、され可変シングル長さによって定義されます。
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.
<値>存在する場合は（表4参照）、長さ<length>をオクテットのフィールドです。アドレスブロックTLVでは、<値>を含め、インデックス停止する位置インデックス開始からアドレスオブジェクトに関連付けられています。 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.
メッセージタイプ、パケットTLVタイプ、メッセージTLVタイプ、およびブロックTLVタイプのアドレス：この文書では、登録された4つの名前空間を紹介しています。このセクションでは、これらの名前空間のための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:
専門家レビューが必要とされる登録要求の場合は、指定Expertは考慮し、以下の一般的な推奨事項を取る必要があります：
o The purpose of these registries is to support Standard and Experimental MANET routing and related protocols and extensions to these protocols.
Oこれらのレジストリの目的は、これらのプロトコルに標準および実験MANETのルーティングおよび関連プロトコルおよび拡張をサポートすることです。
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.
RFCが公開される予定であることが明らかに思える一度O 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指定Expertは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.
30日間の期間が経過する前に、O、指定Expertは承認または登録要求を拒否し、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つのレジストリの作成を意味します。メッセージタイプの登録を要求する文書は、これらのメッセージタイプに固有のTLVタイプは、[BCP26]のいずれかのオプション、および任意の初期配分から、割り振られる方法を指定する必要があります。指定エキスパートは、メッセージタイプの割り当て要求の見直しに考慮にこれらのレジストリに指定した割り当てポリシーを取る必要があります。
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タイプの値を割り当てることができます。 0〜127の範囲で登録可能な場合には、既存のグローバルTLVの定義とモジュラーグローバル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レジストリを作成する文書は、メッセージタイプ固有TLVタイプは[BCP26]のものの中から、割り当てされるメカニズムを指定しなければなりません。
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.
表9で指定されたメッセージTLVタイプ128から223には、新しいレジストリは、メッセージタイプの登録で作成されたメッセージタイプに固有のメッセージの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.
表10に指定されているメッセージの種類に依存しないアドレスブロックTLVタイプのための新しいレジストリは、初期割り当てと割り当てポリシーで、作成されています。
+---------+-----------------------+------------------------+
| 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.
表11に指定されているブロックTLVタイプ128から223には、新しいレジストリは、メッセージタイプの登録で作成されたメッセージタイプに固有のアドレスブロックの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メッセージは、プロトコル情報とMAYのキャリアであるように設計されている各ホップで、この仕様を使用してプロトコルによって転送及び/又は処理されます。
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パケットが単一送信で単一の論理ホップにわたって隣接MANETルータ間のメッセージの数を運ぶように設計されています。
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.
メッセージが転送MANETルータによって不変で転送されたメッセージについてはOが、エンドツーエンドの認証と完全性は、メッセージに暗号署名を含む適切なメッセージTLVを含むことにより、既存のセキュリティアソシエーションとMANETルータ間、実施されてもよいです。そのようなメッセージは、このように転送されるとき、<MSGのホップカウント>と<MSGホップリミット>以降に変更されなければならない唯一のフィールドは、この署名は、メッセージヘッダを含むメッセージ全体に基づいて計算することができるされています存在する場合、<MSG-ホップ数>と<MSG-ホップリミット>とフィールドは、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を含むことにより、既存のセキュリティアソシエーションとMANETルータ間、実施されてもよいです。送信されたように、パケットが受信されているので、この署名は、パケット全体またはそのような適切な部分に基づいて計算することができます。
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（NOメッセージで）のみパケットヘッダからなり、パケットTLVタイプは、その値フィールドが1つまたは複数の暗号化されたメッセージが含まれていることを示しパケットTLVを含むパケット、。このパケット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.
のみメッセージヘッダとメッセージTLVタイプは、その値フィールドは、メッセージの残りのメッセージのTLV、アドレスブロックの暗号化されたバージョンが含まれていることを示し、ブロックTLVをアドレス単一メッセージTLVからなるメッセージは、O。このメッセージ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セドリックAdjih、INRIA、フランス、<Cedric.Adjih@inria.fr>
o Emmanuel Baccelli, INRIA, France, <Emmanuel.Baccelli@inria.fr>
またはエマニュエルBaccelli、INRIA、フランス、<Emmanuel.Baccelli@inria.fr>
o Thomas Heide Clausen, LIX, Ecole Polytechnique, France, <T.Clausen@computer.org>
Oトーマス・ハイデクラウゼン、LIX、エコール・ポリテクニック、フランス、<T.Clausen@computer.org>
o Justin W. Dean, NRL, USA, <jdean@itd.nrl.navy.mil>
Oジャスティン・W.・ディーン、NRL、USA、<jdean@itd.nrl.navy.mil>
o Christopher Dearlove, BAE Systems, UK, <chris.dearlove@baesystems.com>
OクリストファーDearlove、BAEシステムズ、英国、<chris.dearlove@baesystems.com>
o Satoh Hiroki, Hitachi SDL, Japan, <hiroki.satoh.yj@hitachi.com>
お さとｈ ひろき、 ひたち ＳＤＬ、 じゃぱん、 ＜ひろき。さとｈ。ｙｊ＠ひたち。こｍ＞
o Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr>
Oフィリップジャケ、INRIA、フランス、<Philippe.Jacquet@inria.fr>
o Monden Kazuya, Hitachi SDL, Japan, <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.
著者は、アニスLaouiti（INT、フランス）、パスカルMINET、ローランViennot（INRIAの両方で、フランス）、及びアミール・ケイアム（工学教育研究センター、パキスタン）用を含め、OLSR [RFC3626]の後ろにチームを承認したいと思います彼らの貢献。エルウィン・デイヴィス（フォリーコンサルティング、UK）、ラースEggertの（ノキア、フィンランド）、クリス・ニューマン（サン・マイクロシステムズ、米国）、ティム・ポーク（NIST、USA）、およびマグヌスウェスター（エリクソン、スウェーデン）のすべてに提供する詳細なレビューと洞察に満ちたコメント。
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)
作者は感謝して強烈な技術的な議論、早期のレビュー、および仕様とそのコンポーネント（アルファベット順にリストされている）上のコメントを以下の方々に感謝します：ブライアン・アダムソン（NRL）O
o Teco Boot (Infinity Networks)
Oテコブート（インフィニティ・ネットワーク）
o Florent Brunneau (LIX)
OフロランBrunneau（LIX）
o Ian Chakeres (CenGen)
お いあん ちゃけれｓ （せんげん）
o Alan Cullen (BAE Systems)
Oアラン・カレン（BAEシステムズ）
o Ulrich Herberg (LIX)
OウルリッヒHerberg（LIX）
o Joe Macker (NRL)
OジョーMacker（NRL）
o Yasunori Owada (Niigata University)
お やすのり おわだ （にいがた うにゔぇｒしｔｙ）
o Charlie E. Perkins (WiChorus)
OチャーリーE.パーキンス（WiChorus）
o Henning Rogge (FGAN)
ヘニングロゲ（FGAN）O
o Andreas Schjonhaug (LIX)
OアンドレアスSchjonhaug（LIX）
and the entire IETF MANET working group.
全体IETF MANETワーキンググループ。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.デアリング、 "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標準1003.1、オープングループ、およびISO / IEC JTC 1 / SC22 / WG15、 "単一UNIX仕様、バージョン3、2004版"、2004年4月。
[RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State Routing Protocol", RFC 3626, October 2003.
[RFC3626]クラウゼン、T.およびP.ジャケ、 "最適化されたリンクステートルーティングプロトコル"、RFC 3626、2003年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[Stevens] Stevens, W., "TCP/IP Illustrated Volume 1 - The Protocols", 1994.
[スティーブンス]スティーブンス、W.、 "TCP / IPイラスト1巻 - プロトコル"、1994年。
Appendix A. Multiplexing and Demultiplexing
付録A.多重・分離
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.
特に断りのない限り、そのメッセージタイプのIANA予約を行う1 - - 各メッセージ・タイプ、プロトコルのOは、そのメッセージタイプの「所有者」として指定されなければなりません。
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.
パケットTLVブロックを含むパケットヘッダフィールド、O、そのプロトコルインスタンスに使用するためのそのような情報を利用可能にし得る、多重分離プロセスで使用されます。
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.
<PKT-SEQ-NUM>フィールドO、存在する場合、ノードによって生成された各パケットについて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.
2つのプロトコルの両方が同じメッセージタイプを使用する場合は、O、次いで、この相互作用は、そのメッセージ・タイプの指定された所有者であるプロトコルによって指定されるべきです。
Appendix B. Intended Usage
付録B.使用目的
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ルータ間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つ以上の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フィールドが、存在する場合、与えられたタイプの最初のメッセージが発信ノードによって生成されたときに0から始まるシーケンス番号を含む<MSG-SEQ-NUM>、そしてそれは、そのタイプの生成された各メッセージのために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.
<MSG-ORIG-ADDR>および<MSG-SEQ-NUM>フィールドが両方とも存在する場合、O、メッセージヘッダ、メッセージの<MSG-ORIG-ADDR>からなる識別子、<msg-を使用して、重複した抑制を提供しますSEQ-NUM>、および<MSG型>。これらは、一意の時間内MANETにおけるメッセージを識別するために、<MSG-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ホップリミット>フィールドは、存在する場合、パケットはMANETルータによって破棄される前に移動させたホップの数を含んでいます。 <MSGホップリミット>メッセージ発信者によって設定され、無限MANET内を循環からのメッセージを防止するために使用されます。メッセージを転送するとき、MANETルータは1 <MSGのホップリミット>を減らす必要があり、<MSGホップリミット> 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-ホップカウント>フィールド、存在する場合、パケットはMANET全体で走行した上でホップ数が含まれています。 <MSGのホップカウント>メッセージ発信者によって0に設定され、無限MANET内を循環からのメッセージを防止するために使用されます。メッセージを転送するとき、MANETルータは1 <MSGのホップカウント>を増やす必要があり、<MSGホップカウントが> 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 <MSGホップリミット>と<MSGのホップカウント>フィールドが両方とも存在する場合、メッセージヘッダは、スコープ制限フラッディングの転送決定を行うために情報を提供します。これは、この仕様を使用して、プロトコルによって指定された任意の適切なフラッディングメカニズムによるものであってもよいです。
Appendix C. Examples
付録C.例
This appendix contains some examples of parts of this specification.
この付録では、この仕様の部品のいくつかの例が含まれています。
C.1. Address Block Examples
C.1。アドレスブロックの例
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、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」）ahasheadとフラグahasfulltailがクリアされた特定の一つに、あまり効率的な表現を使用することが許容されることに注意し、ひいてはヘッド長= 0、テール長さ= 0、中間長= ADDRESS- （NOアドレスプレフィックスを有する）長さ、およびアドレスブロックはアドレスの数、値0、および非凝集アドレスのリストを<ADDR-フラグ>で構成されています。これは、単一のアドレスを表現するための最も効率的な方法、および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);
* <ADDR-フラグ> ahashead（値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 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);
* <ADDR-フラグ>セット（値64）ahasfulltail有します。
* <head-length> and <head> are omitted.
* <ヘッドの長さ>と<ヘッド>が省略されています。
The Address Block is then 2 64 1 g a b c d e f (10 octets).
アドレスブロックは、B C D EがF（10オクテット）、次いで2 64 1グラムです。
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は、フラグ> ahasheadとセット（値192）ahasfulltailました。
The Address Block is then 2 192 1 a 2 d e b c (9 octets).
アドレスブロックは2 192 1 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);
* <ADDR-フラグ> ahasheadとセット（値160）ahaszerotailました。
* <tail> is omitted.
* <尾>が省略されています。
The Address Block is then 3 160 1 a 2 b c d (8 octets).
アドレスブロックは2 BはD =（8つのオクテット）を3 160 1です。
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);
* <ADDR-フラグ>セット（値32）ahaszerotail有します。
* <head> and <tail> are omitted.
* <head>と<尾>が省略されています。
The Address Block is then 2 32 2 a b c d (7 octets).
アドレスブロックは2 32 2の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);
* <ADDR-フラグ> ahaszerotailあり、（値48）に設定ahassingleprelen。
* <head> and <tail> are omitted.
* <head>と<尾>が省略されています。
The Address Block is then 2 48 2 a b c d n (8 octets).
アドレスブロックは2 48 2 B、CのD nを（8つのオクテット）です。
o To include a.b.0.0/n and c.d.0.0/m:
a.b.0.0 / nおよびc.d.0.0 / Mを含むように、O：
* head-length = 0;
*ヘッド長= 0。
* tail-length = 2;
*テイル長= 2。
* mid-length = 2;
*半ば長= 2;
* <addr-flags> has ahaszerotail and ahasmultiprelen set (value 40);
* <ADDR-フラグ> ahaszerotailあり、（値40）に設定ahasmultiprelen。
* <head> and <tail> are omitted.
* <head>と<尾>が省略されています。
The Address Block is then 2 40 2 a b c d n m (9 octets).
アドレスブロックは2 40 2 bはC D N M（9つのオクテット）です。
C.2. TLV Examples
C.2。 TLV例
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の定義を想定します。 、値B、及びCはCを省略することができるデフォルト値である前回のアドレスブロック内の4つのアドレスに関連付けることができる多くの方法があります。
Examples:
例：
o Using one multivalue TLV to cover all of the addresses:
アドレスのすべてをカバーするために1多値TLVを使用して、O：
* <tlv-flags> has thasvalue and tismultivalue set (value 20);
* <TLV-フラグ> thasvalueとtismultivalueセット（値20）を有しています。
* <index-start> and <index-stop> are omitted;
* <インデックス開始>と<インデックスストップ>が省略されています。
* <length> = 4 (single-length = 1).
* <長さ> = 4（シングル長さ= 1）。
* The TLV is then EXAMPLE1 20 4 a a b c (7 octets).
* TLVは次にEXAMPLE1 20 4のB C（7つのオクテット）です。
o Using one multivalue TLV and omitting the last address:
1つの多値TLVを使用して、最後のアドレスを省略し、O：
* <tlv-flags> has thasmultiindex, thasvalue, and tismultivalue set (value 52);
* <TLV-フラグ> thasmultiindex、thasvalue、及びtismultivalueセット（値52）を有しています。
* <index-start> = 0;
* <インデックススタート> = 0;
* <index-stop> = 2;
* <インデックスストップ> = 2。
* <length> = 3 (single-length = 1).
* <長さ> = 3（シングル長さ= 1）。
* The TLV is then EXAMPLE1 52 0 2 3 a a b (8 octets).
* TLVは次にEXAMPLE1 52 0 2 3 B（8つのオクテット）です。
o Using two single value TLVs and omitting the last address. First:
2つの値のTLVを使用して、最後のアドレスを省略し、O。最初：
* <tlv-flags> has thasmultiindex and thasvalue set (value 48);
* <TLV-フラグ> thasmultiindexとthasvalueセット（値48）を有しています。
* <index-start> = 0;
* <インデックススタート> = 0;
* <index-stop> = 1;
* <インデックスストップ> = 1。
* <length> = 1;
* <長さ> = 1。
* <value> = a.
* <値> = A。
* The TLV is then EXAMPLE1 48 0 1 1 a (6 octets).
* TLVは次にEXAMPLE1 48 0 1 1（6つのオクテット）です。
Second:
第二：
* <tlv-flags> has thassingleindex and thasvalue set (value 80);
* <TLV-フラグ> thassingleindexとthasvalueセット（値80）を有しています。
* <index-start> = 2;
* <インデックススタート> = 2;
* <index-stop> is omitted;
* <インデックスストップ>が省略されています。
* <length> = 1;
* <長さ> = 1。
* <value> = b.
* <値> = B。
* The TLV is then EXAMPLE1 80 2 1 b (5 octets).
* TLV 2件の1 B（5つのオクテット）をEXAMPLE1 80です。
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-フラグ> thasmultiindexセット（値32）を有しています。
o <index-start> = 1;
O <インデックススタート> = 1。
o <index-stop> = 2;
O <インデックスストップ> = 2。
o <length> and <value> are omitted.
O <長さ>と<値>省略されています。
o The TLV is then EXAMPLE2 32 1 2 (4 octets).
O TLVは次にEXAMPLE2 32 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):
任意の長さの値フィールドを取ることができるタイプ例3とメッセージTLV（無型エクステンション）の定義を想定します。データの8つのオクテット（H）を有するようなTLVのために：
o <tlv-flags> has thasvalue set (value 16);
O <TLV-フラグ> thasvalueセット（値16）を有しています。
o <index-start> and <index-stop> are omitted;
O <インデックス開始>と<インデックスストップ>が省略されています。
o <length> = 8.
O <長さ> = 8。
o The TLV is then EXAMPLE3 16 8 a b c d e f g h (11 octets).
O TLVは、例3 16 8 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-フラグ>また、（最上位）の長さは2つのオクテットを必要とする設定thasextlen値24を有しているであろう。 TLVの長さNはデータオクテットの数である4つの+ Nオクテットであろう（Nは255以下である場合には、3つの+ Nオクテットであることができます）。
Appendix D. Illustrations
付録D.イラスト
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'）がクリアまたは（ '1'）に設定することができます。
D.1. Packet
D.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 |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D.2. Message
D.2。メッセージ
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.
このセクションでは、<メッセージ>要素のための可能なオプションを示しています。これらは、その第二（旗）オクテットによって区別されています。メッセージ本文の長さが示され、すべてのフィールドを結合した長さであるメッセージサイズフィールドを使用して決定されます。 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 |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D.3. Message Body
D.3。メッセージ本文
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.
このセクションでは、メッセージ本文（当初<MSG-ヘッダ>要素を除く<メッセージ>要素）のフォーマットを示します。メッセージ本文は、一つのメッセージ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 |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D.4. Address Block
D.4。アドレスブロック
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ブロック>要素のための可能なオプションを示します。これらは、その第二（旗）オクテットによって区別されています。中間要素の数は、（中間の長さが全く中間要素が存在しない場合、ゼロである場合を除く）アドレスの数に等しいです。プレフィックス長フィールドの可変数が示されている場合、その数は、アドレスの数に等しいです。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D.5. TLV Block
D.5。 TLVブロック
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ブロック>要素のフォーマットを示す図です。長さフィールドに等しい（オクテットで）の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 |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D.6. TLV
D.6。 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>要素のための可能なオプションを示しています。これらは、その第二（旗）オクテットによって区別されています。何のインデックスフィールドが存在しない場合、これは、パケット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 |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
Appendix E. Complete Example
付録E.完全な例
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
パケットは、長さが54個のオクテットを持つ単一のメッセージが含まれています。このメッセージはmhasorig、mhashoplimit、mhashopcount、その4ビットフラグフィールドセットのmhasseqnumフラグ（値15）を有し、従って発信元アドレス、ホップリミット、ホップカウント、およびメッセージシーケンス番号（タイプが含まれ独立しました）。その4ビットのメッセージアドレス長フィールドは値3を有し、したがって、メッセージに対処し、ここでのIPv4アドレスであること、長さ4つのオクテットを持っています。メッセージは、単一を含むコンテンツ長さ9つのオクテットとメッセージTLVブロックを有しています
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.
メッセージTLV。このTLVは、そのフラグオクテットセット（値16）のthasvalueフラグを有し、従って値の長さを6つのオクテットを先行して、値フィールドを含みます。メッセージは、その後、次のアドレスブロックTLVブロックと2つのアドレスブロック、それぞれを有しています。
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そのフラグオクテットセット（値48）のahassingleprelenフラグを有し、したがって（ヘッド長さがゼロのオクテットで）はヘッドを有していません。それは、したがって半ばの長さは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つのアドレスが含まれています。これは、そのフラグオクテットセット（値128）のahasheadフラグを有している（テール長はゼロオクテットで）ヘッド長の2つのオクテット、及び無テールを有します。したがって、半ば長さは2つのオクテットです。これは、2つのアドレスブロックTLVを含む、コンテンツの長さ9つのオクテットと、アドレスブロックTLVブロックが続きます。これらのTLVの最初のは、そのフラグオクテットセット（値16）のthasvalueフラグを有し、アドレスブロック内のアドレスのすべてに適用される長さ2オクテットの単一値を有します。これらのTLVの第二は、そのフラグオクテットセット（値32）のthasmultiindexフラグを有し、それゆえ値なしの長さまたは値フィールドを有していません。それは、このTLVは（ゼロから数え包含範囲）に適用されるこれらのアドレスを示す2つのインデックスフィールド（インデックススタートとインデックスストップ）を、持っています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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
トーマス・ハイデクラウゼンLIX、エコールポリテクニック
Phone: +33 6 6058 9349 EMail: T.Clausen@computer.org URI: http://www.thomasclausen.org/
電話：+33 6 6058 9349 Eメール：T.Clausen@computer.org URI：http://www.thomasclausen.org/
Christopher M. Dearlove BAE Systems ATC
クリストファー・M. Dearlove BAEシステムズATC
Phone: +44 1245 242194 EMail: chris.dearlove@baesystems.com URI: http://www.baesystems.com/
電話：+44 1245 242194 Eメール：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/
電話：+1 202 767 3397 Eメール：URI jdean@itd.nrl.navy.mil：http://pf.itd.nrl.navy.mil/
Cedric Adjih INRIA Rocquencourt
セドリックAdjih INRIA Rocquencourt
Phone: +33 1 3963 5215 EMail: Cedric.Adjih@inria.fr URI: http://menetou.inria.fr/~adjih/
電話：+33 1 3963 5215 Eメール：Cedric.Adjih@inria.fr URI：http://menetou.inria.fr/~adjih/