Subject: draft-ietf-6man-rpl-routing-header-07

From: "Park, Kundok" <[email-masked]>
Date: Mon, 19 Dec 2011 21:17:33 +0000

It seems that the following text on page 10 has some slight oversights:

"

   In order to respect the IPv6 Hop Limit value of the original

   datagram, a RPL router generating an SRH MUST set the Segments Left

   to no greater than the original datagram's IPv6 Hop Limit value upon

   forwarding.
"

should have been as follows:

"

   In order to respect the IPv6 Hop Limit value of the original

   datagram, a RPL router generating an SRH in an IPv6-in-IPv6 tunnel

   MUST set the Segments Left to less than the original datagram's IPv6

   Hop Limit value upon forwarding.
"

If the Segments Left is equal to Hop Limit value, the source route includes one more hop than the hop limit, which is not intended here.
The other change is to make clear that the above phrase does not apply to the case where the SRH is directly included within the original packet.

As a side note, the traceroute application doesn't seem to be able to handle the case with no tunnel use, because the original datagram destination address alters when SRH is added, unless, I guess, traceroute application is re-written to handle source routing in returned ICMPv6 error messages. Perhaps, that recommended direct inclusion of SRH should be removed?

Best Regards,
Kundok

---

From: "Park, Kundok" <[email-masked]>
Date: Mon, 19 Dec 2011 23:59:11 +0000

As another side note, this new draft revision creates a situation where the hop limit from the RPL router performing source routing may be one and hence it cannot use SRH (because Segments Left becomes zero and no address can be included). In order to make it appear as if it tried the source routing with one hop, I think the RPL router must forward the packet to the next hop that it should normally pick for a source routing without modifying the original packet (that is, the destination address remains the same as the final destination). I don't think this requires any change to the draft because the RPL router in this case is not using SRH and hence out of scope of this draft.

BR,
Kundok

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Park, Kundok
Sent: Monday, December 19, 2011 1:18 PM
To: [email-masked]
Subject: draft-ietf-6man-rpl-routing-header-07

"

   forwarding.
"

"

Best Regards,
Kundok

---

From: Mukul Goyal <[email-masked]>
Date: Tue, 20 Dec 2011 10:14:21 -0600 (CST)

Jonathan

The IESG-approved draft refers to the RPL instance as the scope where the routing header can be used. How would this routing header be used for general source routing (across RPL instances) in an LLN? How would a node use this routing header if it wants to travel along a source route discovered using P2P-RPL?

Thanks
Mukul

---

From: Robert Cragie <[email-masked]>
Date: Wed, 21 Dec 2011 13:25:30 +0000

Looks like I missed the boat, but I also had some comments on 
draft-ietf-6man-rpl-routing-header-07:

_More significant comments_

p7: RPL Instance ID - why is this needed for source routing? RPL is not 
even used for source routing. This flavors the SRH unnecessarily and the 
processing does not use it. If the reason is for checking entering and 
exiting a RPL domain, this processing needs to be stated.

p10: "In order to respect the IPv6 Hop Limit value of the original 
datagram, a RPL router generating an SRH MUST set the Segments Left to 
no greater than the original datagram's IPv6 Hop Limit value upon 
forwarding.". This language is confusing. 'upon forwarding' suggests 
that it is the 'IPv6 Hop Limit - 1' value, and again only if it is 
forwarded, but it is not clear. Also, an 'original datagram' may not 
always be *forwarded*, i.e. if it originates on the RPL router itself.

p10: "In the case that the source route is longer than the original 
datagram's IPv6 Hop Limit, only the initial hops (determined by the 
original datagram's IPv6 Hop Limit) should be included in the SRH.". 
This means it is unlikely to reach its destination, so why bother?

p10: "If the RPL router is not the source of the original datagram, the 
original datagram's IPv6 Hop Limit field is decremented before 
generating the SRH." If this were placed the the beginning of the 
paragraph, it might be clearer.

