Path: senator-bedfellow.mit.edu!dreaderd!not-for-mail

Path: senator-bedfellow.mit.edu!dreaderd!not-for-mail
Message-ID: <internet/tcp-ip/[email protected]>
Supersedes: <internet/tcp-ip/[email protected]>
Expires: 31 May 2004 11:22:46 GMT
X-Last-Updated: 2003/06/08
Organization: none
Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.mac.comm,comp.unix.questions,comp.os.ms-windows.networking.tcp-ip,comp.answers,news.answers
Approved: [email protected]
From: [email protected] (Uri Raz)
Subject: TCP/IP Applications FAQ
Followup-To: comp.protocols.tcp-ip
Summary: This document describes the technical sides of not-so-well documented TCP/IP protocols, such as the r-* services, talk, etc, as well as some utilities, such as ping & traceroute.
Originator: [email protected]
Date: 17 Apr 2004 11:29:02 GMT
Lines: 559
NNTP-Posting-Host: penguin-lust.mit.edu
X-Trace: 1082201342 senator-bedfellow.mit.edu 569 18.181.0.29
Xref: senator-bedfellow.mit.edu comp.protocols.tcp-ip:118104 comp.protocols.tcp-ip.ibmpc:49396 comp.sys.mac.comm:334882 comp.unix.questions:195277 comp.os.ms-windows.networking.tcp-ip:86663 comp.answers:56892 news.answers:270059

Posting-Frequency: Monthly
Copyright: (c) 1998-2001 Uri Raz
Maintainer: Uri Raz <[email protected]>
Last-modified: 14/Nov/2001
Archive-Name: internet/tcp-ip/applications-FAQ
URL: http://www.private.org.il/mini-tcpip.faq.html

**************************************************************************
* *
* If you have any comments, addition suggestions, corrections, etc, *
* to the article itself, please send them to me at the technion. *
* My email address is mailto:[email protected] *
* *
* If you have any questions about TCP/IP in general, which are not *
* directly related to this article, please post them to an appropriate *
* newsgroup, as my time is limited, and as it will serve you better. *
* *
**************************************************************************

0. Introduction.
----------------

This document deals mainly with those protocols of the TCP/IP suit of
protocols which are either undocumented in RFCs, with some treatment
of utilities and not so well documented protocols.

If you're interested in RFCs for well documented protocols, see :

- STD1 : Internet Official Protocols Standards
Describes the state of standardization of protocols
used in the Internet, as determined by the IAB.

- STD2 : Assigned Numbers
A status report on numbers & keywords used in the
Internet Community.

- STD3 : Host Requirements
This document incorporates by reference, amendment,
correction, and supplementation the primary protocol
standards documents relating to hosts.

- STD4 : Gateway Requirements
This document is a formal statement of the requirements
to be met by gateways used in the Internet system.

