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/