p10: "After generating the SRH, the RPL router decrements the original 
datagram's IPv6 Hop Limit value by the SRH Segments Left value.  
Processing the SRH Segments Left and original datagram's IPv6 Hop Limit 
fields in this way ensures that ICMPv6 Time Exceeded errors occur as 
would be expected on more traditional IPv6 networks that forward 
datagrams without tunneling." It's not really a tunnel then as defined 
by RFC 2473 and somewhat conflicts with what's written in RFC 2473. 
Also, you don't want to do this when the packet is not tunneled or you 
will be double counting.

_Minor (use of language) comments:_

Throughout: Inconsistent use of:

1. 'router'
2. 'RPL router'
3. 'RPL Router'

(3) (note capitalization) is a defined term. (1) and (2) are used 
generally but inconsistently. Use 'RPL router' to mean a 'RPL Border 
Router' or a 'RPL Router' throughout. Use 'a RPL router' as introductory 
to a sentence and, if necessary, 'the router' only to refer to the 
introduced RPL router, although 'the RPL router' is generally better. 
This would make the document clearer in places.

p1: "or few routers" -> "or a few routers". Reason for change: 'few 
routers' on its own implies 'not many routers'.

p6: "In the scenarios above, R may indicate a RPL Border Router (when 
connecting to other routing domains) or a RPL Router" -> "In the 
scenarios above, the RPL router R may indicate a RPL Border Router (when 
connecting to other routing domains) or a RPL Router". Reason for 
change: This introduces the term 'RPL router' as either a 'RPL Border 
Router' or a 'RPL Router' (note both are defined terms) correctly for 
the subsequent paragraph.

p6: "One such use case with RPL is to have all RPL traffic flow through 
a Border Router and have the Border Router use source routes to deliver 
datagrams to their final destination.  When including the SRH using 
tunneled mode, the Border Router would encapsulate the received datagram 
unmodified using IPv6-in-IPv6 and include a SRH in the outer IPv6 
header." -> "One such use case with RPL is to have all RPL traffic flow 
through a RPL Border Router and have the RPL Border Router use source 
routes to deliver datagrams to their final destination.  When including 
the SRH using tunneled mode, the RPL Border Router would encapsulate the 
received datagram unmodified using IPv6-in-IPv6 and include a SRH in the 
outer IPv6 header." Reason for change: Uses the correct terminology.

p6: "In the above scenario, datagrams travel from S to D through LBR" -> 
"In the above scenario, datagrams travel from S to D through the RPL 
Border Router LBR (referred to as LBRs in [I-D.ietf-roll-terminology])". 
Reason for change: Clarify what LBR is.

Robert

On 19/12/2011 11:59 PM, Park, Kundok wrote:
>
> As another side note, this new draft revision creates a situation 
> where the hop limit from the RPL router performing source routing may 
> be one and hence it cannot use SRH (because Segments Left becomes zero 
> and no address can be included). In order to make it appear as if it 
> tried the source routing with one hop, I think the RPL router must 
> forward the packet to the next hop that it should normally pick for a 
> source routing without modifying the original packet (that is, the 
> destination address remains the same as the final destination). I 
> don't think this requires any change to the draft because the RPL 
> router in this case is not using SRH and hence out of scope of this draft.
>
> BR,
>
> Kundok
>
> ------------------------------------------------------------------------
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf 
> Of *Park, Kundok
> *Sent:* Monday, December 19, 2011 1:18 PM
> *To:* [email-masked]
> *Subject:* draft-ietf-6man-rpl-routing-header-07
>
>     to_no greater_  than the original datagram's IPv6 Hop Limit value upon
>     forwarding.
>
> "
>
>     datagram, a RPL router generating an SRH_in an IPv6-in-IPv6 tunnel_
>     MUST set the Segments Left to_less_  than the original datagram's IPv6
> If the Segments Left is equal to Hop Limit value, the source route 
> includes one more hop than the hop limit, which is not intended here.
>
> The other change is to make clear that the above phrase does not apply 
> to the case where the SRH is directly included within the original packet.
>
> As a side note, the traceroute application doesn't seem to be able to 
> handle the case with no tunnel use, because the original datagram 
> destination address alters when SRH is added, unless, I guess, 
> traceroute application is re-written to handle source routing in 
> returned ICMPv6 error messages. Perhaps, that recommended direct 
> inclusion of SRH should be removed?
>
> Best Regards,
>
> Kundok
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 21 Dec 2011 07:51:33 -0800

