Difference between revisions of "RFC1141"

From RFC-Wiki
imported>Admin
(Created page with " Network Working Group T. Mallory Request for Comments: 1141 A. Kullberg Obsoletes: [[RFC1071|RF...")
 
Line 7: Line 7:
 
Network Working Group                                        T. Mallory
 
Network Working Group                                        T. Mallory
 
Request for Comments: 1141                                  A. Kullberg
 
Request for Comments: 1141                                  A. Kullberg
Obsoletes: [[RFC1071|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 [[RFC1071|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 [[RFC1071|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
  
  
  
 +
Mallory & Kullberg                                              [Page 1]
  
 +
RFC 1141                  Incremental Updating              January 1990
  
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)
+
   can bundle updating and checking the ttl.  Compiler mileage may vary.
   struct ip_hdr *ipptr;
+
   Here is a more general and possibly more helpful example which
   unsigned char n;
+
   updates the ttl by n seconds:
  {
 
      unsigned long sum;
 
      unsigned short old;
 
  
      old = ntohs(*(unsigned short *)&ipptr->ttl);
+
      UpdateTTL(iph,n)
      ipptr->ttl -= n;
+
      struct ip_hdr *ipptr;
      sum = old + (~ntohs(*(unsigned short *)&ipptr->ttl) & 0xffff);
+
      unsigned char n;
      sum += ntohs(ipptr->Checksum);
+
      {
      sum = (sum & 0xffff) + (sum>>16);
+
          unsigned long sum;
      ipptr->Checksum = htons(sum + (sum>>16));
+
          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 22:54, 22 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


Mallory & Kullberg [Page 1]

RFC 1141 Incremental Updating January 1990


  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]





Mallory & Kullberg [Page 2]