draft-ietf-manet-packetbb-15.txt   draft-ietf-manet-packetbb-16.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 20, 2009 BAE Systems Advanced Technology Expires: March 30, 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 16, 2008 September 26, 2008
Generalized MANET Packet/Message Format Generalized MANET Packet/Message Format
draft-ietf-manet-packetbb-15 draft-ietf-manet-packetbb-16
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 20, 2009. This Internet-Draft will expire on March 30, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Packets . . . . . . . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.4.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.4.2. TLV Inclusion and Constraints . . . . . . . . . . . . 18 5.4.2. TLV Inclusion and Constraints . . . . . . . . . . . . 18
5.5. Malformed Elements . . . . . . . . . . . . . . . . . . . . 18 5.5. Malformed Elements . . . . . . . . . . . . . . . . . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 19 6.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 19
6.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 21 6.2. Address Family . . . . . . . . . . . . . . . . . . . . . . 21
6.2.1. Message Type Specific TLV Registry Creation . . . . . 21 6.3. Message Types . . . . . . . . . . . . . . . . . . . . . . 22
6.3. Packet TLV Types . . . . . . . . . . . . . . . . . . . . . 22 6.3.1. Message Type Specific TLV Registry Creation . . . . . 22
6.3.1. Packet TLV Type Extension Registry Creation . . . . . 22 6.4. Packet TLV Types . . . . . . . . . . . . . . . . . . . . . 22
6.4. Message TLV Types . . . . . . . . . . . . . . . . . . . . 22 6.4.1. Packet TLV Type Extension Registry Creation . . . . . 22
6.4.1. Message TLV Type Extension Registry Creation . . . . . 23 6.5. Message TLV Types . . . . . . . . . . . . . . . . . . . . 23
6.5. Address Block TLV Types . . . . . . . . . . . . . . . . . 23 6.5.1. Message TLV Type Extension Registry Creation . . . . . 23
6.5.1. Address Block TLV Type Extension Registry Creation . . 24 6.6. Address Block TLV Types . . . . . . . . . . . . . . . . . 24
6.6.1. Address Block TLV Type Extension Registry Creation . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
7.1. Authentication and Integrity Suggestions . . . . . . . . . 24 7.1. Authentication and Integrity Suggestions . . . . . . . . . 25
7.2. Confidentiality Suggestions . . . . . . . . . . . . . . . 25 7.2. Confidentiality Suggestions . . . . . . . . . . . . . . . 25
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.1. Normative References . . . . . . . . . . . . . . . . . . . 26 8.1. Normative References . . . . . . . . . . . . . . . . . . . 26
8.2. Informative References . . . . . . . . . . . . . . . . . . 26 8.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A. Multiplexing and Demultiplexing . . . . . . . . . . . 26 Appendix A. Multiplexing and Demultiplexing . . . . . . . . . . . 27
Appendix B. Intended Usage . . . . . . . . . . . . . . . . . . . 27 Appendix B. Intended Usage . . . . . . . . . . . . . . . . . . . 28
Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 28 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 29
C.1. Address Block Examples . . . . . . . . . . . . . . . . . . 28 C.1. Address Block Examples . . . . . . . . . . . . . . . . . . 29
C.2. TLV Examples . . . . . . . . . . . . . . . . . . . . . . . 31 C.2. TLV Examples . . . . . . . . . . . . . . . . . . . . . . . 31
Appendix D. Illustrations . . . . . . . . . . . . . . . . . . . . 33 Appendix D. Illustrations . . . . . . . . . . . . . . . . . . . . 34
D.1. Packet . . . . . . . . . . . . . . . . . . . . . . . . . . 33 D.1. Packet . . . . . . . . . . . . . . . . . . . . . . . . . . 34
D.2. Message . . . . . . . . . . . . . . . . . . . . . . . . . 37 D.2. Message . . . . . . . . . . . . . . . . . . . . . . . . . 37
D.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 43 D.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 43
D.4. Address Block . . . . . . . . . . . . . . . . . . . . . . 44 D.4. Address Block . . . . . . . . . . . . . . . . . . . . . . 44
D.5. TLV Block . . . . . . . . . . . . . . . . . . . . . . . . 51 D.5. TLV Block . . . . . . . . . . . . . . . . . . . . . . . . 51
D.6. TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 D.6. TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Appendix E. Complete Example . . . . . . . . . . . . . . . . . . 57 Appendix E. Complete Example . . . . . . . . . . . . . . . . . . 57
Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 58 Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 58
Appendix G. Acknowledgments . . . . . . . . . . . . . . . . . . . 59 Appendix G. Acknowledgments . . . . . . . . . . . . . . . . . . . 59
1. Introduction 1. Introduction
skipping to change at page 5, line 38 skipping to change at page 5, line 38
Variables are introduced into the specification solely as a means to Variables are introduced into the specification solely as a means to
clarify the description. The following two notations are used: clarify the description. The following two notations are used:
<foo> - If <foo> is an unsigned integer field then <foo> is also <foo> - If <foo> is an unsigned integer field then <foo> is also
used to represent the value of that field. used to represent the value of that field.
bar - A variable, usually obtained through calculations based on the bar - A variable, usually obtained through calculations based on the
value(s) of element(s). value(s) of element(s).
The following variable is defined:
address-length - A variable whose value is the length of an address
in octets, it is 4 if using IPv4, or 16 if using IPv6.
2.2. Terminology 2.2. Terminology
This document uses the following terminology: This document uses the following terminology:
Packet - The top level entity in this specification. A packet Packet - The top level entity in this specification. A packet
contains a packet header and zero or more messages. contains a packet header and zero or more messages.
Message - The fundamental entity carrying protocol information, in Message - The fundamental entity carrying protocol information, in
the form of address objects and TLVs. the form of address objects and TLVs.
Address - A number of octets of the same length as the source IP Address - A number of octets that make up an address of the length
address in the IP datagram carrying the packet. The meaning of an indicated by the encapsulating message header. The meaning of an
address is defined by the protocol using this specification. address is defined by the protocol using this specification.
Address Prefix- An address plus a prefix length, with the prefix Address Prefix- An address plus a prefix length, with the prefix
length being a number of address bits measured from the left/most length being a number of address bits measured from the left/most
significant end of the address. significant end of the address.
Address Object - Either an address, or an address prefix, as Address Object - Either an address, or an address prefix, as
specified in an address block in this specification. specified in an address block in this specification.
TLV - A Type-Length-Value structure. This is a generic way in which TLV - A Type-Length-Value structure. This is a generic way in which
skipping to change at page 7, line 44 skipping to change at page 7, line 37
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 provides syntactical specification of a packet, This section normatively provides syntactical specification of a
represented by the element <packet> and the elements from which it is packet, represented by the element <packet> and the elements from
composed. The specification is given using the notation in which it is composed. The specification is given using the notation
Section 2.1. Illustrations of specified elements are given in in Section 2.1.
Appendix D.
Graphical illustrations of the layout of specified elements are given
in Appendix D, a graphical illustration of a complete example
(packet, message with address blocks, 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 9, line 41 skipping to change at page 9, line 32
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-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 an 8 bit field, specifying the interpretation of the <msg-flags> is a 5 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>.
skipping to change at page 10, line 37 skipping to change at page 10, line 29
is included in the <msg-header>. is included in the <msg-header>.
bit 4 (mnouniord): If cleared ('0'), then the message TLV block bit 4 (mnouniord): If cleared ('0'), then the message TLV block
and all address TLV blocks in the message MUST conform to the and all address TLV blocks in the message MUST conform to the
constraints in Section 5.4.2. If set ('1'), then the message constraints in Section 5.4.2. If set ('1'), then the message
TLV block and all address TLV blocks in the message are not TLV block and all address TLV blocks in the message are not
subject to the constraints in Section 5.4.2. Additional subject to the constraints in Section 5.4.2. Additional
constraints MAY be imposed by a protocol using this constraints MAY be imposed by a protocol using this
specification. specification.
bit 5-7: Are RESERVED, and SHOULD each be cleared ('0') on <msg-addr-family> is a 3 bit unsigned integer field, specifying the
transmission, and SHOULD be ignored on reception. 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
address in octets, of the address family specified in <msg-addr-
family> as interpreted according to the IANA registry in
Section 6.2. For example, address-length is 4 if the address
family is IPv4, or 16 if the address family is IPv6.
<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 msg-flag is cleared
('0'), otherwise is an identifier with length equal to address- ('0'), otherwise is an identifier with length equal to address-
length, which can serve to uniquely identify the MANET router that length, 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 msg-flag is cleared
skipping to change at page 11, line 16 skipping to change at page 11, line 21
('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 msg-flag is cleared
('0'), otherwise is a 16 bit unsigned integer field, which can ('0'), otherwise is a 16 bit unsigned integer field, which can
contain a sequence number, generated by the message's originator contain a sequence number, generated by the message's originator
MANET router. MANET router.
5.3. Address Blocks 5.3. Address Blocks
An address block can specify one or more addresses. It can also An address block can specify one or more addresses, all of which will
specify prefix lengths that can be applied to all addresses in the each be of the address family as specified by the <msg-addr-family>
address block. This allows an address block to specify either in the <msg-header> of the message containing the address block. An
addresses or address prefixes. A protocol may specify that an address block can also specify prefix lengths that can be applied to
address with a maximum prefix length (equal to the address length, in all addresses in the address block, if appropriate. This allows an
bits) is considered to be an address, rather than an address prefix, address block to specify either addresses or address prefixes. A
thus allowing an address block to contain a mixture of addresses and protocol may specify that an address with a maximum prefix length
address prefixes. The common term "address object" is used in this (equal to the address length, in bits) is considered to be an
specification to cover both of these; note that an address object in address, rather than an address prefix, thus allowing an address
an address block always includes the prefix length, if present. block to contain a mixture of addresses and address prefixes. The
common term "address object" is used in this specification to cover
both of these; note that an address object in an address block always
includes the prefix length, if present.
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 39 skipping to change at page 12, line 47
+--------------+--------------+---------------+---------------------+ +--------------+--------------+---------------+---------------------+
| 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 addr- Table 1: Interpretation of the ahasfulltail and ahaszerotail bits in
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
addr-flags bits in <addr-flags>
<head-length> if present is an 8 bit unsigned integer field, which <head-length> if present is an 8 bit unsigned integer field, which
contains the number of octets in the head of all of the addresses contains the number of octets in the head of all of the addresses
in the address block, 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
skipping to change at page 16, line 17 skipping to change at page 16, line 32
+-----------------+----------------+---------------+--------------+ +-----------------+----------------+---------------+--------------+
| 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
tlv-flags bits in <tlv-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 tlv-flags Table 4: Interpretation of the thasvalue and thasextlen bits in <tlv-
flags>
<tlv-type-ext> is an 8 bit unsigned integer field, specifying an <tlv-type-ext> is an 8 bit unsigned integer field, specifying an
extension of the TLV type, specific to the TLV type and kind (i.e. extension of the TLV type, specific to the TLV type and kind (i.e.
packet, message, or address block TLV). packet, message, or address block TLV).
tlv-type-ext is a variable, defined to equal <tlv-type-ext> if tlv-type-ext is a variable, defined to equal <tlv-type-ext> if
present, or 0 otherwise. present, or 0 otherwise.
tlv-fulltype is a variable, defined by: tlv-fulltype is a variable, defined by:
skipping to change at page 17, line 21 skipping to change at page 17, line 39
+-----------------+----------------+----------------+---------------+ +-----------------+----------------+----------------+---------------+
| 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
tlv-flags bits in <tlv-flags>
number-values is a variable, defined by: number-values is a variable, defined by:
number-values := index-stop - index-start + 1 number-values := index-stop - index-start + 1
<length> is omitted or is an 8 or 16 bit unsigned integer field <length> is omitted or is an 8 or 16 bit unsigned integer field
according to Table 4. If the tismultivalue tlv-flag is set ('1') according to Table 4. If the tismultivalue tlv-flag is set ('1')
then <length> MUST be an integral multiple of number-values, and then <length> MUST be an integral multiple of number-values, and
the variable single-length is defined by: the variable single-length is defined by:
skipping to change at page 21, line 4 skipping to change at page 21, line 18
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.2.1), and registrations specific message type value (see Section 6.3.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. Message Types 6.2. Address Family
A new registry for message types must be created, with initial A new registry for address families must be created, with initial
assignments and allocation policies as specified in Table 6. 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
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 6: Message Types Table 7: Message Types
6.2.1. Message Type Specific TLV Registry Creation 6.3.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 8) and message for both message type specific message TLVs (Table 9) and message
type specific address block TLVs (Table 10). A document which type specific address block TLVs (Table 11). 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.3. Packet TLV Types 6.4. 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 7. assignments and allocation policies as specified in Table 8.
+---------+-------------+-------------------+ +---------+-------------+-------------------+
| 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: Packet TLV Types Table 8: Packet TLV Types
6.3.1. Packet TLV Type Extension Registry Creation 6.4.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.4. Message TLV Types 6.5. 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 8. specified in Table 9.
+---------+-----------------------+-----------------------+ +---------+-----------------------+------------------------+
| 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 9 | | 128-223 | Message Type Specific | Reserved, see Table 10 |
| 224-255 | Unassigned | Experimental Use | | 224-255 | Unassigned | Experimental Use |
+---------+-----------------------+-----------------------+ +---------+-----------------------+------------------------+
Table 8: Message TLV Types Table 9: 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 9. allocation policies as specified in Table 10.
+---------+-----------------------------+-------------------+ +---------+-----------------------------+-------------------+
| 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 9: Message Specific Message TLV Types Table 10: 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.2.1. containing message type, see Section 6.3.1.
6.4.1. Message TLV Type Extension Registry Creation 6.5.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.5. Address Block TLV Types 6.6. 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 10. specified in Table 11.
+---------+-----------------------+------------------------+ +---------+-----------------------+------------------------+
| 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 11 | | 128-223 | Message Type Specific | Reserved, see Table 12 |
| 224-255 | Unassigned | Experimental Use | | 224-255 | Unassigned | Experimental Use |
+---------+-----------------------+------------------------+ +---------+-----------------------+------------------------+
Table 10: Address Block TLV Types Table 11: 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 11. allocation policies as specified in Table 12.
+---------+-----------------------------+-------------------+ +---------+-----------------------------+-------------------+
| 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 11: Message Specific Address Block TLV Types Table 12: 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.2.1. containing message type, see Section 6.3.1.
6.5.1. Address Block TLV Type Extension Registry Creation 6.6.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 16 skipping to change at page 26, line 38
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.
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version
an IANA Considerations Section in RFCs", RFC 5226, 6 (IPv6) Specification", RFC 2460, December 1998.
BCP 26, May 2008.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", RFC 5226,
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.
8.2. Informative References 8.2. Informative References
[RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State
Routing Protocol", RFC 3626, October 2003. Routing Protocol", RFC 3626, October 2003.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
skipping to change at page 33, line 31 skipping to change at page 34, line 11
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 or R should be cleared ('0'). Bits labeled C or M
may be cleared ('0') or set ('1'). may be cleared ('0') or set ('1'). Bits labeled MAF define the
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
skipping to change at page 37, line 43 skipping to change at page 37, line 43
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.
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| Rsv | Message Size | | Message Type |0|0|0|0|C| MAF | 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| Rsv | Message Size | | Message Type |1|0|0|0|C| MAF | 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| Rsv | Message Size | | Message Type |0|1|0|0|C| MAF | 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| Rsv | Message Size | | Message Type |1|1|0|0|C| MAF | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | | | Hop Limit | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|0|1|0|C| Rsv | Message Size | | Message Type |0|0|1|0|C| MAF | 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| Rsv | Message Size | | Message Type |1|0|1|0|C| MAF | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | | | Hop Count | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|1|1|0|C| Rsv | Message Size | | Message Type |0|1|1|0|C| MAF | 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| Rsv | Message Size | | Message Type |1|1|1|0|C| MAF | 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| Rsv | Message Size | | Message Type |0|0|0|1|C| MAF | 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| Rsv | Message Size | | Message Type |1|0|0|1|C| MAF | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Sequence Number | | | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|1|0|1|C| Rsv | Message Size | | Message Type |0|1|0|1|C| MAF | 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| Rsv | Message Size | | Message Type |1|1|0|1|C| MAF | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Message Sequence Number | | | Hop Limit | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|0|1|1|C| Rsv | Message Size | | Message Type |0|0|1|1|C| MAF | 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| Rsv | Message Size | | Message Type |1|0|1|1|C| MAF | 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| Rsv | Message Size | | Message Type |0|1|1|1|C| MAF | 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| Rsv | Message Size | | Message Type |1|1|1|1|C| MAF | 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 7 skipping to change at page 57, line 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Value | | Value |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Appendix E. Complete Example Appendix E. Complete Example
The following example packet, using IPv4 addresses (hence address- The following example packet is included with the intent to exemplify
length is four octets) is included with the intent to exemplify how how packet and message headers are constructed, and how addresses and
packet and message headers are constructed, and how addresses and
attributes are encoded using address blocks and TLV blocks. This attributes are encoded using address blocks and TLV blocks. This
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 flags octet set (value 240), and hence includes an flags of its five bit flags field set (value 30), and hence includes
Originator Address, a Hop Limit, a Hop Count and a Message Sequence an Originator Address, a Hop Limit, a Hop Count and a Message
Number (which is type independent). The message has a message TLV Sequence Number (which is type independent). Its three bit message
block with content length 9 octets, containing a single message TLV. address family field has value 0 and hence addresses in the message
This TLV has the thasvalue flag of its flags octet set (value 16), are IPv4 addresses, with address length four octets. The message has
and hence contains a Value field, with preceding value length 6 a message TLV block with content length 9 octets, containing a single
octets. The message then has two address blocks each with a message TLV. This TLV has the thasvalue flag of its flags octet set
(value 16), and hence contains a Value field, with preceding value
length 6 octets. The message then has two address blocks each with a
following address 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
tail octets of each address are not included (since ahaszerotail is tail octets of each address are not included (since ahaszerotail is
set) and have value zero. The address block has a single Prefix set) and have value zero. The address block has a single Prefix
Length. The following address TLV block is empty (content length 0 Length. The following address TLV block is empty (content length 0
octets). octets).
skipping to change at page 59, line 23 skipping to change at page 59, line 23
o Monden Kazuya, Hitachi SDL, Japan, o Monden Kazuya, Hitachi SDL, Japan,
<kazuya.monden.vw@sdl.hitachi.co.jp> <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
Davis (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
insightful comments. insightful comments.
The authors would like to gratefully acknowledge the following people The authors would like to gratefully acknowledge the following people
for intense technical discussions, early reviews and comments on the for intense technical discussions, early reviews and comments on the
specification and its components (listed alphabetically): specification and its components (listed alphabetically):
o Brian Adamson (NRL) o Brian Adamson (NRL)
 End of changes. 78 change blocks. 
117 lines changed or deleted 160 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/