Dear Brian, Many thanks for your review. We addressed your comment in the new revision, just posted.
Kind Regards. JP. > > From: Brian E Carpenter <[email protected]> > > Date: December 16, 2010 3:37:50 PM PST > > To: Brian Haberman <[email protected]> > > Cc: IPv6 WG Mailing List <[email protected]> > > Subject: Re: Lack of responses on WG Last Calls > > > > For my sins, I was the Gen-ART reviewer for the main RPL spec, > > so I was able to have a quick glance at these without being > > completely mystified. > > > > On 2010-12-17 02:53, Brian Haberman wrote: > >> All, > >> Working group last calls ended 10 days ago for the two RPL-related > >> drafts (draft-ietf-6man-rpl-option > > > > This looks basically OK to me. However: > > > >> 9. IANA Considerations > >> > >> The RPL option requires an IPv6 Option Number. > > > > Shouldn't we have a "TBD" here, as used in the main text? > > And an instruction to the RFC Editor to resolve the TBD > > after IANA performs the assignment. > > > >> > >> HEX act chg rest > >> --- --- --- ----- > >> 1 01 1 01011 > >> > >> > >> The first two bits indicate that the IPv6 node MUST discard the > >> packet if it doesn't recognize the option type, and the third bit > >> indicates that the Option Data may change en-route. > >> > >> This document also creates a new IANA registry for the sub-TLVs. No > >> sub-TLVs are defined in this specification. The policy for this > >> registry [RFC5226] is IETF Review. > > > > I think the IANA will ask for a bit more guidance about the format > > and name of this registry. > > > > and > >> draft-ietf-6man-rpl-routing-header). > > > > This defines a new routing header called RH4 (subject to > > IANA confirming the "4"). One question that comes to mind > > is whether this is going to cause more or fewer operational > > difficulties than an instantiation of draft-ietf-6man-exthdr > > would. Will legacy nodes treat RH4 as they should (discard the > > packet), treat it like RH0 due to sloppy coding (which > > amounts to the same thing under RFC5095) or what? Anyway, > > it seems clear that RH4 will not successfully cross any > > non-RPL-aware routers. > > > > Now this may be deemed irrelevant because RH4 is "for use > > strictly within a RPL domain." But it seems highly likely that > > in practice, the odd non-RPL router will see one of these > > headers. So at the least, I think the draft should discuss > > what will happen in that case, even if only to point out that > > the rules of RFC 2460 mean that the packet (not just the header) > > will be dropped unless Segments Left is zero. > > > > Then: > > > >> 6.1. Source Routing Attacks > >> > >> [RFC5095] deprecates the Type 0 Routing header due to a number of > >> significant attacks that are referenced in that document. Such > >> attacks include network discovery, bypassing filtering devices, > >> denial-of-service, and defeating anycast. > >> > >> Because this document specifies that Type 4 Routing headers are only > >> for use within a RPL domain, such attacks cannot be mounted from > >> outside the RPL domain. As described in Section 5, RPL Border > >> Routers MUST drop datagrams entering or exiting the RPL domain that > >> contain a Type 4 Routing header in the IPv6 Extension headers. > > > > OK, but that implies that such attacks can still be mounted inside the > > RPL domain. How is that OK, given that ROLL may be deployed in highly > > dynamic scenarios where roaming nodes drop into a network at will? > > > > Brian > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > [email protected] > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > >
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
