draft-ietf-roll-p2p-rpl-13.txt   draft-ietf-roll-p2p-rpl-14.txt 
Internet Engineering Task Force M. Goyal, Ed. Internet Engineering Task Force M. Goyal, Ed.
Internet-Draft University of Wisconsin Internet-Draft University of Wisconsin
Intended status: Experimental Milwaukee Intended status: Experimental Milwaukee
Expires: December 6, 2012 E. Baccelli Expires: April 20, 2013 E. Baccelli
M. Philipp M. Philipp
INRIA INRIA
A. Brandt A. Brandt
Sigma Designs Sigma Designs
J. Martocci J. Martocci
Johnson Controls Johnson Controls
June 4, 2012 October 17, 2012
Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Reactive Discovery of Point-to-Point Routes in Low Power and Lossy
Networks Networks
draft-ietf-roll-p2p-rpl-13 draft-ietf-roll-p2p-rpl-14
Abstract Abstract
This document specifies a point-to-point route discovery mechanism, This document specifies a point-to-point route discovery mechanism,
complementary to the RPL core functionality. This mechanism allows complementary to the RPL core functionality. This mechanism allows
an IPv6 router to discover "on demand" routes to one or more IPv6 an IPv6 router to discover "on demand" routes to one or more IPv6
routers in the LLN such that the discovered routes meet specified routers in the LLN such that the discovered routes meet specified
metrics constraints. metrics constraints.
Status of this Memo Status of this Memo
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 December 6, 2012. This Internet-Draft will expire on April 20, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 46 skipping to change at page 2, line 46
9.7. Processing a DRO At The Origin . . . . . . . . . . . . . . 27 9.7. Processing a DRO At The Origin . . . . . . . . . . . . . . 27
10. The Discovery Reply Object Acknowledgement (DRO-ACK) . . . . . 28 10. The Discovery Reply Object Acknowledgement (DRO-ACK) . . . . . 28
11. Packet Forwarding Along a Route Discovered Using P2P-RPL . . . 29 11. Packet Forwarding Along a Route Discovered Using P2P-RPL . . . 29
12. Interoperability with Core RPL . . . . . . . . . . . . . . . . 29 12. Interoperability with Core RPL . . . . . . . . . . . . . . . . 29
13. Security Considerations . . . . . . . . . . . . . . . . . . . 30 13. Security Considerations . . . . . . . . . . . . . . . . . . . 30
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
14.1. Additions to Mode of Operation . . . . . . . . . . . . . . 31 14.1. Additions to Mode of Operation . . . . . . . . . . . . . . 31
14.2. Additions to RPL Control Message Options . . . . . . . . . 31 14.2. Additions to RPL Control Message Options . . . . . . . . . 31
14.3. Additions to RPL Control Codes . . . . . . . . . . . . . . 32 14.3. Additions to RPL Control Codes . . . . . . . . . . . . . . 32
14.4. New Registry for Upper Layer Protocol Types Inside 14.4. New Registry for Upper Layer Protocol Types Inside
Data Option . . . . . . . . . . . . . . . . . . . . . . . 32 Data Option . . . . . . . . . . . . . . . . . . . . . . . 33
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
16.1. Normative References . . . . . . . . . . . . . . . . . . . 33 16.1. Normative References . . . . . . . . . . . . . . . . . . . 34
16.2. Informative References . . . . . . . . . . . . . . . . . . 34 16.2. Informative References . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
Targeting Low power and Lossy Networks (LLNs), the RPL routing Targeting Low power and Lossy Networks (LLNs), the RPL routing
protocol [RFC6550] provides paths along a Directed Acyclic Graph protocol [RFC6550] provides paths along a Directed Acyclic Graph
(DAG) rooted at a single router in the network. Establishment and (DAG) rooted at a single router in the network. Establishment and
maintenance of a DAG is performed by routers in the LLN using DODAG maintenance of a DAG is performed by routers in the LLN using DODAG
Information Object (DIO) messages. When two arbitrary routers Information Object (DIO) messages. When two arbitrary routers
(neither of which is the DAG's root) need to communicate, the data (neither of which is the DAG's root) need to communicate, the data
packets are restricted to travel only along the links in the DAG. packets are restricted to travel only along the links in the DAG.
skipping to change at page 10, line 8 skipping to change at page 10, line 8
flag in the DRO message to let the nodes in the LLN know about the flag in the DRO message to let the nodes in the LLN know about the
completion of the route discovery process. The routers receiving completion of the route discovery process. The routers receiving
such a DRO should not generate any more DIOs for this temporary DAG. such a DRO should not generate any more DIOs for this temporary DAG.
Neither should they process any received DIOs for this temporary DAG Neither should they process any received DIOs for this temporary DAG
in future. However, such routers must still process the DROs in future. However, such routers must still process the DROs
received for this temporary DAG. received for this temporary DAG.
6. P2P Route Discovery Mode Of Operation 6. P2P Route Discovery Mode Of Operation
This section specifies a new RPL Mode of Operation (MOP), P2P Route This section specifies a new RPL Mode of Operation (MOP), P2P Route
Discovery Mode (or P2P mode, for short), with value 4 (to be Discovery Mode (or P2P mode, for short), with value TBD1. A DIO
confirmed by IANA). A DIO message, listing P2P mode as the MOP, is message, listing P2P mode as the MOP, is identified as performing a
identified as performing a P2P-RPL route discovery by creating a P2P-RPL route discovery by creating a temporary DAG. A P2P mode DIO
temporary DAG. A P2P mode DIO MUST carry one and only one P2P Route MUST carry one and only one P2P Route Discovery Option (specified in
Discovery Option (specified in Section 7.1). Section 7.1).
6.1. Setting a P2P Mode DIO 6.1. Setting a P2P Mode DIO
The Base Object in a P2P mode DIO message MUST be set in the The Base Object in a P2P mode DIO message MUST be set in the
following manner: following manner:
o RPLInstanceID: RPLInstanceID MUST be a local value as described in o RPLInstanceID: RPLInstanceID MUST be a local value as described in
Section 5.1 of [RFC6550]. The Origin MUST NOT use the same Section 5.1 of [RFC6550]. The Origin MUST NOT use the same
RPLInstanceID in two or more concurrent route discoveries. When RPLInstanceID in two or more concurrent route discoveries. When
initiating a new route discovery to a particular Target, the initiating a new route discovery to a particular Target, the
skipping to change at page 13, line 16 skipping to change at page 13, line 16
This document defines two new RPL control message options: the P2P This document defines two new RPL control message options: the P2P
Route Discovery Option and the Data Option. Route Discovery Option and the Data Option.
7.1. P2P Route Discovery Option (P2P-RDO) 7.1. P2P Route Discovery Option (P2P-RDO)
- -
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 10 | Option Length |R|H| N | Compr | L |MaxRank/NH | | Type = TBD2 | Option Length |R|H| N | Compr | L |MaxRank/NH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Target | | Target |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Address[1..n] | | Address[1..n] |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of P2P Route Discovery Option (P2P-RDO) Figure 1: Format of P2P Route Discovery Option (P2P-RDO)
The format of a P2P Route Discovery Option (P2P-RDO) is illustrated The format of a P2P Route Discovery Option (P2P-RDO) is illustrated
in Figure 1. A P2P mode DIO and a DRO (defined in Section 8) message in Figure 1. A P2P mode DIO and a DRO (defined in Section 8) message
MUST carry one and at most one P2P-RDO. A P2P-RDO consists of the MUST carry one and at most one P2P-RDO. A P2P-RDO consists of the
following fields: following fields:
o Option Type: 0x0A (to be confirmed by IANA). o Option Type: TBD2.
o Option Length: 8-bit unsigned integer, representing the length in o Option Length: 8-bit unsigned integer, representing the length in
octets of the option, not including the Option Type and Option octets of the option, not including the Option Type and Option
Length fields. Length fields.
o Reply (R): The Origin sets this flag to one to allow the Target(s) o Reply (R): The Origin sets this flag to one to allow the Target(s)
to send DRO messages back to the Origin. If this flag is zero, a to send DRO messages back to the Origin. If this flag is zero, a
Target MUST NOT generate any DRO message. Target MUST NOT generate any DRO message.
o Hop-by-hop (H): This flag is valid only if the R flag is set to o Hop-by-hop (H): This flag is valid only if the R flag is set to
skipping to change at page 16, line 12 skipping to change at page 16, line 12
specifying a complete route in the Address vector MUST ensure specifying a complete route in the Address vector MUST ensure
that the vector does not contain any address more than once. that the vector does not contain any address more than once.
* The Address vector MUST NOT contain any multicast addresses. * The Address vector MUST NOT contain any multicast addresses.
7.2. Data Option 7.2. Data Option
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 11 | Option Length | UpperLayerPrt | Data | | Type = TBD3 | Option Length | UpperLayerPrt | Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Figure 2: Format of Data Option Figure 2: Format of Data Option
The format of a Data Option is illustrated in Figure 2. A P2P mode The format of a Data Option is illustrated in Figure 2. A P2P mode
DIO and a DRO (defined in Section 8) message MAY carry one Data DIO and a DRO (defined in Section 8) message MAY carry one Data
Option. A P2P-RDO consists of the following fields: Option. A P2P-RDO consists of the following fields:
o Option Type: 0x0B (to be confirmed by IANA). o Option Type: TBD3.
o Option Length: An 8-bit unsigned integer, representing the length o Option Length: An 8-bit unsigned integer, representing the length
in octets of the option, not including the Option Type and Option in octets of the option, not including the Option Type and Option
Length fields. Length fields.
o Upper Layer Protocol: An 8-bit field that identifies the upper o Upper Layer Protocol: An 8-bit field that identifies the upper
layer protocol header with which the information in the Data field layer protocol header with which the information in the Data field
starts. A value 0x00 in this field identifies UDP as the upper starts. A value 0x00 in this field identifies UDP as the upper
layer protocol while the value 0xFF is reserved for Private Use as layer protocol while the value 0xFF is reserved for Private Use as
defined in [RFC5226]. The other values are Unassigned [RFC5226] defined in [RFC5226]. The other values are Unassigned [RFC5226]
skipping to change at page 17, line 9 skipping to change at page 17, line 9
it MUST include the same Data Option in all retransmissions of this it MUST include the same Data Option in all retransmissions of this
DRO message and MUST NOT include a different Data Option in any other DRO message and MUST NOT include a different Data Option in any other
DRO messages it generates for this route discovery. Also, an DRO messages it generates for this route discovery. Also, an
Intermediate Router, which needs to forward a received DRO message Intermediate Router, which needs to forward a received DRO message
further, MUST include in the forwarded message a verbatim copy of the further, MUST include in the forwarded message a verbatim copy of the
Data Option found inside the received message. Data Option found inside the received message.
8. The Discovery Reply Object (DRO) 8. The Discovery Reply Object (DRO)
This section defines two new RPL Control Message types, the Discovery This section defines two new RPL Control Message types, the Discovery
Reply Object (DRO), with code 0x04 (to be confirmed by IANA), and the Reply Object (DRO), with code TBD4, and the Secure DRO, with code
Secure DRO, with code 0x84 (to be confirmed by IANA). A DRO serves TBD5. A DRO serves one of the following functions:
one of the following functions:
o Carry a discovered Source Route from a Target to the Origin; o Carry a discovered Source Route from a Target to the Origin;
o Establish a Hop-by-hop Route as it travels from a Target to the o Establish a Hop-by-hop Route as it travels from a Target to the
Origin. Origin.
A DRO message MAY serve the function of letting the routers in the A DRO message MAY serve the function of letting the routers in the
LLN know that a P2P-RPL route discovery is complete and no more DIO LLN know that a P2P-RPL route discovery is complete and no more DIO
messages need to be generated for the corresponding temporary DAG. A messages need to be generated for the corresponding temporary DAG. A
DRO message MAY also carry time-critical application data from the DRO message MAY also carry time-critical application data from the
skipping to change at page 28, line 50 skipping to change at page 28, line 50
Intermediate Router may drop the DRO message (e.g., because of its Intermediate Router may drop the DRO message (e.g., because of its
inability to store the state for the Hop-by-hop Route the DRO is inability to store the state for the Hop-by-hop Route the DRO is
establishing). To protect against the potential failure of a DRO establishing). To protect against the potential failure of a DRO
message to reach the Origin, the Target MAY request the Origin to message to reach the Origin, the Target MAY request the Origin to
send back a DRO Acknowledgement (DRO-ACK) message on receiving a DRO send back a DRO Acknowledgement (DRO-ACK) message on receiving a DRO
message. Failure to receive such an acknowledgement within the message. Failure to receive such an acknowledgement within the
DRO_ACK_WAIT_TIME interval of sending the DRO message forces the DRO_ACK_WAIT_TIME interval of sending the DRO message forces the
Target to resend the message. Target to resend the message.
This section defines two new RPL Control Message types: DRO This section defines two new RPL Control Message types: DRO
Acknowledgement (DRO-ACK; with code 0x05; to be confirmed by IANA) Acknowledgement (DRO-ACK; with code TBD6) and Secure DRO-ACK (with
and Secure DRO-ACK (with code 0x85; to be confirmed by IANA). A DRO- code TBD7). A DRO-ACK message MUST travel as a unicast message from
ACK message MUST travel as a unicast message from the Origin to the the Origin to the Target. The format of a base DRO-ACK message is
Target. The format of a base DRO-ACK message is shown in Figure 4. shown in Figure 4. Various fields in a DRO-ACK message MUST have the
Various fields in a DRO-ACK message MUST have the same values as the same values as the corresponding fields in the DRO message. The
corresponding fields in the DRO message. The field marked as field marked as "Reserved" MUST be set to zero on transmission and
"Reserved" MUST be set to zero on transmission and MUST be ignored on MUST be ignored on reception. A Secure DRO-ACK message follows the
reception. A Secure DRO-ACK message follows the format in Figure 7 format in Figure 7 of [RFC6550], where the base format is same as the
of [RFC6550], where the base format is same as the base DRO-ACK shown base DRO-ACK shown in Figure 4.
in Figure 4.
11. Packet Forwarding Along a Route Discovered Using P2P-RPL 11. Packet Forwarding Along a Route Discovered Using P2P-RPL
An Origin MAY use a Source Routing Header (SRH) [RFC6554] to send a An Origin MAY use a Source Routing Header (SRH) [RFC6554] to send a
packet along a Source Route discovered using P2P-RPL. packet along a Source Route discovered using P2P-RPL.
Travel along a Hop-by-hop Route, established using P2P-RPL, requires Travel along a Hop-by-hop Route, established using P2P-RPL, requires
specifying the RPLInstanceID and the DODAGID (of the temporary DAG specifying the RPLInstanceID and the DODAGID (of the temporary DAG
used for the route discovery) to identify the route. This is because used for the route discovery) to identify the route. This is because
a P2P-RPL route discovery does not use globally unique RPLInstanceID a P2P-RPL route discovery does not use globally unique RPLInstanceID
skipping to change at page 31, line 15 skipping to change at page 31, line 14
before the router could forward the message further. As specified in before the router could forward the message further. As specified in
Section 9.6, this check involves the router making sure that its IPv6 Section 9.6, this check involves the router making sure that its IPv6
addresses do not appear multiple times inside the Source Route with addresses do not appear multiple times inside the Source Route with
one or more other IPv6 addresses in between. one or more other IPv6 addresses in between.
14. IANA Considerations 14. IANA Considerations
14.1. Additions to Mode of Operation 14.1. Additions to Mode of Operation
This document defines a new Mode of Operation, entitled "P2P Route This document defines a new Mode of Operation, entitled "P2P Route
Discovery Mode" (see Section 6), assigned a value of 4 from the "Mode Discovery Mode" (see Section 6), assigned a value TBD1 from the "Mode
of Operation" space [to be removed upon publication: of Operation" space [to be removed upon publication:
http://www.iana.org/assignments/rpl/rpl.xml#mop] [RFC6550]. http://www.iana.org/assignments/rpl/rpl.xml#mop] [RFC6550]. IANA is
requested to allocate a suitable value to TBD1. The string TBD1 in
this document should be replaced by the allocated value. The
previous two sentences should be removed before publication.
+-------+---------------------------------------+---------------+ +-------+---------------------------------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+---------------------------------------+---------------+ +-------+---------------------------------------+---------------+
| 4 | P2P Route Discovery Mode of Operation | This document | | TBD1 | P2P Route Discovery Mode of Operation | This document |
+-------+---------------------------------------+---------------+ +-------+---------------------------------------+---------------+
Mode of Operation Mode of Operation
14.2. Additions to RPL Control Message Options 14.2. Additions to RPL Control Message Options
This document defines two new RPL options: This document defines two new RPL options:
o "P2P Route Discovery Option" (see Section 7.1), assigned a value o "P2P Route Discovery Option" (see Section 7.1), assigned a value
of 0x0A from the "RPL Control Message Options" space [to be TBD2 from the "RPL Control Message Options" space [to be removed
removed upon publication: http://www.iana.org/assignments/rpl/ upon publication: http://www.iana.org/assignments/rpl/
rpl.xml#control-message-options] [RFC6550]. rpl.xml#control-message-options] [RFC6550]. IANA is requested to
allocate a suitable value to TBD2. The string TBD2 in this
document should be replaced by the allocated value. The previous
two sentences should be removed before publication.
o "Data Option" (see Section 7.2), assigned a value of 0x0B from the o "Data Option" (see Section 7.2), assigned a value TBD3 from the
"RPL Control Message Options" space [to be removed upon "RPL Control Message Options" space [to be removed upon
publication: http://www.iana.org/assignments/rpl/ publication: http://www.iana.org/assignments/rpl/
rpl.xml#control-message-options] [RFC6550]. rpl.xml#control-message-options] [RFC6550]. IANA is requested to
allocate a suitable value to TBD3. The string TBD3 in this
document should be replaced by the allocated value. The previous
two sentences should be removed before publication.
+-------+---------------------+---------------+ +-------+---------------------+---------------+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+-------+---------------------+---------------+ +-------+---------------------+---------------+
| 0x0A | P2P Route Discovery | This document | | TBD2 | P2P Route Discovery | This document |
| 0x0B | Data | This document | | TBD3 | Data | This document |
+-------+---------------------+---------------+ +-------+---------------------+---------------+
RPL Control Message Options RPL Control Message Options
14.3. Additions to RPL Control Codes 14.3. Additions to RPL Control Codes
This document defines the following new RPL messages: This document defines the following new RPL messages:
o "Discovery Reply Object" (see Section 8), assigned a value of 0x04 o "Discovery Reply Object" (see Section 8), assigned a value TBD4
from the "RPL Control Codes" space [to be removed upon from the "RPL Control Codes" space [to be removed upon
publication: publication:
http://www.iana.org/assignments/rpl/rpl.xml#control-codes] http://www.iana.org/assignments/rpl/rpl.xml#control-codes]
[RFC6550]. [RFC6550]. IANA is requested to allocate TBD4 from the range
0x00-0x7F to indicate a message without security enabled. The
string TBD4 in this document should be replaced by the allocated
value. The previous two sentences should be removed before
publication.
o "Discovery Reply Object Acknowledgement" (see Section 10), o "Secure Discovery Reply Object" (see Section 8.1), assigned a
assigned a value of 0x05 from the "RPL Control Codes" space [to be value TBD5 from the "RPL Control Codes" space [to be removed upon
removed upon publication: publication:
http://www.iana.org/assignments/rpl/rpl.xml#control-codes] http://www.iana.org/assignments/rpl/rpl.xml#control-codes]
[RFC6550]. [RFC6550]. IANA is requested to allocate TBD5 from the range
0x80-0xFF to indicate a message with security enabled. The string
TBD5 in this document should be replaced by the allocated value.
The previous two sentences should be removed before publication.
o "Secure Discovery Reply Object" (see Section 8.1), assigned a o "Discovery Reply Object Acknowledgement" (see Section 10),
value of 0x84 from the "RPL Control Codes" space [to be removed assigned a value TBD6 from the "RPL Control Codes" space [to be
upon publication: removed upon publication:
http://www.iana.org/assignments/rpl/rpl.xml#control-codes] http://www.iana.org/assignments/rpl/rpl.xml#control-codes]
[RFC6550]. [RFC6550]. IANA is requested to allocate TBD6 from the range
0x00-0x7F to indicate a message without security enabled. The
string TBD6 in this document should be replaced by the allocated
value. The previous two sentences should be removed before
publication.
o "Secure Discovery Reply Object Acknowledgement" (see Section 10), o "Secure Discovery Reply Object Acknowledgement" (see Section 10),
assigned a value of 0x85 from the "RPL Control Codes" space [to be assigned a value TBD7 from the "RPL Control Codes" space [to be
removed upon publication: removed upon publication:
http://www.iana.org/assignments/rpl/rpl.xml#control-codes] http://www.iana.org/assignments/rpl/rpl.xml#control-codes]
[RFC6550]. [RFC6550]. IANA is requested to allocate TBD7 from the range
0x80-0xFF to indicate a message with security enabled. The string
TBD7 in this document should be replaced by the allocated value.
The previous two sentences should be removed before publication.
+------+--------------------------------------------+---------------+ +------+--------------------------------------------+---------------+
| Code | Description | Reference | | Code | Description | Reference |
+------+--------------------------------------------+---------------+ +------+--------------------------------------------+---------------+
| 0x04 | Discovery Reply Object | This document | | TBD4 | Discovery Reply Object | This document |
| 0x05 | Discovery Reply Object Acknowledgement | This document | | TBD5 | Secure Discovery Reply Object | This document |
| 0x84 | Secure Discovery Reply Object | This document | | TBD6 | Discovery Reply Object Acknowledgement | This document |
| 0x85 | Secure Discovery Reply Object | This document | | TBD7 | Secure Discovery Reply Object | This document |
| | Acknowledgement | | | | Acknowledgement | |
+------+--------------------------------------------+---------------+ +------+--------------------------------------------+---------------+
RPL Control Codes RPL Control Codes
14.4. New Registry for Upper Layer Protocol Types Inside Data Option 14.4. New Registry for Upper Layer Protocol Types Inside Data Option
The Data Option (see Section 7.2) defines an 8-bit "Upper Layer The Data Option (see Section 7.2) defines an 8-bit "Upper Layer
Protocol" field, for which IANA is requested to create and maintain a Protocol" field, for which IANA is requested to create and maintain a
new registry titled "Upper Layer Protocol Types Inside RPL Data new registry titled "Upper Layer Protocol Types Inside RPL Data
skipping to change at page 34, line 15 skipping to change at page 34, line 37
[RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D.
Barthel, "Routing Metrics Used for Path Calculation in Barthel, "Routing Metrics Used for Path Calculation in
Low-Power and Lossy Networks", RFC 6551, March 2012. Low-Power and Lossy Networks", RFC 6551, March 2012.
16.2. Informative References 16.2. Informative References
[I-D.ietf-roll-p2p-measurement] [I-D.ietf-roll-p2p-measurement]
Goyal, M., Baccelli, E., Brandt, A., and J. Martocci, "A Goyal, M., Baccelli, E., Brandt, A., and J. Martocci, "A
Mechanism to Measure the Quality of a Point-to-point Route Mechanism to Measure the Quality of a Point-to-point Route
in a Low Power and Lossy Network", in a Low Power and Lossy Network",
draft-ietf-roll-p2p-measurement-05 (work in progress), draft-ietf-roll-p2p-measurement-06 (work in progress),
May 2012. September 2012.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095, of Type 0 Routing Headers in IPv6", RFC 5095,
December 2007. December 2007.
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation
Routing Requirements in Low-Power and Lossy Networks", Routing Requirements in Low-Power and Lossy Networks",
RFC 5826, April 2010. RFC 5826, April 2010.
[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
 End of changes. 31 change blocks. 
58 lines changed or deleted 79 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/