Jonathan,
I think we have converged (one suggestion inline below though). Please submit
the draft.
Here are my comments in more detail:
Datagrams being forwarded within a RPL domain MUST include a RPL
Option. For datagrams sourced within a RPL domain, the RPL Option
MAHui,Y be included in the datagram itself.
I'm not sure I understand the difference or its motivation. Do you really mean
that a packet might not have the option until it hits the first router? Or are
you just talking about something that happens internally on a host, but on the
wire all packets would still have the option? Also, since the tunnel (or
something else) is used to include the option for datagrams sourced outside the
RPL domain, wouldn't it be easier to just say this:
"Datagrams sent between nodes within an RPL domain MUST include an RPL Option."
Agree.
OK
I spoke too quickly on the comment above. In fact, the RPL Option is not
required when a RPL Source Route Header exists. With SRH, there is no
potential for loops, so the RPL Option is not required. How about the
following text?
"Datagrams sent between nodes within a RPL domain MUST include a RPL Option or RPL
Source Route Header. Datagrams MAY include both a RPL Option and a RPL Source Route
Header."
OK
For datagrams sourced
outside a RPL domain, IPv6-in-IPv6 tunneling, as specified in
[RFC2473<http://tools.ietf.org/html/rfc2473>] SHOULD be used to include a
RPL Option.
This text should be aligned with whatever conclusion we will have for the issue
that I raised with the other document.
Agree. See my response to your other review.
OK
To help avoid IP-layer fragmentation, the RPL Option has a maximum
size of RPL_OPTION_MAX_SIZE octets and links within a RPL domain
SHOULD have a MTU of at least 1280 + 44 (outer IP header, Hop-by-Hop
Option header, Option header) + RPL_OPTION_MAX_SIZE + (additional
extension headers or options needed within RPL domain).
There's a same MTU issue here as in the other document.
Agree. See my response to your other review.
I have a text suggestion on the other thread now.,
We will add the suggested text in the next revision.
OK
The action taken by using the RPL Option and the potential set of
sub-TLVs carried within the RPL Option MUST be specified by the RFC
of the protocol that use that option. No TLVs are defined in this
document.
I think you should define the behavior when a node encounters a sub-TLV that it
does not recognize. E.g., ignore and move on to the next sub-TLV. Or do you
want a stricter policy? In any case, for future extensions it will be necessary
to know how they are treated by legacy RPL nodes.
Yes, we need to define the behavior. I'm comfortable with specifying an
skip-over-and-continue policy for unknown sub-TLVs.
OK
In very specific cases, IPv6-in-IPv6 tunneling may be undesirable due
to the added cost and complexity required to process and carry a
datagram with two IPv6 headers.
[I-D.hui-6man-rpl-headers<http://tools.ietf.org/html/draft-ietf-6man-rpl-option-03#ref-I-D.hui-6man-rpl-headers>]
describes
how to avoid using IPv6-in-IPv6 tunneling in such specific cases and
the risks involved.
Again, the same comments as in the other draft. Please delete this paragraph.
Agree.
OK
For datagrams exiting the RPL domain, RPL Border Routers MUST remove
the RPL Option from the datagram. If the RPL Option was included
using tunneled mode and the RPL Border Router serves as the tunnel
end-point, removing the outer IPv6 header serves to remove the RPL
Option as well. Otherwise, the RPL Border Router assumes that the
RPL Option was included using transport mode and MUST remove the RPL
Option from the IPv6 Hop-by-Hop Option header.
The part about removing the RPL option even in a non-tunneled case relates to
the issue of supporting that particular mode of operation.
But in addition, I wonder if you should write the above text not in terms of
packet modification operations but rather in terms of forwarding decision
outcomes. Like this, for instance:
"For datagrams destined to the RPL Border Router the router processes the packet in
the usual way. For instance, if the RPL Option was included using tunneled mode and the
RPL Border Router serves as the tunnel end-point, the router removes the outer IPv6
header, at the same removing the RPL Option as well. Datagrams destined elsewhere within
the same RPL domain are forwarded to the right interface. Datagrams destined outside the
RPL domain are dropped."
The intent was to allow operation where a device within the RPL domain could
source a packet destined outside the RPL domain and not use tunneling. In this
case, we would like to simply remove the option at the border router rather
than drop the packet. Do you see cases where removing the option is
unacceptable?
I don't know.
But maybe it doesn't matter. If we don't have other alternative encapsulations
than tunneling, the point is moot. And I'm not sure we do. The two drafts
really only describe the tunneling case. Even if you source a packet from an
RPL domain and want to send it to an outside destination, you'll still have to
use both the routing header and the option, no?
I agree. As mentioned above, if the packet already includes a RPL routing
header, it does not also need to include the RPL option.
OK
6. Usage of the RPL Option
The RPL Option is only for use within a RPL domain. RPL routers MUST
process and include the RPL Option when forwarding datagrams to other
nodes within the RPL domain. Routers on the edge of a RPL domain
MUST remove the RPL Option when forwarding datagrams to nodes outside
the RPL domain.
What is it that this section says that is not already covered by sections 2 and
5:
Sect 2: Datagrams being forwarded within a RPL domain MUST include a RPL Option.
Sect 5: ... serves as the tunnel end-point, removing the outer IPv6 header
serves to remove the RPL Option as well. Otherwise, the RPL Border Router
assumes that the RPL Option was included using transport mode and MUST remove
the RPL Option from the IPv6 Hop-by-Hop Option header.
Agree. Will remove the redundant text.
OK
This option may be used to mount several potential attacks since
routers may be flooded by bogus datagram containing the RPL option.
It is thus RECOMMENDED for routers to implement a rate limiter for
datagrams using the RPL Option.
Please open this up a bit. What specific danger does flooding by bogus
datagrams and RPL options cause? What would be the default settings for the
rate limiter?
The option contains information that can affect the operation of RPL. For
example, an inconsistent Rank value can cause a RPL router to reset its trickle
timer.
After some careful thought, I'm not sure specifying a default setting for a
rate limiter is the best approach. Determining what is acceptable vs.
unacceptable can vary greatly between different deployments and environments.
But rather than rate limiting, how about the following:
This option may be used to mount several potential attacks since
routers may be flooded by bogus datagrams containing the RPL
option. In particular, an inconsistent Rank value can cause a RPL
router to reset its DIO Trickle timer. Thus, it is RECOMMENDED
that a RPL router monitor triggers caused by receiving a RPL
option and log conditions when the average rate is higher than
expected.
I like your description of the problem. But given the possibility of some DIO
timer issues, wouldn't it be prudent to actually have some kind of rate
limiting? Maybe not rate limiting of packets with this option, but rate
limiting of packets causing a trigger to happen?
How about the following text?
"In order to avoid any unacceptable impact on network operations, an implementation
MAY allow a limit to be placed on the number of triggers caused by receiving a RPL
option, and MAY allow a limit to be placed on the rate of messages sent by a specific
neighbor. It MAY also allow logging an error or sending a notification when a rate
threshold is reached."
OK otherwise, but I would prefer to see a default for such a rate limit in the spec.
That is, specify that by default such limit should be <some rate>.
Opt Data Len: 8-bit field indicating the length of the option, in
octets, excluding the Option Type and Opt Data Len fields.
Down 'O': 1-bit flag as defined in Section 11 of
[I-D.ietf-roll-rpl<http://tools.ietf.org/html/draft-ietf-6man-rpl-option-03#ref-I-D.ietf-roll-rpl>].
Rank-Error 'R': 1-bit flag as defined in Section 11 of
[I-D.ietf-roll-rpl<http://tools.ietf.org/html/draft-ietf-6man-rpl-option-03#ref-I-D.ietf-roll-rpl>].
Forwarding-Error 'F': 1-bit flag as defined in Section 11 of
[I-D.ietf-roll-rpl<http://tools.ietf.org/html/draft-ietf-6man-rpl-option-03#ref-I-D.ietf-roll-rpl>].
RPLInstanceID: 8-bit field as defined in Section 11 of
[I-D.ietf-roll-rpl<http://tools.ietf.org/html/draft-ietf-6man-rpl-option-03#ref-I-D.ietf-roll-rpl>].
SenderRank: 16-bit field as defined in Section 11 of
[I-D.ietf-roll-rpl<http://tools.ietf.org/html/draft-ietf-6man-rpl-option-03#ref-I-D.ietf-roll-rpl>].
Values within the RPL Option are expected to change en-route.
This specification needs to describe what the behavior of a router is with the
content of the option. I think this is easy, you should just add to the end:
"The processing shall follow the rules described in Section 11.2 of [roll-rpl].
Agree.
As an aside, the entire Section 11 is marked in roll-rpl as non-normative. I
don't think that's actually right as far as 11.2 goes, because it contains tons
of MUSTs and SHOULDs. Perhaps you want to fix that in AUTH48...
Right.
OK
Thanks.
--
Jonathan Hui
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
