Re: [v6ops] Extension Headers / Impact on Security Devices

Joe Touch <> Tue, 19 May 2015 18:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6F0621AD0CA for <>; Tue, 19 May 2015 11:54:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.011
X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DIDaCx8c3-i9 for <>; Tue, 19 May 2015 11:54:41 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7063A1AC3FE for <>; Tue, 19 May 2015 11:54:27 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id t4JIpGZb019662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 May 2015 11:51:19 -0700 (PDT)
Message-ID: <>
Date: Tue, 19 May 2015 11:51:14 -0700
From: Joe Touch <>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Ted Lemon <>, Fernando Gont <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
Archived-At: <>
Cc: "" <>
Subject: Re: [v6ops] Extension Headers / Impact on Security Devices
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 May 2015 18:54:42 -0000

On 5/19/2015 11:14 AM, Ted Lemon wrote:
> On May 19, 2015, at 12:15 AM, Fernando Gont <> wrote:
>> * The size of IPv4 options is very limited (well under 128 bytes)
>> * IYou only need to look at the IHL of the IPv4 packet to be able to
>> jump to the layer-4 protocol header. -- there's no such a thing in IPv6.
> I think it's generally agreed that we can expect devices to be somewhat limited as to how far into the packet they can peek on the fast path, and that we may need to tolerate a certain degree of non-compliance in such devices until Moore's law fixes the problem, or people become willing to pay more for it (which they probably won't absent some significant application).
> Maybe we should have an extension header that says where the transport header is... ;)

I briefly considered this at various times when this thread keeps
reappearing, but it would need to be another "HBH" header because it
needs to be examined and/or modified at any hop that modifies any other
extension header.

IPv4 knows where the transport header is but has limited option space
and can't natively support "shim" protocol layers inbetween IP and TCP
BUT it can find the transport header with localized info.

IPv6 makes the opposite trade-off.