DHCPREQUEST之前，一台机器的IP是多less？

从我了解的很less，DHCP允许从DHCP服务器dynamic分配IP地址给networking上的客户机。客户端发送一个DHCPDISCOVER数据包，然后从服务器返回一个DHCPOFFER到客户端，然后可以跟随一个DHCPREQUEST等等。

因此，如果一旦服务器收到客户端的DHCPREQUEST数据包，IP地址就被正式“分配”，那么在这之前是否有一些通用的IP分配规则？由路由器，交换机或网卡？

我很好奇，因为我知道我对networking工作有一些误解，还因为我试图使用wireshark来查看一些DHCPOFFER和DHCPREQUEST数据包，wireshark当然列出了源和目标IP地址，但我有不知道在整个过程结束之前会发生什么。所有我知道的是客户端的MAC地址，因为/var/log/messages字面上只是说： DHCPDISCOVER from [MAC ADDRESS]

它有一个IP之前没有IP。

DHCP Discover数据包的示例将源IP设置为0.0.0.0，目标为255.255.255.255，以便向本地networking上的每个主机广播。

从服务器的答复到客户端的MAC地址。当你说All I know about is the client's MAC address – 这就是所有的DHCP服务器知道以及，这就够了。

但是，主机有一个标准来为自己分配一个IP，这通常在DHCP请求失败时发生。这些IP位于169.254.0.0/16范围内。

http://packetlife.net/blog/2008/sep/24/169-254-0-0-addresses-explained/

当主机无法dynamic获取地址时，可以根据RFC 3927select性地为自己分配链路本地IPv4地址。微软的这个术语是自动专用互联网协议寻址（APIPA）。

因此，如果主机之前已经尝试过DHCP，并且无法获取地址，则主机可能拥有一个自行分配的链接本地地址，现在正在尝试DHCP。

（这与DNS无关）

有一个基本的观点应该是清楚地弄清楚DHCP发生了什么： 你在一个以太网上 ……在这个networking之上，IP数据包正在stream动，其中的UDP数据包被封装在里面其中DHCP消息被发送/接收。总之，你必须考虑整个协议栈，而不是限制自己到DHCP。

你说：“ 客户端发送DHCPDISCOVER数据包，然后从服务器返回到客户端的DHCPOFFER，然后可以跟随一个DHCPREQUEST等 ”

对于“ 客户端传输 ”部分，您应该考虑在以太网上，两台主机只能通过MAC地址进行“对话”。这些是由物理networking适配器内的硬件制造商唯一地烧毁的地址。举个例子，我现在使用的PC的网卡有这个MAC：“a4：ba：db：98：fc：a4”。

如果您认为，MAC地址不能在“随机”的基础上定义/分配。事实上，每个供应商都被分配了一组固定的地址，并且由此得知，我的networking适配器是由戴尔

所以，现在我们知道在以太网上寻址是基于MAC地址（而不是IP地址）的。这意味着为了在以太网networking中有效地路由IP数据包，我们需要一些东西来获取目的主机的MAC地址。例如：“ 我想发送一个消息给主机，其IP地址是abcd;我需要它的MAC地址;一旦我得到这样的MAC地址，我将封装我的IP数据包，并发送到该MAC地址 ”。

你可能会想：

如果我不知道目标主机的MAC地址怎么办？

或者更高层的协议栈：

如果我不知道目标主机的IP地址怎么办？

关键的概念在这里是广播。以太网和IP都提供了特殊的地址，当我们需要到达一个地址对我们来说是未知的人时，这个地址就可以正确使用。

在以太网中，特殊的MAC地址： ff：ff：ff：ff：ff：ff （48位，全为1）是广播。以太网协议规定，如果你是一个以太网适配器，你必须读取和读取：

数据包发送到你自己的MAC地址（a4：ba：db：98：fc：a4，如果是我的笔记本）。
发往广播地址的数据包（ff：ff：ff：ff：ff：ff）。

这意味着：

如果我是一个尚未configurationIP地址的主机，并…
我configuration为请求基于DHCP协议的IP地址和…
我通常不知道要问的DHCP服务器的MAC地址

然后

我可以在发往以太网广播地址（ff：ff：ff：ff：ff：ff）的以太网帧内发送DHCP请求。

通过做这个：

我的局域网上的每个以太网主机都会收到我的请求;
所有不运行DHCP服务器的主机都会忽略它。
DHCP服务器会明白这是一个DHCP消息，并将相应地处理它。
DHCP服务器将使用自己的MAC地址作为“源MAC”和自己的IP地址作为“源IP”来回复（使用以太网帧）（因此，对于我而言，直接向其发送下一帧，而不再通过广播），并使用我的MAC地址作为目标MAC（我的MAC被报告在我的原始帧，在source_MAC字段）。

回到你的问题，你想知道IP地址。

现在我们知道DHCP-discover消息被发送到以太网广播MAC地址，我们需要提醒的是，在以太网帧内封装了一个IPv4数据包。这样的IPv4分组必须包含一个SOURCE_IP地址和一个DESTINATION_IP地址。在这个非常特殊的情况下（DHCP-discover消息），发送主机不知道这两者中的任何一个：

它不知道它是自己的IPv4地址，因为它正在开始要求的东西。因此，源地址字段将被设置为0.0.0.0;
它不知道DHCP服务器的IPv4地址。因此，目标地址字段将被设置为255.255.255.255（猜测什么？32位，设置为1）你注意到相似之处吗？）

请注意，在这个非常特殊的情况下（DHCP-discover），这两个地址几乎都是无用的：MAC地址是什么计数（再次：在这个DHCP发现帧）。

让我添加一个最后的笔记。你写道：“ 我试图使用wireshark来查看一些DHCPOFFER和DHCPREQUEST数据包，wireshark当然列出了源和目标IP地址 ”。 Wireshark，因为在以太网上运行的每个数据包嗅探器都会向你报告许多事情，包括source-mac-address和destination-mac-address。

实际上Wireshark将真正帮助你理解封装过程，因为你将看到完全用MAC寻址的以太网层（第二层），其中包含包含IP数据包的第三层（IPv4）。此外，在IP内，您将在DHCP消息中看到UDP数据包。

我期待你在没有任何filter的情况下启动wireshark捕获。这是因为如果你使用filter，你冒着风险不能捕获所有你需要的东西（提醒广播和无地址帧/数据包）。

PS：我恳求所有技术人员都读这个信息：我知道我一直是极其普遍的，并且有许多不是非常正式的概念。 我知道。 我认为这需要帮助@ krb686进入我非常喜欢的networking世界:-)

DHCP握手成功完成之前，客户端没有IP地址。

它的工作原理，你不打一个鸡和鸡蛋的问题是一个IP地址是没有必要的两台主机在同一子网内进行通信 – 它可以使用只有MAC地址。

DHCP是通过UDP完成的，这意味着，它确实使用IP地址。目标是广播，客户端的源为0.0.0.0，服务器回复的服务器的IP为0.0.0.0。