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

RJ Atkinson <> Mon, 10 February 2014 20:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B65991A01FD for <>; Mon, 10 Feb 2014 12:07:23 -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 ziRq3SR7OGAN for <>; Mon, 10 Feb 2014 12:07:21 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c01::236]) by (Postfix) with ESMTP id 479C61A0473 for <>; Mon, 10 Feb 2014 12:07:21 -0800 (PST)
Received: by with SMTP id c9so11275607qcz.41 for <>; Mon, 10 Feb 2014 12:07:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=CF5lalMeWYQ/3A2OJKfvDh5fY0Vh4F7r06y72PbGrhs=; b=nYm3ryetVABqR22lOeILA4kvYd3yjFSmzwSgxa8JuM7AZhoS3sf5nqPKtiF9oqcdrh 8Zr51ShH7vzbKG0Tk7ERH0L3tgp2Y2jBYGu2bfUkt+1LEKn2wvEON4vRBR8aSrHdjolp oV7TVydm0OH74WlMlqYoRaholjNYfjfb70KUX4mwB6T1X1ubIph7a2NIFYiQzdm3RXu3 6nOP+UBTKUi71ftQKJe7W36ONT1zm0+4EL9l7QB0bcB45ELvo67kgndSYYHOpiaPaP4b XiPjypUJ/yIQYVW+fdailVuCf2SsZhqvqPCSmISaNQaRLU00Q1MrYf9U0pKZnTFisb/Q xYdg==
X-Received: by with SMTP id b79mr47812302qge.108.1392062840950; Mon, 10 Feb 2014 12:07:20 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id 3sm45770442qan.15.2014. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 12:07:20 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1283)
Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers
From: RJ Atkinson <>
In-Reply-To: <>
Date: Mon, 10 Feb 2014 15:07:19 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <>
References: <> <>
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 20:07:23 -0000

On 10  Feb 2014, at 14:06 , Brian E Carpenter wrote:
> 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 write
>   Today's reality is that the Internet is very unlikely to deploy
>   any new IPv6 Destination Options, because firewalls block
>   unknown options.

(I am not sure, but I think Fernando might have posted this,
or words like this, within the past week. :-)

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

Many ISPs have long declined to carry IPv4 transit packets that
contain IPv4 options because all IPv4 options create interrupts
to transit routers (i.e. easily exploited DDOS attack vector on
the ISP and its routers).  That reality creates a large barrier 
to deployment of anything in the global Internet.

A key difference for IPv6, compared with IPv4 options, is that any 
options inside an IPv6 Destination Options header do NOT have the 
hop-by-hop behaviour (from the router's perspective), so they
are not automatic easily-exploited DDOS attack vectors on the ISP
or its routers.

So there is a meaningful technical difference between the 
IPv4 history and the case of options in an IPv6 Destination
Options header.

As to firewalls, the IPv6 firewalls seem (on average) to be more
configurable (e.g. often ICMPv6 has selective filters whereas, 
in the same box, ICMPv4 only has "drop all/accept all" filtering).

Some sites deliberately will configure their firewalls to drop
nearly everything optional (headers, transport protocols, flying
geese, whatever).  Nothing here will change that for such sites.

Other sites configure their firewalls more selectively.  What we
do here might have an impact on those deployments and sites.

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

Agreed.  Many ISPs long ago decided that they will drop all
IPv6 packets with the IPv6 Hop-by-Hop Header at their ingress
border router.  The "hop-by-hop" behaviour creates an easily
exploited DDOS attack vector on the deployed infrastructure.
Bad actors found that out years ago, and the ISPs responded
shortly thereafter.


I don't think that draft-gont-6man-ipv6-universal-extension-header
is worth any time investment, because it can't change the deployed 
operational behaviour.

If we bother to do anything, we ought to just acknowledge reality
and say that no more IPv6 extension *headers* are allowed.  Instead,
options must be used.  We also should note that options with hop-by-hop
behaviour likely cannot be deployed reliably across the global public
Internet.  That would mean that any "new" NextHeader value would
denote a transport-layer protocol (which I think also would be 
very difficult to deploy - I have never seen SCTP on-the-wire).