[要約] RFC 7188は、OLSRv2とNHDPの拡張TLVに関するものであり、MANETネットワークでの最適化されたリンク状態ルーティングプロトコルのバージョン2を提供します。このRFCの目的は、MANETネットワークでの効率的なルーティングとネイバーディスカバリを実現するための拡張TLVの仕様を提供することです。
Internet Engineering Task Force (IETF) C. Dearlove
Request for Comments: 7188 BAE Systems ATC
Updates: 6130, 7181 T. Clausen
Category: Standards Track LIX, Ecole Polytechnique
ISSN: 2070-1721 April 2014
Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs
最適化されたリンク状態ルーティングプロトコルバージョン2（OLSRv2）およびMANET近隣探索プロトコル（NHDP）拡張TLV
Abstract
概要
This specification describes extensions to definitions of TLVs used by the Optimized Link State Routing Protocol version 2 (OLSRv2) and the MANET Neighborhood Discovery Protocol (NHDP) to increase their abilities to accommodate protocol extensions. This document updates RFC 7181 (OLSRv2) and RFC 6130 (NHDP).
この仕様では、最適化されたリンク状態ルーティングプロトコルバージョン2（OLSRv2）とMANET近隣探索プロトコル（NHDP）がプロトコル拡張に対応する能力を高めるために使用するTLVの定義に対する拡張について説明します。このドキュメントは、RFC 7181（OLSRv2）およびRFC 6130（NHDP）を更新します。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7188.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7188で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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トラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 3
4. TLV Values . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Unrecognized TLV Values . . . . . . . . . . . . . . . . . 4
4.2. TLV Value Lengths . . . . . . . . . . . . . . . . . . . . 5
4.3. Undefined TLV Values . . . . . . . . . . . . . . . . . . 5
4.3.1. NHDP TLVs: LOCAL_IF, LINK_STATUS, and OTHER_NEIGHB . 6
4.3.2. OLSRv2 TLVs: MPR and NBR_ADDR_TYPE . . . . . . . . . 6
4.3.3. Unspecified TLV Values . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5.1. LOCAL_IF Address Block TLVs . . . . . . . . . . . . . . . 7
5.1.1. New Registry . . . . . . . . . . . . . . . . . . . . 7
5.1.2. Modification to Existing Registry . . . . . . . . . . 8
5.2. LINK_STATUS Address Block TLVs . . . . . . . . . . . . . 8
5.2.1. New Registry . . . . . . . . . . . . . . . . . . . . 8
5.2.2. Modification to Existing Registry . . . . . . . . . . 9
5.3. OTHER_NEIGHB Address Block TLVs . . . . . . . . . . . . . 10
5.3.1. Create New Registry . . . . . . . . . . . . . . . . . 10
5.3.2. Modification to Existing Registry . . . . . . . . . . 11
5.4. MPR Address Block TLVs . . . . . . . . . . . . . . . . . 11
5.4.1. New Registry . . . . . . . . . . . . . . . . . . . . 11
5.4.2. Modification to Existing Registry . . . . . . . . . . 12
5.5. NBR_ADDR_TYPE Address Block TLVs . . . . . . . . . . . . 12
5.5.1. New Registry . . . . . . . . . . . . . . . . . . . . 12
5.5.2. Modification to Existing Registry . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 15
The MANET Neighborhood Discovery Protocol (NHDP) [RFC6130] and the Optimized Link State Routing Protocol version 2 (OLSRv2) [RFC7181] are protocols for use in Mobile Ad Hoc Networks (MANETs) [RFC2501], based on the Generalized MANET Packet/Message Format [RFC5444].
MANET Neighborhood Discovery Protocol（NHDP）[RFC6130]およびOptimized Link State Routing Protocolバージョン2（OLSRv2）[RFC7181]は、モバイルアドホックネットワーク（MANET）[RFC2501]で使用されるプロトコルであり、一般化されたMANETパケット/メッセージに基づいています。フォーマット[RFC5444]。
This document updates [RFC6130] and [RFC7181], specifically their use of TLV (Type-Length-Value) elements, to increase the extensibility of these protocols and to enable some improvements in their implementation.
このドキュメントは、[RFC6130]と[RFC7181]、特にTLV（Type-Length-Value）要素の使用を更新して、これらのプロトコルの拡張性を高め、実装のいくつかの改善を可能にします。
This specification reduces the latitude of implementations of [RFC6130] and [RFC7181] to consider some messages, which will not be created by implementations simply following those specifications, as a reason to consider the message as "badly formed", and thus as a reason to reject the message. This gives greater latitude to the creation of extensions of these protocols, in particular extensions that will interoperate with unextended implementations of those protocols. As part of that, it indicates how TLVs with unexpected value fields must be handled, and adds some additional options to those TLVs.
この仕様は、[RFC6130]と[RFC7181]の実装の自由度を減らし、メッセージを「不正な形式」と見なす理由として、これらの仕様に従うだけの実装では作成されないメッセージを考慮します。メッセージを拒否します。これにより、これらのプロトコルの拡張、特にこれらのプロトコルの拡張されていない実装と相互運用する拡張の作成により大きな自由度が与えられます。その一部として、予期しない値フィールドを持つTLVの処理方法を示し、それらのTLVにいくつかの追加オプションを追加します。
Note that TLVs with unknown type or type extension are already specified as to be ignored by [RFC6130] and [RFC7181] and also are not a reason to reject a message.
タイプまたはタイプの拡張子が不明なTLVは、[RFC6130]および[RFC7181]によって無視されるようにすでに指定されており、メッセージを拒否する理由にもならないことに注意してください。
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」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
Additionally, this document uses the terminology of [RFC5444], [RFC6130], and [RFC7181].
さらに、このドキュメントでは、[RFC5444]、[RFC6130]、および[RFC7181]という用語を使用しています。
This document updates the specification of the protocols described in [RFC6130] and [RFC7181].
このドキュメントは、[RFC6130]と[RFC7181]で説明されているプロトコルの仕様を更新します。
Specifically, this specification updates [RFC6130] and [RFC7181] in the following ways:
具体的には、この仕様は[RFC6130]と[RFC7181]を次のように更新します。
o Removes the latitude of rejecting a message with a TLV with a known type, but with an unexpected TLV Value field, for the TLV Types defined in [RFC6130] and [RFC7181].
o [RFC6130]および[RFC7181]で定義されているTLVタイプについて、既知のタイプのTLVで予期しないTLV値フィールドを持つメッセージを拒否する寛容さを排除します。
o Specifies the handling of a TLV Value field with unexpected length.
o 予期しない長さのTLV値フィールドの処理を指定します。
o Sets up IANA registries for TLV Values for the Address Block TLVs:
o アドレスブロックTLVのTLV値のIANAレジストリを設定します。
* LOCAL_IF, defined in [RFC6130].
* [RFC6130]で定義されているLOCAL_IF。
* LINK_STATUS, defined in [RFC6130].
* LINK_STATUS、[RFC6130]で定義されています。
* OTHER_NEIGHB, defined in [RFC6130].
* OTHER_NEIGHB、[RFC6130]で定義。
* MPR, defined in [RFC7181], now considered as a bit field.
* [RFC7181]で定義されたMPRは、ビットフィールドと見なされます。
* NBR_ADDR_TYPE, defined in [RFC7181], now considered as a bit field.
* [RFC7181]で定義されているNBR_ADDR_TYPEは、ビットフィールドと見なされます。
o Defines a well-known TLV Value for "UNSPECIFIED" for the Address Block TLV Types LOCAL_IF, LINK_STATUS, and OTHER_NEIGHB, all defined in [RFC6130].
o アドレスブロックTLVタイプLOCAL_IF、LINK_STATUS、およびOTHER_NEIGHBの「UNSPECIFIED」の既知のTLV値を定義します。これらはすべて[RFC6130]で定義されています。
NHDP [RFC6130] and OLSRv2 [RFC7181] define a number of TLVs within the framework of [RFC5444]. These TLVs define the meaning of only some of the contents that can be found in a TLV Value field. This limitation may be either defining only certain TLV Values or considering only some lengths of the TLV Value fields (or a single-value field in a multivalue Address-Block TLV). This specification describes how NHDP [RFC6130] and OLSRv2 [RFC7181] are to handle TLVs with other TLV Value fields.
NHDP [RFC6130]およびOLSRv2 [RFC7181]は、[RFC5444]のフレームワーク内でいくつかのTLVを定義します。これらのTLVは、TLV値フィールドにある一部のコンテンツのみの意味を定義します。この制限は、特定のTLV値のみを定義するか、TLV値フィールド（または複数値のアドレスブロックTLVの単一値フィールド）の一部の長さのみを考慮するかのいずれかです。この仕様は、NHDP [RFC6130]およびOLSRv2 [RFC7181]が他のTLV値フィールドでTLVを処理する方法を説明します。
NHDP and OLSRv2 specify that, in addition to well-defined reasons (in the respective protocol specifications), an implementation of these protocols MAY recognize a message as "badly formed" and therefore "invalid for processing" for other reasons (Section 12.1 of [RFC6130] and Section 16.3.1 of [RFC7181]). These sections could be interpreted as allowing rejection of a message because a TLV Value field is unrecognized. This specification removes that latitude:
NHDPとOLSRv2は、（それぞれのプロトコル仕様で）明確に定義された理由に加えて、これらのプロトコルの実装がメッセージを「不正な形式」として認識し、したがって他の理由から「処理に無効」であることを指定しています（[ RFC6130]および[RFC7181]のセクション16.3.1）。 TLV値フィールドが認識されないため、これらのセクションはメッセージの拒否を許可すると解釈できます。この仕様はその緯度を削除します：
o An implementation MUST NOT reject a message because it contains an unrecognized TLV value. Instead, any unrecognized TLV Value field MUST be processed or ignored by an unextended implementation of NHDP or OLSRv2, as described in the following sections.
o 認識できないTLV値が含まれているため、実装はメッセージを拒否してはなりません（MUST NOT）。代わりに、認識されないTLV値フィールドは、次のセクションで説明するように、NHDPまたはOLSRv2の拡張されていない実装によって処理または無視される必要があります。
o Hence, this specification removes the 7th, 10th, and 11th bullets in Section 12.1 of [RFC6130].
o したがって、この仕様では、[RFC6130]のセクション12.1の7、10、11番目の箇条書きが削除されています。
It should be stressed that this is not a change to [RFC6130] or [RFC7181], except with regard to not allowing this to be a reason for rejection of a message. [RFC6130] or [RFC7181] are specified in terms such as "if an address is associated with a value of LOST by a LINK_STATUS TLV". Association with an unrecognized value has no effect on any implementation strictly following such a specification.
これが[RFC6130]または[RFC7181]への変更ではないことを強調する必要があります。ただし、これがメッセージの拒否の理由となることを許可しない場合を除きます。 [RFC6130]または[RFC7181]は、「アドレスがLINK_STATUS TLVによってLOSTの値に関連付けられている場合」などの用語で指定されます。認識されない値との関連付けは、そのような仕様に厳密に従っている実装には影響しません。
The TLVs specified in [RFC6130] and [RFC7181] may be either single-value or multivalue TLVs. In either case, the length of each item of information encoded in the TLV Value field is the "single-length", defined and calculated as in Section 5.4.1 of [RFC5444]. All TLVs specified in [RFC6130] and [RFC7181] have a one- or two-octet single-length. These are considered the expected single-lengths of such a received TLV.
[RFC6130]および[RFC7181]で指定されているTLVは、単一値または複数値のTLVのいずれかです。どちらの場合も、TLV値フィールドにエンコードされた各情報項目の長さは「単一の長さ」であり、[RFC5444]のセクション5.4.1のように定義および計算されます。 [RFC6130]と[RFC7181]で指定されているすべてのTLVは、1オクテットまたは2オクテットのシングルレングスです。これらは、そのような受信されたTLVの予想される単一長と見なされます。
Other single-length TLV Value fields may be introduced by extensions to [RFC6130] and [RFC7181]. This document specifies how implementations of [RFC6130] and [RFC7181], or extensions thereof, MUST behave on receiving TLVs of the TLV types defined in [RFC6130] and [RFC7181], but with TLV Value fields with other single-length values.
[RFC6130]および[RFC7181]の拡張により、他の長さのTLV値フィールドが導入される場合があります。このドキュメントは、[RFC6130]と[RFC7181]、またはその拡張の実装が、[RFC6130]と[RFC7181]で定義されたTLVタイプのTLVを受信する際にどのように動作するかを指定する必要があります。
The following principles apply:
次の原則が適用されます。
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）。
Exception:
例外：
o A received CONT_SEQ_NUM with a single-length < 2 SHOULD be considered an error.
o 単一の長さが2未満の受信されたCONT_SEQ_NUMは、エラーと見なされるべきです（SHOULD）。
[RFC6130] and [RFC7181] define a number of TLVs, but for some of these TLVs they specify meanings for only some TLV Values. This document establishes IANA registries for these TLV Values, with initial registrations reflecting those used by [RFC6130] and [RFC7181], and as specified in Section 4.3.3.
[RFC6130]と[RFC7181]はいくつかのTLVを定義していますが、これらのTLVの一部では、一部のTLV値の意味のみを指定しています。このドキュメントは、[RFC6130]と[RFC7181]で使用されているものを反映し、セクション4.3.3で指定されているように、これらのTLV値のIANAレジストリを確立します。
There are different cases of TLV Values with different characteristics. These cases are considered in this section.
さまざまな特性を持つTLV値のさまざまなケースがあります。これらのケースはこのセクションで考慮されます。
For the Address-Block TLVs LOCAL_IF, LINK_STATUS, and OTHER_NEIGHB TLVs, defined in [RFC6130], only a limited number of values are specified for each. These are converted, by this specification, into extensible registries with initial registrations for values defined and used by [RFC6130] -- see Section 5.
[RFC6130]で定義されているアドレスブロックTLVのLOCAL_IF、LINK_STATUS、およびOTHER_NEIGHB TLVについては、それぞれに限られた数の値のみが指定されています。これらは、この仕様により、[RFC6130]によって定義および使用される値の初期登録を持つ拡張可能なレジストリに変換されます。セクション5を参照してください。
An implementation of [RFC6130] that receives a LOCAL_IF, LINK_STATUS, or OTHER_NEIGHB TLV with any TLV Value other than the values that are defined in [RFC6130] MUST ignore that TLV Value, as well as any corresponding attribute association to the address.
[RFC6130]で定義されている値以外のTLV値を持つLOCAL_IF、LINK_STATUS、またはOTHER_NEIGHB TLVを受信する[RFC6130]の実装は、そのTLV値、およびアドレスに対応する属性の関連付けを無視する必要があります。
The Address-Block TLVs MPR and NBR_ADDR_TYPE, defined in [RFC7181], are similar to those defined in [RFC6130] in having only limited values specified (1, 2, and 3): 1 and 2 represent the presence of two different attributes associated to an address, and 3 represents "both 1 and 2".
[RFC7181]で定義されているアドレスブロックTLV MPRおよびNBR_ADDR_TYPEは、[RFC6130]で定義されているものと類似しており、指定された値が制限されています（1、2、および3）。1および2は、関連付けられた2つの異なる属性の存在を表します。 3は「1と2の両方」を表します。
These TLV Value fields are, by this specification, converted to bit fields and MUST be interpreted as such. As the existing definitions of values 1, 2, and 3 behave in that manner, it is likely that this will involve no change to an implementation, but any test of (for example) Value = 1 or Value = 3 MUST be converted to a test of (for example) Value bitand 1 = 1, where "bitand" denotes a bitwise AND operation.
これらのTLV値フィールドは、この仕様により、ビットフィールドに変換され、そのように解釈する必要があります。値1、2、および3の既存の定義はそのように動作するため、これは実装への変更を含まない可能性が高いですが、（たとえば）値= 1または値= 3のテストは、 （たとえば）値のテストbitand 1 = 1ここで、「bitand」はビットごとのAND演算を示します。
This specification creates registries for recording reservations of the individual bits in these bit fields, with initial registrations for values defined and used by [RFC7181] -- see Section 5.
この仕様は、これらのビットフィールドの個々のビットの予約を記録するためのレジストリを作成し、[RFC7181]によって定義および使用される値の初期登録を行います。セクション5を参照してください。
Other TLVs defined by [RFC7181] are not affected by this specification.
[RFC7181]で定義されている他のTLVは、この仕様の影響を受けません。
The registries defined in Section 5 for the LOCAL_IF, LINK_STATUS, and OTHER_NEIGHB TLVs each include an additional TLV Value UNSPECIFIED. This TLV Value represents a defined value that, like currently undefined TLV Values, indicates that no information is associated with this address; the defined value will always have this meaning. Such a TLV Value may be used to enable the creation of more efficient multivalue Address Block TLVs or to simplify an implementation.
セクション5で定義されたLOCAL_IF、LINK_STATUS、およびOTHER_NEIGHB TLVのレジストリには、それぞれ追加のTLV値UNSPECIFIEDが含まれています。このTLV値は、現在未定義のTLV値と同様に、このアドレスに関連付けられている情報がないことを示す定義済みの値を表します。定義された値は常にこの意味を持ちます。このようなTLV値は、より効率的な多値アドレスブロックTLVの作成を可能にするため、または実装を簡素化するために使用できます。
The similar requirement for the MPR and NBR_ADDR_TYPES TLVs is already satisfied by the TLV Value zero, provided that each bit in the TLV Value is defined as set ('1') when indicating the presence of an attribute, or clear ('0') when indicating the absence of an attribute. Therefore, this is required for registrations from the relevant registries; see Section 5.
MPRおよびNBR_ADDR_TYPES TLVの同様の要件は、TLV値の各ビットが属性の存在を示すときにセット（ '1'）またはクリア（ '0'）として定義されている場合、TLV値ゼロによってすでに満たされています。属性がないことを示す場合。したがって、これは関連するレジストリからの登録に必要です。セクション5を参照してください。
For the LINK_METRIC TLV, this is already possible by clearing the most significant bits (0 to 3) of the first octet of the TLV Value. It is RECOMMENDED that in this case the remaining bits of the TLV Value are either all clear ('0') or all set ('1').
LINK_METRIC TLVの場合、これはTLV値の最初のオクテットの最上位ビット（0〜3）をクリアすることですでに可能です。この場合、TLV値の残りのビットはすべてクリア（「0」）またはすべてセット（「1」）にすることをお勧めします。
IANA has completed the ten actions set out in the following sections.
IANAは、次のセクションで説明する10のアクションを完了しました。
IANA has created a new sub-registry called "LOCAL_IF TLV Values" within the "Mobile Ad hoc NETwork (MANET) Parameters" registry.
IANAは、「モバイルアドホックネットワーク（MANET）パラメータ」レジストリ内に「LOCAL_IF TLV値」と呼ばれる新しいサブレジストリを作成しました。
IANA has populated this registry as specified in Table 1.
IANAは、表1に指定されているように、このレジストリにデータを入力しました。
+---------+-------------+-------------------------------+-----------+
| Value | Name | Description | Reference |
+---------+-------------+-------------------------------+-----------+
| 0 | THIS_IF | The network address is | RFC 7188 |
| | | associated with this local | |
| | | interface of the sending | |
| | | router | |
| | | | |
| 1 | OTHER_IF | The network address is | RFC 7188 |
| | | associated with another local | |
| | | interface of the sending | |
| | | router | |
| | | | |
| 2-223 | | Unassigned | |
| | | | |
| 224-254 | | Reserved for Experimental Use | RFC 7188 |
| | | | |
| 255 | UNSPECIFIED | No information about this | RFC 7188 |
| | | network address is provided | |
+---------+-------------+-------------------------------+-----------+
Table 1: LOCAL_IF TLV Values
表1：LOCAL_IF TLV値
New assignments are to be made by Expert Review [RFC5226].
新しい割り当てはExpert Review [RFC5226]によって行われます。
The Designated Experts are required to use the guidelines specified in [RFC6130] and [RFC7181].
Designated Expertsは、[RFC6130]と[RFC7181]で指定されたガイドラインを使用する必要があります。
IANA maintains a sub-registry called "LOCAL_IF Address Block TLV Type Extensions" within the "Mobile Ad hoc NETwork (MANET) Parameters" registry. This sub-registry already had an entry for value 0. IANA has replaced the entry in the Description column for this value with the text "This value is to be interpreted according to the registry LOCAL_IF TLV Values". The resulting table is as specified in Table 2.
IANAは、「モバイルアドホックネットワーク（MANET）パラメータ」レジストリ内に「LOCAL_IFアドレスブロックTLVタイプ拡張」と呼ばれるサブレジストリを保持しています。このサブレジストリにはすでに値0のエントリがありました。IANAはこの値の[説明]列のエントリを「この値はレジストリLOCAL_IF TLV値に従って解釈される」というテキストに置き換えました。結果の表は、表2で指定したとおりです。
+-----------+-----------------------------------------+-------------+
| Type | Description | Reference |
| Extension | | |
+-----------+-----------------------------------------+-------------+
| 0 | This value is to be interpreted | RFC 6130, |
| | according to the registry LOCAL_IF TLV | RFC 7188 |
| | Values | |
| | | |
| 1-255 | Unassigned | |
+-----------+-----------------------------------------+-------------+
Table 2: LOCAL_IF Address Block TLV Type Extensions Modifications
表2：LOCAL_IFアドレスブロックTLVタイプ拡張の変更
IANA has created a new sub-registry called "LINK_STATUS TLV Values" within the "Mobile Ad hoc NETwork (MANET) Parameters" registry.
IANAは、「モバイルアドホックネットワーク（MANET）パラメータ」レジストリ内に「LINK_STATUS TLV値」という新しいサブレジストリを作成しました。
IANA has populated this registry as specified in Table 3.
IANAは、表3で指定されているように、このレジストリにデータを入力しました。
+---------+-------------+-------------------------------+-----------+
| Value | Name | Description | Reference |
+---------+-------------+-------------------------------+-----------+
| 0 | LOST | The link on this interface | RFC 7188 |
| | | from the router with that | |
| | | network address has been lost | |
| | | | |
| 1 | SYMMETRIC | The link on this interface | RFC 7188 |
| | | from the router with that | |
| | | network address has the | |
| | | status of symmetric | |
| | | | |
| 2 | HEARD | The link on this interface | RFC 7188 |
| | | from the router with that | |
| | | network address has the | |
| | | status of heard | |
| | | | |
| 3-223 | | Unassigned | |
| | | | |
| 224-254 | | Reserved for Experimental Use | RFC 7188 |
| | | | |
| 255 | UNSPECIFIED | No information about this | RFC 7188 |
| | | network address is provided | |
+---------+-------------+-------------------------------+-----------+
Table 3: LINK_STATUS TLV Values
表3：LINK_STATUS TLV値
New assignments are to be made by Expert Review [RFC5226].
新しい割り当てはExpert Review [RFC5226]によって行われます。
The Designated Experts are required to use the guidelines specified in [RFC6130] and [RFC7181].
Designated Expertsは、[RFC6130]と[RFC7181]で指定されたガイドラインを使用する必要があります。
IANA maintains a sub-registry called "LINK_STATUS Address Block TLV Type Extensions" within the "Mobile Ad hoc NETwork (MANET) Parameters" registry. This sub-registry already had an entry for value 0. IANA has replaced the entry in the Description column for this value with the text "This value is to be interpreted according to the registry LINK_STATUS TLV Values". The resulting table is as specified in Table 4.
IANAは、「モバイルアドホックネットワーク（MANET）パラメータ」レジストリ内に「LINK_STATUSアドレスブロックTLVタイプ拡張」と呼ばれるサブレジストリを保持しています。このサブレジストリにはすでに値0のエントリがありました。IANAはこの値の[説明]列のエントリを「この値はレジストリのLINK_STATUS TLV値に従って解釈される」というテキストに置き換えました。結果の表は、表4で指定されているとおりです。
+-----------+------------------------------------------+------------+
| Type | Description | Reference |
| Extension | | |
+-----------+------------------------------------------+------------+
| 0 | This value is to be interpreted | RFC 6130, |
| | according to the registry LINK_STATUS | RFC 7188 |
| | TLV Values | |
| | | |
| 1-255 | Unassigned | |
+-----------+------------------------------------------+------------+
Table 4: LINK_STATUS Address Block TLV Type Extensions Modifications
表4：LINK_STATUSアドレスブロックTLVタイプ拡張の変更
IANA has created a new sub-registry called "OTHER_NEIGHB TLV Values" within the "Mobile Ad hoc NETwork (MANET) Parameters" registry.
IANAは、「モバイルアドホックネットワーク（MANET）パラメータ」レジストリ内に「OTHER_NEIGHB TLV値」と呼ばれる新しいサブレジストリを作成しました。
IANA has populated this registry as specified in Table 5.
IANAは、表5で指定されているように、このレジストリにデータを入力しました。
+---------+-------------+-------------------------------+-----------+
| Value | Name | Description | Reference |
+---------+-------------+-------------------------------+-----------+
| 0 | LOST | The neighbor relationship | RFC 7188 |
| | | with the router with that | |
| | | network address has been lost | |
| | | | |
| 1 | SYMMETRIC | The neighbor relationship | RFC 7188 |
| | | with the router with that | |
| | | network address is symmetric | |
| | | | |
| 2-223 | | Unassigned | |
| | | | |
| 224-254 | | Reserved for Experimental Use | RFC 7188 |
| | | | |
| 255 | UNSPECIFIED | No information about this | RFC 7188 |
| | | network address is provided | |
+---------+-------------+-------------------------------+-----------+
Table 5: OTHER_NEIGHB Address Block TLV Values
表5：OTHER_NEIGHBアドレスブロックTLV値
New assignments are to be made by Expert Review [RFC5226].
新しい割り当てはExpert Review [RFC5226]によって行われます。
The Designated Experts are required to use the guidelines specified in [RFC6130] and [RFC7181].
Designated Expertsは、[RFC6130]と[RFC7181]で指定されたガイドラインを使用する必要があります。
IANA maintains a sub-registry called "OTHER_NEIGHB Address Block TLV Type Extensions" within the "Mobile Ad hoc NETwork (MANET) Parameters" registry. This sub-registry already had an entry for value 0. IANA has replaced the entry in the Description column for this value with the text "This value is to be interpreted according to the registry OTHER_NEIGHB TLV Values". The resulting table is as specified in Table 6.
IANAは、「モバイルアドホックネットワーク（MANET）パラメータ」レジストリ内に「OTHER_NEIGHBアドレスブロックTLVタイプ拡張」と呼ばれるサブレジストリを保持しています。このサブレジストリには既に値0のエントリがありました。IANAはこの値の[説明]列のエントリを「この値はレジストリOTHER_NEIGHB TLV値に従って解釈される」というテキストに置き換えました。結果の表は、表6で指定されているとおりです。
+-----------+------------------------------------------+------------+
| Type | Description | Reference |
| Extension | | |
+-----------+------------------------------------------+------------+
| 0 | This value is to be interpreted | RFC 6130, |
| | according to the registry OTHER_NEIGHB | RFC 7188 |
| | TLV Values | |
| | | |
| 1-255 | Unassigned | |
+-----------+------------------------------------------+------------+
Table 6: OTHER_NEIGHB Address Block TLV Type Extensions Modifications
表6：OTHER_NEIGHBアドレスブロックTLVタイプ拡張の変更
IANA has created a new sub-registry called "MPR TLV Bit Values" within the "Mobile Ad hoc NETwork (MANET) Parameters" registry.
IANAは、「モバイルアドホックネットワーク（MANET）パラメータ」レジストリ内に「MPR TLVビット値」と呼ばれる新しいサブレジストリを作成しました。
IANA has populated this registry as specified in Table 7.
IANAは、表7で指定されているように、このレジストリにデータを入力しました。
+-----+-------+----------+------------------------------+-----------+
| Bit | Value | Name | Description | Reference |
+-----+-------+----------+------------------------------+-----------+
| 7 | 0x01 | Flooding | The neighbor with that | RFC 7188 |
| | | | network address has been | |
| | | | selected as flooding MPR | |
| | | | | |
| 6 | 0x02 | Routing | The neighbor with that | RFC 7188 |
| | | | network address has been | |
| | | | selected as routing MPR | |
| | | | | |
| 0-5 | | | Unassigned | |
+-----+-------+----------+------------------------------+-----------+
Table 7: MPR Address Block TLV Bit Values
表7：MPRアドレスブロックTLVビット値
New assignments are to be made by Expert Review [RFC5226].
新しい割り当てはExpert Review [RFC5226]によって行われます。
The Designated Experts are required to use the guidelines specified in [RFC6130] and [RFC7181]. Additionally, the Designated Experts are required to ensure that the following sense is preserved:
Designated Expertsは、[RFC6130]と[RFC7181]で指定されたガイドラインを使用する必要があります。さらに、Designated Expertsは、次の意味が保持されるようにする必要があります。
o For each bit in the field, a set bit (1) means that the address has the designated property, while an unset bit (0) means that no information about the designated property is provided. In particular, an unset bit must not be used to convey any specific information about the designated property.
o フィールドの各ビットについて、セットビット（1）はアドレスに指定されたプロパティがあることを意味し、セットビット（0）は指定されたプロパティに関する情報が提供されないことを意味します。特に、指定されたプロパティに関する特定の情報を伝えるために、未設定ビットを使用してはなりません。
IANA maintains a sub-registry called "MPR Address Block TLV Type Extensions" within the "Mobile Ad hoc NETwork (MANET) Parameters" registry. This sub-registry already had an entry for value 0. IANA has replaced the entry in the Description column for this value with the text "This value is to be interpreted according to the registry MPR TLV Bit Values". The resulting table is as specified in Table 8.
IANAは、「モバイルアドホックネットワーク（MANET）パラメータ」レジストリ内に「MPRアドレスブロックTLVタイプ拡張」と呼ばれるサブレジストリを保持しています。このサブレジストリにはすでに値0のエントリがありました。IANAは、この値の[説明]列のエントリを「この値はレジストリのMPR TLVビット値に従って解釈される」というテキストに置き換えました。結果の表は、表8で指定されているとおりです。
+-----------+-----------------------------------------+-------------+
| Type | Description | Reference |
| Extension | | |
+-----------+-----------------------------------------+-------------+
| 0 | This value is to be interpreted | RFC 7181, |
| | according to the registry MPR TLV Bit | RFC 7188 |
| | Values | |
| | | |
| 1-255 | Unassigned | |
+-----------+-----------------------------------------+-------------+
Table 8: MPR Address Block TLV Type Extensions Modifications
表8：MPRアドレスブロックTLVタイプ拡張の変更
IANA has created a new sub-registry called "NBR_ADDR_TYPE Address Block TLV Bit Values" within the "Mobile Ad hoc NETwork (MANET) Parameters" registry.
IANAは、「モバイルアドホックネットワーク（MANET）パラメータ」レジストリ内に「NBR_ADDR_TYPEアドレスブロックTLVビット値」と呼ばれる新しいサブレジストリを作成しました。
IANA has populated this registry as specified in Table 9.
IANAは、表9で指定されているように、このレジストリにデータを入力しました。
+-----+-------+------------+----------------------------+-----------+
| Bit | Value | Name | Description | Reference |
+-----+-------+------------+----------------------------+-----------+
| 7 | 0x01 | ORIGINATOR | The network address is an | RFC 7188 |
| | | | originator address | |
| | | | reachable via the | |
| | | | originating router | |
| | | | | |
| 6 | 0x02 | ROUTABLE | The network address is a | RFC 7188 |
| | | | routable address reachable | |
| | | | via the originating router | |
| | | | | |
| 0-5 | | | Unassigned | |
+-----+-------+------------+----------------------------+-----------+
Table 9: NBR_ADDR_TYPE Address Block TLV Bit Values
表9：NBR_ADDR_TYPEアドレスブロックTLVビット値
New assignments are to be made by Expert Review [RFC5226].
新しい割り当てはExpert Review [RFC5226]によって行われます。
The Designated Experts are required to use the guidelines specified in [RFC6130] and [RFC7181]. Additionally, the Designated Experts are required to ensure that the following sense is preserved:
Designated Expertsは、[RFC6130]と[RFC7181]で指定されたガイドラインを使用する必要があります。さらに、Designated Expertsは、次の意味が保持されるようにする必要があります。
o For each bit in the field, a set bit (1) means that the address has the designated property, while an unset bit (0) means that no information about the designated property is provided. In particular, an unset bit must not be used to convey any specific information about the designated property.
o フィールドの各ビットについて、セットビット（1）はアドレスに指定されたプロパティがあることを意味し、セットビット（0）は指定されたプロパティに関する情報が提供されないことを意味します。特に、指定されたプロパティに関する特定の情報を伝えるために、未設定ビットを使用してはなりません。
IANA maintains a sub-registry called "NBR_ADDR_TYPE Address Block TLV Type Extensions" within the "Mobile Ad hoc NETwork (MANET) Parameters" registry. This sub-registry already had an entry for value 0. IANA has replaced the entry in the Description column for this value with the text "This value is to be interpreted according to the registry NBR_ADDR_TYPE TLV Bit Values". The resulting table is as specified in Table 10.
IANAは、「モバイルアドホックネットワーク（MANET）パラメータ」レジストリ内に「NBR_ADDR_TYPEアドレスブロックTLVタイプ拡張」と呼ばれるサブレジストリを保持しています。このサブレジストリにはすでに値0のエントリがありました。IANAはこの値の[説明]列のエントリを「この値はレジストリNBR_ADDR_TYPE TLVビット値に従って解釈される」というテキストに置き換えました。結果の表は、表10で指定されているとおりです。
+-----------+-------------------------------------------+-----------+
| Type | Description | Reference |
| Extension | | |
+-----------+-------------------------------------------+-----------+
| 0 | This value is to be interpreted according | RFC 7181, |
| | to the registry NBR_ADDR_TYPE Address | RFC 7188 |
| | Block TLV Bit Values | |
| | | |
| 1-255 | Unassigned | |
+-----------+-------------------------------------------+-----------+
Table 10: NBR_ADDR_TYPE Address Block TLV Type Extensions Modifications
表10：NBR_ADDR_TYPEアドレスブロックTLVタイプ拡張の変更
The updates made to [RFC6130] and [RFC7181] have the following implications on the security considerations:
[RFC6130]と[RFC7181]に加えられた更新は、セキュリティの考慮事項に次の影響を及ぼします。
o Created IANA registries for retaining TLV values for TLVs, already defined in the already published specifications of the two protocols, and with initial registrations for the TLV values defined by these specifications. This does not give rise to any additional security considerations.
o 2つのプロトコルのすでに公開された仕様ですでに定義されているTLVのTLV値を保持するためのIANAレジストリを作成し、これらの仕様で定義されたTLV値の初期登録を行いました。これにより、セキュリティに関する追加の考慮事項が発生することはありません。
o Enabled protocol extensions for registering TLV values in the created IANA registries. Such extensions MUST specify appropriate security considerations.
o 作成されたIANAレジストリにTLV値を登録するためのプロトコル拡張を有効にしました。そのような拡張は、適切なセキュリティの考慮事項を指定しなければなりません。
o Created, in some registries, a registration for "UNSPECIFIED" values for more efficient use of multivalue Address Block TLVs. The interpretation of an address being associated with a TLV of a given type and with the value "UNSPECIFIED" is identical to that address not being associated with a TLV of that type. Thus, this update does not give rise to any additional security considerations.
o 複数値のアドレスブロックTLVをより効率的に使用するために、一部のレジストリで「未指定」値の登録を作成しました。特定のタイプのTLVと値「UNSPECIFIED」に関連付けられているアドレスの解釈は、そのタイプのTLVに関連付けられていないアドレスと同じです。したがって、この更新では、セキュリティに関する追加の考慮事項は発生しません。
o Reduced the latitude of implementations of the two protocols to reject a message as "badly formed" due to the value field of a TLV being unexpected. These protocols are specified in terms such as "if an address is associated with a value of LOST by a LINK_STATUS TLV". Association with an unknown value (or a value newly defined to mean no link status information) has no effect on such a specification. Thus, this update does not give rise to any additional security considerations.
o TLVの値フィールドが予期しないものであるために、メッセージが「不正な形式」として拒否されるように、2つのプロトコルの実装の許容範囲を狭めました。これらのプロトコルは、「アドレスがLINK_STATUS TLVによってLOSTの値に関連付けられている場合」などの用語で指定されます。不明な値（またはリンクステータス情報がないことを意味するように新しく定義された値）との関連付けは、そのような仕様には影響しません。したがって、この更新では、セキュリティに関する追加の考慮事項は発生しません。
o Did not introduce any opportunities for attacks on the protocols through signal modification that are not already present in the two protocols.
o 2つのプロトコルにまだ存在していない信号の変更を介したプロトコルへの攻撃の機会は導入されませんでした。
The authors would like to gratefully acknowledge the following people for intense technical discussions, early reviews, and comments on the specification (listed alphabetically): Ulrich Herberg (Fujitsu Laboratories of America) and Henning Rogge (Frauenhofer FKIE).
著者は、仕様（アルファベット順）についての激しい技術的な議論、初期のレビュー、およびコメントについて、Ulrich Herberg（Fujitsu Laboratories of America）およびHenning Rogge（Frauenhofer FKIE）に感謝します。
The authors would also like to express their gratitude to Adrian Farrel for his assistance and contributions to the successful and timely completion of this specification.
著者はまた、この仕様の成功したタイムリーな完成に対する彼の支援と貢献に対して、エイドリアン・ファレルに感謝の意を表したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized MANET Packet/Message Format", RFC 5444, February 2009.
[RFC5444] Clausen、T.、Dearlove、C.、Dean、J。、およびC. Adjih、「Generalized MANET Packet / Message Format」、RFC 5444、2009年2月。
[RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, April 2011.
[RFC6130] Clausen、T.、Dean、J。、およびC. Dearlove、「モバイルアドホックネットワーク（MANET）近隣探索プロトコル（NHDP）」、RFC 6130、2011年4月。
[RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, "The Optimized Link State Routing Protocol Version 2", RFC 7181, April 2014.
[RFC7181] Clausen、T.、Dearlove、C.、Jacquet、P。、およびU. Herberg、「The Optimized Link State Routing Protocol Version 2」、RFC 7181、2014年4月。
[RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations", RFC 2501, January 1999.
[RFC2501] Macker、J。およびS. Corson、「モバイルアドホックネットワーキング（MANET）：ルーティングプロトコルのパフォーマンスの問題と評価に関する考慮事項」、RFC 2501、1999年1月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
Authors' Addresses
著者のアドレス
Christopher Dearlove BAE Systems Advanced Technology Centre West Hanningfield Road Great Baddow, Chelmsford United Kingdom
Christopher Dearlove BAE Systems Advanced Technology Center West Hanningfield Roadイギリス、チェルムズフォード、グレートバッドウ
Phone: +44 1245 242194
EMail: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/
Thomas Heide Clausen LIX, Ecole Polytechnique
トーマスハイデクラウセンLIX、エコールポリテクニック
Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org
URI: http://www.ThomasClausen.org/