Subject: impacts of rfc2460bis on draft-ietf-roll-useofrplinfo

From: Michael Richardson <[email-masked]>
Date: Mon, 18 Jul 2016 15:03:13 -0400

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Jul 2016 17:28:58 +1200

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

> also ignore hop-by-hop options if they haven't been told to pay attention to

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

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 19 Jul 2016 06:31:07 -0400

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

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

A type=10 option was allocated by RFC6553

I think it was a mistake.  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.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Jul 2016 23:05:44 +1200

> It's not what *I* want to do, it's what *I* can expect *others* to do.

Well, it legitimizes a router simply ignoring a HbH header. Isn't that useful?

> I think it was a mistake. 

Agreed.
    Brian

> We have discussed changing it as we add

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 19 Jul 2016 11:37:52 +0000

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 <[email-masked]> a écrit :
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Tim Chown <[email-masked]>
Date: Wed, 20 Jul 2016 15:11:06 +0000

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) <[email-masked]> wrote:
> 
> Actually Brian:
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 20 Jul 2016 16:24:10 +0000

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 <[email-masked]> a écrit :
> 
> Hi Pascal,
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 20 Jul 2016 13:17:11 -0400

> Well, it legitimizes a router simply ignoring a HbH header. Isn't that

It doesn't tell me what behaviour I can expect, just what I'm allowed to do
myself.  In RPL networks, we don't want to ignore that HbH header, we simply
want to avoid having to go through conniptions to remove it.

today, at ROLL, we went through some slides to explain the improvements that
2460bis "Note" does for us.   Here are the link to the slides:

The ROLL WG meeting we seemed to have consensus in the room to wait for
rfc2460bis to progress, and to have a normative reference to it in
useofrplinfo.

I have merged the changes that were shown in the links I posted before:
  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

I have merged the changes into draft-ietf-roll-useofrplinfo-07, so you can
now see the changes directly in the datatracker.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 20 Jul 2016 20:21:14 -0400

> 2460bis "Note" does for us.   Here are the link to the slides:

https://www.ietf.org/proceedings/96/slides/slides-96-roll-2.pdf
starting at slide 9.
I will probably fix some minor typos and fill some missing labels
to make it stand-alone

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jul 2016 17:45:11 +1200

> I will probably fix some minor typos and fill some missing labels

Again, I'm OK with the "Note" as a compromise to get us to Internet Standard.
Without the "Note" the compromise breaks. Remember, for Internet Standard we
are focussed on proven Internet-wide interoperability.

Once that's done I think we should circle around again and look seriously
at this and other "local use" issues. What should we say on top of
Internet-wide standard about local use? We have a clear local use mechanism
for DSCPs. We argued through the same issue for the latest revision of the
flow label standard. For that matter, ULAs and NPTv6 also touch local use
issues. I think it's a future work item after shipping 2460bis.