Re: New Version Notification for draft-hui-6man-rpl-option-00.txt

[Vishwas Manral <[e-mail]>]

Hi Jonathan,

I read your draft. As I have not read RPL I have to say the draft by
itself was not self contained so was a bit hard to figure out what can
be done in the RPL option.

After finding the Traffic amplification issues, I had a draft
http://tools.ietf.org/html/draft-manral-ipv6-rh4-00 which had some
additional checks that could be required for any new RH header (we had
named it RH4 too).

Though the scope is limited to LLN with RPL, I was wondering if the
issues known would not be an issue in such a network. If not so why?

Thanks,
Vishwas

On Sun, May 30, 2010 at 9:37 PM, Jonathan Hui <[e-mail]> wrote:
>
> Hemant,
>
> Being able to change the option data hop-by-hop is fundamental to RPL's
> ability to verify routing information consistency.  That is why Section 2 of
> the rpl-option draft states that "the RPL option is expected to change
> en-route."
>
> The Router Alert Option as specified today does not satisfy this fundamental
> requirement.  Section 2.1 of RFC 2711 states that "the option must not
> change en route."
>
> --
> Jonathan Hui
>
> On May 30, 2010, at 1:46 PM, Hemant Singh (shemant) wrote:
>
>> If RFC 2711 already defines a Router Alert Option to use, why do we need
>> a new option in the Hop by Hop option for roll as specified by this
>> document?  I suggest we just use a new code value for roll with RFC 2711
>> and be done with it.  See section 2.1 of RFC 2711.  Here is a list of
>> what IPv6 protocols already use the Router Alert Option.
>>
>> http://www.iana.org/assignments/ipv6-routeralert-values/ipv6-routeralert
>> -values.xhtml
>>
>> RFC 2711 also already lists the security concerns with use of the Router
>> Alert Option.  This document is repeating the same security concern.
>> Further one should look at
>>
>> http://tools.ietf.org/html/draft-rahman-rtg-router-alert-considerations-
>> 03
>>
>>
>> Hemant
>>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Philip Levis
>> Sent: Saturday, May 29, 2010 1:08 PM
>> To: JP Vasseur
>> Cc: [e-mail]
>> Subject: Re: New Version Notification for
>> draft-hui-6man-rpl-option-00.txt
>>
>>
>> On May 17, 2010, at 6:18 AM, JP Vasseur wrote:
>>
>>> Dear all,
>>>
>>> This is to re-activate our discussion during the last IETF
>>> meetings. Feed-back are very welcome since we would like to move
>>> forward as soon as possible, this proposed extension is indeed
>>> critical for RPL to move forward.
>>>
>>> Many Thanks.
>>>
>>> JP and Jonathan.
>>
>> I strongly support this draft; it is a make-or-break extension,
>> without which RPL will not be an effective protocol. There is
>> extensive experimental evidence from many LLN deployments and
>> testbeds that the mechanisms it enables (datapath validation) are
>> critical.
>>
>> I think Jonathan has done an excellent job of narrowly defining what
>> the option can do: containing it within a RPL domain addresses most
>> of the major concerns with hop-by-hop options.
>>
>> Phil
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>