Re: Lack of responses on WG Last Calls

[JP Vasseur <[e-mail]>]

Dear Brian,

Many thanks for your review. We addressed your comment in the new revision, just posted.

Kind Regards.

JP.
> > From: Brian E Carpenter <[e-mail]>
> > Date: December 16, 2010 3:37:50 PM PST
> > To: Brian Haberman <[e-mail]>
> > Cc: IPv6 WG Mailing List <[e-mail]>
> > 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
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> 
>