On Tue, Jul 24, 2001 at 11:09:23AM -0400, Kastenholz, Frank wrote:
> At 04:27 AM 7/24/01 -0400, Ignatios Souvatzis wrote:
> 
> >On Tue, Jul 24, 2001 at 04:42:37PM +1200, Sean Lin wrote: 
> >
> >>     As we all know, there's no ipv6 header checksum field. Therefore, 
> >> for routers forwarding packets, the checksum of ipv6 packets cannot be 
> >> calculated? Which means that ipv6 routers will generally have a faster 
> >> throughput compared to a similar ipv4 router (assuming there's no 
> >> extension headers and option headers)? 
> >
> >Yes. That's the reason it was designed that way. 
> 
> For software based forwarding engines, you are correct.
> 
> However, most if not all high-speed routers one encounters
> today use silicon-based (ASICs and/or FPGAs) forwarders.
> The nice thing about silicon is that lots of stuff can be
> done in parallel. The IPv4 header checksum can be, and is,
> calculated in parallel with the other header checks, etc,
> that are going on. Thus, it takes 0.000000.... additional
> time. If IPv6 had a header checksum, it too would be 
> calculated in 0.00000... additional time.

you're aware that IPv6 has bigger headers, and additionally more likely
to be variable length, than IPv4? But even if hardware checksummers could
checksum most v6 headers easily - a) you'd need new hardware, b) you'd 
penalize most software routers and endnodes, and c) needlessly, as most
links used today are CRCing hop-by-hop anyway (all sorts of Ethernet, FDDI, 
ARCnet, Token Ring, PPP, to name a few), so what's really needed is 
end-to-end checking, not hop-by-hop.

Anyway - it was designed to be that way when I was much younger (you could
read about it in, err, was it Huitemas book 5 years ago?) and before
I joined the business, so you discussing with me about this point today seems
to be completely useless to me, as I can't and won't change it.

Regards
        Ignatios

PGP signature

Reply via email to