platinum 老大這裡確實理解有問題，ip數據報不可能沒有mac信息 二層數據報： frameheader---framebody 三層數據報： frameheader---ipheader---ipbody 對於工作在二層的設備來說任何數據報都只區分為數據頭和數據體，一個ip包的ip頭和ip數據會被統一認作二層
platinum 老大這裡確實理解有問題，ip數據報不可能沒有mac信息
二層數據報：
frameheader---framebody
三層數據報：
frameheader---ipheader---ipbody
對於工作在二層的設備來說任何數據報都只區分為數據頭和數據體，一個ip包的ip頭和ip數據會被統一認作二層數據體。
而對於工作在三層的設備來說，基本上是二層已經根據二層頭作過相應處理提交上來的，但你不能說它沒有二層頭，這個信息肯定是保留的，只是對於三層設備來說只能拿到二層設備已經分揀過的數據。
iptables確實是工作在三層及以上，這從iptables幾個鉤子函數的位置可以看出。有了這個結論，再澄清兩點：
1，關於iptables的mac過濾----雖然工作在三層，但是二層信息也是存在的，所以過濾也是可行的，但有一點限制，就是二層向三層遞交時，只會遞交你能對應識別的三層包：
（1）iptables是工作在第三層ip協議下，你iptables當然不可能抓到其他三層協議的數據報，比如，你無法處理ipx包。
（2）iptables是工作在第三層ip協議下，不能處理二層沒有提交到三層的數據報，比如arp請求和rarp請求，你是過濾不到的。
2，關於為什麼iptables無法過濾dhcp請求----根據第一點的結論，這一點也很顯然可以得出結論了：
（1）dhcp協議是一個ip地址分配協議，面向的是還沒有建立ip協議盞的client，對於此類的client，很顯然不可能使用目前還不存在的三層協議通訊來分配三層地址。
（2）由（1）的結論以及rfc可知，dhcp是通過二層廣播來傳送報文的，所以共享hub環境和交換環境的廣播處理的不同導致的不同的結果。
（3）根據（2），此時的dhcp報文，對於dhcpserver來說，不可能提交到ip層，所以不經iptables處理，對於dhcpclient，ip協議盞還沒建立起來，你iptables都還沒出生，你還能干什麼？
所以對於dhcp，只能從二層環境想辦法，iptables就別想了，ebtables應該還可以有所作為，再加上交換環境和共享環境的不同，相信也能得出自己相應的解決辦法了。
再有就是Windows的驗證dhcp問題，這個是因為Windows特有的AD構建的特有的安全邊界導致的，你可以看一下，所謂的驗證dhcp服務器，只能用於域存在的環境，如果在同一網段即存在域和工作做，那惡意dhcp服務器對於工作組環境的機器還是會起作用的。
表達能力不強，見諒！
