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

joel jaeggli <joelja@bogus.com> Mon, 22 October 2012 16:42 UTC

Return-Path: <joelja@bogus.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 252D821F8B7E for <v6ops@ietfa.amsl.com>; Mon, 22 Oct 2012 09:42:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.119
X-Spam-Level:
X-Spam-Status: No, score=-102.119 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 48JkyLf+sH7C for <v6ops@ietfa.amsl.com>; Mon, 22 Oct 2012 09:42:44 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id BD83D21F843E for <v6ops@ietf.org>; Mon, 22 Oct 2012 09:42:44 -0700 (PDT)
Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q9MGgeof020533 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 22 Oct 2012 16:42:41 GMT (envelope-from joelja@bogus.com)
Message-ID: <5085777C.2010404@bogus.com>
Date: Mon, 22 Oct 2012 09:42:36 -0700
From: joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121002 Thunderbird/16.0
MIME-Version: 1.0
To: Tom Taylor <tom.taylor.stds@gmail.com>
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> <5081A245.9050707@gmail.com>
In-Reply-To: <5081A245.9050707@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 22 Oct 2012 16:42:41 +0000 (UTC)
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: Mon, 22 Oct 2012 16:42:45 -0000

On 10/19/12 11:56 AM, Tom Taylor wrote:
> On 19/10/2012 2:11 PM, Templin, Fred L wrote:
>>> other than causing bandwidth / pps DoS attacks, or alternatively 
>>> tickling
>>> obscure ipv6 stack bugs, no.  At least in theory.
>>
>> There's no excuse for broken IPv6 stacks that can't handle
>> fragmentation and reassembly. About DoS concerns, if the
>> network is going to intentionally break frag/reass out of
>> concern for edge devices that might not be able to handle
>> the load, then that is very bad for applications that cannot
>> reduce the size of packets they send down to 1280. Again,
>> tunnels fall into that category.
>>
>> So, if tunnels cannot rely on ICMP PTB and also cannot rely
>> on IPv6 frag/reass then there is only one option remaining:
>> https://datatracker.ietf.org/doc/draft-templin-intarea-seal/

They can implement fragmentation in their upper layer encapsulation 
rather than using the ip fragmentation header and two or more fragmented 
ip datagrams in addition to seal, SSL/TLS-vpn's and SSTP have to do the 
same thing...
>> .
> which, as a matter of fact, came up briefly in the Interim Meeting 
> discussion.
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>