Difference between revisions of "RFC1141"

From RFC-Wiki
Line 1: Line 1:
 
 
 
 
 
 
 
Network Working Group                                        T. Mallory
 
Network Working Group                                        T. Mallory
 
Request for Comments: 1141                                  A. Kullberg
 
Request for Comments: 1141                                  A. Kullberg
 
Obsoletes: RFC 1071                                  BBN Communications
 
Obsoletes: RFC 1071                                  BBN Communications
                                                            January 1990
+
                                                        January 1990
  
 
+
          Incremental Updating of the Internet Checksum
            Incremental Updating of the Internet Checksum
 
  
 
Status of this Memo
 
Status of this Memo
  
  This memo correctly describes the incremental update procedure for
+
This memo correctly describes the incremental update procedure for
  use with the standard Internet checksum.  It is intended to replace
+
use with the standard Internet checksum.  It is intended to replace
  the description of Incremental Update in RFC 1071.  This is not a
+
the description of Incremental Update in RFC 1071.  This is not a
  standard but rather, an implementation technique.  Distribution of
+
standard but rather, an implementation technique.  Distribution of
  this memo is unlimited.
+
this memo is unlimited.
  
 
Description
 
Description
  
  In RFC 1071 on pages 4 and 5, there is a description of a method to
+
In RFC 1071 on pages 4 and 5, there is a description of a method to
  update the IP checksum in the IP header without having to completely
+
update the IP checksum in the IP header without having to completely
  recompute the checksum.  In particular, the RFC recommends the
+
recompute the checksum.  In particular, the RFC recommends the
  following equation for computing the update checksum C' from the
+
following equation for computing the update checksum C' from the
  original checksum C, and the old and new values of byte m:
