Network Working Group T. Clausen
Request for Comments: 5444 LIX, Ecole Polytechnique
Category: Standards Track C. Dearlove
BAE Systems ATC
J. Dean
Naval Research Laboratory
C. Adjih
INRIA Rocquencourt
February 2009
Network Working Group T. Clausen
Request for Comments: 5444 LIX, Ecole Polytechnique
Category: Standards Track C. Dearlove
BAE Systems ATC
J. Dean
Naval Research Laboratory
C. Adjih
INRIA Rocquencourt
February 2009
Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format
通用移动自组网（MANET）数据包/消息格式
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/ 许可证信息）在本文件发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
This document specifies a packet format capable of carrying multiple messages that may be used by mobile ad hoc network routing protocols.
本文档规定了一种能够承载移动自组织网络路由协议可能使用的多条消息的数据包格式。
Table of Contents
目录
1. Introduction ....................................................3
2. Notation and Terminology ........................................4
2.1. Notation ...................................................4
2.1.1. Elements ............................................4
2.1.2. Variables ...........................................5
2.2. Terminology ................................................5
3. Applicability Statement .........................................6
4. Protocol Overview and Functioning ...............................7
5. Syntactical Specification .......................................7
5.1. Packets ....................................................8
5.2. Messages ...................................................9
5.3. Address Blocks ............................................11
5.4. TLVs and TLV Blocks .......................................14
5.4.1. TLVs ...............................................14
5.4.2. TLV Usage ..........................................17
5.5. Malformed Elements ........................................18
6. IANA Considerations ............................................18
6.1. Expert Review: Evaluation Guidelines ......................18
6.2. Message Types .............................................20
6.2.1. Message-Type-Specific TLV Registry Creation ........20
6.3. Packet TLV Types ..........................................21
6.3.1. Packet TLV Type Extension Registry Creation ........21
6.4. Message TLV Types .........................................21
6.4.1. Message TLV Type Extension Registry Creation .......22
6.5. Address Block TLV Types ...................................22
6.5.1. Address Block TLV Type Extension Registry
Creation ...........................................23
7. Security Considerations ........................................23
7.1. Authentication and Integrity Suggestions ..................23
7.2. Confidentiality Suggestions ...............................24
8. Contributors ...................................................25
9. Acknowledgments ................................................25
10. References ....................................................26
10.1. Normative References .....................................26
10.2. Informative References ...................................27
Appendix A. Multiplexing and Demultiplexing .......................28
Appendix B. Intended Usage ........................................28
Appendix C. Examples ..............................................30
C.1. Address Block Examples ....................................30
C.2. TLV Examples ..............................................32
Appendix D. Illustrations .........................................34
D.1. Packet ....................................................34
D.2. Message ...................................................38
D.3. Message Body ..............................................44
D.4. Address Block .............................................45
1. Introduction ....................................................3
2. Notation and Terminology ........................................4
2.1. Notation ...................................................4
2.1.1. Elements ............................................4
2.1.2. Variables ...........................................5
2.2. Terminology ................................................5
3. Applicability Statement .........................................6
4. Protocol Overview and Functioning ...............................7
5. Syntactical Specification .......................................7
5.1. Packets ....................................................8
5.2. Messages ...................................................9
5.3. Address Blocks ............................................11
5.4. TLVs and TLV Blocks .......................................14
5.4.1. TLVs ...............................................14
5.4.2. TLV Usage ..........................................17
5.5. Malformed Elements ........................................18
6. IANA Considerations ............................................18
6.1. Expert Review: Evaluation Guidelines ......................18
6.2. Message Types .............................................20
6.2.1. Message-Type-Specific TLV Registry Creation ........20
6.3. Packet TLV Types ..........................................21
6.3.1. Packet TLV Type Extension Registry Creation ........21
6.4. Message TLV Types .........................................21
6.4.1. Message TLV Type Extension Registry Creation .......22
6.5. Address Block TLV Types ...................................22
6.5.1. Address Block TLV Type Extension Registry
Creation ...........................................23
7. Security Considerations ........................................23
7.1. Authentication and Integrity Suggestions ..................23
7.2. Confidentiality Suggestions ...............................24
8. Contributors ...................................................25
9. Acknowledgments ................................................25
10. References ....................................................26
10.1. Normative References .....................................26
10.2. Informative References ...................................27
Appendix A. Multiplexing and Demultiplexing .......................28
Appendix B. Intended Usage ........................................28
Appendix C. Examples ..............................................30
C.1. Address Block Examples ....................................30
C.2. TLV Examples ..............................................32
Appendix D. Illustrations .........................................34
D.1. Packet ....................................................34
D.2. Message ...................................................38
D.3. Message Body ..............................................44
D.4. Address Block .............................................45
D.5. TLV Block .................................................52
D.6. TLV .......................................................53
Appendix E. Complete Example ......................................57
D.5. TLV Block .................................................52
D.6. TLV .......................................................53
Appendix E. Complete Example ......................................57
This document specifies the syntax of a packet format designed for carrying multiple routing protocol messages for information exchange between MANET (Mobile Ad hoc NETwork) routers. Messages consist of a Message Header, which is designed for control of message dissemination, and a Message Body, which contains protocol information. Only the syntax of the packet and messages is specified.
本文件规定了用于承载多个路由协议消息的数据包格式的语法，以便在MANET（移动自组织网络）路由器之间进行信息交换。消息由消息头（用于控制消息传播）和消息体（包含协议信息）组成。只指定数据包和消息的语法。
This document specifies:
本文件规定：
o A packet format, allowing zero or more messages to be contained within a single transmission. A packet with zero messages may be sent in case the only information to exchange is contained in the Packet Header.
o 一种数据包格式，允许在一次传输中包含零条或多条消息。如果要交换的唯一信息包含在分组报头中，则可以发送具有零消息的分组。
o A message format, where a message is composed of a Message Header and a Message Body.
o 一种消息格式，其中消息由消息头和消息体组成。
o A Message Header format, which contains information that may be sufficient to allow a protocol using this specification to make processing and forwarding decisions.
o 一种消息头格式，其中包含的信息可能足以允许使用此规范的协议做出处理和转发决策。
o A Message Body format, containing attributes associated with the message or the originator of the message, as well as blocks of addresses, or address prefixes, with associated attributes.
o 一种报文正文格式，包含与报文或报文发起人相关联的属性，以及带有相关属性的地址块或地址前缀。
o An Address Block format, where an Address Block represents sets of addresses, or address prefixes, in a compact form with aggregated addresses.
o 一种地址块格式，其中地址块以压缩形式表示地址集或地址前缀，并带有聚合地址。
o A generalized type-length-value (TLV) format representing attributes. Each TLV can be associated with a packet, a message, or one or more addresses or address prefixes in a single Address Block. Multiple TLVs can be included, each associated with a packet, a message, and the same, different, or overlapping sets of addresses or address prefixes.
o 表示属性的通用类型长度值（TLV）格式。每个TLV可以与单个地址块中的数据包、消息或一个或多个地址或地址前缀相关联。可以包括多个TLV，每个TLV与数据包、消息以及相同、不同或重叠的地址集或地址前缀相关联。
The specification has been explicitly designed with the following properties, listed in no particular order, in mind:
本规范明确设计了以下特性，并没有按照特定顺序列出：
Parsing logic - The notation used in this specification facilitates generic, protocol-independent parsing logic.
解析逻辑-本规范中使用的符号有助于实现通用的、与协议无关的解析逻辑。
Extensibility - Packets and messages defined by a protocol using this specification are extensible by defining new messages and new TLVs. Protocols using this specification will be able to correctly identify and skip such new messages and TLVs, while correctly parsing the remainder of the packet and message.
可扩展性—使用此规范的协议定义的数据包和消息可通过定义新消息和新TLV进行扩展。使用此规范的协议将能够正确识别和跳过此类新消息和TLV，同时正确解析数据包和消息的其余部分。
Efficiency - When reported addresses share common bit sequences (e.g., address prefixes or IPv6 interface identifiers), the Address Block representation allows for a compact representation. Compact Message Headers are ensured through permitting inclusion of only required Message Header elements. The multi-message packet structure allows a reduction in the number of transmitted octets and in the number of transmitted packets. The structure of packet and message encoding allows parsing, verifying, and identifying individual elements in a single pass.
效率-当报告的地址共享公共位序列（例如，地址前缀或IPv6接口标识符）时，地址块表示允许紧凑表示。通过只允许包含所需的消息头元素来确保消息头的紧凑性。多消息分组结构允许减少发送的八位字节的数量和发送的分组的数量。数据包和消息编码的结构允许在一次传递中解析、验证和识别单个元素。
Separation of forwarding and processing - A protocol using this specification can be designed such that duplicate detection and controlled-scope message forwarding decisions can be made using information contained in the Message Header, without processing the Message Body.
转发和处理分离-可以设计使用本规范的协议，以便使用消息头中包含的信息做出重复检测和受控范围消息转发决策，而无需处理消息体。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
Additionally, this document uses the notation in Section 2.1 and the terminology in Section 2.2.
此外，本文件使用第2.1节中的符号和第2.2节中的术语。
The following notations, for elements and variables, are used in this document.
本文件中使用了以下元素和变量的符号。
This format uses network byte order (most significant octet first) for all fields. The most significant bit in an octet is numbered bit 0, and the least significant bit of an octet is numbered bit 7 [Stevens].
此格式对所有字段使用网络字节顺序（首先是最重要的八位字节）。八位字节中的最高有效位是编号为0的位，八位字节中的最低有效位是编号为7的位[Stevens]。
This specification defines elements. An element is a group of any number of consecutive bits that together form a syntactic entity represented using the notation <element>. Each element in this document is defined as either:
本规范定义了元素。元素是由任意数量的连续位组成的一组，这些位共同构成了使用符号<element>表示的语法实体。本文件中的每个元素定义为：
o a specifically sized field of bits OR
o 一种特定大小的位或数的字段
o a composite element, composed of other <element>s.
o 由其他<element>s组成的复合元素。
A composite element is defined as follows:
组合元素的定义如下：
<element> := specification
<element> := specification
where, on the right hand side following :=, specification is represented using the regular expression syntax defined in [SingleUNIX]. Only the following notation is used:
其中，在后面的右侧：=，使用[SingleUNIX]中定义的正则表达式语法表示规范。仅使用以下符号：
<element1><element2> - Indicates that <element1> is immediately followed by <element2>.
<element1><element2>-表示紧跟在<element1>之后的是<element2>。
(<element1><element2>) - Indicates a grouping of the elements enclosed by the parentheses.
（<element1><element2>）-表示由括号括起的元素分组。
? - Zero or one occurrences of the preceding element or group.
? - 前面元素或组的零次或一次出现。
* - Zero or more occurrences of the preceding element or group.
* -前面元素或组的零次或多次出现。
Variables are introduced into the specification solely as a means to clarify the description. The following two notations are used:
在规范中引入变量仅仅是为了澄清说明。使用以下两种符号：
<foo> - If <foo> is an unsigned integer field, then <foo> is also used to represent the value of that field.
<foo>-如果<foo>是无符号整数字段，则<foo>也用于表示该字段的值。
bar - A variable, usually obtained through calculations based on the value(s) of element(s).
bar-一个变量，通常通过基于元素值的计算获得。
This document uses the following terminology:
本文件使用以下术语：
Packet - The top level entity in this specification. A packet contains a Packet Header and zero or more messages.
数据包-本规范中的顶级实体。数据包包含一个数据包头和零条或多条消息。
Message - The fundamental entity carrying protocol information, in the form of address objects and TLVs.
消息-以地址对象和TLV的形式承载协议信息的基本实体。
Address - A number of octets that make up an address of the length indicated by the encapsulating Message Header. The meaning of an address is defined by the protocol using this specification.
地址-组成封装消息头所指示长度地址的八位字节数。地址的含义由使用本规范的协议定义。
Address Prefix - An address plus a prefix length, with the prefix length being a number of address bits measured from the left/most significant end of the address.
地址前缀-地址加上前缀长度，前缀长度是从地址的左/最高有效端测量的地址位数。
Address Object - Either an address, or an address prefix, as specified in an Address Block in this specification.
地址对象-本规范中地址块中指定的地址或地址前缀。
TLV - A type-length-value structure. This is a generic way in which an attribute can be represented and correctly parsed without the parser having to understand the attribute.
TLV-类型长度值结构。这是一种通用的方法，可以在解析器不必理解属性的情况下表示和正确解析属性。
This specification describes a generic packet format, designed for use by MANET routing protocols. The specification has been inspired by and extended from that used by the OLSR (Optimized Link State Routing) protocol [RFC3626].
本规范描述了一种通用数据包格式，设计用于MANET路由协议。该规范受OLSR（优化链路状态路由）协议[RFC3626]的启发并从中扩展。
MANETs are, commonly though not exclusively, characterized as being able to run over wireless network interfaces of limited to moderate capacity. MANETs are therefore less tolerant of wasted transmitted octets than are most wired networks. This specification thus represents a tradeoff between sometimes competing attributes, specifically efficiency, extensibility, and ease of use.
移动自组网（MANET）通常（但不是唯一）的特点是能够在有限到中等容量的无线网络接口上运行。因此，与大多数有线网络相比，移动自组网对浪费传输的八位字节的容忍度较低。因此，该规范代表了有时相互竞争的属性之间的权衡，特别是效率、可扩展性和易用性。
Efficiency is supported by reducing packet size and by allowing multiple disjoint messages in a single packet. Reduced packet size is primarily supported by address aggregation, optional Packet Header and Message Header fields, and optional fields in Address Blocks and TLVs. Supporting multi-message packets allows a reduction in the number of packets, each of which can incur significant bandwidth costs from transport, network, and lower layers.
通过减少数据包大小和允许在单个数据包中包含多个不相交的消息来支持效率。减少的数据包大小主要由地址聚合、可选数据包头和消息头字段以及地址块和TLV中的可选字段支持。支持多消息包可以减少数据包的数量，每个数据包都会导致传输、网络和较低层的带宽成本。
This specification provides both external and internal extensibility. External extensibility is supported by the ability to add Packet TLVs and to define new Message Types. Internal extensibility is supported by the ability to add Message TLVs and Address Block TLVs to existing messages. Protocols can define new TLV Types, and hence the contents of their Value fields, and new Message Types (see Section 6.1). Protocols can also reuse TLV Type definitions from other protocols that also use this specification.
该规范提供了外部和内部扩展性。添加数据包TLV和定义新消息类型的能力支持外部扩展性。向现有消息添加消息TLV和地址块TLV的能力支持内部扩展性。协议可以定义新的TLV类型，从而定义其值字段的内容和新的消息类型（参见第6.1节）。协议还可以重用来自也使用此规范的其他协议的TLV类型定义。
This specification aims at being sufficiently expressive and flexible to be able to accommodate different classes of MANET routing protocols (e.g., proactive, reactive, and hybrid routing protocols) as well as extensions thereto. Having a common packet and message
本规范旨在具有足够的表达能力和灵活性，以便能够适应不同类别的MANET路由协议（例如，主动式、反应式和混合式路由协议）及其扩展。有共同的数据包和信息
format, and a common way of representing IP addresses and associated attributes, allows generic parsing code to be developed, regardless of the algorithm used by the routing protocol.
格式，以及表示IP地址和相关属性的常用方式，允许开发通用解析代码，而不管路由协议使用何种算法。
All addresses within a message are assumed to be of the same size, specified in the Message Header. In the case of mixed IPv6 and IPv4 addresses, IPv4 addresses can be represented as IPv4-mapped IPv6 addresses as specified in [RFC4291].
假定消息中的所有地址大小相同，在消息头中指定。在混合使用IPv6和IPv4地址的情况下，IPv4地址可以表示为[RFC4291]中指定的IPv4映射IPv6地址。
The messages defined by this specification are designed to carry MANET routing protocol signaling between MANET routers. This specification includes elements that can support scope-limited flooding, as well as being usable for point-to-point delivery of MANET routing protocol signaling in a multi-hop network. Packets may be unicast or multicast and may use any appropriate transport protocol or none.
本规范定义的消息旨在承载MANET路由器之间的MANET路由协议信令。本规范包括可支持范围受限泛洪的元件，以及可用于多跳网络中MANET路由协议信令的点对点交付的元件。数据包可以是单播或多播的，并且可以使用任何适当的传输协议，也可以不使用。
A MANET routing protocol using the message format defined by this specification can constrain the syntax (for example, requiring a specific set of Message Header fields) that the protocol will employ. Protocols with such restrictions need not be able to parse all possible message structures as defined by this document but must be coherent in message generation and reception of messages that they define. If a protocol specifies which elements are included, then direct indexing of the appropriate fields is possible, dependent on the syntax restrictions imposed by the protocol. Such protocols may have more limited extensibility.
使用本规范定义的消息格式的MANET路由协议可以约束协议将采用的语法（例如，需要一组特定的消息头字段）。具有此类限制的协议不需要能够解析本文档定义的所有可能的消息结构，但必须在其定义的消息生成和接收中保持一致。如果协议指定包含哪些元素，则根据协议施加的语法限制，可以对相应字段进行直接索引。这样的协议可能具有更有限的可扩展性。
This specification does not describe a protocol. It describes a packet format, which may be used by any mobile ad hoc network routing protocol.
本规范不描述协议。它描述了一种数据包格式，可由任何移动自组织网络路由协议使用。
This section normatively provides the syntactical specification of a packet, represented by the element <packet> and the elements from which it is composed. The specification is given using the notation in Section 2.1.
本节规范性地提供了数据包的语法规范，由元素<packet>及其组成元素表示。本规范使用第2.1节中的符号给出。
Graphical illustrations of the layout of specified elements are given in Appendix D, a graphical illustration of a complete example (a packet including a message with Address Blocks and TLVs) is given in Appendix E.
附录D中给出了指定元件布局的图形说明，附录E中给出了完整示例（包括带有地址块和TLV的消息的数据包）的图形说明。
This format uses network byte order, as indicated in Section 2.1.
该格式使用网络字节顺序，如第2.1节所示。
<packet> is defined by:
<packet>的定义如下：
<packet> := <pkt-header>
<message>*
<packet> := <pkt-header>
<message>*
where <message> is as defined in Section 5.2. Successful parsing is terminated when all octets of the packet (as defined by the datagram containing the packet) are used.
其中<message>的定义见第5.2节。当使用数据包的所有八位字节（由包含该数据包的数据报定义）时，成功的解析终止。
<pkt-header> is defined by:
<pkt header>由以下内容定义：
<pkt-header> := <version>
<pkt-flags>
<pkt-seq-num>?
<tlv-block>?
<pkt-header> := <version>
<pkt-flags>
<pkt-seq-num>?
<tlv-block>?
where:
哪里：
<version> is a 4-bit unsigned integer field and specifies the version of the specification on which the packet and the contained messages are constructed. This document specifies version 0.
<version>是一个4位无符号整数字段，指定用于构造数据包和包含的消息的规范版本。此文档指定版本0。
<pkt-flags> is a 4-bit field, specifying the interpretation of the remainder of the Packet Header:
<pkt flags>是一个4位字段，指定对包头其余部分的解释：
bit 0 (phasseqnum): If cleared ('0'), then <pkt-seq-num> is not included in the <pkt-header>. If set ('1'), then <pkt-seq-num> is included in the <pkt-header>.
位0（phasseqnum）：如果清除（'0'），则<pkt seq num>不包括在<pkt头中。如果设置为（'1'），则<pkt seq num>包含在<pkt header>中。
bit 1 (phastlv): If cleared ('0'), then <tlv-block> is not included in the <pkt-header>. If set ('1'), then <tlv-block> is included in the <pkt-header>.
位1（相位tlv）：如果清除（'0'），则<pkt头中不包括<tlv块>。如果设置了（'1'），则<tlv block>包含在<pkt头中。
bits 2-3: Are RESERVED and SHOULD each be cleared ('0') on transmission and SHOULD be ignored on reception.
位2-3：保留，传输时应清除（“0”），接收时应忽略。
<pkt-seq-num> is omitted if the phasseqnum flag is cleared ('0'); otherwise, is a 16-bit unsigned integer field, specifying a Packet Sequence Number.
如果清除phasseqnum标志（'0'），则省略<pkt seq num>；否则，是一个16位无符号整数字段，指定数据包序列号。
<tlv-block> is omitted if the phastlv flag is cleared ('0') and is otherwise as defined in Section 5.4.
如果清除了phastlv标志（'0'），并且如第5.4节所定义，则省略<tlv block>。
It is assumed that the network layer is able to deliver the exact payload length, thus avoiding having to carry the packet length in the packet.
假设网络层能够传送准确的有效载荷长度，从而避免必须在分组中携带分组长度。
Packets may, in addition to the Packet Header, contain one or more messages. Messages contain:
除了分组报头之外，分组还可以包含一个或多个消息。信息包括：
o A Message Header.
o 消息头。
o A Message TLV Block that contains zero or more TLVs, associated with the whole message.
o 包含零个或多个TLV的消息TLV块，与整个消息关联。
o Zero or more Address Blocks, each containing one or more address objects.
o 零个或多个地址块，每个地址块包含一个或多个地址对象。
o An Address Block TLV Block, containing zero or more TLVs and following each Address Block, through which addresses can be associated with additional attributes.
o 一种地址块TLV块，包含零个或多个TLV，在每个地址块之后，通过该地址块可以将地址与附加属性相关联。
<message> is defined by:
<message>的定义如下：
<message> := <msg-header>
<tlv-block>
(<addr-block><tlv-block>)*
<message> := <msg-header>
<tlv-block>
(<addr-block><tlv-block>)*
<msg-header> := <msg-type>
<msg-flags>
<msg-addr-length>
<msg-size>
<msg-orig-addr>?
<msg-hop-limit>?
<msg-hop-count>?
<msg-seq-num>?
<msg-header> := <msg-type>
<msg-flags>
<msg-addr-length>
<msg-size>
<msg-orig-addr>?
<msg-hop-limit>?
<msg-hop-count>?
<msg-seq-num>?
where:
哪里：
<tlv-block> is as defined in Section 5.4.
<tlv block>的定义见第5.4节。
<addr-block> is as defined in Section 5.3.
<addr block>如第5.3节所述。
<msg-type> is an 8-bit unsigned integer field, specifying the type of the message.
<msg type>是一个8位无符号整数字段，用于指定消息的类型。
<msg-flags> is a 4-bit field, specifying the interpretation of the remainder of the Message Header:
<msg flags>是一个4位字段，指定消息头其余部分的解释：
bit 0 (mhasorig): If cleared ('0'), then <msg-orig-addr> is not included in the <msg-header>. If set ('1'), then <msg-orig-addr> is included in the <msg-header>.
位0（mhasorig）：如果清除（'0'），则<msg orig addr>不包括在<msg header>中。如果设置（'1'），则<msg orig addr>包含在<msg header>中。
bit 1 (mhashoplimit): If cleared ('0'), then <msg-hop-limit> is not included in the <msg-header>. If set ('1'), then <msg-hop-limit> is included in the <msg-header>.
位1（mhashoplimit）：如果清除（'0'），则<msg-hop-limit>不包括在<msg-header>中。如果设置（'1'），则<msg-hop-limit>包含在<msg-header>中。
bit 2 (mhashopcount): If cleared ('0'), then <msg-hop-count> is not included in the <msg-header>. If set ('1'), then <msg-hop-count> is included in the <msg-header>.
位2（mhashopcount）：如果清除（'0'），则<msg-hop-count>不包括在<msg-header>中。如果设置（'1'），则<msg-hop-count>包含在<msg-header>中。
bit 3 (mhasseqnum): If cleared ('0'), then <msg-seq-num> is not included in the <msg-header>. If set ('1'), then <msg-seq-num> is included in the <msg-header>.
位3（mhasseqnum）：如果清除（'0'），则<msg seq num>不包括在<msg header>中。如果设置（'1'），则<msg seq num>包含在<msg header>中。
<msg-addr-length> is a 4-bit unsigned integer field, encoding the length of all addresses included in this message (<msg-orig-addr> as well as each address included in Address Blocks as defined in Section 5.3), as follows:
<msg addr length>是一个4位无符号整数字段，编码此消息中包含的所有地址的长度（<msg orig addr>以及第5.3节中定义的地址块中包含的每个地址），如下所示：
<msg-addr-length> = the length of an address in octets - 1
<msg-addr-length> = the length of an address in octets - 1
<msg-addr-length> is thus 3 for IPv4 addresses, or 15 for IPv6 addresses.
因此，IPv4地址的<msg addr length>为3，IPv6地址的<msg addr length>为15。
address-length is a variable whose value is the length of an address in octets and is calculated as follows:
地址长度是一个变量，其值为地址的长度（以八位字节为单位），计算如下：
address-length = <msg-addr-length> + 1
address-length = <msg-addr-length> + 1
<msg-size> is a 16-bit unsigned integer field, specifying the number of octets that make up the <message>, including the <msg-header>.
<msg size>是一个16位无符号整数字段，指定组成<message>的八位字节数，包括<msg头>。
<msg-orig-addr> is omitted if the mhasorig flag is cleared ('0'); otherwise, is an identifier with length equal to address-length that can serve to uniquely identify the MANET router that originated the message.
如果清除mhasorig标志（'0'），则省略<msg orig addr>；否则，是长度等于地址长度的标识符，可用于唯一标识发起消息的MANET路由器。
<msg-hop-limit> is omitted if the mhashoplimit flag is cleared ('0'); otherwise, is an 8-bit unsigned integer field that can contain the maximum number of hops that the message should be further transmitted.
如果清除mhashoplimit标志（'0'），则省略<msg hop limit>；否则，是一个8位无符号整数字段，可包含消息应进一步传输的最大跳数。
<msg-hop-count> is omitted if the mhashopcount flag is cleared ('0'); otherwise, is an 8-bit unsigned integer field that can contain the number of hops that the message has traveled.
如果清除mhashopcount标志（'0'），则忽略<msg hop count>；否则，是一个8位无符号整数字段，可以包含消息经过的跃点数。
<msg-seq-num> is omitted if the mhasseqnum flag is cleared ('0'); otherwise, is a 16-bit unsigned integer field that can contain a sequence number, generated by the message's originator MANET router.
如果清除mhasseqnum标志（'0'），则省略<msg seq num>；否则，是一个16位无符号整数字段，它可以包含一个序列号，由消息的发起人MANET路由器生成。
An Address Block can specify one or more addresses, all of which will be address-length octets long, as specified using the <msg-addr-length> in the <msg-header> of the message containing the Address Block. An Address Block can also specify prefix lengths that can be applied to all addresses in the Address Block, if appropriate. This allows an Address Block to specify either addresses or address prefixes. A protocol may specify that an address with a maximum prefix length (equal to the address length in bits, i.e., 8 * address-length) is considered to be an address, rather than an address prefix, thus allowing an Address Block to contain a mixture of addresses and address prefixes. The common term "address object" is used in this specification to cover both of these; note that an address object in an Address Block always includes the prefix length, if present.
地址块可以指定一个或多个地址，所有地址都将是地址长度八位字节，如使用包含地址块的消息的<msg header>中的<msg addr length>指定的。如果合适，地址块还可以指定可应用于地址块中所有地址的前缀长度。这允许地址块指定地址或地址前缀。协议可以指定具有最大前缀长度（等于以位表示的地址长度，即8*地址长度）的地址被视为地址，而不是地址前缀，从而允许地址块包含地址和地址前缀的混合。本规范中使用的通用术语“地址对象”涵盖了这两个方面；请注意，地址块中的地址对象始终包含前缀长度（如果存在）。
An address is specified as a sequence of address-length octets of the form Head:Mid:Tail. There are no semantics associated with Head, Mid, or Tail; this representation is solely to allow aggregation of addresses, which often have common parts (e.g., common prefixes or multiple IPv6 addresses on the same interface). An Address Block contains an ordered set of addresses all sharing the same Head and the same Tail, but having individual Mids. Independently, Head and Tail may be empty, allowing for representation of address objects that do not have common Heads or common Tails. Detailed examples of Address Blocks are included in Appendix C.1.
地址被指定为Head:Mid:Tail格式的地址长度八位字节序列。没有与Head、Mid或Tail相关的语义；此表示仅允许聚合地址，这些地址通常具有公共部分（例如，公共前缀或同一接口上的多个IPv6地址）。地址块包含一组有序的地址，所有地址共享相同的头和尾，但具有单独的MID。独立地，Head和Tail可以是空的，允许表示没有公共Head或公共Tail的地址对象。地址块的详细示例见附录C.1。
An Address Block can specify address prefixes:
地址块可以指定地址前缀：
o with a single prefix length for all address prefixes OR
o 对于所有地址前缀或
o with a prefix length for each address prefix.
o 具有每个地址前缀的前缀长度。
<address-block> is defined by:
<address block>由以下内容定义：
<address-block> := <num-addr>
<addr-flags>
(<head-length><head>?)?
(<tail-length><tail>?)?
<mid>*
<prefix-length>*
<address-block> := <num-addr>
<addr-flags>
(<head-length><head>?)?
(<tail-length><tail>?)?
<mid>*
<prefix-length>*
where:
哪里：
<num-addr> is an 8-bit unsigned integer field containing the number of addresses represented in the Address Block, which MUST NOT be zero.
<num addr>是一个8位无符号整数字段，包含地址块中表示的地址数，不得为零。
<addr-flags> is an 8-bit field specifying the interpretation of the remainder of the Address Block:
<addr flags>是一个8位字段，指定对地址块其余部分的解释：
bit 0 (ahashead): If cleared ('0'), then <head-length> and <head> are not included in the <address-block>. If set ('1'), then <head-length> is included in the <address-block>, and <head> is included in the <address-block> unless <head-length> is zero.
位0（ahashead）：如果清除（'0'），则<head length>和<head>不包括在<address block>中。如果设置为（'1'），则<head length>包括在<address block>中，<head>包括在<address block>中，除非<head length>为零。
bit 1 (ahasfulltail) and bit 2 (ahaszerotail): Are interpreted according to Table 1. A combination not shown in that table MUST NOT be used.
第1位（ahasfulltail）和第2位（ahaszerotail）：根据表1进行解释。不得使用该表中未显示的组合。
bit 3 (ahassingleprelen) and bit 4 (ahasmultiprelen): Are interpreted according to Table 2. A combination not shown in that table MUST NOT be used.
第3位（AHASSINGLEN）和第4位（AHASMULTIPREN）：根据表2进行解释。不得使用该表中未显示的组合。
bits 5-7: Are RESERVED and SHOULD each be cleared ('0') on transmission and SHOULD be ignored on reception.
位5-7：保留，传输时应清除（“0”），接收时应忽略。
+--------------+--------------+---------------+---------------------+
| ahasfulltail | ahaszerotail | <tail-length> | <tail> |
+--------------+--------------+---------------+---------------------+
| 0 | 0 | not included | not included |
| 1 | 0 | included | included unless |
| | | | <tail-length> is |
| | | | zero |
| 0 | 1 | included | not included |
+--------------+--------------+---------------+---------------------+
+--------------+--------------+---------------+---------------------+
| ahasfulltail | ahaszerotail | <tail-length> | <tail> |
+--------------+--------------+---------------+---------------------+
| 0 | 0 | not included | not included |
| 1 | 0 | included | included unless |
| | | | <tail-length> is |
| | | | zero |
| 0 | 1 | included | not included |
+--------------+--------------+---------------+---------------------+
Table 1: Interpretation of the ahasfulltail and ahaszerotail flags
表1：ahasfulltail和ahaszerotail标志的解释
+------------+-----------+------------------+-----------------------+
| ahassingle | ahasmulti | number of | prefix length of the |
| prelen | prelen | <prefix-length> | nth address prefix, |
| | | fields | in bits |
+------------+-----------+------------------+-----------------------+
| 0 | 0 | 0 | 8 * address-length |
| 1 | 0 | 1 | <prefix-length> |
| 0 | 1 | <num-addr> | nth <prefix-length> |
+------------+-----------+------------------+-----------------------+
+------------+-----------+------------------+-----------------------+
| ahassingle | ahasmulti | number of | prefix length of the |
| prelen | prelen | <prefix-length> | nth address prefix, |
| | | fields | in bits |
+------------+-----------+------------------+-----------------------+
| 0 | 0 | 0 | 8 * address-length |
| 1 | 0 | 1 | <prefix-length> |
| 0 | 1 | <num-addr> | nth <prefix-length> |
+------------+-----------+------------------+-----------------------+
Table 2: Interpretation of the ahassingleprelen and ahasmultiprelen flags
表2：AHASSINGLEPREEN和AHASMULTIPREEN标志的解释
<head-length> if present, is an 8-bit unsigned integer field that contains the number of octets in the Head of all of the addresses in the Address Block, i.e., each <head> element included is <head-length> octets long.
<head length>如果存在，是一个8位无符号整数字段，其中包含地址块中所有地址的头中的八位字节数，即，包含的每个<head>元素都是<head length>八位字节长。
head-length is a variable, defined to equal <head-length>, if present, or 0 otherwise.
头部长度是一个变量，定义为等于<head length>（如果存在）或0（否则）。
<head> is omitted if head-length is equal to 0; otherwise, it is a field of the head-length leftmost octets common to all the addresses in the Address Block.
如果头部长度等于0，则省略<head>；否则，它是地址块中所有地址共有的头长最左八位字节字段。
<tail-length> if present, is an 8-bit unsigned integer field that contains the number of octets in the Tail of all of the addresses in the Address Block, i.e., each <tail> element included is <tail-length> octets long.
<tail length>如果存在，是一个8位无符号整数字段，它包含地址块中所有地址尾部的八位字节数，即包含的每个<tail>元素都是<tail length>八位字节长。
tail-length is a variable, defined to equal <tail-length>, if present, or 0 otherwise.
尾部长度是一个变量，定义为等于<tail length>（如果存在）或0（否则）。
<tail> is omitted if tail-length is equal to 0, or if the ahaszerotail flag is set ('1'); otherwise, it is a field of the tail-length rightmost octets common to all the addresses in the Address Block. If the ahaszerotail flag is set ('1'), then the tail-length rightmost octets of all the addresses in the Address Block are 0.
如果尾部长度等于0，或者如果设置了ahaszerotail标志（'1'），则省略<tail>；否则，它是地址块中所有地址共有的尾长最右边八位字节的字段。如果设置了ahaszerotail标志（'1'），则地址块中所有地址的最右边八位字节的尾部长度为0。
mid-length is a variable that MUST be non-negative, defined by:
中间长度是一个必须为非负的变量，定义如下：
mid-length := address-length - head-length - tail-length
mid-length := address-length - head-length - tail-length
i.e., each <mid> element included is mid-length octets long.
i、 例如，包含的每个<mid>元素都是中等长度的八位字节。
<mid> is omitted if mid-length is equal to 0; otherwise, each <mid> is a field of length mid-length octets, representing the Mid of the corresponding address in the Address Block. When not omitted, an Address Block contains exactly <num-addr> <mid> fields.
如果中间长度等于0，则省略<mid>；否则，每个<mid>都是一个长度为中等长度的八位字节字段，表示地址块中相应地址的mid。如果不省略，地址块正好包含<num addr><mid>字段。
<prefix-length> is an 8-bit unsigned integer field containing the length, in bits, of an address prefix. If the ahassingleprelen flag is set ('1'), then a single <prefix-length> field is included that contains the prefix length of all addresses in the Address Block. If the ahasmultiprelen flag is set ('1'), then <num-addr> <prefix-length> fields are included, each of which contains the prefix length of the corresponding address prefix in the Address Block (in the same order). Otherwise, no <prefix-length> fields are present; each address object can be considered to have a prefix length equal to 8 * address-length bits. The Address Block is malformed if any <prefix-length> element has a value greater than 8 * address-length.
<prefix length>是一个8位无符号整数字段，包含地址前缀的长度（以位为单位）。如果设置了ahassingleprelen标志（'1'），则会包含一个<prefix length>字段，其中包含地址块中所有地址的前缀长度。如果设置了ahasmultiprelen标志（'1'），则会包括<num addr><prefix length>字段，每个字段都包含地址块中相应地址前缀的前缀长度（顺序相同）。否则，不存在<prefix length>字段；可以认为每个地址对象的前缀长度等于8*地址长度位。如果任何<prefix length>元素的值大于8*地址长度，则地址块的格式不正确。
A TLV allows the association of an arbitrary attribute with a message or a packet, or with a single address or a contiguous set of addresses in an Address Block. The attribute (value) is made up from an integer number of consecutive octets. Different attributes have different types; attributes that are unknown when parsing can be skipped.
TLV允许将任意属性与消息或数据包关联，或与地址块中的单个地址或连续地址集关联。属性（值）由连续八位字节的整数组成。不同的属性有不同的类型；可以跳过解析时未知的属性。
TLVs are grouped in TLV Blocks, with all TLVs within a TLV Block associating attributes with either the packet (for the TLV Block in the Packet Header), the message (for the TLV Block immediately following the Message Header), or to addresses in the immediately preceding Address Block. Individual TLVs in a TLV Block immediately following an Address Block can associate attributes to a single address, a range of addresses, or all addresses in that Address Block. When associating an attribute with more than one address, a TLV can include one value for all addresses or one value per address. Detailed examples of TLVs are included in Appendix C.2.
TLV分组在TLV块中，TLV块中的所有TLV将属性与数据包（对于数据包标头中的TLV块）、消息（对于紧跟在消息标头之后的TLV块）或紧跟在前的地址块中的地址相关联。紧跟在地址块之后的TLV块中的各个TLV可以将属性与单个地址、地址范围或该地址块中的所有地址相关联。当将一个属性与多个地址关联时，TLV可以为所有地址包含一个值或每个地址包含一个值。TLV的详细示例见附录C.2。
A TLV Block is defined by:
TLV块的定义如下：
<tlv-block> := <tlvs-length>
<tlv>*
<tlv-block> := <tlvs-length>
<tlv>*
where:
哪里：
<tlvs-length> is a 16-bit unsigned integer field that contains the total number of octets in all of the immediately following <tlv> elements (<tlvs-length> not included).
<tlvs length>是一个16位无符号整数字段，包含紧跟其后的所有<tlv>元素中的八位字节总数（<tlvs length>不包括在内）。
<tlv> is as defined in Section 5.4.1.
<tlv>的定义见第5.4.1节。
There are three kinds of TLV, each represented by an element <tlv>:
有三种TLV，每种TLV由一个元素表示：
o A Packet TLV, included in the Packet TLV Block in a Packet Header.
o 一种分组TLV，包括在分组报头中的分组TLV块中。
o A Message TLV, included in the Message TLV Block in a message, before any Address Blocks.
o 在任何地址块之前，包含在消息的消息TLV块中的消息TLV。
o An Address Block TLV, included in an Address Block TLV Block following an Address Block. An Address Block TLV applies to:
o 一种地址块TLV，包括在地址块之后的地址块TLV块中。地址块TLV适用于：
* all address objects in the Address Block, OR
* 地址块中的所有地址对象，或
* any continuous sequence of address objects in the Address Block, OR
* 地址块中地址对象的任何连续序列，或
* a single address object in the Address Block.
* 地址块中的单个地址对象。
<tlv> is defined by:
<tlv>的定义如下：
<tlv> := <tlv-type>
<tlv-flags>
<tlv-type-ext>?
(<index-start><index-stop>?)?
(<length><value>?)?
<tlv> := <tlv-type>
<tlv-flags>
<tlv-type-ext>?
(<index-start><index-stop>?)?
(<length><value>?)?
where:
哪里：
<tlv-type> is an 8-bit unsigned integer field, specifying the type of the TLV, specific to the TLV kind (i.e., Packet TLV, Message TLV, or Address Block TLV).
<tlv type>是一个8位无符号整数字段，指定tlv的类型，特定于tlv类型（即数据包tlv、消息tlv或地址块tlv）。
<tlv-flags> is an 8-bit field specifying the interpretation of the remainder of the TLV:
<tlv flags>是一个8位字段，指定tlv其余部分的解释：
bit 0 (thastypeext): If cleared ('0'), then <tlv-type-ext> is not included in the <tlv>. If set ('1'), then <tlv-type-ext> is included in the <tlv>.
位0（thastypeext）：如果清除（'0'），则<tlv type ext>不包括在<tlv>中。如果设置（'1'），则<tlv type ext>包含在<tlv>中。
bit 1 (thassingleindex) and bit 2 (thasmultiindex): Are interpreted according to Table 3. A combination not shown in that table MUST NOT be used. Both of these flags MUST be cleared ('0') in Packet TLVs and Message TLVs.
第1位（thassingleindex）和第2位（ThassMultiIndex）：根据表3进行解释。不得使用该表中未显示的组合。必须在数据包TLV和消息TLV中清除这两个标志（“0”）。
bit 3 (thasvalue) and bit 4 (thasextlen): Are interpreted according to Table 4. A combination not shown in that table MUST NOT be used.
第3位（thasvalue）和第4位（thasextlen）：根据表4进行解释。不得使用该表中未显示的组合。
bit 5 (tismultivalue): This flag serves to specify how the <value> field is interpreted, as specified below. This flag MUST be cleared ('0') in Packet TLVs and Message TLVs, if the thasmultiindex flag is cleared ('0'), or if the thasvalue flag is cleared ('0').
位5（tismultivalue）：此标志用于指定如何解释<value>字段，如下所述。如果清除了thasmultiindex标志（'0'），或者如果清除了thasvalue标志（'0'），则必须在数据包TLV和消息TLV中清除该标志（'0'）。
bits 6-7: Are RESERVED and SHOULD each be cleared ('0') on transmission and SHOULD be ignored on reception.
位6-7：保留，传输时应清除（“0”），接收时应忽略。
+-----------------+----------------+---------------+--------------+
| thassingleindex | thasmultiindex | <index-start> | <index-stop> |
+-----------------+----------------+---------------+--------------+
| 0 | 0 | not included | not included |
| 1 | 0 | included | not included |
| 0 | 1 | included | included |
+-----------------+----------------+---------------+--------------+
+-----------------+----------------+---------------+--------------+
| thassingleindex | thasmultiindex | <index-start> | <index-stop> |
+-----------------+----------------+---------------+--------------+
| 0 | 0 | not included | not included |
| 1 | 0 | included | not included |
| 0 | 1 | included | included |
+-----------------+----------------+---------------+--------------+
Table 3: Interpretation of the thassingleindex and thasmultiindex flags
表3：thassingleindex和thasmultiindex标志的解释
+-----------+------------+--------------+---------------------------+
| thasvalue | thasextlen | <length> | <value> |
+-----------+------------+--------------+---------------------------+
| 0 | 0 | not included | not included |
| 1 | 0 | 8 bits | included unless <length> |
| | | | is zero |
| 1 | 1 | 16 bits | included unless <length> |
| | | | is zero |
+-----------+------------+--------------+---------------------------+
+-----------+------------+--------------+---------------------------+
| thasvalue | thasextlen | <length> | <value> |
+-----------+------------+--------------+---------------------------+
| 0 | 0 | not included | not included |
| 1 | 0 | 8 bits | included unless <length> |
| | | | is zero |
| 1 | 1 | 16 bits | included unless <length> |
| | | | is zero |
+-----------+------------+--------------+---------------------------+
Table 4: Interpretation of the thasvalue and thasextlen flags
表4:thasvalue和ThasExttlen标志的解释
<tlv-type-ext> is an 8-bit unsigned integer field, specifying an extension of the TLV Type, specific to the TLV Type and kind (i.e., Packet TLV, Message TLV, or Address Block TLV).
<tlv type ext>是一个8位无符号整数字段，指定tlv类型的扩展名，特定于tlv类型和种类（即数据包tlv、消息tlv或地址块tlv）。
tlv-type-ext is a variable, defined to equal <tlv-type-ext>, if present, or 0 otherwise.
tlv type ext是一个变量，如果存在，定义为等于<tlv type ext>，否则定义为0。
tlv-fulltype is a variable, defined by:
tlv fulltype是一个变量，定义如下：
tlv-fulltype := 256 * <tlv-type> + tlv-type-ext
tlv-fulltype := 256 * <tlv-type> + tlv-type-ext
<index-start> and <index-stop> when present, in an Address Block TLV only, are each an 8-bit unsigned integer field.
<index start>和<index stop>仅在地址块TLV中存在时，都是8位无符号整数字段。
index-start and index-stop are variables, defined according to Table 5. The variable end-index is defined as follows:
索引开始和索引停止是根据表5定义的变量。变量结束索引的定义如下：
* For Message TLVs and Packet TLVs:
* 对于消息TLV和数据包TLV：
end-index := 0
结束索引：=0
* For Address Block TLVs:
* 对于地址块TLV：
end-index := <num-addr> - 1
end-index := <num-addr> - 1
An Address Block TLV applies to the address objects from position index-start to position index-stop (inclusive) in the Address Block, where the first address object has position zero.
地址块TLV应用于地址块中从位置索引开始到位置索引停止（包括）的地址对象，其中第一个地址对象的位置为零。
+-----------------+----------------+----------------+---------------+
| thassingleindex | thasmultiindex | index-start := | index-stop := |
+-----------------+----------------+----------------+---------------+
| 0 | 0 | 0 | end-index |
| 1 | 0 | <index-start> | <index-start> |
| 0 | 1 | <index-start> | <index-stop> |
+-----------------+----------------+----------------+---------------+
+-----------------+----------------+----------------+---------------+
| thassingleindex | thasmultiindex | index-start := | index-stop := |
+-----------------+----------------+----------------+---------------+
| 0 | 0 | 0 | end-index |
| 1 | 0 | <index-start> | <index-start> |
| 0 | 1 | <index-start> | <index-stop> |
+-----------------+----------------+----------------+---------------+
Table 5: Interpretation of the thassingleindex and thasmultiindex flags
表5：thassingleindex和thasmultiindex标志的解释
number-values is a variable, defined by:
数值是一个变量，定义如下：
number-values := index-stop - index-start + 1
number-values := index-stop - index-start + 1
<length> is omitted or is an 8-bit or 16-bit unsigned integer field according to Table 4. If the tismultivalue flag is set ('1'), then <length> MUST be an integral multiple of number-values, and the variable single-length is defined by:
根据表4，<length>被省略或是8位或16位无符号整数字段。如果设置了TISMultipalue标志（'1'），则<length>必须是数值的整数倍，变量single length的定义如下：
single-length := <length> / number-values
single-length := <length> / number-values
If the tismultivalue flag is cleared ('0'), then the variable single-length is defined by:
如果清除TISMultipalue标志（'0'），则变量单长度的定义如下：
single-length := <length>
single-length := <length>
<value> if present (see Table 4), is a field of length <length> octets. In an Address Block TLV, <value> is associated with the address objects from positions index-start to index-stop, inclusive. If the tismultivalue flag is cleared ('0'), then the whole of this field is associated with each of the indicated address objects. If the tismultivalue flag is set ('1'), then this field is divided equally into number-values fields, each of length single-length octets, and these are associated, in order, with the indicated address objects.
<value>如果存在（见表4），则为长度<length>八位字节的字段。在地址块TLV中，<value>与地址对象从索引开始位置到索引停止位置（包括开始位置和结束位置）相关联。如果TISMultipalue标志被清除（“0”），则该字段的整个内容都与每个指定的地址对象相关联。如果设置了TISMultipalue标志（'1'），则该字段将被等分为数值字段，每个字段的长度为单长度八位字节，并且这些字段按顺序与指示的地址对象相关联。
A TLV associates an attribute with a packet, a message, or one or more consecutive address objects in an Address Block. The interpretation and processing of this attribute, and the relationship
TLV将属性与数据包、消息或地址块中的一个或多个连续地址对象相关联。该属性的解释和处理，以及
(including order of processing) between different attributes associated with the same entity MUST be defined by any protocol that uses this specification.
与同一实体关联的不同属性之间的（包括处理顺序）必须由使用本规范的任何协议定义。
Any protocol using this specification MUST define appropriate behaviors if this associated information is inconsistent, in particular if two TLVs of the same type but with different values apply to the same entity (packet, message, or address) but this is not meaningful. The protocol MUST also specify an appropriate processing order for TLVs associated with a given entity.
如果此关联信息不一致，则使用此规范的任何协议必须定义适当的行为，特别是如果两个相同类型但具有不同值的TLV应用于同一实体（数据包、消息或地址），但这没有意义。协议还必须为与给定实体关联的TLV指定适当的处理顺序。
An element is malformed if it cannot be parsed according to its syntactical specification (including if there are insufficient octets available). If the malformed element is in the Packet Header, then the packet MUST be silently discarded, and contained messages MUST NOT be processed and MUST NOT be forwarded. If the malformed element is contained in a message (i.e., is in the Message TLV Block, an Address Block, or an Address Block TLV Block), then that message MUST be silently discarded; it MUST NOT be processed and MUST NOT be forwarded.
如果无法根据其语法规范对元素进行分析（包括如果没有足够的八位字节可用），则该元素的格式不正确。如果格式错误的元素位于数据包头中，则必须以静默方式丢弃该数据包，并且不得处理和转发包含的消息。如果错误的元素包含在消息中（即，在消息TLV块、地址块或地址块TLV块中），则必须以静默方式丢弃该消息；不得对其进行处理，也不得转发。
This document introduces four namespaces that have been registered: Message Types, Packet TLV Types, Message TLV Types, and Address Block TLV Types. This section specifies IANA registries for these namespaces and provides guidance to the Internet Assigned Numbers Authority regarding registrations in these namespaces.
本文档介绍了已注册的四个名称空间：消息类型、数据包TLV类型、消息TLV类型和地址块TLV类型。本节规定了这些名称空间的IANA注册，并就这些名称空间中的注册向Internet Assigned Numbers Authority提供了指导。
The following terms are used with the meanings defined in [BCP26]: "Namespace", "Assigned Value", "Registration", "Unassigned", "Reserved", "Hierarchical Allocation", and "Designated Expert".
以下术语与[BCP26]中定义的含义相同：“名称空间”、“指定值”、“注册”、“未指定”、“保留”、“分层分配”和“指定专家”。
The following policies are used with the meanings defined in [BCP26]: "Private Use", "Expert Review", and "Standards Action".
以下政策的含义见[BCP26]：“私人使用”、“专家评审”和“标准行动”。
For registration requests where an Expert Review is required, the Designated Expert SHOULD take the following general recommendations into consideration:
对于需要专家审查的登记请求，指定专家应考虑以下一般性建议：
o The purpose of these registries is to support Standard and Experimental MANET routing and related protocols and extensions to these protocols.
o 这些注册中心的目的是支持标准和实验性的MANET路由和相关协议以及对这些协议的扩展。
o The intention is that all registrations will be accompanied by a published RFC.
o 其目的是，所有注册都将附带一份已发布的RFC。
o In order to allow for registration prior to the RFC being approved for publication, the Designated Expert can approve the registration once it seems clear that an RFC is expected to be published.
o 为了允许在批准发布RFC之前进行注册，一旦确定RFC有望发布，指定专家可以批准注册。
o The Designated Expert will post a request to the MANET WG mailing list, or to a successor thereto as designated by the Area Director, for comments and reviews. This request will include a reference to the Internet-Draft requesting the registration.
o 指定专家将向MANET工作组邮件列表或区域主任指定的后续邮件列表发送请求，以征求意见和审查。该请求将包括对请求注册的互联网草案的参考。
o Before a period of 30 days has passed, the Designated Expert will either approve or deny the registration request and publish a note of the decision to the MANET WG mailing list or its successor, as well as inform IANA and the IESG. A denial note MUST be justified by an explanation and, in cases where it is possible, suggestions as to how the request can be modified so as to become acceptable SHOULD be provided.
o 在30天内，指定专家将批准或拒绝注册请求，并向MANET工作组邮件列表或其继任者发布一份决定说明，并通知IANA和IESG。拒绝通知必须有解释作为理由，在可能的情况下，应提供关于如何修改请求以使其可接受的建议。
For the registry for Message Types, the following guidelines apply:
对于邮件类型注册表，以下准则适用：
o Registration of a Message Type implies creation of two registries for Message-Type-specific Message TLVs and Message-Type-specific Address Block TLVs. The document that requests the registration of the Message Type MUST indicate how these Message-Type-specific TLV Types are to be allocated, from any options in [BCP26], and any initial allocations. The Designated Expert SHOULD take the allocation policies specified for these registries into consideration in reviewing the Message Type allocation request.
o 消息类型的注册意味着为消息类型特定的消息TLV和消息类型特定的地址块TLV创建两个注册表。请求注册消息类型的文档必须指明如何从[BCP26]中的任何选项以及任何初始分配中分配这些消息类型特定的TLV类型。指定专家在审查电文类型分配请求时，应考虑到为这些登记册规定的分配政策。
For the registries for Packet TLV Types, Message TLV Types, and Address Block TLV Types, the following guidelines apply:
对于数据包TLV类型、消息TLV类型和地址块TLV类型的注册表，以下准则适用：
o These are Hierarchical Allocations, i.e., allocation of a type creates a registry for the extended types corresponding to that type. The document that requests the registration of the type MUST indicate how these extended types are to be allocated, from any options in [BCP26], and any initial allocations. Normally this allocation should also undergo Expert Review, but with the possible allocation of some type extensions as Reserved, Experimental, and/or Private.
o 这些是分层分配，即类型分配为对应于该类型的扩展类型创建一个注册表。请求注册类型的文档必须指明如何从[BCP26]中的任何选项以及任何初始分配中分配这些扩展类型。通常，这种分配也应该经过专家审查，但可能会分配一些类型扩展，如保留的、实验的和/或私有的。
o The request for a TLV Type MUST include the specification of the permitted size, syntax of any internal structure, and meaning, of the Value field (if any) of the TLV.
o TLV类型的请求必须包括TLV值字段（如有）的允许大小、任何内部结构的语法和含义的规范。
For the registries for Message TLV Types and Address Block TLV Types, the following additional guidelines apply:
对于消息TLV类型和地址块TLV类型的注册表，以下附加指南适用：
o TLV Type values 0-127 are common for all Message Types. TLVs that receive registrations from the 0-127 interval SHOULD be modular in design to allow reuse among protocols.
o TLV类型值0-127对于所有消息类型都是通用的。从0-127间隔接收注册的TLV在设计上应该是模块化的，以允许在协议之间重用。
o TLV Type values 128-223 are Message-Type-specific TLV Type values, relevant only in the context of the containing Message Type. Registration of TLV Type values within the 128-223 interval requires that a registry in the 128-223 interval exists for a specific Message Type value (see Section 6.2.1), and registrations are made in accordance with the allocation policies specified for these Message-Type-specific registries. Message-Type-specific TLV Types SHOULD be registered for TLVs that the Designated Expert deems too Message-Type-specific for registration of a 0-127 value. Multiple different TLV definitions MAY be assigned the same TLV Type value within the 128-223 interval, given that they are associated with different Message-Type-specific TLV Type registries. Where possible, existing global TLV definitions and modular global TLV definitions for registration in the 0-127 range SHOULD be used.
o TLV类型值128-223是特定于消息类型的TLV类型值，仅在包含消息类型的上下文中相关。在128-223时间间隔内注册TLV类型值需要在128-223时间间隔内为特定的消息类型值存在一个注册表（见第6.2.1节），并且根据为这些消息类型特定注册表指定的分配策略进行注册。对于指定专家认为特定于0-127值的TLV，应为其注册特定于消息类型的TLV类型。如果多个不同的TLV定义与不同的消息类型特定的TLV类型注册表相关联，则可以在128-223间隔内为它们分配相同的TLV类型值。在可能的情况下，应使用0-127范围内注册的现有全局TLV定义和模块化全局TLV定义。
A new registry for Message Types has been created, with initial assignments and allocation policies as specified in Table 6.
已为消息类型创建了一个新的注册表，初始分配和分配策略如表6所示。
+---------+-------------+-------------------+
| Type | Description | Allocation Policy |
+---------+-------------+-------------------+
| 0-223 | Unassigned | Expert Review |
| 224-255 | Unassigned | Experimental Use |
+---------+-------------+-------------------+
+---------+-------------+-------------------+
| Type | Description | Allocation Policy |
+---------+-------------+-------------------+
| 0-223 | Unassigned | Expert Review |
| 224-255 | Unassigned | Experimental Use |
+---------+-------------+-------------------+
Table 6: Message Types
表6：消息类型
When a Message Type is registered, then registries MUST be specified for both Message-Type-specific Message TLVs (Table 8) and Message-Type-specific Address Block TLVs (Table 10). A document that creates a Message-Type-specific TLV registry MUST also specify the mechanism by which Message-Type-specific TLV Types are allocated, from among those in [BCP26].
注册消息类型时，必须为消息类型特定的消息TLV（表8）和消息类型特定的地址块TLV（表10）指定注册表。创建特定于消息类型的TLV注册表的文档还必须指定从[BCP26]中分配特定于消息类型的TLV类型的机制。
A new registry for Packet TLV Types has been created, with initial assignments and allocation policies as specified in Table 7.
已经为数据包TLV类型创建了一个新的注册表，初始分配和分配策略如表7所示。
+---------+-------------+-------------------+
| Type | Description | Allocation Policy |
+---------+-------------+-------------------+
| 0-223 | Unassigned | Expert Review |
| 224-255 | Unassigned | Experimental Use |
+---------+-------------+-------------------+
+---------+-------------+-------------------+
| Type | Description | Allocation Policy |
+---------+-------------+-------------------+
| 0-223 | Unassigned | Expert Review |
| 224-255 | Unassigned | Experimental Use |
+---------+-------------+-------------------+
Table 7: Packet TLV Types
表7：数据包TLV类型
When a Packet TLV Type is registered, then a new registry for type extensions of that type must be created. A document that defines a Packet TLV Type MUST also specify the mechanism by which its type extensions are allocated, from among those in [BCP26].
注册数据包TLV类型时，必须为该类型的类型扩展创建新的注册表。定义数据包TLV类型的文档还必须从[BCP26]中指定分配其类型扩展的机制。
A new registry for Message-Type-independent Message TLV Types has been created, with initial assignments and allocation policies as specified in Table 8.
已为独立于消息类型的消息TLV类型创建了一个新的注册表，初始分配和分配策略如表8所示。
+---------+-----------------------+-----------------------+
| Type | Description | Allocation Policy |
+---------+-----------------------+-----------------------+
| 0-127 | Unassigned | Expert Review |
| 128-223 | Message-Type-specific | Reserved, see Table 9 |
| 224-255 | Unassigned | Experimental Use |
+---------+-----------------------+-----------------------+
+---------+-----------------------+-----------------------+
| Type | Description | Allocation Policy |
+---------+-----------------------+-----------------------+
| 0-127 | Unassigned | Expert Review |
| 128-223 | Message-Type-specific | Reserved, see Table 9 |
| 224-255 | Unassigned | Experimental Use |
+---------+-----------------------+-----------------------+
Table 8: Message TLV Types
表8：消息TLV类型
Message TLV Types 128-223 are reserved for Message-Type-specific Message TLVs, for which a new registry is created with the registration of a Message Type, and with initial assignments and allocation policies as specified in Table 9.
消息TLV类型128-223是为特定于消息类型的消息TLV保留的，为其创建一个新的注册中心，注册一个消息类型，并具有表9中指定的初始分配和分配策略。
+---------+-----------------------------+-------------------+
| Type | Description | Allocation Policy |
+---------+-----------------------------+-------------------+
| 0-127 | Common to all Message Types | Reserved |
| 128-223 | Message-Type-specific | See Below |
| 224-255 | Common to all Message Types | Reserved |
+---------+-----------------------------+-------------------+
+---------+-----------------------------+-------------------+
| Type | Description | Allocation Policy |
+---------+-----------------------------+-------------------+
| 0-127 | Common to all Message Types | Reserved |
| 128-223 | Message-Type-specific | See Below |
| 224-255 | Common to all Message Types | Reserved |
+---------+-----------------------------+-------------------+
Table 9: Message-Type-specific Message TLV Types
表9：特定于消息类型的消息TLV类型
Allocation policies for Message-Type-specific Message TLV Types MUST be specified when creating the registry associated with the containing Message Type, see Section 6.2.1.
创建与包含消息类型关联的注册表时，必须指定特定于消息类型的消息TLV类型的分配策略，请参见第6.2.1节。
If a Message TLV Type is registered, then a new registry for type extensions of that type must be created. A document that defines a Message TLV Type MUST also specify the mechanism by which its type extensions are allocated, from among those in [BCP26].
如果注册了消息TLV类型，则必须为该类型的类型扩展创建新的注册表。定义消息TLV类型的文档还必须从[BCP26]中指定分配其类型扩展的机制。
A new registry for Message-Type-independent Address Block TLV Types has been created, with initial assignments and allocation policies as specified in Table 10.
已为独立于消息类型的地址块TLV类型创建了一个新的注册表，初始分配和分配策略如表10所示。
+---------+-----------------------+------------------------+
| Type | Description | Allocation Policy |
+---------+-----------------------+------------------------+
| 0-127 | Unassigned | Expert Review |
| 128-223 | Message-Type-specific | Reserved, see Table 11 |
| 224-255 | Unassigned | Experimental Use |
+---------+-----------------------+------------------------+
+---------+-----------------------+------------------------+
| Type | Description | Allocation Policy |
+---------+-----------------------+------------------------+
| 0-127 | Unassigned | Expert Review |
| 128-223 | Message-Type-specific | Reserved, see Table 11 |
| 224-255 | Unassigned | Experimental Use |
+---------+-----------------------+------------------------+
Table 10: Address Block TLV Types
表10：地址块TLV类型
Address Block TLV Types 128-223 are reserved for Message-Type-specific Address Block TLVs, for which a new registry is created with the registration of a Message Type, and with initial assignments and allocation policies as specified in Table 11.
地址块TLV类型128-223是为特定于消息类型的地址块TLV保留的，为该地址块TLV创建了一个新的注册表，注册了一个消息类型，并具有表11中指定的初始分配和分配策略。
+---------+-----------------------------+-------------------+
| Type | Description | Allocation Policy |
+---------+-----------------------------+-------------------+
| 0-127 | Common to all Message Types | Reserved |
| 128-223 | Message-Type-specific | See Below |
| 224-255 | Common to all Message Types | Reserved |
+---------+-----------------------------+-------------------+
+---------+-----------------------------+-------------------+
| Type | Description | Allocation Policy |
+---------+-----------------------------+-------------------+
| 0-127 | Common to all Message Types | Reserved |
| 128-223 | Message-Type-specific | See Below |
| 224-255 | Common to all Message Types | Reserved |
+---------+-----------------------------+-------------------+
Table 11: Message-Type-specific Address Block TLV Types
表11：特定于消息类型的地址块TLV类型
Allocation policies for Message-Type-specific Address Block TLV Types MUST be specified when creating the registry associated with the containing Message Type, see Section 6.2.1.
创建与包含消息类型相关联的注册表时，必须指定特定于消息类型的地址块TLV类型的分配策略，请参见第6.2.1节。
When an Address Block TLV Type is registered, then a new registry for type extensions of that type must be created. A document that defines a Message TLV Type MUST also specify the mechanism by which its type extensions are allocated, from among those in [BCP26].
注册地址块TLV类型时，必须为该类型的类型扩展创建新的注册表。定义消息TLV类型的文档还必须从[BCP26]中指定分配其类型扩展的机制。
This specification does not describe a protocol; it describes a packet format. As such, it does not specify any security considerations; these are matters for a protocol using this specification. However, some security mechanisms are enabled by this specification and may form part of a protocol using this specification. Mechanisms that may form part of an authentication and integrity approach in a protocol using this specification are described in Section 7.1. Mechanisms that may form part of a confidentiality approach in a protocol using this specification are described in Section 7.2. There is, however, no requirement that a protocol using this specification should use either.
本规范不描述协议；它描述了一种数据包格式。因此，它没有规定任何安全考虑因素；这些是使用本规范的协议的事项。但是，某些安全机制由本规范启用，并且可能构成使用本规范的协议的一部分。第7.1节描述了在使用本规范的协议中可能构成认证和完整性方法一部分的机制。第7.2节描述了在使用本规范的协议中可能构成保密方法一部分的机制。但是，不要求使用此规范的协议也使用这两种规范。
The authentication and integrity suggestions made here are based on the intended usage in Appendix B, specifically that:
此处提出的认证和完整性建议基于附录B中的预期用途，具体如下：
o Messages are designed to be carriers of protocol information and MAY, at each hop, be forwarded and/or processed by the protocol using this specification.
o 消息被设计为协议信息的载体，并且可以在每个跃点处由协议使用本规范转发和/或处理。
o Packets are designed to carry a number of messages between neighboring MANET routers in a single transmission and over a single logical hop.
o 数据包被设计成在单个传输和单个逻辑跳上在相邻的MANET路由器之间传输大量消息。
Consequently:
因此：
o For forwarded messages where the message is unchanged by forwarding MANET routers, end-to-end authentication and integrity MAY be implemented, between MANET routers with an existing security association, by including a suitable Message TLV containing a cryptographic signature in the message. Since <msg-hop-count> and <msg-hop-limit> are the only fields that should be modified when such a message is forwarded in this manner, this signature can be calculated based on the entire message, including the Message Header, with the <msg-hop-count> and <msg-hop-limit> fields set to 0, if present.
o 对于转发的消息，其中消息通过转发MANET路由器保持不变，可通过在消息中包括包含密码签名的适当消息TLV，在具有现有安全关联的MANET路由器之间实现端到端认证和完整性。由于<msg hop count>和<msg hop limit>是以这种方式转发此类消息时应修改的唯一字段，因此可以基于整个消息（包括消息头）计算此签名，并且<msg hop count>和<msg hop limit>字段设置为0（如果存在）。
o Hop-by-hop packet level authentication and integrity MAY be implemented, between MANET routers with an existing security association, by including a suitable Packet TLV containing a cryptographic signature to the packet. Since packets are received as transmitted, this signature can be calculated based on the entire packet or on parts thereof as appropriate.
o 可以在具有现有安全关联的MANET路由器之间通过包括包含对分组的密码签名的合适分组TLV来实现逐跳分组级认证和完整性。由于分组是在发送时接收的，因此可以根据整个分组或其部分（视情况而定）来计算该签名。
This specification does not explicitly enable protecting packet/ message confidentiality. Such confidentiality would normally, when required, be provided hop-by-hop, either by link-layer mechanisms or at the IP layer using [RFC4301], and would apply to a packet only.
本规范未明确启用保护数据包/消息机密性。当需要时，这种保密性通常会通过链路层机制或在IP层使用[RFC4301]逐跳提供，并且只适用于数据包。
It is possible, however, for a protocol using this specification to protect the confidentiality of information included in a Packet, Message, or Address Block TLV by specifying that the Value field of that TLV Type be encrypted, as well as specifying the encryption mechanism.
然而，对于使用该规范的协议来说，可以通过指定该TLV类型的值字段被加密以及指定加密机制来保护包括在分组、消息或地址块TLV中的信息的机密性。
In an extreme case, all information can be encrypted by defining either:
在极端情况下，可以通过定义以下任一项对所有信息进行加密：
o A packet, consisting of only a Packet Header (with no messages) and containing a Packet TLV, where the Packet TLV Type indicates that its Value field contains one or more encrypted messages. Upon receipt, and once this Packet TLV is successfully decrypted, these messages may then be parsed according to this specification and processed according to the protocol using this specification.
o 一种数据包，仅由一个数据包头（无消息）组成，并包含一个数据包TLV，其中数据包TLV类型表示其值字段包含一个或多个加密消息。一旦收到，并且一旦成功解密该分组TLV，则可根据本规范解析这些消息，并根据使用本规范的协议处理这些消息。
o A message, consisting of only a Message Header and a single Message TLV, where the Message TLV Type indicates that its Value field contains an encrypted version of the message's remaining Message TLVs, Address Blocks, and Address Block TLVs. Upon receipt, and once this Message TLV is successfully decrypted, the
o 一种消息，仅由消息头和单个消息TLV组成，其中消息TLV类型指示其值字段包含消息其余消息TLV、地址块和地址块TLV的加密版本。一旦收到此消息TLV并成功解密，则
complete message may then be parsed according to this specification and processed according to the protocol using this specification.
然后，可以根据本规范对完整消息进行解析，并根据使用本规范的协议进行处理。
In either case, the protocol MUST define the encrypted TLV Type, as well as the format of the encrypted data block contained in the Value field of the TLV.
无论哪种情况，协议都必须定义加密的TLV类型，以及TLV的值字段中包含的加密数据块的格式。
This specification is the result of the joint efforts of the following contributors from the OLSRv2 Design Team, listed alphabetically:
本规范是以下OLSRv2设计团队贡献者共同努力的结果，按字母顺序列出：
o Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr>
o 塞德里克·阿吉，法国因里亚，<塞德里克。Adjih@inria.fr>
o Emmanuel Baccelli, INRIA, France, <Emmanuel.Baccelli@inria.fr>
o 伊曼纽尔·巴切利，法国因里亚，<伊曼纽尔。Baccelli@inria.fr>
o Thomas Heide Clausen, LIX, Ecole Polytechnique, France, <T.Clausen@computer.org>
o 托马斯·海德·克劳森，法国理工学院LIX，<T。Clausen@computer.org>
o Justin W. Dean, NRL, USA, <jdean@itd.nrl.navy.mil>
o 贾斯汀·W·迪安，美国北爱尔兰共和国<jdean@itd.nrl.navy.mil>
o Christopher Dearlove, BAE Systems, UK, <chris.dearlove@baesystems.com>
o Christopher Dearlove，英国BAE系统公司，<chris。dearlove@baesystems.com>
o Satoh Hiroki, Hitachi SDL, Japan, <hiroki.satoh.yj@hitachi.com>
o 佐藤广木，日立SDL，日本，<Hiroki.Satoh。yj@hitachi.com>
o Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr>
o 菲利普·雅克，法国因里亚，<菲利普。Jacquet@inria.fr>
o Monden Kazuya, Hitachi SDL, Japan, <kazuya.monden.vw@hitachi.com>
o Monden Kazuya，日立SDL，日本，<Kazuya.Monden。vw@hitachi.com>
The authors would like to acknowledge the team behind OLSR [RFC3626], including Anis Laouiti (INT, France), Pascale Minet, Laurent Viennot (both at INRIA, France), and Amir Qayyum (Center for Advanced Research in Engineering, Pakistan) for their contributions. Elwyn Davies (Folly Consulting, UK), Lars Eggert (Nokia, Finland), Chris Newman (Sun Microsystems, USA), Tim Polk (NIST, USA), and Magnus Westerlund (Ericsson, Sweden) all provided detailed reviews and insightful comments.
作者要感谢OLSR[RFC3626]背后的团队，包括Anis Laouiti（法国INT）、Pascale Minet、Laurent Vienno（均位于法国INRIA）和Amir Qayyum（巴基斯坦高级工程研究中心），感谢他们的贡献。Elwyn Davies（英国富利咨询公司）、Lars Eggert（芬兰诺基亚公司）、Chris Newman（美国太阳微系统公司）、Tim Polk（美国NIST公司）和Magnus Westerlund（瑞典爱立信公司）都提供了详细的评论和深刻的评论。
The authors would like to gratefully acknowledge the following people for intense technical discussions, early reviews, and comments on the specification and its components (listed alphabetically):
作者感谢以下人员对本规范及其组件（按字母顺序列出）进行了深入的技术讨论、早期审查和评论：
o Brian Adamson (NRL)
o 布莱恩·亚当森（NRL）
o Teco Boot (Infinity Networks)
o Teco Boot（无限网络）
o Florent Brunneau (LIX)
o 弗洛伦特布鲁诺（里克斯）
o Ian Chakeres (CenGen)
o 伊恩·查克斯（岑根）
o Alan Cullen (BAE Systems)
o 艾伦·库伦（英国宇航系统公司）
o Ulrich Herberg (LIX)
o 乌尔里希·赫伯格（LIX）
o Joe Macker (NRL)
o 乔·麦克尔（NRL）
o Yasunori Owada (Niigata University)
o 小和田Yasunori（新泻大学）
o Charlie E. Perkins (WiChorus)
o 查理·E·珀金斯（威科罗斯）
o Henning Rogge (FGAN)
o 亨宁·罗格（FGAN）
o Andreas Schjonhaug (LIX)
o Andreas Schjonhaug（LIX）
and the entire IETF MANET working group.
以及整个IETF移动自组网工作组。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 2119，BCP 14，1997年3月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[BCP26]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[SingleUNIX] IEEE Std 1003.1, The Open Group, and ISO/IEC JTC 1/SC22/WG15, "Single UNIX Specification, Version 3, 2004 Edition", April 2004.
[SingleUNIX]IEEE Std 1003.1开放组和ISO/IEC JTC 1/SC22/WG15，“单一UNIX规范，版本3，2004年版”，2004年4月。
[RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State Routing Protocol", RFC 3626, October 2003.
[RFC3626]Clausen，T.和P.Jacquet，“优化链路状态路由协议”，RFC 3626，2003年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[Stevens] Stevens, W., "TCP/IP Illustrated Volume 1 - The Protocols", 1994.
[Stevens]Stevens，W.，“TCP/IP图解卷1-协议”，1994年。
The packet and message format specified in this document is designed to allow zero or more messages to be contained within a single packet. Such messages may be from the same or different protocols. Thus, a multiplexing and demultiplexing process MUST be present.
本文件中规定的数据包和消息格式旨在允许在单个数据包中包含零条或多条消息。此类消息可以来自相同或不同的协议。因此，必须存在多路复用和解多路复用过程。
Multiplexing messages on a given MANET router into a single packet, rather than having each message generate its own packet, reduces the total number of octets and the number of packets transmitted by that MANET router.
将给定MANET路由器上的消息多路复用到单个数据包中，而不是让每条消息生成自己的数据包，从而减少了八位组的总数和该MANET路由器传输的数据包的数量。
The multiplexing and demultiplexing process running on a given UDP port or IP protocol number, and its associated protocols, MUST:
在给定UDP端口或IP协议号上运行的多路复用和解多路复用过程及其相关协议必须：
o For each Message Type, a protocol -- unless specified otherwise, the one making the IANA reservation for that Message Type -- MUST be designated as the "owner" of that Message Type.
o 对于每种消息类型，必须将协议（除非另有规定，否则为该消息类型进行IANA保留的协议）指定为该消息类型的“所有者”。
o The Packet Header fields, including the Packet TLV Block, are used by the multiplexing and demultiplexing process, which MAY make such information available for use in its protocol instances.
o 分组报头字段，包括分组TLV块，由复用和解复用过程使用，其可使此类信息在其协议实例中可用。
o The <pkt-seq-num> field, if present, contains a sequence number that is incremented by 1 for each packet generated by a node. The sequence number after 65535 is 0. In other words, the sequence number "wraps" in the usual way.
o <pkt seq num>字段（如果存在）包含一个序列号，该序列号对于节点生成的每个数据包递增1。65535之后的序列号为0。换句话说，序列号以通常的方式“包装”。
o Incoming messages MUST be either silently discarded or MUST be delivered to the instance of the protocol that owns the associated Message Type. Incoming messages SHOULD NOT be delivered to any other protocol instances and SHOULD NOT be delivered to more than one protocol instance.
o 传入消息必须以静默方式丢弃，或者必须传递到拥有关联消息类型的协议实例。传入消息不应传递到任何其他协议实例，也不应传递到多个协议实例。
o Outgoing messages of a given type MUST be generated only by the protocol instance that owns that Message Type and be delivered to the multiplexing and demultiplexing process.
o 给定类型的传出消息必须仅由拥有该消息类型的协议实例生成，并传递到多路复用和解多路复用进程。
o If two protocols both wish to use the same Message Type, then this interaction SHOULD be specified by the protocol that is the designated owner of that Message Type.
o 如果两个协议都希望使用相同的消息类型，则此交互应由作为该消息类型指定所有者的协议指定。
This appendix describes the intended usage of Message Header fields, including their content and use. Alternative uses of this specification are permitted.
本附录描述了消息头字段的预期用途，包括其内容和用途。允许替代使用本规范。
The message format specified in this document is designed to carry MANET routing protocol signaling between MANET routers and to support scope-limited flooding as well as point-to-point delivery.
本文档中指定的消息格式旨在承载MANET路由器之间的MANET路由协议信令，并支持范围有限的泛洪以及点对点交付。
Messages are designed to be able to be forwarded over one or more logical hops, in a new packet for each logical hop. Each logical hop may consist of one or more IP hops.
消息被设计为能够在一个或多个逻辑跳上转发，在每个逻辑跳的新数据包中。每个逻辑跃点可以由一个或多个IP跃点组成。
Specifically, scope-limited flooding is supported for messages when:
具体而言，在以下情况下，消息支持作用域受限泛洪：
o The <msg-orig-addr> field, if present, contains the unique identifier of the MANET router that originated the message.
o <msg orig addr>字段（如果存在）包含发起消息的MANET路由器的唯一标识符。
o The <msg-seq-num> field, if present, contains a sequence number that starts at 0 when the first message of a given type is generated by the originator node, and that is incremented by 1 for each message generated of that type. The sequence number after 65535 is 0. In other words, the sequence number "wraps" in the usual way.
o <msg seq num>字段（如果存在）包含一个序列号，当发起者节点生成给定类型的第一条消息时，该序列号从0开始，并且对于该类型生成的每条消息，该序列号递增1。65535之后的序列号为0。换句话说，序列号以通常的方式“包装”。
o If the <msg-orig-addr> and <msg-seq-num> fields are both present, then the Message Header provides for duplicate suppression, using the identifier consisting of the message's <msg-orig-addr>, <msg-seq-num>, and <msg-type>. These serve to uniquely identify the message in the MANET within the time period until <msg-seq-num> is repeated, i.e., wraps around to a matching value.
o 如果<msg orig addr>和<msg seq num>字段都存在，则消息头使用由消息的<msg orig addr>、<msg seq num>和<msg type>组成的标识符提供重复抑制。这些用于在重复<msg seq num>之前的时间段内唯一地标识MANET中的消息，即，环绕到匹配值。
o <msg-hop-limit> field, if present, contains the number of hops on which the packet is allowed to travel before being discarded by a MANET router. The <msg-hop-limit> is set by the message originator and is used to prevent messages from endlessly circulating in a MANET. When forwarding a message, a MANET router should decrease the <msg-hop-limit> by 1, and the message should be discarded when <msg-hop-limit> reaches 0.
o <msg hop limit>字段（如果存在）包含数据包在被MANET路由器丢弃之前允许传输的跃点数。<msg hop limit>由消息发起者设置，用于防止消息在MANET中无限循环。在转发消息时，MANET路由器应将<msg-hop-limit>减少1，当<msg-hop-limit>达到0时，消息应被丢弃。
o <msg-hop-count> field, if present, contains the number of hops on which the packet has traveled across the MANET. The <msg-hop-count> is set to 0 by the message originator and is used to prevent messages from endlessly circulating in a MANET. When forwarding a message, a MANET router should increase <msg-hop-count> by 1 and should discard the message when <msg-hop-count> reaches 255.
o <msg hop count>字段（如果存在）包含数据包在MANET上移动的跃点数。消息发起者将<msg hop count>设置为0，用于防止消息在MANET中无限循环。转发消息时，MANET路由器应将<msg hop count>增加1，并在<msg hop count>达到255时丢弃消息。
o If the <msg-hop-limit> and <msg-hop-count> fields are both present, then the Message Header provides the information to make forwarding decisions for scope-limited flooding. This may be by any appropriate flooding mechanism specified by a protocol using this specification.
o 如果<msg-hop-limit>和<msg-hop-count>字段都存在，则消息头将提供信息，以便为范围有限的泛洪做出转发决策。这可以通过使用本规范的协议指定的任何适当的泛洪机制来实现。
This appendix contains some examples of parts of this specification.
本附录包含本规范部分的一些示例。
The following examples illustrate how some combinations of addresses may be efficiently included in Address Blocks. These examples are for IPv4, with address-length equal to 4. a, b, c, etc. represent distinct, non-zero octet values.
以下示例说明如何在地址块中有效地包括一些地址组合。这些示例适用于IPv4，地址长度等于4。a、 b、c等表示不同的非零八位组值。
Note that it is permissible to use a less efficient representation, in particular one in which the ahashead and ahasfulltail flags are cleared ('0'), and hence head-length = 0, tail-length = 0, mid-length = address-length, and (with no address prefixes) the Address Block consists of the number of addresses, <addr-flags> with value 0, and a list of the unaggregated addresses. This is the most efficient way to represent a single address, and the only way to represent, for example, a.b.c.d and e.f.g.h in one Address Block.
请注意，允许使用效率较低的表示法，尤其是其中清除ahashead和ahasfulltail标志（'0'），因此头长=0，尾长=0，中长=地址长度，并且（没有地址前缀）地址块由地址数组成，值为0的<addr flags>，以及未汇总地址的列表。这是表示单个地址的最有效方法，也是在一个地址块中表示a.b.c.d和e.f.g.h等地址的唯一方法。
Examples:
示例：
o To include a.b.c.d, a.b.e.f, and a.b.g.h:
o 包括a.b.c.d、a.b.e.f和a.b.g.h：
* head-length = 2;
* 头长=2；
* tail-length = 0;
* 尾长=0；
* mid-length = 2;
* 中长=2；
* <addr-flags> has ahashead set (value 128);
* <addr-flags> has ahashead set (value 128);
* <tail-length> and <tail> are omitted.
* <tail length>和<tail>被省略。
The Address Block is then 3 128 2 a b c d e f g h (11 octets).
然后地址块是31282ABCDEFGH（11个八位字节）。
o To include a.b.c.g and d.e.f.g:
o 包括a.b.c.g和d.e.f.g：
* head-length = 0;
* 头长=0；
* tail-length = 1;
* 尾长=1；
* mid-length = 3;
* 中长=3；
* <addr-flags> has ahasfulltail set (value 64);
* <addr-flags> has ahasfulltail set (value 64);
* <head-length> and <head> are omitted.
* <head length>和<head>被省略。
The Address Block is then 2 64 1 g a b c d e f (10 octets).
地址块则为2641GBCDEF（10个八位字节）。
o To include a.b.d.e and a.c.d.e:
o 包括a.b.d.e和a.c.d.e：
* head-length = 1;
* 头长=1；
* tail-length = 2;
* 尾长=2；
* mid-length = 1;
* 中长=1；
* <addr-flags> has ahashead and ahasfulltail set (value 192).
* <addr flags>设置了ahashead和ahasfulltail（值192）。
The Address Block is then 2 192 1 a 2 d e b c (9 octets).
然后地址块是21921A2EDBC（9个八位字节）。
o To include a.b.0.0, a.c.0.0, and a.d.0.0:
o 包括a.b.0.0、a.c.0.0和a.d.0.0：
* head-length = 1;
* 头长=1；
* tail-length = 2;
* 尾长=2；
* mid-length = 1;
* 中长=1；
* <addr-flags> has ahashead and ahaszerotail set (value 160);
* <addr-flags> has ahashead and ahaszerotail set (value 160);
* <tail> is omitted.
* <tail>被省略。
The Address Block is then 3 160 1 a 2 b c d (8 octets).
然后地址块是311601A2BCD（8个八位字节）。
o To include a.b.0.0 and c.d.0.0:
o 包括a.b.0.0和c.d.0.0：
* head-length = 0;
* 头长=0；
* tail-length = 2;
* 尾长=2；
* mid-length = 2;
* 中长=2；
* <addr-flags> has ahaszerotail set (value 32);
* <addr-flags> has ahaszerotail set (value 32);
* <head> and <tail> are omitted.
* <head>和<tail>被省略。
The Address Block is then 2 32 2 a b c d (7 octets).
然后地址块是232CD（7个八位字节）。
o To include a.b.0.0/n and c.d.0.0/n:
o 包括a.b.0.0/n和c.d.0.0/n：
* head-length = 0;
* 头长=0；
* tail-length = 2;
* 尾长=2；
* mid-length = 2;
* 中长=2；
* <addr-flags> has ahaszerotail and ahassingleprelen set (value
48);
* <addr-flags> has ahaszerotail and ahassingleprelen set (value
48);
* <head> and <tail> are omitted.
* <head>和<tail>被省略。
The Address Block is then 2 48 2 a b c d n (8 octets).
然后地址块是2482abcdn（8个八位字节）。
o To include a.b.0.0/n and c.d.0.0/m:
o 包括a.b.0.0/n和c.d.0.0/m：
* head-length = 0;
* 头长=0；
* tail-length = 2;
* 尾长=2；
* mid-length = 2;
* 中长=2；
* <addr-flags> has ahaszerotail and ahasmultiprelen set (value
40);
* <addr-flags> has ahaszerotail and ahasmultiprelen set (value
40);
* <head> and <tail> are omitted.
* <head>和<tail>被省略。
The Address Block is then 2 40 2 a b c d n m (9 octets).
然后地址块是2402abcdnm9个八位组。
Assume the definition of an Address Block TLV with type EXAMPLE1 (and no type extension) that has single octet values per address. There are a number of ways in which values a, a, b, and c may be associated with the four addresses in the preceding Address Block, where c is a default value that can be omitted.
假设地址块TLV的定义为EXAMPLE1类型（没有类型扩展），每个地址有一个八位字节值。有许多方法可以将值a、a、b和c与前面地址块中的四个地址相关联，其中c是可以忽略的默认值。
Examples:
示例：
o Using one multivalue TLV to cover all of the addresses:
o 使用一个多值TLV覆盖所有地址：
* <tlv-flags> has thasvalue and tismultivalue set (value 20);
* <tlv-flags> has thasvalue and tismultivalue set (value 20);
* <index-start> and <index-stop> are omitted;
* <index-start> and <index-stop> are omitted;
* <length> = 4 (single-length = 1).
* <length>=4（单个长度=1）。
* The TLV is then EXAMPLE1 20 4 a a b c (7 octets).
* 然后举例说明TLV 1 20 4 a b c（7个八位组）。
o Using one multivalue TLV and omitting the last address:
o 使用一个多值TLV并省略最后一个地址：
* <tlv-flags> has thasmultiindex, thasvalue, and tismultivalue
set (value 52);
* <tlv-flags> has thasmultiindex, thasvalue, and tismultivalue
set (value 52);
* <index-start> = 0;
* <index-start> = 0;
* <index-stop> = 2;
* <index-stop> = 2;
* <length> = 3 (single-length = 1).
* <length>=3（单个长度=1）。
* The TLV is then EXAMPLE1 52 0 2 3 a a b (8 octets).
* TLV是示例1 52 0 2 3 a b（8个八位组）。
o Using two single value TLVs and omitting the last address. First:
o 使用两个单值TLV并省略最后一个地址。第一：
* <tlv-flags> has thasmultiindex and thasvalue set (value 48);
* <tlv-flags> has thasmultiindex and thasvalue set (value 48);
* <index-start> = 0;
* <index-start> = 0;
* <index-stop> = 1;
* <index-stop> = 1;
* <length> = 1;
* <length> = 1;
* <value> = a.
* <value>=a。
* The TLV is then EXAMPLE1 48 0 1 1 a (6 octets).
* TLV是示例14801A（6个八位组）。
Second:
第二：
* <tlv-flags> has thassingleindex and thasvalue set (value 80);
* <tlv-flags> has thassingleindex and thasvalue set (value 80);
* <index-start> = 2;
* <index-start> = 2;
* <index-stop> is omitted;
* <index-stop> is omitted;
* <length> = 1;
* <length> = 1;
* <value> = b.
* <value>=b。
* The TLV is then EXAMPLE1 80 2 1 b (5 octets).
* 例如，TLV为18021B（5个八位组）。
Total length of TLVs is 11 octets.
TLV的总长度为11个八位字节。
In this case, the first of these is the most efficient. In other cases, patterns such as the others may be preferred. Regardless of efficiency, any of these may be used.
在这种情况下，第一种是最有效的。在其它情况下，诸如其它的模式可能是优选的。无论效率如何，都可以使用其中任何一种。
Assume the definition of an Address Block TLV with type EXAMPLE2 (and no type extension) that has no value and that is to be associated with the second and third addresses in an Address Block. This can be indicated with a single TLV:
假设地址块TLV的定义为EXAMPLE2类型（没有类型扩展），该类型没有值，并且与地址块中的第二个和第三个地址关联。这可以用一个TLV来表示：
o <tlv-flags> has thasmultiindex set (value 32);
o <tlv-flags> has thasmultiindex set (value 32);
o <index-start> = 1;
o <index-start> = 1;
o <index-stop> = 2;
o <index-stop> = 2;
o <length> and <value> are omitted.
o <length>和<value>被省略。
o The TLV is then EXAMPLE2 32 1 2 (4 octets).
o TLV是示例2 32 1 2（4个八位组）。
Assume the definition of a Message TLV with type EXAMPLE3 (and no type extension) that can take a Value field of any length. For such a TLV with 8 octets of data (a to h):
假设消息TLV的定义为EXAMPLE3类型（没有类型扩展），可以采用任意长度的值字段。对于具有8个八位字节数据（a到h）的TLV：
o <tlv-flags> has thasvalue set (value 16);
o <tlv-flags> has thasvalue set (value 16);
o <index-start> and <index-stop> are omitted;
o <index-start> and <index-stop> are omitted;
o <length> = 8.
o <length>=8。
o The TLV is then EXAMPLE3 16 8 a b c d e f g h (11 octets).
o 然后以TLV为例3 16 8 a b c d e f g h（11个八位组）。
If, in this example, the number of data octets were 256 or greater, then <tlv-flags> would also have thasextlen set and have value 24. The length would require two octets (most significant first). The TLV length would be 4 + N octets, where N is the number of data octets (it can be 3 + N octets if N is 255 or less).
在本例中，如果数据八位字节数为256或更大，则<tlv flags>也将设置thasextlen，且值为24。长度需要两个八位字节（最重要的是第一个）。TLV长度为4+N个八位字节，其中N为数据八位字节数（如果N为255或更小，则可以为3+N个八位字节）。
This informative appendix illustrates the elements that are normatively specified in Section 5.
本资料性附录说明了第5节中规范性规定的要素。
Bits labeled Rsv should be cleared ('0'). Bits labeled M may be cleared ('0') or set ('1').
标记为Rsv的位应清除（“0”）。标记为M的位可以清除（'0'）或设置（'1'）。
This section illustrates possible options for the <packet> element. These are differentiated by the flags field in the first octet. The packet may include any number (zero or more) of messages. The number of messages is determined from when the packet is exhausted, given the packet length from the network layer.
本节说明了<packet>元素的可能选项。它们通过第一个八位字节中的标志字段进行区分。该分组可以包括任意数量（零或更多）的消息。根据网络层给定的数据包长度，从数据包耗尽时确定消息的数量。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0|0|Rsv| |
+-+-+-+-+-+-+-+-+ |
| Message |
| |
| +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0|0|Rsv| |
+-+-+-+-+-+-+-+-+ |
| Message |
| |
| +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|1|0|Rsv| Packet Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message |
| |
| +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|1|0|Rsv| Packet Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message |
| |
| +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0|1|Rsv| |
+-+-+-+-+-+-+-+-+ |
| |
| Packet TLV Block |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+ |
| Message |
| |
| +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0|1|Rsv| |
+-+-+-+-+-+-+-+-+ |
| |
| Packet TLV Block |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+ |
| Message |
| |
| +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|1|1|Rsv| Packet Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Packet TLV Block |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message |
| |
| +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|1|1|Rsv| Packet Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Packet TLV Block |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message |
| |
| +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This section illustrates possible options for the <message> element. These are differentiated by their second (flags) octet. The length of the Message Body is determined using the Message Size field, which is the combined length of all the fields shown. The field labeled MAL defines the length of all addresses (including the Originator Address, if present, and all addresses in Address Blocks) in octets, as one more than the value in the field.
本节说明了<message>元素的可能选项。它们通过第二个（标志）八位字节来区分。消息正文的长度使用消息大小字段确定，该字段是所示所有字段的组合长度。标记为MAL的字段将所有地址（包括发起者地址，如果存在，以及地址块中的所有地址）的长度定义为八位字节，比字段中的值多一个。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|0|0|0| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|0|0|0| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |1|0|0|0| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |1|0|0|0| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|1|0|0| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | |
+-+-+-+-+-+-+-+-+ |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|1|0|0| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | |
+-+-+-+-+-+-+-+-+ |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |1|1|0|0| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | |
+-+-+-+-+-+-+-+-+ |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |1|1|0|0| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | |
+-+-+-+-+-+-+-+-+ |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|0|1|0| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | |
+-+-+-+-+-+-+-+-+ |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|0|1|0| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | |
+-+-+-+-+-+-+-+-+ |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |1|0|1|0| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | |
+-+-+-+-+-+-+-+-+ |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |1|0|1|0| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | |
+-+-+-+-+-+-+-+-+ |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|1|1|0| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|1|1|0| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |1|1|1|0| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |1|1|1|0| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|0|0|1| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|0|0|1| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |1|0|0|1| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |1|0|0|1| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|1|0|1| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|1|0|1| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |1|1|0|1| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |1|1|0|1| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|0|1|1| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|0|1|1| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |1|0|1|1| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |1|0|1|1| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|1|1|1| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|1|1|1| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |1|1|1|1| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |1|1|1|1| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This section illustrates the format of a Message Body (the <message> element excluding its initial <msg-header> element). The Message Body includes one Message TLV Block (containing zero or more TLVs) and may include any number (zero or more) of Address Block and Address Block TLV Block pairs.
本节说明消息正文的格式（不包括其初始<msg header>元素的<Message>元素）。消息体包括一个消息TLV块（包含零个或多个TLV），并且可以包括任意数量（零个或多个）的地址块和地址块TLV块对。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message TLV Block |
| +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Address Block |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+ |
| Address Block TLV Block |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Address Block |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Address Block TLV Block |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message TLV Block |
| +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Address Block |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+ |
| Address Block TLV Block |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Address Block |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Address Block TLV Block |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This section illustrates possible options for the <addr-block> element. These are differentiated by their second (flags) octet. The number of Mid elements is equal to the number of addresses (except when mid-length is zero, when there are no Mid elements). Where a variable number of prefix length fields is shown, their number is equal to the number of addresses.
本节说明了<addr block>元素的可能选项。它们通过第二个（标志）八位字节来区分。中间元素的数量等于地址的数量（中间长度为零时除外，没有中间元素时除外）。如果显示的前缀长度字段数量可变，则其数量等于地址数量。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|0|0|0|0| Rsv | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|0|0|0|0| Rsv | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|0|0|0|0| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|0|0|0|0| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|1|0|0|0| Rsv | Tail Length | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail (cont) | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|1|0|0|0| Rsv | Tail Length | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail (cont) | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|1|0|0|0| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Tail Length | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|1|0|0|0| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Tail Length | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|0|1|0|0| Rsv | Tail Length | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | |
+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|0|1|0|0| Rsv | Tail Length | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | |
+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|0|1|0|0| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Tail Length | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ... :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|0|1|0|0| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Tail Length | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ... :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|0|0|1|0| Rsv | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|0|0|1|0| Rsv | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|0|0|1|0| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|0|0|1|0| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|1|0|1|0| Rsv | Tail Length | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail (cont) | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|1|0|1|0| Rsv | Tail Length | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail (cont) | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|1|0|1|0| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Tail Length | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|1|0|1|0| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Tail Length | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|0|1|1|0| Rsv | Tail Length | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | |
+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|0|1|1|0| Rsv | Tail Length | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | |
+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|0|1|1|0| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Tail Length | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ... :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|0|1|1|0| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Tail Length | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ... :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|0|0|0|1| Rsv | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | Prefix Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|0|0|0|1| Rsv | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | Prefix Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|0|0|0|1| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|0|0|0|1| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|1|0|0|1| Rsv | Tail Length | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail (cont) | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|1|0|0|1| Rsv | Tail Length | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail (cont) | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|1|0|0|1| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Tail Length | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | |
+-+-+-+-+-+-+-+-+ |
: ... :
| +-+-+-+-+-+-+-+-+
| | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|1|0|0|1| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Tail Length | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | |
+-+-+-+-+-+-+-+-+ |
: ... :
| +-+-+-+-+-+-+-+-+
| | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|0|1|0|1| Rsv | Tail Length | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | |
+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|0|1|0|1| Rsv | Tail Length | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | |
+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|0|1|0|1| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Tail Length | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ... :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | Prefix Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|0|1|0|1| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Tail Length | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ... :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | Prefix Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This section illustrates the format of a <tlv-block> element. There may be any number (zero or more) of TLVs, with total length of the TLVs (in octets) equal to the Length field.
本节说明<tlv block>元素的格式。TLV可以有任意数量（零或更多），TLV的总长度（以八位字节为单位）等于长度字段。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| TLV |
| +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| TLV |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| TLV |
| +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| TLV |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This section illustrates possible options for the <tlv> element. These are differentiated by their second (flags) octet. If there are no Index fields, then this may be a Packet TLV, Message TLV, or Address Block TLV; if there are one or two Index fields, then this must be an Address Block TLV. The Length field gives the length of the Value field (in octets).
本节说明了<tlv>元素的可能选项。它们通过第二个（标志）八位字节来区分。如果没有索引字段，则这可能是数据包TLV、消息TLV或地址块TLV；如果有一个或两个索引字段，则这必须是地址块TLV。长度字段给出值字段的长度（以八位字节为单位）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |0|0|0|0|0|0|Rsv|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |0|0|0|0|0|0|Rsv|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |1|0|0|0|0|0|Rsv| Type Ext |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |1|0|0|0|0|0|Rsv| Type Ext |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |0|1|0|0|0|0|Rsv| Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |0|1|0|0|0|0|Rsv| Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |1|1|0|0|0|0|Rsv| Type Ext | Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |1|1|0|0|0|0|Rsv| Type Ext | Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |0|0|1|0|0|0|Rsv| Index Start | Index Stop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |0|0|1|0|0|0|Rsv| Index Start | Index Stop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |1|0|1|0|0|0|Rsv| Type Ext | Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index Stop |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |1|0|1|0|0|0|Rsv| Type Ext | Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index Stop |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |0|0|0|1|0|M|Rsv| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |0|0|0|1|0|M|Rsv| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |1|0|0|1|0|M|Rsv| Type Ext | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |1|0|0|1|0|M|Rsv| Type Ext | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |0|1|0|1|0|0|Rsv| Index Start | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |0|1|0|1|0|0|Rsv| Index Start | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |1|1|0|1|0|0|Rsv| Type Ext | Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | |
+-+-+-+-+-+-+-+-+ |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |1|1|0|1|0|0|Rsv| Type Ext | Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | |
+-+-+-+-+-+-+-+-+ |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |0|0|1|1|0|M|Rsv| Index Start | Index Stop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | |
+-+-+-+-+-+-+-+-+ |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |0|0|1|1|0|M|Rsv| Index Start | Index Stop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | |
+-+-+-+-+-+-+-+-+ |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |1|0|1|1|0|M|Rsv| Type Ext | Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index Stop | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |1|0|1|1|0|M|Rsv| Type Ext | Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index Stop | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |0|0|0|0|1|M|Rsv| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |0|0|0|0|1|M|Rsv| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |1|0|0|1|1|M|Rsv| Type Ext | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (cont) | |
+-+-+-+-+-+-+-+-+ |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |1|0|0|1|1|M|Rsv| Type Ext | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (cont) | |
+-+-+-+-+-+-+-+-+ |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |0|1|0|1|1|0|Rsv| Index Start | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (cont) | |
+-+-+-+-+-+-+-+-+ |
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |0|1|0|1|1|0|Rsv| Index Start | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (cont) | |
+-+-+-+-+-+-+-+-+ |
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |1|1|0|1|1|0|Rsv| Type Ext | Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |1|1|0|1|1|0|Rsv| Type Ext | Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |0|0|1|1|1|M|Rsv| Index Start | Index Stop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |0|0|1|1|1|M|Rsv| Index Start | Index Stop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |1|0|1|1|1|M|Rsv| Type Ext | Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index Stop | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |1|0|1|1|1|M|Rsv| Type Ext | Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index Stop | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
The following example packet is included with the intent to exemplify how Packet Headers and Message Headers are constructed, and how addresses and attributes are encoded using Address Blocks and TLV Blocks. This example is specifically not constructed to exhibit maximum message or packet size reduction.
包含以下示例数据包旨在举例说明如何构造数据包头和消息头，以及如何使用地址块和TLV块对地址和属性进行编码。该示例的构造并不是为了显示最大消息或数据包大小的减少。
The Packet Header has the phasseqnum flag of its flags field set (value 8), and hence has a Packet Sequence Number, but no Packet TLV Block.
数据包报头的标志字段设置为phasseqnum标志（值8），因此具有数据包序列号，但没有数据包TLV块。
The packet contains a single message with length 54 octets. This message has the mhasorig, mhashoplimit, mhashopcount, and mhasseqnum flags of its four-bit flags field set (value 15), and hence includes an Originator Address, a Hop Limit, a Hop Count, and a Message Sequence Number (which is type independent). Its four-bit Message Address Length field has value 3, and hence addresses in the message have length four octets, here being IPv4 addresses. The message has a Message TLV Block with content length 9 octets, containing a single
该数据包包含一条长度为54个八位字节的消息。此消息具有其四位标志字段集（值15）的mhasorig、mhashoplimit、mhashopcount和mhasseqnum标志，因此包括发起者地址、跃点限制、跃点计数和消息序列号（与类型无关）。它的四位消息地址长度字段的值为3，因此消息中的地址长度为四个八位字节，这里是IPv4地址。该消息有一个内容长度为9个八位字节的消息TLV块，其中包含一个
Message TLV. This TLV has the thasvalue flag of its flags octet set (value 16), and hence contains a Value field, with preceding Value Length 6 octets. The message then has two Address Blocks, each with a following Address Block TLV Block.
信息TLV。此TLV具有其标志八位字节集（值16）的thasvalue标志，因此包含一个值字段，前面的值长度为6个八位字节。然后，该消息有两个地址块，每个地址块后面有一个地址块TLV块。
The first Address Block contains 2 address prefixes. It has the ahaszerotail and ahassingleprelen flags of its flags octet set (value 48), and hence has no Head (head-length is zero octets). It has a tail-length of 2 octets, hence mid-length is two octets. The two Tail octets of each address are not included (since ahaszerotail is set) and have value zero. The Address Block has a single prefix length. The following Address Block TLV Block is empty (content length 0 octets).
第一个地址块包含2个地址前缀。它具有其标志八位字节集（值48）的ahaszerotail和ahassingleprelen标志，因此没有头部（头部长度为零八位字节）。它的尾部长度为2个八位字节，因此中间长度为2个八位字节。每个地址的两个尾部八位字节不包括在内（因为设置了ahaszerotail），并且值为零。地址块只有一个前缀长度。以下地址块TLV块为空（内容长度为0个八位字节）。
The second Address Block contains 3 addresses. It has the ahashead flag of its flags octet set (value 128), has head-length 2 octets, and no Tail (tail-length is zero octets); hence, mid-length is two octets. It is followed by an Address Block TLV Block, with content length 9 octets, containing two Address Block TLVs. The first of these TLVs has the thasvalue flag of its flags octet set (value 16), and has a single value of length 2 octets, which applies to all of the addresses in the Address Block. The second of these TLVs has the thasmultiindex flag of its flags octet set (value 32), and hence has no Value Length or Value fields. It has two Index fields (Index Start and Index Stop), which indicate those addresses this TLV applies to (inclusive range, counting from zero).
第二个地址块包含3个地址。它有其标志八位字节集的ahashead标志（值128），头长为2个八位字节，无尾（尾长为0个八位字节）；因此，中间长度为两个八位字节。它后面是一个地址块TLV块，内容长度为9个八位字节，包含两个地址块TLV。这些TLV中的第一个具有其标志八位字节集的thasvalue标志（值16），并且具有长度为2个八位字节的单个值，该值适用于地址块中的所有地址。第二个TLV具有其标志八位字节集的thasmultiindex标志（值32），因此没有值长度或值字段。它有两个索引字段（索引开始和索引停止），指示该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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0 0| Packet Sequence Number | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 0 0 1 1|0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 0| Orig Addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address (cont) | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | Message Sequence Number |0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0 1| TLV Type |0 0 0 1 0 0 0 0|0 0 0 0 0 1 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (cont) |0 0 0 0 0 0 1 0|0 0 1 1 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 0| Mid | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | Prefix Length |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 1|1 0 0 0 0 0 0 0|0 0 0 0 0 0 1 0| Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Mid | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | Mid |0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0 1| TLV Type |0 0 0 1 0 0 0 0|0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | TLV Type |0 0 1 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index Start | Index Stop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0 0| Packet Sequence Number | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 0 0 1 1|0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 0| Orig Addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address (cont) | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | Message Sequence Number |0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0 1| TLV Type |0 0 0 1 0 0 0 0|0 0 0 0 0 1 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (cont) |0 0 0 0 0 0 1 0|0 0 1 1 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 0| Mid | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | Prefix Length |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 1|1 0 0 0 0 0 0 0|0 0 0 0 0 0 1 0| Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Mid | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | Mid |0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0 1| TLV Type |0 0 0 1 0 0 0 0|0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | TLV Type |0 0 1 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index Start | Index Stop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Authors' Addresses
作者地址
Thomas Heide Clausen LIX, Ecole Polytechnique
托马斯·海德·克劳森·利克斯，理工学院
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/
Christopher M. Dearlove BAE Systems ATC
克里斯托弗M.迪尔洛夫BAE系统ATC
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/
Justin W. Dean Naval Research Laboratory
贾斯汀·W·迪安海军研究实验室
Phone: +1 202 767 3397
EMail: jdean@itd.nrl.navy.mil
URI: http://pf.itd.nrl.navy.mil/
Phone: +1 202 767 3397
EMail: jdean@itd.nrl.navy.mil
URI: http://pf.itd.nrl.navy.mil/
Cedric Adjih INRIA Rocquencourt
塞德里克·阿吉因里亚·罗库库尔特
Phone: +33 1 3963 5215
EMail: Cedric.Adjih@inria.fr
URI: http://menetou.inria.fr/~adjih/
Phone: +33 1 3963 5215
EMail: Cedric.Adjih@inria.fr
URI: http://menetou.inria.fr/~adjih/