doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc7631.txt b/doc/rfc/rfc7631.txt
new file mode 100644
index 0000000..65d6536
--- /dev/null
+++ b/doc/rfc/rfc7631.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       C. Dearlove
+Request for Comments: 7631                               BAE Systems ATC
+Updates: 5444                                                 T. Clausen
+Category: Standards Track                       LIX, Ecole Polytechnique
+ISSN: 2070-1721                                           September 2015
+
+
+            TLV Naming in the Mobile Ad Hoc Network (MANET)
+                   Generalized Packet/Message Format
+
+Abstract
+
+   This document reorganizes the naming of already-allocated TLV (type-
+   length-value) types and type extensions in the "Mobile Ad hoc NETwork
+   (MANET) Parameters" registries defined by RFC 5444 to use names
+   appropriately.  It has no consequences in terms of any protocol
+   implementation.
+
+   This document also updates the Expert Review guidelines in RFC 5444,
+   so as to establish a policy for consistent naming of future TLV type
+   and type extension allocations.  It makes no other changes to
+   RFC 5444.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7631.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dearlove & Clausen           Standards Track                    [Page 1]
+
+RFC 7631                       TLV Naming                 September 2015
+
+
+Copyright Notice
+
+   Copyright (c) 2015 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Terminology .....................................................4
+   3. IANA Considerations .............................................4
+      3.1. Expert Review: Evaluation Guidelines .......................5
+      3.2. Updated IANA Registries ....................................6
+   4. Security Considerations ........................................13
+   5. References .....................................................13
+      5.1. Normative References ......................................13
+      5.2. Informative References ....................................14
+   Acknowledgments ...................................................15
+   Authors' Addresses ................................................15
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dearlove & Clausen           Standards Track                    [Page 2]
+
+RFC 7631                       TLV Naming                 September 2015
+
+
+1.  Introduction
+
+   This document reorganizes and rationalizes the naming of TLVs (type-
+   length-value structures) defined by [RFC5444] and recorded by IANA in
+   the following subregistries of the "Mobile Ad hoc NETwork (MANET)
+   Parameters" registry: "Packet TLV Types", "Message TLV Types", and
+   "Address Block TLV Types".
+
+   This document reorganizes the naming of already-allocated Packet,
+   Message, and Address Block TLV types, and their corresponding type
+   extensions.  It also updates the corresponding IANA registries.
+
+   TLVs have a type (one octet) and a type extension (one octet) that
+   together form a full type (of two octets).  A TLV may omit the type
+   extension when it is zero.  However, that applies only to its
+   representation; it still has a type extension of zero.  A TLV type
+   defines an IANA registry of type extensions for that type.
+
+   There have been two forms of TLV allocation.
+
+   The first, but less common, form of allocation has been that
+   allocation of the TLV type has defined (but not necessarily
+   allocated) all the type extensions for that TLV type.  This applies,
+   for example, to the Address Block TLV LINK_METRIC specified in
+   [RFC7181].  The LINK_METRIC type extensions are all available for
+   allocation for different definitions of link metric.  It is
+   appropriate in this case to apply the name LINK_METRIC to the type,
+   and also to all the full types corresponding to that type, as has
+   been done.  Type extensions can then be individually named or can be
+   simply referred to by their number.
+
+   The second, more common, form of allocation has been that allocation
+   of the TLV type has defined only type extension 0, and possibly type
+   extension 1, for that TLV type.  An example is the Address Block TLV
+   LINK_STATUS defined in [RFC6130], where only type extension 0 is
+   allocated.  It is not reasonable to assume that the remaining 255
+   type extensions will be allocated to forms of LINK_STATUS.  (Other
+   forms of link status are already catered to by the introduction, in
+   [RFC7188], of a registry for values of the LINK_STATUS TLV.)  Thus,
+   the name LINK_STATUS should be attached to the specific type
+   extension for that type, i.e., to the full type and not to the TLV
+   type when used with any other type extensions.  This was, however,
+   not done as part of the initial registration of this TLV type.
+   Effectively, this leaves, for the LINK_STATUS TLV type, the type
+   extensions 1-255 either unavailable for allocation (if applying
+   strictly the interpretation that they must relate to a LINK_STATUS)
+   or counterintuitively named for their intended function.
+
+
+
+
+Dearlove & Clausen           Standards Track                    [Page 3]
+
+RFC 7631                       TLV Naming                 September 2015
+
+
+   The purpose of this document is to change how names of the second
+   form are applied and recorded in IANA registries, and to provide
+   guidelines and instructions for future TLV type allocations.  This is
+   to facilitate the addition of new TLVs using type extensions other
+   than 0, but without them having inappropriate names attached.  So,
+   for example, LINK_STATUS will become the name of the full type
+   (composed of the TLV type 3 and the TLV type extension 0) and will
+   cease being the name of the TLV type 3.  This leaves the question of
+   how to name the type.  As it is not clear what other TLVs might be
+   defined for other type extensions of the same type, the type is
+   currently left unnamed and specified only by number.
+
+   This document also updates the Expert Review guidelines from
+   [RFC5444], so as to establish a policy for consistent naming of
+   future TLV type and type extension allocations.
+
+   For clarity, all currently allocated TLVs in [RFC5497], [RFC6130],
+   [RFC6621], [RFC7181], and [RFC7182] are listed in the IANA
+   Considerations section of this document, each specifying the updates
+   or indicating no change when that is appropriate (such as the
+   LINK_METRIC TLV and both TLVs defined in [RFC6621]).  The only
+   changes are of naming.
+
+   Note that nothing in this document changes the operation of any
+   protocol.  This naming is already used, in effect, in [RFC6130] and
+   [RFC7181], currently the main users of allocated TLVs.  For example,
+   the former indicates that all usage of LINK_STATUS refers to that TLV
+   with type extension 0.
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   [RFC2119].
+
+   All references to elements such as "packet", "message", and "TLV" in
+   this document refer to those defined in [RFC5444].
+
+3.  IANA Considerations
+
+   This document updates the Expert Review evaluation guidelines for
+   allocations in [RFC5444] in the "Packet TLV Types", "Message TLV
+   Types", and "Address Block TLV Types" registries and updates the
+   already-made allocations to conform with these guidelines.
+
+
+
+
+
+
+Dearlove & Clausen           Standards Track                    [Page 4]
+
+RFC 7631                       TLV Naming                 September 2015
+
+
+3.1.  Expert Review: Evaluation Guidelines
+
+   For registration in the "Packet TLV Types", "Message TLV Types", and
+   "Address Block TLV Types" registries, the following guidelines apply,
+   in addition to those given in Section 6.1 in [RFC5444]:
+
+   o  If the requested TLV type immediately defines (but not necessarily
+      allocates) all the corresponding type extensions for versions of
+      that type, then a common name SHOULD be assigned for the TLV type.
+
+      This case is unchanged by this specification.  This currently
+      includes TLV types named ICV, TIMESTAMP, and LINK_METRIC; it also
+      includes the HELLO Message-Type-specific TLVs defined in
+      [RFC6621].
+
+   o  Otherwise, if the requested TLV type does not immediately define
+      all the corresponding type extensions for versions of that type,
+      then a common name SHOULD NOT be assigned for that TLV type.
+      Instead, it is RECOMMENDED that:
+
+      *  The "description" for the allocated TLV type be "Defined by
+         Type Extension".
+
+      *  For Packet TLV Types, the type extension registry, created for
+         the TLV type, be named "Type XX Packet TLV Type Extensions",
+         with XX replaced by the numerical value of the TLV type.
+
+      *  For Message TLV Types, the type extension registry, created for
+         the TLV type, be named "Type XX Message TLV Type Extensions",
+         with XX replaced by the numerical value of the TLV type.
+
+      *  For Address Block TLV Types, the type extension registry,
+         created for the TLV type, be named "Type XX Address Block TLV
+         Type Extensions", with XX replaced by the numerical value of
+         the TLV type.
+
+      *  When a new type extension is required, unless there are reasons
+         to the contrary, the next consecutive type extension is
+         allocated and given a name.  (Reasons to the contrary MAY
+         include maintaining a correspondence between corresponding
+         Packet, Message, and Address Block TLVs, and reserving type
+         extension zero if not yet allocated.)
+
+
+
+
+
+
+
+
+
+Dearlove & Clausen           Standards Track                    [Page 5]
+
+RFC 7631                       TLV Naming                 September 2015
+
+
+3.2.  Updated IANA Registries
+
+   The following changes (including correction of some existing minor
+   errors) apply to the IANA registry "Mobile Ad hoc NETwork (MANET)
+   Parameters".  For clarity, registries that are unchanged, including
+   those that define all type extensions of a TLV type, are listed as
+   unchanged.
+
+   The IANA registry "Packet TLV Types" is unchanged.
+
+   The IANA registry "ICV Packet TLV Type Extensions" is unchanged.
+
+   The IANA registry "TIMESTAMP Packet TLV Type Extensions" is
+   unchanged.
+
+   The IANA registry "Message TLV Types" is changed to match Table 1.
+
+          +---------+-------------------------------+-----------+
+          |   Type  | Description                   | Reference |
+          +---------+-------------------------------+-----------+
+          |    0    | Defined by Type Extension     | [RFC5497] |
+          |    1    | Defined by Type Extension     | [RFC5497] |
+          |   2-4   | Unassigned                    |           |
+          |    5    | ICV                           | [RFC7182] |
+          |    6    | TIMESTAMP                     | [RFC7182] |
+          |    7    | Defined by Type Extension     | [RFC7181] |
+          |    8    | Defined by Type Extension     | [RFC7181] |
+          |  9-223  | Unassigned                    |           |
+          | 224-255 | Reserved for Experimental Use | [RFC5444] |
+          +---------+-------------------------------+-----------+
+
+                        Table 1: Message TLV Types
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dearlove & Clausen           Standards Track                    [Page 6]
+
+RFC 7631                       TLV Naming                 September 2015
+
+
+   The IANA registry "INTERVAL_TIME Message Type Extensions" has been
+   renamed "Type 0 Message TLV Type Extensions" and changed to match
+   Table 2.
+
+   +-----------+---------------+---------------------------+-----------+
+   |    Type   |      Name     | Description               | Reference |
+   | Extension |               |                           |           |
+   +-----------+---------------+---------------------------+-----------+
+   |     0     | INTERVAL_TIME | The maximum time before   | [RFC5497] |
+   |           |               | another message of the    |           |
+   |           |               | same type as this message |           |
+   |           |               | from the same originator  |           |
+   |           |               | should be received        |           |
+   |   1-223   |               | Unassigned                |           |
+   |  224-255  |               | Reserved for Experimental | [RFC5497] |
+   |           |               | Use                       |           |
+   +-----------+---------------+---------------------------+-----------+
+
+                Table 2: Type 0 Message TLV Type Extensions
+
+   The IANA registry "VALIDITY_TIME Message Type Extensions" has been
+   renamed "Type 1 Message TLV Type Extensions" and changed to match
+   Table 3.
+
+   +-----------+---------------+---------------------------+-----------+
+   |    Type   |      Name     | Description               | Reference |
+   | Extension |               |                           |           |
+   +-----------+---------------+---------------------------+-----------+
+   |     0     | VALIDITY_TIME | The time from receipt of  | [RFC5497] |
+   |           |               | the message during which  |           |
+   |           |               | the information contained |           |
+   |           |               | in the message is to be   |           |
+   |           |               | considered valid          |           |
+   |   1-223   |               | Unassigned                |           |
+   |  224-255  |               | Reserved for Experimental | [RFC5497] |
+   |           |               | Use                       |           |
+   +-----------+---------------+---------------------------+-----------+
+
+                Table 3: Type 1 Message TLV Type Extensions
+
+   The IANA registry "ICV Message TLV Type Extensions" is unchanged.
+
+   The IANA registry "TIMESTAMP Message TLV Type Extensions" is
+   unchanged.
+
+
+
+
+
+
+
+Dearlove & Clausen           Standards Track                    [Page 7]
+
+RFC 7631                       TLV Naming                 September 2015
+
+
+   The IANA registry "MPR_WILLING Message Type Extensions" has been
+   renamed "Type 7 Message TLV Type Extensions" and changed to match
+   Table 4.
+
+   +-----------+-------------+-----------------------------+-----------+
+   |    Type   |     Name    | Description                 | Reference |
+   | Extension |             |                             |           |
+   +-----------+-------------+-----------------------------+-----------+
+   |     0     | MPR_WILLING | Bits 0-3 specify the        | [RFC7181] |
+   |           |             | originating router's        |           |
+   |           |             | willingness to act as a     |           |
+   |           |             | flooding MPR; bits 4-7      |           |
+   |           |             | specify the originating     |           |
+   |           |             | router's willingness to act |           |
+   |           |             | as a routing MPR            |           |
+   |   1-223   |             | Unassigned                  |           |
+   |  224-255  |             | Reserved for Experimental   | [RFC7181] |
+   |           |             | Use                         |           |
+   +-----------+-------------+-----------------------------+-----------+
+
+                Table 4: Type 7 Message TLV Type Extensions
+
+   The IANA registry "CONT_SEQ_NUM Message Type Extensions" has been
+   renamed "Type 8 Message TLV Type Extensions" and changed to match
+   Table 5.
+
+   +-----------+--------------+----------------------------+-----------+
+   |    Type   |     Name     | Description                | Reference |
+   | Extension |              |                            |           |
+   +-----------+--------------+----------------------------+-----------+
+   |     0     | CONT_SEQ_NUM | Specifies a content        | [RFC7181] |
+   |           |  (COMPLETE)  | sequence number for this   |           |
+   |           |              | complete message           |           |
+   |     1     | CONT_SEQ_NUM | Specifies a content        | [RFC7181] |
+   |           | (INCOMPLETE) | sequence number for this   |           |
+   |           |              | incomplete message         |           |
+   |   2-223   |              | Unassigned                 |           |
+   |  224-255  |              | Reserved for Experimental  | [RFC7181] |
+   |           |              | Use                        |           |
+   +-----------+--------------+----------------------------+-----------+
+
+                Table 5: Type 8 Message TLV Type Extensions
+
+   The IANA registry "HELLO Message-Type-specific Message TLV Types" is
+   unchanged.
+
+   The IANA registry "SMF_TYPE Message TLV Type Extensions" is
+   unchanged.
+
+
+
+Dearlove & Clausen           Standards Track                    [Page 8]
+
+RFC 7631                       TLV Naming                 September 2015
+
+
+   The IANA registry "TC Message-Type-specific Message TLV Types" is
+   unchanged.
+
+   The IANA registry "Address Block TLV Types" has been changed to match
+   Table 6.
+
+          +---------+-------------------------------+-----------+
+          |   Type  | Description                   | Reference |
+          +---------+-------------------------------+-----------+
+          |    0    | Defined by Type Extension     | [RFC5497] |
+          |    1    | Defined by Type Extension     | [RFC5497] |
+          |    2    | Defined by Type Extension     | [RFC6130] |
+          |    3    | Defined by Type Extension     | [RFC6130] |
+          |    4    | Defined by Type Extension     | [RFC6130] |
+          |    5    | ICV                           | [RFC7182] |
+          |    6    | TIMESTAMP                     | [RFC7182] |
+          |    7    | LINK_METRIC                   | [RFC7181] |
+          |    8    | Defined by Type Extension     | [RFC7181] |
+          |    9    | Defined by Type Extension     | [RFC7181] |
+          |    10   | Defined by Type Extension     | [RFC7181] |
+          |  11-223 | Unassigned                    |           |
+          | 224-255 | Reserved for Experimental Use | [RFC5444] |
+          +---------+-------------------------------+-----------+
+
+                     Table 6: Address Block TLV Types
+
+   The IANA registry "INTERVAL_TIME Address Block TLV Type Extensions"
+   has been renamed "Type 0 Address Block TLV Type Extensions" and
+   changed to match Table 7.
+
+   +-----------+---------------+---------------------------+-----------+
+   |    Type   |      Name     | Description               | Reference |
+   | Extension |               |                           |           |
+   +-----------+---------------+---------------------------+-----------+
+   |     0     | INTERVAL_TIME | The maximum time before   | [RFC5497] |
+   |           |               | another message of the    |           |
+   |           |               | same type as this message |           |
+   |           |               | from the same originator  |           |
+   |           |               | and containing this       |           |
+   |           |               | address should be         |           |
+   |           |               | received                  |           |
+   |   1-223   |               | Unassigned                |           |
+   |  224-255  |               | Reserved for Experimental | [RFC5497] |
+   |           |               | Use                       |           |
+   +-----------+---------------+---------------------------+-----------+
+
+             Table 7: Type 0 Address Block TLV Type Extensions
+
+
+
+
+Dearlove & Clausen           Standards Track                    [Page 9]
+
+RFC 7631                       TLV Naming                 September 2015
+
+
+   The IANA registry "VALIDITY_TIME Address Block TLV Type Extensions"
+   has been renamed "Type 1 Address Block TLV Type Extensions" and
+   changed to match Table 8.
+
+   +-----------+---------------+---------------------------+-----------+
+   |    Type   |      Name     | Description               | Reference |
+   | Extension |               |                           |           |
+   +-----------+---------------+---------------------------+-----------+
+   |     0     | VALIDITY_TIME | The time from receipt of  | [RFC5497] |
+   |           |               | the address during which  |           |
+   |           |               | the information regarding |           |
+   |           |               | this address is to be     |           |
+   |           |               | considered valid          |           |
+   |   1-223   |               | Unassigned                |           |
+   |  224-255  |               | Reserved for Experimental | [RFC5497] |
+   |           |               | Use                       |           |
+   +-----------+---------------+---------------------------+-----------+
+
+             Table 8: Type 1 Address Block TLV Type Extensions
+
+   The IANA registry "LOCAL_IF Address Block TLV Type Extensions" has
+   been renamed "Type 2 Address Block TLV Type Extensions" and changed
+   to match Table 9.
+
+   +-----------+----------+-----------------------+--------------------+
+   |    Type   |   Name   | Description           | Reference          |
+   | Extension |          |                       |                    |
+   +-----------+----------+-----------------------+--------------------+
+   |     0     | LOCAL_IF | This value is to be   | [RFC7188][RFC6130] |
+   |           |          | interpreted according |                    |
+   |           |          | to the registry       |                    |
+   |           |          | "LOCAL_IF TLV Values" |                    |
+   |   1-223   |          | Unassigned            |                    |
+   |  224-255  |          | Reserved for          | [RFC6130]          |
+   |           |          | Experimental Use      |                    |
+   +-----------+----------+-----------------------+--------------------+
+
+             Table 9: Type 2 Address Block TLV Type Extensions
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dearlove & Clausen           Standards Track                   [Page 10]
+
+RFC 7631                       TLV Naming                 September 2015
+
+
+   The IANA registry "LINK_STATUS Address Block TLV Type Extensions" has
+   been renamed "Type 3 Address Block TLV Type Extensions" and changed
+   to match Table 10.
+
+   +-----------+-------------+--------------------+--------------------+
+   |    Type   |     Name    | Description        | Reference          |
+   | Extension |             |                    |                    |
+   +-----------+-------------+--------------------+--------------------+
+   |     0     | LINK_STATUS | This value is to   | [RFC7188][RFC6130] |
+   |           |             | be interpreted     |                    |
+   |           |             | according to the   |                    |
+   |           |             | registry           |                    |
+   |           |             | "LINK_STATUS TLV   |                    |
+   |           |             | Values"            |                    |
+   |   1-223   |             | Unassigned         |                    |
+   |  224-255  |             | Reserved for       | [RFC6130]          |
+   |           |             | Experimental Use   |                    |
+   +-----------+-------------+--------------------+--------------------+
+
+            Table 10: Type 3 Address Block TLV Type Extensions
+
+   The IANA registry "OTHER_NEIGHB Address Block TLV Type Extensions"
+   has been renamed "Type 4 Address Block TLV Type Extensions" and
+   changed to match Table 11.
+
+   +-----------+--------------+-------------------+--------------------+
+   |    Type   |     Name     | Description       | Reference          |
+   | Extension |              |                   |                    |
+   +-----------+--------------+-------------------+--------------------+
+   |     0     | OTHER_NEIGHB | This value is to  | [RFC7188][RFC6130] |
+   |           |              | be interpreted    |                    |
+   |           |              | according to the  |                    |
+   |           |              | registry          |                    |
+   |           |              | "OTHER_NEIGHB TLV |                    |
+   |           |              | Values"           |                    |
+   |   1-223   |              | Unassigned        |                    |
+   |  224-255  |              | Reserved for      | [RFC6130]          |
+   |           |              | Experimental Use  |                    |
+   +-----------+--------------+-------------------+--------------------+
+
+            Table 11: Type 4 Address Block TLV Type Extensions
+
+   The IANA registry "ICV Address TLV Type Extensions" has been renamed
+   "ICV Address Block TLV Type Extensions" but is otherwise unchanged.
+
+   The IANA registry "TIMESTAMP Address TLV Type Extensions" has been
+   renamed "TIMESTAMP Address Block TLV Type Extensions" but is
+   otherwise unchanged.
+
+
+
+Dearlove & Clausen           Standards Track                   [Page 11]
+
+RFC 7631                       TLV Naming                 September 2015
+
+
+   The IANA registry "LINK_METRIC Address Block TLV Type Extensions" is
+   unchanged.
+
+   The IANA registry "MPR Address Block TLV Type Extensions" has been
+   renamed "Type 8 Address Block TLV Type Extensions" and changed to
+   match Table 12.
+
+   +-----------+------+---------------------------+--------------------+
+   |    Type   | Name | Description               | Reference          |
+   | Extension |      |                           |                    |
+   +-----------+------+---------------------------+--------------------+
+   |     0     | MPR  | This value is to be       | [RFC7188][RFC7181] |
+   |           |      | interpreted according to  |                    |
+   |           |      | the registry "MPR TLV Bit |                    |
+   |           |      | Values"                   |                    |
+   |   1-223   |      | Unassigned                |                    |
+   |  224-255  |      | Reserved for Experimental | RFC 7631 (this     |
+   |           |      | Use                       | document)          |
+   +-----------+------+---------------------------+--------------------+
+
+            Table 12: Type 8 Address Block TLV Type Extensions
+
+   The IANA registry "NBR_ADDR_TYPE Address Block TLV Type Extensions"
+   has been renamed "Type 9 Address Block TLV Type Extensions" and
+   changed to match Table 13.
+
+   +-----------+---------------+------------------+--------------------+
+   |    Type   |      Name     | Description      | Reference          |
+   | Extension |               |                  |                    |
+   +-----------+---------------+------------------+--------------------+
+   |     0     | NBR_ADDR_TYPE | This value is to | [RFC7188][RFC7181] |
+   |           |               | be interpreted   |                    |
+   |           |               | according to the |                    |
+   |           |               | registry         |                    |
+   |           |               | "NBR_ADDR_TYPE   |                    |
+   |           |               | Address Block    |                    |
+   |           |               | TLV Bit Values"  |                    |
+   |   1-223   |               | Unassigned       |                    |
+   |  224-255  |               | Reserved for     | RFC 7631 (this     |
+   |           |               | Experimental Use | document)          |
+   +-----------+---------------+------------------+--------------------+
+
+            Table 13: Type 9 Address Block TLV Type Extensions
+
+
+
+
+
+
+
+
+Dearlove & Clausen           Standards Track                   [Page 12]
+
+RFC 7631                       TLV Naming                 September 2015
+
+
+   The IANA registry "GATEWAY Address Block TLV Type Extensions" has
+   been renamed "Type 10 Address Block TLV Type Extensions" and changed
+   to match Table 14.
+
+   +-----------+---------+------------------------+--------------------+
+   |    Type   |   Name  | Description            | Reference          |
+   | Extension |         |                        |                    |
+   +-----------+---------+------------------------+--------------------+
+   |     0     | GATEWAY | Specifies that a given | [RFC7188][RFC7181] |
+   |           |         | network address is     |                    |
+   |           |         | reached via a gateway  |                    |
+   |           |         | on the originating     |                    |
+   |           |         | router, with value     |                    |
+   |           |         | equal to the number of |                    |
+   |           |         | hops                   |                    |
+   |   1-223   |         | Unassigned             |                    |
+   |  224-255  |         | Reserved for           | RFC 7631 (this     |
+   |           |         | Experimental Use       | document)          |
+   +-----------+---------+------------------------+--------------------+
+
+            Table 14: Type 10 Address Block TLV Type Extensions
+
+   The IANA registry "HELLO Message-Type-specific Address Block TLV
+   Types" is unchanged.
+
+   The IANA registry "SMF_NBR_TYPE Address Block TLV Type Extensions" is
+   unchanged.
+
+   The IANA registry "TC Message-Type-specific Address Block TLV Types"
+   is unchanged.
+
+   Note: This document adds reservations for Experimental Use [RFC5226],
+   omitted in [RFC7181], to the last three tables.
+
+4.  Security Considerations
+
+   As this document is concerned only with how entities are named, those
+   names being used only in documents such as this and IANA registries,
+   this document has no security considerations.
+
+5.  References
+
+5.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+
+
+Dearlove & Clausen           Standards Track                   [Page 13]
+
+RFC 7631                       TLV Naming                 September 2015
+
+
+   [RFC5444]  Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
+              "Generalized Mobile Ad Hoc Network (MANET) Packet/Message
+              Format", RFC 5444, DOI 10.17487/RFC5444, February 2009,
+              <http://www.rfc-editor.org/info/rfc5444>.
+
+   [RFC5497]  Clausen, T. and C. Dearlove, "Representing Multi-Value
+              Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497,
+              DOI 10.17487/RFC5497, March 2009,
+              <http://www.rfc-editor.org/info/rfc5497>.
+
+   [RFC6130]  Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
+              Network (MANET) Neighborhood Discovery Protocol (NHDP)",
+              RFC 6130, DOI 10.17487/RFC6130, April 2011,
+              <http://www.rfc-editor.org/info/rfc6130>.
+
+   [RFC6621]  Macker, J., Ed., "Simplified Multicast Forwarding",
+              RFC 6621, DOI 10.17487/RFC6621, May 2012,
+              <http://www.rfc-editor.org/info/rfc6621>.
+
+   [RFC7181]  Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
+              "The Optimized Link State Routing Protocol Version 2",
+              RFC 7181, DOI 10.17487/RFC7181, April 2014,
+              <http://www.rfc-editor.org/info/rfc7181>.
+
+   [RFC7182]  Herberg, U., Clausen, T., and C. Dearlove, "Integrity
+              Check Value and Timestamp TLV Definitions for Mobile Ad
+              Hoc Networks (MANETs)", RFC 7182, DOI 10.17487/RFC7182,
+              April 2014, <http://www.rfc-editor.org/info/rfc7182>.
+
+   [RFC7188]  Dearlove, C. and T. Clausen, "Optimized Link State Routing
+              Protocol Version 2 (OLSRv2) and MANET Neighborhood
+              Discovery Protocol (NHDP) Extension TLVs", RFC 7188,
+              DOI 10.17487/RFC7188, April 2014,
+              <http://www.rfc-editor.org/info/rfc7188>.
+
+5.2.  Informative References
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              DOI 10.17487/RFC5226, May 2008,
+              <http://www.rfc-editor.org/info/rfc5226>.
+
+
+
+
+
+
+
+
+
+
+Dearlove & Clausen           Standards Track                   [Page 14]
+
+RFC 7631                       TLV Naming                 September 2015
+
+
+Acknowledgments
+
+   The authors would like to thank Adrian Farrel for pointing out the
+   need to reorganize and rationalize the naming of the TLVs defined by
+   [RFC5444] and Tom Taylor and the RFC Editor for pointing out some
+   omissions and errors.
+
+Authors' Addresses
+
+   Christopher Dearlove
+   BAE Systems Advanced Technology Centre
+   West Hanningfield Road
+   Great Baddow, Chelmsford
+   United Kingdom
+
+   Phone: +44 1245 242194
+   Email: chris.dearlove@baesystems.com
+   URI:   http://www.baesystems.com/
+
+
+   Thomas Heide Clausen
+   LIX, Ecole Polytechnique
+
+   Phone: +33 6 6058 9349
+   Email: T.Clausen@computer.org
+   URI:   http://www.ThomasClausen.org/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dearlove & Clausen           Standards Track                   [Page 15]
+