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

On 19/07/2016 07:03, Michael Richardson 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 is unclear what end-hosts can/should do. I will assume they can
> also ignore hop-by-hop options if they haven't been told to pay attention to
> them).

If they are 00 options, yes, RFC2460 is clear that for all options:

   The Option Type identifiers are internally encoded such that their
   highest-order two bits specify the action that must be taken if the
   processing IPv6 node does not recognize the Option Type:

      00 - skip over this option and continue processing the header.

  Brian

> 
> https://goo.gl/cxWkP5 this is a reference to an RFC diff between:
>       draft-ietf-roll-useofrplinfo-06.txt
> and   draft-richardson-roll-useofrplinfo-2460bis-00.txt
> 
> (Note we have only re-analyzed storing mode , so please ignore changes in
> section 6)
> 
> The summary is that in storing mode we never need to use per-hop
> IPv6-in-IPv6 encapsulation with the 2460bis text.  Packets originating from
> not-RPL aware nodes (i.e. 6LN leafs or Internet nodes), need to be
> encapsulated so that the RPI option can be added, but no complex
> considerations need apply for where to remove the RPI, as it can be left in
> place until the end-host.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 