[STD numbers rather then RFC numbers, as the later get changed with
time, while the first does not. STDs can be found under the following
URL : ftp://venera.isi.edu/in-notes/std/ ]

1. Of ping & traceroute.
------------------------

The ping utility checks whether a host is alive & reachable or not.
This is done by sending an ICMP Echo Request packet to the host, and
waiting for an ICMP Echo Reply from the host.

The traceroute utility works in a different way - UDP packets with
increasing TTL values are sent to the host, with three packets sent
for each TTL value. Each trio of packets 'expire' at a succeeding
router on the path to the host, making the routers reply with an ICMP
Time Exceeded packet, until the host is reached, at which time it replies
with an ICMP Port Unreachable packet.

As UDP packets must be sent to a specific port, traceroute sends the
first packet to port 33434, and increments the port number for each
packet sent. Those increments are done in order to differentiate
between the ICMP packets - the ICMP packets include the offending
packet's headers, and the port number from those headers tells how
far (= how many hops) the packet travelled before expiring.
This number was chosen as UDP ports in that neighbourhood are
probably unused. As those ports might actually be used, a different
start number is usually configurable via an appropriate switch.

Microsoft's TRACERT works a little differently - it sends ICMP Echo Request
packets, rather then UDP packets, and therefore expects the host to reply
with an ICMP Echo Reply packet. The logic behind this change is, by
speculation, that as UDP is commonly filtered, while ICMP is not, so
using ICMP should work most of the time, when UDP might fail.

The catch is that the original ICMP specifications dictated that ICMP
errors should not be sent as replies to ICMP packets, so old routers
would not respond correctly to Microsoft's TRACERT. The spec has since
been revised so that ICMP errors are not sent as replies to ICMP error
packets only, which better solves the problem of errors bouncing back
and forth across the net.

Sample output :
---------------
traceroute to www.ibm.com (204.146.18.33), 30 hops max, 20 byte packets
1 teg.technion.ac.il (132.68.7.254) 1 ms 1 ms 1 ms
2 tau-smds.man.ac.il (128.139.210.16) 6 ms 5 ms 5 ms
3 128.139.198.129 (128.139.198.129) 9 ms 8 ms 10 ms
4 TAU-shiber.route.ibm.net.il (192.115.73.5) 160 ms 57 ms 43 ms
5 *
fe7507.tlv.ibm.net.il (192.116.177.1) 24 ms 15 ms
6 port1br1.pt.uk.ibm.net (152.158.16.1) 266 ms 173 ms 152 ms
7 165.87.220.34 (165.87.220.34) 468 ms 408 ms 422 ms
8 165.87.28.105 (165.87.28.105) 453 ms 446 ms 434 ms
9 colu35-16-br2.oh.us.ibm.net (165.87.35.18) 453 ms
colu35-32-br2.oh.us.ibm.net (165.87.35.34) 514 ms
colu35-16-br2.oh.us.ibm.net (165.87.35.18) 525 ms
10 colu35-64-sf1.oh.us.ibm.net (165.87.35.76) 590 ms 536 ms 489 ms
11 204.146.18.33 (204.146.18.33) 526 ms 465 ms 473 ms

Failure indications are as following :
'*' No response received [= timeout]
'!H' ICMP Host Unreachable indication received in response to query
'!N' ICMP Net Unreachable indication received in response to query
'!' Response from final destination had TTL set to < 1, usually due
to a bug in the TCP/IP stack (code derived from BSD 4.2 & 4.3)
In this case the TTL must be set to twice the number of hops to
the destination, making it look twice as far as it really is.

A possible problem is demonstrated in hop 9 in the above example -
a single hop is replied by different hosts. This might be caused
by either the path being changed while traced or by a router using
multipath routing.

Another possible problem is for a single router to appear in two
consecutive hops. This is caused by routers forwarding packets
with TTL decremented to 0, so instead of generating a TTL exceeded
themselves, the next hop routers do so for them, taking their
place in the output.

A possible surprise would be to see a router with an address which
is, according to RFC1918, reserved to private internets (that is
an address from the blocks 10/8, 172.16/12, 192.168/16). This can
happen when somebody assigns a reserved (unroutable) address to
an internal router, saving himself IP addresses on machines that
need not be accessible to the Internet.

Another possible surprise would be that the round trip to one
router would be larger (even significantly larger) than the
round trip to the next router. This could happen for several
reasons - CPU load on the nearer router might be high causing
a delay in the generation of the ICMP reply, ICMP error generation
might have a low priority on the nearer router, and it's possible
the packet that expired on the nearer router took a different and
more congested route on either way or met temporary congestion
on the same path.

Further info can be found in the experimental RFC1393, written by
G. Malkin on Jan '93.

See also "The Story of the PING Program", written by it's author,
at the following page - http://ftp.arl.mil/~mike/ping.html

[thanx to Barry Margolin, [email protected]]
[corrections and additions based on John T. Moy's OSPF book]
[addition done based on an article by Mr. Sam]

2. Of the [n/y]talk protocol.
-----------------------------

The talk protocol has three dialects - [old] talk, new talk, and ytalk.
The old talk was endianess unaware, so people couldn't talk to each other
between a small-endian machine and a big-endian machine.

Michael P. Hunter is currently working on a draft for an RFC describing
the ntalk protocol. The draft RFC can be found at
http://www.alternic.org/drafts/drafts-h-i/draft-hunter-talk-00.html

Eric Ludlam's GNU Talk page includes an extended talk implementation.
http://www.ultranet.com/~zappo/gtalk.shtml

3. Of the rexec protocol.
-------------------------

The rexec protocol works as following :
1. Client makes TCP connection to REXEC port (512).
2. Client sends TCP port number (decimal ascii, null-terminated)
of stderr port. If the first byte is a NULL, then server
won't make any stderr connection - skip step 3.
3. Server makes TCP connection to client's stderr port
4. Client sends target username (null-terminated).
5. Client sends target password, NULL, remote command, NULL,
and then command's stdin, followed by a FIN.
6. Server sends one null byte (=no error), or a non-null
byte, followed by error message(s).
7. Server sends output of command.
8. Server sends FINs on stdout, stderr connections.

A sample TCPDUMP for an rexec command :
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
14:10:14.73 127.0.0.1.1016 > 127.0.0.1.512: S 0:0(0) win 3000 <mss 1500>
4500 002c e405 0000 4006 98c4 7f00 0001 E..,....@.......
7f00 0001 03f8 0200 4ef4 19bb 0000 0000 ........N.......
6002 0bb8 1f9d 0000 0204 05dc `...........
14:10:14.73 127.0.0.1.512 > 127.0.0.1.1016: S 0:0(0) ack 1 win 3000 <mss 1500>
4500 002c e406 0000 4006 98c3 7f00 0001 E..,....@.......
7f00 0001 0200 03f8 4ef4 19bb 4ef4 19bc ........N...N...
6012 0bb8 b6dc 0000 0204 05dc `...........
14:10:14.73 127.0.0.1.1016 > 127.0.0.1.512: . ack 1 win 3000
4500 0028 e407 0000 4006 98c6 7f00 0001 E..(....@.......
7f00 0001 03f8 0200 4ef4 19bc 4ef4 19bc ........N...N...
5010 0bb8 cec1 0000 P.......
14:10:14.75 127.0.0.1.1016 > 127.0.0.1.512: P 1:6(5) ack 1 win 3000
4500 002d e408 0000 4006 98c0 7f00 0001 E..-....@.......
7f00 0001 03f8 0200 4ef4 19bc 4ef4 19bc ........N...N...
5018 0bb8 6c50 0000 3130 3134 00 P...lP..1014.
14:10:14.82 127.0.0.1.512 > 127.0.0.1.1016: . ack 6 win 2995
4500 0028 e409 0000 4006 98c4 7f00 0001 E..(....@.......
7f00 0001 0200 03f8 4ef4 19bc 4ef4 19c1 ........N...N...
5010 0bb3 cec1 0000 P.......
14:10:15.02 127.0.0.1.1013 > 127.0.0.1.1014: S 0:0(0) win 3000 <mss 1500>
4500 002c e40a 0000 4006 98bf 7f00 0001 E..,....@.......
7f00 0001 03f5 03f6 4ef5 13bb 0000 0000 ........N.......
6002 0bb8 23a9 0000 0204 05dc `...#.......
14:10:15.03 127.0.0.1.1014 > 127.0.0.1.1013: S 0:0(0) ack 1 win 3000 <mss 1500>
4500 002c e40b 0000 4006 98be 7f00 0001 E..,....@.......
7f00 0001 03f6 03f5 4ef5 13bb 4ef5 13bc ........N...N...
6012 0bb8 c0e7 0000 0204 05dc `...........
14:10:15.03 127.0.0.1.1013 > 127.0.0.1.1014: . ack 1 win 3000
4500 0028 e40c 0000 4006 98c1 7f00 0001 E..(....@.......
7f00 0001 03f5 03f6 4ef5 13bc 4ef5 13bc ........N...N...
5010 0bb8 d8cc 0000 P.......
14:10:15.06 127.0.0.1.1016 > 127.0.0.1.512: P 6:12(6) ack 1 win 3000
4500 002e e40d 0000 4006 98ba 7f00 0001 E.......@.......
7f00 0001 03f8 0200 4ef4 19c1 4ef4 19bc ........N...N...
5018 0bb8 8cdd 0000 6161 726f 6e00 P.......aaron.
14:10:15.22 127.0.0.1.512 > 127.0.0.1.1016: . ack 12 win 3000
4500 0028 e40e 0000 4006 98bf 7f00 0001 E..(....@.......
7f00 0001 0200 03f8 4ef4 19bc 4ef4 19c7 ........N...N...
5010 0bb8 ceb6 0000 P.......
14:10:15.22 127.0.0.1.1016 > 127.0.0.1.512: P 12:37(25) ack 1 win 3000
4500 0041 e40f 0000 4006 98a5 7f00 0001 E..A....@.......
7f00 0001 03f8 0200 4ef4 19c7 4ef4 19bc ........N...N...
5018 0bb8 9cb0 0000 XXXX XXXX XXXX XXXX P.......XXXXXXXX
XXXX XX00 5348 4f57 2044 4546 4155 4c54 XXX.SHOW DEFAULT
00 .
14:10:15.42 127.0.0.1.512 > 127.0.0.1.1016: . ack 37 win 3000
4500 0028 e410 0000 4006 98bd 7f00 0001 E..(....@.......
7f00 0001 0200 03f8 4ef4 19bc 4ef4 19e0 ........N...N...
5010 0bb8 ce9d 0000 P.......
14:10:15.56 127.0.0.1.512 > 127.0.0.1.1016: P 1:2(1) ack 37 win 3000
4500 0029 e411 0000 4006 98bb 7f00 0001 E..)....@.......
7f00 0001 0200 03f8 4ef4 19bc 4ef4 19e0 ........N...N...
5018 0bb8 ce94 0000 00 P........
14:10:15.62 127.0.0.1.1016 > 127.0.0.1.512: . ack 2 win 3000
4500 0028 e412 0000 4006 98bb 7f00 0001 E..(....@.......
7f00 0001 03f8 0200 4ef4 19e0 4ef4 19bd ........N...N...
5010 0bb8 ce9c 0000 P.......
14:10:19.24 127.0.0.1.512 > 127.0.0.1.1016: P 2:26(24) ack 37 win 3000
4500 0040 e413 0000 4006 98a2 7f00 0001 E..@....@.......
7f00 0001 0200 03f8 4ef4 19bd 4ef4 19e0 ........N...N...
5018 0bb8 777c 0000 2020 4449 534b 2443 P...w|.. DISK$C
5241 575f 4441 443a 5b41 4152 4f4e 5d0a RAW_DAD:[AARON].
14:10:19.39 127.0.0.1.512 > 127.0.0.1.1016: F 26:26(0) ack 37 win 3000
4500 0028 e414 0000 4006 98b9 7f00 0001 E..(....@.......
7f00 0001 0200 03f8 4ef4 19d5 4ef4 19e0 ........N...N...
5011 0bb8 ce83 0000 P.......
14:10:19.40 127.0.0.1.1016 > 127.0.0.1.512: . ack 27 win 3000
4500 0028 e415 0000 4006 98b8 7f00 0001 E..(....@.......
7f00 0001 03f8 0200 4ef4 19e0 4ef4 19d6 ........N...N...
5010 0bb8 ce83 0000 P.......
14:10:19.44 127.0.0.1.1013 > 127.0.0.1.1014: F 1:1(0) ack 1 win 3000
4500 0028 e416 0000 4006 98b7 7f00 0001 E..(....@.......
7f00 0001 03f5 03f6 4ef5 13bc 4ef5 13bc ........N...N...
5011 0bb8 d8cb 0000 P.......
14:10:19.44 127.0.0.1.1014 > 127.0.0.1.1013: . ack 2 win 3000
4500 0028 e417 0000 4006 98b6 7f00 0001 E..(....@.......
7f00 0001 03f6 03f5 4ef5 13bc 4ef5 13bd ........N...N...
5010 0bb8 d8cb 0000 P.......
14:10:19.45 127.0.0.1.1016 > 127.0.0.1.512: F 37:37(0) ack 27 win 3000
4500 0028 e418 0000 4006 98b5 7f00 0001 E..(....@.......
7f00 0001 03f8 0200 4ef4 19e0 4ef4 19d6 ........N...N...
5011 0bb8 ce82 0000 P.......
14:10:19.45 127.0.0.1.512 > 127.0.0.1.1016: . ack 38 win 3000
4500 0028 e419 0000 4006 98b4 7f00 0001 E..(....@.......
7f00 0001 0200 03f8 4ef4 19d6 4ef4 19e1 ........N...N...
5010 0bb8 ce82 0000 P.......
14:10:19.49 127.0.0.1.1014 > 127.0.0.1.1013: F 1:1(0) ack 2 win 3000
4500 0028 e41a 0000 4006 98b3 7f00 0001 E..(....@.......
7f00 0001 03f6 03f5 4ef5 13bc 4ef5 13bd ........N...N...
5011 0bb8 d8ca 0000 P.......
14:10:19.49 127.0.0.1.1013 > 127.0.0.1.1014: . ack 2 win 3000
4500 0028 e41b 0000 4006 98b2 7f00 0001 E..(....@.......
7f00 0001 03f5 03f6 4ef5 13bd 4ef5 13bd ........N...N...
5010 0bb8 d8ca 0000 P.......

[thanx to Aaron Leonard, [email protected]]

4. Of the rsh protocol.
-----------------------

The rshd listens on TCP port #514. The following info is from the unix
rshd man pages :

"Service Request Protocol

When the rshd daemon receives a service request, it initiates the
following protocol:

1. The rshd daemon checks the source port number for the request.
If the port number is not in the range 0 through 1023, the rshd daemon
terminates the connection.

2. The rshd daemon reads characters from the socket up to a null byte.
The string read is interpreted as an ASCII number (base 10). If this
number is nonzero, the rshd daemon interprets it as the port number
of a secondary stream to be used as standard error. A second connection
is created to the specified port on the client host. The source port
on the local host is in the range 0 through 1023.

3. The rshd daemon uses the source address of the initial connection
request to determine the name of the client host. If the name cannot
be determined, the rshd daemon uses the dotted decimal representation
of the client host's address.

4. The rshd daemon retrieves the following information from the initial
socket:

* A null-terminated string of at most 16 bytes interpreted as
the user name of the user on the client host.

* A null-terminated string of at most 16 bytes interpreted as
the user name to be used on the local server host.

* Another null-terminated string interpreted as a command line
to be passed to a shell on the local server host.

5. The rshd daemon attempts to validate the user using the following steps:

a. The rshd daemon looks up the local user name in the /etc/passwd
file and tries to switch to the home directory (using the chdir
subroutine). If either the lookup or the directory change fails,
the rshd daemon terminates the connection.

b. If the local user ID is a nonzero value, the rshd daemon searches
the /etc/hosts.equiv file to see if the name of the client
workstation is listed. If the client workstation is listed as an
equivalent host, the rshd daemon validates the user.

c. If the $HOME/.rhosts file exists, the rshd daemon tries to
authenticate the user by checking the .rhosts file.

d. If either the $HOME/.rhosts authentication fails or the
client host is not an equivalent host, the rshd daemon
terminates the connection.

6. Once rshd validates the user, the rshd daemon returns a null byte
on the initial connection and passes the command line to the user's
local login shell. The shell then inherits the network connections
established by the rshd daemon."

5. Of the rlogin protocol.
--------------------------

rlogin is standardized - see RFC #1282
http://www.ietf.org/rfc/rfc1282.txt

6. Of the rmt protocol.
-----------------------

The rmt protocol allows manipulation of magnetic tape drives attached
to remote hosts, enabling backups and restores across a network, and
is used by such commands as rdump & rrestore.

The rmt protocol relies on either rexec, rcmd, or rsh - the rmt program
is started via rexec / rcmd / rsh and then interacted with via ASCII
commands and responses.

rmt commands are of the following formats -

A. S\n Return the status of the open device.

B. C<device>\n Close the currently open device.
The <device> parameter is ignored.

C. I<operation>\n<count>\n Performs MTIOCP IOCTL with the
<operation> and <count> parameters.
If the command succeeds, rmt will respond
with <count> as the return code.

This operation are, under AIX, as following :
MTOFFL - rewind & unload tape
MTREW - rewind tape
MTERASE - erase & rewind tape
MTRETEN - retention & rewind tape
MTWEOF - write and EOF record to tape
MTFSF - forward space file
MTRSF - reverse space file
MTFSR - forward space record
MTRSR - reverse space record
MTINSRT - pull tape in from loader
MTEJECT - eject tape out to loader

D. L<offset>\n<whence>\n Moves the tape to a given location.
The move is done as following :
- If <whence> = SEEK_SET, the file pointer
is positioned <offset> bytes from the
start of the file.
- If <whence> = SEEK_CUR, the file pointer
is moved <offset> bytes forward or
backward, according to <whence>'s sign.
- If <whence> = SEEK_END, the file pointer
is moved <offset> after the file's end.
If the command succeeds, rmt will respond with
a code noting the distance of the head from
the start of the file in bytes.
If the command fails, rmt will respond with
a code of -1.

E. O<device>\n<mode>\n Opens the specified device in the specified
mode, with <device> being the device's full
name, and <mode> a numerical parameter.

F. R<count>\n Reads <count> bytes of data from the device.
If the command is successful, rmt will respond
with a code noting the number of bytes read,
and sends the data.
If the command fails, an error code is
returned, without any data.

G. W<count>\n Writes <count> bytes, read from the
connection, to the current device, aborting
if EOF occurs during the write.

rmt responses are of two formats. Successful commands are responded
with "A<code>\n", while unsuccessful commands are responded
with "E<code>\n<error-message>\n".

All numbers (codes, modes, etc) are transfered as ASCII strings representing
decimal numbers with the appropriate numerical values.

[thanx to James Carlson, [email protected]]
[used SunOS & AIX man pages]

7. Of the rhosts file.
----------------------

The rhosts file is used the specify which remote users can use
the privileges of a host's local user account over a network,
used as a very weak authentication for the r-services (it saves
the need to send a password in the clear over the network, relying
on the remote host's IP address and the username the process
claims it belongs to. Should be owned by the local user, and be
set as readable & writable by the user alone)

From the unix rhosts man page :

The format of the $HOME/.rhosts file is:

HostNameField [UserNameField]

When a remote command executes, the local host uses the local /etc/hosts.equiv
file and the $HOME/.rhosts file of the local user account to validate
the remote host and remote user.

Host-Name Field

The .rhosts file supports the following host-name entries:

+ Signifies that any host on the network is trusted.
HostName Signifies that any user logging in from HostName is trusted.
-HostName Signifie that the host is not trusted.
+@NetGroup Signifies that all hosts in the netgroup or no hosts in the
-@NetGroup netgroup, respectively, are trusted.
The @NetGroup parameter is used by NIS for grouping.

User-Name Field

The .rhosts file supports the following user-name entries:

+ Signifies that any user on the network is trusted.
UserName Signifies that the remote user is trusted.
If no username is specified, the remote username
must match the local username.
-UserName Signifies that the remote user is not trusted.
+@NetGroup Signifies that all users in the netgroup or no
-@NetGroup users in the netgroup, respectively, are trusted.
The @NetGroup parameter is used by NIS for grouping.

8. Of the syslog protocol.
--------------------------

And James Carlson <[email protected]> has said :

'No RFC for it; it's a Unix thing. The best document for it, like
most of the Unix-derived protocols, is the BSD implementation (take
a look at lib/libc/gen/syslog.c and usr.sbin/syslogd/syslogd.c).

The format is just ASCII text over UDP messages sent to port 514.
The text has this format:

"<%d>%.15s %s[%d]: %s"

The first integer is the priority level and facility code (see
/usr/include/sys/syslog.h), the first string is the date and time
(ctime()+4), the next string is the process name, the next integer
is the PID, and the final string is the text message.

Syslogd will insert a local date/time if the date code in the
message appears to be missing (if it has an odd format) and will
insert the IP address or DNS name of the sender. It also uses the
priority level along with the syslog.conf file to determine where
the message should be delivered (if at all).'

Syslog is now standartized in RFC #3164
http://www.ietf.org/rfc/rfc3164.txt

9. Of the ICQ protocol.
-----------------------

Magnus Ihse has created a page describing the protocols used by
Mirabilis' ICQ. This is an unofficial page.

http://www.student.nada.kth.se/~d95-mih/icq/

Details of ICQ's API can be downloaded from Mirabilis' web site,
subject to certain terms & conditions.

10. Of the lpd protocol.
------------------------

lpd is described in RFC #1179. This RFC is not a standard, but rather
a description of some implementations at the time. Other vendors have
implemented lpd that dont support some of the details in the RFC and/or
with private extentions.
http://www.ietf.org/rfc/rfc1179.txt

11. Of the IP checksum.
-----------------------

The calculation of IP checksums is explained in RFC #1071,
which is titled "Computing the Internet Checksum", which
includes calculation examples and code examples in C.
http://www.ietf.org/rfc/rfc1071.txt

RFC #1071 is updated by RFC #1624, which is titled
"Computation of the Internet Checksum viaIncremental Update".
http://www.ietf.org/rfc/rfc1624.txt

Other relevant RFCs are :

- RFC #1936, "Implementing the Internet Checksum in Hardware".
http://www.ietf.org/rfc/rfc1936.txt

- RFC #1145, RFC #1146, "TCP Alternate Checksum Options".
http://www.ietf.org/rfc/rfc1145.txt
http://www.ietf.org/rfc/rfc1146.txt

- RFC #1141, "Incremental Updating of the Internet Checksum".
http://www.ietf.org/rfc/rfc1141.txt