Safe way to derive IV from the DH shared keys for AES-GCM? I am preparing to use AES-GCM to make a secure communication program. 
Here is the procedure


DH key exchange to get shared keys
SHA256(shared keys)
Use AES-GCM to encrypt a message while the key only used once.


However, I was confused about the way to get IV in step3. I know IV/nonuse must be unique. The size of the IV should be 96 bits. I know we can use the timestamp to generate iv. However, I need to generate the IV from the shared key. Is there any method to do it safely?
If there is no regulatory requirement, for AES-128, a good option would be splitting the SHA-256 hash into a key (128-bit), IV (96-bit), and any unused portion. That allows us to make the IV implicit (and secret, which is unnecessary, but does not harm) thus saves even so little bandwidth. For AES-192 or AES-256,  we can do this with SHA-512 instead of using SHA-256.

On a related note, make sure that the same derived key is never used by a given party both to encrypt and decrypt/authenticate because that opens to mirror attacks. If the communication is bidirectional, derivation could use 
$$\operatorname{HMAC-SHA-xyz}(\mathsf{key}=\text{DH-shared-secret}, \mathsf{message}=\text{sender-ID})$$
as the origin of the session key and IV used by the sender to prepare its message. HMAC internally hashes the shared secret if it more than a certain size (64 bytes for SHA-256), that's fine.

For even stronger assurance:
$$\begin{align}
\text{Key}&amp;=\operatorname{HMAC-SHA-xyz}(\mathsf{key}=\text{DH-shared-secret}, \mathsf{message}=\text{'K'}\mathbin\|\text{sender-ID})\\
\text{IV}&amp;=\operatorname{HMAC-SHA-xyz}(\mathsf{key}=\text{DH-shared-secret}, \mathsf{message}=\text{'I'}\mathbin\|\text{sender-ID})
\end{align}$$

which gives an argument that the leak of IV (which should be assumed even if the IV is not sent in clear) can't harm the secrecy of Key even if the hash has some level of defect. Also, HMAC has a parameter (now shown) to specify the output size, making the definition cleaner.