Re: [Roll] impacts of rfc2460bis on draft-ietf-roll-useofrplinfo

Actually Brian:

What is really needed here is not for routers but for the end hosts to ignore a HbH they are not programmed to recognize. 

The new text says all nodes on the path do. This seems to include the receiver in which case we're good.

This will not change that most open implementations of RPL (all but a prototype implementing this draft) actually do header insertion.

Regards,

Pascal

> Le 19 juil. 2016 à 13:14, Brian E Carpenter <brian.e.carpenter@gmail.com> a écrit :
> 
>> On 19/07/2016 22:31, Michael Richardson wrote:
>> 
>> Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>>> 
>>>> The ROLL document draft-ietf-roll-useofrplinfo documents RFC6553 (a
>>>> Hop-by-Hop critical option) and 6554 (a form of Source Routing Header, RH3).
>>>> There is work on 6lo to allocate additional 6lowpan IPHC codes such that
>>>> the work in ROLL:
>>>> https://datatracker.ietf.org/doc/draft-ietf-roll-routing-dispatch/ can
>>>> know what kinds of things we need to compress.
>>>> 
>>>> A number of things are constrained by the need to always remove the
>>>> RFC6553 Hop-by-Hop option RPI option which had been marked critical:
>>>> i.e. drop packet if you don't understand it.
>>>> 
>>>> As a result of the change in RFC2460bis, which says that intermediate hosts
>>>> will in general not examine hop-by-hop options, but should just ignore
>>>> them, we can make certain simplications to the useofrplinfo document.
>>>> (rfc2460bis, section 4, page 8, "NOTE: While...)
>> 
>>> You can already do that, because RFC7045 section 2.2 updates RFC2460:
>>> " The IPv6 Hop-by-Hop Options header SHOULD be processed by
>>> intermediate forwarding nodes as described in [RFC2460]."
>>> which of course means that forwarding nodes MAY ignore HbH.
>> 
>> It's not what *I* want to do, it's what *I* can expect *others* to do.
>> So 7045 doesn't help me.
> 
> Well, it legitimizes a router simply ignoring a HbH header. Isn't that useful?
> 
>> 
>>> 00 - skip over this option and continue processing the header.
>> 
>> A type=10 option was allocated by RFC6553
>> 
>> I think it was a mistake.
> 
> Agreed.
>    Brian
> 
>> We have discussed changing it as we add
>> compression for 6553, 6554 and IPIP (which would be a flag day anyway).
>> This was considered undesireable, because there was a desire not to leak
>> our headers; that the internet would drop our packets if we screwed up.
>> 
>> But, it turns out that the internet won't drop out packets, so we might
>> as well optimize the situation so that if we don't need to remove our
>> Hob-by-Hop header, then we don't need extra IPIP headers.
>> 
>> --
>> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>> -= IPv6 IoT consulting =-
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll