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 > > > > > >
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