Hi Robert,

Thanks for your review.  We'll try to address what we can in the next revision.  See below:

On Dec 21, 2011, at 5:25 AM, Robert Cragie wrote:

> Looks like I missed the boat, but I also had some comments on draft-ietf-6man-rpl-routing-header-07:
> 
> p7: RPL Instance ID - why is this needed for source routing? RPL is not even used for source routing. This flavors the SRH unnecessarily and the processing does not use it. If the reason is for checking entering and exiting a RPL domain, this processing needs to be stated.

Page 12 describes processing rules intended to keep the SRH within a RPL Instance.

> p10: "In order to respect the IPv6 Hop Limit value of the original datagram, a RPL router generating an SRH MUST set the Segments Left to no greater than the original datagram's IPv6 Hop Limit value upon forwarding.". This language is confusing. 'upon forwarding' suggests that it is the 'IPv6 Hop Limit - 1' value, and again only if it is forwarded, but it is not clear. Also, an 'original datagram' may not always be *forwarded*, i.e. if it originates on the RPL router itself.

"Upon forwarding" was intended to indicate "upon submitting to the proper interface for forwarding".  Would you prefer the RFC 2473 language: "during forwarding"?  We purposely did not indicate that it is the IPv6 Hop Limit - 1 value because, as you indicate, the original datagram may  originate on the router itself.

> p10: "In the case that the source route is longer than the original datagram's IPv6 Hop Limit, only the initial hops (determined by the original datagram's IPv6 Hop Limit) should be included in the SRH.". This means it is unlikely to reach its destination, so why bother?

To support traceroute, which was an application that ZigBee/IP members indicated was important.

> p10: "If the RPL router is not the source of the original datagram, the original datagram's IPv6 Hop Limit field is decremented before generating the SRH." If this were placed the the beginning of the paragraph, it might be clearer.

Agree.

> p10: "After generating the SRH, the RPL router decrements the original datagram's IPv6 Hop Limit value by the SRH Segments Left value.  Processing the SRH Segments Left and original datagram's IPv6 Hop Limit fields in this way ensures that ICMPv6 Time Exceeded errors occur as would be expected on more traditional IPv6 networks that forward datagrams without tunneling." It's not really a tunnel then as defined by RFC 2473 and somewhat conflicts with what's written in RFC 2473. Also, you don't want to do this when the packet is not tunneled or you will be double counting.

Agree that this is in conflict with RFC 2473, but necessary to support traceroute as requested by ZigBee/IP members.  We can add text that clearly states this difference with RFC 2473.

> (3) (note capitalization) is a defined term. (1) and (2) are used generally but inconsistently. Use 'RPL router' to mean a 'RPL Border Router' or a 'RPL Router' throughout. Use 'a RPL router' as introductory to a sentence and, if necessary, 'the router' only to refer to the introduced RPL router, although 'the RPL router' is generally better. This would make the document clearer in places.

Agree.

> p1: "or few routers" -> "or a few routers". Reason for change: 'few routers' on its own implies 'not many routers'.

Agree.

> p6: "In the scenarios above, R may indicate a RPL Border Router (when connecting to other routing domains) or a RPL Router" -> "In the scenarios above, the RPL router R may indicate a RPL Border Router (when connecting to other routing domains) or a RPL Router". Reason for change: This introduces the term 'RPL router' as either a 'RPL Border Router' or a 'RPL Router' (note both are defined terms) correctly for the subsequent paragraph.

Agree.

> p6: "One such use case with RPL is to have all RPL traffic flow through a Border Router and have the Border Router use source routes to deliver datagrams to their final destination.  When including the SRH using tunneled mode, the Border Router would encapsulate the received datagram unmodified using IPv6-in-IPv6 and include a SRH in the outer IPv6 header." -> "One such use case with RPL is to have all RPL traffic flow through a RPL Border Router and have the RPL Border Router use source routes to deliver datagrams to their final destination.  When including the SRH using tunneled mode, the RPL Border Router would encapsulate the received datagram unmodified using IPv6-in-IPv6 and include a SRH in the outer IPv6 header." Reason for change: Uses
> the correct terminology.

