有时，数据包内的连接信息是可预测的。例如，如果 TCP 初始序列号不是随机的，则它们可能会成为问题。有关示例，请参见http://www.networkcomputing.com/unixworld/security/001.txt.html。同样的事情也可能发生在 DNS 请求 ID 上。

通常，这些攻击在第一次尝试时不起作用，但在快速连续几次尝试后会起作用。如果您知道 Bob 刚刚询问 Alice google.com 的解析地址，并且您知道请求 ID，那么您可以通过发送一个声称来自 Alice 的 IP 地址的数据包来告诉 Bob 这是您的服务器。

一个示例可能是作为拒绝服务攻击（例如Smurf 攻击）的一部分进行欺骗。攻击者知道响应是什么，以及它会去哪里，所以不需要自己接收。

这种猜谜游戏的一个例子是 Dan Kaminsky 几年前（2008 年）在几乎所有 dns 实现中发现的现在著名的 DNS 漏洞。

基本上，可以通过在请求服务器上对强制 dns 请求进行许多回复来利用该漏洞，直到一个恰好具有正确的返回端口和序列（当您可以执行数千次时，猜测会更容易）。显然，这种解释距离完整的故事还有很长的路要走，请参阅下文以获得更好的解释。

The Security Now Epsode 155，史蒂夫·吉布森解释了这个漏洞

如果您正在欺骗其他人的 IP，那么您很可能不会收到您的欺骗创建的 IP 的流量。不过，您可能希望拥有该 IP 的欺骗机器接收此流量，例如因为您正在进行拒绝服务攻击。

（愚蠢的例子）假设您希望目标机器接收一百万个 DNS 响应。你构建了一个你知道会导致冗长响应的 DNS 查询（所以你在预测响应，因为你正在设计它），你欺骗了受害者机器的 IP，然后你将你的查询发送到一百万个 DNS 服务器，这些服务器都试图将他们的响应发送回被欺骗的机器。受害者机器被它所获得的流量所淹没，因为它的 IP 被用于攻击。

人们经常将 IP 欺骗与中间人混淆。在 IP 欺骗中，您不是代表原始机器，而是将您所做的任何事情归功于它，这与中间人相反，您实际上是在欺骗两台机器的 IP，其中一个通常是一个路由器，另一个是目标，而您充当中间人，或两者之间的中间人。

在第一种情况下，您不关心欺骗产生的流量，而在第二种情况下，您会关心。