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

RJ Atkinson <> Mon, 10 February 2014 13:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 113941A02C9 for <>; Mon, 10 Feb 2014 05:54:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Zy4qzZCNdQeI for <>; Mon, 10 Feb 2014 05:54:18 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c00::22f]) by (Postfix) with ESMTP id B141E1A083F for <>; Mon, 10 Feb 2014 05:54:18 -0800 (PST)
Received: by with SMTP id j5so9392176qaq.20 for <>; Mon, 10 Feb 2014 05:54:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:content-type:content-transfer-encoding:date:subject:to :message-id:mime-version; bh=LVUZEFNRDDO0DgzuKbe1qUG8p4HWQFc7MZXz+q9pXyQ=; b=kC4mZ06MNSBa7y7TBJCfxUeBWYEzAQ9RLxLOiiguGYoBqF2fk52jgPc8O6Smd2rGT4 AQ8dKBqb4utwANXjaFIPmtTPB/dY+Puc3hdsoShH7eOy/PVRM9ZHpLev3omQYHUTYtXx XQeWNEl3Fyl1ndqDmFU1HTW56Irsu5neMjH8fv6DYzP7X143VU9egvwjvhOcc6EbMqZt FEye5sbax5kGyPkCfGXWBX9mwU+A0KOIAeo9x3PxWp14ROuH2eumsrl1F0od5bWKCNXr PhODrayxjOqBvxqqf/PHEhCyF++4ZsSwsyyJ5g3//KEfqNbwRFAJw1CybPWurtSzoWbC d1/A==
X-Received: by with SMTP id h44mr45317831qgd.68.1392040458517; Mon, 10 Feb 2014 05:54:18 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id p10sm10211482qag.8.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 05:54:18 -0800 (PST)
From: RJ Atkinson <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Date: Mon, 10 Feb 2014 08:54:23 -0500
Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers
Message-Id: <>
Mime-Version: 1.0 (Apple Message framework v1283)
X-Mailer: Apple Mail (2.1283)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 Feb 2014 13:54:22 -0000

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.


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).]


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.


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.


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.


Ran Atkinson