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