Re: [Int-area] IPv6 fragmentation for IPv4

Joe Touch <> Tue, 23 May 2017 21:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 209DE12EB32 for <>; Tue, 23 May 2017 14:20:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xJ3IhHYfbJCF for <>; Tue, 23 May 2017 14:20:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C80BD1287A7 for <>; Tue, 23 May 2017 14:20:00 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id v4NLJBf9014405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 23 May 2017 14:19:26 -0700 (PDT)
To: "Templin, Fred L" <>, "" <>
References: <> <> <> <> <> <>
From: Joe Touch <>
Message-ID: <>
Date: Tue, 23 May 2017 14:19:11 -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: <>
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
Archived-At: <>
Subject: Re: [Int-area] IPv6 fragmentation for IPv4
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 May 2017 21:20:03 -0000

On 5/23/2017 1:45 PM, Templin, Fred L wrote:
> Hi Joe,
>> -----Original Message-----
>> From: Joe Touch []
>> Sent: Tuesday, May 23, 2017 1:22 PM
>> To: Templin, Fred L <>om>;
>> Subject: Re: IPv6 fragmentation for IPv4
>> 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.
> What was it that your document said about the setting of IP ID when
> DF=1? Shouldn't it be OK to set the ID to some value of our own
> choosing, e.g., a hash of the 5-tuple of the original packet?
If DF=1, then the ID should be ignored everywhere.

That's also consistent with the uses that were reported about some
systems just setting DF=1 and using a single ID.

It can't indicate a flow unless you know the next proto=44. But then why
not make next proto=(new number) and just put a proper flow ID (and
reassembly) there?
>> Finally, how do you know when you can even use this? Legacy devices
>> could choke on such packets - whether routers or endpoints.
> That is a real concern, yes. For the same reason that new transports
> like SCTP and DCCP have been proven difficult to deploy. With this
> proposal, ip-proto-44 would be just another protocol that middleboxes
> block. But, maybe it would work in private internetworks such as
> an enterprise network.
IMO, if you've gotten to the point of upgrading a system to speak a new
variant of IPv4, it ought to be IPv6.