Subject: Re: Last Call: <draft-ietf-roll-rpl-11.txt> (RPL: IPv6 Routing Protocol for Low power and Lossy Networks) to Proposed Standard

From: Pekka Savola <[email-masked]>
Date: Fri, 3 Sep 2010 08:54:16 +0300 (EEST)

On Wed, 18 Aug 2010, The IESG wrote:
> The IESG has received a request from the Routing Over Low power and Lossy
> networks WG (roll) to consider the following document:
> - 'RPL: IPv6 Routing Protocol for Low power and Lossy Networks'
>  <draft-ietf-roll-rpl-11.txt> as a Proposed Standard

I've done a solicited but superficial ops-dir review of 
draft-ietf-roll-rpl-11.  Given the document length (139p) I've had to 
skim most of it.  The IETF Last Call expired two days ago, but for 
information I'm still copying the IETF list, even though this review 
is mainly for O&M ADs' and secondarily ROLL WG benefit.

A couple of comments:

In general, ROLL problem space seems to be very similar to MANETs, and 
I wonder why a separate protocol needed to be developed here, 
especially given the amount of scientific research and also IETF 
effort put into MANETs.  ROLL WG charter certainly does not mention 
this.

Copying/modifying various IPv6 ND options for this purpose may be 
required but I wonder if this could have been done in a simpler 
fashion, without having to copy the specifications here.  For example, 
using a TLV container option that includes non-TLV options as-is.

The document mentions uniquely identifying a DODAG by the use of an 
IPv6 address.  The document does not mention what addresses are to be 
used for this purpose, how they are assigned, and how these are 
expected to be unique. (Compare to documents on MANET IPv6 address 
assignments.)

In S 11 on Packet Forwarding:

    1.  This specification only covers how a successor is selected from
        the DODAG Version that matches the RPLInstanceID marked in the
        IPv6 header of the packet being forwarded. [...]

