Subject: Re: Correcting LINK (Advice for Internet Subnetwork Designers)

From: Phil Karn <[email-masked]>
Date: Wed, 28 Feb 2001 22:52:08 -0800

>E2E checks don't detect some IP header errors; some fields
>change hop-by-hop.

Okay, how about this new text:

IP version 6 (IPv6) does away with the IP header checksum. The
destination host detects "important" errors in the IP header such as
the delivery of the packet to the wrong destination. This is done by
including the IP source and destination addresses in the computation
of the TCP header checksum, a practice already performed in
IPv4. Errors in other IPv6 header fields may go undetected; this was
considered a reasonable price to pay for a considerable reduction in
the processing required by each router.

>PPP can catch and regenerate these checksums on individual hops,
>just as ethernet can. I.e., how do you know when the link layer changes?

Here's my present wording:

  If the subnetwork carries the PPP or Ethernet CRC without
  change through the subnetwork, it will automatically provide the
  desired edge-to-edge error detection.

The idea here is that if the subnetwork does not regenerate the CRCs,
then they can serve as effective edge-to-edge checks. If the subnet
regenerates CRCs on a hop by hop basis, then there's always the chance
that it will do so incorrectly. This does not mean that the subnet can't
*verify* the CRC on each hop and discard errored frames if it wants.

Should I add this clarification to the document?

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 1 Mar 2001 10:59:10 +0000 (GMT)

On Wed, 28 Feb 2001, Phil Karn wrote:

> of the TCP

and UDP checksums. It's not a header checksum per se; the
pseudo-header just happens to be included in the whole
thing. 'packet checksum value in the TCP and UDP headers' is probably
clearer; after reading about an IP header checkum, 'TCP header
checksum' just confuses.

> header checksum, a practice already performed in

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 1 Mar 2001 11:22:10 +0000 (GMT)

On Wed, 28 Feb 2001, Phil Karn wrote:

>    There is still a subtle error in the specification of the 
>    packet error rate in the wireless example, point 2,3 :
> 	
>    p = 1 - ([1 - BER]^[MSS * 8]) - Not quite so.
>    
>   MSS should be MSS+(IP HEADER including IPSEC If used)
>      +(Cumulative link overhead in bytes)
> 
> 
> I've made it even simpler. I reworded this section to replace
> all references to "MSS*8" with "PACKET_SIZE". This is defined to
> be the total packet size (user data plus all headers) in bits (not bytes).

see 
http://pilc.grc.nasa.gov/list/archive/1162.html
for my previous comments on that.

I think defining packet_size in bits is a bad idea.

L.

---

From: Phil Karn <[email-masked]>
Date: Thu, 1 Mar 2001 09:18:14 -0800

>I think defining packet_size in bits is a bad idea.

Can you elaborate?

Phil

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 1 Mar 2001 18:02:44 +0000 (GMT)

> >I think defining packet_size in bits is a bad idea.

All other IETF protocol descriptions concerning IP packet size work in
octets. I see packet size, I think octets. If you're already talking
about MSS (earlier in the draft in eqns), you're already talking
octets; stick with it for packet properties.

L.

---

From: Phil Karn <[email-masked]>
Date: Thu, 1 Mar 2001 13:14:33 -0800

>pseudo-header just happens to be included in the whole thing. 'packet
>checksum value in the TCP and UDP headers' is probably clearer; after
>reading about an IP header checkum, 'TCP header checksum' just
>confuses.

Thanks. The text now reads:

  This is done by including the IP source and destination addresses in
  the computation of the checksum in the TCP or UDP header, a practice
  already performed in IPv4.

Phil

---

From: Phil Karn <[email-masked]>
Date: Thu, 1 Mar 2001 13:30:33 -0800

>octets. I see packet size, I think octets. If you're already talking

Well, yes...but we have already introduced the term "BIT error rate" (ber).
I think people can keep the distinction, and by defining PACKET_SIZE
in bits I can tighten up all the equations by dropping the x8 factor.

