Re: A problem with RFC 6465's Uniform Format for Extension Headers

[Fernando Gont <[e-mail]>]

Hi, Suresh,

Thanks so much for your response! Please find my comments in-line...


On 02/05/2014 01:06 AM, Suresh Krishnan wrote:
> 
> "Yes we wanted to do this as well, but the WG didn't want to waste a
> protocol number for something that may never be used"

Short version of my response :-) :

This seems to have happened two/three years ago... so it might be
worthwhile to revisit that decision. In particular:

1) If this problem remains un-addressed, then it's impossible to
differentiate between new upper-layer headers (e.g. a new transport
protocol) and new extension headers. Since such new extension headers
might be leveraged for malicious purposes, the end-result is that
middle-boxes are going to block *everything* (see RFC7045), which means:

  + no new extension headers
  + no new transport protocols

... so I think we really don't want to go there.


2) Among the possible ways to solve this problem is to just use *a
single* Next Header value -- which turns out how we both tried to solve
separately (which is probably an indication that that's a sensible way
to do it ;-) ). It doesn't seem too onerous to use a single Next Header
value... particularly when the alternative is to implicitly waste all
possible Next Header values (see above).

3) We really want to make the extension headers "workable" (RFC7045).
Current stats seem to indicate that they are being massively dropped in
the public Internet (see e.g.
<http://www.iepg.org/2013-11-ietf88/fgont-iepg-ietf88-ipv6-frag-and-eh.pdf>
.. and Tim Chown's research show similar numbers). We either do
something about it.. or else we'll have to completey forget about ext
headers.


> But unfortunately, it turns out that this was not really a problem the
> WG wanted to solve with RFC6564 :-). 

:-)



> I think Thomas Narten's comment summarized the wg feeling at the time
> the best.
> 
> "My general sense is that this work is mostly just good common sense
> advice to someone who has a need to define a new extension type. But
> until we see such a concrete proposal, I am not convinced (yet) that
> we should define anything new that suggests people go change
> implementations or allocate code points. Both are premature."

The problem here is that unless we do something now, in the event
someone needs to define a new extension header (or transport protocol!),
it simply won't be possible.

So, by doing nothing, we kind of are implicitly saying "No new extension
headers, and no new transport protocols".  *That's* really premature.

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492