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

[Michael Tuexen <[e-mail]>]

> On 28. Jul 2020, at 08:14, [e-mail] 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:[e-mail]]
>> Envoyé : lundi 27 juillet 2020 22:13
>> À : BOUCADAIR Mohamed TGI/OLN <[e-mail]>
>> Cc : [e-mail]
>> Objet : Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-16.txt
>> 
>>> On 27. Jul 2020, at 14:04, [e-mail] wrote:
>>> 
>>> Hi Michael,
>>> 
>>> Please see inline.
>>> 
>>> Cheers,
>>> Med
>>> 
>>>> -----Message d'origine-----
>>>> De : Michael Tuexen [mailto:[e-mail]]
>>>> Envoyé : dimanche 26 juillet 2020 12:03 À : BOUCADAIR Mohamed
>> TGI/OLN
>>>> <[e-mail]> Cc : [e-mail] 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.
>