Internet Core Protocols: The Definitive Guide

Errata for Internet Core Protocols: The Definitive Guide

Submit your own errata for this product.


The errata list is a list of errors and their corrections that were found after the product was released. If the error was corrected in a later version or reprint the date of the correction will be displayed in the column titled "Date Corrected".

The following errata were submitted by our customers and approved as valid errors by the author or editor.

Color Key: Serious Technical Mistake Minor Technical Mistake Language or formatting error Typo Question Note Update



Version Location Description Submitted By Date Submitted Date Corrected
Printed
Page xvi
The symbol used to represent a router in figure P-1 was replaced

by the router symbol in P-2.

Anonymous    May 01, 2000
Printed
Page 11
under TCP/IP Protocols and Services In-Depth:

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

Anonymous    Mar 01, 2000
Printed
Page 12
Fig 1-6

"Web browser" now reads "mail agent"

Anonymous    Mar 01, 2000
Printed
Page 14
At the end of the 1st paragraph

00:00:c0:c8:b2:27 NOW READS: 00:00:c0:c8:b3:27

Anonymous    Feb 01, 2004
Printed
Page 38
Tables 2-1 through 2-4,

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.

Anonymous    Mar 01, 2000
Printed
Page 40

In the first paragraph, the sentence that read: "neither of these protocols work well enough to support a significant number of networks," now reads: "neither of these protocols works well enough..."

Anonymous    May 01, 2000
Printed
Page 41

The paragraph above the heading "Datagram Independence" previously read: For more information about hierarchical routing, refer to "Classless Inter-Domain Routing (CIDR)" in Appendix B, IP Addressing Fundamentals. NOW READS: For more information about hierarchical routing, refer to "Subnet Masks and CIDR Networks" in Appendix B, IP Addressing Fundamentals.

Anonymous    Feb 01, 2004
Printed
Page 45
In the end of the first paragraph under the heading "Fragmentation and

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

Anonymous    Feb 01, 2004
Printed
Page 45-46
In the first column of Table 2-5, "16 MB/s Token Ring" NOW READS

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

Anonymous    Feb 01, 2004
Printed
Page 47
The symbol used to represent a router in figure 2-7 was replaced

by the router symbol in P-2.

Anonymous    May 01, 2000
Printed
Page 52
In the last paragraph, change "256 KB/s" NOW READS "256 Kb/s."

Anonymous    Feb 01, 2004
Printed
Page 54
Table 2-9

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)

Anonymous    Apr 05, 2007
Printed
Page 54-55
Values in Table 2-9 were inverted. The numbers HAVE BEEN CHANGED and

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.

Anonymous    Feb 01, 2004
Printed
Page 71
Table 2-12

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

Anonymous    Feb 01, 2004
Printed
Page 89
In the first paragraph under "Notes on Fragmentation," "16 MB/s" NOW READS "16 Mb/s".

Anonymous    Feb 01, 2004
Printed
Page 98
The first sentence of the sixth paragraph

"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."

Anonymous    Feb 01, 2004
Printed
Page 129
In the last paragraph, the sentence that read:

"one of the biggest problems that come from devices that maintain..." now reads: "one of the biggest problems that comes from devices...".

Anonymous    May 01, 2000
Printed
Page 151
In the last paragraph of p. 151, the author stated, "In

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."

Anonymous    May 01, 2000
Printed
Page 152
The first paragraph on p. 152 stated, "Figure 4-6 shows an IGMPv2

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."

Anonymous    May 01, 2000
Printed
Page 180
The symbol used to represent a router in figure 5-3 was replaced

by the router symbol in P-2.

Anonymous    May 01, 2000
Printed
Page 184-185
The following text NOW REPLACES the previously existing paragraph under the

heading "Redirect for Destination Network": This message is used when all traffic for the destination network should go through another router. This has historically been the most common form of the Redirect error message on networks that rely on Router Discovery for dynamic routing. However, this particular message was deprecated by RFC 1812, which mandated that network- wide redirect messages not be sent.

Anonymous    Feb 01, 2004
Printed
Page 185
The symbol used to represent a router in figure 5-5 was replaced

by the router symbol in P-2.

Anonymous    May 01, 2000
Printed
Page 185
The following sentence HAS BEEN ADDED to the end of the description for "Redirect for

