Tcpip Network Administration 3rd Edition 3rd Edition Craig Hunt

Tcpip Network Administration 3rd Edition 3rd
Edition Craig Hunt download
https://ebookbell.com/product/tcpip-network-administration-3rd-
edition-3rd-edition-craig-hunt-2112678
Explore and download more ebooks at ebookbell.com

Here are some recommended products that we believe you will be
interested in. You can click the link to download.
Tcpip Network Administration 3rd Edition 3rd Edition Craig Hunt
https://ebookbell.com/product/tcpip-network-administration-3rd-
edition-3rd-edition-craig-hunt-43767068
The Illustrated Network How Tcpip Works In A Modern Network 2nd
Edition Walter Goralski
https://ebookbell.com/product/the-illustrated-network-how-tcpip-works-
in-a-modern-network-2nd-edition-walter-goralski-35189934
The Illustrated Network How Tcpip Works In A Modern Network 2017th
Edition Walter Goralski
in-a-modern-network-2017th-edition-walter-goralski-60442588
The Illustrated Network How Tcpip Works In A Modern Network Goralski
in-a-modern-network-goralski-230208286

Practical Tcpip Designing Using And Troubleshooting Tcpip Networks On
Linux R And Windows Niall Mansfield
https://ebookbell.com/product/practical-tcpip-designing-using-and-
troubleshooting-tcpip-networks-on-linux-r-and-windows-niall-
mansfield-1619922
End To End Adaptive Congestion Control In Tcpip Networks Houmkozlis
https://ebookbell.com/product/end-to-end-adaptive-congestion-control-
in-tcpip-networks-houmkozlis-4395464
Tcpip Illustrated Vol 1 2nd Ed Kevin R Fall W Richard Stevens
https://ebookbell.com/product/tcpip-illustrated-vol-1-2nd-ed-kevin-r-
fall-w-richard-stevens-47033106
Tcp Ip For Dummies Candace Leiden Marshall Wilensky
https://ebookbell.com/product/tcp-ip-for-dummies-candace-leiden-
marshall-wilensky-47608262
Tcp Ip Essentials A Labbased Approach Shivendra S Panwar Shiwen Mao
https://ebookbell.com/product/tcp-ip-essentials-a-labbased-approach-
shivendra-s-panwar-shiwen-mao-2011448

TCP/IP Network
Administration
THIRD EDITION
Craig Hunt
Beijing • Cambridge • Farnham • Köln • Sebastopol • Taipei • Tokyo

TCP/IP Network Administration, Third Edition
by Craig Hunt
Copyright © 2002, 1998, 1992 Craig Hunt. All rights reserved.
Printed in the United States of America.
Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472.
O’Reilly Media, Inc. books may be purchased for educational, business, or sales promotional use. On-
line editions are also available for most titles (safari.oreilly.com). For more information contact our cor-
porate/institutional sales department: (800) 998-9938 or corporate@oreilly.com.
Editors: Mike Loukides and Debra Cameron
Production Editor: Emily Quill
Cover Designer: Edie Freedman
Interior Designer: Melanie Wang
Printing History:
August 1992: First Edition.
January 1998: Second Edition.
April 2002: Third Edition.
Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of
O’Reilly Media, Inc. TCP/IP Network Administration, Third Edition, the image of a land crab, and
related trade dress are trademarks of O’Reilly Media, Inc. Many of the designations used by
manufacturers and sellers to distinguish their products are claimed as trademarks. Where those
designations appear in this book, and O’Reilly Media, Inc. was aware of a trademark claim, the
designations have been printed in caps or initial caps.
While every precaution has been taken in the preparation of this book, the publisher and author assume
no responsibility for errors or omissions, or for damages resulting from the use of the information
contained herein.
This book uses RepKover™
, a durable and flexible lay-flat binding.
ISBN: 978-0-596-00297-8
[C] [10/08]

—To Alana, the beginning of a new life.

vii
Table of Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
1. Overview of TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
TCP/IP and the Internet 2
A Data Communications Model 6
TCP/IP Protocol Architecture 9
Network Access Layer 11
Internet Layer 12
Transport Layer 18
Application Layer 22
Summary 23
2. Delivering the Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Addressing, Routing, and Multiplexing 24
The IP Address 25
Internet Routing Architecture 35
The Routing Table 37
Address Resolution 43
Protocols, Ports, and Sockets 44
Summary 50
3. Network Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Names and Addresses 51
The Host Table 52
DNS 54
Mail Services 62
File and Print Servers 75
Configuration Servers 76
Summary 82

viii | Table of Contents
4. Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Connected and Non-Connected Networks 85
Basic Information 86
Planning Routing 97
Planning Naming Service 101
Other Services 104
Informing the Users 106
Summary 107
5. Basic Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Kernel Configuration 108
Startup Files 124
The Internet Daemon 129
The Extended Internet Daemon 132
Summary 133
6. Configuring the Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
The ifconfig Command 134
TCP/IP Over a Serial Line 150
Installing PPP 153
Summary 169
7. Configuring Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Common Routing Configurations 170
The Minimal Routing Table 171
Building a Static Routing Table 173
Interior Routing Protocols 178
Exterior Routing Protocols 188
Gateway Routing Daemon 191
Configuring gated 193
Summary 204
8. Configuring DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
BIND: Unix Name Service 205
Configuring the Resolver 207
Configuring named 211
Using nslookup 228
Summary 232

Table of Contents | ix
9. Local Network Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
The Network File System 233
Sharing Unix Printers 252
Using Samba to Share Resources with Windows 259
Network Information Service 268
DHCP 272
Managing Distributed Servers 277
Post Office Servers 280
Summary 283
10. sendmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
sendmail’s Function 285
Running sendmail as a Daemon 286
sendmail Aliases 288
The sendmail.cf File 290
sendmail.cf Configuration Language 297
Rewriting the Mail Address 309
Modifying a sendmail.cf File 319
Testing sendmail.cf 323
Summary 332
11. Configuring Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Installing Apache Software 334
Configuring the Apache Server 338
Understanding an httpd.conf File 341
Web Server Security 361
Managing Your Web Server 378
Summary 380
12. Network Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Security Planning 382
User Authentication 387
Application Security 402
Security Monitoring 404
Access Control 409
Encryption 418
Firewalls 425
Words to the Wise 433
Summary 434

x | Table of Contents
13. Troubleshooting TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
Approaching a Problem 435
Diagnostic Tools 438
Testing Basic Connectivity 440
Troubleshooting Network Access 443
Checking Routing 450
Checking Name Service 456
Analyzing Protocol Problems 471
Protocol Case Study 474
Summary 478
A. PPP Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
B. A gated Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
C. A named Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548
D. A dhcpd Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586
E. A sendmail Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
F. Solaris httpd.conf File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 661
G. RFC Excerpts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687

xi
Preface
The first edition of TCP/IP Network Administration was written in 1992. In the
decade since, many things have changed, yet some things remain the same. TCP/IP is
still the preeminent communications protocol for linking together diverse computer
systems. It remains the basis of interoperable data communications and global com-
puter networking. The underlying Internet Protocol (IP), Transmission Control Pro-
tocol, and User Datagram Protocol (UDP) are remarkably unchanged. But change
has come in the way TCP/IP is used and how it is managed.
A clear symbol of this change is the fact that my mother-in-law has a TCP/IP net-
work connection in her home that she uses to exchange electronic mail, compressed
graphics, and hypertext documents with other senior citizens. She thinks of this as
“just being on the Internet,” but the truth is that her small system contains a func-
tioning TCP/IP protocol stack, manages a dynamically assigned IP address, and han-
dles data types that did not even exist a decade ago.
In 1991, TCP/IP was a tool of sophisticated users. Network administrators managed
a limited number of systems and could count on the users for a certain level of tech-
nical knowledge. No more. In 2002, the need for highly trained network administra-
tors is greater than ever because the user base is larger, more diverse, and less
capable of handling technical problems on its own. This book provides the informa-
tion needed to become an effective TCP/IP network administrator.
TCP/IP Network Administration was the first book of practical information for the
professional TCP/IP network administrator, and it is still the best. Since the first edi-
tion was published there has been an explosion of books about TCP/IP and the Inter-
net. Still, too few books concentrate on what a system administrator really needs to
know about TCP/IP administration. Most books are either scholarly texts written
from the point of view of the protocol designer, or instructions on how to use TCP/IP
applications. All of those books lack the practical, detailed network information
needed by the Unix system administrator. This book strives to focus on TCP/IP and
Unix and to find the right balance of theory and practice.

xii | Preface
I am proud of the earlier editions of TCP/IP Network Administration. In this edition,
I have done everything I can to maintain the essential character of the book while
making it better. Dynamic address assignment based on Dynamic Host Configura-
tion Protocol (DHCP) is covered. The Domain Name System material has been
updated to cover BIND 8 and, to a lesser extent, BIND 9. The email configuration is
based on current version of sendmail 8, and the operating system examples are from
the current versions of Solaris and Linux. The routing protocol coverage includes
Routing Information Protocol version 2 (RIPv2), Open Shortest Path First (OSPF),
and Border Gateway Protocol (BGP). I have also added a chapter on Apache web
server configuration, new material on xinetd, and information about building a fire-
wall with iptables. Despite the additional topics, the book has been kept to a rea-
sonable length.
TCP/IP is a set of communications protocols that define how different types of com-
puters talk to each other. TCP/IP Network Administration is a book about building
your own network based on TCP/IP. It is both a tutorial covering the “why” and
“how” of TCP/IP networking, and a reference manual for the details about specific
network programs.
Audience
This book is intended for everyone who has a Unix computer connected to a TCP/IP
network.* This obviously includes the network managers and the system administra-
tors who are responsible for setting up and running computers and networks, but it
also includes any user who wants to understand how his or her computer communi-
cates with other systems. The distinction between a “system administrator” and an
“end user” is a fuzzy one. You may think of yourself as an end user, but if you have a
Unix workstation on your desk, you’re probably also involved in system administra-
tion tasks.
Over the last several years there has been a rash of books for “dummies” and “idiots.”
If you really think of yourself as an “idiot” when it comes to Unix, this book is not for
you. Likewise, if you are a network administration “genius,” this book is probably
not suitable either. If you fall anywhere between these two extremes, however, you’ll
find this book has a lot to offer.
This book assumes that you have a good understanding of computers and their oper-
ation and that you’re generally familiar with Unix system administration. If you’re
not, the Nutshell Handbook Essential System Administration by Æleen Frisch (pub-
lished by O’Reilly & Associates) will fill you in on the basics.
* Much of this text also applies to non-Unix systems. Many of the file formats and commands and all of the
protocol descriptions apply equally well to Windows 9x, Windows NT/2000, and other operating systems.
If you’re an NT administrator, you should read Windows NT TCP/IP Network Administration (O’Reilly).

Preface | xiii
Organization
Conceptually, this book is divided into three parts: fundamental concepts, tutorial,
and reference. The first three chapters are a basic discussion of the TCP/IP protocols
and services. This discussion provides the fundamental concepts necessary to under-
stand the rest of the book. The remaining chapters provide a “how-to” tutorial.
Chapters 4–7 discuss how to plan a network installation and configure the basic soft-
ware necessary to get a network running. Chapters 8–11 discuss how to set up vari-
ous important network services. Chapters 12 and 13 cover how to perform the
ongoing tasks that are essential for a reliable network: security and troubleshooting.
The book concludes with a series of appendixes that are technical references for
important commands and programs.
This book contains the following chapters:
Chapter 1, Overview of TCP/IP, gives the history of TCP/IP, a description of the pro-
tocol architecture, and a basic explanation of how the protocols function.
Chapter 2, Delivering the Data, describes addressing and how data passes through a
network to reach the proper destination.
Chapter 3, Network Services, discusses the relationship between clients and server
systems and the various services that are central to the function of a modern internet.
Chapter 4, Getting Started, begins the discussion of network setup and configura-
tion. This chapter discusses the preliminary configuration planning needed before
you configure the systems on your network.
Chapter 5, Basic Configuration, describes how to configure TCP/IP in the Unix ker-
nel, and how to configure the system to start the network services.
Chapter 6, Configuring the Interface, tells you how to identify a network interface to
the network software. This chapter provides examples of Ethernet and PPP interface
configurations.
Chapter 7, Configuring Routing, describes how to set up routing so that systems on
your network can communicate properly with other networks. It covers the static
routing table, commonly used routing protocols, and gated, a package that provides
the latest implementations of several routing protocols.
Chapter 8, Configuring DNS, describes how to administer the name server program
that converts system names to Internet addresses.
Chapter 9, Local Network Services, describes how to configure many common net-
work servers. The chapter discusses the DHCP configuration server, the LPD print
server, the POP and IMAP mail servers, the Network File System (NFS), the Samba
file and print server, and the Network Information System (NIS).

