Add an option to announce support for IKE fragmentation but not sending fragments

2017-05-23 16:41:57 +02:00
parent cbbd34f507
commit 46a3f92a76
6 changed files with 34 additions and 16 deletions
@@ -445,22 +445,31 @@ force UDP encapsulation for ESP packets even if no NAT situation is detected.
 This may help to surmount restrictive firewalls. In order to force the peer to
 encapsulate packets, NAT detection payloads are faked.
 .TP
-.BR fragmentation " = " yes "  | force | no"
+.BR fragmentation " = " yes "  | accept | force | no"
 whether to use IKE fragmentation (proprietary IKEv1 extension or IKEv2
 fragmentation as per RFC 7383).  Acceptable values are
 .B yes
 (the default),
+.BR accept ,
 .B force
 and
 .BR no .
-Fragmented IKE messages sent by a peer are always accepted
-irrespective of the value of this option. If set to
-.BR yes ,
-and the peer supports it, larger IKE messages will be sent in fragments.
 If set to
+.BR yes ,
+and the peer supports it, oversized IKE messages will be sent in fragments. If
+set to
+.BR accept ,
+support for fragmentation is announced to the peer but the daemon does not send
+its own messages in fragments. If set to
 .B force
 (only supported for IKEv1) the initial IKE message will already be fragmented
-if required.
+if required. Finally, setting the option to
+.B no
+will disable announcing support for this feature.
+
+Note that fragmented IKE messages sent by a peer are always accepted
+irrespective of the value of this option (even when set to
+.BR no ).
 .TP
 .BR ike " = <cipher suites>"
 comma-separated list of IKE/ISAKMP SA encryption/authentication algorithms