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

[Michael Richardson <[e-mail]>]

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...)

(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).

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 <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-