I was mentioning this already several times offline, but I think our current IPv6 extension handling is not very well designed to put it mildly. Currently, only RPL source routing headers are supported, but they are already quite a mess and make GNRC's reception handling within IPv6 already quite hard to follow (not to mention debug or optimize). I've already tried to refactor some stuff, but it's quite a big knot to untangle. So I think its best to discuss this first.

My main issue is the very weird call hierarchy that is followed for the handling of the RPL routing handler:

gnrc_ipv6_demux();
+> gnrc_ipv6_ext_demux()           # after some prior special handling for extension headers
                                   # also some nested recursion to gnrc_ipv6_demux() in here.
                                   # Not great with limited stack space ;-)
   +> _handle_rh()                 # within gnrc_ipv6_ext.c
      # some weird stuff write-protecting everything until then
      # because now we throw away every context information GNRC provides us with
      +> ipv6_ext_rh_process()     # leaving the GNRC "realm" for a bit
         +> gnrc_rpl_srh_process() # returning to a GNRC-specific implementation of RPL

I believe we can get rid of most of the weird stuff and additional parameter handling if we do two things:

1. Removing ipv6_ext_rh_process() within that hierarchy (or moving it into GNRC and provide
   the context carrying gnrc_pktsnip_ts instead of ipv6_hdr_t and ipv6_ext_rh_t) and providing gnrc_rpl_srh_process() with the GNRC-specific information it needs to handle and write-protect the provided headers itself (bonus: no need for abstraction breaking gnrc_pktbuf_duplicate_upto() anymore).
2. Moving all extension header and encapsulated IPv6 header handling out of gnrc_ipv6_demux() and putting the whole handling of extension headers into a separate function. By their very nature those headers are too different from normal payload headers. By doing that iteratively we can also get rid of above mentioned recursion. It also hopefully, will get rid of all the current and interested parameters in the current code whose meaning make the reception code so hard to decipher and API changes like the one in ipv6/rpl: add hop-by-hop extension handling #7231 could become unnecessary (we might even be able to make gnrc_ipv6_demux() private to gnrc_ipv6.c again).

TODO:

• Remove / Move ipv6_ext_rh_process() (see gnrc_ipv6_ext: move ipv6_ext_rh (partly) to GNRC #10231)
• Move extension header / IPv6 header handling out of gnrc_ipv6_demux()
  • Move iteration out of gnrc_ipv6_ext_demux() (see gnrc_ipv6: move ipv6_ext iteration out of ext_demux() #10234)
  • Handle extension headers separately (see gnrc_ipv6: handle hop-by-hop option before forwarding #10244)
• post clean-up (simplify IPv6 reception) (see gnrc_ipv6: assume no preparsed packets #10233, gnrc_ipv6_ext: merge _handle_rh and gnrc_ipv6_ext_rh_process #10238, ...)

Here is an dependency overview of the currently open PRs: