Subject: [Roll] Question from Alex on RPL

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Oct 2010 20:48:09 +0200

Corrected subject line.

Le 07/10/2010 20:10, JP Vasseur a écrit :
 >
 > On Oct 6, 2010, at 11:18 PM, Alexandru Petrescu wrote:
 >
 >> Le 06/10/2010 19:55, JP Vasseur a écrit :
 >>> Hi Alex,
 >>>
 >>> On Oct 6, 2010, at 3:31 PM, Alexandru Petrescu wrote:
 >>>
 >>>> Le 06/10/2010 12:03, JP Vasseur a écrit :
 >>>>> I think that the title capture the topic. I'll update and
 >>>>> propose a resolution to close.
 >>>>
 >>>> JP, when closing this issue, please clarify:
 >>>>
 >>>> - every RPL message has src and dst address scoped as _link_
 >>>> local, i.e. a single link, a single PHY/MAC.  This contradicts
 >>>> the multiple PHY/MAC perspective, because a single link can't
 >>>> be connecting interfaces using different MAC/PHY.
 >>>>
 >>>> I am not sure I am clear...
 >>>>
 >>>
 >>> I am not clear about your question ... why is it different from
 >>> all other L3 routing ?
 >>
 >> Hi JP - I see what you mean, I remember you already said that,
 >> sorry.
 >>
 >> Yes, other routing protocosl sending their flooding messages on
 >> link-scoped multicast addresses (RIP, OSPF) are implemented on
 >> routers having multiple interfaces, thus possibly multiple
 >> PHY/MAC, originating new flooding messages with another src
 >> address topologically valid on that link.
 >>
 >> Should I understand that RPL router doing multiple PHY/MAC has at
 >> least two interfaces?
 >
 > Yes

Ok.

Then, does RPL forward an RPL packet between two interfaces?

I suppose it does not, because the src address is link-local address
(except DAO in non-storing mode).

 >> Should I understand that most RPL Routers have at least two
 >> interfaces?
 >
 > Not sure we can say "most" RPL router have at least two interfaces
 > but the point here is that RPL can be used in networks with multiple
 > PHY/MAC. In this case, some of the routers obviously have multiple
 > interfaces.

YEs, I agree with this view: some of the RPL routers obviously have
multiple interfaces.  Those who have should say when they generate new
RPL messages, what they use as src and dst address, because RPL
link-scoped addressed messages wouldn't be forwarded between interfaces.

 >> If so, is the phrase RPL-12 "Although there may typically be only
 >> one interface in most application scenarios..." a little bit
 >> wrong?
 >>
 >> And that when receiving a DAO message on one interface RPL Router
 >> may generate another DAO with a different link-local source
 >> address on another interface?
 >
 > There is no issue there. Similar to other IPv6 routing protocols.

One RPL issue here: RPL-12 does not specify the value for the Hop Limit.

Other IPv6 routing protocol using link-scoped addresses as src and dst
(OSPF) does not forward rt protocol packets across interfaces, and the
spec explicitely requires to set the Hop Limit to 1.

ND spec sets the Hop Limit to 255 and requires the receiver to check it
to be 255.

RPL-12 is silent about the value for the Hop Limit.  It only says its
value should be decremented when forwarding (which is good for a typical
router, rt protocol or not); but RPL link-scoped packets aren't
typically forwarded.  So it should say what it does about the Hop Limit
- the default value?  Does the receiver do anything special when
receiving a certain value of the Hop Limit?

Wireshark dumps of RPL show it as 255, which may be too big knowing
these packets are never forwarded.

If we want it 255 then it makes sense to write down that the receiver
checks it to be 255 ensuring the packet wasn't forwarded (avoid attacks).

IF we want it 1 then it makes sense to require originators to set it to
1, and the well behaving intermediate routers will drop it, again avoid
attacks.

 >> Or are the DAO messages propagated without modifying the src
 >> address?
 >>
 >> RPL-12 says "If the D flag is cleared then the source address of
 >> the IPv6 packet MUST be the DODAGID...The DODAGID in this case
 >> will be the reachable IPv6 address of node A" - sounds as if there
 >> is _only_ one address of node A?  But a node with multiple
 >> interfaces has multiple link-local addresses.
 >
 > Depends where you DAG goes ...

WEll a DAG goes several directions.

Alex

