二层数据报：
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服务器对于工作组环境的机器还是会起作用的。
表达能力不强，见谅！
文章整理：西部数码--专业提供域名注册、虚拟主机服务
http://www.west263.com
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!
