[要約] RFC 8245は、RFC 5444の一般化されたパケット/メッセージ形式を使用してプロトコルを設計するためのルールを提供しています。その目的は、異なるネットワーク環境でのプロトコルの相互運用性を向上させることです。
Internet Engineering Task Force (IETF) T. Clausen
Request for Comments: 8245 Ecole Polytechnique
Updates: 5444 C. Dearlove
Category: Standards Track BAE Systems
ISSN: 2070-1721 U. Herberg
H. Rogge Fraunhofer FKIE October 2017
H.ロッジフラウンホーファーFKIE 2017年10月
Rules for Designing Protocols Using the Generalized Packet/Message Format from RFC 5444
RFC 5444の一般化されたパケット/メッセージ形式を使用してプロトコルを設計するためのルール
Abstract
概要
RFC 5444 specifies a generalized Mobile Ad Hoc Network (MANET) packet/message format and describes an intended use for multiplexed MANET routing protocol messages; this use is mandated by RFC 5498 when using the MANET port or protocol number that it specifies. This document updates RFC 5444 by providing rules and recommendations for how the multiplexer operates and how protocols can use the packet/message format. In particular, the mandatory rules prohibit a number of uses that have been suggested in various proposals and that would have led to interoperability problems, to the impediment of protocol extension development, and/or to an inability to use optional generic parsers.
RFC 5444は、一般化されたモバイルアドホックネットワーク（MANET）パケット/メッセージフォーマットを指定し、多重化されたMANETルーティングプロトコルメッセージの使用目的について説明しています。指定するMANETポートまたはプロトコル番号を使用する場合、この使用はRFC 5498で義務付けられています。このドキュメントは、マルチプレクサがどのように動作し、プロトコルがパケット/メッセージ形式を使用できるかについてのルールと推奨事項を提供することにより、RFC 5444を更新します。特に、必須の規則は、さまざまな提案で提案されており、相互運用性の問題、プロトコル拡張の開発の妨げ、および/またはオプションの汎用パーサーの使用不能につながる、いくつかの使用を禁止しています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8245.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8245で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. History and Purpose ........................................4
1.2. Features of RFC 5444 .......................................4
1.2.1. Packet/Message Format ...............................5
1.2.2. Multiplexing and Demultiplexing .....................7
1.3. Status of This Document ....................................8
2. Terminology .....................................................8
3. Applicability Statement .........................................9
4. Information Transmission ........................................9
4.1. Where to Record Information ................................9
4.2. Message and TLV Type Allocation ...........................10
4.3. Message Recognition .......................................11
4.4. Message Multiplexing and Packets ..........................11
4.4.1. Packet Transmission ................................12
4.4.2. Packet Reception ...................................13
4.5. Messages, Addresses, and Attributes .......................15
4.6. Addresses Require Attributes ..............................16
4.7. TLVs ......................................................18
4.8. Message Integrity .........................................19
5. Structure ......................................................19
6. Message Efficiency .............................................20
6.1. Address Block Compression .................................21
6.2. TLVs ......................................................22
6.3. TLV Values ................................................23
7. Security Considerations ........................................24
8. IANA Considerations ............................................24
9. References .....................................................25
9.1. Normative References ......................................25
9.2. Informative References ....................................25
Appendix A. Information Representation ............................27
Appendix B. Automation ............................................28
Acknowledgments ...................................................28
Authors' Addresses ................................................29
[RFC5444] specifies a generalized packet/message format that is designed for use by MANET routing protocols.
[RFC5444]は、MANETルーティングプロトコルで使用するために設計された一般化されたパケット/メッセージフォーマットを指定します。
[RFC5444] was designed following experiences with [RFC3626], which attempted to provide a packet/message format accommodating diverse protocol extensions but did not fully succeed. [RFC5444] was designed as a common building block for use by both proactive and reactive MANET routing protocols.
[RFC5444]は、さまざまなプロトコル拡張に対応するパケット/メッセージ形式を提供しようとしたが、完全には成功しなかった[RFC3626]の経験に従って設計されました。 [RFC5444]は、予防型と対処型の両方のMANETルーティングプロトコルで使用するための共通のビルディングブロックとして設計されました。
[RFC5498] mandates the use of this packet/message format and of the packet multiplexing process described in an appendix to [RFC5444] by protocols operating over the MANET IP protocol and UDP port numbers that were allocated by [RFC5498].
[RFC5498]は、[RFC5498]によって割り当てられたMANET IPプロトコルとUDPポート番号を介して動作するプロトコルによる、[RFC5444]の付録に記載されているこのパケット/メッセージ形式とパケット多重化プロセスの使用を義務付けています。
Since the publication of [RFC5444] in 2009, several RFCs have been published, including [RFC5497], [RFC6130], [RFC6621], [RFC7181], [RFC7182], [RFC7183], [RFC7188], [RFC7631], and [RFC7722], that use the format of [RFC5444]. The ITU-T recommendation [G9903] also uses the format of [RFC5444] for encoding some of its control signals. In developing these specifications, experience with the use of [RFC5444] has been acquired, specifically with respect to how to write specifications using [RFC5444] so as to ensure forward compatibility of a protocol with future extensions, to enable the creation of efficient messages, and to enable the use of an efficient and generic parser for all protocols using [RFC5444].
2009年に[RFC5444]が公開されて以来、[RFC5497]、[RFC6130]、[RFC6621]、[RFC7181]、[RFC7182]、[RFC7183]、[RFC7188]、[RFC7631]など、いくつかのRFCが公開されています。 [RFC7722]、[RFC5444]の形式を使用します。 ITU-T勧告[G9903]も、一部の制御信号のエンコードに[RFC5444]の形式を使用しています。これらの仕様を開発する際に、特に[RFC5444]を使用して仕様を記述する方法に関して、[RFC5444]の使用に関する経験が得られ、プロトコルと将来の拡張との上位互換性を確保し、効率的なメッセージの作成を可能にします。 [RFC5444]を使用するすべてのプロトコルで効率的で汎用的なパーサーの使用を可能にする。
During the same time period, other suggestions have been made to use [RFC5444] in a manner that would inhibit the development of interoperable protocol extensions, that would potentially lead to inefficiencies, or that would lead to incompatibilities with generic parsers for [RFC5444]. While these uses were not all explicitly prohibited by [RFC5444], they are strongly discouraged. This document is intended to prohibit such uses, to present experiences from designing protocols using [RFC5444], and to provide these as guidelines (with their rationale) for future protocol designs using [RFC5444].
同じ時期に、相互運用可能なプロトコル拡張の開発を阻害する、非効率につながる可能性がある、または[RFC5444]の汎用パーサーとの非互換性につながるような方法で、[RFC5444]を使用する他の提案が行われました。これらの使用はすべて[RFC5444]によって明示的に禁止されたわけではありませんが、強く非推奨です。このドキュメントは、そのような使用を禁止し、[RFC5444]を使用してプロトコルを設計する経験を提示し、[RFC5444]を使用する将来のプロトコル設計のガイドラインとして（その根拠と共に）提供することを目的としています。
[RFC5444] performs two main functions:
[RFC5444]は2つの主要な機能を実行します：
o It defines a packet/message format for use by MANET routing protocols. As far as [RFC5444] is concerned, it is up to each protocol that uses it to implement the required message parsing and formation. It is natural, especially when implementing more than one such protocol, to implement these processes using protocol-independent packet/message creation and parsing procedures, however, this is not required by [RFC5444]. Some comments in this document might be particularly applicable to such a case, but all that is required is that the messages passed to and from protocols are correctly formatted and that packets containing those messages are correctly formatted as described in the following point.
o MANETルーティングプロトコルで使用するパケット/メッセージフォーマットを定義します。 [RFC5444]に関する限り、それを使用して必要なメッセージの解析と形成を実装するのは、各プロトコル次第です。特に、そのようなプロトコルを複数実装する場合、プロトコルに依存しないパケット/メッセージの作成および解析手順を使用してこれらのプロセスを実装することは自然ですが、これは[RFC5444]では必須ではありません。このドキュメントの一部のコメントは、このような場合に特に当てはまる可能性がありますが、必要なことは、プロトコルとの間でやり取りされるメッセージが正しくフォーマットされ、それらのメッセージを含むパケットが次のポイントで説明するように正しくフォーマットされていることだけです。
o Appendix A of [RFC5444], combined with the intended usage described in Appendix B of [RFC5444], specifies a multiplexing and demultiplexing process whereby an entity that can be referred to as the "RFC 5444 multiplexer" manages packets that travel a single (logical) hop and contain messages that are owned by individual protocols. Note that in this document, the "RFC 5444 multiplexer" is referred to as the "multiplexer", or as the "demultiplexer" when performing that function. A packet can contain messages from more than one protocol. This process is mandated for use on the MANET UDP port and IP protocol (alternative means for the transport of packets) by [RFC5498]. The multiplexer is responsible for creating packets and for parsing Packet Headers, extracting messages, and passing them to the appropriate protocol according to their type (the first octet in the message).
o [RFC5444]の付録Aは、[RFC5444]の付録Bで説明されている使用目的と組み合わせて、「RFC 5444マルチプレクサ」と呼ばれるエンティティが単一の（論理的な）ホップし、個々のプロトコルが所有するメッセージを含みます。このドキュメントでは、「RFC 5444マルチプレクサ」を「マルチプレクサ」または「デマルチプレクサ」と呼び、その機能を実行する場合に注意してください。パケットには、複数のプロトコルからのメッセージを含めることができます。このプロセスは、[RFC5498]により、MANET UDPポートおよびIPプロトコル（パケット転送の代替手段）での使用が義務付けられています。マルチプレクサは、パケットの作成とパケットヘッダーの解析、メッセージの抽出、およびそれらのタイプ（メッセージの最初のオクテット）に応じた適切なプロトコルへの受け渡しを担当します。
Among the characteristics and design objectives of the packet/message format of [RFC5444] are the following:
[RFC5444]のパケット/メッセージ形式の特性と設計目標には、次のものがあります。
o It is designed for carrying MANET routing protocol control signals.
o MANETルーティングプロトコル制御信号を伝送するように設計されています。
o It defines a packet as a Packet Header with a set of Packet TLVs (Type-Length-Value structures), followed by a set of messages. Each message has a well-defined structure consisting of a Message Header (designed for making processing and forwarding decisions) followed by a set of Message TLVs, and a set of (address, type, value) associations using Address Blocks and their Address Block TLVs. The packet/message format from [RFC5444] then enables the use of simple and generic parsing logic for Packet Headers, Message Headers, and message content.
o これは、パケットを一連のパケットTLV（Type-Length-Value構造）を備えたパケットヘッダーとして定義し、その後に一連のメッセージを続けます。各メッセージは、メッセージヘッダー（処理と転送の決定を行うために設計されています）と、それに続くメッセージTLVのセット、およびアドレスブロックとそのアドレスブロックTLVを使用する（アドレス、タイプ、値）の関連付けで構成される明確な構造を持っています。 。 [RFC5444]のパケット/メッセージ形式は、パケットヘッダー、メッセージヘッダー、およびメッセージコンテンツのシンプルで汎用的な解析ロジックの使用を可能にします。
A packet can include messages from different protocols, such as the Neighborhood Discovery Protocol (NHDP) [RFC6130] and the Optimized Link State Routing Protocol version 2 (OLSRv2)
パケットには、近隣探索プロトコル（NHDP）[RFC6130]や最適化リンク状態ルーティングプロトコルバージョン2（OLSRv2）などのさまざまなプロトコルからのメッセージを含めることができます
[RFC7181], in a single transmission. This was observed in [RFC3626] to be beneficial, especially in wireless networks where media contention can be significant.
[RFC7181]、単一の送信。これは、[RFC3626]で、特にメディアの競合が重大になる可能性がある無線ネットワークで有益であることが観察されました。
o Its packets are designed to travel between two neighboring interfaces, which will result in a single decrement of the IPv4 TTL or IPv6 hop limit. The Packet Header and any Packet TLVs can thus convey information relevant to that link (for example, the Packet Sequence Number can be used to count transmission successes across that link). Packets are designed to be constructed for a single-hop transmission; a packet transmission following a successful packet reception is (by design) a new packet that can include all, some, or none of the received messages, plus possibly additional messages either received in separate packets or generated locally at that router. Messages can thus travel more than one hop and are designed to carry end-to-end protocol signals.
o そのパケットは、隣接する2つのインターフェース間を移動するように設計されているため、IPv4 TTLまたはIPv6ホップ制限が1回減少します。したがって、パケットヘッダーと任意のパケットTLVは、そのリンクに関連する情報を伝達できます（たとえば、パケットシーケンス番号を使用して、そのリンク全体の送信成功をカウントできます）。パケットは、シングルホップ伝送用に構築されるように設計されています。パケットの受信に成功した後のパケット送信は、（設計上）受信メッセージのすべて、一部、またはまったくを含まない新しいパケットであり、個別のパケットで受信されるか、ルーターでローカルに生成される追加のメッセージである可能性があります。したがって、メッセージは複数のホップを移動でき、エンドツーエンドのプロトコル信号を伝送するように設計されています。
o It supports "internal extensibility" using TLVs; an extension can add information to an existing message without that information rendering the message unparseable or unusable by a router that does not support the extension. An extension is typically of the protocol that created the message to be extended, for example, [RFC7181] adds information to the HELLO messages created by [RFC6130]. However, an extension can also be independent of the protocol; for example, [RFC7182] can add Integrity Check Value (ICV) and timestamp information to any message (or to a packet, thus extending the multiplexer).
o TLVを使用した「内部拡張性」をサポートしています。拡張機能は既存のメッセージに情報を追加できますが、その情報がないと、拡張機能をサポートしていないルーターでメッセージを解析できなかったり、使用できなくなったりします。拡張は通常、拡張するメッセージを作成したプロトコルのものです。たとえば、[RFC7181]は、[RFC6130]によって作成されたHELLOメッセージに情報を追加します。ただし、拡張機能はプロトコルに依存しない場合もあります。たとえば、[RFC7182]は、整合性チェック値（ICV）とタイムスタンプ情報を任意のメッセージ（またはパケット、つまりマルチプレクサに拡張）に追加できます。
Information, in the form of TLVs, can be added to the message as a whole (such as the integrity information specified in [RFC7182]) or can be associated with specific addresses in the message (such as the Multipoint Relay (MPR) selection and link metric information added to HELLO messages by [RFC7181]). An extension can also add addresses to a message.
TLVの形式の情報は、メッセージ全体に追加するか（[RFC7182]で指定されている整合性情報など）、メッセージ内の特定のアドレスに関連付けることができます（マルチポイントリレー（MPR）の選択や[RFC7181]によってHELLOメッセージに追加されたリンクメトリック情報）。拡張機能は、メッセージにアドレスを追加することもできます。
o It uses address aggregation into compact Address Blocks by exploiting commonalities between addresses. In many deployments, addresses (IPv4 and IPv6) used on interfaces share a common prefix that need not be repeated. Using IPv6, several addresses (of the same interface) might have common interface identifiers that need not be repeated.
o アドレス間の共通性を利用することにより、コンパクトなアドレスブロックへのアドレス集約を使用します。多くの展開では、インターフェイスで使用されるアドレス（IPv4およびIPv6）は、繰り返す必要のない共通のプレフィックスを共有します。 IPv6を使用すると、（同じインターフェースの）複数のアドレスに、繰り返す必要のない共通のインターフェースIDが含まれる場合があります。
o It sets up common namespaces, formats, and data structures for use by different protocols where common parsing logic can be used. For example, [RFC5497] defines a generic TLV format for representing time information (such as interval time or validity time).
o 共通の名前空間、フォーマット、およびデータ構造をセットアップして、共通の解析ロジックを使用できるさまざまなプロトコルで使用できるようにします。たとえば、[RFC5497]は、時間情報（間隔時間や有効時間など）を表すための一般的なTLV形式を定義しています。
o It contains a minimal Message Header (a maximum of five elements: type, originator, sequence number, hop count, and hop limit) that permit decisions regarding whether to locally process a message or forward a message (thus enabling MANET-wide flooding of a message) without processing the body of the message.
o ローカルにメッセージを処理するか、メッセージを転送するか（したがってMANET全体のフラッディングを有効にするかどうか）を決定できる最小のメッセージヘッダー（最大5つの要素：タイプ、発信元、シーケンス番号、ホップカウント、およびホップ制限）が含まれますメッセージ）メッセージ本文を処理しません。
The multiplexer (and demultiplexer) is defined in Appendix A of [RFC5444]. Its purpose is to allow multiple protocols to share the same IP protocol or UDP port. That sharing was made necessary by the separation of [RFC6130] from [RFC7181] as separate protocols and by the allocation of a single IP protocol and UDP port to all MANET protocols, including those protocols following [RFC5498], which states:
マルチプレクサ（およびデマルチプレクサ）は、[RFC5444]の付録Aで定義されています。その目的は、複数のプロトコルが同じIPプロトコルまたはUDPポートを共有できるようにすることです。その共有は、[RFC6130]を[RFC7181]から個別のプロトコルとして分離し、単一のIPプロトコルとUDPポートをすべてのMANETプロトコル（[RFC5498]に続くプロトコルを含む）に割り当てることによって必要とされました。
All interoperable protocols running on these well-known IANA allocations MUST conform to [RFC5444]. [RFC5444] provides a common format that enables one or more protocols to share the IANA allocations defined in this document unambiguously.
これらのよく知られたIANA割り当てで実行されるすべての相互運用可能なプロトコルは、[RFC5444]に準拠する必要があります。 [RFC5444]は、1つまたは複数のプロトコルがこのドキュメントで定義されているIANA割り当てを明確に共有できるようにする共通の形式を提供します。
The multiplexer is the mechanism in [RFC5444] that enables that sharing.
マルチプレクサは、その共有を可能にする[RFC5444]のメカニズムです。
The primary purposes of the multiplexer are to:
マルチプレクサの主な目的は次のとおりです。
o Accept messages from MANET protocols, which also indicate over which interface(s) the messages are to be sent and to which destination address. The latter can be a unicast address or the "LL-MANET-Routers" link-local multicast address defined in [RFC5498].
o MANETプロトコルからのメッセージを受け入れます。これは、メッセージが送信されるインターフェイスと宛先アドレスも示します。後者は、ユニキャストアドレス、または[RFC5498]で定義されている「LL-MANET-Routers」リンクローカルマルチキャストアドレスです。
o Collect messages (possibly from multiple protocols) for the same local interface and destination, into packets to be sent one logical hop, and to send packets using the MANET UDP port or IP protocol defined in [RFC5498].
o 同じローカルインターフェイスと宛先のメッセージ（おそらく複数のプロトコルから）を収集して、1つの論理ホップで送信されるパケットにまとめ、[RFC5498]で定義されているMANET UDPポートまたはIPプロトコルを使用してパケットを送信します。
o Extract messages from received packets and pass them to their owning protocols.
o 受信したパケットからメッセージを抽出し、それらを所有するプロトコルに渡します。
The multiplexer's relationship is with the protocols that own the corresponding Message Types. Where those protocols have their own relationships (for example, as extensions), this is the responsibility of the protocols. For example, OLSRv2 [RFC7181] extends the HELLO messages created by NHDP [RFC6130]. However, the multiplexer will deliver HELLO messages to NHDP and will expect to receive HELLO messages from NHDP; the relationship between NHDP and OLSRv2 is between those two protocols.
マルチプレクサの関係は、対応するメッセージタイプを所有するプロトコルとの関係です。これらのプロトコルに独自の関係がある場合（拡張など）、これはプロトコルの責任です。たとえば、OLSRv2 [RFC7181]は、NHDP [RFC6130]によって作成されたHELLOメッセージを拡張します。ただし、マルチプレクサはHELLOメッセージをNHDPに配信し、NHDPからHELLOメッセージを受信することを期待します。 NHDPとOLSRv2の関係は、これら2つのプロトコルの間にあります。
The multiplexer is also responsible for the Packet Header, including any Packet Sequence Number and Packet TLVs. It can accept some additional instructions from protocols, can pass additional information to protocols, and will follow some additional rules; see Section 4.4.
マルチプレクサは、パケットシーケンス番号やパケットTLVなどのパケットヘッダーも処理します。プロトコルからいくつかの追加の指示を受け入れ、プロトコルに追加の情報を渡すことができ、いくつかの追加の規則に従います。セクション4.4を参照してください。
This document updates [RFC5444] and is published on the Standards Track (rather than as Informational) because it specifies and mandates constraints on the use of [RFC5444] that, if not followed, make forms of extensions of those protocols impossible, impede the ability to generate efficient messages, or make desirable forms of generic parsers impossible.
この文書は[RFC5444]を更新し、[情報としてではなく]標準トラックに公開されています。[RFC5444]の使用に関する制約を指定および義務付けているため、これらのプロトコルの拡張形式を不可能にし、機能を妨げます。効率的なメッセージを生成したり、望ましい形式の汎用パーサーを不可能にしたりします。
Each use of key words from [RFC2119] (see Section 2) can be considered an update to [RFC5444]. In most cases, these codify obvious best practice or constrain the use of [RFC5444] in the circumstances where this specification is applicable (see Section 3). In a few circumstances, operation of [RFC5444] is modified. These are all circumstances that do not occur in its main and current uses, specifically by [RFC6130] and [RFC7181] (that might already include the requirement, particularly through [RFC7188]). That such modifying cases are an update to [RFC5444] is explicitly indicated in this specification.
[RFC2119]（セクション2を参照）のキーワードを使用するたびに、[RFC5444]の更新と見なすことができます。ほとんどの場合、これらは明らかなベストプラクティスを成文化するか、この仕様が適用される状況での[RFC5444]の使用を制限します（セクション3を参照）。いくつかの状況では、[RFC5444]の操作が変更されています。これらはすべて、特に[RFC6130]および[RFC7181]（特に[RFC7188]を介して要件がすでに含まれている可能性がある）によって、その主な現在の使用では発生しない状況です。このような変更ケースが[RFC5444]の更新であることは、この仕様で明示的に示されています。
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Use of those key words applies directly to existing and future implementations of [RFC5444]. It also applies to existing and future protocols that use or update that RFC.
これらのキーワードの使用は、[RFC5444]の既存および将来の実装に直接適用されます。また、そのRFCを使用または更新する既存および将来のプロトコルにも適用されます。
This document uses the terminology and notation defined in [RFC5444]; the terms "packet", "Packet Header", "message", "Message Header", "address", "Address Block", "TLV", "TLV Block", and other related terms are to be interpreted as described therein.
このドキュメントでは、[RFC5444]で定義されている用語と表記法を使用しています。 「パケット」、「パケットヘッダー」、「メッセージ」、「メッセージヘッダー」、「アドレス」、「アドレスブロック」、「TLV」、「TLVブロック」、およびその他の関連用語は、その中で説明されているように解釈されます。
Additionally, this document uses the following terminology:
また、このドキュメントでは次の用語を使用しています。
Full Type (of TLV): As per [RFC5444], the 16-bit combination of the TLV Type and Type Extension is given the symbolic name <tlv-fulltype>. This document uses the term "Full Type", which is not used in [RFC5444], but is assigned (by this document) as standard terminology.
フルタイプ（TLVの）：[RFC5444]に従って、TLVタイプとタイプ拡張の16ビットの組み合わせに記号名<tlv-fulltype>が付けられます。このドキュメントでは、[RFC5444]では使用されない「フルタイプ」という用語を使用していますが、（このドキュメントによって）標準的な用語として割り当てられています。
Owning Protocol: As per [RFC5444], for each Message Type, a protocol -- unless specified otherwise, the one making the IANA reservation for that Message Type -- is designated as the "owning protocol" of that Message Type. The demultiplexer inspects the Message Type of each received message and delivers each message to its corresponding "owning protocol".
所有プロトコル：[RFC5444]のとおり、メッセージタイプごとに、プロトコル（特に指定がない限り、そのメッセージタイプのIANA予約を行うプロトコル）がそのメッセージタイプの「所有プロトコル」として指定されます。デマルチプレクサは、受信した各メッセージのメッセージタイプを検査し、各メッセージを対応する「所有プロトコル」に配信します。
This document does not specify a protocol but documents constraints on how to design protocols that use the generic packet/message format defined in [RFC5444] that, if not followed, makes forms of extensions of those protocols impossible, impedes the ability to generate efficient (small) messages, or makes desirable forms of generic parsers impossible. The use of the [RFC5444] format is mandated by [RFC5498] for all protocols running over the MANET protocol and port, defined therein. Thus, the constraints in this document apply to all protocols running over the MANET IP protocol or UDP port. The constraints are strongly recommended for other uses of [RFC5444].
このドキュメントはプロトコルを指定していませんが、[RFC5444]で定義されている一般的なパケット/メッセージ形式を使用するプロトコルの設計方法に関する制約を文書化しています。これは、従わない場合、これらのプロトコルの拡張形式を不可能にし、効率的な生成を妨げます（小さい）メッセージ、または望ましい形式の汎用パーサーを不可能にします。 [RFC5444]形式の使用は、[RFC5498]によって定義されており、MANETプロトコルとそこで定義されたポート上で実行されるすべてのプロトコルに対して定義されています。したがって、このドキュメントの制約は、MANET IPプロトコルまたはUDPポートで実行されるすべてのプロトコルに適用されます。 [RFC5444]の他の用途には制約を強くお勧めします。
Protocols need to transmit information from one instance implementing the protocol to another.
プロトコルは、プロトコルを実装する1つのインスタンスから別のインスタンスに情報を送信する必要があります。
A protocol has the following choices as to where to put information for transmission:
プロトコルには、送信する情報をどこに置くかに関して次の選択肢があります。
o in a TLV to be added to the Packet Header;
o パケットヘッダーに追加されるTLV内。
o in a message of a type owned by another protocol; or
o 別のプロトコルが所有するタイプのメッセージ内。または
o in a message of a type owned by the protocol.
o プロトコルが所有するタイプのメッセージ内。
The first case (a Packet TLV) can only be used when the information is to be carried one hop. It SHOULD only be used either where the information relates to the packet as a whole (for example, packet integrity check values and timestamps, as specified in [RFC7182]) or if the information is expected to have a wider application than a single protocol. A protocol can also request that the Packet Header include Packet Sequence Numbers but does not control those numbers.
最初のケース（パケットTLV）は、情報が1ホップで運ばれる場合にのみ使用できます。情報がパケット全体に関連している場合（たとえば、[RFC7182]で指定されているパケットの整合性チェック値とタイムスタンプ）、または情報が単一のプロトコルよりも幅広いアプリケーションを持つことが期待される場合にのみ使用してください。プロトコルは、パケットヘッダーにパケットシーケンス番号を含めるように要求することもできますが、これらの番号は制御しません。
The second case (in a message of a type owned by another protocol) is only possible if the adding protocol is an extension to the owning protocol; for example, OLSRv2 [RFC7181] is an extension of NHDP [RFC6130].
2番目のケース（別のプロトコルが所有するタイプのメッセージの場合）は、追加プロトコルが所有プロトコルの拡張である場合にのみ可能です。たとえば、OLSRv2 [RFC7181]はNHDP [RFC6130]の拡張です。
The third case is the normal case for a new protocol.
3番目のケースは、新しいプロトコルの通常のケースです。
A protocol extension can either be simply an update of the protocol (the third case) or be a new protocol that also updates another protocol (the second case). An example of the latter is that OLSRv2 [RFC7181] is a protocol that also extends the HELLO message owned by NHDP [RFC6130]; it is thus an example of both the second and third cases (the latter using the OLSRv2 owned Topology Control (TC) message). An extension to [RFC5444], such as [RFC7182], is considered to be an extension to all protocols. Protocols SHOULD be designed to enable extension by any of these means to be possible, and some of the rules in this document (in Sections 4.6 and 4.8, specifically) are to help facilitate that.
プロトコル拡張は、単にプロトコルを更新する（3番目のケース）か、別のプロトコルも更新する新しいプロトコル（2番目のケース）にすることができます。後者の例は、OLSRv2 [RFC7181]が、NHDP [RFC6130]が所有するHELLOメッセージも拡張するプロトコルであることです。したがって、これは2番目と3番目の両方の例です（後者はOLSRv2所有のトポロジー制御（TC）メッセージを使用します）。 [RFC7182]などの[RFC5444]の拡張は、すべてのプロトコルの拡張と見なされます。プロトコルは、これらの手段のいずれかによる拡張を可能にするように設計されるべきであり、このドキュメント（特にセクション4.6および4.8）の一部のルールは、それを容易にするのに役立ちます。
Protocols SHOULD be conservative in the number of new Message Types that they require, as the total available number of allocatable Message Types is only 224. Protocol design SHOULD consider whether different functions can be implemented by differences in TLVs carried in the same Message Type rather than using multiple Message Types.
プロトコルは、割り当て可能なメッセージタイプの合計数が224しかないため、必要な新しいメッセージタイプの数は控えめにする必要があります。プロトコル設計では、同じメッセージタイプではなく、同じメッセージタイプで伝送されるTLVの違いによって異なる機能を実装できるかどうかを検討する必要があります（SHOULD）。複数のメッセージタイプを使用する。
The TLV Type space, although greater than the Message Type space, SHOULD also be used efficiently. The Full Type of a TLV occupies two octets; thus, there are many more available TLV Full Types than there are Message Types. However, in some cases (currently LINK_METRIC from [RFC7181] and ICV and TIMESTAMP from [RFC7182], all in the global TLV Type space), a TLV Type with a complete set of 256 TLV Full Types is defined (but not necessarily allocated).
TLVタイプスペースは、メッセージタイプスペースよりも大きいものの、効率的に使用する必要があります（SHOULD）。 TLVのフルタイプは2オクテットを占めます。したがって、メッセージタイプよりも多くの利用可能なTLVフルタイプがあります。ただし、場合によっては（現在[RFC7181]のLINK_METRIC、[RFC7182]のICVとTIMESTAMP、すべてグローバルTLVタイプスペース）、256 TLVフルタイプの完全なセットを持つTLVタイプが定義されています（ただし、必ずしも割り当てられているわけではありません）。 。
Each Message Type has an associated block of Message-Type-specific TLV Types (128 to 233, each with 256 type extensions) both for Address Block TLV Types and Message TLV Types. TLV Types from within these blocks SHOULD be used in preference to the Message-Type-independent Message TLV Types (0 to 127, each with 256 type extensions) when a TLV is specific to a message.
各メッセージタイプには、アドレスブロックTLVタイプとメッセージTLVタイプの両方に対して、メッセージタイプ固有のTLVタイプのブロック（128から233、それぞれ256のタイプ拡張がある）が関連付けられています。これらのブロック内のTLVタイプは、TLVがメッセージに固有である場合、メッセージタイプに依存しないメッセージTLVタイプ（0〜127、それぞれ256タイプの拡張子を持つ）に優先して使用する必要があります（SHOULD）。
The Expert Review guidelines in [RFC5444] are updated accordingly, as described in Section 8.
セクション8で説明されているように、[RFC5444]のエキスパートレビューガイドラインはそれに応じて更新されます。
A message contains a Message Header and a Message Body; note that the Message TLV Block is considered part of the latter. The Message Header contains information whose primary purpose is to decide whether to process the message and whether to forward the message.
メッセージには、メッセージヘッダーとメッセージ本文が含まれます。メッセージTLVブロックは後者の一部と見なされることに注意してください。メッセージヘッダーには、メッセージを処理するかどうか、およびメッセージを転送するかどうかを決定することを主な目的とする情報が含まれています。
A protocol might need to recognize whether a message, especially a flooded message, is one that it has previously received (for example, to determine whether to process and/or forward it, or to discard it). A message can be recognized as one that has been previously seen if it contains sufficient information in its Message Header. A message MUST be so recognized by the combination of its Message Type, Originator Address, and Message Sequence Number. The inclusion of Message Type allows each protocol to manage its own Message Sequence Numbers and also allows for the possibility that different Message Types can have greatly differing transmission rates. As an example of such use, [RFC7181] contains a general purpose process for managing processing and forwarding decisions, although specifically for use with MPR flooding. (Blind flooding can be handled similarly by assuming that all other routers are MPR selectors; it is not necessary in this case to differentiate between interfaces on which a message is received.)
プロトコルは、メッセージ、特にフラッディングメッセージが以前に受信したものであるかどうかを認識する必要がある場合があります（たとえば、メッセージを処理または転送するか、または破棄するかを決定するため）。メッセージは、メッセージヘッダーに十分な情報が含まれている場合、以前に表示されたものとして認識できます。メッセージは、そのメッセージタイプ、発信者アドレス、およびメッセージシーケンス番号の組み合わせによってそのように認識される必要があります。メッセージタイプを含めることにより、各プロトコルが独自のメッセージシーケンス番号を管理できるようになり、異なるメッセージタイプが大幅に異なる伝送レートを持つ可能性も可能になります。そのような使用の例として、[RFC7181]には、特にMPRフラッディングで使用するための、処理と転送の決定を管理するための汎用プロセスが含まれています。 （ブラインドフラッディングは、他のすべてのルーターがMPRセレクターであると想定することで同様に処理できます。この場合、メッセージが受信されるインターフェイスを区別する必要はありません。）
Most protocol information is thus contained in the Message Body. A model of how such information can be viewed is described in Sections 4.5 and 4.6. To use that model, addresses (for example, of neighboring or otherwise known routers) SHOULD be recorded in Address Blocks, not as data in TLVs. Recording addresses in TLV Value fields both breaks the model of addresses as identities and associated information (attributes) and also inhibits address compression. However, in some cases, alternative addresses (e.g., hardware addresses when the Address Block is recording IP addresses) can be carried as TLV Values. Note that a message contains a Message Address Length field that can be used to allow carrying alternative message sizes, but only one length of addresses can be used in a single message, in all Address Blocks and the Originator Address, and is established by the router and protocol generating the message.
したがって、ほとんどのプロトコル情報はメッセージ本文に含まれています。このような情報を表示する方法のモデルについては、セクション4.5および4.6で説明しています。このモデルを使用するには、アドレス（たとえば、隣接ルーターまたは既知のルーター）をTLVのデータとしてではなく、アドレスブロックに記録する必要があります（SHOULD）。 TLV値フィールドにアドレスを記録すると、IDと関連情報（属性）としてのアドレスのモデルが壊れ、アドレスの圧縮も抑制されます。ただし、場合によっては、代替アドレス（たとえば、アドレスブロックがIPアドレスを記録している場合のハードウェアアドレス）をTLV値として伝送できます。メッセージにはメッセージアドレス長フィールドが含まれ、これを使用して代替メッセージサイズを運ぶことができますが、1つのメッセージ、すべてのアドレスブロック、および発信元アドレスで使用できるのは、1つの長さのアドレスのみで、ルーターによって確立されます。メッセージを生成するプロトコル。
The multiplexer has to handle message multiplexing into packets and the transmission of said packets, as well as packet reception and demultiplexing into messages. The multiplexer and the protocols that use it are subject to the following rules.
マルチプレクサは、パケットのパケットへの多重化および前記パケットの送信、ならびにパケットの受信およびメッセージへの逆多重化を処理する必要がある。マルチプレクサとそれを使用するプロトコルには、次の規則が適用されます。
Packets are formed for transmission through the following steps:
パケットは、次の手順で送信用に形成されます。
o Outgoing messages are created by their owning protocol and MAY be modified by any extending protocols if the owning protocol permits this. Messages MAY also be forwarded by their owning protocol. It is strongly RECOMMENDED that messages are not modified in the latter case, other than updates to their hop count and hop limit fields, as described in Section 7.1.1 of [RFC5444]. Note that this includes having an identical octet representation, including not allowing a different TLV representation of the same information. This is because it enables end-to-end authentication that ignores (zeros) those two fields (only), as is done in the Message TLV ICV (Integrity Check Value) calculations in [RFC7182]. Protocols MUST document their behavior with regard to modifiability of messages.
o 送信メッセージは、所有するプロトコルによって作成され、所有するプロトコルで許可されている場合は、拡張プロトコルによって変更される場合があります。メッセージは、所有するプロトコルによって転送される場合もあります。 [RFC5444]のセクション7.1.1で説明されているように、ホップカウントとホップリミットフィールドの更新を除いて、後者の場合はメッセージを変更しないことを強くお勧めします。これには、同じ情報の異なるTLV表現を許可しないなど、同一のオクテット表現を持つことが含まれることに注意してください。これは、[RFC7182]のメッセージTLV ICV（整合性チェック値）計算で行われているように、これら2つのフィールド（のみ）を無視（ゼロ）するエンドツーエンド認証を有効にするためです。プロトコルは、メッセージの変更可能性に関する動作を文書化する必要があります。
o Outgoing messages are then sent to the multiplexer. The owning protocol MUST indicate which interface(s) the messages are to be sent on and their destination address. Note that packets travel one hop; the destination is therefore either a link-local multicast address (if the packet is being multicast) or the address of the neighbor interface to which the packet is sent.
o 次に、発信メッセージがマルチプレクサに送信されます。所有プロトコルは、メッセージが送信されるインターフェースとその宛先アドレスを示さなければなりません（MUST）。パケットは1ホップ移動することに注意してください。したがって、宛先は、リンクローカルマルチキャストアドレス（パケットがマルチキャストされている場合）またはパケットの送信先のネイバーインターフェイスのアドレスのいずれかです。
o The owning protocol MAY request that messages are kept together in a packet; the multiplexer SHOULD respect this request if at all possible. The multiplexer SHOULD combine messages that are sent on the same interface in a packet, whether from the same or different protocols, provided that in so doing the multiplexer does not cause an IP packet to exceed the current Maximum Transmission Unit (MTU). Note that the multiplexer cannot fragment messages; creating suitably sized messages that will not cause the MTU to be exceeded if sent in a single message packet is the responsibility of the protocol generating the message. If a larger message is created, then only IP fragmentation is available to allow the packet to be sent; this is generally considered undesirable, especially when transmission can be unreliable.
o 所有プロトコルは、メッセージをパケットにまとめて保持することを要求する場合があります。マルチプレクサは、可能であればこの要求を尊重する必要があります（SHOULD）。マルチプレクサは、マルチプレクサが現在の最大転送ユニット（MTU）を超えないようにすることを条件として、同じプロトコルでも異なるプロトコルでも、パケット内の同じインターフェイスで送信されるメッセージを結合する必要があります（SHOULD）。マルチプレクサはメッセージをフラグメント化できないことに注意してください。単一のメッセージパケットで送信された場合にMTUを超えない適切なサイズのメッセージを作成することは、メッセージを生成するプロトコルの責任です。より大きなメッセージが作成された場合、パケットの送信を許可するために使用できるのはIPフラグメンテーションのみです。これは、特に送信が信頼できない場合は、一般的に望ましくないと考えられています。
o The multiplexer MAY delay messages in order to assemble more efficient packets. It MUST respect any constraints on such delays requested by the protocol if it is practical to do so.
o マルチプレクサは、より効率的なパケットを組み立てるためにメッセージを遅延させる場合があります。それが可能であるならば、それはプロトコルによって要求されたそのような遅延に対するどんな制約も尊重しなければなりません。
o If requested by a protocol, the multiplexer MUST (and otherwise MAY) include a Packet Sequence Number in the packet. Such a request MUST be respected as long as the protocol is active. Note that the errata to [RFC5444] indicates that the Packet Sequence Number SHOULD be specific to the interface on which the packet is sent. This specification updates [RFC5444] by requiring that this sequence number MUST be specific to that interface and also that separate sequence numbers MUST be maintained for each destination to which packets are sent with included Packet Sequence Numbers. Addition of Packet Sequence Numbers MUST be consistent (i.e., for each interface and destination, the Packet Sequence Number MUST be added to all packets or to none).
oプロトコルによって要求された場合、マルチプレクサはパケットにパケットシーケンス番号を含める必要があります（それ以外の場合はMAY）。プロトコルがアクティブである限り、そのような要求は尊重されなければなりません。 [RFC5444]の正誤表は、パケットシーケンス番号がパケットが送信されるインターフェイスに固有であることを示していることに注意してください。この仕様は、[RFC5444]を更新して、このシーケンス番号がそのインターフェイスに固有である必要があり、また、パケットが含まれるパケットシーケンス番号とともに送信される宛先ごとに、個別のシーケンス番号を維持する必要があることを要求します。パケットシーケンス番号の追加は一貫している必要があります（つまり、インターフェイスと宛先ごとに、パケットシーケンス番号をすべてのパケットに追加するか、なしに追加する必要があります）。
o An extension to the multiplexer MAY add TLVs to the packet. It MAY also add TLVs to the messages, in which case it is considered as also extending the corresponding protocols. For example, [RFC7182] can be used by the multiplexer to add Packet TLVs or Message TLVs, or it can be used by the protocol to add Message TLVs.
o マルチプレクサの拡張は、TLVをパケットに追加してもよい（MAY）。メッセージにTLVを追加することもできますが、その場合、対応するプロトコルも拡張すると見なされます。たとえば、[RFC7182]は、マルチプレクサがパケットTLVまたはメッセージTLVを追加するために使用できます。または、プロトコルがメッセージTLVを追加するために使用できます。
When a packet is received, the following steps are performed by the demultiplexer and by protocols:
パケットを受信すると、次の手順がデマルチプレクサーとプロトコルによって実行されます。
o The Packet Header and the organization into the messages that it contains MUST be verified by the demultiplexer.
o パケットヘッダーおよびパケットヘッダーに含まれるメッセージへの編成は、デマルチプレクサーで検証する必要があります。
o The packet and/or the messages it contains MAY also be verified by an extension to the demultiplexer, such as [RFC7182].
o パケットおよび/またはそこに含まれるメッセージは、[RFC7182]などのデマルチプレクサの拡張機能によっても検証される場合があります。
o Each message MUST be sent to its owning protocol or discarded if the Message Type is not recognized. The demultiplexer MUST also make available to the protocol the Packet Header and the source and destination addresses in the IP datagram that included the packet.
o 各メッセージは、それを所有するプロトコルに送信するか、メッセージタイプが認識されない場合は破棄する必要があります。デマルチプレクサは、プロトコルを使用して、パケットを含むIPデータグラム内のパケットヘッダーと送信元アドレスおよび宛先アドレスも使用可能にする必要があります。
o The demultiplexer MUST remove any Message TLVs that were added by an extension to the multiplexer. The message MUST be passed on to the protocol exactly as received from (another instance of) the protocol. This is, in part, an implementation detail. For example, an implementation of the multiplexer and of [RFC7182] could add a Message TLV either in the multiplexer or in the protocol and remove it in the same place on reception. An implementation MUST ensure that the message passed to a protocol is as it would be passed from that protocol by the same implementation, i.e., that the combined implementation on a router is self-consistent, and that messages included in packets by the multiplexer are independent of this implementation detail.
o デマルチプレクサは、マルチプレクサの拡張機能によって追加されたメッセージTLVを削除する必要があります。メッセージは、プロトコル（の別のインスタンス）から受信したとおりにプロトコルに渡される必要があります。これは、一部、実装の詳細です。たとえば、マルチプレクサと[RFC7182]の実装は、マルチプレクサまたはプロトコルのいずれかにメッセージTLVを追加し、受信時に同じ場所から削除することができます。実装は、プロトコルに渡されるメッセージが、同じ実装によってそのプロトコルから渡されるのと同じであること、つまり、ルーターでの実装の組み合わせに一貫性があり、マルチプレクサによってパケットに含まれるメッセージが独立していることを保証する必要があります。この実装の詳細。
o The owning protocol MUST verify each message for correctness; it MUST allow any extending protocol(s) to also contribute to this verification.
o 所有プロトコルは、各メッセージが正しいことを確認する必要があります。拡張プロトコルもこの検証に貢献できるようにする必要があります。
o The owning protocol MUST process each message. In some cases, which will be defined in the protocol specification, this processing will determine that the message will be ignored. Except in the latter case, the owning protocol MUST also allow any extending protocols to process the message.
o 所有プロトコルは、各メッセージを処理する必要があります。プロトコル仕様で定義されるいくつかのケースでは、この処理はメッセージが無視されることを決定します。後者の場合を除いて、所有プロトコルは、拡張プロトコルがメッセージを処理することも許可する必要があります。
o The owning protocol MUST manage the hop count and/or hop limit in the message. It is RECOMMENDED that these are handled as described in Appendix B of [RFC5444]; they MUST be so handled if using hop-count-dependent TLVs such as those defined in [RFC5497].
o 所有プロトコルは、メッセージ内のホップ数やホップ制限を管理する必要があります。これらは[RFC5444]の付録Bで説明されているように処理することをお勧めします。 [RFC5497]で定義されているようなホップ数依存のTLVを使用する場合は、そのように処理する必要があります。
In addition to the messages between the multiplexer and the protocols in each direction, the following additional information (summarized from other sections in this specification) can be exchanged.
マルチプレクサと各方向のプロトコル間のメッセージに加えて、次の追加情報（この仕様の他のセクションから要約）を交換できます。
o The packet source and destination addresses MUST be sent from the demultiplexer to the protocol.
o パケットの送信元アドレスと宛先アドレスは、デマルチプレクサからプロトコルに送信する必要があります。
o The Packet Header, including the Packet Sequence Number, MUST be sent from the (de)multiplexer to the protocol if present. (An implementation MAY choose to only do so or only report the Packet Sequence Number, on request.)
o パケットシーケンス番号を含むパケットヘッダーは、存在する場合、（デ）マルチプレクサからプロトコルに送信する必要があります。 （実装では、要求に応じて、そうするか、パケットシーケンス番号のみを報告するかを選択できます。）
o A protocol MAY require that all outgoing packets contain a Packet Sequence Number.
o プロトコルでは、すべての発信パケットにパケットシーケンス番号が含まれている必要があります。
o The interface over which a message is to be sent and its destination address MUST be sent from protocol to multiplexer. The destination address MAY be a multicast address, in particular, the LL-MANET-Routers link-local multicast address defined in [RFC5498].
o メッセージが送信されるインターフェイスとその宛先アドレスは、プロトコルからマルチプレクサに送信される必要があります。宛先アドレスは、マルチキャストアドレス、特に[RFC5498]で定義されているLL-MANET-Routersリンクローカルマルチキャストアドレスである可能性があります。
o A request to keep messages together in one packet MAY be sent from protocol to multiplexer.
o メッセージを1つのパケットにまとめる要求は、プロトコルからマルチプレクサに送信される場合があります。
o A requested maximum message delay MAY be sent from protocol to multiplexer.
o 要求された最大メッセージ遅延は、プロトコルからマルチプレクサに送信される場合があります。
The protocol SHOULD also be aware of the MTU that will apply to its messages, if this is available.
プロトコルは、利用可能な場合、メッセージに適用されるMTUにも注意する必要があります（SHOULD）。
The information in a Message Body, including Message TLVs and Address Block TLVs, consists of:
メッセージTLVやアドレスブロックTLVを含むメッセージ本文の情報は、次のもので構成されます。
o Attributes of the message, in which each attribute consists of a Full Type, a length, and a Value (of that length).
o メッセージの属性。各属性は、フルタイプ、長さ、および値（その長さ）で構成されます。
o A set of addresses, which are carried in one or more Address Blocks.
o 1つ以上のアドレスブロックで伝送されるアドレスのセット。
o Attributes of each address, in which each attribute consists of a Full Type, a length, and a Value (of that length).
o 各アドレスの属性。各属性は、フルタイプ、長さ、および値（その長さ）で構成されます。
Attributes are carried in TLVs. For Message TLVs, the mapping from TLV to attribute is one to one. For Address Block TLVs, the mapping from TLV to attribute is one to many: one TLV can carry attributes for multiple addresses, but only one attribute per address. Attributes for different addresses can be the same or different.
属性はTLVで伝達されます。メッセージTLVの場合、TLVから属性へのマッピングは1対1です。アドレスブロックTLVの場合、TLVから属性へのマッピングは1対多です。1つのTLVは複数のアドレスの属性を伝送できますが、アドレスごとに1つの属性しか伝送できません。異なるアドレスの属性は、同じでも異なっていてもかまいません。
[RFC5444] requires that when a TLV Full Type is defined, then it MUST also define how to handle the cases of multiple TLVs of the same type applying to the same information element - i.e., when more than one Packet TLV of the same TLV Full Type is included in the same Packet Header, when more than one Message TLV of the same TLV Full Type is included in the same Message TLV Block, or when more than one Address Block TLV of the same TLV Full Type applies to the same value of any address. It is RECOMMENDED that when defining a new TLV Full Type, a rule of the following form is adopted.
[RFC5444]では、TLVフルタイプが定義されている場合、同じ情報要素に適用される同じタイプの複数のTLVのケースを処理する方法も定義する必要があります。つまり、同じTLVフルの複数のパケットTLVタイプが同じパケットヘッダーに含まれる場合、同じTLVフルタイプの複数のメッセージTLVが同じメッセージTLVブロックに含まれる場合、または同じTLVフルタイプの複数のアドレスブロックTLVが同じ値に適用される場合任意のアドレス。新しいTLVフルタイプを定義するときは、次の形式のルールを採用することをお勧めします。
o If used, there MUST be only one TLV of that Full Type associated with the packet (Packet TLV), message (Message TLV), or any value of any address (Address Block TLV).
o 使用する場合、パケット（パケットTLV）、メッセージ（メッセージTLV）、または任意のアドレスの任意の値（アドレスブロックTLV）に関連付けられたそのフルタイプのTLVが1つだけ存在する必要があります。
Note that this applies to address values; an address can appear more than once in a message, but the restriction on associating TLVs with addresses covers all copies of that address. It is RECOMMENDED that addresses are not repeated in a message.
これはアドレス値に適用されることに注意してください。 1つのアドレスがメッセージに複数回現れる場合がありますが、TLVとアドレスの関連付けに関する制限は、そのアドレスのすべてのコピーをカバーします。メッセージ内でアドレスが繰り返されないようにすることをお勧めします。
A conceptual way to view this information is described in Appendix A.
この情報を表示する概念的な方法は、付録Aで説明されています。
It is not mandatory in [RFC5444] to associate an address with attributes using Address Block TLVs. Information about an address could thus, in principle, be carried using:
[RFC5444]では、アドレスブロックTLVを使用してアドレスを属性に関連付けることは必須ではありません。したがって、アドレスに関する情報は、原則として、以下を使用して伝達できます。
o The simple presence of an address.
o 住所の単純な存在。
o The ordering of addresses in an Address Block.
o アドレスブロック内のアドレスの順序。
o The use of different meanings for different Address Blocks.
o 異なるアドレスブロックに異なる意味を使用します。
This specification, however, requires that those methods of carrying information MUST NOT be used for any protocol using [RFC5444]. Information about the meaning of an address MUST only be carried using Address Block TLVs.
しかしながら、この仕様は、情報を運ぶそれらの方法が[RFC5444]を使用するあらゆるプロトコルに使用されてはならないことを要求します。アドレスの意味に関する情報は、アドレスブロックTLVを使用してのみ伝送されなければなりません（MUST）。
In addition, rules for the extensibility of OLSRv2 and NHDP are described in [RFC7188]. This specification extends their applicability to other uses of [RFC5444].
さらに、OLSRv2とNHDPの拡張性に関するルールは、[RFC7188]で説明されています。この仕様は、[RFC5444]の他の用途への適用性を拡張します。
These rules are:
これらのルールは次のとおりです。
o A protocol MUST NOT assign any meaning to the presence or absence of an address (either in a Message or in a given Address Block in a Message), to the ordering of addresses in an Address Block, or to the division of addresses among Address Blocks.
o プロトコルは、アドレスの有無（メッセージ内、またはメッセージ内の特定のアドレスブロック内）、アドレスブロック内のアドレスの順序付け、またはアドレスブロック間のアドレスの分割に意味を割り当ててはなりません（MUST NOT）。 。
o A protocol MUST NOT reject a message based on the inclusion of a TLV of an unrecognized type. The protocol MUST ignore any such TLVs when processing the message. The protocol MUST NOT remove or change any such TLVs if the message is to be forwarded unchanged.
o プロトコルは、認識されないタイプのTLVの包含に基づいてメッセージを拒否してはなりません（MUST NOT）。プロトコルは、メッセージを処理するときに、そのようなTLVを無視する必要があります。メッセージを変更せずに転送する場合、プロトコルはそのようなTLVを削除または変更してはなりません（MUST NOT）。
o A protocol MUST NOT reject a message based on the inclusion of an unrecognized Value in a TLV of a recognized type. The protocol MUST ignore any such Values when processing the message but MUST NOT ignore recognized Values in such a TLV. The protocol MUST NOT remove or change any such TLVs if the message is to be forwarded unchanged.
o プロトコルは、認識されたタイプのTLVに認識されない値を含めることに基づいてメッセージを拒否してはなりません（MUST NOT）。プロトコルはメッセージを処理するときにそのような値を無視しなければなりません（MUST）が、そのようなTLVで認識されている値を無視してはなりません（MUST NOT）。メッセージを変更せずに転送する場合、プロトコルはそのようなTLVを削除または変更してはなりません（MUST NOT）。
o Similar restrictions to the two preceding points apply to the demultiplexer, which also MUST NOT reject a packet based on an unrecognized message; although it will reject any such messages, it MUST deliver any other messages in the packet to their owning protocols.
o 前の2つのポイントと同様の制限がデマルチプレクサにも適用されます。デマルチプレクサも、認識されないメッセージに基づいてパケットを拒否してはなりません（MUST NOT）。そのようなメッセージはすべて拒否しますが、パケット内の他のメッセージを所有するプロトコルに配信する必要があります。
The following points indicate the reasons for these rules based on considerations of extensibility and efficiency.
以下の点は、拡張性と効率性の考慮に基づくこれらのルールの理由を示しています。
Assigning a meaning to the presence, absence, or location of an address would reduce the extensibility of the protocol, prevent the approach to information representation described in Appendix A, and reduce the options available for message optimization described in Section 6.
アドレスの存在、不在、または場所に意味を割り当てると、プロトコルの拡張性が低下し、付録Aで説明されている情報表現へのアプローチが妨げられ、セクション6で説明されているメッセージ最適化に使用できるオプションが減少します。
To consider how the simple presence of an address conveying information would have restricted the development of an extension, two examples are considered: one actual (included in the base specification, but which could have been added later) and one hypothetical.
情報を伝達するアドレスの単純な存在が拡張機能の開発をどのように制限していたかを検討するために、2つの例が考えられます。
The basic function of NHDP's HELLO messages [RFC6130] is to indicate that addresses are of neighbors, using the LINK_STATUS and OTHER_NEIGHB TLVs. (The message can also indicate the router's own addresses, which could also serve as a further example.)
NHDPのHELLOメッセージ[RFC6130]の基本機能は、LINK_STATUSおよびOTHER_NEIGHB TLVを使用して、アドレスがネイバーのものであることを示すことです。 （メッセージは、ルーター自体のアドレスを示すこともできます。これは、さらに別の例としても機能します。）
An extension to NHDP might decide to use the HELLO message to report that an address is one that could be used for a specialized purpose rather than for normal NHDP-based purposes. Such an example already exists in the use of LOST Values in the LINK_STATUS and OTHER_NEIGHB TLVs to report that an address is of a router known not to be a neighbor.
NHDPの拡張機能は、HELLOメッセージを使用して、アドレスが通常のNHDPベースの目的ではなく、特殊な目的に使用できるアドレスであることを報告する場合があります。そのような例は、アドレスがネイバーではないことがわかっているルーターのものであることを報告するために、LINK_STATUSおよびOTHER_NEIGHB TLVのLOST値を使用することですでに存在しています。
A future example could be to indicate that an address is to be added to a "blacklist" of addresses not to be used. This would use a new TLV (or a new Value of an existing TLV, see below). If no other TLVs were attached to such a blacklisted address, then an unmodified implementation of NHDP would ignore that address, as required; if any other TLVs were attached to that address, then that implementation would process that address for those TLVs. Had NHDP been designed so that just the presence of an address indicated a neighbor, this blacklist extension would not be possible, as an unmodified implementation of NHDP would treat all blacklisted addresses as neighbors.
将来の例としては、使用されないアドレスの「ブラックリスト」にアドレスが追加されることを示すことが考えられます。これは新しいTLV（または既存のTLVの新しい値、以下を参照）を使用します。そのようなブラックリストに登録されたアドレスに他のTLVが接続されていない場合、NHDPの未変更の実装は、必要に応じてそのアドレスを無視します。他のTLVがそのアドレスに接続されている場合、その実装はそれらのTLVのそのアドレスを処理します。アドレスの存在だけがネイバーを示すようにNHDPが設計されていた場合、変更されていないNHDPの実装はすべてのブラックリストアドレスをネイバーとして扱うため、このブラックリスト拡張は不可能です。
Rejecting a message because it contains an unrecognized TLV Type or an unrecognized TLV Value reduces the extensibility of the protocol.
認識されないTLVタイプまたは認識されないTLV値が含まれているためにメッセージを拒否すると、プロトコルの拡張性が低下します。
For example, OLSRv2 [RFC7181] is, among other things, an extension to NHDP. It adds information to addresses in an NHDP HELLO message using a LINK_METRIC TLV. A non-OLSRv2 implementation of NHDP (for example, to support Simplified Multicast Flooding (SMF) [RFC6621]) will still process the HELLO message, ignoring the LINK_METRIC TLVs.
たとえば、OLSRv2 [RFC7181]は、とりわけ、NHDPの拡張機能です。 LINK_METRIC TLVを使用して、NHDP HELLOメッセージのアドレスに情報を追加します。 NHDPの非OLSRv2実装（たとえば、Simplified Multicast Flooding（SMF）[RFC6621]をサポートする）は、LINK_METRIC TLVを無視して、引き続きHELLOメッセージを処理します。
Also, the blacklisting described in the example above could be signaled not with a new TLV but with a new Value of a LINK_STATUS or OTHER_NEIGHB TLV (requiring an IANA allocation as described in [RFC7188]), as is already done in the LOST case.
また、上記の例で説明したブラックリストは、新しいTLVではなく、LINK_STATUSまたはOTHER_NEIGHB TLVの新しい値（[RFC7188]で説明されているようにIANA割り当てが必要）で通知できます。これは、LOSTケースですでに行われています。
The creation of Multi-Topology OLSRv2 (MT-OLSRv2) [RFC7722], as an extension to OLSRv2 that can interoperate with unextended instances of OLSRv2, would not have been possible without these restrictions (which were applied to NHDP and OLSRv2 by [RFC7188]).
OLSRv2の拡張されていないインスタンスと相互運用できるOLSRv2の拡張機能としてのマルチトポロジOLSRv2（MT-OLSRv2）[RFC7722]の作成は、これらの制限（[RFC7188]によってNHDPおよびOLSRv2に適用された）なしでは不可能でした）。
These restrictions do not, however, mean that added information is completely ignored for purposes of the base protocol. Suppose that a faulty implementation of OLSRv2 (including NHDP) creates a HELLO message that assigns two different values of the same link metric to an address, something that is not permitted by [RFC7181]. A receiving OLSRv2-aware implementation of NHDP will reject such a message, even though a receiving OLSRv2-unaware implementation of NHDP will process it. This is because the OLSRv2-aware implementation has access to additional information (that the HELLO message is definitely invalid and the message is best ignored) as it is unknown what other errors it might contain.
ただし、これらの制限は、追加された情報が基本プロトコルの目的で完全に無視されることを意味するものではありません。 OLSRv2（NHDPを含む）の不完全な実装が、同じリンクメトリックの2つの異なる値をアドレスに割り当てるHELLOメッセージを作成するとします。これは、[RFC7181]で許可されていないものです。 NHDPの受信OLSRv2認識実装がそれを処理する場合でも、NHDPの受信OLSRv2認識実装はそのようなメッセージを拒否します。これは、OLSRv2対応の実装が他のエラーに含まれる可能性のある他のエラーが不明であるため、追加情報（HELLOメッセージは間違いなく無効であり、メッセージは無視するのが最善）にアクセスできるためです。
Within a message, the attributes are represented by TLVs. Particularly for Address Block TLVs, different TLVs can represent the same information. For example, using the LINK_STATUS TLV defined in [RFC6130], if some addresses have Value SYMMETRIC and some have Value HEARD, arranged in that order, then this information can be represented using two single-value TLVs or one multivalue TLV. The latter can be used even if the addresses are not so ordered.
メッセージ内では、属性はTLVによって表されます。特にアドレスブロックTLVの場合、異なるTLVが同じ情報を表すことがあります。たとえば、[RFC6130]で定義されているLINK_STATUS TLVを使用して、一部のアドレスに値SYMMETRICがあり、一部の値に値HEARDがある場合、この情報は2つの単一値TLVまたは1つの多値TLVを使用して表すことができます。後者は、アドレスがそれほど順序付けされていなくても使用できます。
A protocol MAY use any representation of information using TLVs that convey the required information. A protocol SHOULD use an efficient representation, but this is a quality of implementation issue. A protocol MUST recognize any permitted representation of the information; even if it chooses to, for example, only use multivalue TLVs, it MUST recognize single-value TLVs (and vice versa).
プロトコルは、必要な情報を伝達するTLVを使用して情報の表現を使用してもよい（MAY）。プロトコルは効率的な表現を使用する必要があります（SHOULD）が、これは実装の品質の問題です。プロトコルは、情報の許可された表現を認識しなければなりません。たとえば、複数値のTLVのみを使用することを選択した場合でも、単一値のTLVを認識しなければなりません（逆も同様です）。
A protocol defining new TLVs MUST respect the naming and organizational rules in [RFC7631]. It SHOULD follow the guidance in [RFC7188], see Section 6.3. (This specification does not, however, relax the application of [RFC7188] where it is mandated.)
新しいTLVを定義するプロトコルは、[RFC7631]の命名規則と編成規則を尊重する必要があります。 [RFC7188]のガイダンスに従う必要があります。セクション6.3を参照してください。 （ただし、この仕様では、[RFC7188]の適用が緩和されるわけではありません。）
In addition to not rejecting a message due to unknown TLVs or TLV Values, a protocol MUST NOT reject a message based on the inclusion of a TLV of an unrecognized type. The protocol MUST ignore any such TLVs when processing the message. The protocol MUST NOT remove or change any such TLVs if the message is to be forwarded unchanged. Such behavior may have the following consequences:
未知のTLVまたはTLV値が原因でメッセージを拒否しないことに加えて、プロトコルは、認識されないタイプのTLVの包含に基づいてメッセージを拒否してはなりません（MUST NOT）。プロトコルは、メッセージを処理するときに、そのようなTLVを無視する必要があります。メッセージを変更せずに転送する場合、プロトコルはそのようなTLVを削除または変更してはなりません（MUST NOT）。このような動作は、次の結果をもたらす可能性があります。
o It might disrupt the operation of an extension of which it is unaware. Note that it is the responsibility of a protocol extension to handle interoperation with unextended instances of the protocol. For example, OLSRv2 [RFC7181] adds an MPR_WILLING TLV to HELLO messages (created by NHDP [RFC6130], of which it is an extension) to recognize this case (and for other reasons).
o 認識されていない拡張機能の動作を妨害する可能性があります。プロトコルの拡張されていないインスタンスとの相互運用を処理するのは、プロトコル拡張の責任であることに注意してください。たとえば、OLSRv2 [RFC7181]はMPR_WILLING TLVをHELLOメッセージ（NHDP [RFC6130]によって作成され、これは拡張機能です）に追加して、このケースを認識します（他の理由により）。
o It would prevent the operation of end-to-end message authentication using [RFC7182] or any similar mechanism. The use of immutable (apart from hop count and/or hop limit) messages by a protocol is strongly RECOMMENDED for that reason.
o これは、[RFC7182]または同様のメカニズムを使用したエンドツーエンドのメッセージ認証の操作を妨げます。そのため、プロトコルによる不変（ホップカウントやホップリミット以外の）メッセージの使用は強く推奨されます。
This section concerns the properties of the format defined in [RFC5444] itself, rather than the properties of protocols using it.
このセクションは、それを使用するプロトコルのプロパティではなく、[RFC5444]自体で定義されたフォーマットのプロパティに関するものです。
The elements defined in [RFC5444] have structures that are managed by a number of flags fields:
[RFC5444]で定義されている要素には、いくつかのフラグフィールドで管理される構造があります。
o Packet flags field (4 bits, 2 used) that manages the contents of the Packet Header.
o パケットヘッダーの内容を管理するパケットフラグフィールド（4ビット、2つ使用）。
o Message flags field (4 bits, 4 used) that manages the contents of the Message Header.
o メッセージヘッダーの内容を管理するメッセージフラグフィールド（4ビット、4を使用）。
o Address Block flags field (8 bits, 4 used) that manages the contents of an Address Block.
o アドレスブロックの内容を管理するアドレスブロックフラグフィールド（8ビット、4を使用）。
o TLV flags field (8 bits, 5 used) that manages the contents of a TLV.
o TLVの内容を管理するTLVフラグフィールド（8ビット、5を使用）。
Note that all of these flags are structural; they specify which elements are present or absent, field lengths, or whether a field has one or multiple values in it.
これらのフラグはすべて構造的であることに注意してください。これらは、存在する要素と存在しない要素、フィールド長、またはフィールドに1つまたは複数の値が含まれるかどうかを指定します。
In the current version of [RFC5444], indicated by version number 0 in the <version> field of the Packet Header, unused bits in these flags fields are stated as "are RESERVED and SHOULD each be cleared ('0') on transmission and SHOULD be ignored on reception". For the avoidance of any compatibility issues, with regard to version number 0, this is updated to "MUST each be cleared ('0') on transmission and MUST be ignored on reception".
パケットヘッダーの<version>フィールドのバージョン番号0で示される[RFC5444]の現在のバージョンでは、これらのフラグフィールドの未使用ビットは、 "予約済みであり、送信時にそれぞれクリア（ '0'）されている必要があります。受信時には無視してください。」互換性の問題を回避するために、バージョン番号0に関して、これは「送信時にそれぞれクリア（ '0'）しなければならず、受信時に無視しなければならない」に更新されています。
If a specification updating [RFC5444] introduces new flags in one of the flags fields of a packet, Address Block, or TLV (there being no unused flags in the message flags field), the following rules MUST be followed:
仕様更新[RFC5444]が、パケット、アドレスブロック、またはTLVのフラグフィールドの1つに新しいフラグを導入する場合（メッセージフラグフィールドに未使用のフラグがない場合）、次の規則に従う必要があります。
o The version number contained in the <version> field of the Packet Header MUST NOT be 0.
o パケットヘッダーの<version>フィールドに含まれるバージョン番号は0であってはなりません。
o The new flag(s) MUST indicate the structure of the corresponding packet, Address Block, or TLV. They MUST NOT be used to indicate any other semantics, such as message forwarding behavior.
o 新しいフラグは、対応するパケット、アドレスブロック、またはTLVの構造を示す必要があります。メッセージ転送動作など、他のセマンティクスを示すために使用してはなりません（MUST NOT）。
An update that would be incompatible with the current specification of [RFC5444] SHOULD NOT be created unless there is a pressing reason for it that cannot be satisfied using the current specification (e.g., by use of a suitable Message TLV or Address Block TLV).
[RFC5444]の現在の仕様と互換性のない更新は、現在の仕様を使用して満足できない緊急の理由がない限り（たとえば、適切なメッセージTLVまたはアドレスブロックTLVを使用して）作成しないでください。
During the development of [RFC5444] (and since publication thereof), some proposals have been made to use these RESERVED flags to specify behavior rather than structure, message forwarding in particular. These proposals were, after due consideration, not accepted for a number of reasons. These reasons include that message forwarding, in particular, is protocol specific; for example, [RFC7181] forwards messages using its MPR mechanism rather than a "blind" flooding mechanism. (These proposals were made during the development of [RFC5444] when there were still unused message flags. Later addition of a 4-bit Message Address Length field later left no unused message flags, but other flags fields still have unused flags.)
[RFC5444]の開発中（およびその公開以降）、これらのRESERVEDフラグを使用して、特にメッセージ転送などの構造ではなく動作を指定する提案がいくつかなされています。これらの提案は、十分な検討の結果、いくつかの理由で承認されませんでした。これらの理由には、特にメッセージ転送がプロトコル固有であることが含まれます。たとえば、[RFC7181]は、「ブラインド」フラッディングメカニズムではなく、MPRメカニズムを使用してメッセージを転送します。 （これらの提案は、未使用のメッセージフラグが存在する[RFC5444]の開発中に行われました。後で4ビットのメッセージアドレス長フィールドを追加すると、未使用のメッセージフラグはなくなりましたが、他のフラグフィールドには未使用のフラグが残っています。）
The ability to organize addresses into the same or different Address Blocks and to change the order of addresses within an Address Block (as well as the flexibility of the TLV specification) enables avoiding unnecessary repetition of information and can consequently generate smaller messages. There are no algorithms for address organization, compression, or for TLV usage in [RFC5444]; any algorithms that leave the information content unchanged MAY be used when generating a message. See also Appendix B.
アドレスを同じまたは異なるアドレスブロックに編成し、アドレスブロック内のアドレスの順序を変更する機能（およびTLV仕様の柔軟性）により、不必要な情報の繰り返しを回避し、結果としてより小さなメッセージを生成できます。 [RFC5444]には、アドレスの編成、圧縮、またはTLVの使用に関するアルゴリズムはありません。情報の内容を変更しないアルゴリズムは、メッセージを生成するときに使用できます。付録Bも参照してください。
[RFC5444] allows the addresses in an Address Block to be compressed. A protocol generating a message SHOULD compress addresses as much as it can.
[RFC5444]では、アドレスブロックのアドレスを圧縮できます。メッセージを生成するプロトコルは、アドレスをできるだけ圧縮する必要があります（SHOULD）。
Addresses in an Address Block consist of a Head, a Mid, and a Tail, where all addresses in an Address Block have the same Head and Tail but different Mids. Each has a length that is greater than or equal to zero, the sum of the lengths being the address length. (The Mid length is deduced from this relationship.) Compression is possible when the Head and/or the Tail have non-zero length. An additional compression is possible when the Tail consists of all zero-valued octets. Expected use cases include IPv4 and IPv6 addresses from within the same prefix and that therefore have a common Head, IPv4 subnets with a common zero-valued Tail, and IPv6 addresses with a common Tail representing an interface identifier as well as having a possible common Head. Note that when, for example, IPv4 addresses have a common Head, their Tail will usually have length zero.
アドレスブロックのアドレスは、ヘッド、ミッド、テールで構成されます。アドレスブロックのすべてのアドレスは、ヘッドとテールは同じですが、ミッドは異なります。それぞれの長さがゼロ以上であり、長さの合計がアドレス長になります。 （中間の長さはこの関係から推定されます。）ヘッドおよび/またはテールの長さがゼロ以外の場合、圧縮が可能です。テールがすべてゼロ値のオクテットで構成されている場合、追加の圧縮が可能です。予想される使用例には、同じプレフィックス内からのIPv4アドレスとIPv6アドレスが含まれるため、共通のヘッド、ゼロ値のテールが共通のIPv4サブネット、インターフェース識別子を表す共通のテールを持つIPv6アドレス、および共通のヘッドの可能性があります。たとえば、IPv4アドレスに共通のヘッドがある場合、それらのテールの長さは通常ゼロになります。
For example:
例えば：
o The IPv4 addresses 192.0.2.1 and 192.0.2.2 would, for greatest efficiency, have a 3-octet Head, a 1-octet Mid, and a 0-octet Tail.
o IPv4アドレス192.0.2.1および192.0.2.2は、効率を最大にするために、3オクテットのヘッド、1オクテットのミッド、および0オクテットのテールを持ちます。
o The IPv6 addresses 2001:DB8:prefix1:interface and 2001:DB8:prefix2:interface that use the same interface identifier but completely different prefixes (except as noted) would, for greatest efficiency, have a 4-octet head, a 4-octet Mid, and an 8-octet Tail. (They could have a larger Head and/or Tail and a smaller Mid if the prefixes have any octets in common.)
o IPv6アドレス2001：DB8：prefix1：interfaceおよび2001：DB8：prefix2：interface同じインターフェース識別子を使用するが、完全に異なるプレフィックス（注記がある場合を除く）は、最大の効率のために、4オクテットのヘッド、4オクテットを持ちます。ミッド、8オクテットのテール。 （接頭辞に共通のオクテットがある場合、それらはより大きなヘッドおよび/またはテールとより小さなミッドを持つことができます。）
Putting addresses into a message efficiently also requires consideration of the following:
メッセージにアドレスを効率的に入力するには、次のことも考慮する必要があります。
o The split of the addresses into Address Blocks.
o アドレスのアドレスブロックへの分割。
o The order of the addresses within the Address Blocks.
o アドレスブロック内のアドレスの順序。
This split and/or ordering is for efficiency only; it does not provide any information. The split of the addresses affects both the address compression and the TLV efficiency (see Section 6.2); the order of the addresses within an Address Block affects only the TLV efficiency. However, using more Address Blocks than needed can increase the message size due to the overhead of each Address Block and the following TLV Block, and/or if additional TLVs are now required.
この分割または順序付け、あるいはその両方は、効率のみを目的としています。情報は提供されません。アドレスの分割は、アドレス圧縮とTLV効率の両方に影響します（セクション6.2を参照）。アドレスブロック内のアドレスの順序は、TLV効率にのみ影響します。ただし、必要以上にアドレスブロックを使用すると、各アドレスブロックと次のTLVブロックのオーバーヘッドが原因で、または追加のTLVが必要になった場合に、メッセージサイズが大きくなる可能性があります。
The order of addresses can be as simple as sorting the addresses, but if many addresses have the same TLV Types attached, it might be more useful to put these addresses together, either within the same Address Block as other addresses or in a separate Address Block. A separate Address Block might also improve address compression, for example, if more than one address form is used (such as from independent subnets). An example of the possible use of address ordering is a HELLO message from [RFC6130] that could be generated with local interface addresses first and neighbor addresses later. These could be in separate Address Blocks.
アドレスの順序は、アドレスを並べ替えるのと同じくらい簡単ですが、多くのアドレスに同じTLVタイプがアタッチされている場合は、これらのアドレスを、他のアドレスと同じアドレスブロック内または別のアドレスブロック内にまとめた方が便利です。 。たとえば、独立したサブネットからなど、複数のアドレス形式が使用されている場合は、個別のアドレスブロックによってアドレス圧縮も改善される可能性があります。アドレス順序付けの可能な使用例は、[RFC6130]からのHELLOメッセージです。これは、最初にローカルインターフェイスアドレスを使用し、後でネイバーアドレスを使用して生成できます。これらは別のアドレスブロックにある可能性があります。
When considering TLVs, the main opportunities for creating more efficient messages are in Address Block TLVs rather than Message TLVs. The approaches described here apply to each Address Block.
TLVを検討する場合、より効率的なメッセージを作成するための主な機会は、メッセージTLVではなくアドレスブロックTLVにあります。ここで説明するアプローチは、各アドレスブロックに適用されます。
An Address Block TLV provides attributes for one address or a contiguous (as stored in the Address Block) set of addresses (with a special case for when this set is of all of the addresses in the Address Block). When associated with more than one address, a TLV can be single value (associating the same attribute with each address) or multivalue (associating a separate attribute with each address).
アドレスブロックTLVは、1つのアドレスまたは連続する（アドレスブロックに格納されている）アドレスのセット（このセットがアドレスブロック内のすべてのアドレスである場合の特別な場合）の属性を提供します。複数のアドレスに関連付けられている場合、TLVは単一値（同じ属性を各アドレスに関連付ける）または複数値（個別の属性を各アドレスに関連付ける）にすることができます。
The approach that is simplest to implement is to use multivalue TLVs that cover all affected addresses. However, unless care is taken to order addresses appropriately, these affected addresses might not all be contiguous. Some approaches to this are the following:
実装が最も簡単なアプローチは、影響を受けるすべてのアドレスをカバーする複数値TLVを使用することです。ただし、アドレスを適切に順序付けるように注意しない限り、影響を受けるこれらのアドレスがすべて連続しているとは限りません。これに対するいくつかのアプローチは次のとおりです。
o Reorder the addresses. It is, for example, possible (though not straightforward, and beyond the scope of this document to describe exactly how) to order all addresses in HELLO message as specified in [RFC6130] so that all TLVs used only cover contiguous addresses. This is even possible if the MPR TLV specified in OLSRv2 [RFC7181] is added; but it is not possible, in general, if the LINK_METRIC TLV specified in OLSRv2 [RFC7181] is also added.
o アドレスを並べ替えます。たとえば、[RFC6130]で指定されているように、HELLOメッセージ内のすべてのアドレスを順序付けして、使用されているすべてのTLVが連続するアドレスのみをカバーするようにすることは可能です（簡単ではありません。これは、OLSRv2 [RFC7181]で指定されたMPR TLVが追加された場合でも可能です。ただし、一般的には、OLSRv2 [RFC7181]で指定されているLINK_METRIC TLVも追加されている場合は不可能です。
o Allow the TLV to span over addresses that do not need the corresponding attribute and use a Value that indicates no information; see Section 6.3.
o TLVが対応する属性を必要としないアドレスにまたがることを許可し、情報がないことを示す値を使用します。セクション6.3を参照してください。
o Use more than one TLV. Note that this can be efficient when the TLVs become single-value TLVs. In a typical case where a LINK_STATUS TLV uses only the Values HEARD and SYMMETRIC, with enough addresses sorted appropriately, two single-value TLVs can be more efficient than one multivalue TLV. If only one Value is involved (such as NHDP in a steady state with LINK_STATUS equal to SYMMETRIC in all cases) then one single-value TLV SHOULD always be used.
o複数のTLVを使用します。これは、TLVが単一値TLVになる場合に効率的であることに注意してください。 LINK_STATUS TLVが値HEARDおよびSYMMETRICのみを使用し、十分なアドレスが適切にソートされている一般的なケースでは、2つの単一値TLVが1つの複数値TLVよりも効率的です。 1つの値のみが関係する場合（すべての場合でLINK_STATUSがSYMMETRICに等しい定常状態のNHDPなど）、常に1つの単一値TLVを使用する必要があります（SHOULD）。
If, for example, an Address Block contains five addresses, the first two and the last two requiring Values assigned using a LINK_STATUS TLV but the third does not, then this can be indicated using two TLVs. It is, however, more efficient to do this with one multivalue LINK_STATUS TLV, assigning the third address the Value UNSPECIFIED (as defined in [RFC7188]). In general, use of UNSPECIFIED Values allows use of fewer TLVs and is thus often an efficiency gain; however, a long run of consecutive UNSPECIFIED Values (more than the overhead of a TLV) can make use of more TLVs more efficient.
たとえば、アドレスブロックに5つのアドレスが含まれている場合、最初の2つと最後の2つはLINK_STATUS TLVを使用して割り当てられた値を必要としますが、3つ目はそうではない場合、これは2つのTLVを使用して示すことができます。ただし、これを1つの複数値LINK_STATUS TLVで行い、3番目のアドレスに値UNSPECIFIED（[RFC7188]で定義されている）を割り当てると、より効率的です。一般に、UNSPECIFIED値を使用すると、使用するTLVが少なくなるため、多くの場合、効率が向上します。ただし、連続したUNSPECIFIED値を（TLVのオーバーヘッドよりも）長く実行すると、より多くのTLVをより効率的に使用できます。
Some other TLVs might need a different approach. As noted in [RFC7188], but implicitly permissible before then, the LINK_METRIC TLV (defined in [RFC7181]) has two octet Values whose first four bits are flags indicating whether the metric applies in four cases; if these are all zero, then the metric does not apply in this case, which is thus the equivalent of an UNSPECIFIED Value.
他の一部のTLVには、別のアプローチが必要な場合があります。 [RFC7188]で述べられているように、それ以前は暗黙的に許可されていたLINK_METRIC TLV（[RFC7181]で定義）には2つのオクテット値があり、最初の4ビットはメトリックが4つの場合に適用されるかどうかを示すフラグです。これらがすべてゼロの場合、この場合、メトリックは適用されません。したがって、これはUNSPECIFIED値と同等です。
[RFC7188] requires that protocols that extend [RFC6130] and [RFC7181] allow unspecified values in TLVs where applicable; it is here RECOMMENDED that all protocols follow that advice. In particular, it is RECOMMENDED that when defining an Address Block TLV with discrete Values, an UNSPECIFIED Value is defined with the same value (255), and a modified approach should be used where possible for other Address Block TLVs (for example, as is done for a LINK_METRIC TLV, though not necessarily using that exact approach).
[RFC7188]は、[RFC6130]および[RFC7181]を拡張するプロトコルが、該当する場合、TLVで未指定の値を許可することを要求します。ここでは、すべてのプロトコルがそのアドバイスに従うことをお勧めします。特に、個別の値でアドレスブロックTLVを定義する場合、UNSPECIFIED値を同じ値（255）で定義し、他のアドレスブロックTLVで可能な場合は変更されたアプローチを使用することをお勧めします（たとえば、現状のまま） LINK_METRIC TLVに対して行われますが、必ずしもその正確なアプローチを使用しているわけではありません）。
It might be argued that provision of an unspecified value (of any form) to allow an Address Block TLV to cover unaffected addresses is not always necessary because addresses can be reordered to avoid this. However, ordering addresses to avoid this for all TLVs that might be used is not, in general, possible.
アドレスブロックTLVが影響を受けないアドレスをカバーできるようにするために、（任意の形式の）未指定の値を提供することは必ずしも必要ではない、というのは、アドレスを並べ替えてこれを回避できるためです。ただし、一般に、使用される可能性のあるすべてのTLVに対してこれを回避するためにアドレスを順序付けることはできません。
In addition, [RFC7188] recommends that if a TLV Value (per address for an Address Block TLV) has a single-length that does not match the defined length for that TLV Type, then the following rules are adopted:
さらに、[RFC7188]は、TLV値（アドレスブロックTLVのアドレスごと）が、そのTLVタイプに定義された長さに一致しない単一の長さを持っている場合、次の規則が採用されることを推奨しています：
o If the received single-length is greater than the expected single length, then the excess octets MUST be ignored.
o 受信したシングルレングスが予想されるシングルレングスよりも大きい場合、過剰なオクテットは無視されなければなりません（MUST）。
o If the received single-length is less than the expected single length, then the absent octets MUST be considered to have all bits cleared (0).
o 受信した単一の長さが予想される単一の長さよりも短い場合、存在しないオクテットはすべてのビットがクリアされている（0）と見なされなければなりません（MUST）。
This specification RECOMMENDS a similar rule for all protocols defining new TLVs.
この仕様は、新しいTLVを定義するすべてのプロトコルに対して同様のルールを推奨します。
This document does not specify a protocol but provides rules and recommendations for how to design protocols using [RFC5444], whose security considerations apply.
このドキュメントではプロトコルを指定していませんが、セキュリティに関する考慮事項が適用される[RFC5444]を使用してプロトコルを設計する方法のルールと推奨事項を提供しています。
If the recommendation from Section 4.4.1 is followed, which specifies that messages are not modified (except for hop count and hop limit) when forwarded, then the security framework for [RFC5444] (specified in [RFC7182]) can be used in full. If that recommendation is not followed, then the Packet TLVs from [RFC7182] can be used, but the Message TLVs from [RFC7182] cannot be used as intended.
転送時にメッセージが変更されない（ホップカウントとホップリミットを除く）ことを指定するセクション4.4.1の推奨に従う場合、[RFC5444]のセキュリティフレームワーク（[RFC7182]で指定）を完全に使用できます。 。その推奨に従わない場合、[RFC7182]のパケットTLVは使用できますが、[RFC7182]のメッセージTLVは意図したとおりに使用できません。
In either case, a protocol using [RFC5444] MUST document whether it is using [RFC7182] and if so, how.
どちらの場合でも、[RFC5444]を使用するプロトコルは、[RFC7182]を使用しているかどうか、使用している場合は、その方法を文書化する必要があります。
The Expert Review guidelines in [RFC5444] are updated to include the general requirement that:
[RFC5444]のExpert Reviewガイドラインが更新され、以下の一般的な要件が含まれています。
o The Designated Expert will consider the limited TLV and (especially) Message Type space when considering whether a requested allocation is allowed and whether a more efficient allocation than that requested is possible.
o Designated Expertは、要求された割り当てが許可されるかどうか、および要求された割り当てよりも効率的な割り当てが可能かどうかを検討するときに、制限されたTLVおよび（特に）メッセージタイプスペースを検討します。
IANA has added this document as a reference for the following Mobile Ad hoc NETwork (MANET) Parameters registries:
IANAは、次のモバイルアドホックネットワーク（MANET）パラメータレジストリのリファレンスとしてこのドキュメントを追加しました。
o Message Types o Packet TLV Types o Message TLV Types o Address Block TLV Types
o パケットのメッセージタイプTLVメッセージのTLVタイプアドレスブロックのTLVタイプTLVタイプ
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format", RFC 5444, DOI 10.17487/RFC5444, February 2009, <https://www.rfc-editor.org/info/rfc5444>.
[RFC5444] Clausen、T.、Dearlove、C.、Dean、J。、およびC. Adjih、「Generalized Mobile Ad Hoc Network（MANET）Packet / Message Format」、RFC 5444、DOI 10.17487 / RFC5444、2009年2月、< https://www.rfc-editor.org/info/rfc5444>。
[RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols", RFC 5498, DOI 10.17487/RFC5498, March 2009, <https://www.rfc-editor.org/info/rfc5498>.
[RFC5498] Chakeres、I。、「モバイルアドホックネットワーク（MANET）プロトコルのIANA割り当て」、RFC 5498、DOI 10.17487 / RFC5498、2009年3月、<https://www.rfc-editor.org/info/rfc5498> 。
[RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)", RFC 7182, DOI 10.17487/RFC7182, April 2014, <https://www.rfc-editor.org/info/rfc7182>.
[RFC7182] Herberg、U.、Clauseen、T。、およびC. Dearlove、「モバイルアドホックネットワーク（MANET）の整合性チェック値およびタイムスタンプTLV定義」、RFC 7182、DOI 10.17487 / RFC7182、2014年4月、<https： //www.rfc-editor.org/info/rfc7182>。
[RFC7631] Dearlove, C. and T. Clausen, "TLV Naming in the Mobile Ad Hoc Network (MANET) Generalized Packet/Message Format", RFC 7631, DOI 10.17487/RFC7631, September 2015, <https://www.rfc-editor.org/info/rfc7631>.
[RFC7631] Dearlove、C。およびT. Clausen、「モバイルアドホックネットワーク（MANET）の一般化されたパケット/メッセージ形式におけるTLV命名」、RFC 7631、DOI 10.17487 / RFC7631、2015年9月、<https：//www.rfc -editor.org/info/rfc7631>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[G9903] ITU-T, "G.9903 : Narrowband orthogonal frequency division multiplexing power line communication transceivers for G3-PLC networks", ITU-T Recommendation G.9903, August 2017.
[G9903] ITU-T、「G.9903：G3-PLCネットワーク用の狭帯域直交周波数分割多重電力線通信トランシーバー」、ITU-T勧告G.9903、2017年8月。
[RFC3626] Clausen, T., Ed. and P. Jacquet, Ed., "Optimized Link State Routing Protocol (OLSR)", RFC 3626, DOI 10.17487/RFC3626, October 2003, <https://www.rfc-editor.org/info/rfc3626>.
[RFC3626]クラウセン、T。、エド。およびP. Jacquet編、「Optimized Link State Routing Protocol（OLSR）」、RFC 3626、DOI 10.17487 / RFC3626、2003年10月、<https://www.rfc-editor.org/info/rfc3626>。
[RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, DOI 10.17487/RFC5497, March 2009, <https://www.rfc-editor.org/info/rfc5497>.
[RFC5497] Clausen、T。およびC. Dearlove、「モバイルアドホックネットワーク（MANET）での多値時間の表現」、RFC 5497、DOI 10.17487 / RFC5497、2009年3月、<https：//www.rfc-editor。 org / info / rfc5497>。
[RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, DOI 10.17487/RFC6130, April 2011, <https://www.rfc-editor.org/info/rfc6130>.
[RFC6130] Clausen、T.、Dearlove、C。、およびJ. Dean、「Mobile Ad Hoc Network（MANET）Neighborhood Discovery Protocol（NHDP）」、RFC 6130、DOI 10.17487 / RFC6130、2011年4月、<https：// www.rfc-editor.org/info/rfc6130>。
[RFC6621] Macker, J., Ed., "Simplified Multicast Forwarding", RFC 6621, DOI 10.17487/RFC6621, May 2012, <https://www.rfc-editor.org/info/rfc6621>.
[RFC6621] Macker、J。、編、「Simplified Multicast Forwarding」、RFC 6621、DOI 10.17487 / RFC6621、2012年5月、<https://www.rfc-editor.org/info/rfc6621>。
[RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, "The Optimized Link State Routing Protocol Version 2", RFC 7181, DOI 10.17487/RFC7181, April 2014, <https://www.rfc-editor.org/info/rfc7181>.
[RFC7181] Clausen、T.、Dearlove、C.、Jacquet、P.、U。Herberg、「The Optimized Link State Routing Protocol Version 2」、RFC 7181、DOI 10.17487 / RFC7181、2014年4月www.rfc-editor.org/info/rfc7181>。
[RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)", RFC 7183, DOI 10.17487/RFC7183, April 2014, <https://www.rfc-editor.org/info/rfc7183>.
[RFC7183] Herberg、U.、Dearlove、C。、およびT. Clausen、「Integrity Protection for the Neighborhood Discovery Protocol（NHDP）and Optimized Link State Routing Protocol Version 2（OLSRv2）」、RFC 7183、DOI 10.17487 / RFC7183、 2014年4月、<https://www.rfc-editor.org/info/rfc7183>。
[RFC7188] Dearlove, C. and T. Clausen, "Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs", RFC 7188, DOI 10.17487/RFC7188, April 2014, <https://www.rfc-editor.org/info/rfc7188>.
[RFC7188] Dearlove、C。およびT. Clausen、「Optimized Link State Routing Protocol Version 2（OLSRv2）and MANET Neighborhood Discovery Protocol（NHDP）Extension TLVs」、RFC 7188、DOI 10.17487 / RFC7188、2014年4月、<https：/ /www.rfc-editor.org/info/rfc7188>。
[RFC7722] Dearlove, C. and T. Clausen, "Multi-Topology Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2)", RFC 7722, DOI 10.17487/RFC7722, December 2015, <https://www.rfc-editor.org/info/rfc7722>.
[RFC7722] Dearlove、C。およびT. Clausen、「最適化されたリンクステートルーティングプロトコルバージョン2（OLSRv2）のマルチトポロジ拡張」、RFC 7722、DOI 10.17487 / RFC7722、2015年12月、<https：//www.rfc -editor.org/info/rfc7722>。
This section describes a conceptual way to consider the information in a message. It can be used as the basis of an approach to parsing a message from the information that it contains and to creating a message from the information that it is to contain. However, there is no requirement that a protocol does so. This approach can be used either to inform a protocol design or by a protocol (or generic parser) implementer.
このセクションでは、メッセージ内の情報を検討するための概念的な方法について説明します。これは、メッセージに含まれる情報からメッセージを解析し、メッセージに含まれる情報からメッセージを作成するアプローチの基礎として使用できます。ただし、プロトコルがそうする必要はありません。このアプローチは、プロトコル設計に通知するために、またはプロトコル（または汎用パーサー）の実装者によって使用できます。
A message (excluding the Message Header) can be represented by two, possibly multivalued, maps:
メッセージ（メッセージヘッダーを除く）は、2つの、場合によっては多値のマップで表すことができます。
o Message: (Full Type) -> (length, Value)
o メッセージ：（フルタイプ）->（長さ、値）
o Address: (address, Full Type) -> (length, Value)
o アドレス：（アドレス、フルタイプ）->（長さ、値）
These maps (plus a representation of the Message Header) can be the basis for a generic representation of information in a message. Such maps can be created by parsing the message or can be constructed using the protocol rules for creating a message and later converted into the octet form of the message specified in [RFC5444].
これらのマップ（およびメッセージヘッダーの表現）は、メッセージ内の情報の一般的な表現の基礎となります。このようなマップは、メッセージを解析することによって作成するか、メッセージを作成するためのプロトコルルールを使用して構築し、後で[RFC5444]で指定されているメッセージのオクテット形式に変換することができます。
While of course any implementation of software that represents software in the above form can specify an Application Programming Interface (API) for that software, such an interface is not proposed here. First, a full API would be specific to a programming language. Second, even within the above framework, there are alternative approaches to such an interface. For example, and for illustrative purposes only, consider the alternative address mappings:
もちろん、上記の形式のソフトウェアを表すソフトウェアの実装では、そのソフトウェアのアプリケーションプログラミングインターフェイス（API）を指定できますが、そのようなインターフェイスはここでは提案していません。まず、完全なAPIはプログラミング言語に固有です。第二に、上記のフレームワーク内であっても、そのようなインターフェースには別のアプローチがあります。たとえば、説明の目的でのみ、代替アドレスマッピングを検討してください。
o Input: address and Full Type. Output: list of (length, Value) pairs. Note that for most Full Types, it will be known in advance that this list will have a length of zero or one. The list of addresses that can be used as inputs with non-empty output would need to be provided as a separate output.
o 入力：住所とフルタイプ。出力：（長さ、値）のペアのリスト。ほとんどのフルタイプでは、このリストの長さが0または1であることが事前にわかっていることに注意してください。空でない出力を持つ入力として使用できるアドレスのリストは、別の出力として提供する必要があります。
o Input: Full Type. Output: list of (address, length, Value) triples. As this list length can be significant, a possible output will be of one or two iterators that will allow iterating through that list. (One iterator that can detect the end of the list or a pair of iterators specifying a range.)
o 入力：フルタイプ。出力：（アドレス、長さ、値）トリプルのリスト。このリストの長さは重要になる可能性があるため、可能な出力は、そのリストを反復できる1つまたは2つの反復子になります。 （リストの終わりを検出できる1つのイテレーター、または範囲を指定する2つのイテレーター。）
Additional differences in the interface might relate to, for example, the ordering of output lists.
インターフェースのその他の違いは、例えば、出力リストの順序に関連している可能性があります。
There is scope for creating a protocol-independent optimizer for [RFC5444] messages that performs appropriate address re-organization (ordering and Address Block separation) and TLV changes (of number, of being single value or multivalue, and use of unspecified values) to create more compact messages. The possible gain depends on the efficiency of the original message creation and the specific details of the message. Note that this process cannot be TLV Type independent; for example, a LINK_METRIC TLV has a more complicated Value structure than a LINK_STATUS TLV does if using UNSPECIFIED Values.
プロトコルに依存しない[RFC5444]メッセージ用のオプティマイザを作成するためのスコープがあり、適切なアドレス再編成（順序とアドレスブロックの分離）およびTLV変更（番号、単一値または複数値、および未指定値の使用）を実行します。よりコンパクトなメッセージを作成します。可能な利益は、元のメッセージ作成の効率とメッセージの特定の詳細に依存します。このプロセスはTLVタイプに依存しないことに注意してください。たとえば、LINK_METRIC TLVは、UNSPECIFIED値を使用する場合、LINK_STATUS TLVよりも複雑なValue構造を持っています。
Such a protocol-independent optimizer MAY be used by the router generating a message but MUST NOT be used on a message that is forwarded unchanged by a router.
このようなプロトコルに依存しないオプティマイザは、メッセージを生成するルーターによって使用される場合がありますが、ルーターによって変更されずに転送されるメッセージに対しては使用してはなりません（MUST NOT）。
Acknowledgments
謝辞
The authors thank Cedric Adjih (INRIA) and Justin Dean (NRL) for their contributions as authors of RFC 5444.
著者は、RFC 5444の著者として貢献してくれたCedric Adjih（INRIA）とJustin Dean（NRL）に感謝します。
Authors' Addresses
著者のアドレス
Thomas Clausen Ecole Polytechnique 91128 Palaiseau Cedex France
Thomas Clausen Ecole Polytechnique 91128パレゾーセデックスフランス
Phone: +33-6-6058-9349
Email: T.Clausen@computer.org
URI: http://www.thomasclausen.org
Christopher Dearlove BAE Systems Applied Intelligence Laboratories West Hanningfield Road Great Baddow, Chelmsford United Kingdom
Christopher Dearlove BAE Systems Applied Intelligence Laboratoriesウェストハニングフィールドロードイギリス、チェルムズフォード、グレートバッドウ
Email: chris.dearlove@baesystems.com
URI: http://www.baesystems.com
Ulrich Herberg
ウルリッヒ・ヘルベルク
Email: ulrich@herberg.name
URI: http://www.herberg.name
Henning Rogge Fraunhofer FKIE Fraunhofer Strasse 20 53343 Wachtberg Germany
Henning Rogge Fraunhofer FKIE Fraunhofer Strasse 20 53343ヴァヒトベルクドイツ
Email: henning.rogge@fkie.fraunhofer.de