Internet Core Protocols: The Definitive Guide by Eric A. Hall This errata page lists errors outstanding in the most recent printing. If you have technical questions or error reports, you can send them to booktech@oreilly.com. Please specify the printing date of your copy. This page was last modified on February 23, 2004. Here's a key to the markup: [page-number]: serious technical mistake {page-number}: minor technical mistake : important language/formatting problem (page-number): language change or minor formatting problem ?page-number?: reader question or request for clarification CONFIRMED errors: {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) {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. {233} Figure 5-32 does not represent the last ECHO Request sent. The sequence number should be 512, not 0. {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". {308} Figure 7-12 is in error. <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 possible 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. <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. <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. <390> Figure 7-48 has the same error. <407-416> Appendix B has been revised. You can find the new version online at: http://www.oreilly.com/catalog/9781565925724/chapter/appb.html. <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.