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

mohamed.boucadair@orange.com Tue, 28 July 2020 06:15 UTC

Return-Path: <mohamed.boucadair@orange.com>
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 2B62A3A0CCD for <tsvwg@ietfa.amsl.com>; Mon, 27 Jul 2020 23:15:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.118
X-Spam-Level:
X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
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 onNBHDz64uhg for <tsvwg@ietfa.amsl.com>; Mon, 27 Jul 2020 23:14:58 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AE283A0CC9 for <tsvwg@ietf.org>; Mon, 27 Jul 2020 23:14:57 -0700 (PDT)
Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 4BG5xX0VJbz11dM; Tue, 28 Jul 2020 08:14:56 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1595916896; bh=okd7XXUDf9CdVcQnNW7dNkPV3uB/SzG7B0VvxaESbHE=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=KLUy53TLnHCZlcFUBMqPLdE7mqH8CROO894vSYJ5iIJn9iTa75h/KFuDmhmxbBYcb 9ZKBoRZbSxTiNekNVM9uWU44u9x+hJdnjgsYoVWv4/9MF0VuxWW/wHXUtdE9tGchXx qF4CaRbj9zXNUZyUpWMBT2/ApFXMbz4Z7J+z6QCrTkA3fKEEkM/BJ/t+3vUCATAdmg A34LUGXnqyONAEwIrxiXJNRQPLX00arha8/IxyoVe2ktXQp/mSBO0qJzrmfsHxMfri y3sbsCeNUceb27T4JhWzaiwMuzdEZfWS7G0i1ryheeALBSXCDla7dkgX/0KCqBTnMR pc3vwiynegAcQ==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.35]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 4BG5xW6xT2zDq7W; Tue, 28 Jul 2020 08:14:55 +0200 (CEST)
From: mohamed.boucadair@orange.com
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
CC: "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-16.txt
Thread-Index: AQHWZFJODT6fHOnDck+BWnLx1FXYCakcfivA
Date: Tue, 28 Jul 2020 06:14:54 +0000
Message-ID: <20988_1595916896_5F1FC25F_20988_204_1_787AE7BB302AE849A7480A190F8B933031504776@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
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>
In-Reply-To: <F73A3EF9-09B7-42AC-9D88-2278DB3C672D@lurchi.franken.de>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/PTxtfY23g7l11k7wqjEKGNixoQ4>
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 06:15:00 -0000

Hi Michael, 

That's better. 

I would: s/can not be sent/can not be forwarded.

I prefer if the "corresponding" message is called out in the text (that is, "Fragmentation needed and DF set" or PTB).

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.