Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop

Joe Touch <touch@isi.edu> Thu, 01 November 2012 20:21 UTC

Return-Path: <touch@isi.edu>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFF021F96E9 for <v6ops@ietfa.amsl.com>; Thu, 1 Nov 2012 13:21:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.522
X-Spam-Level:
X-Spam-Status: No, score=-103.522 tagged_above=-999 required=5 tests=[AWL=-0.923, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCHgpn8ZpPc2 for <v6ops@ietfa.amsl.com>; Thu, 1 Nov 2012 13:21:42 -0700 (PDT)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 47BBC21F96DD for <v6ops@ietf.org>; Thu, 1 Nov 2012 13:21:42 -0700 (PDT)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id qA1KLRKs009644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Nov 2012 13:21:27 -0700 (PDT)
Message-ID: <5092D9C7.9040409@isi.edu>
Date: Thu, 01 Nov 2012 13:21:27 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Joel Jaeggli <jjaeggli@zynga.com>
References: <CAKD1Yr1BvZQudt8nrcTaFtJRTVXWH6m5M68jJ2=rQmpG8i+KcQ@mail.gmail.c! om> <CAKD1Yr1BvZQudt8nrcTaFtJRTVXWH6m5M68jJ2=rQmpG8i+KcQ@mail.gmail.com> <5092C14B.7090704@isi.edu> <20121101.202416.112557190.sthaug@nethelp.no> <5092D3FC.2010902@isi.edu> <48C09AC6-4068-4DEB-BFEF-26E1BED5305B@zynga.com>
In-Reply-To: <48C09AC6-4068-4DEB-BFEF-26E1BED5305B@zynga.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "<v6ops@ietf.org>" <v6ops@ietf.org>, "<draft-taylor-v6ops-fragdrop@tools.ietf.org>" <draft-taylor-v6ops-fragdrop@tools.ietf.org>
Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 01 Nov 2012 20:21:43 -0000

On 11/1/2012 1:11 PM, Joel Jaeggli wrote:
...
>> Then either get your vendors - of whatever boxes you want to call them - to support the current option structure, or choose not to support IPv6.
>
> That's not an operationally useful statement.

Well, we had a third alternative in IPv4, which was to avoid options. I 
don't think that's a practical alternative here.

What's more likely is that we'll start running IPv6 with fragmentation 
(and options) over IPv6 with no options just to get the fast-path 
processing.

At that point, either operators will forward those packets and we have a 
badly busted Internet that exists only at the edges, or operators will 
toss all those packets because they can't inspect them, at which point 
we have a badly busted Internet.

Continued insistence on looking inside IP packets will then result in no 
IPv6.

> and it's not what's cooked into silicon by a number of companies that are well represented at the IETF.

Sure, but it may be time to consider that their business model may be 
flawed if this is what they expect.

>> There are choices here.
>
> Indeed, and the observable phenomena on the internet indicate what operators and their vendors arrived at indepedantly.

Well, either this works or it kills IPv6.

However, as I noted, the only realistic recommendation from this group 
is "it's OK to configure routers to drop all packets with any options". 
IMO that's not an appropriate position for an ops group to take, since 
it undermines an existing standard.

So if options are being deprecated in IPv6, that needs (IMO) to be taken 
to intarea, not simply asserted here.

Joe