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

[RJ Atkinson <[e-mail]>]

At Thursday, 6th February 2014 07:21:49 -0500, Thomas Narten wrote:
> At Wed, 05 Feb 2014 01:25:03 -0300, Fernando Gont wrote:
> > 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.
> 
> But we are already there. Folk won't deploy anything other than
> TCP/UDP because NAT won't deal with it. That has already been reality
> and is the reason that other or new transport protocols appear to be
> virtually undeployable today.
> 
> Reality is that existing middleboxes tend to process what they
> understand and have been explicitely coded to deal with. They just
> punt on anything else because that is the easiest/safest thing to do.
> 
> I see little that we can do to change that.
> 
> Thomas

I agree with Thomas Narten's analysis.  

The deployed situation perhaps isn't ideal, but the IETF ought to  
hew to the deployed reality.  Today's reality is that the Internet 
is very unlikely to deploy any new transport protocol(s) or any new 
IPv6 extension headers.  My own preference (has been and) would be 
to outright ban all new IPv6 Extension Headers -- insisting that 
future IPv6 extensions be specified as options within the existing 
Destination Options header or Hop-by-Hop Options header.

ENTERPRISE/OPERATOR FIREWALLS:

I understand that some residential users have (or want to have)
pure/direct IPv6 connectivity without any firewalls/middleboxes.

(Many folks that I know have some form of home firewall. Many
of those folks demand NAT for the perceived security benefits.  
At a previous employer of mine, IPv6 NAT/NAPT was the single
most commonly requested IPv6 feature -- by a wide margin.)

However, every enterprise/corporate/similar IPv6 user (or planned 
future IPv6 user) that I can identify is staying that a full firewall 
is a non-negotiable absolute requirement for ALL Internet-related
connectivity.  The handful of content providers that I've talked with
also will not permit their content servers to be directly connected
-- all are using some form of firewall.

[Aside:  Quite commonly, the firewall device also acts as a site's 
VPN termination point (e.g. for IPsec-based or TLS-based VPNs).]

NEWER TRANSPORT PROTOCOLS:

Few, if any, IP firewalls support SCTP at present.  Ditto for NORM,
although NORM can traverse some firewalls because NORM usually runs
over UDP.  I'm not certain why SCTP has little or no deployment,
but one certainly wonders how SCTP could be deployed widely -- 
given that most firewalls simply drop all SCTP traffic.  My sense
is that any new transport protocol probably should use UDP framing
(or UDP encapsulation) if it wants to be easily and widely deployed.

There is probably more mileage to be had from further TCP optimisation/
extension than from a new reliable transport protocol.

HARDWARE PACKET PARSERS:

The handful of wire-speed packet parsers that I am familiar with
all are built out of ASICs.  The set of options/headers/protocols
that those packet parsers can process in hardware are fixed at the
time that the Verilog of the ASIC is frozen -- and will not change
during the lifetime of that ASIC's deployment.  Any unrecognised
"Next Header" value likely will cause either (a) packet to be dropped,
(b) packet to be processed without further parsing, or (c) packet
to be kicked to a CPU-based (or NP-based) slow-path packet handler.
Of those three, alternative (a) is the most likely to be seen in
the deployed Internet.

With improvements in FPGAs, one certainly can imagine that some future
generation of wire-speed hardware packet parsers would be built using
FPGAs.  Those could, in principle at least, be updated after deployment.
It is unclear to me whether such updates would be supplied by the
manufacturer or how many users would deploy updates that are supplied
by the manufacturer.

BOTTOM LINE:

My perception is that this ship sailed several years ago, and that it
is either impossible or nearly impossible to deploy any new IPv6
Extension Header (although IPv6 options carried in existing headers
still seem possible) or any new transport-layer protocol using different
framing from TCP/UDP.

Yours,

Ran Atkinson