xiv | Preface
Chapter 10, sendmail, discusses how to configure sendmail, which is the daemon
responsible for delivering electronic mail.
Chapter 11, Configuring Apache, describes how the Apache web server software is
configured.
Chapter 12, Network Security, discusses how to live on the Internet without exces-
sive risk. This chapter covers the security threats introduced by the network, and
describes the plans and preparations you can make to meet those threats.
Chapter 13, Troubleshooting TCP/IP, tells you what to do when something goes
wrong. It describes the techniques and tools used to troubleshoot TCP/IP problems
and gives examples of actual problems and their solutions.
Appendix A, PPP Tools, is a reference guide to the various programs used to config-
ure a serial port for TCP/IP. The reference covers dip, pppd, and chat.
Appendix B, A gated Reference, is a reference guide to the configuration language of
the gated routing package.
Appendix C, A named Reference, is a reference guide to the Berkeley Internet Name
Domain (BIND) name server software.
Appendix D, A dhcpd Reference, is a reference guide to the Dynamic Host Configura-
tion Protocol Daemon (dhcpd).
Appendix E, A sendmail Reference, is a reference guide to sendmail syntax, options,
and flags.
Appendix F, Solaris httpd.conf File, lists the contents of the Apache configuration file
discussed in Chapter 11.
Appendix G, RFC Excerpts, contains detailed protocol references taken directly from
the RFCs that support the protocol troubleshooting examples in Chapter 13. This
appendix explains how to obtain your own copies of the RFCs.
Unix Versions
Most of the examples in this book are taken from Red Hat Linux, currently the most
popular Linux distribution, and from Solaris 8, the Sun operating system based on
System V Unix. Fortunately, TCP/IP software is remarkably standard from system to
system, and because of this uniformity, the examples should be applicable to any
Linux, System V, or BSD-based Unix system. There are small variations in command
output or command-line options, but these should not present a problem.
Some of the ancillary networking software is identified separately from the Unix
operating system by its own release number. Many such packages are discussed, and
when appropriate are identified by their release numbers. The most important of
these packages are:

