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

Andrew Yourtchenko <ayourtch@cisco.com> Thu, 25 October 2012 23:12 UTC

Return-Path: <ayourtch@cisco.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 A29ED21F887A for <v6ops@ietfa.amsl.com>; Thu, 25 Oct 2012 16:12:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.832
X-Spam-Level:
X-Spam-Status: No, score=-7.832 tagged_above=-999 required=5 tests=[AWL=2.767, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 F+NMhwImOYnP for <v6ops@ietfa.amsl.com>; Thu, 25 Oct 2012 16:11:59 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 572C721F8727 for <v6ops@ietf.org>; Thu, 25 Oct 2012 16:11:59 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9PMWcsS028078 for <v6ops@ietf.org>; Fri, 26 Oct 2012 00:32:38 +0200 (CEST)
Received: from ams-ayourtch-8718.cisco.com (ams-ayourtch-8718.cisco.com [10.55.144.249]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9PMWa4B008311; Fri, 26 Oct 2012 00:32:36 +0200 (CEST)
Date: Fri, 26 Oct 2012 00:32:36 +0200
From: Andrew Yourtchenko <ayourtch@cisco.com>
X-X-Sender: ayourtch@ayourtch-lnx
To: Mark Andrews <marka@isc.org>
In-Reply-To: <20121025202222.185852A40C3F@drugs.dv.isc.org>
Message-ID: <alpine.DEB.2.02.1210260013030.15761@ayourtch-lnx>
References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF3A2@XCH-NW-01V.nw.nos.boeing.com> <507DA6A3.20807@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF3C3@XCH-NW-01V.nw.nos.boeing.com> <507DAB13.2010704@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF3CE@XCH-NW-01V.nw.nos.boeing.com> <507DDF8A.9010607@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF5AB@XCH-NW-01V.nw.nos.boeing.com> <BB219517-B488-4777-AE9C-35C57BE91263@kumari.net> <Pine.LNX.4.64.1210171337470.7337@shell4.bayarea.net> <AC530E99-4054-4B0A-9B5C-30F9EF4A530C@kumari.net> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DF5C66F@XCH-NW-01V.nw.nos.boeing.com> <5085319B.60707@inex.ie> <CAKD1Yr2qDsM6cCPapRmKuWw7SG-cuMd9PuiBD7ineqj7Bp4+Xw@mail.gmail.com> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> <20121025202222.185852A40C3F@drugs.dv.isc.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Cc: V6 Ops <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: Thu, 25 Oct 2012 23:12:00 -0000

On Fri, 26 Oct 2012, Mark Andrews wrote:

>> Internet involves developing for the worst case, not the best. If a small
>> but significant enough portion of sites on the Internet drop fragments, then
>> applications will be developed to avoid using fragments. Once applications
>> avoid using fragments to suit some sites on the Internet, then all sites
>> on the Internet may as well drop them, because they've been rendered useles=
>> s.
>
> Or they learn to adapt and use fragments where they work.  DNS clients
> do this today.  They get stuck behind equipment that:
>
> 	* drops packets > 512 bytes
> 	* drops fragments
> 	* drops EDNS packets
> 	* drops packets with DO set
> 	* drops packets where the initial fagment doesn't arrive first
>
> The clients adapt the queries they make to get responses back.
>
> They work much more efficiently however if they can get fragmented EDNS
> responses back.

What about DNSSEC ? Seems like there's a problem if the fragmentation 
does not work correctly: https://tnc2012.terena.org/getfile/1603

--a