draft-ietf-manet-packetbb-12.txt   draft-ietf-manet-packetbb-13.txt 
Mobile Ad hoc Networking (MANET) T. Clausen Mobile Ad hoc Networking (MANET) T. Clausen
Internet-Draft LIX, Ecole Polytechnique, France Internet-Draft LIX, Ecole Polytechnique, France
Intended status: Standards Track C. Dearlove Intended status: Standards Track C. Dearlove
Expires: September 8, 2008 BAE Systems Advanced Technology Expires: December 26, 2008 BAE Systems Advanced Technology
Centre Centre
J. Dean J. Dean
Naval Research Laboratory Naval Research Laboratory
C. Adjih C. Adjih
INRIA Rocquencourt INRIA Rocquencourt
March 7, 2008 June 24, 2008
Generalized MANET Packet/Message Format Generalized MANET Packet/Message Format
draft-ietf-manet-packetbb-12 draft-ietf-manet-packetbb-13
Status of This Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 40 skipping to change at page 1, line 40
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 8, 2008. This Internet-Draft will expire on December 26, 2008.
Abstract Abstract
This document specifies a packet format capable of carrying multiple This document specifies a packet format capable of carrying multiple
messages that may be used by mobile ad hoc network routing and messages that may be used by mobile ad hoc network routing protocols.
signaling protocols.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 5 2. Notation and Terminology . . . . . . . . . . . . . . . . . . . 4
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 7 2.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 8 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
5. Syntactical Specification . . . . . . . . . . . . . . . . . . 9 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5
5.1. Packets . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 7
5.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Syntactical Specification . . . . . . . . . . . . . . . . . . 7
5.3. Address Blocks . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Packets . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.4. TLVs and TLV Blocks . . . . . . . . . . . . . . . . . . . 16 5.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.4.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.3. Address Blocks . . . . . . . . . . . . . . . . . . . . . . 10
5.4.2. TLV Inclusion and Constraints . . . . . . . . . . . . 19 5.4. TLVs and TLV Blocks . . . . . . . . . . . . . . . . . . . 13
5.5. Malformed Elements . . . . . . . . . . . . . . . . . . . . 20 5.4.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 5.4.2. TLV Inclusion and Constraints . . . . . . . . . . . . 17
6.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 21 5.5. Malformed Elements . . . . . . . . . . . . . . . . . . . . 18
6.2. Packet TLV Types . . . . . . . . . . . . . . . . . . . . . 21 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6.3. Message TLV Types . . . . . . . . . . . . . . . . . . . . 22 6.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 18
6.4. Address Block TLV Types . . . . . . . . . . . . . . . . . 22 6.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 6.2.1. Message Type Specific TLV Registry Creation . . . . . 21
7.1. Authentication Suggestions . . . . . . . . . . . . . . . . 24 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 . . . . . . . . . 24
7.2. Confidentiality Suggestions . . . . . . . . . . . . . . . 24
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. Normative References . . . . . . . . . . . . . . . . . . . 25 8.1. Normative References . . . . . . . . . . . . . . . . . . . 25
8.2. Informative References . . . . . . . . . . . . . . . . . . 25 8.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Intended Usage . . . . . . . . . . . . . . . . . . . 26 Appendix A. Intended Usage . . . . . . . . . . . . . . . . . . . 26
Appendix B. Compatibility Requirements for Future Versions . . . 27 Appendix B. Multiplexing and Demultiplexing . . . . . . . . . . . 27
Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 28 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 28
C.1. Address Block Examples . . . . . . . . . . . . . . . . . . 28 C.1. Address Block Examples . . . . . . . . . . . . . . . . . . 28
C.2. TLV Examples . . . . . . . . . . . . . . . . . . . . . . . 30 C.2. TLV Examples . . . . . . . . . . . . . . . . . . . . . . . 30
Appendix D. Illustrations . . . . . . . . . . . . . . . . . . . . 33 Appendix D. Illustrations . . . . . . . . . . . . . . . . . . . . 32
D.1. Packet . . . . . . . . . . . . . . . . . . . . . . . . . . 33 D.1. Packet . . . . . . . . . . . . . . . . . . . . . . . . . . 33
D.2. Message . . . . . . . . . . . . . . . . . . . . . . . . . 40 D.2. Message . . . . . . . . . . . . . . . . . . . . . . . . . 36
D.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 46 D.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 42
D.4. Address Block . . . . . . . . . . . . . . . . . . . . . . 47 D.4. Address Block . . . . . . . . . . . . . . . . . . . . . . 43
D.5. TLV Block . . . . . . . . . . . . . . . . . . . . . . . . 54 D.5. TLV Block . . . . . . . . . . . . . . . . . . . . . . . . 50
D.6. TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 D.6. TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Appendix E. Complete Example . . . . . . . . . . . . . . . . . . 60 Appendix E. Complete Example . . . . . . . . . . . . . . . . . . 56
Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 62 Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 57
Appendix G. Acknowledgements . . . . . . . . . . . . . . . . . . 63 Appendix G. Acknowledgments . . . . . . . . . . . . . . . . . . . 58
1. Introduction 1. Introduction
This document specifies the syntax of a general purpose packet format This document specifies the syntax of a packet format designed to
capable of carrying multiple messages for information exchange carrying multiple messages for information exchange between MANET
between MANET (Mobile Ad hoc NETwork) routers. Messages consist of a (Mobile Ad hoc NETwork) routers. Messages consist of a message
message header, which is designed for control of message header, which is designed for control of message dissemination, and a
dissemination, and a message body, which contains protocol message body, which contains protocol information. Only the syntax
information. Only the syntax of the packet and messages is of the packet and messages is specified. All syntactical entities,
specified. All syntactical entities, including packets and messages, including packets and messages, are specified using a regular
are specified using regular expressions. expression derived notation.
This document specifies: This document specifies:
o A packet format, allowing zero or more messages to be contained o A packet format, allowing zero or more messages to be contained
within a single transmission, and optionally including a packet within a single transmission. A packet with zero messages may be
header. A packet with zero messages may be sent in case the only sent in case the only information to exchange is contained in the
information to exchange is contained in the packet header. packet header.
o A message format, where a message is composed of a message header o A message format, where a message is composed of a message header
and a message body. and a message body.
o A message header format, which contains information which may be o A message header format, which contains information which may be
sufficient to allow a protocol using this specification to make sufficient to allow a protocol using this specification to make
processing and forwarding decisions. processing and forwarding decisions.
o A message body format, containing attributes associated with the o A message body format, containing attributes associated with the
message or the originator of the message, as well as blocks of message or the originator of the message, as well as blocks of
addresses, or address prefixes, with associated attributes. addresses, or address prefixes, with associated attributes.
o An address block format, where an address block represents sets of o An address block format, where an address block represents sets of
addresses, or address prefixes, in a compact (compressed) form. addresses, or address prefixes, in a compact form with aggregated
addresses.
o A generalized type-length-value (TLV) format representing o A generalized type-length-value (TLV) format representing
attributes. Multiple TLVs can be included and each associated attributes. Each TLV can be associated with a packet, a message,
with a packet, a message, or one or more addresses or address or one or more addresses or address prefixes in a single address
prefixes. block. Multiple TLVs can be included and each associated with a
packet, a message, and with the same, different or overlapping
sets of addresses or address prefixes.
The specification has been explicitly designed with the following The specification has been explicitly designed with the following
properties, listed in no particular order, in mind: properties, listed in no particular order, in mind:
Parsing logic - the regular expression specification facilitates Parsing logic - the regular expression derived notation used in this
generic, protocol independent, parsing logic. specification facilitates generic, protocol independent, parsing
logic.
Extensibility - packets and messages defined by a protocol using Extensibility - packets and messages defined by a protocol using
this specification are extensible through defining new message this specification are extensible by defining new message types
types and new TLVs. Existing protocol specifications using this and new TLVs. Protocols using this specification will be able to
specification will be able to correctly identify and skip such new correctly identify and skip such new message types and TLVs, while
message types and TLVs, while correctly parsing the remainder of correctly parsing the remainder of the packet and message.
the packet and message.
Efficiency - when reported addresses share common bit sequences Efficiency - when reported addresses share common bit sequences
(e.g. address prefixes or IPv6 interface identifiers) the address (e.g. address prefixes or IPv6 interface identifiers) the address
block representation allows for a compact representation. Compact block representation allows for a compact representation. Compact
message headers are ensured through permitting inclusion of only message headers are ensured through permitting inclusion of only
required message header elements, unless indicated otherwise. The required message header elements. The structure of packet and
structure of packet and message encoding allows parsing, message encoding allows parsing, verifying, and identifying
verifying, and identifying individual elements in a single pass. individual elements in a single pass.
Separation of forwarding and processing - a protocol using this Separation of forwarding and processing - a protocol using this
specification can be designed such that duplicate detection and specification can be designed such that duplicate detection and
controlled scope message forwarding decisions can be made using controlled scope message forwarding decisions can be made using
information contained in the message header, without processing information contained in the message header, without processing
the message body. the message body.
2. Terminology and Notation 2. Notation and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119. [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
Additionally, this document uses the following terminology: Additionally, this document uses the notation in Section 2.1, and the
terminology in Section 2.2.
2.1. Notation
This specification uses a derivative of the regular expression
language from [SingleUNIX], [POSIX] or [ECMAScript], using only the
following notation:
Element - A group of any number of consecutive bits which, together,
forms a syntactic entity, represented using the notation <foo>.
<foo> - If <foo> is an unsigned integer field then <foo> is also
used to represent the value of that field.
bar - A variable, usually obtained through calculations based on the
value(s) of element(s). Variables are introduced into the
specification solely as a means to clarify the description.
:= - Indicates that the element or variable on the left hand side is
defined as the expression on the right hand side.
(<element1><element2>) - Indicates a grouping of the elements
enclosed by the parentheses.
? - Zero or one occurrences of the preceding element or group.
* - Zero or more occurrences of the preceding element or group.
address-length - A variable whose value is the length of an address
in octets, it is 4 if using IPv4, or 16 if using IPv6.
2.2. Terminology
This document uses the following terminology:
Packet - The top level entity in this specification. A packet Packet - The top level entity in this specification. A packet
contains zero or more messages, and may contain a packet header. contains a packet header and zero or more messages.
Message - The fundamental entity carrying protocol information, in Message - The fundamental entity carrying protocol information, in
the form of address objects and TLVs. the form of address objects and TLVs.
Address - A number of octets of the same length as the source IP Address - A number of octets of the same length as the source IP
address in the IP datagram carrying the packet. The meaning of an address in the IP datagram carrying the packet. The meaning of an
address is defined by the protocol using this specification. address is defined by the protocol using this specification.
Address Prefix - An address plus a prefix length, with the prefix Address Prefix - An address plus a prefix length, with the prefix
length being a number of address bits measured from the left/most length being a number of address bits measured from the left/most
significant end of the address. significant end of the address.
Address Object - Either an address, or an address prefix, as Address Object - Either an address, or an address prefix, as
specified in an address block in this specification. specified in an address block in this specification.
TLV - A Type-Length-Value structure. This is a generic way in which TLV - A Type-Length-Value structure. This is a generic way in which
an attribute can be represented and correctly parsed, without the an attribute can be represented and correctly parsed, without the
parser having to understand the attribute. parser having to understand the attribute.
Element - A syntactic entity defined in the regular expression 3. Applicability Statement
specification, represented using the notation <foo>.
<foo> - If <foo> is an 8 or 16 bit unsigned integer field then <foo>
is also used to represent the value of that field.
bar - A variable, usually obtained through calculations based on the
value(s) of element(s). Variables are introduced into the
specification solely as a means to clarify the description.
:= - Indicates that the element or variable on the left hand side is
defined as the expression on the right hand side.
{<element1><element2>} - Indicates a grouping of the elements
enclosed by the braces.
? - Zero or one occurrences of the preceding element or group. 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 OLSR (The Optimized Link State
Routing protocol) [RFC3626].
* - Zero or more occurrences of the preceding element or group. 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.
address-length - A variable whose value is the length of an address Efficiency is supported by reducing packet size and by allowing
in octets, it is 4 if using IPv4, 16 if using IPv6. multiple disjoint messages in a single packet. Reduced packet size
is primarily supported by address aggregation, optional packet 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.
3. Applicability Statement 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 (see Section 6.1), and new message types.
Protocols can also reuse message and TLV type definitions from other
protocols which also use this specification.
This specification describes a generic packet format capable of This specification aims at being sufficiently expressive and flexible
carrying multiple messages, for carrying MANET routing protocol to be able to accommodate both different classes of MANET routing
signals. The specification has been inspired by and extended from protocols (e.g. proactive, reactive and hybrid routing protocols), as
that used by OLSR (The Optimized Link State Routing protocol) well as extensions thereto. Having a common packet and message
[RFC3626]. 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.
The specification is designed with IP (IPv4/IPv6) in mind. All All addresses within a message are assumed to be of the same size,
addresses within a control message are assumed to be of the same deduced from the IP header. In the case of mixed IPv6 and IPv4
size, deduced from IP. In the case of mixed IPv6 and IPv4 addresses, addresses, IPv4 addresses can be represented as IPv4-mapped IPv6
IPv4 addresses can be represented as IPv4-mapped IPv6 addresses as addresses as specified in [RFC4291]. Packets may be unicast or
specified in [RFC4291]. multicast, and may use any appropriate transport protocol, or none.
The messages defined by this specification are designed to carry The messages defined by this specification are designed to carry
MANET routing protocol signals between MANET routers. This MANET routing protocol signaling between MANET routers. This
specification includes elements which can support limited diffusion specification includes elements which can support limited diffusion
(flooding), as well as being usable for point to point delivery of (flooding), as well as being usable for point to point delivery of
MANET routing protocol signals in a multi-hop network. MANET routing protocol signaling in a multi-hop network.
The packets defined by this specification are designed to carry a
number of MANET routing protocol messages in a single transmission.
The packets may be unicast or multicast, and may be transmitted as
appropriate to the MANET routing protocol using this specification.
This specification is particularly appropriate for extensible MANET
routing protocols. It offers external extensibility in the form of
new message types. It offers internal extensibility in the form of
TLVs, which may be added to existing message types.
A MANET routing protocol using the multi-message packet format A MANET routing protocol using the packet format defined by this
defined by this specification MAY constrain the syntax (for example specification can constrain the syntax (for example requiring a
requiring a specific set of message header fields) that the protocol specific set of message header fields) that the protocol will employ.
will employ. Protocols with such restrictions need not be able to parse all
possible packet structures as defined by this document but must be
coherent in packet generation and reception of packets of which they
define. If a protocol specifies which elements are included, then
direct indexing of the appropriate fields is possible, dependant on
the syntax restrictions imposed by the protocol. Such protocols may
have more limited extensibility.
4. Protocol Overview and Functioning 4. Protocol Overview and Functioning
This specification does not describe a protocol. It describes a This specification does not describe a protocol. It describes a
packet format, which may be used by any mobile ad hoc network routing packet format, which may be used by any mobile ad hoc network routing
or other protocol. protocol.
5. Syntactical Specification 5. Syntactical Specification
This section provides syntactical specification of a packet, This section provides syntactical specification of a packet,
represented by the element <packet> and the elements from which it is represented by the element <packet> and the elements from which it is
composed. The specification is given in the form of regular composed. The specification is given using the notation in
expressions. Illustrations of specified elements are given in Section 2.1. Illustrations of specified elements are given in
Appendix D. Appendix D.
This format uses network byte order (most significant octet first) This format uses network byte order (most significant octet first)
for all fields. 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].
5.1. Packets 5.1. Packets
<packet> is defined by: <packet> is defined by:
<packet> := <pkt-header>? <packet> := <pkt-header>
<message>* <message>*
where <message> is as defined in Section 5.2. Successful parsing is where <message> is as defined in Section 5.2. Successful parsing is
terminated when all octets (defined using the variable pkt-size terminated when all octets of the packet (as defined by the datagram
below) are used. A packet MUST NOT be empty, that is a packet MUST containing the packet) are used.
contain either a <pkt-header> or at least one <message>.
<pkt-header> is defined by: <pkt-header> is defined by:
<pkt-header> := <zero> <pkt-header> := <version>
<pkt-semantics> <pkt-flags>
<pkt-version>?
<pkt-size>?
<pkt-seq-num>? <pkt-seq-num>?
<tlv-block>? <tlv-block>?
where: where:
<zero> is an 8 bit field with all bits cleared ('0'). This field <version> is a 4 bit unsigned integer field and specifies the
serves to identify that the packet starts with a <pkt-header>. version of the specification on which the packet and the contained
messages are constructed. This document specifies version 0.
<pkt-semantics> is an 8 bit field, specifying the composition of the
<pkt-header>:
bit 0 (phasversion): If cleared ('0'), then <pkt-version> is not
included in the <pkt-header>. If set ('1'), then <pkt-version>
is included in the <pkt-header>.
bit 1 (phassize): If cleared ('0'), then <pkt-size> is not <pkt-flags> is a 4 bit field, specifying the interpretation of the
included in the <pkt-header>. If set ('1'), then <pkt-size> is remainder of the packet header:
included in the <pkt-header>.
bit 2 (phasseqnum): If cleared ('0'), then <pkt-seq-num> is not bit 0 (phasseqnum): If cleared ('0'), then <pkt-seq-num> is not
included in the <pkt-header>. If set ('1'), then <pkt-seq-num> included in the <pkt-header>. If set ('1'), then <pkt-seq-num>
is included in the <pkt-header>. is included in the <pkt-header>.
bit 3 (phastlv): If cleared ('0'), then <tlv-block> is not bit 1 (phastlv): If cleared ('0'), then <tlv-block> is not
included in the <pkt-header>. If set ('1'), then <tlv-block> included in the <pkt-header>. If set ('1'), then <tlv-block>
is included in the <pkt-header>. is included in the <pkt-header>.
bit 4 (pnouniord): If cleared ('0'), then the packet TLV block bit 2 (pnouniord): If cleared ('0'), then the packet TLV block
MUST conform to the constraints in Section 5.4.2. If set MUST conform to the constraints in Section 5.4.2. If set
('1'), then the packet TLV block is not subject to the ('1'), then the packet TLV block is not subject to the
constraints in Section 5.4.2. Additional constraints MAY be constraints in Section 5.4.2. Additional constraints MAY be
imposed by a protocol using this specification. imposed by a protocol using this specification.
bits 5-7: Are RESERVED, and SHOULD each be cleared ('0') on bit 3: Is RESERVED, and SHOULD be cleared ('0') on transmission,
transmission, and SHOULD be ignored on reception. and SHOULD be ignored on reception.
<pkt-version> is omitted if the phasversion bit is cleared ('0'),
otherwise is an 8 bit unsigned integer field, specifying the
version of this specification.
<pkt-size> is omitted if the phassize bit is cleared ('0'),
otherwise is a 16 bit unsigned integer field, specifying the
number of octets that make up the <packet>.
<pkt-seq-num> is omitted if the phasseqnum bit is cleared ('0'), <pkt-seq-num> is omitted if the phasseqnum pkt-flag is cleared
otherwise is a 16 bit unsigned field, specifying a packet sequence ('0'), otherwise is a 16 bit unsigned integer field, specifying a
number. packet sequence number.
<tlv-block> is omitted if the phastlv bit is cleared ('0'), and is <tlv-block> is omitted if the phastlv flag is cleared ('0'), and is
otherwise as defined in Section 5.4. otherwise as defined in Section 5.4.
Note that since message type zero is not used (see Section 6), the
presence or absence of a packet header can be determined by
inspecting the first octet of the packet.
pkt-version is a variable, defined to equal <pkt-version> if
present, or zero (0) otherwise. pkt-version MUST be zero to be in
accordance with this version of this specification. See
Appendix B.
pkt-size is a variable, defined to equal <pkt-size> if present, or
the size of the payload of the network or transport protocol
employed otherwise. (If not present, and the payload size is
unknown, then the packet cannot be parsed, and is considered
malformed.)
5.2. Messages 5.2. Messages
Information is carried through messages. Messages contain: Packets may, in addition to the packet header, contain one or more
messages. Messages contain:
o A message header. o A message header.
o A message TLV block that contains zero or more TLVs, associated o A message TLV block that contains zero or more TLVs, associated
with the whole message. with the whole message.
o Zero or more address blocks, each containing one or more address o Zero or more address blocks, each containing one or more address
objects. objects.
o An address TLV block, containing zero or more TLVs, following each o An address TLV block, containing zero or more TLVs, following each
address block. address block, through which addresses can be associated with
additional attributes.
<message> is defined by: <message> is defined by:
<message> := <msg-header> <message> := <msg-header>
<tlv-block> <tlv-block>
{<addr-block><tlv-block>}* (<addr-block><tlv-block>)*
<msg-header> := <msg-type> <msg-header> := <msg-type>
<msg-semantics> <msg-flags>
<msg-version>?
<msg-size> <msg-size>
<msg-orig-addr>? <msg-orig-addr>?
<msg-hop-limit>? <msg-hop-limit>?
<msg-hop-count>? <msg-hop-count>?
<msg-seq-num>? <msg-seq-num>?
where: where:
<tlv-block> is as defined in Section 5.4. <tlv-block> is as defined in Section 5.4.
<addr-block> is as defined in Section 5.3. <addr-block> is as defined in Section 5.3.
<msg-type> is an 8 bit unsigned integer field, specifying the type <msg-type> is an 8 bit unsigned integer field, specifying the type
of the message. A type with all bits cleared ('0') MUST NOT be of the message.
used.
<msg-semantics> is an 8 bit field, specifying the interpretation of
the remainder of the message header:
bit 0 (mhasversion): If cleared ('0'), then <msg-version> is not <msg-flags> is an 8 bit field, specifying the interpretation of the
included in the <msg-header>. If set ('1'), then <msg-version> remainder of the message header:
is included in the <msg-header>.
bit 1 (mhasorig): If cleared ('0'), then <msg-orig-addr> is not bit 0 (mhasorig): If cleared ('0'), then <msg-orig-addr> is not
included in the <msg-header>. If set ('1'), then <msg-orig- included in the <msg-header>. If set ('1'), then <msg-orig-
addr> is included in the <msg-header>. addr> is included in the <msg-header>.
bit 2 (mhashoplimit): If cleared ('0'), then <msg-hop-limit> is bit 1 (mhashoplimit): If cleared ('0'), then <msg-hop-limit> is
not included in the <msg-header>. If set ('1'), then <msg-hop- not included in the <msg-header>. If set ('1'), then <msg-hop-
limit> is included in the <msg-header>. limit> is included in the <msg-header>.
bit 3 (mhashopcount): If cleared ('0'), then <msg-hop-count> is bit 2 (mhashopcount): If cleared ('0'), then <msg-hop-count> is
not included in the <msg-header>. If set ('1'), then <msg-hop- not included in the <msg-header>. If set ('1'), then <msg-hop-
count> is included in the <msg-header> count> is included in the <msg-header>.
bit 4 (mhasseqnum): If cleared ('0'), then <msg-seq-num> is not bit 3 (mhasseqnum): If cleared ('0'), then <msg-seq-num> is not
included in the <msg-header>. If set ('1'), then <msg-seq-num> included in the <msg-header>. If set ('1'), then <msg-seq-num>
is included in the <msg-header>. is included in the <msg-header>.
bit 5 (mistypedep): If cleared ('0'), then the message sequence bit 4 (mistypedep): If cleared ('0'), then the message sequence
number in the message is type-independent. If set ('1'), then number in the message is type-independent. If set ('1'), then
the message sequence number contained in the message is type the message sequence number contained in the message is type
dependent (the message originator maintains a sequence number dependent (the message originator maintains a sequence number
specific to <msg-type>). This bit MUST be cleared ('0') if the specific to <msg-type>). This msg-flag MUST be cleared ('0')
mhasorig bit is cleared ('0'). if the mhasorig msg-flag is cleared ('0').
bit 6 (mnouniord): If cleared ('0'), then the message TLV block bit 5 (mnouniord): If cleared ('0'), then the message TLV block
and all address TLV blocks in the message MUST conform to the and all address TLV blocks in the message MUST conform to the
constraints in Section 5.4.2. If set ('1'), then the message constraints in Section 5.4.2. If set ('1'), then the message
TLV block and all address TLV blocks in the message are not TLV block and all address TLV blocks in the message are not
subject to the constraints in Section 5.4.2. Additional subject to the constraints in Section 5.4.2. Additional
constraints MAY be imposed by a protocol using this constraints MAY be imposed by a protocol using this
specification. specification.
bit 7: Is RESERVED, and SHOULD be cleared ('0') on transmission, bit 6-7: Are RESERVED, and SHOULD each be cleared ('0') on
and SHOULD be ignored on reception. transmission, and SHOULD be ignored on reception.
<msg-version> is omitted if the mhasversion bit is cleared ('0'),
otherwise is an 8 bit unsigned integer field, specifying the
version of this specification.
<msg-size> is a 16 bit unsigned integer field, specifying the number <msg-size> is a 16 bit unsigned integer field, specifying the number
of octets that make up the <message> of octets that make up the <message>, including the <msg-header>.
<msg-orig-addr> is omitted if the mhasorig bit is cleared ('0'),
otherwise is an identifier with length equal to address-length,
which can serve to uniquely identify the node that originated the
message.
<msg-hop-limit> is omitted if the mhashoplimit bit is cleared ('0'), <msg-orig-addr> is omitted if the mhasorig msg-flag is cleared
otherwise is an 8 bit unsigned integer field, which can contain ('0'), otherwise is an identifier with length equal to address-
the maximum number of hops that the message should be further length, which can serve to uniquely identify the node that
transmitted. originated the message.
<msg-hop-count> is omitted if the mhashopcount bit is cleared ('0'), <msg-hop-limit> is omitted if the mhashoplimit msg-flag is cleared
otherwise is an 8 bit unsigned integer field, which can contain ('0'), otherwise is an 8 bit unsigned integer field, which can
the number of hops that the message has traveled. contain the maximum number of hops that the message should be
further transmitted.
<msg-seq-num> is omitted if the mhasseqnum bit is cleared ('0'), <msg-hop-count> is omitted if the mhashopcount msg-flag is cleared
otherwise is a 16 bit unsigned integer field, which can contain a ('0'), otherwise is an 8 bit unsigned integer field, which can
sequence number, generated by the message's originator node. contain the number of hops that the message has traveled.
msg-version is a variable, defined to equal <msg-version> if <msg-seq-num> is omitted if the mhasseqnum msg-flag is cleared
present, or to pkt-version otherwise. msg-version MUST be 0 (zero) ('0'), otherwise is a 16 bit unsigned integer field, which can
to be in accordance with this version of this specification. See contain a sequence number, generated by the message's originator
Appendix B. node.
5.3. Address Blocks 5.3. Address Blocks
An address block can specify one or more addresses. It can also An address block can specify one or more addresses. It can also
specify prefix lengths that can be applied to all addresses in the specify prefix lengths that can be applied to all addresses in the
address block. This allows an address block to specify either address block. This allows an address block to specify either
addresses or address prefixes. A protocol may specify that an addresses or address prefixes. A protocol may specify that an
address with a maximum prefix length (equal to the address length, in address with a maximum prefix length (equal to the address length, in
bits) is considered to be an address, rather than a address prefix, bits) is considered to be an address, rather than an address prefix,
thus allowing an address block to contain a mixture of addresses and thus allowing an address block to contain a mixture of addresses and
address prefixes. The common term "address object" is used in this address prefixes. The common term "address object" is used in this
specification to cover both of these; note that an address object in specification to cover both of these; note that an address object in
an address block always includes the prefix length, if present. an address block always includes the prefix length, if present.
An address is specified as a sequence of address-length octets of the An address is specified as a sequence of address-length octets of the
form head:mid:tail. An address block contains an ordered set of form head:mid:tail. There are no semantics associated with head, mid
addresses sharing the same head and tail, and having individual mids. 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
which do not have common heads or common tails. Detailed examples of
address blocks are included in Appendix C.1.
An address block can specify address prefixes: An address block can specify address prefixes:
o with a single prefix length for all address prefixes, OR o with a single prefix length for all address prefixes; OR
o with a prefix length for each address prefix. o with a prefix length for each address prefix.
<address-block> is defined by: <address-block> is defined by:
<address-block> := <num-addr> <address-block> := <num-addr>
<addr-semantics> <addr-flags>
{<head-length><head>?}? (<head-length><head>?)?
{<tail-length><tail>?}? (<tail-length><tail>?)?
<mid>* <mid>*
<prefix-length>* <prefix-length>*
where: where:
<num-addr> is an 8 bit unsigned integer field containing the number <num-addr> is an 8 bit unsigned integer field containing the number
of addresses represented in the address block, which MUST NOT be of addresses represented in the address block, which MUST NOT be
zero. zero.
<addr-semantics> is an 8 bit field specifying the interpretation of <addr-flags> is an 8 bit field specifying the interpretation of the
the remainder of the address block: remainder of the address block:
bit 0 (ahashead): If cleared ('0'), then <head-length> and <head> bit 0 (ahashead): If cleared ('0'), then <head-length> and <head>
are not included in the <address-block>. If set ('1'), then are not included in the <address-block>. If set ('1'), then
<head-length> is included in the <address-block>, and <head> is <head-length> is included in the <address-block>, and <head> is
included in the <address-block> unless <head-length> is zero. included in the <address-block> unless <head-length> is zero.
bit 1 (ahasfulltail) and bit 2 (ahaszerotail): Are interpreted bit 1 (ahasfulltail) and bit 2 (ahaszerotail): Are interpreted
according to Table 1. A combination not shown in that table according to Table 1. A combination not shown in that table
MUST NOT be used. MUST NOT be used.
skipping to change at page 14, line 35 skipping to change at page 12, line 12
interpreted according to Table 2. A combination not shown in interpreted according to Table 2. A combination not shown in
that table MUST NOT be used. that table MUST NOT be used.
bits 5-7: Are RESERVED, and SHOULD each be cleared ('0') on bits 5-7: Are RESERVED, and SHOULD each be cleared ('0') on
transmission, and SHOULD be ignored on reception. transmission, and SHOULD be ignored on reception.
+--------------+--------------+---------------+---------------------+ +--------------+--------------+---------------+---------------------+
| ahasfulltail | ahaszerotail | <tail-length> | <tail> | | ahasfulltail | ahaszerotail | <tail-length> | <tail> |
+--------------+--------------+---------------+---------------------+ +--------------+--------------+---------------+---------------------+
| 0 | 0 | not included | not included | | 0 | 0 | not included | not included |
| | | | |
| 1 | 0 | included | included unless | | 1 | 0 | included | included unless |
| | | | <tail-length> is | | | | | <tail-length> is |
| | | | zero | | | | | zero |
| | | | |
| 0 | 1 | included | not included | | 0 | 1 | included | not included |
+--------------+--------------+---------------+---------------------+ +--------------+--------------+---------------+---------------------+
Table 1: Interpretation of the ahasfulltail and ahaszerotail bits Table 1: Interpretation of the ahasfulltail and ahaszerotail addr-
flags
+------------+-----------+------------------+-----------------------+ +------------+-----------+------------------+-----------------------+
| ahassingle | ahasmulti | number of | prefix length of the | | ahassingle | ahasmulti | number of | prefix length of the |
| prelen | prelen | <prefix-length> | nth address prefix, | | prelen | prelen | <prefix-length> | nth address prefix, |
| | | fields | in bits | | | | fields | in bits |
+------------+-----------+------------------+-----------------------+ +------------+-----------+------------------+-----------------------+
| 0 | 0 | 0 | 8 * address-length | | 0 | 0 | 0 | 8 * address-length |
| | | | |
| 1 | 0 | 1 | <prefix-length> | | 1 | 0 | 1 | <prefix-length> |
| | | | |
| 0 | 1 | <num-addr> | nth <prefix-length> | | 0 | 1 | <num-addr> | nth <prefix-length> |
+------------+-----------+------------------+-----------------------+ +------------+-----------+------------------+-----------------------+
Table 2: Interpretation of the ahassingleprelen and ahasmultiprelen Table 2: Interpretation of the ahassingleprelen and ahasmultiprelen
bits addr-flags
<head-length> if present is an 8 bit unsigned integer field, which <head-length> if present is an 8 bit unsigned integer field, which
contains the number of octets in the head of all of the addresses. contains the number of octets in the head of all of the addresses
in the address block.
head-length is a variable, defined to equal <head-length> if head-length is a variable, defined to equal <head-length> if
present, or 0 otherwise. present, or 0 otherwise.
<head> is omitted if head-length is equal to 0, otherwise it is a <head> is omitted if head-length is equal to 0, otherwise it is a
field of the head-length leftmost octets of all the addresses. field of the head-length leftmost octets common to all the
addresses in the address block.
<tail-length> if present is an 8 bit unsigned integer field, which <tail-length> if present is an 8 bit unsigned integer field, which
contains the number of octets in the tail of all of the addresses. contains the number of octets in the tail of all of the addresses
in the address block.
tail-length is a variable, defined to equal <tail-length> if tail-length is a variable, defined to equal <tail-length> if
present, or 0 otherwise. present, or 0 otherwise.
<tail> is omitted if tail-length is equal to 0 or if the <tail> is omitted if tail-length is equal to 0, or if the
ahaszerotail bit is set ('1'), otherwise it is a field of the ahaszerotail bit is set ('1'), otherwise it is a field of the
tail-length rightmost octets of all the addresses. If the tail-length rightmost octets common to all the addresses in the
ahaszerotail bit is set ('1') then the tail-length rightmost address block. If the ahaszerotail bit is set ('1') then the
octets of all the addresses are all 0. tail-length rightmost octets of all the addresses in the address
block are all 0.
mid-length is a variable, which MUST be non-negative, defined by: mid-length is a variable, which MUST be non-negative, defined by:
* mid-length := address-length - head-length - tail-length * mid-length := address-length - head-length - tail-length
<mid> is omitted if mid-length is equal to 0, otherwise each <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 is a field of length mid-length octets, representing the mid of
the corresponding address in the address block. the corresponding address in the address block. When not omitted,
an address block contains exactly <num-addr> <mid> fields.
<prefix-length> is an 8 bit unsigned integer field containing the <prefix-length> is an 8 bit unsigned integer field containing the
length, in bits, of the prefix length of an address prefix. If length, in bits, of an address prefix. If the ahassingleprelen
the ahassingleprelen bit is set ('1') then a single <prefix- addr-flag is set ('1') then a single <prefix-length> field is
length> field contains the prefix length of all addresses in the included, which contains the prefix length of all addresses in the
address block. If the ahasmultiprelen bit is set ('1') then each address block. If the ahasmultiprelen addr-flag is set ('1') then
of the <num-addr> <prefix-length> fields contains the prefix <num-addr> <prefix-length> fields are included, each of which
length of the corresponding address prefix in the address block contains the prefix length of the corresponding address prefix in
(in the same order). Otherwise no <prefix-length> fields are the address block (in the same order). Otherwise no <prefix-
present; each address object can be considered to have a prefix length> fields are present; each address object can be considered
length equal to 8 * address-length bits. The address block is to have a prefix length equal to 8 * address-length bits. The
malformed if any <prefix-length> element has a value greater than address block is malformed if any <prefix-length> element has a
8 * address-length. value greater than 8 * address-length.
5.4. TLVs and TLV Blocks 5.4. TLVs and TLV Blocks
A TLV allows 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 which are unknown when parsing can be
skipped.
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.
A TLV block is defined by: A TLV block is defined by:
<tlv-block> := <tlvs-length> <tlv-block> := <tlvs-length>
<tlv>* <tlv>*
where: where:
<tlvs-length> is a 16 bit unsigned integer field, which contains the <tlvs-length> is a 16 bit unsigned integer field, which contains the
total number of octets in all of the immediately following <tlv> total number of octets in all of the immediately following <tlv>
elements. elements (<tlvs-length> not included).
<tlv> is as defined in Section 5.4.1. <tlv> is as defined in Section 5.4.1.
5.4.1. TLVs 5.4.1. TLVs
There are three kinds of TLV, each represented by an element <tlv>: There are three kinds of TLV, each represented by an element <tlv>:
o A packet TLV, included in the packet TLV block in a packet header. o A packet TLV, included in the packet TLV block in a packet header.
o A message TLV, included in the message TLV block in a message, o A message TLV, included in the message TLV block in a message,
before the first address block. before any address blocks.
o An address block TLV, included in an address TLV block following o An address block TLV, included in an address TLV block following
an address block. An address block TLV applies to: an address block. An address block TLV applies to:
* all address objects in the address block; OR * all address objects in the address block; OR
* any continuous sequence of address objects in the address * any continuous sequence of address objects in the address
block; OR block; OR
* a single address object in the address block. * a single address object in the address block.
<tlv> is defined by: <tlv> is defined by:
<tlv> := <tlv-type> <tlv> := <tlv-type>
<tlv-semantics> <tlv-flags>
<tlv-type-ext>? <tlv-type-ext>?
{<index-start><index-stop>?}? (<index-start><index-stop>?)?
{<length><value>?}? (<length><value>?)?
where: where:
<tlv-type> is an 8 bit unsigned integer field, specifying the type <tlv-type> is an 8 bit unsigned integer field, specifying the type
of the TLV, specific to the TLV kind (i.e. packet, message, or of the TLV, specific to the TLV kind (i.e. packet, message, or
address block TLV). address block TLV).
<tlv-semantics> is an 8 bit field specifying the interpretation of <tlv-flags> is an 8 bit field specifying the interpretation of the
the remainder of the TLV: remainder of the TLV:
bit 0 (thastypeext): If cleared ('0'), then <tlv-type-ext> is not 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>. If set ('1'), then <tlv-type-ext> is
included in the <tlv>. included in the <tlv>.
bit 1 (thassingleindex) and bit 2 (thasmultiindex): Are bit 1 (thassingleindex) and bit 2 (thasmultiindex): Are
interpreted according to Table 3. A combination not shown in interpreted according to Table 3. A combination not shown in
that table MUST NOT be used. Both bits MUST be cleared ('0') that table MUST NOT be used. Both of these tlv-flags MUST be
in packet and message TLVs. cleared ('0') in packet and message TLVs.
bit 3 (thasvalue) and bit 4 (thasextlen): Are interpreted bit 3 (thasvalue) and bit 4 (thasextlen): Are interpreted
according to Table 4. A combination not shown in that table according to Table 4. A combination not shown in that table
MUST NOT be used. MUST NOT be used.
bit 5 (tismultivalue): This bit serves to specify how the <value> bit 5 (tismultivalue): This tlv-flag serves to specify how the
field is interpreted, as specified below. This bit MUST be <value> field is interpreted, as specified below. This tlv-
cleared ('0') in packet and message TLVs, if the thasmultiindex flag MUST be cleared ('0') in packet and message TLVs, if the
bit is cleared ('0'), or if the thasvalue bit is cleared ('0'). thasmultiindex tlv-flag is cleared ('0'), or if the thasvalue
tlv-flag is cleared ('0').
bits 6-7: Are RESERVED, and SHOULD each be cleared ('0') on bits 6-7: Are RESERVED, and SHOULD each be cleared ('0') on
transmission, and SHOULD be ignored on reception. transmission, and SHOULD be ignored on reception.
+-----------------+----------------+---------------+--------------+ +-----------------+----------------+---------------+--------------+
| thassingleindex | thasmultiindex | <index-start> | <index-stop> | | thassingleindex | thasmultiindex | <index-start> | <index-stop> |
+-----------------+----------------+---------------+--------------+ +-----------------+----------------+---------------+--------------+
| 0 | 0 | not included | not included | | 0 | 0 | not included | not included |
| | | | |
| 1 | 0 | included | not included | | 1 | 0 | included | not included |
| | | | |
| 0 | 1 | included | included | | 0 | 1 | included | included |
+-----------------+----------------+---------------+--------------+ +-----------------+----------------+---------------+--------------+
Table 3: Interpretation of the thassingleindex and thasmultiindex Table 3: Interpretation of the thassingleindex and thasmultiindex
bits tlv-flags
+-----------+------------+-------------+----------------------------+
+-----------+------------+--------------+---------------------------+
| thasvalue | thasextlen | <length> | <value> | | thasvalue | thasextlen | <length> | <value> |
+-----------+------------+-------------+----------------------------+ +-----------+------------+--------------+---------------------------+
| 0 | 0 | not | not included | | 0 | 0 | not included | not included |
| | | included | |
| | | | |
| 1 | 0 | 8 bits | included unless <length> | | 1 | 0 | 8 bits | included unless <length> |
| | | | is zero | | | | | is zero |
| | | | |
| 1 | 1 | 16 bits | included unless <length> | | 1 | 1 | 16 bits | included unless <length> |
| | | | is zero | | | | | is zero |
+-----------+------------+-------------+----------------------------+ +-----------+------------+--------------+---------------------------+
Table 4: Interpretation of the thasvalue and thasextlen bits
Table 4: Interpretation of the thasvalue and thasextlen tlv-flags
<tlv-type-ext> is an 8 bit unsigned integer field, specifying an <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. extension of the TLV type, specific to the TLV type and kind (i.e.
packet, message, or address block TLV). packet, message, or address block TLV).
tlv-type-ext is a variable, defined to equal <tlv-type-ext> if tlv-type-ext is a variable, defined to equal <tlv-type-ext> if
present, or 0 otherwise. present, or 0 otherwise.
tlv-fulltype is a variable, defined by: tlv-fulltype is a variable, defined by:
* 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 <index-start> and <index-stop> when present, in an address block TLV
only, are each an 8 bit unsigned integer field. only, are each an 8 bit unsigned integer field.
index-start and index-stop are variables, defined according to index-start and index-stop are variables, defined according to
Table 5. The variable end-index is defined as follows: Table 5. The variable end-index is defined as follows:
* For message and packet TLVs: * For message and packet TLVs:
+ end-index := 0 + end-index := 0
skipping to change at page 19, line 9 skipping to change at page 16, line 37
+ end-index := <num-addr> - 1 + end-index := <num-addr> - 1
An address block TLV applies to the address objects from position An address block TLV applies to the address objects from position
index-start to position index-stop (inclusive) in the address index-start to position index-stop (inclusive) in the address
block, where the first address object has position zero. block, where the first address object has position zero.
+-----------------+----------------+----------------+---------------+ +-----------------+----------------+----------------+---------------+
| thassingleindex | thasmultiindex | index-start := | index-stop := | | thassingleindex | thasmultiindex | index-start := | index-stop := |
+-----------------+----------------+----------------+---------------+ +-----------------+----------------+----------------+---------------+
| 0 | 0 | 0 | end-index | | 0 | 0 | 0 | end-index |
| | | | |
| 1 | 0 | <index-start> | <index-start> | | 1 | 0 | <index-start> | <index-start> |
| | | | |
| 0 | 1 | <index-start> | <index-stop> | | 0 | 1 | <index-start> | <index-stop> |
+-----------------+----------------+----------------+---------------+ +-----------------+----------------+----------------+---------------+
Table 5: Interpretation of the thassingleindex and thasmultiindex Table 5: Interpretation of the thassingleindex and thasmultiindex
bits tlv-flags
number-values is a variable, defined by: 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 or 16 bit unsigned integer field <length> is omitted or is an 8 or 16 bit unsigned integer field
according to Table 4. If the tismultivalue bit is set ('1') then according to Table 4. If the tismultivalue tlv-flag is set ('1')
<length> MUST be an integral multiple of number-values, and the then <length> MUST be an integral multiple of number-values, and
variable single-length is defined by: the variable single-length is defined by:
* single-length := <length> / number-values * single-length := <length> / number-values
If the tismultivalue bit is cleared ('0'), then the variable If the tismultivalue tlv-flag is cleared ('0'), then the variable
single-length is defined by: single-length is defined by:
* single-length := <length> * single-length := <length>
<value> if present (see Table 4) is a field of 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 octets. In an address block TLV, <value> is associated with the
address objects from positions index-start to index-stop, address objects from positions index-start to index-stop,
inclusive. If the tismultivalue bit is cleared ('0') then the inclusive. If the tismultivalue tlv-flag is cleared ('0') then
whole of this field is associated with each of the indicated the whole of this field is associated with each of the indicated
address objects. If the tismultivalue bit is set ('1') then this address objects. If the tismultivalue tlv-flag is set ('1') then
field is divided equally into number-values fields, each of length this field is divided equally into number-values fields, each of
single-length octets and these are associated, in order, with the length single-length octets, and these are associated, in order,
indicated address objects. with the indicated address objects.
5.4.2. TLV Inclusion and Constraints 5.4.2. TLV Inclusion and Constraints
A TLV associates an attribute with a packet, a message or one or more A TLV associates an attribute with a packet, a message or one or more
consecutive address objects in an address block. The interpretation consecutive address objects in an address block. The interpretation
and processing of this attribute, and the relationship (including and processing of this attribute, and the relationship (including
order of processing) between different attributes associated with the order of processing) between different attributes associated with the
same entity MUST be defined by a protocol which uses this same entity MUST be defined by a protocol which uses this
specification. specification.
If the appropriate semantics bit (pnouniord for a packet TLV block, If the appropriate flags (pnouniord for a packet TLV block, mnouniord
mnouniord for a message TLV block or an address TLV block) is clear for a message TLV block or an address block TLV block) are cleared
('0'), then the following constraints MUST be respected. These bits ('0'), then the following constraints MUST be respected. These flags
MUST always be clear ('0') unless a protocol using this specification MUST always be cleared ('0') unless a protocol using this
defines otherwise. Protocols SHOULD only define use of these bits specification defines otherwise. Protocols SHOULD only define use of
when necessary, and then MUST indicate what constraints do apply if these flags when necessary, and then MUST indicate what constraints
each of the indicated bits is set ('1'); each of these constraints do apply if each of the indicated flags is set ('1'); each of these
SHOULD be retained unless otherwise necessary. constraints SHOULD be retained unless otherwise necessary.
o TLVs in the same TLV block are sorted in non-descending tlv- o TLVs in the same TLV block are sorted in non-descending tlv-
fulltype order. fulltype order.
o Two or more address TLVs with the same tlv-fulltype in the same o Two or more address TLVs with the same tlv-fulltype in the same
message are not associated with the same value of address object. message are not associated with the same value of address object.
o TLVs with the same tlv-fulltype associated with the same address o TLVs with the same tlv-fulltype associated with the same address
block are sorted in ascending index-start order. block are sorted in ascending index-start order.
skipping to change at page 20, line 43 skipping to change at page 18, line 25
TLV block in a single pass and allows terminating the search for a TLV block in a single pass and allows terminating the search for a
TLV with a specific type without traversing the entire TLV block. TLV with a specific type without traversing the entire TLV block.
The constraints on address block TLVs ensure that encoded information The constraints on address block TLVs ensure that encoded information
(entity-attributes) can be unambiguously decoded. (entity-attributes) can be unambiguously decoded.
5.5. Malformed Elements 5.5. Malformed Elements
An element is malformed if it cannot be parsed according to its An element is malformed if it cannot be parsed according to its
syntactical specification (including if there are insufficient octets syntactical specification (including if there are insufficient octets
available when a length is specified, in particular if there are available) or if a constraint (including, but not only, those
fewer than pkt-size octets overall) or if a constraint (including, specified in Section 5.4.2) specified as one which MUST be satisfied,
but not only, those specified in Section 5.4.2) specified as one is not. A protocol using this specification MUST specify the action,
which MUST be satisfied, is not. A protocol using this specification or choice of actions, to be taken when a packet containing such
MUST specify the action, or choice of actions, to be taken when a elements is received. Typical examples will include discarding any
packet containing such elements is received. Typical examples will affected message(s), or discarding the complete packet.
include discarding any affected message(s), or discarding the
complete packet.
6. IANA Considerations 6. IANA Considerations
6.1. Message Types This document introduces four namespaces that require registration:
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.
The following terms are used with the meanings defined in [BCP26]:
"Namespace", "Assigned Value", "Registration", "Unassigned",
"Reserved", "Hierarchical Allocation", "Designated Expert".
The following policies are used with the meanings defined in [BCP26]:
"Private Use", "Expert Review", "Standards Action".
6.1. Expert Review: Evaluation Guidelines
For registration requests where an Expert Review is required, the
Designated Expert SHOULD take the following general recommendations
into consideration:
o The purposes of these registries are to support Standard and
Experimental MANET routing and related protocols, and extensions
to the same.
o The intention is that all registrations will be accompanied by a
published 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 The Designated Expert will post a request to the MANET WG mailing
list, or to a successor hereto as designated by the Area Director,
for comments and reviews. This request will include a reference
to the Internet-Draft requesting the registration.
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 informing 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.
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 which 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.
For the registries for Packet TLV Types, Message TLV Types and
Address Block TLV Types, the following guidelines apply:
o These are Hierarchical Allocations, allocation of a type creates a
registry for the extended types corresponding to that type. The
document which 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 be Expert Review, but with the possible allocation of
some type extensions as Reserved, Experimental and/or Private.
o TLV type values 0-7 MUST NOT be registered except when a
documented need exists that TLVs of a given type are required to
appear before all other TLVs in the TLV block as encoded for
transmission. Note that the need for a TLV to be processed before
other TLVs does not however automatically translate into a need
for the TLV to appear before all other TLVs in the TLV block (the
order in which TLVs are to be processed MUST be defined, if
applicable, in the protocols using this specification).
o The request for a TLV type MUST include the specification of the
permitted size, syntax of any internal structure of, and meaning
of, the value field (if any) of the TLV.
For the registries for Message TLV Types and Address Block TLV Types,
the following additional guidelines apply:
o TLV type values 0-127 are common for all message types. TLVs
which receive registrations from the 0-127 interval SHOULD be
modular in design to allow reuse among protocols.
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
require 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 which 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.
6.2. Message Types
A new registry for message types must be created, with initial A new registry for message types must be created, with initial
assignments as specified in Table 6. assignments and allocation policies as specified in Table 6.
+---------+---------------------------------+ +---------+-------------+-------------------+
| Type | Description | | Type | Description | Allocation Policy |
+---------+---------------------------------+ +---------+-------------+-------------------+
| 0 | MUST NOT be allocated. | | 0-223 | Unassigned | Expert Review |
| | | | 224-255 | Unassigned | Experimental Use |
| 128-255 | Reserved for private/local use. | +---------+-------------+-------------------+
+---------+---------------------------------+
Table 6: Message Types Table 6: Message Types
Future values in the range 1-127 can be allocated using standards 6.2.1. Message Type Specific TLV Registry Creation
action [RFC2434]. Message type 0 MUST NOT be allocated because a
zero octet signifies a packet header.
6.2. Packet TLV Types 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 which
creates a message type specific TLV registry MUST also specify the
mechanism by which message specific TLV types are allocated, from
among those in [BCP26].
6.3. Packet TLV Types
A new registry for packet TLV types must be created, with initial A new registry for packet TLV types must be created, with initial
assignments as specified in Table 7. assignments and allocation policies as specified in Table 7.
+---------+---------------------------------+ +---------+-------------+-------------------+
| Type | Description | | Type | Description | Allocation Policy |
+---------+---------------------------------+ +---------+-------------+-------------------+
| 128-255 | Reserved for private/local use. | | 0-223 | Unassigned | Expert Review |
+---------+---------------------------------+ | 224-255 | Unassigned | Experimental Use |
+---------+-------------+-------------------+
Table 7: Packet TLV Types Table 7: Packet TLV Types
Future values in the range 0-127 can be allocated using standards 6.3.1. Packet TLV Type Extension Registry Creation
action [RFC2434], respecting the following guidelines:
values 0-7 - MUST NOT be assigned except when a documented need
exists that TLVs of a given type are required to appear before all
other TLVs in the TLV block as encoded for transmission. Note
that the need for a TLV to be processed before other TLVs does not
however automatically translate into a need for the TLV to appear
before all other TLVs in the TLV block - the order in which TLVs
are to be processed MUST be defined, if applicable, in the
protocols using this specification.
values 8-127 - no constraints.
If a packet TLV type is allocated then a new registry for type When a packet TLV type is registered then a new registry for type
extensions of that type must be created. A document which defines a extensions of that type must be created. A document which defines a
packet TLV type MUST also specify the mechanism by which its type packet TLV type MUST also specify the mechanism by which its type
extensions are allocated, from among those in [RFC2434]. extensions are allocated, from among those in [BCP26].
6.3. Message TLV Types 6.4. Message TLV Types
A new registry for message TLV types must be created, with initial A new registry for message type independent message TLV types must be
assignments as specified in Table 8. created, with initial assignments and allocation policies as
specified in Table 8.
+---------+---------------------------------+ +---------+-----------------------+-----------------------+
| Type | Description | | Type | Description | Allocation Policy |
+---------+---------------------------------+ +---------+-----------------------+-----------------------+
| 128-255 | Reserved for private/local use. | | 0-127 | Unassigned | Expert Review |
+---------+---------------------------------+ | 128-223 | Message Type Specific | Reserved, see Table 9 |
| 224-255 | Unassigned | Experimental Use |
+---------+-----------------------+-----------------------+
Table 8: Message TLV Types Table 8: Message TLV Types
Future values in the range 0-127 can be allocated using standards Message TLV Types 128-223 are reserved for message type specific
action [RFC2434], respecting the following guidelines: 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.
values 0-7 - MUST NOT be assigned except when a documented need +---------+-----------------------------+-------------------+
exists that TLVs of a given type are required to appear before all | Type | Description | Allocation Policy |
other TLVs in the TLV block as encoded for transmission. Note +---------+-----------------------------+-------------------+
that the need for a TLV to be processed before other TLVs does not | 0-127 | Common to all Message Types | Reserved |
however automatically translate into a need for the TLV to appear | 128-223 | Message Type Specific | See Below |
before all other TLVs in the TLV block - the order in which TLVs | 224-255 | Common to all Message Types | Reserved |
are to be processed MUST be defined, if applicable, in the +---------+-----------------------------+-------------------+
protocols using this specification.
values 8-127 - no constraints. Table 9: Message Specific Message TLV Types
If a message TLV type is allocated then a new registry for type 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.
6.4.1. Message TLV Type Extension Registry Creation
If a message TLV type is registered then a new registry for type
extensions of that type must be created. A document which defines a extensions of that type must be created. A document which defines a
message TLV type MUST also specify the mechanism by which its type message TLV type MUST also specify the mechanism by which its type
extensions are allocated, from among those in [RFC2434]. extensions are allocated, from among those in [BCP26].
6.4. Address Block TLV Types 6.5. Address Block TLV Types
A new registry for address block TLV types must be created, with A new registry for message type independent address block TLV types
initial assignments as specified in Table 9. must be created, with initial assignments and allocation policies as
specified in Table 10.
+---------+---------------------------------+ +---------+-----------------------+------------------------+
| Type | Description | | Type | Description | Allocation Policy |
+---------+---------------------------------+ +---------+-----------------------+------------------------+
| 128-255 | Reserved for private/local use. | | 0-127 | Unassigned | Expert Review |
+---------+---------------------------------+ | 128-223 | Message Type Specific | Reserved, see Table 11 |
| 224-255 | Unassigned | Experimental Use |
+---------+-----------------------+------------------------+
Table 9: Address Block TLV Types Table 10: Address Block TLV Types
Future values in the range 0-127 can be allocated using standards Address Block TLV Types 128-223 are reserved for message type
action [RFC2434], respecting the following guidelines: 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.
values 0-7 - MUST NOT be assigned except when a documented need +---------+-----------------------------+-------------------+
exists that TLVs of a given type are required to appear before all | Type | Description | Allocation Policy |
other TLVs in the TLV block as encoded for transmission. Note +---------+-----------------------------+-------------------+
that the need for a TLV to be processed before other TLVs does not | 0-127 | Common to all Message Types | Reserved |
however automatically translate into a need for the TLV appearing | 128-223 | Message Type Specific | See Below |
before all other TLVs in the TLV block - the order in which TLVs | 224-255 | Common to all Message Types | Reserved |
are to be processed MUST be defined, if applicable, in the +---------+-----------------------------+-------------------+
protocols using this specification.
values 8-127 - no constraints. Table 11: Message Specific Address Block TLV Types
If an address block TLV type is allocated then a new registry for 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.
6.5.1. Address Block TLV Type Extension Registry Creation
When an address block TLV type is registered then a new registry for
type extensions of that type must be created. A document which type extensions of that type must be created. A document which
defines an address block TLV type MUST also specify the mechanism by defines a message TLV type MUST also specify the mechanism by which
which its type extensions are allocated, from among those in its type extensions are allocated, from among those in [BCP26].
[RFC2434].
7. Security Considerations 7. Security Considerations
This specification does not describe a protocol; it describes a This specification does not describe a protocol; it describes a
packet format. As such it does not specify any security packet format. As such it does not specify any security
considerations, these are matters for a protocol using this considerations, these are matters for a protocol using this
specification. However two mechanisms which are enabled by this specification. However some security mechanisms are enabled by this
specification, and may form part of a security approach in a protocol specification, and may form part of a protocol using this
using this specification, are described in Section 8.1. There is specification. Mechanisms which may form part of an authentication
however no requirement that a protocol using this specification and integrity approach in a protocol using this specification, are
should use either. described in Section 7.1. Mechanisms which 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. Authentication Suggestions 7.1. Authentication and Integrity Suggestions
The authentication suggestions made here, are based on the intended The authentication and integrity suggestions made here, are based on
usage in Appendix A, specifically that: the intended usage in Appendix A, specifically that:
o Messages are designed to be carriers of protocol information and o Messages are designed to be carriers of protocol information and
MAY, at each hop, be forwarded and/or processed by the protocol MAY, at each hop, be forwarded and/or processed by the protocol
using this specification. using this specification.
o Packets are designed to carry a number of messages between o Packets are designed to carry a number of messages between
neighboring nodes in a single transmission and over a single neighboring nodes in a single transmission and over a single
logical hop. logical hop.
Consequently: Consequently:
o For forwarded messages where the message is unchanged by o For forwarded messages where the message is unchanged by
forwarding nodes, then end-to-end security MAY be implemented, forwarding nodes, then end-to-end authentication and integrity MAY
between nodes with an existing security association, by including be implemented, between nodes with an existing security
a suitable message TLV containing a cryptographic signature in the association, by including a suitable message TLV containing a
message. Since <hop-count> and <hop-limit> are the only fields cryptographic signature in the message. Since <hop-count> and
that should be modified when such a message is forwarded in this <hop-limit> are the only fields that should be modified when such
manner, this signature can be calculated based on the entire a message is forwarded in this manner, this signature can be
message, including the message header, with the <hop-count> and calculated based on the entire message, including the message
<hop-limit> fields set to 0 if present. header, with the <hop-count> and <hop-limit> fields set to 0 if
present.
o Hop-by-hop packet level security MAY be implemented, between nodes o Hop-by-hop packet level authentication and integrity MAY be
with an existing security association, by including a suitable implemented, between nodes with an existing security association,
packet TLV containing a cryptographic signature to the packet. by including a suitable packet TLV containing a cryptographic
Since packets are received as transmitted, this signature can be signature to the packet. Since packets are received as
calculated based on the entire packet, or on parts thereof as transmitted, this signature can be calculated based on the entire
appropriate. packet, or on parts thereof as appropriate.
7.2. Confidentiality Suggestions
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.
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.
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 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
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.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997. Requirement Levels", RFC 2119, BCP 14, March 1997.
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", RFC 5226,
BCP 26, May 2008.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [SingleUNIX] IEEE Std 1003.1, The Open Group, and ISO/IEC JTC
IANA Considerations Section in RFCs", RFC 2434, BCP 26, 1/SC22/WG15, "Single UNIX Specification, Version 3,
October 1998. 2004 Edition", April 2004.
[POSIX] ISO/IEC Standard 9945-1:2003, "Portable Operating
System Interface (POSIX) - Part 1: Base Definitions",
January 2003.
[ECMAScript] ISO/IEC Standard 9845-1:2003, "Ecma-262, ECMAScript
Language Specification", January 2003.
8.2. Informative References 8.2. Informative References
[RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State
Routing Protocol", RFC 3626, October 2003. Routing Protocol", RFC 3626, October 2003.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[Stevens] Stevens, W., "TCP/IP Illustrated Volume 1 - The
Protocols.", 1994.
Appendix A. Intended Usage Appendix A. Intended Usage
The packet and message format specified in this document is designed The packet and message format specified in this document is designed
to carry MANET routing protocol messages and signals between MANET to carry MANET routing protocol signaling between MANET routers, and
routers, and to support scope limited diffusion (flooding) as well as to support scope limited diffusion (flooding) as well as point-to-
point-to-point delivery. point delivery.
Specifically: Specifically:
o Packets are transmitted over a single logical hop and are not o Packets are transmitted over a single logical hop and are not
forwarded. Messages are designed to be able to be forwarded over forwarded. Messages are designed to be able to be forwarded over
one or more logical hops, in a new packet for each logical hop. one or more logical hops, in a new packet for each logical hop.
Each logical hop may consist of one or more IP hops. Packets may Each logical hop may consist of one or more IP hops. Packets may
contain a different combination of messages for each logical hop. contain a different combination of messages for each logical hop.
Packets may be formed from messages from more than one MANET Packets may be formed from messages from more than one MANET
routing protocol; the use of a single message type space for all routing protocol; the use of a single message type space for all
such protocols allows these messages to be separated by protocol. such protocols allows these messages to be separated by protocol.
o Scope limited flooding is supported for messages thus: o Scope limited flooding is supported for messages thus:
* If the mhasorig and mhasseqnum and bits in the <msg-semantics> * If the mhasorig and mhasseqnum msg-flags are both set ('1')
field are both set ('1') then the message header provides for then the message header provides for duplicate suppression,
duplicate suppression, using the identifier consisting of the using the identifier consisting of the message's <msg-orig-
message's <msg-orig-addr>, <msg-seq-num>, and, if the addr>, <msg-seq-num>, and, if the mistypedep flag in the <msg-
mistypedep bit in the <msg-semantics> field is set ('1), <msg- flags> field is set ('1'), <msg-type>. These serve to uniquely
type>. These serve to uniquely identify the message in the identify the message in the network within the time period
network within the time period until <msg-seq-num> is repeated, until <msg-seq-num> is repeated, i.e. wraps around to a
i.e. wraps around to a matching value if used sequentially. matching value if used sequentially.
* If the mhashoplimit bit in the <msg-semantics> field is set * If the mhashoplimit msg-flag is set ('1'), then the message
('1'), then the message header provides the information to make header provides the information to make forwarding decisions
forwarding decisions for scope limited diffusion (flooding). for scope limited diffusion (flooding). This may be by any
This may be by any appropriate flooding mechanism specified by appropriate flooding mechanism specified by a protocol using
a protocol using this specification. this specification.
* <msg-hop-limit> SHOULD, if present, be decremented, usually by * <msg-hop-limit> SHOULD, if present, be decremented, usually by
one, if the message is forwarded. one, if the message is forwarded.
* <msg-hop-count> SHOULD, if present, be incremented, usually by * <msg-hop-count> SHOULD, if present, be incremented, usually by
one, if the message is forwarded. one, if the message is forwarded.
Appendix B. Compatibility Requirements for Future Versions Appendix B. Multiplexing and Demultiplexing
This specification defines packets and messages with version zero The packet and message format specified in this document is designed
(0). to allow zero or more messages to be contained within a single packet
(e.g. a single IP datagram or UDP datagram). Such messages may be
from the same or may be from different protocols. In the latter
case, multiplexing of outgoing messages from different protocols and
demultiplexing of incoming messages contained within a single packet,
must be addressed.
Although this specification does not define packet and message Multiplexing messages of different message types from different
versions greater than zero, any future version of this specification protocols running on a given node into a single packet, rather than
MUST, for backwards compatibility, satisfy the following: to have each protocol generate its own packet, is an optimization.
Doing so may reduce the total number of octets as transmitted by that
node, while not doing so should not have any adverse effects on
protocol functioning.
o If the packet version is greater than zero, then a <pkt-header> Having two different protocols (or, two different instances of the
element MUST be included in the packet, which MUST include a <pkt- same protocol) generate messages of the same message type on the same
version> element indicating the packet version. interface may, however, cause inconsistencies, unless this message
generation is coordinated.
o If the message version is greater than zero, then a <msg-version> If a packet contains messages destined for multiple protocols,
element MUST be included in the <msg-header>, indicating the correct functioning of each of these protocols depends on the
message version. appropriate messages being delivered to each protocol.
o The initial octets of a <pkt-header>, up to and including <pkt- If multiple protocols which are using the packet and message format
version>, MUST be preserved as in this specification, in order specified in this document are running over the same UDP port or IP
that packets of versions greater than zero can be correctly protocol number, multiplexing and demultiplexing of messages SHOULD
recognized (and discarded) by implementations of this version of be accomplished based on message types, ensuring a correspondence
this specification. between message types and protocol instances thus:
o The initial octets of a <msg-header>, up until and including <msg- o For each message type, a protocol - unless specified otherwise,
length>, MUST be preserved as in this specification, in order that the one making the IANA reservation for that message type - SHOULD
messages of versions greater than zero can be correctly recognized be designated as the "owner" of that message type.
(and discarded) by implementations of this version of this
specification. o On a given interface, and for a given UDP port or IP protocol
number, only one protocol instance of a protocol which is the
designated "owner" of a message type SHOULD be running,
o Any incoming messages of a given message type SHOULD be delivered
to the protocol instance on the receiving interface which "owns"
messages of that type. Specifically, any incoming message SHOULD
NOT be delivered to any other protocol instances and SHOULD NOT be
delivered to more than one protocol instance.
o Any outgoing messages of a given type SHOULD be generated and
transmitted only by the protocol instance which "owns" that
message type.
o If two protocols both wish to use the same message type (e.g.
through inspecting information carried in messages of that type,
or through inserting information into generated messages of that
type) then this interaction SHOULD be specified by the protocol
which is the designated "owner" of that message type.
Appendix C. Examples Appendix C. Examples
This appendix contains some examples of parts of this specification. This appendix contains some examples of parts of this specification.
C.1. Address Block Examples C.1. Address Block Examples
The following examples illustrate how some combinations of addresses The following examples illustrate how some combinations of addresses
may be efficiently included in address blocks. These examples are may be efficiently included in address blocks. These examples are
for IPv4, with address-length equal to 4. a, b, c etc. represent for IPv4, with address-length equal to 4. a, b, c etc. represent
distinct, non-zero, octet values. distinct, non-zero, octet values.
Note that it is permissible to use a less efficient representation, Note that it is permissible to use a less efficient representation,
in particular one in which the ahashead and ahasfulltail bits of the in particular one in which the ahashead and ahasfulltail flags are
semantics octet are cleared ('0'), and hence head-length = 0, tail- cleared ('0'), and hence head-length = 0, tail-length = 0, mid-length
length = 0, mid-length = address-length, and (with no address = address-length, and (with no address prefixes) the address block
prefixes) the address block consists of the number of addresses, the consists of the number of addresses, <addr-flags> with value 0, and a
semantics octet with value 0, and a list of the uncompressed list of the unaggregated addresses. This is the most efficient way
addresses. This is also the most efficient way to represent a single to represent a single address, and the only way to represent, for
address, and the only way to represent, for example, a.b.c.d and example, a.b.c.d and e.f.g.h in one address block.
e.f.g.h in one address block.
Examples: Examples:
o To include a.b.c.d, a.b.e.f and a.b.g.h: o To include a.b.c.d, a.b.e.f and a.b.g.h:
* head-length = 2; * head-length = 2;
* tail-length = 0; * tail-length = 0;
* mid-length = 2; * mid-length = 2;
* <addr-semantics> has ahashead set (value 1); * <addr-flags> has ahashead set (value 128);
* <tail-length> and <tail> are omitted. * <tail-length> and <tail> are omitted.
The address block is then 3 1 2 a b c d e f g h (11 octets). The address block is then 3 128 2 a b c d e f g h (11 octets).
o To include a.b.c.g and d.e.f.g: o To include a.b.c.g and d.e.f.g:
* head-length = 0; * head-length = 0;
* tail-length = 1; * tail-length = 1;
* mid-length = 3; * mid-length = 3;
* <addr-semantics> has ahasfulltail set (value 2); * <addr-flags> has ahasfulltail set (value 64);
* <head-length> and <head> are omitted. * <head-length> and <head> are omitted.
The address block is then 2 2 1 g a b c d e f (10 octets). The address block is then 2 64 1 g a b c d e f (10 octets).
o To include a.b.d.e and a.c.d.e: o To include a.b.d.e and a.c.d.e:
* head-length = 1; * head-length = 1;
* tail-length = 2; * tail-length = 2;
* mid-length = 1; * mid-length = 1;
* <addr-semantics> has ahashead and ahasfulltail set (value 3). * <addr-flags> has ahashead and ahasfulltail set (value 192).
The address block is then 2 3 1 a 2 d e b c (9 octets). The address block is then 2 192 1 a 2 d e b c (9 octets).
o To include a.b.0.0, a.c.0.0, and a.d.0.0: o To include a.b.0.0, a.c.0.0, and a.d.0.0:
* head-length = 1; * head-length = 1;
* tail-length = 2; * tail-length = 2;
* mid-length = 1; * mid-length = 1;
* <addr-semantics> has ahashead and ahaszerotail set (value 5); * <addr-flags> has ahashead and ahaszerotail set (value 160);
* <tail> is omitted. * <tail> is omitted.
The address block is then 3 5 1 a 2 b c d (8 octets). The address block is then 3 160 1 a 2 b c d (8 octets).
o To include a.b.0.0 and c.d.0.0: o To include a.b.0.0 and c.d.0.0:
* head-length = 0; * head-length = 0;
* tail-length = 2; * tail-length = 2;
* mid-length = 2; * mid-length = 2;
* <addr-semantics> has ahaszerotail set (value 4); * <addr-flags> has ahaszerotail set (value 32);
* <head> and <tail> are omitted. * <head> and <tail> are omitted.
The address block is then 2 4 2 a b c d (7 octets). The address block is then 2 32 2 a b c d (7 octets).
o To include a.b.0.0/n and c.d.0.0/n: o To include a.b.0.0/n and c.d.0.0/n:
* head-length = 0; * head-length = 0;
* tail-length = 2; * tail-length = 2;
* mid-length = 2; * mid-length = 2;
* <addr-semantics> has ahaszerotail and ahassingleprelen set * <addr-flags> has ahaszerotail and ahassingleprelen set (value
(value 12); 48);
* <head> and <tail> are omitted. * <head> and <tail> are omitted.
The address block is then 2 12 2 a b c d n (8 octets). The address block is then 2 48 2 a b c d n (8 octets).
o To include a.b.0.0/n and c.d.0.0/m: o To include a.b.0.0/n and c.d.0.0/m:
* head-length = 0; * head-length = 0;
* tail-length = 2; * tail-length = 2;
* mid-length = 2; * mid-length = 2;
* <addr-semantics> has ahaszerotail and ahasmultiprelen set * <addr-flags> has ahaszerotail and ahasmultiprelen set (value
(value 20); 40);
* <head> and <tail> are omitted. * <head> and <tail> are omitted.
The address block is then 2 20 2 a b c d n m (9 octets). The address block is then 2 40 2 a b c d n m (9 octets).
C.2. TLV Examples C.2. TLV Examples
Assuming the definition of an address block TLV with type EXAMPLE1 Assuming the definition of an address block TLV with type EXAMPLE1
(and no type extension) which has single octet values per address, (and no type extension) which has single octet values per address,
then if values a, a, b and c are to be associated with the four then if values a, a, b and c are to be associated with the four
addresses in the preceding address block, where c is a default value addresses in the preceding address block, where c is a default value
that can be omitted, then this can be done in a number of ways. that can be omitted, then this can be done in a number of ways.
Examples: Examples:
o Using one multivalue TLV covering all of the addresses: o Using one multivalue TLV covering all of the addresses:
* <tlv-semantics> has thasvalue and tismultivalue set (value 36); * <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 (single-length = 1).
* The TLV is then EXAMPLE1 36 4 a a b c (7 octets). * The TLV is then EXAMPLE1 20 4 a a b c (7 octets).
o Using one multivalue TLV omitting the last address: o Using one multivalue TLV omitting the last address:
* <tlv-semantics> has thasvalue, thasmultiindex and tismultivalue * <tlv-flags> has thasmultiindex, thasvalue and tismultivalue set
set (value 52); (value 52);
* <index-start> = 0; * <index-start> = 0;
* <index-stop> = 2 * <index-stop> = 2
* <length> = 3 (single-length = 1). * <length> = 3 (single-length = 1).
* The TLV is then EXAMPLE1 52 0 2 3 a a b (8 octets). * The TLV is then EXAMPLE1 52 0 2 3 a a b (8 octets).
o Using two single value TLVs, omitting the last address. First: o Using two single value TLVs, omitting the last address. First:
* <tlv-semantics> has thasvalue and thasmultiindex set (value * <tlv-flags> has thasmultiindex and thasvalue set (value 48);
20);
* <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 20 0 1 1 a (6 octets). * The TLV is then EXAMPLE1 48 0 1 1 a (6 octets).
Second: Second:
* <tlv-semantics> has thasvalue and thassingleindex set (value * <tlv-flags> has thassingleindex and thasvalue set (value 80);
12);
* <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 12 2 1 b (5 octets). * The TLV is then EXAMPLE1 80 2 1 b (5 octets).
Total length of TLVs is 11 octets. Total length of TLVs is 11 octets.
In this case the first of these is the most efficient. In other In this case the first of these is the most efficient. In other
cases patterns such as the others may be preferred. Regardless of cases patterns such as the others may be preferred. Regardless of
efficiency, any of these may be used. efficiency, any of these may be used.
Assuming the definition of an address block TLV with type EXAMPLE2 Assuming the definition of an address block TLV with type EXAMPLE2
(and no type extension) which has no value, which is to be associated (and no type extension) which has no value, which is to be associated
with the second and third addresses in an address block, then this with the second and third addresses in an address block, then this
can be indicated with a single TLV: can be indicated with a single TLV:
o <tlv-semantics> has thasmultiindex set (value 16); 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> and <value> are omitted.
o The TLV is then EXAMPLE2 16 1 2 (4 octets). o The TLV is then EXAMPLE2 32 1 2 (4 octets).
Assuming the definition of a message TLV with type EXAMPLE3 (and no Assuming the definition of a message TLV with type EXAMPLE3 (and no
type extension) which can take a value field of any length, for such type extension) which can take a value field of any length, for such
a TLV with 8 octets of data (a to h): a TLV with 8 octets of data (a to h):
o <tlv-semantics> has thasvalue set (value 4); 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 4 8 a b c d e f g h (11 octets). o The TLV is then EXAMPLE3 16 8 a b c d e f g h (11 octets).
If, in this example, the number of data octets were 256 or greater If, in this example, the number of data octets were 256 or greater
then <tlv-semantics> would also have thasextlen set and have value 6. then <tlv-flags> would also have thasextlen set and have value 24.
The length would require two octets (most significant first). The The length would require two octets (most significant first). The
TLV length would be 4 + N octets, where N is the number of data 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). octets (it can be 3 + N octets if N is 255 or less).
Appendix D. Illustrations Appendix D. Illustrations
This informative appendix illustrates the elements, which are This informative appendix illustrates the elements which are
normatively specified in Section 5 using regular expressions. normatively specified in Section 5.
Examples with version fields are omitted, as not needed when using
this version of this specification (although permitted).
Bits labeled Rsv or R must be cleared ('0'). Bits labeled C, N, or M Bits labeled Rsv or R should be cleared ('0'). Bits labeled C, N, or
may be cleared ('0') or set ('1'). M may be cleared ('0') or set ('1').
D.1. Packet D.1. Packet
Possible options for the <packet> element. These are differentiated Possible options for the <packet> element. These are differentiated
by their second (semantics) octet, except the last, which starts with by the flags field in the first octet. The packet may include any
a non-zero octet. The packet may include any number (zero or more) number (zero or more) of Messages. The number of Messages is
of messages, except in the last case, when there must be one or more determined from when the packet is exhausted, given the packet length
messages. The number of messages is determined from the size of the from the network layer.
packet (either the <pkt-size> field if present, or from the network
or transport protocol employed).
0 1 2 3 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 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 0 0| Rsv |C|0|0|0|0| | |0|0|0|0|0|0|C|R| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| |
| 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 0 0| Rsv |C|0|0|1|0| Packet Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message | | Message |
| | | |
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
: ... : : ... :
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
skipping to change at page 34, line 26 skipping to change at page 34, line 4
: ... : : ... :
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Message | | Message |
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 0 0| Rsv |C|0|1|0|0| Packet Sequence Number | |0|0|0|0|1|0|C|R| Packet Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message |
| |
| +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| 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 0 0| Rsv |C|0|1|1|0| Packet Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Message |
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
: ... : : ... :
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Message | | Message |
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 0 0| Rsv |C|1|0|0|0| | |0|0|0|0|0|1|C|R| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| | | |
| Packet TLV Block | | Packet TLV Block |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| Message | | Message |
| | | |
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+
| | | | | |
skipping to change at page 37, line 7 skipping to change at page 36, line 7
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Message | | Message |
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 0 0| Rsv |C|1|0|1|0| Packet Size | |0|0|0|0|1|1|C|R| 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 0 0 0 0| Rsv |C|1|1|0|0| Packet Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Packet TLV Block | | Packet TLV Block |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Message | | Message |
| | | |
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+
| | | | | |
skipping to change at page 39, line 4 skipping to change at page 36, line 32
: ... : : ... :
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| 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 0 0| Rsv |C|1|1|1|0| Packet Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message |
| |
| +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D.2. Message D.2. Message
Possible options for the <message> element. These are differentiated Possible options for the <message> element. These are differentiated
by their second (semantics) octet. The length of the message body is by their second (flags) octet. The length of the Message Body is
determined using the <msg-size> field, which includes all the fields determined using the Message Size field, which is the combined length
shown. of all the fields shown.
0 1 2 3 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 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 |R|C|N|0|0|0|0|0| Message Size | | Message Type |0|0|0|0|0|C|Rsv| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 |R|C|N|0|0|0|1|0| Message Size | | Message Type |1|0|0|0|0|C|Rsv| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 |R|C|N|0|0|1|0|0| Message Size | | Message Type |0|1|0|0|0|C|Rsv| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | | | Hop Limit | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 |R|C|N|0|0|1|1|0| Message Size | | Message Type |1|1|0|0|0|C|Rsv| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | | | Hop Limit | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 |R|C|N|0|1|0|0|0| Message Size | | Message Type |0|0|1|0|0|C|Rsv| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | | | Hop Count | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 |R|C|N|0|1|0|1|0| Message Size | | Message Type |1|0|1|0|0|C|Rsv| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | | | Hop Count | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 |R|C|N|0|1|1|0|0| Message Size | | Message Type |0|1|1|0|0|C|Rsv| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | | | Hop Limit | Hop Count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 |R|C|N|0|1|1|1|0| Message Size | | Message Type |1|1|1|0|0|C|Rsv| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | | | Hop Limit | Hop Count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 |R|C|N|1|0|0|0|0| Message Size | | Message Type |0|0|0|1|N|C|Rsv| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Sequence Number | | | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 |R|C|N|1|0|0|1|0| Message Size | | Message Type |1|0|0|1|N|C|Rsv| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Sequence Number | | | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 |R|C|N|1|0|1|0|0| Message Size | | Message Type |0|1|0|1|N|C|Rsv| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Message Sequence Number | | | Hop Limit | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 |R|C|N|1|0|1|1|0| Message Size | | Message Type |1|1|0|1|N|C|Rsv| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Message Sequence Number | | | Hop Limit | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 |R|C|0|1|1|0|0|0| Message Size | | Message Type |0|0|1|1|N|C|Rsv| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | Message Sequence Number | | | Hop Count | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 |R|C|N|1|1|0|1|0| Message Size | | Message Type |1|0|1|1|N|C|Rsv| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | Message Sequence Number | | | Hop Count | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 |R|C|0|1|1|1|0|0| Message Size | | Message Type |0|1|1|1|N|C|Rsv| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | Message Sequence Number | | Hop Limit | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 |R|C|N|1|1|1|1|0| Message Size | | Message Type |1|1|1|1|N|C|Rsv| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | Message Sequence Number | | Hop Limit | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D.3. Message Body D.3. Message Body
Format of a message body (the <message> element excluding its initial Format of a message body (the <message> element excluding its initial
<msg-header> element). The message may include any number (zero or <msg-header> element). The message body includes one Message TLV
more) of address block and address TLV block pairs. Block (containing zero or more TLVs) and may include any number (zero
or more) of Address Block and Address TLV Block pairs.
0 1 2 3 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 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 | | Message TLV Block |
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
skipping to change at page 47, line 8 skipping to change at page 43, line 8
| | | |
| Address TLV Block | | Address TLV Block |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D.4. Address Block D.4. Address Block
Possible options for the <addr-block> element. These are Possible options for the <addr-block> element. These are
differentiated by their second (semantics) octet. The number of differentiated by their second (flags) octet. The number of Mid
<mid> elements is equal to the number of addresses (except when mid- elements is equal to the number of addresses (except when mid-length
length is zero, when there are no <mid> elements). Where a variable is zero, when there are no Mid elements). Where a variable number of
number of <prefix-length> fields is shown, their number is equal to Prefix Length fields is shown, their number is equal to the number of
the number of addresses. addresses.
0 1 2 3 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 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 | Rsv |0|0|0|0|0| Mid | | Number Addrs |0|0|0|0|0| Rsv | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | | | Mid (cont) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
: ... : : ... :
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | | | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | | Mid (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 | Rsv |0|0|0|0|1| Head Length | Head | | Number Addrs |1|0|0|0|0| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Mid | | | Head (cont) | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
: ... : : ... :
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | | | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 | Rsv |0|0|0|1|0| Tail Length | Tail | | Number Addrs |0|1|0|0|0| Rsv | Tail Length | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail (cont) | Mid | | | Tail (cont) | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
: ... : : ... :
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | | | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 | Rsv |0|0|0|1|1| Head Length | Head | | Number Addrs |1|1|0|0|0| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Tail Length | Tail | | Head (cont) | Tail Length | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | | | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
: ... : : ... :
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | | | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 | Rsv |0|0|1|0|0| Tail Length | Mid | | Number Addrs |0|0|1|0|0| Rsv | Tail Length | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | | | Mid (cont) | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| | | |
: ... : : ... :
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | | | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 | Rsv |0|0|1|0|1| Head Length | Head | | Number Addrs |1|0|1|0|0| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Tail Length | Mid | | Head (cont) | Tail Length | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: ... : : ... :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 | Rsv |0|1|0|0|0| Mid | | Number Addrs |0|0|0|1|0| Rsv | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | | | Mid (cont) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
: ... : : ... :
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | | | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | Prefix Length | | Mid (cont) | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 | Rsv |0|1|0|0|1| Head Length | Head | | Number Addrs |1|0|0|1|0| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Mid | | | Head (cont) | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
: ... : : ... :
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | Prefix Length | | | Mid | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 | Rsv |0|1|0|1|1| Head Length | Head | | Number Addrs |0|1|0|1|0| Rsv | Tail Length | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Tail Length | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | | | Tail (cont) | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
: ... : : ... :
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | | | Mid | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length |
+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 | Rsv |0|1|0|1|0| Tail Length | Tail | | Number Addrs |1|1|0|1|0| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail (cont) | Mid | | | Head (cont) | Tail Length | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
: ... : : ... :
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | Prefix Length | | | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length |
+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 | Rsv |0|1|1|0|0| Tail Length | Mid | | Number Addrs |0|0|1|1|0| Rsv | Tail Length | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | | | Mid (cont) | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| | | |
: ... : : ... :
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | Prefix Length | | | Mid | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 | Rsv |0|1|1|0|1| Head Length | Head | | Number Addrs |1|0|1|1|0| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Tail Length | Mid | | Head (cont) | Tail Length | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: ... : : ... :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | Prefix Length | | Mid | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 | Rsv |1|0|0|0|0| Mid | | Number Addrs |0|0|0|0|1| Rsv | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | | | Mid (cont) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
: ... : : ... :
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | | | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | Prefix Length | | | Mid (cont) | Prefix Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
: ... : : ... :
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Prefix Length | | | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 | Rsv |1|0|0|0|1| Head Length | Head | | Number Addrs |1|0|0|0|1| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Mid | | | Head (cont) | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
: ... : : ... :
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | Prefix Length | | | Mid | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: ... : : ... :
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Prefix Length | | | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 | Rsv |1|0|0|1|0| Tail Length | Tail | | Number Addrs |0|1|0|0|1| Rsv | Tail Length | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail (cont) | Mid | | | Tail (cont) | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
: ... : : ... :
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | Prefix Length | | | Mid | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: ... : : ... :
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Prefix Length | | | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 | Rsv |1|0|0|1|1| Head Length | Head | | Number Addrs |1|1|0|0|1| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Tail Length | Tail | | Head (cont) | Tail Length | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | | | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
: ... : : ... :
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | | | Mid |
skipping to change at page 53, line 29 skipping to change at page 49, line 29
| Prefix Length | | | Prefix Length | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
: ... : : ... :
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+
| | Prefix Length | | | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 | Rsv |1|0|1|0|0| Tail Length | Mid | | Number Addrs |0|0|1|0|1| Rsv | Tail Length | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | | | Mid (cont) | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| | | |
: ... : : ... :
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | Prefix Length | | | Mid | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: ... : : ... :
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Prefix Length | | | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 | Rsv |1|0|1|0|1| Head Length | Head | | Number Addrs |1|0|1|0|1| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Tail Length | Mid | | Head (cont) | Tail Length | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: ... : : ... :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | Prefix Length | | | Mid | Prefix Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
: ... : : ... :
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Prefix Length | | | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D.5. TLV Block D.5. TLV Block
Format if a <tlv-block> element. There may be any number (zero or Format of a <tlv-block> element. There may be any number (zero or
more) of TLVs, with total length (in octets) equal to the length more) of TLVs, with total length of the TLVs (in octets) equal to the
field. Length field.
0 1 2 3 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 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 | | | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| TLV | | TLV |
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+
| | | | | |
skipping to change at page 55, line 8 skipping to change at page 51, line 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| TLV | | TLV |
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D.6. TLV D.6. TLV
Possible options for the <tlv> element. These are differentiated by Possible options for the <tlv> element. These are differentiated by
their second (semantics) octet. If there are no index fields then their second (flags) octet. If there are no index fields then this
this may be a packet, message or address block TLV, if there is one may be a packet, message or address block TLV, if there are one or
or two index fields then this must be an address block TLV. The two index fields then this must be an address block TLV. The Length
length field gives the length of the value field (in octets). field gives the length of the value field (in octets).
0 1 2 3 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 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 |Rsv|0|0|0|0|0|0| | Type |0|0|0|0|0|0|Rsv|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 |Rsv|0|0|0|0|0|1| Type Ext | | Type |1|0|0|0|0|0|Rsv| Type Ext |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 |Rsv|0|0|0|0|1|0| Index Start | | Type |0|1|0|0|0|0|Rsv| Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 |Rsv|0|0|0|0|1|1| Type Ext | Index Start | | Type |1|1|0|0|0|0|Rsv| Type Ext | Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 |Rsv|0|0|0|1|0|0| Index Start | Index Stop | | Type |0|0|1|0|0|0|Rsv| Index Start | Index Stop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 |Rsv|0|0|0|1|0|1| Type Ext | Index Start | | Type |1|0|1|0|0|0|Rsv| Type Ext | Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index Stop | | Index Stop |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
0 1 2 3 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 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 |Rsv|M|0|1|0|0|0| Length | | | Type |0|0|0|1|0|M|Rsv| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Value | | Value |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
0 1 2 3 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 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 |Rsv|M|0|1|0|0|1| Type Ext | Length | | Type |1|0|0|1|0|M|Rsv| Type Ext | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Value | | Value |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
0 1 2 3 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 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 |Rsv|0|0|1|0|1|0| Index Start | Length | | Type |0|1|0|1|0|0|Rsv| Index Start | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Value | | Value |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
0 1 2 3 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 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 |Rsv|0|0|1|0|1|1| Type Ext | Index Start | | Type |1|1|0|1|0|0|Rsv| Type Ext | Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | | | Length | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| Value | | Value |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
0 1 2 3 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 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 |Rsv|M|0|1|1|0|0| Index Start | Index Stop | | Type |0|0|1|1|0|M|Rsv| Index Start | Index Stop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | | | Length | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| Value | | Value |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
0 1 2 3 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 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 |Rsv|M|0|1|1|0|1| Type Ext | Index Start | | Type |1|0|1|1|0|M|Rsv| Type Ext | Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index Stop | Length | | | Index Stop | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Value | | Value |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
0 1 2 3 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 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 |Rsv|M|1|1|0|0|0| Length | | Type |0|0|0|0|1|M|Rsv| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Value | | Value |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
0 1 2 3 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 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 |Rsv|M|1|1|0|0|1| Type Ext | Length | | Type |1|0|0|1|1|M|Rsv| Type Ext | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (cont) | | | Length (cont) | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| Value | | Value |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
0 1 2 3 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 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 |Rsv|0|1|1|0|1|0| Index Start | Length | | Type |0|1|0|1|1|0|Rsv| Index Start | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (cont) | | | Length (cont) | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| | | |
| Value | | Value |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
0 1 2 3 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 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 |Rsv|0|1|1|0|1|1| Type Ext | Index Start | | Type |1|1|0|1|1|0|Rsv| Type Ext | Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | | | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Value | | Value |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
0 1 2 3 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 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 |Rsv|M|1|1|1|0|0| Index Start | Index Stop | | Type |0|0|1|1|1|M|Rsv| Index Start | Index Stop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | | | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Value | | Value |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
0 1 2 3 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 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 |Rsv|M|1|1|1|0|1| Type Ext | Index Start | | Type |1|0|1|1|1|M|Rsv| Type Ext | Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index Stop | Length | | | Index Stop | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Value | | Value |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Appendix E. Complete Example Appendix E. Complete Example
An example packet, using IPv4 addresses (length four octets) is The following example packet, using IPv4 addresses (hence address-
shown. This packet has a header, indicated by the initial octet 0. length is four octets) is included with the intent to exemplify how
The packet header has the phasseqnum bit of its semantics octet 4 packet and message headers are constructed, and how addresses and
set, and hence has version zero, no packet size (this is taken from attributes are encoded using address blocks and TLV blocks. This
the network or transport protocol carrying this packet), a packet example is specifically not constructed to exhibit maximum message or
sequence number, and no packet TLV block. packet size reduction. Appendix D contains illustrations of all
syntactical elements.
The packet contains a single message with length 55 octets. This The packet header has the phasseqnum flag set of its flags field set
(value 8), and hence has a Packet Sequence Number, but no packet TLV
block.
The packet contains a single message with length 54 octets. This
message has the mhasorig, mhashoplimit, mhashopcount and mhasseqnum message has the mhasorig, mhashoplimit, mhashopcount and mhasseqnum
bits of its semantics octet 30 set, and hence has version zero and flags of its flags octet set (value 240), and hence includes an
includes an originator address, a hop limit, a hop count and a Originator Address, a Hop Limit, a Hop Count and a Message Sequence
message sequence number (which is type independent). The message has Number (which is type independent). The message has a message TLV
a message TLV block with content length 9 octets, containing a single block with content length 9 octets, containing a single message TLV.
message TLV. This TLV has the thasvalue bit of its semantics octet 8 This TLV has the thasvalue flag of its flags octet set (value 16),
set, and hence contains a value field, with preceding value length 6 and hence contains a Value field, with preceding value length 6
octets. The message then has two address blocks each with a octets. The message then has two address blocks each with a
following address TLV block. following address TLV block.
The first address block contains 2 address prefixes. It has the The first address block contains 2 address prefixes. It has the
ahaszerotail and ahassingleprelen bits of its semantics octet 12 set, ahaszerotail and ahassingleprelen flags of its flags octet set (value
and hence has no head (head length is zero octets). It has tail 48), and hence has no head (head-length is zero octets). It has a
length 2 octets, hence mid length two octets. The two tail octets of tail-length of 2 octets, hence mid-length is two octets. The two
each address are not included and have value zero. The address block tail octets of each address are not included (since ahaszerotail is
has a single prefix length. The following address TLV block is empty set) and have value zero. The address block has a single Prefix
(content length 0 octets). Length. The following address TLV block is empty (content length 0
octets).
The second address block contains 3 addresses. It has the ahashead The second address block contains 3 addresses. It has the ahashead
bit of its semantics octet 1 set, and has head length 2 octets, no flag of its flags octet set (value 128), and has head length 2
tail (tail length is zero octets) and hence mid length two octets. octets, no tail (tail-length is zero octets) and hence mid-length is
It is followed by an address TLV block, with content length 9 octets, two octets. It is followed by an address TLV block, with content
containing two address block TLVs. The first of these TLVs has the length 9 octets, containing two address block TLVs. The first of
thasvalue bit of its semantics octet 8 set, and has a single value of these TLVs has the thasvalue flag of its flags octet set (value 16),
length 2 octets, which applies to all of the addresses in the address and has a single Value of length 2 octets, which applies to all of
block. The second of these TLVs has the thasmultiindex bit of its the addresses in the address block. The second of these TLVs has the
semantics octet 4 set, and hence has no value length or value fields. thasmultiindex flag of its flags octet set (value 32), and hence has
It has two index fields, which indicate those addresses this TLV 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). applies to (inclusive range, counting from zero).
0 1 2 3 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 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 0 0|0 0 0 0 0 1 0 0| Packet Sequence Number | |0 0 0 0 1 0 0 0| Packet Sequence Number | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0 0 0 1 1 1 1 0|0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 1| |1 1 1 1 0 0 0 0|0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 0| Orig Addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address (cont) | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | Message Sequence Number | | Hop Count | Message Sequence Number |0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1| TLV Type |0 0 0 0 1 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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 1 0| Value | | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (cont) |0 0 0 0 0 0 1 0| | Value (cont) |0 0 0 0 0 0 1 0|0 0 1 1 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 1 0 0|0 0 0 0 0 0 1 0| Mid | |0 0 0 0 0 0 1 0| Mid | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | Prefix Length |0 0 0 0 0 0 0 0| | 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 0 0|0 0 0 0 0 0 1 1|0 0 0 0 0 0 0 1|0 0 0 0 0 0 1 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 | Mid | | Head (cont) | Mid | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | Mid | | Mid (cont) | Mid |0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1| TLV Type |0 0 0 0 1 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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 0| Value | TLV Type | | Value | TLV Type |0 0 1 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0| Index Start | Index Stop | | Index Start | Index Stop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Appendix F. Contributors Appendix F. Contributors
This specification is the result of the joint efforts of the This specification is the result of the joint efforts of the
following contributors from the OLSRv2 Design Team, listed following contributors from the OLSRv2 Design Team, listed
alphabetically: alphabetically:
o Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr> o Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr>
o Emmanuel Baccelli, INRIA, France, <Emmanuel.Baccelli@inria.fr> o Emmanuel Baccelli, INRIA, France, <Emmanuel.Baccelli@inria.fr>
skipping to change at page 62, line 17 skipping to change at page 58, line 4
This specification is the result of the joint efforts of the This specification is the result of the joint efforts of the
following contributors from the OLSRv2 Design Team, listed following contributors from the OLSRv2 Design Team, listed
alphabetically: alphabetically:
o Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr> o Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr>
o Emmanuel Baccelli, INRIA, France, <Emmanuel.Baccelli@inria.fr> o Emmanuel Baccelli, INRIA, France, <Emmanuel.Baccelli@inria.fr>
o Thomas Heide Clausen, LIX, Ecole Polytechnique, France, o Thomas Heide Clausen, LIX, Ecole Polytechnique, France,
<T.Clausen@computer.org> <T.Clausen@computer.org>
o Justin W. Dean, NRL, USA<jdean@itd.nrl.navy.mil> o Justin W. Dean, NRL, USA<jdean@itd.nrl.navy.mil>
o Christopher Dearlove, BAE Systems, UK, o Christopher Dearlove, BAE Systems, UK,
<chris.dearlove@baesystems.com> <chris.dearlove@baesystems.com>
o Satoh Hiroki, Hitachi SDL, Japan, <h-satoh.yj@sdl.hitachi.co.jp> o Satoh Hiroki, Hitachi SDL, Japan,
<hiroki.satoh.yj@sdl.hitachi.co.jp>
o Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr> o Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr>
o Monden Kazuya, Hitachi SDL, Japan, <monden.vw@sdl.hitachi.co.jp> o Monden Kazuya, Hitachi SDL, Japan,
<kazuya.monden.vw@sdl.hitachi.co.jp>
Appendix G. Acknowledgements Appendix G. Acknowledgments
The authors would like to acknowledge the team behind OLSRv1, as The authors would like to acknowledge the team behind OLSR [RFC3626],
specified in RFC 3626, including Anis Laouiti, Pascale Minet, Laurent including Anis Laouiti (INT, France), Pascale Minet, Laurent Viennot
Viennot (all at INRIA, France), and Amir Qayyum (Center for Advanced (both at INRIA, France), and Amir Qayyum (Center for Advanced
Research in Engineering, Pakistan) for their contributions. Research in Engineering, Pakistan) for their contributions.
The authors would like to gratefully acknowledge the following people The authors would like to gratefully acknowledge the following people
for intense technical discussions, early reviews and comments on the for intense technical discussions, early reviews and comments on the
specification and its components: Joe Macker (NRL), Alan Cullen (BAE specification and its components (listed alphabetically):
Systems), Ian Chakeres (Motorola), Charlie E. Perkins (Nokia),
Andreas Schjonhaug (LIX), Florent Brunneau (LIX), Yasunori Owada o Brian Adamson (NRL)
(Niigata University), Teco Boot (Infinity Networks) and the entire
IETF MANET working group. o Teco Boot (Infinity Networks)
o Florent Brunneau (LIX)
o Ian Chakeres (Motorola)
o Alan Cullen (BAE Systems)
o Ulrich Herberg (LIX)
o Joe Macker (NRL)
o Yasunori Owada (Niigata University)
o Charlie E. Perkins (WiChorus)
o Andreas Schjonhaug (LIX)
and the entire IETF MANET working group.
Authors' Addresses Authors' Addresses
Thomas Heide Clausen Thomas Heide Clausen
LIX, Ecole Polytechnique, France LIX, Ecole Polytechnique, France
Phone: +33 6 6058 9349 Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org EMail: T.Clausen@computer.org
URI: http://www.thomasclausen.org/ URI: http://www.thomasclausen.org/
 End of changes. 284 change blocks. 
766 lines changed or deleted 886 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/