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

[Tim Chown <[e-mail]>]

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) <[e-mail]> 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 <[e-mail]> a écrit :
>> 
>>> On 19/07/2016 22:31, Michael Richardson wrote:
>>> 
>>> Brian E Carpenter <[e-mail]> 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 <[e-mail]>, Sandelman Software Works
>>> -= IPv6 IoT consulting =-
>> 
>> _______________________________________________
>> Roll mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/roll
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------