+
original checksum C, and the old and new values of byte m:
  
        C' = C + (-m) + m' = C + (m' - m)
+
      C' = C + (-m) + m' = C + (m' - m)
  
  While the equation above is correct, it is not very useful for
+
While the equation above is correct, it is not very useful for
  incremental updates since the equation above updates the checksum C,
+
incremental updates since the equation above updates the checksum C,
  rather than the 1's complement of the checksum, ~C, which is the
+
rather than the 1's complement of the checksum, ~C, which is the
  value stored in the checksum field.  In addition, it suffers because
+
value stored in the checksum field.  In addition, it suffers because
  the notation does not clearly specify that all arithmetic, including
+
the notation does not clearly specify that all arithmetic, including
  the unary negation, must be performed one's complement, and so is
+
the unary negation, must be performed one's complement, and so is
  difficult to use to build working code.  The useful calculation for
+
difficult to use to build working code.  The useful calculation for
  2's complement machines is:
+
2's complement machines is:
  
        ~C' = ~(C + (-m) + m') = ~C + (m - m') = ~C + m + ~m'
+
      ~C' = ~(C + (-m) + m') = ~C + (m - m') = ~C + m + ~m'
  
  In the oft-mentioned case of updating the IP TTL field, subtracting
+
In the oft-mentioned case of updating the IP TTL field, subtracting
  one from the TTL means ADDING 1 or 256 as appropriate to the checksum
+
one from the TTL means ADDING 1 or 256 as appropriate to the checksum
  field in the packet, using one's complement addition.  One big-endian
+
field in the packet, using one's complement addition.  One big-endian
  non-portable implementation in C looks like:
+
non-portable implementation in C looks like:
  
      unsigned long sum;
+
  unsigned long sum;
      ipptr->ttl--;                  /* decrement ttl */
+
  ipptr->ttl--;                  /* decrement ttl */
      sum = ipptr->Checksum + 0x100;  /* increment checksum high byte*/
+
  sum = ipptr->Checksum + 0x100;  /* increment checksum high byte*/
      ipptr->Checksum = (sum + (sum>>16)) /* add carry */
+
  ipptr->Checksum = (sum + (sum>>16)) /* add carry */
  
  This special case can be optimized in many ways: for instance, you
+
This special case can be optimized in many ways: for instance, you
  
 +
can bundle updating and checking the ttl.  Compiler mileage may vary.
 +
Here is a more general and possibly more helpful example which
 +
updates the ttl by n seconds:
  
 +
  UpdateTTL(iph,n)
 +
  struct ip_hdr *ipptr;
 +
  unsigned char n;
 +
  {
 +
      unsigned long sum;
 +
      unsigned short old;
  
Mallory & Kullberg                                              [Page 1]
+
      old = ntohs(*(unsigned short *)&ipptr->ttl);
 
+
      ipptr->ttl -= n;
RFC 1141                  Incremental Updating              January 1990
+
      sum = old + (~ntohs(*(unsigned short *)&ipptr->ttl) & 0xffff);
 
+
      sum += ntohs(ipptr->Checksum);
 
+
      sum = (sum & 0xffff) + (sum>>16);
  can bundle updating and checking the ttl.  Compiler mileage may vary.
+
      ipptr->Checksum = htons(sum + (sum>>16));
  Here is a more general and possibly more helpful example which
+
  }
  updates the ttl by n seconds:
 
 
 
      UpdateTTL(iph,n)
 
      struct ip_hdr *ipptr;
 
      unsigned char n;
 
      {
 
          unsigned long sum;
 
          unsigned short old;
 
 
 
          old = ntohs(*(unsigned short *)&ipptr->ttl);
 
          ipptr->ttl -= n;
 
          sum = old + (~ntohs(*(unsigned short *)&ipptr->ttl) & 0xffff);
 
          sum += ntohs(ipptr->Checksum);
 
          sum = (sum & 0xffff) + (sum>>16);
 
          ipptr->Checksum = htons(sum + (sum>>16));
 
      }
 
  
 
Security Considerations
 
Security Considerations
  
  Security issues are not addressed in this memo.
+
Security issues are not addressed in this memo.
  
 
Authors' Addresses
 
Authors' Addresses
  
  Tracy Mallory
+
Tracy Mallory
  BBN Communications Corporation
+
BBN Communications Corporation
  50 Moulton Street
+
50 Moulton Street
  Cambridge, MA 02238
+
Cambridge, MA 02238
 
 
  Phone: (617) 873-3193
 
 
 
 
 
 
 
 
  A. Kullberg
 
  BBN Communications Corporation
 
  50 Moulton Street
 
  Cambridge, MA 02238
 
 
 
  Phone: (617) 873-4000
 
 
 
  EMail:  [email protected]
 
 
 
 
 
 
 
  
 +
Phone: (617) 873-3193
  
 +
  
 +
A. Kullberg
 +
BBN Communications Corporation
 +
50 Moulton Street
 +
Cambridge, MA 02238
  
 +
Phone: (617) 873-4000
  
Mallory & Kullberg                                              [Page 2]
+

Revision as of 13:53, 29 September 2020

Network Working Group T. Mallory Request for Comments: 1141 A. Kullberg Obsoletes: RFC 1071 BBN Communications

                                                        January 1990
         Incremental Updating of the Internet Checksum

Status of this Memo

This memo correctly describes the incremental update procedure for use with the standard Internet checksum. It is intended to replace the description of Incremental Update in RFC 1071. This is not a standard but rather, an implementation technique. Distribution of this memo is unlimited.

Description

In RFC 1071 on pages 4 and 5, there is a description of a method to update the IP checksum in the IP header without having to completely recompute the checksum. In particular, the RFC recommends the following equation for computing the update checksum C' from the original checksum C, and the old and new values of byte m:

     C' = C + (-m) + m' = C + (m' - m)

While the equation above is correct, it is not very useful for incremental updates since the equation above updates the checksum C, rather than the 1's complement of the checksum, ~C, which is the value stored in the checksum field. In addition, it suffers because the notation does not clearly specify that all arithmetic, including the unary negation, must be performed one's complement, and so is difficult to use to build working code. The useful calculation for 2's complement machines is:

     ~C' = ~(C + (-m) + m') = ~C + (m - m') = ~C + m + ~m'

In the oft-mentioned case of updating the IP TTL field, subtracting one from the TTL means ADDING 1 or 256 as appropriate to the checksum field in the packet, using one's complement addition. One big-endian non-portable implementation in C looks like:

  unsigned long sum;
  ipptr->ttl--;                  /* decrement ttl */
  sum = ipptr->Checksum + 0x100;  /* increment checksum high byte*/
  ipptr->Checksum = (sum + (sum>>16)) /* add carry */

This special case can be optimized in many ways: for instance, you

can bundle updating and checking the ttl. Compiler mileage may vary. Here is a more general and possibly more helpful example which updates the ttl by n seconds:

  UpdateTTL(iph,n)
  struct ip_hdr *ipptr;
  unsigned char n;
  {
      unsigned long sum;
      unsigned short old;
      old = ntohs(*(unsigned short *)&ipptr->ttl);
      ipptr->ttl -= n;
      sum = old + (~ntohs(*(unsigned short *)&ipptr->ttl) & 0xffff);
      sum += ntohs(ipptr->Checksum);
      sum = (sum & 0xffff) + (sum>>16);
      ipptr->Checksum = htons(sum + (sum>>16));
  }

Security Considerations

Security issues are not addressed in this memo.

Authors' Addresses

Tracy Mallory BBN Communications Corporation 50 Moulton Street Cambridge, MA 02238

Phone: (617) 873-3193

EMail: [email protected]

A. Kullberg BBN Communications Corporation 50 Moulton Street Cambridge, MA 02238

Phone: (617) 873-4000

EMail: [email protected]