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

Mark Smith <markzzzsmith@yahoo.com.au> Tue, 30 October 2012 20:14 UTC

Return-Path: <markzzzsmith@yahoo.com.au>
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 82EB521F8639 for <v6ops@ietfa.amsl.com>; Tue, 30 Oct 2012 13:14:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.131
X-Spam-Level:
X-Spam-Status: No, score=0.131 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, FROM_LOCAL_NOVOWEL=0.5]
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 FGW8tZ3Ja5bd for <v6ops@ietfa.amsl.com>; Tue, 30 Oct 2012 13:14:53 -0700 (PDT)
Received: from nm1.bullet.mail.ac4.yahoo.com (nm1.bullet.mail.ac4.yahoo.com [98.139.52.198]) by ietfa.amsl.com (Postfix) with ESMTP id 574C521F8624 for <v6ops@ietf.org>; Tue, 30 Oct 2012 13:14:53 -0700 (PDT)
Received: from [98.139.52.196] by nm1.bullet.mail.ac4.yahoo.com with NNFMP; 30 Oct 2012 20:14:48 -0000
Received: from [98.139.52.163] by tm9.bullet.mail.ac4.yahoo.com with NNFMP; 30 Oct 2012 20:14:48 -0000
Received: from [127.0.0.1] by omp1046.mail.ac4.yahoo.com with NNFMP; 30 Oct 2012 20:14:48 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 414856.16493.bm@omp1046.mail.ac4.yahoo.com
Received: (qmail 93024 invoked by uid 60001); 30 Oct 2012 20:14:47 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1351628087; bh=f8tm1F6qY3HyuuGXBOh1wP5N2NEjNBcudPJUSB6a48I=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Bgu4QJyJiqAXFgvyyobFqFAo0uF7B4U9SqZeZGQeybVWAM3F34SSOnaGxpt+mUYLhZECxMWHxrnsipXW7cFGcWFDRktThJDarIVBQgkdXqltylkdUE3uvLMcBPKzl2vbt0wtQ2CrBkOiVinJcAf9sx8aR3h4hQSK7F6CSi5fKVc=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=08U+0QN3ftstmWiJkG/CsjBDMtXJWlAXSwFkFJ9ofKznNg8TJaDbwRUKCrIaMitnM+X7SxHL4SUFwYNrnIMetdwsAx9sUhPTAUh2RbblFpImvWRfNKgS3dQ6g68zl1iIZ2Jx414KDesNafyJ666/NZ333M+hdgk6B54S/lHf3nA=;
X-YMail-OSG: dbdsOj4VM1lMLhamE966U914kBFAzyw3xR_rcxV2dbS1NpK i1.4noeQ.rx62wRIN61BCnuGUFLo_Rf.ADJp.bOdeX.xpyY3S9yclHpRg8cJ BlFJ3D7wCrLnigGJoxQ4_qb9R0jgaPGvGEKcMq6HPJygIFQcXxEHNuWYt.yX JCk9dka_ULpwIDxChDgzcBrtyn86AIu6hMl2VskjrPSihCxcVxrBUI51BI8D IcapdBdBxBJGjWeNzB6J862P6neSrYwe59BAizHAK8iXLxwyZxIgaMhVxK79 nrpOiy2oRpeqh0N077MVnJeSh0Qejb_R9kF85ICm9ilyZNY9l0yxk0P_AdlI QR_R8oX647vgx_k9kxpafzE3A7njjF1u1KMykhqPaJRL3MhFbXDysTfhQMlL 9G3g.WeyxBAcDxYJOOckWVBRMwzqbJfNBdqm69qXS56KKbeKAHRAzmrkbQAY CgXBfx0k7CWkbgB9F5hTpN63CJUzPFWXO_vbB4f45mCEPooTwXBSODOuij_A s3Csn0t8cd4X0kshKvLhFsmPG_QMyMVYP
Received: from [150.101.221.237] by web32508.mail.mud.yahoo.com via HTTP; Tue, 30 Oct 2012 13:14:47 PDT
X-Rocket-MIMEInfo: 001.001, SGkgTG9yZW56bywKCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNvbT4KPlRvOiBNYXJrIFNtaXRoIDxtYXJrenp6c21pdGhAeWFob28uY29tLmF1PiAKPkNjOiBGZXJuYW5kbyBHb250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20.OyBWNiBPcHMgPHY2b3BzQGlldGYub3JnPiAKPlNlbnQ6IE1vbmRheSwgMjkgT2N0b2JlciAyMDEyIDU6NTEgUE0KPlN1YmplY3Q6IFJlOiBbdjZvcHNdIG5ldyBkcmFmdDogZHJhZnQtdGF5bG8BMAEBAQE-
X-Mailer: YahooMailWebService/0.8.123.460
References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.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> <CAKD1Yr1xDC7BefRyaHHKfw9THRkyQWwHS5P05_uWTOV539uS2w@mail.gmail.com> <508A876F.6070503@si6networks.com> <1351454911.473 61.YahooMailNeo@web32501.mail.mud.yahoo.com> <CAKD1Yr1CmXV_m4X7Rgdvuj6bXaiaai1rsaosJt5-_m2ChJjgSw@mail.gmail.com>
Message-ID: <1351628087.79801.YahooMailNeo@web32508.mail.mud.yahoo.com>
Date: Tue, 30 Oct 2012 13:14:47 -0700
From: Mark Smith <markzzzsmith@yahoo.com.au>
To: Lorenzo Colitti <lorenzo@google.com>
In-Reply-To: <CAKD1Yr1CmXV_m4X7Rgdvuj6bXaiaai1rsaosJt5-_m2ChJjgSw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Fernando Gont <fgont@si6networks.com>, 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
Reply-To: Mark Smith <markzzzsmith@yahoo.com.au>
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: Tue, 30 Oct 2012 20:14:54 -0000

