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

[Karsten Thomann <[e-mail]>]

Am Freitag, 7. Februar 2014, 10:21:11 schrieb Fernando Gont:
> 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,

Hi,

I think the "simple" solution is to provide middle boxes an offset to the upper layer header, if the 
EH is unknown to the box, it can still identify the upperlayer.

With that offset every middlebox can identify the used transport protocol without knowledge of 
any future EH.

I know that it is not that easy and has it's own pros and cons, but I provide it as an idea to solve 
the problem.

Regards
Karsten