Re: Comments on <draft-gont-6man-rfc6564bis-01>

[Hagen Paul Pfeifer <[e-mail]>]

> On October 27, 2015 at 1:51 AM Brian E Carpenter
> <[e-mail]> wrote:

Hey Brian

> That is 6 extension header types. There are 11 header types
> currently registered:
> http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#extension-header
> .
> Where does the code handle the other 5, and in particular how does it
> handle the experimental values, whose structure is completely open?

The Linux Kernel must handle some types a little bit different. So for
example see
http://lxr.free-electrons.com/source/include/uapi/linux/in6.h#L130 and
click on IPPROTO_MH you will find the code how IP Mobility is implemented.
HIP and SHIM is not mainlined and not supported yet. Sure, a patch can
help to make these extension headers known to let the kernel ignore them.
If currently one of these extension header is received the packet will be
discarded. Maybe this is an indicator that HIP/SHIM is not widely adopted.
;-) Note: "received" means in particular the packet is locally delivered.
Let's skip the decision what happens to HIP/SHIM packets over netfiltered
forwarding paths.

The experimental range is not supported because it is impossible! This is
the central issue and it is addressed with this ID (among other things).
Supporting the "experimental range" is not possible because the kernel do
not know how the particular extension header is encoded! The kernel do not
know how to jump over unknown extension header. What is required is a
guarantee that a particular extension header is encoded in a pre-known
format. This is where draft-gont-6man-rfc6564bis comes into play.

1. Define a Universal Extension Header with a TLV like encoding where the
header size is always at the same position
2. Provide the Kernel a guarantee that a header is encoded with the
Universal Extension header

Hagen