"Introduction IKEv2@ as described in [RFC5996] and its predecessor RFC 4306@ has a method for recovering from a reboot of one peer. As long as traffic flows in both directions@ the rebooted peer should re-establish the tunnels immediately. However@ in many cases@ the rebooted peer is a VPN gateway that protects only servers@ so all traffic is inbound. In other cases@ the non-rebooted peer has a dynamic IP address@ so the rebooted peer cannot initiate IKE because its current IP address is unknown. In such cases@ the rebooted peer will not be able to re-establish the tunnels. Section 2 describes how recovery works under RFC 5996@ and explains why it may take several minutes. The method proposed here is to send an octet string@ called a ""QCD token""@ in the IKE_AUTH exchange that establishes the tunnel. That token can be stored on the peer as part of the IKE SA. After a reboot@ the rebooted implementation can re-generate the token and send it to the peer@ so as to delete the IKE SA. Deleting the IKE SA results in a quick establishment of new IPsec tunnels. This is described in Section 3. Conventions Used in This Document The key words ""MUST""@ ""MUST NOT""@ ""REQUIRED""@ ""SHALL""@ ""SHALL NOT""@ ""SHOULD""@ ""SHOULD NOT""@ ""RECOMMENDED""@ ""MAY""@ and ""OPTIONAL"" in this document are to be interpreted as described in [RFC2119]. The term ""token"" refers to an octet string that an implementation can generate using only the properties of a protected IKE message (such as IKE Security Parameter Indexes (SPIs)) as input. A conforming implementation MUST be able to generate the same token from the same input even after rebooting. The term ""token maker"" refers to an implementation that generates a token and sends it to the peer as specified in this document. The term ""token taker"" refers to an implementation that stores such a token or a digest thereof@ in order to verify that a new token it receives is identical to the old token it has stored. The term ""non-volatile storage"" in this document refers to a data storage module that persists across restarts of the token maker. Examples of such a storage module include an internal disk@ an internal flash memory module@ an external disk@ and an external database. A small non-volatile storage module is required for a token maker@ but a larger one can be used to enhance performance@ as described in Section 8.2."