Agree.

> p6: "In the above scenario, datagrams travel from S to D through LBR" -> "In the above scenario, datagrams travel from S to D through the RPL Border Router LBR (referred to as LBRs in [I-
> D.ietf-roll-terminology])". Reason for change: Clarify what LBR is.

Agree.

Thanks again.

--
Jonathan Hui

---

From: Mukul Goyal <[email-masked]>
Date: Wed, 21 Dec 2011 11:24:27 -0600 (CST)

Hi Jonathan

I have serious issues with the use of RPL Instance as the domain for SRH.

>>[R Cragie]

>[J Hui]

Page 12 has no mention of RPL Instance. Page 13 does mention RPL Instance in the following rules:

   2.  Datagrams destined elsewhere within the same RPL Instance are
       forwarded to the correct interface.

   3.  Datagrams destined to nodes outside the RPL Instance are dropped
       if the outer-most IPv6 header contains a SRH not generated by the
       RPL router forwarding the datagram.

My question is how does a router know whether the next hop is within the same RPL Instance or not? A router has no idea what RPL Instances its neighbors belong to. 

It seems that a router, that receives a packet with a SRH, does not need to check if it belongs to the RPL Instance mentioned in the SRH. It just needs to check if the next hop belongs to that RPL Instance or not. And as I said in the prev para, I am not sure how would the router make that check.

It would be a problem if the router were required to check its own membership in the RPL Instance in order to accept a packet with SRH. Routers part of a source route should not need to maintain any state about it. 

Thanks
Mukul

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 21 Dec 2011 10:07:09 -0800

>> Page 12 describes processing rules intended to keep the SRH within a RPL Instance.

Oops, typo.  s/12/13/

> It seems that a router, that receives a packet with a SRH, does not need to check if it belongs to the RPL Instance mentioned in the SRH. It just needs to check if the next hop belongs to that RPL…

It knows whether or not RPL is running on an interface.  It could at least check that.  By the same argument, how do you propose we limit packets to a RPL routing domain?  If we have no good way of limiting packets, then the stated security considerations do not apply.

> It would be a problem if the router were required to check its own membership in the RPL Instance in order to accept a packet with SRH. Routers part of a source route should not need to maintain an…

Note that in draft-ietf-roll-rpl, RPL routers do maintain such state already.  I agree the issue comes up with P2P.

Remember that the original purpose of the RPL Instance is to support MTR.  The RPL Instance identifies what routing topology to use.  This is important especially if the SRH does not specify the entire path to the destination.  How does the tunnel exit-point know what routing topology to use to reach the destination?

The lack of and need for the RPL Instance identifier was raised during IESG review.  The options are (1) to require inclusion a RPL Option in addition to the RPL routing header or (2) add a RPL Instance field in the RPL routing header itself.  I doubt that you would prefer option 1.

If the RPL router has no idea of the RPL Instance when forwarding, it can choose to forward the packet along anyway.  At the very least, the tunnel exit-point should enforce the use of the RPL Instance.  Surely the end-points of a source route should at least know what RPL Instance they are in...

--
Jonathan Hui

---

From: Mukul Goyal <[email-masked]>
Date: Wed, 21 Dec 2011 20:10:28 -0600 (CST)

Hi Jonathan

>It knows whether or not RPL is running on an interface.  It could at least check that.  By the same argument, how do you propose we limit packets to a RPL routing domain?  If we have no good way of…

Just the knowledge that the router is part of a particular RPL instance via a particular interface is no guarantee that all the neighbors reachable via that interface belong to the same RPL instance. On the other hand, a router would clearly know whether its particular interface belongs to the RPL domain or not. A packet wont be sent down an interface if that interface is not part of the RPL domain. Here, I am assuming that the RPL domain is defined in the manner you had suggested (analogous to the definition of a routing domain in Section 1.2 of RFC 1195).

