AD reviews of draft-ietf-6man-rpl-option and draft-ietf-6man-rpl-routing-header

[Jari Arkko <[e-mail]>]

JP, Jonathan,

Has there a been response to the two reviews from June? I'd like to move 
these drafts forward...

Jari

Jari Arkko kirjoitti:
> I have reviewed this draft. Some of the issues from the other draft 
> are visible in this one as well, and I saw two additional substantive 
> issues:
>
> - we need to specify the behavior with regards to the data in this 
> option better
> - the text about processing packets in RPL border routers should be 
> written in a different manner
>
> Both of these should be easily addressed, however. Please revise the 
> draft and we can send the draft to IETF Last Call.
>
> 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
>> MAY 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."
>
>>   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.
>
>> 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.
>
>> 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.
>
>> 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.
>
>> 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."
>
>> 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.
>
>> 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?
>
>>    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].
>
> 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...
>
> Jari
>
>