Random session key + predictable IV I'm using Blowfish in a toy Diffie-Hellman communications scheme. Random session keys are generated for each connection.

In this case I can simply feed a null array to the IV right? The same plaintext would never be encrypted with the same keystream.
If you use CBC mode and your communication protocol looks like SSL, then you may have trouble. In SSL 3.0 and TLS 1.0, the IV for each record is the last block from the previous IV; this implies that an attacker who can both inject some data of his own in the stream, and observe the outcome, may know the IV for the next record and choose his data accordingly. This is the basis for the BEAST attack: that attack context turned out to be realistic when the client is a Web browser.

In all generality, a decent communication protocol should provide both confidentiality and integrity, which means that your data should use a MAC. Combining symmetric encryption and MAC properly is known to be tricky and a good method is to use an encryption mode such as GCM or EAX which does both jobs. A nice point here is that these two modes don't require a random IV, only a non-repeating IV.

This leads to a communication protocol where the initial key exchange (say, your Diffie-Hellman) produces an initial shared secret, which is expanded into two symmetric keys, for the two directions of communications (this "expansion" can be as simple as hashing the initial shared secret with SHA-256, and splitting the 256-bit result into two 128-bit halves). Then both client and server send a sequence of "messages" to each other, using as IV the sequence number of each message (first message from client to server uses as IV the value 1, second message uses the value 2, and so on).



Note that GCM and EAX rely on AES. You can adapt them to any 128-bit block cipher. Usage of block ciphers with 64-bit blocks, like 3DES or Blowfish, is not recommended nowadays, because security of many encryption modes tends to break down when encrypting $2^{n/2}$ blocks with the same key, when blocks have size $n$ bits. For 64-bit blocks, the threshold is around 30 gigabytes, which is not that much.



If your protocol is single-record (after the key exchange, each party sends a single message, which is encrypted in one go, avoiding any BEAST-like issue), then a fixed IV is acceptable, since the key will be used for a single encryption run. However, it would be equally acceptable to derive from the shared DH secret a symmetric key for encryption and the IV; this is what SSL/TLS does (or at least did prior to version TLS-1.1): see the standard, section 6.3.