In your letter dated Wed, 22 Jun 2011 07:08:43 -0400 you wrote: >More importantly, the implementation approach I described on the IPv6 >list is neither complicated nor computationally expensive. In fact, >supporting the limited set of non-silly-for-ND-packet Extension Headers >has tiny incremental memory footprint and tiny increase in the >instruction count. The instruction count increase only applies if >an actual Extension Header is encountered, btw. The code for a L2 >device to locate the IPv6 header, read that header, and read into >the ICMP message to determine that a packet is an ND packet *dwarfs* >the code to skip past the small set of reasonable Extension Headers >for ND packets.
I have to admit I don't know much about the internals of L2 switches. But my mental model of a 10 Gbit/s ethernet switch is that of an ASIC/FPGA that does almost all forwarding with the CPU just for management. I've no idea how expensive it would be to parse extension headers in an ASIC. I think it is a bit ironic that if a L2 device has to parse all extension headers, that then L2 switching of IPv6 packets will be more expensive that L3 routing them. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