Destination Network Based on Type-of-Service": "This message was also deprecated by RFC 1812."

Anonymous    Feb 01, 2004
Printed
Page 190
The symbol used to represent a router in figure 5-7 was replaced

by the router symbol in P-2.

Anonymous    May 01, 2000
Printed
Page 196
The last sentence in the 2nd paragraph:

"Note that RFC 1122 states that if a system receives an ICMP message with type or code that it does not understand, it must ignore the message." NOW READS: "Note that RFC 1122 states that if a system receives an ICMP message with an unknown type, it must ignore the message. Systems that implement a specific message type are expected to implement all of the codes for that type."

Anonymous    Feb 01, 2004
Printed
Page 204
The two occurances of port "1051" on page 204 were

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

Anonymous    May 01, 2000
Printed
Page 210
Table 5-6:. The phrase "(deprecated)" HAS BEEN ADDED to the end of the sentences

describing Code 0 and Code 2.

Anonymous    Feb 01, 2004
Printed
Page 215
Figure 5-21 showed a an ICMP error message when it was supposed to show

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.

Anonymous    May 01, 2000
Printed
Page 220
The "Additional Fields" entry just above Table 5-12:

"Both the Echo Request and Echo Reply query messages use four additional fields." NOW READS: "...three additional fields."

Anonymous    Feb 01, 2004
Printed
Page 221-222
Last sentence under "Capture Sample" & Fig 5-26

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.

Anonymous    Apr 05, 2007
Printed
Page 233
Figure 5-32 does not represent the last ECHO Request sent. The

sequence number should be 512, not 0.

Anonymous    Apr 05, 2007
Printed
Page 233
Figure 5-32 was changed as follows

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.

Anonymous    May 01, 2000
Printed
Page 275
There is an error in Figure 7-3, which shows "TCP:src port xxxx,

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

Anonymous    Apr 05, 2007
Printed
Page 278
In Table 7-1, the descriptions for ports 20 and 21 were backwards.

They NOW READ: 20 File Transfer Protocol, Data Channel (FTP-Data) 21 File Transfer Protocol, Control Channel (FTP)

Anonymous    Feb 01, 2004
Printed
Page 290
In the 2nd paragraph under "MTU and MRU Size Considerations,":

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

Anonymous    Feb 01, 2004
Printed
Page 292
In the last sentence of the 2nd paragraph above "Path MTU Discovery,"

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

Anonymous    Feb 01, 2004
Printed
Page 293
In the first full paragraph on the page, the two occurrances of "1.5 kilobyte"

NOW READ "1500 byte."

Anonymous    Feb 01, 2004
Printed
Page 299
In the 4th line of the first full paragraph, "kilo398byte" NOW READS "kilobyte."

Anonymous    Feb 01, 2004
Printed
Page 308
Figure 7-12 is in error.

Anonymous   
Printed
Page 309
The second sentence in the second paragraph under the Congestion Avoidance heading

"As such, RFC 1112 states that..." NOW READS: "As such, RFC 1122 states that..."

Anonymous    Feb 01, 2004
Printed
Page 350
Change this text

Also, note that some systems do not take into consideration any extra IP Options or TCP Options which would reduce the maximum segment size being advertised, and only subtract 40 bytes from the MTU when sending this option. This may or may not cause problems down the road, depending on the options that are being used on that circuit. For example, if the first segment only has this option defined, then none of the remaining segments will have any extra TCP Options (so TCP does not need to leave room for any additional TCP Options). However, if the systems agree to use the TCP Timestamp Option and the Selective Acknowledgments Option, then it is very likely that some segments will have those options, so the advertised value should leave room for the extra space. Otherwise, later segments may end up being larger than the maximum size advertised, and thus will be fragmented. To this text: Also, note that the MSS option only applies to the larget <i>possible</i> segment size that can be processed. As such, reserving a fixed 40-byte overhead is generally accepted as the proper method for representing this value, since this value would represent the maximum size of a single segment if no other factors came into play. The actual segment sizes that will be used on a connection may not be anywhere as large as the segment size advertised in the MSS option. For example, two systems may agree to use a variety of other TCP options (such as Timestamp, Window Scale, Selective Acknowledgments and more), and the TCP end-points will have to leave room in the TCP segments for this extra header data. Similarly, Path MTU Discovery may indicate that the intermediary link between two Ethernet networks is only capable of handling 1024 bytes, and the TCP end-points would have to deal with this as well when they were generating segments. For all of these reasons, the MSS option is mostly used to indicate the "maximum possible segment size," which may be reduced significantly.

