When a DVIPA is moved during a DVIPA takeover (planned or unplanned), new Sysplex-Wide Security Associations (SWSAs) are automatically reestablished with the same security service characteristics as the Security Associations (SAs) that existed on the host that previously owned the DVIPA. When you are using IKEv1 and the SA is reestablished, the process is transparent to the client that owns the other end of the SA. The process appears to be a normal SA refresh when IKEv1 is used to negotiate the SA. When IKEv2 is used, the SA reestablishment appears as a new SA. Figure 1 shows DVIPA 192.168.253.4 being taken over by the backup host; SAs are transparently reestablished between the client and the backup host.
The IKE running on behalf of the TCP stack of the DVIPA owner is responsible for all IKE SA negotiations. The TCP stack owning the DVIPA is responsible for keeping the coupling facility updated with information needed to reestablish the SAs in the event of a DVIPA takeover. When a takeover occurs, the IKE on the backup host assumes responsibility for renegotiating new SAs based on information read from the coupling facility by the TCP stack of the new DVIPA owner.
When the SA is reestablished using the IKEv2 protocol, it appears as a new SA. The old SA on the client system might not be deleted immediately. This typically happens when a phase 1 SA exists on the backup system that has the same local and remote identities as the phase 1 SA protecting the SA that is being reestablished. When this scenario occurs, the old SA on the client remains active until it is deleted by liveness checking, which is described in RFC 5996. For more information about liveness checking as implemented on the z/OS® platform, see the LivenessInterval parameter on the KeyExchangePolicy statement in z/OS Communications Server: IP Configuration Reference. For more information about the IKEv1 and IKEv2 protocols, see the IKE protocol details appendix in z/OS Communications Server: IP Diagnosis Guide.