IETF Logo Mail Archive

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

Fernando Gont <fgont@si6networks.com> Wed, 31 October 2012 17:54 UTC

Return-Path: <fgont@si6networks.com>
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 A97D521F886A for <v6ops@ietfa.amsl.com>; Wed, 31 Oct 2012 10:54:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 D5fO6y0cGmr8 for <v6ops@ietfa.amsl.com>; Wed, 31 Oct 2012 10:54:27 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 1F45521F8855 for <v6ops@ietf.org>; Wed, 31 Oct 2012 10:54:27 -0700 (PDT)
Received: from r186-52-22-47.dialup.adsl.anteldata.net.uy ([186.52.22.47] helo=[192.168.51.104]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from <fgont@si6networks.com>) id 1TTcUf-0002Er-AG; Wed, 31 Oct 2012 18:54:21 +0100
Message-ID: <509165B8.404@si6networks.com>
Date: Wed, 31 Oct 2012 15:54:00 -0200
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
References: <CAKD1Yr13cNspdWvTaXxHt4R_8UB-CKeA4nq8_XWrkbFGCgW7Gg@mail.gmail.com> <5090DECF.3050100@gmail.com> <CAKD1Yr1dUy-f78A2+kfA7NjpzD0WQRT8iwqGYAm5A=Erodpn-A@mail.gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <CAKD1Yr0mTTcVeq+Qf0fLv3UCBP_90QmStkK3Ha4tDdm3FxJjVA@mail.gmail.com> <50915F86.7050304@gmail.com>
In-Reply-To: <50915F86.7050304@gmail.com>
X-Enigmail-Version: 1.4.5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: v6ops@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: Wed, 31 Oct 2012 17:54:27 -0000

On 10/31/2012 03:27 PM, Brian E Carpenter wrote:
>> But why? If you can't get extension headers to work reliably in the
>> Internet (as opposed to in your own network), then what's the point? You
>> still need a fallback plan for when they get dropped, and users don't like
>> waiting. Why not just use the more reliable plan all the time?
> 
> For MTU/fragmentation issues, there may be such a plan.
> 
> There are other extension headers for which there is no such plan.

The end-result is/is going to be that sine extension headers are not
reliable, no mechanism will be able to rely on them. SO, in practice,
you better put your "options"/fragmentation somewhere else, or prepare
to be dropped.

It happened with IPv4 options already....

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

v2.23.0 | Report a Bug | By Email