referring to fig1 a communication system 10 comprises a correspondent 12 such as a cell phone , pager , or pda , connected to a public network 18 such as the internet . typically , the correspondent wishes to connect to a virtual private network ( vpn ) using the internet . to it connect to a site on the vpn , the correspondent must obtain the ip address of the recipient from a domain name server ( dns ). in doing so , the correspondent 12 sends a request for an ip address indicating the destination address as that of the dns , but after a secure channel has been obtained , the destination address is changed to that of the vpn dns . this redirects a request originally intended for the dns to a request to the vpn dns . the correspondent 12 includes a processor 14 suitable for computing error detecting codes and is connected to the network 18 through a network enabler 16 which processes communications between the correspondent 12 and the network 18 to redirect a transmission as outlined above . communications over the network take the form of packets of a certain length . each packet 20 comprises a number of fields 23 of a certain length , typically 8 bits for internet protocols . referring to fig2 a packet 20 includes a set of fields 23 comprising a header portion 21 and a set of fields 23 comprising a data portion 22 , each field comprising an 8 bit segment . the header 21 includes a field 26 containing a value m identifying the intended recipient , and a 16 - bit header checksum ( hc ) 24 computed from the information in the header 21 including the field 26 and the data 22 . the network enabler 16 changes the packet 20 of fig2 into the modified packet 30 of fig3 . this modified packet 30 comprises the data 22 from the packet 20 and a modified header 32 . the modified header is obtained by replacing the value m in field 26 with the new value m ′ in the field 36 . as a result of this modification , the network enabler 16 also inserts a modified checksum hc ′ 34 into the packet 30 . referring to fig4 a method 100 of modifying the 16 - bit checksum hc 24 into the modified 16 - bit checksum hc ′ 34 when the value m is changed to the value m ′ is shown . first , the 16 - bit checksum hc is xored 102 with the 16 - bit hexadecimal value 0xffff , which is the all ones bit string , to obtain hc1 , the one &# 39 ; s complement of hc . a difference diff is computed 104 from the new value m ′ and the old value m by standard two &# 39 ; s complement subtraction , which sets a first carry flag 106 if the result is negative . to obtain the one &# 39 ; s complement difference of m ′ and m , the difference diff is decremented by one , as indicated at 110 , if the carry flag is set 108 , otherwise its value is left unchanged . an intermediate checksum hc2 is then computed 112 from hc1 and diff as hc2 = hc1 + diff , setting a second carry flag 114 if the two &# 39 ; s complement sum overflows 16 bits . to obtain the one &# 39 ; s complement intermediate checksum , the intermediate checksum hc2 is then incremented 118 if the second carry flag is set 116 , otherwise it is left unchanged . then the updated checksum hc ′ is computed by xoring 120 the one &# 39 ; s complement intermediate checksum hc2 with 0xffff to obtain its one &# 39 ; s complement . the updated checksum hc ′ is then placed in the new packet 30 and the new packet 30 is sent in place of the old packet 20 . once the enabler 16 has changed the packet and inserted a correct checksum , it simply sends the packet out to the internet as usual . assuming there are no errors introduced in transmission , the recipient will check the checksum and accept the new packet as undamaged since the checksum corresponds to the packet contents . it is recognized that the method may be used when any field in a packet is changed . typically , fields in the header will be changed , and more usually one specific field will be changed for a particular application . this field may be the destination address as described above in the preferred embodiment , or alternatively any field in the header , or still alternatively any field in a packet . fields may be changed by a network enabler as described in the preferred embodiment , or by any device that processes the packet . these devices may include for example a driver , an interface , or a router . referring to fig5 an alternate embodiment for computing incremental checksums is shown . in this embodiment , the value m is changed to the new value m ′ for each of a plurality of packets 200 , 210 . . . 2 n 0 . this could be the situation when the network enabler must redirect packets intended for one fixed address to another fixed address . in that case , the values m and m ′ are predetermined and pre - computation may be used . packet 200 comprises a checksum 202 on , a header containing the value m in the field 204 and a first set of data 206 . a second packet 210 contains the same value m in the field 214 , a second set of data 216 , with a second checksum 212 computed on the value m in the field 214 and the second set of data 216 . each of the packets are of similar form , with a final packet 2 n 0 including the same value m in the field 2 n 4 , a final set of data 2 n 6 , and a checksum 2 n 2 thereupon . the network enabler will process these packets to provide the packets of fig6 . referring therefore to fig6 packets 300 and 310 through 3 n 0 correspond to the packets of fig5 after being changed . each packet contains the data 206 , 216 , 2 n 6 from its corresponding packet , the new value m ′ in the field 304 , 314 , 3 n 4 and a corresponding checksum 302 , 312 , 3 n 2 . the packets of fig6 are obtained from the packets of fig5 by the method of fig7 and 8 . where the network enabler knows that the value m will be changed to the new value m ′ it may precompute the change as shown in fig7 . first , it computes diff 404 as the integer difference between m ′ and m , setting a carry flag 406 when the difference is negative . when the carry flag is set 408 , the network enabler decrements diff by 1 410 , otherwise it leaves diff unchanged . the value of diff is stored for future use in the method of fig8 . referring therefore to fig8 a packet of the general form of fig5 is modified to a packet of the general form of fig6 by the steps 500 . first , the 16 - bit checksum hc is xored 502 with the 16 - bit hexadecimal value 0xffff , which is the all ones bit string , to obtain hc1 , the one &# 39 ; s complement of hc . the precomputed value diff is obtained 511 from storage . an intermediate checksum hc2 is then computed 112 from hc1 and diff , as hc2 = hc1 + diff , setting a second carry flag 514 if the two &# 39 ; s complement sum overflows 16 bits . to obtain the one &# 39 ; s complement intermediate checksum , the intermediate checksum hc2 is then incremented 518 if the second carry flag is set 516 , otherwise it is left unchanged . then the new checksum hc ′ is computed by xoring the one &# 39 ; s complement intermediate checksum hc2 with 0xffff 520 to obtain its one &# 39 ; s complement . the new checksum hc ′ is then placed in the new packet 30 and the new packet 30 is sent in place of the old packet 20 . accordingly , the internet checksum may be incrementally updated using the carry flag of the processor to implement addition and subtraction . in the case of subtraction , the carry flag may be indicated by the most significant bit of the difference . further , a difference may be precomputed when many different packets are changed in the same way . each of the above techniques may be used in all of the situations contemplated to provide an accurate , updated checksum without reprocessing of the entire packet .