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

Fernando Gont <> Fri, 07 February 2014 02:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3240E1A05A3 for <>; Thu, 6 Feb 2014 18:54:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.403
X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RANDOM_SURE=0.499, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GYGbO44aamQj for <>; Thu, 6 Feb 2014 18:54:03 -0800 (PST)
Received: from ( [IPv6:2a00:d10:2000:e::3]) by (Postfix) with ESMTP id 9891C1A05A2 for <>; Thu, 6 Feb 2014 18:54:03 -0800 (PST)
Received: from [2001:5c0:1400:a::843] by with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from <>) id 1WBbZc-000497-IF; Fri, 07 Feb 2014 03:53:48 +0100
Message-ID: <>
Date: Thu, 06 Feb 2014 23:52:35 -0300
From: Fernando Gont <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Randy Bush <>
Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers
References: <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Thomas Narten <>, "C. M. Heard" <>, Tim Chown <>, "" <>, Suresh Krishnan <>
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: Fri, 07 Feb 2014 02:54:05 -0000

Hi, Randy,

On 02/06/2014 09:23 PM, Randy Bush wrote:
>>> 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.
>> Well, IPv6 *might* give a fresh start in this respect -- there *might*
>> be IPv6 NAT.. but not necessarily. So.. while the end result might be
>> the same, it need not.
> and cash could fall from the sky

You missed the rest of my response:

I was simply arguing that NATs are not the reason for which anything
other than TCP or UDP wouldn't fly over IPv6. The outcome might be the
same... but for different reasons.

However, what I believe is the high order bit of the discussion is to
try bridge what seems to be a gap between standards making and
operational reality. If what we're heading is towards "no new extensions
nor transport protocols", let's spell that out. And if that's not the
plan, let's see if there's anything that can be done fo that to be

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.

Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492