Anonymous    Nov 15, 2013
Printed
Page 369
Please add the following paragraph to entry #4, in between the two

existing paragraphs: This can be somewhat confusing so some clarification is in order. Remember that command segments which do not contain any data always use a sequence number that points to the next byte of data that will be sent, so Arachnid used that value for frame three above. However, Arachnid never did send that byte of data. Meanwhile, Arachnid also has to increment the sequence number by one for the shutdown segment, which just so happens to be the same value as was used by the command segment sent in frame three above. In this particular scenario, the command segment and the shutdown segment are using the same sequence number, but for different purposes.

Anonymous   
Printed
Page 370
Item 1 under "Interactive Data Exchange"

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

Anonymous    Feb 01, 2004
Printed
Page 370
The last sentence of the first paragraph in item 7:

"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)."

Anonymous    Feb 01, 2004
Printed
Page 374
The first sentence in item 2

"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."

Anonymous    Feb 01, 2004
Printed
Page 377
The next-to-last sentence in item 26:

"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."

Anonymous    Feb 01, 2004
Printed
Page 380
In the last paragraph, both occurrences of "100 MB/s" NOW READ "100 Mb/s".

Anonymous    Feb 01, 2004
Printed
Page 381
In the Note, "19.2 KB/s" NOW READS "19.2 Kb/s" and "1.5 MB/s" NOW READS "1.5 Mb/s".

Anonymous    Feb 01, 2004
Printed
Page 381
In the paragraph below the Note, "19.2 KB/s" NOW READS "19.2 Kb/s".

Anonymous    Feb 01, 2004
Printed
Page 381-382
In Table 7-10, all occurrences of "KB/s" NOW READ "Kb/s" and all

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

Anonymous    Feb 01, 2004
Printed
Page 382
In the first paragraph, "19.2 KB/s" NOW READS "19.2 Kb/s".

Anonymous    Feb 01, 2004
Printed
Page 382
In the second paragraph, "100 mb/s" NOW READS "100Mb/s" and "10 MB/s" NOW READS "10 Mb/s".

Anonymous    Feb 01, 2004
Printed
Page 382
In the third paragraph, "19.2 KB/s" NOW READS "19.2 Kb/s" and "10 MB/s" NOW READS "10 Mb/s".

Anonymous    Feb 01, 2004
Printed
Page 384
Table 7-11 was changed to the following

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)

Anonymous    May 01, 2000
Printed
Page 384
In Table 7-11, all occurrences of "KB/s" NOW READ "Kb/s" and all

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

Anonymous    Feb 01, 2004
Printed
Page 384
In the paragraph under Table 7-11, "100 MB/s" NOW READS "100Mb/s".

Anonymous    Feb 01, 2004
Printed
Page 388
The fifth paragraph down, beginning:

"The HTTP problem is illustrated in Figure 7-47. In that example, the HTTP client is sending 1500 bytes of data to the HTTP server, but because the client is using the Nagle algorithm, the sixty bytes of overflow data are delayed until the first segment has been acknowledged." NOW READS: "The HTTP problem is illustrated in Figure 7-47. In that example, the HTTP client is sending 1500 bytes of data to the HTTP server, but because the client is using the Nagle algorithm, the forty bytes of overflow data are delayed until the first segment has been acknowledged."

Anonymous    Feb 01, 2004
Printed
Page 389
Figure 7-47 shows 1460 bytes in the first segment, followed by 60

additional bytes in the next segment (number "3"). The latter element should be "40 bytes" since 1500-1460=40, not 60.

Anonymous    Nov 15, 2013
Printed
Page 390
Figure 7-48 has the same error.

Anonymous    Nov 15, 2013
Printed
Page 407-416
Appendix B has been revised. You can find the new version online at

http://www.oreilly.com/catalog/9781565925724/chapter/appb.html.

Anonymous   
Printed
Page 417
A note should be added to the description of Surveyor Lite indicating

that readers should either use the help file from the 15 day trial version or contact the O'Reilly support desk to obtain a copy of the help file.

Anonymous