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

[Michael Tuexen <[e-mail]>]

> 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.
>