二层数据报：
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服务器对于工作组环境的机器还是会起作用的。
表达能力不强，见谅！
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
