draft-ietf-manet-nhdp-olsrv2-tlv-extension-03.txt   draft-ietf-manet-nhdp-olsrv2-tlv-extension-04.txt 
Mobile Ad hoc Networking (MANET) C. Dearlove Mobile Ad hoc Networking (MANET) C. Dearlove
Internet-Draft BAE Systems ATC Internet-Draft BAE Systems ATC
Updates: RFC6130, OLSRv2 T. Clausen Updates: RFC6130, OLSRv2 T. Clausen
(if approved) LIX, Ecole Polytechnique (if approved) LIX, Ecole Polytechnique
Intended status: Standards Track February 24, 2014 Intended status: Standards Track March 4, 2014
Expires: August 28, 2014 Expires: September 5, 2014
Optimized Link State Routing Protocol version 2 (OLSRv2) and MANET Optimized Link State Routing Protocol version 2 (OLSRv2) and MANET
Neighborhood Discovery Protocol (NHDP) Extension TLVs Neighborhood Discovery Protocol (NHDP) Extension TLVs
draft-ietf-manet-nhdp-olsrv2-tlv-extension-03 draft-ietf-manet-nhdp-olsrv2-tlv-extension-04
Abstract Abstract
This specification describes extensions to definitions of TLVs used This specification describes extensions to definitions of TLVs used
by the Optimized Link State Routing Protocol version 2 (OLSRv2) and by the Optimized Link State Routing Protocol version 2 (OLSRv2) and
the MANET Neighborhood Discovery Protocol (NHDP), to increase their the MANET Neighborhood Discovery Protocol (NHDP), to increase their
abilities to accommodate protocol extensions. This document updates abilities to accommodate protocol extensions. This document updates
OLSRv2 and RFC6130. OLSRv2 and RFC6130.
Status of this Memo Status of this Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on August 28, 2014. This Internet-Draft will expire on September 5, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 21
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 3
4. TLV Values . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. TLV Values . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Unrecognized TLV Values . . . . . . . . . . . . . . . . . 4 4.1. Unrecognized TLV Values . . . . . . . . . . . . . . . . . 4
4.2. TLV Value Lengths . . . . . . . . . . . . . . . . . . . . 5 4.2. TLV Value Lengths . . . . . . . . . . . . . . . . . . . . 5
4.3. Undefined TLV Values . . . . . . . . . . . . . . . . . . . 5 4.3. Undefined TLV Values . . . . . . . . . . . . . . . . . . . 5
4.3.1. NHDP TLVs: LOCAL_IF, LINK_STATUS and OTHER_NEIGHB . . 6 4.3.1. NHDP TLVs: LOCAL_IF, LINK_STATUS and OTHER_NEIGHB . . 6
4.3.2. OLSRv2 TLVs: MPR and NBR_ADDR_TYPE . . . . . . . . . . 6 4.3.2. OLSRv2 TLVs: MPR and NBR_ADDR_TYPE . . . . . . . . . . 6
4.3.3. Unspecified TLV Values . . . . . . . . . . . . . . . . 6 4.3.3. Unspecified TLV Values . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5.1. Address Block TLVs . . . . . . . . . . . . . . . . . . . . 7 5.1. LOCAL_IF Address Block TLVs . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5.1.1. Create New Registry . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 5.1.2. Modification to Existing Registry . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. LINK_STATUS Address Block TLVs . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 5.2.1. Create New Registry . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 12 5.2.2. Modification to Existing Registry . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 5.3. OTHER_NEIGHB Address Block TLVs . . . . . . . . . . . . . 11
5.3.1. Create New Registry . . . . . . . . . . . . . . . . . 11
5.3.2. Modification to Existing Registry . . . . . . . . . . 12
5.4. MPR Address Block TLVs . . . . . . . . . . . . . . . . . . 12
5.4.1. Create New Registry . . . . . . . . . . . . . . . . . 12
5.4.2. Modification to Existing Registry . . . . . . . . . . 13
5.5. NBR_ADDR_TYPE Address Block TLVs . . . . . . . . . . . . . 14
5.5.1. Create New Registry . . . . . . . . . . . . . . . . . 14
5.5.2. Modification to Existing Registry . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
The MANET Neighborhood Discovery Protocol (NHDP) [RFC6130] and the The MANET Neighborhood Discovery Protocol (NHDP) [RFC6130] and the
Optimized Link State Routing Protocol, version 2 (OLSRv2) [OLSRv2] Optimized Link State Routing Protocol, version 2 (OLSRv2) [OLSRv2]
are protocols for use in mobile ad hoc networks (MANETs) [RFC2501], are protocols for use in mobile ad hoc networks (MANETs) [RFC2501],
based on the Generalized Mobile Ad Hoc Network (MANET) Packet/Message based on the Generalized Mobile Ad Hoc Network (MANET) Packet/Message
Format [RFC5444]. Format [RFC5444].
This document updates [RFC6130] and [OLSRv2], specifically their use This document updates [RFC6130] and [OLSRv2], specifically their use
skipping to change at page 7, line 19 skipping to change at page 7, line 19
attribute; this is therefore required for registrations from the attribute; this is therefore required for registrations from the
relevant registries, see Section 5. relevant registries, see Section 5.
For the LINK_METRIC TLV, this is already possible by clearing the For the LINK_METRIC TLV, this is already possible by clearing the
most significant bits (0 to 3) of the first octet of the TLV Value. most significant bits (0 to 3) of the first octet of the TLV Value.
It is RECOMMENDED that in this case the remaining bits of the TLV It is RECOMMENDED that in this case the remaining bits of the TLV
Value are either all clear ('0') or all set ('1'). Value are either all clear ('0') or all set ('1').
5. IANA Considerations 5. IANA Considerations
Note: Values defined as "Unallocated: Expert Review" mean that these IANA is requested to take a total of ten actions as set out in the
values may be allocated according to the expert review guidelines following sections.
specified in [RFC6130] and [OLSRv2]. In two cases a constraint on
future allocation is specified. IANA tables referenced are from
"Mobile Ad hoc NETwork (MANET) Parameters".
5.1. Address Block TLVs 5.1. LOCAL_IF Address Block TLVs
IANA is requested to create a registry associated with the Address 5.1.1. Create New Registry
Block TLV with name LOCAL_IF (Type = 2, Type Extension = 0) defined
in [RFC6130], specifying the meaning of its single values. This
replaces the Description column in IANA table "LOCAL_IF Address Block
TLV Type Extensions" (from Table 6 in [RFC6130]) by a reference to
this table.
+---------+-------------+-------------------------------------------+ IANA maintains a registry called "Mobile Ad hoc NETwork (MANET)
| Value | Name | Description | Parameters". IANA is requested to create a new sub-registry called
+---------+-------------+-------------------------------------------+ "LOCAL_IF TLV Values".
| 0 | THIS_IF | The network address is associated with |
| | | this local interface of the sending | IANA is requested to populate this registry as specified in Table 1.
| | | router |
| 1 | OTHER_IF | The network address is associated with | +---------+-------------+------------------------------+------------+
| | | another local interface of the sending | | Value | Name | Description | Reference |
| | | router | +---------+-------------+------------------------------+------------+
| 2-223 | | Unallocated: Expert Review | | 0 | THIS_IF | The network address is | [This.I-D] |
| 224-254 | | Experimental Use | | | | associated with this local | |
| 255 | UNSPECIFIED | No information about this network address | | | | interface of the sending | |
| | | is provided | | | | router | |
+---------+-------------+-------------------------------------------+ | 1 | OTHER_IF | The network address is | [This.I-D] |
| | | associated with another | |
| | | local interface of the | |
| | | sending router | |
| 2-223 | | Unallocated: Expert Review | |
| 224-254 | | Experimental Use | [This.I-D] |
| 255 | UNSPECIFIED | No information about this | [This.I-D] |
| | | network address is provided | |
+---------+-------------+------------------------------+------------+
Table 1: LOCAL_IF TLV Values Table 1: LOCAL_IF TLV Values
IANA is requested to create a registry associated with the Address New assignments are to be made by Expert Review [RFC5226].
Block TLV with name LINK_STATUS (Type = 3, Type Extension = 0)
defined in [RFC6130], specifying the meaning of its single values.
This replaces the Description column in the IANA table "LINK_STATUS
Address Block TLV Type Extensions" (from Table 7 in [RFC6130]) by a
reference to this table.
+---------+-------------+-------------------------------------------+ The Designated Experts are required to use the guidelines specified
| Value | Name | Description | in [RFC6130] and [OLSRv2]. IANA is not expected to record this fact
+---------+-------------+-------------------------------------------+ in the registry.
| 0 | LOST | The link on this interface from the |
| | | router with that network address has been |
| | | lost |
| 1 | SYMMETRIC | The link on this interface from the |
| | | router with that network address has the |
| | | status of symmetric |
| 2 | HEARD | The link on this interface from the |
| | | router with that network address has the |
| | | status of heard |
| 3-223 | | Unallocated: Expert Review |
| 224-254 | | Experimental Use |
| 255 | UNSPECIFIED | No information about this network address |
| | | is provided |
+---------+-------------+-------------------------------------------+
Table 2: LINK_STATUS TLV Values 5.1.2. Modification to Existing Registry
IANA is requested to create a registry associated with the Address IANA maintains a registry called "Mobile Ad hoc NETwork (MANET)
Block TLV with name OTHER_NEIGHB (Type = 4, Type Extension = 0) Parameters" with a sub-registry called "LOCAL_IF Address Block TLV
defined in [RFC6130], specifying the meaning of its single values. Type Extensions". This sub-registry currently has an entry for value
This replaces the Description column in Table 8 in the IANA table 0. IANA is requested to replace the entry in the Description column
"OTHER_NEIGHB Address Block TLV Type Extensions" (from [RFC6130]) by for this value with the text "The value is to be interpreted
a reference to this table. according to the registry LOCAL_IF TLV Values". The resulting table
should look as specified in Table 2.
+---------+-------------+-------------------------------------------+ +-----------+-----------------------------------------+-------------+
| Value | Name | Description | | Type | Description | Reference |
+---------+-------------+-------------------------------------------+ | Extension | | |
| 0 | LOST | The neighbor relationship with the router | +-----------+-----------------------------------------+-------------+
| | | with that network address has been lost | | 0 | The value is to be interpreted | [RFC6130] |
| 1 | SYMMETRIC | The neighbor relationship with the router | | | according to the registry LOCAL_IF TLV | [This.I-D] |
| | | with that network address is symmetric | | | Values | |
| 2-223 | | Unallocated: Expert Review | | 1-255 | Unassigned | [This.I-D] |
| 224-254 | | Experimental Use | +-----------+-----------------------------------------+-------------+
| 255 | UNSPECIFIED | No information about this network address |
| | | is provided |
+---------+-------------+-------------------------------------------+
Table 3: OTHER_NEIGHB TLV Values Table 2: LOCAL_IF Address Block TLV Type Extensions Modifications
IANA is requested to create a registry associated with the Address 5.2. LINK_STATUS Address Block TLVs
Block TLV with name MPR (Type = 8, Type Extension = 0) defined in
[OLSRv2], specifying the meaning of its single values in terms of the
values of each bit of the value, from bit 0 (most significant) to bit
7 (least significant). If multiple bits are set then each applies.
This replaces the Description column in the (not yet created) IANA
table "MPR Address Block TLV Type Extensions" (from Table 14 in
[OLSRv2]) by a reference to this table.
+-------+-------+----------+----------------------------------------+ 5.2.1. Create New Registry
| Value | Value | Name | Description |
| Bit | | | |
+-------+-------+----------+----------------------------------------+
| 7 | 1 | FLOODING | The neighbor with that network address |
| | | | has been selected as flooding MPR |
| 6 | 2 | ROUTING | The neighbor with that network address |
| | | | has been selected as routing MPR |
| 0-5 | | | Unallocated: Expert Review |
+-------+-------+----------+----------------------------------------+
Table 4: MPR TLV Bit Values IANA maintains a registry called "Mobile Ad hoc NETwork (MANET)
Parameters". IANA is requested to create a new sub-registry called
"LINK_STATUS TLV Values".
Note that this registry maintains a bit field, and that the IANA is requested to populate this registry as specified in Table 3.
combination of the bits FLOODING + ROUTING being set (1) (which gives
a value of 3) is given the name FLOOD_ROUTE in [OLSRv2]. For each
bit in the field, a set bit (1) means that the address has the
designated property, while an unset bit (0) means that no information
about the designated property is provided. For future allocations,
the Designated Expert has to ensure that this sense is preserved,
and, in particular, an unset bit MUST NOT be used to convey any
specific information about the designated property.
IANA is requested to create a registry associated with the Address +---------+-------------+------------------------------+------------+
Block TLV with name NBR_ADDR_TYPE (Type = 9, Type Extension = 0) | Value | Name | Description | Reference |
defined in [OLSRv2], specifying the meaning of its single values in +---------+-------------+------------------------------+------------+
terms of the values of each bit of the value, from bit 0 (most | 0 | LOST | The link on this interface | [This.I-D] |
significant) to bit 7 (least significant). If multiple bits are set | | | from the router with that | |
then each applies. This replaces the Description column in the (not | | | network address has been | |
yet created) IANA table "NBR_ADDR_TYPE Address Block TLV Type | | | lost | |
Extensions" (from Table 15 in [OLSRv2]) by a reference to this table. | 1 | SYMMETRIC | The link on this interface | [This.I-D] |
| | | from the router with that | |
| | | network address has the | |
| | | status of symmetric | |
| 2 | HEARD | The link on this interface | [This.I-D] |
| | | from the router with that | |
| | | network address has the | |
| | | status of heard | |
| 3-223 | | Unallocated: Expert Review | |
| 224-254 | | Experimental Use | [This.I-D] |
| 255 | UNSPECIFIED | No information about this | [This.I-D] |
| | | network address is provided | |
+---------+-------------+------------------------------+------------+
+-------+-------+------------+--------------------------------------+ Table 3: LINK_STATUS TLV Values
| Value | Value | Name | Description |
| Bit | | | |
+-------+-------+------------+--------------------------------------+
| 7 | 1 | ORIGINATOR | The network address is an originator |
| | | | address reachable via the |
| | | | originating router |
| 6 | 2 | ROUTABLE | The network address is a routable |
| | | | address reachable via the |
| | | | originating router |
| 0-5 | | | Unallocated: Expert Review |
+-------+-------+------------+--------------------------------------+
Table 5: NBR_ADDR_TYPE TLV Bit Values New assignments are to be made by Expert Review [RFC5226].
Note that this registry maintains a bit field, and that the The Designated Experts are required to use the guidelines specified
combination of the bits ORIGINATOR + ROUTABLE being set (1) (which in [RFC6130] and [OLSRv2]. IANA is not expected to record this fact
gives a value of 3) is given the name ROUTABLE_ORIG in [OLSRv2]. For in the registry.
each bit in the field, a set bit (1) means that the address has the
designated property, while an unset bit (0) means that no information 5.2.2. Modification to Existing Registry
about the designated property is provided. For future allocations,
the Designated Expert has to ensure that this sense is preserved, IANA maintains a registry called "Mobile Ad hoc NETwork (MANET)
and, in particular, an unset bit MUST NOT be used to convey any Parameters" with a sub-registry called "LINK_STATUS Address Block TLV
specific information about the designated property. Type Extensions". This sub-registry currently has an entry for value
0. IANA is requested to replace the entry in the Description column
for this value with the text "The value is to be interpreted
according to the registry LINK_STATUS TLV Values". The resulting
table should look as specified in Table 4.
+-----------+-----------------------------------------+-------------+
| Type | Description | Reference |
| Extension | | |
+-----------+-----------------------------------------+-------------+
| 0 | The value is to be interpreted | [RFC6130] |
| | according to the registry LINK_STATUS | [This.I-D] |
| | TLV Values | |
| 1-255 | Unassigned | [This.I-D] |
+-----------+-----------------------------------------+-------------+
Table 4: LINK_STATUS Address Block TLV Type Extensions Modifications
5.3. OTHER_NEIGHB Address Block TLVs
5.3.1. Create New Registry
IANA maintains a registry called "Mobile Ad hoc NETwork (MANET)
Parameters". IANA is requested to create a new sub-registry called
"OTHER_NEIGHB TLV Values".
IANA is requested to populate this registry as specified in Table 5.
+---------+-------------+------------------------------+------------+
| Value | Name | Description | Reference |
+---------+-------------+------------------------------+------------+
| 0 | LOST | The neighbor relationship | [This.I-D] |
| | | with the router with that | |
| | | network address has been | |
| | | lost | |
| 1 | SYMMETRIC | The neighbor relationship | [This.I-D] |
| | | with the router with that | |
| | | network address is symmetric | |
| 2-223 | | Unallocated: Expert Review | |
| 224-254 | | Experimental Use | [This.I-D] |
| 255 | UNSPECIFIED | No information about this | [This.I-D] |
| | | network address is provided | |
+---------+-------------+------------------------------+------------+
Table 5: OTHER_NEIGHB Address Block TLV Values
New assignments are to be made by Expert Review [RFC5226].
The Designated Experts are required to use the guidelines specified
in [RFC6130] and [OLSRv2]. IANA is not expected to record this fact
in the registry.
5.3.2. Modification to Existing Registry
IANA maintains a registry called "Mobile Ad hoc NETwork (MANET)
Parameters" with a sub-registry called "OTHER_NEIGHB Address Block
TLV Type Extensions". This sub-registry currently has an entry for
value 0. IANA is requested to replace the entry in the Description
column for this value with the text "The value is to be interpreted
according to the registry OTHER_NEIGHB TLV Values". The resulting
table should look as specified in Table 6.
+-----------+-----------------------------------------+-------------+
| Type | Description | Reference |
| Extension | | |
+-----------+-----------------------------------------+-------------+
| 0 | The value is to be interpreted | [RFC6130] |
| | according to the registry OTHER_NEIGHB | [This.I-D] |
| | TLV Values | |
| 1-255 | Unassigned | [This.I-D] |
+-----------+-----------------------------------------+-------------+
Table 6: OTHER_NEIGHB Address Block TLV Type Extensions Modifications
5.4. MPR Address Block TLVs
5.4.1. Create New Registry
IANA maintains a registry called "Mobile Ad hoc NETwork (MANET)
Parameters". IANA is requested to create a new sub-registry called
"MPR TLV Bit Values".
IANA is requested to populate this registry as specified in Table 7.
+-----+-------+----------+-----------------------------+------------+
| Bit | Value | Name | Description | Reference |
+-----+-------+----------+-----------------------------+------------+
| 7 | 0x01 | Flooding | The neighbor with that | [This.I-D] |
| | | | network address has been | |
| | | | selected as flooding MPR | |
| 6 | 0x02 | Routing | The neighbor with that | [This.I-D] |
| | | | network address has been | |
| | | | selected as routing MPR | |
| 0-5 | | | Unallocated: Expert Review | |
+-----+-------+----------+-----------------------------+------------+
Table 7: MPR Address Block TLV Bit Values
New assignments are to be made by Expert Review [RFC5226].
The Designated Experts are required to use the guidelines specified
in [RFC6130] and [OLSRv2]. Additionally, the Designated Experts are
required to ensure that the following sense is preserved:
o For each bit in the field, a set bit (1) means that the address
has the designated property, while an unset bit (0) means that no
information about the designated property is provided. In
particular, an unset bit must not be used to convey any specific
information about the designated property. IANA is not expected
to record these facts in the registry.
5.4.2. Modification to Existing Registry
IANA maintains a registry called "Mobile Ad hoc NETwork (MANET)
Parameters" with a sub-registry called "MPR Address Block TLV Type
Extensions". This sub-registry currently has an entry for value 0.
IANA is requested to replace the entry in the Description column for
this value with the text "The value is to be interpreted according to
the registry MPR TLV Bit Values". The resulting table should look as
specified in Table 8.
+-----------+-----------------------------------------+-------------+
| Type | Description | Reference |
| Extension | | |
+-----------+-----------------------------------------+-------------+
| 0 | The value is to be interpreted | [OLSRv2] |
| | according to the registry MPR TLV Bit | [This.I-D] |
| | Values | |
| 1-255 | Unassigned | [This.I-D] |
+-----------+-----------------------------------------+-------------+
Table 8: MPR Address Block TLV Type Extensions Modifications
5.5. NBR_ADDR_TYPE Address Block TLVs
5.5.1. Create New Registry
IANA maintains a registry called "Mobile Ad hoc NETwork (MANET)
Parameters". IANA is requested to create a new sub-registry called
"NBR_ADDR_TYPE Address Block TLV Bit Values".
IANA is requested to populate this registry as specified in Table 9.
+-----+-------+------------+---------------------------+------------+
| Bit | Value | Name | Description | Reference |
+-----+-------+------------+---------------------------+------------+
| 7 | 0x01 | ORIGINATOR | The network address is an | [This.I-D] |
| | | | originator address | |
| | | | reachable via the | |
| | | | originating router | |
| 6 | 0x02 | ROUTABLE | The network address is a | [This.I-D] |
| | | | routable address | |
| | | | reachable via the | |
| | | | originating router | |
| 0-5 | | | Unallocated: Expert | |
| | | | Review | |
+-----+-------+------------+---------------------------+------------+
Table 9: NBR_ADDR_TYPE Address Block TLV Bit Values
New assignments are to be made by Expert Review [RFC5226].
The Designated Experts are required to use the guidelines specified
in [RFC6130] and [OLSRv2]. Additionally, the Designated Experts are
required to ensure that the following sense is preserved:
o For each bit in the field, a set bit (1) means that the address
has the designated property, while an unset bit (0) means that no
information about the designated property is provided. In
particular, an unset bit must not be used to convey any specific
information about the designated property. IANA is not expected
to record these facts in the registry.
5.5.2. Modification to Existing Registry
IANA maintains a registry called "Mobile Ad hoc NETwork (MANET)
Parameters" with a sub-registry called "NBR_ADDR_TYPE Address Block
TLV Type Extensions". This sub-registry currently has an entry for
value 0. IANA is requested to replace the entry in the Description
column for this value with the text "The value is to be interpreted
according to the registry NBR_ADDR_TYPE TLV Bit Values". The
resulting table should look as specified in Table 10.
+-----------+------------------------------------------+------------+
| Type | Description | Reference |
| Extension | | |
+-----------+------------------------------------------+------------+
| 0 | The value is to be interpreted according | [OLSRv2] |
| | to the registry NBR_ADDR_TYPE Address | [This.I-D] |
| | Block TLV Bit Values | |
| 1-255 | Unassigned | [This.I-D] |
+-----------+------------------------------------------+------------+
Table 10: NBR_ADDR_TYPE Address Block TLV Type Extensions
Modifications
6. Security Considerations 6. Security Considerations
The presented updates to [RFC6130] and [OLSRv2]: The presented updates to [RFC6130] and [OLSRv2]:
o Create IANA registries for retaining TLV values for TLVs, already o Create IANA registries for retaining TLV values for TLVs, already
defined in the already published specifications of the two defined in the already published specifications of the two
protocols, and with initial registrations for the TLV values protocols, and with initial registrations for the TLV values
defined by these specifications. This does not give rise to any defined by these specifications. This does not give rise to any
additional security considerations. additional security considerations.
skipping to change at page 11, line 33 skipping to change at page 16, line 22
through signal modification that are not already present in the through signal modification that are not already present in the
two protocols. two protocols.
7. Acknowledgments 7. Acknowledgments
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 (listed alphabetically): Ulrich Herberg (Fujitsu specification (listed alphabetically): Ulrich Herberg (Fujitsu
Laboratories of America) and Henning Rogge (Frauenhofer FKIE). Laboratories of America) and Henning Rogge (Frauenhofer FKIE).
The authors would also like to express their gratitude to Adrian
Farrel, for his assistance and contributions to successful and timely
completion of this specification.
8. References 8. References
8.1. Normative References 8.1. Normative References
[OLSRv2] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, [OLSRv2] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
"The Optimized Link State Routing Protocol version 2", "The Optimized Link State Routing Protocol version 2",
work in progress draft-ietf-manet-olsrv2-19, March 2013. work in progress draft-ietf-manet-olsrv2-19, March 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 12, line 11 skipping to change at page 17, line 5
[RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)", Network (MANET) Neighborhood Discovery Protocol (NHDP)",
RFC 6130, April 2011. RFC 6130, April 2011.
8.2. Informative References 8.2. Informative References
[RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking [RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking
(MANET): Routing Protocol Performance Issues and (MANET): Routing Protocol Performance Issues and
Evaluation Considerations", RFC 2501, January 1999. Evaluation Considerations", RFC 2501, January 1999.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
Authors' Addresses Authors' Addresses
Christopher Dearlove Christopher Dearlove
BAE Systems Advanced Technology Centre BAE Systems Advanced Technology Centre
West Hanningfield Road West Hanningfield Road
Great Baddow, Chelmsford Great Baddow, Chelmsford
United Kingdom United Kingdom
Phone: +44 1245 242194 Phone: +44 1245 242194
Email: chris.dearlove@baesystems.com Email: chris.dearlove@baesystems.com
 End of changes. 24 change blocks. 
138 lines changed or deleted 312 lines changed or added

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