Internet Engineering Task Force M. Goyal, Ed. Internet-Draft University of Wisconsin Intended status: Experimental Milwaukee Expires:August 7,September 21, 2013 E. Baccelli M. Philipp INRIA A. Brandt Sigma Designs J. Martocci Johnson ControlsFebruary 3,March 20, 2013 Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Networksdraft-ietf-roll-p2p-rpl-16draft-ietf-roll-p2p-rpl-17 Abstract This document specifies a point-to-point route discovery mechanism, complementary to the RPL core functionality. This mechanism allows an IPv6 router to discover "on demand" routes to one or more IPv6 routers in the LLN such that the discovered routes meet specified metrics constraints. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire onAugust 7,September 21, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .34 1.1. Known Issues/Future Work . . . . . . . . . . . . . . . . . 4 2. The Use Cases . . . . . . . . . . . . . . . . . . . . . . . .45 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .45 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . .56 5. Functional Overview . . . . . . . . . . . . . . . . . . . . .68 6. P2P Route Discovery Mode Of Operation . . . . . . . . . . . .910 6.1. Setting a P2P Mode DIO . . . . . . . . . . . . . . . . . .911 7.New RPL Control Message Options . . . . . . . . . . . . . . . 12 7.1.P2P Route Discovery Option (P2P-RDO) . . . . . . . . . . .13 7.2. Data Option . . .. . 14 8. The P2P Discovery Reply Object (P2P-DRO) . . . . . . . . . . . 18 8.1. Secure P2P-DRO . . . . . . .16 8. The Discovery Reply Object (DRO). . . . . . . . . . . . . . .17 8.1. Secure DRO20 8.2. Setting a P2P-RDO Carried in a P2P Discovery Reply Object . . . . . . . . . . . . . . . . . . . . . . . .19 8.2. Setting a P2P-RDO Carried in a Discovery Reply Object. .1920 9. P2P-RPL Route Discovery By Creating a Temporary DAG . . . . .2021 9.1. Joining a Temporary DAG . . . . . . . . . . . . . . . . .2021 9.2. Trickle Operation For P2P Mode DIOs . . . . . . . . . . .2022 9.3. Processing a P2P Mode DIO . . . . . . . . . . . . . . . .2324 9.4. Additional Processing of a P2P Mode DIO At An Intermediate Router . . . . . . . . . . . . . . . . . . .2425 9.5. Additional Processing of a P2P Mode DIO At The Target . .2526 9.6. Processing aDROP2P-DRO At An Intermediate Router . . . . . .. . 2627 9.7. Processing aDROP2P-DRO At The Origin . . . . . . . . . . . .. . 2829 10. The P2P Discovery Reply Object Acknowledgement(DRO-ACK)(P2P-DRO-ACK) . . . . .29. . . . . . . . . . . . . . . . . . . 30 11. Secure P2P-RPL Operation . . . . . . . . . . . . . . . . . . . 31 12. Packet Forwarding Along a Route Discovered Using P2P-RPL . . .30 12.32 13. Interoperability with Core RPL . . . . . . . . . . . . . . . .30 13.33 14. Security Considerations . . . . . . . . . . . . . . . . . . .31 14.33 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . .32 14.1.35 15.1. Additions to Mode of Operation . . . . . . . . . . . . . .32 14.2.35 15.2. Additions to RPL Control Message Options . . . . . . . . .32 14.3.35 15.3. Additions to RPL Control Codes . . . . . . . . . . . . . .33 15.36 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .34 16.37 17. References . . . . . . . . . . . . . . . . . . . . . . . . . .34 16.1.37 17.1. Normative References . . . . . . . . . . . . . . . . . . .34 16.2.37 17.2. Informative References . . . . . . . . . . . . . . . . . .3538 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .3538 1. Introduction Targeting Low power and Lossy Networks (LLNs), the IPv6 Routing Protocol for LLNs (RPL) [RFC6550] provides paths along a Directed Acyclic Graph (DAG) rooted at a single router in the network. Establishment and maintenance of a DAG is performed by routers in the LLN using Destination-Oriented DAG (DODAG) Information Object (DIO) messages. When two arbitrary routers (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. Such point-to-point (P2P) routing functionality may not be sufficient for several Home and Building Automation applications [RFC5826] [RFC5867] due to the following reasons: o The need to pre-establish routes: each potential destination in the network must declare itself as such ahead of the time a source needs to reach it. o The need to route only along the links in the DAG: A DAG is built to optimize the routing cost to reach the root. Restricting P2P routes to use only the in-DAG links may result in significantly suboptimal routes and severe traffic congestion near the DAG root. This document describes an extension to core RPL (i.e., the RPL functionality described in [RFC6550]) that enables an IPv6 router in the LLN to discover routes to one or more IPv6 routers in the LLN "on demand". The discovered routes may not be the best available but are guaranteed to meet the specified routing metric constraints. Thus, such routes are considered "good enough" from the application's perspective. This reactive P2P route discovery mechanism is henceforth referred to as P2P-RPL. A mechanism to measure the end-to-end cost of an existing route is specified in [I-D.ietf-roll-p2p-measurement]. As discussed in Section 4, measuring the end-to-end cost of an existing route may help decide whether to initiate the discovery of a better route using P2P-RPL and the metric constraints to be used for this purpose. 1.1. Known Issues/Future Work This document is presented as an Experimental specification to facilitate P2P-RPL's deployment in LLN scenarios where reactive P2P route discovery is considered useful or necessary. It is anticipated that, once sufficient operational experience has been gained, this specification will be revised to progress it on to the Standards Track. Experience reports regarding P2P-RPL implementation and deployment are encouraged particularly with respect to: oThe values in the default DODAG Configuration OptionSecure P2P-RPL operation (Section6.1);11); oThe rulesRules governing Trickle operation (Section 9.2); oThe utility and the implementation complexity ofValues in theDatadefault DODAG Configuration Option (Section7.2) that provides a facility to piggyback time-critical application data on the routing messages;6.1); o TheutilityRPLInstanceID reuse policy (Section 6.1); o Utility andtheimplementation complexity of allowing multiple Target addresses in a P2P-RPL route discovery. 2. The Use Cases One use case, common in home [RFC5826] and commercial building [RFC5867] environments, involves a device (say a remotecontrol or an airduct controller)control) that suddenly needs to communicate with another device (say alamp or a humidity sensor)lamp) to which it does not already have aroute.route (and whose network address it knows apriory). In this case, the remote control(or the airduct controller)must be able to discover a route to the lamp(or the humidity sensor)"on demand". Another use case, common in a commercial building environment, involves a large LLN deployment where P2P communication along a particular DAG among hundreds (or thousands) of routers creates severe traffic congestion near that DAG'sroot, and thus routes acrossroot. In thisDAG are desirable.case, it is desirable to discover direct routes between various source- destination pairs that do not pass through the DAG's root. Other use cases involve scenarios where energy or latency constraints are not satisfied by the P2P routes along an existing DAG because they involve traversing many more intermediate routers than necessary to reach the destination. 3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Additionally, this document uses terminology from[RFC6550].[RFC6550] and [I-D.ietf-roll-terminology]. This document introduces the following terms: Origin : The IPv6 router initiating the P2P-RPL route discovery. Target : The IPv6 router at the other end point of the P2P route(s) to be discovered. A P2P-RPL route discovery can discover routes to multiple Targets at the same time. Intermediate Router: An IPv6 router that is neither the Origin nor a Target. Forward direction: The direction from the Origin to the Target. Reverse direction: The direction from the Target to the Origin. Forward Route: A route in the Forward direction. Reverse Route: A route in the Reverse direction. Bidirectional Route: A route that can be used in both Forward and Reverse directions. Ingress-only Interface: A network interface that can only receive packets. Egress-only Interface: A network interface that can only send packets. Source Route: A complete and ordered list of routers that can be used by a packet to travel from a source to a destination node. Hop-by-hop Route: The route characterized by each router on the route using its routing table to determine the next hop on the route. RPL Security Configuration: The values for Counter is Time, Security Algorithm, Key Identifier Mode and Security Level fields, defined in Section 6.1 of [RFC6550], inside the Security section of a secure RPL control message. 4. Applicability A route discovery using P2P-RPL may be performed by an Origin when no route exists between itself and the Target(s) or when the existing routes do not satisfy the application requirements. P2P-RPL is designed to discover Hop-by-hop or Source Routes to one or more Targets such that the discovered routes meet the specified constraints. In some application contexts, the constraints that the discovered routes must satisfy are intrinsically known or can be specified by the application. For example, an Origin that expects its Targets to be less than 5 hops away may use "hop-count < 5" as the constraint. In other application contexts, the Origin may need to measure the cost of the existing route to a Target to determine the constraints. For example, an Origin that measures the total ETX along its current route to a Target to be 20 may use "ETX < x*20", where x is a fraction that the Origin decides, as the constraint. A mechanism to measure the cost of an existing route between two IPv6 routers is specified in [I-D.ietf-roll-p2p-measurement]. If there is no existing route between the Origin and the Target(s) or the cost measurement for the existing routes fails, the Origin will have to guess the constraints to be used in the initial route discovery. Once, the initial route discovery succeeds or fails, the Origin will have a better estimate for the constraints to be used in the subsequent route discovery. P2P-RPL may result in discovery of better P2P routes than the ones available along a global DAG designed to optimize routing cost to the DAG's root. The improvement in route quality depends on a number of factors including the network topology, the "distance" between the Origin and the Target (in terms of the routing metrics in use) and the prevalent conditions in the network. In general, a P2P-RPL route may be better than the one along a global DAG if the Origin and the Target are nearby. Similarly, a P2P-RPL route may not be much better than the one along a global DAG if the Origin and the Target are far apart. Note that, even when P2P-RPL routes are not much better than those along a global DAG, P2P-RPL routes may still be able to avoid congestion that might occur near the root if the routing takes place only along a global DAG. In general, the costs associated with a P2P-RPL route discovery (in terms of the control messages, mostly DIOs, generated) increases with the distance between the Origin and the Target. However, it is possible to limit the cost of route discovery by carefully setting the routing constraints, the Trickle parameters (that govern the DIO generation) and thelifetime oftime duration for which a router maintains its membership in the temporary DAG created for the route discovery. A network designer may take into consideration both the benefits (potentially better routes; no need to maintain routes proactively; avoid congestion near the global DAG's root) and costs when using P2P-RPL. The latency associated with a P2P-RPL route discovery again depends on the distance between the Origin and the Target and the Trickle parameters. Like core RPL [RFC6550], P2P-RPL operation requires links to have bidirectional reachability.RoutersFor this reason, the routers participating in a P2P-RPL route discovery must ensure that o Links that do not have bidirectional reachability do not become part of the route being discovered; and o IPv6 addresses belonging toegress-only or ingress-only interfacesIngress-only (or Egress-only) Interfaces do not become part of the route being discovered. 5. Functional Overview This section contains a high level description of P2P-RPL. A P2P-RPL route discovery takes place by forming a DAG rooted at the Origin. As is the case with core RPL, P2P-RPL uses IPv6 link-local multicast DIO messages to establish a DAG. However, unlike core RPL, this DAG is temporary innaturenature. The routes are discovered androutersinstalled while the DAG is alive. Once the specified duration of their membership in the DAG is over, the routers leaveoncetheDAG'sDAG and hence the DAG ceases to exist. However, the installed routes are retained for their specified life time (which isover. Thedifferent than the specified duration of a router's membership in the DAG) even though the DAG that caused their installation no longer exists. In P2P-RPL, the sole purpose of DAG creation is to discover routes to the Target(s) and DIOs serve as the route discovery messages. Each router joining the DAG determines a rank for itself in the DAG and ignores the subsequent DIOs received from lower (higher in numerical value) ranked neighbors. Thus, the route discovery messages propagate away from the Origin rather than return back to it. As in core RPL, DIO generation at a router is controlled by a Trickle timer [RFC6206] that allows a router to avoid generating unnecessary messages while providing protection against packet loss. P2P-RPL also uses the routing metrics [RFC6551], objective functions and packet forwarding framework [RFC6554][RFC6553] developed for core RPL. An Origin may use P2P-RPL to discover routes to one or more Target(s) identified by one or more unicast/multicast addresses. P2P-RPL allows for the discovery of one Hop-by-hop Route or up to four Source Routes per Target. The discovered routes are guaranteed to meet the specified routing metric constraints but may not be the best available. P2P-RPL may fail to discover any route if the specified routing constraints are overly strict.P2P-RPL allows an Origin to piggyback time-critical application data on the DIO messages for delivery to the Target(s).The Origin initiates a P2P-RPL route discovery by forming a temporary DAG rooted at itself. The DIOs used to create the temporary DAG are identified by a new Mode of Operation (P2P Route Discovery mode defined in Section 6). The DIOs listing the P2P Route Discovery mode as the Mode of Operation are henceforth referred to as the P2P mode DIOs. A P2P mode DIO always carries exactly one P2P Route Discovery Option(defined(P2P-RDO, defined in Section7.1)7) in which the Origin specifies the following information: o The IPv6 address of a Target. This could be a unicast address or a multicast address. Any additional Targets may be specified by including one or more RPL Target Options [RFC6550] inside the DIO. o The nature of the route(s) to be discovered: Hop-by-hop or Source Routes. This specification allows for the discovery of one Hop- by-hop Route or up to four Source Routes per Target. o The desired number of routes (if Source Routes are being discovered). o Whether the Target(s) should send P2P Discovery Reply Object(DRO)(P2P- DRO) messages (defined in Section 8) back to the Origin on receiving a DIO message. ADROP2P-DRO message carries a discovered Source Route back to the Origin or establishes a Hop-by-hop Route between the Origin and the Target.By not allowing the generation of DRO messages, an Origin can use P2P-RPL as purely a mechanism to deliver time- critical application data to the Target(s).AP2P Route Discovery OptionP2P-RDO alsoaccumulates aincludes the best route from the Originto a Target asthat therouters joinrouter, generating thetemporary DAG.P2P mode DIO, has seen so far. A P2P mode DIO MAY also carry: o One or more Metric Container Options to specify: * The relevant routing metrics. * The constraints that the discovered route must satisfy. These constraints also limit how far the DIOs message may travel. o One or more RPL Target options to specify additional unicast or multicast Targets.o One Data Option (defined in Section 7.2) to carry time-critical application-level data to be delivered to the Target(s).As the routers join the temporary DAG, they keep track of the best route(s) (so far from the Origin) they have seen and advertise these routes, along with the corresponding routing metrics, in their P2P mode DIOs. A router, including the Target(s), discards a received P2P mode DIO if the aggregated routing metrics on the route advertised by the DIO do not satisfy the listed constraints. These constraints can be used to limit the propagation of P2P mode DIO messages. A router may also discard a received P2P mode DIO if it does not wish to be a part of the discovered route due to limited resources or due to policy reasons. When a Target receives a P2P mode DIO, itforwardscontains inside thedata inP2P-RDO a complete Source Route from theData Option, if present,Origin tothe higher layer.this Target. Since the links in the discovered route have bidirectional reachability (Section7.1),7), the Target mayrememberuse the discovered routefor useto reach the Origin. Thus, a router that provides a particular service in the LLN (e.g. an outside temperature server) could initiate a P2P-RPL route discovery listing all its potential clients as Targets, thereby allowing the clients to discover a Source Route back toreachtheOrigin.server. In this case, the Origin (the server) might want to disable the generation of P2P-DRO messages by the Targets (the clients). If the Origin has requestedDROP2P-DRO messages to be sent back, the Target may select the discovered routecontainedin the received DIO for further processing as described next. This document does not specify a particular method for the Target to use to select a route for further processing. Example methods include selecting any route that meets the constraints or selecting the best route(s) discovered over a certain time period. If one or more Source Route(s) are being discovered, the Target sends the selected Source Route(s) to the Origin viaDROP2P-DRO messages with oneDROP2P-DRO message carrying one discovered route. On receiving aDROP2P-DRO message, the Origin stores the discovered route in its memory. This specification allows the Origin to discover up to four Source Routes per Target, thereby allowing the Origin to have sufficientready-to- useready-to-use alternatives should one or more of these routes fail. If aHop- by-hopHop-by-hop Route is being discovered, the Target sends aDROP2P-DRO message containing the selected route to the Origin. TheDROP2P-DRO message travels back to the Origin along the selected route, establishing state for the Forward Route in the routers on the path. The Target mayinclude a Data Option in a DRO message to deliver any time-critical application data to the Origin. The Target mayrequest the Origin to acknowledge the receipt of aDROP2P-DRO message by sending back aDROP2P-DRO Acknowledgement(DRO-ACK)(P2P-DRO- ACK) message (defined in Section 10). The Origin unicasts aDRO-ACKP2P-DRO- ACK message to the Target. If the Target does not receive the requestedDRO-ACKP2P-DRO-ACK within a certain time interval of sending aDRO,P2P-DRO, it resends theDROP2P-DRO message (up to a certain number of times) carrying the same route as before. The use of trickle timers to delay the propagation of DIO messages may cause some nodes to generate these messages even when the desired routes have already been discovered. In order to preempt the generation of such unnecessary messages, the Target may set a "Stop" flag in theDROP2P-DRO message to let the nodes in the LLN know about the completion of the route discovery process. The routers receiving such aDROP2P-DRO should not generate any more DIOs for this temporary DAG. Neither should they process any received DIOs for this temporary DAG in future. However, such routers must still process theDROsP2P-DROs received for this temporary DAG. 6. P2P Route Discovery Mode Of Operation This section specifies a new RPL Mode of Operation (MOP), P2P Route Discovery Mode (or P2P mode, for short), with value TBD1. A DIO message, listing P2P mode as the MOP, is identified as performing a P2P-RPL route discovery by creating a temporary DAG. A P2P mode DIO MUST carry exactly one P2P Route Discovery Option(specified(P2P-RDO, specified in Section7.1).7). 6.1. Setting a P2P Mode DIO The Base Object in a P2P mode DIO message MUST be set in the following manner: o RPLInstanceID: RPLInstanceID MUST be a local value as described in Section 5.1 of [RFC6550]. The OriginMUSTchooses the RPLInstanceID to be used for a particular route discovery in accordance with the following rules: * The Origin SHOULD NOT reuse an RPLInstanceID for a route discovery ifitssome routers might still maintain membership in the DAG the Origin had initiated for the previous route discovery using thisRPLInstanceID might still be going on.RPLInstanceID. As described in Section7.1, the Life Time parameter7, a router's membership in a DAG created for a P2P-RPL route discovery lasts for theP2P Route Discovery Option specifiestime duration (say 'l' seconds) indicated by the L field inside the P2P-RDO. In general, there is no upper bound on the time duration by when all the routers have left the DAG created for a P2P-RPL routediscovery lasts. So,discovery. In theOrigin MUST NOT reuse an RPLInstanceIDspecific case where the discovered route must be at most 'n' hops inalength, all the routers must have left the DAG "(n+1)*l" seconds after its initiation by the Origin. In practice, all the routers should have joined the DAG within 'l' seconds of its initiation (since the route discoveryuntilmust complete while theLife TimeOrigin still belongs to the DAG) and hence all the routers should have left the DAG within "2*l" seconds of its initiation. Hence, it is usually sufficient that the Origin wait for twice the duration indicated by the L field inside the P2P-RDO used for the previous route discoveryusing thisbefore reusing the RPLInstanceIDis over.for a new route discovery. Individual P2P-RPL deployments are encouraged to share their experience with various RPLInstanceID reuse policies to help guide the development of standards track version of the protocol. * When initiating a new route discovery to a particular Target, the Origin MUST NOT reuse the RPLInstanceID used in a previous route discovery to this Target if thepreviously discovered routesstate created during the previous route discovery might stillexist.exist in some routers. Note that it is possible that the previous route discovery did not succeed yet some routers still ended up creating state. The Default Lifetime and Lifetime Unit parameters in the DODAG Configuration Option specify the lifetime of the state the routers, including the Origin and the Target, maintain for a Hop-by-hop or a Source Route discovered using P2P-RPL.Thus, anSuppose this lifetime is 'X' seconds. As discussed above, any state created during the previous route discovery was likely created within "2*l" seconds of its initiation. Hence, it is sufficient that the Origincan safely reuse an RPLInstanceIDlets a time duration equal todiscover"X+2*l" seconds pass since the initiation of the previous route discovery before initiating a new route discovery toa Target ifthelifetime of all previously discovered routes to thissame Target usingthis RPLInstanceID is over.the same RPLInstanceID. o Version Number: MUST be set to zero. The temporary DAG used for P2P-RPL route discovery does not exist long enough to have newversions (the Life Time parameter inside the P2P Route Discovery Option, defined in Section 7.1, specifies the life time of the temporary DAG).versions. o Grounded (G) Flag: This flag MUST be set to one. Unlike a global RPL instance, the concept of a floating DAG, used to provide connectivity within a sub-DAG detached from a grounded DAG, does not apply to a local RPL instance. Hence, an Origin MUST always set the G flag to one when initiating a P2P-RPL route discovery. Further, clause 3 of Section 8.2.2.2 in [RFC6550] does not apply and a node MUST NOT initiate a new DAG if it does not have any parent left in a P2P-RPL DAG. o Mode of Operation (MOP): MUST be set to TBD1, corresponding to P2P Route Discovery mode. o DTSN: MUST be set to zero on transmission and ignored on reception. o DODAGPreference (Prf): This field MUST be set to zero (least preferred). o DODAGID: This field MUST be set to an IPv6 address of the Origin. o The other fields in the DIO Base Object can be set in the desired fashion as per the rules described in [RFC6550]. A received P2P mode DIO MUST be discarded if it does not follow the above-listed rules regarding the RPLInstanceID, Version Number, G flag, MOP and Prf fields inside the base object. The DODAG Configuration Option, inside a P2P mode DIO MUST be set in the following manner: o The Origin MUST set the MaxRankIncrease parameter to zero to disable local repair of the temporary DAG. A received P2P mode DIO MUST be discarded if the MaxRankIncrease parameter inside the DODAG Configuration Option is not zero. o The Origin SHOULD set the Trickle parameters (DIOIntervalDoublings, DIOIntervalMin, DIORedundancyConstant) as recommended in Section 9.2. o The Origin sets the Default Lifetime and Lifetime Unit parameters to indicate the lifetime of the state the routers, including the Origin and the Target(s), maintain for a Hop-by-hop or a Source Route discovered using P2P-RPL. o The Origin sets the other fields in the DODAG Configuration Option, including the OCP identifying the Objective function, in the desired fashion as per the rules described in [RFC6550]. o An Intermediate Router (or a Target) MUST set various fields in the DODAG Configuration Option in the outgoing P2P mode DIOs to the values they had in the incoming P2P mode DIOs for this DAG. A default DODAG Configuration Option comes in effect if a P2P mode DIO does not carry an explicit one. The default DODAG Configuration Option has the following parameter values: o Authentication Enabled: 0 o DIOIntervalMin: 6, which translates to 64ms as the value for Imin parameter in Trickle operation. This value is roughly one order of magnitude larger than the typical transmission delay on IEEE 802.15.4 links and corresponds to the recommendation in Section 9.2 for well-connected topologies. o DIORedundancyConstant: 1. See the discussion in Section 9.2. o MaxRankIncrease: 0 (to disable local repair of the temporary DAG). o Default Lifetime: 0xFF, to correspond to infinity. o Lifetime Unit: 0xFFFF, to correspond to infinity. o Objective Code Point: 0, i.e., OF0 [RFC6552] is the default objective function. o The remaining parameters have default values as specified in [RFC6550]. Individual P2P-RPL deployments are encouraged to share their experience with these default valueswith ROLL working groupto help guide the development of standards track version of the protocol. The routing metrics and constraints [RFC6551] used in P2P-RPL route discovery are included in one or more Metric Container Options [RFC6550] inside the P2P mode DIO. Note that a DIO need not include a Metric Container if OF0 is the objective function in effect. In that case, a P2P mode DIO may still specify an upper limit on the maximum rank, that a router may have in the temporary DAG, inside theP2P Route Discovery Option (described in Section 7.1).P2P-RDO. A P2P mode DIO: o MUST carry one (and only one)P2P Route Discovery Option (described in Section 7.1).P2P-RDO. TheP2P Route Discovery OptionP2P-RDO allows for the specification of one unicast or multicast address for the Target. A received P2P mode DIO MUST be discarded if it does not contain exactly oneP2P Route Discovery Option.P2P-RDO. o MAY carry one or more RPL Target Options to specify additional unicast/multicast addresses for the Target. If a unicast address is specified, it MUST be a global address or a unique local address. o MAY carry one or more Metric Container Options to specify routing metrics and constraints. o MAY carry oneData Option (described in Section 7.2) containing time-critical application data to be delivered to the Target(s). A received P2P mode DIO MUST be discarded if it contains multiple Data Options. o MAY carry oneor more Route Information Options [RFC6550]. In the context of P2P-RPL, a Route Information Option advertizes to the Target(s) the Origin's connectivity to the prefix specified in the option.o MAY carry one or more Prefix Information Options subject toAn RPL Option, besides theusageones listed above, MUST be ignored when found inside a received P2P mode DIO andrules specifiedMUST NOT be included inSection 6.7.10the P2P mode DIOs the receiving router generates. In accordance with core RPL, a P2P mode DIO MUST propagate via link- local multicast. The IPv6 source address in a P2P mode DIO MUST be a link-local address and the IPv6 destination address MUST be the link- local multicast address all-RPL-nodes [RFC6550].7. NewA P2P mode DIO MUST be transmitted on all interfaces the router has in this RPLControl Message Optionsdomain [I-D.ietf-roll-terminology]. 7. P2P Route Discovery Option (P2P-RDO) Thisdocumentsection definestwoa new RPL control messageoptions: the P2P Route Discovery Option andoption: theData Option. 7.1.P2P Route Discovery Option(P2P-RDO)(P2P-RDO). - 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TBD2 | Option Length |R|H| N | Compr | L |MaxRank/NH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | TargetAddr | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Address[1..n] | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Format of P2P Route Discovery Option (P2P-RDO) The format of a P2P Route Discovery Option (P2P-RDO) is illustrated in Figure 1. A P2P mode DIO and aDROP2P-DRO (defined in Section 8) message MUST carry exactly one P2P-RDO. A P2P-RDO consists of the following fields: o Option Type: TBD2. o Option Length: 8-bit unsigned integer, representing the length in octets of the option, not including the Option Type and Option Length fields. o Reply (R): The Origin sets this flag to one to allow the Target(s) to sendDROP2P-DRO messages back to the Origin. If this flag is zero, a Target MUST NOT generate anyDROP2P-DRO message. o Hop-by-hop (H): This flag is valid only if the R flag is set to one. The Origin sets this flag to one if it desires Hop-by-hop Routes. The Origin sets this flag to zero if it desires Source Routes. This specification allows for the establishment of one Hop-by-hop route or up to four Source Routes per Target. The Hop- by-hop Route is established in the Forward direction, i.e. from the Origin to the Target. This specification does not allow for the establishment of Hop-by-hop Routes in the Reverse direction. o Number of Routes (N): This field is valid only if the R flag is one and H flag is zero, i.e. the Targets are allowed to generateDROP2P-DRO messages carrying discovered Source Routes back to the Origin. In this case, the value in the N field plus one indicates the number of Source Routes that each Target should convey to the Origin. When Hop-by-hop Routes are being discovered, the N field MUST be set to zero on transmission and ignored on reception. o Compr: 4-bit unsigned integer indicating the number of prefix octets that are elided from the Target field and the Address vector. For example, Compr value will be zero if full IPv6 addresses are carried in the Target field and the Address vector. o Life Time (L): A 2-bit field that indicates thelife time of the temporary DAG, i.e., theexact duration a router joining the temporaryDAGDAG, including the Origin and the Target(s), MUST maintain its membership in the DAG. A router MUST leave the temporary DAG once the time elapsed since it joined reaches the value indicated by this field. The mapping between thevaluesvalue in this field and thelife timeduration of the router's membership in the temporary DAG is as follows: * 0x00: 1 second; * 0x01: 4 seconds; * 0x02: 16 seconds; * 0x03: 64 seconds; The Origin sets this field based on its expectation regarding the time required for the route discovery to complete, which includes the time required for the DIOs to reach the Target(s) and the P2P- DROs to travel back to the Origin. The time required for the DIOs to reach the Target(s) would in turn depend on the Trickle parameters (Imin and the redundancy constant) as well as the expected distance (in terms of hops and/or ETX) to the Target(s). While deciding thetemporary DAG's lifetime,value in this field, the Origin should also take in account the fact that all routers joining the temporary DAG would need to stay in the DAG for this much time. o MaxRank/NH: * When a P2P-RDO is included in a P2P mode DIO, this field indicates the upper limit on the integer portion of the rank (calculated using the DAGRank() macro defined in [RFC6550]) that a router may have in the temporary DAG being created. An Intermediate Router MUST NOT join a temporary DAG being created by a P2P mode DIO if the integer portion of its rank would be equal to or higher (in numerical value) than the MaxRank limit. A Target can join the temporary DAG at a rank whose integer portion is equal to the MaxRank. A router MUST discard a received P2P mode DIO if the integer part of the advertized rank equals or exceeds the MaxRank limit. A value 0 in this field indicates that the MaxRank is infinity. * When a P2P-RDO is included in aDROP2P-DRO message, this field indicates the index of the next hop address inside the Address vector. o TargetAddr: An IPv6 address of the Target after eliding Compr number of prefix octets. When the P2P-RDO is included in a P2P mode DIO, this field may contain a unicast address or a multicast address. If a unicast address is specified, it MUST be a global address or a unique local address. Any additional Target addresses can be specified by including one or more RPL Target Options [RFC6550] in the DIO. When the P2P-RDO is included in aDRO,P2P-DRO, this field MUST contain a unicast global or unique local IPv6 address of the Target generating theDRO.P2P-DRO. o Address[1..n]: A vector of IPv6 addresses representing a complete route so far in the Forward direction: * Each element in the Address vector has size (16 - Compr) octets and MUST contain a valid global or unique local IPv6 address with first Compr octets elided. * The total number of elements inside the Address vector is given by n = (Option Length - 2 - (16 - Compr))/(16 - Compr). * The IPv6addresses of ingress-only (or egress-only)address that a routerinterfacesadds to the vector MUSTNOT be addedbelong to theAddress vector.interface on which the router received the DIO containing this P2P-RDO. Further, this interface MUST NOT be an Ingress-only Interface. This allows the route accumulated in the Address vector to be a Bidirectional Route that can be used by a Target to send aDROP2P-DRO message to the Origin. * The Address vector MUST carry the accumulated route in the Forward direction, i.e., the first element in the Address vector must contain the IPv6 address of the router next to the Origin and so on. * The Origin and Target addresses MUST NOT be included in the Address vector. * A router adding its address to the vector MUST ensure that any of its addresses do not already exist in the vector. A Target specifying a complete route in the Address vector MUST ensure that the vector does not contain any address more than once. * The Address vector MUST NOT contain any multicast addresses.7.2. Data Option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TBD3 | Option Length | UpperLayerPrt | Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... Figure 2: Format of Data Option 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 Option. A P2P-RDO consists of the following fields: o Option Type: TBD3. o Option Length: An 8-bit unsigned integer, representing the length in octets of the option, not including the Option Type and Option Length fields. o Upper Layer Protocol: An 8-bit field that identifies the upper layer protocol header with which the information in the Data field starts. The protocol identifiers used in this field are same as those defined in IANA's "Protocol Numbers" registry [PROTOCOL]. o Data: If the Data Option is contained in a DIO, this field contains application data to be delivered to the Target(s). If the Data Option is contained in a DRO, this field contains application data to be delivered to the Origin. If the Origin chooses to include a Data Option inside its DIO, it MUST include the same Data Option in all its future DIO transmissions for this temporary DAG. An Intermediate Router MUST NOT modify the Data Option received inside a parent's DIO and MUST include this Data Option in all its future DIO transmissions for this temporary DAG. The same is true for a Target that needs to propagate the DIOs further (required when the route discovery involves multiple Targets). If a Target chooses to include a Data Option inside a DRO, 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 messages it generates for this route discovery. Also, an Intermediate Router, which needs to forward a received DRO message further, MUST include in the forwarded message a verbatim copy of the Data Option found inside the received message. Note that the data inside a Data Option has the same level of security as the DIO/DRO message it is part of. A P2P-RPL deployment SHOULD take in consideration the security requirements of the data being sent inside the Data Options when deciding the overall security requirements. Further, note that P2P-RPL does not guarantee successful delivery of the data contained in a Data Option.8. The P2P Discovery Reply Object(DRO)(P2P-DRO) This section defines two new RPL Control Message types, the P2P Discovery Reply Object(DRO),(P2P-DRO), with codeTBD4,TBD3, and the Secure P2P- DRO, with codeTBD5.TBD4. ADROP2P-DRO serves one of the following functions: 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 Origin. ADROP2P-DRO messageMAYcan also serve the function of letting the routers in the LLN know that a P2P-RPL route discovery is complete and no more DIO messages need to be generated for the corresponding temporary DAG. ADRO message MAY also carry time-critical application data from the Target to the Origin in a Data Option. A DROP2P-DRO message MUST carry one (and only one)P2P-RDOP2P- RDO whose TargetAddr field MUST contain a unicast IPv6 address of the Target that generates theDRO.P2P-DRO. ADROP2P-DRO messagetravelsMUST travel from the Target to the Origin via link-local multicast along the route specified inside the Address vector in the P2P-RDO, as included in theDRO.P2P-DRO. The IPv6 source address in a P2P-DRO message MUST be a link-local address and the IPv6 destination address MUST be the link-local multicast address all-RPL-nodes [RFC6550]. A P2P-DRO message MUST be transmitted on all interfaces the router has in this RPL domain [I-D.ietf-roll-terminology]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPLInstanceID | Version |S|A|Seq| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | DODAGID | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option(s)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... Figure3:2: Format of the base P2P Discovery Reply Object(DRO)(P2P-DRO) The format of the base P2P Discovery Reply Object(DRO)(P2P-DRO) is shown in Figure3.2. A baseDROP2P-DRO consists of the following fields: o RPLInstanceID: The RPLInstanceID of the temporary DAG used for route discovery. o Version: The Version of the temporary DAG used for route discovery. Since a temporary DAG always has value zero for the Version, this field MUST always be set to zero. o Stop (S): This flag, when set to one by a Target, indicates that the P2P-RPL route discovery is over. All the routers receiving such aDRO,P2P-DRO, including the ones not listed in the route carried inside P2P-RDO, * SHOULD NOT process any more DIOs received for this temporary DAG; * SHOULD NOT generate any more DIOs for this temporary DAG; * SHOULD cancel any pending DIO transmission for this temporary DAG. Note that the Stop flag serves to stop further DIO generation/ processing for a P2P-RPL route discovery but it does not affect the processing ofDROP2P-DRO messages at either the Origin or the Intermediate Routers. In other words, a router (the Origin or an Intermediate Router) MUST continue to process theDROP2P-DRO messages even if an earlierDROP2P-DRO message (with the same RPLInstanceID and DODAGID fields) had the Stop flag set to one. When set to zero, this flag does not imply any thing and MUST be ignored on reception. o Ack Required (A): This flag, when set to one by the Target, indicates that the Origin MUST unicast aDRO-ACKP2P-DRO-ACK message (defined in Section 10) to the Target when it receives the P2P- DRO. o Sequence Number (Seq): This 2-bit field indicates the sequence number for theDRO.P2P-DRO. This field is relevant when the A flag is set to one, i.e., the Target requests an acknowledgement from the Origin for a receivedDRO.P2P-DRO. The Origin includes the RPLInstanceID, the DODAGID and the Sequence Number of the receivedDROP2P-DRO inside theDRO-ACKP2P-DRO-ACK message it sends back to the Target. o Reserved: These bits are reserved for future use. These bits MUST be set to zero on transmission and MUST be ignored on reception. o DODAGID: The DODAGID of the temporary DAG used for route discovery. The DODAGID also identifies the Origin. The RPLInstanceID, the Version and the DODAGID together uniquely identify the temporary DAG used for route discovery and can be copied from the DIO message advertizing the temporary DAG. o Options: TheDROP2P-DRO message: * MUST carry one (and only one) P2P-RDO that MUST specify a complete route between the Target and theOrigin;Origin. A received P2P-DRO message MUST be discarded if it does not contain exactly one P2P-RDO. * MAY carry one or more Metric Container Options that contains the aggregated routing metrics values for the route specified inP2P-RDO; * MAY carry one Data Option to carry any time-critical application data to the Origin, subject to the following conditions: if a Target chooses to include a Data Option inside a DRO, + it MUST includeP2P-RDO. An RPL Option, besides thesame Data Option in all retransmissions of this DRO message and + itones listed above, MUSTNOT include a different Data Option in any other DRO messages it generates for this route discovery. The Target MAY repeat the same Data Option in multiple DRO messages it generates forbe ignored when found inside aparticular route discovery. AreceivedDRO message MUST be discarded if it does not contain exactly one P2P-RDO or if it contains multiple Data Options.P2P-DRO message. 8.1. SecureDROP2P-DRO A SecureDROP2P-DRO message follows the format in Figure 7 of [RFC6550], where the base format is the baseDROP2P-DRO shown in Figure3.2. 8.2. Setting a P2P-RDO Carried in a P2P Discovery Reply Object A P2P Discovery Reply Object MUST carry one (and only one) P2P-RDO, which MUST be set as defined in Section7.1.7. Specifically, the following fields MUST be set as specified next: o Reply (R): This flag MUST be set to zero on transmission and ignored on reception. o Hop-by-Hop (H): The H flag in the P2P-RDO included in aDROP2P-DRO message MUST have the same value as the H flag in the P2P-RDO inside the corresponding DIO message. o Number of Routes (N): This field MUST be set to zero on transmission and ignored on reception. o Life Time (L): This field MUST be set to zero on transmission and ignored on reception. o MaxRank/NH: This field indicates the index of the next hop address in the Address vector. When a Target generates aDROP2P-DRO message, the NH field is set to n = (Option Length - 2 - (16 - Compr))/(16 - Compr). o TargetAddr: This field MUST contain a unicast global or unique local IPv6 address of the Target generating theDRO.P2P-DRO. o Address[1..n]: The Address vector MUST contain a complete route between the Origin and the Target such that the first element in the vector contains the IPv6 address of the router next to the Origin and the last element contains the IPv6 address of the router next to the Target. 9. P2P-RPL Route Discovery By Creating a Temporary DAG This section details the P2P-RPL route discovery operation. 9.1. Joining a Temporary DAG All the routers participating in a P2P-RPL route discovery, including the Origin and the Target(s), MUST join the temporary DAG being created for the purpose. When a router joins a temporary DAG advertized by a P2P mode DIO, it MUST maintain its membership in the temporary DAG for theLife Timedurationlisted inindicated by the L field inside the P2P-RDO. The only purpose of a temporary DAG's existence is to facilitate theP2P- RPLP2P-RPL route discovery process. The temporary DAG MUST NOT be used to route data packets. In other words, joining a temporary DAG does not allow a router to provision routing table entries listing the router's parents in the temporary DAG as the next hops (i.e., the last bullet point in Section 3.2.8 of [RFC6550] is not applicable when the DAG is a temporary DAG created for the purpose of a P2P-RPL route discovery.). Given the nature of a temporary DAG created for a P2P-RPL route discovery, this document disallows the solicitation of P2P mode DIOs using DODAG Information Solicitation (DIS) messages as described in [RFC6550]. A router participating in a P2P-RPL route discovery MUST NOT reset its Trickle timer that controls the transmission of P2P mode DIOs in response to a multicast DIS. Also, the router MUST NOT send a P2P mode DIO in response to a unicast DIS. In other words, the rules in Section 8.3 of [RFC6550] regarding a router's response to a multicast/unicast DIS are not applicable for P2P mode DIOs. A router MUST detach from the temporary DAG created for a P2P-RPL route discovery once the duration of its membership in the DAG has reached theDAG's life time.value indicated by the L field inside the P2P-RDO. After receiving aDROP2P-DRO with the Stop flag set to one, a router SHOULD NOT send orreceiveprocess any more DIOs for this temporary DAG and SHOULD also cancel any pending DIO transmission. 9.2. Trickle Operation For P2P Mode DIOs An RPL router uses a Trickle timer [RFC6206] to control DIO transmissions. The Trickle control of DIO transmissions provides quick resolution of any "inconsistency" while avoiding redundant DIO transmissions. The Trickle algorithm also imparts protection against loss of DIOs due to inherent lack of reliability in LLNs. When controlling the transmissions of a P2P mode DIO, a Trickle timer SHOULD follow the following rules: o The receipt of a P2P mode DIO, that allows the router to advertise a better route (in terms of the routing metrics and the OF in use) than before, is considered "inconsistent" and hence resets the Trickle timer. Note that the first receipt of a P2P mode DIO advertising a particular temporary DAG is always considered an "inconsistent" event. o The receipt of a P2P mode DIO from a parent in the temporary DAG is considered neither "consistent" nor "inconsistent" if it does not allow the router to advertise a better route than before. Thus, the receipt of such DIOs has no impact on the Trickle operation. Note that this document does not impose any requirements on how a router might choose its parents in the temporary DAG. o The receipt of a P2P mode DIO is considered "consistent" if the source of the DIO is not a parent in the temporary DAG and either of the following conditions is true: * The DIO advertises a better route than the router but does not allow the router to advertise a better route itself; or * The DIO advertises a route as good as the route (to be) advertised by the router. Note that the Trickle algorithm's DIO suppression rules are in effect at all times. Hence, a P2P-RPL router may suppress a DIO transmission even if it has not made any DIO transmission yet. o The receipt of a P2P mode DIO, that advertises a worse route than what the router advertises (or would advertise when it gets a chance to generate its DIO), is considered neither "consistent" nor "inconsistent", i.e., the receipt of such a DIO has no impact on the Trickle operation. o The Imin parameter SHOULD be set taking in account the connectivity within the network. For highly connected networks, a small Imin value (of the order of the typical transmission delay for a DIO) may lead to congestion in the network as a large number of routers reset their Trickle timers in response to the first receipt of a DIO from the Origin. These routers would generate their DIOs within Imin interval and cause additional routers to reset their trickle timers and generate more DIOs. Thus, for highly connected networks, the Imin parameter SHOULD be set to a value at least one order of magnitude larger than the typical transmission delay for a DIO. For sparsely connected networks, the Imin parameter can be set to a value that is a small multiple of the typical transmission delay for a DIO. Note that the Imin value has a direct impact on the time required for a P2P-RPL route discovery to complete. In general, the time required for a P2P- RPL route discovery would increase approximately linearly with the value of the Imin parameter. Since the route discovery must completewithinwhile thelifetime ofOrigin still belongs to the temporary DAG created for the purpose, the Origin should setthis lifetimethe time duration a router maintains its membership in the temporary DAG (indicated by the L field inside the P2P-RDO) to a large enough value taking in account the Imin value as well as the expected distance (in terms of hops and/or ETX) to the Target(s). o The Imax parameter SHOULD be set to a large value (several orders of magnitude higher than the Imin value) and is unlikely to be critical for P2P-RPL operation. This is because the first receipt of a P2P mode DIO for a particular temporary DAG is considered an inconsistent event and would lead to resetting of Trickle timer duration to the Imin value. Given the temporary nature of the DAGs used in P2P-RPL, Trickle timer may not get a chance to increase much. o The recommended value of redundancy constant "k" is 1. With this value of "k", a DIO transmission will be suppressed if the router receives even a single "consistent" DIO during a timer interval. This setting for the redundancy constant is designed to reduce the number of messages generated during a route discovery process and is suitable for the environments with low or moderate packet loss rates. However, this setting may result in an increase in the time required for the route discovery process to complete. A higher value for the redundancy constant may be more suitable in * Environments with high packet loss rates; or * Deployments where the time required for the route discovery process to complete needs to be as small as possible; or * Deployments where specific destinations are reachable only through specific intermediate routers (and hence these intermediate routers should not suppress their DIOs). A particular deployment should take in account the above mentioned factors when deciding the value of the redundancy constant. Individual P2P-RPL deployments are encouraged to share their experience with these ruleswith ROLL working groupto help guide the development of standards track version of the protocol. Applicability Statements that specify the use of P2P-RPL MUST provide guidance for setting Trickle parameters, particularly Imin and the redundancy constant. 9.3. Processing a P2P Mode DIO The rules for DIO processing and transmission, described in Section 8 of RPL [RFC6550], apply to P2P mode DIOs as well except as modified in this document. In particular, in accordance with Section 8.2.3 of RPL [RFC6550], a received P2P mode DIO MUST be discarded if it is malformed according to the rules specified in this document and in [RFC6550]. The following rules for processing a received P2P mode DIO apply to both Intermediate Routers and the Target. A router SHOULD discard a received P2P mode DIO with no further processing if it does not have bidirectional reachability with the neighbor that generated the received DIO. Note that bidirectional reachability does not mean that the link must have the same values for a routing metric in both directions. A router SHOULD calculate the values of the link-level routing metrics included in the received DIO taking in account the metric's value in both Forward and Reverse directions. Bidirectional reachability along a discovered route allows the Target to use this route to reach the Origin. In particular, theDROP2P-DRO messages travel from the Target to the Origin along a discovered route. A router MUST discard a received P2P mode DIO with no further processing: o If the DIO advertises INFINITE_RANK as defined in Section 17 of [RFC6550]. o If the integer part of the rank advertised in the DIO equals or exceeds the MaxRank limit listed in the P2P Route Discovery Option. o If the routing metric values do not satisfy one or more of the mandatory route constraints listed in the DIO or if the router cannot evaluate the mandatory route constraints, e.g., if the router does not support the metrics used in the constraints. o If the router previously received aDROP2P-DRO message with the same RPLInstanceID and DODAGID as the received DIO and with the Stop flag set to one. The router MUST check the Target addresses listed in the P2P-RDO and any RPL Target Options included in the received DIO. If one of its IPv6 addresses is listed as a Target address or if it belongs to the multicast group specified as one of the Target addresses, the router considers itself a Target and processes the received DIO as specified in Section 9.5. Otherwise, the router considers itself an Intermediate Router and processes the received DIO as specified in Section 9.4. 9.4. Additional Processing of a P2P Mode DIO At An Intermediate Router An Intermediate Router MUST discard a received P2P mode DIO with no further processing o if therouter cannot elideDIO is received on an Ingress-only Interface; or o if the receiving interface does not have a global or unique local IPv6 address configured with the address prefix implied by the Compr(as specifiedfield in theP2P-RDO)P2P-RDO inside the received DIO; or o if the router can not uniquely identify the address prefixoctets from itsimplied by the Compr field in the P2P-RDO (this might happen if the receiving interface has multiple global/unique-local IPv6 addresses, each configured with a different address prefix); or o if adding its IPv6 address to the route in the Address vector(insideinside theP2P-RDO)P2P-RDO would result in theAddress vectorroute containingmultiple, non-back-to-backmultiple addresses belonging to this router. On receiving a P2P mode DIO, an Intermediate Router MUST do thefollowing: ofollowing. The router MUST determine whether this DIO advertises a better route than the router itself and whether the receipt of the DIO would allow the router to advertise a better route than before. Accordingly, the router SHOULD consider this DIO as consistent/ inconsistent from Trickle perspective as described in Section 9.2. Note that the route comparison in a P2P-RPL route discovery is performed using the parent selection rules of the OF in use as specified in Section 14 of RPL [RFC6550]. If the received DIO would allow the router to advertise a better route, the router MUSTrememberadd a unicast IPv6 address of theroute advertised (insidereceiving interface (after eliding Compr prefix octets) to theP2P-RDO)route in theDIO (after adding its own IPv6 address toAddress vector inside theroute)P2P-RDO and remember this route for inclusion in its future DIOs. When an Intermediate Router addsitselfan IPv6 address to a route, it MUST ensure that o the IPv6 addressaddedis a unicast global or unique local IPv6 address assigned to the interface on which the DIO containing the routedoes not belong to an ingress-only or an egress-only interface.was received; o the IPv6 address was configured with the address prefix implied by the Compr field in the P2P-RDO inside the received DIO; To improve the diversity of the routes being discovered, an Intermediate Router SHOULD keep track of multiple routes (as long as all these routes are the best seen so far), one of which SHOULD be selected in a uniform random manner for inclusion in theP2P- RDOP2P-RDO inside the router's next DIO. Note that the route accumulation in a P2P mode DIO MUST take place even if the Origin does not want anyDROP2P-DRO messages to be generated (i.e., the R flag inside the P2P-RDO is set to zero). This is because the Target may still be able to use the accumulated route as a source route to reach the Origin.o The router MUST copy any Data Option (to be included in its future DIO transmissions) if the received DIO comes from a parent and is the first parent-originated DIO received with a Data Option inside.9.5. Additional Processing of a P2P Mode DIO At The Target The TargetMUST determine if the received DIO contains a Data Option and deliver the data to the specified upper layer protocol unless it has already done so in response to a previously received DIO. If this route discovery involves multiple Targets, the Target MUST remember this Data Option for inclusion in its own DIOs. The TargetMAYstoreremember the discovered route contained in the P2P-RDO in the received DIO for use as a Source Route to reach the Origin. The lifetime of this Source Route is specified by the Default Lifetime and Lifetime Unit parameters inside the DODAG Configuration Option currently in effect. This lifetime can be extended (or shortened) appropriately following a hint from an upper-layer protocol. If the Reply flag inside the P2P-RDO in the received DIO iszero,set to one, the Target MUSTdiscard the received DIO with no further processing. Otherwise, the Target MAYselectthe route contained in the P2P-RDO toone or more discovered routes and senda DRO messageone or more P2P-DRO messages, carrying one discovered route each, back to the Origin. If the H flag inside the P2P-RDO is set to one, the Target needs to select one route and send aDROP2P-DRO message along this route back to the Origin. As this P2P-DRO message travels back to the Origin, the routers on the path establish hop-by-hop routing state, thereby establishing a Hop-by-hop Route in the Forward direction. If the H flag is set to zero, the number ofroutesSource Routes to be selected (and the number ofDROP2P-DRO messages to be sent back) is given by one plus the value of the N field in the P2P-RDO. The Target may select the discovered route inside the received DIO as (one of) the route(s) that would be carried inside a P2P-DRO message back to the Origin. This document does not prescribe a particular method for the Target to select the routes. Example methods include selecting each route that meets the specified routing constraints until the desired number have been selected or selecting the best routes discovered over a certain time period. If multiple routes are to be selected, the Target SHOULD avoid selecting routes that have large segments in common. If the Target selects the route contained in the P2P-RDO in the received DIO, it sends aDROP2P-DRO message back to the Origin (identified by the DODAGID field in the DIO). TheDROP2P-DRO message MUST include a P2P-RDO that contains the selected route inside the Address vector. Various fields inside the P2P-RDO MUST be set as specified in Section 8.2. The Target MAY set the A flag inside theDROP2P-DRO message to one if it desires the Origin to send back a P2P- DRO-ACK message on receiving theDRO.P2P-DRO. In this case, the Target waits forDRO_ACK_WAIT_TIMEP2P_DRO_ACK_WAIT_TIME duration for theDRO-ACKP2P-DRO-ACK message to arrive. Failure to receive theDRO-ACKP2P-DRO-ACK message within this time duration causes the Target to retransmit theDROP2P-DRO message. The Target MAY retransmit theDROP2P-DRO message in this fashion up toMAX_DRO_RETRANSMISSIONSMAX_P2P_DRO_RETRANSMISSIONS times. BothDRO_ACK_WAIT_TIMEP2P_DRO_ACK_WAIT_TIME andMAX_DRO_RETRANSMISSIONSMAX_P2P_DRO_RETRANSMISSIONS are configurable parameters to be decided based on the characteristics of individual deployments. Note that allDROP2P-DRO transmissions and retransmissions MUST take place while the Target is still a part of the temporary DAG created for the route discovery. A Target MUST NOT transmit aDROP2P-DRO if it no longer belongs to this DAG. The Target MAY set the Stop flag inside theDROP2P-DRO message to one if o this router is the only Target specified in the corresponding DIO, i.e., the corresponding DIO specified a unicast address of the router as the TargetAddr inside the P2P-RDO with no additional Targets specified via RPL Target Options; and o the Target has already selected the desired number of routes. The Target MAY include a Metric Container Option in theDROP2P-DRO message. This Metric Container contains the end-to-end routing metric values for the route specified in the P2P-RDO. The TargetMAY include one Data Option in the DRO message to carry time-critical application data for the Origin, subject to the conditions listed in Section 8. The TargetMUST transmit theDROP2P-DRO message via a link-local multicast. A Target MUST NOT forward a P2P mode DIO any further if no other Targets are to be discovered, i.e., if a unicast IPv6 address (of this Target) is specified as the TargetAddr inside the P2P-RDO and no additional Targets are specified via RPL Target Options inside the DIOs for this route discovery. Otherwise, the Target MUST generate DIOs for this route discovery as an Intermediate Router would. 9.6. Processing aDROP2P-DRO At An Intermediate Router If the DODAGID field in the receivedDROP2P-DRO does not list a router's own IPv6 address, the router considers itself an Intermediate Router and MUST process the received message in the following manner: o The router MUST discard the receivedDROP2P-DRO with no further processing if it does not belong to the temporary DAG identified by the RPLInstanceID and the DODAGID fields in theDRO.P2P-DRO. o If the Stop flag inside the receivedDROP2P-DRO is set to one, the router SHOULD NOT send or receive any more DIOs for this temporary DAG and SHOULD cancel any pending DIO transmission. o The router MUST ignore any Metric Containerand DataOptions contained in theDROP2P-DRO message. o If Address[NH] element inside the P2P-RDO lists the router's own unicast IPv6 address, the router is a part of the route carried in the P2P-RDO. In this case, the router MUST do the following: * To prevent loops, the router MUST discard theDROP2P-DRO message with no further processing if the Address vector in the P2P-RDO includes multiple IPv6 addresses assigned to the router's interfaces. * If the H flag inside the P2P-RDO is one, the router MUST store the state for the Forward Hop-by-hop route carried inside the P2P-RDO. This state consists of: + The RPLInstanceID and the DODAGID fields of theDRO.P2P-DRO. + The route's destination, the Target (identified by TargetAddr field inside P2P-RDO). + The IPv6 address of the next hop, Address[NH+1] (unless NH value equals the number of elements in the Address vector, in which case the Target itself is the next hop). This Hop-by-hop routing state MUST expire at the end of the lifetime specified by the Default Lifetime and Lifetime Unit parameters inside the DODAG Configuration Option used in P2P mode DIOs for this route discovery. * If the router already maintains a Hop-by-hop state listing the Target as the destination and carrying same RPLInstanceID and DODAGID fields as the receivedDROP2P-DRO and the next hop information in the state does not match the next hop indicated in the receivedDRO,P2P-DRO, the router MUST discard theDROP2P-DRO message with no further processing. Note that this situation would occur in the following two cases: + When the route listed in the Address vector inside the P2P- RDO contains a previously undetected loop. In this case, the rule above causes theDROP2P-DRO messages to be discarded. + When a Hop-by-hop Route between the Origin and the Target, previously established using the same RPLInstanceID and DODAGID as the route currently being established, still exists and at least partially overlaps the route currently being established. * The router MUST decrement the NH field inside the P2P-RDO and send theDROP2P-DRO message further via link-local multicast. 9.7. Processing aDROP2P-DRO At The Origin When a router receives aDROP2P-DRO message that lists its IPv6 address in the DODAGID field, the router recognizes itself as the Origin for the corresponding P2P-RPL route discovery, notes the Target that originated this message (from the TargetAddr field inside the P2P- RDO) and processes the message in the following manner: o The Origin MUST discard the receivedDROP2P-DRO with no further processing if it no longer belongs to the temporary DAG identified by the RPLInstanceID and the DODAGID fields in theDRO. o If the received DRO contains a Data Option and if it has not already done so following the receipt of an earlier DRO from this Target, the Origin MUST deliver the data inside the Data Option to the specified upper layer protocol.P2P-DRO. o If the Stop flag inside the receivedDROP2P-DRO is set to one, the Origin SHOULD NOT generate any more DIOs for this temporary DAG and SHOULD cancel any pending DIO transmission. o If the P2P-RDO inside theDROP2P-DRO has the H flag set to 0, the Address vector inside the P2P-RDO contains a Source Route to thisTarget and theTarget. The Origin MUSTstore this Source Route in its memory. Theset the lifetime of this Source Routeisto the value specified by the Default Lifetime and Lifetime Unit parameters inside the DODAG Configuration Option in the P2P mode DIOs used for this route discovery. This lifetime could be extended (or shortened) appropriately following a hint from an upper-layer protocol. o If the P2P-RDO inside theDROP2P-DRO has the H flag set to 1, theDROP2P-DRO message is establishing a Hop-by-hop Route to this Target and the Origin MUST store in its memory the state for thisHop-by-hopHop-by- hop Route in the manner described in Section 9.6. This Hop-by-hop routing state MUST expire at the end of the lifetime specified by the Default Lifetime and Lifetime Unit parameters inside the DODAG Configuration Option used in P2P mode DIOs for this route discovery. The standards track version of P2P-RPL may consider specifying a signaling mechanism that will allow the Origin to extend (or shorten) the lifetime of a P2P-RPL Hop-by-hop Route following a suitable hint from an upper-layer protocol. o If the receivedDROP2P-DRO message contains one or more Metric Container Options, the Origin MAY store the values of the routing metrics associated with the discovered route in its memory. This information may be useful in formulating the constraints for any future P2P-RPL route discovery to this Target. o If the A flag is set to one in the receivedDROP2P-DRO message, the Origin MUST generate aDRO-ACKP2P-DRO-ACK message as described in Section 10 and unicast the message to the Target. The Origin MAY use the route just discovered to send theDRO-ACKP2P-DRO-ACK message to the Target. Section1112 describes how a packet may be forwarded along aSource/ Hop-by-hopSource/Hop-by-hop Route discovered using P2P-RPL. 10. The P2P Discovery Reply Object Acknowledgement(DRO-ACK)(P2P-DRO-ACK) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPLInstanceID | Version |Seq| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | DODAGID | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure4:3: Format of the base P2P Discovery Reply Object Acknowledgement(DRO-ACK)(P2P-DRO-ACK) ADROP2P-DRO message may fail to reach the Origin due to a number of reasons. Unlike the DIO messages that benefit from Trickle- controlled retransmissions, theDROP2P-DRO messages are prone to loss due to unreliable packet transmission in LLNs. Since aDROP2P-DRO message travels via link-local multicast, it cannot use link-level acknowledgements to improve the reliability of its transmission. Also, an Intermediate Router may drop theDROP2P-DRO message (e.g., because of its inability to store the state for the Hop-by-hop Route theDROP2P-DRO is establishing). To protect against the potential failure of aDROP2P-DRO message to reach the Origin, the Target MAY request the Origin to send back aDROP2P-DRO Acknowledgement(DRO-ACK)(P2P-DRO- ACK) message on receiving aDROP2P-DRO message. Failure to receive such an acknowledgement within theDRO_ACK_WAIT_TIMEP2P_DRO_ACK_WAIT_TIME interval of sending theDROP2P-DRO message forces the Target to resend themessage.message (as described in Section 9.5). This section defines two new RPL Control Message types:DROP2P-DRO Acknowledgement(DRO-ACK;(P2P-DRO-ACK; with codeTBD6)TBD5) and SecureDRO-ACKP2P-DRO-ACK (with codeTBD7).TBD6). ADRO-ACKP2P-DRO-ACK message MUST travel as a unicast message from the Origin to the Target. The IPv6 source and destination addresses used in a P2P-DRO-ACK message MUST be global or unique local. The format of a baseDRO-ACKP2P-DRO-ACK message is shown in Figure4.3. Various fields in aDRO-ACKP2P-DRO-ACK message MUST have the same values as the corresponding fields in theDROP2P-DRO message. The field marked as "Reserved" MUST be set to zero on transmission and MUST be ignored on reception. A SecureDRO-ACKP2P-DRO-ACK message follows the format in Figure 7 of [RFC6550], where the base format is same as the baseDRO-ACKP2P-DRO-ACK shown in Figure4.3. 11. Secure P2P-RPL Operation Each RPL control message type, including the ones defined in this document, has a secure version. A secure RPL control message is identified by the value 1 in the most significant bit of the Code field. Each secure RPL control message contains a security section (see Figure 7 of [RFC6550]), whose contents are described in Section 6.1 of [RFC6550]. Sections 6.1, 10 and 19 of [RFC6550] describe core RPL's security apparatus. These sections are applicable to P2P-RPL's secure operation as well except as constrained in this section. Core RPL allows a router to decide locally on a per-packet basis whether to use security and if yes what Security Configuration (see definition in Section 3) to use (the only exception being the requirement to send a Secure DIO in response to a Secure DIS; see Section 10.2 of [RFC6550]). In contrast, this document requires routers participating in a P2P-RPL route discovery to follow the Origin's lead regarding security. The Origin decides whether to use security and the particular Security Configuration to be used for this purpose. All the routers participating in this route discovery MUST generate only secure control messages if the Origin decides so and MUST use for this purpose the Security Configuration that the Origin chose. The Origin MUST NOT set the "Key Identifier Mode" field inside the chosen Security Configuration to value 1 since this setting indicates the use of a per-pair key which is not suitable for securing messages that travel by (link local) multicast (e.g. DIOs) or that travel over multiple hops (e.g. P2P-DROs). The Origin MUST use the chosen Security Configuration to secure all the control messages (DIOs and P2P-DRO-ACKs) it generates. A router MUST NOT join the temporary DAG being created for a P2P-RPL route discovery if: o it receives both secure and unsecure DIOs or Secure DIOs with different Security Configurations pertaining to this route discovery (i.e., referring to the same RPLInstanceID and DODAGID combination) prior to joining; or o it can not use the Security Configuration found in the Secure DIOs pertaining to this route discovery. When a router (an Intermediate Router or a Target) joins a temporary DAG being created using Secure DIOs, it MUST remember the common Security Configuration used in the received Secured DIOs and MUST use this configuration to secure all the control messages (DIOs and P2P- DROs) it generates. If an Intermediate Router (or a Target) encounters a control message (a DIO or a P2P-DRO or a P2P-DRO-ACK) pertaining to this route discovery that is either not secure or does not follow the Security Configuration the router remembers for this route discovery, the router MUST enter the "lock down" mode for the remainder of its stay in this temporary DAG. An Intermediate Router (or a Target) in the "lock down" mode MUST NOT generate or process any control message (irrespective of the Security Configuration used) pertaining to this route discovery. If the Origin receives a control message (a P2P- DRO) that does not follow the Security Configuration the Origin has chosen for this route discovery, it MUST discard the received message with no further processing. 12. Packet Forwarding Along a Route Discovered Using P2P-RPL An OriginMAY use auses the Source Routing Header (SRH) [RFC6554] to send a packet along a Source Route discovered using P2P-RPL. Travel along a Hop-by-hop Route, established using P2P-RPL, requires specifying the RPLInstanceID and the DODAGID (of the temporary DAG used for the route discovery) to identify the route. This is because a P2P-RPL route discovery does not use globally unique RPLInstanceID values and hence both the RPLInstanceID (a local value assigned by the Origin) and the DODAGID (an IPv6 address of the Origin) are required to uniquely identify a P2P-RPL Hop-by-hop Route to a particular destination. An OriginMAY includeincludes an RPL option [RFC6553] inside the IPv6hop-by- hophop-by-hop options header of a packet to send it along a Hop-by-hop Route established using P2P-RPL. For this purpose, the Origin MUST set the DODAGID of the temporary DAG used for the route discovery as the source IPv6 address of the packet. Further, the Origin MUST specify inside the RPL option the RPLInstanceID of the temporary DAG used for the route discovery and set the O flag inside the RPL option to one. On receiving this packet, an Intermediate Router checks the O flag and correctly infer the source IPv6 address of the packet as the DODAGID of the Hop-by-hop Route. The router then uses the DODAGID, the RPLInstanceID and the destination address to identify the routing state to be used to forward the packet further.12.13. Interoperability with Core RPL This section describes how RPL routers that implement P2P-RPL interact with RPL routers that do not. In general, P2P-RPL operation does not affect core RPL operation and vice versa. However, core RPL does allow a router to join a DAG as a leaf node even if it does not understand the Mode of Operation (MOP) used in the DAG. Thus, an RPL router that does not implement P2P-RPL may conceivably join a temporary DAG being created for a P2P-RPL route discovery as a leaf node and maintain its membership even though the DAG no longer exists. This may impose a drain on the router's memory. However, such RPL-only leaf nodes do not interfere with P2P-RPL route discovery since a leaf node may only generate a DIO advertising an INFINITE_RANK and all routers implementing P2P-RPL are required to discard such DIOs. Note that core RPL does not require a router to join a DAG whose MOP it does not understand. Moreover, RPL routers in a particular deployment may have strict restrictions on the DAGs they may join, thereby mitigating the problem. The P2P-RPL mechanism described in this document works best when all the RPL routers in the LLN implement P2P-RPL. In general, the ability to discover routes as well as the quality of discovered routes would deteriorate with the fraction of RPL routers that implement P2P-RPL.13.14. Security ConsiderationsA P2P-RPL deployment may be susceptible to denial of service attacks by rogue routers that initiate fake route discoveries. A rogue router could join a temporary DAG and advertise false information in its DIOs in order to include itself in the discovered route(s). It could generate bogus DRO messages carrying bad routes or maliciously modify genuine DRO messages it receives.In general, the security considerations for the operation of P2P-RPL are similar to the ones for the operation of RPL (as described in Section 19 of [RFC6550]).SectionSections 6.1 and 10 of RPL specification [RFC6550]describes a variety ofdescribe RPL's securitymechanismsframework thatprovideprovides data confidentiality, authentication, replay protection and delay protection services.Each RPL control message hasThis security framework can also be used in P2P-RPL after taking in account the constraints specified in Section 11. P2P-RPL requires all routers participating in a secureversion that allows the specification ofroute discovery to use thelevel of security andSecurity Configuration decided by thealgorithms usedOrigin. The intention is tosecureavoid compromising themessage. The mechanism definedoverall security of a route discovery due to some routers using a weaker Security Configuration. With "lock down" mechanism, described inthis documentSection 11, in effect, it isbased onunlikely that an Origin would accept a route discovered under a Security Configuration other than the one it intended. Any attempt to useof DIOsa different Security Configuration (than the one the Origin intended) is likely toformresult, in the worst case, in the failure of the route discovery process. In the best case scenario, any such attempt by atemporary DAGrogue router would result in its neighbors entering the "lock down" mode anddiscover P2P routes. These DIOs can be usedacting as firewalls to allow the route discovery to proceed intheir secure versions if desired. Newthe remaining network. RPL specification describes three modes of security: unsecured, pre- installed and authenticated. In the unsecured mode, secure control messagesdefined in this document (DROare not used andDRO-ACK) have secure versions as well. In addition, a P2P-RPL deployment may usethe only available securityfeaturesis the one provided by the link layerin use. Thus,protocols. In the pre-installed mode, all the nodes use aparticular P2P-RPL deployment can analyzepre-installed group key to join a secure DAG as the "routers" or "hosts", where the term "router" means a node that is capable of forwarding packets received from itssecurity requirementsparents or children in the DAG andusetheappropriate set of RPL (or link layer) security mechanisms that meet those requirements. Noteterm "host" refers to nodes that can not function as "routers". In thecontents of the Data Option, if used, hasauthenticated mode, thesame level of securitynodes can join a secure DAG as "hosts" using theDIO/DRO messagepre-installed key but then need to authenticate themselves to a key server to obtain the key that will allow them to work as "routers". The temporary DAG created for a P2P-RPL discovery can not be used for routing packets. Hence, it ispart of.not meaningful to say that a node joins this DAG as a "router" or a "host" in the sense defined above. Hence, in P2P-RPL, there is no distinction between the pre-installed and authenticated modes. A router can join a temporary DAG created for a secure P2P-RPLdeployment SHOULD takeroute discovery only if it can support the Security Configuration inconsiderationuse, which also specifies thesecurity requirementskey in use. It does not matter whether the key is pre-installed or dynamically acquired. The router must have the key in use before it can join the DAG beiing created for a secure P2P-RPL route discovery. If a rogue router can support the Security Configuration in use (in particular, it knows the key in use), it can join the secure P2P-RPL route discovery and cause a variety of damage. Such a rogue router could advertise false information in its DIOs in order to include itself in thedata being sent insidediscovered route(s). It could generate bogus P2P-DRO messages carrying bad routes or maliciously modify genuine P2P-DRO messages it receives. A rogue router acting as theData Options when decidingOrigin could launch denial of service attacks against theoverall security requirements.LLN deployment by initiating fake P2P-RPL route discoveries. Here, RPL's authenticated mode operation would be useful, where a node can obtain the key to use for a P2P-RPL route discovery only after proper authentication. Since aDROP2P-DRO message travels along a Source Route specified inside the message, some of the security concerns that led to the deprecation of Type 0 routing header [RFC5095] may apply. To avoid the possibility of aDROP2P-DRO message traveling in a routing loop, this document requires each Intermediate Router to confirm that the Source Route listed inside the message does not contain any routing loop involving itself before the router could forward the message further. As specified in Section 9.6, this check involves the router making sure that its IPv6 addresses do not appear multiple times inside the Source Route with one or more other IPv6 addresses in between.14.15. IANA Considerations14.1.15.1. Additions to Mode of Operation This document defines a new Mode of Operation, entitled "P2P Route Discovery Mode" (see Section 6), assigned a value TBD1 from the "Mode of Operation" space [to be removed upon publication: 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 | +-------+---------------------------------------+---------------+ | TBD1 | P2P Route Discovery Mode of Operation | This document | +-------+---------------------------------------+---------------+ Mode of Operation14.2.15.2. Additions to RPL Control Message Options This document definestwoa new RPLoptions: ooption: "P2P Route Discovery Option" (see Section7.1),7), assigned a value TBD2 from the "RPL Control Message Options" space [to be removed upon publication:http://www.iana.org/assignments/rpl/ rpl.xml#control-message-options]http://www.iana.org/assignments/rpl/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 TBD3 from the "RPL Control Message Options" space [to be removed upon publication: http://www.iana.org/assignments/rpl/ 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 | +-------+---------------------+---------------+ | TBD2 | P2P Route Discovery | This document || TBD3 | Data | This document |+-------+---------------------+---------------+ RPL Control Message Options14.3.15.3. Additions to RPL Control Codes This document defines the following new RPL messages: o"Discovery"P2P Discovery Reply Object" (see Section 8), assigned a valueTBD4TBD3 from the "RPL Control Codes" space [to be removed upon publication: http://www.iana.org/assignments/rpl/rpl.xml#control-codes] [RFC6550]. IANA is requested to allocateTBD4TBD3 from the range 0x00-0x7F to indicate a message without security enabled. The stringTBD4TBD3 in this document should be replaced by the allocated value. The previous two sentences should be removed before publication. o "Secure P2P Discovery Reply Object" (see Section 8.1), assigned a valueTBD5TBD4 from the "RPL Control Codes" space [to be removed upon publication: http://www.iana.org/assignments/rpl/rpl.xml#control-codes] [RFC6550]. IANA is requested to allocateTBD5TBD4 from the range 0x80-0xFF to indicate a message with security enabled. The stringTBD5TBD4 in this document should be replaced by the allocated value. The previous two sentences should be removed before publication. o"Discovery"P2P Discovery Reply Object Acknowledgement" (see Section 10), assigned a valueTBD6TBD5 from the "RPL Control Codes" space [to be removed upon publication: http://www.iana.org/assignments/rpl/rpl.xml#control-codes] [RFC6550]. IANA is requested to allocateTBD6TBD5 from the range 0x00-0x7F to indicate a message without security enabled. The stringTBD6TBD5 in this document should be replaced by the allocated value. The previous two sentences should be removed before publication. o "Secure P2P Discovery Reply Object Acknowledgement" (see Section 10), assigned a valueTBD7TBD6 from the "RPL Control Codes" space [to be removed upon publication: http://www.iana.org/assignments/rpl/rpl.xml#control-codes] [RFC6550]. IANA is requested to allocateTBD7TBD6 from the range 0x80-0xFF to indicate a message with security enabled. The stringTBD7TBD6 in this document should be replaced by the allocated value. The previous two sentences should be removed before publication.+------+--------------------------------------------+---------------++------+---------------------------------------------+--------------+ | Code | Description | Reference |+------+--------------------------------------------+---------------++------+---------------------------------------------+--------------+ |TBD4TBD3 | P2P Discovery Reply Object | This | | | | document | |TBD5TBD4 | Secure P2P Discovery Reply Object | This | | | | document | |TBD6TBD5 | P2P Discovery Reply Object Acknowledgement | This | | | | document | |TBD7TBD6 | Secure P2P Discovery Reply Object | Thisdocument| | | Acknowledgement | document |+------+--------------------------------------------+---------------++------+---------------------------------------------+--------------+ RPL Control Codes15.16. Acknowledgements Authors gratefully acknowledge the contributions of the following individuals (in alphabetical order) in the development of this document: Dominique Barthel, Jakob Buron, Cedric Chauvenet, Thomas Clausen, Robert Cragie, Ralph Droms, Adrian Farrel, Stephen Farrell, Brian Haberman, Ted Humpal, Richard Kelsey, Phil Levis, Charles Perkins, Joseph Reddy, Michael Richardson, Zach Shelby, Martin Stiemerling, Pascal Thubert, Hristo Valev and JP Vasseur.16.17. References16.1.17.1. Normative References[PROTOCOL] "Protocol Numbers", <http://www.iana.org/assignments/ protocol-numbers/protocol-numbers.xml>.[I-D.ietf-roll-terminology] Vasseur, J., "Terminology in Low power And Lossy Networks", draft-ietf-roll-terminology-10 (work in progress), January 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, "The Trickle Algorithm", RFC 6206, March 2011. [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012. [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. Barthel, "Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks", RFC 6551, March 2012.16.2.17.2. Informative References [I-D.ietf-roll-p2p-measurement] Goyal, M., Baccelli, E., Brandt, A., and J. Martocci, "A Mechanism to Measure the Routing Metrics along a Point-to- point Route in a Low Power and Lossy Network",draft-ietf-roll-p2p-measurement-08draft-ietf-roll-p2p-measurement-09 (work in progress),JanuaryFebruary 2013. [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, December 2007. [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5826, April 2010. [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, "Building Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5867, June 2010. [RFC6552] Thubert, P., "Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6552, March 2012. [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams", RFC 6553, March 2012. [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6554, March 2012. Authors' Addresses Mukul Goyal (editor) University of Wisconsin Milwaukee 3200 N Cramer St Milwaukee, WI 53201 USA Phone: +1 414 2295001 Email: mukul@uwm.edu Emmanuel Baccelli INRIA Phone: +33-169-335-511 Email: Emmanuel.Baccelli@inria.fr URI: http://www.emmanuelbaccelli.org/ Matthias Philipp INRIA Phone: +33-169-335-511 Email: Matthias.Philipp@inria.fr Anders Brandt Sigma Designs Emdrupvej 26A, 1. Copenhagen, Dk-2100 Denmark Phone: +45-29609501 Email: abr@sdesigns.dk Jerald Martocci Johnson Controls 507 E Michigan St Milwaukee, WI 53202 USA Phone: +1 414-524-4010 Email: jerald.p.martocci@jci.com