[...]
 >>> Same reasoning applies to ETX. Now, note that the metric ID does
 >>> not mandate for all RPL networks to support all of the specified
 >>> metrics of course. Further, one may decide to specify a RPL
 >>> metric that is relevant for a specific PHY/MAC: RPL specifies
 >>> what a node is supposed to do when it does not
 >>> understand/support a metric (leaf node). This is a deployment
 >>> issue. This is very similar to what is done with other routing
 >>> protocols.
 >>
 >> In this sense, I think further work is needed on the common
 >> metrics to support multiple PHY/MACs.
 >
 > The statement is way too vague to help. As you can see all of the
 > metrics proposed can be used for various "lossy" PHY/MAC. Nothing
 > PHY/MAC specific.
 >
 > Hope this helps.
 >
 > Thanks.
 >
 > JP.
 >
 >>
 >> Alex
 >>
 >>>
 >>> Hope that helps.
 >>>
 >>> JP.
 >>>
 >>>> I may be wrong but that's how I see it.
 >>>>
 >>>> Alex
 >>>>
 >>>>> Cheers.
 >>>>>
 >>>>> JP.
 >>>>>
 >>>>> On Oct 6, 2010, at 10:53 AM, Yoav Ben-Yehezkel wrote:
 >>>>>
 >>>>>> I agree with Colin This ticket misses the essence of the
 >>>>>> real issue which Colin and Alex discussed, as Colin
 >>>>>> clarified in one of his responses to my below concern.
 >>>>>>
 >>>>>>
 >>>>>> Regards, Yoav
 >>>>>>
 >>>>>>
 >>>>>> -----Original Message----- From: [email-masked]
 >>>>>> [mailto:[email-masked]] On Behalf Of Colin O'Flynn
 >>>>>> Sent: Wednesday, October 06, 2010 10:51 AM To: 'JP
 >>>>>> Vasseur'; 'Michael Richardson' Cc: [email-masked] Subject:
 >>>>>> Re: [Roll] [roll] routing-metrics #80 (new): RPL across
 >>>>>> Multiple PHY/MAC: comment received during WG Last Call of
 >>>>>>
 >>>>>> Hello,
 >>>>>>
 >>>>>>> As far as I'm concerned, these scenarios were always in
 >>>>>>> scope.
 >>>>>>
 >>>>>> The original issue was only about if the routing metrics
 >>>>>> would work across multiple MAC/PHY. The issue was quickly
 >>>>>> blown out of context to become about RPL in general, which
 >>>>>> of course will work across multiple MAC/PHY.
 >>>>>>
 >>>>>> But it wasn't a real issue anyway, just some discussion.
 >>>>>>
 >>>>>> Regards,
 >>>>>>
 >>>>>> -Colin
 >>>>>>
 >>>>>> -----Original Message----- From: [email-masked]
 >>>>>> [mailto:[email-masked]] On Behalf Of JP Vasseur
 >>>>>> Sent: October 6, 2010 5:05 AM To: Michael Richardson Cc:
 >>>>>> [email-masked] Subject: Re: [Roll] [roll] routing-metrics
 >>>>>> #80 (new): RPL across Multiple PHY/MAC: comment received
 >>>>>> during WG Last Call of
 >>>>>>
 >>>>>>
 >>>>>> On Oct 5, 2010, at 7:35 PM, Michael Richardson wrote:
 >>>>>>
 >>>>>>>
 >>>>>>>>>>>> "roll" == roll issue
 >>>>>>>>>>>> tracker<[email-masked]> writes:
 >>>>>>> roll>     I am seeking for WG confirmation that these use
 >>>>>>> cases are roll>    covered well by RPL (as a route over
 >>>>>>> media and link layer roll>    agnostic protocol).
 >>>>>>> Otherwise, I think this is a significant roll>
 >>>>>>> short-coming of the protocol.
 >>>>>>>
 >>>>>>> As far as I'm concerned, these scenarios were always in
 >>>>>>> scope.
 >>>>>>
 >>>>>> They are (even in the charter !) but I wanted to close one
 >>>>>>  ticket per item raised during WG LC. We'll now close the
 >>>>>> tickets.
 >>>>>>
 >>>>>> Thanks.
 >>>>>>
 >>>>>> JP.
 >>>>>>
 >>>>>>>
 >>>>>>> -- ]       He who is tired of Weird Al is tired of life!
 >>>>>>> |
 >>>>>> firewalls  [
 >>>>>>> ]   Michael Richardson, Sandelman Software Works,
 >>>>>>> Ottawa, ON |net
 >>>>>> architect[
 >>>>>>> ] [email-masked]
 >>>>>>> http://www.sandelman.ottawa.on.ca/ |device
 >>>>>> driver[
 >>>>>>> Kyoto Plus: watch the video
 >>>>>> <http://www.youtube.com/watch?v=kzx1ycLXQSE>
 >>>>>>> then sign the petition.
 >>>>>>> _______________________________________________ Roll
 >>>>>>> mailing list [email-masked]
 >>>>>>> https://www.ietf.org/mailman/listinfo/roll
 >>>>>>
 >>>>>> _______________________________________________ Roll
 >>>>>> mailing list [email-masked]
 >>>>>> https://www.ietf.org/mailman/listinfo/roll
 >>>>>>
 >>>>>> _______________________________________________ Roll
 >>>>>> mailing list [email-masked]
 >>>>>> https://www.ietf.org/mailman/listinfo/roll
 >>>>>
 >>>>> _______________________________________________ Roll mailing
 >>>>>  list [email-masked]
 >>>>> https://www.ietf.org/mailman/listinfo/roll
 >>>>>
 >>>>
 >>>>
 >>>> _______________________________________________ Roll mailing
 >>>> list [email-masked] https://www.ietf.org/mailman/listinfo/roll
 >>>
 >>>
 >>
 >
 >

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll