I have a question:
What is the relation between send-initial-contact and passive parameters found in peer configuration under ipsec?

What does it mean for mikrotik (how it affects behavior) if a mikrotik router is working as ipsec initiator if it has:
a) send-initial-contact=no passive=no
b) send-initial-contact=no passive=yes
c) send-initial-contact=yes passive=no
d) send-initial-contact=yes passive=yes

What does it mean for mikrotik working as ipsec responder if it has:
a) send-initial-contact=no passive=no
b) send-initial-contact=no passive=yes
c) send-initial-contact=yes passive=no
d) send-initial-contact=yes passive=yes

The documentation is very bad on this, there is no real explaination on what each parameter REALLY means, when and how it is used by router and for what purpose, both look like doing quite the same? They are both part of peer definition so both of them should be used during IKE phase of ipsec connection. Am I rhight?

The Mikrotik documentation often assumes the reader is familiar with the standards regarding the protocol and only explains the particular ways how that protocol is implemented on Mikrotik. Plus, like other vendors, Mikrotik sometimes uses shorter keywords to express the behavior.

So passive should actually read responder-only as it tells the peer not to attempt to initiate Phase 1 (the "control" connection, IKE/IKEv2, for those not familiar with the IPsec vernacular), whereas send-initial-contact literally means "send the INITIAL_CONTACT IKE notification", which suggests the recipient to drop any already existing connections authenticated using the same set of credentials that are used for the IKE session within which this notification has arrived. In another words, it has no effect on the initiator/responder role. And yes, it took me months to find that out.

The Mikrotik documentation often assumes the reader is familiar with the standards regarding the protocol (...)
send-initial-contact literally means "send the INITIAL_CONTACT IKE notification", which suggests the recipient to drop any already existing connections authenticated using the same set of credentials that are used for the IKE session within which this notification has arrived. In another words, it has no effect on the initiator/responder role. And yes, it took me months to find that out.

I think I am actually familiar with IPSEC, but what is actually missing for me is exactly how that protocol is implemented on Mikrotik. I am really struggling to understand:
Can you be more clear?

...which suggests the recipient to drop any already existing connections...

How this parameter works if it is used by initiator? and how does it work if used by responder?

Do I understand correctly, that:
- if Mikrotik is used as a responder than send-initial-contact is simply ignored, and will not be used (meaning that Mikrotik always drops existing SAs for a new IKE from the same peer). So There is no parameter informing Mikrotik to allow multiple connections from the same identity?
- if Mikrotik is used as an initiator than it will include INITIAL_CONTACT notify payload in the first IKE_AUTH request?

I found this in Huawei documentation:

The INITIAL_CONTACT notify payload asserts that an IKE SA (that is currently negotiated 'control' connection) is the only active IKE SA between a pair of IKE peers. By default, the device will delete the old IKE SA without the INITIAL_CONTACT notify payload after the new IKE SA is created. When the remote end requires the INITIAL_CONTACT notify payload to delete the old IKE SA, configure this parameter.

When the local device restarts or expects to use the current IKE SA for establishing an IPSec tunnel only, run this command to enable the device to send the INITIAL_CONTACT notify payload in the first IKE_AUTH request so that the remote device deletes the old IKE SA.

Does this work the same for Mikrotik?

Btw it would be enough to include just the sentence "nclude INITIAL_CONTACT notify payload in the first IKE_AUTH request" in wiki for this to be precise and clear.

Can you be more clear? ... How this parameter works if it is used by initiator? and how does it work if used by responder?
...
Do I understand correctly, that:

• if Mikrotik is used as a responder than send-initial-contact is simply ignored, and will not be used (meaning that Mikrotik always drops existing SAs for a new IKE from the same peer). So There is no parameter informing Mikrotik to allow multiple connections from the same identity?
• if Mikrotik is used as an initiator than it will include INITIAL_CONTACT notify payload in the first IKE_AUTH request?

I was as clear as my knowledge allowed

I never dove deep enough to analyze whether there is a way to instruct the responder to ignore INITIAL_CONTACT because it was always (as in "in about five cases in total") easier for me to set send-initial-contact to no on the initiators. On the initiator side, I assume it just controls whether that notification will be added to the message or not. On the responder side, I figure an instruction to eventually ignore a received INITIAL_CONTACT would have to be part of the identity parameters to be useful, and there is nothing like that. If you want to learn more, file a support ticket.

Btw it would be enough to include just the sentence "nclude INITIAL_CONTACT notify payload in the first IKE_AUTH request" in wiki for this to be precise and clear.

It's not Wiki any more, it's Confluence now, but that did not make the explanation of send-initial-contact on https://help.mikrotik.com/docs/display/ROS/IPsec any clearer.