  <varlistentry>
  <term><emphasis remap='B'>ikev2</emphasis></term>
  <listitem>
<para>IKEv2 (RFC4309) settings to be used. Currently the accepted values
are
<emphasis remap='B'>permit</emphasis>,
(the default)
signifying no IKEv2 should be transmitted, but will be accepted if the other
ends initiates to us with IKEv2;
<emphasis remap='B'>never</emphasis> or <emphasis remap='B'>no</emphasis>
signifying no IKEv2 negotiation should be transmitted or accepted;
<emphasis remap='B'>propose</emphasis> or <emphasis remap='B'>yes</emphasis>
signifying that we permit IKEv2, and also use it as the default to initiate;
<emphasis remap='B'>insist</emphasis>,
signifying we only accept and receive IKEv2 - IKEv1 negotiations will be
rejected.
</para><para>
If the ikev2= setting is set to <emphasis remap='B'>permit</emphasis>
or <emphasis remap='B'>propose</emphasis>, Libreswan will try and detect a
"bid down" attack from IKEv2 to IKEv1.  Since there is no standard for
transmitting the IKEv2 capability with IKEv1, Libreswan uses a special
Vendor ID "CAN-IKEv2". If a fall back from IKEv2 to IKEv1 was detected,
and the IKEv1 negotiation contains Vendor ID "CAN-IKEv2", Libreswan will
immediately attempt and IKEv2 rekey and refuse to use the IKEv1 connection.
With an ikev2= setting of <emphasis remap='B'>insist</emphasis>, no IKEv1
negotiation is allowed, and no bid down attack is possible.</para>
  </listitem>
  </varlistentry>