>Note that in draft-ietf-roll-rpl, RPL routers do maintain such state already.  I agree the issue comes up with P2P.

Indeed, this would be a big problem for P2P-RPL.

>Remember that the original purpose of the RPL Instance is to support MTR.  The RPL Instance identifies what routing topology to use.  This is important especially if the SRH does not specify the ent…

There is no mention of MTR in the RPL specs. As far as RPL spec goes, an RPL Instance is simply a group of DAGs using the same OF. You can not assume that a tunnel exit-point would get any information from RPL Instance ID regarding how to reach the ultimate destination of the packet. That information would probably come from the routing table (which may be getting information via several routing protocols).

>The lack of and need for the RPL Instance identifier was raised during IESG review.  The options are (1) to require inclusion a RPL Option in addition to the RPL routing header or (2) add a RPL Inst…

I will try to go back and find the IESG review you have mentioned. If you could quickly direct me to right place, that will be helpful. But, at the moment, it is truly mind-boggling for me that RPL instance id is required to be specified in the source routing header. 

>If the RPL router has no idea of the RPL Instance when forwarding, it can choose to forward the packet along anyway.

Doing that would break the rules in SRH draft.

>  At the very least, the tunnel exit-point should enforce the use of the RPL Instance.  Surely the end-points of a source route should at least know what RPL Instance they are in...

Yes, this RPL Instance is a local instance which has no significance associated. I think you are trying to assign a meaning to RPL Instance ID which it does not currently have under RPL core spec.

Thanks
Mukul

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 21 Dec 2011 18:42:25 -0800

> Just the knowledge that the router is part of a particular RPL instance via a particular interface is no guarantee that all the neighbors reachable via that interface belong to the same RPL instanc…

And by the same logic, when forwarding a message, there is no guarantee that all neighboring nodes reachable via an interface belong to the same RPL routing domain.

> There is no mention of MTR in the RPL specs. As far as RPL spec goes, an RPL Instance is simply a group of DAGs using the same OF. You can not assume that a tunnel exit-point would get any informat…

The *entire* point of the RPL Instance concept is to support MTR.  The RPL Instance is used to distinguish between different DODAGs from the same root.  It gives you the ability to have multiple different routes to the same destination (e.g. one that minimizes latency vs. one that minimizes energy consumption).  If you don't have the RPL Instance information when forwarding a packet, how do you know whether to forward along the path that minimizes latency vs. the path that minimizes energy?

See slide 18 of http://www.iab.org/wp-content/IAB-uploads/2011/04/Vasseur.pdf if you want one such reference of MTR and RPL Instances.

> I will try to go back and find the IESG review you have mentioned. If you could quickly direct me to right place, that will be helpful. But, at the moment, it is truly mind-boggling for me that RPL…

Not so mind boggling if you consider MTR.

> Doing that would break the rules in SRH draft.

Of course.  I was making a proposal that we could relax the processing rules to end-points of the SRH.

> Yes, this RPL Instance is a local instance which has no significance associated. I think you are trying to assign a meaning to RPL Instance ID which it does not currently have under RPL core spec.