Phil

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 1 Mar 2001 21:36:00 +0000 (GMT)

> in bits I can tighten up all the equations by dropping the x8 factor.

tighten up != clarify.

'*8' is a useful, clear indication that you're using bits...

L.

---

From: Phil Karn <[email-masked]>
Date: Thu, 1 Mar 2001 17:46:18 -0800

>octets. I see packet size, I think octets. If you're already talking

Okay, fine, I've changed it back to octets.

Speak for yourself regarding bits vs bytes. In the telecom world, everybody
works in units of bits. Only those nerdy computer types even know what
a "byte" is. :-)

Phil

---

From: Cannara <[email-masked]>
Date: Thu, 01 Mar 2001 21:12:42 -0800

I'd add that to be more generally understandable, the terms PDU and PDU
checksum could be used -- e.g., "the TCP PDU checksum".  This covers all the
issues stated.

Alex

---

From: Cannara <[email-masked]>
Date: Thu, 01 Mar 2001 23:05:51 -0800

Sounds good.  A little side comment -- the IPv6 committee surprisingly saw to
it that v6 would be deficient in relation to v4 in at least two important,
real-world respects:  a) no more IP ID, just to save 16 bits, so no more
ability to easily detect switching/bridging loops with a pkt analyzer (seeing
pkts with same ID on same LAN segment); and b) loss of the header checksum,
which at least gave a hope of detecting flakey router/bridge/gateway memory
and preventing oddball routing-table garbage from being created downstream. 
Such is the 'progress' we learn to expect from committees.  Where's v7?  :]

Alex

Phil Karn wrote:
> 
> Gorry,
> 
> After reading the Stone & Partridge paper you cited, I've
> substantially rewritten the section on subnetwork error detection. How
> do you like this new text? --Phil
> 
> The TCP, UDP and IPv4 protocols all use the same simple 16-bit 1's
> complement checksum algorithm to detect corrupted packets. The IP
> checksum protects only the IP header, while the TCP and UDP checksums
> protect both the TCP/UDP header and any user data.
> 
> IP version 6 (IPv6) does away with the IP header checksum and relies
> on end-to-end checking to detect IP header errors.
> 
> These checksums are not very strong from a coding theory standpoint.
> But they are easy to compute in software, and various proposals to
> replace them with stronger checksums have failed. Yet a study [SP2000]
> has shown that the Internet corrupts one in 1,100 to 32,000 packets,
> and it is up to the end-to-end Internet checksum to detect these
> errors.
> 
> Most packet corruption appears to be caused by bugs and errors in host
> and router hardware and software. So even if every subnetwork
> implemented strong error detection, the end-to-end use of TCP and UDP
> checksums would still be necessary.
> 
> Most subnetworks implement error detection just above the physical
> layer. Packets corrupted in transmission are detected and discarded
> before delivery to the IP layer.  A 16-bit cyclic redundancy check
> (CRC) is usually the minimum, and this is known to be considerably
> stronger than the 16-bit standard Internet checksum. The
> Point-to-Point Protocol [RFC1662] requires support of a 16-bit CRC,
> with a 32-bit CRC as an option. (Note that PPP is often used in
> conjunction with a dialup modem, which provides its own error
> control). Other subnetworks, including 802.3/Ethernet, AAL5/ATM, FDDI,
> Token Ring and PPP over SONET/SDH all use a 32-bit CRC that is
> considerably stronger.  In addition, many subnetworks (notably dialup
> modems, mobile radio and satellite channels) also incorporate forward
> error correction, often in hardware.
> 
> Any new subnetwork designed to carry IP should therefore provide error
> detection at least as strong as the 32-bit CRC specified in [ISO3309].
> 
> While this will achieve a very low undetected packet error rate, it
> will not (and need not) achieve a very low packet loss rate as the
> Internet protocols are better suited to dealing with lost packets than
> with corrupted packets.
> 
> Designers of complex subnetworks consisting of internal links and
> packet switches should consider implementing error detection on an
> edge-to-edge basis, i.e., at the interface to IP, either in addition
> to or instead of error detection at the interface to each physical
> link. This has the significant advantage of protecting against errors
> introduced anywhere in the subnetwork, not just its transmission
> links.
> 
> This is straightforward if the interface presented to IP by the
> subnetwork already includes error detection, as with PPP or
> Ethernet. If the subnetwork carries the PPP or Ethernet CRC without

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 2 Mar 2001 09:49:28 +0000 (GMT)

