Re: [tcpm] 793bis: IP ID

Fernando Gont <fgont@si6networks.com> Fri, 24 January 2020 11:55 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3EAD120044 for <tcpm@ietfa.amsl.com>; Fri, 24 Jan 2020 03:55:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.308
X-Spam-Level:
X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 DXS0xIIoQVxH for <tcpm@ietfa.amsl.com>; Fri, 24 Jan 2020 03:55:51 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1DCE120024 for <tcpm@ietf.org>; Fri, 24 Jan 2020 03:55:50 -0800 (PST)
Received: from [192.168.100.103] (unknown [186.183.3.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id AC99886107; Fri, 24 Jan 2020 12:55:01 +0100 (CET)
To: Joe Touch <touch@strayalpha.com>
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, tcpm@ietf.org
References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk> <f4d75224-d7d0-002b-2bca-f93505d6c9d3@mti-systems.com> <4D99C7DD-F57E-4708-8F02-824EB4BF8E24@weston.borman.com> <333A2AF9-7DDD-4FAA-B0BD-E6871564850F@strayalpha.com> <F9E41A50-83FA-477C-8E19-5CE6A58931D3@weston.borman.com> <a7080caa-18ce-94ec-3bbf-ae5c8d1bc17c@si6networks.com> <495c6e94-d5a4-effe-3c4d-d5275deb8cc8@erg.abdn.ac.uk> <F0125DC6-540B-4807-BA46-3D39226FB02B@strayalpha.com> <fe017958-221b-1ae2-7079-1fd0e6ef6d19@si6networks.com> <5C1F0A09-F6B8-4EDB-BB9D-431DD6C04D06@strayalpha.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <58445bde-d5a1-d853-cb50-80d1ab1fc8e6@si6networks.com>
Date: Fri, 24 Jan 2020 03:08:36 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <5C1F0A09-F6B8-4EDB-BB9D-431DD6C04D06@strayalpha.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/1WUFtJiYRbpa2z9PqN7znyFaPaY>
Subject: Re: [tcpm] 793bis: IP ID
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jan 2020 11:55:53 -0000

On 24/1/20 02:48, Joe Touch wrote:
> 
> 
>> On Jan 23, 2020, at 8:58 PM, Fernando Gont <fgont@si6networks.com 
>> <mailto:fgont@si6networks.com>> wrote:
>>
>> On 23/1/20 11:54, Joe Touch wrote:
>>>> On Jan 23, 2020, at 5:24 AM, Gorry Fairhurst <gorry@erg.abdn.ac.uk 
>>>> <mailto:gorry@erg.abdn.ac.uk>> wrote:
>>>>
>>>> I think this is the wrong ID to discuss anything related to IPv4 ID.
>>> I disagree.
>>> It’s important to support the *requirement* in 6864 by explicitly 
>>> indicating that the ID *MUST NOT* be used for duplicate segment 
>>> detection in TCP.
>>
>> With layering in mind, why would one want to do that?
> 
> Because the information in RFC1122 in section 4.2.2.15 needs to be 
> integrated

Does it? It would seem to me that these IP ID tricks are an 
implementation-specific trick that would never be implemented in 
general-purpose implementations.

Even more, it would make even less sense in the light of the Internet 
moving towards IPv6 (albeit at a horrible pace), wheere the "IP ID" is 
not available in all packets.


> and corrected to bring it up to date with RFC6864, even if in 
> the negative.
> 
> I.e., this doc should be very clear on two points:
> 
> - TCP MUST NOT attempt to control the IP ID to try to indicate duplicate 
> sent segments
> - TCP MUST NOT use the IP ID in trying to identify duplicate received 
> segments
> 
> I.e., in summary, exactly to encode that layering.


My question here is whether we want to drag such (mostly obsolete) 
details into this more modern spec, or not.

It would seem yo me that a fresh reader of *this* 793bis would probably 
be quite puzzled when reading this sort of requirement that mostly have 
to do with what some implementations did ages ago...


-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492