Preface | xv
BIND
Our discussion of the BIND software is based on version 8 running on a Solaris 8
system. BIND 8 is the version of the BIND software delivered with Solaris, and
supports all of the standard resource records. There are relatively few adminis-
trative differences between BIND 8 and the newer BIND 9 release for basic con-
figurations.
sendmail
Our discussion of sendmail is based on release 8.11.3. This version should be
compatible with other releases of sendmail v8.
Conventions
This book uses the following typographical conventions:
Italic
is used for the names of files, directories, hostnames, domain names, and to
emphasize new terms when they are introduced.
Constant width
is used to show the contents of files or the output from commands. It is also
used to represent commands, options, and keywords in text.
Constant width bold
is used in examples to show commands typed on the command line.
Constant width italic
is used in examples and text to show variables for which a context-specific sub-
stitution should be made. (The variable filename, for example, would be
replaced by some actual filename.)
%, #
Commands that you would give interactively are shown using the default C shell
prompt (%). If the command must be executed as root, it is shown using the
default superuser prompt (#). Because the examples may include multiple sys-
tems on a network, the prompt may be preceded by the name of the system on
which the command was given.
[ option ]
When showing command syntax, optional parts of the command are placed
within brackets. For example, ls [ -l ] means that the -l option is not required.
We’d Like to Hear from You
We have tested and verified all of the information in this book to the best of our
ability, but you may find that features have changed (or even that we have made

xvi | Preface
mistakes!). Please let us know about any errors you find, as well as your suggestions
for future editions, by writing:
O’Reilly & Associates, Inc.
1005 Gravenstein Highway North
Sebastopol, CA 95472
(800) 998-9938 (in the United States or Canada)
(707) 829-0515 (international or local)
(707) 829-0104 (fax)
There is a web page for this book, where we list errata, examples, or any additional
information. You can access this page at:
http://www.oreilly.com/catalog/tcp3
To comment or ask technical questions about this book, send email to:
bookquestions@oreilly.com
For more information about books, conferences, Resource Centers, and the O’Reilly
Network, see our web site at:
http://www.oreilly.com
To find out what else Craig is doing, visit his web site, http://www.wrotethebook.com.
Acknowledgments
I would like to thank the many people who helped in the preparation of this book.
All of the people who contributed to the first and second editions deserve thanks
because so much of their input lives on in this edition. For the first edition that’s
John Wack, Matt Bishop, Wietse Venema, Eric Allman, Jeff Honig, Scott Brim, and
John Dorgan. For the second edition that’s Eric Allman again, Bryan Costales,
Cricket Liu, Paul Albitz, Ted Lemon, Elizabeth Zwicky, Brent Chapman, Simson
Garfinkel, Jeff Sedayao, and Æleen Frisch.
The third edition has also benefited from many contributors—a surprising number
of whom are authors in their own right. They set me straight about the technical
details and improved my prose. Three authors are due special thanks. Cricket Liu,
one of the authors of the best book ever written about DNS, provided many com-
ments that improved the sections on Domain Name System. David Collier-Brown,
one of the authors of Using Samba, did a complete technical review of the Samba
material. Charles Aulds, author of a best-selling book on Apache administration,
provided insights into Apache configuration. All of these people helped me make this
book better than earlier editions. Thanks!
All the people at O’Reilly & Associates have been very helpful. Deb Cameron, my
editor, deserves a special thanks. Deb kept everything moving forward while balanc-
ing the demands of a beautiful newborn daughter, Bethany Rose. Emily Quill was

Preface | xvii
the production editor and project manager. Jeff Holcomb and Jane Ellin performed
quality control checks. Leanne Soylemez provided production assistance. Tom Dinse
wrote the index. Edie Freedman designed the cover, and Melanie Wang designed the
interior format of the book. Neil Walls converted the book from Microsoft Word to
Framemaker. Chris Reilley and Robert Romano’s illustrations from the earlier edi-
tions have been updated by Robert Romano and Jessamyn Read.
Finally, I want to thank my family—Kathy, Sara, David, and Rebecca. They keep my
feet on the ground when the pressure to meet deadlines is driving me into orbit.
They are the best.

1
In this chapter:
• TCP/IP and the Internet
• A Data Communications Model
• TCP/IP Protocol Architecture
• Network Access Layer
• Internet Layer
• Transport Layer
• Application Layer
CHAPTER 1
Overview of TCP/IP
All of us who use a Unix desktop system—engineers, educators, scientists, and busi-
ness people—have second careers as Unix system administrators. Networking these
computers gives us new tasks as network administrators.
Network administration and system administration are two different jobs. System
administration tasks such as adding users and doing backups are isolated to one
independent computer system. Not so with network administration. Once you place
your computer on a network, it interacts with many other systems. The way you do
network administration tasks has effects, good and bad, not only on your system but
on other systems on the network. A sound understanding of basic network adminis-
tration benefits everyone.
Networking your computers dramatically enhances their ability to communicate—
and most computers are used more for communication than computation. Many
mainframes and supercomputers are busy crunching the numbers for business and
science, but the number of these systems in use pales in comparison to the millions
of systems busy moving mail to a remote colleague or retrieving information from a
remote repository. Further, when you think of the hundreds of millions of desktop
systems that are used primarily for preparing documents to communicate ideas from
one person to another, it is easy to see why most computers can be viewed as com-
munications devices.
The positive impact of computer communications increases with the number and type
of computers that participate in the network. One of the great benefits of TCP/IP is
that it provides interoperable communications between all types of hardware and all
kinds of operating systems.
The name “TCP/IP” refers to an entire suite of data communications protocols. The
suite gets its name from two of the protocols that belong to it: the Transmission
Control Protocol (TCP) and the Internet Protocol (IP). TCP/IP is the traditional
name for this protocol suite and it is the name used in this book. The TCP/IP proto-
col suite is also called the Internet Protocol Suite (IPS). Both names are acceptable.

2 | Chapter 1: Overview of TCP/IP
This book is a practical, step-by-step guide to configuring and managing TCP/IP net-
working software on Unix computer systems. TCP/IP is the leading communica-
tions software for local area networks and enterprise intranets, and it is the
foundation of the worldwide Internet. TCP/IP is the most important networking
software available to a Unix network administrator.
The first part of this book discusses the basics of TCP/IP and how it moves data
across a network. The second part explains how to configure and run TCP/IP on a
Unix system. Let’s start with a little history.
TCP/IP and the Internet
In 1969 the Advanced Research Projects Agency (ARPA) funded a research and
development project to create an experimental packet-switching network. This net-
work, called the ARPAnet, was built to study techniques for providing robust, reli-
able, vendor-independent data communications. Many techniques of modern data
communications were developed in the ARPAnet.
The experimental network was so successful that many of the organizations attached
to it began to use it for daily data communications. In 1975 the ARPAnet was con-
verted from an experimental network to an operational network, and the responsibil-
ity for administering the network was given to the Defense Communications Agency
(DCA).* However, development of the ARPAnet did not stop just because it was
being used as an operational network; the basic TCP/IP protocols were developed
after the network was operational.
The TCP/IP protocols were adopted as Military Standards (MIL STD) in 1983, and
all hosts connected to the network were required to convert to the new protocols. To
ease this conversion, DARPA† funded Bolt, Beranek, and Newman (BBN) to imple-
ment TCP/IP in Berkeley (BSD) Unix. Thus began the marriage of Unix and TCP/IP.
About the time that TCP/IP was adopted as a standard, the term Internet came into
common usage. In 1983 the old ARPAnet was divided into MILNET, the unclassi-
fied part of the Defense Data Network (DDN), and a new, smaller ARPAnet. “Inter-
net” was used to refer to the entire network: MILNET plus ARPAnet.
In 1985 the National Science Foundation (NSF) created NSFNet and connected it to
the then-existing Internet. The original NSFNet linked together the five NSF super-
computer centers. It was smaller than the ARPAnet and no faster: 56Kbps. Still, the
* DCA has since changed its name to Defense Information Systems Agency (DISA).
† During the 1980s, ARPA, which is part of the U.S. Department of Defense, became Defense Advanced
Research Projects Agency (DARPA). Whether it is known as ARPA or DARPA, the agency and its mission of
funding advanced research have remained the same.

TCP/IP and the Internet | 3
creation of the NSFNet was a significant event in the history of the Internet because
NSF brought with it a new vision of the use of the Internet. NSF wanted to extend
the network to every scientist and engineer in the United States. To accomplish this,
in 1987 NSF created a new, faster backbone and a three-tiered network topology that
included the backbone, regional networks, and local networks. In 1990 the ARPA-
net formally passed out of existence, and in 1995 the NSFNet ceased its role as a pri-
mary Internet backbone network.
Today the Internet is larger than ever and encompasses hundreds of thousands of
networks worldwide. It is no longer dependent on a core (or backbone) network or
on governmental support. Today’s Internet is built by commercial providers.
National network providers, called tier-one providers, and regional network provid-
ers create the infrastructure. Internet Service Providers (ISPs) provide local access
and user services. This network of networks is linked together in the United States at
several major interconnection points called Network Access Points (NAPs).
The Internet has grown far beyond its original scope. The original networks and
agencies that built the Internet no longer play an essential role for the current net-
work. The Internet has evolved from a simple backbone network, through a three-
tiered hierarchical structure, to a huge network of interconnected, distributed net-
work hubs. It has grown exponentially since 1983—doubling in size every year.
Through all of this incredible change one thing has remained constant: the Internet is
built on the TCP/IP protocol suite.
A sign of the network’s success is the confusion that surrounds the term internet.
Originally it was used only as the name of the network built upon IP. Now internet is
a generic term used to refer to an entire class of networks. An internet (lowercase “i”)
is any collection of separate physical networks, interconnected by a common proto-
col, to form a single logical network. The Internet (uppercase “I”) is the worldwide
collection of interconnected networks, which grew out of the original ARPAnet, that
uses IP to link the various physical networks into a single logical network. In this
book, both “internet” and “Internet” refer to networks that are interconnected by
TCP/IP.
Because TCP/IP is required for Internet connection, the growth of the Internet
spurred interest in TCP/IP. As more organizations became familiar with TCP/IP,
they saw that its power can be applied in other network applications as well. The
Internet protocols are often used for local area networking even when the local net-
work is not connected to the Internet. TCP/IP is also widely used to build enterprise
networks. TCP/IP-based enterprise networks that use Internet techniques and web
tools to disseminate internal corporate information are called intranets. TCP/IP is the
foundation of all of these varied networks.

TCP/IP Features
The popularity of the TCP/IP protocols did not grow rapidly just because the proto-
cols were there, or because connecting to the Internet mandated their use. They met
an important need (worldwide data communication) at the right time, and they had
several important features that allowed them to meet this need. These features are:
• Open protocol standards, freely available and developed independently from any
specific computer hardware or operating system. Because it is so widely sup-
ported, TCP/IP is ideal for uniting different hardware and software components,
even if you don’t communicate over the Internet.
• Independence from specific physical network hardware. This allows TCP/IP to
integrate many different kinds of networks. TCP/IP can be run over an Ethernet,
a DSL connection, a dial-up line, an optical network, and virtually any other
kind of physical transmission medium.
• A common addressing scheme that allows any TCP/IP device to uniquely
address any other device in the entire network, even if the network is as large as
the worldwide Internet.
• Standardized high-level protocols for consistent, widely available user services.
Protocol Standards
Protocols are formal rules of behavior. In international relations, protocols minimize
the problems caused by cultural differences when various nations work together. By
agreeing to a common set of rules that are widely known and independent of any
nation’s customs, diplomatic protocols minimize misunderstandings; everyone knows
how to act and how to interpret the actions of others. Similarly, when computers
communicate, it is necessary to define a set of rules to govern their communications.
In data communications, these sets of rules are also called protocols. In homoge-
neous networks, a single computer vendor specifies a set of communications rules
designed to use the strengths of the vendor’s operating system and hardware archi-
tecture. But homogeneous networks are like the culture of a single country—only the
natives are truly at home in it. TCP/IP creates a heterogeneous network with open
protocols that are independent of operating system and architectural differences.
TCP/IP protocols are available to everyone and are developed and changed by con-
sensus, not by the fiat of one manufacturer. Everyone is free to develop products to
meet these open protocol specifications.
The open nature of TCP/IP protocols requires an open standards development pro-
cess and publicly available standards documents. Internet standards are developed by
the Internet Engineering Task Force (IETF) in open, public meetings. The protocols

TCP/IP and the Internet | 5
developed in this process are published as Requests for Comments (RFCs).* As the title
“Request for Comments” implies, the style and content of these documents are much
less rigid than in most standards documents. RFCs contain a wide range of interest-
ing and useful information, and are not limited to the formal specification of data
communications protocols. There are three basic types of RFCs: standards (STD),
best current practices (BCP), and informational (FYI).
RFCs that define official protocol standards are STDs and are given an STD number
in addition to an RFC number. Creating an official Internet standard is a rigorous
process. Standards track RFCs pass through three maturity levels before becoming
standards:
Proposed Standard
This is a protocol specification that is important enough and has received
enough Internet community support to be considered for a standard. The speci-
fication is stable and well understood, but it is not yet a standard and may be
withdrawn from consideration to be a standard.
Draft Standard
This is a protocol specification for which at least two independent, interopera-
ble implementations exist. A draft standard is a final specification undergoing
widespread testing. It will change only if the testing forces a change.
Internet Standard
A specification is declared a standard only after extensive testing and only if the
protocol defined in the specification is considered to be of significant benefit to
the Internet community.
There are two categories of standards. A Technical Specification (TS) defines a proto-
col. An Applicability Statement (AS) defines when the protocol is to be used. There
are three requirement levels that define the applicability of a standard:
Required
This standard protocol is a required part of every TCP/IP implementation. It
must be included for the TCP/IP stack to be compliant.
Recommended
This standard protocol should be included in every TCP/IP implementation,
although it is not required for minimal compliance.
Elective
This standard is optional. It is up to the software vendor to implement it or not.
Two other requirements levels (limited use and not recommended) apply to RFCs that
are not part of the standards track. A “limited use” protocol is used only in special
* Interested in finding out how Internet standards are created? Read RFC 2026, The Internet Standards Process.

circumstances, such as during an experiment. A protocol is “not recommended”
when it has limited functionality or is outdated. There are three types of non-
standards track RFCs:
Experimental
An experimental RFC is limited to use in research and development.
Historic
A historic RFC is outdated and no longer recommended for use.
Informational
An informational RFC provides information of general interest to the Internet
community; it does not define an Internet standard protocol.
A subset of the informational RFCs is called the FYI (For Your Information) notes.
An FYI document is given an FYI number in addition to an RFC number. FYI docu-
ments provide introductory and background material about the Internet and TCP/IP
networks. FYI documents are not mentioned in RFC 2026 and are not included in
the Internet standards process. But there are several interesting FYI documents avail-
able.*
Another group of RFCs that go beyond documenting protocols are the Best Current
Practices (BCP) RFCs. BCPs formally document techniques and procedures. Some of
these document the way that the IETF conducts itself; RFC 2026 is an example of
this type of BCP. Others provide guidelines for the operation of a network or ser-
vice; RFC 1918, Address Allocation for Private Internets, is an example of this type of
BCP. BCPs that provide operational guidelines are often of great interest to network
administrators.
There are now more than 3,000 RFCs. As a network system administrator, you will
no doubt read several. It is as important to know which ones to read as it is to under-
stand them when you do read them. Use the RFC categories and the requirements
levels to help you determine which RFCs are applicable to your situation. (A good
starting point is to focus on those RFCs that also have an STD number.) To under-
stand what you read, you need to understand the language of data communications.
RFCs contain protocol implementation specifications defined in terminology that is
unique to data communications.
A Data Communications Model
To discuss computer networking, it is necessary to use terms that have special mean-
ing. Even other computer professionals may not be familiar with all the terms in the
networking alphabet soup. As is always the case, English and computer-speak are
* To find out more about FYI documents, read RFC 1150, FYI on FYI: An Introduction to the FYI Notes.

A Data Communications Model | 7
not equivalent (or even necessarily compatible) languages. Although descriptions
and examples should make the meaning of the networking jargon more apparent,
sometimes terms are ambiguous. A common frame of reference is necessary for
understanding data communications terminology.
An architectural model developed by the International Standards Organization (ISO)
is frequently used to describe the structure and function of data communications
protocols. This architectural model, which is called the Open Systems Interconnect
(OSI) Reference Model, provides a common reference for discussing communica-
tions. The terms defined by this model are well understood and widely used in the
data communications community—so widely used, in fact, that it is difficult to dis-
cuss data communications without using OSI’s terminology.
The OSI Reference Model contains seven layers that define the functions of data
communications protocols. Each layer of the OSI model represents a function per-
formed when data is transferred between cooperating applications across an inter-
vening network. Figure 1-1 identifies each layer by name and provides a short
functional description for it. Looking at this figure, the protocols are like a pile of
building blocks stacked one upon another. Because of this appearance, the structure
is often called a stack or protocol stack.
Figure 1-1. The OSI Reference Model
standardizesdatapresentationtothe
applications.
managessessionsbetween
applications.
providesend-to-enderror
detectionandcorrection.
managesconnectionsacrossthenetworkfor
theupperlayers.
providesreliabledatadeliveryacrossthe
physicallink.
definesthephysicalcharacteristicsofthe
networkmedia.
consistsofapplicationprogramsthatusethe
network.
ApplicationLayer
PresentationLayer
SessionLayer
TransportLayer
NetworkLayer
DataLinkLayer
PhysicalLayer
1
2
3
4
5
6
7

A layer does not define a single protocol—it defines a data communications func-
tion that may be performed by any number of protocols. Therefore, each layer may
contain multiple protocols, each providing a service suitable to the function of that
layer. For example, a file transfer protocol and an electronic mail protocol both pro-
vide user services, and both are part of the Application Layer.
Every protocol communicates with its peers. A peer is an implementation of the same
protocol in the equivalent layer on a remote system; i.e., the local file transfer proto-
col is the peer of a remote file transfer protocol. Peer-level communications must be
standardized for successful communications to take place. In the abstract, each pro-
tocol is concerned only with communicating to its peers; it does not care about the
layers above or below it.
However, there must also be agreement on how to pass data between the layers on a
single computer, because every layer is involved in sending data from a local applica-
tion to an equivalent remote application. The upper layers rely on the lower layers to
transfer the data over the underlying network. Data is passed down the stack from
one layer to the next until it is transmitted over the network by the Physical Layer
protocols. At the remote end, the data is passed up the stack to the receiving applica-
tion. The individual layers do not need to know how the layers above and below
them function; they need to know only how to pass data to them. Isolating network
communications functions in different layers minimizes the impact of technological
change on the entire protocol suite. New applications can be added without chang-
ing the physical network, and new network hardware can be installed without
rewriting the application software.
Although the OSI model is useful, the TCP/IP protocols don’t match its structure
exactly. Therefore, in our discussions of TCP/IP, we use the layers of the OSI model
in the following way:
Application Layer
The Application Layer is the level of the protocol hierarchy where user-accessed
network processes reside. In this text, a TCP/IP application is any network pro-
cess that occurs above the Transport Layer. This includes all of the processes
that users directly interact with as well as other processes at this level that users
are not necessarily aware of.
Presentation Layer
For cooperating applications to exchange data, they must agree about how data
is represented. In OSI, the Presentation Layer provides standard data presenta-
tion routines. This function is frequently handled within the applications in
TCP/IP, though TCP/IP protocols such as XDR and MIME also perform this
function.
Session Layer
As with the Presentation Layer, the Session Layer is not identifiable as a separate
layer in the TCP/IP protocol hierarchy. The OSI Session Layer manages the

TCP/IP Protocol Architecture | 9
sessions (connections) between cooperating applications. In TCP/IP, this func-
tion largely occurs in the Transport Layer, and the term “session” is not used;
instead, the terms “socket” and “port” are used to describe the path over which
cooperating applications communicate.
Transport Layer
Much of our discussion of TCP/IP is directed to the protocols that occur in the
Transport Layer. The Transport Layer in the OSI reference model guarantees
that the receiver gets the data exactly as it was sent. In TCP/IP, this function is
performed by the Transmission Control Protocol (TCP). However, TCP/IP offers
a second Transport Layer service, User Datagram Protocol (UDP), that does not
perform the end-to-end reliability checks.
Network Layer
The Network Layer manages connections across the network and isolates the
upper layer protocols from the details of the underlying network. The Internet
Protocol (IP), which isolates the upper layers from the underlying network and
handles the addressing and delivery of data, is usually described as TCP/IP’s
Network Layer.
Data Link Layer
The reliable delivery of data across the underlying physical network is handled
by the Data Link Layer. TCP/IP rarely creates protocols in the Data Link Layer.
Most RFCs that relate to the Data Link Layer discuss how IP can make use of
existing data link protocols.
Physical Layer
The Physical Layer defines the characteristics of the hardware needed to carry
the data transmission signal. Features such as voltage levels and the number and
location of interface pins are defined in this layer. Examples of standards at the
Physical Layer are interface connectors such as RS232C and V.35, and stan-
dards for local area network wiring such as IEEE 802.3. TCP/IP does not define
physical standards—it makes use of existing standards.
The terminology of the OSI reference model helps us describe TCP/IP, but to fully
understand it, we must use an architectural model that more closely matches the
structure of TCP/IP. The next section introduces the protocol model we’ll use to
describe TCP/IP.
TCP/IP Protocol Architecture
While there is no universal agreement about how to describe TCP/IP with a layered
model, TCP/IP is generally viewed as being composed of fewer layers than the seven
used in the OSI model. Most descriptions of TCP/IP define three to five functional
levels in the protocol architecture. The four-level model illustrated in Figure 1-2 is
based on the three layers (Application, Host-to-Host, and Network Access) shown in

the DOD Protocol Model in the DDN Protocol Handbook Volume 1, with the addi-
tion of a separate Internet layer. This model provides a reasonable pictorial represen-
tation of the layers in the TCP/IP protocol hierarchy.
As in the OSI model, data is passed down the stack when it is being sent to the net-
work, and up the stack when it is being received from the network. The four-layered
structure of TCP/IP is seen in the way data is handled as it passes down the protocol
stack from the Application Layer to the underlying physical network. Each layer in
the stack adds control information to ensure proper delivery. This control informa-
tion is called a header because it is placed in front of the data to be transmitted. Each
layer treats all the information it receives from the layer above as data, and places its
own header in front of that information. The addition of delivery information at
every layer is called encapsulation. (See Figure 1-3 for an illustration of this.) When
data is received, the opposite happens. Each layer strips off its header before passing
the data on to the layer above. As information flows back up the stack, information
received from a lower layer is interpreted as both a header and data.
Each layer has its own independent data structures. Conceptually, a layer is unaware
of the data structures used by the layers above and below it. In reality, the data struc-
tures of a layer are designed to be compatible with the structures used by the sur-
rounding layers for the sake of more efficient data transmission. Still, each layer has
its own data structure and its own terminology to describe that structure.
Figure 1-4 shows the terms used by different layers of TCP/IP to refer to the data
being transmitted. Applications using TCP refer to data as a stream, while applica-
tions using UDP refer to data as a message. TCP calls data a segment, and UDP calls
its data a packet. The Internet layer views all data as blocks called datagrams. TCP/IP
uses many different types of underlying networks, each of which may have a different
terminology for the data it transmits. Most networks refer to transmitted data as pack-
ets or frames. Figure 1-4 shows a network that transmits pieces of data it calls frames.
Figure 1-2. The TCP/IP architecture
consistsofapplicationsandprocessesthat
usethenetwork.
providesend-to-enddatadelivery
services.
definesthedatagramandhandlestherouting
ofdata.
consistsofroutinesforaccessingphysical
networks.
ApplicationLayer
Host-to-HostTransportLayer
InternetLayer
NetworkAccessLayer
1
2
3
4

Network Access Layer | 11
Let’s look more closely at the function of each layer, working our way up from the
Network Access Layer to the Application Layer.
Network Access Layer
The Network Access Layer is the lowest layer of the TCP/IP protocol hierarchy. The
protocols in this layer provide the means for the system to deliver data to the other
devices on a directly attached network. This layer defines how to use the network to
transmit an IP datagram. Unlike higher-level protocols, Network Access Layer
Figure 1-3. Data encapsulation
Figure 1-4. Data structures
ApplicationLayer
TransportLayer
InternetLayer
NetworkAccessLayer
Header
Header
Header
Data
Data
Data
Data
Header
Header Header
Send Receive
UDP
TCP
ApplicationLayer
TransportLayer
InternetLayer
NetworkAccessLayer
packet
message
datagram
frame
segment
stream
datagram
frame

protocols must know the details of the underlying network (its packet structure,
addressing, etc.) to correctly format the data being transmitted to comply with the net-
work constraints. The TCP/IP Network Access Layer can encompass the functions of
all three lower layers of the OSI Reference Model (Network, Data Link, and Physical).
The Network Access Layer is often ignored by users. The design of TCP/IP hides the
function of the lower layers, and the better-known protocols (IP, TCP, UDP, etc.) are
all higher-level protocols. As new hardware technologies appear, new Network
Access protocols must be developed so that TCP/IP networks can use the new hard-
ware. Consequently, there are many access protocols—one for each physical net-
work standard.
Functions performed at this level include encapsulation of IP datagrams into the
frames transmitted by the network, and mapping of IP addresses to the physical
addresses used by the network. One of TCP/IP’s strengths is its universal addressing
scheme. The IP address must be converted into an address that is appropriate for the
physical network over which the datagram is transmitted.
Two RFCs that define Network Access Layer protocols are:
• RFC 826, Address Resolution Protocol (ARP), which maps IP addresses to Ether-
net addresses
• RFC 894, A Standard for the Transmission of IP Datagrams over Ethernet Net-
works, which specifies how IP datagrams are encapsulated for transmission over
Ethernet networks
As implemented in Unix, protocols in this layer often appear as a combination of
device drivers and related programs. The modules that are identified with network
device names usually encapsulate and deliver the data to the network, while separate
programs perform related functions such as address mapping.
Internet Layer
The layer above the Network Access Layer in the protocol hierarchy is the Internet
Layer. The Internet Protocol (IP) is the most important protocol in this layer. The
release of IP used in the current Internet is IP version 4 (IPv4), which is defined in
RFC 791. There are more recent versions of IP. IP version 5 is an experimental
Stream Transport (ST) protocol used for real-time data delivery. IPv5 never came into
operational use. IPv6 is an IP standard that provides greatly expanded addressing
capacity. Because IPv6 uses a completely different address structure, it is not interop-
erable with IPv4. While IPv6 is a standard version of IP, it is not yet widely used in
operational, commercial networks. Since our focus is on practical, operational net-
works, we do not cover IPv6 in detail. In this chapter and throughout the main body
of the text, “IP” refers to IPv4. IPv4 is the protocol you will configure on your system
when you want to exchange data with remote systems, and it is the focus of this text.

Internet Layer | 13
The Internet Protocol is the heart of TCP/IP. IP provides the basic packet delivery ser-
vice on which TCP/IP networks are built. All protocols, in the layers above and below
IP, use the Internet Protocol to deliver data. All incoming and outgoing TCP/IP data
flows through IP, regardless of its final destination.
Internet Protocol
The Internet Protocol is the building block of the Internet. Its functions include:
• Defining the datagram, which is the basic unit of transmission in the Internet
• Defining the Internet addressing scheme
• Moving data between the Network Access Layer and the Transport Layer
• Routing datagrams to remote hosts
• Performing fragmentation and re-assembly of datagrams
Before describing these functions in more detail, let’s look at some of IP’s character-
istics. First, IP is a connectionless protocol. This means that it does not exchange con-
trol information (called a “handshake”) to establish an end-to-end connection before
transmitting data. In contrast, a connection-oriented protocol exchanges control infor-
mation with the remote system to verify that it is ready to receive data before any
data is sent. When the handshaking is successful, the systems are said to have estab-
lished a connection. The Internet Protocol relies on protocols in other layers to estab-
lish the connection if they require connection-oriented service.
IP also relies on protocols in the other layers to provide error detection and error
recovery. The Internet Protocol is sometimes called an unreliable protocol because it
contains no error detection and recovery code. This is not to say that the protocol
cannot be relied on—quite the contrary. IP can be relied upon to accurately deliver
your data to the connected network, but it doesn’t check whether that data was cor-
rectly received. Protocols in other layers of the TCP/IP architecture provide this
checking when it is required.
The datagram
The TCP/IP protocols were built to transmit data over the ARPAnet, which was a
packet-switching network. A packet is a block of data that carries with it the informa-
tion necessary to deliver it, similar to a postal letter, which has an address written on
its envelope. A packet-switching network uses the addressing information in the pack-
ets to switch packets from one physical network to another, moving them toward their
final destination. Each packet travels the network independently of any other packet.
The datagram is the packet format defined by the Internet Protocol. Figure 1-5 is a
pictorial representation of an IP datagram. The first five or six 32-bit words of the
datagram are control information called the header. By default, the header is five
words long; the sixth word is optional. Because the header’s length is variable, it

includes a field called Internet Header Length (IHL) that indicates the header’s length
in words. The header contains all the information necessary to deliver the packet.
The Internet Protocol delivers the datagram by checking the Destination Address in
word 5 of the header. The Destination Address is a standard 32-bit IP address that
identifies the destination network and the specific host on that network. (The for-
mat of IP addresses is explained in Chapter 2.) If the Destination Address is the
address of a host on the local network, the packet is delivered directly to the destina-
tion. If the Destination Address is not on the local network, the packet is passed to a
gateway for delivery. Gateways are devices that switch packets between the different
physical networks. Deciding which gateway to use is called routing. IP makes the
routing decision for each individual packet.
Routing datagrams
Internet gateways are commonly (and perhaps more accurately) referred to as IP
routers because they use Internet Protocol to route packets between networks. In tra-
ditional TCP/IP jargon, there are only two types of network devices—gateways and
hosts. Gateways forward packets between networks, and hosts don’t. However, if a
host is connected to more than one network (called a multi-homed host), it can for-
ward packets between the networks. When a multi-homed host forwards packets, it
acts just like any other gateway and is in fact considered to be a gateway. Current
data communications terminology makes a distinction between gateways and rout-
ers,* but we’ll use the terms gateway and IP router interchangeably.
Figure 1-5. IP datagram format
* In current terminology, a gateway moves data between different protocols, and a router moves data between
different networks. So a system that moves mail between TCP/IP and X.400 is a gateway, but a traditional
IP gateway is a router.
Header
Words Bits
Version IHL Type of Service Total Length
Identification Flags Fragmentation Offset
Header Checksum
Time to Live Protocol
Source Address
Destination Address
Options
data begins here ...
Padding
0 4 8 2 6 0 4 8 1
1
2
3
4
5
6
1 1 2 2 2 3

Internet Layer | 15
Figure 1-6 shows the use of gateways to forward packets. The hosts (or end systems)
process packets through all four protocol layers, while the gateways (or intermediate
systems) process the packets only up to the Internet Layer where the routing deci-
sions are made.
Systems can deliver packets only to other devices attached to the same physical net-
work. Packets from A1 destined for host C1 are forwarded through gateways G1 and
G2. Host A1 first delivers the packet to gateway G1, with which it shares network A.
Gateway G1 delivers the packet to G2 over network B. Gateway G2 then delivers the
packet directly to host C1 because they are both attached to network C. Host A1 has
no knowledge of any gateways beyond gateway G1. It sends packets destined for
both networks C and B to that local gateway and then relies on that gateway to prop-
erly forward the packets along the path to their destinations. Likewise, host C1 sends
its packets to G2 to reach a host on network A, as well as any host on network B.
Figure 1-7 shows another view of routing. This figure emphasizes that the underly-
ing physical networks a datagram travels through may be different and even incom-
patible. Host A1 on the token ring network routes the datagram through gateway G1
to reach host C1 on the Ethernet. Gateway G1 forwards the data through the X.25
network to gateway G2 for delivery to C1. The datagram traverses three physically
different networks, but eventually arrives intact at C1.
Fragmenting datagrams
As a datagram is routed through different networks, it may be necessary for the IP
module in a gateway to divide the datagram into smaller pieces. A datagram received
from one network may be too large to be transmitted in a single packet on a differ-
ent network. This condition occurs only when a gateway interconnects dissimilar
physical networks.
Figure 1-6. Routing through gateways
Application
Transport
Internet
Network Access
HostA1
Internet
Network Access
GatewayG1
Internet
Network Access
GatewayG2
Application
Transport
Internet
Network Access
HostC1
NetworkA NetworkB NetworkC

Each type of network has a maximum transmission unit (MTU), which is the largest
packet that it can transfer. If the datagram received from one network is longer than
the other network’s MTU, the datagram must be divided into smaller fragments for
transmission. This process is called fragmentation. Think of a train delivering a load
of steel. Each railway car can carry more steel than the trucks that will take it along
the highway, so each railway car’s load is unloaded onto many different trucks. In
the same way that a railroad is physically different from a highway, an Ethernet is
physically different from an X.25 network; IP must break an Ethernet’s relatively
large packets into smaller packets before it can transmit them over an X.25 network.
The format of each fragment is the same as the format of any normal datagram.
Header word 2 contains information that identifies each datagram fragment and pro-
vides information about how to re-assemble the fragments back into the original
datagram. The Identification field identifies what datagram the fragment belongs to,
and the Fragmentation Offset field tells what piece of the datagram this fragment is.
The Flags field has a “More Fragments” bit that tells IP if it has assembled all of the
datagram fragments.
Passing datagrams to the transport layer
When IP receives a datagram that is addressed to the local host, it must pass the data
portion of the datagram to the correct Transport Layer protocol. This is done by
Figure 1-7. Networks, gateways, and hosts
X.25
Token Ring
A1
C1
G2
G1
Ethernet

Internet Layer | 17
using the protocol number from word 3 of the datagram header. Each Transport
Layer protocol has a unique protocol number that identifies it to IP. Protocol num-
bers are discussed in Chapter 2.
You can see from this short overview that IP performs many important functions.
Don’t expect to fully understand datagrams, gateways, routing, IP addresses, and all
the other things that IP does from this short description; each chapter will add more
details about these topics. So let’s continue on with the other protocol in the TCP/IP
Internet Layer.
Internet Control Message Protocol
An integral part of IP is the Internet Control Message Protocol (ICMP) defined in RFC
792. This protocol is part of the Internet Layer and uses the IP datagram delivery
facility to send its messages. ICMP sends messages that perform the following con-
trol, error reporting, and informational functions for TCP/IP:
Flow control
When datagrams arrive too fast for processing, the destination host or an inter-
mediate gateway sends an ICMP Source Quench Message back to the sender.
This tells the source to stop sending datagrams temporarily.
Detecting unreachable destinations
When a destination is unreachable, the system detecting the problem sends a
Destination Unreachable Message to the datagram’s source. If the unreachable
destination is a network or host, the message is sent by an intermediate gate-
way. But if the destination is an unreachable port, the destination host sends the
message. (We discuss ports in Chapter 2.)
Redirecting routes
A gateway sends the ICMP Redirect Message to tell a host to use another gate-
way, presumably because the other gateway is a better choice. This message can
be used only when the source host is on the same network as both gateways. To
better understand this, refer to Figure 1-7. If a host on the X.25 network sent a
datagram to G1, it would be possible for G1 to redirect that host to G2 because
the host, G1, and G2 are all attached to the same network. On the other hand, if
a host on the token ring network sent a datagram to G1, the host could not be
redirected to use G2. This is because G2 is not attached to the token ring.
Checking remote hosts
A host can send the ICMP Echo Message to see if a remote system’s Internet Pro-
tocol is up and operational. When a system receives an echo message, it replies
and sends the data from the packet back to the source host. The ping command
uses this message.

Transport Layer
The protocol layer just above the Internet Layer is the Host-to-Host Transport Layer,
usually shortened to Transport Layer. The two most important protocols in the
Transport Layer are Transmission Control Protocol (TCP) and User Datagram Proto-
col (UDP). TCP provides reliable data delivery service with end-to-end error detec-
tion and correction. UDP provides low-overhead, connectionless datagram delivery
service. Both protocols deliver data between the Application Layer and the Internet
Layer. Applications programmers can choose whichever service is more appropriate
for their specific applications.
User Datagram Protocol
The User Datagram Protocol gives application programs direct access to a datagram
delivery service, like the delivery service that IP provides. This allows applications to
exchange messages over the network with a minimum of protocol overhead.
UDP is an unreliable, connectionless datagram protocol. As noted, “unreliable”
merely means that there are no techniques in the protocol for verifying that the data
reached the other end of the network correctly. Within your computer, UDP will
deliver data correctly. UDP uses 16-bit Source Port and Destination Port numbers in
word 1 of the message header to deliver data to the correct applications process.
Figure 1-8 shows the UDP message format.
Why do applications programmers choose UDP as a data transport service? There
are a number of good reasons. If the amount of data being transmitted is small, the
overhead of creating connections and ensuring reliable delivery may be greater than
the work of re-transmitting the entire data set. In this case, UDP is the most efficient
choice for a Transport Layer protocol. Applications that fit a query-response model
are also excellent candidates for using UDP. The response can be used as a positive
acknowledgment to the query. If a response isn’t received within a certain time
period, the application just sends another query. Still other applications provide their
own techniques for reliable data delivery and don’t require that service from the
Figure 1-8. UDP message format
Source Port
Length
Destination Port
Checksum
Bits
0 16 31

Transport Layer | 19
Transport Layer protocol. Imposing another layer of acknowledgment on any of
these types of applications is inefficient.
Transmission Control Protocol
Applications that require the transport protocol to provide reliable data delivery use
TCP because it verifies that data is delivered across the network accurately and in the
proper sequence. TCP is a reliable, connection-oriented, byte-stream protocol. Let’s
look at each of these characteristics in more detail.
TCP provides reliability with a mechanism called Positive Acknowledgment with Re-
transmission (PAR). Simply stated, a system using PAR sends the data again unless it
hears from the remote system that the data arrived OK. The unit of data exchanged
between cooperating TCP modules is called a segment (see Figure 1-9). Each seg-
ment contains a checksum that the recipient uses to verify that the data is undam-
aged. If the data segment is received undamaged, the receiver sends a positive
acknowledgment back to the sender. If the data segment is damaged, the receiver dis-
cards it. After an appropriate timeout period, the sending TCP module re-transmits
any segment for which no positive acknowledgment has been received.
TCP is connection-oriented. It establishes a logical end-to-end connection between
the two communicating hosts. Control information, called a handshake, is exchanged
between the two endpoints to establish a dialogue before data is transmitted. TCP
indicates the control function of a segment by setting the appropriate bit in the Flags
field in word 4 of the segment header.
The type of handshake used by TCP is called a three-way handshake because three
segments are exchanged. Figure 1-10 shows the simplest form of the three-way hand-
shake. Host A begins the connection by sending host B a segment with the “Synchro-
nize sequence numbers” (SYN) bit set. This segment tells host B that A wishes to set
Figure 1-9. TCP segment format
Source Port Destination Port
Sequence Number
Acknowledgment Number
Window
Checksum
Options
Padding
Header
Words
0 4 8 2 6 0 4 8 1
1
2
3
4
5
6
1 1 2 2 2 3
Bits
Urgent Pointer
Flags
Reserved
Offset

up a connection, and it tells B what sequence number host A will use as a starting
number for its segments. (Sequence numbers are used to keep data in the proper
order.) Host B responds to A with a segment that has the “Acknowledgment” (ACK)
and SYN bits set. B’s segment acknowledges the receipt of A’s segment, and informs
A which sequence number host B will start with. Finally, host A sends a segment that
acknowledges receipt of B’s segment, and transfers the first actual data.
After this exchange, host A’s TCP has positive evidence that the remote TCP is alive
and ready to receive data. As soon as the connection is established, data can be trans-
ferred. When the cooperating modules have concluded the data transfers, they will
exchange a three-way handshake with segments containing the “No more data from
sender” bit (called the FIN bit) to close the connection. It is the end-to-end exchange
of data that provides the logical connection between the two systems.
TCP views the data it sends as a continuous stream of bytes, not as independent
packets. Therefore, TCP takes care to maintain the sequence in which bytes are sent
and received. The Sequence Number and Acknowledgment Number fields in the
TCP segment header keep track of the bytes.
The TCP standard does not require that each system start numbering bytes with any
specific number; each system chooses the number it will use as a starting point. To
keep track of the data stream correctly, each end of the connection must know the
other end’s initial number. The two ends of the connection synchronize byte-num-
bering systems by exchanging SYN segments during the handshake. The Sequence
Number field in the SYN segment contains the Initial Sequence Number (ISN), which
is the starting point for the byte-numbering system. For security reasons the ISN
should be a random number.
Each byte of data is numbered sequentially from the ISN, so the first real byte of data
sent has a Sequence Number of ISN+1. The Sequence Number in the header of a data
segment identifies the sequential position in the data stream of the first data byte in
Figure 1-10. Three-way handshake
HostA
SYN
ACK,data
HostB
SYN,ACK
data transfer has begun

Transport Layer | 21
the segment. For example, if the first byte in the data stream was sequence number 1
(ISN=0) and 4000 bytes of data have already been transferred, then the first byte of
data in the current segment is byte 4001, and the Sequence Number would be 4001.
The Acknowledgment Segment (ACK) performs two functions: positive acknowledg-
ment and flow control. The acknowledgment tells the sender how much data has
been received and how much more the receiver can accept. The Acknowledgment
Number is the sequence number of the next byte the receiver expects to receive. The
standard does not require an individual acknowledgment for every packet. The
acknowledgment number is a positive acknowledgment of all bytes up to that num-
ber. For example, if the first byte sent was numbered 1 and 2000 bytes have been
successfully received, the Acknowledgment Number would be 2001.
The Window field contains the window, or the number of bytes the remote end is
able to accept. If the receiver is capable of accepting 6000 more bytes, the window
would be 6000. The window indicates to the sender that it can continue sending seg-
ments as long as the total number of bytes that it sends is smaller than the window of
bytes that the receiver can accept. The receiver controls the flow of bytes from the
sender by changing the size of the window. A zero window tells the sender to cease
transmission until it receives a non-zero window value.
Figure 1-11 shows a TCP data stream that starts with an Initial Sequence Number of
0. The receiving system has received and acknowledged 2000 bytes, so the current
Acknowledgment Number is 2001. The receiver also has enough buffer space for
another 6000 bytes, so it has advertised a window of 6000. The sender is currently
sending a segment of 1000 bytes starting with Sequence Number 4001. The sender
has received no acknowledgment for the bytes from 2001 on, but continues sending
data as long as it is within the window. If the sender fills the window and receives no
acknowledgment of the data previously sent, it will, after an appropriate timeout,
send the data again starting from the first unacknowledged byte.
Figure 1-11. TCP data stream
DataReceived
1 1001 2001 3001 4001 5001 6001 7001
Window6000
Current
Segment
InitialSequence
Number0
Acknowledgment
Number2001
Sequence
Number4001

In Figure 1-11 re-transmission would start from byte 2001 if no further acknowledg-
ments are received. This procedure ensures that data is reliably received at the far
end of the network.
TCP is also responsible for delivering data received from IP to the correct applica-
tion. The application that the data is bound for is identified by a 16-bit number
called the port number. The Source Port and Destination Port are contained in the
first word of the segment header. Correctly passing data to and from the Application
Layer is an important part of what the Transport Layer services do.
Application Layer
At the top of the TCP/IP protocol architecture is the Application Layer. This layer
includes all processes that use the Transport Layer protocols to deliver data. There
are many applications protocols. Most provide user services, and new services are
always being added to this layer.
The most widely known and implemented applications protocols are:
Telnet
The Network Terminal Protocol, which provides remote login over the network.
FTP
The File Transfer Protocol, which is used for interactive file transfer.
SMTP
The Simple Mail Transfer Protocol, which delivers electronic mail.
HTTP
The Hypertext Transfer Protocol, which delivers web pages over the network.
While HTTP, FTP, SMTP, and Telnet are the most widely implemented TCP/IP
applications, you will work with many others as both a user and a system adminis-
trator. Some other commonly used TCP/IP applications are:
Domain Name System (DNS)
Also called name service, this application maps IP addresses to the names
assigned to network devices. DNS is discussed in detail in this book.
Open Shortest Path First (OSPF)
Routing is central to the way TCP/IP works. OSPF is used by network devices to
exchange routing information. Routing is also a major topic of this book.
Network File System (NFS)
This protocol allows files to be shared by various hosts on the network.
Some protocols, such as Telnet and FTP, can be used only if the user has some
knowledge of the network. Other protocols, like OSPF, run without the user even
knowing that they exist. As the system administrator, you are aware of all these

Summary | 23
applications and all the protocols in the other TCP/IP layers. And you’re responsible
for configuring them!
Summary
In this chapter we discussed the structure of TCP/IP, the protocol suite upon which
the Internet is built. We have seen that TCP/IP is a hierarchy of four layers: Applica-
tions, Transport, Internet, and Network Access. We have examined the function of
each of these layers. In the next chapter we look at how the IP datagram moves
through a network when data is delivered between hosts.

24
In this chapter:
• Addressing, Routing,
and Multiplexing
• The IP Address
• Internet Routing Architecture
• The Routing Table
• Address Resolution
• Protocols, Ports, and Sockets
CHAPTER 2
Delivering the Data
In Chapter 1, we touched on the basic architecture and design of the TCP/IP proto-
cols. From that discussion, we know that TCP/IP is a hierarchy of four layers. In this
chapter, we explore in finer detail how data moves between the protocol layers and
the systems on the network. We examine the structure of Internet addresses, includ-
ing how addresses route data to its final destination and how address structure is
locally redefined to create subnets. We also look at the protocol and port numbers
used to deliver data to the correct applications. These additional details move us
from an overview of TCP/IP to the specific implementation issues that affect your
system’s configuration.
Addressing, Routing, and Multiplexing
To deliver data between two Internet hosts, it is necessary to move the data across
the network to the correct host, and within that host to the correct user or process.
TCP/IP uses three schemes to accomplish these tasks:
Addressing
IP addresses, which uniquely identify every host on the network, deliver data to
the correct host.
Routing
Gateways deliver data to the correct network.
Multiplexing
Protocol and port numbers deliver data to the correct software module within
the host.
Each of these functions—addressing between hosts, routing between networks, and
multiplexing between layers—is necessary to send data between two cooperating
applications across the Internet. Let’s examine each of these functions in detail.
To illustrate these concepts and provide consistent examples, we’ll use an imagi-
nary corporate network. Our imaginary company brings together authors to write

The IP Address | 25
computer books and conduct training. Our company network is made up of several
networks at our training facilities and publishing office, as well as a connection to
the Internet. We are responsible for managing the Ethernet in the computing cen-
ter. This network’s structure, or topology, is shown in Figure 2-1.
The icons in the figure represent computer systems. There are, of course, several
other imaginary systems on our imaginary network, but we’ll use the hosts rodent (a
workstation) and crab (a system that serves as a gateway) for most of our examples.
The thick line is our computer center Ethernet, and the oval is the local network that
connects our various corporate networks. The cloud is the Internet, and the num-
bers are IP addresses.
The IP Address
An IP address is a 32-bit value that uniquely identifies every device attached to a
TCP/IP network. IP addresses are usually written as four decimal numbers separated
by dots (periods) in a format called dotted decimal notation.* Each decimal number
Figure 2-1. Sample network topology
* Addresses are occasionally written in other formats, e.g., as hexadecimal numbers. Whatever the notation,
the structure and meaning of the address are the same.
172.16.12.0
172.16.1.0
jerboas
172.16.12.4
172.16.12.1
crab
10.104.0.19
rodent
172.16.12.2
172.16.12.3
horseshoe
172.16.1.5
Internet

26 | Chapter 2: Delivering the Data
represents an 8-bit byte of the 32-bit address, and each of the four numbers is in the
range 0–255 (the decimal values possible in a single byte).
IP addresses are often called host addresses. While this is common usage, it is
slightly misleading. IP addresses are assigned to network interfaces, not to computer
systems. A gateway, such as crab (see Figure 2-1), has a different address for each
network to which it is connected. The gateway is known to other devices by the
address associated with the network that it shares with those devices. For example,
rodent addresses crab as 172.16.12.1 while external hosts address it as 10.104.0.19.
Systems can be addressed in three different ways. Individual systems are directly
addressed by a host address, which is called a unicast address. A unicast packet is
addressed to one individual host. Groups of systems can be addressed using a multi-
cast address, e.g., 224.0.0.9. Routers along the path from the source to the destina-
tion recognize the special address and route copies of the packet to each member of
the multicast group.* All systems on a network are addressed using the broadcast
address, e.g., 172.16.255.255. The broadcast address depends on the broadcast
capabilities of the underlying physical network.
The broadcast address is a good example of the fact that not all network addresses or
host addresses can be assigned to a network device. Some host addresses are reserved
for special uses. On all networks, host numbers 0 and 255 are reserved. An IP address
with all host bits set to 1 is a broadcast address.† The broadcast address for network
172.16 is 172.16.255.255. A datagram sent to this address is delivered to every indi-
vidual host on network 172.16. An IP address with all host bits set to 0 identifies the
network itself. For example, 10.0.0.0 refers to network 10, and 172.16.0.0 refers to
network 172.16. Addresses in this form are used in routing tables to refer to entire
networks.
Network addresses with a first byte value greater than 223 cannot be assigned to a
physical network, because those addresses are reserved for special use. There are two
other network addresses that are used only for special purposes: network 0.0.0.0 des-
ignates the default route and network 127.0.0.1 is the loopback address. The default
route is used to simplify the routing information that IP must handle. The loopback
address simplifies network applications by allowing the local host to be addressed in
the same manner as a remote host. These special network addresses play an impor-
tant part when configuring a host, but these addresses are not assigned to devices on
real networks. Despite these few exceptions, most addresses are assigned to physical
devices and are used by IP to deliver data to those devices.
* This is only partially true. Multicasting is not supported by every router. Sometimes it is necessary to tunnel
through routers and networks by encapsulating the multicast packet inside a unicast packet.
† There are configuration options that affect the default broadcast address. Chapter 5 discusses these options.

The IP Address | 27
The Internet Protocol moves data between hosts in the form of datagrams. Each
datagram is delivered to the address contained in the Destination Address (word 5)
of the datagram’s header. The Destination Address is a standard 32-bit IP address,
which contains sufficient information to uniquely identify a network and a specific
host on that network.
Address Structure
An IP address contains a network part and a host part, but the format of these parts is
not the same in every IP address. The number of address bits used to identify the net-
work and the number used to identify the host vary according to the prefix length of
the address. The prefix length is determined by the address bit mask.
An address bit mask works like this: if a bit is on in the mask, that equivalent bit in
the address is interpreted as a network bit; if a bit in the mask is off, the bit belongs
to the host part of the address. For example, if address 172.22.12.4 is given the net-
work mask 255.255.255.0, which has 24 bits on and 8 bits off, the first 24 bits are
the network number and the last 8 bits are the host address. Combining the address
and the mask tells us that this is the address of host 4 on network 172.22.12.
Specifying both the address and the mask in dotted decimal notation is cumbersome
when writing out addresses. A shorthand notation is available for writing an address
with its associated address mask. Instead of writing network 172.31.26.32 with a
mask of 255.255.255.224, we can write 172.31.26.32/27. The format of this nota-
tion is address/prefix-length, where prefix-length is the number of bits in the net-
work portion of the address. Without this notation, the address 172.31.26.32 could
easily be misinterpreted.
Organizations usually obtain official IP addresses by purchasing a block of addresses
from their Internet service provider. The ISP normally assigns a single organization a
continuous block of addresses that is appropriate for the needs of the organization.
For example, a moderately large business might purchase 192.168.16.0/20 while a
small business might buy 192.168.32.0/24. Because the prefix shows the length of the
network portion of the address, the number of host addresses that are available to an
organization (the host portion of the address) is determined by subtracting the prefix
from the total number of bits in an address, which is 32. Thus a prefix of 20 leaves 12
bits that are available to be locally assigned. This is called a “12-bit block” of
addresses. A prefix of 24 creates an “8-bit block.” Of the two sample address blocks,
the first is a 12-bit block that encompasses 4,096 addresses from 192.168.16.0 to
192.168.31.255, and the second is an 8-bit block that includes the 256 addresses
from 192.168.32.0 to 192.168.32.255.
Each of these address blocks appears to the outside world to be a single “network”
address. Thus external routers have one route to the block 192.168.16.0/20 and one
route to the block 192.168.32.0/24, regardless of the size of the address block.

Internally, however, the organization may have several separate physical networks
within the address block. The flexibility of address masks means that service provid-
ers can assign arbitrary length blocks of addresses to their customers, and the cus-
tomers can subdivide those address blocks using different length masks.
Subnets
The structure of an IP address can be locally modified by using host address bits as
additional network address bits. Essentially, the “dividing line” between network
address bits and host address bits is moved, creating additional networks but reduc-
ing the maximum number of hosts that can belong to each network. These newly
designated network bits define an address block within the larger address block,
which is called a subnet.
Organizations usually decide to subnet in order to overcome topological or organiza-
tional problems. Subnetting allows decentralized management of host addressing.
With the standard addressing scheme, a central administrator is responsible for man-
aging host addresses for the entire network. By subnetting, the administrator can del-
egate address assignment to smaller organizations within the overall organization—
which may be a political expedient, if not a technical requirement. If you don’t want
to deal with the data processing department, for example, assign them their own
subnet and let them manage it themselves.
Subnetting can also be used to overcome hardware differences and distance limita-
tions. IP routers can link dissimilar physical networks together, but only if each phys-
ical network has its own unique network address. Subnetting divides a single address
block into many unique subnet addresses, so that each physical network can have its
own unique address.
A subnet is defined by changing the bit mask of the IP address. A subnet mask func-
tions in the same way as a normal address mask: an “on” bit is interpreted as a net-
work bit; an “off” bit belongs to the host part of the address. The difference is that a
subnet mask is only used locally. On the outside, the address is still interpreted using
the address mask known to the outside world.
Assume you have a small real estate business that has been assigned the address block
192.168.32.0/24. The bit mask associated with that address block is 255.255.255.0,
and the block contains 256 addresses. Further, assume that your business has 10
offices, each with a half-dozen computers, and that you want to allocate some
addresses to each office and keep some for future expansion. You can subdivide the
256 address block with a subnet mask that extends the network portion of the
address by a few additional bits.
To subdivide 192.168.32.0/24 into 16 subnets, use the mask 255.255.255.240, i.e.,
192.168.32.0/28. The first three bytes contain the original network address block;
the fourth byte is divided between the subnet address and the address of the host on

The IP Address | 29
that subnet. Applying this mask defines the four high-order bits of the fourth byte as
the subnet part of the address, and the remaining four bits—the last four bits of the
fourth byte—as the host portion of the address. This creates 16 subnets that each
contain 14 host addresses, which is better suited to the network topology of your
small real estate business. Table 2-1 shows the subnets and host addresses produced
by applying this subnet mask to network address 192.168.32.0/24.
In Table 2-1, the first row describes a subnet with a subnet number that is all 0s (the
first four bits of the fourth byte are all set to 0). The last row in the table describes a
subnet with a subnet number that is all 1s (the first four bits of the fourth byte are all
set to 1). Originally, the RFCs implied that you should not use subnet numbers of all
0s or all 1s. However, RFC 1812, Requirements for IP Version 4 Routers, makes it
clear that subnets of all 0s and all 1s are legal and should be supported by all rout-
ers. Some older routers did not allow the use of these addresses despite the newer
RFCs. Today’s router software and hardware should make it possible for you to reli-
ably use all subnet addresses.
You don’t have to manually calculate a table like this to know what subnets and host
addresses are produced by a subnet mask. The calculations have already been done
for you. RFC 1878, Variable Length Subnet Table For IPv4, lists all possible subnet
masks and the valid addresses they produce.
Table 2-1. Effects of a subnet mask
Network number Host address range Broadcast address
192.168.32.0 192.168.32.1 – 192.168.32.14 192.168.32.15
192.168.32.16 192.168.32.17 – 192.168.32.30 192.168.32.31
192.168.32.32 192.168.32.33 – 192.168.32.46 192.168.32.47
192.168.32.48 192.168.32.49 – 192.168.32.62 192.168.32.63
192.168.32.64 192.168.32.65 – 192.168.32.78 192.168.32.79
192.168.32.80 192.168.32.81 – 192.168.32.94 192.168.32.95
192.168.32.96 192.168.32.97 – 192.168.32.110 192.168.32.111
192.168.32.112 192.168.32.113 – 192.168.32.126 192.168.32.127
192.168.32.128 192.168.32.129 – 192.168.32.142 192.168.32.143
192.168.32.144 192.168.32.145 – 192.168.32.158 192.168.32.159
192.168.32.160 192.168.32.161 – 192.168.32.174 192.168.32.175
192.168.32.176 192.168.32.177 – 192.168.32.190 192.168.32.191
192.168.32.192 192.168.32.193 – 192.168.32.206 192.168.32.207
192.168.32.208 192.168.32.209 – 192.168.32.222 192.168.32.223
192.168.32.224 192.168.32.225 – 192.168.32.238 192.168.32.239
192.168.32.240 192.168.32.241 – 192.168.32.254 192.168.32.255

RFC 1878 describes all 32 prefix values. But little documentation is needed because
the prefix is easy to understand and remember. Writing 10.104.0.19 as 10.104.0.19/8
shows that this address has 8 bits for the network number and therefore 24 bits for
the host number. Unfortunately, things are not always this neat. Sometimes the
address is not given an explicit address mask, and you need to know how to deter-
mine the natural mask that an address will be assigned by default.
The Natural Mask
Originally, the IP address space was divided into a few fixed-length structures called
address classes. The three main address classes were class A, class B, and class C. IP
software determined the class, and therefore the structure, of an address by examin-
ing its first few bits. Address classes are no longer used, but the same rules that were
used to determine the address class are now used to create the default address mask,
which is called the natural mask. These rules are as follows:
• If the first bit of an IP address is 0, the default mask is 8 bits long (prefix 8). This
is the same as the old class A network address format. The first 8 bits identify the
network, and the last 24 bits identify the host.
• If the first 2 bits of the address are 1 0, the default mask is 16 bits long (prefix
16), which is the same as the old class B network address format. The first 16
bits identify the network, and the last 16 bits identify the host.
• If the first 3 bits of the address are 1 1 0, the default mask is 24 bits long (prefix
24). This mask is the same as the old class C network address format. The first
24 bits are the network address, and the last 8 bits identify the host.
• If the first 4 bits of the address are 1 1 1 0, it is a multicast address. These
addresses were sometimes called class D addresses, but they don’t really refer to
specific networks. Multicast addresses are used to address groups of computers
all at one time. They identify a group of computers that share a common appli-
cation, such as a videoconference, as opposed to a group of computers that share
a common network. All bits in a multicast address are significant for routing, so
the default mask is 32 bits long (prefix 32).
When an IP address is written in dotted decimal format, it is sometimes easier to
think of the address as four 8-bit bytes instead of as a 32-bit value. We can look at
the address as composed of full bytes of network address and full bytes of host
address when using the natural mask, because the three default masks all create pre-
fix lengths that are multiples of 8. A simple way to determine the default mask is to
look at the first byte of the address. If the value of the first byte is:
• Less than 128, the default address mask is 8 bits long; the first byte is the net-
work number, and the next three bytes are the host address.
• From 128 to 191, the default address mask is 16 bits long; the first two bytes
identify the network, and the last two bytes identify the host.

Other documents randomly have
different content

and then kneeling down beside the wounded dog, Florence
Nightingale for the first time gave "first aid to the wounded."
As the heat drew out the inflammation and pain, Cap looked up at
the little helper, all his simple dog heart shining in his eyes; the look
sank into the child's heart and deepened the tenderness already
there. Another step, and a great one, was taken on the blessed road
she was to travel.
Florence came again the next day to bandage the leg; Cap got
entirely well, and tended sheep for many a year after that; and old
Roger was very grateful, and Mrs. Nightingale gave him a new
smock frock, and everyone was happy; and that is the end of the
story.

CHAPTER III.
THE SQUIRE'S DAUGHTER.
It soon became a recognized thing in Florence's own home and in all
the neighborhood, that she was one of the Sisters of Mercy. Nothing
was too small, no creature too humble to awaken her sympathy and
tenderness. When the stable cat had kittens, Florence was the first
to visit them, to fondle the tiny creatures and soothe their mother's
angry fear. When she walked along the pleasant wood roads of Lea
Hurst, the squirrels expected nuts as a matter of course, and could
hardly wait for her to give them. When anyone in the village or farm
fell ill, it was Florence who was looked for to cheer and comfort. Mrs.
Nightingale was a most kind and charitable lady, and delighted in
sending delicacies to the sick. It was Florence's happy privilege to
carry them, and whether she walked or rode there was apt to be a
basket on her arm or fastened to her saddlebow.
If you think hard, you can see—at least I can—just how it would be.
Old Goody Brown's rheumatism, let us say, was very bad one
morning. You children who read this know little about rheumatism.
Very likely you think it rather a funny word, and that it is just a thing
that old people have, and that they make a good deal of fuss about.
If it were a toothache, now, you say, or colic—but the truth is, no
pain is in any way pleasant. If a red-hot sword were run into your
back you would not like it? Well, sometimes rheumatism is like that.
So old Goody Brown was suffering, and very cross, just as we might
be; and nothing suited her, poor old soul; her tea was too hot, and
her porridge too cold, and her pillow set askew, and—dear! dear!
dear! she wished she was dead, so she did. Martha, her good
patient daughter, was at her wits' ends.

"Send to the 'All'!" said poor old Goody. "Send for Miss Florence!
She'll do something for me, I know."
So a barefoot boy would trudge up to the great house, and very
soon a light, slight figure would come quickly along the village street
and enter the cottage. A slender girl, quietly dressed, with perfect
neatness and taste; brown hair smoothly parted, shining like satin;
gray-blue eyes full of light and thoughtfulness; regular features, an
oval face, cheeks faintly tinted with rose—this was Florence
Nightingale.
I cannot tell you just what she had in the little basket on her arm,
whether jelly or broth or chicken or oranges; there was sure to be
something good beside the liniment and medicines to help the
aching back and limbs. But the basket held the least of what she
brought. At the very sound of her voice the fretful lines melted away
from the poor old face. I cannot tell you—I wish I could—the words
she said, this little Sister of Mercy, yet I can almost hear her speak,
in that sweet, cordial voice whose range held no harsh note; can see
her setting the pillow straight and smooth, making the little tray
dainty and pretty with the posy she had brought, coaxing the old
woman to eat, making her laugh over some story of her pets and
their droll ways. Perhaps before leaving she would open the worn
Bible or prayer book, and read a psalm; can you not see her sitting
by the bedside, her pretty head bent over the book, her face full of
tenderness and reverence? I am sure that when she went away
there was peace and comfort in that cottage room, and that
heartfelt blessings followed the "Angel Child" as she went on her
homeward way. "She had a way with her," they said; and that meant
more than volumes of praise.
The flowers that Florence used to carry were from her own garden, I
like to think. Both at Lea Hurst and Embley, she and her sister had
each her own little garden and gardening tools. Florence was a good
gardener; indeed, I think she was a good everything that she tried
to be, just because she tried. She dug, and sowed, and watered,
pruned and tied up and did all the things a garden needs; and so

her garden was full of flowers all summer long, giving delight to her
and to every sick or lonely or sorrowful person for miles around.
As Florence and her sister grew older they became more and more
helpful to their parents in the good works that they both loved to
carry on. I have read a delightful account of the "feast day" of the
village school-children, as it used to be given at Lea Hurst when
Florence was a girl.
The children gathered together at the school-house, all in their best
frocks and pinafores, and walked in procession up the street and
through the fields to Lea Hurst. Each child carried a posy and a stick
wreathed with flowers, and at the head of the procession marched a
band of music, provided by the good squire. In the field below the
garden tables were set, and here Mrs. Nightingale and her
daughters, aided by the servants, served tea and buns and cakes,
waiting on their little guests, and seeing that every child got all he
wanted—or at least all that was good for him. Then when all had
eaten and drunk their fill, the band struck up, and the boys and girls
danced on the green to their hearts' content.
What did they dance? Polkas, perhaps, and the redowa, a pretty
round dance with a good deal of stamping in it; and of course Sir
Roger de Coverley, which is very like our Virginia Reel. (If you do not
know about Sir Roger de Coverley himself, ask papa to tell you or
read you about him, for he is one of the pleasantest persons you will
ever know.)
Perhaps they sang, too; perhaps they sang the pretty old Maypole
Song. Do you know it?
Come lasses and lads, get leave of your dads,
And away to the Maypole hie,
For ev'ry fair has a sweetheart there,
And the fiddler's standing by.
For Willy shall dance with Jane,
And Johnny has got his Joan,
To trip it, trip it, trip it, trip it,

Trip it up and down.
"You're out!" says Dick, "not I," says Nick,
"'Twas the fiddler play'd it wrong."
"'Tis true," says Hugh, and so says Sue,
And so says ev'ry one;
The fiddler then began
To play the tune again,
And ev'ry girl did trip it, trip it,
Trip it to the men.
Then when feast and dance and song were all over, it was time to
reform the procession and take up the homeward march. The two
sisters, Florence and Parthe, had disappeared during the dancing;
but now, as the procession passed along the terrace, there they
were, standing behind a long table; a table at sight of which the
children's eyes grew round and bright, for it was covered from end
to end with presents. Such delightful presents! Books, and pretty
boxes and baskets, thimble-cases and needle-books and pin-
cushions; dolls, too, I am sure, for the little ones, and scrap-books,
and—but you can fill up the list for yourself with everything you like
best in the way of pretty, simple, useful gifts. I am quite sure that
Florence would not have wished to give the children foolish or
elaborate gimcracks, and that Mr. Nightingale would never have
allowed it if she had; and I think it probable that many of the gifts
were made by the two sisters and their kind and clever mother.
All about Lea Hurst, in many and many a pleasant cottage home,
those little gifts are treasured to-day like the relics of some blessed
saint; which indeed is just what they are. The saint is still living, and
some of the children of the school feasts are living, too, and now in
their age will show with pride and joy the gifts they received long
ago from the hands of the beloved Miss Florence.
As Florence grew up to womanhood she found more and more work
to do. There were mills and factories in the neighborhood of Lea

Hurst; and in the hosiery mills, especially, hundreds of women and
girls were employed, many of whom lived on the Nightingale estate.
She may have been seventeen or eighteen when she started her
Bible class for the young women of the district, holding it in the tiny
ancient chapel at Lea Hurst which I described in the first chapter.
Gathering the girls around her, she would read a chapter from the
Bible, and then give them her thoughts about it, and explain the
difficult passages; then they would all sing together, her sweet, clear
voice leading the hymns. Here is another memory very precious to
the old women who were once those happy girls. They love to tell
"how beautifully Miss Florence used to talk."
Long years after, when Miss Nightingale, spent with her noble labors,
would come to Lea Hurst for a time of rest and refreshment, the
daughters of these girls counted it a high privilege to gather on the
lawn under her window and sing to her as she sat in the room
above; and would go home proud and happy as queens if they had
seen the saintly face smiling from the window.
Shall I try to show you Florence Nightingale at seventeen? Her face
was little changed from that of the girl we saw in the cottage,
cheering old Goody Brown. She still wore her hair brushed smoothly
"Madonna-wise" on either side her face; often, now, she wore a rose
at the side, tucked in among the shining braids or coils. You would
think her frocks very queer if you saw them to-day, but then they
were extremely pretty; full skirts (no crinoline! that was to come
later) and full sleeves, with broad flat collar of lace or embroidery.
When she went to church or to make visits she wore a spencer, a
kind of full plaited jacket with a belt, something like a Norfolk jacket
—only different! and a Leghorn bonnet. You have seen pictures of
the Leghorn bonnets of the Thirties and Forties; "coal-scuttles,"
some people called them, and they were something the shape of a
scuttle. Some of them were enormous in size, and they look queer
enough now in the pictures, or—if your grandmamma had a way of
keeping things—in the "dress-up" trunk or cupboard in the attic. But
people who were young in those days tell me that they were

extremely becoming, and that a pretty face never looked prettier
that when it peeped out from the depths of a huge straw "coal-
scuttle."
When Florence rode on horseback, her habit was so long that it
nearly touched the ground (that is, if she followed the fashion of the
day, but I should not wonder a bit if she and her mother were too
sensible!) and she wore a round, broad-brimmed hat with long
ostrich plumes. I remember a picture of the Princess Royal
(afterwards Empress Frederick of Germany), in a costume like this,
which I thought one of the most beautiful things I ever saw, so I
shall imagine Florence, on an afternoon ride with the squire, let us
say, dressed in this way; but when scampering about on her pony, I
trust, she wore a less cumbrous costume.
You will remember that the Nightingales spent the winter at Embley
Park, in Hampshire. Here, too, Florence was busy in good and
helpful work. At Christmas time she found her best pleasure in giving
presents to young and old among the poor people about her, in
getting up entertainments for the children, training them to sing,
arranging treats for the old people in the poorhouse. On Christmas
Eve the village carol singers would come and sing on the lawn; old
English carols, that had been sung by generation after generation.
Poor Anthony Babington over at Lea Hall may have listened on
Christmas Eve to the same sweet old songs.
As Joseph was a-walking,
He heard an angel sing,
"This night shall be the birthnight
Of Christ our heavenly King.
"His birth-bed shall be neither
In housen nor in hall,
Nor in the place of paradise,
But in the oxen's stall.
"He neither shall be rockèd

In silver nor in gold,
But in the wooden manger
That lieth in the mold.
"He neither shall be washen
With white wine nor with red,
But with the fair spring water
That on you shall be shed.
"He neither shall be clothèd
In purple nor in pall,
But in the fair white linen
That usen babies all."
As Joseph was a-walking,
Thus did the angel sing,
And Mary's son at midnight
Was born to be our King.
Then be you glad, good people,
At this time of the year;
And light you up your candles,
For His star it shineth clear.
Then who so glad as Florence to call the singers in and bid them
welcome and "Merry Christmas!" and aid in distributing the mince
pies and silver coins which were always their due.
When Florence was fairly "grown up," other things came into her
life, the gay and merry things that come to so many girls. Mr.
Nightingale was a man of wealth and position, and liked his wife and
daughters to have their share in the gayeties of the county. So there
were many parties, at Embley and elsewhere, and Florence danced
as gayly, I doubt not, as the other girls. She went to London, too,
and she and her sister were presented to Queen Victoria, and had
their share of the brilliant society of the time.

But much as she may have enjoyed all this for a time, still her heart
was not in it, and she soon tired, I fancy, of dancing and dressing
and visiting. Already her mind was turning to other things, already
her clear eyes were looking forward to other ways of life, other
methods of work.

CHAPTER IV.
LOOKING OUT.
Step by step, and all unconsciously, Florence Nightingale had been
training her hand and eye to follow the dictates of her keen mind
and loving heart. Now, grown a young woman, she began to think
seriously how she should apply this training. What should she do
with her life? Should she go on like her friends, in the quiet pleasant
ways of country life? The squire's daughter was busy enough, surely.
Every hour of the day was full of useful, kindly work, of happy,
healthy play; should she be content with this? Her heart told her
that she was not content. In her friendly visiting among the sick
poor she had seen much misery and suffering, far more than she
and all the other kindly ladies could attempt to relieve. She felt that
something more was needed; she began to look around to see what
was being done in the larger world.
It was about this time that she met Elizabeth Fry, the noble and
beautiful friend of the prisoner. Mrs. Fry was then an elderly woman,
with all the glory of her saintly life shining about her; Florence
Nightingale an earnest and thoughtful girl of perhaps eighteen or
twenty. It is pleasant to think of that meeting. I do not know what
words passed between them, but I can almost see them together,
the beautiful stately woman in her Quaker dress, the slender girl
with her quiet face and earnest eyes; can almost hear the young
voice, questioning, eager and ardent; the elder answering, grave
and sedate, words full of weight and wisdom, of sweetness and
tenderness. This interview was one of the great moments of
Florence Nightingale's early life.
A little later than this, in 1843, she met another person whose words
and counsel impressed her deeply; and of this meeting I can give
you a clearer account, for that person was my own dear father, Dr.

Samuel G. Howe. Some ten years before this my father had decided
to devote his life to helping people who needed help. He had
established a school for the blind in Boston; he had brought Laura
Bridgman, the blind, deaf mute, out of her loneliness and taught her
to read, write, and talk with her fingers; the first time this had ever
been done with a person so afflicted. He had labored to help the
prisoners and captives in the North, and the slaves in the South; in
short he was what is called a philanthropist, that is, one who loves
his fellow-men and tries to help them.
My father and mother were traveling in England soon after their
marriage, and were invited by Mr. and Mrs. Nightingale to spend a
few days at Embley Park. One morning Miss Nightingale (for so I
must call her now that she is a woman) met my father in the garden
and said to him:
"Dr. Howe, you have had much experience in the world of
philanthropy; you are a medical man and a gentleman; now may I
ask you to tell me, upon your word, whether it would be anything
unsuitable or unbecoming to a young Englishwoman, if she should
devote herself to works of charity, in hospitals and elsewhere, as the
Catholic Sisters do?"
My father replied: "My dear Miss Florence, it would be unusual, and
in England whatever is unusual is apt to be thought unsuitable; but I
say to you, go forward, if you have a vocation for that way of life;
act up to your aspiration, and you will find that there is never
anything unbecoming or unladylike in doing your duty for the good
of others. Choose your path, go on with it, wherever it may lead
you, and God be with you!"
It was in this spirit that Miss Nightingale now began to train herself
for her life work.
It is hard for you children of to-day to imagine what nursing was in
the early part of the nineteenth century. To you a nurse means a
trim, alert, cheerful person in spotless raiment, who knows just what
to do when you are ill, and does it in the pleasantest possible

manner; you are glad when she comes into the room, sorry when
she leaves. But this pleasant person did not exist in those days,
except in the guise of a Catholic Sister of Charity. The other nurses
were for the most part coarse and ignorant women, often cruel,
often intemperate. When you read "Martin Chuzzlewit" you will find
out more about them than I can tell you. But "Martin Chuzzlewit"
was not written when Miss Nightingale determined to find out the
condition of nursing in England and on the Continent. She first spent
some months in the London hospitals, and then visited those in
Scotland and Ireland. She was horrified at what she found there; dirt
and misery and needless suffering among the patients, drunkenness
and ignorance and brutality among the nurses. Then she turned to
the Continent and found a very different state of things. The
hospitals were clean and cheerful, and the Sisters of Mercy in their
white caps and aprons were as good and kind and capable as our
trained nurses to-day.
Up to this time these good sisters had been the only trained nurses
in Europe; but in Germany Miss Nightingale found a Protestant
sisterhood which was working along the same lines, and in a more
enlightened and modern way; these were the Deaconesses of
Kaiserswerth, the pupils of Pastor Fliedner.
This good man—one of the best men, surely, that ever lived—was
the son of a Lutheran minister. His father was poor, and Theodore
had to work his way through college, but this he did cheerfully, for
he loved work. He studied very hard and also gave lessons, sawed
wood, blacked boots, and did other odd jobs. When his clothes
began to wear out he sewed up the holes with white thread, all he
had, and then inked it over. He loved children, and on the long
tramps he used to take in vacation time he was always collecting
songs and games, and teaching them to the children.
When he was twenty-two years old Theodore Fliedner became
pastor of a small Protestant parish at Kaiserswerth on the Rhine. The
people were so poor that they could do little either for their church
or themselves, so the young pastor set out on foot to seek aid from

other Christian people. He traveled in Germany, Holland and
England, and everywhere people felt his goodness and gave him
help. In London he met Elizabeth Fry, and the noble work she was
doing among the prisoners at Newgate made a deep impression on
him. He determined to do something to help the prisoners in
Germany, especially the poor women, who, after being imprisoned
for a certain time, were cast upon the world with no possession save
an ill name.
In his little garden stood an old summerhouse, partly ruinous, but
with strong walls. With his own hands the good pastor mended the
roof and made the place clean and habitable. He put in a bed, a
table and a chair, and then prayed that God would send to this
shelter some poor soul who needed it.
One night a homeless outcast woman came to the door, and the
pastor and his wife bade her welcome, and took her to the clean
pleasant room that was all ready.
In this humble way opened the now famous institution of
Kaiserswerth. Other poor women soon found out the friendly shelter;
in a short time a new and larger building was needed, and more
helping hands beside those of the good pastor and his devoted wife.
The good work grew and grew; some of the poor women had
children, and so a school was started; the school must have good
teachers, and so a training school for teachers was opened.
But most of all Pastor Fliedner wished to help the condition of the
sick poor; three years after the first opening of the summerhouse
shelter in the garden he founded the Deaconess Hospital. We are
told that it was opened "practically without patients and without
deaconesses." He obtained the use of part of a deserted factory, and
begged from his neighbors old furniture and broken crockery, which
he mended carefully, and put in the big empty rooms. He had only
six sheets, but there was plenty of water to wash them, and when
the first patient, a poor suffering servant maid, came to the door,
she was made comfortable in a spotless bed, in a clean though bare
room.

I wish I could tell you the whole beautiful story, but it would take too
long. By the end of the year there were sixty patients in the hospital,
and seven deaconess nurses to care for them. To-day there is a
deaconess hospital or home in almost every town in Germany, and
thousands upon thousands of sick and poor people bless the
deaconesses, though they may never have heard the name of Pastor
Fliedner.

CHAPTER V.
WAITING FOR THE CALL.
Miss Nightingale spent two periods of training at Kaiserswerth. When
she left it finally, good Pastor Fliedner laid his hands on her head
and gave her his blessing in simple and earnest words; and she
carried with her the love and good wishes of all the pious and
benevolent community.
I wish we had a picture of her in her deaconess costume. The blue
cotton gown, white apron and wide collar, and white muslin cap tied
under the chin with a large bow, must have set off her pensive
beauty very sweetly. She always kept a tender recollection of
Kaiserswerth, and says in a letter: "Never have I met with a higher
love and a purer devotion than there."
On her way home, Miss Nightingale spent some time with the Sisters
of St. Vincent de Paul in Paris. Here she saw what was probably the
best nursing in the world at that time; and she studied the methods
in her usual careful way, not only in the hospitals, but in the homes
of the poor and suffering, where the good sisters came and went
like ministering angels. She had still another opportunity, and this an
unsought one, of learning what they had to teach, for she fell ill
herself, and was tenderly cared for and restored to health by these
skillful and devoted women.
Returning to England, she spent some time in the quiet of home,
and as her strength returned, took up her old work of visiting among
the sick and poor of the neighborhood. But this could not keep her
long. It was not that she did not love it, and did not love her home
dearly, but there were other benevolent ladies who could do this
work. She realized this, and realized too, though perhaps
unconsciously, that she could do harder work than this, and that

there was plenty of hard work waiting to be done. She soon found it.
A call came asking her to be superintendent of a Home for Sick
Governesses in London, and she accepted it at once.
Did you ever think how hard governesses have to work? Did you
ever think how tired they must often be, and how their heads must
ache—and perhaps their hearts, too—when they are trying to teach
you the lessons that you—perhaps again—are not always willing to
learn? Well, try to remember, those of you who have your lessons in
this way! Remember that you can make the teaching a pain or a
pleasure, just as you choose; and that, after all, the teacher is trying
to help you, and to give you knowledge that some day you would be
very sorry not to have.
In the days of which we are speaking, governesses had a much
harder time than nowadays, I think. For one thing, there were not so
many different ways in which women could earn their bread. When a
girl had to make her own living she went out as a governess almost
as a matter of course, whether she had any love for teaching or not,
simply because there was nothing else to do. So the teaching was
often mere drudgery, and often, too, was not well done; and that
meant discontent and unhappiness, and very likely broken health to
follow.
The Harley Street Home, as it was then called, was founded to help
poor gentlewomen who had lost their health in this kind of life.
When Miss Nightingale came to it, things were in a bad condition,
owing to lack of means and good management. The friends of the
institution were discouraged; but discouragement, was a word not to
be found in Miss Nightingale's dictionary. There was no money? Well,
there must be money! She went quietly to work, interested her own
friends to subscribe, then talked with the discouraged people,
restoring their confidence and inducing them to renew their
subscriptions; and soon, with no fuss or flourish of trumpets, the
money was in hand.
Then she proceeded, just as quietly, to reorganize the whole
institution; engaged competent nurses, arranged the daily life of the

inmates, planned and wrote and worked, every day and all day, till
she had brought order out of chaos, and made the home, instead of
a place of disorder and discontent, one of comfort, peace, and
cheerfulness.
You must not think that this was light or pleasant work. Sick and
nervous and broken-down women are not easy to deal with; a
hospital (for this is what the home really was) is not an easy thing to
organize and superintend. It meant, as I have said, hard and
vexatious work every day and all day; and I dare say that often and
often, when night came, Florence Nightingale lay down to rest more
weary than any of her patients.
At length her health gave way under the strain; she broke down,
and was forced to give up the work and go home to Embley for a
long rest.
It was here, in her own home, amid her own beautiful fields and
gardens, that the call came which summoned her to the great work
of her life.

CHAPTER VI.
THE TRUMPET CALL.
Willie, fold your little hands;[1]
Let it drop—that "soldier" toy;
Look where father's picture stands—
Father, that here kissed his boy
Not a month since—father kind,
Who this night may—(never mind
Mother's sob, my Willie dear)
Cry out loud that He may hear
Who is God of battles—cry,
"God keep father safe this day
By the Alma River!"
Ask no more, child. Never heed
Either Russ, or Frank, or Turk;
Right of nations, trampled creed,
Chance-poised victory's bloody work;
Any flag i' the wind may roll
On thy heights, Sevastopol!
Willie, all to you and me
Is that spot, whate'er it be,
Where he stands—no other word—
Stands—God sure the child's prayers heard—
Near the Alma River.
Willie, listen to the bells
Ringing in the town to-day;
That's for victory. No knell swells
For the many swept away—
Hundreds, thousands. Let us weep,

We, who need not—just to keep
Reason clear in thought and brain
Till the morning comes again;
Till the third dread morning tell
Who they were that fought and—fell
By the Alma River.
Come, we'll lay us down, my child;
Poor the bed is—poor and hard;
But thy father, far exiled,
Sleeps upon the open sward,
Dreaming of us two at home;
Or, beneath the starry dome,
Digs out trenches in the dark,
Where he buries—Willie, mark!
Where he buries those who died
Fighting—fighting at his side—
By the Alma River.
Willie, Willie, go to sleep;
God will help us, O my boy!
He will make the dull hours creep
Faster, and send news of joy;
When I need not shrink to meet
Those great placards in the street,
That for weeks will ghastly stare
In some eyes—child, say that prayer
Once again—a different one—
Say "O God! Thy will be done,
By the Alma River."
Open your atlas at the map of Russia. Look down toward the
bottom, at that part of the great empire which borders on the Euxine
or Black Sea; there you will find a small peninsula—it is really almost
an island, being surrounded on three sides by water—labeled
"Crimea." It is only a part of one of the smallest of Russia's forty-odd

provinces, the province of Taurida; yet it is one of the famous places
of history, for here, in the years 1854 and 1855, was fought the
Crimean War, one of the greatest wars of modern times.
Russia and Turkey have never been good neighbors. They have
always been jealous of each other, always quarreling about this or
that, the fact being that each is afraid of the other's getting too
much land and too much power. In these disputes the other
countries of Europe have generally sympathized with Turkey, feeling
that Russia had quite enough power, and that if she had more it
might be dangerous for all of them. Some day you will read in
history about the Eastern Question and the Balance of Power, and
will find out just what these meant in the Fifties; but this is all that
you need know now, in order to understand what I am going to tell
you.
In 1854 Turkey, feeling that Russia was pressing too hard upon her,
called upon the other European powers to help her. The result was
that England, France, Sardinia (now a part of Italy, but then a
separate kingdom), and Turkey made an agreement with one
another, and all together declared war upon Russia.
England had been at peace with all the world for forty years, ever
since the wars of Napoleon, which were closed by the great victory
of Waterloo. The English are a brave race; they had forgotten the
horrors of war, and remembered only its glories and its victories; and
they sprang to arms as joyously as boys run to a football game.
"Sharpen your cutlasses, and the day is ours!" said Sir Charles
Napier to his men, just before the British fleet sailed; and this was
the feeling all through the country.
The fleets of the allied powers gathered in the Black Sea, forming
one great armada; surrounded the peninsula of the Crimea, and
landed their armies. In September, 1854, was fought the first great
battle, by the Alma River. The allies were victorious, and a great
shout of joy went up all over England. "Victory! victory!" cried old
and young. There were bells and bonfires and illuminations; the
whole country went mad with joy, and for a short time no one

thought of anything except glory, waving banners and sounding
trumpets. But banners and trumpets, though a real part of war, are
only a very small part. After a little time, through the shouting and
rejoicing a different sound was heard; the sound of weeping and
lamentation, not only for the hundreds of brave men who were lying
dead beside the fatal river, but for the other hundreds of sick and
wounded soldiers, dying for want of care.
There had been gross neglect and terrible mismanagement in the
carrying on of the war. Nobody knew just whose fault it was, but
everything seemed to be lacking that was most needed on that
desolate shore of the Crimea. The English troops were in an enemy's
country, and a poor country at that; whatever supplies there were
had been taken by the Russian armies for their own needs. Food and
clothing had been sent out from England in great quantities, but
somehow, no one could find them. Some supplies had been stowed
in the hold of vessels, and other things piled on top so that they
could not be got at; some were stored in warehouses which no one
had authority to open; some were actually rotting at the wharves,
for want of precise orders as to their disposal. The surgeons had no
bandages, the doctors no medicines; it was a state of things that to-
day we can hardly imagine. Indeed, it seemed as if the need were so
great and terrible that it paralyzed those who saw it.
"It is now pouring rain," wrote William Howard Russell to the London
Times, "the skies are black as ink, the wind is howling over the
staggering tents, the trenches are turned into dykes; in the tents the
water is sometimes a foot deep; our men have not either warm or
waterproof clothing; they are out for twelve hours at a time in the
trenches; they are plunged into the inevitable miseries of a winter
campaign—and not a soul seems to care for their comfort, or even
for their lives. These are hard truths, but the people of England must
hear them. They must know that the wretched beggar who wanders
about the streets of London in the rain, leads the life of a prince
compared with the British soldiers who are fighting out here for their
country.

"The commonest accessories of a hospital are wanting; there is not
the least attention paid to decency or clean linen; the stench is
appalling; the fetid air can hardly struggle out to taint the
atmosphere, save through the chinks in the walls and roofs; and for
all I can observe, these men die without the least effort being made
to save them. There they lie, just as they were let gently down on
the ground by the poor fellows, their comrades, who brought them
on their backs from the camp with the greatest tenderness, but who
are not allowed to remain with them. The sick appear to be tended
by the sick, and the dying by the dying."
He added that the snow was three feet deep on a level, and the cold
so intense that many soldiers were frozen in their tents.
No one meant to be cruel or neglectful; but there were not half
enough doctors, and—think of it, children! there were no nurses.
How did this happen? Well, when the war broke out the military
authorities did not want female nurses. The matter was talked over,
and it was decided that things would go better without them. This
was put on the ground that the class of nurses, as I have told you,
was at that time in England a very poor one. They were often
drunken, generally unfeeling, and always ignorant. The War
Department decided that this kind of nurse would do more harm
than good; they did not realize that "The old order changeth,
yielding place to new," and that the time was come when the new
nurse must replace the old.
But now the need was come, immediate and terrible, and there was
no one to meet it. When the people of England realized this; when
they learned that the hospital at Scutari was filled with sick and
wounded and dying men, and no one to care for them save a few
male orderlies, wholly untrained for the task; when they heard that
in the hospitals of the French army the Sisters of Mercy were doing
their blessed work, tending the wounded, healing the sick and
comforting the dying, and realized that the English soldiers, their

own sons, brothers and husbands, had no such help and no such
comfort, the sound of bell and trumpet was lost in a great cry of
anger and sorrow that went up from the whole country.
And matters grew worse and worse, as one great battle after
another sent its dreadful fruits to the already overflowing hospital at
Scutari. On October 25th came Balaklava; on November 5th,
Inkerman.
You have all read "The Charge of the Light Brigade"; yet I ask you to
read it again here, so that it may fit into its place in the story of this
terrible war. Remember, it is only one incident of that great battle of
Balaklava, in which both sides claimed the victory, while neither
gained any signal advantage.
Half a league, half a league,[2]
Half a league onward,
All in the valley of Death
Rode the six hundred.
"Forward, the Light Brigade!
Charge for the guns!" he said;
Into the valley of Death
"Forward, the Light Brigade!"
Was there a man dismayed?
Not though the soldier knew
Someone had blundered;
Theirs not to make reply,
Theirs not to reason why,
Theirs but to do and die:
Into the valley of Death
Cannon to right of them,
Cannon to left of them,
Cannon in front of them

Volleyed and thundered.
Stormed at with shot and shell,
Boldly they rode and well;
Into the jaws of Death,
Into the mouth of Hell,
Flashed all their sabres bare,
Flashed as they turned in air,
Sabring the gunners there,
Charging an army, while
All the world wondered;
Plunged in the battery-smoke,
Right through the line they broke.
Cossack and Russian
Reeled from the sabre-stroke,
Shattered and sundered.
Then they rode back, but not—
Not the six hundred.
Cannon to right of them,
Cannon to left of them,
Cannon behind them
Volleyed and thundered:
Stormed at with shot and shell,
While horse and hero fell,
They that had fought so well
Came through the jaws of Death
Back from the mouth of Hell—
All that was left of them,
Left of six hundred.
When can their glory fade?
O the wild charge they made!
All the world wondered.
Honor the charge they made!

Honor the Light Brigade,
Noble six hundred!
I have already spoken of William Howard Russell. He was the war
correspondent of the Times, the great English newspaper, and a
man of intelligence, heart and feeling. He was on the spot, and saw
the horrors of the war at first-hand. His heart was filled with sorrow
and pity for the suffering around him, and with indignation that so
little was done to relieve it; and he wrote day after day home to
England, telling what he saw and what was needed. Soon after
Balaklava he wrote:
"Are there no devoted women amongst us, able and willing to go
forth to minister to the sick and suffering soldiers of the East in the
hospitals at Scutari? Are there none of the daughters of England, at
this extreme hour of need, ready for such a work of mercy? France
has sent forth her Sisters of Mercy unsparingly, and they are even
now by the bedsides of the wounded and the dying, giving what
woman's hand alone can give of comfort and relief. Must we fall so
far below the French in self-sacrifice and devotedness, in a work
which Christ so signally blesses as done unto Himself? 'I was sick
and ye visited me.'"
This was the trumpet call that rang in the ears of the women of
England, sounding a clearer note than all the clarions of victory. We
shall see how it was answered.

CHAPTER VII.
THE RESPONSE.
Mr. Sidney Herbert (afterwards Lord Herbert of Lea) was at this time
at the head of the War Department in England. He was a man of
noble nature and tender heart, whose whole life was spent in doing
good, and in helping those who needed help. He heard with deep
distress the dreadful tidings of suffering that came from the Crimea,
and his heart responded instantly to the call for help. Yes, the
women of England must rise up and go to that far, desolate land to
tend and nurse the sick and wounded and dying; but who should
lead them? What one woman had the strength, the power, the
wisdom, the tenderness, to meet and overcome the terrible
conditions? Asking himself this question, Mr. Herbert answered
without a moment's hesitation: "Florence Nightingale!"
He knew Miss Nightingale well; she was a dear friend of himself and
his beautiful wife, and had again and again given them help and
counsel in planning and managing their many charities, hospitals,
homes for sick children, and so forth. He knew that she possessed
all the qualities needed for this work, and he wrote to her, asking if
she would undertake it. Would she, he asked, go out to Scutari,
taking with her a band of nurses who would be under her orders,
and take charge of the hospital nursing?
He did not make light of the task.
"The selection of the rank and file of nurses would be difficult—no
one knows that better than yourself. The difficulty of finding women
equal to a task after all full of horror, and requiring, besides
intelligence and goodwill, great knowledge and great courage will be
great; the task of ruling them and introducing system among them
great, and not the least will be the difficulty of making the whole

Welcome to our website – the perfect destination for book lovers and
knowledge seekers. We believe that every book holds a new world,
offering opportunities for learning, discovery, and personal growth.
That’s why we are dedicated to bringing you a diverse collection of
books, ranging from classic literature and specialized publications to
self-development guides and children's books.
More than just a book-buying platform, we strive to be a bridge
connecting you with timeless cultural and intellectual values. With an
elegant, user-friendly interface and a smart search system, you can
quickly find the books that best suit your interests. Additionally,
our special promotions and home delivery services help you save time
and fully enjoy the joy of reading.
Join us on a journey of knowledge exploration, passion nurturing, and
personal growth every day!
ebookbell.com

Tcpip Network Administration 3rd Edition 3rd Edition Craig Hunt

More Related Content

Similar to Tcpip Network Administration 3rd Edition 3rd Edition Craig Hunt (20)

Recently uploaded (20)

Tcpip Network Administration 3rd Edition 3rd Edition Craig Hunt