As I mentioned above, the RPL Instance allows you to have multiple distinct paths towards the same destination.  The RPL hop-by-hop option includes a RPL Instance ID so that a forwarding node knows which routing topology to use.  If RPL did not allow multiple routes to the same destination, then why bother having a RPL Instance?  You would only need the DODAGID to uniquely identify a DODAG (whereas the existing definition is the "tuple (RPLInstanceID, DODAGID) uniquely identifies a DODAG".

--
Jonathan Hui

---

From: Mukul Goyal <[email-masked]>
Date: Thu, 22 Dec 2011 09:04:33 -0600 (CST)

Hi Jonathan

>And by the same logic, when forwarding a message, there is no guarantee that all neighboring nodes reachable via an interface belong to the same RPL routing domain.

The receiving router could check if it belongs to the RPL domain listed in the SRH. If not, it can drop the packet.

>The *entire* point of the RPL Instance concept is to support MTR.  The RPL Instance is used to distinguish between different DODAGs from the same root.  It gives you the ability to have multiple dif…

Suppose a tunnel exit point knows that the SRH that carried the packet so far had RPL Instance ID 'x' which happens to be associated with OF0. What information does that give to the tunnel exit point? Is OF0 associated with minimizing of latency or of energy? What is preventing this particular RPL Instance ID 'x' with OF0 to be associated with two different DAGs - one minimizing latency and the other minimizing energy?

>As I mentioned above, the RPL Instance allows you to have multiple distinct paths towards the same destination.  The RPL hop-by-hop option includes a RPL Instance ID so that a forwarding node knows…

All this discussion is really besides the point. If we could just have the RPL domain and not the RPL Instance as the scope for an SRH, that will solve my problem.

Thanks
Mukul

--
Jonathan Hui

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 22 Dec 2011 07:34:40 -0800

> The receiving router could check if it belongs to the RPL domain listed in the SRH. If not, it can drop the packet.

And what information does the SRH provide that indicates what RPL routing domain it is coming from?  A node now has to know what neighbors are in its RPL routing domain?

> Suppose a tunnel exit point knows that the SRH that carried the packet so far had RPL Instance ID 'x' which happens to be associated with OF0. What information does that give to the tunnel exit poi…

The tunnel exit-point knows what kind of paths the tunnel entry-point is forwarding the packet along.  Again, the whole purpose of RPL Instances is to allow multiple paths optimized with different OFs towards the same destination.  If a forwarding device has no idea of what path to choose, then why bother with a RPL Instance?

> All this discussion is really besides the point. If we could just have the RPL domain and not the RPL Instance as the scope for an SRH, that will solve my problem.

Limiting to a RPL Instance is well-defined.  Limiting to a RPL routing domain requires a little more thought.  Can you propose the exact processing rules that would clearly limit a routing header to a RPL routing domain?

--
Jonathan Hui

---

From: Mukul Goyal <[email-masked]>
Date: Thu, 22 Dec 2011 10:05:11 -0600 (CST)

>And what information does the SRH provide that indicates what RPL routing domain it is coming from?  A node now has to know what neighbors are in its RPL routing domain?

The simplest option would be for the router to decide before hand which of its interfaces belong to "the" RPL domain and which not. The SRH need not have any RPL domain field. The router would drop the packet if received over an interface not in "the" RPL domain. If the packet was received over an interface in the RPL domain, it wont be forwarded down the interfaces not in the RPL domain.

A more complicated scheme would be to allow for multiple RPL domains and list the RPL Domain ID in the SRH. The router would know which RPL domains its interfaces belong to and would treat the packet accordingly.

>The tunnel exit-point knows what kind of paths the tunnel entry-point is forwarding the packet along. 

I am trying to say that RPL Instance ID does not give that information to the tunnel exit point. As per RPL spec, RPL Instance ID would have a mapping to the OF. It nowhere says that RPL Instance ID also has a mapping to metrics in use.
 
> Again, the whole purpose of RPL Instances is to allow multiple paths optimized with different OFs towards the same destination.

OF is just a way to calculate the rank. OF does not imply the use of particular routing metrics. Since RPL Instance ID does not identify the routing metrics in use, it can not tell what kind of route is being used to forward a packet.

> If a forwarding device has no idea of what path to choose, then why bother with a RPL Instance?

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.

>Limiting to a RPL Instance is well-defined.  Limiting to a RPL routing domain requires a little more thought.  Can you propose the exact processing rules that would clearly limit a routing header to…

Lets assume that RPL domain is defined as you suggested some time back to be analogous to the routing domain definition in RFC 1195 (section 1.2). I interpret it to mean that the RPL router would characterize its interfaces as either belonging to the RPL domain or outside the RPL domain.

With this interpretation of RPL domain in mind, the following processing rules would replace the rules 2 and 3 on page 13 of your draft:

2.  Datagrams, carrying an SRH and received on an interface not belonging to the RPL domain, will be dropped with no further processing.

3.  Datagrams, carrying an SRH and destined to be forwarded along interfaces outside the RPL domain, are dropped with no further processing.

Thanks
Mukul

--
Jonathan Hui

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 22 Dec 2011 08:17:15 -0800

> The simplest option would be for the router to decide before hand which of its interfaces belong to "the" RPL domain and which not. The SRH need not have any RPL domain field. The router would drop…

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 more complicated scheme would be to allow for multiple RPL domains and list the RPL Domain ID in the SRH. The router would know which RPL domains its interfaces belong to and would treat the pack…

Except that there is no such concept.  RPL Instance ID is the closest we have.

> I am trying to say that RPL Instance ID does not give that information to the tunnel exit point. As per RPL spec, RPL Instance ID would have a mapping to the OF. It nowhere says that RPL Instance I…

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.

> OF is just a way to calculate the rank. OF does not imply the use of particular routing metrics. Since RPL Instance ID does not identify the routing metrics in use, it can not tell what kind of rou…

In reality, it doesn't need to care.  It just needs to care about sending along routes that were created using the same OF.  Having each RPL router choose an arbitrary route created using an arbitrary OF does not make any sense.

> 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 significan…

See above.  RPL Instance does map to metrics.

> Lets assume that RPL domain is defined as you suggested some time back to be analogous to the routing domain definition in RFC 1195 (section 1.2). I interpret it to mean that the RPL router would c…

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.

--
Jonathan Hui

---

From: Mukul Goyal <[email-masked]>
Date: Thu, 22 Dec 2011 11:24:42 -0600 (CST)

>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…

A router not running RPL could have sent me a message carrying SRH?

>Except that there is no such concept.  RPL Instance ID is the closest we have.

Yes, the concept of RPL domain needs to be defined - either in rpl-terminology draft or in your draft.

>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. 

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.

>See above.  RPL Instance does map to metrics.

It need not.

>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…

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.

Thanks
Mukul

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 22 Dec 2011 10:02:29 -0800

> 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.

> 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 th…

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.

> 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 requiremen…

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?

>> See above.  RPL Instance does map to metrics.

You are incorrect again!

> 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

---

From: Robert Cragie <[email-masked]>
Date: Fri, 23 Dec 2011 18:07:20 +0000

Hi Jonathan,

Some comments and questions below.

Robert

> 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.
<RCC>I'm not getting this. The use of SRH is for non-storing mode, 
correct? And only for non-storing mode? There is no current definition 
of partial storing mode and stored mode doesn't need SRH. So the source 
routes are created on the DAG root based on transit information obtained 
by DAOs. How can any router outside of the RPL domain initiate a 
source-routed message to a node in the RPL domain? It would be tunneled 
at the point it got to the DAG root. Therefore, by implication, normally 
the source and destination of the message with SRH must be in the RPL 
domain. So we need to check for exceptions - surely the rules Mukul 
stated are sufficient?</RCC>
> 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 metr…
<RCC>
The source route is determined by the transit options, nothing else. 
There is no processing done at each hop - it simply forwards it to the 
next based on what's in the SRH. So no need for RPL instance (or domain) 
there. You could potentially build up multiple tables for each RPL 
instance but you would just formulate a different SRH based on which 
table you picked. When it gets to the destination, why would the 
OF/metric of whatever DAG it happen to transit through have any bearing 
on where it is subsequently going? I ask this because there is no 
further information based on the domain it has just gone through. The 
message originator would not even be aware of any subsequent RPL domains 
beyond itself; it is bounded by the root and the leaf routers. Unless 
the destination is on path between the DAG root and a leaf router, an 
SRH will always go between the DAG root and a leaf router. I find the 
concept of a partial SRH quite baffling even if it is for the purposes 
of traceroute - even then at the point it emerges someway down the path, 
it will return a time exceeded error.

So basically, I am still failing to understand the need to carry RPL 
instance in the SRH for non-storing mode. I could see its use in partial 
storing mode whereby SRH carries it part of the way and the stored 
information on subsequent routers the rest, but in this case surely you 
would put a RPL option in the inner packet and tunnel? So when it 
emerges from the source-routed tunnel, it is ready to be forwarded using 
RPL.
<RCC>
> Nope.  As I stated before, that would invalidate the Security Considerations section.
<RCC>I agree with Mukul: in normal circumstances a packet with an SRH 
will come from a router in the RPL domain and the rules Mukul stated can 
be used to make sure it doesn't go beyond.</RCC>

---

From: Mukul Goyal <[email-masked]>
Date: Fri, 23 Dec 2011 12:33:04 -0600 (CST)

If a packet, carrying an SRH, is received over an interface not in RPL domain, it is discarded. Thus, an attack may only be mounted within an RPL domain.

Also, a packet, carrying an SRH, cant be sent over an interface not in RPL domain. So, any attack can not propagate beyond the RPL domain.

Also, whats wrong with defining RPL domain based on interfaces?

As I mentioned before, using RPL Instance as the scope of SRH is a problem. Rules on page 13 are difficult to meet. An RPL router has no idea whether the next hop belongs to the particular RPL Instance or not. If the rules are changed so that a router has to check if it itself belongs to the particular RPL Instance, that will be a problem as well. This is because routers on a source route discovered using P2P-RPL dont remember RPL Instance under which the route was discovered. Requiring maintenance of state to be part of a source route does not sound like a good idea. 

Thanks
Mukul

----- Original Message -----
From: "Jonathan Hui (johui)" <[email-masked]>
To: "robert cragie" <[email-masked]>
Cc: "Mukul Goyal" <[email-masked]>, [email-masked], "roll" <[email-masked]>
Sent: Friday, December 23, 2011 12:17:18 PM
Subject: Re: draft-ietf-6man-rpl-routing-header-07

To alleviate some of the usual security concerns with source routing, we want to limit the scope if where attacks can be initiated.

Any outside attacker can fabricate a SRH and send it to a RPL router.  How do you prevent that without some way of limiting the scope?

Also,  Mukul's proposal is to define the scope based on interfaces.  That is not the same as limiting the scope to a collection of RPL routers.

--
Jonathan Hui

On Dec 23, 2011, at 10:07 AM, "Robert Cragie" <[email-masked]> wrote:

> <RCC>I'm not getting this. The use of SRH is for non-storing mode, correct? And only for non-storing mode? There is no current definition of partial storing mode and stored mode doesn't need SRH. So the source routes are created on the DAG root based on transit information obtained by DAOs. How can any router outside of the RPL domain initiate a source-routed message to a node in the RPL domain? It would be tunneled at the point it got to the DAG root. Therefore, by implication, normally the source and destination of the message with SRH must be in the RPL domain. So we need to check for exceptions - surely the rules Mukul stated are sufficient?</RCC>
>> 
> The source route is determined by the transit options, nothing else. There is no processing done at each hop - it simply forwards it to the next based on what's in the SRH. So no need for RPL instance (or domain) there. You could potentially build up multiple tables for each RPL instance but you would just formulate a different SRH based on which table you picked. When it gets to the destination, why would the OF/metric of whatever DAG it happen to transit through have any bearing on where it is subsequently going? I ask this because there is no further information based on the domain it has just gone through. The message originator would not even be aware of any subsequent RPL domains beyond itself; it is bounded by the root and the leaf routers. Unless the destination is on path between the DAG root and a leaf router, an SRH will always go between the DAG root and a leaf router. I find the concept of a partial SRH quite baffling even if it is for the purposes of traceroute - even then at the point it emerges someway down the path, it will return a time exceeded error.
> 
> So basically, I am still failing to understand the need to carry RPL instance in the SRH for non-storing mode. I could see its use in partial storing mode whereby SRH carries it part of the way and the stored information on subsequent routers the rest, but in this case surely you would put a RPL option in the inner packet and tunnel? So when it emerges from the source-routed tunnel, it is ready to be forwarded using RPL.
> <RCC>
>> 
> <RCC>I agree with Mukul: in normal circumstances a packet with an SRH will come from a router in the RPL domain and the rules Mukul stated can be used to make sure it doesn't go beyond.</RCC>
>> 
>> --
>> Jonathan Hui
>> 
>> 
>

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Fri, 23 Dec 2011 10:17:18 -0800

--
Jonathan Hui