An implementation should generate the IV from any cryptographically secure PRNG. TLS 1.1 further details the possible ways to do that:
- The IV can be obtained from a PRNG.
- A random string $r$ can be generated from a PRNG, and added to the plaintext to encrypt where the IV should go; then the whole lot is encrypted with either a fixed IV, or even the last block of the previous record as IV. This method is easier to map on existing implementations of CBC encryption, because the IV is treated like plaintext. It is safe because $E(r \oplus iv)$, for a given $iv$ (e.g. the last block from the previous record) and encryption function $E$, is as uniformly random as $r$ itself.
- The same method, but with $r$ being a fixed string.
It is unclear whether the third method is safe or not. It relies on the encryption $E$ to "act as a PRNG". The TLS 1.1 specification includes this:
The following alternative procedure MAY be used; however, it has
not been demonstrated to be as cryptographically strong as the
above procedures. The sender prepends a fixed block F to the
plaintext (or, alternatively, a block generated with a weak PRNG).
He then encrypts as in (2), above, using the CBC residue from the
previous block as the mask for the prepended block. Note that in
this case the mask for the first record transmitted by the
application (the Finished) MUST be generated using a
cryptographically strong PRNG.
Since the specification gives it as a "MAY", one must assume that some implementers may have used this third method. Its advantage is that it does not require a PRNG invocation for every record, only for the first record, so a relatively slow PRNG can be tolerated.
Interestingly, all these detailed paragraphs have been removed from TLS 1.2, which merely states the generic "The Initialization Vector (IV) SHOULD be chosen at random, and MUST be unpredictable".