假設網路中出現了一個全是FFFF的IP數據包，那這個數據包將會如何被處理？

12-28

IP首部全是FFFF
協議也是FF
後面跟的數據內容也是FFFF FFFF FFFF......

首先，主機可否發送IP包全是FF的數據包？
可以的！

第一步：假設一個主機發送出這樣全FF的包，網卡使用自己的硬體MAC地址做源，FF.FF.FF.FF.FF.FF做目的MAC

第二步：凡是接收到此幀的設備網卡都會正常接收，默認其為廣播地址，根據ether-type = 0x0800通知IP來處理

第三步：IP模塊先進行「完整性檢查」（Sanity Check)，主要針對關鍵欄位如version、head of length、length、source IP、TTL、checksum看是否合法，IPv4 version 應該 = 4，IP包里為F，很顯然檢查失敗，會被丟棄。

同學們會說這些欄位如果偽造的都是合法的，只有目的IP= 255.255.255.255=FF.FF.FF.FF，這就是一個正常的廣播，比如DHCP Discovery就是這樣的，路由器不會對目的「255.255.255.255」的路由轉發，只會默默地丟。

當然也不排除一些naive路由器基於IP包的目的IP「255.255.255.255」路由查找，最後匹配個默認路由「0.0.0.0/0」，發給自己的默認網關，只要默認網關不naive，還是會把這個廣播包丟棄。

結論
這個廣播包會在第一跳三層設備處被丟棄！

燒掉！【大霧

全1那就不是ip包。

首先這種封包，只有在給你所有控制許可權的硬體上，軟體才可以造出來，例如交換機的CPU。
交換機收到這種封包，在二層，SMAC如果是廣播地址，交換機有選項設置是丟棄還是繼續轉發，還是交給CPU處理。SMAC和DMAC相等也會有同樣的選項。一般默認是丟棄。後面的解析模塊會繼續檢驗其他field，例如ethertype等。
同理，三層也是這個道理。

額。。。並不是十分了解IPv6的細節，但是IPv6確實通過數字字母混用把地址擴展到了2的128次方，所以16位f這個IPv6地址也是有可能存在的。。。(不知道有沒有說錯的)

當然協議頭ffff。。。這個數據包可能導致時鐘頻率莫名提高從而導致硬體不可逆的損害，麻煩交換機把這個玩意廢棄掉謝謝(光速逃)