On Wed, 22 Jun 2011 13:18:49 +0200 Philip Homburg <pch-v6...@u-1.phicoh.com> wrote:
> 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. > It may be getting to the point where it'd probably be easier to address these issues by taking away hosts' ability to multicast to other hosts on the same segment i.e. switch to an NBMA/hub-and-spoke mode of LAN operation, allowing the designated routers to also act as traffic sanitisers for on-link inter-host traffic. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
