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

[Fernando Gont <[e-mail]>]

Hi, Ole,

On 02/07/2014 06:05 AM, Ole Troan wrote:
> 
>> But to keep hearing that e.g. extensions are expected to work
>> when I'm measuring over 40% of breakage, It seems to boil down to
>> "you, heretic! don't filter these packets!" on one side and "shut
>> up! you don't know how to run a network" on another. *That*
>> doesn't seem to be the more sane approach to this issue.
> 
> I think we have to be careful throwing these numbers about without 
> qualifying them.
> 
> aren't you in many cases detecting filtering in front of services, 
> where the operator has very good control of how their traffic
> should look like?

Probably, I guess -- I'm in the process of finding out where these
packets are being filtered.

But widespread filtering of stuff that is supposed to be "ignored if
unsupported" eventually leads to "It's not usable, because if you try
to, your packets get dropped".

If, say, tomorrow you come up with this shiny cool new Dst Opt-based
extension for clients, then, from starters, you would have to think of
a back-up plan, because in more than 40% cases your packets would get
dropped just because of that extension. -- that's where we are right now.


> you are not saying if you, me and 8 of our other friends decided
> to use a new L4 protocol we invented between ourselves, those
> packets would in 40% of cases be filtered by the Internet core?

I'm certainly not.

But let's consider this:

We want IPv6 to be extensible, so we have IPv6 extension headers. And
we want middle-boxes to be able to find the upper layer header (or
else the higher the chances our packets will be dropped on the floor).
The options/scenarios are:

1) Pre-RFC6465: If I'm a middle-box and receive a packet, I have no
way of telling whether it's a protocol that I'm supposed to allow
(that just happens to have a unsupported EH), or an upper-layer
protocol that I shouldn't be letting through. So my options:
      a) Drop those packets -- and now you have widespread deployment of
         devices at the edge that wouldn't allow new transport
         protocols or new EHs

      b) Allow everything -- which I doubt would be the case if e.g. any
         sort of firewalling is meant to be in place.

2) post-RFC6465/now:
Firstly, I'd like to believe that RFC6465 has not been interpreted as
"any other Next-Header values you don't explicitly support should
follow the uniform format". Or else a new transport protocol would
look (to any device trying to process the entire IPv6 header chain)
like a malformed EH and get dropped.  -- it might be a dumb
interpretation.. but that's how many of us interpreted RFC6465 at one
point or another.

Secondly, we really need to provide a mechanism for middle-boxes to
find the upper-layer header. Simple example: Let's say that I have a
home firewall that is meant to just allow outgoing communication
instances (for which extension headers are deemed as "fine"). Without
a way to parsing new EHs (such as in the I-D we posted). Such firewall
would simply drop new EHs, not because it wants, but rather because it
has no way of telling what's an extension, and what's a protocol that
it doesn't want to let through. In that case, we should completely
forget about our ability to specify new (usable) EHs.


Thoughts?

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