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

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 31 October 2012 17:27 UTC

Return-Path: <brian.e.carpenter@gmail.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 2EB4721F84D3 for <v6ops@ietfa.amsl.com>; Wed, 31 Oct 2012 10:27:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.635
X-Spam-Level:
X-Spam-Status: No, score=-101.635 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, 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 NGXNXKw+Wrk9 for <v6ops@ietfa.amsl.com>; Wed, 31 Oct 2012 10:27:27 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8547421F863F for <v6ops@ietf.org>; Wed, 31 Oct 2012 10:27:27 -0700 (PDT)
Received: by mail-we0-f172.google.com with SMTP id u46so848175wey.31 for <v6ops@ietf.org>; Wed, 31 Oct 2012 10:27:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2FodnJGu3ct6mLbL6fJe9oCjD3DMc2dPNBj95upXeMM=; b=nNTiCN7CQySz5MIWCMX8pAFXBTeG97+uOUU4Arz5Bs6X2G+vZzyr6+/ec2AjkScHQA H7wxF2Lmrrtzg5iwx+68S8FoTyt2djTzMdgTDn7E9P/XR9/Ky3XSAEOhf3Wn4+k8FVg1 Kt+UnjQjP5pdfi+BiLk1WKCr0qtBkr2mE7wV2Pq+YpNf1z1ERMzaqadPuW9F5ubIomjg VlM0uybjSW61juzroSP8pQN/h2sOOvn1ZPbJzc/WuVUJPqmYbEE6NfC31n/zYYuUv5cs htM4c9RjJwTJLtvkvCGkyuM3G1EkwJ6Uwq66rGsXPiHSLj0QPuMxZPozMCqr0hpx3+pm yOvA==
Received: by 10.181.13.239 with SMTP id fb15mr3919261wid.22.1351704446728; Wed, 31 Oct 2012 10:27:26 -0700 (PDT)
Received: from [192.168.1.65] (host-2-102-217-70.as13285.net. [2.102.217.70]) by mx.google.com with ESMTPS id a10sm6686922wiz.4.2012.10.31.10.27.24 (version=SSLv3 cipher=OTHER); Wed, 31 Oct 2012 10:27:25 -0700 (PDT)
Message-ID: <50915F86.7050304@gmail.com>
Date: Wed, 31 Oct 2012 17:27:34 +0000
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Lorenzo Colitti <lorenzo@google.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>
In-Reply-To: <CAKD1Yr0mTTcVeq+Qf0fLv3UCBP_90QmStkK3Ha4tDdm3FxJjVA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: fgont@si6networks.com, 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:27:28 -0000

On 31/10/2012 12:51, Lorenzo Colitti wrote:
> On Wed, Oct 31, 2012 at 8:40 PM, Brian E Carpenter <
> brian.e.carpenter@gmail.com> wrote:
> 
>>>>> Unfortunately the IPv6 architecture requires the network to
>>>>> be transparent to arbitrary extension header chains.
>>>> Good luck with that in real networks.
>>> Agreed. "Not gonna happen."
>> I am not totally unrealistic. However, there are some things that
>> the IETF can do to make the reality a bit better than it is at
>> the moment.
>>
> 
> 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.

Come to 6man.

   Brian