In a sense, there is no real defense against spoofing; there is only the ability to take precautions against being taken in by the spoofed information. If someone is spoofing IP addresses in her TCP/IP packets, unless she's on your local network, there's little you can do to prevent her from doing so. What you can do (possibly) is prevent your machines from accepting or believing the falsified information.
To perform such prevention, you need to be able to detect that information is being falsified. Software such as arpwatch and tcpdump can provide you with useful logs from which you might detect spoofing incidents. Although they usually can't tell you what of the data is actually false, they often can provide useful hints. Realize that what such software is doing is examining auxiliary data that is correlated to the information in question, and providing you with a warning that something unexpected has been seen.
Arpwatch can't tell you which host that's claiming an IP is actually lying; all it can tell you is that it appears that two hosts are competing for the same address. If you've kept a table of IPs that you've assigned, and the MAC addresses that go with them, you might be able to determine who's the IP address thief . On the other hand, it's possible that both conflicting addresses are being spoofed, in which case arpwatch can tell you that something's up, but you'll lack all ability to determine what information to believe.
Another tool you might use to monitor this spoofery and track it to its source would be a good switched network with usefully manageable switches. (Those frequently billed as "layer 3 switches," though they technically provide all the functions of an internetwork router for every connection, are the ones to look for. 3Com has a nice white paper on the subject at http://www.3com.com/corpinfo/en_US/technology/tech_paper.jsp?DOC_ID=5298.) Such an environment can provide you with a hardware-level view of where the conflicting information is coming from, and let you quickly track it to specific machines on specific wires.
Similarly, employing a firewall might be of some utility in gathering and using auxiliary information. If a packet shows up at your firewall that says that it's from an IP address on your internal network, the firewall can employ information entirely outside the packet to determine whether to believe it ”namely, on which wire did the packet appear? The one for the internal network, or the one from the external network? Employing such technology enables your internal machines to more seriously consider the idea of using a packet's supplied source IP as an identifying credential because it can preclude anyone from outside the local network from injecting traffic with local IPs. Of course, it does nothing to prevent an internal machine from spoofing IP credentials onto your internal wire, so again, a firewall configured to provide this type of barrier is only one more way to increase your trust. It cannot be used to prove trustability.
When looking at how to establish trust (and detect spoofs) in any particular exchange of information, concentrate on data regarding the communication itself that can be brought to bear on the examination. This might be private data such as a password that only you and the sender are expected to know, external information such as what a firewall can tell you about the origin of a packet, a network handshake that proves that you've sufficiently correct network information to carry on a dialog with the sender, an encoding scheme such as a private protocol or secret sequence exchanges that must be performed, or the use of public or private key exchanges. Each type of verification for identity and validation of trust can be checked through the use of different mechanisms. Each can also be spoofed and false, believable credentials provided. For each exchange you want to trust, you need to examine the types of credentials that are being examined, how they can be spoofed, and what tests you might apply to detect such falsification.
Each user and computer installation is likely to be different in its needs, and many protocols already provide some mechanism for checking at least some sort of credentials. You will need to examine your situation and determine whether the mechanisms already in place give you a sufficient level of trust, or whether you need to add hardware or run additional software to increase your level of trust in information that is being conveyed to you.