On Thu, 1 Mar 2001, Cannara wrote:

> I'd add that to be more generally understandable, the terms PDU
> and PDUchecksum could be used -- e.g., "the TCP PDU checksum".  
> This covers all the issues stated.

Then you'd have to define 'PDU', which isn't generally understandable.
More importantly, the TCP PDU checksum isn't a TCP PDU checksum,
because the checksum also includes the IP header, which *isn't in* the
TCP PDU.

Hence 'packet checksum'.

L.

---

From: Thomas Narten <[email-masked]>
Date: Fri, 02 Mar 2001 08:33:33 -0500

To clarify a couple of things regarding IPv6 design decisions.

> Sounds good.  A little side comment -- the IPv6 committee
> surprisingly saw to it that v6 would be deficient in relation to v4
> in at least two important, real-world respects: a) no more IP ID,
> just to save 16 bits, so no more ability to easily detect
> switching/bridging loops with a pkt analyzer (seeing pkts with same
> ID on same LAN segment);

The motivation wasn't just to save 16 bits. It was also to get IP
(i.e., routers that forward packets) from needing to fragment packets
they forward. In IPv6, fragementation is end-to-end from an original
sender to a destination (where a sender is identified by the  source
IP address, so it could be a router on a tunnel entry).

Note that whether routers should fragment or whether it should all be
done end-to-end via PMTU is one of the basic architectural design
points that some folks never felt IPv4 got right (as compared to say
XNS).

> and b) loss of the header checksum, which at least gave a hope of
> detecting flakey router/bridge/gateway memory and preventing oddball
> routing-table garbage from being created downstream.  Such is the
> 'progress' we learn to expect from committees.  Where's v7?  :]

Dropping the checksum from the IP header is a simple engineering
tradeoff. The cost of having a checksum (bits in header, processing,
etc.) isn't offset by the benefits of having one. So the IP fields in
a packet header get corrupted occasionally. So what? What's the
fallout? Maybe the packet gets routed/forwarded to the wrong place
(where it still gets discarded when a higher layer checksum fails, or
no such port exists, etc.). Overall, there is no singificant problem
that results.

I also wonder if you are confusing IP checksum with higher-layer
(e.g., TCP/UPD/ICMP) checksum above. IP checksums won't detect
corruption in the payload, i.e., that might lead to routing table
'garbage' somewhere.

Thomas

---

From: Joe Touch <[email-masked]>
Date: Fri, 02 Mar 2001 10:25:31 -0800

> Such is the 'progress' we learn to expect from committees.  Where's v7?  :]

That progress was motivated by the expected proliferation of IPSEC, in
which case both become largely redundant.

The IP ID doesn't save that much - it was only there for reassembly
anyway. Bridges that tossed replicated IDs would make two mistakes:

	- dropping packets that for which ID was undefined anyway (if frag not
set)
	
	- dropping packets intended to for FEC (see RFC791's example of TCP
retransmits)

IPv6 didn't drop that information, BTW. It buried it inside the
(optional) fragment header (see sec 4.5 of RFC2460), where it belongs so
'clever' bridge designers don't use it when they shouldn't :-)

Joe

---

From: Phil Karn <[email-masked]>
Date: Fri, 2 Mar 2001 12:25:23 -0800

>ID on same LAN segment); and b) loss of the header checksum, which at
>least gave a hope of detecting flakey router/bridge/gateway memory
>and preventing oddball routing-table garbage from being created
>downstream.  Such is the 'progress' we learn to expect from
>committees.  Where's v7?  :]

