An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)
RFC 6554
Yes
No Objection
Note: This ballot was opened for revision 07 and is now closed.
(Jari Arkko; former steering group member) (was Discuss, Yes) Yes
(Adrian Farrel; former steering group member) No Objection
I have no objection to the publication of this document, but I have a number of small editorial questions/comments that I hope you will address along the way.
Section 2
First, RPL routers implement a strict source route policy where each
and every IPv6 hop is specified within the SRH.
appears to be in conflict with
2. If the SRH only specifies a subset of the path from source to
destination, the router uses IPv6-in-IPv6 tunneling [RFC2473]
This probably just needs clarifying text in the paragraph. There is
explanation of when the situation occurs (after the numbered list).
---
Section 3 Next Header
Shouldn't your base reference be RFC 2460? If IPv6 was to choose to
diverge from IPv4, which one would you follow?
---
Section 3 Routing Type
You do not mention the use to which this field is put anywhere in your
document. It should probably go here.
---
Section 3 Reserved
You have not said how the Reserved field is handled.
---
It would have been useful to state (section 4.1?) how "segments left"
is set on the initial SRH and whether the first entry in the address
list includes the source node.
---
Section 4.2
else if 2 or more entries in Address[1..n] are assigned to
local interface and are separated by at least one
address not assigned to local interface {
This check is more specific than the text previously indicated. This
is the first mention of non-adjacent repeat addressing.
---
Section 4.2
swap the IPv6 Destination Address and Address[i]
Do you really mean swap? Or do you just want to set DstA = Address[i] ?
---
Section 4.2
I'm surprised that you check and decrement the hop limit so late in the
cycle.
(Dan Romascanu; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
(Peter Saint-Andre; former steering group member) No Objection
(Ralph Droms; former steering group member) (was Discuss) No Objection
Comment added on 11/30. The working group summary is pretty terse. I think it would be helpful to explain that the design and use of the option morphed several times during the working group discussion before it arrived at its current state. Also, the working group summary should refer to the roll (not RPL) working group.
(Robert Sparks; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) (was Discuss) No Objection
(Stephen Farrell; former steering group member) (was Discuss, No Objection) No Objection
- how are RPL routers supposed to know which of them are border routers at what point in time? Doesn't needing to know this further constrain the applicability of this scheme? - is it allowed for a RPL router to just drop an SRH and replace it with an entirely new SRH? - s1, "necessary mechanisms" is a bit odd, be better to name them if they're known/agreed already. - 6.1 seems to imply that all the attacks listed can be mounted from within the LLN. Truth in advertising would call for saying that explicitly.
(Stewart Bryant; former steering group member) No Objection
(Wesley Eddy; former steering group member) No Objection