Subject: ipv6 header checksum

From: "Sean Lin" <[email-masked]>
Date: Tue, 24 Jul 2001 16:42:37 +1200

Hi,
    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)?

Regards,
Sean

---

From: Ignatios Souvatzis <[email-masked]>
Date: Tue, 24 Jul 2001 10:27:00 +0200

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.

	-is

---

From: "Kastenholz, Frank" <[email-masked]>
Date: Tue, 24 Jul 2001 11:09:23 -0400

>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.

Frank Kastenholz

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Ignatios Souvatzis <[email-masked]>
Date: Wed, 25 Jul 2001 11:23:55 +0200

> 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

---

From: Ignatios Souvatzis <[email-masked]>
Date: Wed, 25 Jul 2001 11:23:55 +0200

Regards
	Ignatios

---

From: Ignatios Souvatzis <[email-masked]>
Date: Wed, 25 Jul 2001 11:23:55 +0200

Regards
	Ignatios

---

From: Robert Elz <[email-masked]>
Date: Wed, 25 Jul 2001 21:29:21 +0700

| On Tue, Jul 24, 2001 at 11:09:23AM -0400, Kastenholz, Frank wrote:
  | > Thus, it takes 0.000000.... additional
  | > time. If IPv6 had a header checksum, it too would be
  | > calculated in 0.00000... additional time.

It could be done in 0 extra time, but not for 0 extra cost.
Reducing the required complexity of ASIC type forwarders reduces
their cost (development cost, and usually parts cost as well), and
hence increases the chances that people will actually be able to
afford a router that can forward packets that fast - while
simultaneously allowing the older, dumber, router types to route faster.

  | From: Ignatios Souvatzis <[email-masked]>

  | you're aware that IPv6 has bigger headers, and additionally more likely
  | to be variable length, than IPv4?

Since IPv6 never had a header checksum, what it would have included
was never defined.   I had always assumed that if it existed, it would
include just the IPv6 header, not all the subsequent headers (if it
did that it would really be a whole packet checksum, as there isn't
really a difference between a "next header == TCP" and "next header ==
destination options" in the design, they're both just next headers.)

If that was correct, then the IPv6 header is certainly bigger than the
minimal IPv4 header, but not at all likely to be variable length.

As I recall the discussions, the prime motivation for deleting the
header checksum was that nothing it protected actually matters.
That is, even if the packet gets corrupted in a way that the header
checksum would detect, the cost of not detecting it is close to 0
(when the packet is actually delivered, the transport level checksum,
including the pseudo-header, will detect anything broken in transit
that matters).

The only real concern was the possibility that something out there
may be inadvertently increasing the TTL, leading to the possibility of
packets that loop forever.   Two things could do that - random
packet corruption not detected by a link level checksum, which can
be ignored, as the chances of it happening repeatedly are about 0,
or broken software, in which case trusting the software generated
checksum to rescue us seems like wishful thinking.

Nothing else in the header matters - the packet will either be
detected as bad en route in other ways (say if the next header
field gets cleared, and what follows doesn't look at all like options)
or when the packet arrives.

Doing validation at every hop either adds cost or delay, for no benefit
worth having.

For people used to the mantra of a checksum being necessary for protection,
deleting it certainly seems rash, but when analysed, it is the right thing
to do.

kre

ps: if other headers (than the IPv6 header) actually need checksums
to protect data in them from modification, those headers should have
checksums.  Stuff like AH, ESP already has better methods.  Transport
already has checksums.  The routing header doesn't need anything, nor
does the frag header.  If there are ever any options data that need to
be protected, then a checksum option could be invented.
(Right now I forget what other headers exist).

---

From: Robert Elz <[email-masked]>
Date: Wed, 25 Jul 2001 21:29:21 +0700

kre

---

From: Robert Elz <[email-masked]>
Date: Wed, 25 Jul 2001 21:29:21 +0700

kre

---

From: "Kastenholz, Frank" <[email-masked]>
Date: Wed, 25 Jul 2001 08:28:06 -0400

At 05:23 AM 7/25/01 -0400, Ignatios Souvatzis wrote:

>to be variable length, than IPv4?

The basic forwarding decisions are all made in from the first,
basic, header. You know, the one with the addresses in it. For basic 
forwarding, none of the other headers matter. The Routing header
is of interest, but if the routing header sees as much use as IPv4's
source routes, the hardware can ignore it.

>But even if hardware checksummers could 
>checksum most v6 headers easily - a) you'd need new hardware, 

But we need to develop new ASICs and FPGA images to support
IPv6 anyway, so adding hypothetical header checksumming would
be almost-0-added-cost for development and truly 0 added cost
for deployment. Of course, if the IPv6 development community
were to decide to add header checksums after IPv6-capable
ASICs and FPGAs were fielded, it would cost a lot.

>b) you'd penalize most software routers and endnodes, 

That depends on how over-built the software systems are, doesn't
it? I mean, if the processor and data path and memory can handle
the load of checksumming without degrading overall system performance,
then there is no operational penalty, is there? 

As to the cost on end-nodes, everything is relative. The cost
of a hypothetical IPv6 header checksum would be rather trivial
compared to the cost, say, of doing the TCP data checksum, which
can be over much, much, much, larger piles of bits.

>and c) needlessly, as most 

For the most part I agree. However, the link CRC does not
protect the packet while it is in a router's buffers or crosses
the various links within the router. So any error that might be 
introduced there would be undetected. Some parts of the
hardware are pretty good -- for instance, error rates within
chips (i.e. when the packet is in the flipflops inside a chip)
are astronomically low. But at other places the rates can
be high -- in particular
- the high-speed (2+ghz) inter-chip links
- drams for buffers and stores of various kinds, and
- inter-board fabrics and backplanes
and those places do need protection. Good vendors will put in 
parity and CRC and whatever to protect things, but that costs
added RAM, links, and so on, which means that costs are higher.
Vendors who are "cost sensitive", careless, or poorly educated,
might omit these protections. Thus, undetected errors can 
creep in.

Then the questions are
- what are the error rates?
- how bad is it if one hits?

The answer to the first question is that the rates are fairly bad.
Any individual link, memory, etc, has a lowish rate, but due to the
quantity of them, the total rate for the box can be distressingly
high (the numbers depend on the box/design in question, of course).

The answer to the second question is less bad if the errors are
transient. Technically, if an occasional packet goes off to some
random place, it's no problem. But now we have data going to the
wrong place. That is generally frowned upon (for the sake of
argument, suppose that the packet has your ATM card number
and PIN in it ...). 

A bigger technical problem is if the error is not transient, 
that it's a 'stuck bit' someplace. Now, every packet goes wrong,
but the box does not know it, and can not report the failure.

You might wonder whether this protection is really relevant.
But I've met with enough customers and potential customers
to know that they ask very very detailed questions about a
router's internal data paths and EDAC and so on. They care.

>to be completely useless to me, as I can't and won't change it. 

I am not trying to change the IPv6 design decision. The lack of
a header checksum is the least of the things I would consider
changing in V6. However, understanding some of the engineering 
issues surrounding the implementation of a critical part of the
Internet infrastructure seems, to me anyway, to be A Good Thing.

Frank Kastenholz

Frank Kastenholz