On 1 Dec 2006, in the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed) .com>, grocery_stocker wrote:
>The following question stems from the bottom of page 55 in the book
> "Unix Network Programming: The Sockets Networking API" by Stevens,
> Fenner, and Rudoff.
You may also want to look at Stevens' "TCP/IP Illustrated Volume 1 - The
Protocols" for additional material.
>"Older SLIP links often used an MTU of 1006 or 296 bytes"
The question you want to look at is "why?". The MTU is being set for
interactive response. See section 2.10 in the TCP/IP Illustrated book.
>I'm assuming the 296 comes from 2^8 + 20 bytes for the TCP header + 20
> bytes for the IP header. What does the 1006 represent in this case?
The 296 comes from an interactive response of 100-200 msec on a 9600 BPS
serial line. The 1006 is more predicated on a 33.6 modem. Most modern
computers have faster links, and a 56k modem even without data compression
will handle 1500 octet frames (the default in ppp and Ethernet) with ease.
>"The minimum link MTU for IPv4 is 68 bytes."
>
>20 bytes is for the fixed header and 8 bytes is for the fragment
> offset. What about other 40 bytes?
0791 Internet Protocol. J. Postel. September 1981. (Format: TXT=97779
bytes) (Obsoletes RFC0760) (Updated by RFC1349) (Also STD0005)
(Status: STANDARD)
RFC791 section 3.2. page 25
Every internet module must be able to forward a datagram of 68
octets without further fragmentation. This is because an internet
header may be up to 60 octets, and the minimum fragment is 8 octets.
>I did some googling and found the following
>
>http://en.wikipedia.org/wiki/MTU_(networking)
Google is an outstanding tool. While the wikipedia is often very useful,
it's not the authority. For that, you should be reading the RFCs.
>Near the end of the article, they have the following:
Blarg!
>Would these be the options in this case?
In addition to RFC0791 above, you also want to look at RFC0793 and similar.
But in this case, it's RFC791 page 2:
The Options provide for control functions needed or useful in some
situations but unnecessary for the most common communications. The
options include provisions for timestamps, security, and special
routing.
A problem with the RFCs is that there are (literally) thousands of them.
[compton ~]$ zcat rfcs/rfc-index.txt.12.01.06.gz | sed 's/^$/\%/' | tr -d
'\n' | tr '%' '\n' | grep '^[0-9]' | tr -s ' ' | grep -v 'Not Issued' | sed
's/.*Status: //' | tr -d '\)' | sort | uniq -c | column
132 BEST CURRENT PRACTICE 1443 INFORMATIONAL
122 DRAFT STANDARD 1473 PROPOSED STANDARD
265 EXPERIMENTAL 87 STANDARD
200 HISTORIC 909 UNKNOWN
[compton ~]$
A helpful file is
ftp://ftp.isi.edu/in-notes/rfc-index.txt which is updated
frequently. I try to download the file monthly (which is usually more than
adequate). The RFCs themselves are widely available at many mirrors. Use
google to find one near you.
Old guy