Independent Submission J. Chroboczek
Request for Comments: 7557 PPS, University of Paris-Diderot
Updates: 6126 May 2015
Category: Experimental
ISSN: 2070-1721
Independent Submission J. Chroboczek
Request for Comments: 7557 PPS, University of Paris-Diderot
Updates: 6126 May 2015
Category: Experimental
ISSN: 2070-1721
Extension Mechanism for the Babel Routing Protocol
Babel路由协议的扩展机制
Abstract
摘要
This document defines the encoding of extensions to the Babel routing protocol, as specified in RFC 6126.
本文件定义了巴别塔路由协议扩展的编码，如RFC 6126所述。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见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/rfc7557.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7557.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Mechanisms for Extending the Babel Protocol . . . . . . . . . 3
2.1. New Versions of the Babel Protocol . . . . . . . . . . . 3
2.2. New TLVs . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. The Flags Field . . . . . . . . . . . . . . . . . . . . . 4
2.5. Packet Trailer . . . . . . . . . . . . . . . . . . . . . 5
3. Format of Sub-TLVs . . . . . . . . . . . . . . . . . . . . . 5
3.1. Sub-TLVs Specified in This Document . . . . . . . . . . . 5
3.2. Unknown Sub-TLVs . . . . . . . . . . . . . . . . . . . . 6
4. Choosing between Extension Mechanisms . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Mechanisms for Extending the Babel Protocol . . . . . . . . . 3
2.1. New Versions of the Babel Protocol . . . . . . . . . . . 3
2.2. New TLVs . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. The Flags Field . . . . . . . . . . . . . . . . . . . . . 4
2.5. Packet Trailer . . . . . . . . . . . . . . . . . . . . . 5
3. Format of Sub-TLVs . . . . . . . . . . . . . . . . . . . . . 5
3.1. Sub-TLVs Specified in This Document . . . . . . . . . . . 5
3.2. Unknown Sub-TLVs . . . . . . . . . . . . . . . . . . . . 6
4. Choosing between Extension Mechanisms . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
A Babel packet [RFC6126] contains a header followed by a sequence of TLVs, each of which is a sequence of octets having an explicit type and length. The original Babel protocol has the following provisions for including extension data:
Babel数据包[RFC6126]包含一个标头，后跟一个TLV序列，每个TLV序列都是具有显式类型和长度的八位字节序列。最初的巴贝尔协议对包括扩展数据有以下规定：
o A Babel packet with a version number different from 2 MUST be silently ignored ([RFC6126], Section 4.2).
o 版本号不同于2的Babel数据包必须被静默忽略（[RFC6126]，第4.2节）。
o An unknown TLV MUST be silently ignored ([RFC6126], Section 4.3).
o 必须默默忽略未知TLV（[RFC6126]，第4.3节）。
o Except for Pad1 and PadN, all TLVs are self-terminating, and any extra data included in a TLV MUST be silently ignored ([RFC6126], Section 4.2).
o 除Pad1和PadN外，所有TLV都是自端接的，TLV中包含的任何额外数据都必须默默忽略（[RFC6126]，第4.2节）。
o The Flags field of the Update TLV contains 6 undefined bits that MUST be silently ignored ([RFC6126], Section 4.4.9).
o 更新TLV的标志字段包含6个未定义的位，必须以静默方式忽略（[RFC6126]，第4.4.9节）。
o Any data following the last TLV of a Babel packet MUST be silently ignored ([RFC6126], Section 4.2).
o Babel数据包最后一个TLV之后的任何数据都必须被静默忽略（[RFC6126]，第4.2节）。
Each of these provisions provides a place to store data needed by extensions of the Babel protocol. However, in the absence of any further conventions, independently developed extensions to the Babel protocol might make conflicting uses of the available space, and therefore lead to implementations that would fail to interoperate.
这些条款中的每一条都提供了一个存储巴贝尔协议扩展所需数据的地方。然而，在没有任何其他约定的情况下，独立开发的巴别塔协议扩展可能会对可用空间产生冲突，从而导致无法互操作的实现。
This document formalises a set of rules for extending the Babel protocol that are designed to ensure that no such incompatibilities arise, and that are currently respected by a number of deployed extensions.
本文档正式确定了一组扩展Babel协议的规则，这些规则旨在确保不会出现此类不兼容，目前许多已部署的扩展都遵守这些规则。
In the rest of this document, we use the term "original protocol" for the protocol defined in [RFC6126], and "extended protocol" for any extension of the Babel protocol that follows the rules set out in this document.
在本文件的其余部分中，我们对[RFC6126]中定义的协议使用术语“原始协议”，对遵循本文件规定规则的巴贝尔协议的任何扩展使用术语“扩展协议”。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This section describes each of the mechanisms available for extending the Babel protocol.
本节描述了可用于扩展Babel协议的每种机制。
The header of a Babel packet contains an eight-bit protocol version. The current version of the Babel protocol is version 2; any packets containing a version number different from 2 MUST be silently ignored.
Babel数据包的报头包含八位协议版本。巴别塔协议的当前版本为第2版；任何包含不同于2的版本号的数据包都必须被静默忽略。
Versions 0 and 1 were earlier experimental versions of the Babel protocol that have seen some modest deployment; these version numbers SHOULD NOT be reused by future versions of the Babel protocol. Version numbers larger than 2 might be used by a future incompatible protocol.
版本0和1是Babel协议的早期实验版本，已经进行了一些适度的部署；巴贝尔协议的未来版本不应重复使用这些版本号。未来不兼容的协议可能会使用大于2的版本号。
An extension may carry its data in a new TLV type. Such new TLVs will be silently ignored by implementations of the original Babel protocol, as well as by other extended implementations of the Babel protocol, as long as the TLV types do not collide.
扩展可以以新的TLV类型携带其数据。只要TLV类型不发生冲突，原始Babel协议的实现以及Babel协议的其他扩展实现都会悄悄地忽略这种新的TLV。
All new TLVs MUST have the format defined in [RFC6126], Section 4.3. New TLVs SHOULD be self-terminating, in the sense defined in the next section, and any data found after the main data section of the TLV SHOULD be treated as a series of sub-TLVs.
所有新TLV必须具有[RFC6126]第4.3节中定义的格式。在下一节定义的意义上，新的TLV应该是自终止的，在TLV的主数据部分之后发现的任何数据都应该被视为一系列子TLV。
TLV types 224 through 254 are reserved for Experimental Use [RFC3692]. TLV type 255 is reserved for expansion of the TLV type space, in the unlikely event that eight bits turn out not to be enough.
TLV类型224至254保留供实验使用[RFC3692]。TLV类型255保留用于扩展TLV类型空间，以防8位不够用。
With the exception of the Pad1 TLV, all Babel TLVs carry an explicit length. With the exception of Pad1 and PadN, all TLVs defined by the original protocol are self-terminating, in the sense that the length of the meaningful data that they contain (the "natural length") can be determined without reference to the explicitly encoded length. In some cases, the natural length is trivial to determine: for example, a HELLO TLV always has a natural length of 2 (4 including the Type and Length fields). In other cases, determining the natural length is not that easy, but this needs to be done anyway by an implementation that interprets the given TLV. For example, the natural length of an Update TLV depends on both the prefix length and the amount of prefix compression being performed.
除Pad1 TLV外，所有巴别塔TLV均具有明确的长度。除Pad1和PadN外，原始协议定义的所有TLV都是自终止的，即它们包含的有意义数据的长度（“自然长度”）可以在不参考显式编码长度的情况下确定。在某些情况下，自然长度很难确定：例如，HELLO TLV的自然长度始终为2（4，包括类型和长度字段）。在其他情况下，确定自然长度并不是那么容易，但无论如何都需要通过解释给定TLV的实现来完成。例如，更新TLV的自然长度取决于前缀长度和正在执行的前缀压缩量。
If the explicit length of a TLV defined by the original protocol is larger than its natural length, the extra space present in the TLV is silently ignored by an implementation of the original protocol; extended implementations MAY use it to store arbitrary data and SHOULD structure the additional data as a sequence of sub-TLVs. Unlike TLVs, the sub-TLVs themselves need not be self-terminating.
如果由原始协议定义的TLV的显式长度大于其自然长度，则原始协议的实现会默默地忽略TLV中存在的额外空间；扩展实现可能使用它来存储任意数据，并应将附加数据作为子TLV序列进行结构。与TLV不同，子TLV本身不需要自终止。
An extension MAY be assigned one or more sub-TLV types. Sub-TLV types are assigned independently from TLV types: the same numeric type can be assigned to a TLV and a sub-TLV. Sub-TLV types are assigned globally: once an extension is assigned a given sub-TLV number, it MAY use this number within any TLV. However, the interpretation of a given sub-TLV type can depend on which particular TLV it is embedded within.
扩展可以被分配一个或多个子TLV类型。子TLV类型的分配独立于TLV类型：可以将相同的数字类型分配给TLV和子TLV。子TLV类型是全局分配的：一旦为扩展分配了给定的子TLV编号，它就可以在任何TLV中使用该编号。然而，对给定子TLV类型的解释可能取决于其嵌入的特定TLV。
Sub-TLV types 224 through 254 are reserved for Experimental Use [RFC3692]. TLV type 255 is reserved for expansion of the sub-TLV type space, in the unlikely event that eight bits turn out not to be enough. The format of sub-TLVs is defined in Section 3 below.
子TLV类型224至254保留供实验使用[RFC3692]。TLV类型255保留用于扩展子TLV类型空间，以防8位不够用。子TLV的格式定义见下文第3节。
The Flags field is an eight-bit field in the Update TLV. Bits 0 and 1 (the bits with values 80 and 40 hexadecimal) are defined by the original protocol and MUST be recognised and used by every implementation. The remaining six bits are not currently used and are silently ignored by implementations of the original protocol.
标志字段是更新TLV中的八位字段。位0和1（十六进制值为80和40的位）由原始协议定义，每个实现都必须识别和使用。其余六位当前未使用，并且被原始协议的实现默默忽略。
Due to the small size of the Flags field, it is NOT RECOMMENDED that one or more bits be assigned to an extension; a sub-TLV SHOULD be assigned instead. An implementation MUST ignore any bits in the Flags field that it does not know about and MUST send them as zero.
由于标志字段的大小较小，不建议为扩展分配一个或多个位；应指定一个子TLV。实现必须忽略Flags字段中它不知道的任何位，并且必须将它们作为零发送。
A Babel packet carries an explicit length in its header. A Babel packet is carried by a UDP datagram, which in turn contains an explicit length in its header. It is possible for a UDP datagram carrying a Babel packet to be larger than the size of the Babel packet. In that case, the extra space after the Babel packet, known as the packet trailer, is silently ignored by an implementation of the original protocol.
Babel数据包在其报头中具有明确的长度。Babel数据包由UDP数据报承载，而UDP数据报又在其报头中包含显式长度。承载Babel数据包的UDP数据报可能大于Babel数据包的大小。在这种情况下，Babel数据包之后的额外空间（称为数据包尾部）被原始协议的实现默默地忽略。
The packet trailer was originally intended to be used as a cryptographic trailer. However, the authentication extension to Babel [RFC7298] ended up using a pair of new TLVs, and no currently deployed extension of Babel uses the packet trailer. The format and purpose of the packet trailer is therefore currently left undefined.
数据包预告片最初打算用作加密预告片。然而，Babel[RFC7298]的身份验证扩展最终使用了一对新的TLV，并且当前部署的Babel扩展没有使用数据包尾部。因此，数据包尾部的格式和用途目前尚未定义。
A sub-TLV has exactly the same structure as a TLV. Except for Pad1 (Section 3.1.1), all sub-TLVs have the following structure:
子TLV的结构与TLV完全相同。除Pad1（第3.1.1节）外，所有子TLV均具有以下结构：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Body...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Body...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields:
领域：
Type The type of the sub-TLV.
键入子TLV的类型。
Length The length of the body, in octets, exclusive of the Type and Length fields.
长度正文的长度，以八位字节为单位，不包括类型和长度字段。
Body The sub-TLV body, the interpretation of which depends on both the type of the sub-TLV and the type of the TLV within which it is embedded.
主体——子TLV主体，其解释取决于子TLV的类型及其嵌入的TLV的类型。
This document defines two types of sub-TLVs, Pad1 and PadN. These two sub-TLVs MUST be correctly parsed and ignored by any extended implementation of the Babel protocol that uses sub-TLVs.
本文件定义了两种类型的子TLV，Pad1和PadN。使用子TLV的Babel协议的任何扩展实现都必须正确解析和忽略这两个子TLV。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Type = 0 |
+-+-+-+-+-+-+-+-+
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Type = 0 |
+-+-+-+-+-+-+-+-+
Fields:
领域：
Type Set to 0 to indicate a Pad1 sub-TLV.
输入设置为0以指示Pad1子TLV。
This sub-TLV is silently ignored on reception.
此子TLV在接收时被默默忽略。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Length | MBZ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Length | MBZ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields:
领域：
Type Set to 1 to indicate a PadN sub-TLV.
输入设置为1以指示PadN子TLV。
Length The length of the body, in octets, exclusive of the Type and Length fields.
长度正文的长度，以八位字节为单位，不包括类型和长度字段。
MBZ Set to 0 on transmission.
MBZ在传输时设置为0。
This sub-TLV is silently ignored on reception.
此子TLV在接收时被默默忽略。
Any unknown sub-TLV MUST be silently ignored by an extended implementation that uses sub-TLVs.
任何未知的子TLV都必须由使用子TLV的扩展实现默默忽略。
New versions of the Babel protocol should only be defined if the new version is not backwards compatible with the original protocol.
只有当新版本与原始协议不向后兼容时，才应定义巴别塔协议的新版本。
In many cases, an extension could be implemented either by defining a new TLV or by adding a new sub-TLV to an existing TLV. For example, an extension whose purpose is to attach additional data to route updates can be implemented either by creating a new "enriched" Update TLV or by adding a sub-TLV to the Update TLV.
在许多情况下，可以通过定义新的TLV或向现有TLV添加新的子TLV来实现扩展。例如，可以通过创建新的“强化”更新TLV或向更新TLV添加子TLV来实现其目的是将附加数据附加到路由更新的扩展。
The two encodings are treated differently by implementations that do not understand the extension. In the case of a new TLV, the whole unknown TLV is ignored by an implementation of the original protocol, while in the case of a new sub-TLV, the TLV is parsed and acted upon, and the unknown sub-TLV is silently ignored. Therefore, a sub-TLV should be used by extensions that extend the Update in a compatible manner (the extension data may be silently ignored), while a new TLV must be used by extensions that make incompatible extensions to the meaning of the TLV (the whole TLV must be thrown away if the extension data is not understood).
不理解扩展的实现对这两种编码的处理是不同的。在新TLV的情况下，原始协议的实现将忽略整个未知TLV，而在新子TLV的情况下，将解析TLV并对其执行操作，并且默认忽略未知子TLV。因此，子TLV应该由以兼容方式扩展更新的扩展使用（扩展数据可能会被静默忽略），而新TLV必须由对TLV含义进行不兼容扩展的扩展使用（如果扩展数据不被理解，则必须丢弃整个TLV）。
Using a new bit in the Flags field is equivalent to defining a new sub-TLV while using less space in the Babel packet. Due to the limited Flags space, and the doubtful space savings, we do not recommend the use of bits in the Flags field -- a new sub-TLV should be used instead.
在Flags字段中使用新位相当于定义新的子TLV，同时在Babel数据包中使用更少的空间。由于标志空间有限，并且节省的空间值得怀疑，因此我们不建议在标志字段中使用位——应该使用新的子TLV。
We refrain from making any recommendations about the usage of the packet trailer due to the lack of implementation experience.
由于缺乏实施经验，我们避免就数据包预告片的使用提出任何建议。
IANA has created three new registries, called "Babel TLV Types", "Babel Sub-TLV Types", and "Babel Flags Values". The allocation policy for each of these registries is Specification Required [RFC5226].
IANA创建了三个新的注册中心，称为“巴贝尔TLV类型”、“巴贝尔子TLV类型”和“巴贝尔标志值”。每个注册表的分配策略都是规范要求的[RFC5226]。
The initial values in the "Babel TLV Types" registry are as follows:
“Babel TLV类型”注册表中的初始值如下所示：
+---------+-----------------------------------------+---------------+
| Type | Name | Reference |
+---------+-----------------------------------------+---------------+
| 0 | Pad1 | [RFC6126] |
| | | |
| 1 | PadN | [RFC6126] |
| | | |
| 2 | Acknowledgment Request | [RFC6126] |
| | | |
| 3 | Acknowledgment | [RFC6126] |
| | | |
| 4 | Hello | [RFC6126] |
| | | |
| 5 | IHU | [RFC6126] |
| | | |
| 6 | Router-Id | [RFC6126] |
| | | |
| 7 | Next Hop | [RFC6126] |
| | | |
| 8 | Update | [RFC6126] |
| | | |
| 9 | Route Request | [RFC6126] |
| | | |
| 10 | Seqno Request | [RFC6126] |
| | | |
| 11 | TS/PC | [RFC7298] |
| | | |
| 12 | HMAC | [RFC7298] |
| | | |
| 13 | Source-specific Update | [BABEL-SS] |
| | | |
| 14 | Source-specific Request | [BABEL-SS] |
| | | |
| 15 | Source-specific Seqno Request | [BABEL-SS] |
| | | |
| 224-254 | Reserved for Experimental Use | this document |
| | | |
| 255 | Reserved for expansion of the type | this document |
| | space | |
+---------+-----------------------------------------+---------------+
+---------+-----------------------------------------+---------------+
| Type | Name | Reference |
+---------+-----------------------------------------+---------------+
| 0 | Pad1 | [RFC6126] |
| | | |
| 1 | PadN | [RFC6126] |
| | | |
| 2 | Acknowledgment Request | [RFC6126] |
| | | |
| 3 | Acknowledgment | [RFC6126] |
| | | |
| 4 | Hello | [RFC6126] |
| | | |
| 5 | IHU | [RFC6126] |
| | | |
| 6 | Router-Id | [RFC6126] |
| | | |
| 7 | Next Hop | [RFC6126] |
| | | |
| 8 | Update | [RFC6126] |
| | | |
| 9 | Route Request | [RFC6126] |
| | | |
| 10 | Seqno Request | [RFC6126] |
| | | |
| 11 | TS/PC | [RFC7298] |
| | | |
| 12 | HMAC | [RFC7298] |
| | | |
| 13 | Source-specific Update | [BABEL-SS] |
| | | |
| 14 | Source-specific Request | [BABEL-SS] |
| | | |
| 15 | Source-specific Seqno Request | [BABEL-SS] |
| | | |
| 224-254 | Reserved for Experimental Use | this document |
| | | |
| 255 | Reserved for expansion of the type | this document |
| | space | |
+---------+-----------------------------------------+---------------+
The initial values in the "Babel Sub-TLV Types" registry are as follows:
“巴别塔子TLV类型”注册表中的初始值如下所示：
+---------+-----------------------------------------+---------------+
| Type | Name | Reference |
+---------+-----------------------------------------+---------------+
| 0 | Pad1 | this document |
| | | |
| 1 | PadN | this document |
| | | |
| 2 | Diversity | [BABEL-DIV] |
| | | |
| 3 | Timestamp | [BABEL-RTT] |
| | | |
| 224-254 | Reserved for Experimental Use | this document |
| | | |
| 255 | Reserved for expansion of the type | this document |
| | space | |
+---------+-----------------------------------------+---------------+
+---------+-----------------------------------------+---------------+
| Type | Name | Reference |
+---------+-----------------------------------------+---------------+
| 0 | Pad1 | this document |
| | | |
| 1 | PadN | this document |
| | | |
| 2 | Diversity | [BABEL-DIV] |
| | | |
| 3 | Timestamp | [BABEL-RTT] |
| | | |
| 224-254 | Reserved for Experimental Use | this document |
| | | |
| 255 | Reserved for expansion of the type | this document |
| | space | |
+---------+-----------------------------------------+---------------+
The initial values in the "Babel Flags Values" registry are as follows:
“Babel Flags values”注册表中的初始值如下所示：
+-----+-------------------+-----------+
| Bit | Name | Reference |
+-----+-------------------+-----------+
| 0 | Default prefix | [RFC6126] |
| | | |
| 1 | Default router-id | [RFC6126] |
| | | |
| 2-7 | Unassigned | |
+-----+-------------------+-----------+
+-----+-------------------+-----------+
| Bit | Name | Reference |
+-----+-------------------+-----------+
| 0 | Default prefix | [RFC6126] |
| | | |
| 1 | Default router-id | [RFC6126] |
| | | |
| 2-7 | Unassigned | |
+-----+-------------------+-----------+
This document specifies the structure of fields that are already present in the original Babel protocol and does not, by itself, raise any new security considerations. Specific extensions may change the security properties of the protocol, for example, by adding security mechanisms [RFC7298] or by enabling new kinds of attack.
本文档指定了原始Babel协议中已经存在的字段的结构，并且本身没有提出任何新的安全注意事项。特定扩展可能会更改协议的安全属性，例如，通过添加安全机制[RFC7298]或启用新类型的攻击。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, DOI 10.17487/RFC3692, January 2004, <http://www.rfc-editor.org/info/rfc3692>.
[RFC3692]Narten，T.，“分配被认为有用的实验和测试数字”，BCP 82，RFC 3692，DOI 10.17487/RFC3692，2004年1月<http://www.rfc-editor.org/info/rfc3692>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, DOI 10.17487/RFC6126, April 2011, <http://www.rfc-editor.org/info/rfc6126>.
[RFC6126]Chroboczek，J.，“巴贝尔路由协议”，RFC 6126，DOI 10.17487/RFC6126，2011年4月<http://www.rfc-editor.org/info/rfc6126>.
[BABEL-DIV] Chroboczek, J., "Diversity Routing for the Babel Routing Protocol", Work in Progress, draft-chroboczek-babel-diversity-routing-00, July 2014.
[BABEL-DIV]Chroboczek，J.，“BABEL路由协议的分集路由”，正在进行的工作，草稿-Chroboczek-BABEL-Diversity-Routing-00，2014年7月。
[BABEL-RTT] Jonglez, B. and J. Chroboczek, "Delay-based Metric Extension for the Babel Routing Protocol", Work in Progress, draft-jonglez-babel-rtt-extension-01, May 2015.
[BABEL-RTT]Jonglez，B.和J.Chroboczek，“BABEL路由协议基于延迟的度量扩展”，正在进行的工作，草稿-Jonglez-BABEL-RTT-Extension-01，2015年5月。
[BABEL-SS] Boutier, M. and J. Chroboczek, "Source-Specific Routing in Babel", Work in Progress, draft-boutier-babel-source-specific-01, May 2015.
[BABEL-SS]Boutier，M.和J.Chroboczek，“BABEL中的特定源路由”，正在进行的工作，草稿-Boutier-BABEL-Source-Specific-012015年5月。
[RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication", RFC 7298, DOI 10.17487/RFC7298, July 2014, <http://www.rfc-editor.org/info/rfc7298>.
[RFC7298]Ovsienko，D.，“Babel哈希消息认证码（HMAC）加密认证”，RFC 7298，DOI 10.17487/RFC7298，2014年7月<http://www.rfc-editor.org/info/rfc7298>.
Acknowledgments
致谢
I am grateful to Denis Ovsienko and Gabriel Kerneis for their feedback on previous draft versions of this document.
我感谢Denis Ovsienko和Gabriel Kerneis对本文件先前草稿的反馈。
Author's Address
作者地址
Juliusz Chroboczek PPS, University of Paris-Diderot Case 7014 75205 Paris Cedex 13 France
Juliusz Chroboczek PPS，巴黎大学狄德罗案7014巴黎75205 CEDEX 13法国
EMail: jch@pps.univ-paris-diderot.fr
EMail: jch@pps.univ-paris-diderot.fr