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
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.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/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.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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邻域发现协议（NHDP）[RFC6130]和优化链路状态路由协议版本2（OLSRv2）[RFC7181]是基于广义MANET分组/消息格式[RFC5444]的移动自组网（MANET）[RFC2501]中使用的协议。
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（类型长度值）元素的使用，以增加这些协议的可扩展性，并对其实现进行一些改进。
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.
此规范降低了[RCF6130]和[RCF7181]的实现的纬度，以考虑一些消息，这些消息不会由遵循这些规范的实现创建，这是将消息视为“格式不良”的原因，因此是拒绝消息的原因。这为创建这些协议的扩展提供了更大的自由度，特别是将与这些协议的未扩展实现进行互操作的扩展。作为其中的一部分，它指出了必须如何处理具有意外值字段的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.
请注意，[RFC6130]和[RFC7181]已指定具有未知类型或类型扩展名的TLV将被忽略，并且也不是拒绝消息的原因。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[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]中定义的局部_IF。
* LINK_STATUS, defined in [RFC6130].
* 链接状态，在[RFC6130]中定义。
* OTHER_NEIGHB, defined in [RFC6130].
* [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_类型，现在被视为位字段。
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和其他_NEIGHB（均在[RFC6130]中定义）的“未指定”定义一个众所周知的TLV值。
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”第12.1节和[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值。相反，NHDP或OLSRv2的未扩展实现必须处理或忽略任何未识别的TLV值字段，如下节所述。
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]以诸如“如果地址与链路状态TLV丢失的值相关联”之类的术语指定。与未识别值的关联对严格遵循此类规范的任何实现都没有影响。
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具有一个或两个八位组的单一长度。这些被视为此类接收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时必须如何运行，但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 如果接收到的单个长度大于预期的单个长度，则必须忽略多余的八位字节。
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）。
Exception:
例外情况：
o A received CONT_SEQ_NUM with a single-length < 2 SHOULD be considered an error.
o 接收到的单个长度小于2的CONT_SEQ_NUM应视为错误。
[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值的含义。本文件为这些TLV值建立IANA注册，初始注册反映了[RFC6130]和[RFC7181]使用的注册，并符合第4.3.3节的规定。
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和其他_NEIGHB TLV，仅为每个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]的一个实现，如果接收本地\u IF、链接\u STATUS或其他\u NEIGHB TLV，并且该TLV具有除[RFC6130]中定义的值以外的任何TLV值，则必须忽略该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]中定义的地址块TLVs MPR和NBR_ADDR_TYPE与[RFC6130]中定义的地址块TLVs MPR和NBR_ADDR_TYPE类似，只指定了有限的值（1、2和3）：1和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节中为本地IF、链路状态和其他相邻TLV定义的登记册均包括未指定的附加TLV值。此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.
如果TLV值为零，则MPR和NBR_ADDR_类型TLV的类似要求已经得到满足，前提是TLV值中的每个位在指示存在属性时定义为set（'1'），或在指示不存在属性时定义为clear（'0'）。因此，在相关登记处进行登记时需要这样做；见第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').
对于链路度量TLV，通过清除TLV值的第一个八位组的最高有效位（0到3），这已经是可能的。在这种情况下，建议TLV值的剩余位全部清除（“0”）或全部设置（“1”）。
IANA has completed the ten actions set out in the following sections.
IANA已完成以下章节中列出的十项行动。
IANA has created a new sub-registry called "LOCAL_IF TLV Values" within the "Mobile Ad hoc NETwork (MANET) Parameters" registry.
IANA在“移动自组织网络（MANET）参数”注册表中创建了一个名为“本地_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 | |
+---------+-------------+-------------------------------+-----------+
+---------+-------------+-------------------------------+-----------+
| 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：局部_IF TLV值
New assignments are to be made by Expert Review [RFC5226].
新的任务将由专家评审[RFC5226]完成。
The Designated Experts are required to use the guidelines specified in [RFC6130] and [RFC7181].
指定专家需要使用[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）参数”注册表中维护一个名为“本地_IF地址块TLV类型扩展”的子注册表。此子注册表已具有值0的项。IANA已将该值的“说明”列中的条目替换为文本“该值将根据注册表本地_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 | |
+-----------+-----------------------------------------+-------------+
+-----------+-----------------------------------------+-------------+
| 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：本地_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）参数”注册表中创建了一个名为“链路状态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 | |
+---------+-------------+-------------------------------+-----------+
+---------+-------------+-------------------------------+-----------+
| 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：链路状态TLV值
New assignments are to be made by Expert Review [RFC5226].
新的任务将由专家评审[RFC5226]完成。
The Designated Experts are required to use the guidelines specified in [RFC6130] and [RFC7181].
指定专家需要使用[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）参数”注册表中维护一个名为“链路_状态地址块TLV类型扩展”的子注册表。此子注册表已具有值0的项。IANA已将该值的“说明”列中的条目替换为文本“该值将根据注册表链接\ U状态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 | |
+-----------+------------------------------------------+------------+
+-----------+------------------------------------------+------------+
| 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：链路状态地址块TLV类型扩展修改
IANA has created a new sub-registry called "OTHER_NEIGHB TLV Values" within the "Mobile Ad hoc NETwork (MANET) Parameters" registry.
IANA在“移动自组织网络（MANET）参数”注册表中创建了一个名为“其他邻域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 | |
+---------+-------------+-------------------------------+-----------+
+---------+-------------+-------------------------------+-----------+
| 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：其他_NEIGHB地址块TLV值
New assignments are to be made by Expert Review [RFC5226].
新的任务将由专家评审[RFC5226]完成。
The Designated Experts are required to use the guidelines specified in [RFC6130] and [RFC7181].
指定专家需要使用[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）参数”注册表中维护一个名为“其他邻居地址块TLV类型扩展”的子注册表。此子注册表已具有值0的项。IANA已将该值的“说明”列中的条目替换为文本“该值将根据注册表其他_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 | |
+-----------+------------------------------------------+------------+
+-----------+------------------------------------------+------------+
| 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：其他地址块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 | |
+-----+-------+----------+------------------------------+-----------+
+-----+-------+----------+------------------------------+-----------+
| 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].
新的任务将由专家评审[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:
指定专家需要使用[RFC6130]和[RFC7181]中规定的指南。此外，指定的专家必须确保保持以下感觉：
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 | |
+-----------+-----------------------------------------+-------------+
+-----------+-----------------------------------------+-------------+
| 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_类型地址块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 | |
+-----+-------+------------+----------------------------+-----------+
+-----+-------+------------+----------------------------+-----------+
| 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_类型地址块TLV位值
New assignments are to be made by Expert Review [RFC5226].
新的任务将由专家评审[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:
指定专家需要使用[RFC6130]和[RFC7181]中规定的指南。此外，指定的专家必须确保保持以下感觉：
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_类型地址块TLV类型扩展”的子注册表。此子注册表已具有值0的项。IANA已将该值的“说明”列中的条目替换为文本“该值将根据注册表NBR_ADDR_类型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 | |
+-----------+-------------------------------------------+-----------+
+-----------+-------------------------------------------+-----------+
| 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\U地址类型地址块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 创建了IANA注册中心，用于保留两个协议已发布规范中定义的TLV的TLV值，以及这些规范中定义的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的值字段是意外的，因此减少了两个协议实现的自由度，以拒绝“格式错误”的消息。这些协议以诸如“如果地址与链路状态TLV丢失的值相关联”之类的术语指定。与未知值（或新定义的表示无链接状态信息的值）的关联对此类规范没有影响。因此，此更新不会引起任何额外的安全考虑。
o Did not introduce any opportunities for attacks on the protocols through signal modification that are not already present in the two protocols.
o 没有通过两个协议中尚未出现的信号修改对协议造成任何攻击的机会。
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（美国富士通实验室）和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.
作者还想对Adrian Farrel表示感谢，感谢他为成功及时完成本规范所提供的帮助和贡献。
[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，“广义MANET数据包/消息格式”，RFC 54442009年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）”，RFC6130，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，“优化链路状态路由协议版本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，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
Authors' Addresses
作者地址
Christopher Dearlove BAE Systems Advanced Technology Centre West Hanningfield Road Great Baddow, Chelmsford United Kingdom
克里斯托弗·迪尔洛夫英国切姆斯福德大巴德西汉宁菲尔德路BAE系统先进技术中心
Phone: +44 1245 242194
EMail: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/
Phone: +44 1245 242194
EMail: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/
Thomas Heide Clausen LIX, Ecole Polytechnique
托马斯·海德·克劳森·利克斯，理工学院
Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org
URI: http://www.ThomasClausen.org/
Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org
URI: http://www.ThomasClausen.org/