... How is RPLInstanceID marked in the IPv6 header of the packet being
forwarded?  Are you modifying IPv6 packet forwarding and processing
algorithms here (must look into the packets)?  That would be a major
change. (You're really referring to the hop-by-hop header processing here.)

In general the document doesn't seem to be sufficiently upfront on the basic
semantics how RPL is going to be used (from "non-RPL" perspective).  One
could argue Section 3 (some 12 pages) tries to provide
an overview, but from IP perspective, it provides too much detail on e.g.
tree forming and maintenance.  The most important things to bring up clearly
should be for example: (1) are there changes to existing packet formats or
usage (e.g. does every packet include some kind of header, does this affect
MTU usable in the network)?, (2) is support for these required at each node
in the network, (3) are there changes to the basic packet processing in
associated nodes?

Upon closer inspection, some answers to these high-level questions can 
be found in first paragraph of S 3.3.7 and the last paragraph of S 5, 
but I'd really have wanted to see one or two paragraphs in 
Introduction.

...

It is a bit strange to see that S 17 on manageability does not mention 
security management, because one of the key problems there (as argued 
in the draft as well) is how do you manually configure and maintain 
shared keys on all these devices.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 03 Sep 2010 12:01:59 -0400

Thank you for your review.

>>>>> "Pekka" == Pekka Savola <[email-masked]> writes:
    Pekka> In S 11 on Packet Forwarding:

    Pekka>    1.  This specification only covers how a successor is
    Pekka> selected from the DODAG Version that matches the
    Pekka> RPLInstanceID marked in the IPv6 header of the packet being
    Pekka> forwarded. [...]

    Pekka> ... How is RPLInstanceID marked in the IPv6 header of the
    Pekka> packet being forwarded?  Are you modifying IPv6 packet
    Pekka> forwarding and processing algorithms here (must look into the
    Pekka> packets)?  That would be a major change. (You're really
    Pekka> referring to the hop-by-hop header processing here.)

So, this is a signficant but as yet unsolved problem.
No details of the RPL protocol itself depend upon how in, the end, the
packets are marked.

At the beginning, many of us thought that the FlowLabel was the right thing
to use.   And it works very well as long as the RPL network does not
need to interact with other networks.  

Applications that run on RPL nodes that need a non-default behaviour
need to be aware of what RPLinstanceID to pick (and this is a
provionsing issue), and thus it will in fact be the application setting
the flow label, not an intermediate node. 

    Pekka> It is a bit strange to see that S 17 on manageability does
    Pekka> not mention security management, because one of the key
    Pekka> problems there (as argued in the draft as well) is how do you
    Pekka> manually configure and maintain shared keys on all these
    Pekka> devices.

I agree that it is a concern --- most of the deployment scenarios (which
are in a series of RFCs published by the WG last fall) are installed by
a single contractor into a single
  commercial-building/house/factor/power-transmission-system
They initialize all the devices in the test lab, and then deploy them.

I think this is because 90% of the participants in the group think that
link-layer security provided by Zigbee is going to solve all of their
problems.    I am very skeptical about this.

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Sep 2010 08:53:13 +0200

Le 03/09/2010 07:54, Pekka Savola a écrit :
>> The IESG has received a request from the Routing Over Low power and
>> Lossy networks WG (roll) to consider the following document: -
>> 'RPL: IPv6 Routing Protocol for Low power and Lossy Networks'
> In general, ROLL problem space seems to be very similar to MANETs,
> and I wonder why a separate protocol needed to be developed here,

I think this comment makes sense.  There was an important draft at some
point discussing why MANET protocols are not enough and why new protocol
was needed.  That WG item was used to motivate the new at that time ROLL
Charter requesting a new protocol design.  However, that draft was
discard soon after and not revived.  I believe that was an error: WG
items are never dropped, even less when they're used to motivate further
Charterer work.   That can still be corrected (revive
draft-ietf-roll-protocols-survey-07).

> expected to be unique. (Compare to documents on MANET IPv6 address

I agree the document is not very clear about how address configuration
is performed.  For example, it says nothing about the use of link-local
addresses - this silence is very wrong.

Another potential error lies in this RPL text:
> Prefix Length  8-bit unsigned integer.  The number of leading bits
> in the Prefix that are valid.  The value ranges from 0 to 128. The
> prefix length field provides necessary information for on- link
> determination (when combined with the L flag in the prefix
> information option).  It also assists with address autoconfiguration
>  as specified in [RFC4862], for which there may be more restrictions
>  on the prefix length.

Does this mean that the prefix in a DIO is used for address
autoconfiguration, instead of a PIO in rfc4861?  I guess yes, and it is
wrong, because it is a new address autoconfiguration mechanism and it
says nothing about how it interacts with the old.

> the DODAG Version that matches the RPLInstanceID marked in the IPv6
> header of the packet being forwarded. [...]
>
> ... How is RPLInstanceID marked in the IPv6 header of the packet
> being forwarded? Are you modifying IPv6 packet forwarding and
> processing algorithms here (must look into the packets)? That would
> be a major change. (You're really referring to the hop-by-hop header
>  processing here.)
>
> In general the document doesn't seem to be sufficiently upfront on
> the basic semantics how RPL is going to be used (from "non-RPL"
> perspective).

I agree!  The RPL protocol seems to be designed for a non-Internet
network.  It seems to need more refinement before interoperating with
other IPv6 nodes.

Alex

> One could argue Section 3 (some 12 pages) tries to provide an
> overview, but from IP perspective, it provides too much detail on
> e.g. tree forming and maintenance. The most important things to
> bring up clearly should be for example: (1) are there changes to
> existing packet formats or usage (e.g. does every packet include some
> kind of header, does this affect MTU usable in the network)?, (2) is
> support for these required at each node in the network, (3) are
> there changes to the basic packet processing in associated nodes?
>
> Upon closer inspection, some answers to these high-level questions
> can be found in first paragraph of S 3.3.7 and the last paragraph of
>  S 5, but I'd really have wanted to see one or two paragraphs in
> Introduction.
>
> ...
>
> It is a bit strange to see that S 17 on manageability does not
> mention security management, because one of the key problems there
> (as argued in the draft as well) is how do you manually configure and
> maintain shared keys on all these devices.
>
> _______________________________________________ Ietf mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/ietf
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 9 Sep 2010 11:54:13 +0100

> That can still be corrected (revive

That was dropped because some people had various issues with it.

That draft, very roughly speaking, said "none of these existing
protocols do what we want because they fail to meet the ideal we
have set for these various reasons". The issues were over whether
all such characteristions were accurate. (Note that absolute accuracy
may not be essential to make a WG decision, but a higher standard
is needed in an RFC. But I do not recall what the specific issues
were.)

What I'd find interesting is whether RPL meets all of those ideals
itself. (That's a genuine question, I don't know.)

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 27 Sep 2010 08:50:36 -0600

I'm not closely involved with ROLL but I am working on devices using the CORE work that would likely make use of and depend on this protocol. I have some concerns about the practically of using ROLL given the IPR. My understanding of the IPR is that one would be required to use certificates that are from an CA license by Certicom. 

My belief is that the many of the low cost devices that would want to implement ROLL would be based on Linux implementation as that has become one of the most widely used operating systems for low cost networking devices such as residential routers. Given the optimal ways of integrating a protocol such as this into the kernel, and the issues of likening such as this in GPL code, I really wonder if the current IPR will be a major determent to deployment of ROLL. It's not easy to search the archives and I easily could have missed things but I can not find any significant discussion of it the WG could avoid this IPR. There were a few emails in July but it did not seem like it really hit this topic.  I would have expected to see discussion on such topics as David McGrews draft on Fundamental Elliptic Curve Cryptography Algorithms or perhaps using  RSA approaches.  I think discussion about this IPR, and ways it could be avoided, would be appropriate before approving this draft. 

Cullen 

On Aug 18, 2010, at 4:28 PM, The IESG wrote:

> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2010-09-01. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-roll-rpl/
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-roll-rpl/
> 
> 
> The following IPR Declarations may be related to this I-D:
> 
> /ipr/1270/
> /ipr/1356/
> /ipr/1366/
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html