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

Joe Touch <touch@isi.edu> Wed, 17 June 2015 18:24 UTC

Return-Path: <touch@isi.edu>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4BF1A00EF for <v6ops@ietfa.amsl.com>; Wed, 17 Jun 2015 11:24:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.011
X-Spam-Level:
X-Spam-Status: No, score=-5.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oQ1_sAbHtpG for <v6ops@ietfa.amsl.com>; Wed, 17 Jun 2015 11:24:27 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AC541A00EE for <v6ops@ietf.org>; Wed, 17 Jun 2015 11:24:27 -0700 (PDT)
Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t5HINCFO024587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 17 Jun 2015 11:23:14 -0700 (PDT)
Message-ID: <5581BB0E.70005@isi.edu>
Date: Wed, 17 Jun 2015 11:23:10 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: "Fred Baker (fred)" <fred@cisco.com>
References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <F1D4404E5E6C614EB9D3083F4D15A7E7C4A92C@hex02> <D17F4C51.4ABB0%evyncke@cisco.com> <20150611165858.GT39827@ernw.de> <CAFU7BAR7m0sZsU9Rc=fUao32zaRE1=9XMBWjiL0AukehdpVpWQ@mail.gmail.com> <5580CC33.2080503@gmail.com> <8447882A-6B4B-4ABE-9BDF-5DA7AFE13AB1@cisco.com> <CAD6AjGSUPV_9EEQGCRHRpKe8Hejgx_CMPq6bEkCsK3v4qmgJgg@mail.gmail.com> <CAD6AjGSFEG1Gi_EDC+Qxd0bxx=rdFveRbVq20ODZE6B5rDwF_Q@mail.gmail.com> <5581B628.5030206@isi.edu> <251C17CD-BFA3-4A59-AC9B-16FB8426E961@cisco.com>
In-Reply-To: <251C17CD-BFA3-4A59-AC9B-16FB8426E961@cisco.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/LQ0Hp6AlV6l0xXT54_XWKSN90T0>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] Extension Headers / Impact on Security Devices
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2015 18:24:28 -0000


On 6/17/2015 11:15 AM, Fred Baker (fred) wrote:
> 
>> On Jun 17, 2015, at 11:02 AM, Joe Touch <touch@isi.edu> wrote:
>>
>> IPv6 *is* the innovation, and because of that - for over 15 years -
>> "you" (commercial vendors) told users how expensive it would be to
>> implement and it wasn't ready (because "you" were making higher margins
>> on IPv4 equipment).
> 
> I don't think that's a fair statement.

Perhaps not from those on the vendor's front lines trying to get support
for these new protocols into products, but from where the customers sit,
that's what we see.

Recall there was a time when IPv4 didn't run fast enough and there were
proposals to "water it down" so hardware could keep up - or simply skip
IP forwarding altogether (via flow/tag switching).

The point of my comment was to note that we're repeating history here.
We're back where innovation is someone else's problem because hardware
can't keep up.

I have more faith in the hardware designers. *Temporary* edicts such as
"keep the chain short" or sensible caveats such as "keep the headers in
the first fragment" are fine, but I hope we don't gut IPv6 for the sole
reason of "kicking the can down the road".

Joe