RFC 1812, section 4.2.2.5

Craig Partridge <craig@aland.bbn.com> Fri, 15 September 1995 00:45 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25969; 14 Sep 95 20:45 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa25965; 14 Sep 95 20:45 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa07917; 14 Sep 95 20:45 EDT
Received: from BBN.COM by venera.isi.edu (5.65c/5.61+local-22) id <AA06258>; Thu, 14 Sep 1995 17:27:17 -0700
Received: from aland.bbn.com by BBN.COM id aa00430; 14 Sep 95 20:25 EDT
Received: by aland.bbn.com (8.6.12/3.1.090690-BBN) id RAA21506; Thu, 14 Sep 1995 17:25:27 -0700
Message-Id: <199509150025.RAA21506@aland.bbn.com>
To: rreq@isi.edu
Subject: RFC 1812, section 4.2.2.5
Reply-To: Craig Partridge <craig@aland.bbn.com>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Craig Partridge <craig@aland.bbn.com>
Date: Thu, 14 Sep 95 17:25:26 -0700
X-Orig-Sender: craig@aland.bbn.com

Hi folks:
    
Just checking an interpretation.  Section 4.2.2.5 on Header Checksum
says "a router MUST verify the IP checksum of any packet that is received"
but goes on to say "a router MAY use incremental IP header checksum updating
when the only change to the IP header is the time to live."

As I read the text there are two possible interpretations:

    1.  You must verify the IP checksum even if you use incremental checksum
    updating.

    2.  You can skip verifying the IP checksum if you use incremental checksum
    updating and the only field being changed is the ttl.

I read various related documents and sections of 1812, and I think either
interpretation is valid, though there are hints that interpretation (1) may
have been intended.  I'm obviously very interested in doing (2), because
on a processor I'm looking at, it represents a 25% performance hit to
actually compute and check the checksum on the header.

Thanks!

Craig