Re: [Int-area] IPv6 fragmentation for IPv4

Joe Touch <touch@isi.edu> Tue, 23 May 2017 20:23 UTC

Return-Path: <touch@isi.edu>
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 AD3B112EB02 for <int-area@ietfa.amsl.com>; Tue, 23 May 2017 13:23:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 v-O2zTm9o_as for <int-area@ietfa.amsl.com>; Tue, 23 May 2017 13:23:16 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD95C1287A7 for <int-area@ietf.org>; Tue, 23 May 2017 13:23:16 -0700 (PDT)
Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v4NKLhaI007933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 23 May 2017 13:21:58 -0700 (PDT)
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>, "int-area@ietf.org" <int-area@ietf.org>
References: <da864471c7b648eea3d9d93029209660@XCH15-06-08.nw.nos.boeing.com> <e62dc1c0-c209-f834-c52c-9b8879048d86@isi.edu> <82ea9cb1ddec4c159fd4b4bdea90be41@XCH15-06-08.nw.nos.boeing.com> <1e04c4fdef5249ec816638aaf0584422@XCH15-06-08.nw.nos.boeing.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <7b58e6e2-8f58-0f80-494c-11053257759c@isi.edu>
Date: Tue, 23 May 2017 13:21:43 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <1e04c4fdef5249ec816638aaf0584422@XCH15-06-08.nw.nos.boeing.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/RR7RnKoUVOU99dfRxvoq7Fp-xAg>
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:23:18 -0000


On 5/23/2017 1:13 PM, Templin, Fred L wrote:
> Here's another think - since the IPv6 Frag Header already has a
> 32-bit IP ID that we are using for fragmentation, and since we
> are asking the IPv4 header to set DF=1, the 16-bit IP ID field in
> the IPv4 header is available for use as a flow field - right?
Except for all those devices that look only at the IPv4 header. In that
case, redefining the IPv4 header this way could interfere with
mechanisms to manage NAT traversal based based on ID context.

Finally, how do you know when you can even use this? Legacy devices
could choke on such packets - whether routers or endpoints.

Joe