On Dec 22, 2011, at 9:24 AM, Mukul Goyal wrote: >> Again, just because you received a message on an interface for which you've >> enabled RPL doesn't mean you know the message came from a router that is >> within the same RPL routing domain. A router not running RPL could have >> sent you that message. > > A router not running RPL could have sent me a message carrying SRH?
Sure. It could be a host as well. Part of limiting the scope is to limit the scope of an attack. See the Security Considerations. >> From Section 3.2.1 of draft-ietf-roll-rpl: > > The Objective Function (OF) defines how RPL nodes select and optimize > routes within a RPL Instance. The OF is identified by an Objective > Code Point (OCP) within the DIO Configuration option. An OF defines > how nodes translate one or more metrics and constraints, which are > themselves defined in [I-D.ietf-roll-routing-metrics], into a value > called Rank, which approximates the node's distance from a DODAG > root. An OF also defines how nodes select parents. Further details > may be found in Section 14, [I-D.ietf-roll-routing-metrics], > [I-D.ietf-roll-of0], and related companion specifications. > >> As you state, RPL Instance maps to OF which, from the cited text, maps to >> metrics and route selection. By transitivity, RPL Instance ID does map to >> metrics and how routes are formed. > > The text you quoted no where says that an OF maps to particular metric. OF0 > is metrics-independent. OF1 (draft-ietf-roll-minrank-hysteresis-of-04) > applies to any additive metric. No RPL doc says that, for a particular LLN, a > particular OF maps to a particular metric only. Incorrect. From draft-ietf-roll-routing-metrics-19: The set of routing metrics and constraints used by an RPL deployment is signaled along the DAG that is built according to the Objective Function (rules governing how to build a DAG) and the routing metrics and constraints are advertised in the DAG Information Option (DIO) message specified in [I-D.ietf-roll-rpl]. In other words, the combination of the OCP and the metrics identified by the DODAG Root describes how to optimize the routes. In the case of OF0, the metric is the Rank itself. > I think the following text clearly specifies what an RPL Instance is. Also, > this text clearly says that an RPL Instance ID maps to a particular OF: > > rpl-19 section 3.1.2: > A RPLInstanceID identifies a set of > one or more Destination Oriented DAGs (DODAGs). A network may > have multiple RPLInstanceIDs, each of which defines an independent > set of DODAGs, which may be optimized for different Objective > Functions (OFs) and/or applications. The set of DODAGs identified > by a RPLInstanceID is called a RPL Instance. All DODAGs in the > same RPL Instance use the same OF. > > This definition says an RPLInstanceID identifies a set of DAGs with a common > OF. No more and no less. A particular LLN may choose to map an OF to a > particular metric but there is no such requirement as per RPL specs. You never answered my question. Why bother having a RPL Instance ID if you don't care how the routes are optimized? Why bother maintaining multiple paths optimized using different OFs and/or metrics? >>> RPL Instance is the top level identifier of the DAGs that can be used to >>> forward the packet. It also maps to a particular OF. In my opinion and as >>> per RPL spec, RPL instance has no other significance. > >> See above. RPL Instance does map to metrics. > > It need not. You are incorrect again! >> The definition I proposed was simply a collection of routers running RPL >> under the same administrative domain. As mentioned above, that does not >> mean that every router on an interface belongs to a RPL routing domain. > > I think the definition you provided is sufficient. An RPL domain is a > collection of routers running RPL under the same administrative domain. Each > router in the RPL domain needs to classify all its interfaces regarding > whether they belong to the RPL domain or not. > > A packet can be assumed to be coming from a router in the RPL domain if it > carries an SRH. Nope. As I stated before, that would invalidate the Security Considerations section. -- Jonathan Hui -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
