Errata

by the router symbol in P-2.

SMTP is defined as "Simple Mail Transfer Protocol"
now reads: "Simple Message Transfer Protocol"

"Web browser" now reads "mail agent"

the entries in the right-hand column that did read:
192.168.10.1 (local Ethernet interface)
now read:
192.168.10.3 (local Ethernet interface)

The titles were also changed to reflect this.

Reassembly," "16-megabit Token Ring" NOW READS:
"16-Mb/s Token Ring."

"16-Mb/s Token Ring" and "4 MBs Token Ring" NOW READS "4-Mb/s Token Ring".

by the router symbol in P-2.

Some of the numeric values in Table 2-9 are indeed inverted. This was clarified in RFC 1349.

The values in Table 2-9 should read as follows:

0 - Normal (same as it exists)
1 - Minimize Cost
2 - Maximize Reliability
4 - Maximize Throughput
8 - Minimize Delay
15 - Maximize Security (same as it exists)

the rows RE-ARRANGED so that the order and values are as follows:

Value Service
____________________________
0 Normal
1 Minimize Cost
2 Maximize Reliability
4 Maximize Throughput
8 Minimize Delay

The descriptive text associated with the labels remain the same, but have been RE-ORDERED
according to the replacement list above.

"2 | Internet Group Message Protocol (IGMP)"

NOW READS:
"2 | Internet Group Management Protocol (IGMP)"

"ARP packets work at the data-link layer, the same as IP packets."

NOW READS:
"ARP packets communicate with the data-link layer directly, the same as IP packets."

addition, all IGMPv2 messages must use the Router Alert Option in
the header of the IP datagram."

"must" was changed to "should", and the following text was added:

"according to RFC 2236, although many implementations do
not follow this suggestion."

Membership Query message..."

The following text was added:

"Note that this IP packet does not have the Router Alert Option, as
suggested by RFC 2236 for IGMPv2 messages."

by the router symbol in P-2.

by the router symbol in P-2.

by the router symbol in P-2.

replaced with "port "1112." Note that there were separate occurrances
of this error in the last two paragraphs.

an ICMP query message. The changes are as follows:

The line above the horizontal scroll bar now reads:

000000 102 Krill Greywolf ICMP Echo Req ID=49153 SN=0

The Internet Protocol section now reads:

...
Total Packet Length 84 bytes
Packet Id 1577
...
Time to Live 64 seconds/hops
...
Checksum 0xDEC1 (Correct)
Source Address Greywolf
Destination Address Krill
No IP Options
64 bytes of data

The Internet Control Message Protocol section now reads:

Type 8 (Echo Request)
Code 0
Checksum 0x8907 (Correct)
Id 49153
Sequence 0
[56 byte(s) of data]

The hex values have also changed.

The last sentence under the heading "Capture Sample" on page 221 states the
the Identifier, Sequence Number, and Optional Data fields are the same in the
echo request and echo reply shown in Figure 5-26.

However, the data presented in Figure 5-26 on page 222 shows the value "0" for
the sequence in the echo request, but the value "512" for the sequence in the
echo response.

sequence number should be 512, not 0.

At the end of the line above the first horizontal scroll bar, "SN=0" was
changed to "SN=512".

The Internet Control Message Protocol section now reads:

...
Checksum 0xB318
...
Sequence 512
[56 byte(s) of data]

The hex values in this figure have also changed.

desk port 80". That should be "destination " not "desk port".

They NOW READ:

20 File Transfer Protocol, Data Channel (FTP-Data)
21 File Transfer Protocol, Control Channel (FTP)

"MTU/MRU for Ethernet networks is only 1.5 kilobytes."

NOW READS:
"MTU/MRU for Ethernet networks is only 1500 bytes."

"capable of supporting MTU sizes of 1.5 kilobytes would use..."

NOW READS:
"capable of supporting MTU sizes of 1500 bytes would use..."

NOW READ "1500 byte."

"the Discard server's well-known port"

NOW READS:
"the Echo server's well-known port"

"This allows the acknowledgment to the shutdown request to be trackedindependently of the request itself."

NOW READS:
"Since the acknowledgement is a zero-length command segment, it is using the sequence number for the
next byte of data that it would normally send (although it won't be sending any more data)."

"the Chargen server on Greywolf immediately starts sending data to the Chargen client on Arachnid."

NOW READS:
"the Chargen server on Arachnid immediately starts sending data to the Chargen client on Greywolf."

"Although Greywolf cannot currently accept any data, it will be able to send a shutdown message,
which Greywolf must be able to accept."

NOW READS:
"Although Greywolf cannot currently accept any data, it will be able to send a shutdown message."

occurrences of "MB/s" NOW READ "Mb/s".

Table 7-11. Possible Window sizes, based on the maximum number of
bits in flight and the available MTU

Bits-per-Second Latency Bits Bytes MTU Window

19.2 kb/s (modem) .060 sec. 1,180 148 1460 * 4 5,840
19.2 kb/s (modem) .120 2,360 295 1460 * 4 5,840
53 kb/s (modem) .060 3,257 408 1460 * 4 5,840
53 kb/s (modem) .120 6,513 815 1460 * 4 5,840
64 kb/s (satellite) .200 13,108 1,639 536 * 4 2,144
(fast)
64 kb/s (satellite) .400 26,215 3,277 536 * 8 4,288
(normal)
384 kb/s (DSL) .060 23,593 2,950 1468 * 4 5,840
384 kb/s (DSL) .120 47,186 5,899 1460 * 6 8,760
1.5 mb/s (T-1) .060 94,372 11,797 1460 * 10 14,600
1.5 mb/s (T-1) .120 188,744 23,593 1460 * 18 26,280
10 mb/s (Ethernet) .002 20,972 2,622 1024 * 4 4,192
(local)
10 mb/s (Ethernet) .010 104,858 13,108 1460 * 10 14,600
(multi-hop)
100 mb/s (Ethernet) .002 209,716 26,215 1460 * 18 26,280
(local)
100 mb/s (Ethernet) .010 1,048,577 131,073 1460 * 90 131,400
(multi-hop)

occurrences of "MB/s" NOW READ "Mb/s".