draft-ietf-manet-packetbb-16.txt   draft-ietf-manet-packetbb-17.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: March 30, 2009 BAE Systems Advanced Technology Expires: May 22, 2009 BAE Systems Advanced Technology
Centre Centre
J. Dean J. Dean
Naval Research Laboratory Naval Research Laboratory
C. Adjih C. Adjih
INRIA Rocquencourt INRIA Rocquencourt
September 26, 2008 November 18, 2008
Generalized MANET Packet/Message Format Generalized MANET Packet/Message Format
draft-ietf-manet-packetbb-16 draft-ietf-manet-packetbb-17
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 March 30, 2009. This Internet-Draft will expire on May 22, 2009.
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 protocols. messages that may be used by mobile ad hoc network routing protocols.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notation and Terminology . . . . . . . . . . . . . . . . . . . 4 2. Notation and Terminology . . . . . . . . . . . . . . . . . . . 4
2.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Elements . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.1. Elements . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2. Variables . . . . . . . . . . . . . . . . . . . . . . 5 2.1.2. Variables . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 7 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 7
5. Syntactical Specification . . . . . . . . . . . . . . . . . . 7 5. Syntactical Specification . . . . . . . . . . . . . . . . . . 7
5.1. Packets . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Packets . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Address Blocks . . . . . . . . . . . . . . . . . . . . . . 11 5.3. Address Blocks . . . . . . . . . . . . . . . . . . . . . . 11
5.4. TLVs and TLV Blocks . . . . . . . . . . . . . . . . . . . 14 5.4. TLVs and TLV Blocks . . . . . . . . . . . . . . . . . . . 14
5.4.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.4.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.4.2. TLV Inclusion and Constraints . . . . . . . . . . . . 18 5.4.2. TLV Usage . . . . . . . . . . . . . . . . . . . . . . 17
5.5. Malformed Elements . . . . . . . . . . . . . . . . . . . . 19 5.5. Malformed Elements . . . . . . . . . . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 19 6.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 18
6.2. Address Family . . . . . . . . . . . . . . . . . . . . . . 21 6.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 20
6.3. Message Types . . . . . . . . . . . . . . . . . . . . . . 22 6.2.1. Message Type Specific TLV Registry Creation . . . . . 20
6.3.1. Message Type Specific TLV Registry Creation . . . . . 22 6.3. Packet TLV Types . . . . . . . . . . . . . . . . . . . . . 20
6.4. Packet TLV Types . . . . . . . . . . . . . . . . . . . . . 22 6.3.1. Packet TLV Type Extension Registry Creation . . . . . 21
6.4.1. Packet TLV Type Extension Registry Creation . . . . . 22 6.4. Message TLV Types . . . . . . . . . . . . . . . . . . . . 21
6.5. Message TLV Types . . . . . . . . . . . . . . . . . . . . 23 6.4.1. Message TLV Type Extension Registry Creation . . . . . 22
6.5.1. Message TLV Type Extension Registry Creation . . . . . 23 6.5. Address Block TLV Types . . . . . . . . . . . . . . . . . 22
6.6. Address Block TLV Types . . . . . . . . . . . . . . . . . 24 6.5.1. Address Block TLV Type Extension Registry Creation . . 23
6.6.1. Address Block TLV Type Extension Registry Creation . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7.1. Authentication and Integrity Suggestions . . . . . . . . . 23
7.1. Authentication and Integrity Suggestions . . . . . . . . . 25 7.2. Confidentiality Suggestions . . . . . . . . . . . . . . . 24
7.2. Confidentiality Suggestions . . . . . . . . . . . . . . . 25 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 8.1. Normative References . . . . . . . . . . . . . . . . . . . 25
8.1. Normative References . . . . . . . . . . . . . . . . . . . 26 8.2. Informative References . . . . . . . . . . . . . . . . . . 25
8.2. Informative References . . . . . . . . . . . . . . . . . . 27 Appendix A. Multiplexing and Demultiplexing . . . . . . . . . . . 25
Appendix A. Multiplexing and Demultiplexing . . . . . . . . . . . 27 Appendix B. Intended Usage . . . . . . . . . . . . . . . . . . . 26
Appendix B. Intended Usage . . . . . . . . . . . . . . . . . . . 28 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 27
Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 29 C.1. Address Block Examples . . . . . . . . . . . . . . . . . . 27
C.1. Address Block Examples . . . . . . . . . . . . . . . . . . 29 C.2. TLV Examples . . . . . . . . . . . . . . . . . . . . . . . 30
C.2. TLV Examples . . . . . . . . . . . . . . . . . . . . . . . 31 Appendix D. Illustrations . . . . . . . . . . . . . . . . . . . . 32
Appendix D. Illustrations . . . . . . . . . . . . . . . . . . . . 34 D.1. Packet . . . . . . . . . . . . . . . . . . . . . . . . . . 32
D.1. Packet . . . . . . . . . . . . . . . . . . . . . . . . . . 34 D.2. Message . . . . . . . . . . . . . . . . . . . . . . . . . 35
D.2. Message . . . . . . . . . . . . . . . . . . . . . . . . . 37 D.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 41
D.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 43 D.4. Address Block . . . . . . . . . . . . . . . . . . . . . . 42
D.4. Address Block . . . . . . . . . . . . . . . . . . . . . . 44 D.5. TLV Block . . . . . . . . . . . . . . . . . . . . . . . . 49
D.5. TLV Block . . . . . . . . . . . . . . . . . . . . . . . . 51 D.6. TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
D.6. TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Appendix E. Complete Example . . . . . . . . . . . . . . . . . . 55
Appendix E. Complete Example . . . . . . . . . . . . . . . . . . 57 Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 57
Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 58 Appendix G. Acknowledgments . . . . . . . . . . . . . . . . . . . 58
Appendix G. Acknowledgments . . . . . . . . . . . . . . . . . . . 59
1. Introduction 1. Introduction
This document specifies the syntax of a packet format designed for This document specifies the syntax of a packet format designed for
carrying multiple routing protocol messages for information exchange carrying multiple routing protocol messages for information exchange
between MANET (Mobile Ad hoc NETwork) routers. Messages consist of a between MANET (Mobile Ad hoc NETwork) routers. Messages consist of a
message header, which is designed for control of message message header, which is designed for control of message
dissemination, and a message body, which contains protocol dissemination, and a message body, which contains protocol
information. Only the syntax of the packet and messages is information. Only the syntax of the packet and messages is
specified. specified.
skipping to change at page 6, line 36 skipping to change at page 6, line 36
octets than are most wired networks. This specification thus octets than are most wired networks. This specification thus
represents a tradeoff between sometimes competing attributes, represents a tradeoff between sometimes competing attributes,
specifically efficiency, extensibility, and ease of use. specifically efficiency, extensibility, and ease of use.
Efficiency is supported by reducing packet size and by allowing Efficiency is supported by reducing packet size and by allowing
multiple disjoint messages in a single packet. Reduced packet size multiple disjoint messages in a single packet. Reduced packet size
is primarily supported by address aggregation, optional packet and is primarily supported by address aggregation, optional packet and
message header fields, and optional fields in address blocks and message header fields, and optional fields in address blocks and
TLVs. Supporting multi-message packets allows a reduction in the TLVs. Supporting multi-message packets allows a reduction in the
number of packets, each of which can incur significant bandwidth number of packets, each of which can incur significant bandwidth
costs from transport, network and lower layers. costs from transport, network, and lower layers.
This specification provides both external and internal extensibility. This specification provides both external and internal extensibility.
External extensibility is supported by the ability to add packet TLVs External extensibility is supported by the ability to add packet TLVs
and to define new message types. Internal extensibility is supported and to define new message types. Internal extensibility is supported
by the ability to add message TLVs and address block TLVs to existing by the ability to add message TLVs and address block TLVs to existing
messages. Protocols can define new TLV types, and hence the contents messages. Protocols can define new TLV types, and hence the contents
of their value fields (see Section 6.1), and new message types. of their value fields (see Section 6.1), and new message types.
Protocols can also reuse message and TLV type definitions from other Protocols can also reuse message and TLV type definitions from other
protocols which also use this specification. protocols which also use this specification.
This specification aims at being sufficiently expressive and flexible This specification aims at being sufficiently expressive and flexible
to be able to accommodate both different classes of MANET routing to be able to accommodate both different classes of MANET routing
protocols (e.g. proactive, reactive and hybrid routing protocols), as protocols (e.g. proactive, reactive and hybrid routing protocols), as
well as extensions thereto. Having a common packet and message well as extensions thereto. Having a common packet and message
format, and a common way of representing IP addresses and associated format, and a common way of representing IP addresses and associated
attributes, allows generic parsing code to be developed, regardless attributes, allows generic parsing code to be developed, regardless
of the algorithm used by the routing protocol. of the algorithm used by the routing protocol.
All addresses within a message are assumed to be of the same size, All addresses within a message are assumed to be of the same size,
deduced from the IP header. In the case of mixed IPv6 and IPv4 specified in the message header. In the case of mixed IPv6 and IPv4
addresses, IPv4 addresses can be represented as IPv4-mapped IPv6 addresses, IPv4 addresses can be represented as IPv4-mapped IPv6
addresses as specified in [RFC4291]. Packets may be unicast or addresses as 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 signaling between MANET routers. This MANET routing protocol signaling between MANET routers. This
specification includes elements which can support scope limited specification includes elements which can support scope limited
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 signaling in a multi-hop network. MANET routing protocol signaling in a multi-hop network. Packets may
be unicast or multicast, and may use any appropriate transport
protocol, or none.
A MANET routing protocol using the packet format defined by this A MANET routing protocol using the message format defined by this
specification can constrain the syntax (for example requiring a specification can constrain the syntax (for example requiring a
specific set of message header fields) that the protocol will employ. specific set of message header fields) that the protocol will employ.
Protocols with such restrictions need not be able to parse all Protocols with such restrictions need not be able to parse all
possible packet structures as defined by this document but must be possible message structures as defined by this document but must be
coherent in packet generation and reception of packets of which they coherent in message generation and reception of messages which they
define. If a protocol specifies which elements are included, then define. If a protocol specifies which elements are included, then
direct indexing of the appropriate fields is possible, dependant on direct indexing of the appropriate fields is possible, dependent on
the syntax restrictions imposed by the protocol. Such protocols may the syntax restrictions imposed by the protocol. Such protocols may
have more limited extensibility. 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
protocol. protocol.
5. Syntactical Specification 5. Syntactical Specification
This section normatively provides syntactical specification of a This section normatively provides syntactical specification of a
packet, represented by the element <packet> and the elements from packet, represented by the element <packet> and the elements from
which it is composed. The specification is given using the notation which it is composed. The specification is given using the notation
in Section 2.1. in Section 2.1.
Graphical illustrations of the layout of specified elements are given Graphical illustrations of the layout of specified elements are given
in Appendix D, a graphical illustration of a complete example in Appendix D, a graphical illustration of a complete example (a
(packet, message with address blocks, TLVs) is given in Appendix E. packet including a message with address blocks and TLVs) is given in
Appendix E.
This format uses network byte order, as indicated in Section 2.1. This format uses network byte order, as indicated in Section 2.1.
5.1. Packets 5.1. Packets
<packet> is defined by: <packet> is defined by:
<packet> := <pkt-header> <packet> := <pkt-header>
<message>* <message>*
skipping to change at page 8, line 36 skipping to change at page 8, line 40
remainder of the packet header: remainder of the packet header:
bit 0 (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 1 (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 2 (pnouniord): If cleared ('0'), then the packet TLV block bits 2-3: Are RESERVED, and SHOULD each be cleared ('0') on
MUST conform to the constraints in Section 5.4.2. If set transmission, and SHOULD be ignored on reception.
('1'), then the packet TLV block is not subject to the
constraints in Section 5.4.2. Additional constraints MAY be
imposed by a protocol using this specification.
bit 3: Is RESERVED, and SHOULD be cleared ('0') on transmission,
and SHOULD be ignored on reception.
<pkt-seq-num> is omitted if the phasseqnum pkt-flag is cleared <pkt-seq-num> is omitted if the phasseqnum flag is cleared ('0'),
('0'), otherwise is a 16 bit unsigned integer field, specifying a otherwise is a 16 bit unsigned integer field, specifying a packet
packet sequence number. sequence number.
<tlv-block> is omitted if the phastlv flag 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.
It is assumed that the network layer is able to deliver the exact It is assumed that the network layer is able to deliver the exact
payload length, thus avoiding having to carry the packet length in payload length, thus avoiding having to carry the packet length in
the packet. the packet.
5.2. Messages 5.2. Messages
skipping to change at page 9, line 32 skipping to change at page 9, line 30
additional attributes. 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-flags> <msg-flags>
<msg-addr-family> <msg-addr-length>
<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. of the message.
<msg-flags> is a 5 bit field, specifying the interpretation of the <msg-flags> is a 4 bit field, specifying the interpretation of the
remainder of the message header: remainder of the message header:
bit 0 (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 1 (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 2 (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 3 (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 4 (mnouniord): If cleared ('0'), then the message TLV block <msg-addr-length> is a 4 bit unsigned integer field, encoding the
and all address TLV blocks in the message MUST conform to the length of all addresses included in this message (<msg-orig-addr>
constraints in Section 5.4.2. If set ('1'), then the message as well as each address included in address blocks as defined in
TLV block and all address TLV blocks in the message are not Section 5.3), as follows:
subject to the constraints in Section 5.4.2. Additional
constraints MAY be imposed by a protocol using this
specification.
<msg-addr-family> is a 3 bit unsigned integer field, specifying the <msg-addr-length> = the length of an address in octets - 1
address family (and hence, the address size) of all addresses
included in this message, i.e. of the <msg-orig-addr> as well as
of addresses included in address blocks as defined in Section 5.3.
The value of this field MUST be set according to the IANA registry
in Section 6.2.
address-length - is a variable whose value is the length of an <msg-addr-length> is thus 3 for IPv4 addresses, or 15 for IPv4
address in octets, of the address family specified in <msg-addr- addresses.
family> as interpreted according to the IANA registry in
Section 6.2. For example, address-length is 4 if the address address-length is a variable whose value is the length of an address
family is IPv4, or 16 if the address family is IPv6. in octets, and is calculated as follows:
address-length = <msg-addr-length> + 1
<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>, including the <msg-header>. of octets that make up the <message>, including the <msg-header>.
<msg-orig-addr> is omitted if the mhasorig msg-flag is cleared <msg-orig-addr> is omitted if the mhasorig flag is cleared ('0'),
('0'), otherwise is an identifier with length equal to address- otherwise is an identifier with length equal to address-length,
length, which can serve to uniquely identify the MANET router that which can serve to uniquely identify the MANET router that
originated the message. originated the message.
<msg-hop-limit> is omitted if the mhashoplimit msg-flag is cleared <msg-hop-limit> is omitted if the mhashoplimit flag is cleared
('0'), otherwise is an 8 bit unsigned integer field, which can ('0'), otherwise is an 8 bit unsigned integer field, which can
contain the maximum number of hops that the message should be contain the maximum number of hops that the message should be
further transmitted. further transmitted.
<msg-hop-count> is omitted if the mhashopcount msg-flag is cleared <msg-hop-count> is omitted if the mhashopcount flag is cleared
('0'), otherwise is an 8 bit unsigned integer field, which can ('0'), otherwise is an 8 bit unsigned integer field, which can
contain the number of hops that the message has traveled. contain the number of hops that the message has traveled.
<msg-seq-num> is omitted if the mhasseqnum msg-flag is cleared <msg-seq-num> is omitted if the mhasseqnum flag is cleared ('0'),
('0'), otherwise is a 16 bit unsigned integer field, which can otherwise is a 16 bit unsigned integer field, which can contain a
contain a sequence number, generated by the message's originator sequence number, generated by the message's originator MANET
MANET router. router.
5.3. Address Blocks 5.3. Address Blocks
An address block can specify one or more addresses, all of which will An address block can specify one or more addresses, all of which will
each be of the address family as specified by the <msg-addr-family> each be address-length octets long, as specified using the <msg-addr-
in the <msg-header> of the message containing the address block. An length> in the <msg-header> of the message containing the address
address block can also specify prefix lengths that can be applied to block. An address block can also specify prefix lengths that can be
all addresses in the address block, if appropriate. This allows an applied to all addresses in the address block, if appropriate. This
address block to specify either addresses or address prefixes. A allows an address block to specify either addresses or address
protocol may specify that an address with a maximum prefix length prefixes. A protocol may specify that an address with a maximum
(equal to the address length, in bits) is considered to be an prefix length (equal to the address length, in bits, i.e. 8 *
address, rather than an address prefix, thus allowing an address address-length) is considered to be an address, rather than an
block to contain a mixture of addresses and address prefixes. The address prefix, thus allowing an address block to contain a mixture
common term "address object" is used in this specification to cover of addresses and address prefixes. The common term "address object"
both of these; note that an address object in an address block always is used in this specification to cover both of these; note that an
includes the prefix length, if present. address object in 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. There are no semantics associated with head, mid form head:mid:tail. There are no semantics associated with head, mid
or tail; this representation is solely to allow aggregation of or tail; this representation is solely to allow aggregation of
addresses, which often have common parts (e.g. common prefixes or addresses, which often have common parts (e.g. common prefixes or
multiple IPv6 addresses on the same interface). An address block multiple IPv6 addresses on the same interface). An address block
contains an ordered set of addresses all sharing the same head and contains an ordered set of addresses all sharing the same head and
the same tail, but having individual mids. Independently, head and the same tail, but having individual mids. Independently, head and
tail may be empty, allowing for representation of address objects tail may be empty, allowing for representation of address objects
which do not have common heads or common tails. Detailed examples of which do not have common heads or common tails. Detailed examples of
skipping to change at page 12, line 47 skipping to change at page 12, line 38
+--------------+--------------+---------------+---------------------+ +--------------+--------------+---------------+---------------------+
| 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 in Table 1: Interpretation of the ahasfulltail and ahaszerotail flags
<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 in <addr-flags> 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, i.e. each <head> element included is <head- in the address block, i.e. each <head> element included is <head-
length> octets long. length> octets long.
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 common to all the field of the head-length leftmost octets common to all the
skipping to change at page 13, line 38 skipping to change at page 13, line 25
<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, i.e. each <tail> element included is <tail- in the address block, i.e. each <tail> element included is <tail-
length> octets long. length> octets long.
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 flag is set ('1'), otherwise it is a field of the
tail-length rightmost octets common to all the addresses in the tail-length rightmost octets common to all the addresses in the
address block. If the ahaszerotail bit is set ('1') then the address block. If the ahaszerotail flag is set ('1') then the
tail-length rightmost octets of all the addresses in the address tail-length rightmost octets of all the addresses in the address
block are all 0. 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
i.e. each <mid> element included is mid-length octets long. i.e. each <mid> element included is mid-length octets long.
<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. When not omitted, the corresponding address in the address block. When not omitted,
an address block contains exactly <num-addr> <mid> fields. 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 an address prefix. If the ahassingleprelen length, in bits, of an address prefix. If the ahassingleprelen
addr-flag is set ('1') then a single <prefix-length> field is flag is set ('1') then a single <prefix-length> field is included,
included, which contains the prefix length of all addresses in the which contains the prefix length of all addresses in the address
address block. If the ahasmultiprelen addr-flag is set ('1') then block. If the ahasmultiprelen flag is set ('1') then <num-addr>
<num-addr> <prefix-length> fields are included, each of which <prefix-length> fields are included, each of which contains the
contains the prefix length of the corresponding address prefix in prefix length of the corresponding address prefix in the address
the address block (in the same order). Otherwise no <prefix- block (in the same order). Otherwise no <prefix-length> fields
length> fields are present; each address object can be considered are present; each address object can be considered to have a
to have a prefix length equal to 8 * address-length bits. The prefix length equal to 8 * address-length bits. The address block
address block is malformed if any <prefix-length> element has a is malformed if any <prefix-length> element has a value greater
value greater than 8 * address-length. 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 TLV allows the association of an arbitrary attribute with a message
a packet, or with a single address or a contiguous set of addresses or a packet, or with a single address or a contiguous set of
in an address block. The attribute (value) is made up from an addresses in an address block. The attribute (value) is made up from
integer number of consecutive octets. Different attributes have an integer number of consecutive octets. Different attributes have
different types; attributes which are unknown when parsing can be different types; attributes which are unknown when parsing can be
skipped. skipped.
TLVs are grouped in TLV blocks, with all TLVs within a TLV block TLVs are grouped in TLV blocks, with all TLVs within a TLV block
associating attributes with either the packet (for the TLV block in associating attributes with either the packet (for the TLV block in
the packet header), the message (for the TLV block immediately the packet header), the message (for the TLV block immediately
following the message header) or to addresses in the immediately following the message header) or to addresses in the immediately
preceding address block. Individual TLVs in a TLV block immediately preceding address block. Individual TLVs in a TLV block immediately
following an address block can associate attributes to a single following an address block can associate attributes to a single
address, a range of addresses or all addresses in that address block. address, a range of addresses or all addresses in that address block.
skipping to change at page 16, line 7 skipping to change at page 15, line 35
<tlv-flags> is an 8 bit field specifying the interpretation of the <tlv-flags> is an 8 bit field specifying the interpretation of 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 of these tlv-flags MUST be that table MUST NOT be used. Both of these flags MUST be
cleared ('0') 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 tlv-flag serves to specify how the bit 5 (tismultivalue): This flag serves to specify how the
<value> field is interpreted, as specified below. This tlv- <value> field is interpreted, as specified below. This flag
flag MUST be cleared ('0') in packet and message TLVs, if the MUST be cleared ('0') in packet and message TLVs, if the
thasmultiindex tlv-flag is cleared ('0'), or if the thasvalue thasmultiindex flag is cleared ('0'), or if the thasvalue flag
tlv-flag is cleared ('0'). 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 in <tlv-flags> flags
+-----------+------------+--------------+---------------------------+ +-----------+------------+--------------+---------------------------+
| thasvalue | thasextlen | <length> | <value> | | thasvalue | thasextlen | <length> | <value> |
+-----------+------------+--------------+---------------------------+ +-----------+------------+--------------+---------------------------+
| 0 | 0 | not included | not included | | 0 | 0 | not included | not 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 in <tlv- Table 4: Interpretation of the thasvalue and thasextlen flags
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:
skipping to change at page 17, line 39 skipping to change at page 17, line 17
+-----------------+----------------+----------------+---------------+ +-----------------+----------------+----------------+---------------+
| 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 in <tlv-flags> 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 tlv-flag is set ('1') according to Table 4. If the tismultivalue flag is set ('1') then
then <length> MUST be an integral multiple of number-values, and <length> MUST be an integral multiple of number-values, and the
the variable single-length is defined by: variable single-length is defined by:
single-length := <length> / number-values single-length := <length> / number-values
If the tismultivalue tlv-flag is cleared ('0'), then the variable If the tismultivalue 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 tlv-flag is cleared ('0') then inclusive. If the tismultivalue flag is cleared ('0') then the
the whole of this field is associated with each of the indicated whole of this field is associated with each of the indicated
address objects. If the tismultivalue tlv-flag is set ('1') then address objects. If the tismultivalue flag is set ('1') then this
this field is divided equally into number-values fields, each of field is divided equally into number-values fields, each of length
length single-length octets, and these are associated, in order, single-length octets, and these are associated, in order, with the
with the indicated address objects. indicated address objects.
5.4.2. TLV Inclusion and Constraints 5.4.2. TLV Usage
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 any protocol which uses this
specification. specification.
If the appropriate flags (pnouniord for a packet TLV block, mnouniord Any protocol using this specification MUST define appropriate
for a message TLV block or an address block TLV block) are cleared behaviors if this associated information is inconsistent, in
('0'), then the following constraints MUST be respected. These flags particular if two TLVs of the same type but with different values
MUST always be cleared ('0') unless a protocol using this apply to the same entity (packet, message or address) but this is not
specification defines otherwise. Protocols SHOULD only define use of meaningful. The protocol MUST also specify an appropriate processing
these flags when necessary, and then MUST indicate what constraints order for TLVs associated with a given entity.
do apply if each of the indicated flags is set ('1'); each of these
constraints SHOULD be retained unless otherwise necessary.
o TLVs in the same TLV block are sorted in non-descending tlv-
fulltype order.
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.
o TLVs with the same tlv-fulltype associated with the same address
block are sorted in ascending index-start order.
In addition, packet and message TLVs MUST be defined so as to
indicate whether two such TLVs with the same tlv-fulltype are, or are
not, allowed in the same packet or message TLV block, respectively.
Note that the above constrains only the encoding of TLVs in a TLV
block for transmission, and do specifically NOT mandate any given
order of processing or interpretation by a protocol of the TLVs and
the entities to which these are associated.
Respecting the constraints above allows parsing and verification of 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.
The constraints on address block TLVs ensure that encoded information
(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) or if a constraint (including, but not only, those available). If the malformed element is in the packet header then
specified in Section 5.4.2) specified as one which MUST be satisfied, the packet MUST be silently discarded, and contained messages MUST
is not. A protocol using this specification MUST specify the action, NOT be processed and MUST NOT be forwarded. If the malformed element
or choice of actions, to be taken when a packet containing such is contained in a message (i.e. is in the message TLV block, an
elements is received. Typical examples will include discarding any address block, or an address block TLV block) then that message MUST
affected message(s), or discarding the complete packet. be silently discarded; it MUST NOT be processed and MUST NOT be
forwarded.
6. IANA Considerations 6. IANA Considerations
This document introduces four namespaces that require registration: This document introduces four namespaces that require registration:
Message Types, Packet TLV Types, Message TLV Types and Address Block Message Types, Packet TLV Types, Message TLV Types and Address Block
TLV Types. This section specifies IANA registries for these TLV Types. This section specifies IANA registries for these
namespaces, and provides guidance to the Internet Assigned Numbers namespaces, and provides guidance to the Internet Assigned Numbers
Authority regarding registrations in these namespaces. Authority regarding registrations in these namespaces.
The following terms are used with the meanings defined in [BCP26]: The following terms are used with the meanings defined in [BCP26]:
skipping to change at page 20, line 37 skipping to change at page 19, line 37
address block TLVs. The document which requests the registration address block TLVs. The document which requests the registration
of the message type MUST indicate how these message type specific of the message type MUST indicate how these message type specific
TLV types are to be allocated, from any options in [BCP26], and TLV types are to be allocated, from any options in [BCP26], and
any initial allocations. The Designated Expert SHOULD take the any initial allocations. The Designated Expert SHOULD take the
allocation policies specified for these registries into allocation policies specified for these registries into
consideration in reviewing the message type allocation request. consideration in reviewing the message type allocation request.
For the registries for Packet TLV Types, Message TLV Types and For the registries for Packet TLV Types, Message TLV Types and
Address Block TLV Types, the following guidelines apply: Address Block TLV Types, the following guidelines apply:
o These are Hierarchical Allocations, allocation of a type creates a o These are Hierarchical Allocations, i.e. allocation of a type
registry for the extended types corresponding to that type. The creates a registry for the extended types corresponding to that
document which requests the registration of the type MUST indicate type. The document which requests the registration of the type
how these extended types are to be allocated, from any options in MUST indicate how these extended types are to be allocated, from
[BCP26], and any initial allocations. Normally this allocation any options in [BCP26], and any initial allocations. Normally
should also be Expert Review, but with the possible allocation of this allocation should also be Expert Review, but with the
some type extensions as Reserved, Experimental and/or Private. 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 o The request for a TLV type MUST include the specification of the
permitted size, syntax of any internal structure of, and meaning permitted size, syntax of any internal structure of, and meaning
of, the value field (if any) of the TLV. of, the value field (if any) of the TLV.
For the registries for Message TLV Types and Address Block TLV Types, For the registries for Message TLV Types and Address Block TLV Types,
the following additional guidelines apply: the following additional guidelines apply:
o TLV type values 0-127 are common for all message types. TLVs o TLV type values 0-127 are common for all message types. TLVs
which receive registrations from the 0-127 interval SHOULD be which receive registrations from the 0-127 interval SHOULD be
modular in design to allow reuse among protocols. modular in design to allow reuse among protocols.
o TLV type values 128-223 are message type specific TLV type values, o TLV type values 128-223 are message type specific TLV type values,
relevant only in the context of the containing message type. relevant only in the context of the containing message type.
Registration of TLV type values within the 128-223 interval Registration of TLV type values within the 128-223 interval
requires that a registry in the 128-223 interval exists for a requires that a registry in the 128-223 interval exists for a
specific message type value (see Section 6.3.1), and registrations specific message type value (see Section 6.2.1), and registrations
are made in accordance with the allocation policies specified for are made in accordance with the allocation policies specified for
these message type specific registries. Message type specific TLV these message type specific registries. Message type specific TLV
types SHOULD be registered for TLVs which the Designated Expert types SHOULD be registered for TLVs which the Designated Expert
deems too message type specific for registration of a 0-127 value. deems too message type specific for registration of a 0-127 value.
Multiple different TLV definitions MAY be assigned the same TLV Multiple different TLV definitions MAY be assigned the same TLV
type value within the 128-223 interval, given that they are type value within the 128-223 interval, given that they are
associated with different message type specific TLV type associated with different message type specific TLV type
registries. Where possible, existing global TLV definitions and registries. Where possible, existing global TLV definitions and
modular global TLV definitions for registration in the 0-127 range modular global TLV definitions for registration in the 0-127 range
SHOULD be used. SHOULD be used.
6.2. Address Family 6.2. Message Types
A new registry for address families must be created, with initial
assignments and allocation policies as specified in Table 6.
+--------+-----------------------------------+-------------------+
| Family | Description | Allocation Policy |
+--------+-----------------------------------+-------------------+
| 0 | 4 octet IPv4 addresses [RFC791] | |
| 1 | 16 octet IPv6 addresses [RFC2460] | |
| 2-6 | Unassigned | Expert Review |
| 7 | Unassigned | Experimental Use |
+--------+-----------------------------------+-------------------+
Table 6: Address Family
6.3. 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 and allocation policies as specified in Table 7. assignments and allocation policies as specified in Table 6.
+---------+-------------+-------------------+ +---------+-------------+-------------------+
| Type | Description | Allocation Policy | | Type | Description | Allocation Policy |
+---------+-------------+-------------------+ +---------+-------------+-------------------+
| 0-223 | Unassigned | Expert Review | | 0-223 | Unassigned | Expert Review |
| 224-255 | Unassigned | Experimental Use | | 224-255 | Unassigned | Experimental Use |
+---------+-------------+-------------------+ +---------+-------------+-------------------+
Table 7: Message Types Table 6: Message Types
6.3.1. Message Type Specific TLV Registry Creation 6.2.1. Message Type Specific TLV Registry Creation
When a message type is registered then registries MUST be specified When a message type is registered then registries MUST be specified
for both message type specific message TLVs (Table 9) and message for both message type specific message TLVs (Table 8) and message
type specific address block TLVs (Table 11). A document which type specific address block TLVs (Table 10). A document which
creates a message type specific TLV registry MUST also specify the creates a message type specific TLV registry MUST also specify the
mechanism by which message specific TLV types are allocated, from mechanism by which message specific TLV types are allocated, from
among those in [BCP26]. among those in [BCP26].
6.4. Packet TLV Types 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 and allocation policies as specified in Table 8. assignments and allocation policies as specified in Table 7.
+---------+-------------+-------------------+ +---------+-------------+-------------------+
| Type | Description | Allocation Policy | | Type | Description | Allocation Policy |
+---------+-------------+-------------------+ +---------+-------------+-------------------+
| 0-223 | Unassigned | Expert Review | | 0-223 | Unassigned | Expert Review |
| 224-255 | Unassigned | Experimental Use | | 224-255 | Unassigned | Experimental Use |
+---------+-------------+-------------------+ +---------+-------------+-------------------+
Table 8: Packet TLV Types Table 7: Packet TLV Types
6.4.1. Packet TLV Type Extension Registry Creation 6.3.1. Packet TLV Type Extension Registry Creation
When a packet TLV type is registered 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 [BCP26]. extensions are allocated, from among those in [BCP26].
6.5. Message TLV Types 6.4. Message TLV Types
A new registry for message type independent message TLV types must be A new registry for message type independent message TLV types must be
created, with initial assignments and allocation policies as created, with initial assignments and allocation policies as
specified in Table 9. specified in Table 8.
+---------+-----------------------+------------------------+ +---------+-----------------------+-----------------------+
| Type | Description | Allocation Policy | | Type | Description | Allocation Policy |
+---------+-----------------------+------------------------+ +---------+-----------------------+-----------------------+
| 0-127 | Unassigned | Expert Review | | 0-127 | Unassigned | Expert Review |
| 128-223 | Message Type Specific | Reserved, see Table 10 | | 128-223 | Message Type Specific | Reserved, see Table 9 |
| 224-255 | Unassigned | Experimental Use | | 224-255 | Unassigned | Experimental Use |
+---------+-----------------------+------------------------+ +---------+-----------------------+-----------------------+
Table 9: Message TLV Types Table 8: Message TLV Types
Message TLV Types 128-223 are reserved for message type specific Message TLV Types 128-223 are reserved for message type specific
Message TLVs, for which a new registry is created with the Message TLVs, for which a new registry is created with the
registration of a message type, and with initial assignments and registration of a message type, and with initial assignments and
allocation policies as specified in Table 10. allocation policies as specified in Table 9.
+---------+-----------------------------+-------------------+ +---------+-----------------------------+-------------------+
| Type | Description | Allocation Policy | | Type | Description | Allocation Policy |
+---------+-----------------------------+-------------------+ +---------+-----------------------------+-------------------+
| 0-127 | Common to all Message Types | Reserved | | 0-127 | Common to all Message Types | Reserved |
| 128-223 | Message Type Specific | See Below | | 128-223 | Message Type Specific | See Below |
| 224-255 | Common to all Message Types | Reserved | | 224-255 | Common to all Message Types | Reserved |
+---------+-----------------------------+-------------------+ +---------+-----------------------------+-------------------+
Table 10: Message Specific Message TLV Types Table 9: Message Specific Message TLV Types
Allocation policies for message type specific message TLV types MUST Allocation policies for message type specific message TLV types MUST
be specified when creating the registry associated with the be specified when creating the registry associated with the
containing message type, see Section 6.3.1. containing message type, see Section 6.2.1.
6.5.1. Message TLV Type Extension Registry Creation 6.4.1. Message TLV Type Extension Registry Creation
If a message TLV type is registered then a new registry for type 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 [BCP26]. extensions are allocated, from among those in [BCP26].
6.6. Address Block TLV Types 6.5. Address Block TLV Types
A new registry for message type independent address block TLV types A new registry for message type independent address block TLV types
must be created, with initial assignments and allocation policies as must be created, with initial assignments and allocation policies as
specified in Table 11. specified in Table 10.
+---------+-----------------------+------------------------+ +---------+-----------------------+------------------------+
| Type | Description | Allocation Policy | | Type | Description | Allocation Policy |
+---------+-----------------------+------------------------+ +---------+-----------------------+------------------------+
| 0-127 | Unassigned | Expert Review | | 0-127 | Unassigned | Expert Review |
| 128-223 | Message Type Specific | Reserved, see Table 12 | | 128-223 | Message Type Specific | Reserved, see Table 11 |
| 224-255 | Unassigned | Experimental Use | | 224-255 | Unassigned | Experimental Use |
+---------+-----------------------+------------------------+ +---------+-----------------------+------------------------+
Table 11: Address Block TLV Types Table 10: Address Block TLV Types
Address Block TLV Types 128-223 are reserved for message type Address Block TLV Types 128-223 are reserved for message type
specific Address Block TLVs, for which a new registry is created with specific Address Block TLVs, for which a new registry is created with
the registration of a message type, and with initial assignments and the registration of a message type, and with initial assignments and
allocation policies as specified in Table 12. allocation policies as specified in Table 11.
+---------+-----------------------------+-------------------+ +---------+-----------------------------+-------------------+
| Type | Description | Allocation Policy | | Type | Description | Allocation Policy |
+---------+-----------------------------+-------------------+ +---------+-----------------------------+-------------------+
| 0-127 | Common to all Message Types | Reserved | | 0-127 | Common to all Message Types | Reserved |
| 128-223 | Message Type Specific | See Below | | 128-223 | Message Type Specific | See Below |
| 224-255 | Common to all Message Types | Reserved | | 224-255 | Common to all Message Types | Reserved |
+---------+-----------------------------+-------------------+ +---------+-----------------------------+-------------------+
Table 12: Message Specific Address Block TLV Types Table 11: Message Specific Address Block TLV Types
Allocation policies for message type specific address block TLV types Allocation policies for message type specific address block TLV types
MUST be specified when creating the registry associated with the MUST be specified when creating the registry associated with the
containing message type, see Section 6.3.1. containing message type, see Section 6.2.1.
6.6.1. Address Block TLV Type Extension Registry Creation 6.5.1. Address Block TLV Type Extension Registry Creation
When an address block TLV type is registered then a new registry for 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 a message TLV type MUST also specify the mechanism by which defines a message TLV type MUST also specify the mechanism by which
its type extensions are allocated, from among those in [BCP26]. its type extensions are allocated, from among those in [BCP26].
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
skipping to change at page 26, line 38 skipping to change at page 25, line 9
specification. specification.
In either case, the protocol MUST define the encrypted TLV type, as 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 well as the format of the encrypted data block contained in the value
field of the TLV. field of the TLV.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC791] Postel (ed), J., "Internet Protocol", RFC 791,
September 1981.
[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.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version
6 (IPv6) Specification", RFC 2460, December 1998.
[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.
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", RFC 5226, an IANA Considerations Section in RFCs", RFC 5226,
BCP 26, May 2008. BCP 26, May 2008.
[SingleUNIX] IEEE Std 1003.1, The Open Group, and ISO/IEC JTC [SingleUNIX] IEEE Std 1003.1, The Open Group, and ISO/IEC JTC
1/SC22/WG15, "Single UNIX Specification, Version 3, 1/SC22/WG15, "Single UNIX Specification, Version 3,
2004 Edition", April 2004. 2004 Edition", April 2004.
skipping to change at page 34, line 10 skipping to change at page 32, line 19
then <tlv-flags> would also have thasextlen set and have value 24. 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. normatively specified in Section 5.
Bits labeled Rsv or R should be cleared ('0'). Bits labeled C or M Bits labeled Rsv should be cleared ('0'). Bits labeled M may be
may be cleared ('0') or set ('1'). Bits labeled MAF define the cleared ('0') or set ('1').
message address family. Currently defined options are
+-+-+-+ +-+-+-+
|0|0|0| and |0|0|1|
+-+-+-+ +-+-+-+
for IPv4 and IPv6 addresses, respectively.
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 the flags field in the first octet. The packet may include any by the flags field in the first octet. The packet may include any
number (zero or more) of Messages. The number of Messages is number (zero or more) of Messages. The number of Messages is
determined from when the packet is exhausted, given the packet length determined from when the packet is exhausted, given the packet length
from the network layer. from the network layer.
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|C|R| | |0|0|0|0|0|0|Rsv| |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| Message | | 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|1|0|C|R| Packet Sequence Number | | |0|0|0|0|1|0|Rsv| Packet Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Message | | Message |
| | | |
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
: ... : : ... :
| | | |
skipping to change at page 36, line 7 skipping to change at page 34, 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|1|C|R| | |0|0|0|0|0|1|Rsv| |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| | | |
| Packet TLV Block | | Packet TLV Block |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| Message | | Message |
| | | |
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+
skipping to change at page 37, line 7 skipping to change at page 35, 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|1|1|C|R| Packet Sequence Number | | |0|0|0|0|1|1|Rsv| Packet Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Packet TLV Block | | Packet TLV Block |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Message | | Message |
| | | |
skipping to change at page 37, line 38 skipping to change at page 35, line 38
| 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 (flags) octet. The length of the Message Body is by their second (flags) octet. The length of the Message Body is
determined using the Message Size field, which is the combined length determined using the Message Size field, which is the combined length
of all the fields shown. of all the fields shown. The field labeled MAL defines the length of
all addresses (including the Originator Address, if present, and all
addresses in address blocks) in octets, as one more than the value in
the field.
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 |0|0|0|0|C| MAF | Message Size | | Message Type |0|0|0|0| MAL | 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 |1|0|0|0|C| MAF | Message Size | | Message Type |1|0|0|0| MAL | 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 |0|1|0|0|C| MAF | Message Size | | Message Type |0|1|0|0| MAL | 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 |1|1|0|0|C| MAF | Message Size | | Message Type |1|1|0|0| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | | | Hop Limit | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 39, line 4 skipping to change at page 37, line 18
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |0|0|1|0|C| MAF | Message Size | | Message Type |0|0|1|0| MAL | 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 |1|0|1|0|C| MAF | Message Size | | Message Type |1|0|1|0| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | | | Hop Count | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 39, line 31 skipping to change at page 38, line 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |0|1|1|0|C| MAF | Message Size | | Message Type |0|1|1|0| MAL | 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 |1|1|1|0|C| MAF | Message Size | | Message Type |1|1|1|0| MAL | 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 |0|0|0|1|C| MAF | Message Size | | Message Type |0|0|0|1| MAL | 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 |1|0|0|1|C| MAF | Message Size | | Message Type |1|0|0|1| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Sequence Number | | | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 41, line 4 skipping to change at page 39, line 19
| 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 |0|1|0|1|C| MAF | Message Size | | Message Type |0|1|0|1| MAL | 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 |1|1|0|1|C| MAF | Message Size | | Message Type |1|1|0|1| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Message Sequence Number | | | Hop Limit | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 41, line 33 skipping to change at page 40, line 4
| 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 |0|0|1|1|C| MAF | Message Size | | Message Type |0|0|1|1| MAL | 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 |1|0|1|1|C| MAF | Message Size | | Message Type |1|0|1|1| MAL | 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 |0|1|1|1|C| MAF | Message Size | | Message Type |0|1|1|1| MAL | 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 |1|1|1|1|C| MAF | Message Size | | Message Type |1|1|1|1| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | Message Sequence Number | | Hop Limit | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 57, line 20 skipping to change at page 55, line 47
example is specifically not constructed to exhibit maximum message or example is specifically not constructed to exhibit maximum message or
packet size reduction. Appendix D contains illustrations of all packet size reduction. Appendix D contains illustrations of all
syntactical elements. syntactical elements.
The packet header has the phasseqnum flag set of its flags field set 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 (value 8), and hence has a Packet Sequence Number, but no packet TLV
block. block.
The packet contains a single message with length 54 octets. This 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
flags of its five bit flags field set (value 30), and hence includes flags of its four bit flags field set (value 15), and hence includes
an Originator Address, a Hop Limit, a Hop Count and a Message an Originator Address, a Hop Limit, a Hop Count and a Message
Sequence Number (which is type independent). Its three bit message Sequence Number (which is type independent). Its four bit message
address family field has value 0 and hence addresses in the message address length field has value 3 and hence addresses in the message
are IPv4 addresses, with address length four octets. The message has have length four octets, here being IPv4 addresses. The message has
a message TLV block with content length 9 octets, containing a single a message TLV block with content length 9 octets, containing a single
message TLV. This TLV has the thasvalue flag of its flags octet set message TLV. This TLV has the thasvalue flag of its flags octet set
(value 16), and hence contains a Value field, with preceding value (value 16), and hence contains a Value field, with preceding value
length 6 octets. The message then has two address blocks each with a length 6 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 flags of its flags octet set (value ahaszerotail and ahassingleprelen flags of its flags octet set (value
48), and hence has no head (head-length is zero octets). It has a 48), and hence has no head (head-length is zero octets). It has a
tail-length of 2 octets, hence mid-length is two octets. The two tail-length of 2 octets, hence mid-length is two octets. The two
skipping to change at page 58, line 10 skipping to change at page 57, line 10
thasmultiindex flag of its flags octet set (value 32), and hence has thasmultiindex flag of its flags octet set (value 32), and hence has
no value length or value fields. It has two index fields (Index no value length or value fields. It has two index fields (Index
Start and Index Stop), which indicate those addresses this TLV 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 1 0 0 0| Packet Sequence Number | Message Type | |0 0 0 0 1 0 0 0| Packet Sequence Number | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 | |1 1 1 1 0 0 1 1|0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 0| Orig Addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address (cont) | Hop Limit | | Originator Address (cont) | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | Message Sequence Number |0 0 0 0 0 0 0 0| | Hop Count | Message Sequence Number |0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0 1| TLV Type |0 0 0 1 0 0 0 0|0 0 0 0 0 1 1 0| |0 0 0 0 1 0 0 1| TLV Type |0 0 0 1 0 0 0 0|0 0 0 0 0 1 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (cont) |0 0 0 0 0 0 1 0|0 0 1 1 0 0 0 0| | Value (cont) |0 0 0 0 0 0 1 0|0 0 1 1 0 0 0 0|
skipping to change at page 59, line 9 skipping to change at page 58, line 9
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, o Satoh Hiroki, Hitachi SDL, Japan, <hiroki.satoh.yj@hitachi.com>
<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, o Monden Kazuya, Hitachi SDL, Japan, <kazuya.monden.vw@hitachi.com>
<kazuya.monden.vw@sdl.hitachi.co.jp>
Appendix G. Acknowledgments Appendix G. Acknowledgments
The authors would like to acknowledge the team behind OLSR [RFC3626], The authors would like to acknowledge the team behind OLSR [RFC3626],
including Anis Laouiti (INT, France), Pascale Minet, Laurent Viennot including Anis Laouiti (INT, France), Pascale Minet, Laurent Viennot
(both 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. Elwyn Research in Engineering, Pakistan) for their contributions. Elwyn
Davies (Folly Consulting, UK), Lars Eggert (Nokia, Finland), Chris Davies (Folly Consulting, UK), Lars Eggert (Nokia, Finland), Chris
Newman (Sun Microsystems, USA), Tim Polk (NIST, USA), and Magnus Newman (Sun Microsystems, USA), Tim Polk (NIST, USA), and Magnus
Westerlund (Ericsson, Sweden) all provided detailed reviews and Westerlund (Ericsson, Sweden) all provided detailed reviews and
skipping to change at page 59, line 48 skipping to change at page 58, line 46
o Ian Chakeres (Motorola) o Ian Chakeres (Motorola)
o Alan Cullen (BAE Systems) o Alan Cullen (BAE Systems)
o Ulrich Herberg (LIX) o Ulrich Herberg (LIX)
o Joe Macker (NRL) o Joe Macker (NRL)
o Yasunori Owada (Niigata University) o Yasunori Owada (Niigata University)
o Henning Rogge (FGAN)
o Charlie E. Perkins (WiChorus) o Charlie E. Perkins (WiChorus)
o Andreas Schjonhaug (LIX) o Andreas Schjonhaug (LIX)
and the entire IETF MANET working group. 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
 End of changes. 114 change blocks. 
297 lines changed or deleted 224 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/