| 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 PROTECTED]>
| 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).
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
