On Tue, 9 Aug 2022, Éric Vyncke via Datatracker wrote:
### Section 3 No AH Even if AH is nearly no more used, I wonder whether there is a reason why AH is not supported by this I-D.
Because we dont wants it :) RFC 3948 also only defines ESPinUDP and not AHinUDP.
### Section 3 ``` Although a TCP stream may be able to send very long messages, implementations SHOULD limit message lengths to typical UDP datagram ESP payload lengths. ``` What is the 'typical' length ?
slightly under 1500?
### Section 5.1 `Since UDP is the preferred method of transport for IKE messages,` hem... previous text (and common sense) stated that direct is the preferred method.
Direct is UDP, as UDP is the native IKE transport.
### Section 6.1 what about IP address changes ? ``` Since new TCP connections may use different ports due to NAT mappings or local port allocations changing, the TCP Responder MUST allow packets for existing SAs to be received from new source ports. ``` For some NAT devices (or IPv6 nodes w/o NAT but with temporary addresses), the IP address could also change. This document should describe what to do in this case.
The IP address cannot just change mid-stream for TCP as it can for UDP. It would have to be a new TCP stream and those cases are described in the document.
Please add that the DF bit is obvioulsy only for IPv4 (Hi, Tommy, I had to insert my mandatory IPv6-related comment ;-) )
:) Perhaps we can add a comment about NAT for IPv6 not being implemented in Linux (or did they finally do it? :) Left other items to the actual authors :) Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
