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

[JP Vasseur <[e-mail]>]

Thanks a lot Jari, sorry for the delay, Jonathan and I just had a discussion and will send a proposal
this week.

Thanks.

JP.

On Jul 28, 2011, at 1:55 PM, Jari Arkko wrote:

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