Hi Jari, Could you tell us if you think that we have addressed your concerns, and we will post the new revision ?
Many Thanks, JP and Jonathan. On Sep 16, 2011, at 5:08 PM, Jonathan Hui wrote: > > Hi Jari, > > I think we are converging here as well. If there are no other comments, we > will update the draft based on your review. See below: > > On Sep 2, 2011, at 2:40 PM, Jari Arkko wrote: > > > Jonathan, > > > > Please see below. I think we are converging. The main remaining discussion > > item below is the description of what the border router does. > > > >>> > 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." > > >>> >> 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. > > >>> >> 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. > > >>> >> 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." > > >>> > >>> >> 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 > -------------------------------------------------------------------- >
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
