IKE is used in the IPSec process to setup a secure means of communication between the two IPSec peers to then start building the IPSec Tunnels, also authenticates the peers. IKE will use Diffie-Hellman as a way of deriving a shared secret key that can be used to secure the communication process for setting up things like an IKE Security Association and the 2 IPSec Security Associations (i am pretty sure there is 2, one for each way).
Security Associations are generated to govern the settings that are agreed to secure the communications (for example, Hashing, Encryption, Lifetimes, etc...)
So to re-cap
IKE - Used to authenticate and protect the identity of the peers, setup a secure channel to then start negotiating the IPSec (or IKE Phase 2) parameters.
Diffie-Hellman - This is the mathematical process of taking a shared, unsecured path and negotiating a shared secret key (dynamically) so both ends can start to secure communications
Diffie-Hellman was one of the first algorithms used for encryption using public keys. SSL comunications over the internet incorporates a Diffie-Hellman exchange at some point. The famous RSA algorithm follows the same method. Here is an extract from the RFC2246:
RFC 2246 The TLS Protocol Version 1.0 January 1999
F.1.1.3. Diffie-Hellman key exchange with authentication
When Diffie-Hellman key exchange is used, the server can either
supply a certificate containing fixed Diffie-Hellman parameters or
can use the server key exchange message to send a set of temporary
Diffie-Hellman parameters signed with a DSS or RSA certificate.
Temporary parameters are hashed with the hello.random values before
signing to ensure that attackers do not replay old parameters. In
either case, the client can verify the certificate or signature to
ensure that the parameters belong to the server.
If the client has a certificate containing fixed Diffie-Hellman
parameters, its certificate contains the information required to
complete the key exchange. Note that in this case the client and
server will generate the same Diffie-Hellman result (i.e.,
pre_master_secret) every time they communicate. To prevent the
pre_master_secret from staying in memory any longer than necessary,
it should be converted into the master_secret as soon as possible.
Client Diffie-Hellman parameters must be compatible with those
supplied by the server for the key exchange to work.
If the client has a standard DSS or RSA certificate or is
unauthenticated, it sends a set of temporary parameters to the server
in the client key exchange message, then optionally uses a
certificate verify message to authenticate itself.
"Appear weak when you are strong and strong when you are weak"