Вы находитесь на странице: 1из 487

Teach Yourself TCP/IP in 14 Days

Second Edition
Pr ef ace t o Second Edit ion
About t he Aut hor
Over view
Int r oduct ion
1. Open Syst ems, St andar ds, and Pr ot ocol s
2. TCP/IP and t he Int er net
3. The Int er net Pr ot ocol (IP)
4. TCP and UDP
5. Gat eway and Rout ing Pr ot ocol s
6. Tel net and FTP
7. TCP/IP Conf igur at ion and Administ r at ion Basics
8. TCP/IP and Net wor ks
9. Set t ing Up a Sampl e TCP/IP Net wor k: Ser ver s
10. Set t ing Up a Sampl e TCP/IP Net wor k: DOS and Windows Cl ient s
11. Domain Name Ser vice
12. Net wor k Fil e Syst em and Net wor k Inf or mat ion Ser vice
13. Managing and Tr oubl eshoot ing TCP/IP
14. The Socket Pr ogr amming Int er f ace
Appendix A: Acr onyms and Abbr eviat ions
Appendix B: Gl ossar y
Appendix C: Commands
Appendix D: Wel l -Known Por t Number s
Appendix E: RFCs
Appendix F: Answer s t o Quizzes

This document was pr oduced using a BETA ver sion of HTML Tr ansit 2

Teach Yourself TCP/IP in 14 Days, Second
Edition
The second edit ion of Teach Yourself TCP/IP in 14 Days expands on t he ver y popul ar f ir st
edit ion, br inging t he inf or mat ion up-t o-dat e and adding new t opics t o compl et e t he
cover age of TCP/IP. The book has been r eor ganized t o make r eading and l ear ning easier ,
as wel l as t o pr ovide a mor e l ogical appr oach t o t he subject .
New mat er ial in t his edit ion deal s wit h inst al l ing, conf igur ing, and t est ing a TCP/IP
net wor k of ser ver s and cl ient s. You wil l see how t o easil y set up UNIX, Linux, and
Windows NT ser ver s f or al l popul ar TCP/IP ser vices, incl uding Tel net , FTP, DNS, NIS,
and NFS. On t he cl ient side, you wil l see how t o set up DOS, Windows, Windows 95, and
WinSock t o int er act wit h a ser ver . Exampl es and t ips t hr oughout t hese sect ions make
t he pr ocess easy and cl ear .
Al so added in t his edit ion of Teach Yourself TCP/IP in 14 Days ar e new sect ions on DNS,
NFS, and NIS. These net wor k ser vices have become popul ar wit h t he gr owt h of l ar ge
TCP/IP net wor ks, so we show you how t o conf igur e and use t hem al l . A new sect ion on
t he l at est ver sion of IP updat es t he t r eat ment of t he base pr ot ocol s t o 1996 st andar ds.
Tim Par ker
Mail :
Dean Mil l er
Comment s Depar t ment
Sams Publ ishing
201 W. 103r d St r eet
Indianapol is, IN 46290
I Topics Cover ed in Det ail in t his Edit ion
I The TCP/IP Pr ot ocol Famil y
I Tr anspor t
I Rout ing
I Net wor k Addr esses
I User Ser vices
I Gat eway Pr ot ocol s
I Ot her s
Topics Cover ed in Det ail in t his Edit ion
G St andar ds and t er minol ogy
G Net wor k ar chit ect ur e
G Hist or y of TCP/IP and t he Int er net
G IPng (IP ver sion 6)
G Tel net and FTP
G Conf igur ing ser ver s and cl ient s
Introduction
So you've just been t ol d you ar e on a TCP/IP net wor k, you ar e t he new TCP/IP syst em
administ r at or , or you have t o inst al l a TCP/IP syst em. But you don't know ver y much
about TCP/IP. That 's wher e t his book comes in. You don't need any pr ogr amming skil l s,
and f amil iar it y wit h oper at ing syst ems is assumed. Even if you've never t ouched a
comput er bef or e, you shoul d be abl e t o f ol l ow t he mat er ial .
This book is int ended f or beginning t hr ough int er mediat e user s and cover s al l t he
pr ot ocol s invol ved in TCP/IP. Each pr ot ocol is examined in a f air l evel of det ail t o show
how it wor ks and how it int er act s wit h t he ot her pr ot ocol s in t he TCP/IP f amil y. Al ong
t he way, t his book shows you t he basic t ool s r equir ed t o inst al l , conf igur e, and maint ain
a TCP/IP net wor k. It al so shows you most of t he user ut il it ies t hat ar e avail abl e.
Because of t he compl ex nat ur e of TCP/IP and t he l ack of a f r iendl y user int er f ace,
t her e is a l ot of inf or mat ion t o l ook at . Thr oughout t he book, t he r ol e of each pr ot ocol
is shown separ at el y, as is t he way it wor ks on net wor ks of al l sizes. The r el at ionship
wit h l ar ge int er net wor ks (l ike t he Int er net ) is al so cover ed.
Each chapt er in t he book adds t o t he compl exit y of t he syst em, buil ding on t he mat er ial
in t he ear l ier chapt er s. Al t hough some chapt er s seem t o be unr el at ed t o TCP/IP at f ir st
gl ance, al l t he mat er ial is invol ved in an int egr al manner wit h t he TCP/IP pr ot ocol
f amil y. The l ast f ew chapt er s cover t he inst al l at ion and t r oubl eshoot ing of a net wor k.
By t he t ime you f inish t his book, you wil l under st and t he dif f er ent component s of a
TCP/IP syst em, as wel l as t he compl ex acr onym-heavy jar gon used. Fol l owing t he
exampl es pr esent ed, you shoul d be abl e t o inst al l and conf igur e a compl et e TCP/IP
net wor k f or any oper at ing syst em and har dwar e pl at f or m.
The TCP/IP Protocol Family
Transport
Tr ansmission Cont r ol Pr ot ocol (TCP): connect ion-based ser vices
User Dat agr am Pr ot ocol (UDP): connect ionl ess ser vices
Routing
Int er net Pr ot ocol (IP): handl es t r ansmission of inf or mat ion
Int er net Cont r ol Message Pr ot ocol (ICMP): handl es st at us messages f or IP
Rout ing Inf or mat ion Pr ot ocol (RIP): det er mines r out ing
Open Shor t est Pat h Fir st (OSPF): al t er nat e pr ot ocol f or
det er mining r out ing
Network Addresses
Addr ess Resol ut ion Pr ot ocol (ARP): det er mines addr esses
Domain Name Syst em (DNS): det er mines addr esses f r om machine names
Rever se Addr ess Resol ut ion Pr ot ocol (RARP): - det er mines
addr esses
User Services
Boot Pr ot ocol (BOOTP): st ar t s up a net wor k machine
Fil e Tr ansf er Pr ot ocol (FTP): t r ansf er s f il es
Tel net : al l ows r emot e l ogins
Gateway Protocols
Ext er ior Gat eway Pr ot ocol (EGP): t r ansf er s r out ing inf or mat ion f or
ext er nal net wor ks
Gat eway-t o-Gat eway Pr ot ocol (GGP): t r ansf er s r out ing inf or mat ion
bet ween gat eways
Int er ior Gat eway Pr ot ocol (IGP): t r ansf er s r out ing inf or mat ion
f or int er nal net wor ks
Others
Net wor k Fil e Syst em (NFS): enabl es dir ect or ies on one machine t o be
mount ed on anot her
Net wor k Inf or mat ion Ser vice (NIS): maint ains user account s acr oss
net wor ks
Remot e Pr ocedur e Cal l (RPC): enabl es r emot e appl icat ions t o communicat e
Simpl e Mail Tr ansf er Pr ot ocol (SMTP): t r ansf er s el ect r onic mail
Simpl e Net wor k Management Pr ot ocol (SNMP): sends st at us
messages about t he net wor k


I The TCP/IP Pr ot ocol Famil y
The TCP/IP Protocol Family
Transport
TCP (Tr ansmission Cont r ol Pr ot ocol ) Connect ion-based ser vices (Day 4)
UDP (User Dat agr am Pr ot ocol ) Connect ionl ess ser vices (Day 4)
Routing
IP (Int er net Pr ot ocol ) Handl es t r ansmission of inf or mat ion (Day 3)
ICMP (Int er net Cont r ol Message
Pr ot ocol )
Handl es st at us messages f or IP (Day 3)
RIP (Rout ing Inf or mat ion Pr ot ocol ) Det er mines r out ing (Day 5)
OSPF (Open Shor t est Pat h Fir st )
Al t er nat e pr ot ocol f or det er mining r out ing
(Day 5)
Network Addresses
ARP (Addr ess Resol ut ion Pr ot ocol ) Det er mines addr esses (Day 2)
DNS (Domain Name Syst em)
Det er mines addr esses f r om machine names
(Day 2 and Day 11)
RARP (Rever se Addr ess Resol ut ion
Pr ot ocol )
Det er mines addr esses (Day 2)
User Services
BOOTP (Boot Pr ot ocol ) St ar t s up a net wor k machine (Day 11)
FTP (Fil e Tr ansf er Pr ot ocol ) Tr ansf er s f il es (Day 6)
Tel net Enabl es r emot e l ogins (Day 6)
TFTP (Tr ivial Fil e Tr ansf er Pr ot ocol ) Enabl es r emot e f il e t r ansf er s (Day 6)
Gateway Protocols
EGP (Ext er ior Gat eway Pr ot ocol )
Tr ansf er s r out ing inf or mat ion f or ext er nal
net wor ks (Day 3 and Day 5)
GGP (Gat eway-t o-Gat eway Pr ot ocol )
Tr ansf er s r out ing inf or mat ion bet ween
gat eways (Day 3 and Day 5)
IGP (Int er ior Gat eway Pr ot ocol )
Tr ansf er s r out ing inf or mat ion f or int er nal
net wor ks (Day 5)
Others
NFS (Net wor k Fil e Syst em)
Enabl es dir ect or ies on one machine t o be
mount ed on anot her (Day 12)
NIS (Net wor k Inf or mat ion Ser vice)
Maint ains user account s acr oss net wor ks
(Day 12)
NTP (Net wor k Time Pr ot ocol ) Synchr onizes cl ocks (Day 11)
PING (Packet Int er net Gr oper ) Checks connect ivit y (Day 7)
RPC (Remot e Pr ocedur e Cal l )
Enabl es r emot e appl icat ions t o communicat e
(Day 12)
SNMP (Simpl e Net wor k Management
Pr ot ocol )
Sends st at us messages about t he net wor k
(Day 13)


I Open Syst ems
I What Is an Open Syst em?
I Net wor k Ar chit ect ur es
I Local Ar ea Net wor ks
I The Bus Net wor k
I The Ring Net wor k
I The Hub Net wor k
I Wide Ar ea Net wor ks
I Layer s
I The Appl icat ion Layer
I The Pr esent at ion Layer
I The Session Layer
I The Tr anspor t Layer
I The Net wor k Layer
I The Dat a Link Layer
I The Physical Layer
I Ter minol ogy and Not at ions
I Packet s
I Subsyst ems
I Ent it ies
I N Not at ion
I N-Funct ions
I N-Facil it ies
I Ser vices
I Making Sense of t he Jar gon
I Queues and Connect ions
I St andar ds
I Set t ing St andar ds
I Int er net St andar ds
I Pr ot ocol s
I Br eaking Dat a Apar t
I Pr ot ocol Header s
I Summar y
I Q&A
I Quiz
1
Open Systems, Standards, and Protocols
Today I st ar t l ooking at t he subject of TCP/IP by cover ing some backgr ound inf or mat ion
you wil l need t o put TCP/IP in per spect ive, and t o under st and why t he TCP/IP pr ot ocol s
wer e designed t he way t hey ar e. This chapt er cover s some impor t ant inf or mat ion,
incl uding t he f ol l owing:
G What an open syst em is
G How an open syst em handl es net wor king
G Why st andar ds ar e r equir ed
G How st andar ds f or pr ot ocol s l ike TCP/IP ar e devel oped
G What a pr ot ocol is
G The OSI pr ot ocol s
You might be eager t o get st ar t ed wit h t he nit t y-gr it t y of t he TCP/IP pr ot ocol s, or t o
f ind out how t o use t he bet t er -known ser vices l ike FTP and Tel net . If you have a specif ic
r equir ement t o sat isf y (such as how t o t r ansf er a f il e f r om one syst em t o anot her ), by
al l means use t he Tabl e of Cont ent s t o f ind t he sect ion you want . But if you want t o
r eal l y under st and TCP/IP, you wil l need t o wade t hr ough t he mat er ial in t his chapt er .
It 's not compl icat ed, al t hough t her e ar e quit e a f ew subject s t o be cover ed. Luckil y,
none of it r equir es memor izat ion; mor e of t en t han not it is a mat t er of set t ing t he st age
f or somet hing el se I discuss in t he next week or so. So don't get t oo over whel med by t his
chapt er !
Open Systems
This is a book about a f amil y of pr ot ocol s cal l ed TCP/IP, so why bot her l ooking at open
syst ems and st andar ds at al l ? Pr imar il y because TCP/IP gr ew out of t he need t o devel op
a st andar dized communicat ions pr ocedur e t hat woul d inevit abl y be used on a var iet y of
pl at f or ms. The need f or a st andar d, and one t hat was r eadil y avail abl e t o anyone
(hence open), was vit al l y impor t ant t o TCP/IP's success. Ther ef or e, a l it t l e backgr ound
hel ps put t he design of TCP/IP int o per spect ive.
Mor e impor t ant l y, open syst ems have become de r igueur in t he cur r ent compet it ive
mar ket . The t er m open system is bandied ar ound by many peopl e as a sol ut ion f or al l
pr obl ems (t o be r epl aced occasional l y by t he t er m client/server), but neit her t er m is
usual l y pr oper l y used or under st ood by t he peopl e spout ing t hem. Under st anding what
an open syst em r eal l y is and what it impl ies l eads t o a bet t er awar eness of TCP/IP's r ol e
on a net wor k and acr oss l ar ge int er net wor ks l ike t he Int er net .
In a simil ar vein, t he use of st andar ds ensur es t hat a pr ot ocol such as TCP/IP is t he same
on each syst em. This means t hat your PC can t al k t o a minicomput er r unning TCP/IP
wit hout special t r ansl at ion or conver sion r out ines. It means t hat an ent ir e net wor k of
dif f er ent har dwar e and oper at ing syst ems can wor k wit h t he same net wor k pr ot ocol s.
Devel oping a st andar d is not a t r ivial pr ocess. Of t en a singl e st andar d invol ves mor e
t han a singl e document descr ibing a sof t war e syst em. A st andar d of t en invol ves t he
int er r el at ionship of many dif f er ent pr ot ocol s, as does TCP/IP. Knowing t he int er act ions
bet ween TCP/IP and t he ot her component s of a communicat ions syst em is impor t ant f or
pr oper conf igur at ion and opt imizat ion, and t o ensur e t hat al l t he ser vices you need ar e
avail abl e and int er wor king pr oper l y.
What Is an Open System?
Ther e ar e many def init ions of open syst ems, and a singl e, concise def init ion t hat
ever yone is happy wit h is f ar f r om being accept ed. For most peopl e, an open syst em is best
l oosel y def ined as one f or which t he ar chit ect ur e is not a secr et . The descr ipt ion of t he
ar chit ect ur e has been publ ished or is r eadil y avail abl e t o anyone who want s t o buil d
pr oduct s f or a har dwar e or sof t war e pl at f or m. This def init ion of an open syst em appl ies
equal l y wel l t o har dwar e and sof t war e.
When mor e t han a singl e vendor begins pr oducing pr oduct s f or a pl at f or m, cust omer s
have a choice. You don't par t icul ar l y l ike Nocr ash Sof t war e's net wor k monit or ing
sof t war e? No pr obl em, because Faul t Fr ee Sof t war e's pr oduct r uns on t he Nocr ash
har dwar e, and you l ike it s f ancy int er f ace much bet t er . You need a mor e col or f ul
gr aphical f r ont -end t o your Whizbang PC t han t he one Whizbang pr ovides? Downl oad
one f r om Super Sof t war e t hr ough t he Int er net , and it wor ks per f ect l y. The pr imar y
idea, of cour se, is a move away f r om pr opr iet ar y pl at f or ms t o one t hat is mul t ivendor .
A decade ago, open syst ems wer e vir t ual l y nonexist ent . Each har dwar e manuf act ur er
had a pr oduct l ine, and you wer e pr act ical l y bound t o t hat manuf act ur er f or al l your
sof t war e and har dwar e needs. Some companies t ook advant age of t he capt ive mar ket ,
char ging out r ageous pr ices or f or cing unwant ed conf igur at ions on t heir cust omer s. The
gr oundswel l of r esent ment gr ew t o t he point t hat cust omer s began f or cing t he issue.
The l ack of choice in sof t war e and har dwar e pur chases is why sever al dedicat ed
minicomput er and mainf r ame companies eit her went bankr upt or had t o accept open
syst em pr incipl es: t heir cust omer s got f ed up wit h r el ying on a singl e vendor . A good
exampl e of a company t hat made t he adapt at ion is Digit al Equipment Cor por at ion (DEC).
They moved f r om a pr opr iet ar y oper at ing syst em on t heir VMS minicomput er s t o a UNIX-
st andar d open oper at ing syst em. By doing t hat , t hey kept t heir cust omer s happy, and
t hey sol d mor e machines. That 's one of t he pr imar y r easons DEC is st il l in business t oday.
UNIX is a cl assic exampl e of an open sof t war e pl at f or m. UNIX has been ar ound f or 30
year s. The sour ce code f or t he UNIX oper at ing syst em was made avail abl e t o anyone who
want ed it , al most f r om t he st ar t . UNIX's sour ce code is wel l under st ood and easy t o
wor k wit h, t he r esul t of 30 year s of devel opment and impr ovement . UNIX can be por t ed
t o r un on pr act ical l y any har dwar e pl at f or m, el iminat ing al l pr opr iet ar y dependencies.
The at t r act ion of UNIX is not t he oper at ing syst em's f eat ur es t hemsel ves but simpl y
t hat a UNIX user can r un sof t war e f r om ot her UNIX pl at f or ms, t hat f il es ar e
compat ibl e f r om one UNIX syst em t o anot her (except f or disk f or mat s), and t hat a wide
var iet y of vendor s sel l pr oduct s f or UNIX.
The gr owt h of UNIX pushed t he l ar ge har dwar e manuf act ur er s t o t he open syst ems
pr incipl e, r esul t ing in most manuf act ur er s l icensing t he r ight t o pr oduce a UNIX ver sion
f or t heir own har dwar e. This st ep l et cust omer s combine dif f er ent har dwar e syst ems
int o l ar ger net wor ks, al l r unning UNIX and wor king t oget her . User s coul d move
bet ween machines al most t r anspar ent l y, ignor ant of t he act ual har dwar e pl at f or m
t hey wer e on. Open syst ems, or iginal l y of pr ime impor t ance onl y t o t he l ar gest
cor por at ions and gover nment s, is now a key el ement in even t he smal l est company's
comput er st r at egy.
Al t hough UNIX is a copyr ight ed wor k now owned by
X/Open, t he det ail s of t he oper at ing syst em have been publ ished
and ar e r eadil y avail abl e t o any devel oper who want s t o
pr oduce appl icat ions or har dwar e t hat wor k wit h t he oper at ing
syst em. UNIX is unique in t his r espect .
The t er m open system networking means many t hings, depending on whom you ask. In it s
br oadest def init ion, open syst em net wor king r ef er s t o a net wor k based on a wel l -known
and under st ood pr ot ocol (such as TCP/IP) t hat has it s st andar ds publ ished and r eadil y
avail abl e t o anyone who want s t o use t hem. Open syst em net wor king al so r ef er s t o t he
pr ocess of net wor king open syst ems (machaine-specif ic har dwar e and sof t war e) using a
net wor k pr ot ocol . It is easy t o see why peopl e want open syst ems net wor king, t hough.
Thr ee ser vices ar e widel y used and account f or t he highest per cent age of net wor k
t r af f ic: f il e t r ansf er , el ect r onic mail , and r emot e l ogin. Wit hout open syst ems
net wor king, set t ing up any of t hese t hr ee ser vices woul d be a night mar e.
Fil e t r ansf er s enabl e user s t o shar e f il es quickl y and ef f icient l y, wit hout excessive
dupl icat ion or concer ns about t he t r anspor t met hod. Net wor k f il e t r ansf er s ar e much
f ast er t han an over night cour ier cr ossing t he count r y, and usual l y f ast er t han copying
a f il e on a disk and car r ying it acr oss t he r oom. Fil e t r ansf er is al so ext r emel y
convenient , which not onl y pl eases user s but al so el iminat es t ime del ays whil e wait ing
f or mat er ial . A common open syst em gover ning f il e t r ansf er s means t hat any
incompat ibil it ies bet ween t he t wo machines t r ansf er r ing f il es can be over come easil y.
El ect r onic mail has mushr oomed t o a phenomenal l y l ar ge ser vice, not just wit hin a
singl e business but wor l dwide. The Int er net car r ies mil l ions of messages f r om peopl e in
gover nment , pr ivat e indust r y, educat ional inst it ut ions, and pr ivat e int er est s.
El ect r onic mail is cheap (no paper , envel ope, or st amp) and f ast (ar ound t he wor l d in 60
seconds or so). It is al so an obvious ext ension of t he comput er -based wor l d we wor k in.
Wit hout an open mail syst em, you woul dn't have anywher e near t he capabil it ies you
now enjoy.
Final l y, r emot e l ogins enabl e a user who is based on one syst em t o connect t hr ough a
net wor k t o any ot her syst em t hat accept s him as a user . This can be in t he next
wor kgr oup, t he next st at e, or in anot her count r y. Remot e l ogins enabl e user s t o t ake
advant age of par t icul ar har dwar e and sof t war e in anot her l ocat ion, as wel l as t o r un
appl icat ions on anot her machine. Once again, wit hout an open st andar d, t his woul d be
al most impossibl e.
Network Architectures
To under st and net wor king pr ot ocol s, it is usef ul t o know a l it t l e about net wor ks. A
quick l ook at t he most common net wor k ar chit ect ur es wil l hel p l at er in t his book when
you r ead about net wor k oper at ions and r out ing. The t er m network usual l y means a set of
comput er s and per ipher al s (pr int er s, modems, pl ot t er s, scanner s, and so on) t hat ar e
connect ed t oget her by some medium. The connect ion can be dir ect (t hr ough a cabl e) or
indir ect (t hr ough a modem). The dif f er ent devices on t he net wor k communicat e wit h
each ot her t hr ough a pr edef ined set of r ul es (t he pr ot ocol ).
The devices on a net wor k can be in t he same r oom or scat t er ed t hr ough a buil ding. They
can be separ at ed by many mil es t hr ough t he use of dedicat ed t el ephone l ines, micr owave,
or a simil ar syst em. They can even be scat t er ed ar ound t he wor l d, again connect ed by a
l ong-dist ance communicat ions medium. The l ayout of t he net wor k (t he act ual devices
and t he manner in which t hey ar e connect ed t o each ot her ) is cal l ed t he network
topology.
Usual l y, if t he devices on a net wor k ar e in a singl e l ocat ion such as a buil ding or a
gr oup of r ooms, t hey ar e cal l ed a l ocal ar ea net wor k, or LAN. LANs usual l y have al l
t he devices on t he net wor k connect ed by a singl e t ype of net wor k cabl e. If t he devices
ar e scat t er ed widel y, such as in dif f er ent buil dings or dif f er ent cit ies, t hey ar e usual l y
set up int o sever al LANs t hat ar e joined t oget her int o a l ar ger st r uct ur e cal l ed a wide
ar ea net wor k, or WAN. A WAN is composed of t wo or mor e LANs. Each LAN has it s own
net wor k cabl e connect ing al l t he devices in t hat LAN. The LANs ar e joined t oget her by
anot her connect ion met hod, of t en high-speed t el ephone l ines or ver y f ast dedicat ed
net wor k cabl es cal l ed backbones, which I discuss in a moment .
One l ast point about WANs: t hey ar e of t en t r eat ed as a singl e ent it y f or
or ganizat ional pur poses. For exampl e, t he ABC Sof t war e company might have br anches
in f our dif f er ent cit ies, wit h a LAN in each cit y. Al l f our LANs ar e joined t oget her by
high-speed t el ephone l ines. However , as f ar as t he Int er net and anyone out side t he ABC
Sof t war e company ar e concer ned, t he ABC Sof t war e WAN is a singl e ent it y. (It has a
singl e domain name f or t he Int er net . Dont wor r y if you dont known what a domain is
at t his point in t ime; it r ef er s t o a singl e ent it y f or or ganizat ional pur poses on t he
Int er net , as you wil l see l at er .)
Local Area Networks
TCP/IP wor ks acr oss LANs and WANs, and t her e ar e sever al impor t ant aspect s of LAN
and WAN t opol ogies you shoul d know about . You can st ar t wit h LANs and l ook at t heir
t opol ogies. Al t hough t her e ar e many t opol ogies f or LANs, t hr ee t opol ogies ar e
dominant : bus, r ing, and hub.
The Bus Network
The bus net wor k is t he simpl est , compr ising a singl e main communicat ions pat hway wit h
each device at t ached t o t he main cabl e (bus) t hr ough a device cal l ed a t r ansceiver or
junct ion box. The bus is al so cal l ed a backbone because it r esembl es a human spine wit h
r ibs emanat ing f r om it . Fr om each t r ansceiver on t he bus, anot her cabl e (of t en ver y
shor t ) r uns t o t he device's net wor k adapt er . An exampl e of a bus net wor k is shown in
Figur e 1.1.
Figur e 1.1. A schemat ic of a bus net wor k showing t he backbone wit h t r ansceiver s
l eading t o net wor k devices.
The pr imar y advant age of a bus net wor k is t hat it al l ows f or a high-speed bus. Anot her
advant age of t he bus net wor k is t hat it is usual l y immune t o pr obl ems wit h any singl e
net wor k car d wit hin a device on t he net wor k. This is because t he t r ansceiver al l ows
t r af f ic t hr ough t he backbone whet her a device is at t ached t o t he junct ion box or not .
Each end of t he bus is t er minat ed wit h a bl ock of r esist or s or a simil ar el ect r ical device
t o mar k t he end of t he cabl e el ect r ical l y. Each device on t he pat hway has a special
ident if ying number , or addr ess, t hat l et s t he device know t hat incoming inf or mat ion is
f or t hat device.
A bus net wor k is sel dom a st r aight cabl e. Inst ead, it is usual l y t wist ed ar ound wal l s
and buil dings as needed. It does have a singl e pat hway f r om one end t o t he ot her , wit h
each end t er minat ed in some way (usual l y wit h a r esist or ). Figur e 1.1 shows a l ogical
r epr esent at ion of t he net wor k, meaning it has simpl if ied t he act ual physical appear ance
of t he net wor k int o a schemat ic wit h st r aight l ines and no r eal scal e t o t he
connect ions. A physical r epr esent at ion of t he net wor k woul d show how it goes t hr ough
wal l s, ar ound desks, and so on. Most devices on t he bus net wor k can send or r eceive
dat a al ong t he bus by packaging a message wit h t he int ended r ecipient 's addr ess.
A var iat ion of t he bus net wor k t opol ogy is f ound in many smal l LANs t hat use Thin
Et her net cabl e (which l ooks l ike t el evision coaxial cabl e) or t wist ed-pair cabl e (which
r esembl es t el ephone cabl es). This t ype of net wor k consist s of a l engt h of coaxial cabl e
t hat snakes f r om machine t o machine. Unl ike t he bus net wor k in Figur e 1.1, t her e ar e no
t r ansceiver s on t he bus. Inst ead, each device is connect ed int o t he bus dir ect l y using a T-
shaped connect or on t he net wor k int er f ace car d, of t en using a connect or cal l ed a BNC.
The connect or connect s t he machine t o t he t wo neighbor s t hr ough t wo cabl es, one t o
each neighbor . At t he ends of t he net wor k, a simpl e r esist or is added t o one side of t he T-
connect or t o t er minat e t he net wor k el ect r ical l y.
A schemat ic of t his t ype of net wor k is shown in Figur e 1.2. Each net wor k device has a T-
connect or at t ached t o t he net wor k int er f ace car d, l eading t o it s t wo neighbor s. The
t wo ends of t he bus ar e t er minat ed wit h r esist or s.
Figur e 1.2. A schemat ic of a machine-t o-machine bus net wor k.
This machine-t o-machine (al so cal l ed peer -t o-peer ) net wor k is not capabl e of sust aining
t he higher speeds of t he backbone-based bus net wor k, pr imar il y because of t he medium of
t he net wor k cabl e. A backbone net wor k can use ver y high-speed cabl es such as f iber
opt ics, wit h smal l er (and sl ower ) cabl es f r om each t r ansceiver t o t he device. A machine-
t o-machine net wor k is usual l y buil t using t wist ed-pair or coaxial cabl e because t hese
cabl es ar e much cheaper and easier t o wor k wit h. Unt il r ecent l y, machine-t o-machine
net wor ks wer e l imit ed t o a t hr oughput of about 10 Mbps (megabit s per second), al t hough
r ecent devel opment s cal l ed 100VG AnyLAN and Fast Et her net al l ow 100 Mbps on t his
t ype of net wor k.
The advant age of t his machine-t o-machine bus net wor k is it s simpl icit y. Adding new
machines t o t he net wor k means inst al l ing a net wor k car d and connect ing t he new
machine int o a l ogical pl ace on t he backbone. One major advant age of t he machine-t o-
machine bus net wor k is al so it s cost : it is pr obabl y t he l owest cost LAN t opol ogy
avail abl e. The pr obl em wit h t his t ype of bus net wor k is t hat if one machine is t aken of f
t he net wor k cabl e, or t he net wor k int er f ace car d mal f unct ions, t he backbone is br oken
and must be t ied t oget her again wit h a jumper of some sor t or t he net wor k might cease
t o f unct ion pr oper l y.
The Ring Network
A r ing net wor k t opol ogy is of t en dr awn as it s name suggest s, shaped l ike a r ing. A
t ypical r ing net wor k schemat ic is shown in Figur e 1.3. You might have hear d of a token
ring network bef or e, which is a r ing t opol ogy net wor k. You might be disappoint ed t o f ind
no physical r ing ar chit ect ur e in a r ing net wor k, t hough.
Figur e 1.3. A schemat ic of a r ing net wor k.
Despit e t he al most aut omat ic assumpt ion t hat a r ing
net wor k has a backbone wit h t he ends of t he cabl e joined t o
f or m a l oop, t her e is no r eal cabl ing r ing at al l . The r ing name
der ives f r om t he const r uct ion of t he cent r al cont r ol unit .
The t er m ring is a misnomer because r ing net wor ks don't have an unending cabl e l ike a
bus net wor k wit h t he t wo t er minat or s joined t oget her . Inst ead, t he r ing r ef er s t o t he
design of t he cent r al unit t hat handl es t he net wor k's message passing. In a t oken r ing
net wor k, t he cent r al cont r ol unit is cal l ed a Media Access Unit , or MAU. The MAU has
a r ing cir cuit inside it (f or which t he net wor k t opol ogy is named). The r ing inside t he
MAU ser ves as t he bus f or devices t o obt ain messages.
The Hub Network
A hub net wor k uses a main cabl e much l ike t he bus net wor k, which is cal l ed t he
backplane. The hub t opol ogy is shown in Figur e 1.4. Fr om t he backpl ane, a set of cabl es
l eads t o a hub, which is a box cont aining sever al por t s int o which devices ar e pl ugged.
The cabl es t o a connect ion point ar e of t en cal l ed drops, because t hey dr op f r om t he
backpl ane t o t he por t s.
Figur e 1.4. A schemat ic of a hub net wor k.
Hub net wor ks can be ver y l ar ge, using a high-speed f iber opt ic backpl ane and sl ight l y
sl ower Et her net dr ops t o hubs f r om which a wor kgr oup can be suppor t ed. The hub
net wor k can al so be smal l , wit h a coupl e of hubs suppor t ing a f ew devices connect ed
t oget her by st andar d Et her net cabl es. The hub net wor k is scal eabl e (meaning you can
st ar t smal l and expand as you need t o), which is par t of it s at t r act ion.
Hub net wor ks have become popul ar f or l ar ge inst al l at ions, in par t because t hey ar e
easy t o set up and maint ain. They al so can be t he l east expensive syst em in many l ar ger
inst al l at ions, which adds t o t heir at t r act ion. The backpl ane can ext end acr oss a
consider abl e dist ance just l ike a bus net wor k, wher eas t he por t s, or connect ion point s,
ar e usual l y gr ouped in a set pl aced in a box or panel . Ther e can be many panel s or
connect ion boxes at t ached t o t he backpl ane.
Wide Area Networks
As I ment ioned ear l ier , LANs can be combined int o a l ar ge ent it y cal l ed a WAN. WANs
ar e usual l y composed of LANs joined t oget her by a high-speed l ink (such as a t el ephone
l ine or dedicat ed cabl e). At t he ent r ance t o each LAN, one or mor e machines act as t he
l ink bet ween t he LAN and WAN: t hese ar e cal l ed gat eways. I t al k about gat eways and
t he t ypes of gat eways used in a WAN in mor e det ail on many of t he f ol l owing days, but
f or now you need t o know onl y t hat a gat eway is t he int er f ace bet ween a LAN and a
WAN. The same appl ies f or any LAN t hat accesses t he Int er net : one machine usual l y
act s as t he gat eway f r om t he LAN t o t he Int er net (which is r eal l y just a ver y l ar ge
WAN).
Many t er ms ot her t han gateway ar e al so used. You wil l hear t er ms l ike router and bridge.
They ar e al l gat eways, but t hey per f or m sl ight l y dif f er ent t asks. To under st and t heir
r ol es (which I ment ion many t imes in t he next week's mat er ial ), you need t o t ake a quick
l ook at how WANs ar e l aid out .
LANs can be t ied t o a WAN t hr ough a gat eway t hat handl es t he passage of dat a
bet ween t he LAN and WAN backbone. In a simpl e l ayout , a r out er is used t o per f or m t his
f unct ion. This is shown in Figur e 1.5.
Figur e 1.5. A r out er connect s a LAN t o t he backbone.
Anot her gat eway device, cal l ed a br idge, is used t o connect LANs using t he same
net wor k pr ot ocol . Br idges ar e used onl y when t he same net wor k pr ot ocol (such as
TCP/IP) is on bot h LANs. The br idge does not car e which physical media is used. Br idges
can connect t wist ed-pair LANs t o coaxial LANs, f or exampl e, or act as an int er f ace t o a
f iber opt ic net wor k. As l ong as t he net wor k pr ot ocol is t he same, t he br idge f unct ions
pr oper l y.
If t wo or mor e LANs ar e invol ved in one or ganizat ion and t her e is t he possibil it y of a
l ot of t r af f ic bet ween t hem, it is bet t er t o connect t he t wo LANs dir ect l y wit h a br idge
inst ead of l oading t he backbone wit h t he cr oss-t r af f ic. This is shown in Figur e 1.6.
Figur e 1.6. Using a br idge t o connect t wo LANs.
In a conf igur at ion using br idges bet ween LANs, t r af f ic f r om one LAN t o anot her can be
sent t hr ough t he br idge inst ead of ont o t he backbone, pr oviding bet t er per f or mance. For
ser vices such as Tel net and FTP, t he speed dif f er ence bet ween using a br idge and going
t hr ough a r out er ont o a heavil y used backbone can be signif icant .
WANs ar e an impor t ant subject , and I l ook at t hem again in mor e det ail on Day 13,
"Managing and Tr oubl eshoot ing TCP/IP."
Layers
Suppose you have t o wr it e a pr ogr am t hat pr ovides net wor king f unct ions t o ever y
machine on your LAN. Wr it ing a singl e sof t war e package t hat accompl ishes ever y t ask
r equir ed f or communicat ions bet ween dif f er ent comput er s woul d be a night mar ish t ask.
Apar t f r om having t o cope wit h t he dif f er ent har dwar e ar chit ect ur es, simpl y wr it ing
t he code f or al l t he appl icat ions you desir e woul d r esul t in a pr ogr am t hat was f ar t oo
l ar ge t o execut e or maint ain.
Dividing al l t he r equir ement s int o simil ar -pur pose gr oups is a sensibl e appr oach, much as
a pr ogr ammer br eaks code int o l ogical chunks. Wit h open syst ems communicat ions, gr oups
ar e quit e obvious. One gr oup deal s wit h t he t r anspor t of dat a, anot her wit h t he
packaging of messages, anot her wit h end-user appl icat ions, and so on. Each gr oup of
r el at ed t asks is cal l ed a layer.
The l ayer s of an ar chit ect ur e ar e meant t o be st and-
al one, independent ent it ies. They usual l y cannot per f or m any
obser vabl e t ask wit hout int er act ing wit h ot her l ayer s, but
f r om a pr ogr amming point of view t hey ar e sel f -cont ained.
Of cour se, some cr ossover of f unct ional it y is t o be expect ed, and sever al dif f er ent
appr oaches t o t he same division of l ayer s f or a net wor k pr ot ocol wer e pr oposed. One
t hat became adopt ed as a st andar d is t he Open Syst ems Int er connect ion Ref er ence
Model (which is discussed in mor e det ail in t he next sect ion). The OSI Ref er ence Model
(OSI-RM) uses seven l ayer s, as shown in Figur e 1.7. The TCP/IP ar chit ect ur e is simil ar but
invol ves onl y f ive l ayer s, because it combines some of t he OSI f unct ional it y in t wo
l ayer s int o one. For now, t hough, consider t he seven-l ayer OSI model .
Figur e 1.7. The OSI Ref er ence Model showing al l seven l ayer s.
The appl icat ion, pr esent at ion, and session l ayer s ar e al l appl icat ion-or ient ed in t hat
t hey ar e r esponsibl e f or pr esent ing t he appl icat ion int er f ace t o t he user . Al l t hr ee ar e
independent of t he l ayer s bel ow t hem and ar e t ot al l y obl ivious t o t he means by which
dat a get s t o t he appl icat ion. These t hr ee l ayer s ar e cal l ed t he upper l ayer s.
The l ower f our l ayer s deal wit h t he t r ansmission of dat a, cover ing t he packaging,
r out ing, ver if icat ion, and t r ansmission of each dat a gr oup. The l ower l ayer s don't
wor r y about t he t ype of dat a t hey r eceive or send t o t he appl icat ion, but deal simpl y
wit h t he t ask of sending it . They don't dif f er ent iat e bet ween t he dif f er ent appl icat ions
in any way.
The f ol l owing sect ions expl ain each l ayer t o hel p you under st and t he ar chit ect ur e of
t he OSI-RM (and l at er cont r ast it wit h t he ar chit ect ur e of TCP/IP).
The Application Layer
The appl icat ion l ayer is t he end-user int er f ace t o t he OSI syst em. It is wher e t he
appl icat ions, such as el ect r onic mail , USENET news r eader s, or dat abase displ ay modul es,
r eside. The appl icat ion l ayer 's t ask is t o displ ay r eceived inf or mat ion and send t he user 's
new dat a t o t he l ower l ayer s.
In dist r ibut ed appl icat ions, such as cl ient /ser ver syst ems, t he appl icat ion l ayer is wher e
t he cl ient appl icat ion r esides. It communicat es t hr ough t he l ower l ayer s t o t he ser ver .
The Presentation Layer
The pr esent at ion l ayer 's t ask is t o isol at e t he l ower l ayer s f r om t he appl icat ion's dat a
f or mat . It conver t s t he dat a f r om t he appl icat ion int o a common f or mat , of t en cal l ed
t he canonical representation. The pr esent at ion l ayer pr ocesses machine-dependent dat a
f r om t he appl icat ion l ayer int o a machine-independent f or mat f or t he l ower l ayer s.
The pr esent at ion l ayer is wher e f il e f or mat s and even char act er f or mat s (ASCII and
EBCDIC, f or exampl e) ar e l ost . The conver sion f r om t he appl icat ion dat a f or mat t akes
pl ace t hr ough a "common net wor k pr ogr amming l anguage" (as it is cal l ed in t he OSI
Ref er ence Model document s) t hat has a st r uct ur ed f or mat .
The pr esent at ion l ayer does t he r ever se f or incoming dat a. It is conver t ed f r om t he
common f or mat int o appl icat ion-specif ic f or mat s, based on t he t ype of appl icat ion t he
machine has inst r uct ions f or . If t he dat a comes in wit hout r ef or mat t ing inst r uct ions,
t he inf or mat ion might not be assembl ed in t he cor r ect manner f or t he user 's appl icat ion.
The Session Layer
The session l ayer or ganizes and synchr onizes t he exchange of dat a bet ween appl icat ion
pr ocesses. It wor ks wit h t he appl icat ion l ayer t o pr ovide simpl e dat a set s cal l ed
synchronization points t hat l et an appl icat ion know how t he t r ansmission and r ecept ion of
dat a ar e pr ogr essing. In simpl if ied t er ms, t he session l ayer can be t hought of as a t iming
and f l ow cont r ol l ayer .
The session l ayer is invol ved in coor dinat ing communicat ions bet ween dif f er ent
appl icat ions, l et t ing each know t he st at us of t he ot her . An er r or in one appl icat ion
(whet her on t he same machine or acr oss t he count r y) is handl ed by t he session l ayer t o
l et t he r eceiving appl icat ion know t hat t he er r or has occur r ed. The session l ayer can
r esynchr onize appl icat ions t hat ar e cur r ent l y connect ed t o each ot her . This can be
necessar y when communicat ions ar e t empor ar il y int er r upt ed, or when an er r or has
occur r ed t hat r esul t s in l oss of dat a.
The Transport Layer
The t r anspor t l ayer , as it s name suggest s, is designed t o pr ovide t he "t r anspar ent
t r ansf er of dat a f r om a sour ce end open syst em t o a dest inat ion end open syst em,"
accor ding t o t he OSI Ref er ence Model . The t r anspor t l ayer est abl ishes, maint ains, and
t er minat es communicat ions bet ween t wo machines.
The t r anspor t l ayer is r esponsibl e f or ensur ing t hat dat a sent mat ches t he dat a
r eceived. This ver if icat ion r ol e is impor t ant in ensur ing t hat dat a is cor r ect l y sent , wit h
a r esend if an er r or was det ect ed. The t r anspor t l ayer manages t he sending of dat a,
det er mining it s or der and it s pr ior it y.
The Network Layer
The net wor k l ayer pr ovides t he physical r out ing of t he dat a, det er mining t he pat h
bet ween t he machines. The net wor k l ayer handl es al l t hese r out ing issues, r el ieving
t he higher l ayer s f r om t his issue.
The net wor k l ayer examines t he net wor k t opol ogy t o det er mine t he best r out e t o send
a message, as wel l as f igur ing out r el ay syst ems. It is t he onl y net wor k l ayer t hat sends
a message f r om sour ce t o t ar get machine, managing ot her chunks of dat a t hat pass
t hr ough t he syst em on t heir way t o anot her machine.
The Data Link Layer
The dat a l ink l ayer , accor ding t o t he OSI r ef er ence paper , "pr ovides f or t he cont r ol of
t he physical l ayer , and det ect s and possibl y cor r ect s er r or s t hat can occur ." In
pr act ical it y, t he dat a l ink l ayer is r esponsibl e f or cor r ect ing t r ansmission er r or s
induced dur ing t r ansmission (as opposed t o er r or s in t he appl icat ion dat a it sel f , which
ar e handl ed in t he t r anspor t l ayer ).
The dat a l ink l ayer is usual l y concer ned wit h signal int er f er ence on t he physical
t r ansmission media, whet her t hr ough copper wir e, f iber opt ic cabl e, or micr owave.
Int er f er ence is common, r esul t ing f r om many sour ces, incl uding cosmic r ays and st r ay
magnet ic int er f er ence f r om ot her sour ces.
The Physical Layer
The physical l ayer is t he l owest l ayer of t he OSI model and deal s wit h t he "mechanical ,
el ect r ical , f unct ional , and pr ocedur al means" r equir ed f or t r ansmission of dat a,
accor ding t o t he OSI def init ion. This is r eal l y t he wir ing or ot her t r ansmission f or m.
When t he OSI model was being devel oped, a l ot of concer n deal t wit h t he l ower t wo
l ayer s, because t hey ar e, in most cases, insepar abl e. The r eal wor l d t r eat s t he dat a l ink
l ayer and t he physical l ayer as one combined l ayer , but t he f or mal OSI def init ion
st ipul at es dif f er ent pur poses f or each. (TCP/IP incl udes t he dat a l ink and physical
l ayer s as one l ayer , r ecognizing t hat t he division is mor e academic t han pr act ical .)
Terminology and Notations
Bot h OSI and TCP/IP ar e r oot ed in f or mal descr ipt ions, pr esent ed as a ser ies of compl ex
document s t hat def ine al l aspect s of t he pr ot ocol s. To def ine OSI and TCP/IP, sever al
new t er ms wer e devel oped and int r oduced int o use; some (most l y OSI t er ms) ar e r at her
unusual . You might f ind t he t er m OSI-speak used t o r ef er t o some of t hese r at her
gr ot esque def init ions, much as legalese r ef er s t o l egal t er ms.
To bet t er under st and t he det ail s of TCP/IP, it is necessar y t o deal wit h t hese t er ms now.
You won't see al l t hese t er ms in t his book, but you might encount er t hem when r eading
manual s or onl ine document at ion. Ther ef or e, al l t he major t er ms ar e cover ed her e.
Many of t he t er ms used by bot h OSI and TCP/IP might seem
t o have mul t ipl e meanings, but t her e is a def init e at t empt t o
pr ovide a singl e, consist ent def init ion f or each wor d.
Unf or t unat el y, t he user communit y is sl ow t o adopt new
t er minol ogy, so t her e is a consider abl e amount of conf usion.
Packets
To t r ansf er dat a ef f ect ivel y, many exper iment s have shown t hat cr eat ing a unif or m
chunk of dat a is bet t er t han sending char act er s singl y or in widel y var ying sized
gr oups. Usual l y t hese chunks of dat a have some inf or mat ion ahead of t hem (t he header)
and somet imes an indicat or at t he end (t he trailer). These chunks of dat a ar e cal l ed
packets in most synchr onous communicat ions syst ems.
The amount of dat a in a packet and t he composit ion of t he header can change depending
on t he communicat ions pr ot ocol as wel l as some syst em l imit at ions, but t he concept of a
packet al ways r ef er s t o t he ent ir e set (incl uding header and t r ail er ). The t er m packet is
used of t en in t he comput er indust r y, somet imes when it shoul dn't be.
You of t en see t he wor d packet used as a gener ic r ef er ence t o any gr oup of dat a packaged
f or t r ansmission. As an appl icat ion's dat a passes t hr ough t he l ayer s of t he ar chit ect ur e,
each adds mor e inf or mat ion. The t er m packet is f r equent l y used at each st age. Tr eat t he
t er m packet as a gener al izat ion f or any dat a wit h addit ional inf or mat ion, inst ead of t he
specif ic r esul t of onl y one l ayer 's addit ion of header and t r ail er . This goes against t he
ef f or t s of bot h OSI and t he TCP gover ning bodies, but it hel ps keep your sanit y int act !
Subsystems
A subsystem is t he col l ect ive of a par t icul ar l ayer acr oss a net wor k. For exampl e, if 10
machines ar e connect ed t oget her , each r unning t he seven-l ayer OSI model , al l 10
appl icat ion l ayer s ar e t he appl icat ion subsyst em, al l 10 dat a l ink l ayer s ar e t he dat a
l ink subsyst em, and so on. As you might have al r eady deduced, wit h t he OSI Ref er ence
Model t her e ar e seven subsyst ems.
It is ent ir el y possibl e (and even l ikel y) t hat al l t he individual component s in a
subsyst em wil l not be act ive at one t ime. Using t he 10-machine exampl e again, onl y t hr ee
might have t he dat a l ink l ayer act ual l y act ive at any moment in t ime, but t he
cumul at ive of al l t he machines makes up t he subsyst em.
Entities
A l ayer can have mor e t han one par t t o it . For exampl e, t he t r anspor t l ayer can have
r out ines t hat ver if y checksums as wel l as r out ines t hat handl e r esending packet s t hat
didn't t r ansf er cor r ect l y. Not al l t hese r out ines ar e act ive at once, because t hey might
not be r equir ed at any moment . The act ive r out ines, t hough, ar e cal l ed ent it ies. The
wor d entity was adopt ed in or der t o f ind a singl e t er m t hat coul d not be conf used wit h
anot her comput er t er m such as modul e, pr ocess, or t ask.
N Notation
The not at ions N, N+1, N+2, and so on ar e used t o ident if y a l ayer and t he l ayer s t hat
ar e r el at ed t o it . Ref er r ing t o Figur e 1.7, if t he t r anspor t l ayer is l ayer N, t he physical
l ayer is N3 and t he pr esent at ion l ayer is N+2. Wit h OSI, N al ways has a val ue of 1
t hr ough 7 incl usive.
One r eason t his not at ion was adopt ed was t o enabl e wr it er s t o r ef er t o ot her l ayer s
wit hout having t o wr it e out t heir names ever y t ime. It al so makes f l ow char t s and
diagr ams of int er act ions a l it t l e easier t o dr aw. The t er ms N+1 and N1 ar e commonl y
used in bot h OSI and TCP f or t he l ayer s above and bel ow t he cur r ent l ayer ,
r espect ivel y, as you wil l see.
To make t hings even mor e conf using, many OSI st andar ds r ef er t o a l ayer by t he f ir st
l et t er of it s name. This can l ead t o a r eal mess f or t he casual r eader , because "S-ent it y,"
"5-ent it y," and "l ayer 5" al l r ef er t o t he session l ayer .
N-Functions
Each l ayer per f or ms N-f unct ions. The f unct ions ar e t he dif f er ent t hings t he l ayer does.
Ther ef or e, t he f unct ions of t he t r anspor t l ayer ar e t he dif f er ent t asks t hat t he l ayer
pr ovides. For most pur poses in t his book, f unct ions and ent it ies mean t he same t hing.
N-Facilities
This uses t he hier ar chical l ayer st r uct ur e t o expr ess t he idea t hat one l ayer pr ovides a
set of f acil it ies t o t he next higher l ayer . This is sensibl e, because t he appl icat ion l ayer
expect s t he pr esent at ion l ayer t o pr ovide a r obust , wel l -def ined set of f acil it ies t o it . In
OSI-speak, t he (N+1)-ent it ies assume a def ined set of N-f acil it ies f r om t he N-ent it y.
Services
The ent ir e set of N-f acil it ies pr ovided t o t he (N+1)-ent it ies is cal l ed t he N-ser vice. In
ot her wor ds, t he ser vice is t he ent ir e set of N-f unct ions pr ovided t o t he next higher
l ayer . Ser vices might seem l ike f unct ions, but t her e is a f or mal dif f er ence bet ween t he
t wo. The OSI document s go t o gr eat l engt hs t o pr ovide det ail ed descr ipt ions of ser vices,
wit h a "ser vice def init ion st andar d" f or each l ayer . This was necessar y dur ing t he
devel opment of t he OSI st andar d so t hat t he dif f er ent t asks invol ved in t he
communicat ions pr ot ocol coul d be assigned t o dif f er ent l ayer s, and so t hat t he
f unct ions of each l ayer ar e bot h wel l -def ined and isol at ed f r om ot her l ayer s.
The ser vice def init ions ar e f or mal l y devel oped f r om t he bot t om l ayer (physical ) upwar d
t o t he t op l ayer . The advant age of t his appr oach is t hat t he design of t he N+1 l ayer can
be based on t he f unct ions per f or med in t he N l ayer , avoiding t wo f unct ions t hat
accompl ish t he same t ask in t wo adjacent l ayer s.
An ent ir e set of var iat ions on t he ser vice name has been devel oped t o appl y t hese
def init ions, some of which ar e in r egul ar use:
An N-ser vice user is a user of a ser vice pr ovided by t he N l ayer t o t he next higher (N+1)
l ayer .
An N-ser vice pr ovider is t he set of N-ent it ies t hat ar e invol ved in pr oviding t he N l ayer
ser vice.
An N-ser vice access point (of t en abbr eviat ed t o N-SAP) is wher e an N-ser vice is pr ovided
t o an (N+1)-ent it y by t he N-ser vice pr ovider .
N-ser vice dat a is t he packet of dat a exchanged at an N-SAP.
N-ser vice dat a unit s (N-SDUs) ar e t he individual unit s of dat a
exchanged at an N-SAP (so t hat N-ser vice dat a is made up of N-
SDUs).
These t er ms ar e shown in Figur e 1.8. Anot her common t er m is encapsulation, which is t he
addit ion of cont r ol inf or mat ion t o a packet of dat a. The cont r ol dat a cont ains
addr essing det ail s, checksums f or er r or det ect ion, and pr ot ocol cont r ol f unct ions.
Figur e 1.8. Ser vice pr ovider s and ser vice user s communicat e t hr ough ser vice access
point s.
Making Sense of the Jargon
It is impor t ant t o r emember t hat al l t hese t er ms ar e used in a f or mal descr ipt ion,
because a f or mal l anguage is usual l y t he onl y met hod t o adequat el y descr ibe
somet hing as compl ex as a communicat ions pr ot ocol . It is possibl e, t hough, t o f it t hese
t er ms t oget her so t hat t hey make a l it t l e mor e sense when you encount er t hem. An
exampl e shoul d hel p.
The session l ayer has a set of session f unct ions. It pr ovides a set of session f acil it ies t o
t he l ayer above it , t he pr esent at ion l ayer . The session l ayer is made up of session
ent it ies. The pr esent at ion l ayer is a user of t he ser vices pr ovided by t he session l ayer
(l ayer 5). A pr esent at ion ent it y is a user of t he ser vices pr ovided by t he session l ayer and
is cal l ed a pr esent at ion ser vice user .
The session ser vice pr ovider is t he col l ect ion of session ent it ies t hat ar e act ivel y
invol ved in pr oviding t he pr esent at ion l ayer wit h t he session's ser vices. The point at
which t he session ser vice is pr ovided t o t he pr esent at ion l ayer is t he session ser vice
access point , wher e t he session ser vice dat a is sent . The individual bit s of dat a in t he
session ser vice dat a ar e cal l ed session ser vice dat a unit s.
Conf using? Bel ieve it or not , af t er a whil e you wil l begin t o f eel mor e comf or t abl e
wit h t hese t er ms. The impor t ant ones t o know now ar e t hat a l ayer pr ovides a set of
ent it ies t hr ough a ser vice access point t o t he next higher l ayer , which is cal l ed t he
ser vice user . The dat a is sent in chunks cal l ed ser vice dat a, made up of ser vice dat a
unit s.
Queues and Connections
Communicat ion bet ween t wo par t ies (whet her over a t el ephone, bet ween l ayer s of an
ar chit ect ur e, or bet ween appl icat ions t hemsel ves) t akes pl ace in t hr ee dist inct st ages:
est abl ishment of t he connect ion, dat a t r ansf er , and connect ion t er minat ion.
Communicat ion bet ween t wo OSI appl icat ions in t he same l ayer is t hr ough queues t o t he
l ayer beneat h t hem. Each appl icat ion (mor e pr oper l y cal l ed a ser vice user ) has t wo
queues, one f or each dir ect ion t o t he ser vice pr ovider of t he l ayer beneat h (which
cont r ol s t he whol e l ayer ). In OSI-speak, t he t wo queues pr ovide f or simul t aneous (or
atomic) int er act ions bet ween t wo N-ser vice act ion point s.
Dat a, cal l ed service primitives, is put int o and r et r ieved f r om t he queue by t he
appl icat ions (ser vice user s). A ser vice pr imit ive can be a bl ock of dat a, an indicat or t hat
somet hing is r equir ed or r eceived, or a st at us indicat or . As wit h most aspect s of OSI, a
l exicon has been devel oped t o descr ibe t he act ions in t hese queues:
A request primitive is when one ser vice submit s a ser vice pr imit ive t o t he queue (t hr ough
t he N-SAP) r equest ing per mission t o communicat e wit h anot her ser vice in t he same l ayer .
An indication primitive is what t he ser vice pr ovider in t he l ayer beneat h t he sending
appl icat ion sends t o t he int ended r eceiving appl icat ion t o l et it know t hat
communicat ion is desir ed.
A response primitive is sent by t he r eceiving appl icat ion t o t he l ayer beneat h's ser vice
pr ovider t o acknowl edge t he gr ant ing of communicat ions bet ween t he t wo ser vice user s.
A confirmation primitive is sent f r om t he ser vice pr ovider t o t he
f inal appl icat ion t o indicat e t hat bot h appl icat ions on t he
l ayer above can now communicat e.
An exampl e might hel p cl ar if y t he pr ocess. Assume t hat t wo appl icat ions in t he
pr esent at ion l ayer want t o communicat e wit h each ot her . They can't do so dir ect l y
(accor ding t o t he OSI model ), so t hey must go t hr ough t he l ayer bel ow t hem. These st eps
ar e shown in Figur e 1.9.
Figur e 1.9. Two appl icat ions communicat e t hr ough SAPs using pr imit ives.
The f ir st appl icat ion sends a r equest pr imit ive t o t he ser vice pr ovider of t he session
l ayer and wait s. The session l ayer 's ser vice pr ovider r emoves t he r equest pr imit ive f r om
t he inbound queue f r om t he f ir st appl icat ion and sends an indicat ion pr imit ive t o t he
second appl icat ion's inbound queue.
The second appl icat ion t akes t he indicat ion pr imit ive f r om it s queue t o t he session
ser vice pr ovider and decides t o accept t he r equest f or connect ion by sending a posit ive
r esponse pr imit ive back t hr ough it s queue t o t he session l ayer . This is r eceived by t he
session l ayer ser vice pr ovider , and a conf ir mat ion pr imit ive is sent t o t he f ir st
appl icat ion in t he pr esent at ion l ayer . This is a pr ocess cal l ed confirmed service because
t he appl icat ions wait f or conf ir mat ion t hat communicat ions ar e est abl ished and r eady.
OSI al so pr ovides f or unconfirmed service, in which a r equest pr imit ive is sent t o t he ser vice
pr ovider , sending t he indicat ion pr imit ive t o t he second appl icat ion. The r esponse and
conf ir mat ion pr imit ives ar e not sent . This is a sor t of "get r eady, because her e it comes
whet her you want it or not " communicat ion, of t en r ef er r ed t o as send and pray.
When t wo ser vice user s ar e using conf ir med ser vice t o communicat e, t hey ar e consider ed
connect ed. Two appl icat ions ar e t al king t o each ot her , awar e of what t he ot her is
doing wit h t he ser vice dat a. OSI r ef er s t o t he est abl ishment and maint enance of state
information bet ween t he t wo, or t he f act t hat each knows when t he ot her is sending or
r eceiving. OSI cal l s t his connection-oriented or connection-mode communicat ions.
Connectionless communicat ion is when ser vice dat a is sent independent l y, as wit h
unconf ir med ser vice. The ser vice dat a is sel f -cont ained, possessing ever yt hing a r eceiving
ser vice user needs t o know. These ser vice dat a packet s ar e of t en cal l ed datagrams. The
appl icat ion t hat sends t he dat agr am has no idea who r eceives t he dat agr am and how it is
handl ed, and t he r eceiving ser vice user s have no idea who sent it (ot her t han
inf or mat ion t hat might be cont ained wit hin t he dat agr am it sel f ). OSI cal l s t his
connectionless-mode.
OSI (and TCP/IP) use bot h connect ed and connect ionl ess syst ems bet ween l ayer s of t heir
ar chit ect ur e. Each has it s benef it s and ideal impl ement at ions. Al l t hese communicat ions
ar e bet ween appl icat ions (ser vice user s) in each l ayer , using t he l ayer beneat h t o
communicat e. Ther e ar e many ser vice user s, and t his pr ocess is going on al l t he t ime. It 's
quit e amazing when you t hink about it .
Standards
Peopl e don't quest ion t he need f or r ul es in a boar d game. If you didn't have r ul es, each
pl ayer coul d be happil y pl aying as it suit s t hem, r egar dl ess of whet her t heir pl ay was
consist ent wit h t hat of ot her pl ayer s. The exist ence of r ul es ensur es t hat each pl ayer
pl ays t he game in t he same way, which might not be as much f un as a f r ee-f or -al l .
However , when a f ight over a pl ayer 's act ions ar ises, t he wr it t en r ul es cl ear l y indicat e
who is r ight . The r ul es ar e a set of st andar ds by which a game is pl ayed.
St andar ds pr event a sit uat ion ar ising wher e t wo seemingl y compat ibl e syst ems r eal l y
ar e not . For exampl e, 10 year s ago when CP/M was t he dominant oper at ing syst em, t he
5.25-inch f l oppy was used by most syst ems. But t he f l oppy f r om a Kaypr o II coul dn't be
r ead by an Osbour ne I because t he t r acks wer e l aid out in a dif f er ent manner . A ut il it y
pr ogr am coul d conver t bet ween t he t wo, but t hat ext r a st ep was a major annoyance f or
machine user s.
When t he IBM PC became t he pl at f or m of choice, t he 5.25-inch f or mat used by t he IBM
PC was adopt ed by ot her companies t o ensur e disk compat ibil it y. The IBM f or mat became
a de f act o st andar d, one adopt ed because of mar ket pr essur es and cust omer demand.
Setting Standards
Cr eat ing a st andar d in t oday's wor l d is not a simpl e mat t er . Sever al or ganizat ions ar e
dedicat ed t o devel oping t he st andar ds in a compl et e, unambiguous manner . The most
impor t ant of t hese is t he Int er nat ional Or ganizat ion f or St andar dizat ion, or ISO (of t en
cal l ed t he Int er nat ional St andar dizat ion Or ganizat ion t o f it t heir acr onym, al t hough
t his is incor r ect ). ISO consist s of st andar ds or ganizat ions f r om many count r ies who t r y
t o agr ee on int er nat ional cr it er ion. The Amer ican Nat ional St andar ds Inst it ut e (ANSI),
Br it ish St andar ds Inst it ut e (BSI), Deut sches Inst it ut f ur Nor mung (DIN), and Associat ion
Fr ancaise du Nor mal izat ion (AFNOR) ar e al l member gr oups. The ISO devel oped t he Open
Syst ems Int er connect ion (OSI) st andar d t hat is discussed t hr oughout t his book.
Each nat ion's st andar ds or ganizat ion can cr eat e a st andar d f or t hat count r y, of
cour se. The goal of ISO, however , is t o agr ee on wor l dwide st andar ds. Ot her wise,
incompat ibil it ies coul d exist t hat woul dn't al l ow one count r y's syst em t o be used in
anot her . (An exampl e of t his is wit h t el evision signal s: t he US r el ies on NTSC, wher eas
Eur ope uses PALsyst ems t hat ar e incompat ibl e wit h each ot her .)
Cur iousl y, t he l anguage used f or most int er nat ional st andar ds is Engl ish, even t hough
t he major it y of par t icipant s in a st andar ds commit t ee ar e not f r om Engl ish-speaking
count r ies. This can cause quit e a bit of conf usion, especial l y because most st andar ds ar e
wor ded awkwar dl y t o begin wit h.
The r eason most st andar ds invol ve awkwar d l anguage is t hat t o descr ibe somet hing
unambiguousl y can be ver y dif f icul t , somet imes necessit at ing t he cr eat ion of new t er ms
t hat t he st andar d def ines. Not onl y must t he concept s be cl ear l y def ined, but t he
absol ut e behavior is necessar y t oo. Wit h most t hings t hat st andar ds appl y t o, t his means
using number s and physical t er ms t o pr ovide a concr et e def init ion. Def ining a 2x4 piece of
l umber necessit at es t he use of a measur ement of some sor t , and simil ar l y def ining
comput er t er ms r equir es mat hemat ics.
Simpl y def ining a met hod of communicat ions, such as TCP/IP, woul d be f air l y
st r aight f or war d if it wer en't f or t he compl icat ion of def ining it f or open syst ems. The
use of an open syst em adds anot her dif f icul t y because al l aspect s of t he st andar d must
be machine-independent . Imagine t r ying t o def ine a 2x4 wit hout using a measur ement you
ar e f amil iar wit h, such as inches, or if inches ar e adopt ed, it woul d be dif f icul t t o def ine
inches in an unambiguous way (which indeed is what happens, because most unit s of
l engt h ar e def ined wit h r espect t o t he wavel engt h of a par t icul ar kind of coher ent
l ight ).
Comput er s communicat e t hr ough bit s of dat a, but t hose bit s can r epr esent char act er s,
number s, or somet hing el se. Number s coul d be int eger s, f r act ions, or oct al
r epr esent at ions. Again, you must def ine t he unit s. You can see t hat t he compl icat ions
mount , one on t op of t he ot her .
To hel p def ine a st andar d, an abst r act appr oach is usual l y used. In t he case of OSI, t he
meaning (cal l ed t he semant ics) of t he dat a t r ansf er r ed (t he abst r act synt ax) is f ir st
deal t wit h, and t he exact r epr esent at ion of t he dat a in t he machine (t he concr et e
synt ax) and t he means by which it is t r ansf er r ed (t r ansf er synt ax) ar e handl ed
separ at el y. The separ at ion of t he abst r act l et s t he dat a be r epr esent ed as an ent it y,
wit hout concer n f or what it r eal l y means. It 's a l it t l e l ike t r eat ing your car as a unit
inst ead of an engine, t r ansmission, st eer ing wheel , and so on. The abst r act ion of t he
det ail s t o a simpl er whol e makes it easier t o convey inf or mat ion. ("My car is br oken" is
abst r act , wher eas "t he power st eer ing f l uid has al l l eaked out " is concr et e.)
To descr ibe syst ems abst r act l y, it is necessar y t o have a l anguage t hat meet s t he
pur pose. Most st andar ds bodies have devel oped such a syst em. The most commonl y used is
ISO's Abst r act Synt ax Not at ion One, f r equent l y shor t ened t o ASN.1. It is suit ed
especial l y f or descr ibing open syst ems net wor king. Thus, it 's not sur pr ising t o f ind it used
ext ensivel y in t he OSI and TCP descr ipt ions. Indeed, ASN.1 was devel oped concur r ent l y
wit h t he OSI st andar ds when it became necessar y t o descr ibe upper -l ayer f unct ions.
The pr imar y concept of ASN.1 is t hat al l t ypes of dat a, r egar dl ess of t ype, size, or igin, or
pur pose, can be r epr esent ed by an object t hat is independent of t he har dwar e, oper at ing
syst em sof t war e, or appl icat ion. The ASN.1 syst em def ines t he cont ent s of a dat agr am
pr ot ocol header t he chunk of inf or mat ion at t he beginning of an object t hat descr ibes
t he cont ent s t o t he syst em. (Header s ar e discussed in mor e det ail in t he sect ion t it l ed
"Pr ot ocol Header s" l at er in t his chapt er .)
Par t of ASN.1 descr ibes t he l anguage used t o descr ibe object s and dat a t ypes (such as a
dat a descr ipt ion l anguage in dat abase t er minol ogy). Anot her par t def ines t he basic
encoding r ul es t hat deal wit h moving t he dat a object s bet ween syst ems. ASN.1 def ines
dat a t ypes t hat ar e used in t he const r uct ion of dat a packet s (dat agr ams). It pr ovides f or
bot h st r uct ur ed and unst r uct ur ed dat a t ypes, wit h a l ist of 28 suppor t ed t ypes.
Don't be t oo wor r ied about l ear ning ASN.1 in t his book. I
r ef er t o it in passing in onl y a coupl e of pl aces. It is usef ul ,
t hough, t o know t hat t he l anguage is pr ovided f or t he f or mal
def init ion of al l t he aspect s of TCP/IP.
Internet Standards
When t he Def ense Advanced Resear ch Pr oject s Agency (DARPA) was est abl ished in 1980,
a gr oup was f or med t o devel op a set of st andar ds f or t he Int er net . The gr oup, cal l ed t he
Int er net Conf igur at ion Cont r ol Boar d (ICCB) was r eor ganized int o t he Int er net
Act ivit ies Boar d (IAB) in 1983, whose t ask was t o design, engineer , and manage t he
Int er net .
In 1986, t he IAB t ur ned over t he t ask of devel oping t he Int er net st andar ds t o t he
Int er net Engineer ing Task For ce (IETF), and t he l ong-t er m r esear ch was assigned t o t he
Int er net Resear ch Task For ce (IRTF). The IAB r et ained f inal aut hor izat ion over
anyt hing pr oposed by t he t wo t ask f or ces.
The l ast st ep in t his saga was t he f or mat ion of t he Int er net Societ y in 1992, when t he
IAB was r enamed t he Int er net Ar chit ect ur e Boar d. This gr oup is st il l r esponsibl e f or
exist ing and f ut ur e st andar ds, r epor t ing t o t he boar d of t he Int er net Societ y.
Af t er al l t hat , what happened dur ing t he shuf f l ing? Al most f r om t he beginning, t he
Int er net was def ined as "a l oosel y or ganized int er nat ional col l abor at ion of
aut onomous, int er connect ed net wor ks," which suppor t ed host -t o-host communicat ions
"t hr ough vol unt ar y adher ence t o open pr ot ocol s and pr ocedur es" def ined in a t echnical
paper cal l ed t he Int er net St andar ds, RFC 1310,2. That def init ion is st il l used t oday.
The IETF cont inues t o wor k on r ef ining t he st andar ds used f or communicat ions over t he
Int er net t hr ough a number of wor king gr oups, each one dedicat ed t o a specif ic aspect of
t he over al l Int er net pr ot ocol suit e. Ther e ar e wor king gr oups dedicat ed t o net wor k
management , secur it y, user ser vices, r out ing, and many mor e t hings. It is int er est ing t hat
t he IETF's gr oups ar e consider abl y mor e f l exibl e and ef f icient t han t hose of , say, t he
ISO, whose wor king gr oups can t ake year s t o agr ee on a st andar d. In many cases, t he
IETF's gr oups can f or m, cr eat e a r ecommendat ion, and disband wit hin a year or so. This
hel ps cont inuousl y r ef ine t he Int er net st andar ds t o r ef l ect changing har dwar e and
sof t war e capabil it ies.
Cr eat ing a new Int er net st andar d (which happened wit h TCP/IP) f ol l ows a wel l -def ined
pr ocess, shown schemat ical l y in Figur e 1.10. It begins wit h a r equest f or comment (RFC).
This is usual l y a document cont aining a specif ic pr oposal , somet imes new and somet imes a
modif icat ion of an exist ing st andar d. RFCs ar e widel y dist r ibut ed, bot h on t he net wor k
it sel f and t o int er est ed par t ies as pr int ed document s. Impor t ant RFCs and inst r uct ions
f or r et r ieving t hem ar e incl uded in t he appendixes at t he end of t his book.
Figur e 1.10. The pr ocess f or adopt ing a new Int er net st andar d.
The RFC is usual l y discussed f or a whil e on t he net wor k it sel f , wher e anyone can
expr ess t heir opinion, as wel l as in f or mal IETF wor king gr oup meet ings. Af t er a suit abl e
amount of r evision and cont inued discussion, an Internet draft is cr eat ed and dist r ibut ed.
This dr af t is cl ose t o f inal f or m, pr oviding a consol idat ion of al l t he comment s t he RFC
gener at ed.
The next st ep is usual l y a proposed standard, which r emains as such f or at l east six
mont hs. Dur ing t his t ime, t he Int er net Societ y r equir es at l east t wo independent and
int er oper abl e impl ement at ions t o be wr it t en and t est ed. Any pr obl ems ar ising f r om t he
act ual t est s can t hen be addr essed. (In pr act ice, it is usual f or many impl ement at ions t o
be wr it t en and given a t hor ough t est ing.)
Af t er t hat t est ing and r ef inement pr ocess is compl et ed, a draft standard is wr it t en, which
r emains f or at l east f our mont hs, dur ing which t ime many mor e impl ement at ions ar e
devel oped and t est ed. The l ast st epaf t er many mont hsis t he adopt ion of t he
st andar d, at which point it is impl ement ed by al l sit es t hat r equir e it .
Protocols
Dipl omat s f ol l ow r ul es when t hey conduct business bet ween nat ions, which you see
r ef er r ed t o in t he media as pr ot ocol . Dipl omat ic pr ot ocol r equir es t hat you don't insul t
your host s and t hat you do r espect l ocal cust oms (even if t hat means you have t o eat
some unappet izing dinner s!). Most embassies and commissions have special ist s in pr ot ocol ,
whose f unct ion is t o ensur e t hat ever yt hing pr oceeds smoot hl y when communicat ions
ar e t aking pl ace. The pr ot ocol is a set of r ul es t hat must be f ol l owed in or der t o "pl ay
t he game," as car eer dipl omat s ar e f ond of saying. Wit hout t he pr ot ocol s, one side of t he
conver sat ion might not r eal l y under st and what t he ot her is saying.
Simil ar l y, comput er pr ot ocol s def ine t he manner in which communicat ions t ake pl ace. If
one comput er is sending inf or mat ion t o anot her and t hey bot h f ol l ow t he pr ot ocol
pr oper l y, t he message get s t hr ough, r egar dl ess of what t ypes of machines t hey ar e and
what oper at ing syst ems t hey r un (t he basis f or open syst ems). As l ong as t he machines
have sof t war e t hat can manage t he pr ot ocol , communicat ions ar e possibl e. Essent ial l y,
a comput er pr ot ocol is a set of r ul es t hat coor dinat es t he exchange of inf or mat ion.
Pr ot ocol s have devel oped f r om ver y simpl e pr ocesses ("I'l l send you one char act er , you
send it back, and I'l l make sur e t he t wo mat ch") t o el abor at e, compl ex mechanisms t hat
cover al l possibl e pr obl ems and t r ansf er condit ions. A t ask such as sending a message
f r om one coast t o anot her can be ver y compl ex when you consider t he manner in which
it moves. A singl e pr ot ocol t o cover al l aspect s of t he t r ansf er woul d be t oo l ar ge,
unwiel dy, and over l y special ized. Ther ef or e, sever al pr ot ocol s have been devel oped,
each handl ing a specif ic t ask.
Combining sever al pr ot ocol s, each wit h t heir own dedicat ed pur poses, woul d be a
night mar e if t he int er act ions bet ween t he pr ot ocol s wer e not cl ear l y def ined. The
concept of a l ayer ed st r uct ur e was devel oped t o hel p keep each pr ot ocol in it s pl ace
and t o def ine t he manner of int er act ion bet ween each pr ot ocol (essent ial l y, a pr ot ocol
f or communicat ions bet ween pr ot ocol s!).
As you saw ear l ier , t he ISO has devel oped a l ayer ed pr ot ocol syst em cal l ed OSI. OSI
def ines a pr ot ocol as "a set of r ul es and f or mat s (semant ic and synt act ic), which
det er mines t he communicat ion behavior of N-ent it ies in t he per f or mance of N-f unct ions."
You might r emember t hat N r epr esent s a l ayer , and an ent it y is a ser vice component of a
l ayer .
When machines communicat e, t he r ul es ar e f or mal l y def ined and account f or possibl e
int er r upt ions or f aul t s in t he f l ow of inf or mat ion, especial l y when t he f l ow is
connect ionl ess (no f or mal connect ion bet ween t he t wo machines exist s). In such a
syst em, t he abil it y t o pr oper l y r out e and ver if y each packet of dat a (dat agr am) is
vit al l y impor t ant . As discussed ear l ier , t he dat a sent bet ween l ayer s is cal l ed a ser vice
dat a unit (SDU), so OSI def ines t he anal ogous dat a bet ween t wo machines as a pr ot ocol
dat a unit (PDU).
The f l ow of inf or mat ion is cont r ol l ed by a set of act ions t hat def ine t he st at e machine
f or t he pr ot ocol . OSI def ines t hese act ions as pr ot ocol cont r ol inf or mat ion (PCI).
Breaking Data Apart
It is necessar y t o int r oduce a f ew mor e t er ms commonl y used in OSI and TCP/IP, but
l uckil y t hey ar e r eadil y under st ood because of t heir r eal -wor l d connot at ions. These
t er ms ar e necessar y because dat a doesn't usual l y exist in manageabl e chunks. The dat a
might have t o be br oken down int o smal l er sect ions, or sever al smal l sect ions can be
combined int o a l ar ge sect ion f or mor e ef f icient t r ansf er . The basic t er ms ar e as f ol l ows:
Segmentation is t he pr ocess of br eaking an N-ser vice dat a unit (N-SDU) int o sever al N-
pr ot ocol dat a unit s (N-PDUs).
Reassembly is t he pr ocess of combining sever al N-PDUs int o an N-SDU (t he r ever se of
segment at ion).
Blocking is t he combinat ion of sever al SDUs (which might be f r om dif f er ent ser vices) int o
a l ar ger PDU wit hin t he l ayer in which t he SDUs or iginat ed.
Unblocking is t he br eaking up of a PDU int o sever al SDUs in t he same l ayer .
Concatenation is t he pr ocess of one l ayer combining sever al N-PDUs f r om t he next higher
l ayer int o one SDU (l ike bl ocking except occur r ing acr oss a l ayer boundar y).
Separation is t he r ever se of concat enat ion, so t hat a l ayer
br eaks a singl e SDU int o sever al PDUs f or t he next l ayer
higher (l ike unbl ocking except acr oss a l ayer boundar y).
These six pr ocesses ar e shown in Figur e 1.11.
Figur e 1.11. Segment at ion, r eassembl y, bl ocking, unbl ocking, concat enat ion, and
separ at ion.
Final l y, her e is one l ast set of def init ions t hat deal wit h connect ions:
Multiplexing is when sever al connect ions ar e suppor t ed by a singl e connect ion in t he next
l ower l ayer (so t hr ee pr esent at ion ser vice connect ions coul d be mul t ipl exed int o a
singl e session connect ion).
Demultiplexing is t he r ever se of mul t ipl exing, in which one connect ion is spl it int o sever al
connect ions f or t he l ayer above it .
Splitting is when a singl e connect ion is suppor t ed by sever al connect ions in t he l ayer
bel ow (so t he dat a l ink l ayer might have t hr ee connect ions t o suppor t one net wor k
l ayer connect ion).
Recombining is t he r ever se of spl it t ing, so t hat sever al
connect ions ar e combined int o a singl e one f or t he l ayer above.
Mul t ipl exing and spl it t ing (and t heir r ever ses, demul t ipl exing and r ecombining) ar e
dif f er ent in t he manner in which t he l ines ar e spl it . Wit h mul t ipl exing, sever al
connect ions combine int o one in t he l ayer bel ow. Wit h spl it t ing, however , one
connect ion can be spl it int o sever al in t he l ayer bel ow. As you might expect , each has
it s impor t ance wit hin TCP and OSI.
Protocol Headers
Pr ot ocol cont r ol inf or mat ion is inf or mat ion about t he dat agr am t o which it is
at t ached. This inf or mat ion is usual l y assembl ed int o a bl ock t hat is at t ached t o t he
f r ont of t he dat a it accompanies and is cal l ed a header or protocol header. Pr ot ocol
header s ar e used f or t r ansf er r ing inf or mat ion bet ween l ayer s as wel l as bet ween
machines. As ment ioned ear l ier , t he pr ot ocol header s ar e devel oped accor ding t o r ul es
l aid down in t he ISO's ASN.1 document set .
When a pr ot ocol header is passed t o t he l ayer beneat h, t he dat agr am incl uding t he
l ayer 's header is t r eat ed as t he ent ir e dat agr am f or t hat r eceiving l ayer , which adds it s
own pr ot ocol header t o t he f r ont . Thus, if a dat agr am st ar t ed at t he appl icat ion l ayer ,
by t he t ime it r eached t he physical l ayer , it woul d have seven set s of pr ot ocol header s
on it . These l ayer pr ot ocol header s ar e used when moving back up t he l ayer st r uct ur e;
t hey ar e st r ipped of f as t he dat agr am moves up. An il l ust r at ion of t his is shown in Figur e
1.12.
Figur e 1.12. Adding each l ayer ' s pr ot ocol header t o user dat a.
It is easier t o t hink of t his pr ocess as l ayer s on an onion. The inside is t he dat a t hat is t o
be sent . As it passes t hr ough each l ayer of t he OSI model , anot her l ayer of onion skin is
added. When it is f inished moving t hr ough t he l ayer s, sever al pr ot ocol header s ar e
encl osing t he dat a. When t he dat agr am is passed back up t he l ayer s (pr obabl y on
anot her machine), each l ayer peel s of f t he pr ot ocol header t hat cor r esponds t o t he
l ayer . When it r eaches t he dest inat ion l ayer , onl y t he dat a is l ef t .
This pr ocess makes sense, because each l ayer of t he OSI model r equir es dif f er ent
inf or mat ion f r om t he dat agr am. By using a dedicat ed pr ot ocol header f or each l ayer of
t he dat agr am, it is a r el at ivel y simpl e t ask t o r emove t he pr ot ocol header , decode it s
inst r uct ions, and pass t he r est of t he message on. The al t er nat ive woul d be t o have a
singl e l ar ge header t hat cont ained al l t he inf or mat ion, but t his woul d t ake l onger t o
pr ocess. The exact cont ent s of t he pr ot ocol header ar e not impor t ant r ight now, but I
examine t hem l at er when l ooking at t he TCP pr ot ocol .
As usual , OSI has a f or mal descr ipt ion f or al l t his, which st at es t hat t he N-user dat a t o
be t r ansf er r ed is pr epended wit h N-pr ot ocol cont r ol inf or mat ion (N-PCI) t o f or m an N-
pr ot ocol dat a unit (N-PDU). The N-PDUs ar e passed acr oss an N-ser vice access point (N-
SAP) as one of a set of ser vice par amet er s compr ising an N-ser vice dat a unit (N-SDU). The
ser vice par amet er s compr ising t he N-SDU ar e cal l ed N-ser vice user dat a (N-SUD), which
is pr epended t o t he (N1)PCI t o f or m anot her (N1)PDU.
For ever y ser vice in a l ayer , t her e is a pr ot ocol f or it t o communicat e t o t he l ayer
bel ow it (r emember t hat appl icat ions communicat e t hr ough t he l ayer bel ow, not
dir ect l y). The pr ot ocol exchanges f or each ser vice ar e def ined by t he syst em, and t o a
l esser ext ent by t he appl icat ion devel oper , who shoul d be f ol l owing t he r ul es of t he
syst em.
Pr ot ocol s and header s might sound a l it t l e compl ex or over l y compl icat ed f or t he t ask
t hat must be accompl ished, but consider ing t he or iginal goal s of t he OSI model , it is
gener al l y acknowl edged t hat t his is t he best way t o go. (Many a sar cast ic comment has
been made about OSI and TCP t hat cl aim t he header inf or mat ion is much mor e impor t ant
t han t he dat a cont ent s. In some ways t his is t r ue, because wit hout t he header t he dat a
woul d never get t o it s dest inat ion.)
Summary
Today's t ext has t hr own a l ot of t er minol ogy at you, most of which you wil l see
f r equent l y in t he f ol l owing chapt er s. In most cases, a gent l e r eminder of t he def init ion
accompanies t he f ir st occur r ence of t he t er m. To under st and t he r el at ionships bet ween
t he dif f er ent t er ms, t hough, you might have t o r ef er back t o t oday's mat er ial .
You now have t he basic knowl edge t o r el at e TCP/IP t o t he OSI's l ayer ed model , which
wil l hel p you under st and what TCP/IP does (and how it goes about doing it ). The next
chapt er l ooks at t he hist or y of TCP/IP and t he gr owt h of t he Int er net .
Q&A
What ar e t he t hr ee main t ypes of LAN ar chit ect ur e? What ar e t heir pr imar y
char act er ist ics?
The t hr ee net wor k ar chit ect ur es ar e bus, r ing, and hub. Ther e ar e ot her s, but t hese
t hr ee descr ibe t he vast major it y of al l LANs.
A bus net wor k is a l engt h of cabl e t hat has a connect or f or each device dir ect l y
at t ached t o it . Bot h ends of t he net wor k cabl e ar e t er minat ed. A r ing net wor k has a
cent r al cont r ol unit cal l ed a Media Access Unit t o which al l devices ar e at t ached by
cabl es. A hub net wor k has a backpl ane wit h connect or s l eading t hr ough anot her cabl e
t o t he devices.
What ar e t he seven OSI l ayer s and t heir r esponsibil it ies?
The OSI l ayer s (f r om t he bot t om up) ar e as f ol l ows:
Physical : Tr ansmit s dat a
Dat a Link: Cor r ect s t r ansmission er r or s
Net wor k: Pr ovides t he physical r out ing inf or mat ion
Tr anspor t : Ver if ies t hat dat a is cor r ect l y t r ansmit t ed
Session: Synchr onizes dat a exchange bet ween upper and l ower l ayer s
Pr esent at ion: Conver t s net wor k dat a t o appl icat ion-specif ic f or mat s
Appl icat ion: End-user int er f ace
What is t he dif f er ence bet ween segment at ion and r eassembl y, and concat enat ion
and separ at ion?
Segment at ion is t he br eaking apar t of a l ar ge N-ser vice dat a unit (N-SDU) int o sever al
smal l er N-pr ot ocol dat a unit s (N-PDUs), wher eas r eassembl y is t he r ever se.
Concat enat ion is t he combinat ion of sever al N-PDUs f r om t he next higher l ayer int o
one SDU. Separ at ion is t he r ever se.
Def ine mul t ipl exing and demul t ipl exing. How ar e t hey usef ul ?
Mul t ipl exing is when sever al connect ions ar e suppor t ed by a singl e connect ion.
Accor ding t o t he f or mal def init ion, t his appl ies t o l ayer s (so t hat t hr ee pr esent at ion
ser vice connect ions coul d be mul t ipl exed int o a singl e session connect ion). However , it
is a t er m gener al l y used f or al l kinds of connect ions, such as put t ing f our modem cal l s
down a singl e modem l ine. Demul t ipl exing is t he r ever se of mul t ipl exing, in which one
connect ion is spl it int o sever al connect ions.
Mul t ipl exing is a key t o suppor t ing many connect ions at once wit h l imit ed r esour ces. A
t ypical exampl e is a r emot e of f ice wit h t went y t er minal s, each of which is connect ed t o
t he main of f ice by a t el ephone l ine. Inst ead of r equir ing t went y l ines, t hey can al l be
mul t ipl exed int o t hr ee or f our . The amount of mul t ipl exing possibl e depends on t he
maximum capacit y of each physical l ine.
How many pr ot ocol header s ar e added by t he t ime an OSI-based e-mail appl icat ion
(in t he appl icat ion l ayer ) has sent a message t o t he physical l ayer f or
t r ansmission?
Seven, one f or each OSI l ayer . Mor e pr ot ocol header s can be added by t he act ual
physical net wor k syst em. As a gener al r ul e, each l ayer adds it s own pr ot ocol
inf or mat ion.
Quiz
1. Pr ovide def init ions f or each of t he f ol l owing t er ms:
packet
subsyst em
ent it y
ser vice
l ayer
ISO
ASN.1
2. What does each of t he f ol l owing pr imit ives do?
ser vice pr imit ive
r equest pr imit ive
indicat ion pr imit ive
r esponse pr imit ive
conf ir mat ion pr imit ive
3. What is a Ser vice Access Point ? How many ar e t her e per l ayer ?
4. Expl ain t he pr ocess f ol l owed in adopt ing a new Int er net St andar d f or TCP/IP.
5. Use diagr ams t o show t he dif f er ences bet ween segment at ion, separ at ion, and
bl ocking.


I A Quick Over view of TCP/IP Component s
I Tel net
I Fil e Tr ansf er Pr ot ocol
I Simpl e Mail Tr ansf er Pr ot ocol
I Ker ber os
I Domain Name Syst em
I Simpl e Net wor k Management Pr ot ocol
I Net wor k Fil e Syst em
I Remot e Pr ocedur e Cal l
I Tr ivial Fil e Tr ansf er Pr ot ocol
I Tr ansmission Cont r ol Pr ot ocol
I User Dat agr am Pr ot ocol
I Int er net Pr ot ocol
I Int er net Cont r ol Message Pr ot ocol
I TCP/IP Hist or y
I Ber kel ey UNIX Impl ement at ions and TCP/IP
I OSI and TCP/IP
I TCP/IP and Et her net
I The Int er net
I The St r uct ur e of t he Int er net
I The Int er net Layer s
I Int er net wor k Pr obl ems
I Int er net Addr esses
I Subnet wor k Addr essing
I The Physical Addr ess
I The Dat a Link Addr ess
I Et her net Fr ames
I IP Addr esses
I Addr ess Resol ut ion Pr ot ocol
I Mapping Types
I The Har dwar e Type Fiel d
I The Pr ot ocol Type Fiel d
I ARP and IP Addr esses
I The Domain Name Syst em
I Summar y
I Q&A
I Quiz
2
TCP/IP and the Internet
Bef or e pr oceeding int o a consider abl e amount of det ail about TCP/IP, t he Int er net , and
t he Int er net Pr ot ocol (IP), it is wor t hwhil e t o t r y t o compl et e a quick out l ine of TCP/IP.
Then, as t he det ail s of each pr ot ocol ar e discussed individual l y, t hey can be pl aced in
t he br oader out l ine mor e easil y, t her eby l eading t o a mor e compl et e under st anding in
t he next t wo chapt er s.
Just what is TCP/IP? As you saw on Day 1, it is a sof t war e-based communicat ions pr ot ocol
used in net wor king. Al t hough t he name TCP/IP impl ies t hat t he ent ir e scope of t he
pr oduct is a combinat ion of t wo pr ot ocol sTr ansmission Cont r ol Pr ot ocol and Int er net
Pr ot ocol t he t er m TCP/IP r ef er s not t o a singl e ent it y combining t wo pr ot ocol s, but a
l ar ger set of sof t war e pr ogr ams t hat pr ovides net wor k ser vices such as r emot e l ogins,
r emot e f il e t r ansf er s, and el ect r onic mail . TCP/IP pr ovides a met hod f or t r ansf er r ing
inf or mat ion f r om one machine t o anot her . A communicat ions pr ot ocol shoul d handl e
er r or s in t r ansmission, manage t he r out ing and del iver y of dat a, and cont r ol t he act ual
t r ansmission by t he use of pr edet er mined st at us signal s. TCP/IP accompl ishes al l of t his.
TCP/IP is not a singl e pr oduct . It is a cat ch-al l name f or a
f amil y of pr ot ocol s t hat use a simil ar behavior . Using t he t er m
TCP/IP usual l y r ef er s t o one or mor e pr ot ocol s wit hin t he
f amil y, not just TCP and IP.
In t he f ir st chapt er , you saw t hat t he OSI Ref er ence Model is composed of seven l ayer s.
TCP/IP was designed wit h l ayer s as wel l , al t hough t hey do not cor r espond one-t o-one
wit h t he OSI-RM l ayer s. You can over l ay t he TCP/IP pr ogr ams on t his model t o give you
a r ough idea of wher e al l t he TCP/IP l ayer s r eside. I do t hat in a l it t l e mor e det ail l at er
in t his chapt er . Bef or e t hat , I t ake a quick l ook at t he TCP/IP pr ot ocol s and how t hey
r el at e t o each ot her , and show a r ough mapping t o t he OSI l ayer s.
Figur e 2.1 shows t he basic el ement s of t he TCP/IP f amil y of pr ot ocol s. You can see t hat
TCP/IP is not invol ved in t he bot t om t wo l ayer s of t he OSI model (dat a l ink and physical )
but begins in t he net wor k l ayer , wher e t he Int er net Pr ot ocol (IP) r esides. In t he
t r anspor t l ayer , t he Tr ansmission Cont r ol Pr ot ocol (TCP) and User Dat agr am Pr ot ocol
(UDP) ar e invol ved. Above t his, t he ut il it ies and pr ot ocol s t hat make up t he r est of t he
TCP/IP suit e ar e buil t using t he TCP or UDP and IP l ayer s f or t heir communicat ions
syst em.
Figur e 2.1. TCP/IP suit e and OSI l ayer s.
Figur e 2.1 shows t hat some of t he upper -l ayer pr ot ocol s depend on TCP (such as Tel net
and FTP), wher eas some depend on UDP (such as TFTP and RPC). Most upper -l ayer TCP/IP
pr ot ocol s use onl y one of t he t wo t r anspor t pr ot ocol s (TCP or UDP), al t hough a f ew,
incl uding DNS (Domain Name Syst em) can use bot h.
A not e of caut ion about TCP/IP: Despit e t he f act t hat TCP/IP is an open pr ot ocol , many
companies have modif ied it f or t heir own net wor king syst em. Ther e can be
incompat ibil it ies because of t hese modif icat ions, which, even t hough t hey might adher e
t o t he of f icial st andar ds, might have ot her aspect s t hat cause pr obl ems. Luckil y, t hese
t ypes of changes ar e not r ampant , but you shoul d be car ef ul when choosing a TCP/IP
pr oduct t o ensur e it s compat ibil it y wit h exist ing sof t war e and har dwar e.
TCP/IP is dependent on t he concept of cl ient s and ser ver s. This has not hing t o do wit h a
f il e ser ver being accessed by a diskl ess wor kst at ion or PC. The t er m client/server has a
simpl e meaning in TCP/IP: any device t hat init iat es communicat ions is t he cl ient , and t he
device t hat answer s is t he ser ver . The ser ver is r esponding t o (ser ving) t he cl ient 's
r equest s.
A Quick Overview of TCP/IP Components
To under st and t he r ol es of t he many component s of t he TCP/IP pr ot ocol f amil y, it is
usef ul t o know what you can do over a TCP/IP net wor k. Then, once t he appl icat ions ar e
under st ood, t he pr ot ocol s t hat make it possibl e ar e a l it t l e easier t o compr ehend. The
f ol l owing l ist is not exhaust ive but ment ions t he pr imar y user appl icat ions t hat TCP/IP
pr ovides.
Telnet
The Tel net pr ogr am pr ovides a r emot e l ogin capabil it y. This l et s a user on one machine
l og ont o anot her machine and act as t hough he or she wer e dir ect l y in f r ont of t he
second machine. The connect ion can be anywher e on t he l ocal net wor k or on anot her
net wor k anywher e in t he wor l d, as l ong as t he user has per mission t o l og ont o t he
r emot e syst em.
You can use Tel net when you need t o per f or m act ions on a machine acr oss t he count r y.
This isn't of t en done except in a LAN or WAN cont ext , but a f ew syst ems accessibl e
t hr ough t he Int er net al l ow Tel net sessions whil e user s pl ay ar ound wit h a new
appl icat ion or oper at ing syst em.
File Transfer Protocol
Fil e Tr ansf er Pr ot ocol (FTP) enabl es a f il e on one syst em t o be copied t o anot her syst em.
The user doesn't act ual l y l og in as a f ul l user t o t he machine he or she want s t o access,
as wit h Tel net , but inst ead uses t he FTP pr ogr am t o enabl e access. Again, t he cor r ect
per missions ar e necessar y t o pr ovide access t o t he f il es.
Once t he connect ion t o a r emot e machine has been est abl ished, FTP enabl es you t o copy
one or mor e f il es t o your machine. (The t er m transfer impl ies t hat t he f il e is moved f r om
one syst em t o anot her but t he or iginal is not af f ect ed. Fil es ar e copied.) FTP is a widel y
used ser vice on t he Int er net , as wel l as on many l ar ge LANs and WANs.
Simple Mail Transfer Protocol
Simpl e Mail Tr ansf er Pr ot ocol (SMTP) is used f or t r ansf er r ing el ect r onic mail . SMTP is
compl et el y t r anspar ent t o t he user . Behind t he scenes, SMTP connect s t o r emot e
machines and t r ansf er s mail messages much l ike FTP t r ansf er s f il es. User s ar e al most
never awar e of SMTP wor king, and f ew syst em administ r at or s have t o bot her wit h it .
SMTP is a most l y t r oubl e-f r ee pr ot ocol and is in ver y wide use.
Kerberos
Ker ber os is a widel y suppor t ed secur it y pr ot ocol . Ker ber os uses a special appl icat ion
cal l ed an authentication server t o val idat e passwor ds and encr ypt ion schemes. Ker ber os is
one of t he mor e secur e encr ypt ion syst ems used in communicat ions and is quit e common in
UNIX.
Domain Name System
Domain Name Syst em (DNS) enabl es a comput er wit h a common name t o be conver t ed t o a
special net wor k addr ess. For exampl e, a PC cal l ed Dar kst ar cannot be accessed by
anot her machine on t he same net wor k (or any ot her connect ed net wor k) unl ess some
met hod of checking t he l ocal machine name and r epl acing t he name wit h t he machine's
har dwar e addr ess is avail abl e. DNS pr ovides a conver sion f r om t he common l ocal name t o
t he unique physical addr ess of t he device's net wor k connect ion.
Simple Network Management Protocol
Simpl e Net wor k Management Pr ot ocol (SNMP) pr ovides st at us messages and pr obl em
r epor t s acr oss a net wor k t o an administ r at or . SNMP uses User Dat agr am Pr ot ocol (UDP)
as a t r anspor t mechanism. SNMP empl oys sl ight l y dif f er ent t er ms f r om TCP/IP, wor king
wit h manager s and agent s inst ead of cl ient s and ser ver s (al t hough t hey mean
essent ial l y t he same t hing). An agent pr ovides inf or mat ion about a device, wher eas a
manager communicat es acr oss a net wor k wit h agent s.
Network File System
Net wor k Fil e Syst em (NFS) is a set of pr ot ocol s devel oped by Sun Micr osyst ems t o enabl e
mul t ipl e machines t o access each ot her 's dir ect or ies t r anspar ent l y. They accompl ish t his
by using a dist r ibut ed f il e syst em scheme. NFS syst ems ar e common in l ar ge cor por at e
envir onment s, especial l y t hose t hat use UNIX wor kst at ions.
Remote Procedure Call
The Remot e Pr ocedur e Cal l (RPC) pr ot ocol is a set of f unct ions t hat enabl e an
appl icat ion t o communicat e wit h anot her machine (t he ser ver ). It pr ovides f or
pr ogr amming f unct ions, r et ur n codes, and pr edef ined var iabl es t o suppor t dist r ibut ed
comput ing.
Trivial File Transfer Protocol
Tr ivial Fil e Tr ansf er Pr ot ocol (TFTP) is a ver y simpl e, unsophist icat ed f il e t r ansf er
pr ot ocol t hat l acks secur it y. It uses UDP as a t r anspor t . TFTP per f or ms t he same t ask as
FTP, but uses a dif f er ent t r anspor t pr ot ocol .
Transmission Control Protocol
Tr ansmission Cont r ol Pr ot ocol (t he TCP par t of TCP/IP) is a communicat ions pr ot ocol
t hat pr ovides r el iabl e t r ansf er of dat a. It is r esponsibl e f or assembl ing dat a passed f r om
higher -l ayer appl icat ions int o st andar d packet s and ensur ing t hat t he dat a is
t r ansf er r ed cor r ect l y.
User Datagram Protocol
User Dat agr am Pr ot ocol (UDP) is a connect ionl ess-or ient ed pr ot ocol , meaning t hat it
does not pr ovide f or t he r et r ansmission of dat agr ams (unl ike TCP, which is connect ion-
or ient ed). UDP is not ver y r el iabl e, but it does have special ized pur poses. If t he
appl icat ions t hat use UDP have r el iabil it y checking buil t int o t hem, t he shor t comings of
UDP ar e over come.
Internet Protocol
Int er net Pr ot ocol (IP) is r esponsibl e f or moving t he packet s of dat a assembl ed by eit her
TCP or UDP acr oss net wor ks. It uses a set of unique addr esses f or ever y device on t he
net wor k t o det er mine r out ing and dest inat ions.
Internet Control Message Protocol
Int er net Cont r ol Message Pr ot ocol (ICMP) is r esponsibl e f or checking and gener at ing
messages on t he st at us of devices on a net wor k. It can be used t o inf or m ot her devices of
a f ail ur e in one par t icul ar machine. ICMP and IP usual l y wor k t oget her .
TCP/IP History
The ar chit ect ur e of TCP/IP is of t en cal l ed t he Int er net ar chit ect ur e because TCP/IP and
t he Int er net as so cl osel y int er woven. In t he l ast chapt er , you saw how t he Int er net
st andar ds wer e devel oped by t he Def ense Advanced Resear ch Pr oject s Agency (DARPA)
and event ual l y passed on t o t he Int er net Societ y.
The Int er net was or iginal l y pr oposed by t he pr ecur sor of DARPA, cal l ed t he Advanced
Resear ch Pr oject s Agency (ARPA), as a met hod of t est ing t he viabil it y of packet -
swit ching net wor ks. (When ARPA's f ocus became mil it ar y in nat ur e, t he name was
changed.) Dur ing it s t enur e wit h t he pr oject , ARPA f or esaw a net wor k of l eased l ines
connect ed by swit ching nodes. The net wor k was cal l ed ARPANET, and t he swit ching
nodes wer e cal l ed Int er net Message Pr ocessor s, or IMPs.
The ARPANET was init ial l y t o be compr ised of f our IMPs l ocat ed at t he Univer sit y of
Cal if or nia at Los Angel es, t he Univer sit y of Cal if or nia at Sant a Bar bar a, t he St anf or d
Resear ch Inst it ut e, and t he Univer sit y of Ut ah. The or iginal IMPs wer e t o be Honeywel l
316 minicomput er s.
The cont r act f or t he inst al l at ion of t he net wor k was won by Bol t , Ber anek, and
Newman (BBN), a company t hat had a st r ong inf l uence on t he devel opment of t he
net wor k in t he f ol l owing year s. The cont r act was awar ded in l at e 1968, f ol l owed by
t est ing and r ef inement over t he next f ive year s.
Bol t , Ber anek, and Newman (BBN) made many suggest ions
f or t he impr ovement of t he Int er net and t he devel opment of
TCP/IP, f or which t heir names ar e of t en associat ed wit h t he
pr ot ocol .
In 1971, ARPANET ent er ed int o r egul ar ser vice. Machines used t he ARPANET by
connect ing t o an IMP using t he "1822" pr ot ocol so cal l ed because t hat was t he number
of t he t echnical paper descr ibing t he syst em. Dur ing t he ear l y year s, t he pur pose and
ut il it y of t he net wor k was widel y (and somet imes heat edl y) discussed, l eading t o
r ef inement s and modif icat ions as user s r equest ed mor e f unct ional it y f r om t he syst em.
A commonl y r ecognized need was t he capabil it y t o t r ansf er f il es f r om one machine t o
anot her , as wel l as t he capabil it y t o suppor t r emot e l ogins. Remot e l ogins woul d enabl e
a user in Sant a Bar bar a t o connect t o a machine in Los Angel es over t he net wor k and
f unct ion as t hough he or she wer e in f r ont of t he UCLA machine. The pr ot ocol t hen in
use on t he net wor k wasn't capabl e of handl ing t hese new f unct ional it y r equest s, so new
pr ot ocol s wer e cont inual l y devel oped, r ef ined, and t est ed.
Remot e l ogin and r emot e f il e t r ansf er wer e f inal l y impl ement ed in a pr ot ocol cal l ed
t he Net wor k Cont r ol Pr ogr am (NCP). Lat er , el ect r onic mail was added t hr ough Fil e
Tr ansf er Pr ot ocol (FTP). Toget her wit h NCP's r emot e l ogins and f il e t r ansf er , t his
f or med t he basic ser vices f or ARPANET.
By 1973, it was cl ear t hat NCP was unabl e t o handl e t he vol ume of t r af f ic and pr oposed
new f unct ional it y. A pr oject was begun t o devel op a new pr ot ocol . The TCP/IP and
gat eway ar chit ect ur es wer e f ir st pr oposed in 1974. The publ ished ar t icl e by Cer f and
Kahn descr ibed a syst em t hat pr ovided a st andar dized appl icat ion pr ot ocol t hat al so
used end-t o-end acknowl edgment s.
Neit her of t hese concept s wer e r eal l y novel at t he t ime, but mor e impor t ant l y (and wit h
consider abl e vision), Cer f and Kahn suggest ed t hat t he new pr ot ocol be independent of
t he under l ying net wor k and comput er har dwar e. Al so, t hey pr oposed univer sal
connect ivit y t hr oughout t he net wor k. These t wo ideas wer e r adical in a wor l d of
pr opr iet ar y har dwar e and sof t war e, because t hey woul d enabl e any kind of pl at f or m t o
par t icipat e in t he net wor k. The pr ot ocol was devel oped and became known as TCP/IP.
A ser ies of RFCs (Request s f or Comment , par t of t he pr ocess f or adopt ing new Int er net
St andar ds) was issued in 1981, st andar dizing TCP/IP ver sion 4 f or t he ARPANET. In 1982,
TCP/IP suppl ant ed NCP as t he dominant pr ot ocol of t he gr owing net wor k, which was now
connect ing machines acr oss t he cont inent . It is est imat ed t hat a new comput er was
connect ed t o ARPANET ever y 20 days dur ing it s f ir st decade. (That might not seem l ike
much compar ed t o t he cur r ent est imat e of t he Int er net 's size doubl ing ever y year , but in
t he ear l y 1980s it was a phenomenal gr owt h r at e.)
Dur ing t he devel opment of ARPANET, it became obvious t hat nonmil it ar y r esear cher s
coul d use t he net wor k t o t heir advant age, enabl ing f ast er communicat ion of ideas as
wel l as f ast er physical dat a t r ansf er . A pr oposal t o t he Nat ional Science Foundat ion
l ead t o f unding f or t he Comput er Science Net wor k in 1981, joining t he mil it ar y wit h
educat ional and r esear ch inst it ut es t o r ef ine t he net wor k. This l ed t o t he spl it t ing of
t he net wor k int o t wo dif f er ent net wor ks in 1984. MILNET was dedicat ed t o uncl assif ied
mil it ar y t r af f ic, wher eas ARPANET was l ef t f or r esear ch and ot her nonmil it ar y
pur poses.
ARPANET's gr owt h and subsequent demise came wit h t he appr oval f or t he Of f ice of
Advanced Scient if ic Comput ing t o devel op wide access t o super comput er s. They cr eat ed
NSFNET t o connect six super comput er s spr ead acr oss t he count r y t hr ough T-1 l ines
(which oper at ed at 1.544 Mbps). The Depar t ment of Def ense f inal l y decl ar ed ARPANET
obsol et e in 1990, when it was of f icial l y dismant l ed.
Berkeley UNIX Implementations and TCP/IP
TCP/IP became impor t ant when t he Depar t ment of Def ense st ar t ed incl uding t he
pr ot ocol s as mil it ar y st andar ds, which wer e r equir ed f or many cont r act s. TCP/IP became
popul ar pr imar il y because of t he wor k done at UCB (Ber kel ey). UCB had been a cent er of
UNIX devel opment f or year s, but in 1983 t hey r el eased a new ver sion t hat incor por at ed
TCP/IP as an int egr al el ement . That ver sion4.2BSD (Ber kel ey Syst em
Dist r ibut ion)was made avail abl e t o t he wor l d as publ ic domain sof t war e.
The popul ar it y of 4.2BSD spur r ed t he popul ar it y of TCP/IP, especial l y as mor e sit es
connect ed t o t he gr owing ARPANET. Ber kel ey r el eased an enhanced ver sion (which
incl uded t he so-cal l ed Ber kel ey Ut il it ies) in 1986 as 4.3BSD. An opt imized TCP
impl ement at ion f ol l owed in 1988 (4.3BSD/Tahoe). Pr act ical l y ever y ver sion of TCP/IP
avail abl e t oday has it s r oot s (and much of it s code) in t he Ber kel ey ver sions.
Despit e t he demise of Ber kel ey Sof t war e Dist r ibut ion's
UNIX ver sion in 1993, t he BSD and UCB devel opment s ar e
int egr al par t s of TCP/IP and cont inue t o be used as par t of t he
pr ot ocol f amil y's naming syst em.
OSI and TCP/IP
The adopt ion of TCP/IP didn't conf l ict wit h t he OSI st andar ds because t he t wo devel oped
concur r ent l y. In some ways, TCP/IP cont r ibut ed t o OSI, and vice-ver sa. Sever al
impor t ant dif f er ences do exist , t hough, which ar ise f r om t he basic r equir ement s of TCP/IP
which ar e:
G A common set of appl icat ions
G Dynamic r out ing
G Connect ionl ess pr ot ocol s at t he net wor king l evel
G Univer sal connect ivit y
G Packet -swit ching
The dif f er ences bet ween t he OSI ar chit ect ur e and t hat of TCP/IP r el at e t o t he l ayer s
above t he t r anspor t l evel and t hose at t he net wor k l evel . OSI has bot h t he session
l ayer and t he pr esent at ion l ayer , wher eas TCP/IP combines bot h int o an appl icat ion
l ayer . The r equir ement f or a connect ionl ess pr ot ocol al so r equir ed TCP/IP t o combine
OSI's physical l ayer and dat a l ink l ayer int o a net wor k l evel . TCP/IP al so incl udes t he
session and pr esent at ion l ayer s of t he OSI model int o TCP/IPs appl icat ion l ayer . A
schemat ic view of TCP/IP's l ayer ed st r uct ur e compar ed wit h OSI's seven-l ayer model is
shown in Figur e 2.2. TCP/IP cal l s t he dif f er ent net wor k l evel el ement s subnetworks.
Figur e 2.2. The OSI and TCP/IP l ayer ed st r uct ur es.
OSI and TCP/IP ar e not incompat ibl e, but neit her ar e t hey
per f ect l y compat ibl e. They bot h have a l ayer ed ar chit ect ur e,
but t he OSI ar chit ect ur e is much mor e r igor ousl y def ined, and
t he l ayer s ar e mor e independent t han TCP/IP's.
Some f uss was made about t he net wor k l evel combinat ion, al t hough it soon became
obvious t hat t he ar gument was academic, as most impl ement at ions of t he OSI model
combined t he physical and l ink l evel s on an int el l igent cont r ol l er (such as a net wor k
car d). The combinat ion of t he t wo l ayer s int o a singl e l ayer had one major benef it : it
enabl ed a subnet wor k t o be designed t hat was independent of any net wor k pr ot ocol s,
because TCP/IP was obl ivious t o t he det ail s. This enabl ed pr opr iet ar y, sel f -cont ained
net wor ks t o impl ement t he TCP/IP pr ot ocol s f or connect ivit y out side t heir cl osed
syst ems.
The l ayer ed appr oach gave r ise t o t he name TCP/IP. The t r anspor t l ayer uses t he
Tr ansmission Cont r ol Pr ot ocol (TCP) or one of sever al var iant s, such as t he User
Dat agr am Pr ot ocol (UDP). (Ther e ar e ot her pr ot ocol s in use, but TCP and UDP ar e t he
most common.) Ther e is, however , onl y one pr ot ocol f or t he net wor k l evel t he Int er net
Pr ot ocol (IP). This is what assur es t he syst em of univer sal connect ivit y, one of t he
pr imar y design goal s.
Ther e is a consider abl e amount of pr essur e f r om t he user communit y t o abandon t he OSI
model (and any f ut ur e communicat ions pr ot ocol s devel oped t hat conf or m t o it ) in f avor
of TCP/IP. The ar gument hinges on some obvious r easons:
G TCP/IP is up and r unning and has a pr oven r ecor d.
G TCP/IP has an est abl ished, f unct ioning management body.
G Thousands of appl icat ions cur r ent l y use TCP/IP and it s wel l -document ed
appl icat ion pr ogr amming int er f aces.
G TCP/IP is t he basis f or most UNIX syst ems, which ar e gaining t he l ar gest shar e of
t he oper at ing syst em mar ket (ot her t han deskt op singl e-user machines such as t he
PC and Macint osh).
G TCP/IP is vendor -independent .
Ar guing r at her st r enuousl y against TCP/IP, sur pr isingl y enough, is t he US
gover nment t he ver y body t hat sponsor ed it in t he f ir st pl ace. Their pr imar y ar gument
is t hat TCP/IP is not an int er nat ional l y adopt ed st andar d, wher eas OSI has t hat
r ecognit ion. The Depar t ment of Def ense has even begun t o move it s syst ems away f r om
t he TCP/IP pr ot ocol set . A compr omise wil l pr obabl y r esul t , wit h some aspect s of OSI
adopt ed int o t he st il l -evol ving TCP/IP pr ot ocol suit e.
TCP/IP and Ethernet
For many peopl e t he t er ms TCP/IP and Et her net go t oget her al most aut omat ical l y,
pr imar il y f or hist or ical r easons, as wel l as t he simpl e f act t hat t her e ar e mor e Et her net -
based TCP/IP net wor ks t han any ot her t ype. Et her net was or iginal l y devel oped at
Xer ox's Pal o Al t o Resear ch Cent er as a st ep t owar d an el ect r onic of f ice communicat ions
syst em, and it has since gr own in capabil it y and popul ar it y.
Et her net is a har dwar e syst em pr oviding f or t he dat a l ink and physical l ayer s of t he OSI
model . As par t of t he Et her net st andar ds, issues such as cabl e t ype and br oadcast speeds
ar e est abl ished. Ther e ar e sever al dif f er ent ver sions of Et her net , each wit h a dif f er ent
dat a t r ansf er r at e. The most common is Et her net ver sion 2, al so cal l ed 10Base5, Thick
Et her net , and IEEE 802.3 (af t er t he number of t he st andar d t hat def ines t he syst em
adopt ed by t he Inst it ut e of El ect r ical and El ect r onic Engineer s). This syst em has a 10
Mbps r at e.
Ther e ar e sever al commonl y used var iant s of Et her net , such as Thin Et her net (cal l ed
10Base2), which can oper at e over t hinner cabl e (such as t he coaxial cabl e used in cabl e
t el evision syst ems), and Twist ed-Pair Et her net (10BaseT), which uses simpl e t wist ed-pair
wir es simil ar t o t el ephone cabl e. The l at t er var iant is popul ar f or smal l companies
because it is inexpensive, easy t o wir e, and has no st r ict r equir ement s f or dist ance
bet ween machines.
It is usual l y easy t o t el l which t ype of Et her net net wor k
is being used by checking t he connect or t o a net wor k car d. If it
has a t el ephone-st yl e pl ug, it is 10BaseT. The cabl e f or 10BaseT
l ooks t he same as t el ephone cabl e. If t he net wor k has a D-
shaped connect or wit h many pins in it , it is 10Base5. A 10Base2
net wor k has a connect or simil ar t o a cabl e TV coaxial
connect or , except it l ocks int o pl ace. The 10Base2 connect or is
al ways cir cul ar .
The size of a net wor k is al so a good indicat or . 10Base5 is used in
l ar ge net wor ks wit h many devices and l ong t r ansmission r uns.
10Base2 is used in smal l er net wor ks, usual l y wit h al l t he
net wor k devices in f air l y cl ose pr oximit y. Twist ed-pair (10BaseT)
net wor ks ar e of t en used f or ver y smal l net wor ks wit h a
maximum of a f ew dozen devices in cl ose pr oximit y.
Et her net and TCP/IP wor k wel l t oget her , wit h Et her net pr oviding t he physical cabl ing
(l ayer s one and t wo) and TCP/IP t he communicat ions pr ot ocol (l ayer s t hr ee and f our )
t hat is br oadcast over t he cabl e. The t wo have t heir own pr ocesses f or packaging
inf or mat ion: TCP/IP uses 32-bit addr esses, wher eas Et her net uses a 48-bit scheme. The t wo
wor k t oget her , however , because of one component of TCP/IP cal l ed t he Addr ess
Resol ut ion Pr ot ocol (ARP), which conver t s bet ween t he t wo schemes. (I discuss ARP in
mor e det ail l at er , in t he sect ion t it l ed "Addr ess Resol ut ion Pr ot ocol .")
Et her net r el ies on a pr ot ocol cal l ed Car r ier Sense Mul t ipl e Access wit h Col l ision
Det ect (CSMA/CD). To simpl if y t he pr ocess, a device checks t he net wor k cabl e t o see if
anyt hing is cur r ent l y being sent . If it is cl ear , t he device sends it s dat a. If t he cabl e is
busy (car r ier det ect ), t he device wait s f or it t o cl ear . If t wo devices t r ansmit at t he same
t ime (a col l ision), t he devices know because of t heir const ant compar ison of t he cabl e
t r af f ic t o t he dat a in t he sending buf f er . If a col l ision occur s, t he devices wait a r andom
amount of t ime bef or e t r ying again.
The Internet
As ARPANET gr ew out of a mil it ar y-onl y net wor k t o add subnet wor ks in univer sit ies,
cor por at ions, and user communit ies, it became known as t he Int er net . Ther e is no singl e
net wor k cal l ed t he Int er net , however . The t er m r ef er s t o t he col l ect ive net wor k of
subnet wor ks. The one t hing t hey al l have in common is TCP/IP as a communicat ions
pr ot ocol .
As descr ibed in t he f ir st chapt er , t he or ganizat ion of t he Int er net and adopt ion of new
st andar ds is cont r ol l ed by t he Int er net Advisor y Boar d (IAB). Among ot her t hings, t he
IAB coor dinat es sever al t ask f or ces, incl uding t he Int er net Engineer ing Task For ce
(IETF) and Int er net Resear ch Task For ce (IRTF). In a nut shel l , t he IRTF is concer ned
wit h ongoing r esear ch, wher eas t he IETF handl es t he impl ement at ion and engineer ing
aspect s associat ed wit h t he Int er net .
A body t hat has some bear ing on t he IAB is t he Feder al Net wor king Council (FNC), which
ser ves as an int er mediar y bet ween t he IAB and t he gover nment . The FNC has an advisor y
capacit y t o t he IAB and it s t ask f or ces, as wel l as t he r esponsibil it y f or managing t he
gover nment 's use of t he Int er net and ot her net wor ks. Because t he gover nment was
r esponsibl e f or f unding t he devel opment of t he Int er net , it r et ains a consider abl e
amount of cont r ol , as wel l as sponsor ing some r esear ch and expansion of t he Int er net .
The Structure of the Internet
As ment ioned ear l ier , t he Int er net is not a singl e net wor k but a col l ect ion of net wor ks
t hat communicat e wit h each ot her t hr ough gat eways. For t he pur poses of t his chapt er , a
gateway (somet imes cal l ed a router) is def ined as a syst em t hat per f or ms r el ay f unct ions
bet ween net wor ks, as shown in Figur e 2.3. The dif f er ent net wor ks connect ed t o each
ot her t hr ough gat eways ar e of t en cal l ed subnet wor ks, because t hey ar e a smal l er par t
of t he l ar ger over al l net wor k. This does not impl y t hat a subnet wor k is smal l or
dependent on t he l ar ger net wor k. Subnet wor ks ar e compl et e net wor ks, but t hey ar e
connect ed t hr ough a gat eway as a par t of a l ar ger int er net wor k, or in t his case t he
Int er net .
Figur e 2.3. Gat eways act as r el ays bet ween subnet wor ks.
Wit h TCP/IP, al l int er connect ions bet ween physical net wor ks ar e t hr ough gat eways. An
impor t ant point t o r emember f or use l at er is t hat gat eways r out e inf or mat ion packet s
based on t heir dest inat ion net wor k name, not t he dest inat ion machine. Gat eways ar e
supposed t o be compl et el y t r anspar ent t o t he user , which al l eviat es t he gat eway f r om
handl ing user appl icat ions (unl ess t he machine t hat is act ing as a gat eway is al so
someone's wor k machine or a l ocal net wor k ser ver , as is of t en t he case wit h smal l
net wor ks). Put simpl y, t he gat eway's sol e t ask is t o r eceive a Pr ot ocol Dat a Unit (PDU)
f r om eit her t he int er net wor k or t he l ocal net wor k and eit her r out e it on t o t he next
gat eway or pass it int o t he l ocal net wor k f or r out ing t o t he pr oper user .
Gat eways wor k wit h any kind of har dwar e and oper at ing syst em, as l ong as t hey ar e
designed t o communicat e wit h t he ot her gat eways t hey ar e at t ached t o (which in t his
case means t hat it uses TCP/IP). Whet her t he gat eway is l eading t o a Macint osh net wor k,
a set of IBM PCs, or mainf r ames f r om a dozen dif f er ent companies doesn't mat t er t o t he
gat eway or t he PDUs it handl es.
Ther e ar e act ual l y sever al t ypes of gat eways, each
per f or ming a dif f er ence t ype of t ask. I l ook at t he dif f er ent
gat eways in mor e det ail on Day 5, "Gat eway and Rout ing
Pr ot ocol s."
In t he Unit ed St at es, t he Int er net has t he NFSNET as it s backbone, as shown in Figur e
2.4. Among t he pr imar y net wor ks connect ed t o t he NFSNET ar e NASA's Space Physics
Anal ysis Net wor k (SPAN), t he Comput er Science Net wor k (CSNET), and sever al ot her
net wor ks such as WESTNET and t he San Diego Super comput er Net wor k (SDSCNET), not
shown in Figur e 2.4. Ther e ar e al so ot her smal l er user -or ient ed net wor ks such as t he
Because It 's Time Net wor k (BITNET) and UUNET, which pr ovide connect ivit y t hr ough
gat eways f or smal l er sit es t hat can't or don't want t o est abl ish a dir ect gat eway t o t he
Int er net .
Figur e 2.4. The US Int er net net wor k.
The NFSNET backbone is compr ised of appr oximat el y 3,000 r esear ch sit es, connect ed by T-3
l eased l ines r unning at 44.736 Megabit s per second. Test s ar e cur r ent l y under way t o
incr ease t he oper at ional speed of t he backbone t o enabl e mor e t hr oughput and
accommodat e t he r apidl y incr easing number of user s. Sever al t echnol ogies ar e being
f iel d-t est ed, incl uding Synchr onous Opt ical Net wor k (SONET), Asynchr onous Tr ansf er
Mode (ATM), and ANSI's pr oposed High-Per f or mance Par al l el Int er f ace (HPPI). These new
syst ems can pr oduce speeds appr oaching 1 Gigabit per second.
The Internet Layers
Most int er net wor ks, incl uding t he Int er net , can be t hought of as a l ayer ed
ar chit ect ur e (yes, even mor e l ayer s!) t o simpl if y under st anding. The l ayer concept hel ps
in t he t ask of devel oping appl icat ions f or int er net wor ks. The l ayer ing al so shows how
t he dif f er ent par t s of TCP/IP wor k t oget her . The mor e l ogical st r uct ur e br ought about
by using a l ayer ing pr ocess has al r eady been seen in t he f ir st chapt er f or t he OSI model ,
so appl ying it t o t he Int er net makes sense. Be car ef ul t o t hink of t hese l ayer s as
concept ual onl y; t hey ar e not r eal l y physical or sof t war e l ayer s as such (unl ike t he
OSI or TCP/IP l ayer s).
It is convenient t o t hink of t he Int er net as having f our l ayer s. This l ayer ed Int er net
ar chit ect ur e is shown in Figur e 2.5. These l ayer s shoul d not be conf used wit h t he
ar chit ect ur e of each machine, as descr ibed in t he OSI seven-l ayer model . Inst ead, t hey
ar e a met hod of seeing how t he int er net wor k, net wor k, TCP/IP, and t he individual
machines wor k t oget her . Independent machines r eside in t he subnet wor k l ayer at t he
bot t om of t he ar chit ect ur e, connect ed t oget her in a l ocal ar ea net wor k (LAN) and
r ef er r ed t o as t he subnet wor k, a t er m you saw in t he l ast sect ion.
Figur e 2.5. The Int er net ar chit ect ur e.
On t op of t he subnet wor k l ayer is t he int er net wor k l ayer , which pr ovides t he
f unct ional it y f or communicat ions bet ween net wor ks t hr ough gat eways. Each
subnet wor k uses gat eways t o connect t o t he ot her subnet wor ks in t he int er net wor k.
The int er net wor k l ayer is wher e dat a get s t r ansf er r ed f r om gat eway t o gat eway unt il
it r eaches it s dest inat ion and t hen passes int o t he subnet wor k l ayer . The int er net wor k
l ayer r uns t he Int er net Pr ot ocol (IP).
The ser vice pr ovider pr ot ocol l ayer is r esponsibl e f or t he over al l end-t o-end
communicat ions of t he net wor k. This is t he l ayer t hat r uns t he Tr ansmission Cont r ol
Pr ot ocol (TCP) and ot her pr ot ocol s. It handl es t he dat a t r af f ic f l ow it sel f and ensur es
r el iabil it y f or t he message t r ansf er .
The t op l ayer is t he appl icat ion ser vices l ayer , which suppor t s t he int er f aces t o t he user
appl icat ions. This l ayer int er f aces t o el ect r onic mail , r emot e f il e t r ansf er s, and r emot e
access. Sever al pr ot ocol s ar e used in t his l ayer , many of which you wil l r ead about
l at er .
To see how t he Int er net ar chit ect ur e model wor ks, a simpl e exampl e is usef ul . Assume
t hat an appl icat ion on one machine want s t o t r ansf er a dat agr am t o an appl icat ion on
anot her machine in a dif f er ent subnet wor k. Wit hout al l t he signal s bet ween l ayer s, and
simpl if ying t he ar chit ect ur e a l it t l e, t he pr ocess is shown in Figur e 2.6. The l ayer s in t he
sending and r eceiving machines ar e t he OSI l ayer s, wit h t he equival ent Int er net
ar chit ect ur e l ayer s indicat ed.
Figur e 2.6. Tr ansf er of a dat agr am over an int er net wor k.
The dat a is sent down t he l ayer s of t he sending machine, assembl ing t he dat agr am wit h
t he Pr ot ocol Cont r ol Inf or mat ion (PCI) as it goes. Fr om t he physical l ayer , t he dat agr am
(which is somet imes cal l ed a frame af t er t he dat a l ink l ayer has added it s header and
t r ail ing inf or mat ion) is sent out t o t he l ocal ar ea net wor k. The LAN r out es t he
inf or mat ion t o t he gat eway out t o t he int er net wor k. Dur ing t his pr ocess, t he LAN has
no concer n about t he message cont ained in t he dat agr am. Some net wor ks, however , al t er
t he header inf or mat ion t o show, among ot her t hings, t he machines it has passed t hr ough.
Fr om t he gat eway, t he f r ame passes f r om gat eway t o gat eway al ong t he int er net wor k
unt il it ar r ives at t he dest inat ion subnet wor k. At each st ep, t he gat eway anal yzes t he
dat agr am's header t o det er mine if it is f or t he subnet wor k t he gat eway l eads t o. If not ,
it r out es t he dat agr am back out over t he int er net wor k. This anal ysis is per f or med in t he
physical l ayer , el iminat ing t he need t o pass t he f r ame up and down t hr ough dif f er ent
l ayer s on each gat eway. The header can be al t er ed at each gat eway t o r ef l ect it s
r out ing pat h.
When t he dat agr am is f inal l y r eceived at t he dest inat ion subnet wor k's gat eway, t he
gat eway r ecognizes t hat t he dat agr am is at it s cor r ect subnet wor k and r out es it int o
t he LAN and event ual l y t o t he t ar get machine. The r out ing is accompl ished by r eading
t he header inf or mat ion. When t he dat agr am r eaches t he dest inat ion machine, it passes up
t hr ough t he l ayer s, wit h each l ayer st r ipping of f it s PCI header and t hen passing t he
r esul t on up. At l ong l ast , t he appl icat ion l ayer on t he dest inat ion machine pr ocesses
t he f inal header and passes t he message t o t he cor r ect appl icat ion.
If t he dat agr am was not dat a t o be pr ocessed but a r equest f or a ser vice, such as a r emot e
f il e t r ansf er , t he cor r ect l ayer on t he dest inat ion machine woul d decode t he r equest
and r out e t he f il e back over t he int er net wor k t o t he or iginal machine. Quit e a pr ocess!
Internetwork Problems
Not ever yt hing goes smoot hl y when t r ansf er r ing dat a f r om one subnet wor k t o anot her .
Al l manner of pr obl ems can occur , despit e t he f act t hat t he ent ir e net wor k is using one
pr ot ocol . A t ypical pr obl em is a l imit at ion on t he size of t he dat agr am. The sending
net wor k might suppor t dat agr ams of 1,024 byt es, but t he r eceiving net wor k might use
onl y 512-byt e dat agr ams (because of a dif f er ent har dwar e pr ot ocol , f or exampl e). This is
wher e t he pr ocesses of segment at ion, separ at ion, r eassembl y, and concat enat ion
(expl ained in t he l ast chapt er ) become impor t ant .
The act ual addr essing met hods used by t he dif f er ent subnet wor ks can cause conf l ict s
when r out ing dat agr ams. Because communicat ing subnet wor ks might not have t he same
net wor k cont r ol sof t war e, t he net wor k-based header inf or mat ion might dif f er , despit e
t he f act t hat t he communicat ions met hods ar e based on TCP/IP. An associat ed pr obl em
occur s when deal ing wit h t he dif f er ences bet ween physical and l ogical machine names.
In t he same manner , a net wor k t hat r equir es encr ypt ion inst ead of cl ear -t ext dat agr ams
can af f ect t he decoding of header inf or mat ion. Ther ef or e, dif f er ences in t he secur it y
impl ement ed on t he subnet wor ks can af f ect dat agr am t r af f ic. These dif f er ences can al l
be r esol ved wit h sof t war e, but t he pr obl ems associat ed wit h addr essing met hods can
become consider abl e.
Anot her common pr obl em is t he dif f er ent net wor ks' t ol er ance f or t iming pr obl ems. Time-
out and r et r y val ues might dif f er , so when t wo subnet wor ks ar e t r ying t o est abl ish
communicat ion, one might have given up and moved on t o anot her t ask whil e t he second
is st il l wait ing pat ient l y f or an acknowl edgment signal . Al so, if t wo subnet wor ks ar e
communicat ing pr oper l y and one get s busy and has t o pause t he communicat ions pr ocess
f or a shor t whil e, t he amount of t ime bef or e t he ot her net wor k assumes a disconnect ion
and gives up might be impor t ant . Coor dinat ing t he t iming over t he int er net wor k can
become ver y compl icat ed.
Rout ing met hods and t he speed of t he machines on t he net wor k can al so af f ect t he
int er net wor k's per f or mance. If a gat eway is managed by a par t icul ar l y sl ow machine, t he
t r af f ic coming t hr ough t he gat eway can back up, causing del ays and incompl et e
t r ansmissions f or t he ent ir e int er net wor k. Devel oping an int er net wor k syst em t hat can
dynamical l y adapt t o l oads and r er out e dat agr ams when a bot t l eneck occur s is ver y
impor t ant .
Ther e ar e ot her f act or s t o consider , such as net wor k management and t r oubl eshoot ing
inf or mat ion, but you shoul d begin t o see t hat simpl y connect ing net wor ks t oget her
wit hout due t hought does not wor k. The many dif f er ent net wor k oper at ing syst ems and
har dwar e pl at f or ms r equir e a l ogical , wel l -devel oped appr oach t o t he int er net wor k.
This is out side t he scope of TCP/IP, which is simpl y concer ned wit h t he t r ansmission of t he
dat agr ams. The TCP/IP impl ement at ions on each pl at f or m, however , must be abl e t o
handl e t he pr obl ems ment ioned.
Internet Addresses
Net wor k addr esses ar e anal ogous t o mail ing addr esses in t hat t hey t el l a syst em wher e
t o del iver a dat agr am. Thr ee t er ms commonl y used in t he Int er net r el at e t o addr essing:
name, addr ess, and r out e.
The t er m address is of t en gener ical l y used wit h
communicat ions pr ot ocol s t o r ef er t o many dif f er ent t hings. It
can mean t he dest inat ion, a por t of a machine, a memor y
l ocat ion, an appl icat ion, and mor e. Take car e when you
encount er t he t er m t o make sur e you know what it is r eal l y
r ef er r ing t o.
A name is a specif ic ident if icat ion of a machine, a user , or an appl icat ion. It is usual l y
unique and pr ovides an absol ut e t ar get f or t he dat agr am. An address t ypical l y ident if ies
wher e t he t ar get is l ocat ed, usual l y it s physical or l ogical l ocat ion in a net wor k. A
route t el l s t he syst em how t o get a dat agr am t o t he addr ess.
You use t he r ecipient 's name of t en, eit her specif ying a user name or a machine name, and
an appl icat ion does t he same t hing t r anspar ent l y t o you. Fr om t he name, a net wor k
sof t war e package cal l ed t he name server t r ies t o r esol ve t he addr ess and t he r out e,
making t hat aspect unimpor t ant t o you. When you send el ect r onic mail , you simpl y
indicat e t he r ecipient 's name, r el ying on t he name ser ver t o f igur e out how t o get t he
mail message t o t hem.
Using a name ser ver has one ot her pr imar y advant age besides making t he addr essing and
r out ing unimpor t ant t o t he end user : It gives t he syst em or net wor k administ r at or a l ot
of f r eedom t o change t he net wor k as r equir ed, wit hout having t o t el l each user 's
machine about any changes. As l ong as an appl icat ion can access t he name ser ver , any
r out ing changes can be ignor ed by t he appl icat ion and user s.
Naming convent ions dif f er depending on t he pl at f or m, t he net wor k, and t he sof t war e
r el ease, but f ol l owing is a t ypical Et her net -based Int er net subnet wor k as an exampl e.
Ther e ar e sever al t ypes of addr essing you need t o l ook at , incl uding t he LAN syst em, as
wel l as t he wider int er net wor k addr essing convent ions.
Subnetwork Addressing
On a singl e net wor k, sever al pieces of inf or mat ion ar e necessar y t o ensur e t he cor r ect
del iver y of dat a. The pr imar y component s ar e t he physical addr ess and t he dat a l ink
addr ess.
The Physical Address
Each device on a net wor k t hat communicat es wit h ot her s has a unique physical address,
somet imes cal l ed t he hardware address. On any given net wor k, t her e is onl y one
occur r ence of each addr ess; ot her wise, t he name ser ver has no way of ident if ying t he
t ar get device unambiguousl y. For har dwar e, t he addr esses ar e usual l y encoded int o a
net wor k int er f ace car d, set eit her by swit ches or by sof t war e. Wit h r espect t o t he OSI
model , t he addr ess is l ocat ed in t he physical l ayer .
In t he physical l ayer , t he anal ysis of each incoming dat agr am (or pr ot ocol dat a unit ) is
per f or med. If t he r ecipient 's addr ess mat ches t he physical addr ess of t he device, t he
dat agr am can be passed up t he l ayer s. If t he addr esses don't mat ch, t he dat agr am is
ignor ed. Keeping t his anal ysis in t he bot t om l ayer of t he OSI model pr event s unnecessar y
del ays, because ot her wise t he dat agr am woul d have t o be passed up t o ot her l ayer s f or
anal ysis.
The l engt h of t he physical addr ess var ies depending on t he net wor king syst em, but
Et her net and sever al ot her s use 48 bit s in each addr ess. For communicat ion t o occur , t wo
addr esses ar e r equir ed: one each f or t he sending and r eceiving devices.
The IEEE is now handl ing t he t ask of assigning univer sal physical addr esses f or
subnet wor ks (a t ask pr eviousl y per f or med by Xer ox, as t hey devel oped Et her net ). For
each subnet wor k, t he IEEE assigns an or ganizat ion unique ident if ier (OUI) t hat is 24 bit s
l ong, enabl ing t he or ganizat ion t o assign t he ot her 24 bit s however it want s. (Act ual l y,
t wo of t he 24 bit s assigned as an OUI ar e cont r ol bit s, so onl y 22 bit s ident if y t he
subnet wor k. Because t his pr ovides 2
22
combinat ions, it is possibl e t o r un out of OUIs in t he
f ut ur e if t he cur r ent r at e of gr owt h is sust ained.)
The f or mat of t he OUI is shown in Figur e 2.7. The l east signif icant bit of t he addr ess (t he
l owest bit number ) is t he individual or gr oup addr ess bit . If t he bit is set t o 0, t he addr ess
r ef er s t o an individual addr ess; a set t ing of 1 means t hat t he r est of t he addr ess f iel d
ident if ies a gr oup addr ess t hat needs f ur t her r esol ut ion. If t he ent ir e OUI is set t o 1s,
t he addr ess has a special meaning which is t hat al l st at ions on t he net wor k ar e assumed
t o be t he dest inat ion.
Figur e 2.7. Layout of t he or ganizat ion unique ident if ier .
The second bit is t he local or universal bit . If set t o zer o, it has been set by t he univer sal
administ r at ion body. This is t he set t ing f or IEEE-assigned OUIs. If it has a val ue of 1, t he
OUI has been l ocal l y assigned and woul d cause addr essing pr obl ems if decoded as an IEEE-
assigned addr ess.
The r emaining 22 bit s make up t he physical addr ess of t he subnet wor k, as assigned by t he
IEEE. The second set of 24 bit s ident if ies l ocal net wor k addr esses and is administ er ed
l ocal l y. If an or ganizat ion r uns out of physical addr esses (t her e ar e about 16 mil l ion
addr esses possibl e f r om 24 bit s), t he IEEE has t he capacit y t o assign a second subnet wor k
addr ess.
The combinat ion of 24 bit s f r om t he OUI and 24 l ocal l y assigned bit s is cal l ed a media
access cont r ol (MAC) addr ess. When a packet of dat a is assembl ed f or t r ansf er acr oss an
int er net wor k, t her e ar e t wo set s of MACs: one f r om t he sending machine and one f or t he
r eceiving machine.
The Data Link Address
The IEEE Et her net st andar ds (and sever al ot her al l ied st andar ds) use anot her addr ess
cal l ed t he l ink l ayer addr ess (abbr eviat ed as LSAP f or l ink ser vice access point ). The
LSAP ident if ies t he t ype of l ink pr ot ocol used in t he dat a l ink l ayer . As wit h t he
physical addr ess, a dat agr am car r ies bot h sending and r eceiving LSAPs. The IEEE al so
enabl es a code t hat ident if ies t he Et her Type assignment , which ident if ies t he upper l ayer
pr ot ocol (ULP) r unning on t he net wor k (al most al ways a LAN).
Ethernet Frames
The l ayout of inf or mat ion in each t r ansmit t ed packet of dat a dif f er s depending on t he
pr ot ocol , but it is hel pf ul t o examine one t o see how t he addr esses and r el at ed
inf or mat ion ar e pr epended t o t he dat a. This sect ion uses t he Et her net syst em as an
exampl e because of it s wide use wit h TCP/IP. It is quit e simil ar t o ot her syst ems as wel l .
A t ypical Et her net f r ame (r emember t hat a f r ame is t he t er m f or a net wor k-r eady
dat agr am) is shown in Figur e 2.8. The pr eambl e is a set of bit s t hat ar e used pr imar il y t o
synchr onize t he communicat ion pr ocess and account f or any r andom noise in t he f ir st
f ew bit s t hat ar e sent . At t he end of t he pr eambl e is a sequence of bit s t hat ar e t he st ar t
f r ame del imit er (SFD), which indicat es t hat t he f r ame f ol l ows immediat el y.
Figur e 2.8. The Et her net f r ame.
The r ecipient and sender addr esses f ol l ow in IEEE 48-bit f or mat , f ol l owed by a 16-bit
t ype indicat or t hat is used t o ident if y t he pr ot ocol . The dat a f ol l ows t he t ype indicat or .
The Dat a f iel d is bet ween 46 and 1,500 byt es in l engt h. If t he dat a is l ess t han 46 byt es, it
is padded wit h 0s unt il it is 46 byt es l ong. Any padding is not count ed in t he cal cul at ions
of t he dat a f iel d's t ot al l engt h, which is used in one par t of t he IP header . The next
chapt er cover s IP header s.
At t he end of t he f r ame is t he cycl ic r edundancy check (CRC) count , which is used t o
ensur e t hat t he f r ame's cont ent s have not been modif ied dur ing t he t r ansmission pr ocess.
Each gat eway al ong t he t r ansmission r out e cal cul at es a CRC val ue f or t he f r ame and
compar es it t o t he val ue at t he end of t he f r ame. If t he t wo mat ch, t he f r ame can be sent
f ar t her al ong t he net wor k or int o t he subnet wor k. If t hey dif f er , a modif icat ion t o t he
f r ame must have occur r ed, and t he f r ame is discar ded (t o be l at er r et r ansmit t ed by t he
sending machine when a t imer expir es).
In some pr ot ocol s, such as t he IEEE 802.3, t he over al l l ayout of t he f r ame is t he same,
wit h sl ight var iat ions in t he cont ent s. Wit h 802.3, t he 16 bit s used by Et her net t o
ident if y t he pr ot ocol t ype ar e r epl aced wit h a 16-bit val ue f or t he l engt h of t he dat a
bl ock. Al so, t he dat a ar ea it sel f is pr epended by a new f iel d.
IP Addresses
TCP/IP uses a 32-bit addr ess t o ident if y a machine on a net wor k and t he net wor k t o which
it is at t ached. IP addr esses ident if y a machine's connect ion t o t he net wor k, not t he
machine it sel f an impor t ant dist inct ion. Whenever a machine's l ocat ion on t he net wor k
changes, t he IP addr ess must be changed, t oo. The IP addr ess is t he set of number s many
peopl e see on t heir wor kst at ions or t er minal s, such as 127.40.8.72, which uniquel y
ident if ies t he device.
IP (or Int er net ) addr esses ar e assigned onl y by t he Net wor k Inf or mat ion Cent er (NIC),
al t hough if a net wor k is not connect ed t o t he Int er net , t hat net wor k can det er mine it s
own number ing. For al l Int er net accesses, t he IP addr ess must be r egist er ed wit h t he NIC.
Ther e ar e f our f or mat s f or t he IP addr ess, wit h each used depending on t he size of t he
net wor k. The f our f or mat s, cal l ed Cl ass A t hr ough Cl ass D, ar e shown in Figur e 2.9. The
cl ass is ident if ied by t he f ir st f ew bit sequences, shown in t he f igur e as one bit f or Cl ass
A and up t o f our bit s f or Cl ass D. The cl ass can be det er mined f r om t he f ir st t hr ee (high-
or der ) bit s. In f act , in most cases, t he f ir st t wo bit s ar e enough, because t her e ar e f ew
Cl ass D net wor ks.
Figur e 2.9. The f our IP addr ess cl ass st r uct ur es.
Cl ass A addr esses ar e f or l ar ge net wor ks t hat have many machines. The 24 bit s f or t he
l ocal addr ess (al so f r equent l y cal l ed t he host addr ess) ar e needed in t hese cases. The
net wor k addr ess is kept t o 7 bit s, which l imit s t he number of net wor ks t hat can be
ident if ied. Cl ass B addr esses ar e f or int er mediat e net wor ks, wit h 16-bit l ocal or host
addr esses and 14-bit net wor k addr esses. Cl ass C net wor ks have onl y 8 bit s f or t he l ocal
or host addr ess, l imit ing t he number of devices t o 256. Ther e ar e 21 bit s f or t he net wor k
addr ess. Final l y, Cl ass D net wor ks ar e used f or mul t icast ing pur poses, when a gener al
br oadcast t o mor e t han one device is r equir ed. The l engt hs of each sect ion of t he IP
addr ess have been car ef ul l y chosen t o pr ovide maximum f l exibil it y in assigning bot h
net wor k and l ocal addr esses.
IP addr esses ar e f our set s of 8 bit s, f or a t ot al 32 bit s. You of t en r epr esent t hese bit s as
separ at ed by a per iod f or convenience, so t he IP addr ess f or mat can be t hought of as
net wor k.l ocal .l ocal .l ocal f or Cl ass A or net wor k.net wor k.net wor k.l ocal f or Cl ass C.
The IP addr esses ar e usual l y wr it t en out in t heir decimal equival ent s, inst ead of t he
l ong binar y st r ings. This is t he f amil iar host addr ess number t hat net wor k user s ar e used
t o seeing, such as 147.10.13.28, which woul d indicat e t hat t he net wor k addr ess is 147.10
and t he l ocal or host addr ess is 13.28. Of cour se, t he act ual addr ess is a set of 1s and 0s.
The decimal not at ion used f or IP addr esses is pr oper l y cal l ed dotted quad notationa bit of
t r ivia f or your next dinner par t y.
The IP addr esses can be t r ansl at ed t o common names and l et t er s. This can pose a pr obl em,
t hough, because t her e must be some met hod of unambiguousl y r el at ing t he physical
addr ess, t he net wor k addr ess, and a l anguage-based name (such a t pci_ws_4 or
bobs_machine). The sect ion l at er in t his chapt er t it l ed "The Domain Name Syst em" l ooks
at t his aspect of addr ess naming.
Fr om t he IP addr ess, a net wor k can det er mine if t he dat a is t o be sent out t hr ough a
gat eway. If t he net wor k addr ess is t he same as t he cur r ent addr ess (r out ing t o a l ocal
net wor k device, cal l ed a direct host), t he gat eway is avoided, but al l ot her net wor k
addr esses ar e r out ed t o a gat eway t o l eave t he l ocal net wor k (indirect host). The
gat eway r eceiving dat a t o be t r ansmit t ed t o anot her net wor k must t hen det er mine t he
r out ing f r om t he dat a's IP addr ess and an int er nal t abl e t hat pr ovides r out ing
inf or mat ion.
As ment ioned, if an addr ess is set t o al l 1s, t he addr ess appl ies t o al l addr esses on t he
net wor k. (See t he pr evious sect ion t it l ed "Physical Addr esses.") The same r ul e appl ies t o
IP addr esses, so t hat an IP addr ess of 32 1s is consider ed a br oadcast message t o al l
net wor ks and al l devices. It is possibl e t o br oadcast t o al l machines in a net wor k by
al t er ing t he l ocal or host addr ess t o al l 1s, so t hat t he addr ess 147.10.255.255 f or a
Cl ass B net wor k (ident if ied as net wor k 147.10) woul d be r eceived by al l devices on t hat
net wor k (255.255 being t he l ocal addr esses composed of al l 1s), but t he dat a woul d not
l eave t he net wor k.
Ther e ar e t wo cont r adict or y ways t o indicat e br oadcast s. The l at er ver sions of TCP/IP
use 1s, but ear l ier BSD syst ems use 0s. This causes a l ot of conf usion. Al l t he devices on a
net wor k must know which br oadcast convent ion is used; ot her wise, dat agr ams can be
st uck on t he net wor k f or ever !
A sl ight t wist is coding t he net wor k addr ess as al l 0s, which means t he or iginat ing
net wor k or t he l ocal addr ess being set t o 0s, which r ef er s t o t he or iginat ing device onl y
(usual l y used onl y when a device is t r ying t o det er mine it s IP addr ess). The al l -zer o
net wor k addr ess f or mat is used when t he net wor k IP addr ess is not known but ot her
devices on t he net wor k can st il l int er pr et t he l ocal addr ess. If t his wer e t r ansmit t ed t o
anot her net wor k, it coul d cause conf usion! By convent ion, no l ocal device is given a
physical addr ess of 0.
It is possibl e f or a device t o have mor e t han one IP addr ess if it is connect ed t o mor e t han
one net wor k, as is t he case wit h gat eways. These devices ar e cal l ed multihomed, because
t hey have a unique addr ess f or each net wor k t hey ar e connect ed t o. In pr act ice, it is best
t o have a dedicat e machine f or a mul t ihomed gat eway; ot her wise, t he appl icat ions on
t hat machine can get conf used as t o which addr ess t hey shoul d use when buil ding
dat agr ams.
Two net wor ks can have t he same net wor k addr ess if t hey ar e connect ed by a gat eway.
This can cause pr obl ems f or addr essing, because t he gat eway must be abl e t o
dif f er ent iat e which net wor k t he physical addr ess is on. This pr obl em is l ooked at again in
t he next sect ion, showing how it can be sol ved.
Address Resolution Protocol
Det er mining addr esses can be dif f icul t because ever y machine on t he net wor k might not
have a l ist of al l t he addr esses of t he ot her machines or devices. Sending dat a f r om one
machine t o anot her if t he r ecipient machine's physical addr ess is not known can cause a
pr obl em if t her e is no r esol ut ion syst em f or det er mining t he addr esses. Having t o
const ant l y updat e a t abl e of addr esses on each machine woul d be a net wor k
administ r at ion night mar e. The pr obl em is not r est r ict ed t o machine addr esses wit hin a
smal l net wor k, because if t he r emot e dest inat ion net wor k addr esses ar e unknown,
r out ing and del iver y pr obl ems wil l al so occur .
The Addr ess Resol ut ion Pr ot ocol (ARP) hel ps sol ve t hese pr obl ems. ARP's job is t o
conver t IP addr esses t o physical addr esses (net wor k and l ocal ) and in doing so, el iminat e
t he need f or appl icat ions t o know about t he physical addr esses. Essent ial l y, ARP is a
t abl e wit h a l ist of t he IP addr esses and t heir cor r esponding physical addr esses. The
t abl e is cal l ed an ARP cache. The l ayout of an ARP cache is shown in Figur e 2.10. Each
r ow cor r esponds t o one device, wit h f our pieces of inf or mat ion f or each device:
Figur e 2.10. The ARP cache addr ess t r ansl at ion t abl e l ayout .
G IF Index: The physical por t (int er f ace)
G Physical Addr ess: The physical addr ess of t he device
G IP Addr ess: The IP addr ess cor r esponding t o t he physical addr ess
G Type: The t ype of ent r y in t he ARP cache
Mapping Types
The mapping t ype is one of f our possibl e val ues indicat ing t he st at us of t he ent r y in t he
ARP cache. A val ue of 2 means t he ent r y is inval id; a val ue of 3 means t he mapping is
dynamic (t he ent r y can change); a val ue of 4 means st at ic (t he ent r y doesn't change);
and a val ue of 1 means none of t he above.
When t he ARP r eceives a r ecipient device's IP addr ess, it sear ches t he ARP cache f or a
mat ch. If it f inds one, it r et ur ns t he physical addr ess. If t he ARP cache doesn't f ind a
mat ch f or an IP addr ess, it sends a message out on t he net wor k. The message, cal l ed an
ARP request, is a br oadcast t hat is r eceived by al l devices on t he l ocal net wor k. (You
might r emember t hat a br oadcast has al l 1s in t he addr ess.) The ARP r equest cont ains t he
IP addr ess of t he int ended r ecipient device. If a device r ecognizes t he IP addr ess as
bel onging t o it , t he device sends a r epl y message cont aining it s physical addr ess back t o
t he machine t hat gener at ed t he ARP r equest , which pl aces t he inf or mat ion int o it s ARP
cache f or f ut ur e use. In t his manner , t he ARP cache can det er mine t he physical addr ess
f or any machine based on it s IP addr ess.
Whenever an ARP r equest is r eceived by an ARP cache, it uses t he inf or mat ion in t he
r equest t o updat e it s own t abl e. Thus, t he syst em can accommodat e changing physical
addr esses and new addit ions t o t he net wor k dynamical l y wit hout having t o gener at e an
ARP r equest of it s own. Wit hout t he use of an ARP cache, al l t he ARP r equest s and
r epl ies woul d gener at e a l ot of net wor k t r af f ic, which can have a ser ious impact on
net wor k per f or mance. Some simpl er net wor k schemes abandon t he cache and simpl y use
br oadcast messages each t ime. This is f easibl e onl y when t he number of devices is l ow
enough t o avoid net wor k t r af f ic pr obl ems.
The l ayout of t he ARP r equest is shown in Figur e 2.11. When an ARP r equest is sent , al l
f iel ds in t he l ayout ar e used except t he Recipient Har dwar e Addr ess (which t he r equest
is t r ying t o ident if y). In an ARP r epl y, al l t he f iel ds ar e used.
Figur e 2.11. The ARP r equest and ARP r epl y l ayout .
This l ayout , which is combined wit h t he net wor k syst em's pr ot ocol s int o a pr ot ocol dat a
unit (PDU), has sever al f iel ds. The f iel ds and t heir pur poses ar e as f ol l ows:
G Har dwar e Type: The t ype of har dwar e int er f ace
G Pr ot ocol Type: The t ype of pr ot ocol t he sending device is using
G Har dwar e Addr ess Lengt h: The l engt h of each har dwar e addr ess in t he dat agr am,
given in byt es
G Pr ot ocol Addr ess Lengt h: The l engt h of t he pr ot ocol addr ess in t he dat agr am,
given in byt es
G Oper at ion Code (Opcode): The Opcode indicat es whet her t he dat agr am is an ARP
r equest or an ARP r epl y. If t he dat agr am is a r equest , t he val ue is set t o 1. If it is a
r epl y, t he val ue is set t o 2.
G Sender Har dwar e Addr ess: The har dwar e addr ess of t he sending device
G Sender IP Addr ess: The IP addr ess of t he sending device
G Recipient IP Addr ess: The IP Addr ess of t he r ecipient
G Recipient Har dwar e Addr ess: The har dwar e addr ess of t he r ecipient device
Some of t hese f iel ds need a l it t l e mor e expl anat ion t o show t heir l egal val ues and f iel d
usage. The f ol l owing sect ions descr ibe t hese f iel ds in mor e det ail .
The Hardware Type Field
The har dwar e t ype ident if ies t he t ype of har dwar e int er f ace. Legal val ues ar e as
f ol l ows:
Type Description
1 Et her net
2 Exper iment al Et her net
3 X.25
4 Pr ot eon Pr oNET (Token Ring)
5 Chaos
6 IEEE 802.X
7 ARCnet
The Protocol Type Field
The pr ot ocol t ype ident if ies t he t ype of pr ot ocol t he sending device is using. Wit h TCP/IP,
t hese pr ot ocol s ar e usual l y an Et her Type, f or which t he l egal val ues ar e as f ol l ows:
Decimal Description
512 XEROX PUP
513 PUP Addr ess Tr ansl at ion
1536 XEROX NS IDP
2048 Int er net Pr ot ocol (IP)
2049 X.75
2050 NBS
2051 ECMA
2052 Chaosnet
2053 X.25 Level 3
2054 Addr ess Resol ut ion Pr ot ocol (ARP)
2055 XNS
4096 Ber kel ey Tr ail er
21000 BBN Simnet
24577 DEC MOP Dump/Load
24578 DEC MOP Remot e Consol e
24579 DEC DECnet Phase IV
24580 DEC LAT
24582 DEC
24583 DEC
32773 HP Pr obe
32784 Excel an
32821 Rever se ARP
32824 DEC LANBr idge
32823 Appl eTal k
If t he pr ot ocol is not Et her Type, ot her val ues ar e al l owed.
ARP and IP Addresses
Two (or mor e) net wor ks connect ed by a gat eway can have t he same net wor k addr ess. The
gat eway has t o det er mine which net wor k t he physical addr ess or IP addr ess cor r esponds
wit h. The gat eway can do t his wit h a modif ied ARP, cal l ed t he Pr oxy ARP (somet imes
cal l ed Pr omiscuous ARP). A pr oxy ARP cr eat es an ARP cache consist ing of ent r ies f r om
bot h net wor ks, wit h t he gat eway abl e t o t r ansf er dat agr ams f r om one net wor k t o t he
ot her . The gat eway has t o manage t he ARP r equest s and r epl ies t hat cr oss t he t wo
net wor ks.
An obvious f l aw wit h t he ARP syst em is t hat if a device doesn't know it s own IP addr ess,
t her e is no way t o gener at e r equest s and r epl ies. This can happen when a new device
(t ypical l y a diskl ess wor kst at ion) is added t o t he net wor k. The onl y addr ess t he device is
awar e of is t he physical addr ess set eit her by swit ches on t he net wor k int er f ace or by
sof t war e. A simpl e sol ut ion is t he Rever se Addr ess Resol ut ion Pr ot ocol (RARP), which
wor ks t he r ever se of ARP, sending out t he physical addr ess and expect ing back an IP
addr ess. The r epl y cont aining t he IP addr ess is sent by an RARP ser ver , a machine t hat
can suppl y t he inf or mat ion. Al t hough t he or iginat ing device sends t he message as a
br oadcast , RARP r ul es st ipul at e t hat onl y t he RARP ser ver can gener at e a r epl y. (Many
net wor ks assign mor e t han one RARP ser ver , bot h t o spr ead t he pr ocessing l oad and t o
act as a backup in case of pr obl ems.)
The Domain Name System
Inst ead of using t he f ul l 32-bit IP addr ess, many syst ems adopt mor e meaningf ul names f or
t heir devices and net wor ks. Net wor k names usual l y r ef l ect t he or ganizat ion's name
(such as t pci.com and bobs_cement ). Individual device names wit hin a net wor k can r ange
f r om descr ipt ive names on smal l net wor ks (such as t ims_machine and l aser _1) t o mor e
compl ex naming convent ions on l ar ger net wor ks (such as hpws_23 and t pci704).
Tr ansl at ing bet ween t hese names and t he IP addr esses woul d be pr act ical l y impossibl e on
an Int er net -wide scal e.
To sol ve t he pr obl em of net wor k names, t he Net wor k Inf or mat ion Cent er (NIC) maint ains
a l ist of net wor k names and t he cor r esponding net wor k gat eway addr esses. This syst em
gr ew f r om a simpl e f l at -f il e l ist (which was sear ched f or mat ches) t o a mor e compl icat ed
syst em cal l ed t he Domain Name Syst em (DNS) when t he net wor ks became t oo numer ous
f or t he f l at -f il e syst em t o f unct ion ef f icient l y.
DNS uses a hier ar chical ar chit ect ur e, much l ike t he UNIX f il esyst em. The f ir st l evel of
naming divides net wor ks int o t he cat egor y of subnet wor ks, such as com f or commer cial ,
mil f or mil it ar y, edu f or educat ion, and so on. Bel ow each of t hese is anot her division
t hat ident if ies t he individual subnet wor k, usual l y one f or each or ganizat ion. This is
cal l ed t he domain name and is unique. The or ganizat ion's syst em manager can f ur t her
divide t he company's subnet wor ks as desir ed, wit h each net wor k cal l ed a subdomain. For
exampl e, t he syst em mer l in.abc_cor p.com has t he domain name abc_cor p.com, wher eas t he
net wor k mer l in.abc_cor p is a subdomain of mer l in.abc_cor p.com. A net wor k can be
ident if ied wit h an absolute name (such as mer l in.abc_cor p.com) or a relative name (such as
mer l in) t hat uses par t of t he compl et e domain name.
Seven f ir st -l evel domain names have been est abl ished by t he NIC so f ar . These ar e as
f ol l ows:
.ar pa An ARPANET-Int er net ident if icat ion
.com Commer cial company
.edu Educat ional inst it ut ion
.gov Any gover nment al body
.mil Mil it ar y
.net Net wor ks used by Int er net Ser vice Pr ovider s
.or g Anyt hing t hat doesn't f al l int o one of t he ot her cat egor ies
The NIC al so al l ows f or a count r y designat or t o be appended. Ther e ar e designat or s f or
al l count r ies in t he wor l d, such as .ca f or Canada and .uk f or t he Unit ed Kingdom.
DNS uses t wo syst ems t o est abl ish and t r ack domain names. A name resolver on each
net wor k examines inf or mat ion in a domain name. If it can't f ind t he f ul l IP addr ess, it
quer ies a name server, which has t he f ul l NIC inf or mat ion avail abl e. The name r esol ver
t r ies t o compl et e t he addr essing inf or mat ion using it s own dat abase, which it updat es in
much t he same manner as t he ARP syst em (discussed ear l ier ) when it must quer y a name
ser ver . If a quer ied name ser ver cannot r esol ve t he addr ess, it can quer y anot her name
ser ver , and so on, acr oss t he ent ir e int er net wor k.
Ther e is a consider abl e amount of inf or mat ion st or ed in t he name r esol ver and name
ser ver , as wel l as a whol e set of pr ot ocol s f or quer ying bet ween t he t wo. The det ail s,
l uckil y, ar e not impor t ant t o an under st anding of TCP/IP, al t hough t he over al l concept
of t he addr ess r esol ut ion is impor t ant when under st anding how t he Int er net t r ansl at es
bet ween domain names and IP addr esses.
Summary
In t his chapt er you have seen t he r el at ionship of OSI and TCP/IP l ayer ed ar chit ect ur es, a
hist or y of TCP/IP and t he Int er net , t he st r uct ur e of t he Int er net , Int er net and IP
addr esses, and t he Addr ess Resol ut ion Pr ot ocol . Using t hese concept s, you can now move
on t o l ook at t he TCP/IP f amil y of pr ot ocol s in mor e det ail .
The next chapt er begins wit h t he Int er net Pr ot ocol (IP), showing how it is used and t he
f or mat of it s header inf or mat ion. The r est of t he chapt er cover s gat eway inf or mat ion
necessar y t o piece t oget her t he r est of t he pr ot ocol s. Gat eways ar e al so r evisit ed on
Day 5.
Q&A
Expl ain t he r ol e of gat eways in int er net wor ks.
Gat eways act as a r el ay bet ween net wor ks, passing dat agr ams f r om net wor k t o net wor k
sear ching f or a dest inat ion addr ess. Net wor ks t al k t o each ot her t hr ough gat eways.
Expand t he f ol l owing TCP/IP pr ot ocol acr onyms: DNS, SNMP, NFS, RPC, TFTP.
DNS is t he Domain Name Ser ver , which al l ows a common name t o be used inst ead of an IP
addr ess. SNMP is t he Simpl e Net wor k Management Pr ot ocol , used t o pr ovide inf or mat ion
about devices. NFS is t he Net wor k Fil e Syst em, a pr ot ocol t hat al l ows machines t o access
ot her f il e syst ems as if t hey wer e par t of t heir own. RPC is t he Remot e Pr ocedur e Cal l
pr ot ocol t hat al l ows appl icat ions t o communicat e. TFTP is t he Tr ivial Fil e Tr ansf er
Pr ot ocol , a simpl e f il e t r ansf er syst em wit h no secur it y.
Name t he Int er net ' s advisor y bodies.
The Int er net Advisor y Boar d (IAB) cont r ol s t he Int er net . The Int er net Engineer ing Task
For ce (IETF) handl es impl ement at ions of pr ot ocol s on t he Int er net , and t he Int er net
Resear ch Task For ce (IRTF) handl es r esear ch.
What does ARP do?
The Addr ess Resol ut ion Pr ot ocol conver t s IP addr esses t o physical device addr esses.
What ar e t he f our IP addr ess cl ass st r uct ur es and t heir st r uct ur e?
Cl ass A f or l ar ge net wor ks: Net wor k addr ess is 7 bit s, l ocal addr ess is 24 bit s. Cl ass B f or
midsize net wor ks: Net wor k addr ess is 14 bit s, l ocal addr ess is 16 bit s. Cl ass C f or smal l
net wor ks: Net wor k addr ess is 21 bit s, l ocal addr ess is 8 bit s. Cl ass D f or mul t icast
addr esses, using 28 bit s. Cl ass D net wor ks ar e sel dom encount er ed.
Quiz
1. Dr aw t he l ayer ed ar chit ect ur es of bot h t he OSI Ref er ence Model and TCP/IP.
Show how t he l ayer s cor r espond in each diagr am.
2. Show t he l ayer ed Int er net ar chit ect ur e, expl aining each l ayer 's pur pose.
3. Show how a dat agr am is t r ansf er r ed f r om one net wor k, t hr ough one or mor e
gat eways, t o t he dest inat ion net wor k. In each device, show t he l ayer ed
ar chit ect ur e and how high up t he l ayer ed st r uct ur e t he dat agr ams goes.
4. Dr aw t he IP header and an Et her net f r ame, showing t he number of bit s used f or
each component . Expl ain each component 's r ol e.
5. Expl ain what an ARP cache is. What is it s st r uct ur e and why is it used?


I Int er net Pr ot ocol
I The Int er net Pr ot ocol Dat agr am Header
I Ver sion Number
I Header Lengt h
I Type of Ser vice
I Dat agr am Lengt h (or Packet Lengt h)
I Ident if icat ion
I Fl ags
I Fr agment Of f set
I Time t o Live (TTL)
I Tr anspor t Pr ot ocol
I Header Checksum
I Sending Addr ess and Dest inat ion Addr ess
I Opt ions
I Padding
I A Dat agr am's Lif e
I Int er net Cont r ol Message Pr ot ocol (ICMP)
I IPng: IP Ver sion 6
I IPng Dat agr am
I Pr ior it y Cl assif icat ion
I Fl ow Label s
I 128-Bit IP Addr esses
I IP Ext ension Header s
I Hop-by-Hop Header s
I Rout ing Header s
I Fr agment Header s
I Aut hent icat ion Header s
I Int er net Pr ot ocol Suppor t in Dif f er ent Envir onment s
I MS-DOS
I Micr osof t Windows
I Windows NT
I OS/2
I Macint osh
I DEC
I IBM's SNA
I Local Ar ea Net wor ks
I Summar y
I Q&A
I Quiz
3
The Internet Protocol (IP)
Yest er day I l ooked at t he hist or y of TCP/IP and t he Int er net in some det ail . Today I
move on t o t he f ir st of t he t wo impor t ant pr ot ocol el ement s of TCP/IP: t he Int er net
Pr ot ocol , t he "IP" par t of TCP/IP. A good under st anding of IP is necessar y t o cont inue on
t o TCP and UDP, because t he IP is t he component t hat handl es t he movement of
dat agr ams acr oss a net wor k. Knowing how a dat agr am must be assembl ed and how it is
moved t hr ough t he net wor ks hel ps you under st and how t he higher -l evel l ayer s wor k
wit h IP. For al most al l pr ot ocol s in t he TCP/IP f amil y, IP is t he essent ial el ement t hat
packages dat a and ensur es t hat it is sent t o it s dest inat ion.
This chapt er cont ains, unf or t unat el y, even mor e det ail on header s, pr ot ocol s, and
messaging t han you saw in t he l ast coupl e of days. This l evel of inf or mat ion is necessar y
in or der f or you t o deal wit h under st anding t he appl icat ions and t heir int er act ion wit h
IP, as wel l as t r oubl eshoot ing t he syst em. Al t hough I don't go int o exhaust ive det ail ,
t her e is enough her e t hat you can r ef er back t o t his chapt er whenever needed.
As wit h many of t he subject s I l ook at in t his book, don't assume t hat t his chapt er cover s
ever yt hing t her e is t o know about IP. Ther e ar e many books wr it t en on IP al one, going
int o each f acet of t he pr ot ocol and it s f unct ional it y. Luckil y, most of t he det ail s ar e
t r anspar ent t o you, and t her e is l it t l e advant age gained in knowing it . For t hat r eason,
I simpl if y t he subject a l it t l e, st il l pr oviding enough det ail f or you t o see how IP wor ks
and what it does.
Internet Protocol
The Int er net Pr ot ocol (IP) is a pr imar y pr ot ocol of t he OSI model , as wel l as an int egr al
par t of TCP/IP (as t he name suggest s). Al t hough t he wor d "Int er net " appear s in t he
pr ot ocol 's name, it is not r est r ict ed t o use wit h t he Int er net . It is t r ue t hat al l machines
on t he Int er net can use or under st and IP, but IP can al so be used on dedicat ed net wor ks
t hat have no r el at ion t o t he Int er net at al l . IP def ines a pr ot ocol , not a connect ion.
Indeed, IP is a ver y good choice f or any net wor k t hat needs an ef f icient pr ot ocol f or
machine-t o-machine communicat ions, al t hough it f aces some compet it ion f r om pr ot ocol s
l ike Novel l Net War e's IPX on smal l t o medium l ocal ar ea net wor ks t hat use Net War e as
a PC ser ver oper at ing syst em.
What does IP do? It s main t asks ar e addr essing of dat agr ams of inf or mat ion bet ween
comput er s and managing t he f r agment at ion pr ocess of t hese dat agr ams. The pr ot ocol
has a f or mal def init ion of t he l ayout of a dat agr am of inf or mat ion and t he f or mat ion of
a header composed of inf or mat ion about t he dat agr am. IP is r esponsibl e f or t he r out ing
of a dat agr am, det er mining wher e it wil l be sent , and devising al t er nat e r out es in case
of pr obl ems.
Anot her impor t ant aspect of IP's pur pose has t o do wit h unr el iabl e del iver y of a
dat agr am. Unr el iabl e in t he IP sense means t hat t he del iver y of t he dat agr am is not
guar ant eed, because it can get del ayed, misr out ed, or mangl ed in t he br eakdown and
r eassembl y of message f r agment s. IP has not hing t o do wit h f l ow cont r ol or r el iabil it y:
t her e is no inher ent capabil it y t o ver if y t hat a sent message is cor r ect l y r eceived. IP
does not have a checksum f or t he dat a cont ent s of a dat agr am, onl y f or t he header
inf or mat ion. The ver if icat ion and f l ow cont r ol t asks ar e l ef t t o ot her component s in
t he l ayer model . (For t hat mat t er , IP doesn't even pr oper l y handl e t he f or war ding of
dat agr ams. IP can make a guess as t o t he best r out ing t o move a dat agr am t o t he next
node al ong a pat h, but it does not inher ent l y ver if y t hat t he chosen pat h is t he f ast est
or most ef f icient r out e.) Par t of t he IP syst em def ines how gat eways manage dat agr ams,
how and when t hey shoul d pr oduce er r or messages, and how t o r ecover f r om pr obl ems
t hat might ar ise.
In t he f ir st chapt er , you saw how dat a can be br oken int o smal l er sect ions f or
t r ansmission and t hen r eassembl ed at anot her l ocat ion, a pr ocess cal l ed f r agment at ion
and r eassembl y. IP pr ovides f or a maximum packet size of 65,535 byt es, which is much
l ar ger t han most net wor ks can handl e, hence t he need f or f r agment at ion. IP has t he
capabil it y t o aut omat ical l y divide a dat agr am of inf or mat ion int o smal l er dat agr ams if
necessar y, using t he pr incipl es you saw in Day 1.
When t he f ir st dat agr am of a l ar ger message t hat has been divided int o f r agment s
ar r ives at t he dest inat ion, a reassembly timer is st ar t ed by t he r eceiving machine's IP
l ayer . If al l t he pieces of t he ent ir e dat agr am ar e not r eceived when t he t imer r eaches a
pr edet er mined val ue, al l t he dat agr ams t hat have been r eceived ar e discar ded. The
r eceiving machine knows t he or der in which t he pieces ar e t o be r eassembl ed because of a
f iel d in t he IP header . One consequence of t his pr ocess is t hat a f r agment ed message has
a l ower chance of ar r ival t han an unf r agment ed message, which is why most
appl icat ions t r y t o avoid f r agment at ion whenever possibl e.
IP is connect ionl ess, meaning t hat it doesn't wor r y about which nodes a dat agr am passes
t hr ough al ong t he pat h, or even at which machines t he dat agr am st ar t s and ends. This
inf or mat ion is in t he header , but t he pr ocess of anal yzing and passing on a dat agr am has
not hing t o do wit h IP anal yzing t he sending and r eceiving IP addr esses. IP handl es t he
addr essing of a dat agr am wit h t he f ul l 32-bit Int er net addr ess, even t hough t he
t r anspor t pr ot ocol addr esses use 8 bit s. A new ver sion of IP, cal l ed ver sion 6 or IPng (IP
Next Gener at ion) can handl e much l ar ger header s, as you wil l see t owar d t he end of
t oday's mat er ial in t he sect ion t it l ed "IPng: IP Ver sion 6."
The Internet Protocol Datagram Header
It is t empt ing t o compar e IP t o a har dwar e net wor k such as Et her net because of t he basic
simil ar it ies in packaging inf or mat ion. Yest er day you saw how Et her net assembl es a
f r ame by combining t he appl icat ion dat a wit h a header bl ock cont aining addr ess
inf or mat ion. IP does t he same, except t he cont ent s of t he header ar e specif ic t o IP. When
Et her net r eceives an IP-assembl ed dat agr am (which incl udes t he IP header ), it adds it s
header t o t he f r ont t o cr eat e a f r amea pr ocess cal l ed encapsulation. One of t he pr imar y
dif f er ences bet ween t he IP and Et her net header s is t hat Et her net 's header cont ains t he
physical addr ess of t he dest inat ion machine, wher eas t he IP header cont ains t he IP
addr ess. You might r ecal l f r om yest er day's discussion t hat t he t r ansl at ion bet ween t he
t wo addr esses is per f or med by t he Addr ess Resol ut ion Pr ot ocol .
Encapsul at ion is t he pr ocess of adding somet hing t o t he
st ar t (and somet imes t he end) of dat a, just as a pil l capsul e
hol ds t he medicinal cont ent s. The added header and t ail give
det ail s about t he encl osed dat a.
The dat agr am is t he t r ansf er unit used by IP, somet imes mor e specif ical l y cal l ed an
Int er net dat agr am, or IP dat agr am. The specif icat ions t hat def ine IP (as wel l as most of
t he ot her pr ot ocol s and ser vices in t he TCP/IP f amil y of pr ot ocol s) def ine header s and
t ail s in t er ms of wor ds, wher e a wor d is 32 bit s. Some oper at ing syst ems use a dif f er ent
wor d l engt h, al t hough 32 bit s per wor d is t he mor e-of t en encount er ed val ue (some
minicomput er s and l ar ger syst ems use 64 bit s per wor d, f or exampl e). Ther e ar e eight bit s
t o a byt e, so a 32-bit wor d is t he same as f our byt es on most syst ems.
The IP header is six 32-bit wor ds in l engt h (24 byt es t ot al ) when al l t he opt ional f iel ds
ar e incl uded in t he header . The shor t est header al l owed by IP uses f ive wor ds (20 byt es
t ot al ). To under st and al l t he f iel ds in t he header , it is usef ul t o r emember t hat IP has
no har dwar e dependence but must account f or al l ver sions of IP sof t war e it can
encount er (pr oviding f ul l backwar d-compat ibil it y wit h pr evious ver sions of IP). The IP
header l ayout is shown schemat ical l y in Figur e 3.1. The dif f er ent f iel ds in t he IP header
ar e examined in mor e det ail in t he f ol l owing subsect ions.
Figur e 3.1. The IP header l ayout .
Version Number
This is a 4-bit f iel d t hat cont ains t he IP ver sion number t he pr ot ocol sof t war e is using.
The ver sion number is r equir ed so t hat r eceiving IP sof t war e knows how t o decode t he
r est of t he header , which changes wit h each new r el ease of t he IP st andar ds. The most
widel y used ver sion is 4, al t hough sever al syst ems ar e now t est ing ver sion 6 (cal l ed
IPng). The Int er net and most LANs do not suppor t IP ver sion 6 at pr esent .
Par t of t he pr ot ocol def init ion st ipul at es t hat t he r eceiving sof t war e must f ir st check
t he ver sion number of incoming dat agr ams bef or e pr oceeding t o anal yze t he r est of t he
header and encapsul at ed dat a. If t he sof t war e cannot handl e t he ver sion used t o buil d
t he dat agr am, t he r eceiving machine's IP l ayer r eject s t he dat agr am and ignor es t he
cont ent s compl et el y.
Header Length
This 4-bit f iel d r ef l ect s t he t ot al l engt h of t he IP header buil t by t he sending machine;
it is specif ied in 32-bit wor ds. The shor t est header is f ive wor ds (20 byt es), but t he use of
opt ional f iel ds can incr ease t he header size t o it s maximum of six wor ds (24 byt es). To
pr oper l y decode t he header , IP must know when t he header ends and t he dat a begins,
which is why t his f iel d is incl uded. (Ther e is no st ar t -of -dat a mar ker t o show wher e t he
dat a in t he dat agr am begins. Inst ead, t he header l engt h is used t o comput e an of f set
f r om t he st ar t of t he IP header t o give t he st ar t of t he dat a bl ock.)
Type of Service
The 8-bit (1 byt e) Ser vice Type f iel d inst r uct s IP how t o pr ocess t he dat agr am pr oper l y.
The f iel d's 8 bit s ar e r ead and assigned as shown in Figur e 3.2, which shows t he l ayout of
t he Ser vice Type f iel d inside t he l ar ger IP header shown in Figur e 3.1. The f ir st 3 bit s
indicat e t he dat agr am's pr ecedence, wit h a val ue f r om 0 (nor mal ) t hr ough 7 (net wor k
cont r ol ). The higher t he number , t he mor e impor t ant t he dat agr am and, in t heor y at
l east , t he f ast er t he dat agr am shoul d be r out ed t o it s dest inat ion. In pr act ice, t hough,
most impl ement at ions of TCP/IP and pr act ical l y al l har dwar e t hat uses TCP/IP ignor es
t his f iel d, t r eat ing al l dat agr ams wit h t he same pr ior it y.
Figur e 3.2. The 8-bit Ser vice Type f iel d l ayout .
The next t hr ee bit s ar e 1-bit f l ags t hat cont r ol t he del ay, t hr oughput , and r el iabil it y
of t he dat agr am. If t he bit is set t o 0, t he set t ing is nor mal . A bit set t o 1 impl ies l ow
del ay, high t hr oughput , and high r el iabil it y f or t he r espect ive f l ags. The l ast t wo bit s
of t he f iel d ar e not used. Most of t hese bit s ar e ignor ed by cur r ent IP impl ement at ions,
and al l dat agr ams ar e t r eat ed wit h t he same del ay, t hr oughput , and r el iabil it y
set t ings.
For most pur poses, t he val ues of al l t he bit s in t he Ser vice Type f iel d ar e set t o 0 because
dif f er ences in pr ecedence, del ay, t hr oughput , and r el iabil it y bet ween machines ar e
vir t ual l y nonexist ent unl ess a special net wor k has been est abl ished. Al t hough t hese
f l ags woul d be usef ul in est abl ishing t he best r out ing met hod f or a dat agr am, no
cur r ent l y avail abl e UNIX-based IP syst em bot her s t o eval uat e t he bit s in t hese f iel ds.
(Al t hough it is conceivabl e t hat t he code coul d be modif ied f or high secur it y or high
r el iabil it y net wor ks.)
Datagram Length (or Packet Length)
This f iel d gives t he t ot al l engt h of t he dat agr am, incl uding t he header , in byt es. The
l engt h of t he dat a ar ea it sel f can be comput ed by subt r act ing t he header l engt h f r om
t his val ue. The size of t he t ot al dat agr am l engt h f iel d is 16 bit s, hence t he 65,535 byt es
maximum l engt h of a dat agr am (incl uding t he header ). This f iel d is used t o det er mine t he
l engt h val ue t o be passed t o t he t r anspor t pr ot ocol t o set t he t ot al f r ame l engt h.
Identification
This f iel d hol ds a number t hat is a unique ident if ier cr eat ed by t he sending node. This
number is r equir ed when r eassembl ing f r agment ed messages, ensur ing t hat t he f r agment s
of one message ar e not int er mixed wit h ot her s. Each chunk of dat a r eceived by t he IP
l ayer f r om a higher pr ot ocol l ayer is assigned one of t hese ident if icat ion number s when
t he dat a ar r ives. If a dat agr am is f r agment ed, each f r agment has t he same ident if icat ion
number .
Flags
The Fl ags f iel d is a 3-bit f iel d, t he f ir st bit of which is l ef t unused (it is ignor ed by t he
pr ot ocol and usual l y has no val ue wr it t en t o it ). The r emaining t wo bit s ar e dedicat ed
t o f l ags cal l ed DF (Don't Fr agment ) and MF (Mor e Fr agment s), which cont r ol t he
handl ing of t he dat agr ams when f r agment at ion is desir abl e.
If t he DF f l ag is set t o 1, t he dat agr am cannot be f r agment ed under any cir cumst ances.
If t he cur r ent IP l ayer sof t war e cannot send t he dat agr am on t o anot her machine
wit hout f r agment ing it , and t his bit is set t o 1, t he dat agr am is discar ded and an er r or
message is sent back t o t he sending device.
If t he MF f l ag is set t o 1, t he cur r ent dat agr am is f ol l owed by mor e packet s (somet imes
cal l ed subpackets), which must be r eassembl ed t o r e-cr eat e t he f ul l message. The l ast
f r agment t hat is sent as par t of a l ar ger message has it s MF f l ag set t o 0 (of f ) so t hat
t he r eceiving device knows when t o st op wait ing f or dat agr ams. Because t he or der of
t he f r agment s' ar r ival might not cor r espond t o t he or der in which t hey wer e sent , t he
MF f l ag is used in conjunct ion wit h t he Fr agment Of f set f iel d (t he next f iel d in t he IP
header ) t o indicat e t o t he r eceiving machine t he f ul l ext ent of t he message.
Fragment Offset
If t he MF (Mor e Fr agment s) f l ag bit is set t o 1 (indicat ing f r agment at ion of a l ar ger
dat agr am), t he f r agment of f set cont ains t he posit ion in t he compl et e message of t he
submessage cont ained wit hin t he cur r ent dat agr am. This enabl es IP t o r eassembl e
f r agment ed packet s in t he pr oper or der .
Of f set s ar e al ways given r el at ive t o t he beginning of t he message. This is a 13-bit f iel d,
so of f set s ar e cal cul at ed in unit s of 8 byt es, cor r esponding t o t he maximum packet
l engt h of 65,535 byt es. Using t he ident if icat ion number t o indicat e which message a
r eceiving dat agr am bel ongs t o, t he IP l ayer on a r eceiving machine can t hen use t he
f r agment of f set t o r eassembl e t he ent ir e message.
Time to Live (TTL)
This f iel d gives t he amount of t ime in seconds t hat a dat agr am can r emain on t he
net wor k bef or e it is discar ded. This is set by t he sending node when t he dat agr am is
assembl ed. Usual l y t he TTL f iel d is set t o 15 or 30 seconds.
The TCP/IP st andar ds st ipul at e t hat t he TTL f iel d must be decr eased by at l east one
second f or each node t hat pr ocesses t he packet , even if t he pr ocessing t ime is l ess t han
one second. Al so, when a dat agr am is r eceived by a gat eway, t he ar r ival t ime is t agged so
t hat if t he dat agr am must wait t o be pr ocessed, t hat t ime count s against it s TTL. Hence,
if a gat eway is par t icul ar l y over l oaded and can't get t o t he dat agr am in shor t or der ,
t he TTL t imer can expir e whil e await ing pr ocessing, and t he dat agr am is abandoned.
If t he TTL f iel d r eaches 0, t he dat agr am must be discar ded by t he cur r ent node, but a
message is sent back t o t he sending machine when t he packet is dr opped. The sending
machine can t hen r esend t he dat agr am. The r ul es gover ning t he TTL f iel d ar e designed
t o pr event IP packet s f r om endl essl y cir cul at ing t hr ough net wor ks.
Transport Protocol
This f iel d hol ds t he ident if icat ion number of t he t r anspor t pr ot ocol t o which t he
packet has been handed. The number s ar e def ined by t he Net wor k Inf or mat ion Cent er
(NIC), which gover ns t he Int er net . Ther e ar e cur r ent l y about 50 pr ot ocol s def ined and
assigned a t r anspor t pr ot ocol number . The t wo most impor t ant pr ot ocol s ar e ICMP
(det ail ed in t he sect ion t it l ed "Int er net Cont r ol Message Pr ot ocol (ICMP)" l at er
t oday), which is number 1, and TCP, which is number 6. The f ul l l ist of number s is not
necessar y her e because most of t he pr ot ocol s ar e never encount er ed by user s. (If you
r eal l y want t his inf or mat ion, it s in sever al RFCs ment ioned in t he apendixes.)
Header Checksum
The number in t his f iel d of t he IP header is a checksum f or t he pr ot ocol header f iel d
(but not t he dat a f iel ds) t o enabl e f ast er pr ocessing. Because t he Time t o Live (TTL)
f iel d is decr ement ed at each node, t he checksum al so changes wit h ever y machine t he
dat agr am passes t hr ough. The checksum al gor it hm t akes t he ones-compl ement of t he 16-
bit sum of al l 16-bit wor ds.
This is a f ast , ef f icient al gor it hm, but it misses some unusual cor r upt ion cir cumst ances
such as t he l oss of an ent ir e 16-bit wor d t hat cont ains onl y 0s. However , because t he
dat a checksums used by bot h TCP and UDP cover t he ent ir e packet , t hese t ypes of er r or s
usual l y can be caught as t he f r ame is assembl ed f or t he net wor k t r anspor t .
Sending Address and Destination Address
These f iel ds cont ain t he 32-bit IP addr esses of t he sending and dest inat ion devices. These
f iel ds ar e est abl ished when t he dat agr am is cr eat ed and ar e not al t er ed dur ing t he
r out ing.
Options
The Opt ions f iel d is opt ional , composed of sever al codes of var iabl e l engt h. If mor e t han
one opt ion is used in t he dat agr am, t he opt ions appear consecut ivel y in t he IP header .
Al l t he opt ions ar e cont r ol l ed by a byt e t hat is usual l y divided int o t hr ee f iel ds: a 1-bit
copy f l ag, a 2-bit opt ion cl ass, and a 5-bit opt ion number . The copy f l ag is used t o
st ipul at e how t he opt ion is handl ed when f r agment at ion is necessar y in a gat eway.
When t he bit is set t o 0, t he opt ion shoul d be copied t o t he f ir st dat agr am but not
subsequent ones. If t he bit is set t o 1, t he opt ion is copied t o al l t he dat agr ams.
The opt ion cl ass and opt ion number indicat e t he t ype of opt ion and it s par t icul ar val ue.
At pr esent , t her e ar e onl y t wo opt ion cl asses set . (Wit h onl y 2 bit s t o wor k wit h in t he
f iel d, a maximum of f our opt ions coul d be set .) When t he val ue is 0, t he opt ion appl ies t o
dat agr am or net wor k cont r ol . A val ue of 2 means t he opt ion is f or debugging or
administ r at ion pur poses. Val ues of 1 and 3 ar e unused. Cur r ent l y suppor t ed val ues f or
t he opt ion cl ass and number ar e given in Tabl e 3.1.
Tabl e 3.1. Val id opt ion cl ass and number s f or IP header s.
Option Class Option Number Description
0 0 Mar ks t he end of t he opt ions l ist
0 1 No opt ion (used f or padding)
0 2 Secur it y opt ions (mil it ar y pur poses onl y)
0 3 Loose sour ce r out ing
0 7 Act ivat es r out ing r ecor d (adds f iel ds)
0 9 St r ict sour ce r out ing
2 4 Timest amping act ive (adds f iel ds)
Of most int er est t o you ar e opt ions t hat enabl e t he r out ing and t imest amps t o be
r ecor ded. These ar e used t o pr ovide a r ecor d of a dat agr am's passage acr oss t he
int er net wor k, which can be usef ul f or diagnost ic pur poses. Bot h t hese opt ions add
inf or mat ion t o a l ist cont ained wit hin t he dat agr am. (The t imest amp has an int er est ing
f or mat : it is expr essed in mil l iseconds since midnight , Univer sal Time. Unf or t unat el y,
because most syst ems have widel y dif f er ing t ime set t ingseven when cor r ect ed t o
Univer sal Timet he t imest amps shoul d be t r eat ed wit h mor e t han a l it t l e suspicion.)
Ther e ar e t wo kinds of r out ing indicat ed wit hin t he Opt ions f iel d: l oose and st r ict . Loose
routing pr ovides a ser ies of IP addr esses t hat t he machine must pass t hr ough, but it
enabl es any r out e t o be used t o get t o each of t hese addr esses (usual l y gat eways). Strict
routing enabl es no deviat ions f r om t he specif ied r out e. If t he r out e can't be f ol l owed, t he
dat agr am is abandoned. St r ict r out ing is f r equent l y used f or t est ing r out es but r ar el y
f or t r ansmission of user dat agr ams because of t he higher chances of t he dat agr am being
l ost or abandoned.
Padding
The cont ent of t he padding ar ea depends on t he opt ions sel ect ed. The padding is usual l y
used t o ensur e t hat t he dat agr am header is a r ound number of byt es.
A Datagram's Life
To under st and how IP and ot her TCP/IP l ayer s wor k t o package and send a dat agr am
f r om one machine t o anot her , I t ake a simpl if ied l ook at a t ypical dat agr am's passage.
When an appl icat ion must send a dat agr am out on t he net wor k, it per f or ms a f ew simpl e
st eps. Fir st , it const r uct s t he IP dat agr am wit hin t he l egal l engt hs st ipul at ed by t he
l ocal IP impl ement at ion. The checksum is cal cul at ed f or t he dat a, and t hen t he IP
header is const r uct ed. Next , t he f ir st hop (machine) of t he r out e t o t he dest inat ion must
be det er mined t o r out e t he dat agr am t o t he dest inat ion machine dir ect l y over t he l ocal
net wor k, or t o a gat eway if t he int er net wor k is used. If r out ing is impor t ant , t his
inf or mat ion is added t o t he header using an opt ion. Final l y, t he dat agr am is passed t o
t he net wor k f or it s manipul at ion of t he dat agr am.
As a dat agr am passes al ong t he int er net wor k, each gat eway per f or ms a ser ies of t est s.
Af t er t he net wor k l ayer has st r ipped of f it s own header , t he gat eway IP l ayer
cal cul at es t he checksum and ver if ies t he int egr it y of t he dat agr am. If t he checksums
don't mat ch, t he dat agr am is discar ded and an er r or message is r et ur ned t o t he sending
device. Next , t he TTL f iel d is decr ement ed and checked. If t he dat agr am has expir ed, it is
discar ded and an er r or message is sent back t o t he sending machine. Af t er det er mining
t he next hop of t he r out e, eit her by anal ysis of t he t ar get addr ess or f r om a specif ied
r out ing inst r uct ion wit hin t he Opt ions f iel d of t he IP header , t he dat agr am is r ebuil t
wit h t he new TTL val ue and new checksum.
If f r agment at ion is necessar y because of an incr ease in t he dat agr am's l engt h or a
l imit at ion in t he sof t war e, t he dat agr am is divided, and new dat agr ams wit h t he cor r ect
header inf or mat ion ar e assembl ed. If a r out ing or t imest amp is r equir ed, it is added as
wel l . Final l y, t he dat agr am is passed back t o t he net wor k l ayer .
When t he dat agr am is f inal l y r eceived at t he dest inat ion device, t he syst em per f or ms a
checksum cal cul at ion andassuming t he t wo sums mat chchecks t o see if t her e ar e
ot her f r agment s. If mor e dat agr ams ar e r equir ed t o r eassembl e t he ent ir e message, t he
syst em wait s, meanwhil e r unning a t imer t o ensur e t hat t he dat agr ams ar r ive wit hin a
r easonabl e t ime. If al l t he par t s of t he l ar ger message have ar r ived but t he device can't
r eassembl e t hem bef or e t he t imer r eaches 0, t he dat agr am is discar ded and an er r or
message is r et ur ned t o t he sender . Final l y, t he IP header is st r ipped of f , t he or iginal
message is r econst r uct ed if it was f r agment ed, and t he message is passed up t he l ayer s t o
t he upper l ayer appl icat ion. If a r epl y was r equir ed, it is t hen gener at ed and sent back
t o t he sending device.
When ext r a inf or mat ion is added t o t he dat agr am f or r out ing or t imest amp r ecor ding,
t he l engt h of t he dat agr am can incr ease. Handl ing al l t hese condit ions is par t of IP's
f or t e, f or which pr act ical l y ever y pr obl em has a r esol ut ion syst em.
Internet Control Message Protocol (ICMP)
As you have seen t oday and over t he l ast t wo days, many pr obl ems can occur in r out ing
a message f r om sender t o r eceiver . The TTL t imer might expir e; f r agment ed dat agr ams
might not ar r ive wit h al l segment s int act ; a gat eway might misr out e a dat agr am, and so
on. Let t ing t he sending device know of a pr obl em wit h a dat agr am is impor t ant , as is
cor r ect l y handl ing er r or condit ions wit hin t he net wor k r out ing it sel f . The Int er net
Cont r ol Message Pr ot ocol (ICMP) was devel oped f or t his t ask.
ICMP is an er r or -r epor t ing syst em. It is an int egr al par t of IP and must be incl uded in
ever y IP impl ement at ion. This pr ovides f or consist ent , under st andabl e er r or messages
and signal s acr oss t he dif f er ent ver sions of IP and dif f er ent oper at ing syst ems. It is
usef ul t o t hink of ICMP as one IP package designed specif ical l y t o t al k t o anot her IP
package acr oss t he net wor k: in ot her wor ds, ICMP is t he IP l ayer 's communicat ions
syst em. Messages gener at ed by ICMP ar e t r eat ed by t he r est of t he net wor k as any ot her
dat agr am, but t hey ar e int er pr et ed dif f er ent l y by t he IP l ayer sof t war e. ICMP messages
have a header buil t in t he same manner as any IP dat agr am, and ICMP dat agr ams ar e not
dif f er ent iat ed at any point f r om nor mal dat a-car r ying dat agr ams unt il a r eceiving
machine's IP l ayer pr ocesses t he dat agr am pr oper l y.
In al most al l cases, er r or messages sent by ICMP ar e r out ed back t o t he or iginal
dat agr am's sending machine. This is because onl y t he sender 's and dest inat ion device's IP
addr esses ar e incl uded in t he header . Because t he er r or doesn't mean anyt hing t o t he
dest inat ion device, t he sender is t he l ogical r ecipient of t he er r or message. The sender
can t hen det er mine f r om t he ICMP message t he t ype of er r or t hat occur r ed and
est abl ish how t o best r esend t he f ail ed dat agr am.
ICMP messages go t hr ough t wo encapsul at ions, as do al l IP messages: incor por at ion int o
a r egul ar IP dat agr am and t hen int o t he net wor k f r ame. This is shown in Figur e 3.3.
ICMP header s have a dif f er ent f or mat t han IP header s, t hough, and t he f or mat dif f er s
sl ight l y depending on t he t ype of message. However , al l ICMP header s st ar t wit h t he
same t hr ee f iel ds: a message t ype, a code f iel d, and a checksum f or t he ICMP message.
Figur e 3.4 shows t he l ayout of t he ICMP message.
Figur e 3.3. Two-st ep encapsul at ion of an ICMP message.
Figur e 3.4. The l ayout of an ICMP message.
Usual l y, any ICMP message t hat is r epor t ing a pr obl em wit h del iver y al so incl udes t he
header and f ir st 64 bit s of t he dat a f iel d f r om t he dat agr am f or which t he pr obl em
occur r ed. Incl uding t he 64 bit s of t he or iginal dat agr am accompl ishes t wo t hings. Fir st ,
it enabl es t he sending device t o mat ch t he dat agr am f r agment t o t he or iginal dat agr am
by compar ison. Al so, because most of t he pr ot ocol s invol ved ar e def ined at t he st ar t of
t he dat agr am, t he incl usion of t he or iginal dat agr am f r agment al l ows f or some
diagnost ics t o be per f or med by t he machine r eceiving t he ICMP message.
The 8-bit Message Type f iel d in t he ICMP header (shown in Figur e 3.4) can have one of
t he val ues shown in Tabl e 3.2.
Tabl e 3.2. Val id val ues f or t he ICMP Message Type f iel d.
Value Description
0 Echo Repl y
3 Dest inat ion Not Reachabl e
4 Sour ce Quench
5 Redir ect ion Requir ed
8 Echo Request
11 Time t o Live Exceeded
12 Par amet er Pr obl em
13 Timest amp Request
14 Timest amp Repl y
15 Inf or mat ion Request (now obsol et e)
16 Inf or mat ion Repl y (now obsol et e)
17 Addr ess Mask Request
18 Addr ess Mask Repl y
The Code f iel d expands on t he message t ype, pr oviding a l it t l e mor e inf or mat ion f or t he
r eceiving machine. The checksum in t he ICMP header is cal cul at ed in t he same manner as
t he nor mal IP header checksum.
The l ayout of t he ICMP message is sl ight l y dif f er ent f or each t ype of message. Figur e 3.5
shows t he l ayout s of each t ype of ICMP message header . The Dest inat ion Unr eachabl e
and Time Exceeded messages ar e sel f -expl anat or y, al t hough t hey ar e used in ot her
cir cumst ances, t oo, such as when a dat agr am must be f r agment ed but t he Don't
Fr agment f l ag is set . This r esul t s in a Dest inat ion Unr eachabl e message being r et ur ned
t o t he sending machine.
Figur e 3.5. ICMP message header l ayout s.
The Sour ce Quench ICMP message is used t o cont r ol t he r at e at which dat agr ams ar e
t r ansmit t ed, al t hough t his is a ver y r udiment ar y f or m of f l ow cont r ol . When a device
r eceives a Sour ce Quench message, it shoul d r educe t he t r ansmit t al r at e over t he
net wor k unt il t he Sour ce Quench messages cease. The messages ar e t ypical l y gener at ed
by a gat eway or host t hat eit her has a f ul l r eceiving buf f er or has sl owed pr ocessing of
incoming dat agr ams because of ot her f act or s. If t he buf f er is f ul l , t he device is supposed
t o issue a Sour ce Quench message f or each dat agr am t hat is discar ded. Some
impl ement at ions issue Sour ce Quench messages when t he buf f er exceeds a cer t ain
per cent age t o sl ow down r ecept ion of new dat agr ams and enabl e t he device t o cl ear t he
buf f er .
Redir ect ion messages ar e sent t o a gat eway in t he pat h when a bet t er r out e is avail abl e.
For exampl e, if a gat eway has just r eceived a dat agr am f r om anot her gat eway but on
checking it s dat af il es f inds a bet t er r out e, it sends t he Redir ect ion message back t o t hat
gat eway wit h t he IP addr ess of t he bet t er r out e. When a Redir ect ion message is sent , an
int eger is pl aced in t he code f iel d of t he header t o indicat e t he condit ions f or which t he
r er out ing appl ies. A val ue of 0 means t hat dat agr ams f or any device on t he dest inat ion
net wor k shoul d be r edir ect ed. A val ue of 1 indicat es t hat onl y dat agr ams f or t he
specif ic device shoul d be r er out ed. A val ue of 2 impl ies t hat onl y dat agr ams f or t he
net wor k wit h t he same t ype of ser vice (r ead f r om one of t he IP header f iel ds) shoul d be
r er out ed. Final l y, a val ue of 3 r er out es onl y f or t he same host wit h t he same t ype of
ser vice.
The Par amet er Pr obl em message is used whenever a semant ic or synt act ic er r or has been
encount er ed in t he IP header . This can happen when opt ions ar e used wit h incor r ect
ar gument s. When a Par amet er Pr obl em message is sent back t o t he sending device, t he
Par amet er f iel d in t he ICMP er r or message cont ains a point er t o t he byt e in t he IP
header t hat caused t he pr obl em. (See Figur e 3.5.)
Echo r equest or r epl y messages ar e commonl y used f or debugging pur poses. When a
r equest is sent , a device or gat eway down t he pat h sends a r epl y back t o t he specif ied
device. These r equest /r epl y pair s ar e usef ul f or ident if ying r out ing pr obl ems, f ail ed
gat eways, or net wor k cabl ing pr obl ems. The simpl e act of pr ocessing an ICMP message
al so act s as a check of t he net wor k, because each gat eway or device al ong t he pat h
must cor r ect l y decode t he header s and t hen pass t he dat agr am al ong. Any f ail ur e
al ong t he way coul d be wit h t he impl ement at ion of t he IP sof t war e. A commonl y used
r equest /r epl y syst em is t he ping command. The ping command sends a ser ies of r equest s
and wait s f or r epl ies.
Timest amp r equest s and r epl ies enabl e t he t iming of message passing al ong t he net wor k
t o be monit or ed. When combined wit h st r ict r out ing, t his can be usef ul in ident if ying
bot t l enecks. Addr ess mask r equest s and r epl ies ar e used f or t est ing wit hin a specif ic
net wor k or subnet wor k.
IPng: IP Version 6
When IP ver sion 4 (t he cur r ent r el ease) was devel oped, t he use of a 32-bit IP addr ess
seemed mor e t han enough t o handl e t he pr oject ed use of t he Int er net . Wit h t he
incr edibl e gr owt h r at e of t he Int er net over t he l ast f ew year s, however , t he 32-bit IP
addr ess might become a pr obl em. To count er t his l imit , IP Next Gener at ion, usual l y
cal l ed IP ver sion 6 (IPv6), is under devel opment .
Sever al pr oposal s f or IPng impl ement at ion ar e cur r ent l y being st udied, t he most
popul ar of which ar e TUBA (TCP and UDP wit h Bigger Addr esses), CATNIP (Common
Ar chit ect ur e f or t he Int er net ), and SIPP (Simpl e Int er net Pr ot ocol Pl us). None of t he
t hr ee meet al l t he pr oposed changes f or ver sion 6, but a compr omise or modif icat ion
based on one of t hese pr oposal s is l ikel y.
What does IPng have t o of f er ? The l ist of changes t el l s you t he main f eat ur es of IPng in
a nut shel l :
G 128-bit net wor k addr ess inst ead of 32-bit
G Mor e ef f icient IP header wit h ext ensions f or appl icat ions and opt ions
G No header checksum
G A f l ow l abel f or qual it y-of -ser vice r equir ement s
G Pr event ion of int er mediat e f r agment at ion of dat agr ams
G Buil t -in secur it y f or aut hent icat ion and encr ypt ion
Next I l ook at IPng in a l it t l e mor e det ail t o show t he changes t hat af f ect most user s,
as wel l as net wor k pr ogr ammer s and net wor k administ r at or s. I st ar t wit h a l ook at t he
IPng header . Remember t hat at pr esent IPng is st il l under devel opment and is not widel y
depl oyed except on t est net wor ks.
IPng Datagram
As ment ioned ear l ier , t he header f or IPng dat agr ams has been modif ied over t he ear l ier
ver sion 4 header . The changes ar e most l y t o pr ovide suppor t f or t he new, l onger 128-bit
IP addr esses and t o r emove obsol et e and unneeded f iel ds. The basic l ayout of t he IPng
header is shown in Figur e 3.6. As you can see, t her e ar e quit e a f ew changes f r om t he IP
header used in IP ver sion 4 (see Figur e 3.1).
Figur e 3.6. The IPng header l ayout .
The ver sion number in t he IP dat agr am header is f our bit s l ong and hol ds t he r el ease
number (which is 6 wit h IPng). The Pr ior it y f iel d is f our bit s l ong and hol ds a val ue
indicat ing t he dat agr am's pr ior it y. The pr ior it y is used t o def ine t he t r ansmission or der .
The pr ior it y is set f ir st wit h a br oad cl assif icat ion, t hen a nar r ower ident if ier wit hin
each cl ass. I l ook at t he pr ior it y cl assif icat ion in a l it t l e mor e det ail in a moment .
The Fl ow Label f iel d is 24 bit s l ong and is st il l in t he devel opment st age. It is l ikel y t o
be used in combinat ion wit h t he sour ce machine IP addr ess t o pr ovide f l ow ident if icat ion
f or t he net wor k. For exampl e, if you ar e using a UNIX wor kst at ion on t he net wor k, t he
f l ow is dif f er ent f r om anot her machine such as a Windows 95 PC. This f iel d can be used
t o ident if y f l ow char act er ist ics and pr ovide some adjust ment capabil it ies. The f iel d can
al so be used t o hel p ident if y t ar get machines f or l ar ge t r ansf er s, in which case a cache
syst em becomes mor e ef f icient at r out ing bet ween sour ce and dest inat ion. Fl ow l abel s
ar e discussed in mor e det ail in t he sect ion t it l ed "Fl ow Label s" l at er t oday.
The Payl oad Lengt h f iel d is a 16-bit f iel d used t o specif y t he t ot al l engt h of t he IP
dat agr am, given in byt es. The t ot al l engt h is excl usive of t he IP header it sel f . The use
of a 16-bit f iel d l imit s t he maximum val ue in t his f iel d t o 65,535, but t her e is a pr ovision
t o send l ar ge dat agr ams using an ext ension header (see t he sect ion t it l ed "IP Ext ension
Header s" l at er t oday).
The Next Header f iel d is used t o indicat e which header f ol l ows t he IP header when
ot her appl icat ions want t o piggy-back on t he IP header . Sever al val ues have been
def ined f or t he Next Header f iel d, as shown in Tabl e 3.3.
Tabl e 3.3. IP Next Header f iel d val ues.
Value Description
0 Hop-by-hop opt ions
4 IP
6 TCP
17 UDP
43 Rout ing
44 Fr agment
45 Int er domain Rout ine
46 Resour ce Reser vat ion
50 Encapsul at ing Secur it y
51 Aut hent icat ion
58 ICMP
59 No Next Header
60 Dest inat ion Opt ions
The Hop Limit f iel d det er mines t he number of hops t he dat agr am can t r avel . Wit h each
f or war ding, t he number is decr ement ed by 1. When t he Hop Limit f iel d r eaches 0, t he
dat agr am is discar ded, just as wit h IP ver sion 4.
Final l y, t he Sending and Dest inat ion IP Addr esses in 128-bit f or mat ar e pl aced in t he
header . I l ook at t he new IP addr ess f or mat in mor e det ail in t he sect ion t it l ed "128-Bit
IP Addr esses" l at er in t his chapt er .
Priority Classification
The Pr ior it y Cl assif icat ion f iel d in t he IPng header f ir st divides t he dat agr am int o one
of t wo cat egor ies: congest ion cont r ol l ed or noncongest ion cont r ol l ed. Noncongest ion
cont r ol l ed dat agr ams ar e al ways r out ed as a pr ior it y over congest ion cont r ol l ed
dat agr ams. Ther e ar e subcl assif icat ions of noncongest ion cont r ol l ed dat agr am
pr ior it ies avail abl e f or use, but none of t he cat egor ies have been accept ed as st andar d
yet .
If t he dat agr am is congest ion cont r ol l ed, it is sensit ive t o congest ion pr obl ems on t he
net wor k. If congest ion occur s, t he dat agr am can be sl owed down and hel d t empor ar il y
in caches unt il t he pr obl em is al l eviat ed. Beneat h t he br oad congest ion cont r ol l ed
cat egor y ar e sever al subcl asses t hat f ur t her r ef ine t he pr ior it y of t he dat agr am. The
subcat egor ies of congest ion cont r ol l ed pr ior it ies ar e given in Tabl e 3.4.
Tabl e 3.4. Pr ior it ies f or congest ion cont r ol l ed dat agr ams.
Value Meaning
0 No pr ior it y specif ied
1 Backgr ound t r af f ic
2 Unat t ended dat a t r ansf er
3 Unassigned
4 At t ended bul k t r ansf er
5 Unassigned
6 Int er act ive t r af f ic
7 Cont r ol t r af f ic
Noncongest ion cont r ol l ed t r af f ic has pr ior it ies 8 t hr ough 15 avail abl e, but as I
ment ioned ear l ier , t hey ar e not def ined.
Exampl es of each of t he pr imar y subcat egor ies might hel p you see how t he dat agr ams ar e
pr ior it ized. Rout ing and net wor k management t r af f ic t hat is consider ed highest pr ior it y
is assigned cat egor y 7. Int er act ive appl icat ions such as Tel net and r emot e X sessions ar e
assigned as int er act ive t r af f ic (cat egor y 6). Tr ansf er s t hat ar e not t ime-cr it ical (such as
Tel net sessions) but ar e st il l cont r ol l ed by an int er act ive appl icat ion such as FTP ar e
assigned as cat egor y 4. E-mail is usual l y assigned as cat egor y 2, wher eas l ow-pr ior it y
mat er ial such as news is set t o cat egor y 1.
Flow Labels
As ment ioned ear l ier , t he Fl ow Label f iel d new t o t he IPng header can be used t o hel p
ident if y t he sender and dest inat ion of many IP dat agr ams. By empl oying caches t o
handl e f l ows, t he dat agr ams can be r out ed mor e ef f icient l y. Not al l appl icat ions can
handl e f l ow l abel s, in which case t he f iel d is set t o a val ue of 0.
A simpl e exampl e might hel p show t he usef ul ness of t he f l ow l abel f iel d. Suppose a PC
r unning Windows 95 is connect ed t o a UNIX ser ver on anot her net wor k and is sending a
l ar ge number of dat agr ams. By set t ing a specif ic val ue of t he f l ow l abel f or al l t he
dat agr ams in t he t r ansmission, t he r out er s al ong t he way t o t he ser ver can assembl e
ent r ies in t heir r out ing caches t hat indicat e which way t o r out e each dat agr am wit h
t he same f l ow l abel . When subsequent dat agr ams wit h t he same f l ow l abel ar r ive, t he
r out er doesn't have t o r ecal cul at e t he r out e; it can simpl y check t he cache and ext r act
t he saved inf or mat ion f r om t hat . This speeds up t he passage of t he dat agr ams t hr ough
each r out er .
To pr event caches f r om gr owing t oo l ar ge or hol ding st al e inf or mat ion, IPng st ipul at es
t hat t he cache maint ained in a r out ing device cannot be kept f or mor e t han six seconds.
If a new dat agr am wit h t he same f l ow l abel is not r eceived wit hin six seconds, t he cache
ent r y is r emoved. To pr event r epeat ed val ues f r om t he sending machine, t he sender must
wait six seconds bef or e using t he same f l ow l abel val ue f or anot her dest inat ion.
IPng al l ows f l ow l abel s t o be used t o r eser ve a r out e f or t ime-cr it ical appl icat ions. For
exampl e, a r eal -t ime appl icat ion t hat has t o send sever al dat agr ams al ong t he same
r out e and needs as r apid a t r ansmission as possibl e (such as is needed f or video or audio,
f or exampl e) can est abl ish t he r out e by sending dat agr ams ahead of t ime, being car ef ul
not t o exceed t he six second t ime-out on t he int er im r out er s.
128-Bit IP Addresses
Pr obabl y t he most impor t ant aspect of IPng is it s capabil it y t o pr ovide f or l onger IP
addr esses. IPng incr eases t he IP addr ess f r om 32 bit s t o 128 bit s. This enabl es an incr edibl e
number of addr esses t o be assembl ed, pr obabl y mor e t han can ever be used.
The new IP addr esses suppor t t hr ee kinds of addr esses: unicast , mul t icast , and anycast .
G Unicast addr esses ar e meant t o ident if y a par t icul ar machine's int er f ace. This l et s
a PC, f or exampl e, have sever al dif f er ent pr ot ocol s in use, each wit h it s own
addr ess. Thus, you coul d send messages specif ical l y t o a machine's IP int er f ace
addr ess and not t he Net BEUI int er f ace addr ess.
G A mul t icast addr ess ident if ies a gr oup of int er f aces, enabl ing al l machines in a
gr oup t o r eceive t he same packet . This is much l ike br oadcast s in IP ver sion 4,
al t hough wit h mor e f l exibil it y f or def ining gr oups. Your machine's int er f aces
coul d bel ong t o sever al mul t icast gr oups.
G An anycast addr ess ident if ies a gr oup of int er f aces on a singl e mul t icast addr ess.
In ot her wor ds, mor e t han one int er f ace can r eceive t he dat agr am on t he same
machine.
The handl ing of f r agment at ion and r eassembl y is al so changed wit h IPng t o pr ovide
mor e capabil it ies f or IP. Al so pr oposed f or IPng is an aut hent icat ion scheme t hat can
ensur e t hat t he dat a has not been cor r upt ed bet ween sender and r eceiver , as wel l as
ensur ing t hat t he sending and r eceiving machines ar e who t hey cl aim t hey ar e.
IP Extension Headers
IPng has t he pr ovision t o enabl e addit ional header s t o be t acked ont o t he IP header .
This might be necessar y when a simpl e r out ing t o t he dest inat ion is not possibl e, or when
special ser vices such as aut hent icat ion ar e r equir ed f or t he dat agr am. The addit ional
inf or mat ion r equir ed is packaged int o an ext ension header and appended t o t he IP
header .
IPng def ines sever al t ypes of ext ension header s ident if ied by a number pl aced in t he Next
Header f iel d of t he IP header . The cur r ent l y accept ed val ues and t heir meanings wer e
shown in Tabl e 3.3. Sever al ext ensions can be appended ont o one IP header , wit h each
ext ension's Next Header f iel d indicat ing t he next ext ension. Nor mal l y, t he ext ension
header s ar e appended in ascending numer ical or der . This makes it easier f or r out er s t o
anal yze t he ext ensions, st opping t he examinat ion when it get s past r out er -specif ic
ext ensions.
Hop-by-Hop Headers
Ext ension t ype 0 is hop-by-hop, which is used t o pr ovide IP opt ions t o ever y machine t he
dat agr am passes t hr ough. The opt ions incl uded in t he hop-by-hop ext ension have a
st andar d f or mat of a Type val ue, a Lengt h, and a Val ue (except f or t he Pad1 opt ion,
which has a singl e val ue set t o 0 and no l engt h or val ue f iel d). Bot h t he Type and
Lengt h f iel ds ar e a singl e byt e in l engt h, wher eas t he Val ue f iel d's l engt h is var iabl e
and indicat ed by t he l engt h byt e.
Ther e ar e t hr ee t ypes of hop-by-hop ext ensions def ined so f ar , cal l ed Pad1, PadN, and
Jumbo Payl oad. The Pad1 opt ion is a singl e byt e wit h a val ue of 0, no l engt h, and no
val ue. It is used t o al t er t he or der and posit ion of ot her opt ions in t he header when
necessar y, dict at ed usual l y by an appl icat ion. The PadN opt ion is simil ar except it has N
zer os pl aced in t he Val ue f iel d and a cal cul at ed val ue f or t he l engt h.
The Jumbo Payl oad ext ension opt ion is used t o handl e dat agr am sizes in excess of 65,535
byt es. The Lengt h f iel d in t he IP header is l imit ed t o 16 bit s, hence t he l imit of 65,535 f or
t he dat agr am size. To handl e l ar ger dat agr am l engt hs, t he IP header 's Lengt h f iel d is
set t o 0, which r edir ect s t he r out er s t o t he ext ension t o pick up a cor r ect l engt h val ue.
The Lengt h f iel d can be def ined in t he ext ension header using 32 bit s, which is in excess
of 4 t er abyt es.
Routing Headers
A r out ing ext ension can be t acked ont o t he IP header when t he sending machine want s
t o cont r ol t he r out ing of t he dat agr am inst ead of l eaving it t o t he r out er s al ong t he
pat h. The r out ing ext ension can be used t o give r out es t o t he dest inat ion. The r out ing
ext ension incl udes f iel ds f or each IP addr ess al ong t he desir ed r out e.
Fragment Headers
The f r agment header can be appended t o an IP dat agr am t o enabl e a machine t o
f r agment a l ar ge dat agr am int o smal l er par t s. Par t of t he design of IPng was t o pr event
subsequent f r agment at ion, but in some cases f r agment at ion must be enabl ed in or der t o
pass t he dat agr am al ong t he net wor k.
Authentication Headers
The aut hent icat ion header is used t o ensur e t hat no al t er at ion was made t o t he
cont ent s of t he dat agr am and t hat t he dat agr am or iginat ed at t he machine shown in
t he IP header . By def aul t , IPng uses an aut hent icat ion scheme cal l ed Message Digest 5
(MD5). Ot her aut hent icat ion schemes can be used as l ong as bot h ends of t he connect ion
agr ee on t he same scheme.
The aut hent icat ion header consist s of a secur it y par amet er s index (SPI) t hat , when
combined wit h t he dest inat ion IP addr ess, def ines t he aut hent icat ion scheme. The SPI is
f ol l owed by aut hent icat ion dat a, which wit h MD5 is 16 byt es l ong. MD5 st ar t s wit h a
key (padded t o 128 bit s if it is shor t er ), t hen appends t he ent ir e dat agr am. The key is t hen
t agged at t he end, and t he MD5 al gor it hm is r un on t he whol e. To pr event pr obl ems
wit h hop count er s and t he aut hent icat ion header it sel f al t er ing t he val ues, t hey ar e
zer oed f or t he pur poses of cal cul at ing t he aut hent icat ion val ue. The MD5 al gor it hm
gener at es a 128-bit val ue t hat is pl aced in t he aut hent icat ion header . The st eps ar e
r epeat ed in r ever se at t he r eceiving end. Bot h ends must have t he same key val ue, of
cour se, f or t he scheme t o wor k.
The dat agr am cont ent s can be encr ypt ed pr ior t o gener at ing aut hent icat ion val ues
using t he def aul t IPng encr ypt ion scheme, cal l ed Cipher Bl ock Chaining (CBC), par t of
t he Dat a Encr ypt ion St andar d (DES).
Internet Protocol Support in Different Environments
The Univer sit y of Cal if or nia at Ber kel ey was given a gr ant in t he ear l y 1980s t o modif y
t heir UNIX oper at ing syst em t o incl uded suppor t f or IP. The BSD4.2 UNIX r el ease
al r eady of f er ed suppor t f or TCP and IP, as wel l as t he Simpl e Mail Tr ansf er Pr ot ocol
(SMTP) and Addr ess Resol ut ion Pr ot ocol (ARP), but wit h DARPA's f unds, BSD4.3 was
devel oped t o pr ovide mor e compl et e suppor t .
The BSD4.2 suppor t f or IP was quit e good pr ior t o t his gr ant , but it was l imit ed t o use in
smal l l ocal ar ea net wor ks onl y. To incr ease t he capabil it ies of BSD UNIX's IP suppor t ,
BSD added r et r ansmission capabil it ies, Time t o Live inf or mat ion, and r edir ect ion
messages. Ot her f eat ur es wer e added, t oo, enabl ing BSD4.3 t o wor k wit h l ar ger
net wor ks, int er net wor ks (connect ions bet ween dif f er ent net wor ks), and wide ar ea
net wor ks connect ed by l eased l ines. This pr ocess br ought t he BSD UNIX syst em (and it s
l icensees, such as Sun's SunOS) in l ine wit h t he IP st andar ds used on AT&T UNIX and
ot her UNIX-based pl at f or ms.
Wit h t he st r ong suppor t f or IP among t he UNIX communit y, it was inevit abl e t hat
manuf act ur er s of ot her sof t war e oper at ing syst ems woul d st ar t t o pr oduce sof t war e
t hat al l owed t heir machines t o int er connect t o t he UNIX IP syst em. Most of t he dr ive
t o pr oduce IP ver sions f or non-UNIX oper at ing syst ems was not because of t he Int er net
(which hadn't st ar t ed it s phenomenal gr owt h at t he t ime) but t he desir e t o int egr at e
t he ot her oper at ing syst ems int o l ocal ar ea net wor ks t hat used UNIX ser ver s.
This sect ion of t oday's mat er ial examines sever al har dwar e and sof t war e syst ems,
f ocusing on t he most widel y used pl at f or ms, and shows t he avail abil it y of IP (and ent ir e
TCP/IP suit es) f or t hose machines. Much of t his is of int er est onl y if you have t he
par t icul ar pl at f or m discussed (DEC VAX user s t end not t o car e about int er connect ivit y
t o IBM SNA pl at f or ms, f or exampl e), so you can be sel ect ive about t he sect ions you r ead.
In some cases, I use one IP package f r om some of t hese pl at f or ms as an exampl e and f or
scr een capt ur es l at er in t his book.
MS-DOS
PCs came ont o t he scene when TCP/IP was al r eady in common use, so it was not sur pr ising
t o f ind int er connect ion sof t war e r apidl y int r oduced. In many ways, t he PC was a per f ect
pl at f or m as a st and-al one machine wit h access t hr ough a communicat ions package t o
ot her l ar ger syst ems. The PC was per f ect f or a cl ient /ser ver envir onment .
Ther e ar e many PC-based ver sions of TCP/IP. The most widel y used packages come f r om
FTP Sof t war e, The Wol l ongong Gr oup, and Beame and Whit eside Sof t war e Inc. Al l t he
packages f eat ur e int er connect ion capabil it ies t o ot her machines using TCP/IP, and most
add ot her usef ul f eat ur es such as FTP and mail r out ing.
FTP Sof t war e's PC/TCP is one of t he most widel y used. PC/TCP suppor t s t he major
net wor k int er f aces: Packet Dr iver , IBM's Adapt er Suppor t Int er f ace (ASI), Novel l 's Open
Dat a Link Int er f ace (ODI), and Micr osof t /3Com's Net wor k Dr iver Int er f ace Specif icat ion
(NDIS). Al l f our LAN int er f aces ar e discussed in mor e det ail in t he sect ion t it l ed "Local
Ar ea Net wor ks" l at er t oday.
The design of PC/TCP cover s al l seven l ayer s of t he OSI model , devel oped in such a
manner t hat component s can be conf igur ed as r equir ed t o suppor t dif f er ent t r anspor t
mechanisms and appl icat ions. Typical l y, t he Packet Dr iver , ASI, ODI, or NDIS modul e has
a gener ic PC/TCP ker nel on t op of it , wit h t he PC/TCP appl icat ion on t op of t hat .
PC/TCP enabl es t he sof t war e t o r un bot h TCP/IP and anot her pr ot ocol , such as DECnet ,
Novel l Net War e, or LAN Manager , simul t aneousl y. This can be usef ul f or enabl ing a PC
t o wor k wit hin a smal l LAN wor kgr oup, as wel l as wit hin a l ar ger net wor k, wit hout
swit ching sof t war e.
Microsoft Windows
Ther e ar e sever al TCP/IP pr oduct s appear ing f or Micr osof t 's Windows 3.x, Windows f or
Wor kgr oups, and Windows 95. Most of t he ear l y packages f or Windows 3.x wer e por t s of
DOS pr oduct s. Al t hough t hese t end t o wor k wel l , a t ot al l y Windows-designed pr oduct
t ends t o have a sl ight edge in t er ms of int egr at ion wit h t he Windows envir onment .
Windows f or Wor kgr oups 3.11 has no inher ent TCP/IP dr ives, but sever al pr oduct s ar e
avail abl e t o add TCP/IP suit es f or t his GUI, as wel l as Windows 3.1 and Windows 3.11.
One Windows 3.x-designed pr oduct is Net Manage's Chamel eon TCP/IP f or Windows.
Chamel eon of f er s a compl et e por t of TCP/IP and addit ional sof t war e ut il it ies t o enabl e
a PC r unning Windows 3.x t o int egr at e int o a TCP/IP net wor k. Chamel eon of f er s
t er minal emul at ion, Tel net , FTP, el ect r onic mail , DNS dir ect or y ser vices, and NFS
capabil it ies. Ther e ar e sever al ver sions of Chamel eon, depending on whet her NFS is
r equir ed.
Windows 95 has TCP/IP dr iver s incl uded wit h t he dist r ibut ion sof t war e, but t hey ar e not
l oaded by def aul t (Net War e's IPX/SPX is t he def aul t pr ot ocol f or Windows 95). You
must inst al l and conf igur e t he TCP/IP pr oduct as a separ at e st ep af t er inst al l ing
Windows 95 if you want t o use IP on your net wor k. You can see how t his is done on Day
10, "Set t ing Up a Sampl e TCP/IP Net wor k: DOS and Windows Cl ient s."
Windows NT
Windows NT is ideal l y suit ed f or TCP/IP because it is designed t o act as a ser ver and
gat eway. Al t hough Windows NT is not inher ent l y mul t iuser , it does wor k wel l as a
TCP/IP access device. Windows NT incl udes suppor t f or t he TCP/IP pr ot ocol s as a net wor k
t r anspor t , al t hough t he impl ement at ion does not incl ude al l t he ut il it ies usual l y
associat ed wit h TCP/IP. TCP/IP can be chosen as t he def aul t pr ot ocol on a Windows NT
machine when t he oper at ing syst em is inst al l ed.
Among t he add-on pr oduct s avail abl e f or Windows NT, Net Manage's Chamel eon32 is a
popul ar package. Simil ar t o t he Micr osof t Windows ver sion, Chamel eon32 of f er s ver sions
f or NFS.
OS/2
IBM's OS/2 pl at f or m has a st r ong pr esence in cor por at ions because of t he IBM r eput at ion
and OS/2's sol id per f or mance. Not sur pr isingl y, TCP/IP pr oduct s ar e popul ar in t hese
inst al l at ions, as wel l . Al t hough OS/2 dif f er s f r om DOS in many ways, it is possibl e t o
r un DOS-based por t s of TCP/IP sof t war e under OS/2. A bet t er sol ut ion is t o r un a nat ive
OS/2 appl icat ion. Sever al TCP/IP OS/2-nat ive impl ement at ions ar e avail abl e, incl uding a
TCP/IP pr oduct f r om IBM it sel f .
Macintosh
Except f or ver sions of UNIX t hat r un on t he Macint osh, t he Macint osh and UNIX wor l ds
have depended on sever al dif f er ent ver sions of TCP/IP t o keep t hem connect ed. Wit h
many cor por at ions now want ing t heir invest ment in Macint osh comput er s t o ser ve
doubl e dut y as X t er minal s ont o UNIX wor kst at ion, TCP/IP f or t he Mac has become even
mor e impor t ant .
Macint osh TCP pr oduct s ar e avail abl e in sever al f or ms, usual l y as an add-on
appl icat ion or device dr iver f or t he Macint osh oper at ing syst em. An al t er nat ive is
Tenon Int er syst ems' MachTen pr oduct l ine, which enabl es a UNIX ker nel and t he
Macint osh oper at ing syst em t o coexist on t he same machine, pr oviding compat ibil it y
bet ween UNIX and t he Macint osh f il e syst em and Appl e event s. TCP/IP is par t of t he
MachTen pr oduct .
The Appl eTal k net wor king syst em enabl es Macs and UNIX machines t o int er connect t o a
l imit ed ext ent , al t hough t his r equir es inst al l at ion of Appl eTal k sof t war e on t he UNIX
host somet hing many syst em administ r at or s ar e r el uct ant t o do. Al so, because
Appl eTal k is not as f ast and ver sat il e as Et her net and ot her net wor k t r anspor t s, t his
sol ut ion is sel dom f avor ed.
A bet t er sol ut ion is simpl y t o inst al l TCP/IP on t he Macint osh using one of sever al
commer cial packages avail abl e. Appl e's own MacTCP sof t war e pr oduct can per f or m t he
basic ser vices but must be coupl ed wit h sof t war e f r om ot her vendor s f or t he higher
l ayer appl icat ions. MacTCP al so r equir es a Dat agr am Del iver y Pr ot ocol t o Int er net
Pr ot ocol (DDP-t o-IP) r out er t o handl e t he sending and r eceiving of DDP and IP
dat agr ams.
Appl e's MacTCP f unct ions by pr oviding t he physical t hr ough t r anspor t l ayer s of t he
ar chit ect ur e. MacTCP al l ows f or bot h Local Tal k and Et her net har dwar e and suppor t s
bot h IP and TCP, as wel l as sever al ot her pr ot ocol s. Running on t op of MacTCP is t he
t hir d-par t y appl icat ion, which uses MacTCP's f unct ion cal l s t o pr ovide t he f inal
appl icat ion f or t he user . Funct ions such as Tel net and FTP pr ot ocol s ar e suppor t ed wit h
add-on sof t war e, t oo.
DEC
Digit al Equipment Cor por at ion's minicomput er s wer e f or many year s a mainst ay in
scient if ic and educat ional r esear ch, so an obvious devel opment f or DEC and t hir d-par t y
sof t war e companies was t o int r oduce IP sof t war e. Most DEC machines r un eit her VMS or
Ul t r ix (DEC's l icensed ver sion of UNIX). Pr oviding IP capabil it ies t o Ul t r ix was a mat t er
of dupl icat ing t he code devel oped at Ber kel ey, but VMS was not designed f or IP-t ype
communicat ions, r el ying inst ead on DEC's pr opr iet ar y net wor k sof t war e.
DEC's net wor king sof t war e is t he Digit al Net wor k Ar chit ect ur e (DECnet ). The f ir st
widel y used ver sion was DECnet Phase IV (int r oduced in 1982), which used indust r y-
st andar d pr ot ocol s f or t he l ower l ayer s but was pr opr iet ar y in t he upper l ayer s. The
1987 r el ease of DECnet Phase V pr ovided a combined DECnet IV and OSI syst em t hat
al l owed new OSI pr ot ocol s t o be used wit hin t he DECnet envir onment .
DEC announced t he ADVANTAGE-NETWORKS in 1991 as an enhancement of DECnet
Phase V, adding suppor t f or t he Int er net Pr ot ocol s. Wit h t he ADVANTAGE-NETWORKS,
user s coul d choose bet ween t he ol der , DEC-specif ic DECnet , OSI, or IP schemes.
ADVANTAGE-NETWORKS is DEC's at t empt t o pr ovide int er oper abil it y, pr oviding t he
DEC-excl usive DECnet syst em f or LAN use, and t he TCP/IP and OSI syst ems f or WANs and
syst em int er connect ion bet ween dif f er ent har dwar e t ypes.
User s of VMS syst ems can connect t o t he UNIX envir onment in sever al ways. The easiest
is t o use a sof t war e gat eway bet ween t he VMS machine and a UNIX machine. DEC's
TCP/IP Ser vices f or VMS per f or ms t his f unct ion, as do sever al t hir d-par t y sof t war e
sol ut ions, such as t he Ker mit pr ot ocol f r om Col umbia Univer sit y, Wol l ongong Gr oup's
WIN/TCP, and TGV's Mul t iNet . The advant age of t he t hir d-par t y communicat ions
pr ot ocol pr oduct s such as Ker mit is t hat t hey don't have t o be connect ed t o a UNIX
machine, because any oper at ing syst em t hat suppor t s t he communicat ions pr ot ocol wil l
wor k.
ADVANTAGE-NETWORKS user s have mor e opt ions avail abl e, many f r om DEC. Because
t he pr ot ocol is al r eady embedded in t he net wor k sof t war e, it makes t he most sense
simpl y t o use it as it comes, if it f it s int o t he exist ing syst em ar chit ect ur e. Because of
int er nal conver sion sof t war e, ADVANTAGE-NETWORKS can connect f r om a DECnet
machine using eit her t he DECnet or t he OSI pr ot ocol s.
IBM's SNA
IBM's Syst ems Net wor k Ar chit ect ur e (SNA) is in widespr ead use f or bot h mainf r ames and
minicomput er s. Essent ial l y al l IBM equipment pr ovides f ul l suppor t f or IP and TCP, as
wel l as many ot her popul ar pr ot ocol s. Nat ive IBM sof t war e is avail abl e f or each
machine, and sever al t hir d-par t y pr oduct s have appear ed (usual l y at a l ower cost t han
t hose of f er ed by IBM).
The IBM UNIX ver sion, AIX (which f ew peopl e know st ands f or Advanced Int er act ive
Execut ive), has t he TCP/IP sof t war e buil t in, enabl ing any machine t hat can r un AIX
(f r om wor kst at ions t o l ar ge minicomput er s) t o int er connect t hr ough IP wit h no
addit ional sof t war e. The dif f er ent ver sions of AIX have sl ight l y dif f er ent suppor t , so
user s shoul d check bef or e bl indl y t r ying t o connect AIX machines.
For l ar ge syst ems such as mainf r ames, IBM has t he 3172 Int er connect Cont r ol l er , which
sit s bet ween t he mainf r ame and a net wor k. The 3172 is a hef t y box t hat handl es high-
speed t r af f ic bet ween a mainf r ame channel and t he net wor k, of f -l oading t he pr ocessing
f or t he communicat ions aspect f r om t he mainf r ame pr ocessor . It can connect t o Et her net
or t oken r ing net wor ks and t hr ough addit ional sof t war e t o DEC's DECnet .
IBM mainf r ames r unning eit her MVS or VM can r un sof t war e appr opr iat el y cal l ed
TCP/IP f or MVS and TCP/IP f or VM. These pr oduct s pr ovide access f r om ot her machines
r unning TCP/IP t o access t he mainf r ame oper at ing syst em r emot el y, usual l y over a LAN.
The sof t war e enabl es t he cal l ing machine (t he cl ient in a cl ient /ser ver scheme) t o act
as a 3270-ser ies t er minal t o MVS or VM. FTP is pr ovided f or f il e t r ansf er s wit h
aut omat ic conver sion f r om EBCDIC t o ASCII. An int er f ace t o PROFS is avail abl e. Bot h
TCP/IP sof t war e pr oduct s suppor t SMTP f or el ect r onic mail .
Local Area Networks
LANs ar e an obvious t ar get f or TCP/IP, because TCP/IP hel ps sol ve many int er connect ion
pr obl ems bet ween dif f er ent har dwar e and sof t war e pl at f or ms. To r un TCP/IP over a
net wor k, t he exist ing net wor k and t r anspor t l ayer sof t war e must be r epl aced wit h
TCP/IP, or t he t wo must be mer ged t oget her in some manner so t hat t he LAN pr ot ocol
can car r y TCP/IP inf or mat ion wit hin it s exist ing pr ot ocol (encapsul at ion).
Whichever sol ut ion is t aken f or t he l ower l ayer , a higher l ayer int er f ace al so must be
devel oped, which r esides in t he equival ent of t he dat a l ink l ayer , communicat ing
bet ween t he higher l ayer appl icat ions and t he har dwar e. This int er f ace enabl es t he
higher l ayer s t o be independent of t he har dwar e when using TCP/IP, which many popul ar
LAN oper at ing syst ems ar e not cur r ent l y abl e t o cl aim.
Thr ee int er f aces (which have been ment ioned ear l ier t oday) ar e cur r ent l y in common
use. The Packet Dr iver int er f ace was t he f ir st int er f ace devel oped t o meet t hese needs.
3Com Cor por at ion and Micr osof t devel oped t he Net wor k Dr iver Int er f ace Specif icat ion
(NDIS) f or OS/2 and 3Com's net wor king sof t war e. NDIS pr ovides a dr iver t o communicat e
wit h t he net wor king har dwar e and a pr ot ocol dr iver t hat act s as t he int er f ace t o t he
higher l ayer s. Novel l 's Open Dat a Link Int er f ace (ODI) is simil ar t o NDIS.
For singl e-vendor , PC-based net wor ks, sever al dedicat ed TCP/IP packages ar e avail abl e,
such as Novel l 's LAN Wor kPl ace, designed t o enabl e any Net War e syst em t o connect t o
a LAN using an int er f ace har dwar e car d and a sof t war e dr iver .
Summary
Today I st ar t ed an in-dept h l ook at t he TCP/IP pr ot ocol f amil y wit h t he Int er net
Pr ot ocol . I cover ed what IP is and how it does it s t ask of passing dat agr ams bet ween
machines. The const r uct ion of t he IP dat agr am and t he f or mat of t he IP header ar e
shown in det ail . The const r uct ion of t he IP header is impor t ant t o many TCP/IP f amil y
pr ot ocol member s, so you can use t his knowl edge in l at er chapt er s. I al so l ooked at t he
Int er net Cont r ol Message Pr ot ocol (ICMP), an impor t ant aspect of t he TCP/IP syst em.
The next chapt er moves t o t he next -higher l ayer in t he TCP/IP l ayer ed ar chit ect ur e and
l ooks at t he Tr ansmission Cont r ol Pr ot ocol (TCP). I al so l ook at t he r el at ed User
Dat agr am Pr ot ocol (UDP). TCP and UDP f or m t he basis f or al l TCP/IP pr ot ocol s.
Q&A
Why does t he IP header have a Time t o Live f iel d?
The easiest way t o answer t his is t o consider what woul d happen wit hout t he f iel d. A
dat agr am wit h f aul t y inf or mat ion in t he IP header coul d cir cul at e ar ound a net wor k
f or ever , f or war ding f r om one gat eway t o anot her in sear ch of a dest inat ion. Wit h a
Time t o Live f iel d, t he number of bounces t he dat agr am makes is l imit ed. This has been
pr oven t o have an impor t ant ef f ect on net wor k t r af f ic.
Give a one-sent ence descr ipt ion of ICMP.
ICMP is an er r or -r epor t ing syst em t hat communicat es bet ween dif f er ent IP-based devices,
pr oviding inf or mat ion about st at us changes and f ail ed devices.
What is a neighbor in t he IP sense?
Neighbor s ar e connect ed t hr ough a gat eway. Ther e is no physical r est r ict ion on t he
dist ance bet ween neighbor s. However , al l neighbor s shar e gat eways.
How is an ICMP message dat agr am const r uct ed?
The ICMP message, which can incl ude par t of t he dat agr am t hat causes an ICMP message
t o be gener at ed, has an ICMP header at t ached t o t he f r ont of it . This is t hen passed t o
IP, which encapsul at es it wit hin an IP header . Final l y, a net wor k header is added when
t he dat agr am is sent over t he net wor k.
Quiz
1. Expl ain why IP is impor t ant t o t he pr oper t r ansmission of dat a.
2. Show t he const r uct ion of t he IP header and t he meaning of each el ement wit hin
t he header st r uct ur e.
3. ICMP header s ar e quit e smal l . Show t he st r uct ur e of a t ypical message header and
t he meaning of t he bit s wit hin it .


I What Is TCP?
I Fol l owing a Message
I Por t s and Socket s
I TCP Communicat ions wit h t he Upper Layer s
I Passive and Act ive Por t s
I TCP Timer s
I The Ret r ansmission Timer
I The Quiet Timer
I The Per sist ence Timer
I The Keep-Al ive Timer and t he Idl e Timer
I Tr ansmission Cont r ol Bl ocks and Fl ow Cont r ol
I TCP Pr ot ocol Dat a Unit s
I TCP and Connect ions
I Est abl ishing a Connect ion
I Dat a Tr ansf er
I Cl osing Connect ions
I User Dat agr am Pr ot ocol (UDP)
I Summar y
I Q&A
I Wor kshop
I Quiz
4
TCP and UDP
Yest er day's t ext examined t he Int er net Pr ot ocol (IP) in consider abl e det ail . As you
might r emember , t he Int er net Pr ot ocol handl es t he l ower -l ayer f unct ional it y. Today I
l ook at t he t r anspor t l ayer , wher e t he Tr ansmission Cont r ol Pr ot ocol (TCP) and User
Dat agr am Pr ot ocol (UDP) come int o pl ay.
TCP is one of t he most widel y used t r anspor t l ayer pr ot ocol s, expanding f r om it s
or iginal impl ement at ion on t he ARPANET t o connect ing commer cial sit es al l over t he
wor l d. On Day 1, "Open Syst ems, St andar ds, and Pr ot ocol s," you l ooked at t he OSI seven-
l ayer model , which bear s a st r iking r esembl ance t o TCP/IP's l ayer ed model , so it is not
sur pr ising t hat many of t he f eat ur es of t he OSI t r anspor t l ayer wer e based on TCP.
In t heor y, a t r anspor t l ayer pr ot ocol coul d be a ver y simpl e sof t war e r out ine, but TCP
cannot be cal l ed simpl e. Why use a t r anspor t l ayer t hat is as compl ex as TCP? The most
impor t ant r eason depends on IP's unr el iabil it y. As you saw yest er day, IP does not
guar ant ee del iver y of a dat agr am; it is a connect ionl ess syst em wit h no r el iabil it y. IP
simpl y handl es t he r out ing of dat agr ams, and if pr obl ems occur , IP discar ds t he packet
wit hout a second t hought (gener at ing an ICMP er r or message back t o t he sender in t he
pr ocess). The t ask of ascer t aining t he st at us of t he dat agr ams sent over a net wor k and
handl ing t he r esending of inf or mat ion if par t s have been discar ded f al l s t o TCP, which
can be t hought of as r iding shot gun over IP.
Most user s t hink of TCP and IP as a t ight l y knit pair , but TCP can be (and f r equent l y is)
used wit h ot her pr ot ocol s wit hout IP. For exampl e, TCP or par t s of it ar e used in t he Fil e
Tr ansf er Pr ot ocol (FTP) and t he Simpl e Mail Tr ansf er Pr ot ocol (SMTP), bot h of which
do not use IP.
What Is TCP?
The Tr ansmission Cont r ol Pr ot ocol pr ovides a consider abl e number of ser vices t o t he IP
l ayer and t he upper l ayer s. Most impor t ant l y, it pr ovides a connect ion-or ient ed
pr ot ocol t o t he upper l ayer s t hat enabl e an appl icat ion t o be sur e t hat a dat agr am sent
out over t he net wor k was r eceived in it s ent ir et y. In t his r ol e, TCP act s as a message-
val idat ion pr ot ocol pr oviding r el iabl e communicat ions. If a dat agr am is cor r upt ed or
l ost , TCP usual l y handl es t he r et r ansmission, r at her t han t he appl icat ions in t he
higher l ayer s.
TCP is not a piece of sof t war e. It is a communicat ions
pr ot ocol . When you inst al l a TCP st ack on your machine, you
ar e inst al l ing t he TCP l ayer , and usual l y a l ot mor e sof t war e
t o pr ovide t he r est of t he TCP/IP ser vices. TCP is used as a cat ch-
al l phr ase f or TCP/IP in many cases.
TCP manages t he f l ow of dat agr ams f r om t he higher l ayer s t o t he IP l ayer , as wel l as
incoming dat agr ams f r om t he IP l ayer up t o t he higher l evel pr ot ocol s. TCP has t o
ensur e t hat pr ior it ies and secur it y ar e pr oper l y r espect ed. TCP must be capabl e of
handl ing t he t er minat ion of an appl icat ion above it t hat was expect ing incoming
dat agr ams, as wel l as f ail ur es in t he l ower l ayer s. TCP al so must maint ain a st at e t abl e
of al l dat a st r eams in and out of t he TCP l ayer . The isol at ion of al l t hese ser vices in a
separ at e l ayer enabl es appl icat ions t o be designed wit hout r egar d t o f l ow cont r ol or
message r el iabil it y. Wit hout t he TCP l ayer , each appl icat ion woul d have t o impl ement
t he ser vices t hemsel ves, which is a wast e of r esour ces.
TCP r esides in t he t r anspor t l ayer , posit ioned above IP but bel ow t he upper l ayer s and
t heir appl icat ions, as shown in Figur e 4.1. TCP r esides onl y on devices t hat act ual l y
pr ocess dat agr ams, ensur ing t hat t he dat agr am has gone f r om t he sour ce t o t he t ar get
machine. It does not r eside on a device t hat simpl y r out es dat agr ams, so t her e is usual l y
no TCP l ayer in a gat eway. This makes sense, because on a gat eway t he dat agr am has no
need t o go higher in t he l ayer ed model t han t he IP l ayer .
Figur e 4.1. TCP pr ovides end-t o-end communicat ions.
Because TCP is a connect ion-or ient ed pr ot ocol r esponsibl e f or ensur ing t he t r ansf er of
a dat agr am f r om t he sour ce t o dest inat ion machine (end-t o-end communicat ions), TCP
must r eceive communicat ions messages f r om t he dest inat ion machine t o acknowl edge
r eceipt of t he dat agr am. The t er m virtual circuit is usual l y used t o r ef er t o t he
communicat ions bet ween t he t wo end machines, most of which ar e simpl e
acknowl edgment messages (eit her conf ir mat ion of r eceipt or a f ail ur e code) and
dat agr am sequence number s.
Following a Message
To il l ust r at e t he r ol e of TCP, it is inst r uct ive t o f ol l ow a sampl e message bet ween t wo
machines. The pr ocesses ar e simpl if ied at t his st age, t o be expanded on l at er t oday. The
message or iginat es f r om an appl icat ion in an upper l ayer and is passed t o TCP f r om t he
next higher l ayer in t he ar chit ect ur e t hr ough some pr ot ocol (of t en r ef er r ed t o as an
upper -l ayer pr ot ocol , or ULP, t o indicat e t hat it r esides above TCP). The message is
passed as a streama sequence of individual char act er s sent asynchr onousl y. This is in
cont r ast t o most pr ot ocol s, which use f ixed bl ocks of dat a. This can pose some conver sion
pr obl ems wit h appl icat ions t hat handl e onl y f or mal l y const r uct ed bl ocks of dat a or
insist on f ixed-size messages.
TCP r eceives t he st r eam of byt es and assembl es t hem int o TCP segments, or packet s. In t he
pr ocess of assembl ing t he segment , header inf or mat ion is at t ached at t he f r ont of t he
dat a. Each segment has a checksum cal cul at ed and embedded wit hin t he header , as wel l
as a sequence number if t her e is mor e t han one segment in t he ent ir e message. The l engt h
of t he segment is usual l y det er mined by TCP or by a syst em val ue set by t he syst em
administ r at or . (The l engt h of TCP segment s has not hing t o do wit h t he IP dat agr am
l engt h, al t hough t her e is somet imes a r el at ionship bet ween t he t wo.)
If t wo-way communicat ions ar e r equir ed (such as wit h Tel net or FTP), a connect ion
(vir t ual cir cuit ) bet ween t he sending and r eceiving machines is est abl ished pr ior t o
passing t he segment t o IP f or r out ing. This pr ocess st ar t s wit h t he sending TCP sof t war e
issuing a r equest f or a TCP connect ion wit h t he r eceiving machine. In t he message is a
unique number (cal l ed a socket number ) t hat ident if ies t he sending machine's
connect ion. The r eceiving TCP sof t war e assigns it s own unique socket number and sends
it back t o t he or iginal machine. The t wo unique number s t hen def ine t he connect ion
bet ween t he t wo machines unt il t he vir t ual cir cuit is t er minat ed. (I l ook at socket s in a
l it t l e mor e det ail in a moment .)
Af t er t he vir t ual cir cuit is est abl ished, TCP sends t he segment t o t he IP sof t war e, which
t hen issues t he message over t he net wor k as a dat agr am. IP can per f or m any of t he
changes t o t he segment t hat you saw in yest er day's mat er ial , such as f r agment ing it and
r eassembl ing it at t he dest inat ion machine. These st eps ar e compl et el y t r anspar ent t o
t he TCP l ayer s, however . Af t er winding it s way over t he net wor k, t he r eceiving
machine's IP passes t he r eceived segment up t o t he r ecipient machine's TCP l ayer , wher e it
is pr ocessed and passed up t o t he appl icat ions above it using an upper -l ayer pr ot ocol .
If t he message was mor e t han one TCP segment l ong (not IP dat agr ams), t he r eceiving
TCP sof t war e r eassembl es t he message using t he sequence number s cont ained in each
segment 's header . If a segment is missing or cor r upt (which can be det er mined f r om t he
checksum), TCP r et ur ns a message wit h t he f aul t y sequence number in t he body. The
or iginat ing TCP sof t war e can t hen r esend t he bad segment .
If onl y one segment is used f or t he ent ir e message, af t er compar ing t he segment 's
checksum wit h a newl y cal cul at ed val ue, t he r eceiving TCP sof t war e can gener at e
eit her a posit ive acknowl edgment (ACK) or a r equest t o r esend t he segment and r out e
t he r equest back t o t he sending l ayer .
The r eceiving machine's TCP impl ement at ion can per f or m a simpl e f l ow cont r ol t o
pr event buf f er over l oad. It does t his by sending a buf f er size cal l ed a window val ue t o
t he sending machine, f ol l owing which t he sender can send onl y enough byt es t o f il l t he
window. Af t er t hat , t he sender must wait f or anot her window val ue t o be r eceived. This
pr ovides a handshaking pr ot ocol bet ween t he t wo machines, al t hough it sl ows down t he
t r ansmission t ime and sl ight l y incr eases net wor k t r af f ic.
The use of a sl iding window is mor e ef f icient t han a singl e
bl ock send and acknowl edgment scheme because of del ays
wait ing f or t he acknowl edgment . By impl ement ing a sl iding
window, sever al bl ocks can be sent at once. A pr oper l y
conf igur ed sl iding window pr ot ocol pr ovides a much higher
t hr oughput .
As wit h most connect ion-based pr ot ocol s, t imer s ar e an impor t ant aspect of TCP. The use
of a t imer ensur es t hat an undue wait is not invol ved whil e wait ing f or an ACK or an
er r or message. If t he t imer s expir e, an incompl et e t r ansmission is assumed. Usual l y an
expir ing t imer bef or e t he sending of an acknowl edgment message causes a r et r ansmission
of t he dat agr am f r om t he or iginat ing machine.
Timer s can cause some pr obl ems wit h TCP. The specif icat ions f or TCP pr ovide f or t he
acknowl edgment of onl y t he highest dat agr am number t hat has been r eceived wit hout
er r or , but t his cannot pr oper l y handl e f r agment ar y r ecept ion. If a message is composed
of sever al dat agr ams t hat ar r ive out of or der , t he specif icat ion st at es t hat TCP cannot
acknowl edge t he r ecept ion of t he message unt il al l t he dat agr ams have been r eceived.
So even if al l but one dat agr am in t he middl e of t he sequence have been successf ul l y
r eceived, a t imer might expir e and cause al l t he dat agr ams t o be r esent . Wit h l ar ge
messages, t his can cause an incr ease in net wor k t r af f ic.
If t he r eceiving TCP sof t war e r eceives dupl icat e dat agr ams (as can occur wit h a
r et r ansmission af t er a t imeout or due t o a dupl icat e t r ansmission f r om IP), t he r eceiving
ver sion of TCP discar ds any dupl icat e dat agr ams, wit hout bot her ing wit h an er r or
message. Af t er al l , t he sending syst em car es onl y t hat t he message was r eceivednot
how many copies wer e r eceived.
TCP does not have a negat ive acknowl edgment (NAK) f unct ion; it r el ies on a t imer t o
indicat e l ack of acknowl edgment . If t he t imer has expir ed af t er sending t he dat agr am
wit hout r eceiving an acknowl edgment of r eceipt , t he dat agr am is assumed t o have been
l ost and is r et r ansmit t ed. The sending TCP sof t war e keeps copies of al l unacknowl edged
dat agr ams in a buf f er unt il t hey have been pr oper l y acknowl edged. When t his happens,
t he r et r ansmission t imer is st opped, and t he dat agr am is r emoved f r om t he buf f er .
TCP suppor t s a push f unct ion f r om t he upper -l ayer pr ot ocol s. A push is used when an
appl icat ion want s t o send dat a immediat el y and conf ir m t hat a message passed t o TCP
has been successf ul l y t r ansmit t ed. To do t his, a push f l ag is set in t he ULP connect ion,
inst r uct ing TCP t o f or war d any buf f er ed inf or mat ion f r om t he appl icat ion t o t he
dest inat ion as soon as possibl e (as opposed t o hol ding it in t he buf f er unt il it is r eady t o
t r ansmit it ).
Ports and Sockets
Al l upper -l ayer appl icat ions t hat use TCP (or UDP) have a por t number t hat ident if ies
t he appl icat ion. In t heor y, por t number s can be assigned on individual machines, or
however t he administ r at or desir es, but some convent ions have been adopt ed t o enabl e
bet t er communicat ions bet ween TCP impl ement at ions. This enabl es t he por t number t o
ident if y t he t ype of ser vice t hat one TCP syst em is r equest ing f r om anot her . Por t
number s can be changed, al t hough t his can cause dif f icul t ies. Most syst ems maint ain a
f il e of por t number s and t heir cor r esponding ser vice.
Typical l y, por t number s above 255 ar e r eser ved f or pr ivat e use of t he l ocal machine, but
number s bel ow 255 ar e used f or f r equent l y used pr ocesses. A l ist of f r equent l y used por t
number s is publ ished by t he Int er net Assigned Number s Aut hor it y and is avail abl e
t hr ough an RFC or f r om many sit es t hat of f er Int er net summar y f il es f or downl oading.
The commonl y used por t number s on t his l ist ar e shown in Tabl e 4.1. The number s 0 and
255 ar e r eser ved.
Tabl e 4.1. Fr equent l y used TCP por t number s.
Port Number Process Name Description
1 TCPMUX TCP Por t Ser vice Mul t ipl exer
5 RJE Remot e Job Ent r y
7 ECHO Echo
9 DISCARD Discar d
11 USERS Act ive User s
13 DAYTIME Dayt ime
17 Quot e Quot at ion of t he Day
19 CHARGEN Char act er gener at or
20 FTP-DATA Fil e Tr ansf er Pr ot ocol Dat a
21 FTP Fil e Tr ansf er Pr ot ocol Cont r ol
23 TELNET Tel net
25 SMTP Simpl e Mail Tr ansf er Pr ot ocol
27 NSW-FE NSW User Syst em Fr ont End
29 MSG-ICP MSG-ICP
31 MSG-AUTH MSG Aut hent icat ion
33 DSP Displ ay Suppor t Pr ot ocol
35 Pr ivat e Pr int Ser ver s
37 TIME Time
39 RLP Resour ce Locat ion Pr ot ocol
41 GRAPHICS Gr aphics
42 NAMESERV Host Name Ser ver
43 NICNAME Who Is
49 LOGIN Login Host Pr ot ocol
53 DOMAIN Domain Name Ser ver
67 BOOTPS Boot st r ap Pr ot ocol Ser ver
68 BOOTPC Boot st r ap Pr ot ocol Cl ient
69 TFTP Tr ivial Fil e Tr ansf er Pr ot ocol
79 FINGER Finger
101 HOSTNAME NIC Host Name Ser ver
102 ISO-TSAP ISO TSAP
103 X400 X.400
104 X400SND X.400 SND
105 CSNET-NS CSNET Mail box Name Ser ver
109 POP2 Post Of f ice Pr ot ocol v2
110 POP3 Post Of f ice Pr ot ocol v3
111 RPC Sun RPC Por t map
137 NETBIOS-NS NETBIOS Name Ser vice
138 NETBIOS-DG NETBIOS Dat agr am Ser vice
139 NETBIOS-SS NETBIOS Session Ser vice
146 ISO-TP0 ISO TP0
147 ISO-IP ISO IP
150 SQL-NET SQL NET
153 SGMP SGMP
156 SQLSRV SQL Ser vice
160 SGMP-TRAPS SGMP TRAPS
161 SNMP SNMP
162 SNMPTRAP SNMPTRAP
163 CMIP-MANAGE CMIP/TCP Manager
164 CMIP-AGENT CMIP/TCP Agent
165 XNS-Cour ier Xer ox
179 BGP Bor der Gat eway Pr ot ocol
Each communicat ion cir cuit int o and out of t he TCP l ayer is uniquel y ident if ied by a
combinat ion of t wo number s, which t oget her ar e cal l ed a socket . The socket is composed
of t he IP addr ess of t he machine and t he por t number used by t he TCP sof t war e. Bot h
t he sending and r eceiving machines have socket s. Because t he IP addr ess is unique acr oss
t he int er net wor k, and t he por t number s ar e unique t o t he individual machine, t he
socket number s ar e al so unique acr oss t he ent ir e int er net wor k. This enabl es a pr ocess t o
t al k t o anot her pr ocess acr oss t he net wor k, based ent ir el y on t he socket number .
TCP uses t he connect ion (not t he pr ot ocol por t ) as a
f undament al el ement . A compl et ed connect ion has t wo end
point s. This enabl es a pr ot ocol por t t o be used f or sever al
connect ions at t he same t ime (mul t ipl exing).
The l ast sect ion examined t he pr ocess of est abl ishing a message. Dur ing t he pr ocess, t he
sending TCP r equest s a connect ion wit h t he r eceiving TCP, using t he unique socket
number s. This pr ocess is shown in Figur e 4.2. If t he sending TCP want s t o est abl ish a
Tel net session f r om it s por t number 350, t he socket number woul d be composed of t he
sour ce machine's IP addr ess and t he por t number (350), and t he message woul d have a
dest inat ion por t number of 23 (Tel net 's por t number ). The r eceiving TCP has a sour ce
por t of 23 (Tel net ) and a dest inat ion por t of 350 (t he sending machine's por t ).
Figur e 4.2. Set t ing up a vir t ual cir cuit wit h socket number s.
The sending and r eceiving machines maint ain a por t t abl e, which l ist s al l act ive por t
number s. The t wo machines invol ved have r ever sed ent r ies f or each session bet ween t he
t wo. This is cal l ed binding and is shown in Figur e 4.3. The sour ce and dest inat ion
number s ar e simpl y r ever sed f or each connect ion in t he por t t abl e. Of cour se, t he IP
addr esses, and hence t he socket number s, ar e dif f er ent .
Figur e 4.3. Binding ent r ies in por t t abl es.
If t he sending machine is r equest ing mor e t han one connect ion, t he sour ce por t number s
ar e dif f er ent , even t hough t he dest inat ion por t number s might be t he same. For exampl e,
if t he sending machine wer e t r ying t o est abl ish t hr ee Tel net sessions simul t aneousl y,
t he sour ce machine por t number s might be 350, 351, and 352, and t he dest inat ion por t
number s woul d al l be 23.
It is possibl e f or mor e t han one machine t o shar e t he same dest inat ion socket a pr ocess
cal l ed mul t ipl exing. In Figur e 4.4, t hr ee machines ar e est abl ishing Tel net sessions wit h a
dest inat ion. They al l use dest inat ion por t 23, which is por t mul t ipl exing. Because t he
dat agr ams emer ging f r om t he por t have t he f ul l socket inf or mat ion (wit h unique IP
addr esses), t her e is no conf usion as t o which machine a dat agr am is dest ined f or .
Figur e 4.4. Mul t ipl exing one dest inat ion por t .
When mul t ipl e socket s ar e est abl ished, it is conceivabl e t hat mor e t han one machine
might send a connect ion r equest wit h t he same sour ce and dest inat ion por t s. However ,
t he IP addr esses f or t he t wo machines ar e dif f er ent , so t he socket s ar e st il l uniquel y
ident if ied despit e ident ical sour ce and dest inat ion por t number s.
TCP Communications with the Upper Layers
TCP must communicat e wit h appl icat ions in t he upper l ayer and a net wor k syst em in t he
l ayer bel ow. Sever al messages ar e def ined f or t he upper -l ayer pr ot ocol t o TCP
communicat ions, but t her e is no def ined met hod f or TCP t o t al k t o l ower l ayer s
(usual l y, but not necessar il y, IP). TCP expect s t he l ayer beneat h it t o def ine t he
communicat ion met hod. It is usual l y assumed t hat TCP and t he t r anspor t l ayer
communicat e asynchr onousl y.
The TCP t o upper -l ayer pr ot ocol (ULP) communicat ion met hod is wel l -def ined, consist ing
of a set of ser vice r equest pr imit ives. The pr imit ives invol ved in ULP t o TCP
communicat ions ar e shown in Tabl e 4.2.
Tabl e 4.2. ULP-TCP ser vice pr imit ives.
Command Parameters Expected
ULP to TCP Service Request Primitives
ABORT Local connect ion name
ACTIVE-OPEN Local por t , r emot e socket
Opt ional : ULP t imeout , t imeout act ion, pr ecedence,
secur it y, opt ions
ACTIVE-OPEN-WITH-DATA
Sour ce por t , dest inat ion socket , dat a, dat a l engt h,
push f l ag, ur gent f l ag
Opt ional : ULP t imeout , t imeout act ion, pr ecedence,
secur it y
ALLOCATE Local connect ion name, dat a l engt h
CLOSE Local connect ion name
FULL-PASSIVE-OPEN Local por t , dest inat ion socket
Opt ional : ULP t imeout , t imeout act ion, pr ecedence,
secur it y, opt ions
RECEIVE
Local connect ion name, buf f er addr ess, byt e count ,
push f l ag, ur gent f l ag
SEND
Local connect ion name, buf f er addr ess, dat a l engt h,
push f l ag, ur gent f l ag
Opt ional : ULP t imeout , t imeout act ion
STATUS Local connect ion name
UNSPECIFIED-PASSIVE-OPEN Local por t
Opt ional : ULP t imeout , t imeout act ion, pr ecedence,
secur it y, opt ions
TCP t o ULP Ser vice Request Pr imit ives
CLOSING Local connect ion name
DELIVER
Local connect ion name, buf f er addr ess, dat a l engt h,
ur gent f l ag
ERROR Local connect ion name, er r or descr ipt ion
OPEN-FAILURE Local connect ion name
OPEN-ID
Local connect ion name, r emot e socket , dest inat ion
addr ess
OPEN-SUCCESS Local connect ion name
STATUS RESPONSE
Local connect ion name, sour ce por t , sour ce addr ess,
r emot e socket , connect ion st at e, r eceive window, send
window, amount wait ing ACK, amount wait ing r eceipt ,
ur gent mode, pr ecedence, secur it y, t imeout , t imeout
act ion
TERMINATE Local connect ion name, descr ipt ion
Passive and Active Ports
TCP enabl es t wo met hods t o est abl ish a connect ion: act ive and passive. An act ive
connect ion est abl ishment happens when TCP issues a r equest f or t he connect ion, based
on an inst r uct ion f r om an upper -l evel pr ot ocol t hat pr ovides t he socket number . A
passive appr oach t akes pl ace when t he upper -l evel pr ot ocol inst r uct s TCP t o wait f or
t he ar r ival of connect ion r equest s f r om a r emot e syst em (usual l y f r om an act ive open
inst r uct ion). When TCP r eceives t he r equest , it assigns a por t number . This enabl es a
connect ion t o pr oceed r apidl y, wit hout wait ing f or t he act ive pr ocess.
Ther e ar e t wo passive open pr imit ives. A specif ied passive open cr eat es a connect ion when
t he pr ecedence l evel and secur it y l evel ar e accept abl e. An unspecif ied passive open
opens t he por t t o any r equest . The l at t er is used by ser ver s t hat ar e wait ing f or cl ient s
of an unknown t ype t o connect t o t hem.
TCP has st r ict r ul es about t he use of passive and act ive connect ion pr ocesses. Usual l y a
passive open is per f or med on one machine, whil e an act ive open is per f or med on t he ot her ,
wit h specif ic inf or mat ion about t he socket number , pr ecedence (pr ior it y), and secur it y
l evel s.
Al t hough most TCP connect ions ar e est abl ished by an act ive r equest t o a passive por t , it
is possibl e t o open a connect ion wit hout a passive por t wait ing. In t his case, t he TCP t hat
sends a r equest f or a connect ion incl udes bot h t he l ocal socket number and t he r emot e
socket number . If t he r eceiving TCP is conf igur ed t o enabl e t he r equest (based on t he
pr ecedence and secur it y set t ings, as wel l as appl icat ion-based cr it er ia), t he connect ion
can be opened. This pr ocess is l ooked at again in t he sect ion t it l ed "TCP and
Connect ions."
TCP Timers
TCP uses sever al t imer s t o ensur e t hat excessive del ays ar e not encount er ed dur ing
communicat ions. Sever al of t hese t imer s ar e el egant , handl ing pr obl ems t hat ar e not
immediat el y obvious at f ir st anal ysis. The t imer s used by TCP ar e examined in t he
f ol l owing sect ions, which r eveal t heir r ol es in ensur ing t hat dat a is pr oper l y sent f r om
one connect ion t o anot her .
The Retransmission Timer
The r et r ansmission t imer manages r et r ansmission t imeout s (RTOs), which occur when a
pr eset int er val bet ween t he sending of a dat agr am and t he r et ur ning acknowl edgment
is exceeded. The val ue of t he t imeout t ends t o var y, depending on t he net wor k t ype, t o
compensat e f or speed dif f er ences. If t he t imer expir es, t he dat agr am is r et r ansmit t ed
wit h an adjust ed RTO, which is usual l y incr eased exponent ial l y t o a maximum pr eset
l imit . If t he maximum l imit is exceeded, connect ion f ail ur e is assumed, and er r or messages
ar e passed back t o t he upper -l ayer appl icat ion.
Val ues f or t he t imeout ar e det er mined by measur ing t he aver age t ime t hat dat a t akes t o
be t r ansmit t ed t o anot her machine and t he acknowl edgment r eceived back, which is
cal l ed t he r ound-t r ip t ime, or RTT. Fr om exper iment s, t hese RTTs ar e aver aged by a
f or mul a t hat devel ops an expect ed val ue, cal l ed t he smoot hed r ound-t r ip t ime, or SRTT.
This val ue is t hen incr eased t o account f or unf or eseen del ays.
The Quiet Timer
Af t er a TCP connect ion is cl osed, it is possibl e f or dat agr ams t hat ar e st il l making t heir
way t hr ough t he net wor k t o at t empt t o access t he cl osed por t . The quiet t imer is
int ended t o pr event t he just -cl osed por t f r om r eopening again quickl y and r eceiving
t hese l ast dat agr ams.
The quiet t imer is usual l y set t o t wice t he maximum segment l if et ime (t he same val ue as
t he Time t o Live f iel d in an IP header ), ensur ing t hat al l segment s st il l heading f or t he
por t have been discar ded. Typical l y, t his can r esul t in a por t being unavail abl e f or up t o
30 seconds, pr ompt ing er r or messages when ot her appl icat ions at t empt t o access t he por t
dur ing t his int er val .
The Persistence Timer
The per sist ence t imer handl es a f air l y r ar e occur r ence. It is conceivabl e t hat a r eceive
window might have a val ue of 0, causing t he sending machine t o pause t r ansmission. The
message t o r est ar t sending might be l ost , causing an inf init e del ay. The per sist ence t imer
wait s a pr eset t ime and t hen sends a one-byt e segment at pr edet er mined int er val s t o
ensur e t hat t he r eceiving machine is st il l cl ogged.
The r eceiving machine r esends t he zer o window-size message af t er r eceiving one of t hese
st at us segment s, if it is st il l backl ogged. If t he window is open, a message giving t he new
val ue is r et ur ned, and communicat ions ar e r esumed.
The Keep-Alive Timer and the Idle Timer
Bot h t he keep-al ive t imer and t he idl e t imer wer e added t o t he TCP specif icat ions af t er
t heir or iginal def init ion. The keep-al ive t imer sends an empt y packet at r egul ar
int er val s t o ensur e t hat t he connect ion t o t he ot her machine is st il l act ive. If no
r esponse has been r eceived af t er sending t he message by t he t ime t he idl e t imer has
expir ed, t he connect ion is assumed t o be br oken.
The keep-al ive t imer val ue is usual l y set by an appl icat ion, wit h val ues r anging f r om 5
t o 45 seconds. The idl e t imer is usual l y set t o 360 seconds.
TCP uses adapt ive t imer al gor it hms t o accommodat e
del ays. The t imer s adjust t hemsel ves t o t he del ays exper ienced
over a connect ion, al t er ing t he t imer val ues t o r ef l ect
inher ent pr obl ems.
Transmission Control Blocks and Flow Control
TCP has t o keep t r ack of a l ot of inf or mat ion about each connect ion. It does t his
t hr ough a Tr ansmission Cont r ol Bl ock (TCB), which cont ains inf or mat ion about t he
l ocal and r emot e socket number s, t he send and r eceive buf f er s, secur it y and pr ior it y
val ues, and t he cur r ent segment in t he queue. The TCB al so manages send and r eceive
sequence number s.
The TCB uses sever al var iabl es t o keep t r ack of t he send and r eceive st at us and t o
cont r ol t he f l ow of inf or mat ion. These var iabl es ar e shown in Tabl e 4.3.
Tabl e 4.3. TCP send and r eceive var iabl es.
Variable Name Description
Send Variables
SND.UNA Send Unacknowl edged
SND.NXT Send Next
SND.WND Send Window
SND.UP Sequence number of l ast ur gent set
SND.WL1 Sequence number f or l ast window updat e
SND.WL2 Acknowl edgment number f or l ast window updat e
SND.PUSH Sequence number of l ast pushed set
ISS Init ial send sequence number
Receive Variables
RCV.NXT Sequence number of next r eceived set
RCV.WND Number of set s t hat can be r eceived
RCV.UP Sequence number of l ast ur gent dat a
RCV.IRS Init ial r eceive sequence number
Using t hese var iabl es, TCP cont r ol s t he f l ow of inf or mat ion bet ween t wo socket s. A
sampl e connect ion session hel ps il l ust r at e t he use of t he var iabl es. It begins wit h
Machine A want ing t o send f ive bl ocks of dat a t o Machine B. If t he window l imit is seven
bl ocks, a maximum of seven bl ocks can be sent wit hout acknowl edgment . The SND.UNA
var iabl e on Machine A indicat es how many bl ocks have been sent but ar e
unacknowl edged (5), and t he SND.NXT var iabl e has t he val ue of t he next bl ock in t he
sequence (6). The val ue of t he SND.WND var iabl e is 2 (seven bl ocks possibl e, minus f ive
sent ), so onl y t wo mor e bl ocks coul d be sent wit hout over l oading t he window. Machine
B r et ur ns a message wit h t he number of bl ocks r eceived, and t he window l imit is
adjust ed accor dingl y.
The passage of messages back and f or t h can become quit e compl ex as t he sending machine
f or war ds bl ocks unacknowl edged up t o t he window l imit , wait ing f or acknowl edgment
of ear l ier bl ocks t hat have been r emoved f r om t he incoming cue, and t hen sending mor e
bl ocks t o f il l t he window again. The t r acking of t he bl ocks becomes a mat t er of
bookkeeping, but wit h l ar ge window l imit s and t r af f ic acr oss int er net wor ks t hat
somet imes cause bl ocks t o go ast r ay, t he pr ocess is, in many ways, r emar kabl e.
TCP Protocol Data Units
As ment ioned ear l ier , TCP must communicat e wit h IP in t he l ayer bel ow (using an IP-
def ined met hod) and appl icat ions in t he upper l ayer (using t he TCP-ULP pr imit ives). TCP
al so must communicat e wit h ot her TCP impl ement at ions acr oss net wor ks. To do t his, it
uses Pr ot ocol Dat a Unit s (PDUs), which ar e cal l ed segment s in TCP par l ance.
The l ayout of t he TCP PDU (commonl y cal l ed t he header ) is shown in Figur e 4.5.
Figur e 4.5. The TCP Pr ot ocol Dat a Unit .
The dif f er ent f iel ds ar e as f ol l ows:
G Sour ce por t : A 16-bit f iel d t hat ident if ies t he l ocal TCP user (usual l y an upper -
l ayer appl icat ion pr ogr am).
G Dest inat ion por t : A 16-bit f iel d t hat ident if ies t he r emot e machine's TCP user .
G Sequence number : A number indicat ing t he cur r ent bl ock's posit ion in t he
over al l message. This number is al so used bet ween t wo TCP impl ement at ions t o
pr ovide t he init ial send sequence (ISS) number .
G Acknowl edgment number : A number t hat indicat es t he next sequence number
expect ed. In a backhanded manner , t his al so shows t he sequence number of t he
l ast dat a r eceived; it shows t he l ast sequence number r eceived pl us 1.
G Dat a of f set : The number of 32-bit wor ds t hat ar e in t he TCP header . This f iel d is
used t o ident if y t he st ar t of t he dat a f iel d.
G Reser ved: A 6-bit f iel d r eser ved f or f ut ur e use. The six bit s must be set t o 0.
G Ur g f l ag: If on (a val ue of 1), indicat es t hat t he ur gent point er f iel d is
signif icant .
G Ack f l ag: If on, indicat es t hat t he Acknowl edgment f iel d is signif icant .
G Psh f l ag: If on, indicat es t hat t he push f unct ion is t o be per f or med.
G Rst f l ag: If on, indicat es t hat t he connect ion is t o be r eset .
G Syn f l ag: If on, indicat es t hat t he sequence number s ar e t o be synchr onized. This
f l ag is used when a connect ion is being est abl ished.
G Fin f l ag: If on, indicat es t hat t he sender has no mor e dat a t o send. This is t he
equival ent of an end-of -t r ansmission mar ker .
G Window: A number indicat ing how many bl ocks of dat a t he r eceiving machine can
accept .
G Checksum: Cal cul at ed by t aking t he 16-bit one's compl ement of t he one's
compl ement sum of t he 16-bit wor ds in t he header (incl uding pseudo-header ) and
t ext t oget her . (A r at her l engt hy pr ocess r equir ed t o f it t he checksum pr oper l y
int o t he header .)
G Ur gent point er : Used if t he ur g f l ag was set ; it indicat es t he por t ion of t he dat a
message t hat is ur gent by specif ying t he of f set f r om t he sequence number in t he
header . No specif ic act ion is t aken by TCP wit h r espect t o ur gent dat a; t he act ion
is det er mined by t he appl icat ion.
G Opt ions: Simil ar t o t he IP header opt ion f iel d, t his is used f or specif ying TCP
opt ions. Each opt ion consist s of an opt ion number (one byt e), t he number of byt es
in t he opt ion, and t he opt ion val ues. Onl y t hr ee opt ions ar e cur r ent l y def ined f or
TCP:
0 End of opt ion l ist
1 No oper at ion
2 Maximum segment size
G Padding: Fil l ed t o ensur e t hat t he header is a 32-bit mul t ipl e.
Fol l owing t he PDU or header is t he dat a. The Opt ions f iel d has one usef ul f unct ion: t o
specif y t he maximum buf f er size a r eceiving TCP impl ement at ion can accommodat e.
Because TCP uses var iabl e-l engt h dat a ar eas, it is possibl e f or a sending machine t o
cr eat e a segment t hat is l onger t han t he r eceiving sof t war e can handl e.
The Checksum f iel d cal cul at es t he checksum based on t he ent ir e segment size, incl uding
a 96-bit pseudoheader t hat is pr ef ixed t o t he TCP header dur ing t he cal cul at ion. The
pseudoheader cont ains t he sour ce addr ess, dest inat ion addr ess, pr ot ocol ident if ier , and
segment l engt h. These ar e t he par amet er s t hat ar e passed t o IP when a send inst r uct ion
is passed, and al so t he ones r ead by IP when del iver y is at t empt ed.
TCP and Connections
TCP has many r ul es imposed on how it communicat es. These r ul es and t he pr ocesses t hat
TCP f ol l ows t o est abl ish a connect ion, t r ansf er dat a, and t er minat e a connect ion ar e
usual l y pr esent ed in st at e diagr ams. (Because TCP is a st at e-dr iven pr ot ocol , it s act ions
depend on t he st at e of a f l ag or simil ar const r uct .) Avoiding over l y compl ex st at e
diagr ams is dif f icul t , so f l ow diagr ams can be used as a usef ul met hod f or under st anding
TCP.
Establishing a Connection
A connect ion can be est abl ished bet ween t wo machines onl y if a connect ion bet ween t he
t wo socket s does not exist , bot h machines agr ee t o t he connect ion, and bot h machines
have adequat e TCP r esour ces t o ser vice t he connect ion. If any of t hese condit ions ar e
not met , t he connect ion cannot be made. The accept ance of connect ions can be t r igger ed
by an appl icat ion or a syst em administ r at ion r out ine.
When a connect ion is est abl ished, it is given cer t ain pr oper t ies t hat ar e val id unt il t he
connect ion is cl osed. Typical l y, t hese ar e a pr ecedence val ue and a secur it y val ue.
These set t ings ar e agr eed upon by t he t wo appl icat ions when t he connect ion is in t he
pr ocess of being est abl ished.
In most cases, a connect ion is expect ed by t wo appl icat ions, so t hey issue eit her act ive or
passive open r equest s. Figur e 4.6 shows a f l ow diagr am f or a TCP open. The pr ocess begins
wit h Machine A's TCP r eceiving a r equest f or a connect ion f r om it s ULP, t o which it
sends an act ive open pr imit ive t o Machine B. (Ref er back t o Tabl e 4.2 f or t he TCP
pr imit ives.) The segment t hat is const r uct ed has t he SYN f l ag set on (set t o 1) and has a
sequence number assigned. The diagr am shows t his wit h t he not at ion "SYN SEQ 50,"
indicat ing t hat t he SYN f l ag is on and t he sequence number (Init ial Send Sequence
number or ISS) is 50. (Any number coul d have been chosen.)
Figur e 4.6. Est abl ishing a connect ion.
The appl icat ion on Machine B has issued a passive open inst r uct ion t o it s TCP. When t he
SYN SEQ 50 segment is r eceived, Machine B's TCP sends an acknowl edgment back t o
Machine A wit h t he sequence number of 51. Machine B al so set s an ISS number of it s
own. The diagr am shows t his message as "ACK 51; SYN 200," indicat ing t hat t he message is
an acknowl edgment wit h sequence number 51, it has t he SYN f l ag set , and it has an ISS
of 200.
Upon r eceipt , Machine A sends back it s own acknowl edgment message wit h t he sequence
number set t o 201. This is "ACK 201" in t he diagr am. Then, having opened and
acknowl edged t he connect ion, Machine A and Machine B bot h send connect ion open
messages t hr ough t he ULP t o t he r equest ing appl icat ions.
It is not necessar y f or t he r emot e machine t o have a passive open inst r uct ion, as
ment ioned ear l ier . In t his case, t he sending machine pr ovides bot h t he sending and
r eceiving socket number s, as wel l as pr ecedence, secur it y, and t imeout val ues. It is
common f or t wo appl icat ions t o r equest an act ive open at t he same t ime. This is r esol ved
quit e easil y, al t hough it does invol ve a l it t l e mor e net wor k t r af f ic.
Data Transfer
Tr ansf er r ing inf or mat ion is st r aight f or war d, as shown in Figur e 4.7. For each bl ock of
dat a r eceived by Machine A's TCP f r om t he ULP, TCP encapsul at es it and sends it t o
Machine B wit h an incr easing sequence number . Af t er Machine B r eceives t he message, it
acknowl edges it wit h a segment acknowl edgment t hat incr ement s t he next sequence
number (and hence indicat es t hat it has r eceived ever yt hing up t o t hat sequence
number ). Figur e 4.7 shows t he t r ansf er of t wo segment s of inf or mat ionone each way.
Figur e 4.7. Dat a t r ansf er s.
The TCP dat a t r anspor t ser vice act ual l y embodies six subser vices:
G Ful l dupl ex: Enabl es bot h ends of a connect ion t o t r ansmit at any t ime, even
simul t aneousl y.
G Timel iness: The use of t imer s ensur es t hat dat a is t r ansmit t ed wit hin a
r easonabl e amount of t ime.
G Or der ed: Dat a sent f r om one appl icat ion is r eceived in t he same or der at t he
ot her end. This occur s despit e t he f act t hat t he dat agr ams might be r eceived out
of or der t hr ough IP, because TCP r eassembl es t he message in t he cor r ect or der
bef or e passing it up t o t he higher l ayer s.
G Label ed: Al l connect ions have an agr eed-upon pr ecedence and secur it y val ue.
G Cont r ol l ed f l ow: TCP can r egul at e t he f l ow of inf or mat ion t hr ough t he use of
buf f er s and window l imit s.
G Er r or cor r ect ion: Checksums ensur e t hat dat a is f r ee of er r or s (wit hin t he
checksum al gor it hm's l imit s).
Closing Connections
To cl ose a connect ion, one of t he TCPs r eceives a cl ose pr imit ive f r om t he ULP and issues
a message wit h t he FIN f l ag set on. This is shown in Figur e 4.8. In t he f igur e, Machine A's
TCP sends t he r equest t o cl ose t he connect ion t o Machine B wit h t he next sequence
number . Machine B t hen sends back an acknowl edgment of t he r equest and it s next
sequence number . Fol l owing t his, Machine B sends t he cl ose message t hr ough it s ULP t o
t he appl icat ion and wait s f or t he appl icat ion t o acknowl edge t he cl osur e. This st ep is
not st r ict l y necessar y; TCP can cl ose t he connect ion wit hout t he appl icat ion's
appr oval , but a wel l -behaved syst em woul d inf or m t he appl icat ion of t he change in
st at e.
Figur e 4.8. Cl osing a connect ion.
Af t er r eceiving appr oval t o cl ose t he connect ion f r om t he appl icat ion (or af t er t he
r equest has t imed out ), Machine B's TCP sends a segment back t o Machine A wit h t he FIN
f l ag set . Final l y, Machine A acknowl edges t he cl osur e, and t he connect ion is
t er minat ed.
An abr upt t er minat ion of a connect ion can occur when one side shut s down t he socket .
This can be done wit hout any not ice t o t he ot her machine and wit hout r egar d t o any
inf or mat ion in t r ansit bet ween t he t wo. Aside f r om sudden shut downs caused by
mal f unct ions or power out ages, abr upt t er minat ion can be init iat ed by a user , an
appl icat ion, or a syst em monit or ing r out ine t hat judges t he connect ion wor t hy of
t er minat ion. The ot her end of t he connect ion might not r eal ize t hat an abr upt
t er minat ion has occur r ed unt il it at t empt s t o send a message and t he t imer expir es.
To keep t r ack of al l t he connect ions, TCP uses a connect ion t abl e. Each exist ing
connect ion has an ent r y in t he t abl e t hat shows inf or mat ion about t he end-t o-end
connect ion. The l ayout of t he TCP connect ion t abl e is shown in Figur e 4.9.
Figur e 4.9. The TCP connect ion t abl e.
The meaning of each col umn is as f ol l ows:
G St at e: The st at e of t he connect ion (cl osed, cl osing, l ist ening, wait ing, and so on).
G Local addr ess: The IP addr ess f or t he connect ion. When in a l ist ening st at e, t his
is set t o 0.0.0.0.
G Local por t : The l ocal por t number .
G Remot e addr ess: The r emot e machine's IP addr ess.
G Remot e por t : The por t number of t he r emot e connect ion.
User Datagram Protocol (UDP)
TCP is a connect ion-based pr ot ocol . Ther e ar e t imes when a connect ionl ess pr ot ocol is
r equir ed, so UDP is used. UDP is used wit h bot h t he Tr ivial Fil e Tr ansf er Pr ot ocol (TFTP)
and t he Remot e Cal l Pr ocedur e (RCP). Connect ionl ess communicat ions don't pr ovide
r el iabil it y, meaning t her e is no indicat ion t o t he sending device t hat a message has been
r eceived cor r ect l y. Connect ionl ess pr ot ocol s al so do not of f er er r or -r ecover y
capabil it ieswhich must be eit her ignor ed or pr ovided in t he higher or l ower l ayer s.
UDP is much simpl er t han TCP. It int er f aces wit h IP (or ot her pr ot ocol s) wit hout t he
bot her of f l ow cont r ol or er r or -r ecover y mechanisms, act ing simpl y as a sender and
r eceiver of dat agr ams.
UDP is connect ionl ess; TCP is based on connect ions.
The UDP message header is much simpl er t han TCP's. It is shown in Figur e 4.10. Padding
can be added t o t he dat agr am t o ensur e t hat t he message is a mul t ipl e of 16 bit s.
Figur e 4.10. The UDP header .
The f iel ds ar e as f ol l ows:
G Sour ce por t : An opt ional f iel d wit h t he por t number . If a por t number is not
specif ied, t he f iel d is set t o 0.
G Dest inat ion por t : The por t on t he dest inat ion machine.
G Lengt h: The l engt h of t he dat agr am, incl uding header and dat a.
G Checksum: A 16-bit one's compl ement of t he one's compl ement sum of t he
dat agr am, incl uding a pseudoheader simil ar t o t hat of TCP.
The UDP checksum f iel d is opt ional , but if it isn't used, no checksum is appl ied t o t he dat a
segment because IP's checksum appl ies onl y t o t he IP header . If t he checksum is not used,
t he f iel d shoul d be set t o 0.
Summary
Today, I l ooked at TCP in r easonabl e det ail . Combined wit h t he inf or mat ion in t he l ast
t hr ee days, you now have t he t heor y and backgr ound necessar y t o bet t er under st and
TCP/IP ut il it ies, such as Tel net and FTP, as wel l as ot her pr ot ocol s t hat use or cl osel y
r esembl e TCP/IP, such as SMTP and TFTP.
The det ail s of TCP/IP ar e r evisit ed l at er in t his book, but you can now pr oceed t o
act ual l y using TCP/IP and it s t ool set .
Q&A
Def ine mul t ipl exing and how it woul d be used t o combine t hr ee sour ce machines t o
one dest inat ion machine. Rel at e t o por t number s.
Mul t ipl exing was expl ained in some det ail on Day 1. It r ef er s t o combining sever al
connect ions int o one. Thr ee machines coul d each est abl ish sour ce por t s t o one machine
using onl y one r eceiving por t . The por t number s f or t he sending machines woul d al l be
dif f er ent , but al l t hr ee woul d use t he same dest inat ion por t number . This was shown in
Figur e 4.4.
What one wor d best descr ibes t he dif f er ence bet ween TCP and UDP?
Connect ions. TCP is connect ion-based, wher eas UDP is connect ionl ess.
What ar e por t number s and socket s?
A por t number is used t o ident if y t he t ype of ser vice pr ovided. A socket is t he addr ess of
t he por t on which a connect ion is est abl ished. Ther e is no inher ent physical r el at ionship
bet ween t he t wo, al t hough many machines assign cer t ain socket s f or par t icul ar ser vices
(por t number s).
Descr ibe t he t imer s used wit h TCP.
The r et r ansmission t imer is used t o cont r ol t he r esending of a dat agr am. The quiet t imer
is used t o del ay t he r eassignment of a por t . The per sist ence t imer is used t o t est a r eceive
window. Keep-al ive t imer s send empt y dat a t o keep a connect ion al ive. The idl e t imer is
t he amount of t ime t o wait f or a disconnect ion t o be t er minat ed af t er no dat agr ams ar e
r eceived.
What ar e t he six dat a t r anspor t subser vices of f er ed by TCP?
The subser vices ar e f ul l dupl ex, t imel iness, or der ed, l abel ed, cont r ol l ed f l ow, and
er r or cor r ect ion.
Workshop
The Wor kshop pr ovides quiz quest ions t o hel p you sol idif y your under st anding of t he
mat er ial cover ed. Some Wor kshop sect ions of t his book al so cont ain exer cises t o pr ovide
you wit h exper ience in using what you have l ear ned. Tr y t o under st and t he quiz and
exer cise answer s bef or e cont inuing on t o t he next chapt er . Answer s ar e pr ovided in
Appendix F, "Answer s t o Quizzes."
Quiz
1. Dr aw a diagr am showing t he binding of por t t abl es when t hr ee machines ar e
sending inf or mat ion t o each ot her .
2. Dr aw t he TCP pr ot ocol dat a unit (PDU) and expl ain t he meaning of each f iel d.
3. Use a diagr am t o show t he signal s invol ved wit h t wo machines est abl ishing a TCP
connect ion. Then, show how dat a is t r ansf er r ed. Final l y, show t he t er minat ion
pr ocess.
4. What is a TCP connect ion t abl e? How is it used?
5. Dr aw t he UDP header and expl ain t he f iel ds it cont ains.
6. What ar e t he advant ages of using UDP over TCP? When woul d you not want t o
use UDP?


I Gat eways, Br idges, and Rout er s
I Gat eway Pr ot ocol s
I Rout ing Daemons
I Rout ing
I Fewest -Hops Rout ing
I Type of Ser vice Rout ing
I Updat ing Gat eway Rout ing Inf or mat ion
I The IGP and EGPGat eway Pr ot ocol s
I Gat eway-t o-Gat eway Pr ot ocol (GGP)
I The Ext er nal Gat eway Pr ot ocol (EGP)
I Neighbor s and EGP
I EGP Messages
I Neighbor Acquisit ion Messages
I Neighbor Reachabil it y Messages
I Pol l Messages
I Updat e Messages
I Er r or Messages
I EGP t o GGP Messages
I EGP St at e Var iabl es and Timer s
I Int er ior Gat eway Pr ot ocol s (IGP)
I The Rout ing Inf or mat ion Pr ot ocol (RIP)
I The HELLO Pr ot ocol
I The Open Shor t est Pat h Fir st (OSPF) Pr ot ocol
I OSPF Packet s
I HELLO Packet s
I Link St at e Request and Updat e Packet s
I Summar y
I Q&A
I Quiz
5
Gateway and Routing Protocols
TCP/IP f unct ions per f ect l y wel l on a l ocal ar ea net wor k, but it s devel opment was
spur r ed by int er net wor ks (mor e specif ical l y by t he Int er net it sel f ), so it seems l ogical
t hat TCP/IP has an ar chit ect ur e t hat wor ks wel l wit h int er net wor k oper at ions. Today I
examine t hese int er net wor k specif ics in mor e det ail by l ooking at t he manner in which
gat eways t r ansf er r out ing inf or mat ion bet ween t hemsel ves.
The r out ing met hod used t o send a message f r om it s or igin t o dest inat ion is impor t ant ,
but t he met hod by which t he r out ing inf or mat ion is t r ansf er r ed depends on t he r ol e of
t he net wor k gat eways. Ther e ar e special pr ot ocol s devel oped specif ical l y f or dif f er ent
kinds of gat eways, al l of which f unct ion wit h TCP.
Gateways, Bridges, and Routers
To f or war d messages t hr ough net wor ks, a machine's IP l ayer sof t war e compar es t he
dest inat ion addr ess of t he message (cont ained in t he Pr ot ocol Dat a Unit , or PDU) t o t he
l ocal machine's addr ess. If t he message is not f or t he l ocal machine, t he message is passed
on t o t he next machine. Moving messages ar ound smal l net wor k is quit e easy, but l ar ge
net wor ks and int er net wor ks add t o t he compl exit y, r equir ing gat eways, br idges, and
r out er s, which t r y t o est abl ish t he best met hod of moving t he message t o it s dest inat ion.
Def ining t he meaning of t hese t er ms is r el at ivel y easy:
G A gat eway is a device t hat per f or ms r out ing f unct ions, usual l y as a st and-al one
device, t hat al so can per f or m pr ot ocol t r ansl at ion f r om one net wor k t o anot her .
G A br idge is a net wor k device t hat connect s t wo or mor e net wor ks t hat use t he
same pr ot ocol .
G A r out er is a net wor k node t hat f or war ds dat agr ams ar ound t he net wor k.
The gat eway's pr ot ocol conver sion capabil it y is impor t ant (ot her wise, t he machine is no
dif f er ent f r om a br idge). Pr ot ocol conver sion usual l y t akes pl ace in t he l ower l ayer s,
somet imes incl uding t he t r anspor t l ayer . Conver sion can occur in sever al f or ms, such as
when moving f r om a l ocal ar ea net wor k f or mat t o Et her net (in which case t he f or mat
of t he packet is changed) or f r om one pr opr iet ar y f il e convent ion t o anot her (in which
case t he f il e specif icat ions ar e conver t ed).
Br idges act as l inks bet ween net wor ks, which of t en have a br idge at eit her end of a
dedicat ed communicat ions l ine (such as a l eased l ine) or t hr ough a packet syst em such as
t he Int er net . Ther e might be a conver sion appl ied bet ween br idges t o incr ease t he
t r ansmission speed. This r equir es bot h ends of t he connect ion t o under st and a common
pr ot ocol .
Rout er s oper at e at t he net wor k l evel , f or war ding packet s t o t heir dest inat ion.
Somet imes a pr ot ocol change can be per f or med by a r out er t hat has sever al del iver y
opt ions avail abl e, such as Et her net or ser ial l ines.
A t er m you might occasional l y see is brouter, a cont r act ion of bot h br idge and r out er . As
you might expect , br out er s per f or m t he f unct ions of bot h a br idge and a r out er ,
al t hough somet imes not al l f unct ions ar e pr ovided. The t er m br out er is of t en appl ied
f or any device t hat per f or ms some or al l of t he f unct ions of bot h a br idge and a r out er .
A t er m in common use when deal ing wit h r out es is packet-switching. A packet -swit ched
net wor k is one in which al l t r ansf er s ar e based on a sel f -cont ained packet of dat a (l ike
t hat of TCP/IP's dat agr ams). Ther e ar e al so message-swit ched (sel f -cont ained compl et e
messages, as wit h UNIX's UUCP syst em) and l ine-swit ched (f ixed or dedicat ed
connect ions) net wor ks, but t hese ar e r ar el y used wit h TCP/IP. Packet -swit ched
net wor ks t end t o be f ast er over al l t han message-swit ched net wor ks, but t hey ar e al so
consider abl y mor e compl ex.
Gateway Protocols
Gat eway pr ot ocol s ar e used t o exchange inf or mat ion wit h ot her gat eways in a f ast ,
r el iabl e manner . Using gat eway pr ot ocol s, t r ansmission t ime over l ar ge int er net wor ks
has been shown t o incr ease, al t hough t her e is consider abl e suppor t f or t he idea of
having onl y one pr ot ocol acr oss t he ent ir e Int er net (which woul d el iminat e gat eway
pr ot ocol s in f avor of TCP/IP t hr oughout ).
The Int er net pr ovides f or t wo t ypes of gat eways: cor e and non-cor e. Al l cor e gat eways
ar e administ er ed by t he Int er net Net wor k Oper at ions Cent er (INOC). Non-cor e gat eways
ar e not administ er ed by t his cent r al aut hor it y but by gr oups out side t he Int er net
hier ar chy (who might st il l be connect ed t o t he Int er net but administ er t heir own
machines). Typical l y, cor por at ions and educat ional inst it ut ions use non-cor e gat eways.
The or igin of cor e gat eways ar ose f r om t he ARPANET, wher e each node was under t he
cont r ol of t he gover ning agency. ARPANET cal l ed t hem stub gateways, wher eas any
gat eway not under dir ect cont r ol (non-cor e in Int er net t er ms) was cal l ed a nonrouting
gateway. The move t o t he Int er net and it s pr ol if er at ion of gat eways r equir ed t he
impl ement at ion of t he Gat eway-t o-Gat eway Pr ot ocol (GGP), which was used bet ween
cor e gat eways. The GGP was usual l y used t o spr ead inf or mat ion about t he non-cor e
gat eways at t ached t o each cor e gat eway, enabl ing r out ing t abl es t o be buil t .
As t he Int er net gr ew, it became impossibl e f or any one gat eway t o hol d a compl et e map
of t he ent ir e int er net wor k. This was sol ved by having each gat eway handl e onl y a
specif ic sect ion of t he int er net wor k, r el ying on neighbor ing gat eways t o know mor e
about t heir own at t ached net wor ks when a message was passed. One pr obl em t hat
f r equent l y occur r ed was a l ack of inf or mat ion f or compl et e r out ing decisions, so
def aul t r out es wer e used.
Ear l ier in t his book, t he t er m autonomous system was int r oduced. An aut onomous syst em is
one in which t he st r uct ur e of t he net wor k it is at t ached t o is not visibl e t o t he r est of
t he int er net wor k. Usual l y, a gat eway l eads int o t he net wor k, so al l t r af f ic f or t hat
net wor k must go t hr ough t he gat eway, which hides t he int er nal st r uct ur e of t he l ocal
net wor k f r om t he r est of t he int er net wor k.
If t he l ocal net wor k has mor e t han one gat eway and t hey can t al k t o each ot her , t hey
ar e consider ed int er ior neighbor s. (The t er m int er ior neighbor is somet imes appl ied t o t he
machines wit hin t he net wor k, t oo, not just t he gat eways.) If t he gat eways bel ong t o
dif f er ent aut onomous syst ems, t hey ar e ext er ior gat eways. Thus, when def aul t r out es
ar e r equir ed, it is up t o t he ext er ior gat eways t o r out e messages bet ween aut onomous
syst ems. Int er ior gat eways ar e used t o t r ansf er messages int o an aut onomous syst em.
Wit hin a net wor k, t he met hod of t r ansf er r ing r out ing inf or mat ion bet ween int er ior
gat eways is usual l y t he Rout ing Inf or mat ion Pr ot ocol (RIP) or t he l ess common HELLO
pr ot ocol , bot h of which ar e Int er ior Gat eway Pr ot ocol s (IGPs). These pr ot ocol s ar e
designed specif ical l y f or int er ior neighbor s. On t he Int er net , messages bet ween t wo
ext er ior gat eways ar e t hr ough t he Ext er ior Gat eway Pr ot ocol (EGP). RIP, HELLO, and
EGP al l r el y on a f r equent (ever y t hir t y seconds) t r ansf er of inf or mat ion bet ween
gat eways t o updat e r out ing t abl es.
The t hr ee gat eway pr ot ocol s ar e int er t wined: EGP is used
bet ween gat eways of aut onomous syst ems, wher eas t he IGPs RIP
and HELLO ar e used wit hin t he net wor k it sel f . GGP is used
bet ween cor e gat eways.
Why not use GGP f or al l int er net wor k communicat ions, dr opping t he need f or EGPs? The
answer l ies in t he f act t hat cor e gat eways t hat use GGP know about al l t he ot her cor e
gat eways on t he int er net wor k. This simpl if ies t heir messaging and pr ovides compl et e
r out ing t abl es. However , cor e gat eways usual l y l ead int o many compl ex net wor ks of
mor e aut onomous net wor ks, most of which t he cor e gat eways don't know about .
However , t he ext er ior gat eways must know about al l t he net wor ks dir ect l y connect ed
t o it , but not al l t he net wor ks on t he ent ir e int er net wor k, so t he r out ing t abl es and
r out ing al gor it hms f or a cor e and non-cor e gat eway ar e dif f er ent . This al so means t hat
messages can have dif f er ent f or mat s, because r out ing inf or mat ion f or a non-cor e
gat eway has some connect ions t hat ar e hidden f r om ot her gat eways.
It is possibl e f or a l ar ge aut onomous syst em t o be composed of sever al subnet wor ks or
ar eas, each of which communicat es wit h t he ot her ar eas t hr ough an IGP. Each
subnet wor k or ar ea has a designat ed gat eway, cal l ed a border gateway, or border router, t o
indicat e t hat it is wit hin an ar ea. BORDER r out er s communicat e wit h each ot her using
IGP. A commonl y encount er ed t er m is boundary gateway, which is t he same as an ext er ior
gat eway or a pat h t o anot her aut onomous net wor k. This is il l ust r at ed in Figur e 5.1,
which shows t hr ee subnet wor ks or ar eas t hat communicat e wit h each ot her t hr ough
boundar y gat eways or r out er s using IGP, and t wo ext er ior gat eways (al so cal l ed
boundar y gat eways) t hat communicat e wit h t he r est of t he int er net wor k using EGP.
Figur e 5.1. Int er ior and ext er ior gat eways.
Routing Daemons
To handl e t he r out ing t abl es, most UNIX syst ems use a daemon cal l ed r out ed. A f ew
syst ems r un a daemon cal l ed gat ed. Bot h r out ed and gat ed can exchange RIP messages
wit h ot her machines, updat ing t heir r out e t abl es as necessar y. The gat ed pr ogr am can
al so handl e EGP and HELLO messages, updat ing t abl es f or t he int er net wor k. Bot h
r out ed and gat ed can be managed by t he syst em administ r at or t o sel ect f avor abl e
r out es, or t o t ag a r out e as not r el iabl e.
The conf igur at ion inf or mat ion f or gat ed and r out ed is usual l y st or ed as f il es named
gat ed.cf g, gat ed.conf , or gat ed.cf . Some syst ems specif y gat ed inf or mat ion f il es f or each
pr ot ocol , r esul t ing in t he f il es gat ed.egp, gat ed.hel l o, and gat ed.r ip. A sampl e
conf igur at ion f il e f or EGP used by t he gat ed pr ocess is shown her e:
# @(#)gated.egp 4.1 Lachman System V STREAMS TCP source
# sample EGP config file
traceoptions general kernel icmp egp protocol ;
autonomoussystem 519 ;
rip no;
egp yes {
group ASin 519 {
neighbor 128.212.64.1 ;
} ;
} ;
static {
default gateway 128.212.64.1 pref 100 ;
} ;
propagate proto egp as 519 {
proto rip gateway 128.212.64.1 {
announce 128.212 metric 2 ;
} ;
proto direct {
announce 128.212 metric 2 ;
} ;
} ;
propagate proto rip {
proto default {
announce 0.0.0.0 metric 1 ;
} ;
proto rip {
noannounce all ;
} ;
} ;
The code above shows a number of conf igur at ion det ail s. It st ar t s wit h a number of
opt ions and t he swit ch t hat t ur ns EGP on and set s t he neighbor IP addr ess. This is
f ol l owed by code t hat def ines t he way EGP behaves. Most of t he det ail s ar e of l it t l e
int er est and ar e sel dom (if ever ) modif ied by a user . Inst ead, conf igur at ion r out ines t end
t o manage t his f il es cont ent s.
The UNIX syst em administ r at or al so has a pr ogr am cal l ed r out e t hat enabl es dir ect
ent r y of r out ing t abl e inf or mat ion. The inf or mat ion on a UNIX syst em r egar ding
r out ing is usual l y st or ed in t he f il e /et c/gat eways.
It has become common pr act ice t o al l ow a def aul t net wor k Int er net addr ess of 0.0.0.0,
which r ef er s t o a gat eway on t he net wor k t hat shoul d be capabl e of r esol ving an
unknown addr ess. (This is incl uded in t he pr evious sampl e conf igur at ion f il e as proto
default.) The def aul t r out e is used when t he l ocal machine cannot r esol ve t he addr ess
pr oper l y. Because t he r out ing t abl es on a gat eway ar e usual l y mor e compl et e t han
t hose on a l ocal machine, t his hel ps send packet s t o t heir int ended dest inat ion. If t he
def aul t addr ess gat eway cannot r esol ve t he addr ess, an Int er net Cont r ol Message
Pr ot ocol (ICMP) er r or message is r et ur ned t o t he sender .
Routing
Rout ing r ef er s t o t he t r ansmission of a packet of inf or mat ion f r om one machine t hr ough
anot her . Each machine t hat t he packet ent er s anal yzes t he cont ent s of t he packet
header and decides it s act ion based on t he inf or mat ion wit hin t he header . If t he
dest inat ion addr ess of t he packet mat ches t he machine's addr ess, t he packet shoul d be
r et ained and pr ocessed by higher -l evel pr ot ocol s. If t he dest inat ion addr ess doesn't
mat ch t he machine's, t he packet is f or war ded f ur t her ar ound t he net wor k. For war ding
can be t o t he dest inat ion machine it sel f , or t o a gat eway or br idge if t he packet is t o
l eave t he l ocal net wor k.
Rout ing is a pr imar y cont r ibut or t o t he compl exit y of packet -swit ched net wor ks. It is
necessar y t o account f or an opt imal pat h f r om sour ce t o dest inat ion machines, as wel l
as t o handl e pr obl ems such as a heavy l oad on an int er vening machine or t he l oss of a
connect ion. The r out e det ail s ar e cont ained in a r out ing t abl e, and sever al
sophist icat ed al gor it hms wor k wit h t he r out ing t abl e t o devel op an opt imal r out e f or a
packet .
Cr eat ing a r out ing t abl e and maint aining it wit h val id ent r ies ar e impor t ant aspect s of
a pr ot ocol . Her e ar e a f ew common met hods of buil ding a r out ing t abl e:
G A f ixed t abl e is cr eat ed wit h a map of t he net wor k, which must be modif ied and
r er ead ever y t ime t her e is a physical change anywher e on t he net wor k.
G A dynamic t abl e is used t hat eval uat es t r af f ic l oad and messages f r om ot her nodes
t o r ef ine an int er nal t abl e.
G A f ixed cent r al r out ing t abl e is used t hat is l oaded f r om t he cent r al r eposit or y
by t he net wor k nodes at r egul ar int er val s or when needed.
Each met hod has advant ages and disadvant ages. The f ixed t abl e appr oach, whet her
l ocat ed on each net wor k node or downl oaded at r egul ar int er val s f r om a cent r al l y
maint ained f ixed t abl e, is inf l exibl e and can't r eact t o changes in t he net wor k t opol ogy
quickl y. The cent r al t abl e is bet t er t han t he f ir st opt ion, simpl y because it is possibl e
f or an administ r at or t o maint ain t he singl e t abl e much mor e easil y t han a t abl e on each
node.
The dynamic t abl e is t he best f or r eact ing t o changes, al t hough it does r equir e bet t er
cont r ol , mor e compl ex sof t war e, and mor e net wor k t r af f ic. However , t he advant ages
usual l y out weigh t he disadvant ages, and a dynamic t abl e is t he met hod most f r equent l y
used on t he Int er net .
Fewest-Hops Routing
Most net wor ks and gat eways t o int er net wor ks wor k on t he assumpt ion t hat t he
shor t est r out e (in t er ms of machines t r avel ed t hr ough) is t he best way t o r out e
messages. Each machine t hat a message passes t hr ough is cal l ed a hop, so t his r out ing
met hod is known as fewest hops. Al t hough exper iment at ion has shown t hat t he f ewest -
hops met hod is not necessar il y t he f ast est met hod (because it doesn't t ake int o account
t r ansmission speed bet ween machines), it is one of t he easiest r out ing met hods t o
impl ement .
To pr ovide f ewest -hops r out ing, a t abl e of t he dist ance bet ween any t wo machines is
devel oped, or an al gor it hm is avail abl e t o hel p cal cul at e t he number of hops r equir ed
t o r each a t ar get machine. This is shown using t he sampl e int er net wor k of gat eways in
Figur e 5.2 and it s cor r esponding t abl e of dist ances bet ween t he gat eways in t he f igur e,
which is shown in Tabl e 5.1.
Figur e 5.2. An int er net wor k of gat eways.
Tabl e 5.1. Tabl e of f ewest hops f r om Figur e 5.2.
A B C D E F G H I
A 1 2 1 2 3 4 3 4
B 1 1 2 3 4 5 4 5
C 2 1 1 2 3 4 3 4
D 1 2 1 1 2 3 2 3
E 2 3 2 1 1 2 1 2
F 3 4 3 2 1 1 2 1
G 4 5 4 3 2 1 2 1
H 3 4 3 2 1 2 2 1
I 4 5 4 3 2 1 1 1
When a message is t o be r out ed using t he f ewest -hops appr oach, t he t abl e of dist ances is
consul t ed, and t he r out e wit h t he f ewest number of hops is sel ect ed. The message is t hen
r out ed t o t he gat eway t hat is cl osest t o t he dest inat ion net wor k. When int er mediat e
gat eways r eceive t he message, t hey per f or m t he same t ype of t abl e l ookup and f or war d
t o t he next gat eway on t he r out e.
Ther e ar e sever al pr obl ems wit h t he f ewest -hops appr oach. If t he t abl es of t he gat eways
t hr ough which a message t r avel s t o it s dest inat ion have dif f er ent r out e inf or mat ion, it
is conceivabl e t hat a message t hat l ef t t he sour ce machine on t he shor t est r out e coul d
end up f ol l owing a mor e cir cuit ous pat h because of dif f er ing t abl es in t he int er vening
gat eways. The f ewest -hops met hod al so doesn't account f or t r ansf er speed, l ine f ail ur es,
or ot her f act or s t hat coul d af f ect t he over al l t ime t o t r avel t o t he dest inat ion; it is
mer el y concer ned wit h t he shor t est appar ent dist ance, assuming t hat al l connect ions
ar e equal . To accommodat e t hese f act or s, anot her r out ing met hod must be used.
Type of Service Routing
This t ype of r out ing depends on t he t ype of r out ing ser vice avail abl e f r om gat eway t o
gat eway. This is cal l ed type of service (TOS) r out ing. It is al so mor e f or mal l y cal l ed
quality of service (QOS) by OSI. TOS incl udes consider at ion f or t he speed and r el iabil it y of
connect ions, as wel l as secur it y and r out e-specif ic f act or s.
To ef f ect TOS r out ing, most syst ems use dynamic updat ing of t abl es t hat r ef l ect t r af f ic
and l ink condit ions. They al so t ake int o account cur r ent queue l engt hs at each
gat eway, because t he f ast est t heor et ical r out e might not mat t er if t he message is
backl ogged in a queue. This inf or mat ion is obt ained t hr ough t he f r equent t r ansf er of
st at us messages bet ween gat eways, especial l y when condit ions det er ior at e.
Dynamic updat ing of t abl es can have a disadvant age in t hat if t abl es ar e updat ed t oo
f r equent l y, a message might cir cul at e t hr ough a sect ion of t he int er net wor k wit hout
pr oper r out ing t o it s dest inat ion, or pr oceed t hr ough a l ong and convol ut ed pat h. For
t his r eason, dynamic updat ing occur s at r egul ar but not t oo f r equent int er val s. To
pr event st r ay dat agr ams f r om cir cul at ing on t he int er net wor k t oo l ong, t he Time t o
Live inf or mat ion in t he IP message header is impor t ant .
The IP header 's Time t o Live (TTL) f iel d is ver y impor t ant
t o dynamic gat eway r out ing pr ot ocol s, which is why it is a
mandat or y f iel d. Wit hout it , dat agr ams coul d cir cul at e
t hr oughout t he net wor k indef init el y.
The dynamic nat ur e of TOS r out ing can somet imes cause a message's f r agment s t o be
r out ed in dif f er ent ways t o a dest inat ion. For exampl e, if a l ong message of 10 dat agr ams
is being sent by one r out e, but t he r out ing t abl es ar e changed dur ing t r ansmission t o
r ef l ect a backl og, t he r emainder of t he dat agr ams might be sent via an al t er nat e r out e.
This doesn't mat t er , of cour se, because t he r eceiving machine r eassembl es t he message in
t he pr oper or der as t he dat agr ams ar e r eceived.
Updating Gateway Routing Information
A somewhat simpl if ied exampl e of a dynamic updat e is usef ul at t his st age. The exact
communicat ions pr ot ocol s bet ween gat eways ar e examined in mor e det ail l at er t oday.
Assume t hat t wo aut onomous net wor ks ar e connect ed t o each ot her at t wo l ocat ions,
as shown in Figur e 5.3, wit h connect ions t o dif f er ent aut onomous net wor ks at ot her
l ocat ions. The AC connect ion and t he BD connect ion can bot h be used f or r out ing
f r om wit hin t he net wor ks, depending on which is t he opt imal pat h. Gat eway C has a copy
of gat eway A's r out ing t abl e, and vice ver sa. Gat eways B and D each have copies of t he
ot her 's r out ing t abl es, as wel l . These copies ar e t r ansmit t ed at int er val s so t he
gat eways can maint ain an up-t o-dat e pict ur e of t he connect ions avail abl e t hr ough t he
ot her gat eway. The gat eways use EGP t o send t he messages. (They woul d use GGP if t hey
wer e cor e gat eways.)
Figur e 5.3. Two int er connect ed net wor ks.
Suppose t hat a gat eway l ink wit hin one of t he net wor ks was br oken due t o a machine or
connect ion f ail ur e, such as t hat bet ween gat eway C and machine X in Figur e 5.3.
Gat eway C woul d f ind out about t he pr obl em t hr ough an IGP message and updat e it s
r out ing t abl e t o r ef l ect t he br eak, usual l y by put t ing t he l ar gest l egal val ue f or
r out ing l engt h in t hat ent r y. (Remember t hat IGP is a gener al t er m f or any int er nal
net wor k pr ot ocol f or gat eway communicat ions, such as RIP or HELLO.) Gat eway C
t r ansf er s it s new copy of t he r out ing t abl e t o gat eway A.
Rout ing a message t o machine Y woul d now be impossibl e t hr ough t he CX connect ion.
However , because gat eway A has t he r out ing inf or mat ion f r om C, and it exchanges
r out ing inf or mat ion wit h gat eway B, which al so exchanges wit h gat eway D, any
message passing t hr ough eit her D or B f or machine Y coul d be r er out ed up t hr ough
gat eway A, t hen C, and f inal l y t o Y. An EGP message bet ween BD and AC woul d
indicat e t hat t he new r out e cost s l ess t han t he maximum val ue assigned going t hr ough
CX (which is br oken), so t he r ound-about t r ansf er t hr ough t he f our gat eways can be
used.
EGP messages bet ween gat eways ar e usual l y sent whenever a connect ion pr obl em exist s
and t he r out ing inf or mat ion is set t o it s maximum (wor st ) val ue, or when a bet t er
connect ion al t er nat ive has been discover ed f or some r eason. This can be because of an
updat e f r om a r emot e gat eway's r out ing t abl e, or t he addit ion of new connect ions,
machines, or net wor ks t o t he syst em. Whichever happens, an EGP message inf or ms al l t he
connect ed gat eways of t he changes.
The IGP and EGPGateway Protocols
Gat eways need t o know what is happening t o t he r est of t he net wor k in or der t o r out e
dat agr ams pr oper l y and ef f icient l y. This incl udes not onl y r out ing inf or mat ion but al so
t he char act er ist ics of subnet wor ks. For exampl e, if one gat eway is par t icul ar l y sl ow
but is t he onl y access met hod t o a subnet wor k, ot her gat eways on t he net wor k can
t ail or t he t r af f ic t o suit .
A GGP is used t o exchange r out ing inf or mat ion bet ween devices. It is impor t ant not t o
conf use r out ing inf or mat ion, which cont ains addr esses, t opol ogy, and det ail s on r out ing
del ays, wit h t he al gor it hms used t o make r out ing inf or mat ion. Usual l y t he r out ing
al gor it hms ar e f ixed wit hin a gat eway and not modif ied. Of cour se, as t he r out ing
inf or mat ion changes, t he al gor it hm adapt s t he chosen r out es t o r ef l ect t he new
inf or mat ion.
GGPs ar e pr imar il y f or aut onomous (sel f -compl et e) net wor ks. An aut onomous syst em
uses gat eways t hat ar e connect ed in one l ar ge net wor k, such as one might f ind in a
l ar ge cor por at ion. Two kinds of gat eways must be consider ed in an aut onomous net wor k.
The gat eways bet ween smal l er subnet wor ks hel p t ie t he smal l syst ems int o t he l ar ger
cor por at e net wor k, but t he gat eways f or each subnet wor k ar e usual l y under t he
cont r ol of one syst em (usual l y in t he IS depar t ment ). These gat eways ar e consider ed
aut onomous because t he connect ions bet ween gat eways ar e const ant and sel dom
change. These gat eways communicat e t hr ough an IGP.
Lar ge int er net wor ks l ike t he Int er net ar e not as st at ic as cor por at e syst ems. Gat eways
can change const ant l y as t he subsidiar y net wor ks make changes, and t he
communicat ions r out es bet ween gat eways ar e mor e subject t o change, t oo. For widel y
spr ead companies, t her e might be gat eways spr ead t hr oughout t he count r y (or t he
wor l d) t hat ar e al l par t of t he same cor por at e net wor k but use t he Int er net t o
communicat e. The communicat ions bet ween t hese gat eways ar e sl ight l y dif f er ent t han
when t hey ar e al l physical l y connect ed t oget her . These gat eways communicat e
t hr ough an EGP.
Ther e ar e f ewer r ul es gover ning IGPs t han EGPs simpl y because t he IGP can handl e
cust om-devel oped appl icat ions and pr ot ocol s wit hin it s l ocal net wor k. When t he
Int er net is used f or gat eway-t o-gat eway communicat ions, t he messages must conf or m t o
t he int er net wor k st andar ds. Al so, when connect ing t wo subnet wor ks, it is possibl e t o
send onl y one message t o t he subnet wor k gat eway t hr ough EGP, which can t hen be
dupl icat ed, modif ied, and pr opagat ed t o al l gat eways on t he int er nal syst em using IGP.
EGP has f or mal ized r ul es gover ning it s use.
Gateway-to-Gateway Protocol (GGP)
GGP is used f or communicat ions bet ween cor e gat eways. A r ecent impr ovement of t he
pr ot ocol , cal l ed SPREAD, is st ar t ing t o be used but is not yet as common as GGP. Even if
GGP is phased out in f avor of SPREAD, it is a usef ul il l ust r at ion of gat eway-t o-gat eway
pr ot ocol s.
GGP is a vect or -dist ance pr ot ocol , meaning t hat messages t end t o specif y a dest inat ion
(vect or ) and t he dist ance t o t hat dest inat ion. Vect or -dist ance pr ot ocol s ar e al so
cal l ed Bel l man-For d pr ot ocol s, af t er t he r esear cher s who f ir st publ ished t he idea. For
a vect or -dist ance pr ot ocol t o be ef f ect ive, a gat eway must have compl et e inf or mat ion
about al l t he gat eways on t he int er net wor k; ot her wise, comput ing a dist ance wit h a
f ewest -hops t ype of pr ot ocol cannot succeed.
You might r ecal l f r om ear l ier t oday t hat cor e gat eways
have compl et e inf or mat ion about al l ot her cor e gat eways, so a
vect or -dist ance pr ot ocol wor ks. Non-cor e gat eways don't have
a compl et e int er net wor k map, so GGP-t ype messages ar e not
usef ul .
A gat eway est abl ishes it s connect ions t o ot her gat eways by sending out messages,
wait ing f or r epl ies, and t hen buil ding a t abl e. This is init ial l y accompl ished when a
gat eway is inst al l ed and has no r out ing inf or mat ion at al l . This aspect of
communicat ions is not def ined wit hin GGP but r el ies on net wor k-specif ic messages. Once
t he init ial t abl e has been def ined, GGP is used f or al l messages.
Connect ivit y wit h anot her gat eway on t he Int er net is det er mined using t he K-out -of -N
met hod. In t his pr ocedur e, a gat eway sends an echo message t o anot her gat eway and
wait s f or a r epl y. It r epeat s t his ever y f if t een seconds. Accor ding t o t he Int er net
st andar ds, if t he gat eway does not r eceive t hr ee (K) r epl ies out of f our (N) r equest s, t he
ot her gat eway is consider ed down, or unusabl e, and r out ing messages ar e not sent t o
t hat gat eway. This pr ocess can be r epeat ed at r egul ar int er val s.
If a down gat eway becomes act ive again, t he Int er net st andar ds r equir e t wo out of f our
echo messages t o be acknowl edged. This is cal l ed J-out -of -M, wher e J is t wo and M is
f our . The Int er net -assigned val ues f or J, K, M, and N can be changed f or aut onomous
net wor ks, but t he st andar d def ines t he val ues f or use on t he Int er net it sel f .
Each message bet ween gat eways has a sequence number t hat is incr ement ed wit h each
t r ansmit t ed message. Each gat eway t r acks it s own sequence number f or sending t o ever y
ot her gat eway it is connect ed t o, as wel l as t he incoming sequence number s f r om t hat
gat eway. They ar e not necessar il y t he same, because mor e messages might f l ow one way
t han t he ot her , al t hough usual l y each message shoul d have an acknowl edgment or
r epl y of some t ype.
Sequence number s have impor t ant meanings f or t he messages and ar e not just f or t he
sake of keeping an incr ement al count of t he t r af f ic vol ume. When a gat eway r eceives a
message f r om anot her gat eway, it compar es t he sequence number in t hat message t o t he
l ast r eceived sequence number in it s int er nal t abl es. If t he l at est message has a higher
sequence number t han t he l ast message r eceived, t he gat eway accept s t he message and
updat es it s sequence number t o t he l at est r eceived val ue. If t he number was l ess t han
t he l ast r eceived sequence number , t he message is consider ed ol d and is ignor ed, wit h an
er r or message cont aining t he just -r eceived message sent back. This pr ocess is shown in
Figur e 5.4.
Figur e 5.4. Pr ocessing sequence number s in GGP.
The r eceiving gat eway acknowl edges t he r eceived message by sending a r et ur n message
t hat cont ains t he sequence number of t he just -r eceived message. The ot her gat eway
compar es t hat number wit h t he number of it s l ast sent message, and if t hey ar e t he same,
t he gat eway knows t hat t he message was pr oper l y r eceived. If t he number s do not
mat ch, t he gat eway knows an er r or occur r ed and t r ansmit s t he message again.
When a message is ignor ed by t he r ecipient gat eway, t he sending gat eway r eceives a
message wit h t he sequence number of t he ignor ed message. It can t hen det er mine which
messages wer e skipped and adjust it sel f accor dingl y, r esending messages t hat need t o be
sent .
The GGP message f or mat is shown in Figur e 5.5. Af t er it is const r uct ed, it is encapsul at ed
int o an IP dat agr am t hat incl udes sour ce and t ar get addr esses. The f ir st f iel d is a
message t ype, which is set t o a val ue of 12 f or r out ing inf or mat ion. The sequence number
was discussed ear l ier and pr ovides an incr ement al count er f or each message. The Updat e
f iel d is set t o a val ue of 0 unl ess t he sending gat eway want s a r out ing updat e f or t he
pr ovided dest inat ion addr ess, in which case it is set t o a val ue of 1. The Number of
Dist ances f iel d hol ds t he number of gr oups of addr esses cont ained in t he cur r ent
message.
Figur e 5.5. The GGP message f or mat .
For each dist ance gr oup in t he message, a dist ance val ue and t he number of net wor ks
t hat can be r eached at t hat dist ance ar e pr ovided, f ol l owed by al l t he net wor k addr ess
ident if icat ions. Accor ding t o t he GGP st andar d, not al l t he dist ances need t o be
r epor t ed, but t he mor e inf or mat ion suppl ied, t he mor e usef ul t he message is t o each
gat eway.
GGP does not deal wit h f ul l Int er net addr esses specif ical l y, so t he host por t ion of t he
addr ess does not necessar il y have t o be incl uded in t he addr ess, al t hough t he net wor k
addr ess is al ways pr ovided. This can r esul t in dif f er ent l engt hs of addr esses in t he
ident if icat ion f iel d (8, 16, or 24 bit s, depending on t he t ype of addr ess).
Thr ee ot her f or mat s ar e used wit h GGP messages, as shown in Figur e 5.6. The
acknowl edgment message uses t he Type f iel d t o indicat e whet her t he message is a
posit ive acknowl edgment (t ype is set t o 2) or a negat ive acknowl edgment (t ype is set t o
10) . The sequence number , as ment ioned ear l ier t oday, is used t o ident if y t he message t o
which t he acknowl edgment appl ies.
Figur e 5.6. Ot her GGP message f or mat s.
The echo r equest and echo r epl y f or mat s ar e passed bet ween gat eways t o inf or m t he
gat eways of st at us changes and t o ensur e t he gat eway is up. An echo r equest has t he
Type f iel d set t o t he val ue 8, wher eas an echo r epl y has t he Type f iel d set t o a val ue of
0. Because t he addr ess of t he sending gat eway is embedded in t he IP header , it is not
dupl icat ed in t he GGP message. The r emaining 24 bit s of t he message ar e unused.
The net wor k int er f ace st at us message is used by a gat eway t o ensur e t hat it is abl e t o
send and r eceive messages pr oper l y. This t ype of message can be sent t o t he or iginat ing
gat eway it sel f , wit h t he t ype f iel d set t o a val ue of 9 and t he IP addr ess in t he header
set t o t he net wor k int er f ace's addr ess.
The External Gateway Protocol (EGP)
As ment ioned ear l ier , an EGP is used t o t r ansf er inf or mat ion bet ween non-cor e
neighbor ing gat eways. Non-cor e gat eways cont ain compl et e det ail s about t heir
immediat e neighbor s and t he machines at t ached t o t hem, but t hey l ack inf or mat ion
about t he r est of t he net wor k. Cor e gat eways know about al l t he ot her cor e gat eways
but of t en l ack t he det ail s of t he machines beyond a gat eway.
EGP is usual l y r est r ict ed t o inf or mat ion wit hin t he gat eway's aut onomous syst em. This
pr event s t oo much inf or mat ion f r om passing t hr ough t he net wor ks, especial l y when
most of t he inf or mat ion t hat r el at es t o ext er nal aut onomous syst ems woul d be
unusabl e t o anot her gat eway. EGP t her ef or e imposes r est r ict ions on t he gat eways
about t he machines EGP passes r out ing inf or mat ion about .
Neighbors and EGP
Because EGP was devel oped t o enabl e r emot e syst ems t o exchange r out ing inf or mat ion
and st at us messages, t he pr ot ocol is heavil y based in r equest s or commands f ol l owed by
r epl ies. The f our EGP commands and t heir possibl e r esponses ar e shown in Tabl e 5.2.
Tabl e 5.2. EGP commands.
Command Name Command Description Response Name Response Description
Request
Request t hat a neighbor
become a gat eway
Conf ir m/Ref use
Agr ee or r ef use t he
r equest
Cease
Request t he t er minat ion
of a neighbor
Cease-Ack Agr ee t o t er minat ion
Hel l o
Request conf ir mat ion of
r out ing t o neighbor
(neighbor r eachabil it y)
IHU Conf ir ms t he r out ing
Pol l
Request t hat t he neighbor
pr ovide net wor k
inf or mat ion (net wor k
r eachabil it y)
Updat e
Pr ovides net wor k
inf or mat ion
To under st and Tabl e 5.2 pr oper l y, you must under st and t he concept of neighbor t o an
int er net wor k. Gat eways ar e neighbor s if t hey shar e t he same subnet wor k. They might be
gat eways t o t he same net wor k (such as t he Int er net ) or wor k wit h dif f er ent net wor ks.
When t he t wo want t o exchange inf or mat ion, t hey must f ir st est abl ish communicat ions
bet ween each ot her ; t he t wo gat eways ar e essent ial l y agr eeing t o exchange r out ing
inf or mat ion. This pr ocess is cal l ed neighbor acquisition.
Neighbor doesn't mean t he net wor ks have t o be next t o each ot her . They ar e connect ed
by a gat eway, but t he net wor ks can be on dif f er ent cont inent s. The t er m neighbor has
t o do wit h connect ions, not geogr aphy.
The pr ocess of becoming neighbor s is f or mal , because one gat eway might not want t o
become a neighbor at t hat par t icul ar t ime (f or any number of r easons, but usual l y
because t he gat eway is busy). It begins wit h a Request , which is f ol l owed by eit her an
accept ance (Conf ir m) or r ef usal (Ref use) f r om t he second machine. If t he t wo gat eways
ar e neighbor s, eit her can br eak t he r el at ionship wit h a Cease message.
Af t er t wo gat eways become neighbor s, t hey assur e each ot her t hat t hey ar e st il l in
cont act by occasional l y sending a Hel l o message, t o which t he second gat eway r esponds
wit h an IHU (I Hear d You) message as soon as possibl e. These Hel l o/IHU messages can be
sent at any t ime. Wit h sever al gat eways invol ved on a net wor k, t he number of Hel l o
messages can become appr eciabl e as t he gat eways cont inue t o r emain in t ouch. This
pr ocess is cal l ed neighbor reachability.
The ot her message pair sent by EGP is net wor k r eachabil it y, in which case one gat eway
sends a Pol l message and expect s an Updat e message in r esponse. The r esponse cont ains a
l ist of net wor ks t hat can be r eached t hr ough t hat gat eway, wit h a number
r epr esent ing t he number of hops t hat must be made t o r each t he net wor ks. By assembl ing
t he Updat e messages f r om dif f er ent neighbor s, a gat eway can decide t he best r out e t o
send a dat agr am.
Final l y, an er r or message is r et ur ned whenever t he gat eway cannot under st and an
incoming EGP message.
EGP Messages
The l ayout of t he dif f er ent messages used by EGP ar e shown in Figur e 5.7. The f iel ds
have t he f ol l owing meanings:
G The Ver sion f iel d hol ds t he EGP ver sion number of t he sending machine (t he
cur r ent ver sion is 2).
G The Type f iel d ident if ies t he t ype of EGP messages. Ther e ar e t en message t ypes in
EGP.
G The Code f iel d cont ains a val ue t hat ident if ies t he subt ype of t he message.
G The St at us f iel d is used wit h t he Type and Code f iel ds t o r ef l ect t he cur r ent
st at us of t he gat eway's st at e.
G The Checksum is cal cul at ed f or t he EGP message in t he same manner as ot her
TCP/IP header s.
G The Syst em Number is an ident if icat ion of t he aut onomous syst em t hat t he sending
gat eway bel ongs t o.
G The Sequence Number of t he message is an incr ement ing count er f or each message,
al so used t o ident if y a r epl y t o a pr evious message.
Figur e 5.7. EGP message f or mat .
The Reason f iel d of t he Er r or message can cont ain one of t he f ol l owing int eger s:
0Unspecif ied er r or
1Bad EGP header
2Bad EGP dat a f iel d
3Reachabil it y inf or mat ion not avail abl e
4Excessive pol l ing
5No r esponse r eceived t o a pol l
Thr ough a combinat ion of t he message Type, Code, and St at us f iel ds, t he pur pose and
meaning of t he EGP message can be mor e accur at el y det er mined. Tabl e 5.3 shows al l
codes and st at us val ues.
Tabl e 5.3. EGP messages.
Type Description Code Description Status Description
1 Updat e 0 0 Indet er minat e
1 Up
2 Down
128 Unsol icit ed
2 Pol l 0 0 Indet er minat e
1 Up
2 Down
3 Neighbor Acquisit ion 0 Request 0 Not specif ied
1 Conf ir m 1 Act ive mode
2 Ref use 2 Passive mode
3 Cease 3 Insuf f icient Resour ces
4 Cease-Ack 4 Pr ohibit ed
5 Shut t ing Down
6 Par amet er Pr obl em
7 Pr ot ocol Viol at ion
5 Neighbor Reachabil it y 0 Hel l o 0 Indet er minat e
1 I Hear d You 1 Up
2 Down
8 Er r or 0 0 Indet er minat e
1 Up
2 Down
128 Unsol icit ed
The St at us f iel d can indicat e whet her a gat eway is up or down. In t he down st at e, t he
gat eway does not per f or m any r out ing. The Neighbor Acquisit ion st at us indicat or can
show whet her t he machine is act ive or passive. When passive, t he gat eway does not
gener at e any Hel l o commands, but it r esponds t o t hem. At l east one neighbor has t o be
in t he act ive st at e t o issue t he Hel l os.
When a l ist of net wor ks and t heir dist ances must be added t o an EGP header , it is done in
t he f or mat shown in Figur e 5.8. The number of dist ances in t he l ist is specif ied, f ol l owed
by ent r ies wit h t he same f or mat giving t he dist ance (number of hops) t o t he gat eway, t he
number of net wor ks t hat can be r eached t hr ough t hat gat eway, and t he net wor k
addr esses. The number of int er nal and ext er nal gat eways in t he EGP header t el l s t he
gat eway how many ent r ies ar e in t he l ist .
Figur e 5.8. Rout ing inf or mat ion in an EGP header .
Using EGP, gat eways can updat e each ot her and keep t heir r out ing t abl es cur r ent . A
simil ar scheme is used f or IGP, al t hough t he messages can be cust om-designed by t he
net wor k manager and appl icat ion devel opment t eam because t hey ar e not t r ansmit t ed
over t he Int er net .
Neighbor Acquisition Messages
A Neighbor Acquisit ion message (Request , Conf ir m, and Ref use Acquisit ion message t ypes)
is sent when a neighbor is being checked f or acquisit ion. The same message f or mat is used
whet her t he par t icul ar message is a r equest , a conf ir mat ion, or a r ef usal .
The t ype is set t o a val ue of 3 t o indicat e t hat t he message is a neighbor acquisit ion, and
t he Code f iel d pr ovides t he det ail s as t o t he t ype of Acquisit ion message, as shown in
Tabl e 5.4.
Tabl e 5.4. EGP Acquisit ion message codes.
Code Description
0 Request Acquisit ion
1 Conf ir m Acquisit ion
2 Ref use Acquisit ion
3 Cease
4 Cease Acknowl edgment
The St at us f iel d in t he Acquisit ion message header is set t o one of eight possibl e val ues
and is used t o pr ovide f ur t her inf or mat ion about t he r equest . The val id St at us f iel d
val ues ar e shown in Tabl e 5.5.
Tabl e 5.5. EGP Acquisit ion message St at us val ues.
Status Description
0 Unspecif ied; used when no ot her code is appl icabl e
1 Act ive; indicat es an act ive st at us mode
2 Passive; indicat es a passive st at us mode
3 Insuf f icient r esour ces avail abl e
4 Administ r at ivel y pr ohibit ed
5
Going down eit her because of oper at or int er vent ion or expir at ion of t he t 3
t imer
6 Par amet er er r or wit h incoming message
7
Pr ot ocol viol at ion in incoming message or r esponse message is incompat ibl e wit h
cur r ent machine st at e
The EGP Neighbor Acquisit ion message adds t wo new f iel ds t o t he basic EGP message
header . The 16-bit Hel l o Int er val f iel d specif ies t he minimum int er val bet ween Hel l o
command pol l ings, in seconds. The 16-bit Pol l Int er val f iel d specif ies t he minimum
int er val bet ween Pol l command pol l ings, again in seconds.
Neighbor Reachability Messages
The Neighbor Reachabil it y messages ar e used t o ensur e t hat a neighbor t hat was
pr eviousl y acquir ed is st il l act ive and communicat ing. No ext r a f iel ds ar e added t o t he
basic EGP message f or mat shown in Figur e 5.7.
The Type f iel d is set t o a val ue of 5, but t he Code f iel d has a val ue of eit her 0 f or a
Hel l o message or 1 f or an IHU (I Hear d You) r esponse. The St at us f iel d can have one of
t hr ee val ues, shown in Tabl e 5.6.
Tabl e 5.6. EGP Neighbor Reachabil it y St at us f iel d val ues.
Status Description
0 Indet er minat e; used when no ot her code is appl icabl e
1 Neighbor is in an up st at e
2 Neighbor is in a down st at e
Poll Messages
The Pol l messages ar e used t o r equest net wor k r eachabil it y inf or mat ion. An ext r a t wo
f iel ds ar e added t o t he basic EGP message f or mat , which ar e a 16-bit f iel d r eser ved f or
f ut ur e use and a 32-bit IP Sour ce Net wor k f iel d.
The Pol l messages have t he Type f iel d set t o a val ue of 2 and t he Code f iel d set t o a
val ue of 0. The St at us f iel d is set t o one of t he same t hr ee val ues used in t he
Reachabil it y message, shown in Tabl e 5.6.
The 16-bit Reser ved f iel d at t ached t o t he end of t he basic EGP message f or mat is ignor ed
in t he cur r ent ver sions of EGP. A 32-bit IP Sour ce Net wor k f iel d is used t o specif y t he IP
addr ess of t he net wor k about which t he gat eway is r equest ing r eachabil it y
inf or mat ion.
Update Messages
Updat e messages ar e sent as a r epl y t o a Pol l message and pr ovide inf or mat ion about
net wor k r eachabil it y. The f or mat of t he Updat e message is shown in Figur e 5.9 and is
simil ar t o t he GGP f or mat discussed ear l ier .
Figur e 5.9. EGP Updat e message f or mat .
The Type of an Updat e message is set t o 1, and t he Code is set t o 0. The St at us f iel d is set
t o one of t he val ues shown in Tabl e 5.7. (The val ues ar e t he same as t hose f or
Reachabil it y and Pol l messages except f or t he addit ion of one val ue.)
Tabl e 5.7. EGP Updat e message St at us f iel d val ues.
Status Description
0 Indet er minat e; used when no ot her code is appl icabl e
1 Neighbor is in an up st at e
2 Neighbor is in a down st at e
128 Unsol icit ed message
Af t er t he f amil iar EGP header inf or mat ion ar e t hr ee new f iel ds. The number of int er nal
gat eways and number of ext er nal gat eways f iel ds specif y t he number of int er ior and
ext er ior gat eways t hat ar e r epor t ed in t he message, r espect ivel y. The IP Sour ce
Net wor k Addr ess f iel d cont ains t he IP addr ess of t he net wor k t o which t he inf or mat ion
r el at es.
Fol l owing t he t hr ee gat eway summar ies and t he usual header ar e one or mor e set s of
inf or mat ion about each gat eway t he cur r ent syst em is sending inf or mat ion about . These
ar e cal l ed gat eway bl ocks because each set of f iel ds r ef er s t o one gat eway. The f ir st
f iel d is t he gat eway's IP addr ess. The Number of Dist ances f iel d pr ovides t he number of
dist ances t hat ar e r epor t ed in t he gat eway bl ock and t he number of net wor ks t hat l ie
at t hat dist ance. Then, f or each dist ance specif ied, t he IP net wor k addr ess of each
net wor k is pr ovided. Many bl ocks of gat eway inf or mat ion can be pr ovided in an Updat e
message.
Error Messages
The f inal EGP message is t he Er r or message, which has t he same f or mat as t he basic EGP
message, wit h t wo f iel ds at t ached. The 16-bit f ir st f iel d is r eser ved. Fol l owing t his is a
96-bit f iel d t hat cont ains t he f ir st 96 bit s of t he message t hat gener at ed t he er r or .
EGP to GGP Messages
Cor e gat eways use GGP, and non-cor e gat eways use EGP, so t her e must be some met hod
f or t he t wo t o communicat e wit h each ot her t o f ind out about hidden machines and
net wor ks t hat l ie beyond t heir r out ing t abl es. This can be shown by Figur e 5.10, wher e
gat eway A is a cor e gat eway l eading f r om t he int er net wor k t o a net wor k t hat has non-
cor e gat eways l eading t o t wo ot her net wor ks. Anot her gat eway on t he int er net wor k
does not have inf or mat ion about t he net wor ks and gat eways past t he cor e gat eway,
unl ess specif ical l y updat ed about t hem t hr ough a r equest .
Figur e 5.10. Cor e and non-cor e gat eways.
The Int er net uses a met hod by which any aut onomous (non-cor e) gat eway can send
r eachabil it y inf or mat ion t o ot her syst ems, which must al so go t o at l east one cor e
gat eway. If t her e is a l ar ger aut onomous net wor k, one gat eway usual l y assumes t he r esponsibil it y f or handl ing t his r eachabil it y inf or mat ion. In Figur e 5.10, gat eway A is r esponsibl ef or sending inf or mat ion about t he t hr ee net wor ks t hat l ead f r omit , as wel l as t he t wo non-cor e gat eways. EGPs use a pol l ing pr ocess t o keep t hemsel ves awar e of t heir neighbor s as t hey become -ive or go down, and t o exchange r out ing and st at us inf or mat ion wit h al l t heir neighbor s. EGP is al so a st at e-dr iven pr ot ocol , meaning t hat it depends on a st at e t abl e cont aining val ues t hat r ef l e-gat eway condit ions and a set of oper at ions t hat must be per f or med when a st at e t abl eent r y changes. Ther e ar e f ive st at es, as shown in Tabl e5.8.
Tabl e5.8. EGP st at es.State Description 0 Idl e1 Acquisit ion2 Down 3 Up 4 Cease
The meanings of each of t hese EGP st at es f ol l ow: G An idl est at e means t he gat eway is not invol ved in any a-ivit y and has no r esour ces al l ocat ed t o it . It usual l y r esponds t o a message t o init ial ize it sel f but ignor es al l ot her messages unl ess it swit ches t o eit her t he down or acquisit ion st at es. G An acquisit ionst at e enabl es a gat eway t o t r ansmit messages but not -as a f ul l messaging gat eway. It can r eceive messages and change t o eit her down or idl e st at es. G The down st at e is when t he gat eway is not oper at ional as f ar as pol l ing oper at ions ar e concer ned. Messages ar e neit her r eceived nor gener at ed. G The up st at e is used whenever a gat eway is pr ocessing and r esponding t oal l EGP messages it r eceives and can t r ansmit messages. G A gat eway is in cease st at e when t he gat eway ceases al l updat ing oper at ions but can st il l send and r eceive Cease and Cease Acknowl edgment messages.
Al l EGP messages f al l int o one of t hr ee cat egor ies: commands, r esponses, or indicat ions.
A command usual l y r equir es an act ion t o be per f or med, wher eas a r esponse is a r epl y t o a
command t o per f or m some act ion. An indicat ion shows cur r ent st at us. Command-r esponse
signal s ar e shown in Tabl e 5.9.
Tabl e 5.9. EGP commands and t heir r esponses.
Command Response
Request Conf ir m
Ref use none
Er r or none
Cease Cease Ack
Er r or none
Hel l o IHU (I Hear d You)
Er r or none
Pol l Updat e
Er r or none
EGP State Variables and Timers
As ment ioned ear l ier , EGP is st at e-dr iven, which means t hat t he cur r ent st at e of t he
syst em depends on t he l ast message r eceived, or t he condit ion of one of t he sof t war e
t imer s. EGP maint ains a st at e t abl e wit h sever al par amet er s t hat can be r ef er enced t o
det er mine act ions. These val ues usual l y r ef er t o del ays bet ween sending or r eceiving
messages of a specif ic t ype. In addit ion, a set of t imer s is maint ained f or ensur ing t hat
int er val s bet ween event s ar e r easonabl e. The EGP par amet er s and t imer s ar e shown in
Tabl e 5.10, using t he names empl oyed in t he RFC t hat def ines EGP.
Tabl e 5.10. EGP par amet er s and t imer s.
Name Description
M Hel l o pol l ing mode.
P1
Minimum int er val accept abl e bet ween successive r eceived Hel l o commands.
Def aul t is 30 seconds.
P2
Minimum int er val accept abl e bet ween successive r eceived Pol l commands.
Def aul t is 120 seconds.
P3
Int er val bet ween Request or Cease command r et r ansmissions. Def aul t is 30
seconds.
P4
Int er val dur ing which t he st at e var iabl es ar e maint ained wit hout r eceiving an
incoming message when in t he up or down st at e. Def aul t is one hour .
P5
Int er val dur ing which t he st at e var iabl es ar e maint ained wit hout r eceiving an
incoming message when in t he cease or acquisit ion st at e. Def aul t is 2 minut es.
R Receive sequence number .
S Send sequence number .
T1 Int er val bet ween Hel l o command r et r ansmissions.
T2 Int er val bet ween Pol l command r et r ansmissions.
T3 Int er val dur ing which r eachabil it y at t empt s ar e count ed.
t 1 Ret r ansmission t imer f or Request , Hel l o, and Cease messages.
t 2 Ret r ansmission t imer f or Pol l messages.
t 3 Abor t t imer .
Many of t he st at e par amet er s ar e set dur ing t he init ial est abl ishment of a connect ion
bet ween neighbor s. The except ions ar e t he P1 t hr ough P5 val ues, which ar e est abl ished
by t he host syst em and ar e not modif ied by t he neighbor s. The send sequence number is
det er mined onl y af t er a message has been r eceived f r om t he ot her gat eway.
A f ul l discussion of t he changes bet ween EGP st at es and t he event s t hat occur when a
st at e change occur s is l onger t han t his book and is not of r el evance t o t his l evel of
discussion. Ther ef or e, t he or iginal RFC shoul d be consul t ed f or f ul l st at e condit ion
inf or mat ion. It is usef ul at t his point simpl y t o be awar e of t he st at e-dr iven nat ur e of
EGP and t o under st and t hat t he st at e can be changed by a message r ecept ion, l ack of a
r epl y t o a message, or expir at ion of a t imer .
Interior Gateway Protocols (IGP)
Ther e ar e sever al IGPs in use, none of which have pr oven t hemsel ves dominant . Usual l y,
t he choice of an IGP is made on t he basis of net wor k ar chit ect ur e and suit abil it y t o t he
net wor k's sof t war e r equir ement s. Ear l ier t oday, RIP and HELLO wer e ment ioned. Bot h
ar e exampl es of IGPs. Toget her wit h a t hir d pr ot ocol cal l ed Open Shor t est Pat h Fir st
(OSPF), t hese IGPs ar e now examined in mor e det ail .
Bot h RIP and HELLO cal cul at e dist ances t o a dest inat ion, and t heir messages cont ain
bot h a machine ident if ier and t he dist ance t o t hat machine. In gener al , messages t end t o
be l ong, because t hey cont ain many ent r ies f or a r out ing t abl e. Bot h pr ot ocol s ar e
const ant l y connect ing bet ween neighbor s t o ensur e t hat t he machines ar e act ive and
communicat ing, which can cause net wor k t r af f ic t o buil d.
The Routing Information Protocol (RIP)
The Rout ing Inf or mat ion Pr ot ocol f ound wide use as par t of t he Univer sit y of
Cal if or nia at Ber kel ey's LAN sof t war e inst al l at ions. Or iginal l y devel oped f r om t wo
r out ing pr ot ocol s cr eat ed at Xer ox's Pal o Al t o Resear ch Cent er , RIP became par t of
UCB's BSD UNIX r el ease, f r om which it became widel y accept ed. Since t hen, many
ver sions of RIP have been pr oduced, t o t he point wher e most UNIX vendor s have t heir
own enhanced RIP pr oduct s. The basics ar e now def ined by an Int er net RFC.
RIP uses a br oadcast t echnol ogy (showing it s LAN her it age). This means t hat t he
gat eways br oadcast t heir r out ing t abl es t o ot her gat eways on t he net wor k at r egul ar
int er val s. This is al so one of RIP's downf al l s, because t he incr eased net wor k t r af f ic and
inef f icient messaging can sl ow net wor ks down compar ed t o ot her IGPs. RIP t ends t o
obt ain inf or mat ion about al l dest inat ions in t he aut onomous syst em t o which t he
gat eways bel ong. Like GGP, RIP is a vect or -dist ance syst em, sending a net wor k addr ess
and dist ance t o t he addr ess in it s messages.
A machine in a RIP-based net wor k can be eit her act ive or passive. If it is act ive, it sends
it s r out ing t abl es t o ot her machines. Most gat eways ar e act ive devices. A passive
machine does not send it s r out ing t abl es but can send and r eceive messages t hat af f ect
it s r out ing t abl e. Most user -or ient ed machines (such as PCs and wor kst at ions) ar e
passive devices. RIP empl oys t he User Dat agr am Pr ot ocol (UDP) f or messaging, empl oying
por t number 520 t o ident if y messages as or iginat ing wit h RIP.
The f or mat of t he RIP messages is shown in Figur e 5.11. The message header is composed of
t hr ee f iel ds f or t he command (set t o 1 if a r equest and 2 if a r esponse), t he ver sion
number of t he RIP pr ot ocol , and an unused r eser ved f iel d. The r est of t he message
cont ains addr ess inf or mat ion. Each set begins wit h an ident if ier of t he f amil y pr ot ocol
used (RIP is not specif ical l y f or t he Int er net 's pr ot ocol s, but if used on t he Int er net t his
val ue is set t o 2) and a set of net wor k IDs. Ther e ar e 96 bit s avail abl e f or t he net wor k
addr ess, of which onl y a maximum of 32 ar e necessar y f or an Int er net addr ess. The l ast
f iel d is a met r ic val ue t hat usual l y ident if ies t he number of hops t o t he net wor k.
Figur e 5.11. RIP message f or mat .
A Request message is usual l y sent t o anot her gat eway when a r out ing updat e is needed.
When a r equest is r eceived, t he syst em examines t he message t o check each net wor k
addr ess pr ovided. If it s r out ing t abl e has a dist ance t o t hat net wor k addr ess, it is pl aced
in t he cor r esponding met r ic f iel d in t he r esponse. If t her e is no ent r y in t he l ocal
r out ing t abl e, no val ue is r et ur ned. One convent ion in common use is t o code t he f amil y
as 1 and t he met r ic f iel d as 16. When t his is r eceived, t he message is int er pr et ed as a
r equest f or t he ent ir e r out ing t abl e.
Each RIP-based machine in t he net wor k maint ains a r out ing t abl e, wit h an ent r y f or
each machine t hat it can communicat e wit h. The t abl e has ent r ies f or t he t ar get 's IP
addr ess, it s dist ance, t he IP addr ess of t he next gat eway in t he pat h t o t he t ar get , a
f l ag t o show whet her t he r out e has r ecent l y been updat ed, and a set of t imer s t hat
cont r ol t he r out e. The dist ance is expr essed as a number of hops r equir ed t o r each t he
t ar get and has a val ue f r om 1 t o 15. If t he t ar get is unr eachabl e, a val ue of 16 is set .
The t imer s invol ved wit h RIP ar e devot ed t o each possibl e r out e in t he r out ing t abl e. A
t ime-out t imer is set when t he r out e is init ial ized and each t ime t he r out e is updat ed. If
t he t imer expir es (t he def aul t set t ing is 180 seconds) bef or e anot her updat e, t he r out e is
consider ed unr eachabl e. A second t imer , cal l ed t he gar bage-col l ect ion t imer , t akes
over af t er t he t ime-out t imer and mar ks when t he r out e is compl et el y expunged f r om
t he r out ing t abl e. The gar bage-col l ect ion t imer has a def aul t val ue of 120 seconds. If a
r equest f or a r out ing updat e is r eceived af t er t he t ime-out t imer has expir ed but bef or e
t he gar bage-col l ect ion t imer has expir ed, t he ent r y f or t hat gat eway is sent but wit h
t he maximum val ue f or t he r out e val ue. Af t er t he gar bage-col l ect ion t imer has expir ed,
t he r out e is not sent at al l .
A r esponse t imer t r igger s a set of messages ever y 30 seconds t o al l neighbor ing machines,
in an at t empt t o updat e r out ing t abl es. These messages ar e composed of t he machine's IP
addr ess and t he dist ance t o t he r ecipient machine.
The HELLO Protocol
The HELLO pr ot ocol is used of t en, especial l y wher e TCP/IP inst al l at ions ar e invol ved.
It is dif f er ent f r om RIP in t hat HELLO uses t ime inst ead of dist ance as a r out ing f act or .
This r equir es t he net wor k of machines t o have r easonabl y accur at e t iming, which is
synchr onized wit h each machine. For t his r eason, t he HELLO pr ot ocol depends on cl ock
synchr onizat ion messages.
The f or mat of a HELLO message is shown in Figur e 5.12. The pr imar y header f iel ds ar e as
f ol l ows:
G A checksum of t he ent ir e message
G The cur r ent dat e of t he sending machine
G The cur r ent t ime of t he sending machine
G A t imest amp used t o cal cul at e r ound-t r ip del ays
G An of f set t hat point s t o t he f ol l owing ent r ies
G The number of host s t hat f ol l ow as a l ist
Figur e 5.12. HELLO message f or mat .
Fol l owing t he header ar e sever al ent r ies wit h a del ay est imat e t o t he machine and an
of f set , which is an est imat e of t he dif f er ence bet ween t he sending and r eceiving cl ocks.
The of f set s ar e impor t ant because HELLO is a t ime-cr it ical pr ot ocol , so t he of f set
enabl es cor r ect ion bet ween t imes on dif f er ent machines.
The t imest amp on messages is used by machines t hat t he message passes t hr ough t o
cal cul at e del ays in t he net wor k. In t his manner , a r out ing t abl e based on r eal ist ic
del iver y t imes can be const r uct ed.
The Open Shortest Path First (OSPF) Protocol
The Open Shor t est Pat h Fir st pr ot ocol was devel oped by t he Int er net Engineer ing Task
For ce, wit h t he hope t hat it woul d become t he dominant pr ot ocol wit hin t he Int er net .
In many ways, t he name "shor t est pat h" is inaccur at e in descr ibing t his pr ot ocol 's
r out ing pr ocess (bot h RIP and HELLO use a shor t est pat h met hodRIP based on dist ance
and HELLO on t ime). A bet t er descr ipt ion f or t he syst em woul d be "opt imum pat h," in
which sever al cr it er ia ar e eval uat ed t o det er mine t he best r out e t o a dest inat ion. The
HELLO pr ot ocol is used f or passing st at e inf or mat ion bet ween gat eways and f or passing
basic messages, wher eas t he Int er net Pr ot ocol (IP) is used f or t he net wor k l ayer .
OSPF uses t he dest inat ion addr ess and t ype of ser vice (TOS) inf or mat ion in an IP
dat agr am header t o devel op a r out e. Fr om a r out ing t abl e t hat cont ains inf or mat ion
about t he t opol ogy of t he net wor k, an OSPF gat eway (mor e f or mal l y cal l ed a router in
t he RFC, al t hough bot h t er ms ar e int er changeabl e) det er mines t he shor t est pat h using
cost met r ics, which f act or in r out e speed, t r af f ic, r el iabil it y, secur it y, and sever al ot her
aspect s of t he connect ion. Whenever communicat ions must l eave an aut onomous
net wor k, OSPF cal l s t his ext er nal r out ing. The inf or mat ion r equir ed f or an ext er nal
r out e can be der ived f r om bot h OSPF and EGP.
Ther e ar e t wo t ypes of ext er nal r out ing wit h OSPF. A Type 1 r out e invol ves t he same
cal cul at ions f or t he ext er nal r out e as f or t he int er nal . In ot her wor ds, t he OSPF
al gor it hms ar e appl ied t o bot h t he ext er nal and int er nal r out es. A Type 2 r out e uses
t he OSPF syst em onl y t o cal cul at e a r out e t o t he gat eway of t he dest inat ion syst em,
ignor ing any r out es of t he r emot e aut onomous syst em. This has an advant age in t hat it
can be independent of t he pr ot ocol used in t he dest inat ion net wor k, which el iminat es a
need t o conver t met r ics.
OSPF enabl es a l ar ge aut onomous net wor k t o be divided int o smal l er ar eas, each wit h
it s own gat eway and r out ing al gor it hms. Movement bet ween t he ar eas is over a
backbone, or t he par t s of t he net wor k t hat r out e messages bet ween ar eas. Car e must be
t aken t o avoid conf using OSPF's ar eas and backbone t er minol ogy wit h t hose of t he
Int er net , which ar e simil ar but do not mean pr ecisel y t he same t hing. OSPF def ines
sever al t ypes of r out er s or gat eways:
G An Int er nal Rout er is one f or which al l connect ions bel ong t o t he same ar ea, or
one in which onl y backbone connect ions ar e made.
G A BORDER Rout er is a r out er t hat does not sat isf y t he descr ipt ion of an Int er nal
Rout er (it has connect ions out side an ar ea).
G A Backbone Rout er has an int er f ace t o t he backbone.
G A Boundar y Rout er is a gat eway t hat has a connect ion t o anot her aut onomous
syst em.
OSPF is designed t o enabl e gat eways t o send messages t o each ot her about int er net wor k
connect ions. These r out ing messages ar e cal l ed advertisements, which ar e sent t hr ough
HELLO updat e messages. Four t ypes of adver t isement s ar e used in OSPF:
G A Rout er Links adver t isement pr ovides inf or mat ion on a l ocal r out er 's (gat eway)
connect ions in an ar ea. This message is br oadcast t hr oughout t he net wor k.
G A Net wor k Links adver t isement pr ovides a l ist of r out er s t hat ar e connect ed t o a
net wor k. It is al so br oadcast t hr oughout t he net wor k.
G A Summar y Links adver t isement cont ains inf or mat ion about r out es out side t he
ar ea. It is sent by BORDER r out er s t o t heir ent ir e ar ea.
G An Aut onomous Syst em Ext ended Links adver t isement cont ains inf or mat ion on
r out es in ext er nal aut onomous syst ems. It is used by boundar y r out er s but cover s
t he ent ir e syst em.
OSPF maint ains sever al t abl es f or det er mining r out es, incl uding t he pr ot ocol dat a
t abl e (t he high-l evel pr ot ocol in use in t he aut onomous syst em), t he ar ea dat a t abl e or
backbone dat a t abl e (which descr ibes t he ar ea), t he int er f ace dat a t abl e (inf or mat ion
on t he r out er -t o-net wor k connect ions), t he neighbor dat a t abl e (inf or mat ion on t he
r out er -t o-r out er connect ions), and a r out ing dat a t abl e (which cont ains t he r out e
inf or mat ion f or messages). Each t abl e has a st r uct ur e of it s own, t he det ail s of which
ar e not needed f or t his l evel of discussion. Int er est ed r eader s ar e r ef er r ed t o t he RFC
f or compl et e specif icat ions.
OSPF Packets
As ment ioned ear l ier , OSPF uses IP f or t he net wor k l ayer . The OSPF specif icat ions
pr ovide f or t wo r eser ved mul t icast addr esses: one f or al l r out er s t hat suppor t OSPF
(224.0.0.5) and one f or a designat ed r out er and a backup r out er (224.0.0.6). The IP
pr ot ocol number 89 is r eser ved f or OSPF. When IP sends an OSPF message, it uses t he
pr ot ocol number and a Type of Ser vice (TOS) f iel d val ue of 0. Usual l y, t he IP pr ecedence
f iel d is set higher t han nor mal IP messages, al so.
OSPF uses t wo header f or mat s. The pr imar y OSPF message header f or mat is shown in
Figur e 5.13. Not e t hat t he f iel ds ar e not shown in t heir scal e l engt hs in t his f igur e f or
il l ust r at ive pur poses. The Ver sion Number f iel d ident if ies t he ver sion of t he OSPF
pr ot ocol in use (cur r ent l y ver sion 1). The Type f iel d ident if ies t he t ype of message and
might cont ain a val ue f r om t hose shown in Tabl e 5.11.
Figur e 5.13. OSPF message header f or mat .
Tabl e 5.11. OSPF header Type val ues.
Type Description
1 Hel l o
2 Dat abase descr ipt ion
3 Link st at e r equest
4 Link st at e updat e
5 Link st at e acknowl edgment
The Packet Lengt h f iel d cont ains t he l engt h of t he message, incl uding t he header . The
Rout er ID is t he ident if icat ion of t he sending machine, and t he Ar ea ID ident if ies t he
ar ea t he sending machine is in. The Checksum f iel d uses t he same al gor it hm as IP t o
ver if y t he ent ir e message, incl uding t he header .
The Aut hent icat ion Type (AUType) f iel d ident if ies t he t ype of aut hent icat ion t o be used.
Ther e ar e cur r ent l y onl y t wo val ues f or t his f iel d: 0 f or no aut hent icat ion, and 1 f or a
passwor d. The Aut hent icat ion f iel d cont ains t he val ue t hat is used t o aut hent icat e t he
message, if appl icabl e.
The second header f or mat used by OSPF is f or Link St at e adver t isement s onl y; it is
shown in Figur e 5.14. Al l Link St at e adver t isement s use t his f or mat , which ident if ies
each adver t isement t o al l r out er s. This header mir r or s t he t opol ogic t abl e.
Figur e 5.14. OSPF Link St at e adver t isement header f or mat .
The Link St at e Age f iel d cont ains t he number of seconds since t he Link St at e
adver t isement or iginat ed. The Opt ions f iel d cont ains any IP Type of Ser vice (TOS)
f eat ur es suppor t ed by t he sending machine. The Link St at e Type ident if ies t he t ype of
l ink adver t isement , using one of t he val ues shown in Tabl e 5.12. The val ue in t he Link
St at e Type f iel d f ur t her def ines t he f or mat of t he adver t isement .
Tabl e 5.12. Link St at e adver t isement header Type val ues.
Value Description
1 Rout er l inks (r out er t o ar ea)
2 Net wor k l inks (r out er t o net wor k)
3 Summar y l ink (inf or mat ion on t he IP net wor k)
4 Summar y l ink (inf or mat ion on aut onomous syst em BORDER r out er )
5 AS ext er nal l ink (ext er nal t o aut onomous syst em)
The Link St at e ID f iel d ident if ies which por t ion of t he int er net wor k is descr ibed in t he
adver t isement . The val ue depends on t he Link St at e Type f iel d and can cont ain IP
addr esses f or net wor ks or r out er IDs. The Adver t ising Rout er f iel d ident if ies t he
or iginat ing r out er . The Link St at e Sequence Number is an incr ement ing number used t o
pr event ol d or dupl icat e packet s f r om being int er pr et ed. The Checksum f iel d uses an IP
al gor it hm f or t he ent ir e message, incl uding t he header . Final l y, t he Lengt h f iel d
cont ains t he size of t he adver t isement , incl uding t he header .
HELLO Packets
Bot h t ypes of OSPF header s ar e f ur t her encapsul at ed by t he HELLO pr ot ocol , which is
used f or messaging bet ween neighbor ing r out er s. The inf or mat ion in t he HELLO header
set s t he par amet er s f or t he connect ion. The ent ir e HELLO packet f or mat is shown in
Figur e 5.15.
Figur e 5.15. OSPF HELLO packet f or mat .
Af t er t he OSPF header is t he Net wor k Mask f iel d, which is dependent on t he int er f ace.
The Hel l o Int er val is t he number of seconds bet ween subsequent Hel l o packet s f r om t he
same r out er . The Opt ions f iel d is f or IP's Type of Ser vice suppor t ed val ues. The Rout er
Pr ior it y f iel d def ines whet her t he r out er can be designat ed as a backup. If t he f iel d has
a 0 val ue, t he r out er cannot be def ined as a backup. The Dead Int er val is t he number of
seconds bef or e a r out er is decl ar ed t o be down and unavail abl e. The Designat ed and
Backup Rout er f iel ds hol d t he addr esses of t he designat ed and backup r out er s, if t her e
ar e any. Final l y, each neighbor has a set of f iel ds t hat cont ain t he addr ess of each
r out er t hat has r ecent l y (wit hin t he t ime specif ied by t he Dead Int er val ) sent Hel l o
packet s over t he net wor k.
When t his t ype of message is r eceived by anot her r out er and it has been val idat ed as
cont aining no er r or s, t he neighbor inf or mat ion can be pr ocessed int o t he neighbor dat a
t abl e.
Anot her message t hat is used t o init ial ize t he dat abase of a r out er is t he dat abase
descr ipt ion packet . It cont ains inf or mat ion about t he t opol ogy of t he net wor k (eit her in
whol e or in par t ). To pr ovide dat abase descr ipt ion packet ser vice, one r out er is set as t he
mast er , and t he ot her is t he sl ave. The mast er sends t he dat abase descr ipt ion packet s,
and t he sl ave acknowl edges t hem wit h dat abase descr ipt ion r esponses.
The f or mat of t he dat abase descr ipt ion packet is shown in Figur e 5.16. Af t er t he OSPF
header is a set of unused bit s, f ol l owed by t hr ee 1-bit f l ags. When t he I (init ial ) bit is set
t o 0, it indicat es t hat t his packet is t he f ir st in a ser ies of packet s. The M (mor e) bit , when
set t o 1, means t hat mor e dat abase descr ipt ion packet s f ol l ow t his one. The MS
(mast er /sl ave) bit indicat es t he mast er /sl ave r el at ionship. When it has a val ue of 1 it
means t hat t he r out er t hat sent t he packet is t he mast er . A 0 indicat es t hat t he sending
machine is t he sl ave. The Dat a Descr ipt or Sequence Number is an incr ement ing count er .
The r est of t he packet cont ains Link St at e adver t isement s as seen in Figur e 5.14.
Figur e 5.16. The dat abase descr ipt ion packet l ayout .
Link State Request and Update Packets
The Link St at e Request packet asks f or inf or mat ion about a t opol ogical t abl e f r om a
dat abase, wher eas t he Updat e packet can pr ovide t opol ogical inf or mat ion of t he t ypes
shown in Tabl e 5.11. The Request packet is usual l y sent when an ent r y in t he r out er 's
t opol ogical t abl e is cor r upt ed, missing, or out of dat e. The f or mat of t he Link St at e
Request packet is shown in Figur e 5.17. The Link St at e Request packet cont ains t he OSPF
header and a bl ock of t hr ee r epeat ing f iel ds f or t he Link St at e Type, Link St at e ID, and
Adver t ising Rout er .
Figur e 5.17. OSPF Link St at e Request packet f or mat .
The Link St at e Updat e packet has f our f or mat s, depending on t he l ink st at e t ype: r out er
l inks, net wor k l inks, summar y l inks, or aut onomous syst ems ext er nal l inks. The Rout er
Links adver t isement packet is sent t o neighbor s per iodical l y and cont ains f iel ds f or each
r out er l ink and t he t ype of ser vice pr ovided in each l ink, as shown in Figur e 5.18.
Figur e 5.18. OSPF Rout er Links adver t isement packet f or mat .
Af t er t he OSPF header and t he Link St at e adver t isement header ar e t wo singl e bit f l ags
sur r ounded by 6- and 8-bit unused f iel ds. The E (ext er nal ) f l ag, when set t o 1, indicat es
t hat t he r out er is an aut onomous syst ems (AS) boundar y r out er . The B (bor der ) f l ag,
when set t o 1, indicat es t hat t he r out er is an ar ea BORDER r out er . Fol l owing t he
unused 8-bit ar ea is a f iel d f or t he number of l inks (adver t isement s) in t he message.
Fol l owing t his, t he l inks ar e pr ovided in sequence, one l ink t o a bl ock.
Each Link St at e adver t isement bl ock in t he Rout er Links adver t isement packet has a
f iel d f or t he Link ID (t he t ype of r out er , al t hough t he val ue is dependent on t he Type
f iel d l at er in t he bl ock), t he Link Dat a (whose val ue is an IP addr ess or a net wor k mask,
depending on t he Type f iel d's set t ing), t he Type f iel d (a val ue of 1 indicat es a connect ion
t o anot her r out er , 2 a connect ion t o a t r ansit net wor k, and 3 a connect ion t o a st ub
net wor k), and t he Number of TOS f iel d, which shows t he number of met r ics f or t he l ink
(at l east one must be pr ovided, which is cal l ed TOS 0). Then, a r epeat ing bl ock is
appended f or each TOS, pr oviding t he t ype and t he met r ic.
The ot her t hr ee f or mat s avail abl e ar e t he Net wor k Links adver t isement , Summar y Links
adver t isement , and Aut onomous Syst ems (AS) Ext er nal Links adver t isement . The f or mat s
of t hese adver t isement s ar e shown in Figur e 5.19. The f iel ds have al l been descr ibed
ear l ier in t his sect ion.
Figur e 5.19. OSPF Net wor k, Summar y, and AS Links adver t isement l ayout s.
The l ast packet invol ved in OSPF is t he Link St at e acknowl edgment packet , which is
r equir ed when a Link St at e adver t isement has been r eceived cor r ect l y. The l ayout of
t he acknowl edgment packet is shown in Figur e 5.20. The f iel ds f ol l owing t he OSPF
header ar e f or t he Link St at e Type, Link ID, Adver t ising Rout er ID, Link St at e Sequence
Number , Link St at e Checksum val ue, and Link St at e Age, al l of which have been
ment ioned ear l ier .
Figur e 5.20. Link St at e acknowl edgment packet l ayout .
Summary
Today I l ooked at t he gat eway pr ot ocol s used wit hin t he TCP/IP f amil y specif ical l y, as
wel l as t hose in gener al use on t he Int er net and most net wor ks. Gat eways ar e a
cr it ical component f or f or war ding inf or mat ion f r om one net wor k t o anot her . Wit hout
gat eways, each machine on t he net wor k woul d r equir e a f ul l map of ever y ot her
machine on t he int er net wor k.
As I have shown, t her e ar e sever al pr ot ocol s of impor t ance, depending on t he r ol e of t he
gat eway. I al so l ooked at t he use of br idges, r out er s, and br out er s in a net wor k, and t he
r ol e t hat each of t hese can pl ay. Wit h t his mat er ial , I can l eave t he subject of
gat eways. Except f or some message passing and administ r at ion mat er ial , you now know
al l you need about gat eway pr ot ocol s used wit h TCP/IP.
Q&A
What is a boundar y gat eway?
A boundar y gat eway sit s bet ween t wo net wor ks wit hin a l ar ger int er net wor k, as woul d
be f ound in a l ar ge cor por at ion. The boundar y gat eways mar k t he edges (or boundar ies)
of each LAN, passing message t o ot her LANs wit hin t he l ar ger int er net wor k. Boundar y
gat eways do not communicat e wit h t he net wor ks out side t he or ganizat ion. This t ask is
per f or med by ext er ior gat eways.
How ar e sequence number s used t o cont r ol st at us messages wit hin GGP? Expl ain
f or bot h t he sending and r eceiving gat eways.
The sending gat eway sends packet s wit h an incr ement ing sequence number . The
dest inat ion gat eway r eceives each packet and echoes back t he sequence number in a
message. If t he dest inat ion gat eway r eceives t he next packet wit h a sequence number
t hat does not f ol l ow t he one l ast r eceived, an er r or message is r et ur ned t o t he sender
wit h t he sequence number of t he l ast packet in it . If t he sequence number is cor r ect , an
acknowl edgment is sent . As t he sending gat eway r eceives packet s back f r om t he
dest inat ion, it compar es t he sequence number in t he packet t o it s own int er nal count er .
If t he sequence number in t he dest inat ion machine's packet does not mat ch, t he packet
t hat woul d have been next in sequence f r om t he l ast cor r ect l y r eceived packet is
r esent .
What is a cor e gat eway?
A cor e gat eway is one t hat r esides as an int er f ace bet ween a net wor k and t he
int er net wor k. A non-cor e gat eway is bet ween t wo LANs t hat ar e not connect ed t o t he
l ar ger int er net wor k.
Pr ot ocol conver sion t akes pl ace in which of t he f ol l owing: gat eways, r out er s,
br idges, or br out er s?
Gat eways per f or m pr ot ocol conver sion. They have t o because t hey can join t wo
dissimil ar net wor k t ypes. Some r ecent r out er s and br out er s ar e capabl e of pr ot ocol
conver sion.
What ar e t he t hr ee t ypes of r out ing t abl e?
Rout ing t abl es can be f ixed (a t abl e t hat is modif ied manual l y ever y t ime t her e is a
change), dynamic (one t hat modif ies it sel f based on net wor k t r af f ic), or f ixed cent r al
(one downl oaded at int er val s f r om a cent r al r eposit or y, which can be dynamic).
Quiz
1. Def ine t he r ol e of gat eways, r out er s, br idges, and br out er s.
2. What is a packet -swit ched net wor k?
3. What is t he dif f er ence bet ween int er ior and ext er ior neighbor gat eways?
4. What ar e t he advant ages and disadvant ages of t he t hr ee t ypes of r out ing t abl es?
5. What is t he HELLO pr ot ocol used f or ?


I Tel net
I Tel net Connect ions
I Tel net Commands
I TN3270
I Fil e Tr ansf er Pr ot ocol (FTP)
I FTP Commands
I FTP Connect ions
I FTP Thir d-Par t y Tr ansf er s
I Anonymous FTP Access
I FTP Ser ver s
I Tr ivial Fil e Tr ansf er Pr ot ocol (TFTP)
I TFTP Commands
I TFTP Packet s
I Simpl e Mail Tr ansf er Pr ot ocol (SMTP)
I SMTP Commands
I The Ber kel ey Ut il it ies
I The host s.equiv and .r host s Fil es
I r l ogin
I r sh
I r cp
I r who
I r upt ime
I r exec
I Summar y
I Q&A
I Quiz
I Wor kshop
6
Telnet and FTP
In t he l ast f ive days you have seen t he ar chit ect ur e of TCP/IP, as wel l as bot h t he
Int er net Pr ot ocol and t he Tr ansmission Cont r ol Pr ot ocol in consider abl e det ail .
Buil ding on t hese t wo pr ot ocol s is a l ayer of appl icat ion-l ayer pr ot ocol s t hat ar e
commonl y associat ed wit h TCP/IP. Today I l ook at t he most common appl icat ion l ayer
pr ot ocol s: Tel net , Fil e Tr ansf er Pr ot ocol (FTP), Tr ivial Fil e Tr ansf er Pr ot ocol (TFTP),
and Simpl e Mail Tr ansf er Pr ot ocol (SMTP), as wel l as a suit e of t ool s cal l ed t he
Ber kel ey r -ut il it ies.
To cover al l f our pr ot ocol s in compl et e det ail woul d r equir e sever al hundr ed pages, so
t oday I examine t he pr ot ocol s' most impor t ant aspect s, incl uding t heir pur poses, t heir
r el at ions t o TCP and IP, t heir cont r ol codes and behavior , and t heir t ypical usage. Each
of t he f our appl icat ion l ayer pr ot ocol s has advant ages t hat make it ideal l y suit ed f or a
par t icul ar pur pose. I hope t hat by t he end of t he day you wil l under st and why t hey ar e
used and how t hey f it int o t he TCP/IP wor l d.
Telnet
The Tel net (t el ecommunicat ions net wor k) pr ogr am is int ended t o pr ovide a r emot e l ogin
or vir t ual t er minal capabil it y acr oss a net wor k. In ot her wor ds, a user on machine A
shoul d be abl e t o l og int o machine B anywher e on t he net wor k, and as f ar as t he user is
concer ned, it appear s t hat t he user is seat ed in f r ont of machine B. The Tel net ser vice is
pr ovided t hr ough TCP's por t number 23 (see Tabl e 4.1 or Appendix D, "Wel l Known Por t
Number s," f or t he TCP por t number s). The t er m Tel net is used t o r ef er t o bot h t he
pr ogr am and t he pr ot ocol t hat pr ovide t hese ser vices.
Tel net was devel oped because at one t ime t he onl y met hod of enabl ing one machine t o
access anot her machine's r esour ces (incl uding har d dr ives and pr ogr ams st or ed t her e)
was t o est abl ish a l ink using communicat ions devices such as modems or net wor ks int o
dedicat ed ser ial por t s or net wor k adapt er s. This is a l it t l e mor e compl icat ed t han might
appear at f ir st gl ance because of t he wide diver sit y of t er minal s and comput er s, each
wit h t heir own cont r ol codes and t er minal char act er ist ics. When dir ect l y connect ed t o
anot her machine, t he machine's CPU must manage t he t r ansl at ion of t er minal codes
bet ween t he t wo, which put s a hef t y l oad on t he CPU. Wit h sever al r emot e l ogins
act ive, a machine's CPU can spend an inor dinat e amount of t ime managing t he
t r ansl at ions. This is especial l y a pr obl em wit h ser ver s t hat can handl e many
connect ions at once: if each had t o be handl ed wit h f ul l t er minal t r ansl at ion, t he
ser ver CPU coul d be bogged down just per f or ming t his f unct ion.
Tel net al l eviat es t his pr obl em by embedding t he t er minal char act er ist ic sequences
wit hin t he Tel net pr ot ocol . When t wo machines communicat e using Tel net , Tel net
it sel f can det er mine and set t he communicat ions and t er minal par amet er s f or t he session
dur ing t he connect ion phase. The Tel net pr ot ocol incl udes t he capabil it y not t o suppor t
a ser vice t hat one end of t he connect ion cannot handl e. When a connect ion has been
est abl ished by Tel net , bot h ends have agr eed upon a met hod f or t he t wo machines t o
exchange inf or mat ion, t aking t he l oad of f t he ser ver CPU f or a sizabl e amount of t his
wor k.
Usual l y, Tel net invol ves a pr ocess on t he ser ver t hat accept s incoming r equest s f or a
Tel net session. On UNIX syst ems, t his pr ocess is cal l ed t el net d. On Windows NT and
ot her PC-based oper at ing syst ems, a Tel net Ser ver pr ogr am is usual l y invol ved. The
cl ient (t he end doing t he cal l ing) r uns a pr ogr am, usual l y cal l ed t el net , t hat at t empt s
t he connect ion t o t he ser ver . A r el at ive of t he t el net pr ogr am is t he pr ogr am r l ogin,
which is common on UNIX machines and which I l ook at l at er t oday; see t he sect ion
t it l ed "The Ber kel ey Ut il it ies."
The r l ogin pr ogr am pr ovides al most ident ical
f unct ional it y t o Tel net and adds suppor t f or t he UNIX
envir onment . Many machines, especial l y UNIX wor kst at ions,
act as bot h cl ient and ser ver simul t aneousl y, enabl ing a user
t o l og int o ot her machines on t he net wor k and ot her user s t o
l og int o t he user 's machine.
Telnet Connections
The Tel net pr ot ocol uses t he concept of a network virtual terminal, or NVT, t o def ine bot h
ends of a Tel net connect ion. Each end of t he connect ion (each NVT) has a l ogical
keyboar d and pr int er . The l ogical pr int er can displ ay char act er s, and t he l ogical
keyboar d can gener at e char act er s. The l ogical pr int er is usual l y a t er minal scr een,
wher eas t he l ogical keyboar d is usual l y t he user 's keyboar d, al t hough it coul d be a f il e
or ot her input st r eam. These t er ms ar e al so used in t he Fil e Tr ansf er Pr ot ocol (FTP) and
Simpl e Mail Tr ansf er Pr ot ocol (SMTP). Figur e 6.1 il l ust r at es t he NVT and l ogical
keyboar d and pr int er .
Figur e 6.1. A net wor k vir t ual t er minal f or Tel net .
The Tel net pr ot ocol t r eat s t he t wo ends of t he connect ion as NVTs. The t wo pr ogr ams
at eit her end (t el net and t el net d f or a UNIX ser ver ) manage t he t r ansl at ion f r om
vir t ual t er minal s t o act ual physical devices. The concept of vir t ual t er minal s enabl es
Tel net t o int er connect t o any t ype of device, as l ong as a mapping is avail abl e f r om t he
vir t ual codes t o t he physical device. One advant age of t his appr oach is t hat some
physical devices cannot suppor t al l oper at ions, so t he vir t ual t er minal does not have
t hose codes. When t he t wo ends ar e est abl ishing t he connect ion, t he l ack of t hese codes
is not ed, and sequences t hat woul d use t hem ar e ignor ed. This pr ocess is
st r aight f or war d: one end asks whet her t he f unct ion is suppor t ed, and t he ot her r epl ies
eit her posit ivel y or negat ivel y. If it is suppor t ed, t he necessar y codes ar e sent . The l ist
of suppor t ed f unct ions is cover ed quickl y in t his manner .
When a connect ion is est abl ished t hr ough Tel net , t el net d (or what ever pr ogr am is
act ing as t he Tel net ser ver ) st ar t s a pr ocess on t he ser ver f or r unning appl icat ions.
Ever y keyst r oke in a Tel net session must go t hr ough sever al dif f er ent pr ocesses, as
shown in Figur e 6.2. Each keyst r oke goes t hr ough t el net , t el net d, and t he appl icat ions
t hat ar e used dur ing t he Tel net session. Some appl icat ions want t o communicat e
t hr ough a t er minal device, so t he r emot e syst em r uns a pseudo-TTY dr iver t hat act s l ike
a t er minal t o t he appl icat ion. If a windowed int er f ace such as X or Mot if is used on t he
host and r emot e machines, t he syst ems must be inst r uct ed t o enabl e windowing
inf or mat ion t o be passed back and f or t h; ot her wise, t he r emot e machine t r ies t o open t he
windows on t he ser ver .
Figur e 6.2. A Tel net connect ion.
To st ar t Tel net , you must pr ovide eit her t he name or t he IP addr ess of t he machine t o be
connect ed wit h. The name can be used onl y if t he syst em has a means of r esol ving t he
name int o it s IP addr ess, such as wit h t he Domain Name Syst em. A por t name can usual l y
be used t o connect t o a specif ic ser vice, but t his is used inf r equent l y. For exampl e, t o
connect t o a machine wit h t he IP addr ess 205.150.89.1, you woul d ent er t his command:
telnet 205.150.89.1
If t he syst em had t he name dar kst ar , which was r esol vabl e int o it s IP addr ess, you coul d
issue t his command:
telnet darkstar
If no name, addr ess, or por t is specif ied, Tel net ent er s it s command mode and wait s f or
specif ic inst r uct ions. When t he connect ion is est abl ished, a user ID and passwor d ar e
r equest ed. You can l og in wit h any user ID t hat is val id on t he r emot e syst em (it does
not have t o be t he same user ID you have on t he l ocal syst em). A t ypical connect ion t o a
UNIX ser ver l ooks l ike t his:
telnet 205.150.89.1
Trying...
Connected to tpci
Escape character is '^]'.
HP-UX tpci A.09.01 A 9000/720 (ttys2)
login: tparker
password: xxxxxxxx
$
As you can see in t he pr eceding code, Tel net t r ied t o connect t o t he r emot e syst em, t ol d
you it was connect ed, t hen set up t he communicat ions par amet er s bet ween t he t wo
syst ems. When t hat was done, t he l ogin pr ompt was displ ayed (as on any UNIX t er minal ),
f ol l owed by a passwor d r equest . If t he l ogin and passwor d ar e enabl ed, t he UNIX shel l
pr ompt (a dol l ar sign) is shown t o indicat e t hat t he r emot e machine is now act ive.
You can use a machine name as par t of t he Tel net command onl y if t he syst em has a
means of r esol ving t he name t o it s IP addr ess. If not , no connect ion is est abl ished,
al t hough Tel net might r emain in command mode. To exit , use Ct r l +D or t he br eak
sequence displ ayed as par t of t he st ar t -up message.
You can ent er Tel net 's command mode at any t ime, usual l y by using t he Ct r l +] key
combinat ion (hol d down Ct r l and pr ess t he r ight br acket key). If you ar e cur r ent l y
connect ed t o an act ive session when you ent er command mode, Tel net wait s f or you t o
issue a command, execut e it , and t hen r et ur n t o t he session aut omat ical l y. Command
mode l et s you ent er commands r el at ive t o t he cl ient (t he machine you ar e physical l y in
f r ont of ) inst ead of t he ser ver . You might need t o do t his t o change dir ect or ies or r un a
l ocal appl icat ion, f or exampl e.
Once t he connect ion is successf ul l y est abl ished, your session behaves as t hough you
wer e on t he r emot e machine, wit h al l val id commands of t hat oper at ing syst em. Al l
inst r uct ions ar e r el at ive t o t he ser ver , so a dir ect or y command shows t he cur r ent
dir ect or y on t he ser ver , not t he cl ient . To see t he cl ient 's dir ect or y, you woul d have t o
ent er command mode. A sampl e Tel net l ogin and l ogout session, cal l ing f r om one UNIX
wor kst at ion (mer l in) t o a ser ver (t pci_hpws4, a name t hat can be r esol ved by t he name
ser ver ) f ol l ows:
merlin> telnet tpci_hpws4
Trying...
Connected to tpci_hpws4.
Escape character is '^]'.
HP-UX tpci_hpws4 A.09.01 A 9000/720 (ttys2)
login: tparker
password: xxxxxxxx
tpci_hpws4-1> pwd
/u1/tparker
tpci_hpws4-2> cd docs
tpci_hpws4-3> pwd
/u1/tparker/docs
tpci_hpws4-2> <Ctrl+d>
Connection closed by foreign host.
merlin>
Once you ar e connect ed t o t he r emot e machine, t he session behaves exact l y as if you
wer e on t hat machine. To l og out of t he r emot e session, simpl y issue t he l ogout command
(in t he pr evious exampl e, t he UNIX Ct r l +D combinat ion), and you ar e r et ur ned t o your
l ocal machine. The t el net pr ogr am is usef ul when you ar e on an under -power ed machine
or t er minal and you want t o use anot her machine's pr ocessing capabil it ies, or if anot her
machine has a par t icul ar t ool t hat you don't want t o l oad on your l ocal machine.
Tel net ut il it ies ar e avail abl e f or many dif f er ent oper at ing syst ems. Figur e 6.3 shows a
Windows f or Wor kgr oups Tel net appl icat ion (par t of a l ar ger TCP/IP appl icat ion suit e
f r om Net Manage cal l ed Chamel eonNFS, which I l ook at in much mor e det ail on Day 10,
"Set t ing Up a Sampl e TCP/IP Net wor k: DOS and Windows Cl ient s") l ogging int o an SCO
UNIX ser ver . Even when t he l ocal machine has a gr aphical int er f ace such as Windows,
you can most l ikel y connect t o r emot e machines using a char act er -based int er f ace.
Figur e 6.3. Using Tel net f r om a Windows f or Wor kgr oups machine.
If t he cal l ing and r eceiving wor kst at ions use a gr aphical user int er f ace (GUI) such as
Mot if or X, and you want t o use t hem inst ead of a char act er -based int er f ace, you must
inst r uct bot h ends t o use t he l ocal t er minal f or windowing (because you can't see a
window on t he r emot e t er minal ). Local l y, a pr ogr am is r un t hat inst r uct s t he oper at ing
syst em t o enabl e ot her machines t o displ ay dir ect l y ont o t he scr een, and t he r emot e
must have an inst r uct ion t o r edir ect windowing commands t o t he l ocal scr een. Many
UNIX syst ems per f or m t his f unct ion l ike t his:
tpci_server-1> xhost +
tpci_server-2> telnet tpci_hpws4
Trying...
Connected to tpci_hpws4.
Escape character is '^]'.
HP-UX tpci_hpws4 A.09.01 A 9000/720 (ttys2)
login: tparker
password: xxxxxxxx
tpci_hpws4-1> setenv DISPLAY tpci_server:0.0
tpci_hpws4-2> <Ctrl+d>
Connection closed by foreign host.
tpci_server-3>
The UNIX xhost + inst r uct ion t el l s t he l ocal machine t o enabl e t he r emot e syst em t o
cont r ol windows on t he l ocal scr een (which it nor mal l y is not al l owed t o do). The
inst r uct ion set env DISPLAY machine_name execut ed on t he r emot e UNIX machine set s
t he UNIX shel l envir onment var iabl e DISPLAY t o t he l ocal scr een. Whenever a window
must be opened (as when a Mot if appl icat ion is r un), t he windowing appear s on t he l ocal
scr een, and t he pr ocessing is conduct ed on t he r emot e. These exampl es ar e f or UNIX, but
a simil ar sequence wor ks on ot her machines and GUIs.
Compl et e appl icat ions t hat pr ovide t his capabil it y t o r un l ocal X and Mot if windows on
a Windows, Windows 95, or Windows NT machine ar e avail abl e f r om sever al commer cial
vendor s. For exampl e, Figur e 6.4 shows an appl icat ion r unning on a r emot e ser ver cal l ed
mandel t hat dr aws Mandel br ot f igur es. The ser ver has been inst r uct ed t o displ ay t he
window on t he l ocal Windows f or Wor kgr oups machine using an X cl ient package f or
Windows machines. The ser ver passes al l inf or mat ion about t he size, posit ion, and col or s
of t he window, as wel l as inst r uct ions f or dr awing t he cont ent s t o t he l ocal X cl ient .
The window appear s on t he Windows f or Wor kgr oups machine exact l y as it woul d on t he
UNIX ser ver .
Figur e 6.4. Using an X cl ient t o show UNIX X windows on a PC.
Telnet Commands
Sever al ser vice opt ions ar e avail abl e when a Tel net session is est abl ished. Their val ues
can be changed dur ing t he cour se of a Tel net session if bot h ends agr ee (one end might
be pr event ed f r om enabl ing or disabl ing a ser vice because of administ r at or or r esour ce
set t ings). Ther e ar e f our ver bs used by t he Tel net pr ot ocol t o of f er , r ef use, r equest , and
pr event ser vices: wil l , won't , do, and don't , r espect ivel y. The ver bs ar e designed t o be
pair ed (wil l /won't and do/don't ). To il l ust r at e how t hese ar e used, consider t he
f ol l owing Tel net session, which has t he displ ay of t hese ver bs t ur ned on using t he
t el net command t oggl e opt ions:
tpci_server-1> telnet
telnet> toggle options
Will show option processing.
telnet> open tpci_hpws4
Trying...
Connected to tpci_hpws4.
Escape character is '^]'.
SENT do SUPPRESS GO AHEAD
SENT will TERMINAL TYPE (don't reply)
SEND will NAWS (don't reply)
RCVD do 36 (reply)
sent won't 36 (don't reply)
RECD do TERMINAL TYPE (don't reply)
RCVD will SUPPRESS GO AHEAD (don't reply)
RCVD do NAWS (don't reply)
Sent suboption NAWS 0 80 (80) 0 37 (37)
Received suboption Terminal type - request to send.
RCVD will ECHO (reply)
SEND do ECHO (reply)
RCVD do ECHO (reply)
SENT won't ECHO (don't reply)
HP-UX tpci_hpws4 A.09.01 A 9000/720 (ttys2)
login:
The Tel net commands ar e used by t he pr ot ocol , not by
user s (al t hough you can issue t hem dur ing a Tel net session, but
t his is usual l y used onl y f or diagnost ic pur poses). Ther e ar e no
inher ent Tel net user commands, ot her t han t he command mode
t oggl e, because Tel net 's r ol e is t o connect you t o a r emot e
syst em and l et you use it dir ect l y.
A par t ial set of Tel net command codes is shown in Tabl e 6.1. Addit ional codes ar e used
t o r epr esent pr int er f unct ions such as hor izont al and ver t ical t abs and f or m f eeds, but
t hese have been l ef t of f t he t abl e f or br evit y's sake. Par t of t he Tel net command code
set incl udes six t er minal f unct ions (IP, AO, AYT, EC, EL, and GA) t hat ar e common acr oss
most t er minal def init ions, so t hey ar e f or mal l y def ined in t he Tel net st andar d.
Tabl e 6.1. Tel net command codes.
Code Value Description
Abor t Out put (AO) 245
Runs pr ocess t o compl et ion but does not send t he
out put
Ar e you t her e (AYT) 246
Quer ies t he ot her end t o ensur e t hat an
appl icat ion is f unct ioning
Br eak (BRK) 243 Sends a br eak inst r uct ion
Dat a Mar k 242 Dat a por t ion of a Sync
Do 253
Asks f or t he ot her end t o per f or m or an
acknowl edgment t hat t he ot her end is t o per f or m
Don't 254
Demands t hat t he ot her end st op per f or ming or
conf ir ms t hat t he ot her end is no l onger
per f or ming
Er ase Char act er (EC) 247 Er ases a char act er in t he out put st r eam
Er ase Line (EL) 248 Er ases a l ine in t he out put st r eam
Go Ahead (GA) 249
Indicat es per mission t o pr oceed when using hal f -
dupl ex (no echo) communicat ions
Int er pr et as Command (IAC) 255 Int er pr et s t he f ol l owing as a command
Int er r upt Pr ocess (IP) 244
Int er r upt s, suspends, abor t s, or t er minat es t he
pr ocess
NOP 241 No oper at ion
SB 250 Subnegot iat ion of an opt ion
SE 240 End of t he subnegot iat ion
Wil l 251
Inst r uct s t he ot her end t o begin per f or ming or
conf ir ms t hat t his end is now per f or ming
Won't 252
Ref uses t o per f or m or r eject s t he ot her end
per f or ming
Tel net commands ar e sent in a f or mal package cal l ed a command, as shown in Figur e 6.5.
Typical l y t he commands cont ain t wo or t hr ee byt es: t he Int er pr et as Command (IAC)
inst r uct ion, t he command code being sent , and any opt ional par amet er t o t he command.
The opt ions suppor t ed by Tel net ar e shown in Tabl e 6.2.
Figur e 6.5. The Tel net command st r uct ur e.
Tabl e 6.2. Suppor t ed Tel net opt ion codes.
Code Description
0 Binar y t r ansmission
1 Echo
2 Reconnect ion
3 Suppr ess Go Ahead (GA)
4 Appr oximat e message size negot iat ion
5 St at us
6 Timing mar k
7 Remot e cont r ol l ed t r ansmission and echo
8 Out put l ine widt h
9 Out put page l engt h
10 Out put car r iage-r et ur n act ion
11 Out put hor izont al t ab st op set t ing
12 Out put hor izont al t ab st op act ion
13 Out put f or m f eed act ion
14 Out put ver t ical t ab st op set t ing
15 Out put ver t ical t ab st op act ion
16 Out put l ine f eed act ion
17 Ext ended ASCII char act er s
18 Logout
19 Byt es macr o
20 Dat a ent r y t er minal
21 SUPDUP
22 SUPDUP out put
23 Send l ocat ion
24 Ter minal t ype
25 End of Recor d
26 TACACS user ident if icat ion
27 Out put mar king
28 Ter minal l ocat ion number
29 3270 r egime
30 X.3 PAD (Packet assembl y and disassembl y)
31 Window size
If you r ef er t o t he pr evious code l ist ing wit h t he opt ions t oggl ed on, some of t he
commands can be under st ood mor e cl ear l y now. For exampl e, wil l ECHO (which woul d
be t r ansmit t ed as val ues 255 251 1) inst r uct s t he ot her end t o begin echoing back
char act er s it r eceives. The command won't ECHO (t he command woul d be 255 252 1)
indicat es t hat t he sender wil l not echo back char act er s or want s t o st op echoing.
The use of ASCII char act er s and smal l t abl es of commands
and opt ions make it r el at ivel y easy t o f ol l ow Tel net
communicat ions.
TN3270
Many mainf r ames use EBCDIC, wher eas most smal l er machines r el y on ASCII. This can
cause a pr obl em when t r ying t o Tel net f r om EBCDIC-based machines t o ASCII-based
machines and vice-ver sa, because t he codes being t r ansf er r ed ar e not accur at e. To
cor r ect t his, a Tel net appl icat ion cal l ed TN3270 was devel oped, which pr ovides
t r ansl at ion bet ween t he t wo f or mat s.
When TN3270 is used t o connect bet ween t wo machines, Tel net it sel f est abl ishes t he
init ial connect ion, and t hen one end set s it sel f up f or t r ansl at ion. If an ASCII machine is
cal l ing an EBCDIC machine, t he t r ansl at ion bet ween t he t wo f or mat s is conduct ed at
t he EBCDIC (ser ver ) end unl ess t her e is a gat eway bet ween t hem, in which case t he
gat eway can per f or m t he t r ansl at ion.
Many TCP/IP appl icat ion suit es t hat incl ude a Tel net pr ogr am al so incl ude a TN3270
pr ogr am. For exampl e, Figur e 6.6 shows a TN3270 window f r om t he Net Manage
Chamel eonNFS suit e in t he pr ocess of connect ing t o a mainf r ame EBCDIC-based machine.
The mainf r ame's IP addr ess is used t o init iat e t he connect ion.
Figur e 6.6. TN3270 pr ovides conver sion bet ween ASCII and EBCDIC.
File Transfer Protocol (FTP)
File Transfer Protocol, usual l y cal l ed FTP, is a ut il it y f or managing f il es acr oss machines
wit hout having t o est abl ish a r emot e session wit h Tel net . FTP enabl es you t o t r ansf er
f il es back and f or t h, manage dir ect or ies, and access el ect r onic mail . FTP is not designed
t o enabl e access t o anot her machine t o execut e pr ogr ams, but it is t he best ut il it y f or
f il e t r ansf er s.
FTP uses t wo TCP channel s. TCP por t 20 is t he dat a channel , and por t 21 is t he command
channel . FTP is dif f er ent f r om most ot her TCP/IP appl icat ion pr ogr ams in t hat it does use
t wo channel s, enabl ing simul t aneous t r ansf er of FTP commands and dat a. It al so dif f er s
in one ot her impor t ant aspect : FTP conduct s al l f il e t r ansf er s in t he f or egr ound,
inst ead of t he backgr ound. In ot her wor ds, FTP does not use spool er s or queues, so you
ar e wat ching t he t r ansf er pr ocess in r eal t ime. By using TCP, FTP el iminat es t he need t o
wor r y about r el iabil it y or connect ion management , because FTP can r el y on TCP t o
per f or m t hese f unct ions pr oper l y.
In FTP par l ance, t he t wo channel s t hat exist bet ween t he t wo machines ar e cal l ed t he
protocol interpreter, or PI, and t he data transfer process, or DTP. The PI t r ansf er s inst r uct ions
bet ween t he t wo impl ement at ions using TCP command channel 21, and t he DTP t r ansf er s
dat a on TCP dat a channel 20. This is shown in Figur e 6.7.
Figur e 6.7. FTP channel connect ions.
FTP is simil ar t o Tel net in t hat it uses a ser ver pr ogr am t hat r uns cont inuousl y and a
separ at e pr ogr am t hat is execut ed on t he cl ient . On UNIX syst ems, t hese pr ogr ams ar e
named f t pd and f t p, r espect ivel y (simil ar t o t el net d and t el net ).
FTP Commands
Bef or e l ooking at how you can use FTP t o t r ansf er f il es, you shoul d l ook at t he
commands behind t he pr ot ocol it sel f . As wit h Tel net 's commands, t hese ar e f or t he
pr ot ocol 's use onl y and shoul d not be used by a user (al t hough administ r at or s somet imes
use t he FTP commands f or debugging and diagnost ic pur poses).
FTP's int er nal pr ot ocol commands ar e f our -char act er ASCII sequences t er minat ed by a
newl ine char act er . Some of t he codes r equir e par amet er s af t er t hem. One pr imar y
advant age t o using ASCII char act er s f or commands is t hat a user can obser ve t he
command f l ow and under st and it easil y. This hel ps consider abl y in t he debugging
pr ocess. Al so, it enabl es a knowl edgeabl e user t o communicat e dir ect l y wit h t he FTP
ser ver component (f t pd).
FTP commands used by t he pr ot ocol ar e summar ized in Tabl e 6.3. These commands pr ovide
f or t he connect ion pr ocess, passwor d checking, and t he act ual f il e t r ansf er s. These ar e
not t o be conf used wit h t he commands avail abl e t o a user .
Tabl e 6.3. FTP int er nal commands.
Command Description
ABOR Abor t pr evious command
ACCT User account ID
ALLO Al l ocat e st or age f or f or t hcoming oper at ion
APPE Append incoming dat a t o an exist ing f il e
CDUP Change t o par ent dir ect or y
CWD Change wor king dir ect or y
DELE Del et e f il e
HELP Ret r ieve inf or mat ion
LIST Tr ansf er l ist of dir ect or ies
MKD Make a dir ect or y
MODE Set t r ansf er mode
NLST Tr ansf er a dir ect or y l ist ing
NOOP No oper at ion
PASS User passwor d
PASV Request a passive open
PORT Por t addr ess
PWD Displ ay cur r ent dir ect or y
QUIT Ter minat e t he connect ion
REIN Ter minat e and r est ar t a connect ion
REST Rest ar t mar ker (r est ar t t r ansf er )
RETR Tr ansf er copy of f il e
RMD Remove a dir ect or y
RNFR Ol d pat hname f or r ename command
RNTO New pat hname f or r ename command
SITE Pr ovides ser vice specif ics
SMNT Mount a f il e syst em
STAT Ret ur ns st at us
STOR Accept and st or e dat a
STOU Accept dat a and st or e under dif f er ent name
STRU Fil e st r uct ur e
SYST Quer y t o det er mine oper at ing syst em
TYPE Type of dat a
USER User ID
FTP al so uses simpl e r et ur n codes t o indicat e t r ansf er condit ions. Each r et ur n code is a
t hr ee-digit number , t he f ir st of which signif ies a successf ul execut ion (t he f ir st digit is 1,
2, or 3) or a f ail ur e (t he f ir st digit is 4 or 5). The second and t hir d digit s specif y t he
r et ur n code or er r or condit ion in mor e det ail . The FTP r et ur n codes ar e shown in Tabl e
6.4 and Tabl e 6.5. The t hir d-digit codes ar e not incl uded her e because t her e ar e many of
t hem and t hey var y bet ween impl ement at ions.
Tabl e 6.4. FTP r epl y code f ir st digit s.
First Digit Description
1 Act ion init iat ed. Expect anot her r epl y bef or e sending a new command.
2 Act ion compl et ed. Can send a new command.
3 Command accept ed but on hol d due t o l ack of inf or mat ion.
4
Command not accept ed or compl et ed. Tempor ar y er r or condit ion exist s.
Command can be r eissued.
5
Command not accept ed or compl et ed. Reissuing t he command wil l r esul t in
t he same er r or (don't r eissue).
Tabl e 6.5. FTP r epl y code second digit s.
Second Digit Description
0 Synt ax er r or or il l egal command
1 Repl y t o r equest f or inf or mat ion
2 Repl y t hat r ef er s t o connect ion management
3 Repl y f or aut hent icat ion command
4 Not used
5 Repl y f or st at us of ser ver
FTP enabl es f il e t r ansf er s in sever al f or mat s, which ar e usual l y syst em-dependent . The
major it y of syst ems (incl uding UNIX syst ems) have onl y t wo modes: t ext and binar y. Some
mainf r ame inst al l at ions add suppor t f or EBCDIC, wher eas many sit es have a l ocal t ype
designed f or f ast t r ansf er s bet ween l ocal net wor k machines (t he l ocal t ype might use
32- or 64-bit wor ds).
Text t r ansf er s use ASCII char act er s separ at ed by car r iage-r et ur n and newl ine
char act er s, wher eas binar y enabl es t r ansf er of char act er s wit h no conver sion or
f or mat t ing. Binar y mode is f ast er t han t ext and al so enabl es f or t he t r ansf er of al l
ASCII val ues (necessar y f or nont ext f il es). On most syst ems, FTP st ar t s in t ext mode,
al t hough many syst em administ r at or s now set FTP t o binar y mode as a def aul t f or t heir
user s' convenience. FTP cannot t r ansf er f il e per missions, because t hese ar e not specif ied
as par t of t he pr ot ocol .
Bef or e t r ansf er r ing f il es wit h FTP, make sur e you ar e using t he cor r ect t r ansf er mode.
Tr ansf er r ing a binar y f il e as ASCII r esul t s in gar bage! Check wit h your syst em
administ r at or if you ar e unsur e of t he mode, or wat ch t he messages FTP r et ur ns t o see
t he mode used.
FTP Connections
FTP is usual l y st ar t ed wit h t he name or addr ess of t he t ar get machine. As wit h Tel net ,
t he name must be r esol vabl e int o an IP addr ess f or t he command t o succeed. The t ar get
machine can al so be specif ied f r om t he FTP command l ine. For exampl e, t o connect t o t he
IP addr ess 205.150.89.5, you woul d issue t his command:
ftp 205.150.89.5
When FTP connect s t o t he dest inat ion, you must be abl e t o l og int o t he syst em as a val id
user (as you do when connect ing t hr ough Tel net ). Some syst ems enabl e an anonymous or
guest l ogin f or FTP f il e t r ansf er s (usual l y using your l ogin name as a passwor d as a
r ecor d of your access; see t he sect ion t it l ed "Anonymous FTP Access"), but most r equir e
you t o have r egul ar access t o t he machine. The f ol l owing ext r act shows t he l ogin
pr ocess as a user pr ovides a l ogin and passwor d f or t he r emot e machine:
ftp tpci_hpws4
Connected to tpci_hpws4.
220 tpci_hpws4 FTP server
Name (tpci_hpws4:tparker):
331 Password required for tparker.
Password:
230 User tparker logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
On l ar ge net wor ks wher e a syst em such as Yel l ow Pages (YP) or Net wor k Inf or mat ion
Ser vices (NIS) is used, FTP l ogins ar e usual l y per mit t ed on most machines. If YP or NIS is
not empl oyed, you must be in t he val id user s f il e t o obt ain FTP access. As wit h Tel net ,
you can l og int o t he r emot e wit h a dif f er ent user ID f r om your l ocal machine l ogin. To
t r ansf er f il es, you must have t he pr oper per missions on t he r emot e, if f il e per missions ar e
pr ovided f or by t he oper at ing syst em.
Af t er l ogging int o anot her machine using FTP, you ar e not act ual l y on t he r emot e
machine. You ar e st il l l ogical l y on t he cl ient , so al l inst r uct ions f or f il e t r ansf er s and
dir ect or y movement must be wit h r espect t o your l ocal machine, not t he r emot e one.
Not e t hat t his is t he opposit e of Tel net (a dist inct ion t hat causes consider abl e conf usion
among newcomer s t o FTP and Tel net ).
Remember t hat al l r ef er ences t o f il es and dir ect or ies ar e r el at ive t o t he machine t hat
init iat ed t he FTP session. If you ar e not car ef ul , you can accident al l y over wr it e
exist ing f il es.
The pr ocess f ol l owed by FTP when a connect ion is est abl ished is as f ol l ows:
1. Login: Ver if ies t he user ID and passwor d.
2. Def ine dir ect or y: Ident if ies t he st ar t ing dir ect or y.
3. Def ine f il e t r ansf er mode: Def ines t he t ype of t r ansf er .
4. St ar t dat a t r ansf er : Enabl es user commands.
5. St op dat a t r ansf er : Cl oses t he connect ion.
The st eps ar e per f or med in sequence f or each connect ion. A user has sever al commands
avail abl e t o cont r ol FTP; t he most f r equent l y used commands ar e summar ized in Tabl e
6.6.
Tabl e 6.6. FTP user commands.
FTP Command Description
ascii Swit ch t o ASCII t r ansf er mode
binar y Swit ch t o binar y t r ansf er mode
cd Change dir ect or y on t he ser ver
cl ose Ter minat e t he connect ion
del Del et e a f il e on t he ser ver
dir Displ ay t he ser ver dir ect or y
get Fet ch a f il e f r om t he ser ver
hash Displ ay a pound char act er f or each bl ock t r ansmit t ed
hel p Displ ay hel p
l cd Change dir ect or y on t he cl ient
mget Fet ch sever al f il es f r om t he ser ver
mput Send sever al f il es t o t he ser ver
open Connect t o a ser ver
put Send a f il e t o t he ser ver
pwd Displ ay t he cur r ent ser ver dir ect or y
quot e Suppl y an FTP command dir ect l y
quit Ter minat e t he FTP session
Using FTP is simil ar t o Tel net , except t hat al l movement s of f il es ar e r el at ive t o t he
cl ient . Ther ef or e, put t ing a f il e is moving it f r om t he cl ient t o t he ser ver , wher eas
get t ing a f il e is t he r ever se. A sampl e FTP session f ol l ows:
tpci_hpws1-1> ftp tpci_hpws4
Connected to tpci_hpws4.
220 tpci_hpws4 FTP server (Version 1.7.109.2 Tue Jul 28
23:32:34 GMT 1992) ready.
Name (tpci_hpws4:tparker):
331 Password required for tparker.
Password:
230 User tparker logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> pwd
257 "/u1/tparker" is current directory.
ftp> get mandelfile1.gif
remote: mandelfile1.gif local: mandelfi.gif
200 PORT command successful
150 Opening BINARY mode data connection for mandelfile1.gif
226 File transfer complete
1192834 bytes sent in 0.89 seconds
ftp> <Ctrl+d>
tpci_hpws1-2>
In t his shor t sampl e, I t r ansf er r ed a f il e cal l ed mandel f il e1.gif f r om a UNIX machine
(t he ser ver ) t o t he l ocal machine (t he cl ient ). You might have not iced t hat t he f il ename
was t r uncat ed aut omat ical l y by t he ser ver t o f it t he DOS f il esyst em naming
convent ions. Al so, not e t hat I used binar y mode (which was t he syst em def aul t ). If t he
def aul t had been ASCII mode, I woul d have just t r ansf er r ed over a megabyt e of t ot al
gar bage t hat coul dn't be used f or anyt hing.
A debugging opt ion is avail abl e f r om t he command l ine by adding -d t o t he command. This
displ ays t he command channel inst r uct ions. Inst r uct ions f r om t he cl ient ar e shown wit h
an ar r ow as t he f ir st char act er , wher eas inst r uct ions f r om t he ser ver have t hr ee digit s
in f r ont of t hem. A PORT in t he command l ine indicat es t he addr ess of t he dat a channel
on which t he cl ient is wait ing f or t he ser ver 's r epl y. If no PORT is specif ied, channel 20
(t he def aul t val ue) is used. Unf or t unat el y, t he pr ogr ess of dat a t r ansf er s cannot be
f ol l owed in t he debugging mode. A sampl e session wit h t he debug opt ion enabl ed is
shown her e:
tpci_hpws1-1> ftp -d
ftp> open tpci_hpws4
Connected to tpci_hpws4.
220 tpci_hpws4 FTP server Name (tpci_hpws4:tparker):
---> USER tparker
331 Password required for tparker.
Password:
---> PASS qwerty5
230 User tparker logged in.
---> SYST
215 UNIX Type: L8
Remote system type is UNIX.
---> Type I
200 Type set to I.
Using binary mode to transfer files.
ftp> ls
---> PORT 47,80,10,28,4,175
200 PORT command successful.
---> TYPE A
200 Type set to A.
---> LIST
150 Opening ASCII mode data connection for /bin/ls.
total 4
-rw-r----- 1 tparker tpci 2803 Apr 29 10:46 file1
-rw-rw-r-- 1 tparker tpci 1286 Apr 14 10:46
file5_draft
-rwxr----- 2 tparker tpci 15635 Mar 14 23:23
test_comp_1
-rw-r----- 1 tparker tpci 52 Apr 22 12:19 xyzzy
Transfer complete.
---> TYPE I
200 Type set to I.
ftp> <Ctrl+d>
tpci_hpws1-2>
You might not ice in t he pr evious code how t he mode changes f r om binar y t o ASCII t o
send t he dir ect or y l ist ing, and t hen back t o binar y (t he syst em def aul t val ue). You can
see how t he t wo syst ems communicat e t o displ ay t he st at us messages t hat appear wit hout
t he debugging opt ion act ive.
When FTP is used in a gr aphical user envir onment , you might be abl e t o use a GUI-based
t ool . For exampl e, Net Manage's Chamel eonNFS pr ovides t he FTP ut il it y shown in Figur e
6.8. In t his case, t he NFS cl ient on t he Windows f or Wor kgr oups machine has connect ed
t o a UNIX ser ver . The Local side of t he window shows t he Windows machine, and t he
Remot e side of t he window shows t he UNIX box's cur r ent f il esyst em cont ent s. When
using a GUI-based ut il it y l ike t his one, you can use t he mouse and var ious but t ons t o
t r ansf er f il es back and f or t h bet ween machines.
Figur e 6.8. Many oper at ing syst ems have a GUI-based FTP cl ient .
FTP Third-Party Transfers
FTP enabl es a t r ansf er t o occur t hr ough a t hir d machine posit ioned bet ween t he cl ient
and t he ser ver . This pr ocedur e is known as a third-party transfer and is somet imes necessar y
t o obt ain pr oper per missions t o access t he r emot e machine. Figur e 6.9 shows t he schemat ic
of a t hir d-par t y t r ansf er , wit h t he cont r ol connect ion made t hr ough a t hir d machine.
Figur e 6.9. A t hir d-par t y FTP t r ansf er .
When set t ing up a t hir d-par t y connect ion, t he cl ient opens t he cont r ol connect ions
bet ween t he r emot e machine and t he second cl ient t hat handl es t he cont r ol channel .
Onl y t he cont r ol channel goes t hr ough t he second cl ient , wher eas t he dat a channel
goes dir ect l y bet ween t he t wo ends.
When a t r ansf er r equest is submit t ed, it is t r ansf er r ed t hr ough t he second cl ient , which
checks per missions and t hen f or war ds t he r equest t o t he ser ver . The dat a t r ansf er can
t ake pl ace dir ect l y, because t he per missions wer e checked on t he cont r ol channel .
Anonymous FTP Access
FTP r equir es a user ID and passwor d t o enabl e f il e t r ansf er capabil it ies, but t her e is a
mor e l iber al met hod of enabl ing gener al access t o a f il e or dir ect or y, cal l ed anonymous
FTP. Anonymous FTP r emoves t he r equir ement f or a l ogin account on t he r emot e
machine, usual l y enabl ing t he l ogin anonymous wit h a passwor d of eit her guest or t he
user 's act ual l ogin name. The f ol l owing session shows t he use of an anonymous FTP
syst em:
tpci_hpws4-1> ftp uofo.edu
Connected to uofo.edu.
220 uofo.edu FTP server (Version 1.7.109.2 Tue Jul 28
23:32:34 GMT 1992) ready.
Name (uofo:username): anonymous
331 Guest login ok, send userID as password.
Password: tparker
230 Guest login ok, access restrictions apply.
ftp> <Ctrl+d>
tpci_hpws4-2>
If t he r emot e syst em is set t o enabl e anonymous l ogins, you ar e pr ompt ed f or a passwor d
and t hen given a war ning about access l imit at ions. If t her e is a f il e on t he r emot e syst em
you r equir e, a get command t r ansf er s it . Anonymous FTP sit es ar e becoming common,
especial l y wit h t he popul ar it y of t he Int er net .
FTP Servers
Most UNIX machines act as FTP ser ver s by def aul t . To pr ovide FTP ser ver f acil it ies, t hey
r un t he daemon f t pd when t he oper at ing syst em is boot ed. The daemon is usual l y
handl ed by t he UNIX inet d pr ocess. When you st ar t using inet d, t he inet d daemon
wat ches t he TCP command por t (channel 21) f or an ar r iving r equest f or a connect ion,
t hen st ar t s f t pd t o ser vice t hat r equest . If you want t o ensur e t hat your UNIX or Linux
syst em can handl e FTP r equest s, make sur e t he f t pd daemon can be st ar t ed when needed
by inet d by checking t he inet d conf igur at ion f il e (usual l y /et c/inet d.conf ig or
/et c/inet d.conf ) f or a l ine t hat l ooks l ike t his:
ftp stream tcp nowait root /usr/etc/ftpd ftpd -l
If t his l ine doesn't exist , you shoul d add it . Wit h most UNIX syst ems t his l ine is al r eady
in t he inet d conf igur at ion f il e, al t hough it might be comment ed out , in which case you
shoul d r emove t he comment symbol .
Windows, Windows f or Wor kgr oups, and Windows 95 al l l ack an FTP ser ver pr ogr am as
par t of t heir dist r ibut ion sof t war e (al t hough Windows 95 does have an FTP cl ient ), so
you have t o add a commer cial package. Many commer cial TCP/IP suit es incl ude an FTP
ser ver pr ocess. Figur e 6.10 shows t he Net Manage Chamel eonNFS pr ogr am gr oup, which
incl udes an FTP ser ver pr ogr am you can use as an exampl e f or Windows f or Wor kgr oups
and Windows 3.x machines.
Figur e 6.10. The Net Manage FTP Ser ver dial og handl es t he FTP ser ver pr ocess.
To st ar t t he Net Manage FTP Ser ver sof t war e, doubl e-cl ick t he FTP ser ver icon in t he
Net Manage pr ogr am gr oup. A dial og, shown in Figur e 6.10, appear s. The FTP ser ver
pr ocess is now act ive, and anyone on anot her machine on your l ocal ar ea net wor k can
now connect t o your machine, assuming t hey have access.
Access t o your FTP ser vice is cont r ol l ed t hr ough t he user l ist s maint ained by t he FTP
Ser ver package. Sel ect ing t he User s menu opt ion f r om t he Net Manage FTP Ser ver dial og
opens t he User s dial og, shown in Figur e 6.11. This l et s you add user names t o your syst em.
If anot her user on a dif f er ent machine t r ies t o connect t o your FTP ser ver sof t war e, t he
ser ver ver if ies t hat t heir l ogin name and passwor d mat ch t he name and passwor d you
ent er in t his dial og. This l et s you set up a l ist of user s who can t r ansf er f il es t o and
f r om your syst em, as l ong as t he FTP ser ver is r unning.
Figur e 6.11. Access t o your machine is cont r ol l ed t hr ough t he FTP Ser ver User s
dial og.
If you ar e r unning an FTP ser ver pr ocess, it is of t en a good idea t o cr eat e a dir ect or y
just f or FTP. Many user s pr ef er t o cr eat e a dir ect or y cal l ed publ ic, which is wher e al l
f il es t o be t r ansf er r ed in and out of t he l ocal syst em ar e pl aced. This l et s you pr event
accident al del et ion or t r ansf er of f il es in ot her dir ect or ies on your syst em, as wel l as
pr oviding you wit h t he oppor t unit y t o f il t er incoming mat er ial f or suit abil it y, vir uses,
and so on. If you use a t r ansf er dir ect or y, check it r egul ar l y and make sur e al l user s
who have access t o your syst em can wor k onl y in t hat dir ect or y.
If you want t o pr ovide an anonymous or guest account f or user s on your LAN or any
ot her net wor k t hat can connect t o your machine, you shoul d set up an account wit h
eit her no passwor d or a simpl e passwor d l ike guest . It is ver y impor t ant t o r est r ict t he
ar eas a guest or anonymous l ogin can use.
As ment ioned ear l ier , Windows 95 is suppl ied wit h cl ient FTP sof t war e but not an FTP
ser ver . You can use ot her aspect s of Windows 95 as a f il e t r ansf er syst em, such as f il e
and pr int shar ing over any exist ing net wor k, but t hese do not use FTP. If you want t o
set up an FTP ser ver on your Windows 95 machine, you have t o inst al l t hir d-par t y
commer cial sof t war e f or t his pur pose.
A popul ar Windows 95 FTP ser ver package cal l ed FTP Ser v-U was wr it t en by Rob Becker s
and is pr ovided as shar ewar e. An execut abl e f il e cal l ed Ser v-U st ar t s t he ser ver . To
cont r ol access t o your Windows 95 syst em, you can set up l ogins using t he Ser v-U User s
menu opt ion. This displ ays a scr een t hat l et s you add l ogins and passwor ds, as wel l as
t he dir ect or ies and dr ives t he user has access t o. Figur e 6.12 shows t he Edit User /Gr oup
dial og wit h a user being added. When a user f r om anot her syst em l ogs int o your
Windows 95 machine, t hey ar e asked f or a l ogin and passwor d.
Figur e 6.12. Set up al l user s of your FTP ser ver wit h t he Edit User /Gr oup dial og.
Trivial File Transfer Protocol (TFTP)
The Tr ivial Fil e Tr ansf er Pr ot ocol (TFTP) is one of t he simpl est f il e t r ansf er pr ot ocol s
in use. It dif f er s f r om FTP in t wo pr imar y ways: it does not l og ont o t he r emot e machine,
and it uses t he User Dat agr am Pr ot ocol (UDP) connect ionl ess t r anspor t pr ot ocol
inst ead of TCP. By using UDP, TFTP does not monit or t he pr ogr ess of t he f il e t r ansf er ,
al t hough it does have t o empl oy mor e compl ex al gor it hms t o ensur e pr oper dat a
int egr it y. By avoiding l ogging ont o t he r emot e, user access and f il e per mission pr obl ems
ar e avoided. TFTP uses t he TCP por t ident if ier number 69, even t hough TCP is not
invol ved in t he pr ot ocol .
TFTP has f ew advant ages over FTP. It is not usual l y used f or f il e t r ansf er s bet ween
machines wher e FTP coul d be used inst ead, al t hough TFTP is usef ul when a diskl ess
t er minal or wor kst at ion is invol ved. Typical l y, TFTP is used t o l oad appl icat ions and
f ont s int o t hese machines, as wel l as f or boot st r apping. TFTP is necessar y in t hese cases
because t he diskl ess machines cannot execut e FTP unt il t hey ar e f ul l y l oaded wit h an
oper at ing syst em. TFTP's smal l execut abl e size and memor y r equir ement s make it ideal
f or incl usion in a boot st r ap, wher e t he syst em r equir es onl y TFTP, UDP, and a net wor k
dr iver , al l of which can be pr ovided in a smal l EPROM.
TFTP handl es access and f il e per missions by imposing r est r aint s of it s own. On most UNIX
syst ems, f or exampl e, a f il e can be t r ansf er r ed onl y if it is accessibl e t o al l user s on t he
r emot e (bot h r ead and wr it e per missions ar e set ). Because of t he l ax access r egul at ions,
most syst em administ r at or s impose mor e cont r ol over TFTP (or ban it s use al t oget her );
ot her wise, it is quit e easy f or a knowl edgeabl e user t o access or t r ansf er f il es t hat
coul d const it ut e a secur it y viol at ion.
TFTP t r ansf er s can f ail f or many r easons, because pr act ical l y any kind of er r or
encount er ed dur ing a t r ansf er oper at ion causes a compl et e f ail ur e. TFTP does suppor t
some basic er r or messages, but it cannot handl e simpl e er r or s such as insuf f icient
r esour ces f or a f il e t r ansf er or even a f ail ur e t o l ocat e a r equest ed f il e.
TFTP Commands
The impor t ant inst r uct ions in TFTP's command set ar e shown in Tabl e 6.7. The TFTP
command set is simil ar t o FTP's, but it dif f er s in sever al impor t ant aspect s because of t he
connect ionl ess aspect of t he pr ot ocol . Most not iceabl e is t he connect command, which
simpl y det er mines t he r emot e's addr ess inst ead of init iat ing a connect ion.
Tabl e 6.7. TFTP' s command set .
TFTP Command Description
binar y Use binar y mode f or t r ansf er s
connect Det er mine t he r emot e's addr ess
get Ret r ieve a f il e f r om t he r emot e
put Tr ansf er a f il e t o t he r emot e
t r ace Displ ay pr ot ocol codes
ver bose Displ ay al l inf or mat ion
TFTP enabl es bot h t ext and binar y t r ansf er s, as does FTP. As wit h bot h Tel net and FTP,
TFTP uses a ser ver pr ocess (t f t pd on a UNIX syst em) and an execut abl e, usual l y cal l ed
t f t p. A sampl e TFTP session on a UNIX host is shown her e, wit h f ul l t r ace opt ions and
binar y t r ansf er s t ur ned on:
tpci_hpws1-1> tftp
tftp> connect tpci_hpws4
tftp> trace
Packet tracing on.
tftp> binary
Binary mode on.
tftp> verbose
Verbose mode on.
tftp> status
Connected to tpci_hpws4.
Mode: octet Verbose: on Tracing: on
Rexmt-interval: 5 seconds, Max-timeout: 25 seconds
tftp> get /usr/rmaclean/docs/draft1
getting from tpci_hpws4:/usr/rmaclean/docs/draft1 to
/tmp/draft1 [octet]
sent RRQ <file=/usr/rmaclean/docs/draft1, mode=octet>
received DATA <block1, 512 bytes>
send ACK <block=1>
received DATA <block2, 512 bytes>
send ACK <block=3>
received DATA <block4, 128 bytes>
send ACK <block=3>
Received 1152 bytes in 0.2 second 46080 bits/s]
tftp> quit
tpci_hpws1-2>
In t he session above, you can see t hat t he t r ace and ver bose commands t ur n on t he
echoing of t he inst r uct ions f l owing bet ween t he t wo machines dur ing a f il e t r ansf er .
Ever y t ime a bl ock of dat a is sent af t er t he get command is issued (t he send ACK
inst r uct ion shown on t he session above), a r eceived inst r uct ion is r et ur ned t o
acknowl edge t he ACK.
TFTP is avail abl e on al l UNIX syst ems as wel l as in TCP/IP suit es f or ot her oper at ing
syst ems. Figur e 6.13 shows t he TFTP ut il it y f r om Chamel eonNFS, which l et s you ent er
t he r emot e host name, t he r emot e and l ocal f il enames, and t he t ype of t r ansf er you
want . The f il e t r ansf er is t hen per f or med in t he backgr ound using UDP.
Figur e 6.13. Using TFTP t o t r ansf er a f il e.
TFTP Packets
TFTP uses UDP as a t r anspor t pr ot ocol , so TFTP can use t he UDP header t o encapsul at e
TFTP pr ot ocol inf or mat ion. TFTP uses t he UDP sour ce and dest inat ion por t f iel ds t o set
t he t wo ends of t he connect ion. It accompl ishes t his by t he use of TFTP Transfer Identifiers,
or TIDs, which ar e cr eat ed by TFTP and passed t o UDP, which t hen pl aces t hem in t he
header s.
As wit h Tel net and FTP, TFTP uses por t binding, wher e t he sending machine sel ect s a
TID, and t he r emot e is set t o por t number 69 (TFTP's por t number ). The r emot e machine
r esponds wit h an acknowl edgment of a connect ion r equest , a sour ce por t of 69, and t he
dest inat ion TID sent in t he r equest .
TFTP uses f ive t ypes of Pr ot ocol Dat a Unit s, which ar e r ef er r ed t o as packet s in t he
TFTP l exicon. These packet s ar e l ist ed in Tabl e 6.8. Their l ayout is shown in Figur e 6.14.
Er r or messages suppor t ed by TFTP ar e shown in Tabl e 6.9.
Figur e 6.14. TFTP packet l ayout s.
Tabl e 6.8. TFTP Pr ot ocol Dat a Unit codes.
Code OpCode Description
ACK 4 Acknowl edgment
DATA 3 Send Dat a
Er r or 5 Er r or
RRQ 1 Read r equest
WRQ 2 Wr it e r equest
Tabl e 6.9. TFTP er r or messages and codes.
Code Description
0 Not def ined
1 Fil e not f ound
2 Per missions pr event access
3 Disk f ul l or al l ocat ion l imit exceeded
4 Il l egal TFTP oper at ion r equest ed
5 Unknown t r ansf er number
The l ayout s f or bot h RRQ and WRQ packet s have a Mode f iel d, which indicat es t he t ype
of t r ansf er . Ther e ar e t hr ee modes cur r ent l y avail abl e t o TFTP:
G Net ASCII: St andar d ASCII codes.
G Byt e: 8-bit byt es and binar y inf or mat ion.
G Mail : Indicat es t hat t he dest inat ion is a user , not a f il e (inf or mat ion is
t r ansf er r ed as Net ASCII).
The l ast bl ock in al l packet s cont ains bet ween 0 and 511 byt es of dat a, l abel ed 0 in
Figur e 6.14. This pads out t he bl ock of dat a t o 512 byt es.
The communicat ions pr ocess used by TFTP begins wit h t he cl ient sending an RRQ or WRQ
r equest t o t he ser ver t hr ough UDP. As par t of t he r equest , a t r ansact ion number , t he
f il ename, and a code t o ident if y t he t r ansmission mode t o be used ar e specif ied. The
t r ansact ion number is used t o ident if y f ut ur e t r ansact ions in t he sequence.
Because t her e is no connect ion bet ween t he t wo, t he cl ient set s a t imer and wait s f or a
r epl y f r om t he ser ver . If one doesn't ar r ive bef or e t he t imer expir es, anot her r equest is
sent . Af t er an ACK is r eceived, a DATA packet is t r ansmit t ed, f or which anot her ACK or
an ERROR is r eceived. If t her e ar e sever al packet s t o be t r ansf er r ed, t hey ar e
const r uct ed so t hey have a l engt h of 512 byt es and an incr ement ing sequence number .
The pr ocess t er minat es when a DATA packet wit h a l engt h of l ess t han 512 byt es is
r eceived by t he ser ver . For each packet sent , TFTP wait s f or an acknowl edgment bef or e
sending t he next , a syst em known as a flip-flop protocol.
Simple Mail Transfer Protocol (SMTP)
The Simpl e Mail Tr ansf er Pr ot ocol (SMTP) is t he def ined Int er net met hod f or
t r ansf er r ing el ect r onic mail . SMTP is simil ar t o FTP in many ways, incl uding t he same
simpl icit y of oper at ion. SMTP uses TCP por t number 25.
Most UNIX syst ems use pr ogr ams cal l ed sendmail or mmdf t o impl ement SMTP (as wel l as
sever al ot her mail pr ot ocol s). The sendmail pr ogr am, f or exampl e, act s as bot h a cl ient
and a ser ver , usual l y r unning in t he backgr ound as a daemon. User s do not int er act
wit h sendmail dir ect l y but use a f r ont -end mail pr ogr am such as mail , mail x, or Mail .
These mail syst em int er f aces pass t he message t o sendmail f or f or war ding.
SMTP uses spool s or queues. When a message is sent t o SMTP, it pl aces it in a queue. SMTP
at t empt s t o f or war d t he message f r om t he queue whenever it connect s t o r emot e
machines. If it cannot f or war d t he message wit hin a specif ied t ime l imit , t he message is
r et ur ned t o t he sender or r emoved.
SMTP Commands
SMTP dat a t r ansmissions use a simpl e f or mat . Al l t he message t ext is t r ansf er r ed as 7-bit
ASCII char act er s. The end of t he message is indicat ed by a singl e per iod on a l ine by
it sel f . If f or some r eason a l ine in t he message begins wit h a per iod, a second one is added
by t he pr ot ocol t o avoid conf usion wit h t he end-of -message indicat or .
SMTP has a simpl e pr ot ocol command set , l ist ed in Tabl e 6.10. Using t hese pr ot ocol
el ement s, mail is t r ansf er r ed wit h a minimum of ef f or t .
Tabl e 6.10. The SMTP pr ot ocol command set .
Command Description
DATA Message t ext
EXPN Expansion of a dist r ibut ion l ist
HELO Use in connect ion est abl ishment t o exchange ident if ier s
HELP Request f or hel p
MAIL The sender 's addr ess
NOOP No oper at ion
RCPT The message dest inat ion addr ess (mor e t han one can be pr ovided)
RSET Ter minat e t he cur r ent t r ansact ion
SAML Send a message t o t he user 's t er minal and send mail
SEND Send a message t o t he user 's t er minal
SOML Eit her send a message t o t he user 's t er minal or send mail
TURN Change t he sending dir ect ion (r ever se sending and r eceiving r ol es)
VRFY Ver if y t he user name
When a connect ion is est abl ished, t he t wo SMTP syst ems exchange aut hent icat ion codes.
Fol l owing t his, one syst em sends a MAIL command t o t he ot her t o ident if y t he sender
and pr ovide inf or mat ion about t he message. The r eceiving SMTP r et ur ns an
acknowl edgment , af t er which a RCPT is sent t o ident if y t he r ecipient . If mor e t han one
r ecipient at t he r eceiver l ocat ion is ident if ied, sever al RCPT messages ar e sent , but t he
message it sel f is t r ansmit t ed onl y once. Af t er each RCPT t her e is an acknowl edgment . A
DATA command is f ol l owed by t he message l ines, unt il a singl e per iod on a l ine by it sel f
indicat es t he end of t he message. The connect ion is cl osed wit h a QUIT command.
The sender and r ecipient addr ess f iel ds use st andar d Int er net f or mat s, invol ving t he
user name and domain name (such as t par ker @t pci.com). The domain can be r epl aced by
ot her inf or mat ion if a dir ect connect ion is est abl ished, or if t her e is a f or war ding
machine in t he pat h. SMTP uses t he Domain Name Syst em (DNS) f or al l addr esses.
The Berkeley Utilities
The Univer sit y of Cal if or nia at Ber kel ey was inst r ument al in t he devel opment of
TCP/IP and cont r ibut ed many ut il it y pr ogr ams t o t he appl icat ion t ool set . These ar e
usual l y known by t he t er m Berkeley r-Utilities. They ar e cal l ed r -ut il it ies because t hey
al l st ar t wit h t he l et t er r (f or r emot e). Most of t he ut il it ies ar e UNIX-specif ic,
al t hough t hey have since al l been por t ed t o ot her oper at ing syst ems.
The hosts.equiv and .rhosts Files
To enabl e machines t o communicat e cor r ect l y over net wor ks, access r ight s f or machines
and user s must be set . Usual l y, when l ogging int o anot her machine, a user must suppl y a
user ID and a passwor d. When you l og int o many machines, r et yping t his inf or mat ion can
be t edious and t ime-consuming. It can al so be a secur it y pr obl em, because it is easy t o
wr it e a pr ogr am t hat monit or s net wor k connect ions f or t his inf or mat ion. A way t o
enabl e f ast access wit hout act ual l y l ogging in and pr event ing int er cept ion of
passwor ds is cl ear l y usef ul in some cases.
The syst em administ r at or can decide t hat al l l ogin names used on ot her machines whose
names ar e in t he f il e host s.equiv ar e al l owed access on t he l ocal machine. This enabl es a
pr ot ocol t hat quer ies a machine f or access t o check t he host s.equiv f il e f or t he
r equest ing machine's name, and if it is f ound, t o gr ant access t o t he user on t he r emot e
machine. The user has t he same access r ight s as on his or her home machine.
If t he pr ot ocol doesn't f ind an ent r y in t he host s.equiv f il e, it can check anot her f il e
maint ained in a user 's home dir ect or y, cal l ed .r host s. A user can cont r ol who has access
t o t heir l ogin name wit h t he f il e .r host s in t heir home dir ect or y, enabl ing ot her user s
t o l og in as if t hey wer e t hat user . The .r host s f il e must be owned by t he user (or r oot )
and not al l ow wr it e access t o al l user s (on a UNIX syst em, t he ot her per mission cannot
be wr it e). An .r host s f il e consist s of a l ine f or each user t o be al l owed int o t he home
dir ect or y. The l ine consist s of a machine name and a l ogin name. A sampl e .r host s f il e is
shown her e:
tpci_hpws1 rmaclean
tpci_hpws1 bsmallwood
tpci_hpws3 ychow
tpci_hpws3 bsmallwood
tpci_hpws4 glessard
tpci_hpws4 bsmallwood
tpci_sunws1 chatton
merlin tparker
merlin ahoyt
merlin lrainsford
This f il e al l ows user bsmal l wood t o l og in f r om t hr ee dif f er ent machines.
rlogin
The r l ogin command (f or remote login) enabl es a user t o l og int o anot her machine. It is
ver y simil ar in f unct ional it y t o Tel net , al t hough t he pr ot ocol is much simpl er . Ther e is
a backgr ound pr ogr am r unning on t he ser ver cal l ed r l ogind, and t he pr ogr am r l ogin
r esides on t he cl ient .
The r l ogin pr ot ocol begins a session by sending t hr ee char act er st r ings, separ at ed by 0s.
The f ir st st r ing is t he user 's l ogin ID (on t he cl ient ), t he second st r ing is t he l ogin name
f or t he ser ver (usual l y but not al ways t he same as t he l ogin name on t he cl ient ), and
t he t hir d st r ing is t he l ogin name and t r ansmission r at e of t he user 's t er minal (such as
wyse60/19200). When r eceived on t he ser ver , t he st r ings can be conver t ed t o
envir onment var iabl es (such as UNIX's TERM t er minal var iabl e). You cannot l og int o
t he r emot e machine wit h a dif f er ent user ID, because t he syst em does not pr ompt f or t he
l ogin name. It does pr ompt f or a passwor d, however .
Af t er t he l ogin pr ocess is compl et ed, r l ogin doesn't use any pr ot ocol . Ever y char act er
you t ype on t he cl ient machine is sent t o t he ser ver , wher eas ever y ser ver -gener at ed
char act er is displ ayed on your consol e. The onl y exit t o your l ocal machine is by
cl osing t he connect ion by using Ct r l +D or ent er ing t he escape char act er on a l ine by
it sel f . By def aul t , t he escape char act er is a t il de (~).
Some ver sions of r l ogin enabl e a shel l escape, a t empor ar y suspension of t he r l ogin
session and a r et ur n t o t he oper at ing syst em, by using ~!.
rsh
The r sh ut il it y (r emot e shel l ) l et s you execut e commands on a r emot e machine. As wit h
most Ber kel ey ut il it ies, a backgr ound pr ocess cal l ed r shd is invol ved. Execut ing a
command on a r emot e machine is a mat t er of adding r sh and t he machine name t o t he
f r ont of t he command l ine, such as r sh t pci_hpws3 who or r sh t pci_sunws1 t ar xvf
/dev/r ct 0 (using UNIX exampl es). The r sh ut il it y depends on t he pr esence of eit her
host s.equiv or .r host s t o enabl e l ogin; ot her wise, access is not gr ant ed.
The r sh ut il it y is not a shel l in t he sense t hat it does not int er pr et commands l ike t he
UNIX C shel l or Bour ne shel l . Inst ead, a command ent er ed is sent t o t he ser ver 's
st andar d input and out put , execut ing t he command as a l ocal pr ocess t hr ough t he TCP
connect ion. The pr imar y advant age of t his is t hat a shel l scr ipt t hat execut es on your
l ocal machine can be submit t ed t o t he r emot e machine wit h no modif icat ion, wher e it
r uns just as if it wer e l ocal (except using t he r emot e's f il e syst em). Unf or t unat el y, any
r et ur n codes gener at ed by t he r emot e syst em ar e not sent back t o your l ocal machine.
Al so, most scr een-or ient ed appl icat ions do not f unct ion pr oper l y, because t hey have no
t er minal out put t o wr it e t o.
rcp
The Ber kel ey r cp (r emot e copy) command is simil ar t o t he UNIX cp command, except t hat
it wor ks acr oss t he net wor k. The command synt ax and opt ion l ist s f or r cp ar e t he same as
cp, al t hough a machine name is usual l y specif ied as par t of t he f il ename by t he addit ion
of t he machine name f ol l owed by a col on (see t he f ol l owing exampl es). Even r ecur sive
copying of dir ect or ies is suppor t ed (a usef ul and at t r act ive f eat ur e of r cp t hat isn't
avail abl e under FTP or TFTP). The r cp pr ogr am act s as bot h ser ver and cl ient , init iat ed
when a r equest ar r ives.
rcp tpci_hpws4:/user/tparker/doc/draft1 .
rcp file2 merlin:/u1/bsmallwood/temp/file2
rcp -r merlin:/u2/tparker/tcp_book tpci_server/tcp_book
rcp merlin:/u1/ychow/iso9000_doc
tpci_server:/u1/iso/doc1/iso_doc_from_ychow
rcp file4 tparker@tpci.com:new_info
As t he exampl es indicat e, t he f il enames at bot h t he l ocal and r emot e machines ar e
specif ied, wit h st andar d UNIX convent ions suppor t ed. The t hir d exampl e shows a f il e
being t r ansf er r ed f r om one machine t o anot her , neit her of which is t he machine f r om
which t he command is init iat ed. The l ast exampl e shows t he use of a f ul l DNS-st yl e name
f or t he dest inat ion addr ess.
The r cp ut il it y is a f ast er met hod of t r ansf er r ing f il es t han FTP, al t hough r cp r equir es
access per mission t hr ough an .r host s f il e (not host s.equiv). Wit hout an ent r y in t his f il e,
access is r ef used and FTP or TFTP must be used.
rwho
The r who (r emot e who) command uses t he r whod daemon t o displ ay a l ist of user s on t he
net wor k. It shows al l net wor k user s, compil ed f r om a r egul ar l y sent packet of
inf or mat ion f r om al l r unning r whod pr ogr ams. The f r equency of t his packet br oadcast is
syst em-dependent but is usual l y in t he or der of ever y one t o t hr ee minut es. When an
r whod pr ogr am r eceives a br oadcast f r om anot her machine, it pl aces it in a syst em f il e
f or f ut ur e use. (The f il e on a UNIX syst em is cal l ed /usr /spool /r who.)
When a machine has not sent a br oadcast message wit hin a t ime l imit (usual l y el even
minut es), it is assumed t hat t he machine has disconnect ed f r om t he net wor k, and al l
user s l ist ed as act ive on t hat machine in t he syst em f il e ar e ignor ed. The r whod pr ogr am
dr ops a user ID f r om it s br oadcast if not hing has been ent er ed at t he user 's t er minal in
t he l ast hour .
The out put f r om an r who r equest is shown in t he f ol l owing exampl e. For each user , it
shows t heir l ogin name, t heir machine and t er minal name, and t he t ime and dat e of t heir
l ogin.
bsmallwood merlin:tty2p Feb 29 09:01
etreijs tpci_hpws2:tty01 Feb 29 12:12
rmaclean goofus:tty02 Feb 28 23:52
tparker merlin:tty01 Feb 29 11:43
ychow prudie:tty2a Feb 28 11:37
The r cp pr ogr am has one major pr obl em on l ar ge net wor ks: t he cont inuous sending of
updat e packet s by each machine cr eat es a consider abl e amount of net wor k t r af f ic. For
t his r eason, some impl ement at ions dir ect l y r equest t he user names onl y when an r who
r equest is r eceived.
ruptime
The r upt ime ut il it y displ ays a l ist of al l machines on t he net wor k, t heir st at us, t he
number of act ive user s, cur r ent l oad, and el apsed t ime since t he syst em was boot ed. The
pr ogr am uses t he same inf or mat ion as t he r who command.
A sampl e out put f r om a r upt ime command f ol l ows:
merlin up 3:15,12 users, load 0.90, 0.50, 0.09
prudie down 9:12
tpci_hpws1 up 11:05, 3 users, load 0.10, 0.10, 0.00
tpci_hpws2 up 23:59, 5 users, load 0.30, 0.25, 0.08
tpci_hpws3 down 6:45
tpci_hpws4 up 9:05, 1 user, load 0.12, 0.05, 0.01
rexec
The r exec (r emot e execut ion) pr ogr am is a hol dover f r om ear l ier ver sions of t he UNIX
oper at ing syst em. It was designed t o enabl e r emot e execut ion of a command t hr ough a
ser ver pr ocess cal l ed r execd. The ut il it y uses t he dedicat ed TCP por t number 512.
The pr ot ocol used by r exec is ver y simil ar t o r sh, except t hat an encr ypt ed passwor d is
sent wit h t he r equest and t her e is a f ul l l ogin pr ocess. The r exec ut il it y is sel dom used
because r sh is a f ast er and mor e convenient met hod f or execut ing a command r emot el y.
Summary
Today I l ooked at t he pr imar y appl icat ion pr ot ocol s t hat use TCP/IP, as wel l as t he
Ber kel ey ut il it ies. Now t hat you can see how pr ot ocol s wor k on t op of t he TCP and IP
pr ot ocol s, t he l ayer ed st r uct ur e of TCP/IP becomes mor e pr onounced. Fut ur e days' t ext s
buil d on t his inf or mat ion.
Q&A
What is t he pur pose of Tel net and FTP?
Tel net pr ovides a r emot e l ogin capabil it y, wher eas FTP enabl es you t o t r ansf er f il es
acr oss t he net wor k.
What channel s (por t number s) ar e used by Tel net , FTP, and SMTP?
Tel net uses por t number 23. FTP uses por t number 21 f or t he cont r ol inf or mat ion and
por t number 20 f or dat a. SMTP uses por t number 25.
When you issue a get command in FTP, is it moving a f il e f r om t he l ocal t o r emot e,
or vice ver sa?
FTP commands ar e r el at ive t o t he r emot e, so a get command moves a f il e f r om t he l ocal
t o t he r emot e.
How does TFTP dif f er f r om FTP?
TFTP does not r equir e l ogging in. It sends a r equest over UDP. Wit h FTP, you must l og
int o t he dest inat ion eit her dir ect l y or t hr ough a t hir d-par t y device.
Does r l ogin dif f er f r om t el net ?
The r l ogin pr ogr am was devel oped ear l ier and f or most user s has no dif f er ence. Ther e
ar e some ver sion dependencies wit h some r el eases of r l ogin, r ef l ect ing it s ear l ier (and
l ess f ul l -f eat ur ed) or igins.
Quiz
1. Expl ain what a net wor k vir t ual t er minal is.
2. Dr aw diagr ams showing t wo- and t hr ee-par t y FTP sessions, indicat ing t he por t
number s used by each machine.
3. Why woul d you want t o enabl e anonymous FTP access? Ar e t her e any r easons f or
disal l owing it ?
4. TFTP enabl es f il es t o be t r ansf er r ed wit hout l ogging in. What pr obl ems can t his
cause?
5. What ar e t he Ber kel ey Ut il it ies?
Workshop
If you have access t o a Tel net or FTP session, t r y l ogging int o a r emot e machine and
t r ansf er r ing f il es back and f or t h. Tr y t o r ecognize t hat Tel net does ever yt hing
r el at ive t o t he l ocal machine, wher eas FTP is r el at ive t o t he r emot e.


I Conf igur at ion Fil es
I Symbol ic Machine Names: /et c/host s
I Net wor k Names: /et c/net wor ks
I Net wor k Pr ot ocol s: /et c/pr ot ocol s
I Net wor k Ser vices: /et c/ser vices
I Set t ing t he Host Name
I The Loopback Dr iver
I Managing ARP
I Using if conf ig
I The inet d Daemon
I The net st at Command
I Communicat ions End Point s
I Net wor k Int er f ace St at ist ics
I Dat a Buf f er s
I Rout ing Tabl e Inf or mat ion
I Pr ot ocol St at ist ics
I The ping Ut il it y
I Tr acing a Connect ion
I Summar y
I Q&A
7
TCP/IP Configuration and Administration
Basics
Al t hough TCP/IP wor ks t r anspar ent l y f or t he user , occasional l y communicat ions seem t o
be sl ow and TCP/IP is suspect ed as t he cause. Most user s ar e impat ient and expect t hings t o
happen r ight away, so del ays f or any r eason l ead t o f r ust r at ion. Rat her t han sit and
wait , most user s l ike t o be abl e t o ver if y t hat a connect ion t o a r emot e machine is act ive
and a del ay is caused by net wor k t r af f ic inst ead of a syst em f ail ur e. At t he l east , most
user s woul d l ike t o under st and why a session is pr ogr essing sl owl y.
TCP/IP has sever al ut il it y pr ogr ams t hat pr ovide st at us inf or mat ion and per f or mance
st at ist ics. Al so avail abl e ar e sever al debugging pr ogr ams and opt ions t o enabl e a
devel oper or knowl edgeabl e user t o t r ace a pr obl em. This chapt er examines t he basic set
of t hese t ool s. Al t hough TCP/IP is a st andar d, t her e ar e many dif f er ent impl ement at ions
of t he pr ot ocol f amil y. Most ver sions have t he basic t ool set discussed t oday, al t hough
some might al t er names and out put t o t heir own l iking.
Al l net wor k addr esses and machine names in t his chapt er
ar e chosen at r andom and do not r epr esent any par t icul ar
net wor k. Because t he net wor k addr esses used might cor r espond
t o a r eal net wor k, you shoul d not use t hem in any
exper iment at ion, or you might incur t he wr at h of a syst em
administ r at or !
Not al l t he commands shown in t his chapt er ar e avail abl e t o r egul ar user s (as opposed t o
syst em administ r at or s) on al l syst ems, al t hough some syst em administ r at or s do enabl e
some access t o t he ut il it ies f or checking connect ion and TCP/IP st at us. The commands ar e
pr esent ed her e t o show t he debugging and diagnost ic capabil it ies avail abl e t o t he TCP/IP
user and administ r at or . The commands ar e not cover ed in exhaust ive det ail but ar e
int ended t o compl et e t he TCP/IP pict ur e f or you. Many of t hese pr ogr ams and ut il it ies ar e
seen again l at er in t his book when I set up a sampl e TCP/IP net wor k.
Configuration Files
Sever al f il es ar e invol ved in t he compl et e specif icat ion of net wor k addr esses and
conf igur at ion f or TCP/IP. For il l ust r at ive pur poses, a UNIX syst em is used as t he st andar d
her e, al t hough a f ew ot her oper at ing syst ems ar e ment ioned as appr opr iat e. Ot her
oper at ing syst ems use dif f er ent f il enames, but t he pur pose of t he f il es is usual l y t he same.
You might have t o check wit h your oper at ing syst em document at ion t o ident if y t he f il es
used f or each pur pose.
UNIX al l ows comment s on ever y l ine of t hese conf igur at ion f il es, as l ong as t hey ar e
pr ef aced by a pound sign (#). If you see t his char act er in your own syst em's conf igur at ion
f il es, you shoul d not e t hat it is not par t of an ent r y. Wit h many oper at ing syst ems, t he
def aul t conf igur at ion f il es have many ent r ies, most of which ar e comment ed out unt il
t he syst em administ r at or r emoves t he comment s.
You might not be abl e t o examine t he f il es or r un t he ut il it ies ment ioned in t his chapt er
because of secur it y r est r ict ions. If you edit t he conf igur at ion f il es, make sur e you do not
make any unint ent ional changes! Make backups of al l t he f il es bef or e you make any
changes t o your syst ems.
Symbolic Machine Names: /etc/hosts
Whenever a symbol ic name is used as a t ar get addr ess by an appl icat ion, t her e must be
some met hod t o r esol ve t hat name int o a net wor k addr ess. An ASCII f il e is commonl y used
wit h t he symbol ic names mat ched t o net wor k addr esses. This does not appl y when t he
Yel l ow Pages (YP), Net wor k Inf or mat ion Ser vices (NIS), or t he Domain Name Ser ver (DNS)
is used; t hey use t heir own conf igur at ion f il es.
On UNIX syst ems, t he f il e /et c/host s is used t o hol d t he net wor k addr esses, as wel l as one
special connect ion cal l ed t he loopback (which is examined l at er in t his chapt er in t he
sect ion t it l ed "The Loopback Dr iver "). The l oopback connect ion addr ess is usual l y l ist ed
as t he machine name l oopback or l ocal host .
The f il e /et c/host s consist s of t he net wor k addr ess in one col umn separ at ed f r om t he
symbol ic name in anot her . The net wor k addr esses can be specif ied in decimal , oct al , or
hexadecimal f or mat (al t hough decimal is t he most common). Mor e t han one symbol ic name
can be specif ied on a l ine by separ at ing t he names wit h eit her space char act er s or t abs.
The /et c/host s f il e can be as l ong as necessar y t o cont ain al l t he symbol ic names used on
t he l ocal machine; t hey do not need t o be pr esent ed in any or der . A sampl e UNIX
/et c/host s f il e is as f ol l ows:
# network host addresses
127.0.0.1 localhost local tpci_server
157.40.40.1 tpci_sco1
157.40.40.2 tpci_sco2
157.40.40.3 tpci_hpws1
157.40.40.0 tpci_server tpci_main tpci
47.80.157.36 bnr.ca BNR bnr
191.13.123.4 kitty_cat
205.150.89.1 roy_maclean big_roy
210.24.47.128 bobs_machine
As you can see, t he f il e is made up of t wo col umns. The f ir st col umn gives t he IP addr ess of
a machine, and t he second (separ at ed by one or mor e whit espace char act er s) gives t he
machine's name. If sever al names can be used t o ident if y t he r emot e machine, t hey ar e
l ist ed on t he same l ine, separ at ed by whit espace. For exampl e, t he r emot e machine wit h IP
addr ess 205.150.89.1 can be addr essed as eit her r oy_macl ean or big_r oy. Whenever eit her
of t hose names is used in a command (such as an FTP or Tel net appl icat ion), t his f il e is used
t o mat ch t o t he pr oper IP addr ess.
A syst em or net wor k administ r at or can updat e t he /et c/host s f il e at any t ime, and
changes ar e ef f ect ive immediat el y (so t he machine doesn't have t o be r eboot ed t o ef f ect
t he changes). Whenever a symbol ic name is specif ied by a user or an appl icat ion, t he
/et c/host s f il e is al ways sear ched f ir st f or a mat ching name, and t he pr oper addr ess is r ead
f r om t he same l ine.
Most TCP/IP impl ement at ions on ot her pl at f or ms have a simil ar t ype of f il e t o r esol ve IP
addr esses f r om symbol ic names. Net Manage Chamel eonNFS r unning on a Windows 3.x
machine, f or exampl e, uses a Host Tabl e t o mat ch names and IP addr esses. The Host Tabl e,
shown in Figur e 7.1, is a gr aphical f r ont -end t o a f il e equival ent t o /et c/host s on a UNIX
machine.
Figur e 7.1. Chamel eonNFS uses a Host Tabl e t o mat ch symbol ic names and IP
addr esses.
Network Names: /etc/networks
Net wor ks can be addr essed by a symbol ic name, just as machines ar e. To r esol ve t he
net wor k names, anot her f il e is used t hat cont ains t he cor r esponding net wor k addr ess.
Typical l y, t his f il e isn't accessed of t en, because f ew user s want t o addr ess an ent ir e
net wor k wit hin t heir appl icat ion. The net wor k name r esol ut ion f il e's most common use is
t o specif y t he l ocal net wor k's name.
UNIX syst ems usual l y use t he f il e /et c/net wor ks t o specif y symbol ic net wor k names. The
f or mat of t he f il e pr ovides a net wor k symbol ic name, it s net wor k addr ess, and any al ias
t hat might be used, in much t he same f or mat as t he /et c/host s t abl e is used f or specif ic
machines. A sampl e /et c/net wor ks f il e is shown her e:
# local network names
tpci 146.1 tpci_network tpci_local
bnr 47.80 BNR bnr.ca
tmn 123.2.21
unique 89.123.23 UNIQUE
sco 132.147 SCO
loopback 127 localhost
The /et c/net wor ks f il e l ayout is a l it t l e dif f er ent f r om /et c/host s in t hat t he usual
net wor k name is given in t he f ir st col umn, f ol l owed by t he IP net wor k addr ess, t hen any
al iases.
The l ast ent r y in t his exampl e f il e gives t he l oopback name. The f ir st ent r y specif ies t he
l ocal machine name, it s net wor k addr ess, and any name var iant s. Using t his f il e, an
appl icat ion t hat want ed t o r each t he net wor k cal l ed UNIQUE coul d use t hat name and
l et t he oper at ing syst em r esol ve it t o t he IP net wor k addr ess 89.123.23.
Many impl ement at ions of TCP/IP on ot her pl at f or ms don't bot her wit h a net wor k name
r esol ut ion f il e l ike t his. Par t of t he r eason is t hat t he /et c/net wor ks f il e has l it t l e use
on a UNIX pl at f or m, and many singl e-user oper at ing syst ems don't r equir e t he t ype of
ver sat il it y a mul t iuser oper at ing syst em l ike UNIX must suppl y t o an ent ir e net wor k.
Network Protocols: /etc/protocols
Pr ot ocol number s ar e used t o ident if y t he t r anspor t pr ot ocol t o t he r eceiving machine t o
enabl e pr oper decoding of t he inf or mat ion wit hin t he dat agr am. Wit h TCP/IP, t he
pr ot ocol number is embedded in t he Int er net Pr ot ocol header . A conf igur at ion f il e is
usual l y used t o ident if y al l t he t r anspor t pr ot ocol s avail abl e on t he syst em and t heir
r espect ive pr ot ocol number s.
UNIX syst ems use t he /et c/pr ot ocol s f il e f or t his pur pose. Usual l y, t his f il e is not modif ied
by t he administ r at or but is maint ained by t he syst em and updat ed aut omat ical l y as par t
of t he inst al l at ion pr ocedur e when new TCP/IP sof t war e or ser vices ar e added. The
/et c/pr ot ocol s f il e cont ains t he pr ot ocol name, it s number , and any al ias t hat might be
used f or t hat pr ot ocol . A sampl e /et c/pr ot ocol s f il e is shown her e:
#
# Internet (IP) protocols
#
ip 0 IP # internet protocol, pseudo protocol
number
icmp 1 ICMP # internet control message protocol
igmp 2 IGMP # internet group management protocol
ggp 3 GGP # gateway-gateway protocol
tcp 6 TCP # transmission control protocol
egp 8 EGP # Exterior-Gateway Protocol
pup 12 PUP # PARC universal packet protocol
udp 17 UDP # user datagram protocol
hello 63 HELLO # HELLO Routing Protocol
ospf 89 OSPF # Open Shortest Path First Routing
Protocol
In t his /et c/pr ot ocol s f il e, t he IP pr ot ocol is assigned pr ot ocol 0, and TCP is pr ot ocol 6.
The val ues in t his t abl e shoul d not be changed f r om t heir def aul t val ues except when
special net wor k condit ions mandat e a change. If new TCP/IP ser vices ar e added t o t he
UNIX syst em t his f il e r esides on, new ent r ies ar e made t o t his f il e by t he appl icat ion
inst al l at ion r out ine.
Ther e ar e usual l y no equival ent s of t he /et c/pr ot ocol s f il e on ot her oper at ing syst ems
because t hey assume t hat t he st andar d t r anspor t number is used f or each pr ot ocol .
Network Services: /etc/services
The f inal common conf igur at ion f il e used on most UNIX syst ems ident if ies t he exist ing
net wor k ser vices. As wit h t he /et c/pr ot ocol s f il e, t his f il e is not usual l y modif ied by an
administ r at or but is maint ained by sof t war e as it is inst al l ed or conf igur ed.
The UNIX net wor k ser vices f il e is /et c/ser vices. The f il e is in ASCII f or mat consist ing of
t he ser vice name, a por t number , and t he pr ot ocol t ype. The por t number and pr ot ocol
t ype ar e separ at ed by a sl ash. The por t number s f or TCP/IP usual l y f ol l ow t he
convent ions ment ioned in t he pr evious chapt er s. Any opt ional ser vice al ias names f ol l ow
af t er t he por t number s. A shor t ext r act f r om a sampl e /et c/ser vices f il e (t he f il e is
usual l y quit e l engt hy) is shown her e:
# network services
echo 7/tcp
echo 7/udp
discard 9/tcp sink null
discard 9/udp sink null
ftp 21/tcp
telnet 23/tcp
smtp 25/tcp mail mailx
tftp 69/udp
# specific services
login 513/tcp
who 513/udp whod
Setting the Host Name
TCP/IP r equir es t hat each machine on t he net wor k have an IP addr ess. Usual l y, each
machine al so has a unique symbol ic name; ot her wise, t he IP addr ess must be used f or al l
connect ions t o t hat machine. Most oper at ing syst ems have a simpl e pr ogr am t hat
ident if ies t he name of t he l ocal machine. UNIX syst ems have t he ut il it y host name f or t his
pur pose, as wel l as t he uname pr ogr am, which can give t he node name wit h t he command
uname -n. The uname ut il it y is usual l y suppor t ed in Syst em V and compat ibl e oper at ing
syst ems onl y.
The host name is somet imes saved in a separ at e f il e t hat is r ead when t he oper at ing syst em
st ar t s up, or it can be r ead f r om one of t he conf igur at ion f il es ment ioned pr eviousl y. The
host name is used by most pr ot ocol s on t he syst em and by many TCP/IP appl icat ions, so it is
impor t ant f or pr oper syst em oper at ion. The host name can somet imes be changed by edit ing
t he syst em f il e t hat cont ains t he name and t hen r eboot ing t he machine, al t hough many
oper at ing syst ems pr ovide a ut il it y pr ogr am t o ensur e t hat t his pr ocess is per f or med
cor r ect l y.
On many UNIX syst ems, t he host name and uname commands echo back t he l ocal machine
name, as t he f ol l owing sampl e session shows:
$ hostname
tpci_sco4.tpci.com
$ uname -n
tpci_sco4
On t he SCO UNIX syst em used in t his exampl e, t he host name command r et ur ns t he f ul l y
qual if ied domain name, wher eas t he uname command pr ovides t he l ocal machine name
onl y. On a Hewl et t -Packar d wor kst at ion r unning HP-UX, bot h commands r et ur n onl y
t he l ocal machine name. The exact behavior of t he host name and uname commands is
t her ef or e quit e dependent on t he impl ement at ion.
On a Linux syst em, f or exampl e, t he host name command can be used t o not onl y show t he
cur r ent host name set t ing but al so t o change it when used wit h t he -S (f or set ) opt ion.
For exampl e, t he command
hostname -S willow.tree.com
changes t he l ocal f ul l y qual if ied domain name t o wil l ow.t r ee.com. Not al l ver sions of
Linux suppor t t he -S opt ion of t he host name command.
Most TCP/IP suit es f or ot her oper at ing syst ems use a simpl er met hod of set t ing t he host
name. For exampl e, on a Windows 3.x machine t he Net Manage Chamel eonNFS package uses
t he dial og shown in Figur e 7.2 t o quickl y set t he host name.
Figur e 7.2. Chamel eonNFS uses t his dial og t o set t he host name.
Windows NT has TCP/IP ser vices buil t int o t he basic dist r ibut ion. On a Windows NT syst em,
t he host name is specif ied t hr ough t he Net wor k dial og opened f r om t he Cont r ol Panel , as
shown in Figur e 7.3. Bot h t he Windows NT and Windows 3.x syst ems enabl e a change in t he
host name t o be made ef f ect ive immediat el y, al t hough a syst em r eboot is r ecommended t o
cl ear al l conf igur at ion inf or mat ion hel d in memor y.
Figur e 7.3. Set t ing t he host name t hr ough t he Windows NT Net wor k Cont r ol Panel .
A pot ent ial pr obl em can occur when t he l ocal machine is multihomed, or based in sever al
net wor ks wit h a dif f er ent name and IP addr ess f or each net wor k. The singl e name in t he
conf igur at ion f il e in such an inst al l at ion might not pr ovide enough inf or mat ion t o
per mit pr oper r out ing over al l t he connect ed net wor ks. This pr obl em is sel dom
encount er ed, but it does r equir e t he syst em administ r at or t o set t he host name f or each
net wor k car ef ul l y.
Aside f r om t he simpl e machine name quer y shown, t he host name syst em is a f ul l pr ot ocol
t hat enabl es access t o t he Net wor k Inf or mat ion Cent er (NIC) t abl es t o ver if y addr esses
and obt ain inf or mat ion about t he net wor k, gat eways, and host s. It uses TCP por t number
101 t o connect t o t he NIC. This t ype of access is usual l y r est r ict ed t o t he net wor k
administ r at or .
The Loopback Driver
The loopback driver is pr obabl y t he most f undament al and of t en-used diagnost ic avail abl e
t o an administ r at or . A l oopback dr iver act s as a vir t ual cir cuit , enabl ing out going
inf or mat ion t o be immediat el y r er out ed back t o an input . This enabl es t est ing of t he
machine's cir cuit s by el iminat ing any ext er nal inf l uences, such as t he net wor k it sel f ,
gat eways, or r emot e machines. By convent ion, each machine uses t he IP addr ess 127.0.0.1
f or t he l oopback dr iver (al so cal l ed t he l ocal host IP addr ess).
Ever y syst em shoul d have a l oopback dr iver in pl ace whet her t he machine is on a net wor k
or not . This is because some appl icat ions insist on having an IP addr ess t hey can access t o
f unct ion pr oper l y. Many l icense ser ver s on a UNIX machine have t his r equir ement , f or
exampl e. Al t hough t he need f or a l oopback dr iver isn't impor t ant f or non-net wor ked
Windows and simil ar oper at ing syst em machines, a l oopback dr iver is al ways inst al l ed
wit h a TCP/IP suit e.
By using a l oopback dr iver , an administ r at or can be sur e
t hat t he l ocal machine is wor king pr oper l y and t hat any
f ail ur es ar e f r om f ur t her out . Al so, some appl icat ions insist on
having a l oopback dr iver IP addr ess in or der t o f unct ion
pr oper l y.
Loopback dr iver s ar e usual l y embedded as par t of t he oper at ing syst em ker nel , or
somet imes as an add-on ut il it y pr ogr am. Most mul t iuser syst ems empl oy an embedded
l oopback dr iver . UNIX is a good exampl e: wit hin t he ker nel is a device dr iver specif ical l y
designed t o act as a l oopback dr iver . The l oopback dr iver is al most al ways added
aut omat ical l y when t he oper at ing syst em is inst al l ed, but a f ew UNIX-based oper at ing
syst ems, incl uding sever al ver sions of Linux, don't per f or m t his f unct ion, and t he
l oopback dr iver must be added manual l y by t he syst em administ r at or . As pr eviousl y
ment ioned, sever al conf igur at ion f il es on t he syst em cont ain t he addr ess of t he
l oopback's connect ion, such as /et c/host s.
Using t he l oopback dr iver t o r er out e t he out put st r eam, t he net wor k int er f ace car d
(usual l y an Et her net car d) is bypassed. The l oopback dr iver is usef ul f or t est ing TCP/IP
sof t war e inst al l at ions, because it immediat el y shows any pr obl ems wit h t he l ocal
conf igur at ion. This can be done bef or e t he machine is physical l y connect ed t o t he
net wor k or even bef or e t he net wor king har dwar e and sof t war e ar e inst al l ed. For
exampl e, you can use t he l oopback dr iver t o t est your TCP/IP conf igur at ion bef or e it is
connect ed t o a net wor k by using t he ping command wit h t he l ocal host name or IP
addr ess, as t he f ol l owing exampl e shows:
# ping -c5 localhost
PING localhost (127.0.0.1): 56 data bytes
64 bytes from localhost (127.0.0.1): icmp_seq=0 ttl=64
time=10 ms
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64
time=0 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64
time=0 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64
time=0 ms
64 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=64
time=0 ms
--- localhost ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0/2/10 ms
# ping -c5 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from localhost (127.0.0.1): icmp_seq=0 ttl=64
time=0 ms
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64
time=0 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64
time=0 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64
time=0 ms
64 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=64
time=0 ms
--- 127.0.0.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0/0/0 ms
In t he pr eceding exampl e I used t he ping command wit h t he -c opt ion t o specif y f ive pings,
f ir st wit h t he l ocal host name (which /et c/host s r esol ves t o t he IP addr ess 127.0.0.1) and
t hen wit h t he IP addr ess it sel f . If eit her command had f ail ed, it woul d indicat e a pr obl em
wit h eit her t he /et c/host s f il e (if t he name l ocal host coul d not be r esol ved) or wit h t he
TCP/IP inst al l at ion (if bot h commands f ail ed).
Managing ARP
The ar p pr ogr am manages ent r ies in t he syst em's Addr ess Resol ut ion Pr ot ocol (ARP)
t abl es. You may r ecal l t hat ARP pr ovides t he l ink bet ween t he IP addr ess and t he
under l ying physical addr ess. For mor e inf or mat ion, see Day 2, "TCP/IP and t he Int er net ."
Using ar p (or it s equival ent in ot her oper at ing syst ems), t he administ r at or can cr eat e,
modif y, or del et e ent r ies in t he ARP t abl e. Typical l y, t his has t o be per f or med whenever a
machine's net wor k addr ess changes (eit her because of a change in t he net wor k har dwar e
or because of a physical move).
The ar p pr ogr am dif f er s consider abl y bet ween impl ement at ions and is sel dom used by
user s, so exampl es of it s use ar e l ef t t o t he oper at ing syst em's conf igur at ion and
administ r at ion document at ion.
Using ifconfig
The if conf ig pr ogr am, or one l ike it , enabl es an administ r at or t o act ivat e and deact ivat e
net wor k int er f aces, as wel l as t o conf igur e t hem. Access t o t he if conf ig pr ogr am is
gener al l y r est r ict ed t o a super user or net wor k administ r at or . Changes t o t he
conf igur at ion can usual l y be made onl y bef or e t he syst em is f ul l y oper at ional (such as in
singl e-user mode on a UNIX syst em). When issued, if conf ig essent ial l y inst r uct s t he
net wor k l ayer of t he ker nel t o wor k wit h t he specif ied net wor k int er f ace by assigning
an IP addr ess, t hen issuing a command t o make t he int er f ace act ive on t he syst em. Onl y
when t he int er f ace is act ive can t he oper at ing syst em ker nel send and r eceive dat a
t hr ough t he int er f ace.
The if conf ig pr ogr am enabl es a net wor k administ r at or t o per f or m sever al usef ul
f unct ions on most oper at ing syst ems:
Act ivat e or deact ivat e an int er f ace
Act ivat e or deact ivat e ARP on an int er f ace
Act ivat e or deact ivat e debugging mode on an int er f ace
Assign a br oadcast addr ess
Assign a subnet wor k mask
Assign a r out ing met hod
Examining al l t he opt ions avail abl e t o if conf ig woul d r equir e sever al dozen pages.
Because t his mat er ial is r ar el y used and dif f er s wit h each impl ement at ion, administ r at or s
ar e r ef er r ed t o t heir oper at ing syst em document at ion. As an exampl e, t he Linux ver sion
of t he if conf ig command uses t his gener al f or mat :
ifconfig interface_type IP_Address
interface_type is t he int er f ace's device dr iver name (such as l o f or l oopback, ppp f or PPP, and
et h f or Et her net ), and IP_Address is t he IP addr ess used by t hat int er f ace.
When used wit h onl y t he name of an int er f ace, if conf ig usual l y r et ur ns inf or mat ion
about t he cur r ent st at e of t he int er f ace, as shown in t he f ol l owing exampl e. In t his
exampl e, a quer y of bot h an Et her net car d (cal l ed ec0) and t he l oopback dr iver (cal l ed
l o0) is per f or med. The st at us f l ags of t he int er f ace ar e f ol l owed by t he Int er net addr ess,
t he br oadcast addr ess, and opt ional l y a net wor k mask, which def ines t he Int er net
addr ess used f or addr ess compar ison when r out ing.
tpci_sco1-12> ifconfig ec0
ec0: flags=807<UP,BROADCAST,DEBUG,ARP>
inet 146.8.12.15 netmask fffff00 broadcast
146.8.12.15
tpci_sco1-13> ifconfig lo0
lo0: flags=49<UP,LOOPBACK,RUNNING>
inet 127.0.0.1 netmask ff000000
The pr eceding exampl e shows t hat t he Et her net connect ion ec0 is act ive (UP), abl e t o
t r ansmit br oadcast s (BROADCAST), and is in debugging mode (DEBUG). Al so, t he ARP
pr ot ocol is act ive (ARP). You may r ecal l t hat a br oadcast message is sent t o al l machines
on t he l ocal net wor k by set t ing t he host ID addr ess t o al l 1s.
Once t he if conf ig command has been r un and an int er f ace is act ive, many oper at ing
syst ems r equir e t he r out e command t o be issued t o add or r emove r out es in t he ker nel 's
r out ing t abl e. This is needed t o enabl e t he l ocal machine t o f ind ot her machines. The
gener al f or mat of t he r out e command on a UNIX or Linux syst em is t his:
route add|del IP_Address
Eit her add or del is specif ied t o add or r emove t he r out e f r om t he ker nel 's r out ing t abl e,
and IP_Addr ess is t he r emot e r out e being af f ect ed.
The cur r ent cont ent s of t he ker nel 's r out ing t abl e can be displ ayed on some syst ems by
ent er ing t he command r out e by it sel f on t he command l ine. For exampl e, on a Linux
syst em t hat is set up onl y wit h t he l oopback dr iver , you see an out put l ike t his:
$ route
Kernel Routing Table
Destination Gateway Genmask Flags MSS Window Use
Iface
loopback * 255.0.0.0 U 1936 0 16
lo
The impor t ant col umns ar e t he dest inat ion name, which shows t he name of t he conf igur ed
t ar get (in t his case onl y l oopback), t he mask t o be used (Genmask), and t he int er f ace
(If ace, in t his case /dev/l o). You can f or ce r out e t o displ ay t he IP addr esses inst ead of
symbol ic names by using t he -n opt ion:
$ route -n
Kernel Routing Table
Destination Gateway Genmask Flags MSS Window Use
Iface
127.0.0.1 * 255.0.0.0 U 1936 0 16
lo
Not al l UNIX and Linux ver sions show t his t ype of out put f r om t he r out e command.
The use of t he if conf ig and r out e pr ogr ams can be shown in t he set up of a Sl ackwar e
Linux syst em's Et her net connect ion. To make t he Et her net int er f ace act ive, t he if conf ig
command is issued wit h t he Et her net device name (et h0 on a Sl ackwar e Linux syst em) and
t he l ocal IP addr ess. For exampl e, t he command
ifconfig eth0 147.123.20.1
set s up t he l ocal machine wit h t he IP Addr ess 147.123.20.1. The int er f ace is t he Et her net
device /dev/et h0. The int er f ace can t hen be checked wit h t he if conf ig command using t he
int er f ace name:
$ ifconfig eth0
eth0 Link encap 10Mps: Ethernet Hwaddr
inet addr 147.123.20.1 Bcast 147.123.1.255 Mask
255.255.255.0
UP BROADCAST RUNNING MTU 1500 Metric 1
RX packets:0 errors:0 dropped:0 overruns:0
TX packets:0 errors:0 dropped:0 overruns:0
You may not ice in t he out put t hat t he br oadcast addr ess was set based on t he l ocal
machine's IP addr ess. This is used by TCP/IP t o access al l machines on t he l ocal ar ea
net wor k at once. The Message Tr ansf er Unit (MTU) size is usual l y set t o t he maximum
val ue of 1500 (f or Et her net net wor ks).
Next , an ent r y is added t o t he ker nel r out ing t abl es t o l et t he ker nel know about t he
l ocal machine's net wor k addr ess. The IP addr ess t hat is used wit h t he r out e command is
not your l ocal machine's IP addr ess, but t hat of t he net wor k as a whol e wit hout t he
l ocal ident if ier . To set t he ent ir e l ocal ar e net wor k at once, t he -net opt ion of t he
r out e command is used. In t he case of t he IP addr esses shown ear l ier , t he command woul d
be t his:
route add -net 147.123.20.0
This adds al l t he machines on t he net wor k ident if ied by t he net wor k addr ess 147.123.20 t o
t he ker nel 's l ist of accessibl e machines. An al t er nat ive met hod is t o use t he
/et c/net wor ks f il e. Once t he r out e has been added t o t he ker nel r out ing t abl es, it can be
t est ed wit h t he ping command.
The inetd Daemon
The inet d pr ogr am is a hol dover f r om t he ear l y days of TCP/IP UNIX devel opment . When a
UNIX machine was st ar t ed, it woul d act ivat e TCP/IP and immediat el y accept connect ions
at it s por t s, spawning a pr ocess f or each. This coul d r esul t in many ident ical pr ocesses,
one f or each avail abl e por t .
To cont r ol t he pr ocesses bet t er , t he inet d pr ogr am was devel oped t o handl e t he por t
connect ions it sel f , of f l oading t hat t ask f r om t he ser ver . The pr imar y dif f er ence is t hat
inet d cr eat es a pr ocess f or each connect ion t hat is est abl ished, wher eas t he ser ver
cr eat es a pr ocess f or each por t (which l eads t o many unused pr ocesses).
On many syst ems, some of t he t est pr ogr ams and st at us inf or mat ion ut il it ies ar e r un
t hr ough inet d. Typical l y, ser vices l ike echo, discar d, and t ime use inet d.
The inet d pr ogr am uses a conf igur at ion f il e usual l y cal l ed /et c/inet d.cf g, /et c/inet d.conf ,
or /et c/inet d.cf on UNIX syst ems. An ext r act of a sampl e /et c/inet d.cf g f il e is shown in t he
f ol l owing code:
# @(#)inetd.conf 5.2 Lachman System V STREAMS TCP
source
#
# System V STREAMS TCP - Release 4.0
ftp stream tcp nowait NOLUID /etc/ftpd
ftpd
telnet stream tcp nowait NOLUID
/etc/telnetd telnetd
shell stream tcp nowait NOLUID /etc/rshd
rshd
login stream tcp nowait NOLUID
/etc/rlogind rlogind
exec stream tcp nowait NOLUID
/etc/rexecd rexecd
finger stream tcp nowait nouser
/etc/fingerd fingerd
comsat dgram udp wait root
/etc/comsat comsat
ntalk dgram udp wait root
/etc/talkd talkd
echo stream tcp nowait root internal
discard stream tcp nowait root internal
chargen stream tcp nowait root internal
daytime stream tcp nowait root internal
time stream tcp nowait root internal
echo dgram udp wait root internal
discard dgram udp wait root internal
chargen dgram udp wait root internal
daytime dgram udp wait root internal
time dgram udp wait root internal
The col umns show t he ser vice name (which cor r esponds t o an ent r y in t he ser vices f il e,
such as /et c/ser vices), t he socket t ype (st r eam, r aw, or dat agr am), t he pr ot ocol name,
whet her inet d can accept f ur t her connect ions at t he same por t immediat el y (nowait ) or
must wait f or t he ser ver t o f inish (wait ), t he l ogin t hat owns t he ser vice, t he ser ver
pr ogr am name, and any opt ional par amet er s needed f or t he ser ver pr ogr am.
The conf igur at ion f il e is r ead when t he ser ver is boot ed and ever y t ime a hang-up signal
is r eceived f r om an appl icat ion. This enabl es dynamic changes t o t he f il e, because any
modif icat ions woul d be r ead and r egist er on t he next f il e r ead.
The netstat Command
The net st at pr ogr am or a simil ar ut il it y pr ovides compr ehensive inf or mat ion about t he
l ocal syst em and it s TCP/IP impl ement at ion. This is t he pr ogr am most commonl y used by
administ r at or s t o quickl y diagnose a pr obl em wit h TCP/IP. The act ual inf or mat ion and it s
f or mat suppl ied by t he net st at ut il it y dif f er s wit h t he oper at ing syst em impl ement at ion,
but it usual l y suppl ies t he f ol l owing impor t ant summar ies, each of which is cover ed in
mor e det ail l at er :
Communicat ions end point s
Net wor k int er f ace st at ist ics
Inf or mat ion on t he dat a buf f er s
Rout ing t abl e inf or mat ion
Pr ot ocol st at ist ics
On some syst ems, inf or mat ion about t he int er pr ocess communicat ions and ot her pr ot ocol
st acks might be appended. The inf or mat ion t o be displ ayed can usual l y be t oggl ed wit h a
command-l ine opt ion. The out put f r om a t ypical UNIX inst al l at ion t hat uses t he net st at
command is shown in t he next f ew sect ions, which discuss net st at and it s out put in mor e
det ail . The out put and meaning might be dif f er ent wit h ot her oper at ing syst ems, but t he
gener al pur pose of t he diagnost ic t ool r emains t he same.
Communications End Points
The net st at command wit h no opt ions pr ovides inf or mat ion on al l act ive communicat ions
end point s. To displ ay al l end point s (act ive and passive), net st at uses t he -a opt ion.
The out put is f or mat t ed int o col umns showing t he pr ot ocol (Pr ot o), t he amount of dat a
in t he r eceive and send queues (Recv-Q and Send-Q), t he l ocal and r emot e addr esses, and
t he cur r ent st at e of t he connect ion. A t r uncat ed sampl e out put is shown her e:
$ netstat -a
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Address
(state)
ip 0 0 *.* *.*
tcp 0 2124 tpci.login merlin.1034
ESTABL.
tcp 0 0 tpci.1034 prudie.login
ESTABL.
tcp 11212 0 tpci.1035 treijs.1036
ESTABL.
tcp 0 0 tpci.1021 reboc.1024
TIME_WAIT
tcp 0 0 *.1028 *.*
LISTEN
tcp 0 0 *.* *.*
CLOSED
tcp 0 0 *.6000 *.*
LISTEN
tcp 0 0 *.listen *.*
LISTEN
tcp 0 0 *.1024 *.*
LISTEN
tcp 0 0 *.sunrpc *.*
LISTEN
tcp 0 0 *.smtp *.*
LISTEN
tcp 0 0 *.time *.*
LISTEN
tcp 0 0 *.echo *.*
LISTEN
tcp 0 0 *.finger *.*
LISTEN
tcp 0 0 *.exec *.*
LISTEN
tcp 0 0 *.telnet *.*
LISTEN
tcp 0 0 *.ftp *.*
LISTEN
tcp 0 0 *.* *.*
CLOSED
udp 0 0 *.60000 *.*
udp 0 0 *.177 *.*
udp 0 0 *.1039 *.*
udp 0 0 *.1038 *.*
udp 0 0 localhost.1036 localhost.syslog
udp 0 0 *.1034 *.*
udp 0 0 *.* *.*
udp 0 0 *.1027 *.*
udp 0 0 *.1026 *.*
udp 0 0 *.sunrpc *.*
udp 0 0 *.1025 *.*
udp 0 0 *.time *.*
udp 0 0 *.daytime *.*
udp 0 0 *.chargen *.*
udp 0 0 *.route *.*
udp 0 0 *.* *.*
The out put shown f or t he net st at commands in t his sect ion
is f r om an SCO UNIX syst em. Each impl ement at ion of net st at is
sl ight l y dif f er ent , so t he out put col umns might change, and
dif f er ent opt ions might be needed t o obt ain each t ype of r epor t .
Check wit h your syst em document at ion f or mor e det ail s about
your net st at impl ement at ion.
In t he pr eceding exampl e, t her e ar e t hr ee act ive TCP connect ions, as ident if ied by t he
st at e ESTABL. One has dat a being sent (as shown in t he Send-Q col umn), and anot her has
incoming dat a in t he queue. The net wor k names and por t number s of t he connect ion ends
ar e shown whenever possibl e. An ast er isk (*) means t her e is no end point associat ed wit h
t hat addr ess yet .
One connect ion is wait ing t o be hung up, ident if ied by TIME_WAIT in t he st at e col umn.
Af t er 30 seconds, t hese sessions ar e t er minat ed and t he connect ion f r eed. Any r ow wit h
LISTEN as t he st at e has no connect ion at t he moment , and is wait ing. Ther e is no st at e
col umn f or UDP sessions because t hey do not have an end-t o-end connect ion (as discussed
on Day 5, "Gat eway and Rout ing Pr ot ocol s"). A CLOSED ent r y in t he out put shows t hat
t he connect ion is cl osed but hasnt swit ched over t o LISTEN yet .
Network Interface Statistics
The behavior of t he net wor k int er f ace (such as t he net wor k int er f ace car d) can be
det er mined wit h t he -i opt ion t o t he net st at command. This inf or mat ion quickl y shows an
administ r at or whet her t her e ar e major pr obl ems wit h t he net wor k connect ion.
The net st at -i command displ ays t he name of t he int er f ace, t he maximum number of
char act er s a packet can cont ain (Mt u), t he net wor k and host addr esses or names, t he
number of input packet s (Ipkt s), input er r or s (Ier r s), out put packet s (Opkt s), out put er r or s
(Oer r s), and number of col l isions (Col l is) exper ienced in t he cur r ent sampl ing session. The
col l isions col umn has r el evance onl y f or a net wor king syst em t hat enabl es packet
col l isions, such as Et her net . A sampl e out put f r om a net st at -i command is shown her e:
$ netstat -i
Name Mtu Network Address Ipkts Ierrs Opkts
Oerrs Collis
ec0 1500 tpci merlin 34 0 125
0 0
lan0 1497 47.80 tpci_hpws4 11625 0 11625
0 0
lo0 8232 loopback localhost 206 0 206
0 0
An administ r at or can obt ain mor e specif ic inf or mat ion about one int er f ace by using t he -I
opt ion wit h a device name and a t ime int er val , specif ied in seconds, such as net st at -I ec0
30 t o obt ain specif ic inf or mat ion about t he behavior of t he ec0 (Et her net ) int er f ace over
t he l ast 30 seconds.
Data Buffers
Inf or mat ion about t he dat a buf f er s can be obt ained wit h t he net st at command's -m opt ion.
Monit or ing t he behavior of t he buf f er s is impor t ant , because t hey dir ect l y impact t he
per f or mance of TCP/IP. The out put of t he net st at -m command dif f er s depending on t he
ver sion of UNIX in use, r ef l ect ing t he dif f er ent impl ement at ions of t he TCP/IP code.
The net st at -m command out put f r om a Syst em V-based UNIX ver sion is shown in t he
f ol l owing code exampl e. Ent r ies ar e pr ovided f or t he st r eamhead, queue, message
descr ipt or t abl e (mbl ks), dat a descr ipt or t abl e (dbl ks), and t he dif f er ent cl asses of dat a
descr ipt or t abl es. The col umns show t he number of bl ocks conf igur ed (conf ig) and
cur r ent l y al l ocat ed (al l oc), t he number of col umns f r ee (f r ee), t he t ot al number of
bl ocks in use (t ot al ), t he maximum number of bl ocks t hat wer e in use at one t ime (max),
and t he number of t imes a bl ock was not avail abl e (f ail ).
$ netstat -m
streams allocation:
config alloc free total max
fail
streams 292 79 213 233 80
0
queues 1424 362 1062 516 368
0
mblks 5067 196 4871 3957 206
0
dblks 4054 196 3858 3957 206
0
class 0, 4 bytes 652 50 602 489 53
0
class 1, 16 bytes 652 2 650 408 4
0
class 2, 64 bytes 768 6 762 2720 14
0
class 3, 128 bytes 872 105 767 226 107
0
class 4, 256 bytes 548 21 527 36 22
0
class 5, 512 bytes 324 12 312 32 13
0
class 6, 1024 bytes 107 0 107 1 1
0
class 7, 2048 bytes 90 0 90 7 1
0
class 8, 4096 bytes 41 0 41 38 1
0
total configured streams memory: 1166.73KB
streams memory in use: 44.78KB
maximum streams memory used: 58.57KB
For t he administ r at or , t he f ail ur e col umn is impor t ant . It shoul d al ways show 0s. If a
l ar ger number appear s, t hat r esour ce has been over t axed and t he number of bl ocks
assigned t o t hat r esour ce shoul d be incr eased (f ol l owed by a ker nel r ebuil d and a r eboot
of t he syst em t o ef f ect t he changes).
Routing Table Information
Rout ing t abl es ar e cont inual l y updat ed t o r ef l ect connect ions t o ot her machines. To
obt ain inf or mat ion about t he r out ing t abl es, t he net st at -r and -r s opt ions ar e used. (The
l at t er gener at es st at ist ics about t he r out ing t abl es.)
The out put f r om net st at -r and net st at -r s commands ar e shown in t he f ol l owing code
exampl e. The col umns show t he dest inat ion machine, t he addr ess of t he gat eway t o be
used, a f l ag t o show whet her t he r out e is act ive (U) and whet her it l eads t o a gat eway or
a machine (H f or host ), a r ef er ence count er (Ref s) t hat specif ies how many act ive
connect ions can use t hat r out e simul t aneousl y, t he number of packet s t hat have been
sent over t he r out e (Use), and t he int er f ace name.
$ netstat -r
Routing tables
Destination Gateway Flags Refs Use
Interface
localhost localhost UH 4 10
lo0
merlin localhost UH 2 2
ec0
treijs hoytgate UG 0 0
ec0
47.80 bcarh736 U 12 21029
lan0
tpci sco4-57> netstat -rs
routing:
0 bad routing redirects
0 dynamically created routes
0 new gateways found unreachable
2 destinations found unreachable
122 uses of a wildcard route
0 routes marked doutbful
0 routes cleared of being doubtful
0 routes deleted
Protocol Statistics
St at ist ics about t he over al l behavior of net wor k pr ot ocol s can be obt ained wit h t he
net st at -s command. This usual l y pr ovides summar ies f or IP, ICMP, TCP, and UDP. The
out put f r om t his command is usef ul f or det er mining wher e an er r or in a r eceived packet
was l ocat ed, which t hen l eads t he user t o isol at e whet her t hat er r or was caused by a
sof t war e or net wor k pr obl em.
Issuing t he net st at -s command pr ovides a ver bose out put . A sampl e out put is shown in t he
f ol l owing code. The ent r ies ar e sel f -expl anat or y.
tpci_sco4-67> netstat -s
ip:
183309 total packets received
0 bad header checksums
0 with size smaller than minimum
0 with data size < data length
0 with header length < data size
0 with data length < header length
0 with unknown protocol
13477 fragments received
0 fragments dropped (dup or out of space)
0 fragments dropped after timeout
0 packets reassembled
0 packets forwarded
0 packets not forwardable
75 no routes
0 redirects sent
0 system errors during input
309 packets delivered
309 total packets sent
0 system errors during output
0 packets fragmented
0 packets not fragmentable
0 fragments created
icmp:
1768 calls to icmp_error
0 errors not generated because old message was icmp
Output histogram:
destination unreachable: 136
0 messages with bad code fields
0 messages < minimum length
0 bad checksums
0 messages with bad length
Input histogram:
destination unreachable: 68
0 message responses generated
68 messages received
68 messages sent
0 system errors during output
tcp:
9019 packets sent
6464 data packets (1137192 bytes)
4 data packets (4218 bytes) retransmitted
1670 ack-only packets (918 delayed)
0 URG only packets
0 window probe packets
163 window update packets
718 control packets
24 resets
9693 packets received
4927 acks (for 74637 bytes)
37 duplicate acks
0 acks for unsent data
5333 packets (1405271 bytes) received in-sequence
23 completely duplicate packets (28534 bytes)
0 packets with some dup. data (0 bytes duped)
38 out-of-order packets (5876 bytes)
0 packets (0 bytes) of data after window
0 window probes
134 window update packets
0 packets received after close
0 discarded for bad checksums
0 discarded for bad header offset fields
0 discarded because packet too short
0 system errors encountered during processing
224 connection requests
130 connection accepts
687 connections established (including accepts)
655 connections closed (including 0 drops)
24 embryonic connections dropped
0 failed connect and accept requests
0 resets received while established
5519 segments updated rtt (of 5624 attempts)
5 retransmit timeouts
0 connections dropped by rexmit timeout
0 persist timeouts
0 keepalive timeouts
0 keepalive probes sent
0 connections dropped by keepalive
0 connections lingered
0 linger timers expired
0 linger timers cancelled
0 linger timers aborted by signal
udp:
0 incomplete headers
0 bad data length fields
0 bad checksums
68 bad ports
125 input packets delivered
0 system errors during input
268 packets sent
The ping Utility
The ping (Packet Int er net Gr oper ) ut il it y is used t o quer y anot her syst em t o ensur e t hat
a connect ion is st il l act ive. (You may r ecal l t he r upt ime ut il it y f r om yest er day, which
al so does t his. However , r upt ime wait s f ive minut es bef or e t r ying t he r emot e, and you may
want t o know r ight away if t he connect ion is act ive.) The ping command is avail abl e on
most oper at ing syst ems t hat impl ement TCP/IP.
The ping pr ogr am oper at es by sending out an Int er net Cont r ol Message Pr ot ocol (ICMP)
echo r equest . If t he dest inat ion machine's IP sof t war e r eceives t he ICMP r equest , it issues
an echo r epl y immediat el y. The sending machine cont inues t o send an echo r equest unt il
t he ping pr ogr am is t er minat ed wit h a br eak sequence (Ct r l +C or t he Del et e key in UNIX).
Af t er t er minat ion, ping displ ays a set of st at ist ics. A sampl e ping session is shown her e:
$ ping merlin
PING merlin: 64 data bytes
64 bytes from 142.12.130.12: icmp_seq=0. time=20. ms
64 bytes from 142.12.130.12: icmp_seq=1. time=10. ms
64 bytes from 142.12.130.12: icmp_seq=2. time=10. ms
64 bytes from 142.12.130.12: icmp_seq=3. time=20. ms
64 bytes from 142.12.130.12: icmp_seq=4. time=10. ms
64 bytes from 142.12.130.12: icmp_seq=5. time=10. ms
64 bytes from 142.12.130.12: icmp_seq=6. time=10. ms
--- merling PING Statistics ---
7 packets transmitted, 7 packets received, 0% packet loss
round-trip (ms) min/avg/max = 10/12/20
An al t er nat e met hod t o invoke ping is t o pr ovide t he number of t imes you want it t o
quer y t he r emot e. Al so, you coul d pr ovide a packet l engt h as a t est . The f ol l owing
exampl e inst r uct s ping t o use 256 dat a byt e packet s and t r y f ive t imes. Using ping t o send
l ar ge packet s is one met hod of det er mining t he net wor k's behavior wit h l ar ge packet
sizes, especial l y when f r agment at ion must occur . The ping pr ogr am is al so usef ul f or
monit or ing r esponse t imes of t he net wor k, by obser ving t he r epl y t ime on packet s sent as
t he net wor k l oad (or t he machine l oad) changes. This inf or mat ion can be ver y usef ul in
opt imizat ion of TCP/IP.
$ ping merlin 256 5
PING merlin: 256 data bytes
256 bytes from 142.12.130.12: icmp_seq=0. time=20. ms
256 bytes from 142.12.130.12: icmp_seq=1. time=10. ms
256 bytes from 142.12.130.12: icmp_seq=2. time=10. ms
256 bytes from 142.12.130.12: icmp_seq=3. time=20. ms
256 bytes from 142.12.130.12: icmp_seq=4. time=10. ms
--- merling PING Statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip (ms) min/avg/max = 10/13/20
Some ol der impl ement at ions of ping simpl y r epl y wit h a message t hat t he syst em at t he
ot her end is act ive. (The message is of t he f or m X is al ive.) To obt ain t he ver bose messages
shown pr eviousl y, t he -s opt ion must be used.
The ping pr ogr am is usef ul f or diagnost ics because it pr ovides f our impor t ant pieces of
inf or mat ion: whet her t he TCP/IP sof t war e is f unct ioning cor r ect l y; whet her a l ocal
net wor k device can be addr essed (val idat ing it s addr ess); whet her a r emot e machine can
be accessed (again val idat ing t he addr ess and t est ing t he r out ing); and ver if ying t he
sof t war e on t he r emot e machine.
Most non-UNIX TCP/IP impl ement at ions pr ovide ping ut il it ies as par t of t heir suit e. For
exampl e, Figur e 7.4 shows t he Net Manage Chamel eonNFS ping ut il it y. The Chamel eon
ping sends onl y a singl e ICMP packet inst ead of a cont inuous st r eam, but is usef ul f or
ver if ying t hat a r emot e machine is r esponding.
Figur e 7.4. Chamel eonNFS uses a ping ut il it y t o send a singl e packet .
Windows 95 has a ping ut il it y buil t int o t he dist r ibut ion sof t war e, but it is DOS-based and
doesn't use t he Windows 95 GUI. Figur e 7.5 shows t he Windows 95 ping ut il it y used t o ping
anot her machine on t he net wor k.
Figur e 7.5. The Windows 95 ping ut il it y is DOS-based.
Tracing a Connection
Ther e is a t r acing opt ion buil t int o TCP/IP. When simpl er met hods have f ail ed, t his opt ion
can be used t o t r ace a pr obl em. To act ivat e t he t r ace, a syst em cal l is sent t o t he end
point t hat t ur ns on a f l ag. Most TCP/IP impl ement at ions enabl e t he t r acing opt ion t o be
t ur ned on f r om t he command l ine using t he -d (debug) opt ion. When t r acing is t ur ned on,
al l act ivit ies ar e echoed t o a buf f er or t o t he scr een, depending on t he syst em
conf igur at ion.
The out put f r om t he TCP/IP t r acing opt ion is examined using t he pr ogr am t r pt (t r ace
r epor t ). A specif ic connect ion can be specif ied, or al l behavior passing t hr ough TCP/IP can
be displ ayed. The out put f r om t r pt is ver bose and of l it t l e int er est t o most user s.
Summary
This chapt er has shown you t he basic administ r at ion pr ogr ams used wit h TCP/IP, as wel l as
t he conf igur at ion f il es t hat ar e necessar y in or der t o use symbol ic names. Al t hough t his
inf or mat ion is not l ikel y t o be used by most user s, knowing t he avail abl e t ool s and t he
t ype of diagnost ics t hat can be pr oduced is usef ul in bet t er under st anding TCP/IP.
Q&A
Al l t he TCP/IP pr ot ocol s avail abl e t o you ar e l ist ed in a syst em conf igur at ion f il e.
Which f il e is t his?
Al l TCP/IP pr ot ocol s ar e l ist ed in /et c/ pr ot ocol s. The f il e l ist s t he pr ot ocol name and
t he cor r esponding pr ot ocol number .
What is a l oopback dr iver used f or ?
The l oopback dr iver is a vir t ual cir cuit wit hin t he host machine, avoiding al l cont act
wit h t he physical net wor k it sel f . The most common use of a l oopback dr iver is as a
diagnost ic. By sending dat a t o t he l oopback dr iver , you can make sur e t he pr ot ocol s ar e
wor king cor r ect l y on your machine. Wit hout t his capabil it y, it woul d be dif f icul t t o
separ at e net wor k pr obl ems and sof t war e conf igur at ion pr obl ems.
What does t he f ol l owing excer pt f r om a net st at -a command t el l you?
Proto Recv-Q Send-Q Local Address Foreign Address
(state)
ip 0 0 *.* *.*
tcp 0 1024 tpci.login merlin.1034
ESTABL.
tcp 8756 0 tpci.1035 treijs.1036
ESTABL.
tcp 0 0 tpci.1021 reboc.1024
TIME_WAIT
tcp 0 0 *.1028 *.*
LISTEN
tcp 0 0 *.6000 *.*
LISTEN
This ext r act shows t her e ar e t wo est abl ished TCP connect ions (t o mer l in.1034 and
t r eijs.1036), one of which is sending inf or mat ion and t he ot her r eceiving. The connect ion
t o r eboc.1024 is wait ing t o hang up. Ther e ar e t wo por t s wait ing f or a connect ion.
What is t he ut il it y ping used f or ?
The ping ut il it y is used t o quer y anot her syst em. It sends an ICMP message t o t he r emot e
and wait s f or a r epl y. The ping command is ver y usef ul f or t est ing connect ions.
What command gives you over al l st at ist ics about t he net wor k pr ot ocol s r unning
on your syst em?
One of t he best summar ies is obt ained wit h t he net st at -s command.


I TCP/IP and Ot her Pr ot ocol s
I LAN Layer s
I Net BIOS and TCP/IP
I XNS and TCP/IP
I IPX and UDP
I ARCnet and TCP/IP
I FDDI Net wor ks
I X.25 and IP
I ISDN and TCP/IP
I Swit ched Mul t i-Megabit Dat a Ser vices and IP
I Asynchr onous Tr ansf er Mode (ATM) and BISDN
I Windows 95 and TCP/IP
I Opt ional TCP/IP Ser vices
I Act ive User s
I Char act er Gener at or
I Dayt ime
I Discar d
I Echo
I Quot e of t he Day
I Time
I Using t he Opt ional Ser vices
I Summar y
I Q&A
I Quiz
8
TCP/IP and Networks
In t he pr evious seven days you have seen TCP/IP and it s associat ed pr ot ocol s cover ed in
consider abl e dept h. It is now t ime t o begin l ooking at TCP/IP in a br oader sense. Today
you l ear n how TCP/IP can oper at e wit h ot her pr ot ocol s in a net wor ked syst em. You al so
l ear n about pr ot ocol s t hat don't use TCP/IP but ar e commonl y encount er ed.
It is usef ul t o under st and how TCP/IP oper at es in conjunct ion wit h ot her pr ot ocol s so
t hat t he management of TCP/IP is cl ear er (you l ear n about managing a TCP/IP net wor k
in t he next f ew days). You might f ind t hat some mat er ial t oday is r epeat ed f r om ear l ier
days, or r ephr ased sl ight l y t o pr esent a dif f er ent appr oach t o t he subject . In a sense,
t oday act s as a summar y, al beit incompl et e, of t he TCP/IP syst em as a whol e.
To r ound out t he day, I l ook at t he miscel l aneous opt ional ser vices pr ovided t hr ough
TCP/IP. Most ar e dedicat ed t o a simpl e t ask, but t hey do ser ve t heir pur pose wel l and use
TCP/IP, hence t heir incl usion her e.
TCP/IP and Other Protocols
TCP/IP is not of t en f ound as a sol e pr ot ocol . It is usual l y one of sever al pr ot ocol s used
in any given net wor k. Ther ef or e, t he int er act ions bet ween TCP/IP (and it s associat ed
pr ot ocol s) and t he ot her pr ot ocol s t hat might be wor king wit h it must be under st ood. It
is easiest t o begin l ooking at t his subject f r om a l ocal ar ea net wor k point of view and
t hen expand t hat view t o cover int er net wor ks.
The l ayer s of a TCP/IP pr ot ocol , as wel l as most ot her OSI-model pr ot ocol s, ar e designed
t o be independent of each ot her , enabl ing mixing of pr ot ocol s. When a message is t o be
sent over t he net wor k t o a r emot e machine, each pr ot ocol l ayer buil ds on t he packet of
inf or mat ion sent f r om t he l ayer above, adding it s own header and t hen passing t he
packet t o t he next l ower l ayer . Af t er being r eceived over t he net wor k (packaged in
what ever net wor k f or mat is r equir ed), t he r eceiving machine passes t he packet back up
t he l ayer s, r emoving t he header inf or mat ion one l ayer at a t ime.
Repl acing any l ayer in t he pr ot ocol st ack r equir es t hat t he new pr ot ocol s can
int er net wor k wit h t he ot her l ayer s, as wel l as per f or m al l t he r equir ed f unct ions of
t hat l ayer (f or exampl e, dupl icat ing t he ser vices of t he r epl aced pr ot ocol ). Al so,
per f or ming dupl icat e oper at ions in mor e t han one l ayer (r edundant oper at ions) shoul d
be avoided f or obvious r easons.
To examine t he int er net wor king of t he l ayer s and t he subst it ut ion or addit ion of
ot her s, a simpl e inst al l at ion can be used as a st ar t ing point . Figur e 8.1 shows a simpl e
l ayer ed ar chit ect ur e using TCP and IP wit h t he Et her net net wor k. Figur e 8.1 al so shows
t he assembl y of Et her net packet s as t hey pass f r om l ayer t o l ayer .
Figur e 8.1. A simpl e l ayer ed ar chit ect ur e.
As you saw ear l ier in t his book, t he pr ocess begins wit h a message of some f or m f r om an
Upper Layer Pr ot ocol (ULP) which it sel f is passing a message f r om an appl icat ion. As t he
message is passed t o TCP, it adds it s own header inf or mat ion and passes t o t he IP l ayer ,
which does t he same. When t he IP message is passed t o t he Et her net l ayer , Et her net adds
it s own inf or mat ion at t he f r ont and back of t he message and sends t he message out over
t he net wor k.
The oper at ing syst em it sel f is not a singl e l ayer but r uns
t hr oughout t he ent ir e l ayer ed ar chit ect ur e wit h connect ions
t o each l ayer . The int er f aces bet ween t he each l ayer 's
pr ot ocol s dif f er depending on t he host machine, but it is
convenient t o ignor e t he oper at ing syst em's inf l uence f or
simpl icit y.
Al t hough t his simpl e model might seem ideal , in pr act ice it has a f ew pr obl ems. Most
impor t ant l y, it r equir es IP t o int er f ace dir ect l y wit h t he Et her net l ayer . This int er f ace
is not a cl ean one; it has many connect ions t hat br eak f r om t he ideal l ayer ed
ar chit ect ur e.
LAN Layers
To expand on t he l ayer ed syst em r equir es a bet t er under st anding of t he int er f aces t o
t he net wor k l ayer in a LAN. Figur e 8.2 shows an expanded l ayer ar chit ect ur e f or a LAN.
This t ype of ar chit ect ur e appl ies f or col l ision sense mul t ipl e access (CSMA) and
col l ision det ect (CD) net wor ks such as Et her net .
Figur e 8.2. Net wor k ar chit ect ur e.
The LAN invol ves some addit ional l ayer s. The Logical Link Cont r ol (LLC) l ayer is an
int er f ace bet ween t he IP l ayer and t he net wor k l ayer s. Ther e ar e sever al kinds of LLC
conf igur at ions, but it is suf f icient at t his point t o know it s basic r ol e as a buf f er
bet ween t he net wor k and IP l ayer s eit her as a simpl e syst em f or a connect ionl ess ser vice
or as an el abor at e syst em f or a connect ion-based ser vice. LLC is usual l y used wit h t he
High-Level Dat a Link Cont r ol (HDLC) l ink st andar d. For connect ionl ess ser vice, t his
uses an unnumbered information (UI) message f r ame, wher eas connect ion-based ser vices can
use t he asynchronous balanced mode (ABM) message f r ame, bot h suppor t ed by HDLC. The
conf igur at ion of LLC wit h r espect t o TCP/IP is impor t ant .
The Media Access Cont r ol (MAC) l ayer was ment ioned br ief l y on Day 2, "TCP/IP and t he
Int er net ." MAC is r esponsibl e f or managing t r af f ic on t he net wor k, such as col l ision
det ect ion and t r ansmission t imes. It al so handl es t imer s and r et r ansmission f unct ions.
MAC is independent of t he net wor k medium but is dependent on t he pr ot ocol used on t he
net wor k.
The physical l ayer in t he Net wor k ar chit ect ur e is composed of sever al ser vices. The
At t achment Unit Int er f ace (AUI) pr ovides an at t achment bet ween t he machine's
physical l ayer and t he net wor k medium. Typical l y, t he AUI is wher e t he net wor k por t s
or jacks ar e l ocat ed.
The Medium At t achment Unit (MAU) is composed of t wo par t s: t he Physical Medium
At t achment (PMA) and t he Medium Dependent Int er f ace (MDI), bot h of which can be
consider ed as separ at e par t s as shown in t he f igur e. The MAU is r esponsibl e f or managing
t he connect ion of t he machine t o t he LAN medium it sel f , as wel l as pr oviding basic dat a
int egr it y checking and net wor k medium monit or ing. The MAU has f unct ions t hat check
t he signal qual it y f r om t he net wor k and t est r out ines f or ver if ying t he net wor k's
cor r ect oper at ion.
When t hese l ayer s ar e added t o t he l ayer ed ar chit ect ur e f or a pr ot ocol st ack, t he IP-
Et her net l ayer is separ at ed. This is shown in Figur e 8.3. This t ype of conf igur at ion is
mor e common t han t he one shown in Figur e 8.1 and is usual l y cal l ed t he IP/802
conf igur at ion (because Et her net is def ined by t he IEEE 802 specif icat ion).
Figur e 8.3. TCP/IP wit h LLC/MAC.
The IP/802 LAN can be connect ionl ess using a simpl e f or m of LLC cal l ed LLC Type 1,
which suppor t s unnumber ed inf or mat ion (UI). The LLC and MAC l ayer s hel p separ at e IP
f r om t he physical l ayer . Mor e header s ar e added t o t he message packet , but t hese have
usef ul inf or mat ion. The LLC header has bot h sour ce and dest inat ion ser vice access
point s (SAP) in it t o ident if y t he l ayer s above.
UDP is f r equent l y used inst ead of TCP in t his t ype of net wor k. UDP is not as compl ex as
TCP, so t he ent ir e net wor k's compl exit y is r educed. However , UDP has no message
int egr it y f unct ional it y buil t in, so a dif f er ent f or m of LLC (cal l ed LLC Type 2) is used
t hat impl ement s t hese f unct ions. LLC Type 2 pr ovides t he dat a int egr it y f unct ional it y
t hat TCP usual l y pr ovides, such as sequencing, t r ansf er window management , and f l ow
cont r ol . The disadvant age is t hat t hese f unct ions ar e now bel ow t he IP l ayer , inst ead
of above it . In case of f at al pr obl ems wit h t he LLC l ayer , t his can r esul t in pr obl ems
t hat must be deal t wit h in t he appl icat ion l ayer it sel f .
The dif f er ences bet ween TCP and LLC Type 1 ver sus UDP
and LLC Type 2 must be car ef ul l y weighed by a syst em
administ r at or . The TCP/LLC 1 combinat ion is mor e compl ex t han
UDP/LLC 2 but of f er s excel l ent r el iabil it y and int egr it y,
wher eas UDP/LLC 2 is bet t er f or high-t hr oughput net wor ks. In
some cases, UDP/LLC 2 r esul t s in dupl icat ed f unct ions, because
t he LLC ver sions dif f er consider abl y among vendor s.
NetBIOS and TCP/IP
A popul ar PC-or ient ed net wor k oper at ing syst em is Net BIOS, which can be cl eanl y
int egr at ed wit h TCP/IP. Figur e 8.4 shows t he net wor k ar chit ect ur e f or t his kind of LAN.
Net BIOS r esides above t he TCP or UDP pr ot ocol , al t hough it usual l y has sol id l inks
int o t hat l ayer (so t he t wo l ayer s cannot be cl eanl y separ at ed). Net BIOS act s t o
connect appl icat ions t oget her in t he upper l ayer s, pr oviding messaging and r esour ce
al l ocat ion.
Figur e 8.4. The Net BIOS Net wor k ar chit ect ur e.
Thr ee Int er net por t number s ar e al l ocat ed f or Net BIOS. These ar e f or t he Net BIOS
name ser vice (por t 137), dat agr am ser vice (por t 138), and session ser vice (por t 139). Ther e
is al so t he pr ovision f or a mapping bet ween Int er net 's Domain Name Ser vice (DNS) and
t he Net BIOS Name Ser ver (NBNS). (DNS is cover ed in det ail on Day 11, "Domain Name
Ser vice.") The Net BIOS Name Ser ver is used t o ident if y PCs t hat oper at e in a Net BIOS
ar ea. In t he int er f ace bet ween Net BIOS and TCP, a mapping bet ween t he names is used t o
pr oduce t he DNS name.
IP can be conf igur ed t o r un above Net BIOS, el iminat ing TCP or UDP ent ir el y and
r unning Net BIOS as a connect ionl ess ser vice. In t his case, Net BIOS t akes over t he
f unct ions of t he TCP/UDP l ayer , and t he upper l ayer pr ot ocol s must have t he dat a
int egr it y, packet sequencing, and f l ow cont r ol f unct ions. This is shown in Figur e 8.5. In
t his ar chit ect ur e, Net BIOS encapsul at es IP dat agr ams. St r ong mapping bet ween IP and
Net BIOS is necessar y so t hat Net BIOS packet s r ef l ect IP addr esses. (To do t his, Net BIOS
codes t he names as IP.nnn.nnn.nnn.nnn.)
Figur e 8.5. Running IP above Net BIOS.
This t ype of net wor k r equir es t hat t he upper l ayer pr ot ocol s (ULPs) handl e al l t he
necessar y f eat ur es of t he TCP pr ot ocol , but t he advant age is t hat t he net wor k
ar chit ect ur e is simpl e and ef f icient . For some net wor ks, t his t ype of appr oach is wel l
suit ed, al t hough t he devel opment of suit abl e ULPs can be pr obl emat ic at t imes.
XNS and TCP/IP
The Xer ox Net wor k Syst em (XNS) was widel y used in t he past and st il l r et ains a
r easonabl e per cent age of net wor k use. XNS is popul ar because Xer ox r el eased t he code
t o t he publ ic domain, hence making it a cost -ef f ect ive net wor k syst em. In most cases, XNS
pr ot ocol s wer e designed t o wor k wit h Xer ox's Et her net , as wel l . XNS now appear s in
sever al commer cial net wor k sof t war e packages.
XNS can use IP, as shown in Figur e 8.6. The Sequenced Packet Pr ot ocol (SPP) is above t he
IP l ayer , pr oviding some TCP f unct ion, al t hough it is not as compl et e a pr ot ocol . In t he
ULP l ayer is t he Cour ier pr ot ocol , which pr ovides pr esent at ion and session l ayer
ser vices.
Figur e 8.6. The XNS Net wor k ar chit ect ur e.
XNS uses t he t er m Internet Transport Protocols t o r ef er t o t he set of pr ot ocol s used,
incl uding IP. Among t he pr ot ocol s is t he Rout ing Inf or mat ion Pr ot ocol (RIP) and an
er r or pr ot ocol simil ar t o t he Int er net Cont r ol Message Pr ot ocol (ICMP).
IPX and UDP
Novel l 's Net War e net wor king pr oduct has a pr ot ocol simil ar t o IP cal l ed t he Int er net
Packet Exchange (IPX), which is based on Xer ox's XNS. The IPX ar chit ect ur e is shown in
Figur e 8.7. IPX usual l y uses UDP f or a connect ionl ess pr ot ocol , al t hough TCP can be
used when combined wit h LLC Type 1.
Figur e 8.7. The IPX Net wor k ar chit ect ur e.
The st acking of t he l ayer s (wit h IPX above UDP) ensur es t hat t he UDP and IP header s
ar e not af f ect ed, wit h t he IPX inf or mat ion encapsul at ed as par t of t he usual message
pr ocess. As wit h ot her net wor k pr ot ocol s, a mapping is necessar y bet ween t he IP addr ess
and t he IPX addr esses. IPX uses net wor k and host number s of 4 and 6 byt es, r espect ivel y.
These ar e conver t ed as t hey ar e passed t o UDP.
It is possibl e t o r econf igur e t he net wor k t o use IPX net wor ks by using TCP inst ead of
UDP and subst it ut ing t he connect ionl ess LLC Type 1 pr ot ocol . This r esul t s in t he
ar chit ect ur e shown in Figur e 8.8. When using t his l ayer ar chit ect ur e, IP addr esses ar e
mapped using ARP.
Figur e 8.8. An IPX-based Net wor k ar chit ect ur e.
ARCnet and TCP/IP
ARCnet is widel y used f or LANs and has an Int er net RFC f or using it wit h IP. The
ar chit ect ur e is simil ar t o t hat of t he IPX-based net wor k but wit h ARCnet r epl acing IPX,
as shown in Figur e 8.9. Messages passed down f r om IP ar e encapsul at ed int o ARCnet
dat agr ams.
Figur e 8.9. The ARCnet -based Net wor k ar chit ect ur e.
A special pl acement of t he IP dat agr am behind t he cl ient dat a ar ea of t he ARCnet
header ensur es t hat IP compat ibil it y is maint ained if t he message must pass out of t he
ARCnet net wor k (t hr ough a conver t er ). IP addr esses ar e mapped t o ARCnet addr esses
using ARP. The pr ot ocol al so suppor t s RARP t o some ext ent .
FDDI Networks
The Fiber Dist r ibut ed Dat a Int er f ace (FDDI) is an ANSI-def ined high-speed net wor k t hat
uses f iber -opt ic cabl e as a t r anspor t medium. FDDI is gaining st r ing suppor t because of
t he high t hr oughout t hat can be achieved. For TCP/IP, FDDI uses a l ayer ed ar chit ect ur e
l ike t he ot her net wor ks discussed. FDDI dif f er s sl ight l y f r om ot her media in t hat t her e
ar e t wo subl ayer s f or t he physical l ayer .
FDDI's addr essing scheme is simil ar t o ot her Et her net net wor ks, r equir ing a simpl e
mapping, as seen wit h t he Et her net syst em. IP and ARP can bot h be used over FDDI. IP is
used wit h t he LLC Type 1 connect ionl ess ser vice.
The f r ame size f or FDDI is set t o 4,500 byt es, incl uding t he header and ot her f r aming
inf or mat ion. Af t er t hat is t aken int o account , t her e ar e 4,470 byt es avail abl e f or dat a.
(The Int er net RFC f or FDDI def ines 4,096 byt es f or dat a and 256 byt es f or header l ayer s
above t he MAC l ayer .) This l ar ge packet size can cause pr obl ems f or some gat eways, so
r out ing f or FDDI packet s must be car ef ul l y chosen t o pr event t r uncat ion or cor r upt ion
of t he packet by a gat eway t hat can't handl e t he l ar ge f r ame size. In case of doubt ,
FDDI packet s shoul d be r educed in size t o 576 dat a byt es.
X.25 and IP
X.25 net wor ks modif y t he net wor k ar chit ect ur e by using an OSI TP4 l ayer on t op of IP,
and t he X.25 Packet Layer Pr ocedur es (PLP) l ayer bel ow IP. This is shown in Figur e 8.10.
TP4 is a TCP-l ike pr ot ocol t hat does not use por t ident if ier s. The dest inat ion and sour ce
f iel ds in t he header ar e t he transport service access points (TSAPs). TP4 is mor e compl ex
t han TCP, which somet imes wor ks against it .
Figur e 8.10. The X.25-based Net wor k ar chit ect ur e.
X.25 is not of t en used on a LAN, but it is used as a connect ion t o a packet -swit ched
net wor k. An Int er net RFC def ines t he r ul es f or X.25 IP-based packet swit ching,
incl uding t he l imit s f or IP dat agr am sizes (576 byt es) and vir t ual cir cuit s.
ISDN and TCP/IP
The Int egr at ed Ser vices Digit al Net wor k (ISDN) pr ovides packet -swit ched TCP/IP
net wor ks. The ar chit ect ur e is shown in Figur e 8.11. IP is not in t he st ack because it is
usual l y incor por at ed int o CLNP. (Bot h TCP and IP can be used wit h ISDN inst ead of OSI
TP4 and CLNP, but t he ISDN ver sions ar e opt imized f or t hat net wor k.)
Figur e 8.11. The ISDN-based Net wor k ar chit ect ur e.
ISDN uses a mor e compl ex ar chit ect ur e t han most net wor ks, r epl acing gat eways and
r out er s wit h terminal adapters and ISDN nodes. These per f or m t he equival ent f unct ions
but have a mor e r igid (and compl ex) int er nal ar chit ect ur e. The det ail s ar e not r el evant
her e, so t he int er est ed r eader is r ef er r ed t o a good ISDN book.
Switched Multi-Megabit Data Services and IP
The Swit ched Mul t i-Megabit Dat a Ser vices (SMDS) syst em is a publ ic packet -swit ched
connect ionl ess ser vice t hat pr ovides high t hr oughput wit h l ar ge packet sizes (up t o 9188
dat a byt es). SMDS uses a subscr iber -t o-net wor k and net wor k-t o-subscr iber access
mechanism f or f l ow cont r ol . SMDS wor ks wit h IP by int er f acing t he SMDS t o t he LLC
l ayer .
SMDS using IP suppor t s mul t ipl e l ogical IP subnet wor ks (LISs), which can be managed
separ at el y but t r eat ed as a singl e unit by SMDS. This met hod r equir es al l t he
subnet wor ks t o have t o same IP addr ess. The ar chit ect ur e of t he SMDS l ayer s is quit e
compl ex, so t hey ar e not cover ed in det ail her e. SMDS uses LLC Type 1 f r ames.
Asynchronous Transfer Mode (ATM) and BISDN
Two new pr ot ocol s f or high-speed int er net wor ks t hat ar e becoming popul ar ar e
Asynchr onous Tr ansf er Mode (ATM) and Br oadband ISDN (BISDN). The ar chit ect ur e on
t he user 's machine is simil ar t o t he TCP/IP ar chit ect ur es discussed ear l ier , al t hough
addit ional l ayer s can be added t o pr ovide new ser vices, such as video and sound
capabil it ies.
The r out er , gat eway, or ot her device t hat accesses t he high-speed net wor k is mor e
compl ex as wel l . Cal l ed a terminal adapter (as wit h ISDN), it pr ovides a sophist icat ed
int er f ace bet ween user l ayer s and adapt at ion l ayer s, which ar e appl icat ion-specif ic.
Fr om t he t er minal adapt er , t r af f ic is passed t o t he ATM ser vice, which pr ovides
swit ching and mul t ipl exing ser vices.
Windows 95 and TCP/IP
Because Windows 95 is supposed t o become t he dominant oper at ing syst em on PC machines
r unning a DOS or Windows oper at ing syst em, it is wor t h t aking a quick l ook at how
Windows 95 int egr at es net wor king sof t war e int o it s ker nel . The appr oach used by
Windows 95 is simil ar t o t hat of Windows NT and OS/2, so t he knowl edge is usef ul f or
many oper at ing syst ems on common cl ient devices in t oday's LANs.
Windows 95 r ef ines t he net wor k ar chit ect ur e used in Windows f or Wor kgr oups and
Windows NT, r esul t ing in bet t er per f or mance and r el iabil it y, as wel l as cat er ing t o t he
demands of dif f er ent net wor k r equir ement s such as mul t ipl e pr ot ocol suppor t . Because
Windows 95 suppor t s many dif f er ent net wor k pr ot ocol s in 16- and 32-bit Vir t ual Mode
Dr iver (VxD) ver sions, t he ar chit ect ur e must pr ovide t he f l exibil it y t o accommodat e a
number of st r uct ur es.
The Windows 95 ar chit ect ur e is l ayer ed; a l ayer ed ar chit ect ur e is t he most common
net wor king st r uct ur e (such as OSI and TCP/IP). The net wor k ar chit ect ur e used in
Windows 95 is known as Micr osof t 's Windows Open Ser vices Ar chit ect ur e (WOSA). WOSA
was devel oped t o enabl e appl icat ions t o wor k wit h sever al dif f er ent net wor k t ypes, and
it incl udes a set of int er f aces designed t o enabl e coexist ence of sever al net wor k
component s.
The net wor king sof t war e component s of Windows 95 ar e shown in t heir r espect ive
l ayer s in Figur e 8.12. Many of t he net wor k component s ar e f amil iar f r om ear l ier
ver sions of Windows f or Wor kgr oups, Windows NT, or ot her oper at ing syst ems and
communicat ions pr ot ocol s. I l ook at each l ayer in t he Windows 95 ar chit ect ur e in a
l it t l e mor e det ail so t hat t he f unct ion of each component is bet t er under st ood. Because
32-bit appl icat ions ar e becoming dominant wit h Windows 95 and Windows NT, I'l l l ook at
t hem in t his sect ion. Ol der 16-bit appl icat ions ar e t r eat ed sl ight l y dif f er ent l y, but t he
pr incipl es ar e t he same.
Figur e 8.12. The Windows 95 net wor king sof t war e ar chit ect ur e showing t he
component s.
G API: The st andar d Win32 Appl icat ion Pr ogr amming Int er f ace (API, t he same syst em
used wit h Windows NT). The API handl es r emot e f il e oper at ions and r emot e
r esour ces (pr int er s and ot her devices). The Win32 APIs ar e used f or pr ogr amming
appl icat ions.
G Mul t ipl e Pr ovider Rout er (MPR): The MPR r out es al l net wor k oper at ions f or
Windows 95, as wel l as impl ement ing net wor k f unct ions common t o al l net wor k
t ypes. Win32 APIs communicat e dir ect or y wit h t he MPR, al t hough some can be
r out ed st r aight t hr ough. The MPR is a 32-bit pr ot ect ed mode DLL.
G Net wor k Pr ovider : The net wor k pr ovider impl ement s t he net wor k ser vice
pr ovider int er f ace. Onl y t he MPR can communicat e wit h t he net wor k pr ovider .
The net wor k pr ovider is a 32-bit pr ot ect ed mode DLL.
G IFS Manager : The IFS Manager r out es f il esyst em r equest s t o t he pr oper
f il esyst em dr iver (FSD). The IFS Manager can be cal l ed dir ect l y by net wor k
pr ovider s.
G Net wor k Fil esyst em Dr iver (FSD): The FSD impl ement s t he par t icul ar r emot e
f il esyst em char act er ist ics. The FSD can be used by t he IFS Manager when t he
f il esyst em of t he l ocal and r emot e machines mat ch. The FSD is a 32-bit pr ot ect ed
mode VxD (vir t ual device dr iver ).
G Net wor k Tr anspor t : The net wor k t r anspor t is a VxD t hat impl ement s t he device-
specif ic net wor k t r anspor t pr ot ocol . Mul t ipl e net wor k t r anspor t s can be act ive
at a t ime. The net wor k FSD int er f aces wit h t he net wor k t r anspor t , usual l y wit h
a one-t o-one mapping, al t hough t hat is not necessar il y t he case.
G Net wor k Dr iver Int er f ace Specif icat ion (NDIS): A vendor -independent
sof t war e specif icat ion t hat def ines int er act ions bet ween t he net wor k t r anspor t
and device dr iver . Windows 95 suppor t s bot h 32-bit and 16-bit NDIS ver sions.
G Net wor k Adapt er Dr iver : The net wor k adapt er dr iver VxD cont r ol s t he act ual
net wor k har dwar e device. NDIS communicat es wit h t he dr iver , which sends
packet s over t he net wor k. Windows 95 uses Media Access Cont r ol (MAC) dr iver s.
One of t he key f eat ur es of Windows 95 is t he incl usion of suppor t f or mul t ipl e
concur r ent pr ot ocol s. The def aul t pr ot ocol is Net War e's IPX/SPX. Al so incl uded ar e
Net BIOS and Net BEUI dr iver s, and a compl et e 32-bit VxD f or TCP/IP. Al l t hese dr iver s
ar e pl ug-and-pl ay enabl ed, al l owing dynamic l oading and unl oading.
Windows 95's suppor t f or mul t ipl e pr ot ocol s is achieved t hr ough t he Net wor k Dr iver
Int er f ace Specif icat ion (NDIS), which is a super set of t he NDIS used in Windows f or
Wor kgr oups and Windows NT. The NDIS 3.1 dr iver has t hr ee par t s: t he pr ot ocol it sel f
(which can be impl ement ed by t hir d-par t y vendor s) and pr ot ocol manager , t he MAC or
mini-por t , and t he mini-por t wr apper . The NDIS pr ot ocol manager l oads and unl oads
pr ot ocol s as needed.
The ver sion of NDIS incl uded wit h Windows 95 adds pl ug-and-pl ay enhancement s and
new mini-dr iver s. The pl ug-and-pl ay capabil it y is added t o t he pr ot ocol manager and t he
Media Access Cont r ol (MAC) l ayer , l et t ing net wor k dr iver s l oad and unl oad
dynamical l y. The mini-dr iver (which is compat ibl e wit h t he mini-dr iver model s used in
Windows NT 3.5) decr eases t he amount of code t hat must be wr it t en t o suppor t a
net wor k adapt er .
Windows 95 enabl es suppor t f or many net wor k ser ver s concur r ent l y. This is an
impr ovement over Windows f or Wor kgr oups 3.11, which enabl ed onl y it s own net wor k
and one addit ional net wor k. The ser ver suppor t of Windows 95 is pr ovided by t he
Net wor k Pr ovider Int er f ace (NPI). Using mul t ipl e net wor k pr ot ocol s at t he same t ime,
you can set up a Windows 95 machine t o use TCP/IP f or UNIX net wor ks, and Net BEUI or
IPX/SPX f or l ocal PC net wor ks, if you want . Al t er nat ivel y, as you see on Day 10,
"Set t ing Up a Sampl e TCP/IP Net wor k: DOS and Windows Cl ient s," you can set Windows
95 t o be a pur e TCP/IP-based machine.
Optional TCP/IP Services
TCP/IP net wor ks of f er a number of opt ional ser vices t hat user s and appl icat ions can use.
Al l t hese opt ional ser vices have st r ict def init ions f or t heir pr ot ocol s. These opt ional
ser vices and t heir assigned por t number s ar e shown in Tabl e 8.1.
Tabl e 8.1. Opt ional TCP/IP ser vices.
Service Port Description
Act ive User s 11 Ret ur ns t he names of al l user s on t he r emot e syst em
Char act er Gener at or 19 Ret ur ns al l pr int abl e ASCII char act er s
Dayt ime 13
Ret ur ns t he dat e and t ime, day of t he week, and mont h of
t he year
Discar d 9 Discar ds al l r eceived messages
Echo 7 Ret ur ns any messages
Quot e of t he Day 17 Ret ur ns a quot at ion
Time 37 Ret ur ns t he t ime since Januar y 1, 1900 (in seconds)
Active Users
The Act ive User s ser vice r et ur ns a message t o t he or iginat ing user t hat cont ains a l ist
of al l user s cur r ent l y act ive on t he r emot e machine. The behavior of t he TCP and UDP
ver sions is t he same. When r equest ed, t he Act ive User s ser vice monit or s por t 11 and, upon
est abl ishment of a connect ion, r esponds wit h a l ist of t he cur r ent l y act ive user s and
t hen cl oses t he por t . UDP sends a dat agr am, and TCP uses t he connect ion it sel f .
Character Generator
The Char act er Gener at or ser vice is designed t o send a set of ASCII char act er s. Upon
r eceipt of a dat agr am (t he cont ent s of which ar e ignor ed), t he Char act er Gener at or
ser vice r et ur ns a l ist of al l pr int abl e ASCII char act er s. The behavior of t he TCP and
UDP ver sions of t he Char act er Gener at or ar e sl ight l y dif f er ent .
The TCP Char act er Gener at or monit or s por t 19, and upon connect ion ignor es al l input
and sends a st r eam of char act er s back unt il t he connect ion is br oken. The or der of
char act er s is f ixed. The UDP Char act er Gener at or ser vice monit or s por t 19 f or an
incoming dat agr am (r emember , UDP doesn't cr eat e connect ions) and r esponds wit h a
dat agr am cont aining a r andom number of char act er s. Up t o 512 char act er s can be sent .
Al t hough t his ser vice might seem usel ess, it does have diagnost ic pur poses. It can ensur e
t hat a net wor k can t r ansf er al l 95 pr int abl e ASCII char act er s pr oper l y, and it can al so
be used t o t est pr int er s f or t heir capabil it y t o pr int al l t he char act er s.
Daytime
The Dayt ime ser vice r et ur ns a message wit h t he cur r ent dat e and t ime. The f or mat it
uses is t he day of t he week, mont h of t he year , day of t he mont h, t ime, and t he year . Time
is specif ied in a HH:MM:SS f or mat . Each f iel d is separ at ed by spaces t o enabl e par sing of
t he cont ent s.
Bot h TCP and UDP ver sions monit or por t 13 and, upon r eceipt of a dat agr am, r et ur n t he
message. The Dayt ime ser vice can be used f or sever al pur poses, incl uding set t ing syst em
cal endar s and cl ocks t o minimize var iat ions. It al so can be used by appl icat ions.
Discard
The Discar d ser vice simpl y discar ds ever yt hing it r eceives. TCP wait s f or a connect ion on
por t 9, wher eas UDP r eceives dat agr ams t hr ough t hat por t . Anyt hing incoming is
ignor ed. No r esponses ar e sent .
The Discar d ser vice might seem point l ess, but it can be usef ul f or r out ing t est messages
dur ing syst em set up and conf igur at ion. It can al so be used by appl icat ions in pl ace of a
discar d ser vice of t he oper at ing syst em (such as /dev/nul l in UNIX).
Echo
The Echo ser vice r et ur ns what ever it r eceives. It is cal l ed t hr ough por t 7. Wit h TCP, it
simpl y r et ur ns what ever dat a comes down t he connect ion, wher eas UDP r et ur ns an
ident ical dat agr am (except f or t he sour ce and dest inat ion addr esses). The echoes
cont inue unt il t he por t connect ion is br oken or no dat agr ams ar e r eceived.
The Echo ser vice pr ovides ver y good diagnost ics about t he pr oper f unct ioning of t he
net wor k and t he pr ot ocol s t hemsel ves. The r el iabil it y of t r ansmissions can be t est ed
t his way, t oo. Tur nar ound t ime f r om sending t o r eceiving t he echo pr ovides usef ul
measur ement s of r esponse t imes and l at ency wit hin t he net wor k.
Quote of the Day
The Quot e of t he Day ser vice does as it s name impl ies. It r et ur ns a quot at ion f r om a f il e
of quot es, r andoml y sel ect ing one a day when a r equest ar r ives on por t 17. If a sour ce
f il e of quot at ions is not avail abl e, t he ser vice f ail s.
Time
The Time ser vice r et ur ns t he number of seconds t hat have el apsed since Januar y 1, 1990.
Por t 37 is used t o l ist ed f or a r equest (TCP) or r eceive an incoming dat agr am (UDP).
When a r equest is r eceived, t he t ime is sent as a 32-bit binar y number . It is up t o t he
r eceiving appl icat ion t o conver t t he number t o a usef ul f igur e.
The Time ser vice is of t en used f or synchr onizing net wor k machines or f or set t ing cl ocks
wit hin an appl icat ion.
Using the Optional Services
As al r eady ment ioned, t he opt ional ser vices can be accessed f r om an appl icat ion. User s
can dir ect l y access t heir ser vice of choice (assuming it is suppor t ed) by using Tel net . A
simpl e exampl e is shown her e:
$ telnet merlin 7
Trying...
Connected to merlin.tpci.com
Escape character is '^T'.
This is a message
This is a message
Isn't this exciting?
Isn't this exciting?
<Ctrl+T>
$ telnet merlin 13
Trying...
Connected to merlin.tpci.com
Escape character is '^T'.
Tues Jun 21 10:16:45 1994
Connection closed.
$ telnet merlin 19
!"#$%&'()*+,-
./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[[\]^_abcdefg
"#$%&'()*+,-
./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[[\]^_abcdefgh
#$%&'()*+,-
./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[[\]^_abcdefghi
$%&'()*+,-
./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[[\]^_abcdefghij
%&'()*+,-
./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[[\]^_abcdefghijk
&'()*+,-
./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[[\]^_abcdefghijkl
'()*+,-
./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[[\]^_abcdefghijklm
<Ctrl+T>
$
In t his exampl e, a connect ion t o por t 7 st ar t s an Echo session. Ever yt hing t yped by t he
user is echoed back immediat el y, unchanged. Then a connect ion t o por t 13 pr ovides t he
Dayt ime ser vice, showing t he cur r ent dat e and t ime. The connect ion is br oken by t he
ser vice once t he dat a is sent . Final l y, t he Char act er Gener at or is st ar t ed. Bot h t he
Echo and Char act er Gener at or ser vices wer e t er minat ed wit h t he Tel net br eak
sequence of Ct r l +T.
Summary
I cover ed a l ot of mat er ial in t his chapt er , most l y about t he way TCP/IP can int er act
wit h ot her net wor king syst ems and pr ot ocol s. By combining TCP/IP wit h exist ing
net wor ks, t he advant ages of bot h can be gained, as wel l as of f er ing compat ibil it y wit h a
wide r ange of TCP-based devices.
I have al so l ooked at sever al pr ot ocol s t hat r ound out t he TCP/IP f amil y. These ar e
most l y basic ser vices, but t hey ar e essent ial t o t he pr oper oper at ion of a TCP/IP-based
net wor k.
Q&A
What is t he r ol e of t he Media Access Cont r ol (MAC) l ayer in a net wor k
ar chit ect ur e?
The MAC l ayer handl es t r af f ic f or t he net wor k, incl uding col l isions and t imer s. The
MAC is independent of t he net wor k's physical medium, but it s exact r ol e and
impl ement at ion depend on t he net wor k pr ot ocol s.
What is t he dif f er ence bet ween LLC Type 1 and LLC Type 2?
Logical Link Cont r ol (LLC) Type 1 is a simpl er f or m t hat suppor t s unnumber ed
inf or mat ion, designed f or TCP. LLC Type 2 is f or UDP and of f er s message int egr it y
f unct ional it y.
What is XNS?
XNS is t he Xer ox Net wor k Syst em, a net wor king design t hat Xer ox r el eased t o t he
publ ic domain. Because XNS is essent ial l y f r ee, it has gained a l ot of suppor t . XNS
suppor t s Et her net .
What is ISDN?
The Int egr at ed Ser vices Digit al Net wor k is a packet -swit ched high-speed net wor k t hat
suppor t s br oadband (many channel ) communicat ions.
Why is a simpl e net wor k pr ot ocol l ike t he Char act er Gener at or suppor t ed?
As simpl e as it may be, t he Char act er Gener at or pr ot ocol (and many ot her s l ike it ) is
used f or basic t asks and quer ies t hat woul d r equir e much mor e compl ex coding and
oper at ions when per f or med as par t of a l ar ger pr ot ocol . The Char act er Gener at or
pr ot ocol is usef ul f or t est ing communicat ions. It is smal l , f ast , easy t o impl ement , and
easy t o under st and.
Quiz
1. What component s make up a Medium At t achment Unit (MAU) and what ar e t heir
r ol es?
2. What is FDDI? Why is it popul ar ?
3. What is t he r ol e of t he Discar d ser vice?
4. The Time pr ot ocol is of t en used by net wor k devices. What is it s r ol e?
5. Does t he pr esence of a second net wor k pr ot ocol (l ike IPX) af f ect t he basic TCP/IP
pr ot ocol suit e's oper at ions?


I The Sampl e Net wor k
I Conf igur ing TCP/IP Sof t war e
I UNIX TCP/IP Conf igur at ion
I Conf igur ing SCO UNIX
I Conf igur ing Linux
I Conf igur ing Sol ar is
I Conf igur ing Windows NT Ser ver
I Test ing t he Ser ver Conf igur at ions
I Pseudo t t ys
I User Equival ence
I Anonymous FTP
I Conf igur ing SLIP and PPP
I Remot e Pr int ing
I Conf igur ing SNMP
I Summar y
I Q&A
I Quiz
9
Setting Up a Sample TCP/IP Network:
Servers
Over t he past eight days I have l ooked at sever al aspect s of t he TCP/IP pr ot ocol f amil y.
Now it 's t ime t o l ook at how you can act ual l y set up TCP/IP on a net wor k. This chapt er
expl ains how t he ser ver s f or a TCP/IP net wor k ar e conf igur ed, and t he next chapt er
examines cl ient machines. In bot h chapt er s, I t r y t o cover a wide r ange of machines and
oper at ing syst ems.
In t his chapt er I l ook at how t o set up f our dif f er ent t ypes of ser ver s: a Sant a Cr uz
Oper at ion (SCO) OpenSer ver 5 machine, a Linux machine, a Windows NT machine, and a
Sun SPARCst at ion 5. Al l f our ser ver s ar e connect ed t o t he sampl e net wor k, and any of
t hem can be accessed by a cl ient machine or ot her ser ver s. Don't be t oo concer ned if I am
not going t o use your par t icul ar ver sion of UNIX, because most of t he det ail s of TCP/IP
conf igur at ion ar e eit her ident ical or ver y simil ar acr oss al l UNIX ver sions. Usual l y al l
t hat changes is t he dir ect or y name f or some of t he conf igur at ion f il es.
As you know f r om ear l ier in t his book, UNIX and TCP/IP ar e int er t wined cl osel y because
t he or iginal impl ement at ions of TCP/IP wer e f or UNIX syst ems. TCP/IP was devel oped f or
t he BSD UNIX ver sion t hat or iginat ed at t he Univer sit y of Cal if or nia at Ber kel ey, and
much of t he l anguage of TCP/IP is hooked int o t he BSD ver sions. Most UNIX syst ems have
moved away f r om BSD UNIX and have embr aced Syst em V Rel ease 4, or iginal l y devel oped
at AT&T and now owned by t he Open Sof t war e Foundat ion. SCO UNIX and SunSof t
Sol ar is 2.4, bot h of which I use in t his chapt er , use t he Syst em V Rel ease 4 ver sion of
UNIX, which pr ovides some backwar d compat ibil it y wit h BSD UNIX.
In t he next chapt er I expand t he cover age of TCP/IP on t he sampl e net wor k by l ooking
at cl ient impl ement at ions. I l ook specif ical l y at how you can impl ement TCP/IP f or DOS,
Windows 3.x, and Windows 95. Any of t he oper at ing syst ems ment ioned in t his chapt er
can act as cl ient s t o any of t he ser ver s, as wel l .
Most of t he mat er ial cover ed in t his chapt er is f amil iar if you have r ead t hr ough t he
book in or der . Some of it is summar ized and shown again f or quick r ef er ence, as wel l as
f or t hose who r ead t he chapt er s out of or der . If you get l ost , you can consul t t he index
f or a point er t o mor e inf or mat ion.
The Sample Network
For t his chapt er I designed a dedicat ed TCP/IP net wor k t o show t he st eps you must
f ol l ow t o set up, conf igur e, and t est a TCP/IP impl ement at ion. The sampl e net wor k r el ies
on sever al ser ver s, al t hough many net wor ks have onl y one. Al so, I use sever al
dif f er ent t ypes of ser ver s t o show you how t hey can be conf igur ed, wher eas most r eal
net wor ks ar e not t his diver se. Al l t he machines ar e connect ed over an Et her net
net wor k. In al l , t he sampl e net wor k has f our ser ver s and t hr ee cl ient s.
Each of t he seven machines on t he net wor k has it s own name and IP addr ess. For t his
sampl e net wor k, t he IP addr ess mask has been r andoml y chosen as 147.120. The names of
t he machines have been chosen f r om my pet s, al t hough any unique name woul d do, of
cour se. The sampl e net wor k conf igur at ion is shown in Figur e 9.1. Bear in mind t hat t his
net wor k is const r uct ed t o show t he dif f er ent t ypes of oper at ing syst ems I examine in
t oday's and t omor r ow's mat er ial ; it is unl ikel y t hat a r eal net wor k woul d have such an
odd mix of ser ver s and cl ient s.
Figur e 9.1. The sampl e TCP/IP net wor k.
The physical set up of t he net wor k is under t aken f ir st . It invol ves inst al l ing a net wor k
int er f ace car d in each machine (except t he SPARCst at ion, which has t he net wor k car d
as par t of t he mot her boar d). On each syst em you must ensur e t hat any jumper s f or
int er r upt vect or s and memor y I/O addr esses do not conf l ict wit h any ot her car d on t hat
syst em. (Some of t he car ds ar e sof t war e pr ogr ammabl e; some ar e set by jumper s or DIP
swit ches.) Al l t he boar ds used in t his syst em ar e f r om dif f er ent manuf act ur er s t o show
t he independent nat ur e of t he TCP/IP net wor k.
Cabl e must be r un bet ween al l t he machines, connect ing t he net wor k int er f ace car ds
t oget her . In t he case of Et her net , t he cabl es must be pr oper l y t er minat ed. The sampl e
net wor k uses t hin Et her net , which cl osel y r esembl es t el evision coaxial cabl e. BNC Thin
Et her net connect or s r esembl e a T, wit h cabl es at t ached t o bot h ends of t he T and t he
st em connect ed t o t he net wor k car d. Two of t he machines f or m t he ends of t he cabl e
and r equir e a t er minat ing r esist or as par t of t heir T. The SPARCst at ion nor mal l y uses
an RJ45 connect or (which l ooks l ike a wide t el ephone connect or , so I used a t r ansceiver
t o conver t it t o BNC).
To t est t he physical net wor k, it is easiest t o wait unt il a coupl e of machines have had
t heir basic sof t war e conf igur at ion compl et ed. Al l t he machines on t he net wor k do not
have t o be act ive, as l ong as t he net wor k cabl e is cont iguous f r om end t o end and each
BNC connect or is at t ached t o a net wor k car d t o pr ovide el ect r ical t er minat ion. If
pr obl ems ar e f ound when t he net wor k is t est ed, t he physical net wor k is t he f ir st it em t o
check. Some net wor k monit or ing devices can suppl y int egr it y inf or mat ion pr ior t o
inst al l ing t he net wor k, but t hese devices ar e not usual l y avail abl e t o syst em
administ r at or s who ar e just beginning t heir inst al l at ion, or who have a smal l number of
machines t o maint ain (pr imar il y because t he net wor k t est er s t end t o be expensive).
Configuring TCP/IP Software
This sect ion f ol l ows t hr ough t he conf igur at ion of t he TCP/IP sof t war e. The discussion
appl ies equal l y t o t he UNIX, Windows, and DOS machines on t he sampl e net wor k (as it
woul d t o any ot her t ype of machine, such as a Macint osh). Fil enames can change wit h
dif f er ent oper at ing syst ems, but t he gener al appr oach r emains val id.
Most oper at ing syst ems and TCP/IP sof t war e packages pr ovide sever al ut il it ies, incl uding
menu-dr iven scr ipt s t hat hel p aut omat e t he inst al l at ion pr ocess of t he TCP/IP
appl icat ions. Some oper at ing syst ems (not abl y ol der UNIX syst ems) st il l r equir e manual
conf igur at ion of sever al f il es using a t ext edit or . To conf igur e TCP/IP sof t war e
pr oper l y, you must know sever al pieces of inf or mat ion bef or e you st ar t . The necessar y
inf or mat ion you need f or each machine on t he net wor k f ol l ows:
G Domain name: The name t he ent ir e net wor k wil l use.
G Syst em name: The unique name of each l ocal machine.
G IP addr ess: The f ul l addr ess of each machine.
G Dr iver t ype: Each int er f ace t o t he net wor k must be associat ed wit h a device
dr iver , inst r uct ing t he oper at ing syst em how t o t al k t o t he device.
G Br oadcast addr ess: The addr ess used f or net wor k-wide br oadcast s.
G Net mask: The net wor k mask t hat uniquel y ident if ies t he l ocal net wor k.
G Har dwar e net wor k car d conf igur at ion inf or mat ion: The int er r upt vect or and
memor y addr ess of t he net wor k car d.
The syst em domain name is necessar y if t he net wor k is t o be connect ed t o ot her machines
out side t he l ocal net wor k. Domain names can be invent ed by t he syst em administ r at or .
If , however , t he net wor k is t o int er f ace wit h Int er net or one of it s ser vice pr ovider s,
t he domain name shoul d be appr oved by t he Int er net Net wor k Inf or mat ion Cent er
(Int er NIC). Cr eat ing and r egist er ing a new domain is as simpl e as f il l ing out a f or m (and
r ecent l y, paying a smal l administ r at ion f ee). Domain names usual l y r ef l ect t he company
name, wit h t he ext ension ident if ying t he t ype of or ganizat ion. The sampl e net wor k uses
t he name t pci.com.
As seen ear l ier in t his book, t he machine name is used f or symbol ic naming of a machine
inst ead of f or cing t he f ul l IP addr ess t o be specif ied. The syst em name must be unique on
t he l ocal net wor k. Ot her net wor ks might have machines wit h t he same name, but t heir
net wor k masks ar e dif f er ent , so t her e is no possibl e conf usion dur ing packet r out ing. In
most cases, syst em names ar e composed of eight char act er s (or l ess) and ar e usual l y al l
l ower case char act er s (in keeping wit h UNIX t r adit ion f or l ower case). The syst em name
can be a mix of char act er s and number s. Lar ger or ganizat ions t end t o number t heir
machines, and smal l companies give t heir machines mor e f amil iar names.
The device dr iver inst r uct s t he oper at ing syst em how t o communicat e wit h t he net wor k
int er f ace (usual l y eit her a net wor k car d or a ser ial por t ). Each int er f ace has it s own
specif ic device dr iver . Most oper at ing syst ems have device dr iver s incl uded in t heir
dist r ibut ion sof t war e, al t hough some r equir e sof t war e suppl ied wit h t he net wor k car d.
Gener ic dr iver s ar e avail abl e f or most net wor k car ds on bul l et in boar d syst ems.
Wit h most oper at ing syst ems, t her e ar e l imit s t o t he number of simil ar devices t hat ar e
suppor t ed. SCO UNIX, f or exampl e, enabl es up t o f our Et her net car ds, t wo Token Ring
adapt er s, f our Ser ial Line Int er net Pr ot ocol (SLIP) l ines, and f our Point -t o-Point
Pr ot ocol (PPP) l ines. These l imit s shoul d be enough f or a machine on any net wor k!
The net wor k car d conf igur at ion must be known in or der t o inst al l t he device dr iver
pr oper l y. Net wor k car ds usual l y have sever al conf igur at ion set t ings, depending on t he
syst em f or which t hey ar e designed. For t he PC-based machines in t he sampl e net wor k,
each car d must have a unique int er r upt vect or (cal l ed an IRQ) and a unique I/O memor y
addr ess. IRQ and addr ess set t ings on many of t he newer net wor k boar ds ar e sof t war e-
conf igur abl e, making t he inst al l at ion and conf igur at ion much easier .
Most net wor k car ds come wit h def aul t set t ings t hat might conf l ict wit h ot her car ds in
t he syst em. User s must car ef ul l y check f or conf l ict s, r esor t ing t o a diagnost ic pr ogr am
if avail abl e. UNIX user s have sever al ut il it ies avail abl e, depending on t he oper at ing
syst em. SCO UNIX and most Syst em V Rel ease 4 oper at ing syst ems have t he ut il it y
hwconf ig, which shows t he cur r ent har dwar e conf igur at ion. The f ol l owing exampl e
shows t he hwconf ig out put and t he out put f r om t he command wit h t he -h opt ion t o
pr ovide l ong f or mat t ing wit h header s (making it is easier t o r ead):
$ hwconfig
name=fpu vec=13 dma=- type=80387
name=serial base=0x3F8 offset=0x7 vec=4 dma=- unit=0
type=Standard nports=1
name=serial base=0x2F8 offset=0x7 vec=3 dma=- unit=1
type=Standard nports=1
name=floppy base=0x3F2 offset=0x5 vec=6 dma=2 unit=0
type=96ds15
name=floppy vec=- dma=- unit=1 type=135ds18
name=console vec=- dma=- unit=vga type=0 12 screens=68k
name=adapter base=0x2C00 offset=0xFF vec=11 dma=- type=arad
ha=0 id=7 fts=st
name=nat base=0x300 offset=0x20 vec=7 dma=- type=NE2000
addr=00:00:6e:24:1e:3e
name=tape vec=- dma=- type=S ha=0 id=4 lun=0 ht=arad
name=disk vec=- dma=- type=S ha=0 id=0 lun=0 ht=arad
fts=stdb
name=Sdsk vec=- dma=- cyls=1002 hds=64 secs=32
$
$ hwconfig -h
device address vec dma comment
====== ======= === === =======
fpu - 13 - type=80387
serial 0x3f8-0x3ff 4 - unit=0 type=Standard
nports=1
serial 0x2f8-0x2ff 3 - unit=1 type=Standard
nports=1
floppy 0x3f2-0x3f7 6 2 unit=0 type=96ds15
floppy - - - unit=1 type=135ds18
console - - - unit=vga type=0 12
screens=68k
adapter 0x2c00-0x2cff 11 - type=arad ha=0 id=7
fts=st
nat 0x300-0x320 7 - type=NE2000
addr=00:00:6e:24:1e:3e
tape - - - type=S ha=0 id=4 lun=0
ht=arad
disk - - - type=S ha=0 id=0 lun=0
ht=arad fts=stdb
Sdsk - - - cyls=1002 hds=64
secs=32
This out put is f r om t he SCO UNIX ser ver s set up f or t he sampl e net wor k. It has t he
net wor k Et her net car d al r eady conf igur ed as device nat , which uses IRQ 7 (shown
under t he vec or int er r upt vect or col umn). The nat l ine al so shows t he memor y addr ess
as 300320 (hexadecimal ) and t he device dr iver as NE2000 (a Novel l Net War e-compat ibl e
dr iver ). The addr ess and vec col umns show no conf l ict s bet ween t he set t ings used f or
t he Et her net car d and ot her devices on t he syst em. (The adapt er ent r y is f or a high-
speed SCSI-2 car d, which cont r ol s bot h t he t ape and t he Sdsk device, t he pr imar y SCSI
har d dr ive. Al l ot her ent r ies shoul d be sel f -expl anat or y.)
DOS user s can use t he Micr osof t Diagnost ic ut il it y, MSD.EXE, or one of sever al t hir d-
par t y t ool s such as Cent r al Point PC Tool s or The Nor t on Ut il it ies t o displ ay IRQ
vect or s and memor y addr esses in use by t he syst em. Some sof t war e even indicat es which
vect or s and addr esses ar e avail abl e f or use.
Ther e is no need t o have t he same IRQ and memor y addr ess f or each car d on t he net wor k,
because t he net wor k it sel f doesn't car e about t hese set t ings. The IRQ and memor y
addr esses ar e r equir ed f or t he machine t o communicat e wit h t he net wor k int er f ace car d
onl y. The sampl e net wor k used a dif f er ent IRQ and memor y addr ess f or each machine.
IRQ and memor y addr esses ar e usual l y set on t he net wor k int er f ace car d it sel f using
eit her jumper s on pins or a DIP-swit ch bl ock. The document at ion accompanying t he car d
shoul d pr ovide al l t he inf or mat ion necessar y f or set t ing t hese val ues. Some r ecent l y
int r oduced net wor k int er f ace car ds can be conf igur ed t hr ough sof t war e, enabl ing t he
set t ings t o be changed wit hout r emoving t he car d f r om t he syst em. This can be ver y
handy when a user is unsur e of t he best set t ings f or t he car d.
The IP addr ess is a 32-bit number t hat must be unique f or each machine. If t he net wor k is
t o be connect ed t o t he Int er net , t he IP addr ess must be assigned by t he NIC (it is usual l y
given t o you when you r egist er your domain name). Even if no access t o t he Int er net is
expect ed, ar bit r ar il y assigning an IP addr ess can cause pr obl ems when messages ar e
passed wit h ot her net wor ks. If t he net wor k is not connect ed t o t he out side wor l d, a
syst em administ r at or can ignor e t he NIC's number ing syst em and adopt any IP addr ess. It
is wor t hwhil e, however , t o consider f ut ur e expansion and connect ion t o ot her
net wor ks.
As you might r ecal l , t he NIC has f our cl asses of IP addr esses in use depending on t he size
of t he net wor k. Each cl ass has some addr esses t hat ar e r est r ict ed. These ar e shown in
Tabl e 9.1. Most net wor ks ar e Cl ass B, al t hough a f ew l ar ge cor por at ions r equir e Cl ass
A net wor ks.
Tabl e 9.1. The NIC IP addr ess cl asses.
Class Network Mask Bytes Number of Hosts per Network Valid Addresses
A 1 16,777,216 1.0.0.1 t o 126.255.255.254
B 2 65,534 128.0.0.1 t o 191.255.255.254
C 3 254 224.0.0.0 t o 255.255.255.254
D r eser ved
The net wor k mask is t he IP addr ess st r ipped of it s net wor k ident if ier s, l eaving onl y t he
l ocal machine addr ess. For a Cl ass A net wor k, t his st r ips one byt e, wher eas a Cl ass B
net wor k st r ips t wo byt es (l eaving t wo). The smal l Cl ass C net wor k st r ips t hr ee byt es as
t he net wor k mask, l eaving one byt e t o ident if y t he l ocal machine (hence t he l imit of 254
machines on t he net wor k). The sampl e net wor k is conf igur ed as a Cl ass B machine wit h
t he r andoml y chosen IP addr ess net wor k mask of 147.120 (not NIC-assigned).
The br oadcast addr ess ident if ies packet s t hat ar e t o be sent t o al l machines on t he l ocal
net wor k. Because a net wor k car d usual l y ignor es any incoming packet s t hat don't have
it s specif ic IP addr ess in t hem, a special br oadcast addr ess can be set t hat t he car d can
int er cept in addit ion t o l ocal l y dest ined messages. The br oadcast addr ess has t he host
por t ion (t he l ocal machine ident if ier s) set t o eit her al l 0s or al l 1s, depending on t he
convent ion f ol l owed. For convenience, t he br oadcast addr ess's net wor k mask is usual l y
t he same as t he l ocal net wor k mask.
Br oadcast addr esses might seem simpl e because t her e ar e onl y t wo possibl e set t ings. Such
addr esses, however , commonl y cause pr obl ems because conf l ict ing set t ings ar e used on a
net wor k. BSD UNIX used t he convent ion of al l 0s f or r el eases 4.1 and 4.2, wher eas
4.3BSD and SVR4 (Syst em V Rel ease 4) UNIX moved t o al l 1s f or t he br oadcast addr ess.
The Int er net st andar d specif ies al l 1s as t he br oadcast addr ess. If pr obl ems ar e
encount er ed on t he net wor k wit h br oadcast s, check al l t he conf igur at ions t o ensur e
t hey ar e using t he same set t ing. The sampl e net wor k uses an al l 1s mask f or it s br oadcast
addr ess.
The st eps f ol l owed f or conf igur ing TCP/IP ar e st r aight f or war d, gener al l y f ol l owing
t he inf or mat ion r equir ed f or each machine. The conf igur at ion st eps ar e as f ol l ows:
G Link dr iver s: TCP/IP must be l inked t o t he oper at ing syst em's ker nel or l oaded
dur ing t he boot st age t o enabl e TCP/IP.
G Add host inf or mat ion: Pr ovide a l ist of al l machines (host s) on t he net wor k
(used f or name r esol ut ion).
G Est abl ish r out ing t abl es: Pr ovide t he inf or mat ion f or r out ing packet s pr oper l y
if name r esol ut ion isn't suf f icient .
G Set user access: Conf igur e t he syst em t o enabl e access in and out of t he
net wor k, as wel l as est abl ishing per missions.
G Remot e device access: Conf igur e t he syst em f or access t o r emot e pr int er s,
scanner s, CD-ROM car ousel s, and ot her shar ed net wor k devices.
G Conf igur e t he name domain ser ver : If using a dist r ibut ed addr ess l ookup syst em
such as Ber kel ey Int er net Name Domain Ser ver (BIND) or NIS, compl et e t he name
ser ver f il es. (This st ep is necessar y onl y if you ar e using BIND or a simil ar ser vice.)
G Tune syst em f or per f or mance: Because a syst em r unning TCP/IP has dif f er ent
behavior t han one wit hout TCP/IP, some syst em t uning is usual l y r equir ed.
G Conf igur e NFS: If t he Net wor k Fil e Syst em (NFS) is t o be used, conf igur e bot h t he
f il e syst em and t he user access.
G Anonymous FTP: If t he syst em is t o enabl e anonymous FTP access, conf igur e t he
syst em and publ ic dir ect or ies f or t his ser vice.
You wil l use t hese st eps (not necessar il y in t he sequence given) as t he individual
machines on t he net wor k ar e conf igur ed. The pr ocesses ar e dif f er ent wit h each
oper at ing syst em, but t he over al l appr oach r emains t he same.
UNIX TCP/IP Configuration
Most UNIX TCP/IP oper at ing syst ems r el y on sever al f il es f or conf igur at ion. These ar e
summar ized in Tabl e 9.2. Remember t hat f il enames can change wit h dif f er ent
impl ement at ions of t he UNIX oper at ing syst em, but t he conf igur at ion inf or mat ion is
consist ent . I l ook at each of t hese f il es in mor e det ail when I l ook at specif ic oper at ing
syst ems l at er t oday. These f il es appl y onl y t o UNIX usual l y; Windows NT, f or exampl e,
uses a dif f er ent set of t abl es.
Tabl e 9.2. TCP/IP UNIX conf igur at ion f il es.
File Description
/et c/host s Host names
/et c/net wor ks Net wor k names
/et c/ser vices List of known ser vices
/et c/pr ot ocol s Suppor t ed pr ot ocol s
/et c/host s.equiv List of t r ust ed host s
/et c/f t puser s List of unwel come FTP user s
/et c/inet d.conf List of ser ver s st ar t ed by inet d
For t he sampl e net wor k, modif ying t hese f il es on any of t he t hr ee UNIX ser ver s (SCO
UNIX, Linux, and SPARCst at ion) is quit e easy. An ASCII t ext edit or is al l t hat is
r equir ed. Ver if ying t he cont ent s is usual l y quit e simpl e, t oo, because t he t abl es on one
machine ar e ver y simil ar t o t hose on ot her machines, except f or a f ew ent r ies.
Configuring SCO UNIX
SCO UNIX and SCO OpenSer ver 5 incl ude sever al conf igur at ion ut il it ies t o hel p pr ovide
inf or mat ion f or TCP/IP and t o l ink t he dr iver int o t he ker nel cor r ect l y. This does not
el iminat e t he need t o edit t he many conf igur at ion f il es manual l y and suppl y
inf or mat ion about t he ot her machines on t he net wor k. Most of t he inf or mat ion in t his
sect ion, al t hough specif ic t o SCO UNIX, is gener al l y appl icabl e t o most UNIX oper at ing
syst ems, especial l y SVR4-compl iant ver sions.
Most UNIX-based net wor ks have a main ser ver machine t hat st ar t s t he net wor k
pr ocesses. This machine is somet imes cal l ed a super server, because any machine t hat r uns
net wor k pr ocesses and accept s r equest s f r om ot her machines is a ser ver . UNIX uses t he
pr ocess inet d (Int er net daemon) as t he mast er ser ver f or al l net wor k pr ocesses t hat ar e
t o be act ivat ed (usual l y cont ained in a singl e f il e cal l ed inet d.conf .) Har dwar e
conf igur at ion r equir es l inking inf or mat ion about t he net wor k car d and pr ot ocol t o t he
oper at ing syst em ker nel . The conf igur at ion is somet imes cal l ed a chain. The pr ocess is
usual l y aut omat ed by a scr ipt f il e, r equir ing user s t o pr ovide t he int er r upt vect or
number , t he I/O memor y addr ess, and t he t ype of car d. The device dr iver f or t hat
net wor k car d is t hen r ebuil t int o t he ker nel so t he dr iver is act ive whenever t he syst em
boot s.
On SCO UNIX syst ems, a ut il it y cal l ed net conf ig is used, pr ompt ing t he user f or t he
t hr ee pieces of inf or mat ion (IRQ, addr ess, and car d t ype) and t hen r ebuil ding t he ker nel .
Under SCO OpenSer ver 5, you can per f or m t he same t asks t hr ough a GUI-dr iven ut il it y
t hat per f or ms t he same t asks. This pr ocess is r epeat ed f or each net wor k car d on t he
machine. (The sampl e net wor k has onl y one car d in each machine, which is t he most
common conf igur at ion.) When st ar t ed, t he SCO UNIX net conf ig pr ogr am pr esent s you
wit h t his scr een:
$ netconfig
Currently configured chains:
1. nfs->sco_tcp
nfs SCO NFS Runtime System for SCO Unix
sco_tcp SCO TCP/IP for UNIX
2. sco_tcp->lo0
sco_tcp SCO TCP/IP for UNIX
lo0 SCO TCP/IP Loopback driver
Available options:
1. Add a chain
2. Remove a chain
3. Reconfigure an element in a chain
q. Quit
Select option: Please enter a value between 1 and 3 ('q' to
quit):
Because a TCP/IP device dr iver is being added, opt ion 1 (Add a chain) is sel ect ed. Some
user s conf use t he f ir st conf igur ed chain in t he l ist wit h a TCP/IP dr iver f or t he net wor k
and at t empt t o r econf igur e it . The f ir st dr iver l ist ed in t he pr evious out put is a def aul t
val ue f or NFS and shoul d be l ef t al one. It has not hing t o do wit h t he addit ion of a
TCP/IP net wor k car d. The second chain l ist ed in t he conf igur at ion is t he l oopback
dr iver , which shoul d be cr eat ed aut omat ical l y f or al l SCO syst ems when t he oper at ing
syst em sof t war e is inst al l ed.
Af t er indicat ing t hat a new chain is t o be added, t he syst em asks f or t he t ype of chain:
Num Name Description
1. lmxc SCO LAN Manager Client
2. nfs SCO NFS Runtime System for SCO UNIX
3. sco_ipx SCO IPX/SPX for UNIX
4. sco_tcp SCO TCP/IP for UNIX
Select top level of chain to Add or 'q' to quit:
Opt ion 4 is chosen because you ar e inst al l ing TCP/IP. LAN Manager and IPX/SPX ar e used
f or int egr at ion wit h DOS-based net wor ks. The NFS Runt ime Syst em is added l at er if NFS
is t o be used on t he net wor k. I l ook at conf igur ing NFS in mor e det ail on Day 12, "NFS
and NIS."
The net conf ig ut il it y t hen pr esent s a l ist of sever al dozen net wor k int er f ace car ds f or
which t he syst em has def aul t val ues. If t he car d inst al l ed in t he syst em is shown, t he
ent r y f or t he car d is chosen. If t he car d is not on t he l ist , a compat ibl e ent r y must be
f ound. This somet imes r equir es digging t hr ough t he net wor k int er f ace car d's
document at ion f or emul at ion or compat ibl e val ues, or cont act ing t he manuf act ur er .
Dr iver s ar e usual l y avail abl e f or Et her net car ds.
The syst em t hen pr ompt s f or t he IRQ t he car d is set f or , f ol l owed by t he memor y addr ess.
Af t er t hese ar e ent er ed, t he oper at ing syst em cr eat es t he necessar y ent r ies in it s
int er nal conf igur at ion f il es t o incl ude t he device dr iver f or t he net wor k car d. As a
f inal st ep, t he syst em asks if t he user want s t o r ebuil d and r el ink t he ker nel . This must
be done if t he new dr iver s ar e t o be ef f ect ive. Af t er a syst em r eboot , t he dr iver s ar e
act ive and can be t est ed wit h a ping command.
You can ping t he l ocal host f ir st , f ol l owed by t he IP addr ess you have assigned f or t he
SCO machine. This does not t est t he net wor k connect ion, because t he oper at ing syst em
doesn't bot her using t he net wor k car d when pinging it sel f . The t est does, however ,
ver if y t hat t he IP addr ess is set pr oper l y and t hat t he TCP/IP sof t war e is embedded in
t he oper at ing syst em ker nel . An exampl e of t his t ype of ping t est ing l ooks l ike t his:
# ping -c5 localhost
PING localhost (127.0.0.1): 56 data bytes
64 bytes from localhost (127.0.0.1): icmp_seq=0 ttl=64
time=10 ms
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64
time=0 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64
time=0 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64
time=0 ms
64 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=64
time=0 ms
--- localhost ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0/2/10 ms
# ping -c5 147.120.0.1
PING 147.120.0.1 (147.120.0.1): 56 data bytes
64 bytes from merlin (147.120.0.1): icmp_seq=0 ttl=64 time=0
ms
64 bytes from merlin (147.120.0.1): icmp_seq=1 ttl=64 time=0
ms
64 bytes from merlin (147.120.0.1): icmp_seq=2 ttl=64 time=0
ms
64 bytes from merlin (147.120.0.1): icmp_seq=3 ttl=64 time=0
ms
64 bytes from merlin (147.120.0.1): icmp_seq=4 ttl=64 time=0
ms
--- 147.120.0.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0/0/0 ms
In t he pr eceding exampl e, issued on t he ser ver mer l in wit h IP addr ess 147.120.0.1, I used
t he ping command wit h t he -c opt ion t o specif y how many packet s t o send. As you can see,
bot h t he l ocal host and IP addr ess r esponded pr oper l y, indicat ing t hat t he TCP/IP
sof t war e is pr oper l y l oaded and t he IP addr ess is r ecognized.
As you saw ear l ier t oday, UNIX TCP/IP net wor king sof t war e r el ies on sever al f il es f or
conf igur at ion. These wer e summar ized in Tabl e 9.2. You can l ook at each of t hese f il es
now wit h r espect t o t he SCO UNIX ser ver on t he sampl e net wor k.
The /et c/host s f il e cont ains t he names of t he ot her machines on t he net wor k and t heir
net wor k addr esses. The f il e l ooks l ike t his:
# @(#)hosts 1.2 Lachman System V STREAMS TCP source
# SCCS IDENTIFICATION
127.0.0.1 localhost tpci
147.120.0.1 merlin merlin.tpci.com
147.120.0.2 freya freya.tpci.com
147.120.0.3 brutus brutus.tpci.com
147.120.0.4 megan megan.tpci.com_
147.120.0.10 whitney whitney.tpci.com
147.120.0.11 sinbad sinbad.tpci.com
147.120.0.12 pepper pepper.tpci.com
Each l ine cont ains t he l ocal machine name and it s f ul l name wit h t he domain so t hat
eit her ver sion is r ecognized by t he oper at ing syst em. As new machines ar e added t o t he
net wor k, new l ines ar e added t o t he f il e. The l ocal machine has t wo ent r ies in t he f il e:
one f or t he l ocal name and one f or l ocal host .
The /et c/net wor ks f il e hol ds a l ist of net wor k names and t heir addr esses. This is an
opt ional f il e as f ar as most TCP/IP inst al l at ions ar e concer ned, and most syst em
administ r at or s use it onl y when t he user s need it . The /et c/net wor ks f il e l et s you name
net wor ks in t he same way as machines. The f ol l owing exampl e shows some of t he SCO
net wor k machines as wel l as t wo net wor ks t hat t he l ocal machines f r equent l y connect
t o. Using t he name macl ean_net as par t of a machine ident if ier suppl ied by a user is now
possibl e because t he oper at ing syst em can r esol ve it t o it s IP addr ess t hr ough t his f il e.
# @(#)networks 1.2 Lachman System V STREAMS TCP source
# SCCS IDENTIFICATION
loopback 127
sco 132.147
sco-hq 132.147.128
sco-mfg 132.147.64
sco-engr 132.147.192
sco-slip 132.147.32
sco-tcplab 132.147.160
sco-odtlab 132.147.1
maclean_net 147.50.1
bnr.ca 47
On Day 6 "Tel net and FTP," you examined t he /et c/ser vices f il e. It incl udes inf or mat ion
about al l t he TCP and UDP ser vices suppor t ed by t he syst em. For t he sampl e net wor k
and most smal l net wor ks, t he def aul t val ues ar e accept abl e. These ent r ies ar e changed
onl y if a ser vice is being r emoved f r om TCP/IP, such as t o pr event Tel net access. The f il e
l ooks l ike t his:
# @(#)services 5.1 Lachman System V STREAMS TCP source
#
# System V STREAMS TCP - Release 4.0
# Network services, Internet style
#
echo 7/tcp
echo 7/udp
discard 9/tcp sink null
discard 9/udp sink null
systat 11/tcp users
daytime 13/tcp
daytime 13/udp
netstat 15/tcp
qotd 17/tcp quote
chargen 19/tcp ttytst source
chargen 19/udp ttytst source
ftp 21/tcp
telnet 23/tcp
smtp 25/tcp mail
time 37/tcp timserver
time 37/udp timserver
rlp 39/udp resource # resource
location
nameserver 42/tcp name # IEN 116
whois 43/tcp nicname
domain 53/tcp nameserver # name-domain
server
domain 53/udp nameserver
mtp 57/tcp # deprecated
bootps 67/udp bootps # bootp server
bootpc 68/udp bootpc # bootp client
tftp 69/udp
rje 77/tcp netrjs
finger 79/tcp
link 87/tcp ttylink
supdup 95/tcp
hostnames 101/tcp hostname # usually from
sri-nic
tsap 102/tcp osi-tp0 tp0
#csnet-cs 105/?
pop 109/tcp postoffice
sunrpc 111/tcp
sunrpc 111/udp
auth 113/tcp authentication
sftp 115/tcp
uucp-path 117/tcp
nntp 119/tcp readnews untp # USENET News
Transfer Protocol
ntp 123/tcp
ntp 123/udp
nb-ns 137/udp nbns netbios-nameservice
nb-ns 137/tcp nbns netbios-nameservice
nb-dgm 138/udp nbdgm netbios-datagram
nb-dgm 138/tcp nbdgm netbios-datagram
nb-ssn 139/tcp nbssn netbios-session
snmp 161/udp
snmp-trap 162/udp
bgp 179/tcp
#
# UNIX specific services
#
exec 512/tcp
biff 512/udp comsat
login 513/tcp
who 513/udp whod
shell 514/tcp cmd # no
passwords used
syslog 514/udp
printer 515/tcp spooler # line
printer spooler
talk 517/udp
ntalk 518/udp
efs 520/tcp # for
LucasFilm
route 520/udp router routed # 521 also
timed 525/udp timeserver
tempo 526/tcp newdate
courier 530/tcp rpc
conference 531/tcp chat
netnews 532/tcp readnews
netwall 533/udp # -for
emergency broadcasts
uucp 540/tcp uucpd # uucp
daemon
remotefs 556/tcp rfs_server rfs # Brunhoff
remote filesystem
pppmsg 911/tcp # PPP daemon
listen 1025/tcp listener RFS
remote_file_sharing
nterm 1026/tcp remote_login
network_terminal
ingreslock 1524/tcp
The /et c/host s.equiv f il e cont r ol s access f r om ot her machines. The /et c/f t puser s f il e
pr event s unaut hor ized l ogins wit h specif ic user names. Bot h f il es ar e examined in mor e
det ail in t he sect ions l at er t oday t it l ed "User Equival ence" and "Anonymous FTP."
The /et c/inet d.conf f il e, ment ioned ear l ier , cont r ol s t he pr ocesses st ar t ed by t he inet d
daemon when t he syst em boot s. The def aul t inet d.conf f il e is f ine f or t he sampl e syst em
and sel dom r equir es modif icat ion. The f il e appear s as f ol l ows:
# @(#)inetd.conf 5.2 Lachman System V STREAMS TCP
source
#
# System V STREAMS TCP - Release 4.0
#
# SCCS IDENTIFICATION
ftp stream tcp nowait NOLUID /etc/ftpd
ftpd
telnet stream tcp nowait NOLUID /etc/telnetd
telnetd
shell stream tcp nowait NOLUID /etc/rshd
rshd
login stream tcp nowait NOLUID /etc/rlogind
rlogind
exec stream tcp nowait NOLUID /etc/rexecd
rexecd
finger stream tcp nowait nouser /etc/fingerd
fingerd
#uucp stream tcp nowait NOLUID /etc/uucpd
uucpd
# Enabling this allows public read files to be accessed via
TFTP.
#tftp dgram udp wait nouser /etc/tftpd
tftpd
comsat dgram udp wait root /etc/comsat
comsat
ntalk dgram udp wait root /etc/talkd
talkd
#bootps dgram udp wait root /etc/bootpd
bootpd
echo stream tcp nowait root internal
discard stream tcp nowait root internal
chargen stream tcp nowait root internal
daytime stream tcp nowait root internal
time stream tcp nowait root internal
echo dgram udp wait root internal
discard dgram udp wait root internal
chargen dgram udp wait root internal
daytime dgram udp wait root internal
time dgram udp wait root internal
smtp stream tcp nowait mmdf
/usr/mmdf/chans/smtpd smtpd /usr/mmdf/chans/smtpsrvr smtp
Wit h t he f il es set up as shown and t he daemons pr oper l y l oading, TCP/IP and UDP shoul d
bot h be act ive and avail abl e. Most oper at ing syst ems r equir e a r eboot af t er any changes
t o t he ker nel or some conf igur at ion f il es, so modif icat ions t o t he TCP/IP f il es shoul d be
f ol l owed by syst em r eset s.
When t he syst em boot s, t he TCP/IP daemons shoul d be l ist ed in t he st ar t up messages
shown on t he consol e. Any er r or s in t he daemon st ar t ups ar e shown on t he displ ay or
mail ed t o t he syst em administ r at or . Usual l y, t hese er r or messages ar e cr ypt ic but at
l east indicat e t he pr esence of a pr obl em (which is bet t er t han you wor r ying about
conf igur at ion inf or mat ion when t he daemon is at f aul t ).
Configuring Linux
Linux is a publ ic domain UNIX ver sion t hat has become ver y popul ar . In t his sect ion I
conf igur e t he Sl akWar e r el ease of Linux on t he sampl e net wor k. Many ot her Linux
ver sions use t he same TCP/IP conf igur at ion pr ocess as Sl akWar e, but you shoul d check
your ver sion's r el ease not es f or any changes. Linux is a combinat ion of BSD UNIX and
SVR4 UNIX, but most of t he conf igur at ion f il es f or TCP/IP ar e ident ical t o t hose f or
SCO UNIX and Sol ar is 2.4. Bef or e you st ar t conf igur ing t he TCP/IP f il es, t hough, you
need t o check a f ew det ail s on your Linux syst em.
Most net wor ked ver sions of Linux r el y on t he /pr oc f il esyst em, which must be cr eat ed
and mount ed bef or e net wor king can be conf igur ed and t est ed. Most Linux ver sions
aut omat ical l y cr eat e t he /pr oc f il esyst em when t he oper at ing syst em is inst al l ed, so you
shoul dn't have t o do anyt hing mor e t han make sur e it is pr oper l y mount ed by t he
ker nel . The /pr oc f il esyst em is essent ial l y a quick int er f ace point f or t he ker nel t o
obt ain net wor k inf or mat ion, as wel l maint aining impor t ant t abl es t hat ar e usual l y
kept in t he subdir ect or y /pr oc/net , which is cr eat ed by t he net wor k inst al l at ion
r out ine.
If t he /pr oc f il esyst em is not cr eat ed by your Linux ker nel , you have t o r ebuil d t he
ker nel and sel ect t he /pr oc opt ion. Change t o t he sour ce dir ect or y (such as
/usr /sr c/Linux) and r un t he conf igur at ion r out ine wit h t his command:
make config
When you ar e asked if you want t he pr ocf s suppor t , answer yes. If you do not get asked
about t he /pr oc f il esyst em suppor t , and t he /pr oc dir ect or y is not cr eat ed on your
f il esyst em, you need t o upgr ade your ker nel t o suppor t net wor king.
You can make sur e t he /pr oc f il esyst em is mount ed aut omat ical l y on your Linux syst em
by examining t he st ar t up code f or t he ker nel . To f or ce t he /pr oc f il esyst em t o be
mount ed aut omat ical l y, modif y t he /et c/f st ab f il e and add t he mount command t her e.
Check t he ent r ies in /et c/f st ab t o see if t her e is a l ine l ike t his:
none /proc proc defaults
If no such l ine exist s, you shoul d add it t o t he cont ent s of t he /et c/f st ab f il e using an
ASCII edit or .
Anot her st ep you must t ake bef or e conf igur ing TCP/IP under Linux is t o set t he
host name. To set t he host name, use t his command:
hostname name
The name is t he syst em name you want f or your l ocal machine. If a host name is not
al r eady set , you can set t he f ul l domain name using t his command:
hostname freya.tpci.com
This set s t he host name t o f r eya on t he sampl e net wor k. When you set t he l ocal
machine's name wit h t he host name command, an ent r y is usual l y made in t he /et c/host s
f il e. You shoul d ver if y t hat your machine name appear s in t hat f il e.
The next st ep in conf igur ing TCP/IP on your Linux machine is t o make t he net wor k
int er f ace accessibl e. This is done wit h t he if conf ig command. When r un, if conf ig
essent ial l y makes t he net wor k l ayer of t he ker nel wor k wit h t he net wor k int er f ace by
giving it an IP addr ess. When t he int er f ace is act ive, t he ker nel can send and r eceive
dat a t hr ough t he int er f ace.
Ther e ar e sever al int er f aces you need t o set up f or your Linux machine, incl uding t he
l oopback dr iver (if it is not al r eady cr eat ed) and t he Et her net int er f ace. The if conf ig
command is used f or each int er f ace in t ur n. The gener al f or mat of t he if conf ig command
is t his:
ifconfig interface_type IP_Address
The interface_type is t he int er f ace's device dr iver name (such as l o f or l oopback and et h
f or Et her net ). The IP_Address is t he IP addr ess used by t hat int er f ace.
When t he if conf ig command has been r un and t he int er f ace is act ive, you can use t he
r out e command t o add or r emove r out es in t he ker nel 's r out ing t abl e. This is needed t o
enabl e t he l ocal machine t o f ind ot her machines. The gener al f or mat of t he r out e
command is t his:
route add|del IP_Address
Eit her add or del is specif ied t o add or r emove t he r out e f r om t he ker nel 's r out ing t abl e,
and IP_Address is t he r emot e r out e being af f ect ed.
You can displ ay t he cur r ent cont ent s of t he ker nel 's r out ing t abl e at any t ime by
ent er ing t he command r out e al l by it sel f on t he command l ine. For exampl e, if your
syst em is set up wit h onl y t he l oopback dr iver , you see an out put l ike t his:
$ route
Kernel Routing Table
Destination Gateway Genmask Flags MSS Window Use
Iface
loopback * 255.0.0.0 U 1936 0 16
lo
The impor t ant col umns ar e t he dest inat ion name, which shows t he name of t he
conf igur ed t ar get (in t his case, l oopback), t he mask t o be used (Genmask), and t he
int er f ace (If ace, in t his case /dev/l o). You can f or ce r out e t o displ ay IP addr esses inst ead
of symbol ic names by using t he -n opt ion:
$ route -n
Kernel Routing Table
Destination Gateway Genmask Flags MSS Window Use
Iface
127.0.0.1 * 255.0.0.0 U 1936 0 16
lo
A t ypical Linux net wor k conf igur at ion incl udes a coupl e of int er f aces. The l oopback
int er f ace shoul d exist on ever y machine. Once t he l oopback dr iver is conf igur ed, you
can add t he Et her net dr iver f or t he net wor k. You begin by inst al l ing t he l oopback
dr iver .
The l oopback int er f ace shoul d exist on ever y machine. The l oopback int er f ace al ways
has t he IP addr ess 127.0.0.1, so t he /et c/host s f il e shoul d have an ent r y f or t his
int er f ace. The l oopback dr iver might have been cr eat ed by t he ker nel dur ing sof t war e
inst al l at ion, so check t he /et c/host s f il e f or a l ine simil ar t o t his:
localhost 127.0.0.1
If t he l ine exist s, t he l oopback dr iver is in pl ace. Make sur e t he l ine doesn't have a pound
sign ahead of it , which woul d comment it out . You can al so use t he if conf ig ut il it y t o
displ ay al l t he inf or mat ion it knows about t he l oopback dr iver . Use t his command:
ifconfig lo
You shoul d see sever al l ines of inf or mat ion about t he l oopback dr iver . If you get an
er r or message, t he l oopback dr iver does not exist .
If t he l oopback int er f ace is not in t he /et c/host s f il e, you need t o cr eat e it wit h t he
if conf ig command. The command
ifconfig lo 127.0.0.1
cr eat es t he necessar y l ine in /et c/host s.
Next you shoul d add t he l oopback dr iver t o t he ker nel r out ing t abl es wit h one of t hese
t wo commands:
route add 127.0.0.1
or
route add localhost
It doesn't mat t er which command you use because t hey bot h r ef er t o t he same t hing. The
command essent ial l y t el l s t he ker nel t hat it can use t he r out e t o addr ess 127.0.0.1 or t o
t he name l ocal host .
As a quick check t hat al l is cor r ect wit h t he l oopback dr iver , you can use t he ping
command t o check t he r out ing. If you issue eit her of t hese t wo commands:
ping localhost
or
ping 127.0.0.1
you shoul d see out put l ike t his:
PING localhost: 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0. ttl=255 time=1 ms
64 bytes from 127.0.0.1: icmp_seq=1. ttl=255 time=1 ms
64 bytes from 127.0.0.1: icmp_seq=2. ttl=255 time=1 ms
64 bytes from 127.0.0.1: icmp_seq=3. ttl=255 time=1 ms
64 bytes from 127.0.0.1: icmp_seq=4. ttl=255 time=1 ms
64 bytes from 127.0.0.1: icmp_seq=5. ttl=255 time=1 ms
64 bytes from 127.0.0.1: icmp_seq=6. ttl=255 time=1 ms
64 bytes from 127.0.0.1: icmp_seq=7. ttl=255 time=1 ms
^C
--- localhost PING Statistics ---
7 packets transmitted, 7 packets received, 0% packet loss
round-trip (ms) min/avg/max = 1/1/1
The ping command's pr ogr ess was int er r upt ed by t he user by issuing a Ct r l +C af t er seven
t r ansmissions. You can l et as many t r ansmissions as you want go by. If you get no r epl ies
f r om t he ping command, t hen t he addr ess 127.0.0.1 or t he name l ocal host wasn't
r ecognized and you shoul d check t he conf igur at ion f il es and r out e ent r y again.
If t he conf igur at ion f il es l ook cor r ect and t he r out e command was accept ed pr oper l y,
but t he ping command st il l doesn't pr oduce t he pr oper r esul t s, you have a mor e ser ious
pr obl em. In some cases, t he net wor k ker nel is not pr oper l y conf igur ed and t he ent ir e
pr ocess must be conduct ed again. Somet imes a mismat ch in ver sions of ker nel dr iver s and
net wor k ut il it ies can cause hang-ups wit h t he ping r out ine, as wel l .
Next , you need t o add t he Et her net dr iver s t o t he ker nel . You can per f or m t he same
conf igur at ion pr ocess wit h t he Et her net dr iver . To begin, you set up t he Et her net
int er f ace using if conf ig. To make t he int er f ace act ive, use t he if conf ig command wit h
t he Et her net device name and your l ocal IP addr ess. For exampl e, use t he command
ifconfig eth0 147.120.0.2
t o set up t he l ocal machine wit h t he IP addr ess 147.120.0.2. The int er f ace is t o t he
Et her net device /dev/et h0. You don't have t o specif y t he net wor k mask wit h t he if conf ig
command because it deduces t he pr oper val ue f r om t he IP addr ess ent er ed. If you want t o
pr ovide t he net wor k mask val ue expl icit l y, append it t o t he command l ine wit h t he
keywor d net mask:
ifconfig eth0 147.120.0.2 netmask 255.255.255.0
You can t hen check t he int er f ace wit h t he if conf ig command using t he int er f ace name:
$ ifconfig eth0
eth0 Link encap 10Mps: Ethernet Hwaddr
inet addr 147.123.20.1 Bcast 147.123.1.255 Mask
255.255.255.0
UP BROADCAST RUNNING MTU 1500 Metric 1
X packets:0 errors:0 dropped:0 overruns:0
TX packets:0 errors:0 dropped:0 overruns:0
You might have not iced in t he out put f r om t he command t hat t he br oadcast addr ess was
set based on t he l ocal machine's IP addr ess. This is used by TCP/IP t o access al l machines
on t he l ocal ar ea net wor k at once. The Message Tr ansf er Unit (MTU) size is usual l y set
t o t he maximum val ue of 1500 suppor t ed by Et her net net wor ks.
Next , you need t o add an ent r y t o t he ker nel r out ing t abl es t hat l et s t he ker nel know
about t he l ocal machine's net wor k addr ess. That l et s it send dat a t o ot her machines on
t he same net wor k. The IP addr ess t hat is used wit h t he r out e command t o do t his is not
your l ocal machine's IP addr ess, but t hat of t he net wor k as a whol e wit hout t he l ocal
ident if ier . To set t he ent ir e l ocal ar ea net wor k at once, t he -net opt ion of t he r out e
command is used. In t he case of t he IP addr esses shown pr eviousl y, t he command woul d be
as f ol l ows:
route add -net 147.120.0
This adds al l t he machines on t he net wor k ident if ied by t he net wor k addr ess 147.120.0 t o
t he ker nel 's l ist of accessibl e machines. If you didn't do it t his way, you woul d have t o
manual l y ent er t he IP addr ess of each machine on t he net wor k. An al t er nat ive met hod
is t o use t he /et c/net wor ks f il e, which can cont ain a l ist of net wor k names and t heir IP
addr esses. If you have an ent r y in t he /et c/net wor ks f il e f or a net wor k cal l ed
macl ean_net , you coul d add t he ent ir e net wor k t o t he r out ing t abl e wit h t his
command:
route add maclean_net
Once t he r out e has been added t o t he ker nel r out ing t abl es, you can t r y t he Et her net
int er f ace out by pinging anot her machine, such as t he SCO ser ver you conf igur ed
ear l ier .
Now you can conf igur e t he f il es used by TCP/IP, as you did f or t he SCO UNIX syst em
conf igur ed ear l ier . Because many of t he det ail s of t hese f il es ar e ident ical t o t hose
shown in t he SCO UNIX sect ion, I skip a l ot of t he det ail s her e.
The /et c/host s f il e is used t o hol d t he net wor k addr esses and symbol ic names, as wel l as
t he l oopback dr iver . The l oopback connect ion addr ess is usual l y l ist ed as t he machine
name l oopback or l ocal host . The /et c/host s f il e consist s of t he net wor k addr ess in one
col umn and t he symbol ic name in anot her . Al t hough t he net wor k addr esses can be
specif ied in decimal , oct al , or hexadecimal f or mat , decimal is t he most commonl y used
f or m (and use of t he ot her s can be downr ight conf using). You can specif y mor e t han one
symbol ic name on a l ine by separ at ing t he names wit h whit e space char act er s (spaces or
t abs). The Linux ser ver /et c/host s f il e on t he sampl e net wor k l ooks l ike t his (r emember
t hat t he Linux ser ver is cal l ed f r eya and has an IP addr ess of 147.120.0.2):
# network host addresses
127.0.0.1 localhost tpci
147.120.0.2 freya freya.tpci.com
147.120.0.1 merlin merlin.tpci.com
147.120.0.3 brutus brutus.tpci.com
147.120.0.4 megan megan.tpci.com_
147.120.0.10 whitney whitney.tpci.com
147.120.0.11 sinbad sinbad.tpci.com
147.120.0.12 pepper pepper.tpci.com
This f il e is essent ial l y ident ical t o t hat of t he SCO UNIX ser ver , because al l t he
machines on t he net wor k have t he same names and addr esses. Because t he l ocal host
name is set t o f r eya, t he Linux ser ver knows which ent r y in t he f il e r ef er s t o it sel f .
The f il e /et c/pr ot ocol s ident if ies al l t he t r anspor t pr ot ocol s avail abl e on t he Linux
ser ver and gives t heir r espect ive pr ot ocol number s. Al l syst ems have t his f il e, al t hough
some ent r ies might be comment ed out t o pr event unwant ed int r usion or abuse. Wit h
Linux t he /et c/pr ot ocol s f il e is not usual l y modif ied by t he administ r at or . Inst ead, t he
f il e is maint ained by t he net wor king sof t war e and updat ed aut omat ical l y as par t of
inst al l at ion pr ocedur es. The f il e cont ains t he pr ot ocol name, it s number , and any al ias
t hat can be used f or t hat pr ot ocol . The /et c/pr ot ocol s f il e f r om t he Linux ser ver is
shown her e:
# protocols
ip 0 IP # internet protocol, pseudo protocol
number
icmp 1 ICMP # internet control message protocol
igmp 2 IGMP # internet group multicast protocol
ggp 3 GGP # gateway-gateway protocol
tcp 6 TCP # transmission control protocol
pup 12 PUP # PARC universal packet protocol
udp 17 UDP # user datagram protocol
idp 22 IDP # WhatsThis?
raw 255 RAW # RAW IP interface
The exact cont ent s of t he /et c/pr ot ocol s f il e on your syst em might dif f er a l it t l e f r om
t he f il e shown her e, but t he pr ot ocol number s and names ar e pr obabl y t he same. Ther e
might be addit ional pr ot ocol s l ist ed, depending on your ver sion of Linux and
net wor king sof t war e.
The l ast TCP/IP conf igur at ion f il e used on most Linux syst ems ident if ies exist ing
net wor k ser vices. This is /et c/ser vices. As wit h t he /et c/pr ot ocol s f il e, t his f il e is not
usual l y modif ied by an administ r at or but is maint ained by sof t war e when inst al l ed or
conf igur ed. The /et c/ser vices f il e is in ASCII f or mat and consist s of t he ser vice name, a
por t number , and t he pr ot ocol t ype. The por t number and pr ot ocol t ype ar e separ at ed by
a sl ash. Any opt ional ser vice al ias names f ol l ow. A shor t ext r act f r om a sampl e
/et c/ser vices f il e (t he f il e is usual l y quit e l engt hy) is shown next :
# network services
echo 7/tcp
echo 7/udp
discard 9/tcp sink null
discard 9/udp sink null
ftp 21/tcp
telnet 23/tcp
smtp 25/tcp mail mailx
tftp 69/udp
# specific services
login 513/tcp
who 513/udp whod
Most /et c/ser vices f il es have many mor e l ines, because a wide number of TCP/IP ser vices
ar e suppor t ed by most ver sions of Linux. Because you never have t o wor r y about t he
cont ent s of t his f il e, you don't need t o check each ent r y.
Configuring Solaris
SunSof t Sol ar is 2.4 is a Syst em V Rel ease 4 ver sion of UNIX, so it is conf igur ed ver y much
l ike t he SCO UNIX syst em conf igur ed ear l ier . The Et her net int er f ace and dr iver s ar e
l inked int o t he ker nel when t he oper at ing syst em is l oaded, so none of t he device
conf igur at ion shoul d have t o be modif ied. When t he Sol ar is oper at ing syst em is l oaded,
par t of t he conf igur at ion pr ocedur e asks f or t he name of t he ser ver and it s IP addr ess (in
t he sampl e net wor k t he name is br ut us and t he IP addr ess is 147.120.0.3).
These set t ings ar e t hen pl aced in t he /et c/host s f il e. You can use any ASCII edit or t o
ent er t he r est of t he machines on t he sampl e net wor k t o compl et e t he /et c/host s f il e, as
shown her e:
#
# Internet Host Table
#
127.0.0.1 localhost
147.120.0.3 brutus brutus.tpci.com loghost
147.120.0.1 merlin merlin.tpci.com
147.120.0.2 freya freya.tpci.com
147.120.0.4 megan megan.tpci.com_
147.120.0.10 whitney whitney.tpci.com
147.120.0.11 sinbad sinbad.tpci.com
147.120.0.12 pepper pepper.tpci.com
The /et c/net wor ks f il e on t he SPARCst at ion ser ver is simil ar t o t hat on t he SCO UNIX
machine:
loopback 127
sco 132.147
sco-hq 132.147.128
sco-mfg 132.147.64
sco-engr 132.147.192
sco-slip 132.147.32
sco-tcplab 132.147.160
sco-odtlab 132.147.1
maclean_net 147.50.1
bnr.ca 47
In some cases, addit ional ent r ies might exist f or backwar d-compat ibil it y r easons. You can
add as many ent r ies as you want t o t he /et c/net wor ks f il e.
As wit h Linux, t he /et c/ser vices and /et c/pr ot ocol s f il es ar e l ef t al one, because t hey ar e
suppl ied wit h al l t he conf igur at ion det ail s al r eady ent er ed. These f il es can be modif ied
if you need t o disabl e a par t icul ar ser vice (f or secur it y r easons, f or exampl e), but in
most cases t hey ar e best l ef t unmodif ied.
The SPARCst at ion was suppl ied wit h an RJ45 connect or t o t he Et her net net wor k, so I
used a t r ansceiver t o conver t f r om RJ45 t o a BNC connect or . Passing t hr ough t he
t r ansceiver conver t s t he Et her net connect ion t o t he mode you need. I coul d have wir ed
t he ent ir e net wor k wit h RJ45 connect or s, but I woul d t hen need a hub t o connect al l
t he RJ45 connect or s t o (as I discussed on Day 1, "Open Syst ems, St andar ds, and
Pr ot ocol s").
Af t er t he SPARCst at ion is connect ed t o t he net wor k, you can t r y pinging a r emot e
machine. If you get a pr oper r esponse, al l is wel l and you can move on t o conf igur ing
ot her machines. If t her e is a pr obl em wit h ping, you have t o ver if y t hat al l t he f il es ar e
cor r ect , t hat t he IP addr ess is val id, and t hat t he net wor k t r ansceiver is f unct ioning
pr oper l y.
Configuring Windows NT Server
Windows NT is avail abl e in bot h ser ver and wor kst at ion ver sions. Today I conf igur e t he
ser ver ver sion f or t he sampl e net wor k. I use Windows NT Ser ver 3.51 on t he sampl e
syst em al t hough Windows NT 4.0 per f or ms in al most exact l y t he same way. (Windows NT
4.0 was st il l in bet a as t his book was being wr it t en; t he onl y changes not iceabl e wer e
because of t he GUI modif icat ions t o r esembl e t he Windows 95 GUI.) Al t hough TCP/IP is
pr ovided wit h Windows NT, it is not inst al l ed as t he def aul t net wor k pr ot ocol . Inst ead,
IPX/SPX and Net BEUI ar e inst al l ed as def aul t pr ot ocol s. To conf igur e TCP/IP, you need
t o ext r act t he TCP/IP sof t war e f r om t he dist r ibut ion media if it hasn't al r eady been
inst al l ed.
You can check f or t he pr esence of t he TCP/IP sof t war e by opening t he Net wor k Set t ings
window inside t he Cont r ol Panel . This window is shown in Figur e 9.2. The scr ol l l ist in
t he bot t om l ef t cor ner has a l ist of al l inst al l ed component s. If it does not incl ude an
ent r y such as TCP/IP Pr ot ocol , t he TCP/IP sof t war e is not inst al l ed. To inst al l t he
TCP/IP sof t war e, cl ick t he Add Sof t war e but t on on t he Net wor k Set t ings window.
Figur e 9.2. The Windows NT Net wor k Set t ings scr een shows al l t he component s
t hat ar e inst al l ed.
When you sel ect Add Sof t war e, t he syst em checks f or al l t he inst al l ed and avail abl e
component s (which can t ake some t ime), t hen displ ays t he windows shown in Figur e 9.3.
Af t er sel ect ing TCP/IP t o be inst al l ed, you can sel ect t he specif ic TCP/IP component s
and any ot her TCP/IP ser vices you want t o inst al l f r om t he window shown in Figur e 9.4.
Figur e 9.3. You can add t he TCP/IP sof t war e t o your Windows NT syst em t hr ough
t his window.
Figur e 9.4. Sel ect t he component s of t he Windows NT TCP/IP sof t war e t hat you
want t o inst al l f r om t his window.
The ser ver ver sion of Windows NT of f er s sever al TCP/IP conf igur at ion opt ions and ext r a
ser vices. Those shown in Figur e 9.4 incl ude t he f ol l owing:
G TCP/IP Int er net wor king: These must be inst al l ed f or TCP/IP t o f unct ion. It
incl udes t he dr iver s f or TCP, IP, UDP, and ARP, as wel l as sever al ot her pr ot ocol s
l ike ICMP. PPP and SLIP ar e al so pr ovided t hr ough t his opt ion.
G Connect ivit y Ut il it ies: Ut il it ies l ike f inger , ping, t el net , and many ot her s. These
shoul d be inst al l ed wit h al l TCP/IP conf igur at ions.
G SNMP Ser vice: The SNMP dr iver s used t o enabl e t he ser ver or wor kst at ion t o be
administ er ed r emot el y. This opt ion shoul d be used if your Windows NT machine is
t o be managed by a r emot e UNIX wor kst at ion. The SNMP Ser vice is al so r equir ed if
you want t o r un t he Per f or mance Monit or and obt ain TCP/IP behavior st at ist ics.
G TCP/IP Net wor k Pr int ing: Enabl es net wor k pr int er s (t hose at t ached dir ect l y t o
t he net wor k cabl es inst ead of a PC) t o be used. This opt ion can al so be used if you
want t o send al l pr int r equest s on t his machine t o anot her machine f or handl ing,
such as a UNIX pr int ser ver .
G FTP Ser ver Ser vice: If you want t o use FTP t o t r ansf er f il es f r om Windows NT,
t his ser vice must be l oaded.
G Simpl e TCP/IP Ser vices: Of f er s special t y ser vices l ike Dayt ime, Echo, and Quot e
t hat ar e used by some appl icat ions. If you ar e using UNIX wor kst at ions on t he
same net wor k, t hese ser vices pr obabl y shoul d be suppor t ed by t he Windows NT
machine.
G DHCP Ser ver Ser vice: Inst al l s t he DHCP ser ver sof t war e. If you want t o use
DHCP on your net wor k, you need a DHCP ser ver .
G WINS Ser ver : If WINS is t o be used on your net wor k, inst al l t he ser ver sof t war e.
Cl icking t he OK but t on begins t he inst al l at ion pr ocess, wit h Windows NT pr ompt ing you
f or t he dist r ibut ion CD-ROM or disks as needed. Af t er t he TCP/IP sof t war e is inst al l ed,
you have t o r eboot t he machine and t hen t he Net wor k Set t ings window shoul d show
t he TCP/IP pr ot ocol s in pl ace.
If you inst al l ed a net wor k adapt er when t he Windows NT oper at ing syst em sof t war e
was l oaded, t he net wor k adapt er car d shoul d al so show in t he l ist of inst al l ed
component s in t he Net wor k Set t ings window. If you need t o add a net wor k adapt er car d
t o t he syst em, it can be added t hr ough t he Net wor k Set t ings window, t oo. The Add
Adapt er but t on st ar t s t he inst al l at ion r out ine, which pr ompt s f or t he t ype of net wor k
adapt er car d, t hen t he set t ings on t he car d f or IRQ and memor y addr ess. Af t er t he
net wor k car d has been conf igur ed, t he dr iver s ar e l oaded by Windows NT, t hen a syst em
r eboot makes t he car d avail abl e.
The Net wor k Set t ings window l et s you conf igur e each component of t he TCP/IP
sof t war e inst al l ed on t he Windows NT ser ver . You can change t he machine name and
domain name f r om t he Net wor k Set t ings window by cl icking t he Change but t on next t o
t hose it ems at t he t op of t he scr een. Onl y an administ r at or can change t he machine and
domain names.
If you highl ight TCP/IP Pr ot ocol in t he Net wor k Set t ings window, t hen cl ick t he
Conf igur e but t on, you see t he TCP/IP Conf igur at ion window shown in Figur e 9.5. This
l et s you pr ovide t he IP addr ess of t he l ocal machine (assuming it is not assigned t hr ough
t he use of anot her ser vice l ike DHCP or WINS). If you ar e using a DHCP or WINS ser ver
(ot her t han t he machine you ar e conf igur ing now), t he IP addr ess of t hat ser ver shoul d
be ent er ed on t his scr een.
Figur e 9.5. The IP addr ess of t he l ocal machine is ent er ed in t his window.
If you ar e using DNS on your net wor k, sel ect t he DNS but t on in t he TCP/IP
Conf igur at ion window. This displ ays t he DNS Conf igur at ion window. This window l et s
you specif y t he host name and domain name of t he DNS ser ver as wel l as any specif ics
about t he DNS ser ver sear ch or der . If you ar e not using DNS, you can l eave t his window
as it is. Because you ar e not set t ing up a DNS ser ver at t he moment , you can l eave t his
window al one. Final l y, t he Advanced but t on on t he TCP/IP Conf igur at ion window l et s
you sel ect subnet masks and gat eway IP addr esses, if necessar y.
Fr om t he Net wor k Set t ings window, you shoul d check t he net wor k bindings t o make
sur e TCP/IP is used f or communicat ions over t he l ocal ar ea net wor k. Sel ect t he Bindings
but t on on t he Net wor k Set t ings window t o displ ay t he Net wor k Bindings window,
shown in Figur e 9.6.
Figur e 9.6. The Net wor k Bindings window shows al l net wor k bindings conf igur ed on
t he syst em.
If TCP/IP is pr oper l y conf igur ed, you see t he TCP/IP pr ot ocol bound t o t he net wor k
adapt er car d. The binding shoul d be enabl ed, as shown by a yel l ow l ight bul b t o t he l ef t
of t he binding name. If it is not enabl ed, cl ick t he Enabl e but t on at t he bot t om of t he
window. If ot her pr ot ocol s, such as IPX/SPX, ar e bound t o t he same net wor k car d and
enabl ed but not needed, you shoul d disabl e t hem. Onl y l eave t he bindings t hat you need
enabl ed.
Af t er t he conf igur at ion inf or mat ion has been ver if ied, you shoul d cl ick Updat e or OK
and al l ow Windows NT t o compl et e t he conf igur at ion f or you. You might have t o
pr ovide t he sour ce disks or CD-ROM if new sof t war e is necessar y. Af t er t he
conf igur at ion is compl et e, you need t o r eboot t he machine t o ef f ect any changes.
To ver if y t hat t he conf igur at ion is wor king pr oper l y, you shoul d r un t he ping command
and t r y pinging anot her machine on t he net wor k. The ping ut il it y is DOS-based and can
usual l y be f ound under WINNT35\SYSTEM32. St ar t a DOS session and issue t he ping
command, f ol l owed by a known IP addr ess. If t he r emot e is successf ul l y pinged, your
inst al l at ion and conf igur at ion ar e wor king.
Testing the Server Configurations
Test ing t he TCP/IP conf igur at ion on any of t he f our conf igur ed ser ver s is
st r aight f or war d. Begin by using ping on each machine t o ensur e t hat t he sof t war e is
t al king t o t he net wor k har dwar e. Unf or t unat el y, a successf ul ping of t he l ocal
machine does not al ways mean t he net wor k is being accessed pr oper l y; it simpl y means
t he net wor k sof t war e is pr ocessing t he r equest . To t est t he net wor k int er f ace it sel f ,
ping t he ot her machines on t he net wor k. In t he f ol l owing exampl e, mer l in is t he l ocal
host and sinbad is a DOS machine r unning f t p Sof t war e's PC/TCP (which you see
t omor r ow):
$ ping merlin
PING localhost (147.120.0.1): 56 data bytes
64 bytes from localhost (147.120.0.1): icmp_seq=0 ttl=255
time=0 ms
64 bytes from localhost (147.120.0.1): icmp_seq=1 ttl=255
time=0 ms
64 bytes from localhost (147.120.0.1): icmp_seq=2 ttl=255
time=0 ms
64 bytes from localhost (147.120.0.1): icmp_seq=3 ttl=255
time=0 ms
64 bytes from localhost (147.120.0.1): icmp_seq=4 ttl=255
time=0 ms
--- localhost ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0/0/0 ms
$ ping sinbad
PING sinbad (147.120.0.11): 56 data bytes
64 bytes from localhost (147.120.0.1): icmp_seq=0 ttl=255
time=20 ms
64 bytes from localhost (147.120.0.1): icmp_seq=1 ttl=255
time=20 ms
64 bytes from localhost (147.120.0.1): icmp_seq=2 ttl=255
time=50 ms
64 bytes from localhost (147.120.0.1): icmp_seq=3 ttl=255
time=30 ms
64 bytes from localhost (147.120.0.1): icmp_seq=4 ttl=255
time=40 ms
--- pepper ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 20/32/50 ms
The f ir st t est shows t hat t he sof t war e is conf igur ed pr oper l y. The command t o ping
mer l in r esul t ed in a conver sion wit hin t he /et c/host s f il e t o r ecognize t he inst r uct ion
as t he l ocal host ent r y. Af t er ver if ying t he l ocal connect ion, t he r emot e machine is
t r ied. The successf ul r ound-t r ip of t he packet s indicat es t hat t he r emot e is wor king
pr oper l y, and t hat t he net wor k is f unct ional . Of cour se, t his wor ks onl y if t he r emot e
machine has been l oaded wit h TCP/IP sof t war e and is act ive.
If t he l ocal host ping command f ail ed, t he sof t war e was pr obabl y conf igur ed
incor r ect l y, or t he har dwar e was not accessed pr oper l y. Fir st , check t he connect or s on
t he net wor k car ds, because t hey have an annoying habit of wor king l oose. Next , check
t he net wor k conf igur at ion (IRQ, addr ess, and t ype of adapt er ), f ol l owed by t he
conf igur at ion f il es, as shown ear l ier . If ever yt hing l ooks cor r ect and t he r emot e
machine answer s it s own ping command pr oper l y, t her e is a pr obl em wit h sof t war e
compat ibil it y.
The net st at net wor k st at us command is usef ul f or monit or ing t he net wor k's
per f or mance and det ect ing pr obl ems. TCP/IP syst em administ r at or s f r equent l y use t he
opt ions -i, -m, and -s. See Day 13, "Managing and Tr oubl eshoot ing TCP/IP," f or mor e
t r oubl eshoot ing inf or mat ion.
A common pr obl em is t he l ack of enough STREAMS buf f er s, which causes a pr ocess t o
hang or a connect ion t o t er minat e f or no appar ent r eason. The size of t he STREAMS
buf f er and it s cur r ent st at us can be checked wit h t he command net st at -m:
$ netstat -m
streams allocation:
config alloc free total max
fail
streams 292 78 214 145 79
0
queues 1424 360 1064 327 364
0
mblks 5077 197 4880 3189 206
0
dblks 4062 197 3865 3167 205
0
class 0, 4 bytes 652 51 601 357 53
0
class 1, 16 bytes 652 1 651 284 3
0
class 2, 64 bytes 768 8 760 2158 15
0
class 3, 128 bytes 872 104 768 237 106
0
class 4, 256 bytes 548 21 527 90 22
0
class 5, 512 bytes 324 12 312 13 13
0
class 6, 1024 bytes 107 0 107 1 1
0
class 7, 2048 bytes 98 0 98 1 1
0
class 8, 4096 bytes 41 0 41 26 1
0
total configured streams memory: 1183.09KB
streams memory in use: 44.66KB
maximum streams memory used: 58.28KB_
The number in t he f ail col umn shoul d be 0 in each r ow; ot her wise, t her e is a pr obl em
wit h t he amount of buf f er al l ocat ed. To change t he number of STREAMS buf f er s
al l ocat ed, ker nel var iabl es must be changed and t he ker nel r el inked. As a gener al
r ul e, if t her e ar e pr obl ems wit h t he exist ing STREAMS buf f er sizes, incr ease t he number
by 50 per cent . If t hat doesn't sol ve t he pr obl em, incr ease by anot her 50 per cent .
To f ul l y t est t he TCP/IP syst em, use Tel net or FTP t o l og in and t r ansf er f il es f r om
machine t o machine. Because t hese t wo ut il it ies ar e t he most common user s of TCP/IP
(unl ess NIS or NFS ar e act ive), t hey hel p show any pr obl ems wit h t he por t assignment s,
ser vices pr ovided, or name mapping.
Pseudo ttys
Most UNIX syst ems suppor t pseudo t t ys (f al se t er minal s) t o enabl e ext er nal machines t o
use Tel net and r l ogin f or access t o t he l ocal machine. Wit hout a pseudo t t y, t he r emot e
machine cannot est abl ish a session.
The SCO UNIX syst em, f or exampl e, conf igur es 32 pseudo t t ys by def aul t , which shoul d
be pl ent y f or smal l and moder at e sized net wor ks. (Remember t hat 32 pseudo t t ys enabl e
32 sessions f r om r emot e user s.) Adding or del et ing pseudo t t ys can be done t hr ough a
conf igur at ion ut il it y or , in t he case of SCO UNIX, wit h t he mkdev pt t y command. Ther e
is no usef ul advant age gained by dr ast ical l y r educing t he number of pseudo t t ys on
smal l net wor ks. Pseudo t t ys shoul d be r econf igur ed af t er TCP/IP has been inst al l ed and
is wor king cor r ect l y.
User Equivalence
User equival ence l et s a user r l ogin t o anot her machine wit h t he same account
inf or mat ion, wit hout ent er ing a passwor d. This is hel pf ul when a user must l og int o
anot her machine f r equent l y, avoiding t he l ogin pr ocess f or speed and r educing t he
number of pr ocesses r unning on t he r emot e.
To per mit user equival ence, UNIX r equir es t hat t he user exist s on bot h machines and
t hat ent r ies in t wo conf igur at ion f il es mat ch. The /et c/passwd f il e, which cont r ol s
over al l access t o t he machine, must have an ent r y f or t he user 's l ogin name on bot h
machines. One of t wo conf igur at ion f il es al so must have inf or mat ion about t he user .
If t he f il e .r host s is used, user equival ence is est abl ished onl y f or account s specif ical l y
named in t he f il e. The .r host s f il e usual l y r esides in t he r oot dir ect or y and has one
ent r y per l ine, specif ying t he r emot e machine name and t he user ID. An .r host s f il e l ooks
l ike t his:
# .rhosts file for brutus.com
merlin tparker
merlin ychow
merlin bsmallwood
pepper etreijs
pepper tparker
freya rmaclean
Wit h t his conf igur at ion, t he user t par ker , on r emot e machine mer l in, coul d l og in t o t he
l ocal machine as t par ker onl y. A user can al l ow access t o an account by anot her by
cr eat ing a .r host s f il e in his or her home dir ect or y.
If t he f il e host s.equiv is used (which usual l y r esides in t he /et c dir ect or y), user
equival ence is val id f or any account on bot h machines except r oot . If t he f il e
host s.equiv cont ained onl y a machine name, any val id user on t hat machine woul d be
al l owed user equival ence (except r oot ). The machine is cal l ed a trusted host .
Unf or t unat el y, t his t ype of access poses consider abl e secur it y pr obl ems, so it shoul d be
used onl y under st r ingent l y cont r ol l ed or ver y r el iabl e condit ions. A major pr obl em is
t hat a user can l og in as any ot her val id user on t he r emot e syst em wit hout using a
passwor d. A sampl e host s.equiv f il e l ooks l ike t his:
# hosts.equiv for brutus.com
merlin tparker
pepper
freya rmaclean
In t his exampl e, any user on t he r emot e syst em (pepper ) coul d l og in as any val id user
(except r oot ) on t he l ocal machine, wit hout using a passwor d. Onl y t he user t par ker , on
t he r emot e machine mer l in, coul d l og in as any val id syst em user (except r oot ) on t he
l ocal machine. The pot ent ial f or misuse of user equival ence wit h t his t ype of access is
high, al t hough it can be handy f or access t o specif ic ut il it ies or appl icat ions.
If bot h .r host s and host s.equiv exist wit h ent r ies f or t he same machine and user ID, t he
ent r y f r om t he host s.equiv f il e is used f or det er mining t he user 's equival ence. Remember
t hat f or bot h .r host s and host s.equiv, mat ching user ent r ies must exist in t he /et c/passwd
f il e.
User equival ence conf igur at ion can cause pr obl ems f or syst em administ r at or s t hat ar e
f r equent l y bl amed on t he net wor k sof t war e. Al so, some user s might want t o al l ow
specif ic ent r ies by a user on a r emot e syst em wit hout having t he syst em administ r at or
gr ant open pr ivil eges.
To il l ust r at e t he ent r ies mor e cl ear l y, a concr et e exampl e might hel p. Assume user
ychow, on t he machine pepper , want s t o access machine mer l in as bot h ychow and shor t ie
wit hout using passwor ds. (In ot her wor ds, ychow on pepper is equival ent t o ychow and
shor t ie on mer l in.) Ther e ar e sever al met hods of conf igur ing t he syst em t o al l ow t his.
The syst em administ r at or can cr eat e an .r host s f il e in t he r oot dir ect or y t hat has t he
f ol l owing ent r ies:
pepper ychow
pepper shortie
This al l ows onl y ychow (on pepper ) t o l og in as ychow, wit h no access as shor t ie unl ess
shor t ie is l ogged in t o pepper , t oo. This isn't what is r equir ed. An ent r y in t he host s.equiv
f il e l ike t his
pepper ychow
doesn't sol ve t he pr obl em eit her because ychow can now l og in as any val id user on
mer l in. Sol ving t his r equir es each user t hat want s t o al l ow ychow t o access t heir
dir ect or ies t o pl ace an .r host s f il e in t heir home dir ect or ies. On t he sampl e net wor k,
bot h ychow's and shor t ie's home dir ect or ies on mer l in woul d have t he same ent r ies.
User ychow can now l og in t o mer l in using one of t he f ol l owing commands:
rlogin merlin
or
rlogin merlin -l shortie
The l at t er command l ogs ychow in as t he user equival ent shor t ie. The f ir st r et ains t he
same l ogin ID. Not e t hat t he .r host s f il e r esides in t he home dir ect or ies of t he user s who
want t o al l ow r emot e user access.
Anonymous FTP
Anonymous FTP enabl es user s f r om ot her l ocat ions t o access a syst em wit hout l ogging
on. They obt ain t he FTP pr ompt as usual but ent er anonymous as t he user name. In most
syst ems, a passwor d can be anyt hing, al t hough convent ion dict at es t hat t he user 's l ogin
name be suppl ied f or t r acking pur poses. Ther e is no check of t he names, however . Once
l ogged in t o anonymous FTP, user s can br owse t hr ough publ ic dir ect or ies and r et r ieve
f il es t hat r eside t her e. Anonymous FTP is excel l ent f or dist r ibut ing inf or mat ion t o t he
gener al publ ic, but it s open access has accompanying secur it y concer ns.
When a user l ogs in t o t he anonymous FTP account , UNIX invokes a pr ocess cal l ed
chr oot , which r est r ict s t he user f r om moving out of t he home dir ect or y. The dependence
on chr oot r equir es t hat some syst em conf igur at ion f il es (incl uding a copy of t he
/et c/passwd and /et c/gr oup f il es) r eside in t he anonymous FTP dir ect or ies.
Conf igur ing a UNIX syst em f or anonymous FTP invol ves est abl ishing a publ ic dir ect or y
syst em and changing f il e per missions t o pr event unwant ed access t o ot her par t s of t he
f il e syst em. Al so, an anonymous account is cr eat ed using t he user name f t p. Anonymous
FTP usual l y uses t he user f t p's home dir ect or y cr eat ed when t he user is gener at ed.
To set up anonymous FTP access, cr eat e a user cal l ed f t p. Wit h UNIX syst ems, t his is
usual l y per f or med wit h a scr ipt cal l ed mkuser or a syst em ut il it y. Al t er nat ivel y, t he
user can be added t o t he /et c/passwd f il e. A gr oup cal l ed f t p shoul d exist or be cr eat ed.
Once t he home dir ect or y f or t he user f t p exist s, change it s user and gr oup ident it ies t o
f t p (using t he chown and chgr p commands).
Assuming t he user ID f t p has been cr eat ed and t he home dir ect or y is /usr /f t p, t he st eps t o
f ol l ow ar e shown her e. (Comment s shown af t er t he pound sign ar e f or descr ipt ion
pur poses onl y and need not be ent er ed.)
$ cd /usr/ftp # change to the home directory
$ chmod 555 . # set file permissions to r-x
$ chown ftp . # change the owner to ftp
$ chgrp ftp . # change the group to ftp
$ mkdir pub # create public directory (see below)
$ chmod 777 pub # set pub dir permissions as rwx
$ mkdir bin # create bin dir for executables
$ cd bin
$ chmod 555 bin # set bin dir to r-x
$ cp /bin/sh /bin/ls .
$ cd ..
$ mkdir etc # create etc dir for passwd file
$ chmod 555 etc # set etc dir to r-x
$ cd etc
$ cp /etc/passwd /etc/group .
$ chmod 444 passwd group
$ cd ..
If you want t o cr eat e subdir ect or ies beneat h t he home dir ect or y f or t he anonymous
user t o access, ensur e t hat t hey have t he cor r ect owner ships, as wel l . It is common
pr act ice t o cr eat e a dir ect or y cal l ed f t p/pub f or upl oading f il es t o t he syst em. Set f il e
per missions so t hat t he user cannot exit t he home dir ect or y st r uct ur e. In t he pr evious
exampl e, al l t he dir ect or ies except pub ar e set t o r ead and execut e onl y. The exampl e
copied t he shel l and l ist ing ut il it ies int o t he FTP dir ect or y st r uct ur e so t he anonymous
user can access t hem. Ot her ut il it ies can be copied if desir ed.
The /et c/passwd and /et c/gr oup f il es must be copied int o a dir ect or y cal l ed et c (bel ow
t he f t p user 's home dir ect or y) t o enabl e chr oot t o f unct ion pr oper l y. It is st r ongl y
r ecommended t hat t hese f il es be edit ed t o r emove any ot her user inf or mat ion; it is
conceivabl e t hat an anonymous user coul d access and anal yze t he f il es f or inf or mat ion
about t he l ocal syst em, l eading t o an unwel come br eak-in. Remove al l user s f r om t he
/et c/passwd f il e except f or r oot , daemon, uucp, and t he f t p ent r ies. Simil ar l y, pr une t he
/et c/gr oup f il e t o r emove al l but t hese ent r ies.
To hel p pr event unwant ed access, t he f il e et c/f t puser s can be cr eat ed t o cont ain user
names t hat r esul t in immediat e disconnect ion. This f il e shoul d have ent r ies f or r oot and
uucp as a minimum.
Windows NT Ser ver enabl es anonymous FTP t hr ough a dif f er ent mechanism (because it
isn't UNIX). To enabl e anonymous FTP on t he Windows NT ser ver on t he sampl e net wor k,
you have t o enabl e t he FTP ser ver . The sof t war e f or t he ser ver shoul d be inst al l ed as
shown ear l ier . Dur ing t he inst al l at ion you wil l pr obabl y r eceive a war ning about t he
insecur it y of using FTP t o t r ansf er passwor ds over your net wor k. However , unl ess you
can inst al l an aut hent icat ion scheme f or your passwor ds, t his is a necessar y evil t o
enabl e FTP access t o t he Windows NT machine.
To conf igur e t he FTP ser ver sof t war e, you sel ect t he FTP ser ver it em f r om t he Net wor k
Set t ings window shown in Figur e 9.2, t hen cl ick t he Conf igur e but t on. This displ ays t he
FTP Ser vice window shown in Figur e 9.7. You can adjust t he number of sessions al l owed
as wel l as t he t ime-out int er val using t he opt ions at t he t op of t his window.
Figur e 9.7. Use t his window t o al t er t he behavior of t he FTP ser ver .
You might not ice t hat t he bot t om par t of t he scr een l et s you set t he FTP ser ver t o
enabl e anonymous connect ions. You can set t he anonymous l ogin and passwor d if you
want . This enabl es user s who ar e not on t he aut hor ized Windows NT User s' l ist t o
t r ansf er f il es f r om t he Windows NT machine. It is a good idea t o r est r ict access t o a
subdir ect or y wher e t her e ar e no sensit ive f il es avail abl e.
You can monit or t he behavior of t he FTP ser ver syst em t hr ough t he FTP Ser ver icon on
t he Cont r ol Panel . This displ ays a window l ike t he one shown in Figur e 9.8, which l ist s
al l act ive user s. The Disconnect and Disconnect Al l but t ons at t he bot t om of t he
window can be used t o f or ce user s of f t he Windows NT machine.
Figur e 9.8. The FTP Ser ver window shows user s who ar e cur r ent l y using FTP.
Some secur it y set t ings can be cont r ol l ed t hr ough t he FTP Ser ver window by cl icking
t he Secur it y but t on. This displ ays t he window shown in Figur e 9.9. The Read and Wr it e
opt ions enabl e you t o cont r ol access t o ent ir e dr ives (al l f l oppy and har d dr ives, as
wel l as any mount ed dr ives such as CD-ROMs and opt ical or r emovabl e media).
Figur e 9.9. The FTP Ser ver Secur it y window l et s you set br oad access r ight s t o
dr ives.
Configuring SLIP and PPP
Ser ial Line Int er net Pr ot ocol (SLIP) and Point -t o-Point Pr ot ocol (PPP) oper at e over
ser ial l ines and r equir e some addit ional inf or mat ion. Because SLIP and PPP connect ions
ar e bet ween t wo machines, t he sour ce and dest inat ion IP addr esses ar e needed. Al so, t he
ser ial por t ident if ier is needed, incl uding t he int er r upt vect or it uses. Ser ial l ines must
be pr oper l y conf igur ed wit h t heir baud r at e. This is usual l y set wit hin anot her f il e on
t he syst em. SLIP connect ions al so r equir e a net mask set t ing, al t hough t his is not needed
f or PPP.
PPP is mor e ver sat il e t han SLIP. SLIP suppor t s asynchr onous communicat ions onl y,
wher eas PPP enabl es synchr onous and asynchr onous. SLIP must have a dedicat ed l ine
t hat is al ways t ied up, wher eas PPP can shar e t he l ine wit h ot her pr ogr ams l ike UUCP
and f r ee t he l ine on command. SLIP l acks any er r or det ect ion, wher eas PPP impl ement s
it . Given t he choice, PPP is t he bet t er ser ial -l ine TCP pr ot ocol , al t hough it is not
avail abl e wit h al l oper at ing syst em impl ement at ions.
SLIP and PPP connect ions ar e usual l y est abl ished in t he same manner as t he Et her net
dr iver s. SCO UNIX, f or exampl e, uses t he net conf ig ut il it y, ment ioned pr eviousl y. When
adding a SLIP or PPP chain, t he syst em pr ompt s f or t he ser ial l ine t o be used, t he baud
r at e, t he addr ess of t he l ocal and dest inat ion machines, and t he r emot e machine's name.
It t hen conf igur es t he syst em t o use t hat ser ial por t . Af t er r el inking t he ker nel and
r eboot ing, t he ser ial l ine is avail abl e f or eit her SLIP or PPP (depending on t he way it
was conf igur ed).
Remote Printing
Remot e pr int ing is a usef ul f eat ur e t hat enabl es a user on one machine t o send pr int jobs
t o ot her machines t hat have at t ached pr int er s. The syst em is cal l ed Remot e Line
Pr int ing (RLP) and is commonl y used t o shar e pr int er s in a wor kgr oup. It is al so usef ul
f or enabl ing access t o special t y pr int er s such as col or l aser s and pl ot t er s. RLP does not
suppor t pr int er cl asses, and some oper at ing syst ems impose r est r ict ions on suppor t ed pr int
command-l ine opt ions. Remot e administ r at ion of pr int er s is not suppor t ed.
RLP f unct ions dif f er ent l y t han nor mal UNIX pr int ing. When a pr int r equest is issued,
t he syst em consul t s t he pr int er conf igur at ion f il e (usual l y /et c/pr int cap) t o det er mine
if t he pr int er is l ocal or r emot e. If t he pr int r equest is f or a l ocal pr int er , t he usual
pr ocess appl ies. If t he r equest is f or a r emot e pr int er , t he l ocal syst em spool s t he pr int
r equest and invokes t he l pd daemon, which packages t he pr int r equest and sends it t o
t he r emot e machine, wher e it is spool ed f or t he pr int er . A user can set a r emot e pr int er
as t he def aul t dest inat ion, as is commonl y done in wor kgr oups t hat shar e a singl e
pr int er .
Sever al ver sions of RLP ar e avail abl e wit h suppor t f or dif f er ent oper at ing syst ems on a
net wor k. SCO UNIX, f or exampl e, suppor t s t wo kinds of cl ient s: SCO-based syst ems and
4.3BSD syst ems. This enabl es wor kst at ions r unning Ber kel ey's 4.3BSD t o queue pr int
r equest s t o SCO pr int ser ver s. SCO cl ient s use RLP wit h t he same commands as a l ocal
pr int er woul d (l p and cancel ), but 4.3BSD cl ient s have special ver sions of t he commands
(l pr and l pr m).
Assuming t hat RLP is avail abl e wit h your oper at ing syst em (some ver sions of UNIX do
not suppor t it ), it is usual l y inst al l ed and act ivat ed wit h a scr ipt or ut il it y pr ogr am.
Wit h SCO UNIX, a mkdev r l p command init iat es t he inst al l at ion scr ipt . Ot her oper at ing
syst ems use a simil ar ut il it y. Dur ing t he inst al l at ion pr ocess, a number of dir ect or ies ar e
cr eat ed t o handl e t he spool ing, and modif icat ions ar e made t o t he pr int er conf igur at ion
f il es. The ol d pr int ing commands ar e ar chived t o a dir ect or y, and new ver sions t hat
suppor t RLP ar e copied int o t heir pl ace.
Remot e pr int ing r equir es a special ent r y in t he pr int er conf igur at ion f il e (/et c/pr int cap).
Some oper at ing syst ems (such as SCO UNIX) have a scr ipt t hat edit s t he f il e f or you,
pr ompt ing f or t he conf igur at ion inf or mat ion. A sampl e l ine in t he f il e f or a r emot e
pr int er woul d l ook l ike t his:
hplaser::lp=:rm=main_hplaser:rp=hplaser:sd=/usr/spool/lpd/hplaser
The f ir st f iel d is t he name used by t he l ocal machine t o r ef er t o t he pr int er . The second
f iel d is usual l y empt y. It def ines t he name of an er r or l og f il e but is not used on most
syst ems. The t hir d f iel d is t he device name f or a l ocal pr int er . Remot e pr int er s l eave t he
f iel d as l p= wit h no specif ied pr int er . The f our t h f iel d is t he net wor k name f or t he
pr int er . It can be t he same as t he l ocal name. The f if t h f iel d is t he name t he pr int ser ver
uses f or t he pr int er (usual l y t he same as t he l ocal name). Final l y, t he sixt h f iel d is t he
name of t he spool ing dir ect or y f or t he pr int er . This is wher e pr int r equest s ar e spool ed
bef or e being sent t o t he r emot e pr int er .
In or der f or machines on t he net wor k t o access t he Hewl et t -Packar d Laser Jet t hat is
at t ached t o t he main machine on t he sampl e net wor k, t he t hr ee r emot e machines shoul d
have ent r ies f or t he pr int er in t heir /et c/pr int cap f il es. The main machine al so has an
ent r y f or it , but as a l ocal pr int er .
Administ er ing a r emot e pr int er is done eit her by l ogging int o t he consol e of t he machine
t o which t he pr int er is at t ached or by using sever al RLP ut il it ies f r om anot her machine.
The ut il it ies dif f er wit h each oper at ing syst em.
Windows NT Ser ver has r emot e TCP/IP pr int ing capabil it ies avail abl e as par t of t he
TCP/IP suit e.
Configuring SNMP
Most TCP/IP net wor ks use t he Simpl e Net wor k Management Pr ot ocol (SNMP) t o monit or
t he net wor k f or pr obl ems. It enabl es a syst em t o examine and al t er net wor king
inf or mat ion maint ained by ot her machines on t he net wor k. SNMP is a simpl e pr ot ocol
t hat uses UDP as a t r anspor t .
Many UNIX oper at ing syst ems use a daemon t o r un SNMP. When t he syst em is r unning,
SNMP l ist ens on it s dedicat ed por t f or incoming r equest s. Thr ee conf igur at ion f il es ar e
al so usual l y invol ved.
The f il e /et c/snmpd.conf cont ains basic inf or mat ion r equir ed by SNMP. The f il e cont ains
ident if ier s f or t he t ypes of SNMP and TCP/IP sof t war e, as wel l as t he cont act name of
t he syst em administ r at or and t he l ocat ion of t he syst em. A sampl e f il e l ooks l ike t his:
# snmpd.conf configuration file for tpci.com
# the first two fields are default value
descr=SNMPD Version 4.0 for SCO UNIX
objid=SCO.1.0
contact=Tim Parker x53153
location=Network Room
If SNMP is set t o send t r ap messages (asynchr onous event messages), it sends
int r oduct or y packet s (cal l ed cold-start t r aps) t o ot her syst ems t hat it is f unct ioning. It
r eads t he names of t he syst ems t o send col d-st ar t t r aps t o f r om t he f il e /et c/snmpd.t r ap,
which l ist s names, IP addr esses, and por t number s:
# sample snmpd.trap file for tpci.com
# lists symbolic name, IP address, and port
test1 128.212.64.99 162
merlin 147.120.0.2 162
The f il e snmpd.comm is a l ist of communit y and IP addr ess pair s t hat specif ies f r om whom
t he agent can accept quer ies. Each l ine in t he f il e has t he name of t he communit y
(somet imes cal l ed a session), t he IP addr ess of t he sit e (a val ue of 0.0.0.0 enabl es any
addr ess t o communicat e), and t he pr ivil eges t hat sit e is al l owed. If t he pr ivil ege is set t o
READ, onl y r ead oper at ions ar e per mit t ed; WRITE enabl es r ead and wr it e oper at ions;
and NONE r est r ict s al l access.
# Copyrighted as an unpublished work.
# Copyright 1989 INTERACTIVE Systems Corporation
# All rights reserved.
# @(#)snmpd.comm 3.1 INTERACTIVE SNMP source
test1 128.212.64.99 READ
test2 128.212.64.15 WRITE
test3 128.212.64.15 READ
public 0.0.0.0 read
beast 0.0.0.0 read
excaliber 0.0.0.0 read
Conf igur at ion of SNMP is usual l y t hr ough an int er act ive shel l scr ipt . Dur ing t he
scr ipt , t he user is pr ompt ed f or al l t he inf or mat ion needed f or t he t hr ee conf igur at ion
f il es. SCO UNIX uses t he command mkdev snmp t o inst al l t he syst em.
Summary
This chapt er has shown how t o inst al l and conf igur e sever al ser ver s wit h TCP/IP. These
met hods have been t est ed and wor k cor r ect l y. In t he pr ocess, t his chapt er ment ioned
sever al al t er nat ive ser vices such as anonymous FTP and r emot e pr int ing. Whet her t hese
ar e avail abl e on your net wor k is up t o you (or t he syst em administ r at or ). The next
chapt er adds cl ient machines t o t he sampl e net wor k.
Q&A
What inf or mat ion is necessar y t o conf igur e a machine' s TCP/IP sof t war e?
For a compl et e conf igur at ion, TCP/IP r equir es t he domain name, syst em name, IP addr ess,
dr iver t ype, br oadcast addr ess, net mask, and har dwar e net wor k car d set t ings. Some
syst ems enabl e conf igur at ion wit h onl y some of t his inf or mat ion.
What does t he net wor k mask do?
The net wor k mask r emoves t he net wor k ident if ier f r om an IP addr ess, l eaving onl y t he
l ocal machine's addr ess. For exampl e, an IP addr ess of 146.120.94.4 can have t he net wor k
mask 146.120 appl ied t o l eave t he l ocal machine addr ess as 94.4.
What r ol e does t he /et c/inet d.conf f il e pl ay?
The f il e /et c/inet d.conf indicat es t he pr ocesses st ar t ed by t he inet d daemon when a
syst em boot s.
Expl ain user equival ence.
User equival ence l et s a user access anot her machine wit hout r equir ing a passwor d
dur ing t he l ogin pr ocess. It is cont r ol l ed by a set of f il es cont r ol l ed by t he syst em or
individual user s.
Quiz
1. How many devices ar e enabl ed on a Cl ass B net wor k (t he most common)?
2. What is t he dif f er ence bet ween t he BSD UNIX TCP/IP br oadcast addr ess set t ing
and t he one nor mal l y used?
3. What is a pseudo t t y?
4. What does t he f ol l owing .r host s f il e do?
# .r host s
ar t emis t par ker
ar t emis goof
ar t emis aar menakis
mig r macl ean
5. What is anonymous FTP and why woul d you use it ?


I DOS-Based TCP/IP: f t p Sof t war e's PC/TCP
I Inst al l ing PC/TCP
I The AUTOEXEC.BAT Fil e
I The CONFIG.SYS Fil e
I The PROTOCOL.INI Fil e
I The PCTCP.INI Fil e
I The Windows SYSTEM.INI Fil e
I Windows f or Wor kgr oups using Net BIOS
I Test ing PC/TCP
I Windows-Based TCP/IP: Net Manage's Chamel eon
I Inst al l ing Chamel eon
I The AUTOEXEC.BAT Fil e
I The CONFIG.SYS Fil e
I The SYSTEM.INI Fil e
I The PROTOCOL.INI Fil e
I Conf igur ing Chamel eon
I Test ing Chamel eon
I Conf igur ing Windows 95 f or TCP/IP
I Inst al l ing TCP/IP
I Fur t her TCP/IP Conf igur at ion
I Test ing TCP/IP
I Winsock
I Tr umpet Winsock
I Inst al l ing Tr umpet Winsock
I Conf igur ing t he TCP/IP Packet Dr iver
I Summar y
10
Setting Up a Sample TCP/IP Network: DOS
and Windows Clients
Yest er day, you conf igur ed t he ser ver s on t he sampl e net wor k. Al l t hr ee UNIX ser ver s
f ol l owed t he same pr ocedur e and had simil ar conf igur at ion f il es. The Windows NT
ser ver was conf igur ed using t he buil t -in TCP/IP st ack. Today you conf igur e some cl ient s
f or t he net wor k. The cl ient s communicat e wit h t he ser ver t hr ough a TCP/IP st ack
l oaded on each machine. You conf igur e t hr ee cl ient s: one DOS, one Windows 3.x, and one
Windows 95. Any of t he oper at ing syst ems you conf igur ed yest er day as ser ver s can al so
act as cl ient s on t he sampl e net wor k.
Windows 95 incl udes TCP/IP cl ient sof t war e as par t of t he dist r ibut ion sof t war e
package, but it is not conf igur ed when Windows 95 is inst al l ed. This is because Windows
95 inst al l s Net War e's IPX/SPX net wor k pr ot ocol s as t he def aul t . Today you see how t o
change t he def aul t pr ot ocol t o TCP/IP. For t he DOS and Windows 3.x machines, sever al
pr oduct s ar e avail abl e t o of f er TCP/IP pr ot ocol s. I have sel ect ed t wo of t he most
popul ar packages t o conf igur e on t hese syst ems. The DOS machine is conf igur ed using f t p
Sof t war e's PC/TCP sof t war e pr oduct . The Windows 3.x machine, r unning Micr osof t
Windows f or Wor kgr oups 3.11, is conf igur ed wit h Net Manage's Chamel eonNFS.
Conf igur ing DOS and Windows machines is dif f er ent t han conf igur ing UNIX syst ems
because of t he changes in f il esyst ems, oper at ing syst em ar chit ect ur e, and t he individual
sof t war e vendor 's appr oaches. However , t he same basic inf or mat ion is r equir ed, and t he
st eps t o add DOS machines ar e anal ogous t o t hose f or a UNIX syst em.
Al t hough t oday I use t wo specif ic commer cial packages f or t he DOS and Windows 3.11
machines, t he pr ocess is simil ar t o ot her vendor s' TCP/IP pr oduct s. The names of f il es and
t he exact conf igur at ion inf or mat ion might dif f er , but t he same gener al pr incipl es appl y.
DOS-Based TCP/IP: ftp Software's PC/TCP
PC/TCP f r om f t p Sof t war e has been avail abl e f or sever al year s and has become a de
f act o st andar d f or DOS machines t hat want t o connect wit h a TCP/IP net wor k. PC/TCP
r uns under bot h DOS and Windows. It l et s a user per f or m al l t he TCP/IP f unct ions, such
as f t p and t el net , and incl udes sof t war e f or sever al member s of t he TCP f amil y of
pr ot ocol s, incl uding SNMP. Ot her machines can al so access a PC r unning PC/TCP,
copying it s f il es (assuming access has been gr ant ed). Bear in mind t hat we ar e
conf igur ing t his machine as a DOS pl at f or m onl y, even t hough PC/TCP of f er s some
Windows icons. The machine might be an ol der device t hat doesn't suppor t Windows, f or
exampl e, or t he user might not want t o inst al l Windows 3.X on t his machine. Some DOS-
based appl icat ions might not wor k wit h a Windows-based TCP/IP st ackhence t he need
f or a DOS-onl y TCP/IP conf igur at ion.
PC/TCP can r un TCP/IP as t he sol e net wor k pr ot ocol on t he PC, or it can piggy-back on
t op of ot her net wor ks, such as Windows f or Wor kgr oups (Net BEUI and Net BIOS) or
Novel l Net War e (IPX/SPX). Your syst em administ r at or can decide t he best conf igur at ion
f or your machine, depending on t he nat ur e of t he net wor k. For exampl e, if a l ar ge
Windows f or Wor kgr oups net wor k al r eady exist s but a user want s access t o a TCP/IP
UNIX ser ver , it might not make sense t o conver t t he ent ir e net wor k t o TCP/IP. In t hat
case, eit her a second net wor k car d can be added specif ical l y f or t he TCP/IP net wor k or
TCP/IP can coexist wit h t he Windows f or Wor kgr oups syst em. (Remember t hat TCP/IP isn't
par t icul ar about t he net wor k t r anspor t t ype.)
The sampl e net wor k you ar e conf igur ing is TCP/IP-based, so PC/TCP is inst al l ed t o r un on
t hat net wor k pr ot ocol onl y. However , because it woul d be usef ul t o be abl e t o r un
Windows f or Wor kgr oups over t he net wor k bet ween t he DOS and Windows 3.11
machines, t he inst al l at ion pr ocess you t ake is designed so t hat bot h Net BEUI and TCP/IP
can r eside simul t aneousl y on t he net wor k.
One appr oach is t o set t he PC/TCP syst em t o enabl e Windows f or Wor kgr oups and TCP/IP
packet s on t he same net wor k. Wit h t his appr oach, TCP/IP sends out IP packet s, and
Windows f or Wor kgr oups sends out Net BEUI packet s (t he def aul t t ype). Bot h pr ot ocol s
use NDIS (Net wor k Device Int er f ace Specif icat ion) device dr iver s t o communicat e wit h
t he net wor k car d. The pr obl em wit h t his appr oach is t hat ot her machines r eceiving t he
packet s might get conf used because of t wo dif f er ent packet t ypes, and t he syst em does
not wor k wel l if an ext er nal net wor k is t o be accessed (such as t he Int er net ), because
r out er s do not handl e Net BEUI packet s.
The al t er nat ive appr oach is t o conf igur e Windows f or Wor kgr oups t o encapsul at e it s
message wit hin IP packet s, which can t hen be sent acr oss t he int er net wor k and t he l ocal
net wor k bet ween TCP/IP machines wit h no pr obl ems. This appr oach has a coupl e of
usef ul advant ages. The net wor k is compl et el y IP-based, so r out er s can handl e t he
t r af f ic t hr ough int er net wor ks. Al so, a Windows f or Wor kgr oups comput er on anot her
net wor k can communicat e t hr ough t he r out er , hence making t he Windows f or
Wor kgr oups ser vices mor e widel y avail abl e. A r eceiving Windows f or Wor kgr oups
machine has t o ext r act t he inf or mat ion f r om t he IP packet , but ot her wise t he syst em
wor ks wel l .
The sampl e net wor k you ar e inst al l ing is conf igur ed t o enabl e bot h PC/TCP and
Windows f or Wor kgr oups t o coexist using NDIS dr iver s. This r esul t s in t wo sof t war e
st acksone f or PC/TCP and one f or Windows f or Wor kgr oupscoexist ing and
communicat ing wit h t he NDIS dr iver . This st r uct ur e is shown in Figur e 10.1. This is
pr obabl y not t he best choice f or t he sampl e net wor k, because al l t he ot her machines on
t he net wor k pr ef er TCP/IP packet f or mat s, but t his appr oach shows how PC/TCP can be
conf igur ed f or dual pr ot ocol s on ot her net wor ks.
Figur e 10.1. PC/TCP and Windows f or Wor kgr oups st acks using NDIS.
PC/TCP uses a ker nel t hat is l oaded int o memor y when DOS boot s. The ker nel is a
Ter minat e and St ay Resident (TSR) pr ogr am. To ensur e t hat t he net wor k is avail abl e at
al l t imes, t he ker nel l oad command is usual l y added t o t he AUTOEXEC.BAT f il e. The
sampl e net wor k uses a ker nel cal l ed ETHDRV.EXE, which is t he Et her net dr iver
suppl ied wit h PC/TCP. (A dif f er ent ker nel must be used if t he net wor k is IEEE 802.3
Et her net , which dif f er s f r om t he nor mal DIX Et her net .) In addit ion, an NDIS Conver t er
must be l oaded in t he AUTOEXEC.BAT f il e as a device dr iver t o pr ovide NDIS-f or mat
packet s t o t he pr ot ocol manager .
Installing PC/TCP
PC/TCP incl udes an aut omat ed inst al l at ion pr ocedur e t hat copies t he dist r ibut ion media
t o t he har d disk and set s up some of t he conf igur at ion f il es. Today, most of t he syst em is
conf igur ed manual l y t o show t he necessar y st eps, and t o enabl e you t o ver if y t he
changes made t o syst em f il es by t he inst al l at ion pr ogr am. In pr act ice, you woul d al l ow
PC/TCP t o inst al l it sel f and per f or m t he conf igur at ion aut omat ical l y, t hen check t he
f il es f or pr oper cont ent .
Inst al l at ion of PC/TCP r equir es t he same basic inf or mat ion as TCP/IP under UNIX: t he
device dr iver , t he syst em's name and IP addr ess, and t he names and IP addr esses of ot her
syst ems t o be accessed. The pr ocess begins wit h a pr oper l y inst al l ed net wor k car d. The
IRQ and memor y addr ess of t he car d must be known, and a device dr iver f or it must be
pr esent f or incl usion in t he CONFIG.SYS f il e. Device dr iver s ar e usual l y suppl ied by t he
net wor k car d vendor , but gener ic dr iver s ar e al so incl uded wit h t he PC/TCP sof t war e
disks. They incl ude dr iver s f or t he most popul ar t ypes of net wor k syst ems but might not
incl ude al l possibl e car ds.
Af t er copying al l t he dist r ibut ion f il es t o t he har d dr ive, t he conf igur at ion can begin.
The sampl e machine is r unning DOS 6.22 and Windows f or Wor kgr oups 3.11, al t hough you
ar e conf igur ing t he DOS oper at ing syst em in par t icul ar in t his sect ion. Changes in t he
DOS sof t war e r el ease number might af f ect t he f ol l owing det ail s, but t he PC/TCP
inst al l at ion inst r uct ions ar e updat ed f or new r el eases. When inst al l ing PC/TCP wit h
Windows f or Wor kgr oups, t he Windows net wor k must be inst al l ed, conf igur ed, and
r unning pr oper l y bef or e PC/TCP modif ies t he Windows f il es t o enabl e bot h DOS and
Windows t o wor k over t he net wor k.
Dur ing t he inst al l at ion pr ocess, PC/TCP r equir es a l engt hy ser ial number and
aut hent icat ion key. These ver if y t he sof t war e and pr event a net wor k f r om using many
copies of t he same sof t war e when onl y one l icense has been pur chased.
Four f il es ar e invol ved in t he init ial conf igur at ion:
G AUTOEXEC.BAT: St ar t s t he PC/TCP ker nel
G CONFIG.SYS: St ar t s t he device dr iver s f or t he net wor k and PC/TCP
G PROTOCOL.INI: Def ines t he t ype of net wor k and dr iver s
G PCTCP.INI: Ker nel par amet er s f or PC/TCP
In yest er day's mat er ial , UNIX ker nel par amet er conf igur at ion was ment ioned in passing
as a way t o f ine-t une t he behavior of t he oper at ing syst em wit h TCP/IP. In some cases,
t his is necessar y wit h t he DOS PC/TCP syst em, as wel l . A ut il it y pr ogr am cal l ed
KAPPCONF enabl es t he ker nel par amet er s t o be al t er ed. The set t ings f or t he ker nel ar e
saved in a conf igur at ion f il e cal l ed PCTCP.INI.
The AUTOEXEC.BAT File
The AUTOEXEC.BAT f il e r equir es envir onment var iabl es t o be pr oper l y set f or PC/TCP
and t wo inst r uct ions added t o t he f il e. One inst r uct ion st ar t s t he net wor k and t he
ot her l oads t he Et her net dr iver . The sampl e machine al r eady had Windows f or
Wor kgr oups inst al l ed, so a l ine in t he AUTOEXEC.BAT f il e r eads
C:\WINDOWS\NET START
This l ine st ar t s t he net wor k. The NET START command can r emain in pl ace or be
r epl aced wit h a PC/TCP command cal l ed NETBIND, which accompl ishes t he same t hing
f or NDIS dr iver s. If bot h commands ar e in t he AUTOEXEC.BAT f il e, an er r or message
r esul t s when t he second net wor k st ar t up command is execut ed. (The dr ive assignment s
f or al l t he exampl es t oday might be dif f er ent on ot her syst ems, as might t he
inst al l at ion dir ect or ies. Inst al l at ion def aul t s wer e used t hr oughout t his chapt er f or
bot h PC/TCP and Windows f or Wor kgr oups. Change t heir val ues as needed t o mat ch
your syst em.)
Af t er t he NET START or NETBIND command, t he f ol l owing l ine must be added t o t he
AUTOEXEC.BAT f il e:
C:\PCTCP\ETHDRV
This st ar t s t he PC/TCP Et her net dr iver . If anot her net wor k syst em is being used, t his
woul d be r epl aced wit h t he device dr iver f or t hat net wor k (such as IEEEDRV f or IEEE
802.3 Et her net or SLPDRV f or SLIP).
It is usef ul t o def ine t wo envir onment var iabl es in t he AUTOEXEC.BAT f il e f or t he
PC/TCP sof t war e t o use when sear ching f or f il e. One is a simpl e addit ion t o t he PATH
command, adding t he PCTCP inst al l at ion dir ect or y t o t he sear ch pat h. The second is an
envir onment var iabl e t hat point s t o t he PCTCP.INI f il e. The t wo decl ar at ions l ook l ike
t his:
SET PCTCP=C:\PCTCP\PCTCP.INI
SET PATH=C:\PCTCP;%PATH%
The l at t er change t o t he PATH command adds C:\PCTCP t o an al r eady def ined PATH. An
al t er nat ive woul d be t o edit t he PATH command t o incl ude t he dir ect or y on t he same
l ine as t he r est of t he decl ar at ion. The PC/TCP sof t war e can be r un wit hout t hese
envir onment var iabl es def ined, but pr obl ems wit h f il e l ocat ions can r esul t if commands
ar e not execut ed f r om t he inst al l at ion dir ect or y.
Ther ef or e, on t he DOS machine, t he compl et ed AUTOEXEC.BAT f il e shoul d have one of
t he f ol l owing f our -l ine combinat ions in it :
SET PCTCP=C:\PCTCP\PCTCP.INI
SET PATH=C:\PCTCP;%PATH%
C:\WINDOWS\NET START
C:\PCTCP\ETHDRV
or
SET PCTCP=C:\PCTCP\PCTCP.INI
SET PATH=C:\PCTCP;%PATH%
C:\PCTCP\NETBIND
C:\PCTCP\ETHDRV
When t hese l ines ar e execut ed dur ing t he syst em boot pr ocess, t he syst em displ ays st at us
messages when each command is compl et ed. The NETBIND command displ ays t his message
if it l oads successf ul l y:
MS-DOS LAN Manager v2.1 Netbind
Microsoft Netbind version 2.1
A t hir d l ine might displ ay a st at us message about t he int er r upt vect or used by t he
syst em. If NETBIND coul dn't l oad cor r ect l y, it gener at es a message l ike t his:
MS-DOS LAN Manager v2.1 Netbind
Error: Making PROTMAN IOCTL call.
This usual l y is gener at ed when t he net wor k is al r eady r unning (such as f r om issuing a
NET START command bef or e t he NETBIND command; you might r ecal l t hat onl y one of
t hese t wo shoul d be in t he AUTOEXEC.BAT f il e).
The ETHDRV command displ ays a message wit h st at us inf or mat ion when it l oads
successf ul l y. It l ooks l ike t his:
MAC/DIS converterFTP Software PC/TCP Resident Module 2.31
01/07/94 12:38
Copyright 1986-1993 by FTP Software, Inc. All rights
reserved.
Patch level 17637
Patch time: Fri Jan 07 14:25:09 1994
Kernel interrupt vector is 0x61
Code Segment occupies 49.0K of conventional memory
Data Segment occupies 19.5K of conventional memory
Packet Driver found at vector 0x60
name:
version: 30, class: 1, type: 57, functionality: 6
ifcust (PC/TCP Class 1 packet driver - DIX Ethernet)
initialized
5 free packets of length 1514, 5 free packets of length 160
The Resident Module occupies 68.7K of conventional memory
If t her e is an er r or when t he ETHDRV pr ogr am l oads, it gener at es an er r or message (of
var ying ut il it y f or debugging pur poses). A sampl e er r or is shown her e:
FTP Software PC/TCP Resident Module 2.31 01/07/94 12:38
Copyright 1986-1993 by FTP Software, Inc. All rights
reserved.
Patch level 17637
Patch time: Fri Jan 07 14:25:09 1994
PC/TCP is already loaded (interrupt 0x61). Use 'inet unload'
to unload it.
This er r or occur r ed because a PC/TCP dr iver had been l oaded pr ior t o t he ETHDRV
command.
Some DOS user s l ike t o l eave t hese commands out of t he AUTOEXEC.BAT f il e and issue
t hem manual l y. This has t he advant age of r educing t he amount of memor y chewed up
when t he machine boot s and t he net wor k is not r equir ed. A usef ul compr omise is t o
cr eat e a smal l bat ch f il e t hat has t hese t wo commands and t hen r un t he bat ch f il e onl y
if t he net wor k is used. Bot h NETBIND and ETHDRV do not seem t o be cr it ical as f ar as
when t hey ar e l oaded in t he st ar t up sequence (as opposed t o some sof t war e t hat insist s
on being l oaded f ir st or l ast in t he AUTOEXEC.BAT f il e).
The CONFIG.SYS File
The CONFIG.SYS f il e has t o have dr iver s l oaded f or t he pr ot ocol manager , t he NDIS
packet conver t er , and t he net wor k car d dr iver . Syst ems r unning Windows f or
Wor kgr oups might r equir e addit ional dr iver s. The CONFIG.SYS f il e must have an ent r y
set t ing t he number of f il es open at one t ime t o at l east 20. If t his doesn't exist , PC/TCP
cr ashes. Add t his l ine:
FILES=20
t o t he CONFIG.SYS f il e. Depending on t he amount of memor y avail abl e, t he number
coul d be r eadil y incr eased. Wit h 8MB RAM or mor e, a val ue of 40 is sat isf act or y.
Number s above t his set t ing t end t o be count er -pr oduct ive because RAM is wast ed f or no
r eason.
The pr ot ocol manager is suppl ied as par t of Windows f or Wor kgr oups, and one is
incl uded wit h t he PC/TCP sof t war e package. The choice of which t o use is your s or your
syst em administ r at or 's. If Windows f or Wor kgr oups 3.1 (not 3.11) was al r eady l oaded and
f unct ional , CONFIG.SYS has a l ine simil ar t o t his:
DEVICE=C:\WINDOWS\PROTMAN.DOS /I:C:\WINDOWS
The pr ot ocol manager is not al ways used wit h t he Windows f or Wor kgr oups 3.11 r el ease
because it is incl uded wit h ot her dr iver s wit hin t he CONFIG.SYS f il e (such as
IFSHLP.SYS). If t her e is no pr ot ocol manager st ar t ed at boot t ime, one shoul d be added
f r om t he PC/TCP sof t war e. The ent r y wit hin t he CONFIG.SYS f il e is
DEVICE=C:\PCTCP\PROTMAN.DOS \I:C:\PCTCP
This l oads t he PC/TCP pr ot ocol manager . The \I at t he end of t he command t el l s t he
dr iver wher e t o l ook f or f il es (in t his case, t he PC/TCP inst al l at ion dir ect or y).
A net wor k car d dr iver shoul d appear next in CONFIG.SYS. This dif f er s f or each net wor k
car d, but f or t he sampl e net wor k DOS machine's Int el Et her Expr ess 16 net wor k car d, t he
l ine is
DEVICE=C:\WINDOWS\EXP16.DOS
This l oads t he EXP16 dr iver f or t he Int el net wor k car d. This was incl uded wit h t he
Windows f or Wor kgr oups sof t war e, but it is al so avail abl e as a gener ic dr iver . Some
machines wit h Windows f or Wor kgr oups al r eady inst al l ed might have t his command
al r eady in t he CONFIG.SYS f il e.
The f inal st ep is t o l oad t he PC/TCP NDIS Packet Conver t er . The cur r ent r el ease of
PC/TCP uses a packet conver t er cal l ed DIS_PKT.GUP. The l ine l ooks l ike t his:
DEVICE=C:\PCTCP\DIS_PKT.GUP
Some syst ems r unning Windows f or Wor kgr oups 3.1 (and a f ew t hat have upgr aded t o
3.11) have t he l ine
DEVICE=C:\WINDOWS\WORKGRP.SYS
in t he CONFIG.SYS f il e. This is f or Windows f or Wor kgr oups' use and is not necessar y if
PC/TCP is t o be used as a DOS-based syst em onl y. If t he f il e was not inst al l ed by
Windows f or Wor kgr oups and t he syst em wor ks pr oper l y wit hout it , t her e is no need t o
add it .
When t he syst em boot s, t he device dr iver s ar e l oaded in t ur n. Each displ ays a shor t
message showing it s ver sion number . Any er r or s t hat occur ar e al so displ ayed. Usual l y
t he device dr iver s don't cause any pr obl ems.
The pr oper l y conf igur ed CONFIG.SYS f il e f or t he DOS machine shoul d have t hese l ines
in it
DEVICE=C:\WINDOWS\PROTMAN.DOS /I:\C:\WINDOWS
DEVICE=C:\WINDOWS\EXP16.DOS
DEVICE=C:\PCTCP\DIS_PKT.GUP
if it is using t he Windows f or Wor kgr oups pr ot ocol manager . It shoul d have t he
f ol l owing l ines if it is using t he PC/TCP pr ot ocol manager :
DEVICE=C:\PCTCP\PROTMAN.DOS /I:\C:\PCTCP
DEVICE=C:\WINDOWS\EXP16.DOS
DEVICE=C:\PCTCP\DIS_PKT.GUP
As not ed ear l ier , t he net wor k int er f ace dr iver (EXP16) is dif f er ent if your machine does
not use t he Int el Et her Expr ess 16 boar d.
The posit ion of t hese l ines wit hin t he CONFIG.SYS f il e isn't cr it ical , al t hough t her e
might be pr obl ems if t hey ar e l oaded int o high memor y wit h ot her dr iver s.
Exper iment at ion is t he onl y way t o f ind t he most memor y-ef f icient sequence.
The PROTOCOL.INI File
Windows f or Wor kgr oups has a PROTOCOL.INI f il e as par t of it s set up. The f il e t el l s t he
syst em about t he net wor k car ds and dr iver s in use. The PC/TCP PROTOCOL.INI f il e does
t he same, but it r esides in t he PCTCP dir ect or y.
The cont ent s of t he PROTOCOL.INI f il e ar e dif f er ent f or each net wor k car d and dr iver
conf igur at ion. Ther e must be a sect ion l abel ed [PKTDRV] (al l in upper case) t hat def ines
t he dr iver name, t he binding t o t he net wor k car d, and any conf igur at ion inf or mat ion
needed. The sampl e net wor k's PROTOCOL.INI f il e l ooks l ike t his:
[PKTDRV]
drivername=PKTDRV$
bindings=MS$EE16
intvec=0x60
[MS$EE16]
DriverName=EXP16$
IOADDRESS=0x360
IRQ=11
IOCHRDY=Late
TRANSCEIVER=Thin Net (BNC/COAX)
This PROTOCOL.INI f il e def ines t he packet dr iver as PKTDRV$, t he def aul t dr iver wit h
PC/TCP. The binding t o t he Int el Et her Expr ess 16 car d used on t he DOS machine r ef er s
t o anot her sect ion in t he f il e t hat l ist s t he addr ess, IRQ, and some specif ics of t he
Et her Expr ess car d. These l ines coul d have been incl uded in t he [PKTDRV] sect ion but
wer e separ at ed f or compat ibil it y wit h t he Windows f or Wor kgr oups PROTOCOL.INI f il e,
which is simil ar in l ayout . The Et her Expr ess 16 car d is set t o use IRQ 11, memor y addr ess
360, and use t he Thin Et her net cabl e connect or . The int vec l ine in t he [PKTDRV]
sect ion does not def ine t he IRQ f or t he net wor k car d; inst ead, it is an int er r upt f or t he
dr iver .
A PROTOCOL.INI f il e f or a syst em using a simpl er net wor k car d t han t he Et her Expr ess
can be shor t er . A sampl e PROTOCOL.INI f il e f or such a car d might l ook l ike t his:
[PKTDRV]
drivername=PKTDRV$
binding=MS$ELNKII
intvec=0x65
chainvec=0x67
Finding t he pr oper set t ings f or t he var iabl es in t he PROTOCOL.INI f il e can be a
har r owing exper ience. If Windows f or Wor kgr oups is inst al l ed and r unning, t he
Windows PROTOCOL.INI f il e is a good sour ce of inf or mat ion and can somet imes be copied
wit hout modif icat ion. Ot her wise, t he net wor k car d document at ion can somet imes hel p.
The PCTCP.INI File
The PCTCP.INI f il e hol ds t he ker nel conf igur at ion inf or mat ion f or PCTCP. In most cases,
it can be l ef t as suppl ied wit h t he sof t war e. Tweaking t he ker nel par amet er s shoul d be
per f or med onl y af t er t he net wor k is inst al l ed and has been oper at ing pr oper l y f or a
whil e. The PCTCP.INI f il e is quit e l engt hy, and car e shoul d be t aken t o avoid accident al
changes, which can r ender t he syst em inoper at ive.
If t he suppl ied inst al l at ion scr ipt is not used t o inst al l PC/TCP, a minimum PCTCP.INI f il e
must be cr eat ed manual l y. Exampl es ar e incl uded wit h t he dist r ibut ion media, usual l y
under t he name TEMPLATE.INI. Ther e ar e t wo ways t o cr eat e t he PCTCP.INI f il e and
conf igur e it pr oper l y. The f ir st is t o use an edit or and modif y t he t empl at e f il e. The
al t er nat ive is t o r un t he ker nel conf igur at ion ut il it y KAPPCONF.
A minimum PCTCP.INI f il e needs t o have t he sof t war e ser ial number and act ivat ion key,
t he IP addr ess, br oadcast addr ess, r out er addr ess, a subnet mask, and inf or mat ion about
t he syst em in gener al . The minimum PCTCP.INI f il e woul d l ook l ike t his:
[pctcp general]
domain = tpci.com
host-name = sinbad
time-zone = EST
time-zone-offset = 600
user = tparker
[pctcp kernel]
serial-number = 1234-5678-9012
authentication-key = 1234-5678-9012
interface = ifcust 0
low-window = 0
window = 2048
[pctcp ifcust 0]
broadcast-address = 255.255.255.255
ip-address = 147.120.0.11
router = 147.120.0.1
subnet-mask = 255.255.0.0
[pctcp addresses]
domain-name-server = 147.120.0.1
mail-relay = 147.120.0.1
This conf igur at ion assumes t hat t he SCO UNIX ser ver (147.120.0.1) is t he pr imar y ser ver
f or t he net wor k. The DOS machine's name (sinbad) and IP addr ess (147.120.0.11) ar e shown
in t he PCTCP.INI f il e. As dif f er ent f eat ur es of PC/TCP ar e enabl ed (such as SNMP and
Ker ber os), new sect ions ar e added t o t he PCTCP.INI f il e.
The Windows SYSTEM.INI File
If Windows f or Wor kgr oups is t o be used on t he DOS machine and you ar e going t o use
t he PC/TCP dr iver s inst ead of a dedicat ed Windows f or Wor kgr oups TCP/IP package, t he
Windows f or Wor kgr oups SYSTEM.INI f il e r equir es modif icat ion. The Windows f or
Wor kgr oups SYSTEM.INI f il e must be set t o use t he Windows f or Wor kgr oups dr iver
inst ead of t he PC/TCP dr iver .
When t he PC/TCP aut omat ic inst al l at ion pr ocess det ect s a copy of Windows, it makes
changes t o t he SYSTEM.INI f il e f or you. Some of t hese changes must be checked and
modif ied t o enabl e Windows t o boot pr oper l y wit h t he PC/TCP dr iver s. One of t he most
impor t ant changes is t he comment ing out of t he Windows f or Wor kgr oups net wor k
dr iver and it s r epl acement wit h t he PC/TCP dr iver :
network.drv=C:\PCTCP\PCTCPNET.DRV
For Windows f or Wor kgr oups 3.1, conf ir m t hat t he SYSTEM.INI f il e has t hese t hr ee
sect ions, wit h t hese commands shown:
[boot]
network.drv=wfwnet.drv
[boot.description]
network.drv=Microsoft Windows for Workgroups (version 3.1)
[386Enh]
device=c:\pctcp\vpctcp.386
device=c:\pctcp\wfwftp.386
Windows f or Wor kgr oups 3.11 has a sl ight l y dif f er ent SYSTEM.INI. It shoul d l ook l ike
t his:
[boot]
network.drv=wfwnet.drv
[boot.description]
network.drv=Microsoft Windows Network (version 3.11)
[386Enh]
device=c:\pctcp\vpctcp.386
At t he bot t om of t he Windows f or Wor kgr oups SYSTEM.INI f il e, PC/TCP somet imes adds a
bl ock of inf or mat ion t hat l ooks l ike t his:
[vpctcp]
; These option settings may be added to SYSTEM.INI, in a
; new section "[vpctcp]".
; The next line tells VPCTCP how much copy space memory to
request.
; It is in units of kilobytes (x1024). This value is only
a bid,
; as Windows may choose to reduce your allocation
arbitrarily.
; This value should be increased if using Windows
applications which
; call the PC/TCP DLL from another DLL; suggested value in
such
; instances is at least 28.
MinimumCopySpace=12
; The next line tells VPCTCP the segment (paragraph) number
of the
; beginning of memory reserved for devices, BIOS, and
upper-
; memory blocks (which could contain TSRs). All calls
below the
; PSP of Windows or above this parameter are not processed
by
; the VxD but rather are passed-thru to the kernel
untouched.
HiTSRFenceSegment=A000h
; eof
For most inst al l at ions, t his bl ock can be l ef t as it is. The comment l ines (t hose beginning
wit h a semicol on) ar e ignor ed by Windows, wher eas t he t wo var iabl es est abl ished in
t hese sect ions ar e used by PC/TCP. Ther e is no need t o del et e t his inf or mat ion. However ,
as t he f ir st not e indicat es, user s of PC/TCP might have t o incr ease t he val ues t o account
f or heavy usage.
If t he t ar get syst em is r unning Windows 3.1 (not Windows f or Wor kgr oups) t her e ar e
mor e changes t o be made, because t he SYSTEM.INI f il e and net wor k-dependent
init ial izat ion f il es do not have t he pr oper f or mat yet . To conf igur e a Windows syst em,
changes must be made t o t he PROGMAN.INI and SYSTEM.INI f il es.
Windows 3.1's PROGMAN.INI f il e cont r ol s t he st ar t up of t he Windows Pr ogr am
Manager . Nor mal l y, t his is modif ied by t he PC/TCP inst al l at ion scr ipt , but if a manual
inst al l at ion has been per f or med, changes must be made wit h a t ext edit or . The
PROGMAN.INI f il e must have t he f ol l owing l ines added:
[Groups]
GROUP16 = C:\PCTCP\PCTCPDOS.GRP
GROUP17 = C:\PCTCP\PCTCPWIN.GRP
The number s next t o GROUP shoul d be higher t han any exist ing number , usual l y l ist ed
sequent ial l y f or convenience. In t his exampl e, t he l ist of gr oups r an t o number 15.
Changes t o t he Windows 3.1 SYSTEM.INI f il e must be made in a f ew sect ions. In t he
[386Enh] sect ion, add a l ine f or t he PC/TCP device dr iver :
device=c:\pctcp\vpctcp.386
A [vpct cp] sect ion must be added wit h t he f ol l owing ent r ies:
[vpctcp]
MinimumCopySpace=12
HiTSRFenceSegment=A000h
See t he discussion of Windows f or Wor kgr oups SYSTEM.INI f il e f or mor e inf or mat ion on
t hese var iabl es.
Some addit ional ent r ies might be necessar y if t he net wor k dr iver is l ocat ed in high
memor y, if t her e is a conf l ict wit h t he def aul t ser ial por t IRQs, or if a Token Ring
net wor k is used. See t he PC/TCP inst al l at ion manual f or compl et e change inf or mat ion
in t hese cases.
Windows for Workgroups using NetBIOS
As ment ioned ear l ier , Windows f or Wor kgr oups can be set t o use IP packet s. This r equir es
a Net BIOS dr iver f or bot h Windows f or Wor kgr oups and PC/TCP. The ar chit ect ur e of
such as syst em is shown in Figur e 10.2. The Windows f or Wor kgr oups packet s ar e sent
t hr ough PC/TCP's Net BIOS and t hen int o t he nor mal PC/TCP st ack.
Figur e 10.2. Windows f or Wor kgr oups wit h Net BIOS.
To inst al l Windows f or Wor kgr oups in t his manner , Windows must f ir st be set up t o use
t he Micr osof t LAN Manager opt ion. This is usual l y a mat t er of sel ect ing t he LAN
Manager opt ion f r om t he Net wor k window if it is not al r eady t he def aul t set t ing.
(Consul t t he Windows f or Wor kgr oups document at ion f or mor e inf or mat ion.)
The conf igur at ion f il es must al so be changed t o r ef l ect t he new ar chit ect ur e. The
AUTOEXEC.BAT f il e has t he net wor k init iat ion command, t he net wor k ker nel dr iver ,
and a NETBIOS command:
C:\WINDOWS\NET START
C:\PCTCP\ETHDRV
C:\PCTCP\NETBIOS.COM
A NETBIND can be per f or med inst ead of a NET START command, al t hough t he l at t er is
pr ef er abl e. The NETBIOS command must come af t er t he NETBIND or NET START
command.
The CONFIG.SYS f il e is simil ar t o t hat seen ear l ier , wit h t he same dr iver s. A sampl e
CONFIG.SYS f il e f or t his t ype of ar chit ect ur e l ooks l ike t his:
DEVICE=C:\WINDOWS\PROTMAN.DOS /I:\C:\WINDOWS
DEVICE=C:\WINDOWS\EXP16.DOS
DEVICE=C:\PCTCP\DIS_PKT.GUP
This st ar t s t he pr ot ocol manager , t he car d dr iver , and t he NDIS packet conver t er . This
exampl e uses t he Int el Et her Expr ess 16 car d dr iver .
The PROTOCOL.INI f il e is t he same as t he pr evious exampl e. A sampl e PROTOCOL.INI f il e
f or t he Int el Et her Expr ess 16 car d l ooks l ike t his:
[PKTDRV]
drivername=PKTDRV$
bindings=MS$EE16
intvec=0x60
[MS$EE16]
DriverName=EXP16$
IOADDRESS=0x360
IRQ=11
IOCHRDY=Late
TRANSCEIVER=Thin Net (BNC/COAX)
Final l y, t he SYSTEM.INI f il e r equir es t hat t he Windows f or Wor kgr oups net wor k dr iver
be used and not t he PC/TCP net wor k dr iver . This might r equir e edit ing t he SYSTEM.INI
f il e, as not ed ear l ier . The SYSTEM.INI f il e shoul d cont ain t he f ol l owing l ines:
[boot]
network.drv=wfwnet.drv
[boot.description]
network.drv=Microsoft Windows for Workgroups (version 3.1)
[386Enh]
device=c:\pctcp\vpctcp.386
device=c:\pctcp\wfwftp.386
TimerCriticialSection=50000
The l ast l ine in t he [386Enh] sect ion might have t o be added manual l y. The ver sion
number in t he [boot .descr ipt ion] sect ion changes t o (ver sion 3.11) wit h t he l at er ver sion
of Windows f or Wor kgr oups.
Testing PC/TCP
Af t er making al l t he changes pr eviousl y ment ioned, t he DOS machine is r eboot ed f or
t est ing. If no er r or messages ar e displ ayed when t he new commands ar e execut ed, t he
syst em is r eady f or t est ing t he TCP/IP pr ot ocol st ack. The simpl est t est is t o use ping t o
ensur e t hat t he TCP/IP sof t war e is t al king t o t he l ocal machine, t hen use it t o t est t he
r emot e machines.
Machine name inf or mat ion f or ot her machines hasn't yet been added t o t he PC/TCP DOS
syst em, so IP addr esses must be used wit h ping. The f ol l owing is an exampl e of a ping
command f or t he l ocal machine (147.120.0.11), t he SCO UNIX ser ver (147.120.0.1), and t he
Windows 95 machine (147.120.0.10) on t he sampl e net wor k (which has not yet been
inst al l ed and hence shoul d not communicat e):
C:\> ping 147.120.0.11
host responding, time = 25 ms
Debugging information for interface ifcust Addr(6): 00 aa
00 20 18 bf
interrupts: 0 (2 receive, 0 transmit)
packets received: 2, transmitted: 3
receive errors: 0, unknown types: 0
runts: 0, aligns: 0, CRC: 0, parity: 0, overflow: 0
too big: 0, out of buffers: 0, rcv timeout: 0, rcv
reset: 0
transmit errors: 0
collisions: 0, underflows: 0, timeouts: 0, resets: 0
lost crs: 0, heartbeat failed: 0
ARP statistics:
arps received: 1 (0 requests, 1 replies)
bad: opcodes: 0, hardware type: 0, protocol type: 0
arps transmitted: 2 (2 requests, 0 replies)
5 large buffers; 4 free now; minimum of 3 free
5 small buffers; 5 free now; minimum of 4 free
C:\>
C:\> ping 147.120.0.1
host responding, time = 25 ms
Debugging information for interface ifcust Addr(6): 00 aa
00 20 18 bf
interrupts: 0 (5 receive, 0 transmit)
packets received: 5, transmitted: 6
receive errors: 0, unknown types: 0
runts: 0, aligns: 0, CRC: 0, parity: 0, overflow: 0
too big: 0, out of buffers: 0, rcv timeout: 0, rcv
reset: 0
transmit errors: 0
collisions: 0, underflows: 0, timeouts: 0, resets: 0
lost crs: 0, heartbeat failed: 0
ARP statistics:
arps received: 2 (0 requests, 2 replies)
bad: opcodes: 0, hardware type: 0, protocol type: 0
arps transmitted: 3 (3 requests, 0 replies)
5 large buffers; 4 free now; minimum of 3 free
5 small buffers; 5 free now; minimum of 4 free
C:\>
C:\> ping 147.120.0.10
ping failed: Host unreachable: ARP failed
Debugging information for interface ifcust Addr(6): 00 aa
00 20 18 bf
interrupts: 0 (5 receive, 0 transmit)
packets received: 5, transmitted: 7
receive errors: 0, unknown types: 0
runts: 0, aligns: 0, CRC: 0, parity: 0, overflow: 0
too big: 0, out of buffers: 0, rcv timeout: 0, rcv
reset: 0
transmit errors: 0
collisions: 0, underflows: 0, timeouts: 0, resets: 0
lost crs: 0, heartbeat failed: 0
ARP statistics:
arps received: 2 (0 requests, 2 replies)
bad: opcodes: 0, hardware type: 0, protocol type: 0
arps transmitted: 4 (4 requests, 0 replies)
5 large buffers; 4 free now; minimum of 3 free
5 small buffers; 5 free now; minimum of 4 free
The message ping f ail ed: Host unr eachabl e f or t he l ast at t empt is expect ed. PC/TCP
pr ovides t he user wit h diagnost ic messages wit h each ping command. To suppr ess t hese
messages and simpl y get a success or f ail message, t he -z opt ion can be used:
C:\> ping -z 147.120.0.11
host responding, time = 25 ms
C:\>
C:\> ping -z 147.120.0.1
host responding, time = 25 ms
C:\>
C:\> ping -z 147.120.0.10
ping failed: Host unreachable: ARP failed
If t he ping command is not successf ul wit h t he l ocal addr ess, eit her t he net wor k
int er f ace car d is conf igur ed incor r ect l y or t he sof t war e inst al l at ion has incor r ect
par amet er s. Check t he net wor k car d f or t he cor r ect IRQ and memor y set t ings and t hen
check t he cabl e t o ensur e t hat it is connect ed pr oper l y and net wor k t er minat or s ar e in
pl ace. The sof t war e must have t he cor r ect dr iver s l oaded, as wel l as t he machine name,
IP addr ess, and simil ar inf or mat ion.
If t he l ocal machine r esponds but t he r emot e machines do not , check t he net wor k
connect ions. Tr y ping f r om one of t he r emot e machines t o ensur e t hat t he DOS machine
can be r eached by t he ot her machines. Exper ience has shown t hat PC-based TCP/IP
impl ement at ions can be quir ky when boot ing. It is not unusual t o have a ping command
f ail f our or f ive t imes and t hen st ar t wor king pr oper l y. Repeat t he commands sever al
t imes, wait ing a f ew seconds bet ween each at t empt .
Once t he machines can successf ul l y r espond t o a ping r equest , t r y f t p or t el net f r om t he
DOS-based machine. An f t p at t empt t o l og ont o t he SCO UNIX machine is shown her e:
FTP Software PC/TCP File Transfer Program 2.31 01/07/94
12:38
Copyright 1986-1993 by FTP Software, Inc. All rights
reserved.
FTP Trying....Open
220 tpci.tpci.com FTP Server (Version 5.60 #1) ready.
Userid for logging in on 147.120.0.1? tparker
331 Password required for tparker.
Password for logging in as tparker on 147.120.0.1? abcdefg
230 User tparker logged in.
ftp:147.120.0.1> ls
.profile
.lastlogin
.odtpref
trash
Initial.dt
XDesktop3
Transferred 265 bytes in 0 seconds
226 Transfer complete.
ftp:147.120.0.1> exit
This session, which displ ayed t he l ist ing of f il es on t he SCO UNIX ser ver , shows t hat t he
f t p command wor ked pr oper l y. The FTP session was cl osed wit h t he command exit .
Fol l owing t he DOS-based t est , st ar t Windows (if it was inst al l ed) and ensur e t hat t he
appl icat ions wit hin t he PC/TCP Appl icat ions pr ogr am gr oup ar e avail abl e and wor king.
If pr obl ems ar e encount er ed wit h Windows st ar t ing, it is l ikel y t hat an er r or was made
in t he SYSTEM.INI f il e. Check t he pr evious inst r uct ions f or t he cor r ect conf igur at ion.
Af t er al l t hat , t he f t p Sof t war e PC/TCP syst em is inst al l ed and conf igur ed pr oper l y.
The DOS machine can now be used f or TCP/IP appl icat ions such as f t p and t el net . If some
of t he mor e power f ul pr ot ocol f eat ur es wer e inst al l ed, t hey ar e al so usabl e. The DOS-
based machine inst al l at ion is now compl et ed. The PC/TCP document at ion cont ains
inst r uct ions f or using t he syst em, as wel l as f ine-t uning t he ker nel . It al so hel ps user s
cr eat e gat eways, r out er s, mail ser ver s, and sever al ot her TCP/IP-r el at ed f eat ur es.
Windows-Based TCP/IP: NetManage's Chameleon
Net Manage pr oduces a l ine of TCP/IP-based sof t war e specif ical l y f or Windows, Windows
95, and Windows f or Wor kgr oups. These appl icat ions ar e designed t o pr ovide f ul l access
t o TCP/IP ut il it ies t hr ough t he Windows envir onment . Net Manage's l ine of pr oduct s
incl udes a basic TCP/IP st ack (cal l ed Newt ), as wel l as f ul l TCP/IP appl icat ion packages
in sever al f or ms, al l cal l ed Chamel eon. The syst em is al so avail abl e f or Windows NT.
You ar e inst al l ing Chamel eon on a Windows f or Wor kgr oups 3.11 machine on t he sampl e
net wor k.
Chamel eon uses t he st andar d NDIS (Net wor k Device Int er f ace Specif icat ion) or t he ODI
(Open Dat a Link Int er f ace) f or communicat ing wit h t he net wor k int er f ace car d. This
enabl es any car d t hat uses eit her NDIS or ODI t o be used wit h Chamel eon.
Pr ior t o inst al l at ion of Chamel eon, t he same st eps ar e per f or med as f or t he DOS-based
TCP/IP package. The net wor k int er f ace car d must be inst al l ed wit h suit abl e IRQ and
memor y addr ess set t ings. If Chamel eon is being added t o an exist ing Windows f or
Wor kgr oups syst em, t he net wor k car d shoul d al r eady be inst al l ed and pr oper l y
conf igur ed. The same inf or mat ion is r equir ed as f or al l TCP/IP inst al l at ions: t he host
name, IP addr ess, br oadcast mask, subnet wor k mask, and any inf or mat ion about gat eways
or r out er s t hat needs t o be incl uded.
The ver sion of Chamel eonNFS used f or t he sampl e net wor k had it s inst al l at ion
inf or mat ion sl ight l y jumbl ed because of updat es t o bot h Chamel eon and Windows f or
Wor kgr oups. The inf or mat ion suppl ied t oday appl ies t o Windows f or Wor kgr oups 3.1 and
3.11 and Chamel eonNFS ver sion 4.0, al t hough ot her ver sions shoul d be simil ar .
Installing Chameleon
Chamel eon can be inst al l ed over a f ul l y f unct ioning Windows or Windows f or
Wor kgr oups syst em. If Windows f or Wor kgr oups is used, ensur e t hat t he net wor k
per f or ms pr oper l y (if possibl e) when t al king t o ot her Net BEUI-compat ibl e machines. In
t his case, t hat 's not possibl e because t he sampl e net wor k uses onl y TCP/IP.
The inst al l at ion pr ocedur e f or Chamel eon is simpl e. Fr om t he Pr ogr am Manager 's Fil e
menu, sel ect Run, t hen execut e t he SETUP.EXE pr ogr am f r om t he f ir st Chamel eon disk.
As wit h most Windows appl icat ions, t his st ar t s t he inst al l at ion pr ogr am.
The changes made t o t he syst em f il es might cause pr obl ems, af f ect ing Windows'
capabil it y t o boot . Bef or e inst al l ing t he Chamel eon sof t war e, make copies of t he
AUTOEXEC.BAT, CONFIG.SYS, PROTOCOL.INI, WIN.INI, and SYSTEM.INI f il es. If
pr obl ems ar e encount er ed, t hese f il es can r et ur n t he syst em t o it s or iginal st at e. You
shoul d consider making a f ul l syst em backup bef or e any major changes t o sof t war e, of
cour se.
The Chamel eon inst al l at ion pr ogr am r equir es a l engt hy ser ial number and an
act ivat ion key t o ensur e t hat t her e is onl y one such ver sion on a net wor k (t his l ocks
out mul t ipl e inst al l at ions using t he same ser ial number and act ivat ion key.) The
inst al l at ion scr ipt pr ompt s f or t he dist r ibut ion disks in or der and copies al l t he
necessar y f il es.
Fol l owing t he inst al l at ion pr ocess, Chamel eon buil ds t he pr ogr am gr oup wit h t he
Chamel eon appl icat ions incl uded. The Chamel eonNFS pr ogr am gr oup is shown in Figur e
10.3. Af t er cr eat ing t he pr ogr am gr oup, Chamel eon st ar t s a cust omizat ion scr een t hat
l et s you specif y your IP addr ess, host name, net wor k mask, and br oadcast addr ess. Save
t his inf or mat ion and t hen exit out of Windows t o t he DOS pr ompt t o compl et e t he check
of t he inst al l at ion.
Figur e 10.3. The Chamel eon pr ogr am gr oup.
Because of t he dif f er ent inst al l at ion var iabl es encount er ed wit h dif f er ent net wor k
dr iver s, it is advisabl e t o check t he f ol l owing conf igur at ion f il es manual l y:
AUTOEXEC.BAT
CONFIG.SYS
PROTOCOL.INI
SYSTEM.INI
The f ol l owing sect ions discuss each of t hese f il es in mor e det ail . If t he f il es do not have
t he inf or mat ion specif ied in t hem, add t hem wit h a t ext edit or . Fail ur e t o check t he f il es
pr oper l y can r esul t in Windows being unabl e t o boot pr oper l y. If t his happens, copy t he
backup f il es in pl ace of t he newl y modif ied f il es, r est ar t Windows, and r einst al l or
r econf igur e as necessar y.
The AUTOEXEC.BAT File
The changes t o t he AUTOEXEC.BAT f il e necessar y t o enabl e Chamel eon t o r un ar e t he
incl usion of t he inst al l at ion dir ect or y in t he PATH envir onment var iabl e and a
net wor k st ar t up command. If Chamel eon is inst al l ed on a Windows f or Wor kgr oups
syst em, t he net wor k st ar t up command shoul d al r eady exist .
The PATH envir onment var iabl e must be modif ied t o incl ude t he Chamel eon inst al l at ion
dir ect or y, which by def aul t is C:\NETMANAG. An exist ing PATH st at ement can be
al t er ed, or a new l ine can be added bel ow t he exist ing PATH st at ement t hat l ooks l ike
t his:
PATH=C:\NETMANAG;%PATH%
Of cour se, t he cor r ect dr ive and subdir ect or y shoul d be subst it ut ed. This chapt er
assumes def aul t val ues t hr oughout .
The command
C:\WINDOWS\NET START
is al r eady in t he AUTOEXEC.BAT f il e if a Windows f or Wor kgr oups syst em is used (eit her
ver sion 3.1 or 3.11). If Chamel eon is inst al l ed on a Windows (not Windows f or
Wor kgr oups) syst em, t he NETBIND command incl uded wit h t he dist r ibut ion sof t war e
shoul d be cal l ed as wel l :
C:\NETMANAG\NETBIND
Chamel eon might inst al l a SHARE command in t he AUTOEXEC.BAT f il e if one does not
exist . If one doesn't exist , it is advisabl e t o add it if ot her s can access t he machine.
SHARE is a DOS ut il it y t hat act ivat es f il e-shar ing and r ecor d-l ocking. If ot her
machines wil l be accessing t he machine, SHARE is necessar y t o pr event er r or messages
and pot ent ial syst em f r eezes when f il e conf l ict s occur .
The compl et ed AUTOEXEC.BAT f il e l ooks l ike t his f or a Windows f or Wor kgr oups 3.1 or
3.11 inst al l at ion:
PATH=C:\NETMANAG;%PATH%
C:\WINDOWS\NET START
SHARE
and l ike t his f or a Windows inst al l at ion:
PATH=C:\NETMANAG;%PATH%
C:\NETMANAG\NETBIND
SHARE
If t he NET START or NETBIND command is not execut ed pr oper l y, Windows displ ays an
er r or message when it l oads. In some cases, Windows can l ock up whil e it t r ies t o access
t he net wor k dr iver s.
The CONFIG.SYS File
The CONFIG.SYS f il e might be consider abl y dif f er ent f or each inst al l at ion. The HIMEM
memor y device dr iver is r equir ed, and t he SMARTDRIVE caching syst em is r ecommended.
Al l inst al l at ions shoul d have adequat e val ues f or t he FILES and BUFFERS set t ings,
which ar e nor mal l y set by Windows when it is inst al l ed. The CONFIG.SYS shoul d have
t hese val ues as a minimum:
BUFFERS=30
FILES=30
LASTDRIVE=Z
STACKS=9,256
This cr eat es enough f il e and buf f er set t ings t o enabl e mul t ipl e f il es t o be open at once.
Higher val ues ar e bet t er , al t hough t her e is a t r ade-of f of ef f iciency once t he val ues
exceed a cer t ain val ue (depending on t he amount of RAM in a syst em). The LASTDRIVE
set t ing enabl es mor e dr ives t o be open t han ar e physical l y connect ed t o t he syst em. This
is necessar y when r emot e dr ives ar e mount ed, eit her t hr ough Windows f or Wor kgr oups
or Chamel eon.
For a Windows or Windows f or Wor kgr oups 3.1 syst em, Chamel eon adds t he f ol l owing
commands t o t he CONFIG.SYS f il e:
DEVICE=C:\NETMANAG\PROTMAN.DOS /I:C:\NETMANAG
DEVICE=C:\NETMANAG\EXP16.DOS
DEVICE=C:\NETMANAG\NETMANAG.DOS
These l oad t he device dr iver s f or t he pr ot ocol manager , t he net wor k int er f ace car d,
and t he specif ic pr ot ocol f or Chamel eon. The pr ot ocol manager and net wor k int er f ace
car d device dr iver s wer e discussed in t he DOS sect ion ear l ier t oday.
Windows f or Wor kgr oups 3.11 usual l y has a command in t he CONFIG.SYS f il e t hat l ooks
l ike t his:
DEVICE=C:\WINDOWS\IFSHLP.SYS
This aut omat ical l y l oads al l t he necessar y dr iver s. In some cases, Chamel eon adds t he
command f or t he Windows f or Wor kgr oups 3.1 device dr iver s t o t he end of t he
CONFIG.SYS f il e, even if t he IFSHLP.SYS dr iver exist s. Comment out t he added device
dr iver s and t r y t he syst em wit hout t hem. The IFSHLP.SYS device dr iver shoul d be
suf f icient .
The SYSTEM.INI File
The Windows SYSTEM.INI f il e r equir es a f ew changes t o ensur e t hat Chamel eon is
l oaded pr oper l y. These shoul d be ef f ect ed by t he inst al l at ion scr ipt , but check t he l ines
car ef ul l y anyway.
The [boot ] sect ion of t he SYSTEM.INI f il e shoul d have t he f ol l owing t wo l ines:
[boot]
shell=progman.exe
network.drv=C:\NETMANAG\MULT400.DRV
The shel l l ine might be dif f er ent if t he syst em uses a r epl acement pr ogr am manager
(such as Cent r al Point PC Tool s f or Windows Deskt op Manager ). The MULT400 dr iver
suppor t s sever al net wor ks at a t ime. The or der of t hese l ines in t he SYSTEM.INI f il e is
not impor t ant , as l ong as t hey appear in t he pr oper sect ion. The MULT400 dr iver t akes
car e of l oading al l t he necessar y dr iver s f or each net wor k. Windows f or Wor kgr oups
shoul d have t his l ine
network.drv=wfwnet.drv
eit her comment ed out wit h a semicol on at t he st ar t of t he l ine or r emoved ent ir el y. The
WFWNET dr iver is t he Windows f or Wor kgr oups net wor k dr iver , which must be r epl aced
by MULT400.
The [boot .descr ipt ion] sect ion of t he SYSTEM.INI f il e is changed t o
[boot.description]
network.drv=NetManage ChameleonNFS
or a simil ar l ine if anot her Net Manage pr oduct is inst al l ed.
The [386Enh] sect ion has sever al changes made. These ar e as f ol l ows:
[386Enh]
device=C:\netmanag\nmredir.386
network=*vnetbios,*vwc,vnetsup.386,vredir.386,vserver.386
netmisc=ndis.386,ndis2sup.386
netcard=
transport=nwlink.386,nwnblink.386,netbeui.386
InDOSPolling=FALSE
The or der of t he l ines in t he sect ion doesn't mat t er . They l oad t he cor r ect net wor k
device dr iver s int o t he Windows ker nel .
Final l y, t he [net wor k dr iver s] sect ion shoul d have t hese l ines:
[network drivers]
netcard=elnk3.dos
devdir=C:\WINDOWS
LoadRMDrivers=YES
transport=ndishlp.sys,c:\netmanag\netmanag.dos,*netbeui
The net car d l ine changes depending on t he net wor k int er f ace car d used. The
LoadRMDr iver s l ine shoul d be changed f r om t he Windows f or Wor kgr oups def aul t
val ue of NO t o YES.
The PROTOCOL.INI File
The PROTOCOL.INI f il e f or a Windows f or Wor kgr oups inst al l at ion doesn't r equir e
many changes. The dr iver inf or mat ion shoul d al r eady exist . A new sect ion added by
Chamel eon shoul d l ook l ike t his:
[NETMANAGE]
DRIVERNAME=netmng$
BINDINGS=MS$ELNK3
The BINDINGS l ine changes depending on t he net wor k int er f ace car d. It is easiest t o
copy t he l ine f r om anot her sect ion of t he PROTOCOL.INI f il e.
Configuring Chameleon
Once Chamel eon has been inst al l ed and t he st ar t up f il es checked f or pr oper cont ent ,
you can conf igur e t he sof t war e f or t he sampl e machine. This is done t hr ough t he
Chamel eon CUSTOM appl icat ion. When st ar t ed, CUSTOM displ ays a st at us scr een as
shown in Figur e 10.4.
Figur e 10.4. The Chamel eon Cust om scr een.
If t he inst al l at ion r out ine didn't add t he machine's name and IP addr ess t o t he Cust om
scr een, use t he Set up menu it em t o sel ect t he dif f er ent aspect s of t he conf igur at ion
t hat must be specif ied. You shoul d pr ovide a machine name, IP addr ess, subnet mask, and
domain name, as wel l as t he int er f ace if not al r eady added (Et her net , in t his case).
To ent er t he names of t he ot her machines on t he net wor k and t heir IP addr esses, sel ect
t he Ser vices menu Host Tabl e opt ion t o displ ay t he Host Tabl e dial og box. To add t he
ot her machines on t he sampl e net wor k, ent er a name in t he t op por t ion of t he window in
t he f iel d t it l ed Of f icial Name and cl ick t he Add but t on. This shows a window f or t he IP
addr ess, which shoul d be f il l ed in compl et el y. Then cl ick OK. The IP addr ess and t he
machine name ar e now ent er ed int o t he host t abl e. This window is shown in Figur e 10.5
wit h t he addr ess f or t he machine mer l in added. If a machine has mor e t han one name, t he
dif f er ent names can be added as al iases t hr ough t his scr een, as wel l .
Figur e 10.5. Chamel eon' s Host Tabl e IP Addr ess dial og box.
Testing Chameleon
Af t er t he changes t o t he f our conf igur at ion f il es ar e compl et ed, r eboot t he syst em and
st ar t Windows. Wat ch f or er r or messages as t he Chamel eon l ines in t he CONFIG.SYS and
AUTOEXEC.BAT f il es ar e execut ed. If Windows f or Wor kgr oups was inst al l ed and
wor king pr ior t o inst al l ing Chamel eon, t her e shoul d not be any er r or s.
The easiest way t o t est t he new TCP/IP syst em is t o use t he ping ut il it y wit hin t he
Chamel eon pr ogr am gr oup. When sel ect ed, it displ ays a smal l dial og box. Sel ect t he
St ar t opt ion, which displ ays anot her dial og box wait ing f or a machine name. Ent er t he
name of t he l ocal machine. This is shown in Figur e 10.6 f or t he sampl e net wor k Windows
machine pepper .
Figur e 10.6. Using ping t o t est t he l ocal host .
The ping window shoul d show a successf ul r esul t . This is indicat ed by a message showing
t he number of byt es r eceived, as wel l as t ime inf or mat ion. A sampl e out put f r om a
successf ul at t empt t o ping t he l ocal machine is shown in Figur e 10.7.
Figur e 10.7. ping diagnost ic messages.
If t he ping at t empt is not successf ul , Chamel eon displ ays a message about t he net wor k
dr iver s not inst al l ed or about unr eachabl e host s. Upon r eceipt of such a message, check
t he net wor k car d set t ings and al l t he conf igur at ion inf or mat ion t hr ough t he CUSTOM
pr ogr am.
The next st ep is t o use ping t o send t o anot her machine on t he net wor k. Figur e 10.8
shows t he out put f r om a ping at t empt on f r eya, t he sampl e net wor k's Linux ser ver and t o
whit ney, t he Windows 95 machine t hat is not boot ed (and hence shoul d f ail ). The syst em
t imed out on t he whit ney at t empt , as you woul d expect .
Figur e 10.8. ping acr oss a net wor k.
If t he ping at t empt s acr oss t he net wor k f ail on al l machines, t he pr obl em is l ikel y wit h
t he conf igur at ion. Check al l t he conf igur at ion inf or mat ion (as pr eviousl y not ed), as
wel l as t he net wor k cabl es and car ds. Make sur e t he machines t o be pinged ar e up and
r unning TCP/IP.
If t he net wor k is oper at ing pr oper l y, t r y t he f t p and t el net appl icat ions f r om t he
Chamel eon pr ogr am gr oup. Ful l inst r uct ions f or t hese ut il it ies ar e in t he
document at ion. As l ong as a host t abl e ent r y has been cr eat ed and ping succeeded, t he
ot her ut il it ies shoul d f unct ion pr oper l y. Bot h pr ovide a gr aphical int er f ace t hat
Windows user s wil l f ind f amil iar , inst ead of t he char act er -based l ine int er f ace f ound
wit h DOS. To conf igur e mor e el abor at e f unct ions wit hin Chamel eon (such as SNMP,
mail , and Gat eway r out ing), consul t t he Chamel eon document at ion.
Configuring Windows 95 for TCP/IP
The f inal cl ient on t he sampl e net wor k t hat r equir es conf igur at ion is t he machine
cal l ed whit ney, wit h IP addr ess 147.120.0.10. Windows 95 is t he easiest of t he t hr ee
cl ient s t o conf igur e because ever yt hing you need t o set up TCP/IP under Windows 95 is
incl uded wit h t he sof t war e dist r ibut ion. Windows 95 is conf igur ed by def aul t t o use
Net War e IPX/SPX as t he net wor k pr ot ocol , but swit ching t o TCP/IP is quit e easy.
Begin t he Windows 95 conf igur at ion pr ocess by inst al l ing t he net wor k adapt er car d. In
some cases, when you r est ar t Windows 95 t he oper at ing syst em aut omat ical l y r ecognizes
t he addit ion of t he net wor k car d and pr oceeds t o t he conf igur at ion r out ines f or you. In
many cases, t hough, you have t o inst r uct Windows 95 t o l ook f or t he net wor k adapt er
car d.
To inst al l a net wor k adapt er car d, open t he Windows 95 Cont r ol Panel and doubl e-
cl ick t he Add New Har dwar e icon. This cal l s t he Add New Har dwar e Wizar d. Af t er you
cl ick t he Next but t on on t he int r oduct or y dial og, Windows 95 gives you t he opt ion of
having t he oper at ing syst em t r y t o det ect t he new har dwar e aut omat ical l y.
It is usual l y best t o l et Windows 95 t r y t o f ind t he net wor k adapt er by it sel f , especial l y
if t he new car d is a pl ug-and-pl ay t ype. If Windows 95 can ident if y t he har dwar e
aut omat ical l y, it saves you having t o pr ovide conf igur at ion inf or mat ion. If you want
Windows 95 t o go ahead and l ook f or t he net wor k adapt er , sel ect t he Yes but t on on
t his dial og (t he def aul t val ue) and cl ick t he Next but t on. Windows 95 begins sear ching
t he syst em f or new har dwar e. If Windows 95 det ect s a new net wor k car d, it displ ays a
scr een showing t he par amet er s it det ect ed and l et s you conf ir m t he sel ect ion. Af t er a
r eboot , t he net wor k car d shoul d be pr oper l y r ecognized and act ive.
If Windows 95 didn't det ect t he net wor k adapt er , you have t o inst al l and conf igur e it
manual l y. Windows 95 shows a dial og l ike t he one in Figur e 10.9. Cl icking t he Next
but t on displ ays t he dial og shown in Figur e 10.10, which asks f or t he t ype of new
har dwar e device you ar e inst al l ing. In t his case, you doubl e-cl ick t he Net wor k adapt er s
opt ion.
Figur e 10.9. This dial og is displ ayed if Windows 95 coul dn' t det ect a new net wor k
adapt er car d.
Figur e 10.10. This dial og asks f or t he t ype of har dwar e you ar e inst al l ing.
The next dial og t o appear shows a l ist of net wor k adapt er car d manuf act ur er s on t he
l ef t side, and a mor e det ail ed l ist of net wor k car d model s f r om t he sel ect ed
manuf act ur er on t he r ight . Sel ect t he pr oper manuf act ur er of t he net wor k adapt er
car d in t he l ist at l ef t by singl e-cl icking t he manuf act ur er 's name, t hen sel ect t he name
in t he r ight -side l ist t hat mat ches t he specif ic car d.
You must be car ef ul t hat you mat ch t he name of t he adapt er car d exact l y wit h t he l ist ,
because some dr iver s do not wor k on ot her car ds f r om t he same manuf act ur er . If you
sel ect t he wr ong adapt er car d, you won't cause any damage t o eit her t he car d or
Windows 95, but t he net wor k wil l not be f ound pr oper l y by Windows 95. If you can't
f ind t he par t icul ar model name of t he net wor k adapt er car d you ar e using, but you have
a dr iver suppl ied on disk, use t he Have Disk but t on t o r ead t he dr iver int o Windows 95.
Once you have sel ect ed t he pr oper net wor k car d name, Windows 95 displ ays a window
wit h conf igur at ion inf or mat ion shown in it . This dial og is shown in Figur e 10.11. The
amount of conf igur at ion inf or mat ion shown in t his dial og, and t he set t ings it shows, ar e
dif f er ent f or each net wor k adapt er car d.
Figur e 10.11. Windows 95 uses t his dial og t o ask f or t he conf igur at ion set t ings of
t he net wor k car d.
If t he net wor k adapt er was f ound by aut odet ect ion, t he set t ings shown in t his dial og
ar e t he ones Windows 95 assumed ar e cor r ect f or t he car d. If Windows 95 coul dn't f ind
t he net wor k car d, t he set t ings shown ar e t he def aul t val ues usual l y used by t he
manuf act ur er . Check t he document at ion suppl ied wit h t he net wor k adapt er car d t o
conf ir m t he set t ings. Af t er you conf ir m t hat t he displ ayed val ues ar e cor r ect , Windows
95 inst al l s t he sof t war e necessar y t o dr ive t he net wor k adapt er car d.
Installing TCP/IP
You can inst al l t he TCP/IP dr iver s incl uded wit h Windows 95 by displ aying t he Net wor k
dial og. Cl ick t he Net wor k icon in t he Cont r ol Panel t o displ ay t he Net wor k dial og
shown in Figur e 10.12. The dial og shoul d show a f ew basic ent r ies cr eat ed when Windows
95 inst al l ed it sel f , as wel l as t he net wor k har dwar e car d. By def aul t , t he Net BEUI or
Net War e (IPX) pr ot ocol s might al r eady be l oaded.
Figur e 10.12. The Net wor k window shows al l conf igur ed har dwar e and pr ot ocol s.
To add t he TCP/IP pr ot ocol dr iver s t o Windows 95, sel ect t he Add but t on bel ow t he l ist
of inst al l ed component s t o displ ay t he Sel ect Net wor k Component Type dial og shown in
Figur e 10.13. This window asks f or t he t ype of component (adapt er car d, pr ot ocol ,
ser vice, or cl ient ) you want t o inst al l . Because you want t o inst al l t he TCP/IP pr ot ocol
dr iver s, choose Pr ot ocol . The Sel ect Net wor k Pr ot ocol dial og, shown in Figur e 10.14, is
displ ayed.
Figur e 10.13. The Sel ect Net wor k Component Type dial og l et s you add a pr ot ocol ,
cl ient , ser vice, or adapt er car d.
Figur e 10.14. The Sel ect Net wor k Pr ot ocol dial og l et s you choose t he t ype of
pr ot ocol t o add.
Fr om t he Sel ect Net wor k Pr ot ocol window, sel ect Micr osof t in t he l ef t scr ol l l ist ,
t hen move t o t he r ight window, which l ist s al l t he Micr osof t pr ot ocol s suppl ied wit h
Windows 95. Choose t he TCP/IP ent r y. You ar e r et ur ned t o t he Net wor k dial og, and
TCP/IP is l ist ed as a suppor t ed pr ot ocol .
To st ar t t he conf igur at ion pr ocess, eit her doubl e-cl ick t he TCP/IP pr ot ocol ent r y in t he
Net wor k dial og l ist , or sel ect t he TCP/IP pr ot ocol ent r y and cl ick t he Pr oper t ies
window. The TCP/IP Pr oper t ies dial og appear s, as shown in Figur e 10.15.
Figur e 10.15. The TCP/IP Pr oper t ies dial og has six pages of conf igur at ion
inf or mat ion.
Fr om t he TCP/IP Pr oper t ies dial og, six pages of inf or mat ion ar e avail abl e by choosing one
of t he t abs acr oss t he t op of t he dial og. For most inst al l at ions you have t o suppl y onl y
a smal l par t of t his inf or mat ion. You can st ar t wit h t he IP Addr ess page, which is t he
f ir st page shown whenever t he TCP/IP Pr oper t ies window is displ ayed. Ent er t he IP
addr ess and subnet mask in t he spaces pr ovided, making sur e t o keep t he f our par t s of t he
dot t ed-quad not at ion separ at e.
Some l ar ger cor por at e net wor ks ar e set up t o assign IP
addr esses t o connect ing cl ient s aut omat ical l y using a special
pr ot ocol . This pr ot ocol , cal l ed Dynamic Host Conf igur at ion
Pr ot ocol (DHCP) ser ver s, is usual l y used f or machines t hat
connect t o a TCP/IP net wor k onl y occasional l y. If your
net wor k uses DHCP, you can sel ect t he f ir st but t on on t he IP
Addr ess page and l et Windows 95 obt ain your IP addr ess and
subnet mask f or you. Most net wor ks do not use DHCP.
Next , you move t o t he Advanced page of t he TCP/IP Pr oper t ies dial og by sel ect ing t he
Advanced t ab at t he t op of t he dial og. This dial og l et s you specif y t hat TCP/IP is t he
def aul t pr ot ocol used by t he Windows 95 machine by cl icking t he opt ion at t he bot t om
of t he page, as shown in Figur e 10.16. If your Windows 95 syst em is at t ached t o a TCP/IP
net wor k and uses TCP/IP most of t he t ime, make sur e you sel ect t his opt ion; ot her wise,
Window 95 t r ies t o use Net BIOS or IPX/SPX on t he TCP/IP net wor k.
Figur e 10.16. Sel ect t he def aul t opt ion f r om t he Advanced page of t he TCP/IP
Pr oper t ies dial og.
For many simpl e TCP/IP net wor ks, t hat 's al l t he inf or mat ion you need t o suppl y.
Windows 95 now l oads t he pr oper dr iver s int o t he oper at ing syst em, using t he val ues
suppl ied f or t he IP addr ess and subnet mask. Af t er t he sof t war e has been pr oper l y
l oaded, Windows 95 must be r est ar t ed t o make t he TCP/IP dr iver s ef f ect ive.
Further TCP/IP Configuration
Some TCP/IP syst ems r equir e ext r a conf igur at ion t o pr ovide Windows 95 wit h t he name of
t he ser ver s, gat eways, or ot her det ail s. You can make many of t hese conf igur at ion st eps
at any t ime, but some ser vices might not be avail abl e t o you unt il you do. Al l of t hese
changes ar e made t hr ough t he TCP/IP Pr oper t ies dial og used t o set t he IP addr ess and
subnet mask.
The WINS Conf igur at ion page of t he TCP/IP Pr oper t ies window is used t o inst r uct your
Windows 95 syst em how t o t al k t o a Windows Int er net Naming Ser vice (WINS) ser ver .
WINS l et s you use t he Net BIOS pr ot ocol on a TCP/IP net wor k. Most net wor ks don't use
WINS, so you can pr obabl y ignor e t his page compl et el y unl ess you know you wil l need
t o use WINS on your net wor k. If WINS is r equir ed on your net wor k, ent er t he IP addr ess
of t he pr imar y (and secondar y, if used) WINS ser ver s, as wel l as t he Scope ID. If WINS is
not used on your net wor k, make sur e t he Disabl e WINS Resol ut ion opt ion is sel ect ed.
The Gat eway page l et s you specif y wher e your net wor k's gat eways ar e. Gat eways ar e
used t o connect t o ot her net wor ks, incl uding t he Int er net . If your net wor k uses a
gat eway, ent er t he IP addr ess of t he pr imar y net wor k gat eway machine and cl ick t he
Add but t on. You can ent er many gat eways int o Windows 95, but you shoul d al ways
pr ovide t he pr imar y gat eway IP addr ess f ir st (because Windows 95 sear ches t he l ist of
gat eways in or der ).
The DNS Conf igur at ion page must be compl et ed if your net wor k uses t he Domain Name
Syst em (DNS). DNS per f or ms a conver sion bet ween an IP addr ess and a symbol ic name.
DNS r equir es a special net wor k conf igur at ion and ser ver , so smal l net wor ks ar e
unl ikel y t o use DNS. If your net wor k is r unning DNS, you can ent er your machine's
symbol ic name, t he domain name (t he name of your wor kgr oup or ent ir e company), and
t he IP addr ess of your DNS ser ver on t his page. Af t er Windows 95 has connect ed t o t he
DNS ser ver and t ol d it your IP addr ess and symbol ic name, ot her user s of t he net wor k
can connect t o your machine using your symbol ic name. Simil ar l y, if you know t he
symbol ic name of a r emot e machine, you can use t hat t o connect t o it inst ead of t he IP
addr ess.
The f inal page of t he TCP/IP Pr oper t ies window is t he Bindings page. This page l ist s al l
t he net wor k component s t hat use t he TCP/IP pr ot ocol . If you have inst al l ed ot her
net wor king pr ot ocol s on your Windows 95 syst em, t her e might be mor e ent r ies in t he
Bindings l ist . Sel ect onl y t hose t hat use t he TCP/IP pr ot ocol . Minimizing t he number of
bindings f or each pr ot ocol hel ps impr ove t he ef f iciency of t he Windows 95 net wor king
sof t war e.
Testing TCP/IP
Once you have inst al l ed t he net wor k car d and sof t war e, you can t est t he new TCP/IP
pr ot ocol . The best ut il it y f or a quick check of your TCP/IP net wor k connect ion is ping.
The ping ut il it y suppl ied wit h Windows 95 is a DOS appl icat ion, not Windows 95, so it
shoul d be l aunched in a DOS window. It usual l y r esides in t he same dir ect or y as
Windows 95 f il es (usual l y \windows).
To use ping, ent er t he name or addr ess af t er t he ping command at t he DOS pr ompt . The
ping ut il it y t hen sends and r eceives packet s of inf or mat ion. If messages such as Bad IP
Addr ess, Request Timed out , or Unknown host ar e displ ayed, ping can't connect or
r esol ve t he name or IP addr ess you suppl ied.
At t his point , if you successf ul l y sent and r eceived packet s, al l is wel l wit h t he TCP/IP
connect ion. If ping displ ayed er r or messages or coul dn't send and r eceive packet s over
t he net wor k, you shoul d ver if y t hat t he IP addr ess is val id. If it is, t r y anot her machine
on t he net wor k t o ping t he Windows 95 machine. If you can't , t hen t he net wor k adapt er
or pr ot ocol on t he Windows 95 machine is not l oaded pr oper l y.
Winsock
For some Windows and Windows 95 user s, Winsock is t he easiest met hod t o get int o
TCP/IP because it is avail abl e f r om many publ ic domain, BBS, and onl ine ser vice sit es.
Ther e ar e sever al ver sions of Winsock, some of which ar e publ ic domain or shar ewar e.
We wil l l ook at t wo ver sions of Winsock, one f or Windows 3.X and anot her f or Windows
95. We have chosen t he popul ar Tr umpet Winsock impl ement at ions f or bot h oper at ing
syst ems because t hey ar e shar ewar e, r eadil y avail abl e, and wel l suppor t ed.
Winsock is shor t f or Windows Socket s, or iginal l y devel oped by Micr osof t . Rel eased in
1993, Windows Socket s is an int er f ace f or net wor k pr ogr amming in t he Windows
envir onment . Micr osof t has publ ished t he specif icat ions f or Windows Socket s, hence
making it an open appl icat ion pr ogr amming int er f ace (API). The Winsock API (cal l ed
WSA) is a l ibr ar y of f unct ion cal l s, dat a st r uct ur es, and pr ogr amming pr ocedur es t hat
pr ovide t his st andar dized int er f ace f or appl icat ions. The second r el ease of Winsock,
cal l ed Winsock ver sion 2, was r el eased in mid 1995.
Trumpet Winsock
Tr umpet Winsock is a shar ewar e impl ement at ion of Winsock pr oduced by Tr umpet
Sof t war e Int er nat ional . Tr umpet Winsock is avail abl e f or Windows 3.X and Windows 95
syst ems. Regist r at ion of t he Winsock package, devel oped in Aust r al ia, is $25 US. Tr umpet
Winsock l et s you use sever al dif f er ent pr ot ocol s incl uding PPP and SLIP f or connect ion
t o t he Int er net or r emot e net wor ks, dir ect connect ion using TCP/IP, and t he BOOTP
pr ot ocol . Tr umpet Winsock al l ows dynamic IP addr essing, which is necessar y wit h many
Int er net Ser vice Pr ovider s.
The Tr umpet Winsock f il es ar e usual l y pr ovided in an ar chive ZIP f il e, and shoul d be
ext r act ed int o a new subdir ect or y on your syst em. The pr imar y f il es in t he Tr umpet
Winsock dist r ibut ion ar e
G WINSOCK.DLL: The pr imar y pr ot ocol st ack f or Winsock
G TCPMAN.EXE: Manages t he communicat ions bet ween WINSOCK.DLL and t he
net wor k
G TRUMPWSK.INI: Cont ains Winsock var iabl e set t ings
G HOSTS: A l ist of host s t hat Winsock is awar e of
G SERVICES: A l ist of ser vices suppor t ed by Winsock
G PROTOCOL: A l ist of pr ot ocol s suppor t ed by Winsock
Ther e ar e a number of sampl e conf igur at ion f il es incl uded in t he ar chive, as wel l as
ut il it ies such as PING and HOP. Some of t he f il es in t he Winsock ar chive, such as HOSTS,
PROTOCOL, and SERVICES, mir r or UNIX f il es of t he same name.
Installing Trumpet Winsock
The inst al l at ion pr ocess f or Tr umpet Winsock is t he same whet her you ar e using
SLIP/PPP f or connect ion or a packet dr iver f or LAN-based oper at ions. Begin t he
inst al l at ion by adding t he dir ect or y hol ding t he Tr umpet Winsock f il es t o your PATH.
The f il es shoul d, of cour se, be ext r act ed f r om t he ZIP f il e t hey ar e usual l y suppl ied in.
Af t er t he pat h has been modif ied, r eboot your machine t o ef f ect t he change.
You can cr eat e a Windows pr ogr am gr oup f or t he Tr umpet Winsock syst em by adding a
new pr ogr am gr oup f r om t he Pr ogr am Manager menus. (Sel ect Fil e menu, t he New menu
it em, and t hen Pr ogr am Gr oup.) Cr eat e a t it l e, such as Tr umpet Winsock. f or t he new
pr ogr am gr oup.
Next , cr eat e a Pr ogr am Icon f or t he TCPMAN pr ogr am (t he pr imar y Tr umpet Winsock
pr ogr am) by eit her cr eat ing a new Pr ogr am It em f r om t he Pr ogr am Manager or opening
t he Fil e Manager and dr agging t he TCPMAN.EXE ent r y f r om it s dir ect or y t o t he
Tr umpet Winsock pr ogr am gr oup. Windows wil l pr ompt you f or any inf or mat ion it needs.
The pr ogr am icon is r ead f r om t he dist r ibut ion f il es if t he pat h is pr oper l y set .
To t est t he inst al l at ion of t he pat h and t he Windows icon, cl ick t he TCPMAN icon. If
you r eceive er r or messages, eit her t he PATH is not set pr oper l y or t he pr ogr am icon has
not been pr oper l y def ined. Because you ar e pr imar il y int er est ed in using Winsock on a
TCP/IP net wor k, ignor e conf igur ing PPP and SLIP and concent r at e on t he TCP/IP st ack.
Configuring the TCP/IP Packet Driver
Tr umpet Winsock r el ies on a pr ogr am cal l ed WINPKT t o pr ovide TCP/IP packet
capabil it ies under Windows. Af t er you cr eat e a pr ogr am gr oup f or Winsock, you need t o
set up t he packet dr iver inf or mat ion in t he net wor k f il es.
You wil l need a packet dr iver f or your syst em, which is not incl uded wit h most Tr umpet
Winsock dist r ibut ions. In many cases, t he net wor k car d vendor incl udes a disk wit h a
packet dr iver on it . If not , one of t he best sour ces f or a packet dr iver is t he Cr ynwr
Packet Dr iver col l ect ion, a l ibr ar y of dif f er ent packet dr iver s avail abl e f r om many
onl ine, BBS, FTP, and WWW sit es. The packet dr iver specif icat ions ar e added t o your
net wor k st ar t up bat ch f il e, usual l y AUTOEXEC.BAT f or DOS-based syst ems.
To obt ain a Cr ynwr packet dr iver , use a Web br owser t o
connect t o ht t p://www.cr ynwr .com. Ther e ar e sever al dozen
publ ic domain dr iver s avail abl e f r om t his sit e.
The pr ocess f or conf igur ing Tr umpet Winsock f or LAN oper at ion is quit e simpl e. Set t he
IRQ and I/O addr ess of t he packet dr iver and add t he packet dr iver t o your syst em. A
t ypical ent r y in t he net wor k bat ch f il e l ooks l ike t his:
ne2000 0x60 2 0x300
WINPKT 0x60
This set s t he net wor k t o use an NE2000 (Novel l ) t ype car d, wit h I/O addr ess of 300H, IRQ
of 2, and a vect or of 60. Sever al conf igur at ions ar e usual l y pr ovided wit h t he Tr umpet
Winsock dist r ibut ion, al t hough it is easy t o der ive your own f r om t he net wor k int er f ace
car d manuf act ur er 's document at ion.
To set up Tr umpet Winsock f or a packet dr iver , use t he Set up scr een t hat appear s when
TCPMAN is f ir st l aunched, or use t he menus wit hin TCPMAN t o displ ay t he set up scr een.
Desel ect bot h Int er nal SLIP and Int er nal PPP set t ings. If eit her of t hem ar e checked,
t he packet dr iver wil l not l aunch pr oper l y.
Ent er t he IP addr ess, net mask, name ser ver IP addr ess, and domain name inf or mat ion. You
may al so modif y t he ent r ies f or Demand Load Time-out , MTU, TCP RWIN, TCP MSS, and
TCP RTO MAX. See t he sect ion on SLIP/PPP conf igur at ion above f or mor e det ail s on any
of t hese set t ings. The def aul t val ues used f or a packet dr iver ar e dif f er ent t han t hose
f or a SLIP/PPP set t ing. If you ar e using BOOTP or RARP t o det er mine your machine IP
addr ess, ent er t he pr oper pr ot ocol name in t he IP addr ess f iel d.
The Packet Vect or f iel d shoul d be set t o t he vect or you used in t he net wor k car d
descr ipt ion, or you can l eave it as 00 t o l et Tr umpet Winsock sear ch f or t he packet
dr iver . Af t er t he conf igur at ion is saved, r est ar t TCPMAN and t he net wor k wil l be
avail abl e (if t he conf igur at ion and packet dr iver s ar e pr oper l y set ). A ping command or
simil ar ut il it y wil l ver if y t he packet dr iver oper at ion is cor r ect .
Summary
Today you l ear ned how t o inst al l and conf igur e t hr ee PC-based syst ems: one f or DOS
and t wo specif ical l y f or Windows ver sions. They ar e now connect ed t o t he sampl e
net wor k, and f il es can be t r ansf er r ed bet ween t he machines quickl y and easil y. The DOS
machines can al so r un Windows f or Wor kgr oups piggy-backed on t he TCP/IP net wor k.
Adding ot her machines usual l y f ol l ows t he same pr ocedur e. For exampl e, t o add a
Macint osh r unning Mac TCP/IP, f ol l ow t he inst al l at ion guide t o inst al l and conf igur e
t he sof t war e, and t hen use ping t o ver if y t hat ever yt hing is wor king cor r ect l y.


I Domain Name Ser vice (DNS)
I DNS St r uct ur e
I The Name Ser ver
I Resour ce Recor ds
I IN-ADDR-ARPA
I Messages
I The Name Resol ver
I Conf igur ing a UNIX DNS Ser ver
I Ent er ing t he Resour ce Recor ds
I Compl et ing t he DNS Fil es
I St ar t ing t he DNS Daemons
I Conf igur ing a Cl ient
I BOOTP Pr ot ocol
I BOOTP Messages
I Net wor k Time Pr ot ocol (NTP)
I Summar y
I Q&A
I Quiz
11
Domain Name Service
TCP/IP uses a 32-bit addr ess t o r out e a dat agr am t o a dest inat ion. It is usef ul t o f or get
t hese 32-bit addr esses and use common names inst ead, because names ar e much easier t o
r emember . Ther e ar e sever al met hods used f or t his. The most common is examined on Day
7, "TCP/IP Conf igur at ion and Administ r at ion Basics," empl oying an ASCII f il e on t he
sending machine t hat had names and cor r esponding addr esses (/et c/host s on a UNIX
device). One major l imit at ion t o t his syst em is t hat t he machine can r out e onl y t o ot her
machines t hat have an ent r y in t his f il e, which can be impossibl e t o maint ain when t her e
ar e many t ar get machines or you want t o access al l t he devices on your net wor k.
Anot her appr oach is t o of f -l oad t he addr ess r esol ut ion t o anot her pr ocess t hat act s
l ike a dir ect or y ser vice. Ther e ar e t wo such schemes in common use t oday: Domain Name
Ser vice (DNS) and Net wor k Inf or mat ion Ser vice (NIS), which is now par t of NFS. Today I
l ook at DNS in mor e det ail . On Day 12, "NFS and NIS," I examine NFS in dept h.
Al so t oday I l ook at t he BOOTP pr ot ocol , a syst em t hat is becoming widel y adopt ed as
diskl ess wor kst at ions and cl ient /ser ver syst ems become mor e common. BOOTP r el ies on
TCP/IP. Anyone wor king wit h TCP/IP can event ual l y expect t o r un acr oss t he BOOTP
pr ot ocol , so an expl anat ion of it is usef ul at t his st age.
Final l y, t he day cl oses wit h a quick l ook at t he Net wor k Time Pr ot ocol (NTP), which is
used t o ensur e synchr onizat ion of t imest amps bet ween machines.
Domain Name Service (DNS)
A symbol ic name is a char act er st r ing t hat is used t o ident if y a machine. A symbol ic name
can be st r aight f or war d (bil l s_machine or t pci_ser ver 1) or mor e compl ex, as is of t en t he
case in l ar ge or ganizat ions wher e t he name ident if ies t he t ype of machine and it s
l ocat ion (such as hpws510, wher e hpws ident if ies an HP wor kst at ion on t he f if t h f l oor ,
r oom 10).
When sending inf or mat ion t o r emot e machines, IP addr esses or Int er net addr esses must be
used. Inst ead of r equir ing t he user t o memor ize t he r emot e machine's number s, it is
common t o use a symbol ic name. Af t er al l , a simpl e name is much easier t o r emember t han
a 32-bit Int er net addr ess.
As you saw ear l ier in t his book, t he conver sion f r om a symbol ic name t o an act ual IP
addr ess is usual l y per f or med wit hin t he sending machine, using a f il e such as UNIX's
/et c/host s f il e. This t ype of appr oach wor ks wel l wit hin a smal l net wor k, wher e a
l imit ed number of dest inat ion machines ar e invol ved. When deal ing wit h t he ent ir e
Int er net , however , it is unr easonabl e t o expect an ASCII f il e t o cont ain al l possibl e
symbol ic names and t heir addr esses.
The sheer size of a f il e r equir ed t o hol d al l possibl e symbol ic domain names and t heir
cor r esponding unique net wor k addr esses is not t he onl y pr obl em. Lar ge net wor ks t end
t o change const ant l y, especial l y on an int er net wor k t he size of t he Int er net . Hundr eds
of addit ions and modif icat ions t o exist ing ent r ies must be per f or med dail y. The t ime
r equir ed t o updat e each machine (or even sel ect ed gat eways t o aut onomous net wor ks)
on t he int er net wor k woul d be huge.
The sol ut ion t o t he pr obl em is t o of f er a met hod of moving t he management of t he
l ookup t abl es away f r om t he Net wor k Inf or mat ion Cent er (NIC), which gover ns t he
Int er net , and t owar d t he par t icipant s and t heir aut onomous net wor ks in such a manner
t hat t he l oad on t he net wor k is smal l but f l exibil it y is not compr omised. This is what
t he Domain Name Ser vice (DNS) does. DNS is somet imes al so cal l ed t he Int er net
dir ect or y ser vice, al t hough t he name is somewhat of a misnomer .
UNIX impl ement s DNS t hr ough a daemon cal l ed named, which r uns on a name server, a
machine t hat handl es t he r esol ut ion of symbol ic names using DNS met hods. Par t of t he
syst em is a l ibr ar y of f unct ions t hat can be used in appl icat ions t o per f or m quer ies on
t he name ser ver . This quer y r out ine is cal l ed t he resolver or name resolver and can r eside
on anot her machine. The name ser ver and r esol ver ar e examined in mor e det ail shor t l y.
DNS Structure
The Domain Name Ser vice, as it s name impl ies, wor ks by dividing t he int er net wor k int o a
set of domains, or net wor ks, t hat can be f ur t her divided int o subdomains. This st r uct ur e
r esembl es a t r ee, as shown in Figur e 11.1, using some ar bit r ar il y chosen domain names.
The f ir st set of domains is cal l ed t he top-level domains. Ther e ar e six t op-l evel domains in
r egul ar use:
G ARPA: For Int er net -specif ic or ganizat ions
G COM: For commer cial ent er pr ises
G EDU: For educat ional or ganizat ions
G GOV: For gover nment al bodies
G MIL: For mil it ar y or ganizat ions
G ORG: For noncommer cial or ganizat ions
Figur e 11.1. The Int er net domain st r uct ur e.
In addit ion t o t hese t op-l evel domains, t her e ar e dedicat ed t op-l evel domains f or each
count r y t hat is connect ed. These ar e usual l y ident if ied by a shor t f or m of t he count r y's
name, such as .ca f or Canada and .uk f or t he Unit ed Kingdom. These count r y t op-l evel
domains ar e usual l y l ef t of f diagr ams of t he Int er net st r uct ur e f or convenience
(ot her wise t her e woul d be hundr eds of t op-l evel domains). The domain br eakdown is
somet imes r epeat ed beneat h t he count r y domain, so t her e coul d be a .com ext ension
coupl ed wit h .ca t o show a Canadian commer cial domain, or an .edu wit h .uk f or a Br it ish
univer sit y.
Beneat h t he t op-l evel domains is anot her l evel f or t he individual or ganizat ions wit hin
each t op-l evel domain. The domain names ar e al l r egist er ed wit h t he Net wor k
Inf or mat ion Cent er (NIC) and ar e unique t o t he net wor k. Usual l y t he names ar e
r epr esent at ive of t he company or or ganizat ion, but a f ew "cut e" names do wor k t heir
way in (usual l y because of hist or ical r easons).
Ther e ar e t wo ways t o name a t ar get . If t he t ar get is on t he int er net wor k, t he absolute
name is used. The absol ut e name is unique and unambiguous, specif ying t he domain of t he
t ar get machine. A relative name can be used eit her wit hin t he l ocal domain, wher e t he
name ser ver knows t hat t he t ar get is wit hin t he domain and hence doesn't need t o r out e
t he dat agr am ont o t he int er net wor k, or when t he r el at ive name is known by t he name
ser ver and can be expanded and r out ed cor r ect l y.
The Name Server
Each DNS Name Ser ver manages a dist inct ar ea of a net wor k (or an ent ir e domain, if t he
net wor k is smal l ). The set of machines managed by t he name ser ver is cal l ed a zone.
Sever al zones can be managed by one name ser ver . Al most ever y zone has a designat ed
secondar y or backup name ser ver , wit h t he t wo (pr imar y and secondar y) name ser ver s
hol ding dupl icat e inf or mat ion. The name ser ver s wit hin a zone communicat e using a zone
transfer protocol.
DNS oper at es by having a set of nest ed zones. Each name ser ver communicat es wit h t he
one above it (and, if t her e is one, t he one bel ow it ). Each zone has at l east one name
ser ver r esponsibl e f or knowing t he addr ess inf or mat ion f or each machine wit hin t hat
zone. Each name ser ver al so knows t he addr ess of at l east one ot her name ser ver .
Messages bet ween name ser ver s usual l y use t he User Dat agr am Pr ot ocol (UDP) because
it s connect ionl ess met hod pr ovides f or bet t er per f or mance. However , TCP is used f or
dat abase updat es because of it s r el iabil it y.
When a user appl icat ion needs t o r esol ve a symbol ic name int o a net wor k addr ess, a
quer y is sent by t he appl icat ion t o t he r esol ver pr ocess, which t hen communicat es t he
quer y t o t he name ser ver . (I examine t he r esol ver in mor e det ail in t he next sect ion,
"Resour ce Recor ds.") The name ser ver checks it s own t abl es and r et ur ns t he net wor k
addr ess cor r esponding t o t he symbol ic name. If t he name ser ver doesn't have t he
inf or mat ion it r equir es, it can send a r equest t o anot her name ser ver . This pr ocess is
shown in Figur e 11.2. Bot h t he name ser ver s and t he r esol ver s use dat abase t abl es and
caches t o maint ain inf or mat ion about t he machines in t he l ocal zone, as wel l as
r ecent l y r equest ed inf or mat ion f r om out side t he zone.
Figur e 11.2. Resol ving symbol ic names.
When a name ser ver r eceives a quer y f r om a r esol ver , t her e ar e sever al t ypes of
oper at ions t he name ser ver can per f or m. Name r esol ver oper at ions f al l int o t wo
cat egor ies: nonrecursive and recursive. A r ecur sive oper at ion is one in which t he name
ser ver must access anot her name ser ver f or inf or mat ion.
Nonr ecur sive oper at ions per f or med by t he name ser ver incl ude a f ul l answer t o t he
r esol ver 's r equest , a r ef er r al t o anot her name ser ver (which t he r esol ver must send a
quer y t o), or an er r or message. When a r ecur sive oper at ion is necessar y, t he name ser ver
cont act s anot her name ser ver wit h t he r esol ver 's r equest . The r emot e name ser ver
r epl ies t o t he r equest wit h eit her a net wor k addr ess or a negat ive message, indicat ing
f ail ur e. DNS r ul es pr ohibit a r emot e name ser ver f r om sending a r ef er r al t o yet anot her
name ser ver .
Resource Records
The inf or mat ion r equir ed t o r esol ve symbol ic names is maint ained by t he name ser ver in a
set of resource records, which ar e ent r ies in a dat abase. Resour ce r ecor ds (of t en
abbr eviat ed RR) cont ain inf or mat ion in ASCII f or mat . Because ASCII is used, it is easy t o
updat e t he r ecor ds. The f or mat of r esour ce r ecor ds is shown in Figur e 11.3.
Figur e 11.3. The r esour ce r ecor d f or mat .
The Name f iel d is t he domain name of t he machine t he r ecor d r ef er s t o. If no name is
specif ied, t he pr eviousl y used name is subst it ut ed.
The Type f iel d ident if ies t he t ype of r esour ce r ecor d. Resour ce r ecor ds ar e used f or
sever al pur poses, such as mapping names t o addr esses and def ining zones. The Type of
r esour ce r ecor d is ident if ied by a mnemonic code or a number . These codes and t heir
meanings ar e shown in Tabl e 11.1. Some of t he r esour ce r ecor d t ypes ar e now obsol et e (3
and 4), and ot her s ar e consider ed exper iment al at t his t ime (13 and 1721).
Tabl e 11.1. Resour ce r ecor d t ypes.
Number Code Description
1 A Net wor k addr ess
2 NS Aut hor it at ive name ser ver
3 MD Mail dest inat ion; now r epl aced by MX
4 MF Mail f or war der ; now r epl aced by MX
5 CNAME Canonical al ias name
6 SOA St ar t of zone aut hor it y
7 MB Mail box domain name
8 MG Mail box member
9 MR Mail r ename domain
10 NULL Nul l r esour ce r ecor d
11 WKS Wel l -known ser vice
12 PTR Point er t o a domain name
13 HINFO Host inf or mat ion
14 MINFO Mail box inf or mat ion
15 MX Mail exchange
16 TXT Text st r ings
17 RP Responsibl e per son
18 AFSDB AFS-t ype ser vices
19 X.25 X.25 addr ess
20 ISDN ISDN addr ess
21 RT Rout e t hr ough
The Cl ass f iel d in t he r esour ce r ecor d l ayout cont ains a val ue f or t he cl ass of r ecor d.
If no val ue is specif ied, t he l ast cl ass used is subst it ut ed. Int er net name ser ver s usual l y
have t he code IN.
The Time t o Live (TTL) f iel d specif ies t he amount of t ime in seconds t hat t he r esour ce
r ecor d is val id in t he cache. If a val ue of 0 is used, t he r ecor d shoul d not be added t o t he
cache. If t he TTL f iel d is omit t ed, a def aul t val ue is used. Usual l y t his f iel d t el l s t he
name ser ver how l ong t he ent r y is val id bef or e it has t o ask f or an updat e.
The dat a sect ion of t he r esour ce r ecor d cont ains t wo par t s, consist ing of t he l engt h of
t he r ecor d and t he dat a it sel f . The Dat a Lengt h f iel d specif ies t he l engt h of t he dat a
sect ion. The dat a is a var iabl e-l engt h f iel d (hence t he need f or a l engt h val ue) t hat
descr ibes t he ent r y somehow. The use of t his f iel d dif f er s wit h t he dif f er ent t ypes of
r esour ce r ecor ds.
Some r esour ce r ecor d t ypes have a singl e piece of inf or mat ion in t he dat a ar ea, such as
an addr ess, or at most t hr ee pieces of inf or mat ion. The onl y except ion is t he St ar t of
Aut hor it y r esour ce r ecor d. The cont ent s of t he r esour ce r ecor d dat a ar eas (except
SOAs) ar e given in Tabl e 11.2.
Tabl e 11.2. The cont ent s of t he r esour ce r ecor d dat a ar eas.
RR Type Fields in Data Area
A Addr ess: A net wor k addr ess
NS NSDNAME: The domain name of host
MG MGNAME: The domain name of mail box
CNAME CNAME: An al ias f or t he machine
HINFO CPU: A st r ing ident if ying CPU t ype
OS: A st r ing ident if ying oper at ing syst em
MINFO RMAILBX: A mail box r esponsibl e f or mail ing l ist s
EMAILBOX: A mail box f or er r or messages
MB MADNAME: Now obsol et e
MR NEWNAME: Renames t he addr ess of a specif ic mail box
MX PREFERENCE: Specif ies t he pr ecedence f or del iver y
EXCHANGE: The domain name of t he host t hat act s as mail exchange
NULL Anyt hing can be pl aced in t he dat a f iel d
PTR PTRDNAME: A domain name t hat act s as a point er t o a l ocat ion
TXT TXTDATA: Any kind of descr ipt ive t ext
WKS Addr ess: A net wor k addr ess
Pr ot ocol : The pr ot ocol used
Bit map: Used t o ident if y por t s and pr ot ocol s
The St ar t of Aut hor it y (SOA) r esour ce r ecor d f or mat is used t o ident if y t he machines
wit hin a zone. Ther e is onl y one SOA r ecor d in each zone. The f or mat of t he SOA dat a
f iel d is shown in Figur e 11.4. The f iel ds in t he SOA r esour ce r ecor d ar e used most l y f or
administ r at ion and maint enance of t he name ser ver .
Figur e 11.4. The SOA r esour ce r ecor d f or mat .
The MNAME f iel d is t he domain name of t he sour ce of dat a f or t he zone. The RNAME
(r esponsibl e per son name) f iel d is t he domain name of t he mail box of t he administ r at or of
t he zone. The Ser ial f iel d cont ains a ver sion number f or t he zone. It is incr ement ed
when t he zone is changed; ot her wise, it is maint ained as t he same val ue f or al l such
messages.
The Ref r esh Time is t he number of seconds bet ween dat a r ef r eshes f or t he zone. The
Ret r y Time is t he number of seconds t o wait bet ween unsuccessf ul r ef r esh r equest s. The
Expir y Time is t he number of seconds af t er which t he zone inf or mat ion is no l onger
val id. Final l y, t he Minimum Time is t he number of seconds t o be used in t he Time t o Live
f iel d of r esour ce r ecor ds wit hin t he zone.
Some sampl e r esour ce r ecor ds show t he simpl e f or mat used. Addr ess r esour ce r ecor ds
consist of t he machine name, t he t ype of r esour ce r ecor d indicat or (A f or Addr ess RRs,
f or exampl e), and t he net wor k addr ess. A sampl e Addr ess r esour ce r ecor d woul d l ook
l ike t his:
TPCI_SCO_4 IN A 143.23.25.7
The IN t ags t he r esour ce r ecor d as an Int er net cl ass. This f or mat makes it easy t o l ocat e
a name and der ive it s addr ess. (The r ever se, going f r om addr ess t o name, is not as easy and
r equir es a special f or mat cal l ed IN-ADDR-ARPA, which is examined in t he next sect ion,
"IN-ADDR-ARPA.")
For Wel l -Known Ser vice r esour ce r ecor ds (WKS, or t ype 11), t he dat a f iel d of t he
r ecor d cont ains t hr ee f iel ds used t o descr ibe t he ser vices suppor t ed at t he addr ess t he
r ecor d r ef er s t o. A sampl e WKS r esour ce r ecor d might l ook l ike t his:
TPCI_SCO.TPCI.COM IN WKS 143.23.1.34.
FTP TCP SMTP TELNET
The f ul l domain name and Int er net addr ess ar e shown, as is t he IN t o show t he Int er net
cl ass of r esour ce r ecor ds. The t ype of r ecor d is indicat ed wit h t he WKS. The pr ot ocol s
suppor t ed by t he machine at t hat addr ess ar e l ist ed af t er t he addr ess. In r eal it y, t hese
ar e bit maps t hat cor r espond t o por t s. When t he por t bit is set t o a val ue of 1, t he ser vice
is suppor t ed. The l ist of por t s and ser vices is def ined by an Int er net RFC.
I N-ADDR-ARPA
The addr ess f iel ds, such as in t he Addr ess r esour ce r ecor d t ype, use a special f or mat
cal l ed IN-ADDR-ARPA. This enabl es r ever se mapping f r om t he addr ess t o t he host name as
wel l as host -t o-addr ess mapping. To under st and IN-ADDR-ARPA, it is usef ul t o begin
wit h a st andar d-f or mat r esour ce r ecor d. Ear l ier it was ment ioned t hat r esour ce r ecor ds
ar e maint ained in ASCII f or mat . One of t he simpl est t ypes of r esour ce r ecor d is f or t he
addr ess (t ype A), as seen ear l ier . An ext r act f r om an addr ess f il e is shown her e:
TPCI_HPWS1 IN A 143.12.2.50
TPCI_HPWS2 IN A 143.12.2.51
TPCI_HPWS3 IN A 143.12.2.52
TPCI_GATEWAY IN A 143.12.2.100
IN A 144.23.56.2
MERLIN IN A 145.23.24.1
SMALLWOOD IN A 134.2.12.75
Each l ine of t he f il e r epr esent s one r esour ce r ecor d. In t his case, t hey ar e al l simpl e
ent r ies t hat have t he machine's symbol ic name (al ias), t he cl ass of machine (IN f or
Int er net ), A t o show it is an Addr ess r esour ce r ecor d, and t he Int er net addr ess. The
ent r y f or t he machine TPCI_GATEWAY has t wo cor r esponding addr esses because it is a
gat eway bet ween t wo net wor ks. The gat eway has a dif f er ent addr ess on each of t he
net wor ks, so it has t wo r esour ce r ecor ds in t he same f il e. (As wit h most ot her code
f r agment s in t his book, t hese exampl e addr esses ar e hypot het ical .)
This t ype of f il e makes name-t o-addr ess mapping easy. The name ser ver simpl y sear ches f or
a l ine wit h t he symbol ic name r equest ed by t he appl icat ion and r et ur ns t he Int er net
addr ess at t he end of t hat l ine. The dat abases ar e indexed on t he name, so t hese sear ches
pr oceed ver y quickl y.
Sear ching f r om t he addr ess t o t he name is not quit e as easy. If t he r esour ce r ecor d f il es
ar e smal l , t ime del ays f or a manual sear ch ar e not appr eciabl e, but wit h l ar ge zones
t her e can be t housands or t ens of t housands of ent r ies. The index is on t he name, so
sear ching f or an addr ess can be a sl ow pr ocess. To sol ve t his r ever se-mapping pr obl em, IN-
ADDR-ARPA was devel oped. IN-ADDR-ARPA uses t he host addr ess as an index t o t he
host 's r esour ce r ecor d inf or mat ion. When t he pr oper r esour ce r ecor d is l ocat ed, t he
symbol ic name can be ext r act ed.
IN-ADDR-ARPA uses t he PTR r esour ce r ecor d t ype (see Tabl e 11.1) t o point f r om t he
addr ess t o t he name. Ther e might be one of t hese point er indexes maint ained on each
name ser ver . An exampl e of a number -t o-name f il e f ol l ows:
23.1.45.143.IN-ADDR-ARPA. PTR TPCI_HPWS_4.TPCI.COM
1.23.64.147.IN-ADDR-ARPA. PTR TPCI_SERVER.MERLIN.COM
3.12.6.123.IN-ADDR-ARPA. PTR BEAST.BEAST.COM
23.143.IN-ADDR-ARPA PTR MERLINGATEWAY.MERLIN.COM
The Int er net addr esses ar e r ever sed in t he IN-ADDR-ARPA f il e f or ease of use. As shown
in t he sampl e f il e, it is not necessar y t o specif y t he compl et e addr ess f or a gat eway
because t he domain name pr ovides enough r out ing inf or mat ion.
Messages
DNS messages ar e t r ansf er r ed bet ween name ser ver s t o updat e t heir r esour ce r ecor ds.
The f iel ds of t hese messages ar e quit e simil ar t o t hose of t he r ecor ds t hemsel ves. The
f or mat of a DNS message is shown in Figur e 11.5. The header has sever al subf iel ds t hat
cont ain inf or mat ion about t he t ype of quest ion or answer being sent . The r est of t he
message consist s of f our var iabl e-l engt h f iel ds, which ar e f ur t her subdivided:
G Quest ion: The inf or mat ion r equir ed.
G Answer : The answer t o t he quer y (f r om t he RR).
G Aut hor it y: The name of ot her name ser ver s t hat might have t he inf or mat ion
r equest ed, if it is not r eadil y avail abl e on t he t ar get ed name ser ver .
G Addit ional inf or mat ion: Inf or mat ion t hat can be pr ovided t o answer t he quer y,
or t he addr esses of name ser ver s if t he Aut hor it y f iel d was used.
Figur e 11.5. The DNS message f or mat .
The DNS message header has sever al dif f er ent f iel ds it sel f , as shown in Figur e 11.6. The
header is pr esent in al l DNS messages. The header ID f iel d is 16 bit s l ong and is used t o
mat ch quer ies and answer s t o each ot her . The singl e-bit QR f iel d is set t o a val ue of 0 t o
indicat e a quer y, or a val ue of 1 t o show a r esponse. The OpCode f iel d is 4 bit s l ong and
can have one of t he val ues shown in Tabl e 11.3.
Figur e 11.6. The DNS message Header f or mat .
Tabl e 11.3. The DNS message header OpCode val ues.
OpCode Value Description
0 St andar d quer y
1 Inver se quer y
2 Ser ver st at us r equest
315 Not used
The AA f iel d is t he aut hor it at ive answer bit . A val ue of 1 in a r esponse message indicat es
t hat t he name ser ver is t he r ecognized aut hor it y f or t he quer ied domain name. The TC
(t r uncat ion) bit is set t o a val ue of 1 when t he message is t r uncat ed because of excessive
l engt h. Ot her wise, t he TC bit is set t o 0. The RD (r ecur sion desir ed) bit is set t o 1 when
t he name ser ver is r equest ed t o per f or m a r ecur sive quer y. The RA (r ecur sion avail abl e)
bit is set t o 1 in a r esponse when t he name ser ver can per f or m r ecur sions.
The Z f iel d is 3 bit s l ong and is not used. The RCODE f iel d is 4 bit s l ong and can be set t o
one of t he val ues shown in Tabl e 11.4.
Tabl e 11.4. The DNS message header RCODE val ues.
RCODE Value Description
0 No er r or s
1 For mat er r or ; name ser ver unabl e t o int er pr et t he quer y
2 Name ser ver pr obl ems have occur r ed
3 The name ser ver coul d not f ind t he domain r ef er ence in t he quer y
4 Name ser ver does not suppor t t his t ype of quer y
5
Name ser ver cannot per f or m t he r equest ed oper at ion f or administ r at ive
r easons
615 Not used
The QDCOUNT f iel d is a 16-bit f iel d f or t he number of ent r ies in t he Quest ion sect ion.
The ANCOUNT f iel d is anot her 16-bit f iel d f or t he number of r epl ies in t he Answer
sect ion (t he number of r esour ce r ecor ds in t he answer ). The NSCOUNT f iel d is 16 bit s and
specif ies t he number of ser ver r esour ce r ecor ds in t he Aut hor it y sect ion of t he message.
The ARCOUNT 16-bit f iel d specif ies t he number of r esour ce r ecor ds in t he Addit ional
r ecor d sect ion.
The Quest ion sect ion of t he message has t hr ee f iel ds of it s own, as shown in Figur e 11.7.
The Quest ion f iel d car r ies t he quer y, which is ident if ied by t hese f iel ds. The QNAME
f iel d is t he domain name r equest ed. The QTYPE is t he t ype of quer y, using one of t he
val ues shown in Tabl e 11.1. The QCLASS is t he cl ass of quer y, which can be set accor ding
t o t he appl icat ions r equir ement s.
Figur e 11.7. The DNS message Quest ion f iel d f or mat .
The l ast t hr ee f iel ds in t he DNS message (Answer , Aut hor it y, and Addit ional
inf or mat ion) al l have t he same f or mat , as shown in Figur e 11.8. The Name f iel d hol ds t he
domain name of t he r esour ce r ecor d. The Type f iel d has any of t he val id r esour ce r ecor d
t ype val ues. (See Tabl e 11.1.)
Figur e 11.8. The f or mat f or DNS message Answer , Aut hor it y, and Addit ional
inf or mat ion f iel ds.
The Cl ass is t he cl ass of dat a in t he dat a f iel d. The Time t o Live (TTL) f iel d is t he number
of seconds t he inf or mat ion is val id wit hout an updat e. The RDLENGTH f iel d is t he
l engt h of t he inf or mat ion in t he dat a f iel d. Final l y, t he RDATA f iel d is t he r esour ce
r ecor d inf or mat ion or ot her dat a, depending on t he cl ass and t ype of t he quer y and
r epl y. Ther e can be many such r ecor ds in t he Answer , Aut hor it y, and Addit ional
inf or mat ion sect ions of t he DNS message.
The Name Resolver
As f ar as user appl icat ions ar e concer ned, r esol ving t he symbol ic names int o act ual
net wor k addr esses is easy. The pr ocess has been ment ioned ear l ier . The appl icat ion sends
a quer y t o a pr ocess cal l ed t he name resolver, or resolver (which somet imes r esides on
anot her machine). The name r esol ver might be abl e t o r esol ve t he name dir ect l y, in
which case it sends a r et ur n message t o t he appl icat ion. If t he r esol ver cannot
det er mine t he net wor k addr ess, it communicat es wit h t he name ser ver (which might
cont act anot her name ser ver ).
The r esol ver is int ended t o r epl ace exist ing name r esol ut ion syst ems on a machine, such
as UNIX's /et c/host s f il e. The r epl acement of t hese common mechanisms is t r anspar ent t o
t he user , al t hough t he administ r at or must know whet her t he nat ive name r esol ut ion
syst em or DNS is t o be used on each machine so t he cor r ect t abl es can be maint ained.
When t he r esol ver acquir es inf or mat ion f r om a name ser ver , it st or es t he ent r ies in it s
own cache t o r educe t he need f or mor e net wor k t r af f ic if t he same symbol ic name is used
again (as is of t en t he case wit h appl icat ions t hat wor k acr oss net wor ks). The amount of
t ime t he name r esol ver st or es t hese r ecor ds is dependent on t he Time t o Live f iel d in t he
r esour ce r ecor ds sent , or on a def aul t val ue set by t he syst em.
When a name ser ver cannot r esol ve a name, it can send back a message t o t he r esol ver
wit h t he addr ess of anot her name ser ver in t he Aut hor it y f iel d of t he message. The
r esol ver must t hen addr ess a message t o t he ot her name ser ver in t he hopes of r esol ving
t he name. The r esol ver can ask t he name ser ver t o conduct t he quer y it sel f by set t ing
t he RD (r ecur sive) bit in t he message. The name ser ver can r ef use or accept t he r equest .
The r esol ver uses bot h UDP and TCP in it s quer y pr ocess, al t hough UDP is mor e common,
due t o it s speed. However , it er at ive quer ies or t r ansf er s of l ar ge amount s of inf or mat ion
might r esor t t o TCP because of it s higher r el iabil it y.
Under t he UNIX oper at ing syst em, sever al dif f er ent impl ement at ions of t he name
r esol ver ar e in use. The r esol ver suppl ied wit h t he BSD ver sions of UNIX was
par t icul ar l y l imit ed, of f er ing neit her a cache nor it er at ive quer y capabil it ies. To sol ve
t hese l imit at ions, t he Ber kel ey Int er net Name Domain (BIND) ser ver was added. BIND
pr ovides bot h caching and it er at ive quer y capabil it ies in t hr ee dif f er ent modes: as a
pr imar y ser ver , as a secondar y ser ver , or as a caching-onl y ser ver (which doesn't have a
dat abase of it s own, onl y a cache). The use of BIND on BSD syst ems enabl es anot her
pr ocess t o t ake over t he wor kl oad of name r esol ut ion, a pr ocess t hat might be on
anot her machine ent ir el y.
Configuring a UNIX DNS Server
Conf igur ing a DNS ser ver r equir es sever al f il es and dat abases t o be modif ied or cr eat ed.
The pr ocess is t ime-consuming, but l uckil y has t o be done onl y once f or each ser ver . The
f il es invol ved in most DNS set ups, and t heir pur poses, ar e as f ol l ows:
named.host s: Def ines t he domain wit h host name-t o-IP mappings
named.r ev: Uses IN-ADDR-ARPA f or IP-t o-host name mappings
named.l ocal : Used t o r esol ve t he l oopback dr iver
named.ca: List s r oot domain ser ver s
named.boot : Used t o set f il e and dat abase l ocat ions
These f il enames ar e used by convent ion, but t hey can be changed t o suit your own
per sonal needs. The pr imar y f il e in t he l ist is named.boot , which is r ead when t he syst em
boot s up and def ines t he ot her f il es in t he set . Ther ef or e, any f il ename changes ar e
r ef l ect ed in named.boot . For simpl icit y, I use t he convent ional f il enames in t his chapt er .
Each of t he f il es l ist ed her e is a dat abase wit h ent r ies in t he f or m of a r esour ce r ecor d.
Entering the Resource Records
For t he sampl e ser ver conf igur at ion, I assume a UNIX oper at ing syst em using f air l y
st andar d names and net wor k l ayout s. DNS l et s you get ver y compl ex, but it 's easier t o
see what t he f il es and r esour ce r ecor ds ar e doing wit h a simpl e l ayout .
An SOA r esour ce r ecor d is pl aced in t he named.host s f il e. Semicol ons in t he r ecor d ar e
used f or comment s. This r esour ce r ecor d has been f or mat t ed as one f iel d per l ine t o make
it s ent r ies cl ear , al t hough t his is not necessar y. This r esour ce r ecor d def ines an upper
boundar y of t he t pci.com domain, wit h ser ver .t pci.com t he pr imar y name ser ver f or t he
domain, r oot .mer l in.t pci.com t he e-mail addr ess of t he per son r esponsibl e f or t he domain,
and t he r est of t he ent r ies ident if ied by comment s:
tpci.com. IN SOA server.tpci.com
root.merlin.tpci.com (
2 ; Serial number
7200 ; Refresh (2 hrs)
3600 ; Retry (1 hr)
151200 ; Expire (1 week)
86400 ); min TTL
Not e t hat t he inf or mat ion f r om t he ser ial number t o t he expir e f iel d is encl osed in
par ent heses. This is par t of t he command synt ax and must be incl uded t o indicat e t he
par amet er or der .
In addit ion t o t he SOA RR, t he named.host s f il e cont ains Addr ess r ecor ds. These r ecor ds
ar e used f or t he act ual mapping of a host name t o it s IP addr ess. A f ew Addr ess r esour ce
r ecor ds show t he f or mat of t hese ent r ies (r ef er t o ear l ier sect ions of t his chapt er f or
t he meanings of each f iel d if you ar e not sur e):
artemis IN A 143.23.25.7
merlin IN A 143.23.25.9
pepper IN A 143.23.25.72
The host names ar e not given as f ul l y qual if ied domain names because t he ser ver can
deduce t he f ul l name. If you want t o use t he f ul l domain name, you must f ol l ow t he
name wit h a per iod. The machines shown in t he pr eceding exampl e woul d be given l ike
t his using f ul l y qual if ied domain names:
artemis.tpci.com. IN A 143.23.25.7
merlin.tpci.com. IN A 143.23.25.9
pepper.tpci.com. IN A 143.23.25.72
The Point er (PTR) r esour ce r ecor d is used t o map an IP addr ess t o a name using IN-ADDR-
ARPA. A singl e PTR RR hel ps make t his cl ear . The r ecor d
7.0.120.147.in-addr.arpa IN PTR merlin
indicat es t hat t he machine named mer l in has t he IP addr ess 147.120.0.7.
The Name Ser ver r esour ce r ecor ds point t o t he name ser ver t hat has aut hor it y f or a
par t icul ar zone. Name Ser ver (NS) r ecor ds ar e used when a l ar ge net wor k has sever al
subnet wor ks, each wit h it s own name ser ver . An ent r y l ooks l ike t his:
tpci.com IN NS merlin.tpci.com
This r ecor d indicat es t hat t he DNS ser ver f or t he t pci.com domain is cal l ed
mer l in.t pci.com. If t her e wer e sever al subnet s used in t pci.com, t her e woul d be an NS RR
f or each subnet .
Completing the DNS Files
As you saw ear l ier , DNS uses sever al f il es t o hol d r esour ce r ecor ds descr ibing t he zones
used by DNS. The f ir st f il e of int er est is named.host s, which cont ains t he SOA, NS, and A
r esour ce r ecor ds. Al l ent r ies in t he named.host s f il e must begin in t he f ir st char act er
posit ion of each l ine. Her e's a sampl e named.host s f il e wit h comment s added t o show t he
r ecor ds:
; named.hosts files
; Start Of Authority RR
tpci.com. IN SOA merlin.tpci.com
root.merlin.tpci.com (
2 ; Serial number
7200 ; Refresh (2 hrs)
3600 ; Retry (1 hr)
151200 ; Expire (1 week)
86400 ); min TTL
;
; Name Service RRs
tpci.com IN NS merlin.tpci.com
subnet1.tpci.com IN NS goofy.subnet1.tpci.com
;
; Address RRs
artemis IN A 143.23.25.7
merlin IN A 143.23.25.9
windsor IN A 143.23.25.12
reverie IN A 143.23.25.23
bigcat IN A 143.23.25.43
pepper IN A 143.23.25.72
The f ir st sect ion set s t he SOA r ecor d, which def ines t he par amet er s f or TTL, expir y,
r ef r esh, and so on. It set s t he name ser ver f or t he t pci.com domain t o mer l in.t pci.com. The
second sect ion uses t he NS r esour ce r ecor ds t o def ine t he name ser ver f or t he t pci.com
domain as mer l in.t pci.com (t he same as t he SOA) and a subnet of t pci cal l ed subnet 1, f or
which t he name ser ver is goof y.subnet 1.t pci.com. The t hir d sect ion has a l ist of t he
addr ess-r ecor d-name-t o-IP-addr ess mapping. Ther e is an ent r y in t his sect ion f or each
machine on t he net wor k.
The named.r ev f il e pr ovides t he r ever se mapping of IP addr ess t o machine name and is
composed of Point er r esour ce r ecor ds. The same f or mat as t he named.host s f il e is
f ol l owed, except f or t he swapping of name and IP addr ess and t he conver sion of t he IP
addr ess t o IN-ADDR-ARPA st yl e. The equival ent named.r ev f il e f or t he named.host s f il e
shown ear l ier l ooks l ike t his:
; named.rev files
; Start Of Authority RR
23.143.in-addr.arpa IN SOA merlin.tpci.com
root.merlin.tpci.com (
2 ; Serial number
7200 ; Refresh (2 hrs)
3600 ; Retry (1 hr)
151200 ; Expire (1 week)
86400 ); min TTL
;
; Name Service RRs
23.143.in-addr.arpa IN NS merlin.tpci.com
100.23.143.in-addr.arpa IN NS goofy.subnet1.tpci.com
;
; Address RRs
9.25.23.143.in-addr.arpa IN PTR merlin
12.25.23.143.in-addr.arpa IN PTR windsor
23.25.23.143.in-addr.arpa IN PTR reverie
43.25.23.143.in-addr.arpa IN PTR bigcat
72.25.23.143.in-addr.arpa IN PTR pepper
Ther e must be a separ at e named.r ev f il e f or each zone or subdomain on t he net wor k.
These f il es can have dif f er ent names or be pl aced in dif f er ent dir ect or ies. If you have
onl y a singl e zone, one named.r ev f il e is al l t hat 's needed.
The named.l ocal f il e cont ains an ent r y f or t he l oopback dr iver (which al ways has t he IP
addr ess 127.0.0.1). This f il e must cont ain inf or mat ion about t he IN-ADDR-ARPA mapping
of t he l oopback dr iver , as wel l as a domain again (because t he named.r ev f il e doesn't
cover t he 127 subnet ). A named.l ocal f il e l ooks l ike t his:
; named.local files
; Start Of Authority RR
0.0.127.in-addr.arpa IN SOA merlin.tpci.com
root.merlin.tpci.com (
2 ; Serial number
7200 ; Refresh (2 hrs)
3600 ; Retry (1 hr)
151200 ; Expire (1 week)
86400 ); min TTL
;
; Name Service RR
0.0.127.in-addr.arpa IN NS merlin.tpci.com
;
; Address RR
1.0.0.127.in-addr.arpa IN PTR localhost
This f il e t hen pr ovides t he mapping f r om t he machine named l ocal host t o t he IP addr ess
127.0.0.1.
The named.ca f il e is used t o specif y name ser ver s t hat t he syst em can r esor t t o. The
machines specif ied in t he named.ca f il e shoul d be st abl e and not subject t o r apid change.
A sampl e named.ca f il e l ooks l ike t his:
; named.ca
; servers for the root domain
;
. 99999999 IN NS ns.nic.ddn.mil.
99999999 IN NS ns.nasa.gov.
99999999 IN NS ns.internic.net
; servers by address
;
ns.nic.ddn.mil 99999999 IN A 192.112.36.4
ns.nasa.gov 99999999 IN A 192.52.195.10
ns.internic.net 99999999 IN A 198.41.0.4
In t his f il e onl y t hr ee DNS ser ver s have been specif ied. A nor mal named.ca f il e can have
a dozen or so name ser ver s, depending on t heir pr oximit y t o your syst em. You can get a
f ul l l ist of val id r oot domain name ser ver s t hr ough anonymous FTP t o nic.ddn.mil , in
t he f il e /net inf o/r oot -ser ver s.t xt . This f il e can be past ed int o named.ca. The ser ver s
specif ied in t he named.ca f il e ar e each ident if ied by t wo ent r ies. One gives t he r oot
domain (t he per iod) f ol l owed by t he name ser ver name; t he ot her has t he name ser ver IP
addr ess. The Time t o Live f iel d is set ver y l ar ge because t hese ser ver s ar e expect ed t o be
al ways avail abl e.
The named.boot f il e is used t o t r igger t he l oading of t he DNS daemons and t o specif y t he
pr imar y and secondar y name ser ver s on t he net wor k. A sampl e named.boot f il e l ooks l ike
t his:
; named.boot
directory /usr/lib/named
primary tpci.com named.hosts
primary 25.143.in-addr.arpa named.rev
primary 0.0.127.in-addr.arpa named.local
cache . named.ca
The f ir st l ine of t he named.boot f il e has t he keywor d dir ect or y f ol l owed by t he
dir ect or y of t he DNS conf igur at ion f il es. Each f ol l owing l ine wit h t he keywor d pr imar y
t el l s DNS t he f il es t hat it shoul d use t o f ind conf igur at ion inf or mat ion. The f ir st l ine,
f or exampl e, set s named.host s as t he f il e f or l ocat ing t he pr imar y ser ver of t pci.com. The
IN-ADDR-ARPA inf or mat ion is kept in t he f il e named.r ev f or t he 143.25 subnet . The
l ocal host inf or mat ion is in named.l ocal , and f inal l y t he ser ver and name cache
inf or mat ion ar e in named.ca.
A secondar y name ser ver is conf igur ed onl y sl ight l y dif f er ent l y t han a pr imar y ser ver .
The dif f er ence is in t he named.boot f il e, which point s back t o t he pr imar y ser ver .
Starting the DNS Daemons
The f inal st ep in t he DNS conf igur at ion is t o ensur e t hat t he DNS daemon cal l ed named
is l oaded when t he UNIX syst em boot s. This is usual l y done t hr ough t he r c st ar t up
scr ipt s. Most ver sions of UNIX have t he r out ines f or DNS st ar t up al r eady ent er ed in t he
st ar t up scr ipt , usual l y in t he f or m of a check f or t he f il e named.boot . If named.boot
exist s, t he DNS daemon named st ar t s. The code usual l y l ooks l ike t his:
# Run DNS server if named.boot exists
if [ -f /etc/inet/named.boot -a -x /usr/sbin/in.named ]
then
/usr/sbin/in.named
fi
The exact dir ect or y pat hs and opt ions might be dif f er ent in your r c scr ipt , but t he
command shoul d check f or t he named.boot f il e and st ar t named if it exist s.
Configuring a Client
Conf igur ing a UNIX machine t o use a pr imar y DNS ser ver f or r esol ut ion is a quick
pr ocess. Fir st , t he /et c/r esol v.conf f il e is modif ied t o incl ude t he pr imar y ser ver 's addr ess.
For exampl e, a r esol v.conf f il e might l ook l ike t his:
domain tpci.com
nameserver 143.25.0.1
nameserver 143.25.0.2
The f ir st l ine est abl ishes t he domain name, which is f ol l owed by t he IP addr esses of
avail abl e name ser ver s. This f il e point s t o t wo name ser ver s on t he 143.25 subnet .
BOOTP Protocol
TCP/IP needs t o know an Int er net addr ess bef or e it can communicat e wit h ot her
machines. This can cause a pr obl em when a machine is init ial l y l oaded or has no
dedicat ed disk dr ive of it s own. On Day 2, "TCP/IP and t he Int er net ," you saw how
Rever se Addr ess Resol ut ion Pr ot ocol (RARP) can be used t o det er mine an IP addr ess, but
an al t er nat ive is in common use: t he bootstrap protocol or BOOTP. BOOTP uses UDP t o
enabl e a diskl ess machine t o det er mine it s IP addr ess wit hout using RARP.
Diskl ess machines usual l y cont ain st ar t -up inf or mat ion in t heir PROMs. Because t hese
must be kept smal l and consist ent bet ween many model s of diskl ess wor kst at ions t o
r educe cost s, it is impossibl e t o pack a compl et e pr ot ocol such as TCP/IP int o a chip. It is
al so impossibl e t o embed an IP addr ess, because t he chip can be used in many dif f er ent
machines on t he same net wor k. This f or ces a newl y boot ed diskl ess wor kst at ion t o
det er mine it s own IP addr ess f r om t he ot her machines on t he net wor k. (In pr act ice, t he
diskl ess machine al so must det er mine t he IP addr ess of t he net wor k ser ver it wil l use, as
wel l as t he addr ess of t he near est IP gat eway.)
BOOTP over comes a f ew of RARP's pr obl ems. RARP r equir es dir ect access t o t he net wor k
har dwar e, which can cause pr obl ems when deal ing wit h ser ver s. Al so, RARP suppl ies
onl y an IP addr ess. When l ar ge packet s must be sent , t his wast es a l ot of space t hat
coul d be used f or usef ul inf or mat ion. BOOTP was devel oped t o use UDP and can be
impl ement ed wit hin an appl icat ion pr ogr am. BOOTP al so r equir es onl y a singl e packet of
inf or mat ion t o pr ovide al l t he inf or mat ion a new diskl ess wor kst at ion r equir es t o begin
oper at ion. Ther ef or e, BOOTP is mor e ef f icient and easier t o devel op appl icat ions f or ,
making it popul ar .
To det er mine a diskl ess wor kst at ion's IP addr ess, BOOTP uses t he br oadcast capabil it ies
of IP. (You might r ecal l t hat IP enabl es sever al special net wor k addr esses t hat ar e
br oadcast t o al l machines on t he net wor k.) This l et s t he wor kst at ion send a message
even when it doesn't know t he dest inat ion machine's addr ess or even it s own.
IP br oadcast addr esses such as 255.255.255.255 enabl e a
message t o be sent t o al l machines on a net wor k despit e having
no sour ce or dest inat ion net wor k addr ess.
BOOTP put s al l t he communicat ions t asks on t he diskl ess wor kst at ion. It specif ies t hat
al l UDP messages sent over t he net wor k use checksums and t hat t he Do Not Fr agment
bit be set . This t ends t o r educe t he number of l ost , misint er pr et ed, or dupl icat ed
dat agr ams.
To handl e t he l oss of a message, BOOTP uses a simpl e set of t imer s. When a message has
been sent , a t imer st ar t s. If no r epl y has been r eceived when t he t imer r uns out , t he
message is r esent . The pr ot ocol st ipul at es t hat t he t imer is set t o a r andom val ue, which
incr eases each t ime t he t imer expir es unt il it r eaches a maximum val ue, af t er which it is
r andomized again. This pr event s massive t r af f ic af t er sever al machines f ail at once and
t r y t o br oadcast BOOTP messages at t he same t ime.
BOOTP uses t he t er ms client and server t o r ef er t o machines. The cl ient is t he machine
t hat init iat es a quer y, and t he ser ver is t he machine t hat r epl ies t o t hat quer y. Fr om
t hese def init ions, it is easy t o see t hat cl ient and ser ver have no physical r el at ion t o
any wor kst at ion, because t he r ol e of each wor kst at ion can change wit h message t r af f ic.
Because most syst ems can handl e mul t ipl e t r af f ic t hr eads at a t ime, it is possibl e f or a
machine t o be bot h a cl ient and a ser ver simul t aneousl y.
When consider ing cl ient /ser ver r ol es in BOOTP, r emember
t hat t he machine t hat sends t he f ir st message is t he cl ient and
t he machine t hat r epl ies is t he ser ver . Ther e is no r el at ionship
t o cl ient /ser ver ar chit ect ur e t er ms.
BOOTP Messages
BOOTP messages ar e kept in f ixed f or mat s f or simpl icit y and t o enabl e t he BOOTP
sof t war e t o f it in a smal l space wit hin a PROM. The f or mat of BOOTP messages is shown
in Figur e 11.9. The OpCode f iel d is used t o signal eit her a r equest (set t o a val ue of 1) or
a r epl y (set t o a val ue of 2). The HTYPE f iel d indicat es t he net wor k har dwar e t ype. The
HLEN f iel d indicat es t he l engt h of a har dwar e addr ess. (These l ast t wo f iel ds ar e t he
same as in ARP.)
Figur e 11.9. The BOOTP message f or mat .
The HOPS f iel d keeps t r ack of t he number of t imes t he message is f or war ded. When t he
cl ient sends t he r equest message, a val ue of 0 is put in t he HOPS f iel d. If t he ser ver
decides t o f or war d t he message t o anot her machine, it incr ement s t he HOPS count .
(For war ding is necessar y when boot st r apping a machine acr oss mor e t han one gat eway.)
The Tr ansact ion Number f iel d is an int eger assigned by t he cl ient t o t he message and is
unchanged f r om r equest t o r epl y. This enabl es mat ching t he r epl ies t o t he cor r ect
r equest . The Seconds f iel d is t he number of seconds t he cl ient has been boot ed, assigned
by t he cl ient when t he message is sent .
The Cl ient IP Addr ess f iel d is f il l ed in as much as possibl e by t he cl ient . This might
r esul t in a par t ial net wor k addr ess or no inf or mat ion at al l , depending on t he cl ient 's
knowl edge of t he net wor k it is in. Any inf or mat ion t hat is unknown is set t o 0 (so t he
f iel d might be 0.0.0.0 if not hing is known about t he net wor k addr ess). If t he cl ient want s
inf or mat ion f r om a par t icul ar ser ver , it can put t he addr ess of t he ser ver in t he Ser ver
IP Addr ess f iel d. Simil ar l y, if t he cl ient knows t he ser ver 's name, it put s it in t he Ser ver
Host Name f iel d. The same appl ies f or t he ot her addr ess f iel ds. If t he f iel ds ar e set t o 0,
any ser ver can r espond. If a specif ic ser ver or gat eway is given, onl y t hat machine
r esponds t o t he message.
The Vendor -Specif ic f iel d is used, as t he name suggest s, f or impl ement at ion inf or mat ion
t hat is specif ic t o each vendor . This f iel d is opt ional . The f ir st 32 bit s def ine t he f or mat
of t he r emaining inf or mat ion. These f ir st bit s ar e known as t he magic cookie and have a
st andar d val ue of 99.120.83.99. Fol l owing t he magic cookie ar e set s of inf or mat ion in a
t hr ee-f iel d f or mat : a t ype, a l engt h, and a val ue. Ther e ar e sever al t ypes ident if ied by
t he Int er net RFC, as shown in Tabl e 11.5. The Lengt h f iel d is not used f or t ypes 0 and
255, but it must be pr esent f or t ypes 1 and 2. The l engt h can var y depending on t he
number of ent r ies in t he ot her t ypes of messages.
Tabl e 11.5. BOOTP vendor -specif ic t ypes.
Type Code Length Description
Padding 0 -- Used onl y f or padding messages
Subnet Mask 1 4 Subnet mask f or l ocal net wor k
Time of Day 2 4 Time of Day
Gat eways 3 Number of ent r ies IP addr esses of gat eways
Time Ser ver s 4 Number of ent r ies IP addr esses of t ime ser ver s
IEN116 Ser ver 5 Number of ent r ies IP addr esses of IEN116 ser ver s
DomainName Ser ver 6 Number of ent r ies IP addr esses of Domain Name Ser ver s
Log Ser ver 7 Number of ent r ies IP addr esses of l og ser ver s
Quot e Ser ver 8 Number of ent r ies IP addr esses of quot e ser ver s
LPR Ser ver s 9 Number of ent r ies IP addr esses of l pr ser ver s
Impr ess 10 Number of ent r ies IP addr esses of impr ess ser ver s
RLP Ser ver 11 Number of ent r ies IP addr esses of RLP ser ver s
Host name 12 Number of byt es Cl ient host name in host name
Boot size 13 2 Int eger size of boot f il e
Unused 128254 -- Not used
End 255 -- End of l ist
You might r emember t hat a machine can obt ain t he subnet mask f r om an ICMP message,
but BOOTP is t he r ecommended met hod of obt aining t his val ue.
The Boot Fil ename f iel d can specif y a f il ename f r om which t o obt ain a memor y image
t hat enabl es t he diskl ess wor kst at ion t o boot pr oper l y. This might be vendor -set or
suppl ied by t he ser ver . This enabl es t he memor y image t o be obt ained f r om one machine
whil e t he act ual addr esses ar e obt ained f r om anot her . If t his f iel d is set t o 0, t he ser ver
sel ect s t he memor y image t o send.
The pr ocess of boot ing f ol l ows t wo st eps. The f ir st is t o use BOOTP t o obt ain
inf or mat ion about t he net wor k addr esses of t he cl ient and at l east one ot her machine
(a gat eway or ser ver ). The second st ep uses a dif f er ent pr ot ocol t o obt ain a memor y
image f or t he cl ient .
A t wo-st ep pr ocess using t wo dif f er ent pr ot ocol s is used t o
separ at e t he conf igur at ion and oper at ing syst em l oad of t he
machine. The use of t wo pr ot ocol s enabl es opt imizat ion f or each
t ask. Two st eps ar e al so used because t he machine t hat r epl ies
t o t he BOOTP cl ient message might not be t he machine t hat
downl oads t he memor y image.
Network Time Protocol (NTP)
Timing is ver y impor t ant t o net wor ks, not onl y t o ensur e t hat int er nal t imer s ar e
maint ained pr oper l y, but al so f or synchr onizat ion of cl ocks f or sending messages and
t imest amps wit hin t hose messages. Some syst ems r el y on t ime f or r out ing. Ensur ing t hat
t ime cl ocks ar e consist ent and accur at e is a t ask of t en over l ooked, but it r emains
impor t ant enough t o have a f or mal pr ocedur e def ined by an Int er net RFC. The pr ot ocol
t hat maint ains t ime st andar ds is cal l ed t he Net wor k Time Pr ot ocol , or NTP. NTP can use
eit her TCP or UDP; por t 37 is dedicat ed t o it .
The oper at ion of NTP r el ies on obt aining an accur at e t ime f r om a quer y t o a pr imar y
t ime ser ver , which it sel f get s it s t iming inf or mat ion f r om a st andar d t ime sour ce (such as
t he Nat ional Inst it ut e of St andar ds and Technol ogy in t he U.S.). The t ime ser ver
quer ies t he st andar d cl ock (al so cal l ed a master clocking source) and set s it s own t imes t o
t he st andar d.
Once t he pr imar y t ime ser ver has an accur at e t ime, it sends NTP messages t o secondar y
t ime ser ver s f ur t her out on t he int er net wor k. Secondar y t ime ser ver s can communicat e
wit h mor e secondar y t ime ser ver s using NTP, al t hough accur acy is l ost wit h each
communicat ion due t o l at ency in t he net wor ks. Event ual l y, t hese t ime messages can be
sent t o gat eways and individual machines wit hin a net wor k, if t he administ r at or so
decides. Usual l y each net wor k has at l east one pr imar y t ime ser ver and one secondar y
ser ver , al t hough l ar ge net wor ks might have sever al of each.
The f or mat of NTP messages is simpl e, as shown in Figur e 11.10. Sever al cont r ol f iel ds ar e
used f or synchr onizat ion and updat ing pr ocedur es, but t he det ail s of t hese f iel ds ar e
not impor t ant t o t his discussion. The Sync Dist ance t o Pr imar y f iel d is an est imat e of t he
r ound-t r ip del ay incur r ed t o t he pr imar y cl ock. The ID of t he pr imar y t ime ser ver is t he
addr ess of t he pr imar y.
Figur e 11.10. The NTP message f or mat .
Ther e ar e sever al t imest amps in t he NTP message. The Time Local Cl ock Updat ed is t he
t ime t he message or iginat or 's l ocal cl ock was updat ed. The Or iginat e t imest amp is t he
t ime t he message was sent . The Receive t imest amp is t he t ime it was r eceived. The
Tr ansmit t imest amp is t he t ime t he message was t r ansmit t ed af t er r ecept ion.
Al l t imest amps ar e cal cul at ed f r om an of f set of t he number of seconds since Januar y 1,
1900. The t imest amp f iel ds ar e 64 bit s, t he f ir st 32 bit s f or a whol e number and t he l ast 32
f or a f r act ion. The f inal Aut hent icat ion f iel d is opt ional and can be used t o
aut hent icat e t he message.
Summary
You have now seen how t he Domain Name Ser vice wor ks. DNS is an int egr al and
impor t ant par t of most TCP/IP inst al l at ions, enabl ing symbol ic names t o be r esol ved
pr oper l y acr oss net wor ks. The use of name ser ver s was expl ained, as wel l as t he manner
in which r ecor ds ar e st or ed wit hin t he ser ver s. Associat ed wit h DNS is t he ARP and IN-
ADDR-ARPA name r esol ut ion pr ocess.
Today I al so l ooked at t he BOOTP pr ot ocol , necessar y t o enabl e many diskl ess t er minal s
and wor kst at ions t o connect t o t he net wor k and l oad t heir oper at ing syst em. Wit hout
BOOTP, you woul d al l need f ul l -f eat ur ed comput er s or wor kst at ions.
Q&A
What ar e t he t op-l evel domain names and what ar e t heir pur poses?
The t op l evel domains ar e .ar pa (Int er net -specif ic), .com (commer cial ), .edu (educat ional
inst it ut ions), .gov (gover nment al ), .mil (mil it ar y), and .or g (non-commer cial
or ganizat ions).
What does a DNS name ser ver do?
The DNS name ser ver manages a zone of machines and pr ovides name r esol ut ion f or al l
machines wit hin t hat zone.
If a name ser ver cannot r esol ve a name using it s own t abl es, what happens?
Quer ies can be sent f r om t he machine r eceiving t he quer y t o ot her name ser ver s t o
sear ch f or a r esol ut ion. If anot her machine does have t he answer , it is not r et ur ned t o
t he inquir ing machine, however . Onl y t he addr ess of t he name r esol ver wit h t he answer
is r et ur ned. The inquir ing machine must t hen send a specif ic quer y t o t he r esol ver wit h
t he answer .
What is t he advant age of t he IN-ADDR-ARPA f or mat ?
IN-ADDR-ARPA enabl es a mapping f r om t he IP addr ess t o t he symbol ic host name.
Somet imes t his is a f ast way t o obt ain t he symbol ic name of a dest inat ion machine.
Why does BOOTP use UDP?
Simpl y because it is smal l er t o code. To embed TCP code in a PROM woul d t ake much mor e
r oom t han t he simpl e code needed f or UDP.
Quiz
1. What pr ot ocol is used by DNS name ser ver s? Why is t hat a good choice?
2. What is a DNS r esour ce r ecor d?
3. Show a sampl e ent r y in an IN-ADDR-ARPA f il e and expl ain what t he f iel ds mean.
4. BOOTP hel ps a diskl ess wor kst at ion boot . How does it get a message t o t he
net wor k l ooking f or it s IP addr ess and t he l ocat ion of it s oper at ing syst em boot
f il es?
5. What is t he Net wor k Time Pr ot ocol ? Why is it used?


I Net wor k Fil e Syst em (NFS)
I NFS Pr ot ocol s
I Remot e Pr ocedur e Cal l (RPC)
I Por t Mapper
I Ext er nal Dat a Repr esent at ion (XDR)
I Net wor k Fil e Syst em Pr ot ocol
I Mount Pr ot ocol
I Fil e Locking
I Remot e Execut ion Ser vice (REX)
I r user s and spr ay
I Conf igur ing NFS
I Conf igur ing UNIX as an NFS Ser ver
I Set t ing Up a UNIX NFS Cl ient
I Set t ing Up Windows-Based NFS
I Shar ing a Windows Dir ect or y
I Net wor k Inf or mat ion Ser vice (NIS)
I Conf igur ing NIS
I Set t ing Up t he NIS Domain
I NIS Daemons
I Set t ing Up an NIS Mast er
I Set t ing Up NIS Sl aves
I Set t ing Up NIS Cl ient s
I RPC and NFS Administ r at ion
I r pcinf o
I nf sst at
I Summar y
I Q&A
I Quiz
12
Network File System and Network
Information Service
Today I l ook at t he Net wor k Fil e Syst em (NFS), a set of pr ot ocol s and pr oduct s in wide
use wit h TCP/IP-based net wor ks. NFS is especial l y popul ar wit h UNIX net wor ks, but it is
now avail abl e f or many pl at f or ms and wor ks wel l acr oss a l ocal ar ea net wor k. I al so
l ook at sever al pr ot ocol s t hat ar e cl osel y associat ed wit h NFS, such as Net wor k
Inf or mat ion Ser vice (NIS), and t he Remot e Execut ion Ser vice (REX).
Today's t ext concent r at es on t he UNIX ver sions of t hese pr ot ocol s, simpl y because t hey
ser ve as an excel l ent il l ust r at ion. For ot her oper at ing syst ems, names of f il es and
pr ocedur es might change, but t he f undament al s ar e compat ibl e. I show some exampl es of
using PC machines f or NFS and NIS as appr opr iat e.
Network File System (NFS)
The move t o dist r ibut ed pr ocessing and cl ient /ser ver ar chit ect ur es has meant t hat many
user s have smal l , power f ul machines on t heir desk t hat communicat e wit h a l ar ger
ser ver somewher e on a net wor k. The appl icat ions t he user needs ar e of t en l ocat ed in
pl aces ot her t han on t heir deskt op, so some met hod of accessing r emot e f il es
(appl icat ions and dat a) is r equir ed. Al t hough bot h Tel net and r l ogin enabl e a user t o
use a r emot e machine, neit her syst em t akes advant age of t he user 's deskt op machine.
Per ipher al shar ing has al so become impor t ant as l ocal ar ea net wor ks gr ow. To hel p
int egr at e wor kst at ions int o l ocal ar ea net wor ks, as wel l as t o simpl if y r emot e f il e
access and per ipher al shar ing, Sun Micr osyst ems int r oduced t he Net wor k Fil e Syst em
(NFS).
Sun designed NFS so t hat it woul d enabl e machines f r om dif f er ent vendor s t o wor k
t oget her , even if t hey used dif f er ent oper at ing syst ems. Sun publ ished t he NFS
specif icat ions, enabl ing ot her vendor s t o adopt t heir own har dwar e and sof t war e t o
wor k smoot hl y wit h NFS. This r esul t s in a compl et el y homogeneous net wor k. Since Sun's
int r oduct ion, NFS has become a de f act o st andar d among UNIX envir onment s, wit h
st r ong suppor t in ot her oper at ing syst ems, as wel l .
NFS act ual l y r ef er s t o bot h a pr oduct and a pr ot ocol . Ther e is an NFS pr oduct t hat
consist s of a set of pr ot ocol s f or dif f er ent t asks (t hese ar e examined in t he sect ion
t it l ed "NFS Pr ot ocol s"). The NFS pr ot ocol is t he one pr ot ocol of t he NFS pr oduct t hat
deal s wit h f il e access. To avoid conf usion, you shoul d t hink of t he NFS pr ot ocol
specif ical l y (inst ead of t he ent ir e pr oduct set ) when NFS is ment ioned t oday.
NFS is now int imat el y t ied wit h UNIX, and it is shipped as par t of t he Syst em V Rel ease 4
sof t war e ver sion. It is al so t ied t o TCP/IP, which r emains t he communicat ions pr ot ocol of
choice f or UNIX net wor ks. For ot her oper at ing syst ems, NFS is usual l y an ext ension
t hat is added at t he syst em administ r at or 's opt ion. UNIX syst ems use t he pr ocess nf sd t o
manage NFS access, wit h t he pr ocess st ar t ed aut omat ical l y when t he UNIX syst em boot s
af t er NFS has been pr oper l y conf igur ed.
NFS enabl es an appl icat ion t o r ead and wr it e f il es t hat r eside on NFS ser ver s, wit h t he
access t o t he NFS ser ver compl et el y t r anspar ent t o t he appl icat ion and t he user . For
devel oper s, NFS r equir es no ext r a coding or special handl ing, which makes it especial l y
at t r act ive. This t r anspar ent access t o anot her machine's f il e st r uct ur e is achieved by
l ogical l y at t aching t he NFS ser ver t o t he cl ient , a pr ocess cal l ed mounting.
The NFS ser ver 's f il e syst em can be at t ached as a whol e, or just a por t ion of it can be
mount ed. The dir ect or y at which t he mount occur s is cal l ed t he mount point. The concept
of shar ed f il es simil ar t o t hat encount er ed wit h NFS is somet imes cal l ed a distributed file
system, al t hough t his is a misnomer wit h NFS.
UNIX has had t he capabil it y t o mount or at t ach anot her
f il e syst em f or a l ong t ime. This t ype of mount ing can occur
acr oss net wor ks and is t r anspar ent t o t he appl icat ion and user ,
as l ong as f il enames t ake int o account t he f ul l pat h name of
t he mount ed f il e syst em. The NFS mount is simil ar t o t he UNIX
mount pr ocess.
NFS uses t he t er m client t o r epr esent any machine t hat r equest s a f il e f r om anot her
machine, which is t he server. Mul t it asking oper at ing syst ems can act as bot h cl ient and
ser ver simul t aneousl y, wit h pr ocesses on t he machine accessing f il es on anot her machine
whil e ot her s on t he net wor k access it s own har d disk. Usual l y, r est r ict ions ar e imposed
as t o t he f il es or por t ions of a f il e syst em t hat can be shar ed, bot h f or secur it y and speed
consider at ions. Typical NFS inst al l at ions use per sonal comput er s or diskl ess
wor kst at ions as cl ient s accessing a mor e power f ul ser ver syst em. Because per sonal
comput er oper at ing syst ems such as MS-DOS ar e singl e-t asking, PCs usual l y act onl y as
cl ient s, unl ess t hey r un a mul t it asking oper at ing syst em such as Windows NT or OS/2. It
is possibl e t o have an ent ir e net wor k of mul t it asking comput er s shar ing t heir dr ives
wit h each ot her , al t hough in pr act ice t his wor ks wel l onl y f or smal l net wor ks because
of t he high densit y of net wor k t r af f ic r equir ed t o suppor t al l t he mount ed f il esyst ems.
Because of t he need t o t r ansf er f il es quickl y, net wor k speed becomes vit al l y impor t ant .
When it was designed, t he or iginal goal f or an NFS-mount ed f il e syst em was t o pr ovide
per f or mance equival ent t o 80 per cent of t he per f or mance expect ed f r om a l ocal l y
mount ed har d disk. This put s t he per f or mance emphasis on bot h t he NFS disk dr ive and
t he net wor k syst em. Typical l y, NFS disk dr ives ar e among t he f ast est avail abl e,
specif ical l y t o r educe bot t l enecks at t he dr ive end. The net wor k har dwar e and
sof t war e must be chosen t o enabl e t he f ast est possibl e t hr oughput .
Because NFS is UNIX-based, t he secur it y of f er ed is r udiment ar y. For t his r eason, Sun has
int r oduced Secur e NFS, which impl ement s an encr ypt ed messaging pr ot ocol f or added
pr ot ect ion against unaut hor ized access t o NFS-mount ed f il e syst ems.
NFS Protocols
The NFS pr oduct compr ises sever al pr ot ocol s, onl y one of which is cal l ed t he NFS
pr ot ocol . The NFS pr oduct pr ot ocol s ar e designed as a set of l ayer s, simil ar t o t he OSI
model . The l ayer s of t he NFS pr oduct ar e compar ed t o t he OSI l ayer s in Figur e 12.1. Each
pr ot ocol in t he NFS pr oduct has an Int er net RFC dedicat ed t o it s specif icat ion.
Figur e 12.1. NFS pr ot ocol l ayer s.
The NFS pr oduct is based on t he OSI l ayer ed model , r esul t ing in pr ot ocol s t hat ar e
independent (in t heor y, at l east ) f r om each ot her and pr ot ocol s in dif f er ent l ayer s. The
design phil osophy is t hat any singl e-l ayer pr ot ocol coul d be r epl aced wit h any ot her
one, assuming t he f unct ional it y of t he pr ot ocol was t he same. To dat e t her e ar e no
common al t er nat ives f or t he t wo l ower -l ayer pr oduct s, RPC and XDR, al t hough t her e
ar e sever al f or t he t op l ayer .
The sour ce code f or bot h t he Remot e Pr ocedur e Cal l
(RPC) and Ext er nal Dat a Repr esent at ion (XDR) pr ot ocol s is
avail abl e f r ee of char ge f r om Sun Micr osyst ems.
Figur e 12.1 int r oduces t he RPC (Remot e Pr ocedur e Cal l ) and XDR (Ext er nal Dat a
Repr esent at ion) pr ot ocol s t hat I l ook at now in mor e det ail .
Remote Procedure Call (RPC)
The Remot e Pr ocedur e Cal l (RPC) pr ot ocol act s as t he session l ayer and as t he message
exchanger f or al l NFS-based appl icat ions. RPC is composed of a set of pr ocedur es t hat
can be incor por at ed int o high-l evel appl icat ions t o handl e any r equir ed net wor k access.
The r emot e pr ocedur es ar e no mor e compl icat ed t o use t han l ocal pr ocedur es.
RPC was special l y devel oped f or NFS but has since f ound
use in ot her pr ot ocol suit es. The pr incipl es cover ed her e appl y
t o t hose RPC pr oduct s, as wel l .
Appl icat ion devel oper s can cr eat e t heir own RPC pr ocedur es bet ween a cl ient (t he one
t hat issues t he r equest ) and a ser ver (t he one t hat pr ocesses t he r equest ). A gr oup of
pr ocedur es is cal l ed a service. Each ser ver can use onl y one ser vice, so each ser vice is
assigned a program number t o ident if y it sel f t o bot h t he cl ient and t he ser ver .
RPC f unct ions over t he net wor k bet ween a cl ient and a ser ver . The pr ocess f ol l owed by
an RPC is shown in Figur e 12.2. It begins wit h t he act ivat ion of t he pr ocedur e by t he
cl ient , f r om which a r equest message is sent t o t he ser ver . Af t er r eceiving t he message
and ext r act ing t he r equest , t he ser ver execut es t he r equest ed pr ocedur e and assembl es
a r esponse message wit h t he r esul t s. Upon r eceipt of t he r epl y, t he cl ient disassembl es
t he message and cont inues wit h t he appl icat ion's nor mal execut ion. Ever y st ep of t he
pr ocedur e is cont r ol l ed by r out ines wit hin t he RPC l ibr ar y (which is l inked int o t he
appl icat ions).
Figur e 12.2. The execut ion of an RPC.
RPC messages can be sent using eit her TCP or UDP (or f or t hat mat t er , any ot her
pr ot ocol t hat pr ovides t he same f unct ional it y). Typical l y, RPC is used wit h UDP because
a connect ion-based pr ot ocol is not necessar y and UDP is usual l y f ast er . However , UDP
does impose a maximum packet size, which can cause some pr obl ems wit h pr ocedur es. Al so,
UDP does not guar ant ee del iver y, so an appl icat ion t hat uses UDP must handl e
r el iabil it y issues (usual l y wit h a r et r ansmission t imer ).
The use of TCP of f er s t he capabil it y not onl y t o ignor e r el iabil it y concer ns (l eaving
t hat t o t he TCP sof t war e), but al so t o bat ch r equest s. Wit h a bat ch connect ion, t he
cl ient and ser ver agr ee t hat t he cl ient can send sever al RPC r equest s one af t er
anot her wit hout wait ing f or acknowl edgment or a r epl y t o each. This can be a usef ul
f eat ur e wit h some appl icat ions.
The RPC pr ot ocol is used t o send r equest s and r epl ies. The f or mat of t he RPC pr ot ocol
packet header is shown in Figur e 12.3, wit h al l f iel ds coded in t he Ext er nal Dat a
Repr esent at ion (XDR) f or mat (see t he sect ion t it l ed "Ext er nal Dat a Repr esent at ion
(XDR)" l at er t oday). The Tr ansact ion ID f iel d is used t o mat ch r equest s and r epl ies and
is changed (usual l y incr ement ed) by t he cl ient wit h each new r equest . The Dir ect ion
Indicat or f iel d shows whet her t he message or iginat ed wit h t he cl ient (a val ue of 0) or
wit h t he ser ver (a val ue of 1). The f ir st Ver sion Number is t he ver sion of RPC used and
t he second Ver sion Number ident if ies t he ver sion of t he pr ogr am. The Pr ogr am Number
ident if ies t he ser vice (set of pr ocedur es) t o use, as ment ioned ear l ier . The Pr ocedur e
Number ident if ies t he par t icul ar pr ocedur e in t he ser vice.
Figur e 12.3. The RPC pr ot ocol header .
Some pr ocedur es might r equir e a cl ient t o aut hent icat e it sel f t o t he ser ver , bot h f or
ident if icat ion pur poses and f or secur it y r easons. The RPC pr ot ocol header cont ains t wo
f iel ds f or aut hent icat ion. The Aut hor izat ion Inf or mat ion f iel d is f or inf or mat ion it sel f ,
and t he Aut hor izat ion Ver if icat ion f iel d is used f or t he val idat ion. The RPC RFC does
not def ine how aut hent icat ion is t o be per f or med, l eaving it up t o t he appl icat ion
devel oper , but it does specif y t wo f iel ds wit h a maximum size of 400 byt es each. Ther e ar e
cur r ent l y f our t ypes of aut hent icat ion pr edef ined f or use:
G None: No aut hent icat ion is used. Bot h aut hent icat ion f iel ds have zer o l engt h.
G UNIX: Uses UNIX per missions (gr oup and user IDs). This t ype of aut hent icat ion is
used by t he NFS pr ot ocol . Ther e is no aut hent icat ion inf or mat ion.
G Shor t : Shor t aut hent icat ion pr ocess. The cl ient gener at es an aut hent icat ion
sequence, which is r et ur ned by t he ser ver (usual l y a r ef er ence t o a pr evious RPC
r equest f or convenience).
G DES: Aut hent icat ion is a char act er st r ing wit h a Dat a Encr ypt ion St andar d (DES)
encoded t imest amp used as t he ver if icat ion. The DES aut hent icat ion is used by t he
secur e NFS pr oduct .
The onl y aut hent icat ion syst em t hat is r eal l y secur e is t he DES met hod. The ot her
t hr ee syst ems can be r eadil y br oken by a knowl edgeabl e devel oper .
Each ser vice t hat uses RPC has a pr ogr am number t hat uniquel y ident if ies it t o t he
pr ot ocol . RPC keeps t r ack of connect ions using a pr ogr am number f or each, which can be
mapped t o a pr ogr am name. In UNIX, t his mapping is per f or med in t he f il e /et c/r pc. A
sampl e /et c/r pc f il e f ol l ows:
portmapper 100000 portmap sunrpc
rstat_svc 100001 rstatd rstat rup perfmeter
rusersd 100002 rusers
nfs 100003 nfsprog
ypserv 100004 ypprog
mountd 100005 mount showmount
ypbind 100007
walld 100008 rwall shutdown
yppasswdd 100009 yppasswd
etherstatd 100010 etherstat
rquotad 100011 rquotaprog quota rquota
sprayd 100012 spray
3270_mapper 100013
rje_mapper 100014
selection_svc 100015 selnsvc
database_svc 100016
rexd 100017 rex
alis 100018
sched 100019
llockmgr 100020
nlockmgr 100021
x25.inr 100022
statmon 100023
status 100024
bootparam 100026
ypupdated 100028 ypupdate
keyserv 100029 keyserver
ypxfrd 100069 ypxfr
pcnfsd 150001 pcnfsd
This f il e shows t he pr ogr am name and it s cor r esponding pr ogr am number . The t hir d
col umn, when pr esent , shows a pr ogr am name t hat cor r esponds wit h t he pr ocess name in
t he f ir st col umn. The pr ogr am number s shown in t his f il e ar e assigned by t he RPC RFC
and shoul d be consist ent acr oss al l impl ement at ions of RPC.
Port Mapper
Connect ions bet ween a cl ient and ser ver ar e over por t s, each wit h it s own number (por t
number s ar e used in TCP/IP t o def ine a connect ion). To pr event pr obl ems wit h por t
al l ocat ion using RPC, a port mapper was devel oped. Wit hout t he por t mapper , a ser ver
coul d easil y r un out of avail abl e por t s wit h onl y a f ew RPC connect ions act ive.
The por t mapper cont r ol s a t abl e of por t s and RPC pr ogr ams using t hose por t s. The por t
mapper it sel f has a dedicat ed por t number (por t 111 wit h bot h UDP and TCP). The por t s
avail abl e t o RPC connect ions ar e assigned when t he RPC pr ogr am is init iat ed, at which
t ime t hese por t number s ar e sent t o t he por t mapper .
When a cl ient want s t o use RPC, it sends a r equest t o t he ser ver . This r equest f ol l ows
t he RPC header f or mat seen in Figur e 12.3 and incl udes t he ver sion number of RPC, t he
ser vice number , and t he pr ot ocol t o be used. The por t mapper can t hen al l ocat e a
suit abl e por t number and r et ur n t hat number in a r epl y message t o t he cl ient . Once a
por t number has been assigned f or t hat cl ient , it is maint ained, so t hat al l pr ocedur e
r equest s come over t hat por t unt il t he appl icat ion t er minat es. The por t number s might
be maint ained over sever al pr ocesses, so t he por t inquir y needs t o be conduct ed onl y
once bet ween syst em power cycl es.
This pr ocedur e does have a dr awback: t he cl ient must know t he ser ver 's addr ess. It
cannot simpl y send out a gener ic r equest f or a ser ver wit h t he ser vices it is l ooking f or .
This has been over come wit h some newl y devel oped net wor k f il e syst ems, al t hough not
NFS.
External Data Representation (XDR)
The Ext er nal Dat a Repr esent at ion (XDR) is t he met hod by which dat a is encoded wit hin
an RPC message (or ot her pr ot ocol syst ems, as wel l ). Ther e is no f or mal message header
or pr ot ocol syst em f or XDR, al t hough t he XDR RFC does def ine t he met hod of encoding
dat a.
XDR is used t o ensur e t hat dat a f r om one syst em is compat ibl e wit h ot her s. It might seem
t hat no f or mal def init ion is r equir ed, but consider t he case of an EBCDIC-based machine
communicat ing wit h an ASCII-based machine. XDR enabl es bot h ends t o conver t f r om
t heir l ocal dat a r epr esent at ion t o a common f or mat , r emoving any doubt s about t he
meaning of t he dat a. (EBCDIC t o ASCII is not t he major conver sion pr obl em. Some syst ems
use high bit s as signif icant , and ot her s use l ow bit s. Al so, f or mat s f or def ining t ypes of
number s dif f er consider abl y.)
The XDR f or mat uses sequent ial bit s wr it t en int o a buf f er , t hen f or mat t ed int o a
message and sent t o t he l ower pr ot ocol l ayer s. XDR r el ies on an 8-bit byt e, wit h t he
l ower byt es being t he most signif icant . The RFC def ines t hat al l int eger dat a t ypes ar e
conver t ed t o 4-byt e int eger s, wit h an ext ended 64-bit hyperinteger f or mat avail abl e. IEEE
32-bit f or mat s ar e used f or f l oat ing-point number s, wher e t he mant issa is t he l ower 23
bit s, t he exponent t akes 8 bit s, and t he sign of t he number is 1 bit . Wher e dat a t akes l ess
t han 4 byt es f or any t ype, padding is added t o ensur e 4-byt e l engt hs.
A special C-l ike l anguage cal l ed XDR has been devel oped
t o simpl if y t he handl ing of XDR-f or mat dat a. It can be used
f r om wit hin ot her pr ogr amming l anguages.
Network File System Protocol
The NFS pr ot ocol is composed of a set of RPC pr ocedur es. It is not a pr ot ocol in t he
convent ional sense of def ining a compl ex handshaking pr ocess bet ween t wo machines.
Inst ead, it is a met hod of communicat ing inf or mat ion about a pr ocedur e t o be r un. NFS
uses UDP and has a por t number of 2049 assigned. This por t number is nonsense; it ar ises
f r om an er r or in t he or iginal impl ement at ion t hat coul d not be cor r ect ed subsequent l y
because of compat ibil it y issues. Because t he por t number s ar e assigned by t he por t
mapper , t his number has no r eal meaning.
NFS was designed t o be a stateless pr ot ocol , meaning t hat t he machines using NFS woul d
not have t o maint ain st at e t abl es t o use t he pr ot ocol . Al so, it was designed t o be r obust ,
meaning t hat af t er f ail ur es (of a connect ion or a machine) t he syst em coul d r ecover
quickl y and easil y.
The NFS pr ot ocol is dif f icul t t o descr ibe wit hout int r oducing some pr ogr amming, because
t he syst em is descr ibed in t er ms of t he XDR l anguage. This t ype of discussion is beyond
t he scope of t his book; f or mor e inf or mat ion, r ef er t o t he RFCs. However , it is possibl e t o
convey a sense of t he pr ot ocol 's cont ent s t hr ough an over view of it s capabil it ies and
f eat ur es.
To under st and t he NFS pr ocedur es t hat compr ise t he pr ot ocol , it is necessar y t o examine
t he dat a st r uct ur es and object s in t he pr ot ocol . NFS def ines a set of const ant s t hat ar e
used t o est abl ish var ious par amet er s, such as t he number of byt es in a pat h name, t he
maximum number of byt es in a r ead or wr it e r equest , or t he size of an NFS point er . These
ar e cal l ed protocol constants and shoul d be t he same f or al l impl ement at ions of NFS.
A data object is a set of var iabl es or val ues t hat ar e
combined in one ent it y, much as an ent r y in a t el ephone book is
act ual l y composed of a name, addr ess, and t el ephone number .
Al l t hr ee var iabl es or val ues combine t o f or m a singl e ent r y or
object .
Sever al dat a object s ar e used by NFS t o def ine f il es and t heir at t r ibut es. Because NFS
deal s specif ical l y wit h f il es, t hese object s ar e impor t ant t o t he pr ot ocol . One dat a
object is t he f il e handl e (or f handl e), which uniquel y ident if ies a f il e on t he ser ver . Fil e
handl es ar e pr ovided in al l NFS messages t hat r ef er t o t he f il e. As wit h most NFS dat a
t ypes, t he f il e handl e is a 32-byt e f iel d of f r ee f or mat t hat is under st andabl e by t he
ser ver . For exampl e, a UNIX f il e is uniquel y def ined by it s device major and minor
number s and it s inode number . The f il ename it sel f is not used.
A dat a object is used f or t he f il e t ype (cal l ed f t ype), which def ines al l t he kinds of f il es
known by NFS. These mimic t he UNIX f il e t ypes, incl uding a r egul ar f il e (any kind of
dat a), a dir ect or y (which is a f il e ent r y in UNIX), l inks (which ar e sever al point er s
under dif f er ent names t o t he same f il e) and bot h bl ock and char act er mode f il es.
Al so used is a dat a st r uct ur e f or t he f il e at t r ibut es, cal l ed f at t r . This def ines t he
per missions of t he f il e, t he t imes of access, t he owner , and sever al ot her par amet er s. This
is necessar y whenever a f il e r ead or wr it e is per f or med, because t he at t r ibut es must be
cor r ect t o al l ow t he pr ocedur e t o cont inue. (The at t r ibut es can be changed by anot her
NFS pr ocedur e cal l ed set at t r ibut es or sat t r .)
These dat a object s can be combined int o a l ar ger ent it y using a discr iminat ing union. A
discriminating union is a combinat ion of sever al dat a object s t hat ar e given a singl e l abel .
These discr iminat ing unions can be t hought of as a l abel f ol l owed by dat a, which might
dif f er depending on t he out come of a pr ocedur e. For exampl e, af t er a pr ocedur e has been
execut ed, a discr iminat ing union might be a l abel f ol l owed by eit her an er r or message or
t he r esul t of t he pr ocedur e, if it execut es pr oper l y. The union, t hough, is r ef er r ed t o by
t he l abel and doesn't car e about t he cont ent s in t he dat a ar ea. This t ype of st r uct ur e is
used t o simpl if y pr ogr amming.
Sevent een pr ocedur es (and a NULL pr ocedur e) ar e def ined wit hin t he NFS pr ot ocol .
These pr ocedur es ar e summar ized in Tabl e 12.1. This book doesn't go int o det ail about t he
pr ocedur es, as t hey ar e not r el evant t o t he l evel of discussion. The RFC cover s t hem al l
in exhaust ive det ail .
Tabl e 12.1. NFS pr ocedur es.
Name Description
Nul l Nul l pr ocedur e
Fet ch f il e at t r ibut es Ret ur ns t he at t r ibut es of a f il e
Set f il e at t r ibut es Set s t he at t r ibut es of a f il e
Read f il e syst em r oot Not used; now obsol et e
Lookup f il ename Ret ur ns t he f il e handl e cor r esponding t o a f il ename
Read cont ent s of l ink Ret ur ns det ail s of symbol ic l inks t o a f il e
Read f il e Reads a f il e
Wr it e t o cache Not used
Wr it e t o f il e Wr it es a f il e
Cr eat e f il e Cr eat es a new f il e and r et ur ns t he new f il e's handl e
Del et e f il e Del et es a f il e
Rename f il e Renames a f il e
Gener at e l ink Cr eat es a l ink t o a f il e (same f il e syst em)
Gener at e symbol ic l ink Gener at es a symbol ic l ink (acr oss f il e syst ems)
Cr eat e dir ect or y Cr eat es a new dir ect or y
Del et e dir ect or y Removes a dir ect or y
Read dir ect or y Ret ur ns a l ist of f il es in t he dir ect or y
Read f il e syst em at t r ibut es Ret ur ns inf or mat ion about t he f il e syst em
Pr ogr ammer s might have not iced t he l ack of any open and cl ose f il e f unct ions wit hin
NFS. This ar ises f r om t he st at el ess nat ur e of t he pr ot ocol . When a f il e must be opened,
t he l ocal NFS pr ocess handl es it , not t he r emot e pr ocess. This al l ows f or bet t er cont r ol
of f il es and por t s af t er f ail ur e of a machine or a connect ion.
Mount Protocol
In t oday's int r oduct ion I ment ioned t hat NFS wor ks by mount ing an NFS ser ver f il e
syst em ont o a cl ient f il e syst em. As you have just seen, however , t he NFS pr ot ocol is
act ual l y about f il e access and inf or mat ion, not connect ing f il e syst ems. This f il e syst em
mount ing pr ocedur e is deal t wit h as a separ at e issue by t he NFS pr oduct , using t he
Mount pr ot ocol . Mount uses UDP.
The Mount pr ot ocol is invol ved in r et ur ning a f il e handl e f r om t he ser ver t o t he
cl ient , enabl ing t he cl ient t o access an ar ea on t he ser ver f il e syst em. The pr ot ocol
r et ur ns not onl y t he f il e handl e but al so t he name of t he f il e syst em in which t he
r equest ed f il e r esides. Mount consist s of a number of pr ocedur es t hat f acil it at e
communicat ions bet ween t he cl ient and ser ver , designed especial l y f or deal ing wit h
f il es.
A pr ocess cal l ed mount d t akes car e of handl ing t he mount pr ot ocol at bot h ends of a
connect ion. The mount d pr ocess maint ains a l ist of machines and pat h names t hat ar e
invol ved in a mount oper at ion. Once a mount has been per f or med, NFS can cont inue
oper at ing wit hout r ef er r ing back t o Mount at al l . This l et s Mount cont inue t o modif y
it s int er nal t abl es wit hout af f ect ing ongoing sessions. This can cause a pr obl em if a
cl ient cr ashes and r econnect s. The ser ver st il l has t he or iginal connect ions l ist ed in it s
int er nal Mount t abl es. To cor r ect t his pr obl em, most NFS cl ient s send a command
(cal l ed UMNTALL, or unmount al l ) t o al l NFS ser ver s when t hey boot .
The Mount pr ot ocol is invol ved onl y dur ing t he or iginal
connect ion bet ween a cl ient and a ser ver . The mount d pr ocess
keeps t r ack of connect ions, but once t he connect ion is
est abl ished, t he Mount pr ot ocol r el inquishes al l cont r ol t o
NFS. Al l NFS needs t o access a f il e syst em is a val id f il e handl e
(which Mount pr ovides when t he connect ion is made).
As ment ioned ear l ier , t he Mount pr ot ocol consist s of a set of pr ocedur es. These ar e
summar ized in Tabl e 12.2 and ar e sel f -expl anat or y.
Tabl e 12.2. Mount pr ot ocol pr ocedur es.
Name Description
NULL Nul l
MNT Mount s a f il e syst em and r et ur ns t he f il e handl e and f il e syst em name
UMNT Unmount s a ser ver f il e syst em, del et ing t he ent r y f r om t he Mount t abl e
UMNTALL
Unmount s al l ser ver f il e syst ems used by t he cl ient and updat es t he
Mount t abl e
EXPORT Pr ovides a l ist of expor t ed f il e syst ems
DUMP
Pr ovides a l ist of t he f il e syst ems on t he ser ver t hat ar e cur r ent l y
mount ed on t he cl ient
Some ver sions of NFS enabl e an aut omount capabil it y, in which t he r emot e f il e syst ems
ar e mount ed onl y when r equir ed. This pr event s t hem f r om being at t ached f or ext ended
per iods of t ime and simpl if ies administ r at ion. The pr ocess of aut omount ing is compl et el y
t r anspar ent t o t he user .
The aut omount capabil it y is buil t upon NFS's pr ocedur es, but it per f or ms a f ew cl ever
t r icks. The aut omount er is not par t of NFS but is an appl icat ion t hat sit s on t op of it .
Symbol ic l inks ar e t he key t o t he aut omount er 's oper at ion.
File Locking
Occasional l y a syst em administ r at or want s t o pr event access t o an NFS-avail abl e f il e
syst em. Such inst ances occur r egul ar l y dur ing maint enance, sof t war e updat es, or t o
pr ot ect dat a dur ing a par t icul ar pr ocess. UNIX has t he capabil it y t o l ock a par t icul ar
f il e by changing per missions, and t he same can be done f or f il e syst ems t o some ext ent ,
but it woul d seem int uit ive t hat l ocking a f il e syst em is mor e invol ved t han simpl y
l ocking a f il e or t wo. The capabil it y t o l ock f il e syst ems f r om access was not devel oped
wit h t he or iginal NFS pr oduct but was impl ement ed as a par al l el ser vice af t er NFS
became mor e widel y avail abl e.
Separ at ing f unct ional it y (such as f il e l ocking) int o
separ at e pr ot ocol s or pr ocedur es is consist ent wit h bot h t he
OSI and NFS phil osophies. This al so enabl es bet t er por t abil it y
and compat ibil it y acr oss pl at f or ms.
Fil e syst em l ocking is handl ed by sever al pr ot ocol s and pr ocedur es, invol ving a f ew
daemon pr ocesses. In t he or iginal f il e l ocking syst em devel oped by Sun Micr osyst ems, a
l ock daemon cal l ed l ockd was used. This r equir es t hat ever y RPC act ivit y t hat invol ves
a l ock communicat es wit h t he pr ocess, even when it is on anot her machine. The
communicat ions bet ween RPC and l ockd use a pr ot ocol cal l ed Ker nel Lock Manager
(KLM), which r ides on UDP.
Whenever a l ock pr ocedur e is cal l ed, l ockd decides whet her it can handl e t he t ask on
t he l ocal machine or whet her messages have t o be sent t o r emot e l ockd pr ocesses (on
ot her machines). Communicat ions bet ween dif f er ent l ockd pr ocesses ar e t hr ough
anot her pr ot ocol cal l ed t he Net wor k Lock Manager (NLM). Ther e ar e sever al ver sions
of bot h KLM and NLM in use, wit h impl ement at ions avail abl e f or most har dwar e
pl at f or ms.
A pr ocess cal l ed st at d (st at us monit or ) monit or s t he st at e of l ocks and handl es quer ies
against a l ocked f il e syst em. This is necessar y so t hat a new quer y against a l ocked f il e
syst em can be queued (if it is l ocked f or a shor t t ime) or r eject ed (if t he f il e syst em is
l ocked f or a whil e).
Ther e ar e sever al buil t -in pr ot ect ion syst ems f or f il e l ocking, such as aut omat ic t imer s
t o pr event inf init e l ocking af t er a machine cr ash, conf l ict ing r equest s f or l ocks, and a
shor t per iod f or compl et ion of exist ing pr ocedur es bef or e a l ock is compl et ed. These ar e
al l def ined and expl ained in t he RFC.
Remote Execution Service (REX)
The Remot e Execut ion Ser vice (REX) is designed t o enabl e a user t o r un commands on
anot her machine wit h f ul l envir onment var iabl es, wit hout incur r ing t he over head of
pr ocesses such as Tel net , r l ogin, or r sh. REX uses a daemon cal l ed r exd t hat r uns on t h