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

Hello Tim:

The spec of the case that requires IP in IP (in effect the root relaying a packet as opposed to sourcing it) was not followed by implementors. 

People figured that the overhead for encapsulation limited the size of the network to 2 or 3 hops. 

This is now somewhat alleviated by the new 6LoRH compression schema. Thus a first tentative implementation of Michael's draft in openWSN.

But the architectural value vs. energy/ bandwidth cost is still hardly convincing for the world outside IETF. 

Regards,

Pascal

> Le 20 juil. 2016 à 17:11, Tim Chown <Tim.Chown@jisc.ac.uk> a écrit :
> 
> Hi Pascal,
> 
> What RFC6554 (defining the RPL Type 3 RH) appears to say is:
> 
>   1.  If the SRH specifies the complete path from source to
>       destination, the router places the SRH directly in the datagram
>       itself.
> 
>   2.  If the SRH only specifies a subset of the path from source to
>       destination, the router uses IPv6-in-IPv6 tunneling [RFC2473] and
>       places the SRH in the outer IPv6 header.  Use of tunneling
>       ensures that the datagram is delivered unmodified and that ICMP
>       errors return to the source of the SRH rather than the source of
>       the original datagram.
> 
> Which seems to suggest otherwise.
> 
> Is it case 2 where insertion is happening rather than tunnelling? Case 1 is at the source, which is compliant with RFC2460. Curious to know...
> 
> Tim
> 
>> On 19 Jul 2016, at 12:37, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
>> 
>> 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
>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 