最开始发现这个现象是在windows上面，之前以为是dhcp失败后，会有个随机值作为IP地址，以为是个垃圾数据，是windows特有的行为。最近一个项目，基于buildroot构建，用到4G上网功能，在开发其他功能，一直没插SIM卡，总发现4G接口会拿到一个奇怪的IP地址169.254.118.160。测试把这个问题当作一个bug提给了我。我发现这个IP地址每次都是一样，而且不同机器拿到的这个IP也是一样，如果按我以前的推测，这是垃圾数据，应该是个随机值才对，不可能全部一样。在windows上测试，也是一个169.254.x.x的地址，看来这个是故意为之的。果然，上网搜索这个叫APIPA(Automatic Private IP Addressing Allocation),自动专有IP地址分配。
The169.254.0.0/16network is used for Automatic Private IP Addressing, or APIPA. If a DHCP client attempts to get an address, but fails to find a DHCP server after the timeout and retries period it will randomly assume an address from this network.
169.254.0.0/16网络用于自动专用IP寻址或APIPA。如果DHCP客户机尝试获取地址，但在超时和重试后找不到DHCP服务器，它将随机假定来自此网络的地址。其实它还有个条件，就是你没设置网关。169.254.0.0/16这个地址段就是local link address，就是链路本地地址。想要看到这个地址，就需要你的设备支持链路本地地址。
LLA在RFC3927中有详细的描述，它分为三个阶段：
首先：在开始Local link时，需要将自已的IP和掩码网关都设为0，并随机生成一个IP，网段在169.254.1.0到169.254.254.255，RFC3927中建议使用MAC来生成IP地址，这样可以使每个设备生成的IP都不一样，将设备同时探测同一个IP的可能性降到了最低。
其次，发送ARP探测包，选择合适的IP地址：将目的IP地址指向要探测的IP，这里假设该IP为A；如果网络中，IP A被绑定，则占用该IP的主机会回应，设备在收到的ARP回应中，如果发现源IP是A，则表示冲突；当然，还有一种情况，可能有其它的设备也在探测这个IP，那么，在这种情况下，选择放弃该IP，重新开始配置。
最后，探测包发完了，并且在规定的时间内没有收到来自源IP为A的主机回应，则认为该IP没有被占用，于是设置本机IP为A，RFC3927 2.5节中描述，地址冲突的检测并不局限于地址选择阶段，在任何时候，如果设备收到一个ARP，其中源IP地址和本机IP一致，但MAC不一致，都将认为这是一个冲突。
那么如何禁用它呢？在linux下，dhcpcd.conf里面加上noipv4ll选项即可。
参考:
标签：APIPA,IP,地址,169.254,IP地址,DHCP,网络接口 From： https://www.cnblogs.com/thammer/p/17607897.html