Re: [Int-area] IPv6 fragmentation for IPv4

"Templin, Fred L" <Fred.L.Templin@boeing.com> Tue, 23 May 2017 20:41 UTC

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09FC12EAA4 for <int-area@ietfa.amsl.com>; Tue, 23 May 2017 13:41:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gY-EQ0eS-3l for <int-area@ietfa.amsl.com>; Tue, 23 May 2017 13:41:06 -0700 (PDT)
Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A78D12EA8C for <int-area@ietf.org>; Tue, 23 May 2017 13:41:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v4NKf5mM015882; Tue, 23 May 2017 13:41:05 -0700
Received: from XCH15-06-07.nw.nos.boeing.com (xch15-06-07.nw.nos.boeing.com [137.136.238.213]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v4NKf4i1015867 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 23 May 2017 13:41:04 -0700
Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 23 May 2017 13:41:04 -0700
Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Tue, 23 May 2017 13:41:03 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Joe Touch <touch@isi.edu>, "int-area@ietf.org" <int-area@ietf.org>
Thread-Topic: IPv6 fragmentation for IPv4
Thread-Index: AdLT3WVYMdiisvTeTLyu7THIVnRQuAAS8QEAAA0n34D//7zxgIAAcBUQ
Date: Tue, 23 May 2017 20:41:03 +0000
Message-ID: <bf0753a622094347ad40b7d4a5903005@XCH15-06-08.nw.nos.boeing.com>
References: <da864471c7b648eea3d9d93029209660@XCH15-06-08.nw.nos.boeing.com> <e62dc1c0-c209-f834-c52c-9b8879048d86@isi.edu> <82ea9cb1ddec4c159fd4b4bdea90be41@XCH15-06-08.nw.nos.boeing.com> <fe9deb1d-923b-0ce9-4974-f917501cf566@isi.edu>
In-Reply-To: <fe9deb1d-923b-0ce9-4974-f917501cf566@isi.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [137.136.248.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/v78lQlWhG5hGAa5dy9Otc4YAc3o>
Subject: Re: [Int-area] IPv6 fragmentation for IPv4
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 May 2017 20:41:08 -0000

Hi Joe,

> -----Original Message-----
> From: Joe Touch [mailto:touch@isi.edu]
> Sent: Tuesday, May 23, 2017 1:17 PM
> To: Templin, Fred L <Fred.L.Templin@boeing.com>om>; int-area@ietf.org
> Subject: Re: IPv6 fragmentation for IPv4
> 
> 
> 
> On 5/23/2017 11:49 AM, Templin, Fred L wrote:
> > Hi Joe,
> >
> >> -----Original Message-----
> >> From: Joe Touch [mailto:touch@isi.edu]
> >> Sent: Tuesday, May 23, 2017 11:01 AM
> >> To: Templin, Fred L <Fred.L.Templin@boeing.com>om>; int-area@ietf.org
> >> Subject: Re: IPv6 fragmentation for IPv4
> >>
> >> Hi, Fred (et al.),
> >>
> >> On 5/23/2017 9:17 AM, Templin, Fred L wrote:
> >>> Joe, I wanted to run an idea by you. We all know that IPv4 fragmentation has
> >>> problems because of the 16-bit ID field. So, why not insert an IPv6 Fragment
> >>> Header between the IPv4 header and the upper layer protocol data, then
> >>> use IPv6-style fragmentation instead of IPv4 fragmentation?
> >> IPv4 fragmentation has several impediments:
> >>     - small ID field
> >>     - lack of a reassembly checksum
> >>     - lack of a fixed-location flow ID
> >>
> >> Using IPv6-Frag as the next header solves only the first of these. The
> >> last is significant - putting a new header would defeat IPv4 flow ECMP
> >> even for the first fragment.
> > ECMP gateways could be updated to look at the ULP headers
> > following the IPv6 Frag header in the first fragment.
> They could, but...
> 
> >> IPv6 includes a flow field that serves this
> >> purpose.
> > How does it work for plain-old IPv4 fragmentation?
> It doesn't. That's part of the problem.
> 
> > I would think
> > that ECMP gateways would look at the IP ID and try to associate
> > the fragments so they all get equal ECMP treatment, i.e., the
> > same as for vanilla IPv4.
> AFAICT, they largely either drop fragments or send them based on the
> base IPv4 header.

I think then it would be the same for both vanilla IPv4 fragmentation
and this hybrid IPv4/6 fragmentation.

> I wonder whether NATs deal with this issue correctly. I doubt either one
> keeps per-ID state.

I heard once long ago about Virtual Fragment Reassembly where the
middlebox collects up fragments until it has all of them, but then
instead of actually reassembling it releases the fragments so that
the final destination has to reassemble. I think it is a cisco thing.
Does anyone know if it is widely deployed?

> (FWIW, IMO, anything that needs to look past the IP header really ought
> to reassemble - if you think that's not something an IP router should
> do, neither do I - but then I don't think routers should be looking past
> the IP header either).

Indeed. 

Thanks - Fred

> Joe
> 
>