I wasn't involved in the IPv6 definition, but I presume they had their
reasons for those changes. The ID field in IPv4 is there to allow
hosts to reassemble packets that have been fragmented by routers, but
since there is no router fragmentation in IPv6 I guess the ID field
was considered superfluous.  Seems to me you could still detect
switching/bridging loops by simply looking for packets with identical
content. You wouldn't even have to look at the complete packet; just
the CRC would be enough (if you can get at it with your analyzer).

I assume the reason for the deletion of the header checksum was to simplify
the job of a router. In IPv4, a router has to first verify the header
checksum and then recompute it after it decrements the TTL.

Phil

---

From: Phil Karn <[email-masked]>
Date: Fri, 2 Mar 2001 12:26:22 -0800

>Hence 'packet checksum'.

I've left it unchanged for now. I've used PNDU to refer to things like ATM
cells, but "packet" to refer to IP datagrams. I think that should be
reasonably nonconfusing, but I'm open to further suggestions.

Phil

---

From: Cannara <[email-masked]>
Date: Sat, 03 Mar 2001 21:18:04 -0800

Joe, thanks.  Perhaps I wasn't clear -- I wasn't advocating bridges/switches
using the IP ID, just people troubleshooting goofed-up LANS, say when Cisco
switches are accidentally configured to forward upon link up (was the default
in early Catalysts to prevent Netware connection timeouts), rather than
waiting the proper Spanning Tree timeout (typically 15 sec.).

Also, I realize the checksum is buried in the (optional) fragment header --
and "optional" is the precise problem.

Alex

---

From: Cannara <[email-masked]>
Date: Sat, 03 Mar 2001 22:33:23 -0800

Thomas, please see my other responses to Phil, etc.  Also, now intimate with
the network processors that folks use to build multi-Gb/s nets, there's little
justification for dumping a checksum calculation that can save downstream
devices from having to allocate precious RAM (slower in access) to cache
mystical routes that simply arise because of IPv6's checksum omission.  Again,
ID and checksum omission seem to be testament to a myopia common in the
Internet community, that networking = TCP/IP networking, despite the latter's
invention and evolution naive of DLC and physical links.

Alex

---

From: Cannara <[email-masked]>
Date: Sat, 03 Mar 2001 22:07:21 -0800

Phil, I don't see why PDU is a problem, nor that the TCP checksum has to do
with IP's, since IP is only on its header and is computed after TCP's (or
whatever other transport is carried by IP).  The words "packet" and "PDU" are
synonymous at each layer, so that's fine, but "frame" is also available at the
physical medium.

Alex

---

From: Cannara <[email-masked]>
Date: Sat, 03 Mar 2001 22:15:28 -0800

Phil,

I had asked some folks on the v6 committee and the ID was simply dumped to
retrieve some small amount of space, perhaps because of the embarrassment of
bits now in the addresses.  Probably, folks didn't know how useful it was for
LAN debugging, especially since the Inet family traditionally has little
comprehension of anything below IP.  The checksum point I make was not even
considered by the committee, at least from what my conversations found.  In
fact, one of the people was perplexed to realize that maybe it's not a good
idea to propagate Layer 3 garbage to the next Layer 3 systems -- mucking up
route caches, etc.

Working one job for a manufacturer of network-processor chips, used by Cisco
etc., is see the code is all there for system makers to use for IP
checksumming and rechecksumming, with little impact on speed (one
instruction).  I'd say we'll rue the day IPv6 checksums were made "optional"

Alex

---

From: Dr G Fairhurst <[email-masked]>
Date: Mon, 05 Mar 2001 14:38:50 +0000

> be the total packet size (user data plus all headers) in bits (not bytes).

Thanks!

Gorry

P.S. Actually I think it may have been better to use "frame size", but
whatever is consistent with the document.

-- 
------------------------------
http://www.erg.abdn.ac.uk/users/gorry