datatracker.ietf.org
Sign in
Version 5.7.4, 2014-11-12
Report a bug

The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams
RFC 6553

Note: This ballot was opened for revision 05 and is now closed.

Summary: Needs 6 more YES or NO OBJECTION positions to pass.

Adrian Farrel

Comment (2011-11-30 for -)

I have no objection to the publication of this document, but I have a umber of
questions/nits that I hope you will consider.

Section 1

  To that end, this document proposes a new IPv6 option,
s/proposes/defines/

---

Setion 2

   Every RPL router along a packet's delivery path processes and updates
   the RPL Option.  If the received packet does not already contain a
   RPL Option, the RPL router must insert a RPL Option before forwarding
   it to another RPL router.

Surely that means that the absence of the option indicates a defect in
the upstream router. This issue is also present in section 4 where there
is some flexibility about whether to include the RPL Option, but no
guidance.

---

Section 3

Please consider using RFC2119 language (e.g. "shall")

---

Section 3

   Nodes
   that do not understand the RPL Option MUST discard the packet.

You cannot state this in this way. Nodes that do not understand the
option will not implement this spec!

You probably simply need:

As defined in [foo] nodes that do not understand an option on a
received packet MUST discard the packet.

---

Sections 3 and 7

Please check "sub-TLV" and "TLV". I think you have used them
interchangeably.

Stephen Farrell

Comment (2011-11-28 for -06)

- Why does this header need an instance ID when the SRH did not?

- I don't get why this wasn't part of the core RPL spec, if in fact "RPL
requires..." this as stated at the start of section 2.

- s2, s/This draft specifies the use.../This draft also specifies the
use.../ would be clearer as the non-tunnelled option is also allowed
here.

- s4, this says the router MUST include the RPL option - but is that
needed in *every* packet?

- s6, it would be better to give more detail of the several potential
attacks, so that people could know to look out for or mitigate those.

[Robert Sparks]

Comment (2011-11-29 for -)

Please double-check the first paragraph of section 4 to make sure that "ICMPv6
errors generated by inserting the RPL option" is really what you mean to say -
are you talking about errors that resulted from inserting the option itself, or
possibly other ICMP errors that might result from other data in the tunnel
header?

[Russ Housley]

Comment (2011-11-28 for -)

  The Gen-ART Review by Joel Halpern on 22-Nov-2011 included a
  suggestion for improved clarity.  Please consider it.

   While calling a bit the O bit does not appear unreasonable, I
   note that when looking at the packet form, the difference between
   the O bit and the mbz bits marked as 0 is small, and a likely
   source of confusion for the reader.

[Sean Turner]

Comment (2011-11-30 for -)

I support Stephen's discuss.