最開始發現這個現象是在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選項即可。
參考: