On Sep 12, 2010, at 4:01 AM, Mark Smith wrote: > What I said was, and I'll highlight the key word, > > "Layer 2 devices inspecting traffic isn't *architecturally* acceptable > because it's a layer violation" > > The best place to fix IPv6 issues in in IPv6.
well, yes, but... let me give you one example. A few years back, in 2002 I believe, Cisco worked out that BCP 38 was pretty important to a subset of its customers that wanted it to apply to people on the same subnet. In short, IPv4 customers wanted to be prevented from classes of attacks that involved spoofing a source address, and having eliminated those attacks, wanted ISPs to be able to track other attacks to their sources. This applied to, among others, access ISPs. So we came up with a feature (which we patented) called IP Source Guard. It snoops DHCP, notes the IPv4 address allocated to a (MAC address on a) port, and sets the Catalyst 6K port filters to drop traffic from that port (and MAC Address) that doesn't have that source address. The existence of the port filter tells you that network administrators had already been installing other filters, such as looking at the transport layer port, for other reasons. Other companies copied the feature. Per a note earlier in this thread, it is something that at least one ISP considers essential to making IPv4 deployable in access networks. SAVI is working on the same feature for IPv6. The technologies under consideration include DHCP snooping, SLAAC snooping, and SEND snooping. Note that the IPv4 feature was never standardized. I can do that in other ways. I could imagine, for example, every host and router on a LAN maintaining a set of registered neighbors and only being willing to talk with neighbors that were registered. That model is under discussion in 6LowPAN. To do that, I need to change every host implementation and every router implementation, and I give up something - an attacker still costs the switched network bandwidth when he sends a message, as it has to be received. If I allow the layer violation, the host costs itself the bandwidth on its own port, but the switch would never send it on. In general, I would agree that the place to fix an issue is in the core protocol for the issue. But for an operational network, the choice of protocol is far less important than the characteristics of the solution they are trying to achieve. Sometimes, holding one's nose and crossing the layer boundaries is the right choice. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
