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

Brian E Carpenter <> Mon, 10 February 2014 19:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 561BF1A03C9 for <>; Mon, 10 Feb 2014 11:06:39 -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 Y4os0K8eE4-m for <>; Mon, 10 Feb 2014 11:06:37 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c01::229]) by (Postfix) with ESMTP id 4556A1A03A5 for <>; Mon, 10 Feb 2014 11:06:37 -0800 (PST)
Received: by with SMTP id up15so6641095pbc.14 for <>; Mon, 10 Feb 2014 11:06:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GtEnt1WRNCNXrKBvk/50YdTBR4Ow1fhuOA7HsL4DkTs=; b=fOFE66cYrcIqufRROV7PpogSGdlNgCj6w1Oi18OBAJxsVGlDgzuJIf1vW2F0K72AOK xlIDJ9yUgSE7+Zl/ZO+gq4p7qcMaAoNrTdkhZBhQMlrnQPjFM6/U+Yugh2EgfFXaiPQ+ EVQRXN6gPAbdn+lhjvTL0ssmyoHRfFJi/lExz6LX0SL76a8Ot/n/mLd+8Jjh88xI0Twg 5oSILfIO6/Y9xPm22Ctpfcm1YV0/FqPnAtLlW091WRXaOa++lHudtxEGOHF+pmQPO8BX xUErCIboipjMDrIo9Gs2myz38kVg04A+MqN5fu5wT0+iRBhrA6PZdDk8Qw9yITOWAcZf t4pg==
X-Received: by with SMTP id ro9mr39775219pbc.72.1392059196095; Mon, 10 Feb 2014 11:06:36 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id yo9sm117125994pab.16.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 11:06:34 -0800 (PST)
Message-ID: <>
Date: Tue, 11 Feb 2014 08:06:34 +1300
From: Brian E Carpenter <>
Organization: University of Auckland
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
To: RJ Atkinson <>
Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
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 19:06:39 -0000

On 11/02/2014 02:54, RJ Atkinson wrote:
> 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.

Not to dispute the facts of life as Thomas and Ran present them,
but let me point out that this argument recurses. If we forbid
additional Extension Headers (i.e. freeze things as they are listed
in RFC 7045) but allow new Options, in a few years somebody will

   Today's reality is that the Internet is very unlikely to deploy
   any new IPv6 Destination Options, because firewalls block
   unknown options.

Guess what? This argument has been used against new IPv4 options
since 1994 to my personal knowledge.

(Hop-by-hop options are pretty much a dead duck anyway.)

Just saying...