Hi Lorenzo,


>________________________________
> From: Lorenzo Colitti <lorenzo@google.com>
>To: Mark Smith <markzzzsmith@yahoo.com.au> 
>Cc: Fernando Gont <fgont@si6networks.com>; V6 Ops <v6ops@ietf.org> 
>Sent: Monday, 29 October 2012 5:51 PM
>Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop
> 
>
>On Mon, Oct 29, 2012 at 5:08 AM, Mark Smith <markzzzsmith@yahoo.com.au> wrote:
>
>I don't really disagree with that either, it's more that fragmentation is a current capability of IPv6, so I think the IETF's recommendation should be that it is enabled by default on the Internet. I think that recommendation fits the robustness principle too - "..., be liberal in what you accept from others".
>>
>>If the IETF recommends against forwarding fragments, then I think that creates the obligation to provide advice and methods on what do instead,
>>which might include specifying a standardised UDP fragmentation method, and provide alternative methods for protocols that utilise IP layer
>>fragmentation.
>>
>>Fragments may still be in use, however they may not used much at the
>>
>>application layer. OSPFv2 and OSPFv3 uses them instead of implementing it's own fragmentation mechanism (and that may be across multiple hops in the case of a OSPF virtual link), and they are likely to be commonly used in IPsec and GRE tunnels (PMTUD across the tunnel path and having the tunnel MTU adjusted to it is a more advanced capability).
>
>
>Ok, so how about stating the following, then?
>
>
>1. Fragments are unreliable on the Internet today.

That seems to be what the [blackhole] paper is concluding.

I haven't read the [blackhole] paper, although I've done a few text

searches of it. Thinking about this issue a bit more, I've started to
wonder how this fragmentation filtering is occurring in IPv6. Is it that
packets with the fragmentation extension header as the first extension
header are dropped, and all first extension header types are let through
(meaning a fragmentation extension header would pass as long as it isn't
the first), or is it that only TCP and UDP first extension headers are
let through (and perhaps IPsec ESP) and all others are dropped? My pure
guess would be the latter is more likely, meaning that this also breaks
DCCP and SCTP. I've been hoping that one of the benefits of IPv6 will be
the ability to use more modern transport layer protocols like DCCP and
SCTP without having to encapsulate them inside UDP.


>2. If you're an application developer and your apps need to run on the Internet, then fragments will likely not work in many cases. If you want your application to work in these cases, you should either use application-layer fragmentation, use path MTU discovery, or limit yourself to small packets instead of sending fragments.


ICMP based PMTUD is probably not reliable enough either :-(

>3. If you control the network (e.g., if you're the network operator), and want to use fragments for tunnels or other purposes, go ahead, but note that in other people's networks, they might be filtered.
>

That's ok for e.g. OSPF, however the use case I was thinking of for IPsec was across the Internet. It's about 10 years since I did a lot of work with IPsec tunnels so I'm wondering how they cope with varying MTUs, broken ICMP PMTUD etc. these days. I'm aware that IPsec has become commonly encapsulated inside UDP to avoid NATs, but RFC3948 doesn't seem to cover fragmentation issues below UDP.

>
>Your suggestion of providing a generic UDP segmentation mechanism is a fine idea, and one that we discussed before this draft was written, but our feeling was that such a solution would be impossible to agree on until we have a problem statement. This draft ("FYI: some operators filter fragments. Keep that in mind.") was supposed to be the problem statement.
>
>

Regards,
Mark.