Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-16.txt

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Mon, 27 July 2020 20:13 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A66A3A0BF0 for <tsvwg@ietfa.amsl.com>; Mon, 27 Jul 2020 13:13:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.631
X-Spam-Level:
X-Spam-Status: No, score=-1.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.267, SPF_NONE=0.001, URIBL_BLOCKED=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 Xx2NzdMx4Uaz for <tsvwg@ietfa.amsl.com>; Mon, 27 Jul 2020 13:13:01 -0700 (PDT)
Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A6713A0BE9 for <tsvwg@ietf.org>; Mon, 27 Jul 2020 13:12:59 -0700 (PDT)
Received: from mb.fritz.box (ip4d15f5fc.dynamic.kabel-deutschland.de [77.21.245.252]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id 0E5907220B806; Mon, 27 Jul 2020 22:12:54 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <31246_1595851462_5F1EC2C6_31246_20_1_787AE7BB302AE849A7480A190F8B93303150315C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Date: Mon, 27 Jul 2020 22:12:52 +0200
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F73A3EF9-09B7-42AC-9D88-2278DB3C672D@lurchi.franken.de>
References: <158377886936.5575.9623052267692928298@ietfa.amsl.com> <4C917C1B-74C0-4E5E-B26C-3CD6A0B2544C@lurchi.franken.de> <787AE7BB302AE849A7480A190F8B93303148DE10@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <F3B1520B-593F-426A-8AC4-9B2371A82B37@lurchi.franken.de> <787AE7BB302AE849A7480A190F8B9330314902D1@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <FC1544B5-87B1-4A46-BEA7-00541206883A@lurchi.franken.de> <9842_1594818722_5F0F00A2_9842_128_4_787AE7BB302AE849A7480A190F8B9330314F980A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <F03E124F-E4DB-4D68-96F5-3EDB48C31883@lurchi.franken.de> <31246_1595851462_5F1EC2C6_31246_20_1_787AE7BB302AE849A7480A190F8B93303150315C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
To: mohamed.boucadair@orange.com
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/HZakq69zv9W-aeBGnGZw6pZwnu4>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-16.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jul 2020 20:13:10 -0000

> On 27. Jul 2020, at 14:04, mohamed.boucadair@orange.com wrote:
> 
> Hi Michael, 
> 
> Please see inline. 
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]
>> Envoyé : dimanche 26 juillet 2020 12:03
>> À : BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com>
>> Cc : tsvwg@ietf.org
>> Objet : Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-16.txt
>> 
>>> In any case, I'm afraid you will need to add details such as: amount
>> of time/resources a NAT can wait for out of order fragments. You may
>> reuse some of the text from RFC 6146, including the default frag
>> timeout.
>>> 
>>> * Consider this change to align with REQ-13 of RFC4787:
>>> 
>>> OLD:
>>>  When an SCTP packet has to be fragmented by the NAT function and
>> the
>>>  IP header forbids fragmentation a corresponding ICMP packet SHOULD
>> be
>>>  sent.
>>> 
>>> NEW:
>>>  When an SCTP packet has to be fragmented by the NAT function and
>> the
>>>  IP header forbids fragmentation, the NAT MUST send back an ICMP
>> message
>>>  "Fragmentation needed and DF set" to the internal host.
>> Changed to
>> <t>When an SCTP packet has to be fragmented by the NAT function and
>> the IP header forbids fragmentation, the NAT MUST send back a
>> corresponding ICMP message to the internal host.
>> 
>> since it covers IPv4 and IPv6.
> 
> [Med] The wording is IPv4-specifc: "When an SCTP packet ** has to be fragmented **".
Hmm. My view is that an IPv6 header always forbids fragmentation... So maybe
a bette workding helps:

<t>When an SCTP packet can not be sent by the NAT function due to MTU issues and
the IP header forbids fragmentation, the NAT MUST send back a
corresponding ICMP message to the internal host.

Is that acceptable?

Best regards
Michael
> 
> You may consider my initial wording for IPv4 + add a new sentence to cover the IPv6 case.
>  
> 
> 
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>