It must be sent with the message in order to be decipherable to the legitimate decipherer.
The message sent has the IV as the first part. The shared key $K$ is known, so the "packet key" $K'$ is $\textrm{IV} || K$ and this is used to encrypt the data + CRC. The recipient can only decrypt using RC4 if he knows $K'$ too, so he must know the IV as well. After decryption the CRC can be checked. Moreover, in network traffic there often is a counter or per packet identifier that is sent with the data anyway, so using (part of) that data as IV is "free".
An alternative would be to encrypt the IV (3 bytes) with key $K$ and send that. But that's bad for several reasons: we need an extra key setup (relatively expensive in RC4) just for 3 bytes of IV decryption. It also gives an extra attack option for sniffers: one coild build tables for keys and their associated encrypted IV's and if IV's were in any way predictable (often counters, so yes) we'd have an extra off-line attack option. If you don't send the IV at all, a recipient would have to do a $24$ bit brute force over all IV's and possible $K'$'s to detect a packet with the right CRC after decryption but then a packet with an invalid CRC wouldn't ever be deciphered. And it's very slow as well.... Not an option, really.
The problem is not plain IV's but too short IV's and bad "mixing" of IV and $K$. The short IV's give too many collisions, and then regardless of mixing we get packets that are in depth. But the bad mixing (in combination wtih the key schedule of RC4) gave a lot of statistical options to attack.