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

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Tue, 28 July 2020 09:00 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 F26C33A0913 for <tsvwg@ietfa.amsl.com>; Tue, 28 Jul 2020 02:00:13 -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 pAyjTSKRJ91N for <tsvwg@ietfa.amsl.com>; Tue, 28 Jul 2020 02:00:11 -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 0F00E3A048D for <tsvwg@ietf.org>; Tue, 28 Jul 2020 02:00:10 -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 5AA14721BE003; Tue, 28 Jul 2020 11:00:04 +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: <20988_1595916896_5F1FC25F_20988_204_1_787AE7BB302AE849A7480A190F8B933031504776@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Date: Tue, 28 Jul 2020 11:00:01 +0200
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <80BDD5E6-7928-48E0-9B52-2DF626D4E33F@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> <F73A3EF9-09B7-42AC-9D88-2278DB3C672D@lurchi.franken.de> <20988_1595916896_5F1FC25F_20988_204_1_787AE7BB302AE849A7480A190F8B933031504776@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/OWWU4ETdJUdnZvVXy9zfzUnflW4>
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: Tue, 28 Jul 2020 09:00:14 -0000

> On 28. Jul 2020, at 08:14, mohamed.boucadair@orange.com wrote:
> 
> Hi Michael, 
> 
> That's better. 
> 
> I would: s/can not be sent/can not be forwarded.
OK.
> 
> I prefer if the "corresponding" message is called out in the text (that is, "Fragmentation needed and DF set" or PTB).
Text no reads:
<t>When an SCTP packet can not be forwarded by the NAT function due to
MTU issues and the IP header forbids fragmentation, the NAT MUST send back a
"Fragmentation needed and DF set" ICMPv4 or PTB ICMPv6 message to the
internal host.

Pushed as rev-19.

Best regards
Michael
> 
> Thank you.
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]
>> Envoyé : lundi 27 juillet 2020 22:13
>> À : BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com>
>> Cc : tsvwg@ietf.org
>> Objet : Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-16.txt
>> 
>>> 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.
>