TCP Representation

Illustrated TCP/IP
by Matthew G. Naugle
Wiley Computer Publishing, John Wiley & Sons, Inc.
ISBN: 0471196568 Pub Date: 11/01/98
Acknowl edgment s
Part One - Introduction to the TCP/IP Protocol
Chapt er 1 - Tr ansmission Cont r ol Pr ot ocol /Int er net Pr ot ocol
Chapt er 2 - TCP/IP and Ot her Pr ot ocol s
Chapt er 3 - The Or igins of TCP/IP
Chapt er 4 - The Wor l d Wide Web
Chapt er 5 - Int er net , Int r anet s, and Ext r anet s
Chapt er 6 - Who Gover ns t he Int er net ?
Chapt er 7 - The Gover ning Bodies of t he Int er net
Chapt er 8 - An Over al l View of t he Int er net
Chapt er 9 - Int er net Timel ine
Chapt er 10 - Cir cuit and Packet Swit ching
Chapt er 11 - TCP/IP Pr ot ocol Document s
Chapt er 12 - Why St udy t he RFCs?
Chapt er 13 - Submit t ing an RFC
Chapt er 14 - RFC Updat es
Chapt er 15 - RFC For mat
Chapt er 16 - Ot her RFC For mat Requir ement s
Chapt er 17 - Requir ement s in RFCs
Chapt er 18 - TCP/IP: The Pr ot ocol s (cover ed in t his book) and t he OSI Model
Chapt er 19 - The Pr ot ocol Suit e, Accor ding t o This Book
Chapt er 20 - IP Over view
Chapt er 21 - IGPs, EGPs, and Rout ing Pr ot ocol s
Chapt er 22 - Int r oduct ion t o Rout ing Pr ot ocol s (RIP)
Chapt er 23 - Int r oduct ion t o Rout ing Pr ot ocol s (OSPF)
Chapt er 24 - Ot her IPRel at ed Pr ot ocol s
Chapt er 25 - Int r oduct ion t o Tr anspor t Layer Pr ot ocol s
Chapt er 26 - Int r oduct ion t o t he TCP/IP St andar d Appl icat ions
Chapt er 27 - The Int er net Pr ot ocol (IP)
Chapt er 28 - Connect ionl ess, Best Ef f or t Del iver y Ser vice
Chapt er 29 - Dat a Encapsul at ion by Layer
Chapt er 30 - IPv4 Header
Chapt er 31 - Header Lengt h, Ser vice Type, and Tot al Lengt h Fiel ds
Chapt er 32 - Fr agment at ion
Chapt er 33 - Time t o Live (TTL)
Chapt er 34 - Pr ot ocol and Checksum Fiel ds
Chapt er 35 - IP Opt ions Fiel d
Chapt er 36 - Sour ce and Dest inat ion Addr ess Fiel ds
Chapt er 37 - The IP Addr ess Scheme
Chapt er 38 - Cl assf ul Addr essing - The Or iginal Addr ess Scheme
Chapt er 39 - IP Addr ess For mat
Chapt er 40 - Ident if ying a Cl ass
Chapt er 41 - Cl ass A Addr ess
Chapt er 42 - Cl ass B Addr ess
Chapt er 43 - Cl ass C Addr ess
Chapt er 44 - Cl ass D Addr ess
Chapt er 45 - Cl asses AD Review
Chapt er 46 - Subnet t ing
Chapt er 47 - Reasons f or Subnet t ing
Chapt er 48 - Subnet t ing Exampl es (Cl asses A, B, and C)
Chapt er 49 - Mor e Subnet Exampl es
Chapt er 50 - Physical and Logical Addr esses
Chapt er 51 - Subnet Mask Templ at e
Chapt er 52 - An Exampl e Conver sion
Chapt er 53 - Let s Tr y One
Chapt er 54 - Subnet Bit s
Chapt er 55 - Subnet Rest r ict ions
Chapt er 56 - Subnet Mask Decisions
Chapt er 57 - Assigning Mor e Than One Addr ess t o an Int er f ace
Chapt er 58 - Cl assf ul IP Addr ess Review
Chapt er 59 - IP Addr ess Rest r ict ions
Chapt er 60 - Addr ess Al l ocat ion (The Int er net Regist r y)
Part Two - The Protocol Suite of TCP/IP
Chapt er 61 - Addr ess Resol ut ion Pr ot ocol (ARP)
Chapt er 62 - ARP Packet For mat
Chapt er 63 - ARP Oper at ion
Chapt er 64 - Rul es f or ARP
Chapt er 65 - Rever se Addr ess Resol ut ion Pr ot ocol (RARP)
Chapt er 66 - Pr oxy ARP
Chapt er 67 - What s Wr ong wit h t he Addr ess?
Chapt er 68 - Ext ending t he Lif e of t he IPv4 Addr ess Space
Chapt er 69 - IP Addr ess Assignment (The Ol d Met hod)
Chapt er 70 - IP Addr essing (The Ol d Met hod)
Chapt er 71 - Addr ess Ter ms and Def init ions
Chapt er 72 - Making t he Addr ess Ef f icient
Chapt er 73 - Masks and Pr ef ixes
Chapt er 74 - Anot her Tr y
Chapt er 75 - Var iabl e-Lengt h Subnet Masks
Chapt er 76 - Longest Mat ch Rul e
Chapt er 77 - Exampl e One: An ISP Addr ess Assignment
Chapt er 78 - Exampl e Two: Rel axing t he Assignment
Chapt er 79 - Super net t ing Exposed
Chapt er 80 - Rout e Aggr egat ion
Chapt er 81 - Det er mining a Common Pr ef ix
Chapt er 82 - Anot her Look at Rout e Aggr egat ion
Chapt er 83 - Cl assl ess Int er -Domain Rout ing (CIDR)
Chapt er 84 - Cl assl ess Int er -Domain Rout ing (cont inued)
Chapt er 85 - Pr ef ix Assignment s
Chapt er 86 - A Look at t he Addr esses of an ISP
Chapt er 87 - A Gr aphic Look at t he Exampl e
Chapt er 88 - CIDR and VLSM Compar ison
Chapt er 89 - Special Subnet Consider at ions
Chapt er 90 - Int er net Assigned Number s Aut hor it y
Chapt er 91 - Cur r ent IANA Addr ess Bl ock Assignment s
Chapt er 92 - IP Rout ing
Chapt er 93 - Dir ect Rout ing
Chapt er 94 - Indir ect Rout ing
Chapt er 95 - A Fl owchar t
Chapt er 96 - Rout ing Pr ot ocol s - Dist ance Vect or
Chapt er 97 - Updat ing Ot her Rout er s (Dist ance Vect or s)
Chapt er 98 - A Bigger Updat e
Chapt er 99 - IP Rout ing Tabl es
Chapt er 100 - The Rout ing Inf or mat ion Pr ot ocol (Ver sion 1)
Chapt er 101 - RIP Oper at ional Types
Chapt er 102 - RIP Fiel d Descr ipt ions
Chapt er 103 - Def aul t Rout er and Gat eways
Chapt er 104 - Disadvant ages of t he RIPv1 Pr ot ocol
Chapt er 105 - Scal ing wit h RIP
Chapt er 106 - Rout er s and Subnet Masks
Chapt er 107 - RIP Fixes
Chapt er 108 - Spl it Hor izon Demonst r at ed
Chapt er 109 - RIP Ver sion 2
Chapt er 110 - Aut hent icat ion
Chapt er 111 - Subnet Mask Fiel d
Chapt er 112 - Rout e Tag and Next -Hop Fiel ds
Chapt er 113 - Mul t icast Suppor t
Chapt er 114 - RIPv2 Compat ibil it y wit h RIPv1
Chapt er 115 - Open Shor t est Pat h Fir st (OSPF, RFC 2178)
Chapt er 116 - An OSPF Net wor k
Chapt er 117 - A Rout ing Pr ot ocol Compar ison
Chapt er 118 - OSPF Over view
Chapt er 119 - OSPF Media Suppor t
Chapt er 120 - Rout er Types
Chapt er 121 - Rout er Names and Rout ing Met hods
Chapt er 122 - Message Types
Chapt er 123 - Met r ics (Cost )
Chapt er 124 - Gener ic Packet For mat
Chapt er 125 - The Hel l o Pr ot ocol
Chapt er 126 - Adjacency
Chapt er 127 - Maint aining t he Dat abase
Chapt er 128 - OSPF Ar eas
Chapt er 129 - The Backbone Ar ea
Chapt er 130 - The Ar ea Bor der Rout er (ABR)
Chapt er 131 - Vir t ual Link
Chapt er 132 - Int er -Ar ea Rout ing
Chapt er 133 - Inf or mat ion f r om Ot her Aut onomous Syst ems
Chapt er 134 - St ub Ar eas
Chapt er 135 - RFCs Rel at ed t o OSPF
Chapt er 136 - St at ic ver sus Dynamic Rout ing
Chapt er 137 - Remot e Net wor ks
Chapt er 138 - Dat agr am Rout ing
Part Three - Internet Protocol Version 6 (IPv6)
Chapt er 139 - Int r oduct ion
Chapt er 140 - IPv6 Feat ur es
Chapt er 141 - Fr om IPv4 t o IPv6
Chapt er 142 - IP Ver sion Number s Accor ding t o RFC 1700
Chapt er 143 - IPv6 Header
Chapt er 144 - IPv4 Opt ions - A Review
Chapt er 145 - IPv4 and IPv6 Header Dif f er ences
Chapt er 146 - IPv6 Ext ension Header s
Chapt er 147 - Fr agment at ion
Chapt er 148 - Pr ior it y and Fl ow Label
Chapt er 149 - IPv6 Addr essing
Chapt er 150 - IPv6 Addr essing Pr ef ix
Chapt er 151 - 6Bone Test Addr essing
Chapt er 152 - Pr ovider -Based IPv6 Addr essing
Chapt er 153 - Local -Use IPv6 Addr essing
Chapt er 154 - IPv6 Addr esses wit h Embedded IPv4 Addr esses
Chapt er 155 - Unicast Addr esses
Chapt er 156 - Aut oconf igur at ion
Chapt er 157 - Neighbor Discover y
Chapt er 158 - Neighbor Discover y Types
Chapt er 159 - Neighbor Discover y and IPv4
Chapt er 160 - Addr ess Resol ut ion
Chapt er 161 - Met hods of Depl oying IPv6
Chapt er 162 - IPv6 Tunnel ing Int r oduct ion
Chapt er 163 - IPv6 Tunnel Addr essing
Chapt er 164 - IPv6 and IPv4 Dual -St ack St r at egy
Chapt er 165 - IPv6 Tunnel ing
Chapt er 166 - IPv6 Tunnel ing
Chapt er 167 - IPv6 Tunnel ing Fl owchar t 1
Chapt er 170 - Anycast Addr essing
Chapt er 171 - Mul t icast ing f or IPv6
Chapt er 172 - IPv6 Rout ing
Chapt er 173 - RIPng
Chapt er 174 - ICMP
Chapt er 175 - ICMPv6 Encapsul at ion
Chapt er 176 - ICMPv6 and ICMPv4
Chapt er 177 - ICMPv6 Er r or Messages
Chapt er 178 - ICMP Inf or mat ional Messages
Chapt er 179 - ICMP and Neighbor Discover y
Chapt er 180 - ICMPv6 and Mul t icast
Chapt er 181 - IPv6 Cache Ent r ies
Chapt er 182 - IPv6 Al gor it hm
Chapt er 183 - RFCs Rel at ed t o IPv6
Part Four - Beyond the IP Layer
Chapt er 184 - Int er net Cont r ol Message Pr ot ocol (ICMP)
Chapt er 185 - ICMP PING
Chapt er 186 - Mor e ICMP Funct ions
Chapt er 187 - User Dat agr am Pr ot ocol (UDP)
Chapt er 188 - Mul t ipl exing and Demul t ipl exing
Chapt er 189 - Por t Number s
Chapt er 190 - Assigned, Regist er ed, and Dynamic Por t Number s
Chapt er 191 - Dynamic Por t Number s
Chapt er 192 - Tr ansmission Cont r ol Pr ot ocol (TCP)
Chapt er 193 - TCP Det ail s
Chapt er 194 - TCP Fiel ds
Chapt er 195 - TCP Ser vices
Chapt er 196 - TCP Connect ion Est abl ishment
Chapt er 197 - The Thr ee-Way Handshake
Chapt er 198 - TCP Segment
Chapt er 199 - Sequence Number s and Acknowl edgment s
Chapt er 200 - Sequence and Acknowl edgment Exampl e
Chapt er 201 - TCP Fl ow and Window Management
Chapt er 202 - TCP Ret r ansmission
Chapt er 203 - Sl ow St ar t and Congest ion Avoidance
Chapt er 204 - Ter minat ion
Chapt er 205 - Real -Time Pr ot ocol and t he Real -Time Cont r ol Pr ot ocol
Chapt er 206 - Tr ansl at or s
Chapt er 207 - Mixer s
Chapt er 208 - RTP Message For mat
Chapt er 209 - Suppor t f or Time-Sensit ive Apps
Chapt er 210 - Payl oad Type
Chapt er 211 - Pr oviding Cont r ol f or RTP
Chapt er 212 - Sender Repor t s
Chapt er 213 - Receiver Repor t s
Chapt er 214 - Sour ce Descr ipt ion Packet
Chapt er 215 - Bye Message (Packet )
Chapt er 216 - Appl icat ion-Specif ic Message
Chapt er 217 - Caveat s
Chapt er 218 - RFCs
Chapt er 219 - Sel ect ed TCP/IP Appl icat ions
Chapt er 220 - TELNET
Chapt er 221 - TELNET Opt ions
Chapt er 222 - Fil e Tr ansf er Pr ot ocol (FTP)
Chapt er 223 - FTP Commands
Chapt er 224 - FTP Dat a Tr ansf er
Chapt er 225 - Tr ivial Fil e Tr ansf er Pr ogr am (TFTP)
Chapt er 226 - Domain Name Ser vice (DNS)
Chapt er 227 - DNS St r uct ur e
Chapt er 228 - DNS Component s
Chapt er 229 - Domain St r uct ur e
Chapt er 230 - Name Ser ver s
Chapt er 231 - Quer y Funct ion Types
Chapt er 232 - Exampl e DNS Dat abase
Chapt er 233 - SOA Recor d
Chapt er 234 - Name Ser ver Recor ds
Chapt er 235 - Addr ess Recor ds
Chapt er 236 - Mail Exchange Recor ds (MX)
Chapt er 237 - Pl aying wit h t he Dat abase
Chapt er 238 - WHOIS Command
Chapt er 239 - Mor e DNS Inf or mat ion
Chapt er 240 - Simpl e Mail Tr ansf er Pr ot ocol (SMTP)
Chapt er 241 - SMTP Funct ions
Chapt er 242 - SMTP Fl ow
Chapt er 243 - DNS Int er act ion f or Mail
Chapt er 244 - Post Of f ice Pr ot ocol (POP)
Chapt er 245 - POP Oper at ion
Chapt er 246 - SMTP, DNS, and POP Topol ogy
Part Five - IP Multicast
Chapt er 247 - Int r oduct ion
Chapt er 248 - Mul t icast Component s
Chapt er 249 - Mul t icast Caveat s
Chapt er 250 - Unicast (ver sus Mul t icast )
Chapt er 251 - Mul t icast (ver sus Unicast )
Chapt er 252 - Mul t icast ing Type
Chapt er 253 - Addr essing Type Review
Chapt er 254 - Int r oduct ion t o IP Mul t icast
Chapt er 255 - Ext ensions t o t he IP Ser vice Int er f ace
Chapt er 256 - Receiving Mul t icast Dat agr ams
Chapt er 257 - Addr ess For mat
Chapt er 258 - Mapping t o an Et her net or IEEE 802.X MAC Addr ess
Chapt er 259 - A Conver t ed IP Mul t icast Addr ess
Chapt er 260 - Pr ot ocol s
Chapt er 261 - IGMP Header
Chapt er 262 - Rout er Funct ions of IGMP
Chapt er 263 - Host Join
Chapt er 264 - Mul t icast Al gor it hms
Chapt er 265 - Leaves, Br anches, and t he Root
Chapt er 266 - Spanning Tr ee and Fl ooding
Chapt er 267 - Rever se Pat h For war ding (RPF)
Chapt er 268 - Pr uning and Gr af t ing (Def init ion)
Chapt er 269 - Rever se Pat h Mul t icast ing (RPM)
Chapt er 270 - Cor e-Based Tr ee (CBT)
Chapt er 271 - Dist ance Vect or Mul t icast Rout ing Pr ot ocol (DVMRP)
Chapt er 272 - DVMRP and IGMP
Chapt er 273 - Neighbor Discover y
Chapt er 274 - Rout e Repor t s
Chapt er 275 - Receiving a Rout e Repor t
Chapt er 276 - DVMRP Tabl es
Chapt er 277 - DVMRP Rout e Tabl es
Chapt er 278 - DVMRP Tunnel ing
Chapt er 279 - IP-in-IP Packet For mat
Chapt er 280 - Pr ot ocol -Independent Mul t icast (PIM)
Chapt er 281 - PIM - Dense Mode (PIM-DM)
Chapt er 282 - PIM - Dense Mode Oper at ion
Chapt er 283 - Adding Int er f aces
Chapt er 284 - PIM - Spar se Mode (PIM-SM)
Chapt er 285 - Types of Mul t icast Tr ees Using PIM-SM
Chapt er 286 - Joining a Gr oup
Chapt er 287 - A Host Sending t o a Gr oup
Chapt er 288 - Conver t ing t o a Sour ce-Root ed Tr ee
Chapt er 289 - Rendezvous Point s
Chapt er 290 - Compar ison of Spar se- and Dense-Mode Pr ot ocol s
Chapt er 291 - Mul t icast Open Shor t est Pat h Fir st (MOSPF)
Chapt er 292 - MOSPF Dif f er ences
Chapt er 293 - MOSPF Caveat s
Chapt er 294 - Local -Gr oup Dat abase and t he Gr oup-Member ship LSA
Chapt er 295 - Rol e of t he DR and t he BDR
Chapt er 296 - The Local -Gr oup Dat abase
Chapt er 297 - Oper at ion
Chapt er 298 - For war ding Cache
Chapt er 299 - Int er -Ar ea MOSPF Rout ing
Chapt er 300 - Int er -Ar ea Mul t icast Exampl e
Chapt er 301 - Int er -Ar ea Shor t est -Pat h Tr ee
Chapt er 302 - Int er -Aut onomous Syst em Mul t icast
Chapt er 303 - Mul t icast Concl usion
Chapt er 304 - RFCs t o Be Reviewed
Part Six - BOOTP, DHCP, RSVP, and SNMP
Chapt er 305 - Boot Pr ot ocol (BOOTP)
Chapt er 306 - BOOTP Oper at ion
Chapt er 307 - BOOTP Fiel d Def init ions
Chapt er 308 - Cl ient Side (BOOTREQUEST)
Chapt er 309 - Ser ver Side
Chapt er 310 - Chicken-or -t he-Egg? Dil emma
Chapt er 311 - BOOTP Rel ay Agent s (or BOOTP Gat eway)
Chapt er 312 - Dynamic Host Conf igur at ion Pr ot ocol (DHCP)
Chapt er 313 - DHCP
Chapt er 314 - IP Addr ess Al l ocat ion
Chapt er 315 - DHCP Messages
Chapt er 316 - DHCP Oper at ion
Chapt er 317 - DHCP Responses
Chapt er 318 - Rel easing an IP Addr ess
Chapt er 319 - DHCP Shor t cut s
Chapt er 320 - Lease Dur at ion
Chapt er 321 - Ef f iciencies
Chapt er 322 - Oper at ional Tabl es
Chapt er 323 - RFCs t o Be Reviewed
Chapt er 324 - Resour ce Reser vat ion Pr ot ocol (RSVP)
Chapt er 325 - Al t er nat ives
Chapt er 326 - Wher e It Wil l Be Used
Chapt er 327 - Oper at ion
Chapt er 328 - Pat h Messages
Chapt er 329 - RSVP and Rout er s
Chapt er 330 - RSVP Request s
Chapt er 331 - Reser vat ion St yl e
Chapt er 332 - RSVP Cont r ol
Chapt er 333 - Disabl ing a Reser vat ion
Chapt er 334 - Handl ing Er r or s
Chapt er 335 - Mer ging Fl owspecs
Chapt er 336 - A Simpl e Exampl e
Chapt er 337 - Issues
Chapt er 338 - RSVP Summar y
Chapt er 339 - Concl usion
Chapt er 340 - Simpl e Net wor k Management Pr ot ocol (SNMP)
Chapt er 341 - SNMP El ement s
Chapt er 342 - SNMP Manager
Chapt er 343 - Agent
Chapt er 344 - Management Inf or mat ion Base (MIB)
Chapt er 345 - Exampl e MIB Ent r y
Chapt er 346 - The Pr ot ocol of SNMP
Chapt er 347 - SNMP Encapsul at ion
Index

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Pr evious Tabl e of Cont ent s Next
Acknowledgments
Two peopl e made t his book possibl e, Mar gar et Hendr ey and Mar jor ie Spencer . I pr ovided
t he inf or mat ion, but it was t he cont inuous wor k of t hese t wo t hat pr oduced t his book.
The amount of wor k it t akes t o put somet hing l ike t his t oget her cover s a l ong t ime and
wit hout t hese individual s assist ance, t his book woul d not have been t he same.
How to Use This Book
Wit h t he amount of inf or mat ion we ar e f or ced t o consume ever yday, it woul d be nice
t o simpl y skim over a f ew sent ences in a par agr aph t o get t he key point s of t he t opic.
That is what t he Il l ust r at ed Net wor k books ar e about . Each page has a gr aphic and
concise t ext t hat makes key point s quick t o l ear n and r eview.
Like al l books in t he Il l ust r at ed Net wor k ser ies, t his one is ver y det ail ed, yet it is
wr it t en in way t hat makes it easy t o compr ehend. Eight y per cent of what is commonl y
wr it t en about is f il l er inf or mat ion. What t his book does is ext r act t he t went y per cent
of t he r equir ed inf or mat ion and pl aces t his inf or mat ion in an easy t o use f or mat . A
simil ar f or mat is used quit e of t en wit h t r aining mat er ial . As we al l know, t r aining must
be done is a ver y st r uct ur ed and concise f ashion and it must be del iver ed wit hin a
l imit ed window of t ime. I have t aken t his quick l ear ning concept f ur t her by using a
combinat ion of a t ext book and a t r aining manual pr oducing t he f or mat of t his book.
This book is buil t specif ical l y t o be used as bot h a r ef er ence manual and a t ext book.
Ther e is no r eason t o r ead it f r om cover t o cover . A t opic can simpl y be t ur ned t o and
quickl y l ear ned wit hout having t o r ead t he whol e book.
The back of t he book cont ains a CD. The gr aphics cont aining al l t he key point s of t he
l essons ar e pr ovided on t his CD. You can use t he gr aphics t o cr eat e a cust omized
t r aining sl ide show, or use t hem in a cl assr oom set t ing in conjunct ion wit h t he book.
The f il es ar e in a Micr osof t Power Point pr esent at ion. The ver sion of Power Point used is
Power Point 97. Simpl y st ar t your Power Point appl icat ion and open one of t he f il es on
t he CD cor r esponding t o t he inf or mat ion in t he book.
This book is dedicated to a good friend of mine, for whom I continue to have great admiration. His
tireless instruction of limitless boundaries will forever be remembered. His thoughts and ideas were
given to me years ago, but I continue to use them successfully everyday.
This book is dedicated to John J. (JJ) Anderson.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Part One
I ntroduction to the TCP/I P Protocol
Chapter 1
Transmission Control Protocol/Internet Protocol
The TCP/IP pr ot ocol suit e is being used f or communicat ions, whet her f or voice, video, or
dat a. Ther e is a new ser vice being br ought out f or voice over IP at a consumer cost of 5.5
cent s per minut e. Radio br oadcast s ar e al l over t he Web. Video is coming, but t he images
ar e st il l shaky and must be buf f er ed heavil y bef or e displ aying on t he monit or . However ,
give it t ime. Al l gr eat t hings ar e r ef ined by t ime, and appl icat ions over TCP/IP ar e no
except ion.
Today, you wil l not f ind t oo many dat a communicat ions inst al l ment s t hat have not
impl ement ed or have not t hought about t he TCP/IP pr ot ocol . TCP/IP is becoming so
common t hat it is not so much a mat t er of sel ect ing t he TCP/IP pr ot ocol st ack as it is
sel ect ing appl icat ions t hat suppor t it . Many user s do not even know t hey ar e using t he
TCP/IP pr ot ocol . Al l t hey know is t hat t hey have a connect ion t o t he Web, which many
peopl e conf use wit h t he Int er net . Wel l get int o t he det ail s of t he dif f er ences l at er ,
but f or now, you just need t o under st and t hat t he Web is an application of t he Int er net .
The Web uses t he communicat ions f acil it ies of t he Int er net t o pr ovide f or dat a f l ow
bet ween cl ient s and ser ver s. The Int er net is not t he Web and t he Web is not t he
Int er net .
In t he 1970s, ever yone had some t ype of WANG machine in t heir of f ice. In t he 1980s and
ear l y 1990s, Novel l s Net War e appl icat ions consumed ever y of f ice. Today, Net War e
cont inues t o dominat e t he net wor k ar ena wit h it s inst al l ed based of cl ient /ser ver
net wor k appl icat ions. However , t he TCP/IP pr ot ocol and Int er net br owser s, such as
Net Scapes Navigat or and Micr osof t s Int er net Expl or er , and Web pr ogr amming
l anguages ar e combining t o pr oduce power f ul cor por at e net wor ks known as intranets,
which mimic t he f acil it ies of t he Int er net but on a cor por at e scal e. Int r anet s f r om
dif f er ent companies or simpl y dif f er ent sit es can communicat e wit h each ot her t hr ough
t he Int er net . Consumer s can access cor por at e int r anet s t hr ough an extranet, which is
simpl y par t of t he cor por at e int r anet t hat is avail abl e t o t he publ ic. A gr eat exampl e of
t his is el ect r onic commer ce, which is what you use when you pur chase somet hing via t he
Int er net . Dir ect or y ser vices ar e pr ovided t hr ough Domain Name Ser vices (DNSs)
Micr osyst ems. Fil e and pr int ser vices ar e pr ovided in many dif f er ent ways. Final l y, t he
ul t imat e in f ul l connect ivit y is t he Int er net , which al l ows t he cor por at e int r anet s t o
int er connect (wit hin t he same cor por at ion or dif f er ent cor por at ions), pr oviding gl obal
connect ivit y unmat ched by any net wor k appl icat ion t oday. Ther ef or e, wit hin a shor t
t ime (possibl y 1998), ver y power f ul appl icat ions wil l be buil t t hat ut il ize t he TCP/IP
sof t war e suit e t hat wil l event ual l y r ival Net War e at t he cor e.
Tr ansmission Cont r ol Pr ot ocol /Int er net Pr ot ocol
The pr ot ocol suit e of TCP/IP is becoming t he wor l ds most widel y impl ement ed
net wor k pr ot ocol .
1970sWANG
1980sSNA / Novel l Net War e
1990sNovel l and TCP/IP
TCP/IP combined wit h t he Web br owser is cr eat ing a new t ype of cl ient /ser ver
net wor k oper at ing syst em.
Int r oduct ion (cont inued)
TCP/IP is por t abl e.
Runs on dif f er ent comput er oper at ing syst ems
Addr essing is handl ed on a gl obal assignment
Novel l is suppor t ing TCP/IP.
Nat ive TCP/IP suppor t
Int r aNet War e (nat ive suppor t wit h r el ease 5.0)
Micr osof t is suppor t ing TCP/IP.
Nat ive
Cl ient /ser ver suppor t wit h NT
Anot her key f act or of TCP/IP is extensibility. How many peopl e can you name t hat use
Net War e out of t heir house t o al l ow f or cor por at e connect ivit y or f or commer cial
connect ivit y? Yes, pr ogr ams such as r emot e node and r emot e cont r ol al l ow f or
Net War e cl ient s t o be accessed r emot el y, but not as seaml essl y as wit h TCP/IP. TCP/IP
al l ows you t o move your wor kst at ion t o any par t of t he net wor k, incl uding dial ing in
f r om any par t of t he wor l d, and gain access t o your net wor k or anot her net wor k. This
br ings up anot her point : How many net wor ks int er act using Net War e? Theor et ical l y,
wit h TCP/IP you can access (excl uding secur it y mechanisms f or now) any ot her TCP/IP
net wor k in t he wor l d f r om any point in t he wor l d. Addr essing in TCP/IP is handl ed on a
gl obal scal e t o ensur e uniqueness. Novel l at t empt ed gl obal addr essing but f ail ed.
Novel l addr esses ar e unique t o each pr ivat e inst al l at ion, such as a singl e company, but
ar e pr obabl y massivel y dupl icat ed when t aken as a whol e (al l inst al l at ions). I know
many inst al l at ions wit h t he Novel l addr ess of 1A somewher e in t heir net wor k. Not
ever yone is going t o r enumber t heir net wor k f or uniqueness, but one t r ick is t o mat ch
t he 32bit addr ess of TCP/IP subnet s t o your Novel l net wor k. Conver t each oct et of t he
32bit addr ess of TCP/IP int o hex and use t hat as your Net War e addr ess.
Novel l has ent er ed t he TCP/IP f r ay wit h it s Int r anet War e and suppor t f or nat ive IP.
Int r aNet War e al l ows Net War e wor kst at ions t o access TCP/IP r esour ces. As of ver sion
5.0, Int r aNet War e is going away in name onl y and anot her ver sion of Net War e is
supposed t o al l ow f or Net War e t o r un dir ect l y on t op of TCP/IP (t his is known as nat ive
TCP/IP suppor t ).
Micr osof t and it s emer ging NT pl at f or m can al so use TCP/IP as a net wor k pr ot ocol . Two
f l avor s ar e avail abl e:
Nat ive TCP/IP and it s appl icat ions (TELNET, FTP, et c.)
RFC compl iant (RFC 1001 and 1002) TCP, which al l ows f il e and pr int ser vice
This enabl es t he abil it y t o t el net f r om an NT ser ver or wor kst at ion and t r ansf er f il es
t o t hat wor kst at ion or ser ver using nat ive TCP/IP. For f il e and pr int ser vices in a TCP/IP
envir onment , NT can be conf igur ed t o use Net BIOS over TCP/IP. This enabl es NT t o be
invol ved in a r out ed net wor k. NT can r un many ot her pr ot ocol s as wel l , but t hat is
beyond t he scope of t his book.
Int r oduct ion (cont inued)
Novel l cont inues t o dominat e t he cl ient /ser ver envir onment .
Mainf r ames ar e cont inual l y upgr aded and being used mor e of t en.
Web int er f aces t o mainf r ame dat a
Some mainf r ame f unct ions have been conver t ed t o Unix pl at f or ms
TCP/IP is an ext ensibl e pr ot ocol
However , t his does not mean t hat t he ot her pr ot ocol s (beyond TCP/IP) ar e being
disbanded. Novel l Net War e cont inues t o r un wit h t he IPX pr ot ocol . As of t his wr it ing,
Net War e is st il l t he best const r uct ed cl ient ser ver pl at f or m avail abl e. Tens of
t housands of pr ogr ams have been wr it t en dir ect l y t o t he Net War e int er f ace and it is
used in cor por at e net wor ks, school s, and st at e, l ocal , and f eder al gover nment s. These
user s ar e not going t o disconnect t heir Net War e net wor ks and move t o TCP/IP over
night . Net War e wil l be ar ound f or a gr eat l engt h of t ime, al beit in a diminishing r ol e
(st ar t t he ar gument s!).
Most For t une 1000 companies st il l depend on l ar ge mainf r ames f or t heir dayt oday
pr ocessing. The ear l y 1990s and l at e 1980s wer e int er est ing t imes when many
cor por at ions wer e convinced t hat smal l er Unix pl at f or ms using a dist r ibut ed
(cl ient /ser ver ) ar chit ect ur e coul d r epl ace t heir ant iquat ed SNA net wor ks. Wr ong!
Al t hough some net wor ks have conver t ed t o t his ar chit ect ur e, many have not . Ther e
ar e many f act or s invol ved her e. Time and money pl ay an impor t ant r ol e, but t he r ul e
cont inues t o be, if it aint br oke, dont f ix it . Huge appl icat ions such as t he air l ine
r eser vat ion syst em and t he banking syst em ar e buil t using t he SNA ar chit ect ur e, and
even if a per f ect sol ut ion is f ound, it wil l t ake year s t o conver t t hese pr ogr ams over t o
a new syst em. SNA is st il l being used, and I have even suppor t ed some sit es t hat have
r ever t ed back t o SNA mainf r ames, which wer e best suit ed t o t heir par t icul ar sit uat ion.
Today, t her e ar e Web ser ver s t hat f r ont IBM mainf r ames as wel l . IBM f ul l y suppor t s
t he TCP/IP pr ot ocol s and t her e is a 3270 t er minal emul at ion pr ogr am known as TN3270
t hat al l ows f or 3270 t er minal emul at ion over t he TCP/IP pr ot ocol . Al l of t his is beyond
t he scope of t his book, but r emember , TCP/IP is ver y popul ar ; however , pr ot ocol schemes
ar e st il l in exist ence, st il l pr ovide many benef it s, and wil l cont inue t o be used f or year s
t o come.
Fr om t his, one woul d t end t o t hink t hat t he TCP/IP pr ot ocol was devel oped by a
l ar gescal e R&D cent er l ike t hat of IBM or DEC. It wasnt . It was devel oped by a t eam
of r esear cht ype peopl e, compr ised of col l ege pr of essor s, gr aduat e st udent s, and
under gr aduat e st udent s f r om major univer sit ies. This shoul d not be har d t o bel ieve.
These individual s ar e t he t ype who not onl y enjoy R&D wor k, but al so bel ieve t hat ,
when pr obl ems occur , t he f un st ar t s.
Many year s f r om now we wil l l ook back on t he TCP/IP pr ot ocol as t he pr ot ocol t hat
pr ovided t he buil ding bl ocks of f ut ur e dat a communicat ions. However , t ake not ice:
TCP/IP is an ext ensibl e pr ot ocol . It is f ul l y f unct ional t oday, but t he wor k on t he
pr oject cont inues. Ther e ar e over 75 wor king gr oups of t he Int er net Engineer ing Task
For ce (IETF, expl ained in a moment ), and as new needs cont inue t o ar ise f or t he Int er net ,
new wor king gr oups ar e f or med and new pr ot ocol s wil l emer ge. In f act , t he IP ver sion of
t he exist ing pr ot ocol (known as IPv4, or IP ver sion 4) wil l be r epl aced. IP ver sion 6 (IPv6)
is cur r ent l y being impl ement ed ar ound t he Int er net . It wil l be a f ew year s bef or e a
compl et e swit chover t akes pl ace, but it is a gr eat exampl e of t he ext ensibl e pr ot ocol .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 2
TCP/IP and Other Protocols
Whil e t he ARPAnet (and l at er t he Int er net ) was being buil t , ot her pr ot ocol s such as
Syst em Net wor k Ar chit ect ur e (SNA) and pr ot ocol s based on XNS (t her e ar e many
pr opr iet ar y ver sions) pr evail ed. Cl ient /ser ver appl icat ions t hat al l owed f or f il e and
pr int ser vices on per sonal comput er s wer e buil t using pr ot ocol s based on XNS such as
Novel l Net War e (using IPX) and Banyan VINES. SNA was al ive and wel l in t he
mainf r ame, and DECnet cont r ol l ed t he minicomput er mar ket pl ace. DEC al so suppor t ed
LAT (Local Ar ea Tr anspor t ) f or t er minal ser ver s, which suppor t ed pr int er s as wel l .
DECnet st ar t ed out bef or e commer cial Et her net , and DECs minicomput er s wer e
connect ed t oget her via l ocal int er f aces. Lat er , ar ound 1982, DEC st ar t ed t o suppor t
Et her net but st il l wit h t he DECnet pr ot ocol .
TCP/IP and Ot her Pr ot ocol s
ARPAnet buil t at t he same t ime as SNA and XNS net wor ks.
XNS suppor t ed Novel l , Banyan, and most ot her net wor king devices.
WAN access l imit ed t o X.25 and vendor pr opr iet ar y sol ut ions.
DEC cont inued t o suppor t DECnet /LAT.
LAN media as Et her net , Token Ring, and FDDI.
Al l of t hese pr ot ocol s coul d r un over Et her net , Token Ring, or FDDI. In t his r espect ,
t hey did openl y suppor t t he LAN pr ot ocol . However , disr egar ding t he LAN pr ot ocol ,
t hese pr ot ocol s wer e pr opr iet ar y; in ot her wor ds, vendor dependent. However , ot her
pr ot ocol s beyond TCP/IP ar e pr opr iet ar y, and t he int er nal s of t hose syst ems ar e known
onl y t o t heir r espect ive company owner s. User s and net wor k administ r at or s wer e hel d
t o pr opr iet ar y net wor k envir onment s and pr opr iet ar y net wor k appl icat ions, which
det er r ed net wor k devel opment and enhancement in al l cor por at e envir onment s. Just
because a vendor suppor t ed XNS, did not mean t hat it woul d int er oper at e wit h ot her
vendor s r unning XNS. Running XNS on one syst em did not guar ant ee compat ibil it y of
communicat ion t o any ot her syst em except f or t he same vendor s. This was good f or t he
vendor , but it t ended t o l ock user s int o one vendor .
The onl y publ ic Wide Ar ea Net wor k (WAN) access was X.25, and not ever yone suppor t ed
al l f eat ur es 100 per cent , which l ead t o compat ibil it y pr obl ems. Al l of us r emember X.25
as a sl ow (pr imar il y 9.6 kbps or 19.2 kbps) WAN access pr ot ocol . (This is not bashing t he
X.25 pr ot ocol . Ther e wer e many val id r easons f or r unning it at t he sl ower net wor k
speeds, l ike er r or cor r ect ion and cont r ol , and f ast er speeds such as T1 wer e not
avail abl e f or dat a connect ion t r ansf er s.)
Al t er nat ivel y, l eased l ines based on pr opr iet ar y pr ot ocol s of t he net wor k vendor s
wer e an opt ion, but t hat onl y al l owed t he cor por at e net wor ks t o be int er connect ed.
Et her net was al so avail abl e, but host int er f aces and st andar dized net wor k pr ot ocol s
wer e not r eadil y avail abl e.
The Int er net st ar t ed as a r esear ch f acil it y and t o l ink t he gover nment t o t he r esear ch
f acil it ies as wel l . It r emained t his way unt il about 1992. Onl y a handf ul of peopl e knew
about t he Int er net , and t he Int er net had not hing r eal l y t o of f er t he commer cial
wor l d. Engineer s and scient ist s l oved t he Int er net . No one knew of t he advant ages of
t he TCP/IP pr ot ocol . It was not unt il t he GUI int er f ace was devel oped t hat t he
Int er net t ook of f , and t he TCP/IP pr ot ocol came wit h it . Ther ef or e ot her pr ot ocol s such
as SNA and Novel l Net War e spr out ed in cor por at e Amer ica. Basical l y, t her e was no
ot her choice.
One of t he bet t er pr ot ocol s was Appl eTal k. Much l ike a Macint osh comput er , it was
ver y cost l y t o impl ement . Ser iousl y, I happen t o l ike t he Appl eTal k pr ot ocol . Appl eTal k
was act ual l y t he sof t war e and Local Tal k was t he har dwar e. It was Appl es ver sion of
net wor king Mac comput er s, and, except f or t he wir ing, it was f r ee. The pr ot ocol was
simpl e t o inst al l and use. It was buil t int o ever y Mac. Cabl es wer e simpl y needed t o
hook up Appl e comput er s t o a simpl e net wor k, and f il e and pr int ser vices wer e buil t in as
wel l . It was known as t r ue peer t opeer , f or each wor kst at ion coul d see ever y ot her
wor kst at ion, and each wor kst at ion coul d be a ser ver and shar e any of it s r esour ces.
Each node r an t he name ser vice. Each node picked it s own physical addr ess. Even dial ing
in t o an Appl eTal k net wor k was easy using t he Appl eTal k Remot e Access (ARA)
pr ot ocol , and it made it l ook l ike you wer e a l ocal node on t he Appl eTal k net wor k. It
soon became a ver y popul ar met hod of hooking t oget her Mac comput er s int o a net wor k.
However , Appl eTal k was not envisioned as a pr ot ocol t o handl e l ar ge int er net s of
Appl e comput er s, and t he inef f iciencies of t he pr ot ocol soon ar ose. It was about as cl ose
as you coul d come t o a net wor k oper at ing syst em t hat al l owed f or simpl icit y and
ingenuit y. Appl eTal k had one pr obl em: scal abil it y. Tr y buil ding a l ar ge Appl eTal k
net wor k, not an easy t ask, if not impossibl e.
TCP/IP el iminat ed pr opr iet ar y net wor k oper at ing syst ems; however , not int ent ional l y.
Again, it was buil t f or a dif f er ent pur pose. TCPs beginnings wer e r ough
(int er oper abil it y issues) and, in f act , TCP/IP was not t he or iginal pr ot ocol of t he
ARPAnet . But t he pr ot ocol st abil ized and t he int er oper abil it y bet ween dif f er ent
comput er s and oper at ing syst ems became a r eal it y. For exampl e, a DEC syst em r unning
t he VMS oper at ing syst em combined wit h TCP/IP r unning as t he net wor k oper at ing
syst em can communicat e wit h a Sun Micr osyst ems Unix wor kst at ion r unning TCP/IP. The
t wo syst ems can communicat e by t aking advant age of t he pr ot ocol and t he specif ic
appl icat ions wr it t en f or t he pr ot ocol , pr imar il y by being abl e t o l og on t o one anot her
and t r ansf er f il es bet ween t he t wo acr oss a net wor k.
Ot her Pr ot ocol s (cont inued)
Appl eTal k (sof t war e) and Local Tal k (har dwar e) wer e buil t int o ever y Mac.
Ver y r obust pr ot ocol but not scal abl e
Each node had a naming ser vice
Net wor k IDs wer e dynamic (seed r out er )
Node IDs wer e dynamic
Remot e access was f ul l y int egr at ed as a r emot e node
TCP/IP el iminat ed t he pr ol if er at ion of pr opr iet ar y net wor k oper at ing syst ems.
Any har dwar e and sof t war e pl at f or m coul d communicat e
TCP/IP was compl et el y open t o any vendor t o wr it e code t o.
TCP/IP is t he pr ot ocol of choice f or f ut ur e net wor k syst ems.
When int er connect ing comput er s and t heir oper at ing syst ems wit h TCP/IP, it does not
mat t er what t he har dwar e ar chit ect ur e or t he oper at ing syst ems of t he comput er s ar e.
The pr ot ocol wil l al l ow any comput er impl ement ing it t o communicat e wit h anot her .
The met hods used t o accompl ish t his ar e discussed in t he f ol l owing sect ions.
Suf f ice it t o say, t he TCP/IP pr ot ocol is t he pr ot ocol of choice f or f ut ur e net wor k
inst al l at ions.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 3
The Origins of TCP/IP
The Or igins of TCP/IP
A TCP/IP net wor k is het er ogeneous.
Popul ar it y due t o:
Pr ot ocol suit e par t of t he Ber kel ey Unix oper at ing syst em
Col l ege st udent s wor ked wit h it and t hen t ook it t o cor por at e
Amer ica
In 1983, al l gover nment pr oposal s r equir ed TCP/IP
The Web gr aphical user int er f ace
TCP/IP has t he ingenious abil it y t o wor k on any oper at ing pl at f or m.
TCP/IP has easy r emot e access capabil it ies.
A TCP/IP net wor k is gener al l y a het er ogeneous net wor k, meaning t her e ar e many
dif f er ent t ypes of net wor k comput ing devices at t ached. The suit e of pr ot ocol s t hat
encompass TCP/IP wer e or iginal l y designed t o al l ow dif f er ent t ypes of comput er syst ems
t o communicat e as if t hey wer e t he same syst em. It was devel oped by a pr oject
under wr it t en by an agency of t he Depar t ment of Def ense known as t he Advanced
Resear ch Pr oject s Agency (DARPA).
Ther e ar e many r easons why t he ear l y TCP/IP became popul ar , t hr ee of which ar e
par amount . Fir st , DARPA pr ovided a gr ant t o al l ow t he pr ot ocol suit e t o become par t of
Ber kel eys Unix syst em. When TCP/IP was int r oduced t o t he commer cial mar ket pl ace,
Unix was al ways ment ioned in ever y st or y about it . Ber kel ey Unix and TCP/IP became
t he st andar d oper at ing syst em and pr ot ocol of choice f or many major univer sit ies,
wher e it was used wit h wor kst at ions in engineer ing and r esear ch envir onment s. Second,
in 1983, al l U.S. gover nment pr oposal s t hat incl uded net wor ks mandat ed t he TCP/IP
pr ot ocol . (This was al so t he year t hat t he ARPAnet was conver t ed t o t he TCP/IP
pr ot ocol . Conver sions in t hose days happened wit hin days. That was when t he Int er net
was smal l .)
And t hir d, a gr aphical user int er f ace was devel oped t o al l ow easy access wit h t he
syst em. TCP/IP or it s appl icat ions can be a dif f icul t pr ot ocol t o use if you have not had
exper ience wit h it . Finding inf or mat ion on t he Int er net was a f or midabl e t ask. Bef or e
t he br owser , TCP/IP appl icat ions wer e accessed f r om a command l ine int er f ace wit h a
f ew basic appl icat ions t hat al l owed you t o cal l a r emot e syst em and act as a r emot e
t er minal , t r ansf er f il es, and send and r eceive mail . Some companies of t hese appl icat ions
buil t gr aphical int er f aces t o t he appl icat ions, but t hey wer e st il l r ough and woul d not
have gained commer cial success. The br owser hid al l t he compl exit ies of t he TCP/IP
pr ot ocol and it s appl icat ions and al l owed f or gr aphics t o appear as wel l as t ext , and by
cl icking on eit her t he gr aphics or t ext , we coul d pl ace our sel ves anywher e on t he
Int er net (wit hin secur it y r easons!). It al so al l owed f or easier access t o inf or mat ion on
t he Int er net .
Based on t hose point s, it was not ver y l ong bef or e ever yone knew of t he capabil it y of
t he pr ot ocol t o al l ow dissimil ar syst ems t o communicat e t hr ough t he net wor kal l
t his wit hout a f or kl if t upgr ade t o mainf r ames, minis, and per sonal comput er s. It simpl y
bol t ed on t o exist ing comput er devices. TCP/IP became a ver y popul ar net wor k oper at ing
syst em t hat cont inues t oday.
TCP/IP or iginat ed when DARPA was t asked t o br ing about a sol ut ion t o a dif f icul t
pr obl em: al l owing dif f er ent comput er s t o communicat e wit h one anot her as if t hey wer e
t he same comput er . This was dif f icul t , consider ing t hat al l comput er ar chit ect ur es in
t hose days (t he ear l y 1970s) wer e highl y guar ded secr et s. Comput er manuf act ur er s
woul d not discl ose eit her t heir har dwar e or sof t war e ar chit ect ur es t o anyone. This is
known as a closed or proprietary syst em.
The ar chit ect ur e behind TCP/IP t akes an al t er nat ive appr oach. TCP/IP devel oped int o an
ar chit ect ur e t hat woul d al l ow t he comput er s t o communicat e wit hout gr ossl y
modif ying t he oper at ing syst em or t he har dwar e ar chit ect ur e of t he machine. TCP/IP
r uns as an appl icat ion on t hose syst ems.
However , bef or e TCP/IP, t he or iginal r esul t was known as t he Net wor k Cont r ol
Pr ogr am (NCP). The pr ot ocol was devel oped t o r un on mul t ipl e host s in geogr aphical l y
disper sed ar eas t hr ough a packet swit ching int er net known as t he Advanced Resear ch
Pr oject Agency net wor kARPAnet . This pr ot ocol was pr imar il y used t o suppor t
appl icat ionor ient ed f unct ions and pr ocesst opr ocess communicat ions bet ween t wo
host s. Specif ic appl icat ions, such as f il e t r ansf er , wer e wr it t en t o t his net wor k
oper at ing syst em. The ARPAnet was t aken down in 1993. The Int er net t hat we r un t oday
was buil t dur ing t he ARPAnet t ime, but as a par al l el net wor k.
In or der t o per pet uat e t he t ask of al l owing dissimil ar gover nment comput er s t o
communicat e, DARPA gave r esear ch gr ant s t o t he Univer sit y of Cal if or nia at Los
Angel es (UCLA), t he Univer sit y of Cal if or nia at San Ber nadino (UCSB), t he St anf or d
Resear ch Inst it ut e (SRI), and t he Univer sit y of Ut ah. A company cal l ed BBN pr ovided
t he Honeywel l 316 Int er f ace Message Pr ocessor s (IMPs, which have evol ved int o t odays
r out er s), which pr ovided t he int er net communicat ions l inks. In 1971, t he ARPAnet
Net wor king Gr oup dissol ved, and DARPA t ook over al l t he r esear ch wor k. The f ir st f ew
year s of t his design pr oved t o be an ef f ect ive t est , but had some ser ious design f l aws, so
a r esear ch pr oject was devel oped t o over come t hese pr obl ems. The out come of t his
pr oject was a r ecommendat ion t o r epl ace t he or iginal pr ogr am known as NCP wit h
anot her cal l ed Tr ansmission Cont r ol Pr ogr am (TCP). Bet ween t he year s of 19751979,
DARPA had begun t he wor k on t he Int er net t echnol ogy, which r esul t ed in t he TCP/IP
pr ot ocol s as we know t hem t oday. The pr ot ocol r esponsibl e f or r out ing t he packet s
t hr ough an int er net was t er med t he Internet Protocol. Today, t he common t er m f or t his
st andar d is TCP/IP.
Or igins (cont inued)
Wit h TCP/IP r epl acing NCP, t he NCP appl icat ionspecif ic pr ogr ams wer e conver t ed t o
r un over t he new pr ot ocol . The pr ot ocol became mandat ed in 1983, when ARPA
demanded t hat al l comput er s at t ached t o t he ARPAnet use t he TCP/IP pr ot ocol .
In 1983, t he ARPAnet was spl it int o t wo net wor ks: t he Def ense Dat a Net wor k (DDN),
al so known as t he MILNET (mil it ar y net wor k), and t he DARPA Int er net , a new name f or
t he ol d ARPAnet net wor k.
Out side of t he ARPAnet , many net wor ks wer e being f or med, such as CSNET (Comput er
Science Net wor k); BITNET (Because It s Time Net wor k) used bet ween IBM syst ems; UUCP
(User t o User Copy), which became t he pr ot ocol used on USENET (a net wor k used f or
dist r ibut ing news); and many ot her s. Al l of t hese net wor ks wer e based on t he TCP/IP
pr ot ocol , and al l wer e int er connect ed using t he ARPAnet as a backbone. Many ot her
advances wer e al so t aking pl ace wit h Local Ar ea Net wor ks using Et her net , and
companies began making equipment t hat enabl ed any host or t er minal t o at t ach t o t he
Et her net . The or iginal r out e messenger s, known as IMPs (Int er f ace Message Pr ocessor s),
wer e now being made commer cial l y and wer e cal l ed routers. These r out er s wer e smal l er ,
cheaper , and f ast er t han t he ARPAnet s IMPs, and t hey wer e mor e easil y maint ained.
Wit h t hese devices, r egional net wor ks wer e buil t and coul d now hook up t o t he
Int er net . However , commer cial access t o t he Int er net was st il l ver y l imit ed.
In 1983, ARPAnet was spl it int o t wo net wor ks.
Def ense Dat a Net wor k (DDN) or MILNET
The DARPA Int er net new name f or t he ARPAnet
In 1985, NSFnet was est abl ished t o al l ow f ive super comput er sit es t o be
accessed by scient ist s.
Out side t he ARPAnet , many r egional net wor ks based on TCP/IP wer e buil t .
CSNET (Comput er Science Net wor k)
BITNET (Because It s Time Net wor k, IBM)
UUCP (User t o User Copy), which became USEnet
Al l wer e connect ed via t he ARPAnet backbone.
Or iginal r out er s wer e cal l ed Int er f ace Message Pr ocessor s (IMPs).
One exper iment t hat was successf ul , CSNET (comput er science net wor k), pr ovided t he
f oundat ion f or t he NSF t o buil d anot her net wor k t hat int er connect ed f ive
super comput er sit es. The f ive sit es wer e int er connect ed via 56kbps l ines. This was
known as NSFnet . However , t he NSF al so st at ed t hat if an academic inst it ut ion buil t a
communit y net wor k, t he NSF woul d give it access t o t he NSFnet . This woul d al l ow bot h
r egional access t o t he NSFnet and t he r egional net wor ks (based on t he TCP/IP
pr ot ocol ) t o communicat e wit h one anot her . The NSFnet was f or mal l y est abl ished in
1986. It buil t a l ar ge backbone net wor k using 56kbps l inks, which wer e l at er upgr aded
t o T1 l inks (Jul y 1988). Anyone who coul d est abl ish a physical l ink t o t he NSFnet
backbone coul d gain access t o it . In 1990, t he NSFnet was upgr aded t o 45Mbps l inks.
Once t he wor d of NSFnet spr ead, many r egional net wor ks spr ang up, such as NYSERnet
(New Yor k St at e Educat ional Resear ch Net wor k), CERFnet (named f or Cal if or nia
Educat ional Resear ch Net wor k and not Vint Cer f ), and ot her s. The r egional net wor ks
wer e suppor t ed at t heir l evel and not by t he NSF.
The NSFnet was f ound t o be ver y usef ul beyond it s concept ion of l inking
super comput er s t o academic inst it ut ions. In 1987, NSF awar ded a cont r act t o MERIT
Net wor k (al ong wit h IBM and MCI) t o upgr ade t he NSFnet t o T1 and t o l ink six
r egional net wor ks, t he exist ing f ive super comput er cent er s, MERIT, and t he Nat ional
Cent er f or At mospher ic Resear ch int o one backbone. This was compl et ed in Jul y 1988. In
1989, a nonpr of it or ganizat ion known as ANS (Advanced Net wor k and Ser vices, Inc.) was
spun of f f r om t he MERIT t eam. It s goal was t o upgr ade t he NSFnet t o a 45Mbps
backbone and l ink t oget her 16 r egional sit es. This was compl et ed in November 1991.
Mor e commer cial ent it ies wer e spr inging up buil ding r egional net wor ks via TCP/IP as
wel l . To al l ow t hese ent it ies access t o t he backbone, a concept known as t he
Commer cial Int er net eXchange (CIX) was buil t . This was a point on t he backbone t hat
al l owed commer cial r egional net wor ks access t o t he academic NSFnet backbone.
The or iginal ARPAnet was expensive t o r un and int er est inside DARPA began t o wane.
Major pr omot er s of t he ARPAnet had l ef t DARPA t o t ake posit ions el sewher e. It was
t aken compl et el y out of ser vice in 1989, and what emer ged in it s pl ace is what we know
as t he Int er net . The t er m Internet was coined as an abbr eviat ion t o t he Int er net
Pr ot ocol (IP).
The or iginal ARPAnet was t aken out of ser vice in 1989.
Int er net backbone suppor t ed by NSFnet using 56kbps l ines.
NSFnet upgr aded t o 45Mbps backbone.
In 1993, NSF gr ant ed out t he oper at ion of t he backbone t o var ious companies
t o cont inue r unning it .
Most oper at ions of t he Int er net ar e r un by pr ivat e companies and not t he
gover nment .
The NSFnet was basical l y a mir r or image of t he ARPAnet , and t hey wer e r unning in
par al l el . Regional net wor ks based on t he TCP/IP pr ot ocol wer e int er connect ed via
NSFnet , which had connect ions t o t he ARPAnet . Mor e connect ions wer e being made
t hr ough NSFnet because it was higher speed, easier t o hook int o, and l ess expensive.
It was det er mined t hat t he or iginal net wor k, t he ARPAnet , shoul d be shut down. Sit es
on t he ARPAnet f ound new homes wit hin t he r egional net wor ks or as r egional
net wor ks. NSFnet pr ovided t he backbone f or int er connect ion of t hese r egional
net wor ks.
Today, any company can buil d a backbone based on TCP/IP.
Connect ions t o ot her backbones ar e pr ovided t hr ough peer ing point s known as
Net wor k Access Point s (NAPs).
Int er net Ser vice Pr ovider s al l ow f or anyone t o connect t o t he Int er net
t hr ough Point s of Pr esence (POPs).
Essent ial l y, a l ocat ion in any cit y t hat can accept a phone cal l f r om a
user s modem. The l ine is t hen connect ed t o a net wor k t hat pr ovides
access t o t he Int er net .
Running TCP/IP does not r equir e access t o t he Int er net .
Wor d quickl y spr ead about t he Int er net and ar ound 1993, and NSF decided it coul d not
cont inue suppor t ing t he r apid expansion dir ect l y and pr oduced cont r act s f or
out sour cing t he cont inuat ion of t he Int er net . Many companies r esponded t o t he cal l ,
and t he f unct ional r esponsibil it ies of r unning t he Int er net wer e given t o many
dif f er ent companies. In pl ace of t he NSFnet woul d be a concept cal l ed Network Access
Points, point s l ocat ed t hr oughout t he Unit ed St at es t hr ough which companies t hat
buil t t heir own backbones coul d int er connect and exchange r out e pat hs. Al so wit h t his
came t he concept of peering. NAPs pr ovided access t o ot her backbones, and by peer ing
wit h anot her backbone pr ovider , a pr ovider al l owed t heir backbone t o be used by
anot her pr ovider t o move t heir cust omer s t r af f ic. Ther e was a l ot of cont r over sy wit h
t his concept : Who shoul d a backbone pr ovider peer wit h or not peer wit h? Why shoul d a
pr ovider l et anot her pr ovider use it s backbone as a t r ansit f or it s cust omer s f or f r ee?
The answer : because NSF st at ed t his and t he issue was t abl ed.
NAPs ar e basical l y t he highest point in t he Int er net . In t his way, many backbones woul d
be pr ivat el y buil t , and al l woul d be int er connect ed t hr ough t he NAPs. Init ial l y, t her e
wer e f our of f icial NAPs, but t his number has gr own by an addit ional 13 (wit h mor e being
added) as of t his wr it ing. Even wit h t he commer cial izat ion of t he Int er net , no one
company owned any par t of t he Int er net , and ever yone associat ed wit h t he Int er net
had t o abide by t he r ul es in pl ace. Ext er nal companies simpl y pr ovided a specif ic ser vice
r equir ed t o r un t he Int er net . For exampl e, Net wor k Sol ut ions, Inc. was gr ant ed t he
r ight t o cont r ol t he domain name r egist r at ion. However , it does not own t his capabil it y.
Net wor k Sol ut ions is st il l under t he aut hor it y of t he Int er net Assigned Number s
Aut hor it y r un by Jon Post el (as of t his wr it ing) at t he Univer sit y of Sout her n
Cal if or nia. AT&T was gr ant ed t he r ight t o host many document dat abases r equir ed by
t he Int er net user communit y. Event ual l y, al l t he f unct ions of r unning t he Int er net
wer e cont r act ed out by NSF. Any company (wit h l ot s of money) can buil d a backbone. To
pr ovide access t o ot her s, it s backbone must be connect ed t o ot her s at t he NAP.
Individual backbone pr ovider s t hen int er connect mul t ipl e connect ions known as Point s
of Pr esence, or POPs, which ar e wher e t he individual user or business connect s t o t he
Int er net . In Apr il of 1995, t he NSFnet backbone was shut down, and t he Int er net was up
and r unning as we know it t oday.
One l ast dist inct ion of TCP/IP: Running t he pr ot ocol on any net wor k does not r equir e a
connect ion t o t he Int er net . TCP/IP may be inst al l ed on as f ew as t wo net wor k st at ions
or on as many as can be addr essed (possibl y mil l ions). When a net wor k r equir es access t o
t he Int er net , t he net wor k administ r at or must cal l his or her l ocal r egist r y (or
Int er net Ser vice Pr ovider [ISP]) t o pl ace a r equest f or access and be assigned an of f icial
IP addr ess.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 4
The World Wide Web
Gr eat appl icat ion pr ogr ams and int er communicat ion have been avail abl e on t he
Int er net f or dozens of year s, so why al l t he hype since 1994? The Web came t o us in 1994
(commer cial l y) and al l owed f or ever yone t o wor k on t he Int er net , even t hough many
had no idea what t hey wer e wor king on. The br owser became t he int er f ace, a
simpl et ouse int er f ace, and t his was t he st ar t of t he commer cial izat ion of t he Web.
This is when cor por at e money became invol ved. However , t he idea st ar t ed out way
back in 1981 wit h a pr ogr am cal l ed Enquir e, devel oped by Tim Ber ner sLee. A pr ogr am
known as Mosaic was r el eased in November 1993 as f r eewar e wr it t en by t he cof ounder
of Net Scape, Mar c Andr eeson, at t he U.S. Nat ional Cent er f or Super comput er
Appl icat ions (NCSA). Mosaic al l owed t ext and gr aphics on t he same Web page and was
t he basis f or Net Scapes Navigat or br owser and Micr osof t s Int er net Expl or er .
Fir st and f or emost , t he Web al l ows anyone, especial l y nont echnical peopl e, inst ant
access t o an inf init e amount of inf or mat ion. You can get st ock r epor t s, inf or mat ion
f r om a l ibr ar y, or der a book, r eser ve air l ine t icket s, page someone, f ind t hat l ongl ost
f r iend t hr ough t he yel l ow pages, or der a dat a l ine f or your house, check your cr edit
car d st at ement , check on t he avail abil it y of t hat oneandonl y car , pr ovide
comput er based t r aining, or at t end a pr ivat e (video and audio) meet ing. And yes, you can
send an email .
Al l t his and st il l mor e! Unl ike ot her onl ine ser vices such as CompuSer ve, Pr odigy, and
Amer ica Onl ine (at t he t ime), anyone can cr eat e a Web page as wel l not t oo har d t o
do, t he l anguage t o cr eat e a Web page is pr et t y much Engl ish. Mil l ions of ideas ar e
avail abl e, and t her e is a pul l down menu in t he br owser t hat al l ows you t o see t he
sour ce code (t he basic inst r uct ions t hat t el l t he Web ser ver how t o f or mat a page) of
any Web page. By 1995, companies known as Int er net Ser vice Pr ovider s (ISPs) wer e
adver t ising t heir abil it y t o put you on t he Web f or a l ow pr ice of $19.95. In f act , t oday,
most pr of essional ISPs give you space on t heir ser ver s (a smal l amount , but enough t o
get st ar t ed) f or you t o cr eat e your Web page, at no char ge!
Point and cl ick t o access any inf or mat ion t hat you woul d l ike; you do not have t o know
an oper at ing syst em t o move ar ound t he Web. No ot her cyber space pr ovider has t he
r ich simpl icit y of t he br owser . One cl ick and you can be on a ser ver in Japan, video
conf er ence t o Cal if or nia, send an email t o your f r iend in Engl and, or pl an a vacat ion
t o Br eckenr idge, Col or ado. Ot her onl ine pr ovider s had inf or mat ion, but it was t he
simpl icit y and combinat ion of t ext and st il l pict ur es on t he same page t hat cat apul t ed
t he Web int o ever y home.
Vir t ual l y anyt hing t hat you want t o check on, you can do on t he Web and you do not
have t o r emember IP addr esses, dir ect or y commands f or DOS and Unix, f il e compr ession,
execut ing t he TAR command, pr int ing t o a post scr ipt pr int er , and so on. Simpl y st at ed,
t he Web al l ows ever yone access t o net wor k dat a wit h a simpl e cl ick of t he mouse.
The Wor l d Wide Web
On t he appl icat ion f r ont , mor e and mor e appl icat ions ar e being wr it t en t owar ds (or
have embedded) t he most common Int er net int er f ace: a br owser . A br owser al l ows t he
Int er net t o be accessed gr aphical l y using icons and pict ur es and a special t ext l anguage
known as Hyper t ext Mar kup Language, or HTML. For pl at f or m independence in wr it ing
appl icat ions f or t he Web, t he Java l anguage was cr eat ed.
What is t he downf al l of t he Int er net ? No, connect ivit y is gener al l y not t he pr obl em.
ISPs can be a pr obl em, but even t hey ar e manageabl e. The biggest pr obl em wit h t he
Int er net is it s biggest asset : inf or mat ion.
You may f ind your sel f scr at ching your head whil e t r avel ing t he Int er net . Anyone can
cr eat e cont ent and post it , so t her e is a l ot of ol d inf or mat ion on t he Int er net . Web
pages ar e not kept up. Web pages ar e not wr it t en cor r ect l y and cont ain t oo many
sl owl oading gr aphics. Many l inks t hat ar e embedded in ot her Web pages no l onger
exist . Inf or mat ion is post ed wit hout having val idit y checks. Remember , no one ent it y
owns t he Int er net or t he Web appl icat ion.
Some companies wit h Web pages ar e no l onger ar ound. Al l Web pages ar e not cr eat ed
equal ; some t ake an et er nit y t o wr it e t o your br owser , whil e ot her s t ake a minimal
amount of t ime. Al so, al l ISPs ar e not cr eat ed equal . An ISP is your connect ion t o t he
Int er net . Test out your ISP f or ser vice and connect ivit y. I r ecent l y swit ched f r om a
major ISP t o a l ocal ISP and f ound 4x impr ovement in speed. However , t he l ocal ISP does
not pr ovide nat ional ser vice (l ocal phone number s ar ound t he Unit ed St at es). So when I
st ar t ed t r avel ing, I swit ched t o anot her ISP t hat has bot h nat ional cover age and speed.
The Web (cont inued)
The biggest asset of t he Web is it s biggest downf al l :
Inf or mat ion
Ther e is a t r emendous amount of inf or mat ion on t he Web.
Inf or mat ion on t he Web can be post ed by anyone.
However :
Many Web pages ar e not kept up
Many ar e not wr it t en cor r ect l y (minut es t o buil d a scr een)
Inf or mat ion is ol d and out of dat e
Inf or mat ion is not document ed
Incr edibl y har d t o sear ch f or simpl e it ems due t o mor e t han 50 mil l ion
Web sit es avail abl e
Sear ch engines br ing back many undesir ed Web pages which r equir e
advanced sear ching t echniques
Be car ef ul when scr ut inizing t he Int er net . Make sur e t he dat a is r eput abl e (i.e., can be
ver if ied). Ther e ar e many char l at ans on t he Int er net post ing f ict ion.
The Int er net r eal l y int r oduced us t o t he concept of t r ying somet hing f or f r ee. For us
ol d t imer s, we expect ed t his. Post ings t o t he Int er net wer e al ways f r ee and
commer cial ism was a nono. Year s ago, when I was devel oping sof t war e, t he Int er net
came t o my r escue many t imes wit h post ings of sour ce code t hat assist ed in my
devel opment pr oject s. This sour ce code was avail abl e f or f r ee and of t en t he per son who
post ed it did not mind an occasional email wit h a quest ion or t wo. Anot her concept t hat
t he Int er net was not used f or was known as shareware, wher e t he f r ee sampl es of
appl icat ions r ange f r om sever el y cr ippl ed (l acking many of t he f ul l ver sion f eat ur es
such as pr int ing abil it ies) t o t he f ul l bl own ver sion of t he sof t war e. The Web combined
t he t wo concept s, and t he mar ket ing concept r eal l y t ook hol d when t he Int er net came
int o t he business wor l d. Ever y business sponsor ing a Web page wil l give you somet hing if
you pur chase somet hinga ver y ol d concept br ought t o l if e again via t he Int er net .
The Web (cont inued)
Ol dst yl e mar ket ing.
Give away t he r azor and sel l t he r azor bl adesGil l et t e
Shar ewar e pr ogr ams.
The ol d concept of t r y bef or e you buy
Fr ee pr ogr ams.
Many diver sif ied pr ogr ams and int er act ive Web pages
The 1800 ser vice f or dat a.
Most companies have a Web page
Most of us t r y a f r ee sampl e bef or e pur chasing. This is st il l known as shar ewar e, and
payment is expect ed, which l eads t o anot her big pr obl em f or t he Int er net : How and
when do you char ge f or somet hing? Most user s expect t o sur f t he Int er net , pick up what
t hey want f or f r ee, and t hen sign of f . Sor r y f ol ks, we dont l ive in a f r ee wor l d, and
event ual l y you must pay. Unf or t unat el y, t her e ar e t hose out t her e who cont inue t o
downl oad sof t war e and not pay f or it . Bad, bad, bad. If t his cont inues, shar ewar e wil l
not be avail abl e, and you wil l end up wit h a payf ir st , t r yl at er at t it ude.
Anot her pr obl em of t he Int er net is t he spr ead of vir uses. Pr ot ect your wor kst at ion wit h
some t ype of ant ivir al sof t war e bef or e downl oading anyt hing f r om t he Int er net . Most
pr ot ect ion schemes ar e dynamic in t hat t hey ar e const ant l y checking f or vir uses even
dur ing an email downl oad or a f il e t r ansf er . Her e is wher e t he ot her onl ine pr ovider s
do have an advant age. Pr ivat e onl ine pr ovider s such as Amer ica Onl ine and CompuSer ve
make ever y ef f or t t o t est upl oaded sof t war e and gener al l y do not al l ow f or cont ent
t o be wr it t en t o t heir ser ver s. You wil l f ind t hose ser vices mor e pr ot ect ed and wat ched
over t han t he Int er net . The Int er net has t r ul y t est ed t he f ir st Amendment of t he
Const it ut ion: t he r ight t o f r ee speech.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 5
Internet, Intranets, and Extranets
We al l know what t he Int er net isat l east I hope so. An intranet is a TCP/IP based
int er net used f or a business internal net wor k. Int r anet s can communicat e wit h each
ot her via connect ions t o t he Int er net , which pr ovides t he backbone communicat ion;
however , an int r anet does not need an out side connect ion t o t he Int er net in or der t o
oper at e. It simpl y uses al l t he TCP/IP pr ot ocol s and appl icat ions t o give you a pr ivat e
int er net .
When a business exposes par t of it s int er nal net wor k t o t he out side communit y, it is
known as an extranet. You may have used t his ext r anet when br owsing t hr ough a web
page at Gener al El ect r ic or or der ing some disket t es via a r esel l er s Web page. You wil l
not have compl et e access t o a cor por at e net wor k, but mer el y a par t of it t hat t he
business want s you t o have access t o. The company can bl ock access on it s r out er s and
put firewalls (a piece of sof t war e or har dwar e t hat al l ows you access t o r esour ces based
on a var iet y of par amet er s such as IP addr esses, por t number s, domain names, et c.) int o
pl ace t hat f or ce you t o have access onl y t o a subset of it s int r anet .
Int er net , Int r anet s, and Ext r anet s
The Int er net is a compl ex or ganizat ion of net wor ks managed by companies
t hat pr ovide access t o int er nat ional r esour ces t hr ough t he use of t he TCP/IP
pr ot ocol suit e.
An int r anet uses t he TCP/IP pr ot ocol s and appl icat ions based on t he Int er net
but in a cor por at e envir onment .
An ext r anet is t he shar ing of a cor por at e int r anet (maybe just a piece of it )
wit h t he out side wor l d.
Ecommer ce is an exampl e of an ext r anet

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 6
Who Governs the Internet?
Who gover ns t he pr ot ocol , t he Int er net , and t he Web? Fir st of f , l et s make it cl ear
t hat no one company or per son owns t he Int er net . In f act , some say t hat it is a mir acl e
t hat t he Int er net cont inues t o f unct ion as wel l as it does. Why is t his har d t o bel ieve?
Wel l , in or der t o f unct ion, t he Int er net r equir es t he compl et e cooper at ion of
t housands of companies known as Int er net Ser vice Pr ovider s (ISPs), t el ecommunicat ions
companies, st andar ds bodies such as IANA, appl icat ion devel oper s, and a host of ot her
r esour ces. The one main goal is t o pr ovide ubiquit ous inf or mat ion access, and anyone
who t r ies t o diver t t he Int er net t o his or her own advant age is usual l y chast ised.
However , t his is becoming mor e dil ut ed now t hat ISPs ar e duking it out f or t r af f ic
pat t er ns. Fur t her mor e, al l t hose who par t icipat e in t he Int er net , incl uding al l
companies t hat have IP connect ions t o t he Int er net , must abide by t he r ul es. Imagine
t hat : Mil l ions of peopl e al l l ist ening t o one set of r ul es.
Ref er t o sl ide 15. The TCP/IP pr ot ocol suit e is gover ned by an or ganizat ion known as t he
Int er net Act ivit ies Boar d (IAB). In t he l at e 1970s, t he gr owt h of t he Int er net was
accompanied by a gr owt h in t he size of t he int er est ed r esear ch communit y, r epr esent ing
an incr eased need f or coor dinat ion mechanisms. Vint Cer f , t hen manager of t he Int er net
Pr ogr am at DARPA, f or med sever al coor dinat ion bodies: an Int er nat ional Cooper at ion
Boar d (ICB) t o coor dinat e act ivit ies wit h some cooper at ing Eur opean count r ies cent er ed
on Packet Sat el l it e r esear ch; an Int er net Resear ch Gr oup, which was an incl usive
gr oup pr oviding an envir onment f or gener al exchange of inf or mat ion; and an Int er net
Conf igur at ion Cont r ol Boar d (ICCB). The ICCB was an invit at ional body t o assist Cer f
in managing t he bur geoning Int er net act ivit y.
Who Gover ns t he Int er net ?
In 1983, cont inuing gr owt h of t he Int er net communit y demanded a r est r uct ur ing of t he
coor dinat ion mechanisms. The ICCB was disbanded and, in it s pl ace, a st r uct ur e of Task
For ces was f or med, each f ocused on a par t icul ar ar ea of t he t echnol ogy (e.g., r out er s,
endt oend pr ot ocol s, et c.). The Int er net Act ivit ies Boar d (IAB) was f or med f r om t he
chair s of t he Task For ces.
By 1985, t her e was a t r emendous gr owt h in t he mor e pr act ical /engineer ing side of t he
Int er net . This r esul t ed in an expl osion in t he at t endance at t he IETF meet ings. This
gr owt h was compl ement ed by a major expansion in t he communit y. No l onger was DARPA
t he onl y major pl ayer in t he f unding of t he Int er net . In addit ion t o NSFnet and t he
var ious U.S. and int er nat ional gover nment f unded act ivit ies, int er est in t he
commer cial sect or was beginning t o gr ow. Al so in 1985, t her e was a signif icant decr ease
in Int er net act ivit y at DARPA. As a r esul t , t he IAB was l ef t wit hout a pr imar y sponsor
and incr easingl y assumed t he mant l e of l eader ship.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 7
The Governing Bodies of the Internet
The gr owt h cont inued, r esul t ing in even f ur t her subst r uct ur e wit hin bot h t he IAB and
IETF. The IETF combined Wor king Gr oups int o Ar eas, and designat ed Ar ea Dir ect or s. An
Int er net Engineer ing St eer ing Gr oup (IESG) was f or med of t he Ar ea Dir ect or s. The IAB
r ecognized t he incr easing impor t ance of t he IETF, and r est r uct ur ed t he st andar ds
pr ocess t o expl icit l y r ecognize t he IESG as t he major r eview body f or st andar ds. The
IAB al so r est r uct ur ed so t hat t he r est of t he Task For ces (ot her t han t he IETF) wer e
combined int o an Int er net Resear ch Task For ce (IRTF), wit h t he ol d t ask f or ces r enamed
as r esear ch gr oups. The gr owt h in t he commer cial sect or br ought wit h it incr eased
concer n r egar ding t he st andar ds pr ocess it sel f . St ar t ing in t he ear l y 1980s (and
cont inuing t o t his day), t he Int er net gr ew beyond it s pr imar il y r esear ch r oot s t o
incl ude bot h a br oad user communit y and incr eased commer cial act ivit y. Incr eased
at t ent ion was paid t o making t he pr ocess open and f air . This coupl ed wit h a r ecognized
need f or communit y suppor t of t he Int er net event ual l y l ed t o t he f or mat ion of t he
Int er net Societ y in 1991, under t he auspices of t he Cor por at ion f or Nat ional Resear ch
Init iat ives (CNRI).
In 1992, t he Int er net Act ivit ies Boar d was r eor ganized and r enamed t he Int er net
Ar chit ect ur e Boar d, oper at ing under t he auspices of t he Int er net Societ y. A mor e peer
r el at ionship was def ined bet ween t he new IAB and IESG, wit h t he IETF and IESG t aking
a l ar ger r esponsibil it y f or t he appr oval of st andar ds. Ul t imat el y, a cooper at ive and
mut ual l y suppor t ive r el at ionship was f or med among t he IAB, IETF, and Int er net Societ y,
wit h t he Int er net Societ y t aking on as a goal t he pr ovision of ser vice and ot her
measur es t hat woul d f acil it at e t he wor k of t he IETF.
The Gover ning Bodies of t he Int er net .
This communit y spir it has a l ong hist or y beginning wit h t he ear l y ARPAnet . The ear l y
ARPAnet r esear cher s wor ked as a cl oseknit communit y t o accompl ish t he init ial
demonst r at ions of packet swit ching t echnol ogy descr ibed ear l ier . Likewise, t he Packet
Sat el l it e, Packet Radio, and sever al ot her DARPA comput er science r esear ch pr ogr ams
wer e mul t icont r act or col l abor at ive act ivit ies t hat heavil y used what ever avail abl e
mechanisms t her e wer e t o coor dinat e t heir ef f or t s, st ar t ing wit h el ect r onic mail and
adding f il e shar ing, r emot e access, and event ual l y, Wor l d Wide Web capabil it ies.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 8
An Overall View of the Internet
This sl ide depict s t he Int er net backbone and shows t he over al l t opol ogy of a nat ional
ISP. Al l of t he connect ion point s (shown as cit ies) ar e pl aces wher e t he pr ovider has a
ser ial connect ion t o anot her one of it s sit es. Locat ed bel ow t hese connect ion point s ar e
point sof pr esence (POP), connect ion point s f or dial in and l easedl ine user s. Local
user s ar e connect ed at POPs by t he connect ion point s shown on t his map and
t hr oughout t he r est of t he Int er net .
The Int er net is a connect ion of net wor ks. Mul t ipl e nat ional ISPs ar e int er connect ed
t hr ough a concept of peering. Ther e ar e point s on t he Int er net wher e nat ional ISPs
connect and al l ow f or r out ing t abl es t o be shar ed and al l ow ubiquit ous access t o t he
Int er net f or al l user s.
An Over al l View of t he Int er net

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 9
Internet Timeline
Ref er t o sl ide 18.
Int er net Timel ine

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 10
Circuit and Packet Switching
Cir cuit and Packet Swit ching
Cir cuit swit ching pr ovides f or a pr ebuil t pat h t hat is r eser ved f or t he l engt h
of t he cal l .
Packet swit ching det er mines a r out e based on inf or mat ion in t he header of t he
packet . The packet is swit ched dynamical l y and mul t ipl e dat a packet s may t ake
t he same r out e.
Packet swit ching is viabl e f or al l t ypes of dat a, whet her voice, video, or
st or eandf or war d dat a.
TCP/IP al l owed f or open communicat ions t o exist and f or t he pr ol if er at ion of
LANt oLAN and LANt oWAN connect ivit y bet ween mul t ipl e oper at ing envir onment s.
It s t opol ogy and ar chit ect ur e, however , wer e not based on t he met hods empl oyed by t he
phone company: cir cuit swit ching.
The phone company (AT&T, bef or e t he br eakup) basical l y l aughed at t he idea of a
packet swit ched net wor k and publ icl y st at ed t hat it coul d never wor k. A net wor k
whose t r ansmit t ed inf or mat ion can f ind it s own way ar ound t he net wor k? Impossibl e! A
net wor k in which ever y t r ansmit t ed packet of inf or mat ion has t he same chance f or
f or war ding? The phone company maint ained it s st ance t hat cir cuit swit ching was t he
onl y met hod t hat shoul d be used f or voice, video, or dat a. Cir cuit swit ching by
def init ion pr ovided guar ant eed bandwidt h and, t her ef or e, Qual it y of Ser vice. At t hat
t ime, t he phone company was cor r ect , but onl y f or voice. Voice and video cannot
wit hst and del ay beyond a smal l t ime f r ame (about 150 mil l iseconds, or 0.150 seconds),
but dat a coul d! In packet swit ching, t he pat h is f ound in r eal t ime, and each t ime t he
pat h shoul d be t he same, but it may not be. St il l , t he inf or mat ion wil l get f r om point A
t o point B.
Ther e ar e many dif f er ences bet ween cir cuit swit ching and packet swit ching. One is t hat
in cir cuit swit ching, a pat h is pr ebuil t bef or e inf or mat ion is sent , wher eas packet
swit ching does not pr edef ine or pr ebuil d a pat h bef or e sending inf or mat ion. For exampl e,
when you make a phone cal l , t he phone company physical l y buil ds a cir cuit f or t hat
cal l . You cannot speak (t r ansmit inf or mat ion) unt il t hat cir cuit is buil t . This cir cuit is
buil t via har dwar e. This pat h is a physical cir cuit t hr ough t he t el ephone net wor k
syst em; however , t he phone company is cur r ent l y empl oying ot her t echnol ogies t o
al l ow f or vir t ual cir cuit swit ching t hr ough t echnol ogies such as Asynchr onous
Tr ansf er Mode, or ATM (beyond t he scope of t his book). For our compar ison, a voice pat h
is pr ebuil t on har dwar e bef or e inf or mat ion is passed. No inf or mat ion is cont ained in t he
digit ized voice signal t o indicat e t o t he swit ches wher e t he dest inat ion is l ocat ed. Each
t r ansmit t ing node has t he same chance in get t ing it s inf or mat ion t o t he r eceiver .
In packet swit ching, t he inf or mat ion needed t o get t o t he dest inat ion st at ion is
cont ained in t he header of t he inf or mat ion being sent . St at ions, known as routers, in t he
net wor k r ead t his inf or mat ion and f or war d t he inf or mat ion al ong it s pat h. Thousands
of dif f er ent packet s of inf or mat ion may t ake t he exact same pat h t o dif f er ent
dest inat ions.
Today we ar e pr oving t hat not onl y is packet swit ching viabl e, it can be used f or voice,
video, and dat a. Newer , f ast er st at ions on t he net wor k al ong wit h f ast er t r ansmission
t r anspor t s have been invent ed. Al ong wit h t his ar e new Qual it y of Ser vice pr ot ocol s
t hat al l ow pr ior it ies t o exist on t he net wor k. This al l ows cer t ain packet s of
inf or mat ion t o l eapf r og over ot her packet s of inf or mat ion t o become f ir st in t he
t r ansmission.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 11
TCP/IP Protocol Documents
Compl et e det ail s of a Request f or Comment s (RFC) document ar e cont ained in RFC 1543.
If TCP/IP is such an open pr ot ocol , wher e does one f ind out inf or mat ion on t he pr ot ocol
and ot her it ems of int er est on t he Int er net ? RFCs def ine t he pr ocessing f unct ions of t his
pr ot ocol , and t hese document s ar e avail abl e onl ine or may be pur chased. Onl ine, t hey
may be f ound on any of t he t hr ee r egist r ies: Int er NIC (US), RIPE (Eur ope), and APNIC
(Asia Pacif ic).
For exampl e, point your Web br owser t o ht t p://ds.int er nic.net /r f c/r f cindex.t xt and
r eview t he l at est index (updat ed al most dail y) of RFCs. My suggest ion is t hat you save
t his as a f il e in your l ocal comput er . You wil l r et ur n many t imes t o t his document t o
f ind mor e inf or mat ion about a par t icul ar aspect of a pr ot ocol . Use t he Find t ool under
t he Edit pul l down menu t o pr ovide a sear ch. Be car ef ul : Just because you t ype in a
wor d, t he sear ch engine may not f ind specif ical l y what you ar e l ooking f or , so you may
have t o know a f ew t hings bef or e vent ur ing f or t h, but f or t he most par t , t his is t he best
met hod of weeding t hr ough t he RFCs.
TCP/IP Pr ot ocol Document s
Review RFC 1583.
TCP/IP t echnical document s ar e known as Request f or Comment s, or RFCs.
Can be f ound at any of t he t hr ee r egist r ies
APNIC (Asia), RIPE (Eur ope), INTERNIC (U.S.)
Point your br owser t o: ds.int er nic.net /RFC/r f cxxxx.t xt
Repl ace t he x wit h t he RFC number
Syst ems engineer s shoul d r ead at a minimum: RFCs 1812, 1122, and 1123.
Af t er f inding an RFC, change rfcindex on t he URL t o rfcxxxx.txt, wher e x is t he RFC
number , and you now have t he RFC onl ine. I suggest t hat you save t he RFCs t hat you
wil l r et ur n t o t he most on your l ocal dir ect or yt hey can t ake some t ime t o downl oad.
A major it y of individual s ar e t r ust ing t he st at ement s of a companys impl ement at ion of
t he TCP/IP pr ot ocol s mor e t han what is wr it t en in an RFC. The RFC is t he def init ive
document f or t he TCP/IP pr ot ocol suit e. I asked some syst ems engineer s who I know t wo
t hings:
When was t he l ast t ime you r eviewed a quest ion by r eading an RFC?
Have you r ead RFC 1812, 1122, and 1123?
The answer t o t he f ir st quest ion is gener al l y, I dont know (occasional l y, I got t he
r esponse, Hey Mat t , get a l if e!), and t he answer t o t he second quest ion is, What s in
t hose RFCs? How any syst ems engineer s can cl aim t hat t hey know t he TCP/IP pr ot ocol
(as al ways indicat ed on t heir r sums, al ong wit h knowl edge of 100 ot her pr ot ocol s and
appl icat ions) wit hout having r ead t hese t hr ee RFCs? The Web makes it so easy t o r eview
an RFC: Simpl y point your br owser t o ds.int er nic.net /r f c/r f cxxxx.t xt , or f or an index t o
ds.int er nic.net /r f c/r f cindex.t xt . Get t he RFC el ect r onical l y, save it , and t hen use t he
sear ch commands t o f ind what you ar e l ooking f or .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 12
Why Study the RFCs?
It may seem t r ivial , but I have expanded t his sect ion of t he book because ever yone seems
t o be get t ing away f r om t he RFCs. Al so, many peopl e ar e st il l get t ing int o t he TCP/IP
pr ot ocol who may have never seen an RFC bef or e.
The Request f or Comment s ar e paper s (document s) t hat def ine t he TCP/IP pr ot ocol suit e.
They ar e t he Int er net s t echnical (most l y) document s; I say most l y f or some ar e
int el l ect ual l y humor ous (e.g., A View f r om t he 21st Cent ur y by Vint Cer f , RFC 1607).
An RFC can be wr it t en and submit t ed by anyone; However , any document does not
aut omat ical l y become an RFC. A t ext document becomes a dr af t RFC f ir st . At t his point
it is consider ed a publ ic document . A peer r eview pr ocess is t hen conduct ed over a per iod
of t ime and comment s ar e cont inual l y made on t he dr af t . It wil l t hen be decided
whet her or not it becomes an RFC.
St eve Cr ocker wr ot e t he f ir st RFC in 1969. These memos wer e int ended t o be an
inf or mal , f ast way t o shar e ideas wit h ot her net wor k r esear cher s. RFCs wer e or iginal l y
pr int ed on paper and dist r ibut ed via snail mail (post al ). As t he Fil e Tr ansf er Pr ot ocol
(FTP) came int o use, t he RFCs wer e pr epar ed as onl ine f il es and accessed via FTP.
Exist ing RFCs (as of t his wr it ing) number over 2200 and cont ain inf or mat ion on any
aspect of any Int er net pr ot ocol . Devel opment engineer s r ead t hese document s and
pr oduce appl icat ions based on t hem.
Why St udy t he RFCs?
Request f or Comment s t echnical l y def ine a pr ot ocol f or t he Int er net and ar e
inf or mat ional , or even humor ous.
The f ir st RFC was wr it t en by St eve Cr ocker .
Sent via snail mail unt il FTP came al ong
An RFC can be submit t ed by anyone.
Does not aut omat ical l y become an RFC
Fir st ent er s as an RFC dr af t wit h no number associat ed
Must f ol l ow t he inst r uct ions f or aut hor s det ail ed in RFC 1543
For syst ems engineer s, most of t he RFCs do not need t o be st udied. However , f or a basic
under st anding of t he TCP/IP pr ot ocol suit e, t hr ee RFCs must be r ead. Ther ef or e, in t he
spir it of t he RFC act ion wor ds, you MUST r ead RFCs 1122, 1123, and 1812 bef or e being
abl e t o st at e t hat you under st and t he TCP/IP pr ot ocol suit e. Ther e ar e many RFCs, but
t he major it y can be summed up in t hose t hr ee RFCs. The r eading is not dif f icul t , and
many t hings ar e expl ained.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 13
Submitting an RFC
Submit t ing an RFC
Anyone can submit an RFC accor ding t o RFC 1543.
A major sour ce f or RFCs is t he Int er net Engineer ing Task For ce (IETF),
which now has over 75 wor king gr oups
The pr imar y RFC, incl uding al l diagr ams, must be wr it t en in 7bit ASCII t ext .
The secondar y publ icat ion may be in post scr ipt .
Pr imar il y used f or cl ar it y
Once issued, RFCs do not change.
Updat ed by new RFCs
RFCs can be obsol et ed but t heir number s ar e never used again
As TCP/IP evol ves, so does t he RFC.
Memos pr oposed t o be RFCs may be submit t ed by anyone. One l ar ge sour ce of memos t hat
become RFCs comes f r om t he Int er net Engineer ing Task For ce (IETF). The IETF wor king
gr oups (WGs) evol ve t heir wor king memos (known as Int er net Dr af t s, or IDs) unt il t hey
f eel t hey ar e r eady f or publ icat ion. Then t he memos ar e r eviewed by t he Int er net
Engineer ing St eer ing Gr oup (IESG) and, if appr oved, ar e sent by t he IESG t o t he RFC
Edit or . The pr imar y RFC must be wr it t en in ASCII t ext . This incl udes al l pict ur es, which
l eads t o some int er est ing images! The RFC may be r epl icat ed as a secondar y document in
Post Scr ipt (t his must be appr oved by t he aut hor and t he RFC edit or ). This al l ows f or an
easyt or ead RFC, incl uding pict ur es. The pr imar y RFC, however , is al ways wr it t en in
ASCII t ext . Remember : Simpl icit y and avail abil it y f or al l is t he over al l t one of t he
Int er net . Ther ef or e, in or der t o int er act in a digit al wor l d, it is mandat or y t hat
ever yone have at l east ASCII t er minal f unct ions eit her t hr ough a comput er t er minal or
on a PC.
The f or mat of an RFC is indicat ed by RFC 1543, Inst r uct ions t o Aut hor s, and al so
shown in sl ide 22. Each RFC is assigned a number in ascending sequence (newer RFCs have
higher number s, and t hey ar e never r eassigned). Once issued, RFCs do not change.
Revisions may be made t o t he RFCs, but r evisions ar e issued as a new RFC. But do not
t hr ow out t hat ol d RFC. Some of t he newer RFCs onl y r epl ace par t of t he ol der RFC
such as r epl acing an appendix or updat ing a f unct ion. They may al so simpl y add
somet hing t o t he ol der RFC. This is indicat ed by an updat edby: st at ement on t he f ir st
page. If a new RFC compl et el y r epl aces an RFC, t he new RFC has Obsol et e: RFC XXXX
in t he upper l ef t cor ner of t he RFC. The index of RFCs, indicat ed by t he URL given
ear l ier , cont ains t he inf or mat ion about updat es.
The RFCs ar e cont inuing t o evol ve as t he t echnol ogy demands. This al l ows f or t he
Int er net t o become t he never ending st or y. For exampl e, t he wide ar ea net wor k
connect ion f acil it y known as t he Fr ame Rel ay specif icat ion is becoming ver y popul ar ,
and t her e ar e RFCs t o def ine how t o int er f ace TCP t o t he f r ame r el ay pr ot ocol . RFCs
al so al l ow r ef inement s t o enhance bet t er int er oper abil it y. As l ong as t he t echnol ogy
is changing, t he RFCs must be updat ed t o al l ow connect ion t o t he pr ot ocol suit e. IPv6 is
wel l document ed wit h many RFCs.
As of t his wr it ing, t he IETF now has in excess of 75 wor king gr oups, each wor king on a
dif f er ent aspect of Int er net engineer ing. Each of t hese wor king gr oups has a mail ing
l ist t o discuss one or mor e dr af t document s under devel opment . When consensus is
r eached on a dr af t , a document may be dist r ibut ed as an RFC.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 14
RFC Updates
The RFC announcement s ar e dist r ibut ed via t wo mail ing l ist s:t he IETFAnnounce l ist ,
and t he RFCDIST l ist . You dont want t o be on bot h l ist s.
To join (or quit ) t he IETFAnnounce l ist , send a message t o:
IETFRequest @cnr i.r est on.va.us
To join (or quit ) t he RFCDIST l ist , send a message t o:
RFCRequest @NIC.DDN.MIL
RFC Updat es
To join or quit t he IETFAnnounce l ist , send an email t o:
IETFRequest @cnr i.r est on.va.us
To join or quit t he RFCDIST l ist , send an email t o:
RFCRequest @NIC.DDN.MIL

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 15
RFC Format
Fir st page. Ref er t o sl ide 24. Net wor k Wor king Gr oup. The t r adit ional heading f or
t he gr oup t hat f ounded t he RFC ser ies. This appear s on t he f ir st l ine on t he l ef t hand
side of t he heading.
Request f or Comment : nnnn. Ident if ies t his as a r equest f or comment s and specif ies t he
number . Indicat ed on t he second l ine on t he l ef t side. The act ual number is f il l ed in at
t he l ast moment bef or e publ icat ion by t he RFC Edit or .
Aut hor Name. The aut hor s name (f ir st init ial and l ast name onl y), indicat ed on t he
f ir st l ine on t he r ight side of t he heading.
Aut hor Or ganizat ion. The aut hor s or ganizat ion (company name, col l ege division,
et c.), indicat ed on t he second l ine on t he r ight side.
Submission Dat e. This is t he mont h and year of t he RFC publ icat ion. Indicat ed on t he
t hir d l ine on t he r ight side.
Obsol et es/Updat es. If t his RFC updat es or obsol et es anot her RFC, it is indicat ed in t he
t hir d l ine on t he l ef t side of t he heading.
Cat egor y. The cat egor y of t his RFC, one of : St andar ds Tr ack, Inf or mat ional , or
Exper iment al . This is indicat ed on t he t hir d (if t her e is no Obsol et es/Updat es indicat ion)
or f our t h l ine on t he l ef t side.
RFC For mat
Tit l e. The t it l e appear s, cent er ed, bel ow t he r est of t he heading. If t her e ar e mul t ipl e
aut hor s, and if t he mul t ipl e aut hor s ar e f r om mul t ipl e or ganizat ions, t he r ight side
heading may have addit ional l ines t o accommodat e t hem.
Running header s. The r unning header in one l ine (on page 2 and al l subsequent pages)
has t he RFC number on t he l ef t (RFC NNNN), t he t it l e cent er ed (possibl y an abbr eviat ed
t it l e), and t he dat e (mont h, year ) on t he r ight .
Running f oot er s. The r unning f oot er in one l ine (on al l pages) has t he aut hor s l ast
name on t he l ef t and t he page number on t he r ight ([Page N]).
St at us sect ion. Each RFC must incl ude on it s f ir st page t he St at us of t his Memo
sect ion, which cont ains a par agr aph descr ibing t he t ype of RFC.
The cont ent of t his sect ion wil l be one of t he t hr ee f ol l owing st at ement s:
St andar ds t r ack. This document specif ies an Int er net st andar ds t r ack pr ot ocol f or
t he Int er net communit y, and r equest s discussion and suggest ions f or impr ovement s.
Pl ease r ef er t o t he cur r ent edit ion of t he Int er net Of f icial Pr ot ocol St andar ds (STD
1) f or t he st andar dizat ion st at e and st at us of t his pr ot ocol . Dist r ibut ion of t his memo is
unl imit ed.
Exper iment al . This memo def ines an exper iment al pr ot ocol f or t he Int er net
communit y. This memo does not specif y an Int er net st andar d of any kind. Discussion and
suggest ions f or impr ovement ar e r equest ed. Dist r ibut ion of t his memo is unl imit ed.
Inf or mat ional . This memo pr ovides inf or mat ion f or t he Int er net communit y. This memo
does not specif y an Int er net st andar d of any kind. Dist r ibut ion of t his memo is
unl imit ed.
RFC For mat (cont inued)

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 16
Other RFC Format Requirements
Int r oduct ion sect ion. Each RFC shoul d have an Int r oduct ion sect ion t hat (among
ot her t hings) expl ains t he mot ivat ion f or t he RFC and (if appr opr iat e) t he appl icabil it y
of t he pr ot ocol .
Discussion. The pur pose of t his RFC is t o f ocus discussion on par t icul ar pr obl ems in t he
Int er net and possibl e sol ut ions. No pr oposed sol ut ions in t his document ar e int ended as
st andar ds f or t he Int er net . Rat her , it is hoped t hat a gener al consensus wil l emer ge as
t o t he appr opr iat e sol ut ion t o such pr obl ems, l eading event ual l y t o t he adopt ion of
st andar ds.
Int er est . This RFC is being dist r ibut ed t o member s of t he Int er net communit y in or der t o
sol icit t heir r eact ions t o t he pr oposal s cont ained in it . Whil e t he issues discussed may
not be dir ect l y r el evant t o t he r esear ch pr obl ems of t he Int er net , t hey may be of
int er est t o a number of r esear cher s and impl ement er s.
St at us r epor t . In r esponse t o t he need f or maint enance of cur r ent inf or mat ion about
t he st at us and pr ogr ess of var ious pr oject s in t he Int er net communit y, t his RFC is issued
f or t he benef it of communit y member s. The inf or mat ion cont ained in t his document is
accur at e as of t he dat e of publ icat ion, but is subject t o change. Subsequent RFCs wil l
r ef l ect such changes. These par agr aphs need not be f ol l owed wor d f or wor d, but t he
gener al int ent of t he RFC must be made cl ear .
Ref er ences sect ion. Near l y al l RFCs cont ain cit at ions t o ot her document s, and t hese
ar e l ist ed in a Ref er ences sect ion near t he end of t he RFC. Ther e ar e many st yl es f or
r ef er ences, and t he RFCs have one of t heir own.
Ot her RFC For mat Requir ement s
Int r oduct ion.
Each RFC shoul d have an Int r oduct ion sect ion t hat (among ot her
t hings) expl ains t he mot ivat ion f or t he RFC and (if appr opr iat e) descr ibes
t he appl icabil it y of t he pr ot ocol descr ibed
RFC t ext .
The body of t he RFC
Discussion.
The pur pose of t his RFC is t o f ocus discussion on par t icul ar pr obl ems in
t he Int er net and possibl e sol ut ions
Acknowl edgment s.
This is wher e t he aut hor may pl ace individual acknowl edgment of
ot her s
Ref er ences.
Near l y al l RFCs cont ain cit at ions t o ot her document s, and t hese ar e
l ist ed in a Ref er ences sect ion near t he end of t he RFC. Ther e ar e many
st yl es f or r ef er ences, and t he RFCs have one of t heir own.
Secur it y consider at ions sect ion. Al l RFCs must cont ain a sect ion near t he end of t he
document t hat discusses t he secur it y consider at ions of t he pr ot ocol or pr ocedur es t hat
ar e t he main t opic of t he RFC.
Aut hor s addr ess sect ion. Each RFC must have at t he ver y end a sect ion giving t he
aut hor s addr ess, incl uding t he name and post al addr ess, t he t el ephone number , a FAX
number (opt ional ), and t he Int er net email addr ess.
Ot her RFC For mat Requir ement s (cont inued)
Secur it y consider at ions.
Al l RFCs must cont ain a sect ion near t he end of t he document t hat
discusses t he secur it y consider at ions of t he pr ot ocol or pr ocedur es t hat
ar e t he main t opic of t he RFC.
Aut hor s addr ess.
Each RFC must have at t he ver y end a sect ion giving t he aut hor s
addr ess, incl uding t he name and post al addr ess, t he t el ephone number , a
FAX number (opt ional ), and t he Int er net email addr ess.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 17
Requirements in RFCs
The f ir st RFCs l ed t o ambiguit y in t he pr ot ocol ; not ever yone r eads and int er pr et s
al ike. Ther ef or e, most RFCs have t he f ol l owing t o indicat e pr ecisel y what shoul d be
impl ement ed and what is opt ional :
MUST. This wor d or t he adject ive REQUIRED means t hat t he it em is an absol ut e
r equir ement of t his specif icat ion.
MUST NOT. This phr ase means t he it em is an absol ut e pr ohibit ion of t his
specif icat ion.
SHOULD. This wor d or t he adject ive RECOMMENDED means t hat t her e may
exist val id r easons in par t icul ar cir cumst ances t o ignor e t his it em, but t he f ul l
impl icat ions shoul d be under st ood and t he case car ef ul l y weighed bef or e
choosing a dif f er ent cour se.
SHOULD NOT. This phr ase means t hat t her e may exist val id r easons in par t icul ar
cir cumst ances when t he l ist ed behavior is accept abl e or even usef ul , but t he f ul l
impl icat ions shoul d be under st ood and t he case car ef ul l y weight ed bef or e
impl ement ing any behavior descr ibed wit h t his l abel .
MAY. This wor d or t he adject ive OPTIONAL means t hat t his it em is t r ul y
opt ional . One vendor may choose t o incl ude t he it em because a par t icul ar
mar ket pl ace r equir es it or because it enhances t he pr oduct . Anot her vendor may
omit t he same it em.
Requir ement s in RFCs
MUSTThe wor d or adject ive REQUIRED means t hat t he it em is an absol ut e
r equir ement of t his specif icat ion.
MUST NOTThis phr ase means t he it em is an absol ut e pr ohibit ion of t his
specif icat ion.
SHOULDThe wor d or t he adject ive RECOMMENDED means t hat t her e may
exist val id r eason in par t icul ar cir cumst ances t o ignor e t his it em, but t he f ul l
impl icat ions shoul d be under st ood and t he case car ef ul l y weighed bef or e
choosing a dif f er ent cour se.
SHOULD NOTThis phr ase means t hat t her e may exist val id r easons in
par t icul ar cir cumst ances when t he l ist ed behavior is accept abl e or even usef ul ,
but t he f ul l impl icat ions shoul d be under st ood and t he case car ef ul l y weighed
bef or e impl ement ing any behavior descr ibed wit h t his l abel .
MAYThis wor d or t he adject ive OPTIONAL means t hat t his it em is t r ul y
opt ional . One vendor may choose t o incl ude t he it em because a par t icul ar
mar ket pl ace r equir es it or because it enhances t he pr oduct , whil e anot her
vendor may omit t he same it em.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 18
TCP/IP: The Protocols (covered in this book) and the
OSI Model
The best way t o int r oduce TCP/IP is by l ooking at it t hr ough t he ISO OSI model . I am
not going t o discuss t he OSI model and it s l ayer f unct ions her e. I am pl acing t he
pr ot ocol of TCP/IP int o t his model t o show you wher e t he pr ot ocol suit e sit s in t his
model .
Let s st ar t wit h under st anding t he f unct ions and pr ot ocol s by st udying t heir
pl acement in t he OSI model . This sl ide shows t hat t he pr ot ocol suit e of TCP/IP has it s
pl ace in t he OSI model . The hear t of t he TCP/IP net wor k pr ot ocol is at l ayer s 3 and 4.
The appl icat ions f or t his pr ot ocol (f il e t r ansf er , mail , and t er minal emul at ion) r un at
t he session t hr ough t he appl icat ion l ayer .
As you can see, t his pr ot ocol r uns independent l y of t he dat al ink and physical l ayer .
At t hese l ayer s, t he TCP/IP pr ot ocol can r un on Et her net , Token Ring, FDDI, ser ial
l ines, X.25, and so f or t h. It has been adapt ed t o r un over any LAN or WAN pr ot ocol .
TCP/IP was f ir st used t o int er connect comput er syst ems t hr ough synchr onous l ines and
not highspeed l ocal ar ea net wor ks. Today, it is used on any t ype of media. This incl udes
ser ial l ines (asynchr onous and synchr onous) and highspeed net wor ks such as FDDI,
Et her net , Token Ring, and Asynchr onous Tr ansf er Mode (ATM).
TCP/IP: The Pr ot ocol s (cover ed in t his book) and t he OSI Model

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 19
The Protocol Suite, According to This Book
1. The Int er net Pr ot ocol (IPv4 and IPv6):
RIP, RIP2, OSPF, ICMP, IGMP, RSVP, and ARP
2. The Tr anspor t Cont r ol Pr ot ocol and t he User Dat agr am Pr ot ocol (TCP and
UDP)
3. The suit e of specif ic appl icat ions specif ical l y devel oped f or TCP/IP:
TELNET
Fil e Tr ansf er Pr ot ocol (FTP)
Tr ivial Fil e Tr ansf er Pr ot ocol (TFTP)
Domain Name Ser vice (DNS)
Simpl e Mail Tr ansf er Pr ogr am (SMTP)
Real Time Pr ot ocol (RTP)
Real Time Cont r ol Pr ot ocol (RTCP)
Boot Pr ot ocol (BOOTP)
Dynamic Host Conf igur at ion Pr ot ocol (DHCP)
Simpl e Net wor k Management Pr ot ocol (SNMP)
Ther e ar e many ot her appl icat ions t hat r un on a net wor k using t he TCP/IP pr ot ocol
suit e t hat ar e not shown her e. Incl uded in t his l ist ing ar e t he appl icat ions t hat ar e
def ined in t he RFCs and ar e usual l y incl uded in ever y TCP/IP pr ot ocol suit e t hat is
of f er ed. However , newer appl icat ions or pr ot ocol s f or TCP/IP ar e somet imes not
incl uded.
The Pr ot ocol Suit e, Accor ding t o This Book
TCP/IP is a f amil y of pr ot ocol s.
Int er net Pr ot ocol (IPv4 and IPv6)
RIPv1, RIPv2, OSPF, ICMP, IGMP, RSVP, ARP
Tr anspor t Cont r ol Pr ot ocol and t he User Dat agr am Pr ot ocol
TCP and UDP
Suit e of appl icat ions
TELNET
Domain Name Ser ver (DNS)
Simpl e Mail Tr ansf er Pr ot ocol (SMTP)
Real Time Pr ot ocol (RTP)
Real Time Cont r ol Pr ot ocol (RTCP)
Boot st r ap Pr ot ocol (BOOTP)

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 20
IP Overview
The Int er net Pr ot ocol (IP) is sit uat ed at t he net wor k l ayer of t he OSI model and is
designed t o int er connect packet swit ched communicat ion net wor ks t o f or m an int er net .
It t r ansmit s bl ocks of dat a cal l ed datagrams r eceived f r om t he IPs upper l ayer sof t war e
t o and f r om sour ce and dest inat ion host s. It pr ovides a best ef f or t or connect ionl ess
del iver y ser vice bet ween t he sour ce and dest inat ionconnect ionl ess in t hat it does not
est abl ish a session bet ween t he sour ce and dest inat ion bef or e it t r ansmit s it s dat a. This
is t he l ayer t hat is al so r esponsibl e f or t he IP pr ot ocol addr essing.
In or der t o al l ow f or mul t ipl e IP net wor ks t o int er oper at e, t her e must be a mechanism
t o pr ovide f l ow bet ween t he dif f er ent l y addr essed syst ems. The device t hat r out es dat a
bet ween dif f er ent IP addr essed net wor ks is cal l ed a router, which is of t en er r oneousl y
t hought of as being t he onl y f unct ion of t he IP l ayer . It is not , and t his is expl ained in
mor e det ail l at er . The r out er is basical l y a t r af f ic cop. You t el l t he t r af f ic cop wher e
you want t o go and he point s you in t he r ight dir ect ion. Rout er s cont ain por t s t hat ar e
physical connect ions t o net wor ks. Each of t hese por t s must be assigned a l ocal addr ess.
Wit h mor e t han one r out er , each r out er must know t he ot her s conf igur ed inf or mat ion.
We coul d conf igur e al l t he IP addr esses and t heir associat ed por t s on a r out er
st at ical l y, but t his is a ver y t imeconsuming and nonef f icient met hod. Ther ef or e, we
have pr ot ocol s t hat dist r ibut e t he IP addr ess inf or mat ion t o each r out er . These ar e
cal l ed routing protocols. The t wo main t ypes f or IP net wor ks ar e RIP (Rout ing Inf or mat ion
Pr ot ocol , ver sion 1 or 2) and OSPF (Open Shor t est Pat h Fir st ). Bot h ar e known as
Int er ior Gat eway Pr ot ocol s (IGPs), pr ot ocol s t hat r un wit hin a singl e aut onomous
syst ems. An aut onomous syst em is a col l ect ion of net wor ks and r out er s t hat is under
one administ r at ive domain. For exampl e, if you wor k f or t he Timbukt u Company and you
have seven r egional of f ices in t he Unit ed St at es, al l communicat ion bet ween t hose
of f ices is accompl ished via r out er s al l r unning RIP. You have one domain known as
Timbukt u.com; t her ef or e, al l t he net wor ks and r out er s and comput er equipment is
under one administ r at ive domain. Connect ion t o t he out side wor l d via t he Int er net
(which is anot her domain) al l ows communicat ion wit h anot her company t hat is under
anot her administ r at ive domain.
IP Over view
IP is designed t o int er connect packet swit ched communicat ion net wor ks t o
f or m an int er net .
It t r ansmit s bl ocks of dat a known as dat agr ams r eceived f r om IPs upper l ayer
sof t war e t o and f r om host s.
IP pr ovides best ef f or t or connect ionl ess del iver y ser vice.
IP is r esponsibl e f or addr essing.
Two ver sions of IP: ver sion 4 and ver sion 6.
Net wor k inf or mat ion is dist r ibut ed via r out ing pr ot ocol s.
You shoul d be awar e t her e ar e t wo ver sion of IP: IPv4 (ver sion 4, t he cur r ent IP) and
IPv6 (ver sion 6, t he exper iment al IP). IPv4 cont inues t o oper at e admir abl y, but has
become st r ained wit h pat ches t o make it cont inue t o wor k. The l at est is t he addr ess
scheme and IPv6 was par t ial l y mot ivat ed by t he inabil it y t o scal e and t he exhaust ion of
IP Cl ass B addr esses. IPv6 is a nat ur al evol ut ion of IP and ext ends t he addr ess space t o
128 bit s and cl eans up a l ot of unused f unct ions.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 21
IGPs, EGPs, and Routing Protocols
IGPs, EGPs, and Rout ing Pr ot ocol s
Ther e is a dif f er ence bet ween a r out ing pr ot ocol and a r out abl e pr ot ocol .
A r out ing pr ot ocol is one t hat is used t o pr opagat e r out e pat h
inf or mat ion on a net wor k
A r out abl e pr ot ocol is one t hat has t he abil it y t o be r out ed as opposed
t o a nonr out abl e pr ot ocol such as Net BIOS
IGPs ar e used as r out ing pr ot ocol s wit hin an AS.
EGPs ar e used as r out ing pr ot ocol s bet ween ASs.
Ther e ar e t wo cl assif icat ions of pr opagat ing inf or mat ion: Int er ior Gat eway Pr ot ocol s
(IGP) and Ext er ior Gat eway Pr ot ocol s (EGP). An IGP is a r out ing pr ot ocol t hat
pr opagat es inf or mat ion inside one aut onomous syst em. An EGP is a r out ing pr ot ocol t hat
pr opagat es inf or mat ion bet ween aut onomous syst ems.
In or der f or dat a t o be moved acr oss an int er net , inf or mat ion on t he l ocat ion of t he
net wor ks must be pr opagat ed t hr oughout t he net wor k. This is t he int r oduct ion t o t he
dif f er ence bet ween a r out ing pr ot ocol and a r out abl e pr ot ocol . IP is a routable pr ot ocol .
Pr opagat ing inf or mat ion t hr oughout t he net wor k as t o t he l ocat ion of t he net wor ks is
known as a routing pr ot ocol . Dont conf use t he t wo.
I know t hat I keep using t he t er m autonomous system (AS). Yes, it is def ined as a net wor k
t hat is under a singl e administ r at ive cont r ol , but l et s def ine t hat a l it t l eand yes, it
does get a l it t l e bl ur r y. Bef or e t he pl et hor a of ISPs, anyone connect ed t o t he Int er net
was assigned an addr ess and used a special pr ot ocol (t hen known as EGP) t o connect t o
t he Int er net . Ther ef or e, t hat connect ion became known as an autonomous system, and
r out es f or t hat net wor k wer e known on t he Int er net using EGP (yes, t he acr onym f or
t he pr ot ocol is t he same one used f or t he def init ion of t he pr ot ocol ). Aut onomous
syst ems wer e simpl y ent it ies connect ed t o t he Int er net . They wer e given a special AS
number , and EGP knew how t o r out e t his dat a. An AS coul d mean a f our user of f ice
wit h a singl e Int er net connect ion, a net wor k as l ar ge as t he one used by Gener al
Mot or s, or an Int er net Ser vice Pr ovider (ISP). So dont get conf used by t he t er m
autonomous system.
Today, ISPs r ul e t he connect ion t o t he Int er net and an AS is mor e bl ur r y. The new
pr ot ocol t hat cont r ol s r out es on t he Int er net is known as Bor der Gat eway Pr ot ocol
(BGP), and it is an EGP (as opposed t o an IGP). However , onl y cer t ain ISPs need t his
pr ot ocol ; al l ot her s ar e simpl y connect ions (hier ar chical ) of f of t heir upst r eam ISP. So
AS t akes on a new meaning. For our pur poses, yes, it st il l means a singl e cust omer
net wor k, but f or t he Int er net , it is gener al l y t he upper end ISP. Many IP net wor ks ar e
simpl y r unning as par t of t heir ISP AS.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 22
Introduction to Routing Protocols (RIP)
Int r oduct ion t o Rout ing Pr ot ocol s (RIP)
Root ed in t he ear l y days of t he ARPAnet .
Hist or ical l y t ied t o t he Xer ox XNS net wor k oper at ing syst em
IP is a r out abl e pr ot ocol , it needs a r out ing pr ot ocol t o r out e bet ween
subnet s.
It is known as a dist ance vect or pr ot ocol .
It buil ds a t abl e of known net wor ks, which is dist r ibut ed t o ot her r out er s.
A hop is one r out er t r aver sed.
Ther e ar e a f ew pr ot ocol s t hat handl e f or a singl e aut onomous syst em. RIP is t he easier
of t he t wo (RIP or OSPF) and came f r om t he Xer ox Net wor k Syst em (XNS) pr ot ocol . The
or igins of RIP ar e based in t he or igins of t he Int er net , but hist or ical l y it came f r om
Xer ox and it s XNS pr ot ocol . RIP was f r eel y dist r ibut ed in t he Unix oper at ing syst em
and, because of it s simpl icit y, gained widespr ead accept ance. Unf or t unat el y, t her e ar e
many def iciencies associat ed wit h t his pr ot ocol , and t her e have been many pat ches
appl ied t o it t o make it wor k mor e r el iabl y in l ar ge net wor ks. For smal l er net wor ks,
t he pr ot ocol wor ks just f ine.
Since, IP is a routable protocol, it needs a routing protocol t o enabl e it t o r out e bet ween
net wor ks. RIP is known as a distance vector pr ot ocol . It s dat abase (t he r out ing t abl e)
cont ains t wo f iel ds needed f or r out ing: a vect or (a known IP addr ess) and t he dist ance
(how many r out er s away) t o t he dest inat ion. Act ual l y, t he t abl e cont ains mor e f iel ds
t han t hat , but we wil l discuss t hat l at er .
RIP simpl y buil ds a t abl e in memor y t hat cont ains al l t he r out es t hat it knows about
and t he dist ance t o t hat net wor k. When t he pr ot ocol init ial izes, it simpl y pl aces t he IP
addr esses of it s l ocal int er f aces int o t he t abl e. It associat es a cost wit h t hose
int er f aces and t hat cost is usual l y set t o 1 (expl ained in a moment ). The r out er wil l
t hen sol icit (or it may wait f or inf or mat ion t o be suppl ied t o it ) inf or mat ion f r om ot her
r out er s on it s l ocal l y at t ached subnet s. Event ual l y, as ot her r out er s r epor t (send
t heir t abl es) t o ot her r out er s, each r out er wil l have t he inf or mat ion needed about al l
r out es on it s subnet s or int er net wor k.
Any IP dat agr ams t hat must t r aver se a r out er in t he pat h t o it s dest inat ion is said t o
have t r aver sed one hop f or each r out er t r aver sed. Ther ef or e, when a r out er r eceives a
packet and examines t he dest inat ion addr ess in t he dat agr am, it wil l t hen per f or m a
t abl e l ookup based on t hat dest inat ion addr ess. The r out er wil l al so f ind t he por t
associat ed wit h t his dest inat ion addr ess in t he dat abase and wil l f or war d t he dat agr am
out of t hat por t and onwar d t o t he f inal dest inat ion. In RIP, al l r out er s comput e t heir
t abl es and t hen give each ot her t heir t abl es (just t he IP net wor k addr ess and t he cost ).
Rout er s t hat r eceive t his t abl e wil l add t he cost assigned t o t he incoming int er f ace
(r eceived por t ) t o each of t he ent r ies in t he t abl e. The r out er t hen decides whet her t o
keep any of t he inf or mat ion in t he r eceived t abl e. This inf or mat ion is t hen passed t o
ot her r out er s.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 23
Introduction to Routing Protocols (OSPF)
OSPF is al so r out ing pr ot ocol , but it does not compar e t o RIP wit h t he except ion t hat
it , t oo, is an IGP. Of cour se, l et s be f air . In t he beginning, when t he Int er net was
cr eat ed, t he pr ocessor s t hat we had wer e nowher e near t he power of what we have
t oday. In f act , a Honeywel l 516 minicomput er was used as t he f ir st r out er (t hen cal l ed
an Int er net Message Pr ocessor , or IMP). The onl y micr oCPU in t hose days was t he Z80
f r om Zil og. RIP wor ked gr eat on t he r out er s t hat we had at t hat t ime. It had ver y l ow
over head (comput at ional l y speaking). OSPF is a gr eat pr ot ocol , but at t he t ime of RIP,
t her e was no machine t hat coul d r un it economical l y.
Today, wit h t he f ast er pr ocessor s and pl ent if ul memor y, OSPF is t he r out ing pr ot ocol of
choice (f or open r out ing pr ot ocol s, t hat is). It is ver y ef f icient when it comes t o t he
net wor k, al t hough it is a compl icat ed pr ot ocol and is ver y CPU int ensive when it buil ds
it s r out ing t abl e.
OSPF is an IGP pr ot ocol . It exchanges r out ing inf or mat ion wit hin a singl e aut onomous
syst em (descr ibed as t hose net wor ks and r out er s gr ouped int o a singl e domain under one
aut hor it y). It can be used in smal l , medium, or l ar ge int er net wor ks, but t he most
dr amat ic ef f ect s wil l be r eadil y not iced on l ar ge IP net wor ks. As opposed t o RIP (a
dist ance vect or pr ot ocol ), OSPF is a l inkst at e pr ot ocol . It maint ains t he st at e of ever y
l ink in t he domain, and inf or mat ion is flooded t o al l r out er s in t he domain. Fl ooding is
t he pr ocess of r eceiving t he inf or mat ion on one por t and t r ansmit t ing it t o al l ot her
act ive por t s on t he r out er . In t his way, al l r out er s r eceive t he same inf or mat ion. This
inf or mat ion is st or ed in a dat abase cal l ed t he linkstate dat abase, which is ident ical on
ver y r out er in t he AS (or ever y ar ea if t he domain is spl it int o mul t ipl e ar eas). Based on
inf or mat ion in t he l inkst at e dat abase, an al gor it hm known as t he Dykst r a al gor it hm
r uns and pr oduces a shor t est pat h t r ee based on t he met r ics, using it sel f as t he r oot of
t he t r ee. The inf or mat ion t his pr oduces is used t o buil d t he r out ing t abl e.
Int r oduct ion t o Rout ing Pr ot ocol s (OSPF)
OSPF is an IGP r out ing pr ot ocol .
Oper at es dif f er ent l y t han RIP.
Used on smal l , medium, and l ar ge net wor ks.
Most benef icial on l ar ge, compl ex net wor ks
It is a l inkst at e pr ot ocol .
It maint ains t he knowl edge of al l l inks (int er f aces) in t he AS
The l ink inf or mat ion is f l ooded t o al l ot her r out er s in t he AS (or ar ea).
Al l r out er s r eceive t he same l ink inf or mat ion
Al l r out er s comput e t heir own t abl es based on t he l ink inf or mat ion.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 24
Other IPRelated Protocols
The Int er net Cont r ol Message Pr ot ocol (ICMP) is an ext ension of t he IP l ayer . This is
t he r eason t hat it uses an IP header and not a UDP (User Dat agr am Pr ot ocol ) header .
The pur pose of ICMP is t o r epor t or t est cer t ain condit ions on t he net wor k. IP del iver s
dat a and has no ot her f or m of communicat ion. ICMP pr ovides some er r or r epor t ing
mechanism f or IP. Basical l y, it al l ows int er net devices (host s or r out er s) t o t r ansmit
er r or or t est messages. These er r or messages may be t hat a net wor k dest inat ion cannot
be r eached or t hey may gener at e/r epl y t o an echo r equest packet (PING, expl ained
l at er ).
The Int er net Gr oup Management Pr ot ocol (IGMP) is an ext ension of t he IP pr ot ocol
t hat al l ows f or mul t icast ing t o exist f or IP. The mul t icast addr ess al r eady exist ed f or
IP but t her e was not a cont r ol pr ot ocol t o al l ow it t o exist on a net wor k. IGMP is a
pr ot ocol t hat oper at es in wor kst at ions and r out er s and al l ows t he r out er s t o
det er mine which mul t icast addr esses exist on t heir segment s. Wit h t his knowl edge,
r out er s can buil d mul t icast t r ees al l owing mul t icast dat a t o be r eceived and
pr opagat ed t o t heir mul t icast wor kst at ions. IGMP header s ar e used as t he basis f or al l
mul t icast r out ing pr ot ocol s f or IPv4.
RSVP is cal l ed t he resource reservation protocol and al l ows some sembl ance of Qual it y of
Ser vice (QoS) t o exist using IP. It used t o be we coul d incr ease t he speed of a net wor k t o
al l ow mor e bandwidt h on which t o f it hungr y appl icat ions. Wit h t hat capabil it y, QoS
was essent ial l y ignor ed. However , bandwidt h cannot cont inual l y expand. The Int er net
was not pr ovisioned f or Qual it y of Ser vice, and RSVP is t he f ir st at t empt t o al l ow f or
it . It s benef it s ar e appar ent in mul t icast ing appl icat ions, but it can be used wit h unicast
appl icat ions as wel l . It al l ows st at ions on t he net wor k t o r eser ve r esour ces via t he
r out er s on t he net wor k.
Ot her IPRel at ed Pr ot ocol s
ICMP is an ext ension of t he IP pr ot ocol .
IP is connect ionl ess
Possibl e t o have er r or s but t hey ar e not r epor t ed by IP
ICMP al l ows f or int er net devices t o t r ansmit er r or or t est messages
IGMP is al so an ext ension of t he IP pr ot ocol .
Al l ows f or mul t icast t o oper at e on an int er net wor k
Al l ows host s t o ident if y t he gr oups t hey want t o t he r out er
RSVP is an ent r ance t o pr oviding QoS on an IP int er net .
Al l ows devices t o r eser ve r esour ces on t he net wor k
ARP pr ovides t he abil it y t o t r ansl at e bet ween 48bit physical l ayer addr esses
and 32bit IP addr esses.
ARP is not r eal l y par t of t he net wor k l ayer ; it r esides bet ween t he IP and dat al ink
l ayer s. It is t he pr ot ocol t hat t r ansl at es bet ween t he 32bit IP addr ess and a 48bit
Local Ar ea Net wor k addr ess. ARP is onl y used wit h IPv4; IPv6 has no concept of ARP.
Since IP was not int ended t o r un over a LAN, an addr ess scheme was impl ement ed t o
al l ow each host and net wor k on t he int er net t o ident if y it sel f . When TCP/IP was
adapt ed t o r un over t he LAN, t he IP addr ess had t o be mapped t o t he 48bit dat al ink or
physical addr ess t hat LANs use, and ARP is t he pr ot ocol t hat accompl ishes it .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 25
Introduction to Transport Layer Protocols
Int r oduct ion t o Tr anspor t Layer Pr ot ocol s
TCP pr ovides f or r el iabl e dat a t r ansf er using sequence number s and
acknowl edgment s.
UDP pr ovides a simpl e connect ionl ess t r anspor t l ayer t o al l ow appl icat ions
access t o t he IP.
RTP and RTCP ar e f r amewor k pr ot ocol s t hat ar e usual l y incor por at ed int o
an appl icat ion.
It is pl aced at t he t r anspor t l ayer sof t war e t o wor k al ongside TCP
Since IP pr ovides f or a connect ionl ess del iver y ser vice of TCP (Tr ansmission Cont r ol
Pr ot ocol ) dat a, TCP pr ovides appl icat ion pr ogr ams access t o t he net wor k, using a
r el iabl e connect ionor ient ed t r anspor t l ayer ser vice. This pr ot ocol is r esponsibl e f or
est abl ishing sessions bet ween user pr ocesses on t he int er net , and al so ensur es r el iabl e
communicat ions bet ween t wo or mor e pr ocesses. The f unct ions t hat it pr ovides ar e t o:
1. List en f or incoming session est abl ishment r equest s
2. Request a session t o anot her net wor k st at ion
3. Send and r eceive dat a r el iabl y using sequence number s and acknowl edgment s
4. Gr acef ul l y cl ose a session
The User Dat agr am Pr ot ocol (UDP) pr ovides appl icat ion pr ogr ams access t o t he net wor k
using an unr el iabl e connect ionl ess t r anspor t l ayer ser vice. It al l ows t he t r ansf er of
dat a bet ween sour ce and dest inat ion st at ions wit hout having t o est abl ish a session
bef or e dat a is t r ansf er r ed. This pr ot ocol al so does not use t he endt oend er r or
checking and cor r ect ion t hat TCP uses. Wit h UDP, t r anspor t l ayer f unct ional it y is
t her e, but t he over head is l ow. It is pr imar il y used f or t hose appl icat ions t hat do not
r equir e t he r obust ness of t he TCP pr ot ocol ; f or exampl e, mail , br oadcast messages,
naming ser vice, and net wor k management .
The Real Time Pr ot ocol (RTP) and t he Real Time Cont r ol Pr ot ocol (RTCP) al l ow f or
r eal t ime appl icat ions t o t r ul y exist on an IP net wor k. RTP r esides at t he t r anspor t
l ayer and wor ks al ongside t he TCP pr ot ocol , and is a r epl acement f or t he TCP pr ot ocol
f or r eal t ime appl icat ions. RTCP is t he pr ot ocol t hat pr ovides f eedback t o t he RTP
appl icat ion and l et s t he appl icat ion know how t hings ar e going on t he net wor k. The
pr ot ocol s ar e act ual l y f r amewor ks mor e t han pr ot ocol s and ar e usual l y incl uded in
t he appl icat ion it sel f r at her t han r esiding as a separ at e pr ot ocol t hat has an int er f ace.
Dat a is not t he onl y inf or mat ion t hat is being passed ar ound on t he Int er net .
Mul t imedia appl icat ions such as voice and video ar e moving f r om exper iment al st at us t o
emer ging. However , voice and video cannot simpl y be pl aced on a connect ionl ess, packet
swit ched net wor k. They need some hel p, and RTP, al ong wit h RTCP, pr ovides t his hel p.
This in conjunct ion wit h RSVP is paving t he way f or r eal t ime appl icat ions on t he
Int er net .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 26
Introduction to the TCP/IP Standard Applications
Int r oduct ion t o t he TCP/IP St andar d Appl icat ions
TELNETPr ovides r emot e t er minal emul at ion.
FTPPr ovides a f il e t r ansf er pr ot ocol .
TFTPPr ovides f or a simpl e f il e t r ansf er pr ot ocol .
SMTPPr ovides a mail ser vice.
DNSPr ovides f or a name ser vice.
BOOTP/DHCPPr ovides f or management of IP par amet er s.
Remot e t er minal emul at ion is pr ovided t hr ough t he TELNET pr ot ocol . For new user s of
t he TCP/IP pr ot ocol , t his is not Tel enet , a packet swit ching t echnol ogy using t he CCITT
st andar d X.25. It is pr onounced TELNET. This is an appl icat ionl evel pr ot ocol t hat
al l ows t er minal emul at ion t o pass t hr ough a net wor k t o a r emot e net wor k st at ion.
TELNET r uns on t op of t he TCP pr ot ocol and al l ows a net wor k wor kst at ion t o appear
as a l ocal device t o a r emot e device (i.e., a host ).
The Fil e Tr ansf er Pr ot ocol (FTP) is simil ar t o TELNET in t er ms of cont r ol , but t his
pr ot ocol al l ows f or dat a f il es t o be r el iabl y t r ansf er r ed on t he Int er net . FTP r esides
on t op of TCP and uses it as it s t r anspor t mechanism. TFTP is a simpl ex f il e t r ansf er
pr ot ocol (based on an unr el iabl e t r anspor t l ayer cal l ed UDP), and is pr imar il y used f or
boot l oading of conf igur at ion f il es acr oss an int er net .
The Simpl e Mail Tr anspor t Pr ot ocol (SMTP) is an el ect r onic mail syst em t hat is r obust
enough t o r un on t he ent ir e Int er net syst em. This pr ot ocol al l ows f or t he exchange of
el ect r onic mail bet ween t wo or mor e syst ems on an int er net . Al ong wit h a syst em
known as Post Of f ice Pr ot ocol , individual user s can r et r ieve t heir mail f r om
cent r al ized mail r eposit or ies.
The Domain Name Ser vice (DNS) is a cent r al ized name ser vice t hat al l ows user s t o
est abl ish connect ions t o net wor k st at ions using humanr eadabl e names inst ead of
cr ypt ic net wor k addr esses. It pr ovides a namet onet wor k addr ess t r ansl at ion ser vice.
Ther e ar e many ot her f unct ions of DNS, incl uding mail ser ver name t o IP addr ess
t r ansl at ion. Mail ser vice woul d not exist if not f or t he DNS.
The Boot Pr ot ocol (BOOTP) and Dynamic Host Conf igur at ion Pr ot ocol (DHCP) al l ow
f or management of IP par amet er s on a net wor k. These pr ot ocol s do not pr ovide f or
r out er conf igur at ions but endst at ion conf igur at ions. BOOTP was t he or iginal pr ot ocol
t hat pr ovided not onl y a wor kst at ions IP addr ess but possibl y it s oper at ing image as
wel l . DHCP is best known f or it s management al l ocat ion scheme of IP addr esses and is a
super set of BOOTP t hat pr ovides ext ended f unct ions of IP as wel l as IP addr ess
management .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 27
The Internet Protocol (IP)
Now t hat t he int r oduct ions ar e over , l et s get int o t he t echnical det ail s of t he TCP/IP
pr ot ocol suit e. The main goal of IP is t o pr ovide int er connect ion of subnet wor ks (t he
int er connect ion of net wor ks, expl ained l at er ) t o f or m an int er net in or der t o pass dat a.
The IP pr ot ocol pr ovides f our main f unct ions:
1. basic unit f or dat a t r ansf er ,
2. addr essing,
3. r out ing, and
4. f r agment at ion of dat agr ams.
The Int er net Pr ot ocol (IP)
IPs main f unct ion is t o pr ovide f or t he int er connect ion of subnet wor ks t o
f or m an int er net in or der t o pass dat a.
The f unct ions pr ovided by IP ar e:
Basic unit f or dat a t r ansf er
Addr essing
Rout ing
Fr agment at ion of dat agr ams

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 28
Connectionless, BestEffort Delivery Service
The IP l ayer pr ovides t he ent r y int o t he del iver y syst em used t o t r anspor t dat a acr oss
t he Int er net . Usual l y, when anyone hear s t he name IP, he or she aut omat ical l y t hinks
of t he net wor ks connect ed t oget her t hr ough devices commonl y known as routers, which
connect mul t ipl e subnet wor ks t oget her . It is t r ue t he IP per f or ms t hese t asks, but t he IP
pr ot ocol per f or ms many ot her t asks, as ment ioned pr eviousl y. The IP pr ot ocol r uns in
al l t he par t icipat ing net wor k st at ions t hat ar e at t ached t o subnet wor ks so t hat t hey
may submit t heir packet s t o r out er s or dir ect l y t o ot her devices on t he same net wor k. It
r esides bet ween t he dat al ink l ayer and t he t r anspor t l ayer . IP al so pr ovides f or
connect ionl ess dat a del iver y bet ween nodes on an IP net wor k.
Connect ionl ess, Best Ef f or t Del iver y Ser vice
Impl ement s t wo f unct ions: addr essing and f r agment at ion.
IP encapsul at es dat a handed t o it f r om it s upper l ayer sof t war e wit h it s
header s.
IP del iver s dat a based on a best ef f or t .
Tr ansmit s an encapsul at ed packet and does not expect a r esponse
IP r eceives dat a handed t o it by t he dat al ink.
Decapsul at es a packet (st r ips it s header s of f ) and hands t he dat a t o it s
upper l ayer sof t war e
The pr imar y goal of IP is t o pr ovide t he basic al gor it hm f or t r ansf er of dat a t o and f r om
a net wor k. In or der t o achieve t his, it impl ement s t wo f unct ions: addressing and
fragmentation. It pr ovides a connect ionl ess del iver y ser vice f or t he upper l ayer
pr ot ocol s. This means t hat IP does not set up a session (a vir t ual l ink) bet ween t he
t r ansmit t ing st at ion and t he r eceiving st at ion pr ior t o submit t ing t he dat a t o t he
r eceiving st at ion. It encapsul at es t he dat a handed t o it and del iver s it on a besteffort
basis. IP does not inf or m t he sender or r eceiver of t he st at us of t he packet ; it mer el y
at t empt s t o del iver t he packet and wil l not make up f or t he f aul t s encount er ed in t his
at t empt . This means t hat if t he dat al ink f ail s or incur s a r ecover abl e er r or , t he IP
l ayer wil l not inf or m anyone. It t r ied t o del iver (addr essed) a message and f ail ed. It is
up t o t he upper l ayer pr ot ocol s (TCP, or even t he appl icat ion it sel f ) t o per f or m er r or
r ecover y. For exampl e, if your appl icat ion is using TCP as it s t r anspor t l ayer pr ot ocol ,
TCP wil l t imeout f or t hat t r ansmission and wil l r esend t he dat a. If t he appl icat ion is
using UDP as it s t r anspor t , t hen it is up t o t he appl icat ion t o per f or m er r or r ecover y
pr ocedur es.
IP submit s a pr oper l y f or mat t ed dat a packet t o t he dest inat ion st at ion and does not
expect a st at us r esponse. Because IP is a connect ionl ess pr ot ocol , IP may r eceive and
del iver t he dat a (dat a sent t o t he t r anspor t l ayer in t he r eceiving st at ion) in t he
wr ong or der f r om which it was sent , or it may dupl icat e t he dat a. Again, it is up t o t he
higher l ayer pr ot ocol s (l ayer 4 and above) t o pr ovide er r or r ecover y pr ocedur es. IP is
par t of t he net wor k del iver y syst em. It accept s dat a and f or mat s it f or t r ansmission t o
t he dat al ink l ayer . (Remember , t he dat al ink l ayer pr ovides t he access met hods t o
t r ansmit and r eceive dat a f r om t he at t ached cabl e pl ant .) IP al so r et r ieves dat a f r om
t he dat al ink and pr esent s it t o t he r equest ing upper l ayer .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 29
Data Encapsulation by Layer
IP wil l add it s cont r ol inf or mat ion (in t he f or m of header s), specif ic t o t he IP l ayer
onl y, t o t he dat a r eceived by t he upper l ayer (t r anspor t l ayer ). Once t his is
accompl ished, it wil l inf or m t he dat al ink (l ayer 2) t hat it has a message t o send t o t he
net wor k. At t he net wor k l ayer , encapsul at ed dat a is known as a datagram (r umor has it
t hat t his t er m was coined r ef er r ing t o a simil ar message del iver y syst em known as t he
t el egr am). This dat agr am may be t r ansf er r ed over highspeed net wor ks (Et her net ,
Token Ring, FDDI). When t he dat al ink l ayer adds it s header s and t r ail er s it is cal l ed a
packet (a t er m r ef er r ing t o a smal l package). When t r ansmit t ed ont o t he cabl e, t he
physical l ayer frames (basical l y wit h signal ing inf or mat ion such as t he pr eambl e f or
Et her net or t he f l ag f iel d f or Fr ame Rel ay and X.25) t he inf or mat ion it has r eceived
f r om t he dat al ink l ayer ; t her ef or e, it is cal l ed a frame. For most of us, t he t er ms frame
and packet ar e int er changeabl e. If you want t o get int o an ar gument about t hose t er ms
you need t o go f ind t he peopl e who ar e st il l ar guing about baud and bit s per second
(bps). For simpl icit y, consider ing t hat t he pr imar y f ocus of t he book is net wor k pr ot ocol s
over highspeed net wor ks, packet s and f r ames wil l be synonymous. Fr ames wil l not be
ment ioned unl ess t he or iginal specif icat ion mandat ed t hat t er m. It is impor t ant t o
r emember t hat IP pr esent s dat agr ams t o it s l ower l ayer (t he dat al ink l ayer ). When I
t al k about a dat agr am, I am specif ical l y t al king about t he IP l ayer . When I t al k about
a packet , I am specif ical l y t al king about t he access l ayer (dat a l ink and physical ).
The IP pr ot ocol does not car e what kind of dat a is in t he dat agr am. Al l it knows is t hat
it must appl y some cont r ol inf or mat ion, cal l ed an IP header , t o t he dat a r eceived f r om
t he upper l ayer pr ot ocol (pr esumabl y TCP or UDP) and t r y t o del iver it t o some st at ion
on t he net wor k or int er net .
Dat a Encapsul at ion by Layer
The IP pr ot ocol is not compl et el y wit hout mer it . It does pr ovide mechanisms on how
host s and r out er s shoul d pr ocess t r ansmit t ed or r eceived dat agr ams, or when an er r or
shoul d be gener at ed, and when an IP dat agr am may be discar ded. To under st and t he IP
f unct ional it y, a br ief l ook at t he cont r ol inf or mat ion it adds (t he IP header ) t o t he
packet wil l be shown.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 30
IPv4 Header
Ther e ar e many header f iel ds in t he IP header , each wit h a def ined f unct ion t o be
det er mined by t he r eceiving st at ion. The IP header is shown her e, encapsul at ed in an
Et her net packet .
The f ir st f iel d is t he VERS, or ver sion, f iel d. This def ines t he cur r ent ver sion of IP
impl ement ed by t he net wor k st at ion. Ver sion 4 is t he l at est ver sion. The ot her ver sions
out t her e ar e in exper iment al st ages, or t he exper iment s ar e f inished and t he pr ot ocol
did not make it or was used t o t est ver sion 6. Ther e ar e t hr ee ver sions of IP t hat ar e
r unning t oday: 4, 5, and 6. Most do not bel ieve t hat ver sion 5 is out t her e but it is; it is
known as t he St r eams 2 pr ot ocol . The f ol l owing inf or mat ion was t aken f r om RFC 1700.
Assigned Int er net Ver sion Number s
Decimal Keywor d Ver sion Ref er ences
0 Reser ved
13 Unassigned
4 IP Int er net Pr ot ocol RFC791
5 ST ST Dat agr am Mode
6 IPv6 RFC 1883
7 TP/IX TP/IX: The Next Int er net
8 PIP The P Int er net Pr ot ocol
9 TUBA TUBA
1014 Unassigned
15 Reser ved
IPv4 Header

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 31
Header Length, Service Type, and Total Length Fields
The l engt h of t he IP header (al l f iel ds except f or t he IP dat a f iel d) can var y. Not al l
t he f iel ds in t he IP header need t o be used. Fiel ds ar e measur ed in t he amount of 32bit
wor ds. The shor t est IP header wil l be 20 byt es; t her ef or e, t his f iel d woul d cont ain a 5
(20 byt es = 160 bit s; 160 bit s/32 bit s = 5). This f iel d is necessar y, f or t he header can be
var iabl e in l engt h depending on t he f iel d cal l ed options. IPv6 has a st at icl engt h
header f iel d.
The ser vice f iel d was a gr eat idea, but it is r ar el y used and is usual l y set t o 0. This was a
ent r y t hat woul d al l ow appl icat ions t o indicat e t he t ype of r out ing pat h t hey woul d
l ike (t he key point her e is t hat t he appl icat ion chooses t his f iel d). For exampl e, a
r eal t ime pr ot ocol woul d choose l ow del ay, high t hr oughput , and high r el iabil it ya
f il e t r ansf er does not need t his. A TELNET session coul d choose l ow del ay wit h nor mal
t hr oughput and r el iabil it y. Ther e is anot her side t o t his st or y, however . The r out er
must suppor t t his f eat ur e as wel l and t his usual l y means buil ding and maint aining
mul t ipl e r out ing t abl es. The Ser vice t ype is made up of t he f ol l owing f iel ds: pr ecedence,
del ay, t hr oughput , and r el iabil it y. However , suppor t ing t his f iel d caused t he r out er t o
suppor t mul t ipl e r out ing t abl es per r out er , and t his compl icat ion never pr ogr essed wit h
t he r out er vendor s. This pr ecedence bit s of t he ser vice f iel d may have an ent r y of zer o
(nor mal pr ecedence) and up t o 7 (net wor k cont r ol ), which al l ows t he t r ansmit t ing
st at ions appl icat ion t o indicat e t o t he IP l ayer t he pr ior it y of sending t he dat agr am.
This is combined wit h t he D (del ay), T (t hr oughput ), and R (r el iabil it y) bit s. This f iel d is
known as a Type of Ser vice (TOS) ident if ier , and t hese bit s indicat e t o a r out er which
r out e t o t ake:
Header Lengt h, Ser vice Type, and Tot al Lengt h Fiel ds
D bit . Request l ow del ay when set t o 1
T bit . Request high t hr oughput when set t o 1
R bit . Request high r el iabil it y when set t o 1
For exampl e, if t her e is mor e t han one r out e t o a dest inat ion, t he r out er coul d r ead t his
f iel d t o pick a r out e. This becomes impor t ant in t he OSPF r out ing pr ot ocol , which is t he
f ir st IP r out ing pr ot ocol t o t ake advant age of t his. If t he t r ansact ion is a f il e t r ansf er ,
you may want t o set t he bit s t o 0 0 1 t o indicat e t hat you do not need l ow del ay or high
t hr oughput , but you woul d l ike high r el iabil it y. TOS f iel ds ar e set by appl icat ions (i.e.,
TELNET or FTP) and not r out er s. Rout er s onl y r ead t his f iel d, t hey do not set t his
f iel d. Based on t he inf or mat ion r ead, r out er s wil l sel ect t he opt imal pat h f or t he
dat agr am. It is up t o t he TCP/IP appl icat ion r unning on a host t o set t hese bit s bef or e
t r ansmit t ing t he packet on t he net wor k. It does r equir e a r out er t o maint ain mul t ipl e
r out ing t abl esone f or each t ype of ser vice.
The t ot al l engt h is t he l engt h of t he dat agr am (not packet ) measur ed in byt es (t his
f iel d al l ot s f or 16 bit s, meaning t he dat a ar ea of t he IP dat agr am may be 65535 byt es in
l engt h). IPv6 al l ows f or a concept known as jumbo datagrams. Remember , TCP may not
al ways r un over Et her net , Token Ring, and so on. It may r un as a channel at t ached t o a
Cr ay super comput er t hat suppor t s much l ar ger dat a sizes.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 32
Fragmentation
Fr agment at ion
Dif f er ent media al l ows f or dif f er ent sized dat agr ams t o be t r ansmit t ed and
r eceived.
Fr agment at ion al l ows a dat agr am t hat is t oo l ar ge t o be f or war ded t o t he
next LAN segment t o be br oken up int o smal l er segment s t o be r eassembl ed at
t he dest inat ion.
The f r agment at ion occur s at t he r out er t hat cannot f or war d it t o t he next
int er f ace.
Appl icat ions shoul d use pat h MTU discover y t o f ind t he smal l est dat agr am
size.
Do not depend on t he r out er
A gr eat idea, but basical l y discour aged, is t he capabil it y of f r agment at ion. Ther e may
be t imes when a packet t r ansmit t ed f r om one net wor k may be t oo l ar ge t o t r ansmit on
anot her net wor k. The def aul t dat agr am size (t he dat a and IP header s but not t he
Et her net packet header s of t he physical f r ame header s or t r ail er s), known as t he pat h
MTU, or Maximum Tr ansmission Unit , is def ined as t he size of t he l ar gest packet t hat
can be t r ansmit t ed or r eceived t hr ough a l ogical int er f ace. This size incl udes t he IP
header but does not incl ude t he size of any Link Layer header s or f r aming (Ref er ence
RFC 1812). It def aul t s t o 576 byt es when t he dat agr am is t o be sent r emot el y (of f t he
l ocal subnet ). Many IP dat agr ams ar e t r ansmit t ed at 576 byt es, a r ecommended st andar d
size, inst ead of queuing t he max MTU size.
But why cr ippl e net wor ks t hat suppor t l ar ge packet s? If a TCP connect ion pat h is f r om
FDDI t o Token Ring, why shoul d t he def aul t dat agr am size be onl y 576 byt es when
t hese media t ypes suppor t much l ar ger packet sizes? The answer is, it shoul dnt , but we
cannot guar ant ee t hat any int er mediat e media t ypes bet ween t he Token Ring and t he
FDDI suppor t t hose l ar ge sizes. For exampl e, suppose t he sour ce is a Token Ring st at ion
and t he dest inat ion is an FDDI st at ion. In bet ween t he t wo st at ions ar e t wo Et her net
net wor ks t hat suppor t onl y 1518byt e packet s. Ther e ar e no t abl es in t he r out er s or
wor kst at ions t hat indicat e media MTU (maximum t r ansmission unit ). Ther e is a pr ot ocol
(pat h MTU discover y, RFC 1981 f or IPv6 and 1191 f or IPv4) t hat al l ows f or t his, but
under IPv4 it is opt ional whet her t he r out er and wor kst at ions impl ement it . Ther ef or e,
t o be saf e, inst ead of impl ement ing RFC 1191, a t r ansmit t ing st at ion wil l send a 576byt e
dat agr am or smal l er when it knows t he dest inat ion is not l ocal .
Anot her exampl e is when a host is init ial ized on an Et her net , it can send a r equest f or a
host ser ver t o boot it . Let s say t he boot st r ap host is on an FDDI net wor k. The host
sends back a 4472byt e message, and t his is r eceived by t he br idge. Nor mal l y, t he br idge
wil l discar d t he packet because br idges do not have t he capabil it y of f r agment ing an IP
dat agr am. Ther ef or e, some br idge vendor s have pl aced t he IP f r agment at ion al gor it hm
in t heir br idges t o al l ow f or somet hing l ike t his t o occur . This is a gr eat exampl e of how
pr opr iet ar y (al beit based on an st andar d) impl ement at ion of cer t ain pr ot ocol s can
benef it t he consumer .
Al t hough a r out er wil l f r agment a dat agr am, it wil l not r eassembl e it . It is up t o t he
r eceiving host t o r eassembl e t he dat agr am. Why? Wel l , consider ing t he impl icat ion of
CPU and memor y r equir ed t o r eassembl e ever y dat agr am t hat was f r agment ed, t his
woul d be an over whel ming f eat ur e of t he r out er . If t her e wer e 2000 st at ions
communicat ing al l using f r agment at ion, it coul d easil y over whel m a r out er , especial l y
in t he ear l y days.
A f r agment ed IP dat agr am cont ains t he f ol l owing f iel ds:
Ident if icat ion. Indicat es which dat agr am f r agment s bel ong t oget her so dat agr ams do
not get mismat ched. The r eceiving IP l ayer uses t his f iel d and t he sour ce IP addr ess t o
ident if y which f r agment s bel ong t oget her .
Fl ags. Indicat e whet her mor e f r agment s ar e t o ar r ive or no mor e dat a is t o be sent f or
t hat dat agr am (no mor e f r agment s).
Whet her or not t o f r agment a dat agr am (a dont f r agment bit ). If a r out er r eceives a
packet t hat it must f r agment t o be f or war ded and t he dont f r agment bit is set , t hen it
wil l discar d t he packet and send an er r or message (t hr ough a pr ot ocol known as ICMP,
discussed l at er ) t o t he sour ce st at ion.
Of f set . Each IP header f r om each of t he f r agment ed dat agr ams is al most ident ical . This
f iel d indicat es t he of f set (in byt es) f r om t he pr evious dat agr am t hat cont inues t he
compl et e dat agr am. In ot her wor ds, if t he f ir st f r agment has 512 byt es, t his of f set
woul d indicat e t hat t his dat agr am st ar t s t he 513t h byt e of t he f r agment ed dat agr am. It
is used by t he r eceiver t o put t he f r agment ed dat agr am back t oget her .
Fr agment at ion (cont inued)
Using, t he t ot al l engt h and t he f r agment of f set f iel ds, IP can r econst r uct a
f r agment ed dat agr am and del iver it t o t he upper l ayer sof t war e. The t ot al l engt h
f iel d indicat es t he t ot al l engt h of t he or iginal packet , and t he of f set f iel d indicat es t o
t he node t hat is r eassembl ing t he packet t he of f set f r om t he beginning of t he packet . It
is at t his point t hat t he dat a wil l be pl aced in t he dat a segment t o r econst r uct t he
packet .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 33
Time to Live (TTL)
This f iel d seems t o conf use many peopl e, so l et s st at e what it does up f r ont . Time t o
Live (TTL) indicat es t he amount of t ime t hat a dat agr am is al l owed t o st ay on t he
net wor k. It is not used by t he r out er s t o count up t o 16 t o know when t o discar d a
packet . Ther e ar e t wo f unct ions f or t he TTL f iel d: t o l imit t he l if et ime of a TCP
segment (t r ansmit t ed dat a) and t o end r out ing l oops.
The init ial TTL ent r y is set by t he or iginat or of t he packet , and it var ies. To be ef f icient ,
a r out ing updat e wil l set t his f iel d t o a 1 (RIP wil l ). Why set it t o anyt hing el se, when
t hat updat e is sent onl y t o it s l ocal segment s? Mul t icast pr ot ocol s set it t o many
dif f er ent sizes t o l imit t he scope of t he mul t icast . For nor mal usage, many appl icat ions
set it t o 32 or 64 (2 and 4 t imes t he size of a RIP net wor k). Time t o l ive is a f iel d t hat is
used by r out er s t o ensur e t hat a packet does not endl essl y l oop ar ound t he net wor k.
This f iel d (cur r ent l y def ined as t he number of seconds) is set at t he t r ansmit t ing st at ion
and t hen, as t he dat agr am passes t hr ough each r out er , it wil l be decr ement ed. Wit h t he
speed of t odays r out er s, t he usual decr ement is 1. One al gor it hm is t hat t he r eceiving
r out er wil l not ice t he t ime a packet ar r ives, and t hen, when it is f or war ded, t he r out er
wil l decr ement t he f iel d by t he number of seconds t he dat agr am sat in a queue wait ing
f or f or war ding. Not al l al gor it hms wor k t his way. A minimum decr ement wil l al ways be
1. The r out er t hat decr ement s t his f iel d t o 0 wil l discar d t he packet and inf or m t he
or iginat or of t he dat agr am (t hr ough t he ICMP pr ot ocol ) t hat t he TTL f iel d expir ed and
t he dat agr am did not make it t o it s dest inat ion.
Time t o Live (TTL)
The t imet ol ive f iel d may al so be set t o a cer t ain t ime (i.e., init ial ized t o a l ow number
l ike 64) t o ensur e t hat a packet st ays on t he net wor k f or onl y a set t ime. Some r out er s
al l ow t he net wor k administ r at or t o set a manual ent r y t o decr ement . This f iel d may
cont ain any number f r om 0 t o 255 (an 8bit f iel d).

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 34
Protocol and Checksum Fields
What IP asks her e is, who above me want s t his dat a? The pr ot ocol f iel d is used t o
indicat e which higher l evel pr ot ocol shoul d r eceive t he dat a of t he dat agr am (i.e.,
TCP, UDP, OSPF, or possibl y ot her pr ot ocol ). This f iel d al l ows f or mul t ipl exing. Ther e
ar e many pr ot ocol s t hat may r eside on t op of IP. Cur r ent l y, t he most common t r anspor t
impl ement at ions ar e TCP and UDP. If t he pr ot ocol f iel d is set t o a number t hat ident if ies
TCP, t he dat a wil l be handed t o t he TCP pr ocess f or f ur t her pr ocessing. The same is t r ue
if t he f r ame is set t o UDP or any ot her upper l ayer pr ot ocol . This f iel d becomes ver y
appar ent t o anyone who t r oubl eshoot s net wor ks. Simpl y st at ed, it al l ows f or IP t o
del iver t he dat a (af t er it st r ips of f and pr ocesses it s f iel ds) t o t he next int ended
pr ot ocol .
The second f iel d is a Cycl ic Redundancy Check (CRC) of 16 bit s. How t his number is
ar r ived at is beyond t he scope of t his book, but t he idea behind it is t o ensur e t he
int egr it y of t he header . A CRC number is gener at ed f r om t he dat a in t he IP dat a f iel d
and pl aced int o t his f iel d by t he t r ansmit t ing st at ion. When t he r eceiving st at ion r eads
t he dat a, it wil l comput e a CRC number . If t he t wo CRC number s do not mat ch, t her e is
an er r or in t he header and t he packet wil l be discar ded. St r et ching it , you may t hink of
t his as a f ancy par it y check. As t he dat agr am is r eceived by each r out er , each r out er
wil l r ecomput e t he checksum. Why change it ? Because t he TTL f iel d is changed by each
r out er t he dat agr am t r aver ses.
Pr ot ocol and Checksum Fiel ds

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 35
IP Options Field
This f iel d is f ound on IPv4 packet header s. It cont ains inf or mat ion on sour ce r out ing
(not hing t o do wit h Token Ring), t r acing a r out e, t imest amping t he packet as it
t r aver ses r out er s, and secur it y ent r ies. These f iel ds may or may not be in t he header
(which al l ows f or t he var iabl e l engt h header ). It was f ound t hat most of t hese
f eat ur es wer e not used or wer e bet t er impl ement ed in ot her pr ot ocol s, so IPv6 does not
impl ement t hem as a f unct ion of t he IP header .
Sour ce r out ing is t he abil it y of t he or iginat ing st at ion t o pl ace r out e inf or mat ion int o
t he dat agr am t o be int er pr et ed by r out er s. Rout er wil l f or war d t he dat agr am based on
inf or mat ion in t he sour ce r out e f iel ds, and in some cases, it wil l be bl ind. The or iginat or
indicat es t he pat h it wishes t o t ake, and t he r out er s must obey, even if t her e is a bet t er
r out e. Ther e ar e t wo t ypes: l oose sour ce r out e (LSR) and st r ict sour ce r out e (SSR).
The dif f er ence bet ween t he t wo is r el at ivel y simpl e. Rout es (IP addr esses) ar e pl aced in
a f iel d of t he IP header . The IP addr esses indicat e t he r out e t he dat agr am woul d l ike t o
t ake t o t he dest inat ion. Loose sour ce r out e al l ows a r out er t o f or war d t he dat agr am
t o any r out er it f eel s is cor r ect t o ser vice t he next r out e indicat ed in t he sour ce r out e
f iel d. A compl et e l ist of IP addr esses f r om t he sour ce t o t he dest inat ion is pr obabl y not
in t he IP header , but some point s in t he Int er net shoul d be used t o f or war d t he
dat agr am. For exampl e, IP mul t icast uses LSR f or t unnel ing it s IP mul t icast dat agr ams
over t he nonmul t icast enabl ed IPv4 Int er net . St r ict sour ce r out ing f or ces a r out er t o
f or war d a dat agr am t o it s dest inat ion compl et el y based on t he r out es indicat ed by t he
sour ce r out e f iel d.
IP Opt ions Fiel d
The Tr acer out e is a ver y usef ul ut il it y. It al l ows t he echoing of t he f or war ding pat h of
a dat agr am. Wit h t his opt ion set , t he point s t o which t he dat agr am is r out ed ar e echoed
back t o t he sender . This al l ows you t o f ol l ow a dat agr am al ong a pat h. It is ver y of t en
used in t r oubl eshoot ing IP net wor ks. If you have Windows 95, you have t his ut il it y.
Type in (DOS pr ompt ) t r acer t <IP addr ess> and wat ch t he echo point s on your scr een.
IPv6 el iminat ed t his f iel d and t hose f unct ions t hat wer e not used or wer e bet t er
impl ement ed by ot her pr ot ocol s.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 36
Source and Destination Address Fields
The next f iel ds ar e t he sour ce and dest inat ion addr ess f iel ds. These f iel ds ar e ver y
impor t ant f or t hey ident if y t he individual IP net wor k and st at ion on any IP net wor k.
These ar e par t icul ar l y impor t ant , f or user s wil l be most awar e of t his when st ar t ing
t heir wor kst at ion or t r ying t o access ot her st at ions wit hout t he use of a domain name
ser ver or an upt odat e host f il e. These f iel ds indicat e t he originator of t he dat agr am,
t he final dest inat ion IP addr ess t hat t he packet shoul d be del iver ed t o, and t he IP
addr ess of t he st at ion t hat or iginal l y t r ansmit t ed t he packet . Al l host s on an IP
int er net wil l be ident if ied by t hese addr esses. IP addr essing is ext r emel y impor t ant and a
f ul l discussion f ol l ows. Cur r ent l y, t hese addr esses ar e set t o 32 bit s, which al l ows f or
over 4 bil l ion addr esses.
This may sound l ike a l ot of addr esses but unf or t unat el y, many mist akes wer e made in
assigning IP addr esses t o cor por at ions and individual s. The mist akes wer e made
unknowingl y, f or t his pr ot ocol suit e t ook of f by sur pr ise. This is f ul l y discussed at t he
end of t his sect ion. Ther e ar e t wo t ypes of addr esses: cl assl ess and cl assf ul . Bot h t ypes
wil l be pr esent ed.
Sour ce and Dest inat ion Addr ess Fiel ds
IPv6, t he next ver sion of IP (cur r ent l y being impl ement ed as aut onomous isl ands in t he
sea of IPv4), al l ows f or 128 bit s of addr ess, which basical l y al l ows f or t housands of
bil l ions of host s t o be number ed. Al so, wit h IPv6, an ef f icient al l ocat ion scheme was
devel oped t o hand out IPv6 addr esses as wel l .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 37
The IP Address Scheme
Ever y syst ems engineer who under st ands IP, under st ands t he IP addr ess scheme. It can
be t he most conf using aspect of IP, however , it must be l ear ned. Do not conf use t his
addr essing st r uct ur e wit h t hat of media (Et her net ) addr ess. The ideas and concept s t hat
evol ved t he pr ot ocol of TCP/IP wer e devised separ at e f r om any dat al ink pr ot ocol s of
Et her net and Token Ring. Host s wer e not at t ached t o a l ocal highspeed net wor k (l ike
Et her net or Token Ring). Host s communicat ed wit h each ot her t hr ough l owspeed,
point t opoint ser ial l ines (t el ephone l ines). Ther ef or e, an addr essing scheme t o
ident if y TCP/IP host s and wher e t hey wer e l ocat ed was impl ement ed. The addr essing
scheme used t o ident if y t hese host s is cal l ed t he 32bit IP addr ess. This is al so known as
a pr ot ocol addr ess.
Ther e ar e t wo t ypes of net wor k addr essing schemes used wit h IP:
Cl assl ess. The f ul l addr ess r ange can be used wit hout r egar d t o bit r eser vat ion
f or cl asses. This t ype of addr essing scheme is pr imar il y not used in dir ect host
assignment . The scheme is dir ect l y appl ied t o t he r out ing t abl es of t he Int er net
and ISPs.
Cl assf ul . The or iginal (RFC 791) segment at ion of t he 32bit addr ess int o specif ic
cl asses denot ing net wor ks and host s.
The f un par t is t hat t he r ange of addr esses (32 bit s f or IPv4) avail abl e ar e used f or bot h
cl assl ess and cl assf ul addr essing. Most of us wil l never have t o wor r y about t he
cl assl ess r ange of IP addr essing, f or it is used on t he Int er net it sel f and not on
cust omer net wor ks. It pr ovides an easy met hod wit h which t o r educe t he r out ing t abl es
and al l ow l ar ge addr ess r anges t o be pr ovided t o t he ISPs. The f ir st par t of t his sect ion
wil l deal wit h cl assf ul , since it st ar t ed f ir st and is cont inuing t o be used on many
net wor ks. It is conf using, but keep r eading.
The IP Addr ess Scheme
Two t ypes of addr essing schemes f or IPv4:
Cl assf ul (based on RFC 791)The or iginal st yl e of addr essing based on
t he f ir st f ew bit s of t he addr ess
Gener al l y used in cust omer sit es
Cl assl essThe new st yl e of addr essing t hat disr egar ds t he Cl ass bit s of
an addr ess and appl ies a var iabl e 32 pr ef ix (mask) t o det er mine t he
net wor k number
Gener al l y used by t he gl obal r out ing t abl es and ISPs
Enabl es ver y ef f icient r out ing, smal l er r out ing t abl es
Enabl es ef f icient IP addr ess al l ocat ion (t o t he ISPs) and
assignment (t o t he ISP cust omer )
The second par t of t his sect ion wil l deal wit h cl assl ess addr essing and t he concept s of
CIDR (Cl assl ess Int er Domain Rout ing), Var iabl e Lengt h Subnet Masks (VLSM), and
super net t ing.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 38
Classful AddressingThe Original Address Scheme
Cl assf ul Addr essingThe Or iginal Addr ess Scheme
Based on RFC 791.
An addr essing scheme based on a simpl e hier ar chy.
Cl ass of addr ess det er mined by t he f ir st f ew bit s of t he addr ess.
Uses t he dot t ed decimal not at ion syst em.
Al l ocat ed by t he Int er net Regist r y.
Al l addr esses ul t imat el y owned by t he IANA.
Many, many year s ago, RFC 760 int r oduced IP. The beginnings of t he IP addr essing
scheme wer e ver y simpl e and f l at . This RFC didnt have a concept of cl asses (not t o be
conf used wit h cl assl ess IP of t oday); addr essing was an 8bit pr ef ix t hat al l owed as
many as 200+ net wor ks and a l ot of host s per net wor k. RFC 791 obsol et es RFC 760 and
t his RFC incl uded t he concept of IP addr ess cl asses. Back t hen, it was easy t o change
addr essing schemes f or t her e wer e but a f ew host s on t he ent ir e net wor k. RFC 950
int r oduced us t o subnet t ing and RFC1518 int r oduced t he CIDR (cl assl ess) pr ot ocol .
Ther e have been many enhancement s t o t he or iginal IP addr essing scheme, but t hey
cont inue t o oper at e on t he bases of Cl ass and Cl assl ess.
Addr essings pur pose was t o al l ow IP t o communicat e bet ween host s on a net wor k or on
an int er net . Cl assf ul IP addr esses ident if y bot h a par t icul ar node and a net wor k
number wher e t he par t icul ar node r esides on an int er net . IP addr esses ar e 32bit s l ong,
separ at ed int o f our f iel ds of 1 byt e each. This addr ess can be expr essed in decimal , oct al ,
hexadecimal , and binar y. The most common IP addr ess f or m is wr it t en in decimal and is
known as t he dotted decimal notation syst em.
Ther e ar e t wo ways t hat an IP addr ess is assigned; it al l depends on your connect ion. If
you have a connect ion t o t he Int er net , t he net wor k por t ion of t he addr ess is assigned
t hr ough an Int er net Ser vice Pr ovider . Yes, t her e ar e t hr ee addr esses assigned f or
pr ivat e addr essing. But f or a connect ion t o t he Int er net , at l east one addr ess must be
def ined as a publ ic addr ess assigned t o you by t he ISP.
To ident if y al l host s on your net wor k wit h publ ic addr ess, t he ISP wil l onl y pr ovide t he
net wor k r ange (a cont inuous IP net wor k addr ess segment ) t hat you may wor k wit h. It
wil l not assign host number s nor assign t he net wor k number s t o any par t of your
net wor k. If your net wor k wil l never have a connect ion t o t he Int er net , you can assign
your own addr esses, but it is highl y r ecommended t hat you f ol l ow RFC 1918 f or t he
pr ivat e assignment . These ar e Cl ass A, Cl ass B, and Cl ass C addr ess assignment s f or
pr ivat e use.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 39
IP Address Format
Each host on a TCP/IP net wor k is uniquel y ident if ied at t he IP l ayer wit h an addr ess
t hat t akes t he f or m of <net id, host id>. The addr ess is not r eal l y separ at ed and is r ead as
a whol e. The whol e addr ess is al ways used t o f ul l y ident if y a host . Ther e is no
separ at ion bet ween t he f iel ds. In f act , when an IP addr ess is wr it t en, it is har d t o t el l
t he dist inct ion bet ween t he t wo f iel ds wit hout knowing how t o separ at e t hem.
The f ol l owing shows t he gener al ized f or mat of an IP addr ess:
<Net wor k Number , Host Number > in t he f or m of xxx.xxx.xxx.xxx
In decimal , t he addr ess r ange is 0.0.0.0 t hr ough 255.255.255.255. 128.4.70.9 is an exampl e of
an IP addr ess. When l ooking at t his addr ess, it is har d t o t el l which is t he net wor k
number and which is t he host number , l et al one a subnet number . Except f or t he f ir st
byt e, any of t he byt es can indicat e a net wor k number or host number . The f ir st byt e
al ways indicat es a net wor k number . In or der t o under st and how t his is accompl ished,
l et s l ook f ir st at how IP addr esses ar e divided.
Each byt e (or in Int er net t er ms, an oct et ) is 8 bit s l ong, nat ur al l y! Each of t he byt es,
however , can ident if y a net wor k, a subnet wor k, or a host .
As shown in t he sl ide, t her e ar e 32 bit s separ at ed int o 4 byt es t hat ar e used t o r epr esent
an IP addr ess. The net wor k number can shif t f r om t he f ir st byt e t o t he second byt e t o
t he t hir d byt e. The same can happen t o t he host por t ion of t he addr ess. xxx r epr esent s a
decimal number f r om 0 t o 255 (t he r eason f or t hr ee xs).
IP Addr ess For mat
Uniquel y ident if ies bot h t he net wor k and t he host in one addr ess.
Uses t he f or m:
<Net wor k ID Host Number >
The addr ess is 32 bit s in l engt h which is f ur t her separ at ed int o 4 byt es of 8 bit s
each.
xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx
Ther e ar e f ive cl asses of addr esses: AE.
IP addr esses ar e divided int o f ive cl asses: A, B, C, D, and E. RFC 791, which cl assif ied
t hese t ypes, did so wit hout t he f or egoing knowl edge of subnet s. The cl asses al l owed f or
var ious amount s of net wor ks and host s t o be assigned. Cl asses A, B, and C ar e used t o
r epr esent host and net wor k addr esses. Cl ass D is a special t ype of addr ess used f or
mul t icast ing (f or exampl e, OSPF r out ing updat es use t his t ype of addr ess as wel l as IP
mul t icast ). Cl ass E is r eser ved f or exper iment al use.
For t hose t r ying t o f igur e out t his addr essing scheme, it is best if you al so know t he
binar y number ing syst em and ar e abl e t o conver t bet ween decimal and binar y. Final l y,
IP addr esses ar e somet imes expr essed in hexadecimal and it is hel pf ul t o know. IPv6 uses
onl y hexadecimal . The most common f or m f or IPv4 is decimal . This book shows most
addr esses in binar y and decimal .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 40
Identifying a Class
For net wor k and host assignment , Cl asses A t hr ough C ar e used. Cl ass D is not used f or
t his, and Cl ass E is never assigned. Ref er r ing t o t he sl ide, we can see how t he cl asses ar e
act ual l y def ined. How does a host or int er net device det er mine which addr ess is of
which cl ass? Since t he l engt h of t he net wor k ID is var iabl e (dependent on t he cl ass), a
simpl e met hod was devised t o al l ow t he sof t war e t o det er mine t he cl ass of addr ess and,
t her ef or e, t he l engt h of t he net wor k number .
The IP sof t war e wil l det er mine t he cl ass of t he net wor k ID by using a simpl e met hod of
r eading t he f ir st bit (s) in t he f ir st f iel d (t he f ir st byt e) of ever y packet . IP addr esses
cont ain 4 byt es. The sl ide shows an addr ess in binar y. If you ar e not f amil iar wit h
binar y, I suggest you st udy up on it , f or under st anding addr essing, especial l y cl assl ess
addr essing, can onl y be f igur ed out by conver t ing t he addr ess t o binar y.
The sl ide br eaks t he IP addr ess down int o it s binar y equival ent . If t he f ir st bit of t he
f ir st byt e is a 0, it is a Cl ass A addr ess. If t he f ir st bit is a 1, t hen t he pr ot ocol mandat es
r eading t he next bit . If t he next bit is a 0, t hen it is a Cl ass B addr ess. If t he f ir st and
second bit s ar e 1 and t he t hir d bit is a 0, it is a Cl ass C addr ess. If t he f ir st , second, and
t hir d bit s ar e 1, t he addr ess is a Cl ass D addr ess and is r eser ved f or mul t icast addr esses.
Cl ass E addr esses ar e r eser ved f or exper iment al use.
Ident if ying a Cl ass

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 41
Class A Address
Cl ass A addr esses t ake t he 4byt e f or m <net wor k number .host .host .host >, byt es 0, 1, 2,
and 3. Subnet t ing has not been int r oduced her e yet ! Cl ass A addr esses use onl y t he f ir st
of t he 4 byt es f or t he net wor k number . Cl ass A is ident if ied by t he f ir st bit in t he f ir st
byt e of t he addr ess. If t his f ir st bit is a 0, t hen it ident if ies a Cl ass A addr ess. The l ast 3
byt es ar e used f or t he host por t ion of t he addr ess.
Cl ass A addr essing al l ows f or 126 net wor ks (using onl y t he f ir st byt e) wit h up t o
16,777,214 mil l ion host s per net wor k number . The r ange f or Cl ass A is 1126. Wit h 24 bit s
in t he host f iel ds (l ast 3 byt es), t her e can be 16,277,214 host s per net wor k (again,
disr egar ding subnet s). This is act ual l y (2
n
24) 2. We subt r act 2 because no host can be
assigned al l 0s (r eser ved t o indicat e a def aul t r out e, which wil l be expl ained l at er ) and
no host can be assigned al l 1s. For exampl e, 10.255.255.255 is not al l owed t o be assigned
t o a host , al t hough it is a val id addr ess. Yes, t his is a br oadcast addr ess.
If al l 7 bit s ar e set t o 1 (st ar t ing f r om t he r ight ), t his r epr esent s 127 in decimal , and
127.x.x.x is r eser ved as an int er nal l oopback addr ess and cannot be assigned t o any host
as a unique addr ess. This is used t o indicat e whet her your l ocal TCP/IP st ack (sof t war e)
is up and r unning. The addr ess is never seen on t he net wor k. You may want t o l ook at
your machine IP addr esses (usual l y by t yping net st at r at t he command l ine) and you
wil l not ice t hat ever y machine has 127.0.0.1 assigned t o it . The sof t war e uses t his as an
int er nal l oopback addr ess. You shoul d not see t his addr ess cr oss over t he LAN (via a
pr ot ocol anal yzer such as a Snif f er .) In f act , 127.anyt hing is pr oposed as t he l oopback.
127.1.1.1 del iver s t he same r esul t s as 127.0.0.1. Think about it . A whol e addr ess r ange
assigned t o one f unct ion: l oopback. The pr obl em is, if we t r ied t o change it , it woul d
pr obabl y cause mayhem on t he mil l ions of host s t hat cur r ent l y use IP.
Cl ass A Addr ess
Today, Cl ass A addr esses ar e being handed out t hr ough a dif f er ent met hod invol ving
Int er net Ser vice Pr ovider s t hat uses t he Cl assl ess Int er Domain Rout ing Pr ot ocol
(CIDR), which is expl ained at t he end of t his sect ion. When you get a Cl ass A addr ess,
you wil l be t ol d t o subnet it appr opr iat el y (you wil l be t ol d what t he subnet addr ess
is). You wil l not get t he whol e Cl ass A addr ess. A good quest ion her e: How much of t he
addr ess space does a Cl ass A addr ess def ine? (Hint : Do not t hink of it as a Cl ass addr ess
but do use t he f ir st bit t o answer t he quest ion). Give up?

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 42
Class B Address
Okay, t he answer is, 50 per cent of t he avail abl e addr ess space is def ined by Cl ass A.
How? Change t he addr ess Cl ass bit s t o binar y. Since t he addr ess is def ined by t he f ir st
bit al one and t he next 31 bit s ar e disr egar ded, it r epr esent s 50 per cent of t he avail abl e
bit s f or addr ess assignment (f or t hose scr at ching t heir heads, it is 2
n
31 bit s, which is 50
per cent of t he addr ess space). Dont t hink in a cl assor ient ed envir onment . I simpl y
asked how much of t he addr ess space can be def ined by using 1 bit . This wil l become mor e
appar ent in t he cl assl ess r out ing sect ion.
Cl ass B addr esses t ake t he f or m <net wor k number .net wor k number .host .host >, f or byt es
0, 1, 2, and 3. This is t he most r equest ed cl ass of addr ess and is t he easiest t o assign
subnet s t o. Cl ass B addr esses use t he f ir st 2 byt es of t he 4 byt es f or t he net wor k number
and t he l ast t wo f iel ds f or t he host number . It is ident if ied by t he f ir st 2 bit s of t he f ir st
byt e. If t he f ir st bit is a 1, t hen t he al gor it hm checks t he second bit . If t he second bit is a
0, t his wil l ident if y a Cl ass B addr ess.
This al l ows f or 16,384 net wor k number s (10111111.11111111.host .host or (2
n
14), wit h
each net wor k number capabl e of suppor t ing 65,534 (2
n
16 2) host s (net .net .11111111.111
11110). Wait , t her e ar e 16 bit s in t he f ir st t wo f iel ds, t his shoul d al l ow f or 65,535
net wor ks. Since Cl ass B r eser ves t he f ir st 2 bit s t o ident if y t he cl ass t ype (in binar y, a
10xxxxxx in t he f ir st f iel d), t her e ar e l imit ed addr ess number s t hat may be used in t he
f ir st f iel d (val id r ange becomes 2
n
14). This t r ansl at es t o 128191 (in decimal ) as t he
al l owabl e net wor k number s in t he f ir st f iel d. Since t he f ir st f iel d ident if ies t he cl ass,
t he second f iel d is f r ee t o use al l 8 bit s, and can r ange f r om 0 t o 255. The t ot al r ange
f or net wor k number s f or Cl ass B addr esses is 128 t o 191 (in t he f ir st f iel d), 0 t o 255 (in
t he second f iel d), and xxx.xxx (x r epr esent s t he host ID) in t he t hir d and f our t h f iel ds.
This is t he most popul ar cl ass of addr esses.
It pr ovides t he l ar gest r ange of addr essing possibil it ies. However , unl ess companies have
handed in t heir Cl ass B addr esses, t his cl ass is exhaust ed and t hey ar e no l onger given
out .
Okay, l et s t r y again. How much of t he avail abl e addr ess space is def ined by Cl ass Bs
r eser ved f ir st 2 bit s? The answer is on t he next page.
Cl ass B Addr ess

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 43
Class C Address
For t hose who answer ed 25 per cent , t his is cor r ect . Wit h t he f ir st t wo bit s r eser ved,
t his l eaves 30 bit s f or addr ess assignment . 230 is 25 per cent of t he avail abl e addr ess
space. Cl ass C t akes t he f or m of <net wor k number .net wor k number .net wor k
number .host >, byt es 0, 1, 2, and 3. Cl ass C addr esses use t he f ir st 3 out of 4 byt es of t he
addr ess f or t he net wor k number and t he l ast f iel d f or t he host number . This al l ows
l ot s of net wor ks wit h a f ewer host s per net wor k. A Cl ass C addr ess is ident if ied by t he
f ir st 3 bit s of t he f ir st f iel d. If t he f ir st and second bit s ar e 1s and t he t hir d bit is a 0,
t his wil l ident if y a Cl ass C addr ess (110xxxxx). Since t he f ir st 3 bit s in t he f ir st f iel d
wil l al ways be a 110xxxxx, t he al l owabl e net wor k r ange is 192223 in t he f ir st f iel d.
This al l ows f or 2,097,152 (2
n
21) possibl e net wor k addr esses. Al l of t he bit s in t he second
and t hir d f iel ds ar e al l owed t o be used (incl uding al l 0s and 1s). Ther ef or e, t he whol e
al l owabl e r ange f or Cl ass C net wor k addr esses is 192 t o 223 (in t he f ir st f iel d), 0 t o 255
(in t he second f iel d), and 0 t o 255 (in t he t hir d f iel d). The l ast f iel d wil l r ange f r om 1 t o
254 f or host assignment . This al l ows 2,097,152 net wor k number s, each capabl e of
suppor t ing 254 host s (al l 0s and al l 1s ar e st il l r eser ved no mat t er what t ype of r out ing
and addr essing you ar e using). No host can be assigned a 0 or al l 1s as it s addr ess. Cl ass C
addr esses al l ow onl y 254 host s per net wor k number . Not ice t hat t he l ar gest number in
t he f ir st f iel d may go up t o 223. Any number over 223 in t he f ir st f iel d wil l indicat e a
Cl ass D addr ess. Cl ass D addr esses ar e r eser ved as mul t icast addr esses.
Cl ass C addr esses ar e t he most commonl y assigned by t he NIC. Cl ass B addr esses have
been exhaust ed. Ther ef or e, ISPs and r egional Int er net Regist r ies ar e assigning Cl ass C
and Cl ass A (wit h subnet s).
Cl ass C Addr ess
Okay, yep, one mor e quest ion: How much of t he addr ess space is def ined by Cl ass Cs bit
r eser vat ion of 110?

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 44
Class D Address
For t hose who answer ed 12.5 per cent , you ar e cor r ect . This is t he odd t hing. Ther e ar e
mil l ions of Cl ass C addr esses (net wor ks), but t hey onl y r epr esent 12.5 per cent of t he
avail abl e addr ess space. Again, get t hose cal cul at or s out .
Cl ass D addr esses ar e special addr esses and ar e known as mul t icast addr esses. This
addr ess t ype is assigned t o a gr oup of net wor k wor kst at ions and is not assigned t o
r epr esent a unique addr ess. They ar e used t o send IP dat agr ams t o a gr oup, but not al l
of t he host s on a net wor k. Mul t icast ing has many uses, incl uding being used f or
addr essing r out er updat e messages as wel l as del iver ing dat a, video, and voice over IP.
Using a mul t icast addr ess is a mor e ef f icient way of br oadcast ing r at her t han using a
br oadcast addr ess, f or t he upper l ayer sof t war e wil l not al ways be int er r upt ed ever y
t ime a br oadcast packet ar r ives. Mul t icast ing is dif f er ent t han br oadcast ing. Wit h
br oadcast ing, ever y st at ion t hat r eceives t he br oadcast packet wil l aut omat ical l y pass
it t o t he upper l ayer sof t war e wit hout r egar d t o t he addr ess. Ever y st at ion t hat
r eceives a br oadcast packet must pr ocess it .
Wit h a mul t icast addr ess, each individual IP st at ion must be wil l ing t o accept t he
mul t icast IP addr ess bef or e t he t r anspor t l ayer sof t war e wil l be int er r upt ed. Each NIC
wil l r egist er a MAC l ayer mul t icast addr ess on it s adapt er car d, just l ike a unicast
addr ess (t he IP addr ess t o Et her net mapping of a mul t icast addr ess is shown in a moment ).
In t his way, t he NIC can discar d a packet wit hout int er r upt ing t he upper l ayer
sof t war e (in most cases, anyway, some dupl icat ion of mul t icast addr esses exist , and t his
t oo is shown in a moment ). The NIC is al r eady set up t o r eceive a br oadcast packet . This is
one addr ess known as FFFFFFFFFFFF.
As of t his wr it ing, RFC 1700 (assigned number s) f ul l y expl ains t he mapping of Cl ass D
addr esses t o MAC addr esses and it al so indicat es assigned mul t icast addr esses and
r egist er ed mul t icast addr esses.
Mul t icast ing is compl et el y cover ed in anot her sect ion of t his book.
Cl ass D Addr ess

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 45
Classes AD Review
For most of us, Cl asses A t hr ough D is what we wil l be wor king wit h. We wil l never
have t o dabbl e in t he cl assl ess societ y of addr esses. Cl asses A t hr ough D wil l be ar ound
f or a l ong t ime and IPv6, al t hough adopt ed, is st il l quit e a f ew year s away. IPv6 does
not under st and t he concept of cl ass net wor king and suppl ies enough addr esses f or
mil l ions of year s t o comeenough t o suppl y an IP addr ess f or al l t hose r ef r iger at or s
and washer s and dr yer s. (Dont l augh, t his wil l happen. Why? Think of maint enance, or
being abl e t o cont r ol t hings in your house via your br owser . For get t o t ur n of f some
l ight s or set t he secur it y up? The possibil it ies ar e endl ess.)
For t hose newbies, t he easiest way t o r emember IP cl ass addr esses is t his: The first byte
wil l al ways ident if y t he class address. Whet her you have conver t ed t o binar y or ar e
l ooking at t he addr ess in it s dot t ed decimal f or m, t he f ir st byt e gives it away. A is t he
first letter in t he al phabet , and t her ef or e a Cl ass A net wor k addr ess is onl y t he first byte,
l eaving t he l ast t hr ee f iel ds f or host addr essing. B is t he second letter in t he al phabet ,
and t her ef or e t he net wor k por t ion of t he addr ess is t he f ir st 2 bytes of t he addr ess,
l eaving t he l ast t wo f iel ds f or host addr ess. C is t he third letter in t he al phabet , and t he
net wor k por t ion t akes up t he f ir st 3 bytes of t he addr ess and l eaves one f iel d f or host
addr esses. As f or r emember ing which number is associat ed t o which cl ass, t he onl y f iel d
t hat is impor t ant is t he f ir st f iel d. Memor ize t he st ar t ing net wor k number f or each
cl ass.
Cl asses AD Review
Net wor k host s can be assigned a Cl ass addr ess of Cl ass AD
These ar e simpl t a gr ouping of addr esses t hat indicat e host and addr ess
assignment
Cl ass A has t he net wor k number in t he f ir st byt e of t he addr ess and t he l ast
t hr ee byt es ar e assigned t o t he host .
Cl ass B has t he net wor k number in t he f ir st t wo byt es of t he addr ess and t he
l ast t wo byt es ar e assigned t o t he host .
Cl ass C has t he net wor k number in t he f ir st t hr ee byt es of t he addr ess and
t he host is assigned t o t he l ast byt e.
Cl ass D is a mul t icast addr ess.
A is t he f ir st l et t er of t he al phabet and t her ef or e t he net wor k numdber is
assigned t he f ir st byt e.
B is t he second l et t er and t her ef or e has t he net wor k number assigned t o t he
f ir st t wo byr t es.
Cl ass C is t he t hir d l et t er and t her ef or e has t hew net wor k number assigned
t o t he f ir st t hr ee byt es.
The cl asses ar e
Cl ass A: 0127
Cl ass B: 128191
Cl ass C: 192223
Cl ass D: 223239
Reser ved: 240254

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 46
Subnetting
Now t hat IP addr ess assignment has been shown, l et s f ur t her conf use t he issue by
l ooking at subnet masks. Anot her name f or subnet masks is ext ended net wor k pr ef ix.
This book wil l cont inue t o use t he wel l known name of subnet t ing. Subnet t ing is
expl ained in RFC 950.
Impl ement ing cl asses in net wor k number s gave us some hier ar chical st r uct ur e t o t he
Int er net . Using cl ass assignment , you coul d sel ect a net wor k number based on t he
number of host s t hat ar e on or wil l be on your net wor k. But t he r ange was ver y
l imit ed. Cl ass A gave you a l ot of host s but just a f ew net wor ks. Cl ass B was t he one
picked t o al l ow f or a bal ance of host s and net wor ks, and Cl ass C al l owed many
net wor ks and a f ew host s. Not much choice, eit her you had a l ot of net wor ks or a l ot of
host s. The most r equest ed net wor k number was Cl ass B; however , many Cl ass B
assignment s wer e not f ul l y usedr eal l y har d t o have 65,535 host s on a singl e net wor k.
Too many Cl ass C addr esses f il l ed up r out ing t abl es and most did not f ul l y use al l 254
host addr esses. Fur t her mor e, some sit es wer e r equest ing mul t ipl e addr esses t o f ul f il l
t heir needs.
Not many Cl ass A addr esses wer e handed out . In f act , af t er about 63 assignment s, Cl ass
A assignment s wer e not handed out at al l . Cl ass B addr esses wer e popul ar and wer e t he
most f r equent l y asked f or addr ess cl ass. What s t he deal wit h Cl ass C addr esses? Wit h
onl y 254 host s avail abl e f or assignment , many Cl ass C addr esses have t o be assigned.
Again, using Cl ass assignment , t he r out ing t abl es st ar t ed t o f il l up and most of t he bit s
wer e wast ed when impl ement ed. It was l ike being given a f ivepassenger car , but you
never had anyone in t he ot her seat s. In shor t , subnet t ing al l ows f or t r emendous
ef f iciency not onl y in Int er net r out ing t abl es but al so on cust omer net wor ks as wel l .
It al l ows us t o assign some of t he bit s nor mal l y used by t he host por t ion of t he addr ess
and r eassign t hese bit s t o t he net wor k por t ion of t he addr ess. This is accompl ished f or
t he r easons t hat f ol l ow.
Subnet t ing

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 47
Reasons for Subnetting
As net wor k number s wer e assigned, many sit es wer e impl ement ing r out ing on t heir
l ocal sit es. This had many benef it s. You coul d have many net wor ks at your sit e (using
RFC 791), but t he pr obl em was t hat you had t o be given mul t ipl e net wor k addr esses
(Cl ass A, Cl ass B, or Cl ass C) t o accompl ish t his. This st ar t ed t o f il l up t he ARPAnet
r out ing t abl es and cr eat ed ot her pr obl ems as wel l .
Many net wor ks t hat accessed t he Int er net wer e cr eat ing t heir own homegr own
subnet t ed envir onment s, and many wer e beginning t o be impl ement ed. Bef or e al l
net wor ks ceased communicat ing because of incompat ibil it ies, RFC 950 was r el eased,
def ining a st andar d met hod f or subnet t ing an IP addr ess. A net wor k mask t hat cover s
simpl y t he net wor k por t ion of t he addr ess is known as t he natural mask (no por t ion of t he
addr ess is subnet t ed).
The sl ide shows a subnet t ed net wor k t opol ogy connect ed t o t he Int er net . It is assigned
a Cl ass B addr ess and uses an 8bit subnet mask. The Int er net knows of t he IP addr ess
130.1.0.0. It does not know t he subnet s invol ved. This al l ows t he Int er net addr ess
(r out ing) t abl es t o r emain smal l er .
Subnet masks ar e used in r out er s and net wor k st at ions.
Reasons f or Subnet t ing
Most IP addr ess assignment s wer e not used ver y ef f icient l y.
Having mil l ions of host s f or Cl ass A and 254 host s f or Cl ass was not
wor king ver y wel l
Many sit es wer e r equest ing mul t ipl e net wor k number s due t o var iabl e
amount s of net wor ks at t heir sit es.
Many net wor ks wer e impl ement ing pr opr iet ar y subnet s.
RFC 950 def ined t he adopt ed subnet met hod.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 48
Subnetting Examples (Classes A, B, and C)
Any of t he cl asses can be subnet t ed, al t hough some ar e easier t han ot her s. The sl ide
shows t he t hr ee cl asses of net wor ks, each wit h an addr ess. This t ime, each of t he
addr esses has been assigned a subnet mask. A mask is a ser ies of bit s t hat ar e appl ied
(known as ANDing) t o a por t ion of t he addr ess. This por t ion is what we ar e subt r act ing
f r om t he or iginal addr ess. It indicat es how many bit s we ar e masking out of t he or iginal
host por t ion of an addr ess t o use as a subnet addr ess. A subnet addr ess is a r eal net wor k
number , but simpl y a net wor k under t he cl ass addr ess. Subnet masks ar e var iabl e in
l engt h and move f r om t he f ir st host bit t o t he l ast . In ot her wor ds, t hey move t o t he
r ight of t he addr ess. Moving a mask t o t he l ef t of t he net wor k addr ess, beyond it s
nat ur al mask, is known as super net t ing (t his concept wil l be discussed in a moment ).
In t his exampl e of t he Cl asses A and B addr esses, I have shown al l avail abl e bit s
f ol l owing t he net wor k ID por t ion of t he addr ess used t o indicat e a subnet . The Cl ass C
addr ess uses t he f ir st 3 bit s of t he host por t ion of t he addr ess f or t he subnet . Wit h any
of t he addr esses, any of t he host bit s (except f or 2 bit s at t he end of t he addr ess; t her e
must be at l east one host on a net wor k) may be used f or subnet t ing. For exampl e, a Cl ass
B addr ess may use al l of t he t hir d oct et and 2 bit s of t he f our t h oct et f or subnet t ing.
This woul d give 1024 possibl e subnet wor k number syes, 1024. Those who ar e paying
at t ent ion her e shoul d have caught t he f act t hat in or der t o have 1024 subnet addr esses
we must use al l 0s and al l 1s in t he subnet f iel d as val id subnet addr esses. This may seem
cont r ar y t o host and net wor k ID assignment , but it is not . Al l 0s and al l 1s ar e al l owed
t o be used in t he subnet por t ion of any addr ess (t hey st il l cannot be used in t he host or
net wor k por t ions of t he addr ess as unique addr esses). Ref er t o RFC 1812. This causes
pr obl ems wit h subnet br oadcast s, which Il l expl ain l at er . Using t he pr eceding exampl e
(10bit subnet on a Cl ass B), each subnet can suppor t up t o 62 host s (63 woul d indicat e a
br oadcast ).
Subnet t ing Exampl es (Cl asses A, B, and C)
Subnet consider at ions:
1. Host s and r out er s must impl ement subnet t ing (t her e is a way ar ound t his
discussed under Pr oxy ARP) and l ocal l y must have t he same mask.
2. The r out er must be abl e t o dist inguish bet ween al l 1s as a subnet addr ess and a
subnet br oadcast .
3. In some sit uat ions, t he r out ing updat e pr ot ocol must suppor t it .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 49
More Subnet Examples
Subnet t ing conf iscat es unused bit s, al l owing f or mor e ef f icient use of an addr ess.
Subnet t ing al l ows f or mor e ef f icient use of addr essing space and l ower s t he number of
r out es in t he Int er net r out ing t abl es. The bit s ar e t aken away f r om host assignment and
given back t o ident if y a subnet of a net wor k addr ess. The sl ide depict s t his. The subnet is
a r eal net wor k. It is a subnet under t he net wor k number . Wit h subnet t ing a Cl ass B
addr ess, we can t ake any amount of t he bit s in t he t hir d byt e, or 6 bit s of t he f our t h
byt e (1 t hr ough 8 bit s; t hey shoul d be cont iguous, st ar t ing f r om t he l ef t ) of t he IP
addr ess and make t hem par t of t he net wor k number (a subnet under t he net wor k
number ). The f or mat of t he IP addr ess woul d now be: <net wor k number , subnet number ,
host number >. For exampl e, if t he addr ess assigned t o a par t icul ar host is 130.1.5.1, t he
net wor k por t ion woul d be 128.1 and t he host por t ion woul d be 5.1. Wit h subnet t ing
(assuming al l 8 bit s of t he t hir d f iel d wer e consumed f or a subnet addr ess), t he addr ess
woul d be def ined as net wor k number 130.1 and subnet 5, wit h a host ID of 1.
Subnet t ing a Cl ass B addr ess is easy when you subnet t he ent ir e t hir d oct et . However , it
becomes dif f icul t when you subnet onl y a por t ion of t he t hir d oct et . Suppose t he f ir st 5
bit s (st ar t ing f r om t he l ef t ; t hey shoul d st ar t f r om t he l ef t and r emain cont iguous
going t o t he r ight ) ar e r eser ved in t he t hir d f iel d f or assigning subnet number s. What
subnet s do we have now? Conver t t hose f ir st 5 bit s of t hat oct et t o binar y. Al l f ive of
t hose bit s ar e now assigned t o t he subnet number and may not be used f or host IDs. Five
bit s yiel ds 32 subnet number s (2
n
5). Now, t he big chal l enge: Ident if y t hose number s!
If we st ar t f r om t he l ef t and go 5 bit s t o t he r ight , we get X.X.11111000.X as a net wor k
number (we dont car e what is in t he X). The binar y number s ar e t aken l it er al l y and
wil l yiel d subnet s in mul t ipl es of 8 (8 is t he f ir st binar y bit set t o a 1). This gives us 0, 8,
16, 24, 32, 40, 48, 56, 64, 72, 80, 88, 96, 104, 112, 120, 128, 136, 144, 152, 160, 168, 176, 184, 192,
200, 208, 216, 224, 232, 240, 248.
You r eal l y must compl et el y under st and binar y bef or e heading int o t his ar ea.
Mor e Subnet Exampl es

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 50
Physical and Logical Addresses
A subnet can be compl icat ed t o f igur e out . The addr ess f iel ds do not al l ow f or mor e
t han 255 t o be pl aced in each f iel d. However , it is possibl e t o have host 257 on your
net wor k. Host 257 is not wr it t en int o t he addr ess, but using t he subnet mask, we can
physical l y have a host 257 on a singl e net wor k.
Do not conf use t he addr esses. A subnet t ed addr ess is st il l r ead as if subnet t ing has not
been t ur ned on. It is not wr it t en dif f er ent l y. For exampl e, if t he addr ess is 130.1.9.1 and
t he subnet mask is 255.255.248.0, t hen it is net wor k 130.1, subnet 8, and host 257.
The point her e is t hat you must make sur e t hat you know t he subnet mask bef or e t r ying
t o det er mine t he host , subnet , and net wor k.
Physical and Logical Addr esses

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 51
Subnet Mask Template
Not sur e about t he pr evious exampl e? Let s br eak it out . To ident if y t he subnet s is a
l it t l e t r icky. The pr evious sl ide is shown again. As you can see, t he ver t ical l ine
separ at ing t he host and subnet por t ions of t he addr ess is t he dividing l ine. The f ir st bit
in t he subnet por t ion of t he addr ess is set t o 1. The subnet woul d not be 1. In
cal cul at ing t he val ue of t he subnet , t he whol e t hir d f iel d is t aken int o consider at ion.
Ther ef or e, since t hat bit is set , it is act ual l y a binar y 8 (t he f our t h bit ). Ther ef or e, t he
f ir st subnet number wil l be a 0. Each subsequent subnet wil l be a mul t ipl e of 8.
In t he pr evious exampl e wit h each of t hose subnet wor k number s, we coul d possibl y have
2046 host s per subnet wor k number . This is a l it t l e mor e r eal ist ic t han not subnet t ing.
Not subnet t ing gives us 65,534 host s. We wer e assigned one IP addr ess and, wit h
subnet t ing, we wer e abl e t o make bet t er use of t he addr ess wit hout having t o r eser ve
mor e addr esses (net wor k number s). Al so, wit h subnet t ing, onl y one IP addr ess is in t he
Int er net r out ing t abl es, even t hough we have 32 subnet s on our net wor k. The Int er net
r out ing t abl es do not car e about subnet s. We used one Cl ass B net wor k number and
have 32 subnet s avail abl e t o us f r om t he one Cl ass B net wor k. Wit hout subnet t ing, we
woul d have one net wor k number and up t o 65,534 host s assigned t o it .
How did we get 32 possibil it ies? Using 5 bit s f or t he subnet mask gives us 32 possibl e
combinat ions (0 t o 31), or 2
n
5. Remember , we can move t he mask anywher e in t he 14
avail abl e bit s. The subnet mask coul d have used al l 8 bit s in t he t hir d oct et , which
woul d give us 256 subnet number s (al l 0s and al l 1s being al l owed).
Subnet Mask Templ at e
How do we wr it e a subnet mask? It is al ways wr it t en in decimal and shows t he number
t hat wil l be used t o mask t he bit s. For exampl e, l et s use t he IP addr ess 130.40.132.3.
Using t he f ir st 5 bit s of t he f ir st host f iel d (t he t hir d oct et ) yiel ds 248 (conver t t he
f ir st 5 bit s t o binar y 11111000). The byt e is r ead as a whol e 8 bit s even t hough par t of it
is used f or t he subnet and par t f or host assignment . This means t he subnet mask f or t hat
IP addr ess wil l be 255.255.248.0 in decimal . This is t he mask t hat we have assigned t o t he
net wor k addr ess of 130.40.132.3. We wil l al ways use 255 in t he net wor k pot ion of t he
subnet mask. The 248 is used t o t el l t he net wor k st at ion t o use t he f ir st 5 bit s (5 bit s
binar y is 248 decimal ) of t he net wor k addr ess, not f or a host ID, but f or a subnet . It
t el l s a net wor k st at ion which bit s t o use f or a subnet mask. The r emaining 11 bit s (t he
r emaining 3 bit s of t he t hir d oct et and 8 bit s of t he f our t h oct et ) shoul d be used f or t he
host ID. This al l ows f or 32 subnet s wit h 2046 host s on each subnet .
Ther ef or e, t he IP addr ess of 130.40.132.3, wit h a subnet mask of 255.255.248.0, yiel ds t he
net wor k number 130.40, subnet number 128, and host ID 1027.64

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 52
An Example Conversion
(Hint : Conver t t he addr ess t o binar y, appl y t he mask in binar y, and t hen conver t it
back t o decimal as shown in t he sl ide.)
An oper at ion is per f or med on an IP addr ess. It is cal l ed a bit wise AND oper at ion. The IP
addr ess is ANDed wit h t he subnet mask t o al l ow t he net wor k st at ion t o det er mine t he
subnet mask. Yes, some mat h is invol ved her e. Basical l y, when you ar e ANDing t wo
binar y number s t oget her , t he f ol l owing r ul e appl ies:
1. 1 AND 1 = 1
2. 1 AND 0 = 0
3. 0 AND 0 = 0
Af t er t his oper at ion, t he bit s t hat f al l out indicat e t he net wor k and subnet bit s.
The sl ide shows t he mask oper at ion. At t he bot t om is t he IP addr ess in binar y. This
addr ess is l ogical l y ANDed wit h t he mask. The bit s t hat dr op out of t his oper at ion wil l
indicat e t o any TCP/IP st at ion t he net wor k addr ess. It masks out t he host addr ess and
l eaves t he net wor k addr ess.
Remember one ot her it em: Even t hough we have boundar ies, using a shor t subnet mask
moves t he binar y number t hat we ar e t r ying t o get . In t he pr evious exampl e, we kept
using t he bit s in t he t hir d oct et as if t hey wer e par t of t he f our t h oct et . That is how we
came up wit h 257. Since t he mask was shor t er t han al l 8 bit s in t he t hir d oct et , when
f igur ing out t he addr essing, we cont inued t o use t he bit s of t he t hir d oct et as if t hey
wer e par t of t he f our t h oct et . This makes t he l ast bit of t he t hir d oct et t he 256 bit
(binar y) f or t he f our t h oct et . Be car ef ul , using t his same exampl e, we must cl ear our
heads and st ar t over when f igur ing out what number s ar e now assigned t o t he subnet .
Af t er we have f igur ed out t he host number , we t hen appl y t he mask, just l ike new, back
on t he t hir d oct et and l ook f or t he subnet s. If it is a 7bit subnet , t hen af t er we
conver t t o binar y, we number t he l ast bit in t he t hir d oct et as t he f ir st bit of t he
subnet number ing scheme, however , not act ual l y par t of t he subnet number it sel f .
Sounds conf using but t r y a f ew mor e.
Cl ass A addr esses can use t he second, t hir d, or f our t h (not t he whol e f our t h f iel d)
f iel d f or subnet s.
Cl ass B addr esses can use t he t hir d or f our t h (not t he whol e f our t h f iel d) f iel d f or
subnet s.
Cl ass C is t r icky. The onl y f iel d l ef t is t he singl e host f iel d (one byt e). Subnet t ing t his
is al l owed, but you can onl y use up t o 6 of t he bit s in t he f our t h f iel d. You need t o have
a coupl e of host s somewher e!
An Exampl e Conver sion

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 53
Lets Try One
You have been assigned an addr ess of 150.5.0.0. You need 75 subnet s wit h at l east 75
host s per subnet . What is t he accept abl e subnet mask?
The f ir st st ep is t o f ind out how many bit s ar e needed f or 75 subnet s. In binar y, 6 bit s
r epr esent 64 possibl e subnet s (2
n
6). Not enough. Seven bit s is 128 (0 incl usive) and t his is
t he number of bit s t hat we wil l use. Pl us it gives us r oom f or expansion. This l eaves 9
bit s f or host s, which al l ows f or 510 host s per subnet .
We st ar t t o assign subnet s f r om t he l ef t and wor k t o t he r ight . We assign t he host s
f r om t he r ight and wor k t o t he l ef t .
You must al so def ine t he br oadcast addr ess f or a subnet . If you want ed t o send
somet hing t o al l host s on a subnet t hen t he host s f iel d must be set t o al l 1s. Wit h t his
subnet mask, t her e ar e 9 bit s of 1s f or an al l host s br oadcast addr ess.
Anot her exampl e (not shown in t he sl ide) woul d be t o def ine t he mask f or a net wor k t o
suppor t 40 host s per subnet using t he cl ass addr ess 195.1.10.0. Fir st , we det er mine t hat
t his addr ess is a Cl ass C addr ess and t hat onl y t he l ast oct et can be used f or subnet t ing.
For t y host s is r epr esent ed by 2
n
6, which al l ows f or 60 host s. This may seem l ike a l ot , but
t he near est mask woul d be 2
n
5, which woul d give us 30 possibl e host IDs, and t his is not
enough. For t y conver t ed t o binar y is 101000. However , in t he conver sion we must r emain
cont iguous and we cannot int er l eaf host and subnet bit s. Ther ef or e, we move t he l ef t 6
bit s and t hen we can consume al l 5 bit s t o t he r ight . However , t his onl y l eaves 2 bit s f or
a subnet . We can have 4, 2 bit s l ef t , subnet s wit h 62 (2
n
6) 2 host s per subnet . If t he sit e
needed mor e subnet s, we woul d have t o assign mor e Cl ass C addr esses t o t he sit e.
Let s Tr y One

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 54
Subnet Bits
This sl ide pr ovides a r eview of t he avail abil it y of bit s used f or subnet s.
Subnet Bit s

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 55
Subnet Restrictions
Subnet s ar e good al l owing f or a mor e ef f icient use of t he addr ess bit s, but when using a
r out ing updat e pr ot ocol such as RIP ver sion 1, you must be car ef ul about assigning a
subnet mask. This pr ot ocol onl y al l ows you t o assign one mask per net wor k number .
Subnet masks al l ows f or ef f iciency of addr ess space, but t her e ar e possibl e pr obl ems.
Under a r est r ict ion of one subnet mask per net wor k, ID can st il l cause inef f iciencies.
For exampl e, a ser ial l ine (a t el ephone connect ion) bet ween t wo sit es needs onl y t wo
host IDs. But wit h t he r est r ict ion of onl y one subnet mask, we wil l st il l not make gr eat
use of al l t he bit s. Under t his cir cumst ance, we woul d have subnet down t o t wo bit s t o
make t he most ef f icient use of t he addr ess (we onl y need t wo host s). But t his wil l not
al l ow us t o use t he addr ess f or host assignment on t he LAN (unl ess we onl y have t wo
host s on t he LAN). As you wil l see l at er , t he best opt ion is t o al l ow var iabl el engt h
subnet masks. In ot her wor ds, move t he mask ar ound on dif f er ent subnet s t hat have
dif f er ent r equir ement s. This is good, but you must make sur e t hat t he r out ing pr ot ocol
(RIP, RIPv2, OSPF, et c.) under st ands t his as wel l . Point bl ank, RIP does not , but RIPv2
does. OSPF does. Why? Rout ing updat es have t he subnet mask incl uded in t he updat e (it
is in t he l inkst at e adver t isement f or OSPF). RIP does not incl ude any subnet masks f or
r out ing ent r ies in it s t abl e.
When using t he RIPv1 r out ing pr ot ocol (expl ained l at er ), t he subnet mask must r emain
t he same t hr oughout a singl e Cl ass B assignment . For exampl e, if t he net wor k
assignment is 130.1.0.0 and t he subnet mask assigned is 255.255.255.0, t he subnet mask must
r emain t he same t hr oughout t he 130.1.0.0 net wor k. If t he net wor k addr ess changes (f or
exampl e, t o 131.1.0.0), t he subnet mask may al so change f or t his new net wor k number .
Subnet Rest r ict ions
RIP ver sion 2 and OSPF do not have t his r est r ict ion because t hey br oadcast t heir subnet
masks in t he t abl e wit h t he net wor k IDs (mor e on t his in a moment ).

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 56
Subnet Mask Decisions
Subnet Mask Decisions
Subnet t ing is based on t he f ol l owing:
Host s
Subnet s
Ser ial l ines
Expansion
Mer ger s
Rout ing pr ot ocol (RIP v1 or v2, OSPF)
Let s say you ar e assigned one net wor k number and you ar e using RIP ver sion 1.
Al t hough we ar e int r oducing t his concept her e, it is cover ed in mor e det ail l at er . It is
pr ovided her e t o give you an under st anding t hat under cer t ain condit ions, cer t ain
decisions have t o be made. The subnet mask must be t he same t hr oughout your net wor k,
unl ess you change net wor k IDs. You must make a decision on how l ar ge t he subnet mask
shoul d be. How many host s per subnet wil l t her e be? What about expansion? These ar e
issues you must consider when assigning a subnet mask. Wit h RIPv1, it is a t r adeof f .
OSPF and RIPv2 do not have t his t r adeof f , but car e must st il l be t aken when assigning
net wor k masks t o a net wor k number . This is shown compl et el y in t he next sect ion on
advanced IP addr essing concept s.
This r est r ict ion becomes r eadil y not iceabl e when assigning an IP addr ess t o a ser ial l ine
(t wo r out er s using a l eased phone l ine t o connect ). Ther e have been cir cumst ances t hat
some r out er vendor s have come up wit h t hat al l ow f or t he no IP addr ess assignment f or
a ser ial l ine. However , if t he ser ial l ink needs an addr ess assignment and you ar e not
using RIP ver sion 2 or OSPF, a whol e subnet number is wast ed on t his point t opoint
l ink. A ser ial l ink wil l consume a net wor k number and associat ed host IDs. Ther ef or e, a
unique net wor k number wil l be assigned and, inst ead of being abl e t o use al l avail abl e
host IDs, it wil l be possibl e t o use onl y t wo host IDs (t her e wil l be onl y t wo addr essabl e
point s on t hat net wor k).
The r est of t he host IDs wil l be l ost f or t hat net wor k number and wil l be assigned and
used f or t hat ser ial l ink; t her ef or e t hey wil l not be abl e t o be assigned t o any ot her
l inks. If you have a l ar ge sit e t hat wil l encompass many ser ial l inks and you do not
have t he abil it y t o assign a l ar ge number of net wor k number s, use subnet addr essing
and t he r out ing pr ot ocol of OSPF. OSPF suppor t s var iabl el engt h subnet masks, which
wil l col l apse t hat ser ial l ink int o t wo host s wit hin a net wor k number ; t her ef or e, no
host number s ar e wast ed on ser ial l inks. Var iabl el engt h subnet masks al l ow a singl e
net wor k number t o use mul t ipl e masks (unl ike RIP ver sion 1, RIP ver sion 2 al l ows
VLSM). This al l ows mor e bit s t o be assigned back t o t he net wor k, al l owing a mor e
ef f icient use of t he addr ess.
A f ew mor e t hings you need t o consider : If t he net wor k st at ion moves t o a new net wor k,
does t he IP addr ess f or t hat st at ion change? Like t he cur r ent t el ephone syst em, IP
addr esses must change when t he net wor k st at ion is moved t o a new net wor k t hat
empl oys a dif f er ent net wor k number . If t he net wor k st at ion is moved on t he same
l ogical net wor k, t he IP addr ess may r emain t he same. For exampl e, if a net wor k st at ion
is moved t o a dif f er ent par t of t he same subnet , t he whol e IP addr ess may st ay t he same.
If t he net wor k st at ion is moved t o a dif f er ent subnet (dif f er ent subnet number ), t he IP
addr ess of t he net wor k st at ion must change.
This subject wil l be picked up again in t he sect ion Advanced IP Addr essing.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 57
Assigning More Than One Address to an Interface
Have a net wor k wit h 275 host s but you wer e assigned al l Cl ass C addr esses? What can
you do her e? TCP/IP f ul l y suppor t s t he abil it y t o assign mor e t han one subnet or
net wor k number t o t he same segment . Act ual l y t he r out er vendor s impl ement ed t his as
an abil it y of TCP/IP. This means t hat one net wor k may empl oy mor e t han one net wor k
number on t he same physical cabl e pl ant . In or der t o accompl ish t his, a r out er must be
used. Net wor k st at ions cont inue t o bel ieve t hey ar e communicat ing wit h a r emot e
net wor k st at ion, but t he r out er is simpl y pr oviding t he addr ess t r ansl at ion. The packet
goes in one por t and t hen r ight back out t he same por t . The t wo nodes act ual l y r eside
on t he same net wor k segment . A r out er wil l t ake t he st eps necessar y t o al l ow net wor k
st at ions t o conver se on t he net wor k. Impl ement at ions ar e dif f er ent , so t he amount of
net wor k number s t hat may be assigned t o t he same cabl e pl ant var ies.
For exampl e, as shown in t he sl ide, mul t ipl e Cl ass C net wor k number s may be assigned t o
t he same cabl e pl ant . Cl ass C addr esses al l ow onl y f or 254 host IDs per net wor k
number . This is a r at her l ow number , and some sit es wil l have mor e t han 254 net wor k
st at ions at t ached t o a cabl e pl ant . This means t hat mul t ipl e st at ions on t he same cabl e
pl ant may have dif f er ent net wor k addr esses. A r out er must be used t o t r ansl at e
bet ween t wo st at ions t hat ar e l ocat ed on t he same cabl e pl ant wit h dif f er ent net wor k
addr esses. This is cal l ed multinetting an int er f ace.
Assigning Mor e Than One Addr ess t o an Int er f ace

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 58
Classful IP Address Review
Let s r eview. Al l IPv4 addr esses ar e 32 bit s in l engt h and ar e t he gr ouping of 4 byt es
t hat r epr esent s bot h a net wor k number and host number . This number is usual l y
r epr esent ed in decimal . Wit h t he f ir st bit r eser ved (set t o 0xxxxxxx) in a Cl ass A
addr ess, t he net wor k number s can r ange f r om 1 t o 126. Number 127 is r eser ved as a l ocal
l oopback IP addr ess and must not be assigned t o a net wor k number and t r ansmit t ed ont o
t he net wor k. Wit h t he f ir st 2 bit s r eser ved in a Cl ass B (10xxxxxx) or 3 bit s in a Cl ass C
(110xxxxx) addr ess, t he net wor k number s f or Cl ass B r ange f r om 128.1.0.0 t o 191.255.0.0,
and f or Cl ass C t hey r ange f r om 192.1.1.0 t o 223.255.255.0.
Exampl es:
192.1.1.1 Node assigned wit h a host ID
of 1, l ocat ed on a Cl ass C
net wor k of net wor k 192.1.1.0
of 4, l ocat ed on a Cl ass C
net wor k of 200.6.5.0
of 5.6, l ocat ed on a Cl ass B
net wor k of 150.150.0.0
of 6.7.8, l ocat ed on a Cl ass A
of 0.1, l ocat ed on a Cl ass B
Not ice t hat t o r epr esent a net wor k number onl y, onl y t he net wor k number is wr it t en.
The host f iel d wil l be set t o 0. This t ype of net wor k number displ ay wil l become
appar ent when l ooking at r out ing t abl es.
Cl assf ul IP Addr ess Review
In t he f ir st f iel d:
Cl ass A has t he r ange of 1126
Cl ass B has t he r ange of 128191
Cl ass C has t he r ange of 192223
Cl ass D has t he r ange of 224239
Subnet t ing is t he abil it y t o pl ace a mask over t he host por t ion of t he addr ess
t o yiel d subnet s.
Al l ows f or anot her l evel of hier ar chy; ef f icient f or r out ing
RIP ver sion 1 has pr obl ems wit h var iabl e subnet masks.
For t hose not f amil iar wit h binar y, you need t o memor ize t he st ar t ing and st opping
point s of t he f ir st byt e of an IP addr ess:
Cl ass A 1126 in t he f ir st f iel d
Cl ass B 128191 in t he f ir st f iel d
Cl ass C 192223 in t he f ir st f iel d
Subnet t ing is t he abil it y t o move a mask over t he bit s nor mal l y associat ed wit h a host
addr ess and r ecl aim t hese bit s as a subnet number . The mask can use 22 bit s f or a Cl ass A
addr ess, 14 bit s f or a Cl ass B addr ess, and 6 bit s f or a Cl ass C addr ess.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 59
IP Address Restrictions
IP Addr ess Rest r ict ions
Addr ess cannot have t he f ir st f our bit s set t o 1.
Cl ass A addr ess of 127.x.x.x is r eser ved f or l oopback.
The host por t ion of t he addr ess cannot be set t o al l 0s or al l 1s.
Al l 0s and al l 1s ar e al l owed in t he subnet .
Any addr ess wit h al l 0s in t he net wor k por t ion of t he addr ess space is meant
t o be t his net wor k.
Ol d f or m of br oadcast ing (al l 0s in t he addr ess) is no l onger used.
IP addr esses may be conf igur ed wit hout r egist r at ion.
Addr esses cannot be out of t he 255 r ange f or each byt e.
1. Addr esses cannot have t he f ir st f our highest bit s (in t he f ir st f iel d) set t o 1111.
This is r eser ved f or Cl ass E net wor ks onl y (a r eser ved net wor k cl assif icat ion).
2. The Cl ass A addr ess of 127.x is f or a special f unct ion known as t he loopback
function. It shoul d never be visibl e on t he net wor k.
3. The bit s t hat def ine t he host por t ion of t he addr ess cannot be set t o al l 1s or
al l 0s t o indicat e an individual addr ess. These ar e r eser ved addr esses. Al l 1s
indicat e a l ocal subnet al l host s br oadcast and al l 0s indicat e a net wor k number .
4. Al l 0s and al l 1s ar e al l owed in t he subnet por t ion of an addr ess as val id
subnet addr esses. Pl acing a 0 in t he subnet is cal l ed subnet 0 (how cl ever ) and most
r out er s must be t ol d t hat subnet 0 is suppor t ed. However , you must be car ef ul
when assigning al l 1s t o t he subnet por t ion of t he addr ess. This is al l owed
(accor ding t o RFC 1812), but it can wr eak havoc on t hose net wor ks t hat use al l
subnet s br oadcast . If t he subnet por t ion of t he addr ess is set t o al l 1s, t his can be
used as a directed broadcast. Rout er s wil l f or war d t his t ype of dat agr am, if t ol d t o
do so (t hey have t o be conf igur ed).
5. Any addr ess wit h al l 0s in t he net wor k por t ion of t he addr ess is meant t o
r epr esent t his net wor k. For exampl e, 0.0.0.120 is meant as host number 120 on
t his net wor k (t he net wor k f r om which it or iginat ed).
6. Ther e is an ol d f or m of br oadcast ing known as t he all0s broadcast. This wil l
t ake t he f or m of 0.0.0.0. This f or m shoul d not be used. 0.0.0.0 is used t o indicat e a
def aul t r out er (expl ained l at er ).
7. You can assign your own IP net wor k number s if you wil l never have access t o
t he Int er net or if you pl an on using somet hing l ike a Net wor k Addr ess Tr ansl at or
(NAT, RFC 1631). RFC 1918 al l ows t hr ee IP addr esses t o be used f or pr ivat e
net wor ks.
8. Addr esses cannot be out of t he 255 (decimal ) r ange f or any of t he 4 byt es.
Ther ef or e, an addr ess of 128.6.200.655 is not a val id addr ess. Likewise, an addr ess
of 420.6.7.900 is not a val id addr ess assignment .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 60
Address Allocation (The Internet Registry)
RFC 2050 descr ibes t he r egist r y syst em f or t he dist r ibut ion of gl obal l y unique Int er net
addr ess space and r egist r y opt ions. This RFC is dif f er ent f r om most ot her s. Look in t he
upper l ef t cor ner and not ice t hat t he cat egor y is Best Cur r ent Pr act ice. It
r epr esent s an accur at e r epr esent at ion of t he cur r ent pr act ice of t he IP addr ess
r egist r ies.
The Int er net Regist r y hier ar chy was est abl ished in or der t o achieve addr ess uniqueness,
dist r ibut ion of hier ar chical dist r ibut ion of gl obal Int er net addr esses, and, most of al l ,
pr oduce a conser vat ion of IPv4 Int er net addr essees. It consist s of IANA, Regional IRs,
and Local IRs.
The IANA is t he Int er net Assigned Number s Aut hor it y, and it has over al l aut hor it y f or
t he number space used in t he Int er net . This number space incl udes por t number , addr ess,
IP ver sion number s, and many ot her signif icant number assignment s. Read RFC 1700 f or a
f ul l descr ipt ion of t he IANA.
The Regional IRs oper at e under t he aut hor it y of IANA. They oper at e in l ar ge
geogr aphical ar eas such as cont inent s. Cur r ent l y, t her e ar e t hr ee def ined: Int er NIC,
which ser ves Nor t h Amer ica; RIPE, which ser ves Eur ope; and APNIC, which ser ves t he
Asian Pacif ic r egion.
These IRs do not cover al l ar eas. It is expect ed t hat each IR cover s any ar ea not
specif ical l y specif ied, but wit hin it s immediat e ar ea. Local IRs ar e est abl ished under t he
aut hor it y of t he r egional IR and IANA. They cover nat ional dimensions.
Addr esses ar e al l ocat ed t o ISPs by r egional r egist r ies, which in t ur n assign t hem t o
t heir cust omer base. ISPs t hat exchange r out ing inf or mat ion dir ect l y wit h ot her ISPs
get t heir addr ess al l ocat ion f r om t heir geogr aphic IR. Ot her ISPs ar e r ef er r ed t o t hese
ISPs f or addr ess assignment . In ot her wor ds, if your addr ess bl ock has a r easonabl e
chance of being pr opagat ed t hr ough t he gl obal Int er net r out ing t abl es, t hen your
addr ess al l ocat ion wil l come f r om t he IR. Ot her wise, you wil l get your addr ess
assignment f r om your upst r eam ISP. Cust omer s (commer cial cor por at ions) need not
wor r y about t his. They wil l get t heir addr ess assignment s f r om t he ISP t hey sign up
wit h. This is just a basic int r oduct ion t o t he IP addr essing scheme.
Addr ess Al l ocat ion (The Int er net Regist r y)

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Part Two
The Protocol Suite of TCP/I P
Chapter 61
Address Resolution Protocol (ARP)
The Int er net , but not t he TCP/IP pr ot ocol , gr ew up wit h high-speed l ocal net wor ks
such as Et her net , Token Ring, and FDDI. Bef or e t he Int er net , t her e was t he ARPAnet
and t his t oo r an t he TCP/IP pr ot ocol . The ARPAnet st ar t ed on ser ial l ines t o
communicat e bet ween t he sit es and Et her net , or any LAN f or t hat mat t er , was not a
consider at ion. IP addr essing wor ked just f ine in t his envir onment . Rout ing was
accompl ished bet ween message pr ocessor s known as IMPs (Int er f ace Message Pr ocessor s).
The host s connect ed t o t he IMP and t he IMP connect ed t o t he phone l ines, which
int er connect ed al l ARPAnet sit es. The IP addr ess ident if ied t he host (and l at er t he
net wor k and subnet wor k). Ther e was not a need f or physical l y ident if ying a host f or
t her e was onl y one host per physical connect ion t o t he IMP. Mul t ipl e host s coul d
connect t o an IMP, but each had an IP addr ess t o which t he IMP f or war ded t he
inf or mat ion.
Et her net was commer cial l y avail abl e in 1980 and st ar t ed t o gain mor e r ecognit ion
when ver sion 2.0 was r el eased in 1982. Since mul t ipl e st at ions wer e t o connect t o a
net wor k (singl e cabl e segment ) l ike Et her net , each st at ion had t o be physical l y
ident if ied on t he Et her net . The designer s of Local Ar ea Net wor ks (LANs) al l ot t ed 48
bit s t o ident if y a net wor k at t achment . This is known as a physical address or MAC address.
Physical addr esses ident if y st at ions at t heir dat al ink l evel . IP is an addr essing scheme
used at t he net wor k l evel . On a LAN (Et her net , Token Ring, et c.), t wo communicat ing
st at ions can set up a session
Addr ess Resol ut ion Pr ot ocol (ARP)
RFC 826.
TCP/IP addr esses ar e 32 bit s and r epr esent a net wor k, subnet , and host ID.
Addr esses on LANs ar e r epr esent ed by physical (MAC) l ayer addr esses and
t hey ar e 48 bit s in l engt h.
ARP pr ovides t he mapping bet ween a host s 32-bit IP addr ess and it s 48-bit MAC
addr ess.
ARP wor ks onl y on t he l ocal subnet (it cannot t r aver se r out er s).
ARP buil ds a t abl e of IP/MAC addr esses t o pr oper l y f or mat a sour ce and
dest inat ion addr ess f iel d in a packet .
onl y if t hey know each ot her s physical addr ess. Think of a MAC addr ess as t he number
on your house. Lot s of houses on your st r eet and each uniquel y ident if ied by t he
number . This is a MAC addr ess.
Since t he MAC addr ess is 48 bit s and IP is 32 bit s, a pr obl em exist ed and an RFC r esol ved
t his pr obl em. The r esol ut ion was simpl e and it did not af f ect t he al r eady est abl ished IP
addr essing scheme. It is known as Address Resolution Protocol, or ARP. This is an IP-addr ess-
t o-physical -st at ion-addr ess r esol ut ion (act ual name is binding).
If you ar e t r ying t o communicat e t o a host on t he same net wor k number as t he one on
which you ar e cur r ent l y r esiding, t he TCP/IP pr ot ocol wil l use ARP t o f ind t he physical
addr ess of t he dest inat ion st at ion. If t he net wor k number of t he dest inat ion st at ion is
r emot e, a r out er must be used t o f or war d t he dat agr am t o t he dest inat ion. The ARP
pr ocess is used her e as wel l , but onl y t o f ind t he physical addr ess of t he r out er .
Ther e have been enhancement s t o t his pr ot ocol al t hough not t hr ough an RFC. Some
st at ions l ist en t o al l ARP packet s since t he or iginat or sends t hem in br oadcast mode.
Al l st at ions r eceive t hese packet s and wil l gl ean t he inf or mat ion t hat t hey need. The
inf or mat ion in t he packet s incl udes t he sender s har dwar e and IP addr ess mapping. In
some inst ances, t his inf or mat ion is used by ot her st at ions t o buil d t heir ARP cache.
Many ARP t abl es (cache) empt y t heir t abl es per iodical l y t o r educe t he cycl es needed t o
r ef r esh t he cache, t o conser ve memor y, and t o keep t he t abl e up t o dat e. If a st at ion
moves f r om one subnet t o anot her and st at ions on t he subnet do not empt y t heir t abl es,
t hey wil l cont inue t o have an ent r y f or t hat har dwar e addr ess. ARP is def ined in RFC
826.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 62
ARP Packet Format
The ARP packet f or mat is shown. It cont ains just a f ew f iel ds, but not ice one t hing: It
does not r eside on t op of IP. It has it s own Et her net Type f iel d (0806), which ident if ies
t he pr ot ocol owner ship of t he packet and al l ows it t o uniquel y ident if y it sel f . It never
l eaves it s l ocal segment , so why use IP?
Ther e ar e f ive main f iel ds: t he oper at ion (ARP r equest or ARP r epl y), t he sour ce and
dest inat ion IP addr esses, and t he sour ce and dest inat ion har dwar e addr esses (mor e
commonl y known as MAC addr esses).
The t ype of har dwar e ident if ies t he LAN (10-Mbps Et her net , f or exampl e), t he t ype of
pr ot ocol ident if ies t he pr ot ocol being used. This makes ARP ver sat il e. It can be used
wit h ot her t ypes of pr ot ocol s as wel l . The most f amous one is Appl eTal k t hr ough t he
Appl eTal k ARP pr ot ocol .
The ARP pr ocess is shown next .
ARP Packet For mat

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 63
ARP Operation
As shown in t he sl ide, in or der t o at t ach t o anot her st at ion on a TCP/IP net wor k, t he
sour ce st at ion must know t he designat ion st at ions IP addr ess. This can be accompl ished
in many ways; f or exampl e, t yping t he addr ess in dir ect l y using a TCP/IP based pr ogr am,
or using a name ser ver . In t his exampl e, St at ion 129.1.1.1 want s a connect ion wit h
129.1.1.4 (no subnet addr essing is used her e). Ther ef or e, t he net wor k addr ess of t his
Cl ass B addr ess is 129.1.0.0 and t he per sonal comput er s host addr ess is 1.1; hence, t he
addr ess is 129.1.1.1.
Wit h ARP, it is assumed t hat t he IP addr ess of t he dest inat ion st at ion is al r eady known
eit her t hr ough a name ser vice (a cent r al ser vice or f il e on a net wor k st at ion t hat maps
IP addr esses t o host names, expl ained in mor e det ail l at er ), or by using t he IP addr ess
it sel f . To r educe over head on t he net wor k, most TCP net wor k st at ions wil l maint ain a
LAN physical -addr ess-t o-IP-addr ess t abl e on t heir host machines. The ARP t abl e is
not hing mor e t han a sect ion of RAM memor y t hat wil l cont ain dat al ink physical (or
MAC addr esses) t o IP addr ess mappings t hat it has l ear ned f r om t he net wor k.
ARP Oper at ion
Once t he IP addr ess is known f or t he dest inat ion st at ion, IP on t he sour ce st at ion wil l
f ir st l ook int o it s ARP t abl e t o f ind t he physical addr ess f or t hat dest inat ion IP addr ess.
If a mapping is f ound, no ARP r equest packet wil l be t r ansmit t ed ont o t he net wor k. IP
can bind (pl ace t he physical addr esses on t he dat al ink header s of t he packet ) t he IP
addr ess wit h t he physical addr ess and send t he IP dat agr am t o t he dat al ink f or
t r ansmission t o t he net wor k.
If t he addr ess is not in t he ARP t abl e, t he ARP pr ot ocol wil l buil d an ARP r equest
packet and send it physical l y addr essed in br oadcast mode (dest inat ion addr ess FF-FF-FF-
FF-FF-FF). Al l st at ions on t he physical net wor k wil l r eceive t he packet , but onl y t he
host wit h t hat IP addr ess wil l r epl y. Host 129.1.1.4 wil l r epl y t o t he r equest packet
wit h an ARP r esponse packet physical l y addr essed t o st at ion 129.1.1.1.
When t he host whose IP addr ess is in t he r equest packet r esponds, it wil l r espond wit h
an ARP r epl y packet wit h t he sour ce addr ess set t o it s addr ess (physical l y and inside t he
ARP r epl y packet ), and t he dest inat ion addr ess as t he or iginat or . Once t he or iginat or of
t he r equest r eceives t he r esponse, it wil l ext r act t he physical addr ess f r om t he sour ce
addr ess in t he packet and updat e it s ARP t abl e. Now t hat it has t he mapping, it wil l t r y
t o submit it s IP dat agr am t o t he dest inat ion st at ion using t he pr oper addr esses (IP and
physical addr ess).
This pr ocess is aut omat ic. The user wil l t ypical l y be using one of TCPs appl icat ions
(TELNET f or t er minal ser vice, SMTP f or mail ser vice, or FTP f or f il e t r ansf er ser vice)
when at t empt ing a connect ion. Most TCP vendor s suppl y a ut il it y pr ogr am t hat al l ows
a user t o see t he ent r ies in t he ARP t abl e.
To impr ove t he ef f iciency of t he pr ot ocol , any st at ion on t he physical net wor k t hat
r eceives t he ARP packet (r equest packet ) can updat e t he ARP cache. The sender s
physical and IP addr esses wil l be in t he packet and, t her ef or e, al l st at ions can updat e
t heir ARP t abl es at t he same t ime.
The sl ide shows t he ARP packet f or mat . It is encapsul at ed in an Et her net packet as
shown. This ARP pr ocess wor ks f or st at ions communicat ing wit h each ot her on t he same
LAN (t he same net wor k number ). If t hey ar e not on t he same LAN, t he ARP pr ocess st il l
wor ks, but an addr ess of a r out er wil l be f ound. This is f ul l y expl ained l at er .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 64
Rules for ARP
1. ARP is not a par t of t he IP pr ot ocol and t her ef or e does not cont ain IP header s.
ARP wor ks dir ect l y on t op of t he dat al ink l ayer .
2. ARP r equest s and r esponses ar e t r ansmit t ed wit h a dest inat ion physical
br oadcast addr ess (al l Fs) and t her ef or e never l eave t heir l ogical subnet . Pl us,
wit h Rul e 1, t hese packet s cannot be r out ed
3. Since ARP is not par t of t he IP pr ot ocol , a new Et her Type (t he f iel d in t he
Et her net packet t hat ident if ies t he pr ot ocol used by t he packet ) is assigned t o
ident if y t his t ype of packet . 0806 is an ARP r equest and 0806 is an ARP r epl y. Some
ARP impl ement at ions can be assigned t he 0800 Et her Type, f or IP wil l be abl e
ident if y t he packet as an ARP r equest or ARP r epl y packet . Not al l impl ement er s
of IP use t hese t ypes. Some st il l use t he Et her Types of 0800 f or ARP.
Rul es f or ARP
ARP does not r un on t op of IP and t her ef or e has no IP header s.
ARP r equest s ar e t r ansmit t ed in br oadcast so t hat al l st at ions r eceive t he
packet .
New Et her Type def ined 0x0806 f or bot h t he ARP r equest and r epl y.
ARP r epl ies ar e sent dir ect l y t o t he r equest ing st at ion (unicast , not
br oadcast ).
ARP t abl es shoul d age out t heir ent r ies.
An at t achment shoul d answer an ARP sent t o it sel f .
4. Some impl ement at ions have an ARP aging capabil it y. This al l ows ARP t o del et e
ent r ies t hat have not been used f or a per iod of t ime, r educing t he ARP l ookup t ime
and saving memor y.
5. If a machine submit s an ARP r equest f or it sel f , it must r epl y t o t he r equest .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 65
Reverse Address Resolution Protocol (RARP)
This pr ot ocol is used when a net wor k st at ion knows it s MAC addr ess but does not know
it s IP addr ess. When woul d t his happen? Diskl ess wor kst at ions ar e a good exampl e.
Not ice t hat RARP uses t he ARP packet f or mat and does not invol ve IP; t her ef or e, t his
packet cannot be r out ed. This pr ot ocol has been in use f or some t ime, but t her e ar e
ot her pr ot ocol s t hat do a bet t er job. This is one of t he r easons t hat we use BOOTP and
DHCP f or addr ess assignment because t hey can be f or war ded over a r out er (wit h a
l it t l e assist ance f r om t he r out er ). One pr obl em wit h RARP is t hat l ike it s cousin ARP, it
does not use IP. Ther ef or e, RARP is gener al l y used onl y on a LAN.
The r equest ing cl ient machine wil l send out a RARP r equest t o a ser ver l ocat ed on t he
l ocal segment t hat has t he RARP ser ver ser vice r unning on it . This RARP ser ver wil l
r espond t o t he r equest wit h t hat par t icul ar st at ions IP addr ess. Al t hough t he RARP
ser ver does not need t o be l ocat ed on t he same cabl e segment or ext ended LAN, it is
pr ef er r ed. Some r out er vendor s have enabl ed t heir r out er s t o f or war d t hese r equest s
and r esponses t o ot her net wor ks.
Rever se Addr ess Resol ut ion Pr ot ocol (RARP)
The packet f or mat f or a RARP packet is t he same as f or ARP. The onl y dif f er ence is t hat
t he f iel d t hat wil l be f il l ed in wil l be t he sender s physical addr ess. The IP addr ess
f iel ds wil l be empt y. A RARP ser ver wil l r eceive t his packet , f il l in t he IP addr ess f iel ds,
and r epl y t o t he sender t he opposit e of t he ARP pr ocess.
Ot her pr ot ocol simil ar t o t his ar e BOOTP and Dynamic Host Conf igur at ion Pr ot ocol
(DHCP). DHCP is mor e power f ul t han RARP, but it does suppl y one of t he same f unct ions
as RARP: r esol ving an IP addr ess. Besides being l ess f unct ional t han DHCP, RARP onl y
wor ks on singl e subnet s. RARP wor ks at t he dat al ink l ayer and t her ef or e cannot span
subnet s gr acef ul l y. DHCP can span subnet s.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 66
Proxy ARP
Pr oxy ARP pr ot ocol is not used much anymor e, but it is st il l wor t h ment ioning. IP was
pr et t y wel l est abl ished when ARP came al ong, and some TCP/IP impl ement at ions did not
suppor t ARP. However , TCP/IP over LANs wit h subnet s was being impl ement ed and an
int er im sol ut ion was needed. This was t he pur pose of Pr oxy ARP (al so known as ARP
Hack). Pr oxy ARP is t he abil it y of a r out er t o be abl e t o r espond t o an endst at ion (host )
ARP r equest f or a host t hat t hinks t he dest inat ion IP addr ess is on t he l ocal LAN.
Ther ef or e, if a host does not suppor t subnet addr essing, it coul d incor r ect l y mist ake an
IP subnet number f or a host number . The r out er t r icks t he t r ansmit t ing st at ion int o
bel ieving t hat t he sour ce st at ion is on t he l ocal LAN.
Endst at ion A t hinks host B is on t he l ocal LAN. Host B suppor t s subnet addr essing and
endst at ion A does not . Decipher ing t he IP addr ess, t he f ir st t wo f iel ds (cont aining t he
net wor k ID) ar e t he same. Ther ef or e, endst at ion A wil l send out a l ocal ARP r equest
packet when it shoul d be submit t ing t he packet t o t he r out er so t hat it can del iver t he
packet t o t he endst at ion. If t he r out er has pr oxy ARP enabl ed, t he r out er wil l answer
f or host B. The r out er , which suppor t s subnet t ing, wil l l ook up t he ARP r equest and
t hen not ice t hat t he subnet wor k addr ess is in it s r out ing t abl e. The r out er r esponds f or
endst at ion B. Endst at ion A wil l r eceive t his r esponse and t hink it is f r om host Bt her e
is not hing in t he physical addr ess of a packet t o indicat e wher e it came f r om. The host
wil l t hen submit al l packet s t o t he r out er and t he r out er wil l del iver t hem t o
endst at ion A. This communicat ion wil l cont inue unt il one end t er minat es t he session.
Pr oxy ARP
Pr oxy ARP is a ver y usef ul pr ot ocol f or t hose net wor ks t hat have been using br idges t o
impl ement t heir IP net wor k and ar e moving t o a r out er envir onment . Ther e ar e ot her
sit uat ion f or which pr oxy ARP is appr opr iat e, but it s use is waning. Today, most host s on
a TCP/IP int er net suppor t subnet masking and most IP net wor ks ar e using r out er s.
A pot ent ial pr obl em in using pr oxy ARP is f or t hose net wor ks t hat impl ement t he
mechanism t o ensur e singl e IP addr esses ar e on each net wor k. Most TCP/IP
impl ement at ions al l ow user s easy access t o t heir net wor k number (t hat is, t hey can
change it wit h a t ext edit or ). This al l ows any hacker t o change his or her number t o
anot her in or der t o r eceive dat agr ams dest ined f or anot her host . Some impl ement at ions
of TCP/IP wil l det ect f or t his. Rout er s t hat impl ement pr oxy ARP wil l get caught , f or
t hey wil l answer f or any st at ion on a dif f er ent net wor k, t her eby giving t he impr ession
t hat t her e is one physical addr ess t o mul t ipl e IP addr esses. Ther e is a t r ust on any IP
net wor k t hat IP addr esses wil l not be ar bit r ar il y assigned. Ther e shoul d be one IP
addr ess f or each physical addr ess on an int er net .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 67
Whats Wrong with the Address?
Wit h t he vast expl osion of connect ivit y t o t he Int er net st ar t ing in 1994, t he Int er net
was soon r unning out of IPv4 addr esses. Cl ass As in t he r ange of 64126 wer e not
assigned; Cl ass Bs wer e at t he point of exhaust ion; and Cl ass Cs, al t hough pl ent if ul ,
onl y al l owed f or 254 host addr esses per net wor k number assignment . Cl ass C subnet t ing
is not exact l y painl ess. Most sit es wer e given mul t ipl e Cl ass C addr esses and t his was
quickl y f il l ing up t he Int er net r out ing t abl es, Some est imat es wer e as high as 85,000
r out es on t he gl obal r out ing t abl es (t hose t abl es hel d by nat ional Int er net Ser vice
Pr ovider s such as Spr int and MCI). Yet , t he comput ing power of t he r out er and
avail abil it y of RAM t o hol d t hose t abl es in t he r out er wer e not r eady yet . The size of
t he Int er net was doubl ing ever y 9 mont hs, yet t he comput ing power of t he r out er s was
doubl ing ever y 18 mont hs. Inst ead of pr oducing f ast er and mor e power f ul r out er s (l ike
we did wit h mainf r ames in t he 1970s and 1980s), we became smar t and invent ed a
hol dover sol ut ion using t he exist ing equipment and cur r ent IPv4 addr essing scheme.
What s Wr ong wit h t he Addr ess?
IP addr ess is 32 bit s in l engt h.
Al l ows f or 4,294,967,296 unique addr esses
A pr obl em occur s because t he addr esses ar e gr ouped in a cl ass addr ess.
A r ange of bit s is appl ied t o an addr ess, most of which ar e wast ed
Addr esses wer e ar bit r ar il y handed out wit hout r egar d t o geogr aphic
l ocat ion.
Cl ass C addr esses wer e over t axing t he Int er net r out ing t abl es.
Cl ass A st opped being handed out and Cl ass B was exhaust ed.
RFC 1338 int r oduced super net t ing as a t hr ee-year f ix.
It t ur ned int o Cl assl ess Int er -Domain Rout ing (CIDR).
Now we hear about t he exhaust ion of IP addr ess space. Can t his be t r ue, wit h over 4
bil l ion addr esses? But wait . We have 32 bit s of addr ess space. Ignor ing t he r ul es of cl ass
addr essing t his, 2
n
32 al l ows f or 4,294,967,296 unicast addr esses t o be assigned (in some
f or mat ion of net wor ks and host s). Seems l ike a l ot of addr esses, but r emember , IP l ived in
a cl ass envir onment , wast ing much of t he avail abl e addr ess space. Subnet t ing al ong
wit h pr ot ocol s such as RIPv2 and OSPF al l owed f or var iabl e-l engt h subnet masks which
al l owed f or mor e ef f iciency of t he addr ess bit s, but t her e is st il l a shor t age of
IPaddr esses.
The or iginal pr obl ems wer e t hr ee t ypes of cl assf ul addr esses and addr ess al l ocat ion
wit hout a pl an. It used t o be t hat anyone who want ed an addr ess was given one
ar bit r ar il y, and addr esses wer e al l ocat ed wit hout knowl edge of t heir l ocat ion or
f ul l y under st anding t heir net wor k r equir ement s l eading t o t he pr oper assignment of
an addr ess. In 1992, a st udy was per f or med and t he concl usion was t hat not onl y was
t he addr ess space near depl et ion (Cl asses A and B), assigning t he r emaining 2 mil l ion
Cl ass C addr esses woul d cause t he Int er net s r out er ar r ay t o mel t down. The Int er net
backbone r out er s wer e al r eady congest ed and sl ow wit h t he cur r ent r out ing t abl es of
l ess t han 30,000 r out es.
Some or ganizat ions and net wor k pr ovider s had mul t ipl e cont iguous net wor ks assigned.
Yet , as we l ear ned in t he pr evious sect ion on addr essing, each addr ess is a net wor k and
hol ds one r ecor d sl ot in t he r out ing dat abase. The idea of super net t ing was int r oduced
in RFC 1338 as a means of summar izing mul t ipl e net wor k number s (one ent r y det ail s
mul t ipl e net wor k IDs), f ur t her r educing t he number of r out es r epor t ed. This was a 1992
RFC int ended as a t hr ee-year f ix, which mat ur ed int o CIDR.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 68
Extending the Life of the IPv4 Address Space
The f ol l owing was t aken f r om RFC 760:
Addresses are fixed length of four octets (32 bits). An address begins with a one-octet
network number, followed by a three-octet local address. This three-octet field is called
the rest field.
Taken f r om RFC 791, page 6:
Addresses are fixed length of four octets (32 bits). An address begins with a network
number, followed by a local address (called the rest field). There are three formats or
classes of internet addresses: In Class A, the high-order bit is 0, the next 7 bits are the
network, and the last 24 bits are the local address; in Class B, the high-order 2 bits are
10, the next 14 bits are the network, and the last 16 bits are the local address; In Class
C, the high-order 3 bits are 110, the next 21 bits are the network, and the last 8 bits
are the local address.
RFC 950 int r oduced us t o subnet t ing:
While this view has proved simple and powerful (two-level model, assigning a network
number per network), a number of organizations have found it inadequate, and have
added a third level to the interpretation of Internet addresses. In this view, a given
Internet network is divided into a collection of subnets.
RFCs 15171520 int r oduced us t o Cl assl ess Int er -Domain Rout ing (CIDR):
It has become clear that the first two of these problems (routing information overload
and Class B exhaustion) are likely to become critical in the near term. Classless Inter-
Domain Routing (CIDR) attempts to deal with these problems by defining a mechanism
with which to slow the growth of routing tables and reduce the need to allocate new IP
network numbers.
Ext ending t he Lif e of t he IPv4 Addr ess Space
Or iginal RFC f or IP was RFC 760.
No concept of cl asses; addr ess was 8-bit net wor k ID
RFC 791 int r oduced a segment at ion of t he addr ess int o Cl asses.
RFC 950 int r oduced subnet t ing.
Al l owed f or ef f iciency t o exist wit h Cl ass addr esses
RFCs 15171520 int r oduced CIDR.
Used on t he Int er net r out ing t abl es
This sect ion deal s pr imar il y wit h t he IPv4 addr ess ext ensions. Incl uded in t his ar e
subnet t ing (an IP addr ess r eview, var iabl e-l engt h subnet masks, r out e aggr egat ion, and
CIDR). IPv6 shoul d be incl uded in t his as wel l wit h t he 128-bit addr ess. However , t his
discussion is hel d of f unt il af t er t he IPv4 discussion. The CIDR discussion f ul l y r eveal s
t he addr ess pr obl em and what was done about it .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 69
IP Address Assignment (The Old Method)
IP Addr ess Assignment (The Ol d Met hod)
Thr ee met hods of assigning addr esses in t he ol d days:
Acquir e a dist inct net wor k number f or each cabl e segment separ at ed by
a r out er
Use a singl e net wor k number f or t he ent ir e oper at ion, but assign host
number in coor dinat ion wit h t heir communicat ion r equir ement s
Use a singl e net wor k number and par t it ion t he host addr ess space by
assigning subnet number t o t he LANs (expl icit subnet s)
Or iginal l y, using RFC 791 wit hout subnet t ing, an or ganizat ion wit h a compl ex (mor e
t han one) net wor k t opol ogy had t hr ee choices f or assigning Int er net addr esses:
1. Acquir e a dist inct Int er net net wor k number f or each cabl e; subnet s ar e not
used at al l .
2. Use a singl e net wor k number f or t he ent ir e or ganizat ion, but assign host
number s in coor dinat ion wit h t heir communicat ion r equir ement s (f l at net wor ks
segment ed using br idges).
3. Use a singl e net wor k number and par t it ion t he host addr ess space by assigning
subnet number s t o t he LANs (expl icit subnet s). Cr eat e your own but dont
adver t ise t hem t o t he ARPAnet . This is t he most popul ar met hod.
Empl oying t he f ir st choice caused r out ing t abl es t o gr ow. RFC 950 al l owed f or subnet
addr essing t o t ake pl ace wit hin an aut onomous syst em, which al l owed f or a sit e t o
cont inue t o subnet it s AS, but t he subnet s wer e never pr opagat ed t o t he Int er net
r out ing t abl es. Subnet t ing and VLSM (var iabl e-l engt h subnet masks, expl ained l at er )
al l owed f or t he gl obal r out ing t abl es t o st op gr owing exponent ial l y and al l owed sit es
t o cont r ol t heir own net wor ks as wel l . However , net wor k number s wer e pl ent if ul and
subnet s sl owed t he expansion of t he Int er net r out ing t abl es. This was bef or e t he
commer cial izat ion of t he Int er net in 1994.
The adver se ef f ect s of br idges in compl ex net wor ks ar e wel l known. Since t he br idge
r evol ut ion, r out er s have become t he mainst ay of t he cor por at e backbone. This wor ked
wel l f or shar ed envir onment s, but t echnol ogy was changing: Net wor k at t achment s
wer e becoming f ast er and mor e power f ul . The br idging r evol ut ion came back as swit ches
in t hat each deskt op coul d now have it s own 10-Mbps pipe. The swit ches buil d a smal l
f l at net wor k and shoul d be used t o f r ont end r out er s, t hus al l owing f or
microsegmenting but not microsubnetting.
Subnet t ing one net wor k number caused t he Int er net r out ing t abl es t o sl ow t heir
gr owt h. This wor ked wel l wit h Cl ass B addr esses. Cl ass C net wor ks f or ced t he Int er net
r out ing t abl es t o gr ow, and Cl ass A addr esses wer e not handed out . Al so, since mor e
t han 50 per cent of t he businesses wer e smal l - and medium-sized businesses. Cl ass C
addr esses wer e needed. Again, we wer e in a pr edicament . We needed a sol ut ion.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 70
IP Addressing (The Old Method)
IP Addr essing (The Ol d Met hod)

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 71
Address Terms and Definitions
Ther e ar e f our t er ms used in t his sect ion:
Var iabl e Lengt h Subnet Masks (VLSM). The abil it y t o pl ace a var iabl e-l engt h subnet
mask on a singl e IP net wor k addr ess. Ref er t o RFC 1817. VLSMs ar e expl ained in det ail in
t he OSPF sect ion.
Super net t ing. A mask t hat is shor t er t han t he IP net wor k addr ess nat ur al mask.
Cl assl ess Int er -Domain Rout ing (CIDR). An adver t isement mechanism t hat al l ows f or
adver t ising r out es wit hout r egar d t o cl ass assignment . The r out e coul d be ident if ied by
a super net or by an ext ended subnet mask.
Addr ess aggr egat ion. The abil it y t o summar ize cont iguous bl ocks of IP addr esses as
one adver t isement .
The abil it y t o manipul at e IP addr esses is af f ect ed not onl y on cust omer sit es but wit hin
t he gl obal Int er net as wel l . Cl ass-or ient ed IP addr esses ar e st il l used in t he cust omer
envir onment , wher eas Cl assl ess IP addr essing is used in t he Int er net it sel f . Cust omer s
ar e f r ee t o use whichever mechanism ef f icient l y uses t he addr ess t hat is assigned t o
t hem. No l onger ar e t hey r est r ict ed t o use onl y one subnet mask f or t heir assigned
net wor k number . OSPF and RIP2 gave us mor e f l exibil it y when using t he subnet mask.
These r out ing updat e pr ot ocol s dist r ibut e t he subnet mask f or each ent r y in it s t abl e.
The al l owed us gr eat f l exibil it y in mask assignment and al l owed f or mor e ef f iciency of
t he net wor k addr ess. For a singl e net wor k ID, we coul d move t he mask ar ound t o
var ious masks f or t he singl e net wor k ID. A sit e coul d make ver y ef f icient use of it s
assigned net wor k ID using VLSM. We coul d move t he mask down t o 255.255.255.252 f or
ser ial l ines al l owing 2 bit s f or t he host , and t hen move t he mask ar ound again f or a
var ious number of host s. OSPF al so al l owed f or summar ies in t he r out ing updat es, which
al l owed r out er s t o send out one net wor k number wit h a mask as an updat e indicat ing
al l bit s in t he mask handl ed by t hat r out er . This is ver y ef f icient .
Addr ess Ter ms and Def init ions
Var ibl e Lengt h Subnet Masks (VLSM)The abil it y t o pl ace a var iabl e-l engt h
subnet mask on a singl e IP net wor k number .
Super net t ingThe abil it y t o appl y a mask t o an IP addr ess t hat is shor t er
t han it s nat ur al mask.
Cl assl ess Int er -Domain Rout ing (CIDR)An adver t isement mechanism t hat
al l ows f or adver t ising r out es wit hout r egar d t o Cl ass assignment . The r out e
coul d be ident if ied by a super net or by an ext ended subnet mask.
Addr ess aggr egat ionThe abil it y t o summar ize cont iguous bl ocks of IP
addr esses as one adver t isement .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 72
Making the Address Efficient
Making t he Addr ess Ef f icient
Al l met hods pr ovide f or ext ending t he l if e of IPv4.
CIDR is ver y simil ar t o VLSM.
Addr esses al l ocat ed in bl ocks.
Exampl e: 205.24.0.0/16 means t hat t he addr ess r ange of 205.24.0.0
t hr ough 205.24.255.0 (256 Cl ass Cs) is assigned t o one ISP or consumer , et c.
Bl ock assignment al l ows f or one r out e t o be pl aced in t he Int er net r out ing
t abl es.
It al l ows t he ISP t o br eak up t he addr esses and ef f icient l y hand t hem out t o
it s cust omer s.
Consumer s must det ail t heir addr essing r equir ement s t o t he ISP.
Addr ess assignment s ar e st il l conser vat ive.
The r apid expansion f or connect ivit y and t he expl oding cor por at e inf r ast r uct ur e
init ial l y caused pr obl ems on t he Int er net . IP addr esses wer e assigned sequent ial l y t o
r equest ing or ganizat ions wit hout r egar d t o t he r equest er s l ocat ion or met hod of
Int er net connect ion. What t his means is t hat a r equest ing company simpl y cal l ed in f or
an IP addr ess assignment and was assigned an IP addr ess f r om a l ist of sequent ial l y
l ist ed number s. For exampl e, a company in Cal if or nia coul d be assigned 150.1.0.0 and a
company in Vir ginia woul d be assigned 151.1.0.0 and maybe 40 Cl ass C addr esses. Then a
company in Texas coul d appl y f or 160.1.0.0 and 50 Cl ass C addr esses. They coul d t hen
sign up f or any ISP t hey desir ed wit h t heir newl y assigned IP addr esses. Ver y inef f icient ,
but at t he t ime, who knew? The r out ing syst em f il l ed up wit h smal l er IP addr esses
acr oss mul t ipl e, l ong hops of r out er s, inst ead of l ar ge cont iguous addr esses.
Super net t ing, CIDR, and addr ess aggr egat ion pr ovided addr ess f l exibil it y and ef f iciency
t o t he ISP and t he Int er net . CIDR is ver y simil ar t o VLSM. Today, bl ocks of addr esses (as
indicat ed t owar d t he end of t his sect ion) ar e handed out t o Int er net Ser vice Pr ovider s
(ISPs) in bl ocks (or a r ange) t hr ough t he Int er net Regist r y (RFC 2050 f ul l y expl ains
t his). For exampl e, an ISP may be assigned t he addr ess bl ock of 205.24.0.0/16, which
al l ows t he ISP t o hand out addr esses in t he r ange of 205.24.0.0 t hr ough 205.24.255.255.
In t his way, t he gl obal r out ing t abl es onl y know t hat addr esses 205.24.0.0 t hr ough
205.24.255.255 go in one dir ect ion t o an ISP. Al l of t hese addr esses ar e summar ized int o
one r out ing t abl e ent r y, which, using t he ol d met hod, woul d have been 255 ent r ies. The
ent r y in t he gl obal r out ing t abl es woul d have been 205.24.0.0/16 inst ead of l ist ing al l
255 addr essest he gl obal r out ing t abl es do not car e about t he individual net wor k
assignment s.
The ISP subdivides t his bl ock t o hand out individual addr esses t o it s cust omer s as
Cl assf ul addr esses, but how an ISP cut s up t he addr esses and assigns t hese bl ocks is
af f ect ed using t he pr ot ocol s pr eviousl y ment ioned. One whol e bl ock woul d not be
assigned t o one company, but mul t ipl e companies.
A company r equir ing Int er net connect ion cal l s it s ISP, det ail ing it s t opol ogy and
r equest ing addr ess space. The ISP (knowing it has t o assign net wor k number s spar ingl y)
wil l t hen assign t he cor r ect number and net wor k r ange t o it s downst r eam cust omer s.
The r ange is t hen ent er ed int o t he ISPs r out ing t abl e, per haps as one addr ess even
t hough mul t ipl e Cl asses wer e given t o t he cust omer .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 73
Masks and Prefixes
Pr ef ix r out ing has been ar ound a l ong t ime. In f act , it is def ined in RFC 1338. Pr ef ix
r out ing is t he met hod used on t he backbone of t he Int er net an IP addr ess is l ooked at
simpl y as a 32-bit number and a pr ef ix. The pr ef ix is a mask t hat sl ides over t he IP addr ess
t o det er mine it s net wor k number . A r out ing ent r y in t he Int er net r out ing t abl e may
simpl y be 150.0.0.0/8 and a next hop addr ess t o t he next in-l ine r out er t o t hat
dest inat ion. The r out er does not car e about anyt hing el se in t he addr ess except t hat
al l 150.x.x.x net wor ks ar e in t he indicat ed dir ect ion.
Masks and Pr ef ixes
The addr esses 210.10.40.0/24 and 210.10.40.0/255.255.255.0 mean t he exact same
t hing.
IP Net wor k
Addr ess Pr ef ix Subnet Mask
128.1.0.0 /16 255.255.0.0
190.1.8.0 /21 255.255.248.0
207.16.16.128 /25 255.255.255.128
A subnet mask and a pr ef ix can be int er mixed. In f act , on Cisco r out er s, you wil l see t he
/pr ef ix commonl y used t hr oughout t heir conf igur at ion int er f ace.
Thr oughout t his t ext , I wil l use bot h t he decimal subnet mask and t he pr ef ix; a mask
and a pr ef ix ar e essent ial l y t he same t hing. For exampl e, a subnet of 255.255.255.0 and a
pr ef ix of /24 ar e t he same. To il l ust r at e, you coul d see an addr ess wr it t en as 150.1.0.0/24,
which means addr ess 150.1.0.0 subnet 255.255.0.0.
Let s l ook at a f ew subnet exampl es, st ar t ing wit h addr ess assignment at a company sit e.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 74
Another Try
A cust omer has t he base net wor k addr ess of 150.1.0.0 wit h a subnet mask of 255.255.0.0,
or /16 pr ef ix.
This t ime we ar e not int er est ed in a r equir ement of subnet s. Al l we know is t hat we
must be abl e t o have 100 host s on each subnet . Each subnet wil l not have t hat many,
but t he l ar gest one wil l , and wit hout mul t inet t ing, we must use a mask smal l enough
t o accommodat e t hat number . In or der t o suppor t 100 host s, 7 bit s ar e needed, which
al l ows f or 126 addr esses (2
n
7 2). This wil l al l ow f or f ut ur e gr owt h. The next -l owest
mask yiel ds 62 addr esses (2
n
6 2), so we must al l ow f or 7 bit s. Al ways assign a mask t hat
al l ows f or f ut ur e gr owt h.
Next we must det er mine t he subnet mask f or t he net wor k number . Since we wil l be
r eser ving 7 bit s f or host assignment , t his wil l l eave 25 bit s l ef t f or t he net wor k mask
(32 bit s 7 bit s = 25 bit s). This gives a subnet mask of 255.255.255.128, or /25 pr ef ix. The
nat ur al mask f or Cl ass B is 255.255.0.0. This mask is 255.255.255.128, which al l ows f or 9
bit s t o be assigned t o t he subnet mask, t her eby al l owing f or 512 subnet s t o be def ined.
The subnet number s r ange f r om 0 t o 521. This gives t he r ange of subnet s of 150.1.0.0
(pr oviding f or t he zer o subnet ) t hr ough 150.1.255.128 (using al l 9 bit s incl uding t he al l -
1s subnet ).
Now t hat we have separ at ed t he subnet s f r om t he host s, we shoul d l ist t hem:
Subnet s Host Range
150.1.0.0 t hr ough 150.1.255.128
1 t hr ough 125 (2
n
7 2)
150.1.1.0 (x host r eser ved bit s) Host 1 (x = net wor k/subnet r eser ved bit s)
10010110 . 00000001 . 00000001 . 0xxxxxxx xxxxxxxx.xxxxxxxx.xxxxxxxx.x0000001
150.1.1.0 Host 127
10010110 . 00000001 . 00000001 . 0xxxxxxx xxxxxxxx.xxxxxxxx.xxxxxxxx.x1111111
Anot her Tr y
Let s f ir st r eview br eaking a net wor k number down wit h a subnet
r equir ement :
Requir ement : A sit e has been assigned t he net wor k number 150.1.0.0. It r equir es
100 host s per subnet . Fut ur e gr owt h indicat es 120 host s per subnet . It
wasdet er mined t hat expansion was mor e l ikel y in t he case of r emot e sit es t han
host s.
St ep 1: Det er mine t he bit s r equir ed t o suppor t at l east 100 host s and f ut ur e
expansion t o 120 host s per subnet .
7 bit s ar e r equir ed f or 100126 host s.
St ar t f r om t he r ight and move l ef t .
St ep 2: Det er mine how subnet s ar e def ined by 9 bit s.
9 bit s suppor t 512 subnet s.
St ar t f r om t he l ef t and move r ight .
St ep 3: Det er mine t he mask.
150.1.0.0/25, or 255.255.255.128

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 75
Variable-Length Subnet Masks
We know about t he r est r ict ion of RIPv1. RIPv2 and OSPF do not have t his r est r ict ion
and can mor e ef f icient l y use t he addr ess. The pr eceding exampl es show how t o spl it up a
net wor k f or subnet s assuming one mask per net wor k ID (discussed ext ensivel y pr eviousl y
in t he book). A concept known as Var iabl e-Lengt h Subnet Mask (VLSM, det ail ed under
t he RIP and OSPF sect ions of t his book), al l ows us t o assign var iabl e masks per net wor k
ID. We can move t he mask ar ound t he singl e net wor k ID. These pr ot ocol s t r ansmit t he
subnet mask al ong wit h t he net wor k ID in t he r out ing updat e message.
VLSM can be ver y, ver y conf using. One r ul e you shoul d f ol l ow: Do not make it over l y
compl icat ed. As a gener al r ul e, do not VLSM mor e t han t hr ee t imes. Yes, ef f iciency is
impor t ant , but you must sit down wit h your t eam or cust omer and det er mine t he
net wor k t opol ogy. For exampl e, if you use t he addr ess 150.1.0.0 wit h a /16 pr ef ix
(255.255.0.0), a ver y ef f ect ive met hod of using VLSM is /24 (f or subnet s wit h l ot s of
net wor ks), /27 (f or subnet s wit h f ewer host s or maybe higher -power ed net wor k-hogging
apps), and /30 (mask f or t he ser ial l ines). This is shown next . You can go wil d and t r y t o
devel op a mask f or ever y subnet , but having a f ew l ef t over bit s is f ine. Al so, using t his
met hod is not ef f icient as you wil l be spr eading dif f er ent subnet s t hr ough t he net wor k
in a noncont iguous f ashion, which can become bur densome on t he r out e t abl es.
However , it does expl ain t he var iabl e-l engt h subnet f eat ur e.
Fir st , your base addr ess is 150.1.0.0/16. This goes at t he t op of t he char t . Fr om her e we
wil l cr eat e 256 subnet s using t he /24 subnet mask. No host s have been assigned yet . We
cur r ent l y have 50 ser ial (point -t o-point ) l ines t o wor k wit h and pr edict a gr owt h of 100
mor e r emot e sit es over t he next t wo year s. Ther ef or e, we need 150 subnet s f or t he ser ial
l ines and t her e ar e onl y t wo host addr esses needed per ser ial l ine. We have r eser ved
t he 150.1.56.0, 150.1.57.0, and t he 150.1.58.0 subnet s f or ser ial l ines. The 150.1.56.0
net wor k is f ur t her subdivided (sub-subnet t ed) using t he f ir st 6 bit s of t he f our t h oct et
(255.255.255.252 or /30), yiel ding 64 subnet s f or ser ial l ines. Wit h each subnet (56, 57, and
58) suppor t ing 64 subnet s we now have 192 subnet s al l ot t ed f or ser ial l ines. We l eave 2
bit s, which al l ows f or t wo host addr esses t o be assigned (al l 0s and al l 1s ar e not
al l owed as host addr esses). Sevent y-f ive of t he subnet s wil l be assigned a anot her mask
(/27) t o al l ow f or sub-subnet s (subnet s of subnet s) wit h a smal l er number of host s per
subnet .
Var iabl e-Lengt h Subnet Masks

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 76
Longest Match Rule
As you can see, pl aying wit h t he addr ess l eads t o a l ot of ambiguit y. Using t hese
t echniques is not f or t he f aint of hear t . It can become ver y, ver y compl icat ed. Usual l y,
company net wor k manages do not have t o over l y concer n t hemsel ves wit h t his schema.
One r ul e t hat must be under st ood bef or e any of t his can wor k is t he longest match rule.
This is al so discussed in t he OSPF sect ion of t he book. When a net wor k ID is encount er ed
t hat mat ches t o dif f er ent -l engt h pr ef ixes, t he r out er wil l al ways t ake t he pat h
indicat ed by t he l ongest mask. For exampl e, if a r out er r eceives an IP dat agr am wit h t he
dest inat ion addr ess of 200.40.1.1 and a r out e t abl e l ookup f ound 200.40.1.0/24 and
200.40.0.0/16, t he r out er wil l f or war d t he dat agr am out t he pat h indicat ed by t he
l ongest mask: 200.40.1.0. Ther ef or e, you must make sur e t her e ar e no host s assigned t o
200.40.0.0/16.
Longest Mat ch Rul e
Al l ows a r out er t o det er mine t he best r out e based on gr anul ar it y of t he
masked addr ess.
Used when a net wor k ID is f ound t o mat ch mor e t han one subnet mask.
Exampl e:
Received dat agr am of 200.40.1.1
Rout e t abl e l ookup f ound t wo ent r ies:
200.40.1.0/24
200.40.0.0/16
Rout e woul d use t he 200.40.1.0/24
Must be car ef ul when assigning addr esses.
The l ongest mat ch r ul e is impl ement ed because t he l onger t he mask f ound, t he bet t er
gr anul ar it y t he r out er has in exact l y def ining t he cor r ect r out e.
Ther ef or e, you must be war y of t he f act t hat t he r out er wil l r out e t o t he r out e
det er mined by t he l ongest mask mat ch. If t her e ar e t wo ent r ies f or t he same r out e, t he
l ongest mask wins.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 77
Example One: An ISP Address Assignment
Let s l ook at anot her exampl e, t his t ime using a bet t er exampl e of addr ess assignment :
t he Int er net Ser vice Pr ovider . The ISP bl ock is 200.24.0.0/16. Hmmmmm. Looks a l it t l e
st r ange. This is a Cl ass C addr ess, but t her e is a 0 in t he t hir d oct et and t he pr ef ix
(subnet mask) is onl y 16-bit s wide. The nat ur al mask is 24 bit s (255.255.255.0). This is
known as supernetting, and wil l be shown in t he next pages, so bear wit h me her e.
A cust omer of t he ISP needs t hr ee subnet s, each suppor t ing 60 host s. Remember , we assign
t he mask cont iguous st ar t ing f r om t he l ef t . Since subnet s ar e divided evenl y (due t o t he
binar y nat ur e of t he addr ess), we cannot have t hr ee subnet s wit hout dividing t he
addr ess t o pr ovide f or f our subnet s. The addr ess assigned t o t he cust omer is
200.24.255.0/24. Ther ef or e:
1. How many bit s ar e needed in t he subnet mask t o suppor t t hr ee subnet s?
2. 2
n
2 = 4, t her ef or e 2 bit s ar e r equir ed in t he subnet mask. This l eaves one l ef t
over but masks must be cont iguous.
Exampl e One: An ISP Addr ess Assignment
3. This l eaves 6 bit s l ef t f or host assignment . 2
n
6 l eaves 62 (2
n
6 =64 and we
subt r act 2 because we cannot have al l 0s or al l 1s in t he host por t ion of t he
addr ess) addr ess assignment s f or host s, and t her ef or e we can use t his singl e
net wor k addr ess assignment f or our company.
This shoul d make you a l it t l e ner vous. Ther e ar e onl y t wo host s per subnet l ef t f or
expansion and t her e is onl y one subnet l ef t . The ISP shoul d make ver y sur e t hat t his
company wil l not gr ow anyt ime soon.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 78
Example Two: Relaxing the Assignment
The pr evious assignment wor ks, but is it r eal l y good? Al t hough we wer e abl e t o be ver y
st r ingent wit h t he addr ess assignment , t his is not a good way of assigning or masking t he
addr ess. It does not l eave much r oom f or gr owt h on t he host side or on t he net wor k
side. For exampl e, what if t he company expands t o 100 host s per subnet and r equir es t wo
mor e subnet s? It coul d cal l it s ISP back and r equest anot her addr ess assignment . But by
now, t he ISP has handed out a f ew mor e addr esses and t he next avail abl e addr ess f or
t he cust omer is 200.24.64.0/24. This is not cont iguous wit h t he or iginal assignment and
t he ISP has t o add anot her ent r y in t he ISPs t abl e when t his coul d have been avoided.
To ant icipat e f or t his expansion, t he cust omer coul d have been assigned f our Cl ass Cs.
The ISP bl ock assigned t o t he cust omer coul d be 200.1.252.0/22 (one ent r y in t he ISP
r out ing t abl e), which yiel ds t he Cl ass C addr esses of 200.1.252.0, 200.1.253.0, 200.1.254.0,
and 200.1.255.0. The cust omer is f r ee t o assign any subnet mask he or she wishes t o t he
addr esses wit hout not if ying t he ISP.
Fr om her e t he cust omer coul d assign 1 bit of subnet mask on t he addr ess of 200.1.252.0,
which al l ows f or 7 bit s of addr ess space yiel ding 125 (2
n
7 2) host s per subnet . The ot her
addr ess coul d r emain int act or be spl it wit h 1 bit subnet mask. The cust omer coul d al so
have simpl y used al l t he bit s in t he f our t h oct et , using no subnet mask. Yes, 1 bit subnet
mask is al l owed on a Cl ass C: a 0 subnet and a 1 subnet . Review RFC 1812. The onl y t ime
t his wil l l ead t o pr obl ems is if t he sit e is using al l subnet s br oadcast . However , check
wit h your r out er vendor . Cisco does not suppor t 1-bit subnet masks. In t his case, you wil l
have t o use t he Cl ass C assignment wit h subnet s. Wit h VLSM, t he consumer woul d have
t o devise a pl an t o det er mine which subnet s wil l onl y have 60 host s and which r equir e
mor e.
Exampl e Two: Rel axing t he Assignment
This is a simpl e exampl e of how you must t hink about your net wor k design bef or e
cal l ing an ISP. You need t o know how many host s and what t he t r af f ic pat t er ns ar e on
t he net wor k. IP addr esses ar e in shor t suppl y and ISPs do not hand t hem out
haphazar dl y. They must t ake int o consider at ion t heir r out ing t abl es as wel l .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 79
Supernetting Exposed
In t he pr evious exampl e, we showed a subnet mask f or a Cl ass C addr ess t hat was
shor t er t han t he nat ur al mask. Appl ying t his t o t he exampl e, t he ISP has a bl ock of
addr esses. As f ar as t he ISP is concer ned, t her e is no Cl ass associat ed wit h t he addr ess; it
is simpl y a bl ock of addr esses def ined by t he pr ef ix. This bl ock is assigned t o t he ISP by
t he Int er net Regist r y under t he aut hor it y of t he Int er net Assigned Number s Aut hor it y
(IANA, yes, t he same gr oup, act ual l y onl y one per son who handl es t he t op-l evel
domains). This is smal l (f our Cl ass C addr esses), but it shows up as one ent r y in t he
r out ing t abl e 200.1.252.0/22. Not ice t he mask at t he ISP is pushed back t o t he l ef t beyond
t he nat ur al subnet mask of a Cl ass addr ess. This is known as supernetting.
The cur r ent appr oach (in l ieu of IPv6) is t o pr ovide l ar ge cont iguous bl ocks of Cl ass C
(and possibl y ot her cl asses) addr esses. They ar e pr ovided by mor e l ocal l evel s in an
hier ar chical f ashion. For exampl e, a nat ional backbone pr ovider (cal l it ISP-1) wit h
connect ions t o ot her nat ional backbone pr ovider s t hr ough Net wor k Access Point s
(NAPs) wil l be assigned a l ar ge bl ock (one t hat wil l l ast t wo year s) of Cl ass C
addr esses. In t ur n, ot her r egional ser vice pr ovider s (cal l t hem ISP-2) who ut il ize ISP-1
wil l be assigned a bl ock of addr esses f r om ISP-1s addr ess bl ock assignment . In t ur n, ISP-
2 wil l pr ovide addr ess assignment t o it s cust omer s f r om t he bl ock it was assigned. This
al l ows f or ver y ef f icient and manageabl e gl obal r out ing t abl es (t hose r out ing t abl es
on t he t op-l evel pr ovider s).
Super net t ing Exposed

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 80
Route Aggregation
Rout e aggr egat ion is not a pr ot ocol . It is act ual l y a def init ion of what we ar e
accompl ishing on t he Int er net r out ing t abl es. Using t he exampl e ment ioned pr eviousl y,
you have been int r oduced t o a concept known as route aggregation. It al l ows a r out er t o
summar ize a gr oup of r out es as one adver t isement . Imagine having one ent r y in t he
r out ing t abl e t o r epr esent a l ar ge gr oup of addr esses. The r out er simpl y needs t o know
t he pr ef ix. This is compl et el y possibl e wit h r out e aggr egat ion, however , it is onl y usef ul
when t he r out es ar e cont iguous. Punching hol es in t he cont inuit y of t he r out es r educes
t he ef f iciency of t his concept .
To show t his benef it cl ear l y, I have chosen a Cl ass A exampl e. The net wor k addr ess is
20.0.0.0. The nat ur al mask f or t his is /8. or 255.0.0.0. We f ir st subnet t he addr ess using a
/16 pr ef ix, or 255.255.0.0. This al l ows f or addr esses in t he r ange of 20.0.0.0 t hr ough
20.255.0.0. We t ake t he 20.127.0.0 subnet and f ur t her subnet it wit h a pr ef ix of /24
(255.255.255.0). Final l y, we t ake t he 20.127.1.0 subnet and appl y a /27 pr ef ix.
Rout e aggr egat ion is based on t he concept of a common pr ef ix. What is t he common
pr ef ix assigned t o a gr oup of IP addr esses? For exampl e, t he 20.127.1.0 was subnet t ed t o
/27. However , al l t he subnet s t hat ar e cr eat ed by t his can be adver t ised as one r out e:
20.127.1.0/24. This is det ail ed l at er in t his sect ion. Al l of t he addr esses in t his r ange
have t he same pr ef ix. This woul d indicat e t o al l ot her r out er s t hat any net wor k in t he
r ange of 20.127.1.0 shoul d be f or war ded t o t hat r out er . The ot her r out er s do not car e
about any of t he par t icul ar subnet s beyond t hat addr ess. The r out er t hat r eceives t he
dat agr am t o be f or war ded t o any subnet bel ow 20.127.1.0 wil l be ident if ied by t he
r out er and it wil l f or war d it t o t he cor r ect net wor k.
Rout e Aggr egat ion
The r ul es ar e simpl e:
1. Wr it e down t he addr esses in t he r ange.
2. Conver t each addr ess t o binar y, one bel ow t he ot her .
3. Check f or a cont iguous, common pr ef ix.
4. Move t he pr ef ix t o t he l ast bit of t he cont iguous binar y digit .
5. Wr it e t he addr ess st ar t ing t he f ir st addr ess and appl y t he st ep 4 pr ef ix.
Remember , do not make t his compl icat ed. It is conf using enough. Thr ee var iabl e subnet
masks ar e enough t o wor k wit h f or most net wor ks (business net wor ks and ISPs
excl uded).

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 81
Determining a Common Prefix
The /27 pr ef ix al l ows f or an addr ess r ange of :
20.127.1.32
20.127.1.64
20.127.1.96
20.127.1.128
20.127.1.160
20.127.1.192
20.127.1.224
Conver t t his t o binar y:
000010100.01111111.00000001.00100000 = 20.127.1.32
000010100.01111111.00000001.01000000 = 20.127.1.64
000010100.01111111.00000001.01100000 = 20.127.1.96
000010100.01111111.00000001.10000000 = 20.127.1.128
000010100.01111111.00000001.10100000 = 20.127.1.160
000010100.01111111.00000001.11000000 = 20.127.1.192
000010100.01111111.00000001.11100000 = 20.127.1.224
000010100.01111111.00000001.00000000 = Common pr ef ix t o al l of t he pr eceding
addr esses
Det er mining a Common Pr ef ix
Ther ef or e, appl ying r ul es 4 and 5, we have 20.127.1.0/24, which r epr esent s al l of t he
addr esses.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 82
Another Look at Route Aggregation
In t his exampl e, aggr egat ion is somewhat l ess ef f icient , but you woul d not know it f r om
t he addr ess. The f ol l owing addr esses appear t o be cont iguous:
155.1.140.0
155.1.141.0
155.1.142.0
155.1.143.0
155.1.144.0
But when we t r ansl at e it t o binar y t o f ind t he common pr ef ix t o al l of t he addr esses,
we f ind a noncont iguous bit pat t er n:
10011011.00000001.10001100.00000000 = 155.1.140.0/24
10011011.00000001.10001101.00000000 = 155.1.141.0/24
10011011.00000001.10001110.00000000 = 155.1.142.0/24
10011011.00000001.10001111.00000000 = 155.1.143.0/24
10011011.00000001.10010000.00000000 = 155.1.144.0/24
10011011.00000001.100011xx.00000000 = Common pr ef ix
The common pr ef ix is 100011xx in t he t hir d oct et . Why? Because we do not know wher e
145 or higher is? We have t o see which ones have t he same pr ef ix and t hen use t hat . Any
ot her number s must be separ at e ent r ies in t he t abl e. This woul d give us a r out e
aggr egat ion of 155.1.140.0/22, but t his l eaves out t he 155.1.144.0 subnet . Depending on
t he r ange t hat t his addr ess is in, it coul d be l ist ed in anot her r out e aggr egat ion pr ef ix.
Since t his is al l t he inf or mat ion we wer e given, however , 155.1.144.0 must be l ist ed as a
separ at e r out e: 155.1.144.0/24 (subnet mask of 255.255.255.0). This is due t o t his addr ess
not being wit hin t he r ange of t he common pr ef ix of t he ot her addr esses even t hough t he
decimal addr ess is cont iguous. Net wor ks do not cal cul at e r out es in decimal !!! Humans
do, and t his is why we make mist akes.
Anot her Look at Rout e Aggr egat ion
155.1.140.0
155.1.141.0
155.1.142.0
155.1.143.0
155.1.144.0
When we t r ansl at e it t o binar y t o f ind t he common pr ef ix t o al l of t he addr esses, we
f ind a non-cont iguous bit pat t er n:
10011011.00000001.10001100.00000000 = 155.1.140.0/24
10011011.00000001.10001101.00000000 = 155.1.141.0/24
10011011.00000001.10001110.00000000 = 155.1.142.0/24
10011011.00000001.10001111.00000000 = 155.1.143.0/24
10011011.00000001.10010000.00000000 = 155.1.144.0/24
10011011.00000001.100011xx.00000000 = Common pr ef ix
You shoul d al so not ice t hat t his al l ows us t o have one r out e ent r y inst ead of f our .
This may not seem l ike much, but when t his concept is appl ied t o a l ar ger r ange of
addr esses (such as t hose on t he Int er net r out ing t abl es), one r out e ent r y is used t o
aggr egat e t housands of individual addr esses.
The common pr ef ix is 100011, which al l ows us t o aggr egat e t hose r out es t o 155.1.140.0/14.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 83
Classless Inter-Domain Routing (CIDR)
Ther e is a l ot mor e t o CIDR t han what is pr esent ed her e, but f or our pur poses, t his wil l
do. Wit h CIDR, net wor k number s and cl asses of net wor ks ar e no l onger val id f or
r out ing pur poses. This is wher e t he net wor k IP addr ess f or mat changes t o <IP Addr ess,
pr ef ix l engt h>. Mind you, t his is f or t he Int er net r out ing t abl es (ISPs); Cl ass addr essing
is cont inuing t o be used in cust omer envir onment s. Cl assl ess coul d oper at e in a cust omer
envir onment , but most host s woul d not under st and t his t ype of impl ement at ion. The
mil l ions and mil l ions of host s t hat ar e at t ached t o t he Int er net ar e st il l oper at ing in a
Cl ass envir onment ; t her ef or e, we simpl y have cr eat ed a hier ar chical r out ing
envir onment t hat does not af f ect t he cust omer envir onment what soever . Let s st ar t
out t his discussion by assigning a pr ef ix t o t he wel l -known Cl ass addr esses. CIDR coul d
oper at e in a cust omer envir onment , but t hat woul d r equir e upgr ading al l r out er s and
host s t o under st and CIDR. This is not going t o happen. CIDR is pr imar il y used on t he
Int er net r out er s.
Cl ass A net wor ks have a /8 pr ef ix
Cl ass B net wor ks have a /16 pr ef ix
Cl ass C net wor ks have a /24 pr ef ix
/8? /16? /24? Hopef ul l y, somet hing cl icked her e! What we have changed t o is t he
net wor k pr ef ix. A net wor k number is basical l y a net wor k pr ef ix. Nodes on a cl assl ess
net wor k simpl y det er mine t he addr ess by f inding t he pr ef ix val ue. This val ue indicat es
t he number of bit s, st ar t ing f r om t he l ef t , which wil l be used f or t he net wor k. The
r emaining bit s ar e l ef t f or host assignment . The pr ef ix can r ange anywher e f r om /0 t o
/32, which al l ows us t o move t he net wor k por t ion of t he addr ess anywher e on t he 32-bit
number .
Imagine t hen, an addr ess of 198.1.192.0/20. This l ooks l ike a Cl ass C addr ess, but t he
nat ur al mask f or a Cl ass C is 24 bit s or /24 pr ef ix. This one al l ows f or onl y 20 bit s as t he
net wor k assignment . But t his pr ef ix coul d be assigned t o any addr ess r egar dl ess of
cl ass. It coul d be assigned t o 15.1.192.0 or 128.1.128.0. The pr ef ix does not car e about
Cl ass. This is t he capabil it y of CIDR. The f ol l owing sect ion assumes t hat you can
conver t binar y t o decimal and vice ver sa. If not , pl ease r ef er t o t he appendix at t he end
of t his book f or an expl anat ion on binar y.
Cl assl ess Int er -Domain Rout ing (CIDR)
Net wor k number s accor ding t o cl asses of addr esses ar e no l onger val id.
IP addr ess f or mat changes t o <IP Addr ess, Pr ef ix>.
Pr imar il y used in ISP r out ing t abl es.
The gl obal Int er net r out ing t abl es
Most host s on a net wor k woul d not under st and t his
Easy exampl es ar e changing t he cl ass addr ess.
Cl ass A has a /8 pr ef ix
Cl ass B has a /16 pr ef ix
Cl ass C has a /24 pr ef ix
What about 198.1.192.0/20?
Super net t ed Cl ass C addr ess t hat pr ovides f or r out e aggr egat ion using
a concept simil ar t o VLSM

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 84
Classless Inter-Domain Routing (continued)
You know t hat I must be l eading up t o somet hing. It is t he next st ep in under st anding IP
addr esses and Int er net r out ing. It is cal l ed CIDR (pr onounced cider ). CIDR is expl ained
in RFCs 15171520, so I am not det ail ing t he CIDR spec her e. Just t he concept . The
concept is simpl e: Impl ement a gener al izat ion of Var iabl e Lengt h Subnet Masks and
move f r om t he t r adit ional Cl ass A, B, C addr ess t owar d t he idea of a 32-bit IP addr ess
and a pr ef ix (wit hout t he concept of a Cl ass). In CIDR, t her e ar e 32 bit s and a pr ef ix. To
under st and CIDR, you must pl ace t he concept not on your l ocal net wor k but on t he
Int er net r out er s. You can empl oy CIDR on your net wor k, but t her e is r eal l y no r eason
t o (since your host s woul d have t o be conf igur ed t o under st and super net s). The
Int er net r out ing t abl es wer e expanding at a exponent ial r at e (wit hout CIDR, t hey
woul d have passed over 80,000 r out es t oday). The Int er net r out er s ar e simpl y t hose
devices t hat move dat a t owar ds a dest inat ion indicat ed by it s IP addr ess, and t her ef or e
do not have l ar ge subnet s of f of t hem wit h which t o suppor t host s. CIDR wor ks on t he
not ion t hat we ar e r out ing ar bit r ar il y sized (a r ange) net wor k addr ess space inst ead of
r out ing on Cl ass A, B, and C. CIDR r out es based on r out ing inf or mat ion t hat has t he
pr ef ix at t ached t o it . For exampl e, t he addr ess of 200.15.0.0/16 coul d be an ent r y in t he
Int er net r out ing t abl eone ent r y indicat ing a r ange of addr esses. Any IP dat agr ams
r eceived by t hat r out er wit h t he f ir st 16 bit s indicat ing 200.15 woul d be f or war ded out
t he por t indicat ed in t he r out ing t abl e. This pr ef ix coul d be assigned t o any r ange of
addr esses because CIDR does not associat e a pr ef ix wit h a Cl ass.
Cl assl ess Int er -Domain Rout ing (cont inued)
Pr onounced cider .
Expl ained in RFCs 15171520.
Uses a gener al izat ion of t he VLSM.
Move f r om t r adit ional Cl ass t o a pr ef ix.
Al l ows f or r out e aggr egat ion in t he Int er net r out ing t abl es.
Reduces t he size and t her ef or e incr eases t he speed
Wor ks on t he not ion t hat we ar e r out ing ar bit r ar il y sized net wor k addr ess
space.
One ent r y in a r out ing t abl e coul d possibl y mat ch mil l ions of addr esses.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 85
Prefix Assignments
Pr ef ix Dot t ed-Decimal Number of Addr esses Number of Cl ass Addr esses
/13 255.248.0.0 512k 8 Cl ass B or 2048 Cl ass C
/15 255.254.0.0. 128k 2 Cl ass B or 512 Cl ass C
/17 255.255.128.0 32k 128 Cl ass C
/18 255.255.192.0 16k 64 Cl ass C
/19 255.255.224.0 8k 32 Cl ass C
/20 255.255.240.0 4k 16 Cl ass C
/21 255.255.248.0 2k 8 Cl ass C
/22 255.255.252.0 1k 4 Cl ass C
/23 255.255.254.0 512 2 Cl ass C
/24 255.255.255.0 256 1 Cl ass C
/25 255.255.255.128 128 _ Cl ass C
/26 255.255.255.192 64 _ Cl ass C
/27 255.255.255.224 32 1/8 Cl ass C
We must l ook at t his concept t hr ough t he ISP net wor ks. ISPs give us t he abil it y t o
communicat e over t he Int er net . You cannot simpl y at t ach t o t he Int er net unl ess you
connect wit h an ISP. ISPs come is a var iet y of f l avor s: some ar e l ar ge and pr ovide access
t o ot her ISPs and individual s, and some ar e smal l and onl y pr ovide Int er net
connect ivit y t o individual s and businesses. ISPs ar e al l ocat ed bl ocks of addr esses t hat
ar e cont iguous in r ange. The concept f ir st used Cl ass C addr esses since Cl ass B addr esses
wer e exhaust ed and Cl ass A addr esses wer e not handed out (t hey ar e being handed out
t oday). The basic idea of t he pl an is t o al l ocat e bl ocks of Cl ass C (f ir st , ot her Cl ass A
and B addr esses t o f ol l ow) net wor k number s t o each net wor k ser vice pr ovider . (It is
ver y hel pf ul her e t o r ead RFC 2050 bef or e cont inuing t his sect ion). The cust omer s of
t hese pr ovider s ar e t hen al l ocat ed bit mask-or ient ed subnet s of t he ser vice pr ovider s
addr ess. The assignment bl ocks t o t he IR can be f ound at t he end of t his sect ion.
Pr ef ix Assignment s
Pr ef ix Dot t ed-Decimal Number of Addr esses Number of Cl ass
Addr esses
/13 255.248.0.0 512k 8 Cl ass B or 2048 Cl ass
C
/14 255.252.0.0 256k 4 Cl ass B or 1024 Cl ass
C
/15 255.254.0.0. 128k 2 Cl ass B or 512 Cl ass
C
/16 255.255.0.0 64k 1 Cl ass B or 256 Cl ass
C
/17 255.255.128.0 32k 128 Cl ass C
/18 255.255.192.0 16k 64 Cl ass C
/19 255.255.224.0 8k 32 Cl ass C
/20 255.255.240.0 4k 16 Cl ass C
/21 255.255.248.0 2k 8 Cl ass C
/22 255.255.252.0 1k 4 Cl ass C
/23 255.255.254.0 512 2 Cl ass C
/24 255.255.255.0 256 1 Cl ass C
/25 255.255.255.128 128 _ Cl ass C
/26 255.255.255.192 64 _ Cl ass C
/27 255.255.255.224 32 1/8 Cl ass C

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 86
A Look at the Addresses of an ISP
An ISP has been assigned t his bl ock f r om t he Int er NIC:
209.16.0.0/16.
At f ir st gl ance, t his addr ess l ooks l ike a Cl ass C, but t he pr ef ix does not mat ch a Cl ass
C. It is a Cl ass B pr ef ix. Again, t his is known as supernetting and shows t hat CIDR does not
car e about Cl asses. Wit h a pr ef ix of /16, t his woul d r epr esent 256 Cl ass C addr esses.
However , in CIDR, t he ISP is f r ee t o choose any met hod of segment ing t his addr ess and
handing it out t o it s cust omer s. The ISP al so knows t hat IANA and t he Int er NIC do not
just hand out l ot s of addr esses; t her ef or e, t he ISP is ver y car ef ul about car ving up t he
addr esses.
The ISP pul l s of f a por t ion of t he addr ess space using a /20 pr ef ix: 209.16.16.0/20. This
r epr esent s a smal l por t ion of t he addr esses, or 16 Cl ass C addr esses. The ISP l eaves t he
upper 4 bit s of t he addr ess r eser ved f or f ut ur e use. 209.16.16.0/20 is t he addr ess space
t hat we wil l wor k wit h. Based on some sur veys wit h it s cust omer s, t he ISP cut s t he
addr ess int o t wo pieces yiel ding 209.16.16.0/21 and 209.16.24.0/21. (For t hose not f amil iar
wit h binar y, shif t ing r ight 1 bit divides t he number by 2. Shif t ing l ef t 1 bit mul t ipl ies t he
number by 2). 209.16.16.0/21 (eight Cl ass Cs) is assigned t o a singl e cust omer . The ot her
hal f of t he addr ess, 209.16.24.0, is cut up again int o t hr ee pieces:
A Look at t he Addr esses of an ISP
ISP is al l ocat ed a bl ock of addr esses: 209.16.0.0/16.
It must now f ind an ef f icient br eakup of t he addr ess
ISP segment s of f 16
addr esses of t he
or iginal addr ess
209.16.0.0/16
becomes
209.16.16.0/20
11010001.00010000.00000000.00000000
11010001.00010000.0001 | 0000.00000000
ISP spl it s t his new
addr ess in hal f ,
yiel ding t wo addr ess
r anges
209.16.16.0/21
209.16.24.0/21
11010001.00010000.00010 | 000.00000000
11010001.00010000.00011 | 000.00000000
Based on a cust omer
sur vey, 209.16.16.0/21
is given t o a singl e
cust omer
Yiel ds 8 Cl ass C
addr esses
209.16.24.0/21 is
spl it up again
209.16.24.0/22
209.16.28.0/23
209.16.30.0/23
11010001.00010000.000110 | 00.00000000
11010001.00010000.0001110 | 0.00000000
11010001.00010000.0001111 | 0.00000000
209.16.24.0/22 r epr esent ing _ of t he addr ess (f our Cl ass Cs)
209.16.28/23 r epr esent ing 1/8 of t he addr ess (t wo Cl ass Cs)
209.16.30.0/23 r epr esent ing 1/8 of t he addr ess (t wo Cl ass Cs)

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 87
A Graphic Look at the Example
How is t his done
Act ion Addr ess Space Binar y Equival ent
ISP segment s of f 16
addr esses of t he
or iginal addr ess
209.16.0.0/16
becomes
209.16.16.0/20
11010001.00010000.00000000.00000000
11010001.00010000.0001 | 0000.00000000
ISP spl it s t his new
addr ess in hal f ,
yiel ding t wo addr ess
r anges
209.16.16.0/21
209.16.24.0/21
11010001.00010000.00010 | 000.00000000
11010001.00010000.00011 | 000.00000000
Based on a cust omer
sur vey, 209.16.16.0/21
is given t o a singl e
cust omer
Yiel ds 8 Cl ass C
addr esses
209.16.24.0/21 is
spl it up again
209.16.24.0/22
209.16.28.0/23
209.16.30.0/23
11010001.00010000.000110 | 00.00000000
11010001.00010000.0001110 | 0.00000000
11010001.00010000.0001111 | 0.00000000
Ther ef or e, cust omer A get s t he Cl ass C addr ess r ange of 209.16.16.0 t hr ough 209.16.23.0.
Cust omer B get s t he Cl ass C addr ess r ange of 209.16.24.0 t hr ough 209.16.27.0.
Cust omer C get s t he Cl ass C addr ess r ange of 209.16.28.0 t hr ough 209.16.29.0.
Cust omer D get s t he Cl ass C addr ess r ange of 209.16.30.0 t hr ough 209.16.31.0.
A Gr aphic Look at t he Exampl e
Use t he pr eceding addr esses and count up in binar y using t he t abl e and you wil l get a
bet t er pict ur e of how t his oper at es.
So CIDR is at t he ISP and Cl ass addr essing is at t he cust omer sit e. What does t his buy us?
Not necessar il y anyt hing (except a f ast er net wor k wit h t he ISP), but it does gr eat
t hings f or t he ISPs r out ing t abl es and, t her ef or e, t he Int er net r out ing t abl es.
Wher eas t he ISP woul d have had 16 ent r ies in t he r out ing t abl e, it now has 4. Wher eas
t he Int er net r out ing t abl es woul d have had 256 ent r ies in t he gl obal r out ing t abl e,
t hey now have 1. Now mul t ipl y t his by t he number of ISPs wor l dwide and I t hink you
begin t o see t he ef f iciencies of t his pr ot ocol , and wit hout it t he expl osion of t he
Int er net r out ing t abl es.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 88
CIDR and VLSM Comparison
CIDR and VLSM seem simil ar ; in essence, t hey ar e. Why not use VLSM inst ead of CIDR?
The dif f er ence is t hat CIDR al l ows f or t he ef f icient r out ing mechanism t o t ake pl ace by
t he r ecur sive al l ocat ion of an addr ess bl ock. Rout ing is t hen based on t his addr ess
bl ock al l ocat ion and not on an individual Cl ass addr ess. This bl ock is handed down by
t he IANA t o t he IR, t o t he upper -l evel ISP down t hr ough t he r anks of downst r eam ISPs,
and, f inal l y, t o t he cust omer .
CIDR and VLSM Compar ison
CIDR and VLSM ar e simil ar .
CIDR al l ows f or t he ef f icient r out ing mechanism t o t ake pl ace by t he abil it y
of t he r ecur sive al l ocat ion of an addr ess bl ock.
Rout ing is based on t he addr ess bl ock al l ocat ion and not t he individual Cl ass
addr ess.
VLSM per mit s r ecur sion at wil l but mor e so on an individual addr ess space in
use by t he cust omer .
VLSM al l ows f or var iabl e l engt hs based on a Cl ass addr ess assigned by an ISP.
VLSM per mit s r ecur sion as wel l , but mor e so on an individual addr ess space in use by t he
cust omer . A cust omer division of an addr ess space is not visibl e by t he Int er net . VLSM
st il l oper at es wit h Cl ass addr esses.
Var iabl e-l engt h masks al l ow f or var iabl e-l engt h subnet s per net wor k ID based on an
addr ess assignment by an ISP. This al l ows one net wor k number t o cont ain dif f er ent
masks and is a bet t er use of an IP addr ess. Wit h VLSM, a l ot of t he bit s in an addr ess
space ar e wast ed. The exampl e is assigning an IP addr ess t o a point -t o-point WAN l ink,
which wast es 252 addr ess bit s.
This al l ows f or gr eat er f l exibil it y when dividing up a net wor k ID int o subnet s and
host s. Wit hout VLSM, you have t o choose bet ween having enough net wor ks, wit h cl ose
t o t he r ight amount of host s, or having t he r ight amount of host s wit h cl ose t o t he
r ight amount of net wor ks.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 89
Special Subnet Considerations
RFC 950 (page 5) st at es t hat we shoul d pr eser ve t he al l 0s and al l 1s in t he subnet
f iel d, f or t hey have special meaning in t he cer t ain f iel ds indicat ed by IANA-assigned
RFC number s. For exampl e, t he addr ess 130.1.255.255 coul d be int er pr et ed as meaning al l
host s on t he net wor k 130.1, or t he addr ess 0.0.0.1 coul d be int er pr et ed as meaning host 1
on t his net wor k.
It is useful to preserve and extend the interpretation of these special addresses in
subnetted networks. This means the values of all 0s and all 1s in the subnet field should
not be assigned to actual (physical) subnets.
Due t o incr easing demand t o make f ul l use of al l of t he bit s in t he 32-bit wide addr ess,
subnet 0s and 1s ar e al l owed. However , you must exer cise caut ion when doing so. RFC
1812 (Requir ement s f or IPv4 Rout er s) st at es:
All-subnets broadcasts (called multisubnet broadcasts) have been deprecated. . . . In a
CIDR routing domain, wherein classical IP network numbers are meaningless, the
concept of an all-subnets-directed-broadcast is also meaningless.
Basical l y, t her e ar e not subnet s in CIDR.
Now, whil e t he pr eceding ext r act was t al king about t he CIDR r out er domain, it coul d
be misr ead by any r out ed domain. Many r out er vendor s int er pr et RFCs dif f er ent ways.
For exampl e, 3Com has t he abil it y t o t ur n ASB (Al l Subnet s Br oadcast ) r out ing on or
of f , t her eby al l owing al l 1s subnet wor k number f r ee t o be assigned.
You may t hink, why woul d you want t o pl ace an ASB? This can come in handy when
mul t icast ing. As of t his wr it ing, t he mul t icast pr ot ocol s ar e not being used on cust omer
net wor ks, mainl y due t o inexper ience and ner vousness of t he r out er suppor t st af f and
it s management . Rout ed net wor ks ar e t r icky enough wit hout t hor oughl y
under st anding mul t icast ing. Ther ef or e, mul t icast appl icat ion sof t war e vendor s suppor t
ASB t o r out e t heir inf or mat ion in a nonmul t icast net wor k. Unr ul y, yes, but it wor ks.
This t hinking may be pr opagat ed down t o t he l owest l evel s of r out ing in t he Int er net :
t he cust omer AS. If t he cust omer AS has depr ecat ed ASB, t hen you wil l be
impl ement ing al l 0s and al l 1s subnet s. However , if a cust omer net wor k has impl ement ed
it (al l 1s subnet s), t hen a packet addr essed t o an ASB wil l be r out ed t o t he subnet
r epr esent ed by t he al l 1s.
Special Subnet Consider at ions
RFC 950 or iginal l y indicat ed t hat 0s and 1s shoul d not be used in eit her host
or subnet assignment s.
Special meaning in t hat 0.0.0.1 means host 1 on t his subnet .
Incr easing pr essur e f or ced t he use of al l avail abl e bit s f or subnet t ing.
CIDR has no concept of subnet s, t her ef or e it has no concept of 0s or 1s being
r eser ved.
You shoul d be car ef ul in using al l 0s or 1s in a subnet . An al l 1s subnet coul d
be misint er pr et ed as an al l -subnet s br oadcast .
Al l 1s in t he subnet f iel d coul d dir ect a r out er t o f or war d t he packet
t o al l subnet s under t he indicat ed net wor k ID.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 90
Internet Assigned Numbers Authority
Int er net Assigned Number s Aut hor it y
The owner of al l number assignment s f or t he TCP/IP pr ot ocol , incl uding many
ot her number assignment s f r om ot her pr ot ocol s t hat ar e asociat ed wit h TCP/IP.
This incl udes por t number s, mul t icast addr ess, IP addr esses, et c.
IANA char t er ed by t he Int er net Societ y (ISOC) and t he Feder al Net wor k
Council (FNC).
Cur r ent RFC number is RFC 1700.
Updat es ar e avail abl e t hr ough:
f t p://f t p.isi.edu/in-not es/iana/assignment s
The Int er net pr ot ocol suit e, as def ined by t he Int er net Engineer ing Task For ce (IETF)
and it s st eer ing gr oup (t he IESG), cont ains numer ous par amet er s, such as int er net
addr esses, domain names, aut onomous syst em number s (used in some r out ing pr ot ocol s),
pr ot ocol number s, por t number s, management inf or mat ion-based object ident if ier s
(incl uding pr ivat e ent er pr ise number s), and many ot her s.
The Int er net Assigned Number s Aut hor it y (IANA) is t he cent r al coor dinat or f or t he
assignment of unique par amet er val ues f or Int er net pr ot ocol s. The IANA is char t er ed by
t he Int er net Societ y (ISOC) and t he Feder al Net wor k Council (FNC) t o act as t he
cl ear inghouse t o assign and coor dinat e t he use of numer ous Int er net pr ot ocol
par amet er s.
Cer t ain f iel ds wit hin IP and TCP ar e r equir ed t o be unique. Imagine a por t number t hat
is ar bit r ar il y assigned f or FTP, or an IP addr ess t hat is al l owed t o be assigned by any
sit e and t hen want s t o connect t o t he Int er net . It is t he t ask of t he IANA t o make t hose
unique assignment s as r equest ed and t o maint ain a r egist r y of t he cur r ent l y assigned
val ues.
As of t his wr it ing, RFC 1700 cont ains t he compil at ion of assigned number s. However , an
up-t o-dat e FTP sit e is avail abl e at :
f t p://f t p.isi.edu/in-not es/iana/assignment s
Request s f or par amet er assignment s (pr ot ocol s, por t s, et c.) shoul d be sent t o:
<iana@isi.edu>
Request s f or SNMP net wor k management pr ivat e ent er pr ise number assignment s shoul d
be sent t o:
<iana-mib@isi.edu>
The IANA is l ocat ed at and oper at ed by t he Inf or mat ion Sciences Inst it ut e (ISI) of t he
Univer sit y of Sout her n Cal if or nia (USC). If you ar e devel oping a pr ot ocol or
appl icat ion t hat wil l r equir e t he use of a l ink, socket , por t , pr ot ocol , and so f or t h,
pl ease cont act t he IANA t o r eceive a number assignment (r ef er t o RFC 1700).

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 91
Current IANA Address Block Assignments
Addr ess Bl ock Regist r y - Pur pose Dat e
000063/8 IANA Sep 81
064095/8 IANAReser ved Sep 81
127/8 IANA Sep 81
128191/8 Var ious Regist r ies May 93
192193/8 Var ious Regist r iesMul t iRegional May 93
194195/8 RIPE NCCEur ope May 93
196197/8 Int er nicOt her s May 93
198199/8 Int er nicNor t h Amer ica May 93
200201/8 Int er nicCent r al and Sout h Amer ica May 93
202203/8 APNICPacif ic Rim May 93
204205/8 Int er nicNor t h Amer ica Mar 94
206/8 Int er nicNor t h Amer ica Apr 95
207/8 Int er nicNor t h Amer ica Nov 95
209/8 Int er nicNor t h Amer ica Jun 96
210/8 APNICPacif ic Rim Jun 96
224239/8 IANAMul t icast (Cl ass D) Sep 81
240255/8 IANAReser ved (Cl ass E) Sep 81
Cur r ent IANA Addr ess Bl ock Assignment s
Addr ess
Bl ock
Regist r y - Pur pose Dat e
000063/8 IANA Sep 81
127/8 IANA Sep 81
128191/8 Var ious Regist r ies May 93
192193/8 Var ious Regist r iesMul t iRegional May 93
194195/8 RIPE NCCEur ope May 93
196197/8 Int er nicOt her s May 93
198199/8 Int er nicNor t h Amer ica May 93
200201/8 Int er nicCent r al and Sout h
Amer ica
May 93
202203/8 APNICPacif ic Rim May 93
204205/8 Int er nicNor t h Amer ica Mar 94
207/8 Int er nicNor t h Amer ica Nov 95
209/8 Int er nicNor t h Amer ica Jun 96
224239/8 IANAMul t icast (Cl ass D) Sep 81
240255/8 IANAReser ved (Cl ass E) Sep 81

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 92
IP Routing
We had t o go t hr ough t he IP addr essing sect ion in or der t o under st and r out ing.
Hopef ul l y, t his sect ion wil l be a l ot mor e compr ehensibl e. Packet s ar e r out ed based on
t he addr ess t hat is in t he packet . Rout er s r ead t his inf or mat ion and det er mine t he best
pat h known as t he next hop. A packet swit ched net wor k (compar ed t o a cir cuit swit ched
net wor k) is based on a unit of inf or mat ion (known as a datagram) and it s abil it y t o make
it s way t hr ough t he net wor k t o t he dest inat ion. The dat agr am may be r out ed l ocal l y
(t he dest inat ion is on t he same subnet as t he or iginat or ) which is known as direct routing,
or it may invoke t he use of a f or war ding device such as a r out er if t he dest inat ion is
r emot e (on a dif f er ent subnet t han t he or iginat or ). The l at t er is known as indirect
routing, which inf er s hier ar chical r out ing. A dat agr am t hat is sent may invoke bot h
dir ect and indir ect r out ing.
Why not just have one l ar ge f l at net wor k? Pl ace ever yone on t he same net wor k. ATM
t r ied t o do t his as wel l as swit ches and br idges. El iminat e indir ect r out ing compl et el y.
Fl at net wor ks do have t heir pl ace: in smal l net wor ks or WAN pr ot ocol s or t o ext end a
subnet t hr ough swit ches or br idges. Wit h t he cur r ent suit e of net wor k pr ot ocol s, a
l ar ge f l at net wor k is inef f icient (it does not scal e wel l ), especial l y when you est imat e
t he mil l ions of addr essabl e st at ions t hat ar e at t ached t o it . And t he pr ot ocol s t hat
cur r ent l y r un on net wor ks ar e br oadcast or ient ed. This means t he net wor k al l ows f or
mul t ipl e st at ions t o be at t ached and gr ouped t o a singl e net wor k, and t hese st at ions
see al l dat a on t heir net wor k no mat t er who sent it and who it is f or . The pr ot ocol s
wer e buil t f or shar ed envir onment s. These net wor ks wer e invent ed bef or e t he advent
of swit ches and r out er s. Al so, when st at ions need t o communicat e, t he init ial
communicat ion coul d be sent in br oadcast mode. Communicat ion bet ween cer t ain devices
(r out er s) is al ways done in br oadcast or mul t icast . This is a special t ype of packet t hat
enabl es al l st at ions t o r eceive t he packet and hand it t o t heir upper -l ayer sof t war e t o
f il t er or pr ocess. As you scal e f or gr owt h, a net wor k cannot r emain f l at . Ther e must be
some sor t of hier ar chy t o al l ow f or ef f iciency.
IP Rout ing
Two t ypes: dir ect and indir ect .
Rout ing pr ovides f or ef f icient net wor k t opol ogies.
Fl at net wor ks cannot scal e.
Pr ot ocol s used t oday ar e t he same ones t hat wer e used back in t he shar ed
net wor k envir onment .
Two t ypes of r out ing pr ot ocol s: IGP and EGP.
IGP pr ovides f or r out ing wit hin a singl e AS
EGP pr ovides f or r out ing bet ween ASs
Not al l st at ions need t o see each ot her . As a net wor k scal es, it must maint ain it s
manageabil it y. To make any net wor k mor e manageabl e, it wil l be spl it int o many
net wor ks cal l ed subnets (vir t ual l y any net wor k t oday, whet her spl it or not , is cal l ed a
subnet). To make t hese subnet net wor ks manageabl e t hey wil l in t ur n be spl it f ur t her
int o sub-subnet s. The int er connect ion of t hese subnet s is accompl ished by f or war ding
devices known as routers. Rout er s enabl e dat a t o be f or war ded t o ot her net wor ks in a
ver y ef f icient manner . It wil l al ways be easier t o manage many smal l er net wor ks t han
it wil l be t o manage one l ar ge net wor k. Al so, br oadcast dat a st ays on it s net wor k or
subnet . It is not f or war ded by r out er s (except ions occur and t hey wil l be not ed in t hose
sect ions, such as DHCP or al l subnet s br oadcast ).
In or der f or r out er s t o f or war d dat a t o ot her net wor ks, t hey use special pr ot ocol s
(known as routing pr ot ocol s) t o enabl e t hem t o int er nal l y dr aw a map of t he ent ir e
int er net f or t he pur poses of r out ing. To accompl ish t his, t her e ar e t wo t ypes of
pr ot ocol s used: Int er ior Gat e-way Pr ot ocol s (IGPs) and Ext er ior Gat eway Pr ot ocol s
(EGPs). The Ext er ior Gat eway Pr ot o-col used wit h IP is known as Bor der Gat eway
Pr ot ocol (BGP). The IGPs t hat I wil l expl ain ar e known as t he Rout ing Inf or mat ion
Pr ot ocol (RIP and RIP2) and Open Shor t est Pat h Fir st (OSPF).

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 93
Direct Routing
As st at ed bef or e t her e ar e t wo t ype of r out ing: dir ect and indir ect . This sect ion gives
you a br ief int r oduct ion t o dir ect r out ing. Thr oughout t his sect ion, dif f er ent net wor k
number s wil l be used. The exampl es wil l not empl oy t he use of subnet s. Subnet s
ef f ect ivel y act l ike net wor k number s. Subnet s ar e al so separ at ed by a r out er . For
exampl e, in t he sl ide, t he net wor k number s coul d be 140.1.1.1 on t he net wor k wit h
endst at ion B, and 140.1.2.1 on t he net wor k cont aining host A. Using a subnet mask of
255.255.255.0 woul d yiel d t wo dif f er ent net wor ks: 140.1.1.0 and 140.1.2.0. For simpl icit y
in expl aining r out er s, I have chosen t o use compl et el y dif f er ent net wor k number s.
How does a net wor k st at ion know whet her t he packet has t o be dir ect l y (l ocal ) or
indir ect l y (r emot e) r out ed? For t he net wor k st at ion, it is a r el at ivel y simpl e pr ocess.
The whol e basis f or r out ing is in t he IP net wor k number assigned t o t he net wor k
st at ion.
Remember f r om t he pr evious sect ion on Addr essing t hat an IP addr ess cont ains t he
net wor k number as wel l as t he host number . Wit h t he f ir st 1, 2, 3, or 4 bit s of t he 32-bit
IP net wor k addr ess ident if ying t he cl ass of t he addr ess, t his al l ows f or any net wor k
st at ion (wor kst at ion or r out er ) t o quickl y ext r act t he net wor k por t ion out of t he
cl ass of IP addr ess. In ot her wor ds, by r eading up t o t he f ir st 4 bit s of t he IP addr ess, a
net wor k st at ion can quickl y det er mine how much of t he IP addr ess t o r ead t o det er mine
t he net wor k number of t he addr ess. The sending st at ion wil l compar e t he packet s
dest inat ion net wor k number t o t hat of it s own net wor k number . If t he net wor k number
por t ion of t he dest inat ion IP addr ess mat ches it own, t he packet can be r out ed dir ect l y
on t he l ocal LAN, wit hout t he use of a r out er . The packet is simpl y t r ansmit t ed t o t he
st at ion (using ARP if necessar y).
Once t his det er minat ion is made, and t he packet is dest ined f or a l ocal r out e, t he
net wor k st at ion woul d check it s ARP t abl e t o f ind t he IP-t o-physical -addr ess mapping.
If one is f ound, t he packet is physical l y addr essed and t r ansmit t ed ont o t he net wor k.
The physical dest inat ion addr ess (l ocat ed in t he dat al ink header ) wil l be t hat of t he
r eceiving st at ion. If t he st at ions addr ess is not in t he ARP cache, t he ARP r equest
pr ocess is invoked.
Ref er r ing t o t he sl ide, endst at ion B and host A ar e l ocat ed on t he same net wor k.
Again, a point needs t o be br ought up her e: Ther e is a dif f er ence bet ween a r out ing
pr ot ocol and a r out abl e pr ot ocol . A r out abl e pr ot ocol is one t hat al l ows f or r out ing
such as Net War e (IPX) and TCP/IP. Net BIOS and LAT (a DEC t er minal /pr int er pr ot ocol )
ar e not r out abl e pr ot ocol s. RIP and OSPF, ar e r out ing pr ot ocol s whichenabl e t he
r out ing f unct ions t o wor k pr oper l y.
Dir ect Rout ing

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 94
Indirect Routing
Indir ect Rout ing
Occur s when t he sour ce and dest inat ion net wor k or subnet do not mat ch.
Sour ce wil l ARP f or a r out er and send t he dat agr am t o t he r out er .
The r out er wil l eit her f or war d t he packet dir ect l y t o t he dest inat ion or it
wil l f or war d it t o anot her r out er in t he pat h t o t he dest inat ion.
Rout er s decr ement t he TTL f iel d.
Rout er s f or war d t he packet based on t he IP addr ess and not t he MAC addr ess.
If t he sour ce and dest inat ion st at ions ar e on dif f er ent net wor ks, t hey must use t he
indir ect r out ing ser vices of a r out er . The t r ansmit t ing st at ion wil l addr ess t he physical
dest inat ion addr ess of t he packet t o t hat of t he r out er (using ARP, if necessar y, t o f ind
t he physical addr ess of t he r out er ) and submit t he packet t o t he r out er . Each
wor kst at ion may be abl e t o det er mine t he addr ess of it s cl osest r out er , or it can be
pr econf igur ed wit h t he addr ess of it s def aul t r out er . The r out er has t wo choices:
1. If t he dest inat ion net wor k indicat ed by t he addr ess in t he IP header is dir ect l y
at t ached t o t he r out er , it wil l f or war d t he packet dir ect l y t o t he dest inat ion
st at ion.
2. If t he dest inat ion net wor k indicat ed by t he addr ess in t he IP header is not
dir ect l y at t ached t o t he r out er , it must use t he ser vices of anot her r out er t o
f or war d t he packet and l et t hat r out er det er mine t he next hop pat h.
Not ice her e, t he dest inat ion physical addr ess is t hat of t he r out er and not t he f inal
dest inat ion st at ion. This t ype of r out ing is indir ect r out ing. The f inal dest inat ion IP
addr ess is embedded in t he IP header .
Sending a packet t o it s f inal dest inat ion might be accompl ished by using bot h dir ect and
indir ect r out ing. For exampl e, when a packet is t o be del iver ed acr oss an int er net , t he
or iginat ing st at ion wil l addr ess it t o t he r out er f or del iver y t o it s f inal net wor k. This
is indir ect r out ing. The or iginat or and dest inat ion may be separ at ed by mor e t han one
r out er . No mat t er whet her t he f inal dest inat ion net wor k ID is dir ect l y connect ed t o
t hat r out er or whet her t he packet must t r aver se a f ew r out er s t o r each it s f inal
dest inat ion, t he l ast r out er in t he pat h must use direct routing t o del iver t he packet t o
it s dest inat ion host .
Depending on t he Opt ions f iel d set t ings, it shoul d be not ed t hat t he or iginal IP
dat agr am, wil l not be al t er ed wit h t wo pr imar y except ions: t he TTL (Time t o Live) f iel d
and t he Cycl ic Redundancy Check f iel d. If an IP dat agr am is r eceived by a r out er and it
has not ar r ived at it s f inal dest inat ion, t he r out er wil l decr ement t he TTL f iel d. If TTL
> 0, it wil l f or war d t he packet based on r out ing t abl e inf or mat ion. The IP dat agr ams
header cont ent s wil l r emain t he same (wit h t he except ion of an er r or -det ect ion f iel d
known as t he Cycl ic Redundancy Check, or CRC). Since t he TTL f iel d changed, t he CRC
must be r ecal cul at ed t hr oughout al l t he net wor ks and r out er s t hat t he dat agr am
t r aver ses. Ot her wise, t he onl y al t er at ions t hat ar e made ar e t o t he dat al ink header s
and t r ail er s. The IP addr esses in t he IP header wil l r emain t he same, as t he dat agr am
t r aver ses any r out er s in t he pat h t o it s dest inat ion.
IP r out er s f or war d dat agr ams on a connect ionl ess basis and t her ef or e do not guar ant ee
del iver y of any packet . They oper at e at t he net wor k l ayer , which pr ovides best -ef f or t
or connect ionl ess dat a t r ansf er . Rout er s do not est abl ish sessions wit h ot her r out er s
on t he int er net . In f act , IP r out er s do not know of any wor kst at ions (nonr out er s) on
t heir subnet s.
These r out er s f or war d packet s based on t he net wor k addr ess of t he packet (in t he IP
header ) and not on t he physical addr ess (t he 48-bit addr ess f or br oadcast net wor ks) of
t he f inal dest inat ion (t he r eceiver ). When t he r out er r eceives t he packet , it wil l l ook
at t he f inal net wor k addr ess (embedded in t he IP header of t he packet ) and det er mine
how t o r out e t he packet . Rout er s onl y r out e packet s t hat ar e dir ect l y addr essed t o
t hem. They do not oper at e in pr omiscuous mode (wat ching al l LAN t r af f ic) f or
f or war ding dat agr ams.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 95
A Flowchart
The sl ide shows t he f l owchar t of t he r out ing pr ocess.
Bef or e compl et e conf usion t akes over her e, t her e ar e some ent it ies t hat need t o be
expl ained about t he IP l ayer t hat al l ow t he int er net t o oper at e. In ot her wor ds, when
a r out er r eceives a packet , how does it know wher e and how t o send t hese packet s? In
or der f or a packet t o be del iver ed t hr ough a r out er , t he r out er must know which pat h
t o del iver t he packet t o in or der f or t he packet t o r each it s f inal dest inat ion. This is
accompl ished t hr ough IP r out ing al gor it hms, which invol ves t wo st eps: maint aining a
t abl e of known r out es (net wor k number s), and l ear ning new r out es (net wor k number s)
when t hey become avail abl e.
A Fl owchar t

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 96
Routing ProtocolsDistance Vector
Inf or mat ion is kept in t he r out er t hat al l ows t o it t o know al l t he net wor ks or subnet s
in it s domain and t he pat h t o get t o t hose net wor ks. The inf or mat ion is about net wor ks
and t heir pat hs. This inf or mat ion is gr ouped t oget her int o a t abl ea t abl e is t he same
t hing as a t abl e in Micr osof t Wor d. It cont ains a gr ouping of l ike inf or mat ion t o be use
as a whol e. Ther e ar e t wo st andar d met hods f or buil ding t hese t abl es: dist ance vect or
and l ink st at e. Link st at e wil l be cover ed l at er . Dist ance vect or means t hat t he
inf or mat ion sent f r om r out er t o r out er is based on an ent r y in a t abl e consist ing of
<vect or , dist ance>. Vector means t he net wor k number and distance means what it cost s t o
get t her e. The r out er s exchange t his net wor k r eachabil it y inf or mat ion wit h each ot her
by br oadcast ing t heir r out ing t abl e inf or mat ion consist ing of t hese dist ance-vect or
ent r ies. This br oadcast is l ocal and each r out er is dependent on ot her r out er s f or
cor r ect cal cul at ion of t he dist ance.
Each ent r y in t he t abl e is a net wor k number (t he vect or ) and t he amount of r out er s
(dist ance) t hat ar e bet ween it (t he r out er ) and t he f inal net wor k (indicat ed by t he
net wor k number ). This dist ance is somet imes r ef er r ed t o as a metric. For exampl e, if t he
sour ce st at ion want s t o t r ansmit a packet t o a dest inat ion st at ion t hat is f our hops
away, t her e ar e pr obabl y f our r out er s separ at ing t he t wo net wor ks.
Any t ime a dat agr am must t r aver se a r out er (t her eby passing t hr ough a new net wor k
number ) it is consider ed a hop (met r ic). For RIP, t he maximum diamet er of t he int er net is
15 r out er s (hops). A dist ance of 16 is an indicat ion t hat t he net wor k is not r eachabl e. In
ot her wor ds, if t he net wor k is mor e t han 15 r out er s away, it is consider ed unr eachabl e.
Remember : This is RIP and RIP is an IGP, which is under one domain. The Int er net it sel f
encompasses many domains and t he diamet er of t he Int er net is much l ar ger t han 15 hops.
As shown in t he sl ide, each r out er wil l cont ain a t abl e wit h st ar t ing ent r ies of t hose
net wor ks t hat ar e dir ect l y at t ached t o it . For a r out er t hat has onl y t wo net wor k
connect ions (t her e ar e no ot her r out er s on t he int er net ), t he init ial ent r ies in t he
t abl e woul d l ook l ike t he f ol l owing:
Net wor k Met r ic Por t Age
134.4.0.0 1 1 XXX
134.3.0.0 1 2 XXX
Ther e ar e act ual l y mor e header ent r ies in a r out ing t abl e, but t he signif icant por t ions
ar e shown in t he sl ide. Fr om t his t abl e, we know t hat net wor ks 134.4.0.0 and 134.3.0.0
ar e dir ect l y connect ed t o t his r out er . Net wor k 134.4.0.0 is assigned t o por t 1 of t he
r out er and 134.3.0.0 is dir ect l y at t ached t o por t 2. It is r unning t he RIP pr ot ocol , and
xxx indicat es how l ong t he r out e has bef or e it is del et ed f r om t he t abl e.
Rout ing Pr ot ocol sDist ance Vect or

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 97
Updating Other Routers (Distance Vectors)
Updat ing Ot her Rout er s (Dist ance Vect or s)
Upon init ial izat ion, each r out er r eads it s pr econf igur ed IP addr ess and met r ic
(cost in hops) of al l it s act ive por t s.
Each r out er t r ansmit s a por t ion of it s r out ing t abl e (net wor k ID, met r ic) t o
each neighbor r out er .
Each r out er uses t he most r ecent updat es f r om each neighbor .
Each r out er uses t he updat e inf or mat ion t o cal cul at e it s own shor t est pat h
(dist ance in hops) t o a net wor k.
Tabl es ar e updat ed onl y:
If t he r eceived inf or mat ion indicat es a shor t er pat h t o t he dest inat ion
net wor k.
If t he r eceived updat e inf or mat ion indicat es a net wor k is no l onger
r eachabl e.
If a new net wor k is f ound.
Some but not al l t he ent r ies of t he r out er s r out e t abl e ar e sent out t he por t s t o
updat e ot her r out er s as t o t he net wor ks t hat t his r out er knows about . Ther e ar e a f ew
except ions, which wil l be expl ained in a moment . These updat es ar e not f or war ded by
any r out er , meaning t he updat es st ay on t he net wor k on which t hey or iginat ed. Any
r out er t hat is l ocat ed on t he same net wor k wil l r eceive t he packet , r ead t he r out ing
t abl e dat a, and updat e it s t abl e if needed. Al l par t icipat ing r out er s wil l accompl ish
t his. In ot her wor ds, al l r out er s f or war d t heir t abl es out each act ive por t . As each
t abl e is r eceived, t he r out er s ar e buil ding a pict ur e of t he net wor k. As each br oadcast is
t r ansmit t ed, mor e and mor e inf or mat ion is being pr opagat ed t hr oughout t he net wor k.
Event ual l y, al l r out er s wil l know of al l net wor ks on t heir int er net .
Ther e ar e t hr ee possibil it ies t hat can cause a r out er t o updat e it s exist ing t abl e based
on just -r eceived inf or mat ion:
1. If t he r eceived t abl e cont ains an ent r y t o a net wor k wit h a l ower hop count ,
it wil l replace its entry wit h t he new ent r y cont aining t he l ower hop count .
2. If a net wor k exist s in t he just -r eceived t abl e t hat does not exist in it s own
t abl e, it wil l add the new entry.
3. If t he r out er f or war ds packet s t o a par t icul ar net wor k t hr ough a specif ied
r out er (indicat ed by t he next -hop r out er addr ess) and t hat r out er s hop count t o
a net wor k dest inat ion changes, it wil l change it s ent r y. In ot her wor ds, if r out er
A nor mal l y r out es dat a f or a net wor k X t hr ough r out er B, and r out er Bs hop-
count ent r y t o t hat net wor k changes, r out er A changes it s ent r y.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 98
A Bigger Update
This sl ide shows what happens when r out er A submit s it s r out ing t abl e out of it s por t
connect ed t o net wor k 2. This sl ide assumes al l r out er s ar e newl y init ial ized. (For
simpl icit y, t he sl ide shows t he updat ing t hr ough one por t onl y. In r eal it y, r out ing
t abl es ar e submit t ed out al l por t s of a r out er , wit h a f ew r est r ict ions on which ent r ies
of t he t abl e get t r ansmit t ed.)
Rout er A t r ansmit s it s t abl e cont aining t wo net wor ks: Z and Y. Each of t hese net wor ks
is one hop away (t hey ar e dir ect l y connect ed). Rout er B wil l r eceive t his packet and
wil l add 1 t o each hop-count ent r y in t he r eceived t abl e. (This is accompl ished assuming
t he RIP cost assigned t o t hat por t of r out er B is 1. The conf igur ed hop count coul d be
set t o somet hing el se.)
Rout er B examines it s t abl e and not ices t hat it does not have an ent r y f or net wor k Z. It
wil l add t his ent r y t o it s t abl e as: net wor k 1, avail abl e t hr ough por t 1, t wo hops away.
It wil l t hen check t he next ent r y. Net wor k Y wil l not be added, f or r out er B al r eady
has net wor k 2 in it s t abl e wit h a cost of 1. Since t he incoming t abl e r epor t s net wor k Y
has a cost of 2, r out er B wil l ignor e t his ent r y. (Ther e ar e r ul es t hat wil l pr event
r out er A f r om sending out inf or mat ion about net wor k 2, which wil l be discussed l at er .)
Once it s t abl e is updat ed, r out er B wil l t r ansmit it s t abl e out it s por t s ever y 30 seconds
(again, f or simpl icit y onl y one r out er updat e is being shown). Rout er C wil l r eceive t his
t abl e f r om r out er B and wil l per f or m t he same st eps as r out er B. Event ual l y, al l
inf or mat ion about al l net wor ks on t he int er net wil l be pr opagat ed t o al l r out er s.
A Bigger Updat e

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 99
IP Routing Tables
The sl ide shows an exampl e of what is in a r out ing t abl e. This is a dist ance-vect or
r out ing t abl e, not a l ink-st at e r out ing t abl e. OSPF woul d have a dif f er ent kind of
t abl e. In t his t abl e, it is impor t ant t o not e t he net wor k number , hops t o t hat net wor k
number , and t he next r out er in t he pat h t o t hat net wor k.
Rout ing t abl e f iel ds var y, depending on t he updat e mechanism used. The f ol l owing
t abl e is a sampl e of a r out ing t abl e used by t he r out ing inf or mat ion pr ot ocol (RIP) f or
t he IP pr ot ocol .
The r out e t abl e ent r ies on t he sl ide ar e def ined as f ol l ows:
Net wor k number . A known net wor k ID.
Next r out er t o del iver t o. The next r out er t hat t he packet shoul d be del iver ed t o if
t he dest inat ion net wor k is not dir ect l y connect ed. A dir ect l y connect ed net wor k is one
t hat is physical l y connect ed t o t he r out er , since most r out er s t oday have mor e t han
t wo connect ed net wor ks.
Hops. This is t he met r ic count of how many r out er s t he packet must t r aver se bef or e
r eaching t he f inal dest inat ion. A 1 indicat es a l ocal r out e.
Lear ned f r om. Since many r out ing al gor it hms may exist in a r out er (i.e., RIP, OSPF, and
EGP may exist in t he same r out er ), t her e is usual l y an ent r y in t he t abl e t o expl ain how
t he r out e was acquir ed.
Time l ef t t o del et e. The amount of t ime l ef t bef or e t he r out e wil l be del et ed f r om
t he t abl e.
Por t . The physical por t on t he r out er f r om which t he r out er r eceived inf or mat ion
about t his net wor k.
IP Rout ing Tabl es

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 100
The Routing Information Protocol (Version 1)
Rout ing t abl es al l ow r out er s t o det er mine t he next hop pat h f or a r eceived dat agr am.
But what buil ds t hose t abl es? Dynamic updat ing is t he pr ocess by which r out er s updat e
each ot her wit h r eachabil it y inf or mat ion. Bef or e t he advent of dynamic updat es of
r out ing t abl es, most commer cial vendor s suppor t ed manual updat es f or t heir r out er
t abl es. This meant manual l y ent er ing net wor k number s, t heir associat ed dist ances, and
t he por t number s int o t he r out er t abl e. The Int er net was t hen known as t he ARPAnet
and it empl oyed a r out ing updat e scheme known as t he Gat eway Inf or mat ion Pr ot ocol
and l at er t he Gat eway t o Gat eway Pr ot ocol (GGP). This is beyond t he scope of t his book
and is not used anymor e. Independent r out er vendor s did not have t hat many r out er s
and subnet s t o updat e, so pl acing a manual ent r y in t he r out er s was not al l t hat bad.
As net wor ks gr ew l ar ger , t his became a cumber some way of buil ding t abl es.
Commer cial l y, RIP was t he pr ot ocol t hat enabl ed aut omat ic updat es of r out er t abl es.
The RIP al gor it hm is based on t he dist ance-vect or al gor it hms just descr ibed. RIP pl aced
t he f undament al s of dist ance-vect or in a simpl e r out ing al gor it hm. Impl ement at ions of
t hese pr ot ocol s wer e f ir st f ound on t he ARPAnet in 1969 using t he Gat eway
Inf or mat ion Pr ot ocol . However , it was f ir st devised by Xer ox Cor por at ion as t he
r out ing al gor it hm used by Int er net Dat agr am Pr ot ocol of XNS.
RFC 1058 f ir st def ined RIP f or TCP/IP, and it was f or mal l y adopt ed by t he IAB in 1988.
Al t hough it was not pr imar il y int ended as the r out ing al gor it hm f or TCP, it gained
widespr ead accept ance when it became embedded int o t he Ber kel ey 4BSD Unix oper at ing
syst em t hr ough a ser vice known as r out ed (pr onounced r out e dd is f or t he daemon
pr ocess t hat r uns t he pr ot ocol in Unix). Pl acing t he f unct ions of RIP int o an RFC
al l owed f or int er oper abil it y and det ail ed cer t ain f unct ions.
The Rout ing Inf or mat ion Pr ot ocol (Ver sion 1)
Wit h RIP inf or mat ion, any r out er knows t he l engt h of t he shor t est pat h (not
necessar il y t he best ) f r om each of it s neighbor r out er s (r out er s l ocat ed on t he same
net wor k) t o any ot her dest inat ion. Ther e ar e many def iciencies in t his pr ot ocol and
t hey ar e discussed at t he end of t his sect ion.
The RIP packet is quit e simpl e. The sl ide shows t he RIP header and dat a encapsul at ed in
an Et her net packet . The RIP dat a is t he t abl e inf or mat ion one r out er shar es wit h
anot her .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 101
RIP Operational Types
RIP Oper at ional Types
RIP can oper at e in eit her ACTIVE or PASSIVE mode.
Act ive means t hat it buil ds r out ing t abl es and r esponds t o RIP r equest s.
Passive means t hat it can buil d a r out ing t abl e f or it s own use, but it does not
r espond t o any RIP r equest s.
Most wor kst at ions (PCs) use a def aul t gat eway (i.e., r out er ) and not a r out ing
updat e pr ot ocol l ike RIP.
Ther e ar e t wo t ypes of RIP packet s t hat t r aver se a net wor k (indicat ed by t he command
f iel d, shown next ): one t o r equest inf or mat ion and t he ot her t o give inf or mat ion (a
r esponse packet ). A r esponse packet is gener at ed f or a r equest packet and is used f or
per iodic RIP updat es. Most RIP packet s t hat t r aver se a l ocal net wor k wil l be t he
per iodic RIP t abl e updat es. Does RIP oper at e in a wor kst at ion? The answer is, yes and
no. Some wor kst at ions impl ement RIP. Windows NT and Unix bot h use RIP; however ,
most simpl e wor kst at ions such as Windows 95 do not (t hey have a def aul t gat eway). If a
wor kst at ion does impl ement RIP, it is usual l y in what is known as passive mode, which
means it can r eceive and pr ocess updat es, but cannot r espond t o RIP r equest s or
br oadcast it s t abl e.
In passive mode, RIP l ist ens onl y f or RIP updat es. (It may buil d it s own t abl es or it may
not . If it does, it wil l not br oadcast t hese t abl es.) It wil l buil d a t abl e so t hat it wil l
not have t o r equest inf or mat ion f r om ot her r out er s on t he net wor k. Passive end is used
f or nonr out ing net wor k st at ions. These devices have no r eason t o br oadcast updat es,
but have ever y r eason t o l ist en f or t hem. Today, most DOS PC comput er s wil l use a
concept of a def aul t gat eway, expl ained l at er . Even Windows 95 uses a def aul t
gat eway if pr ompt ed. It can buil d a r out ing t abl e, but Windows 95 is not RIP-enabl ed.
The RIP passive pr ot ocol al l ows t he host t o maint ain a t abl e of t he shor t est r out es t o a
net wor k and designat es which r out er t o send t he packet s t o. This consumes a
consider abl e amount of RAM f or bot h t he t abl e and t he al gor it hm. Wit hout it , TCP/IP
r equir es a def aul t gat eway ent r y, which specif ies t hat when a packet is dest ined f or a
r emot e net wor k, t he host must submit t he packet t o a specif ied gat eway f or pr ocessing,
even if t his gat eway is not t he shor t est pat h t o t hat net wor k. Passive impl ement at ions
add no over head t o t he net wor k, f or t hey l ist en onl y t o r out ing t abl e updat es t hat ar e
on t he net wor k. Wit hout passive RIP, t hese devices have t o maint ain t heir own t abl es or
impl ement a def aul t r out e.
Most wor kst at ions do not invoke act ive ver sions of t he RIP pr ot ocol They do not buil d
t abl es and keep t r ack of net wor ks. To communicat e wit h a r out er , wor kst at ions
gener al l y use t heir def aul t gat eway par amet er . This is f or simpl icit y. Higher -power ed
wor kst at ions, such as Sun SPARC wor kst at ions, can buil d and maint ain r out ing t abl es.
However t he ear l y impl ement at ions of ICP/IP wer e not power f ul and r equir ed a simpl e
met hod.Remember , RIP packet s do not l eave t heir l ocal net wor k. Al l par t icipant s in t he
RIP pr ot ocol (f or exampl e, r out er s) wil l r eceive t he packet , updat e t heir t abl es if
necessar y, and t hen discar d t he packet . They wil l comput e t he r eachabil it y of net wor ks
based on adding a cost (usual l y 1) t o t he just -r eceived t abl es or count ent r y, and t hen
br oadcast t heir t abl es out t heir por t s (usual l y being mindf ul of a pr ot ocol named split
horizon, which is expl ained a l it t l e l at er ).

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 102
RIP Field Descriptions
The f iel ds in t he RIP packet s ar e:
Command Descr ipt ion
1 Request f or par t ial or f ul l
r out ing t abl e inf or mat ion
2 Response packet cont aining a
r out ing t abl e
34 Tur n on (3) or of f (4) t r ace
mode (obsol et e)
5 Sun Micr osyst ems int er nal
use
Ver sion. Used t o indicat e t he ver sion of RIP. Cur r ent l y set t o 1 f or RIP ver sion 1.
Famil y of net x. Used t o show t he diver sit y of t he RIP pr ot ocol and t o indicat e t he
pr ot ocol t hat owns t he packet . It wil l be set t o 2 f or IP. Since XNS coul d possibl y be
r unning on t he same net wor k as IP, t he RIP f r ames woul d be simil ar . This shows t hat t he
same RIP f r ame can be used f or mul t ipl e pr ot ocol suit es. Appl eTal k, Novel l Net War es
IPX, XNS, and TCP/IP al l use t he RIP packet . Each packet is changed a l it t l e f or each
pr ot ocol .
IP addr ess. Indicat es t he IP addr ess of a specif ic dest inat ion net wor k. This woul d be
f il l ed in by t he r equest ing st at ion. An addr ess of 0.0.0.0 indicat es t he def aul t r out e
(expl ained l at er ). The addr ess f iel d needs onl y 4 byt es of t he avail abl e 14 byt es, so al l
ot her byt es must be set t o 0. This wil l be expl ained in RIP Ver sion 2.
If t his is a r equest packet and t her e is onl y one ent r y, wit h t he addr ess f amil y ID of 0
and a met r ic of 1, t hen t his is a r equest f or t he ent ir e r out ing t abl e.
As f or t he dist ance-t o-net wor k f iel d, onl y t he int eger s of 1 t o 16 ar e al l owed. An
ent r y of 16 in t his f iel d indicat es t hat t he net wor k is unr eachabl e.
The next ent r y in t he f iel d woul d st ar t wit h t he IP addr ess f iel d t hr ough t he met r ic
f iel d. This woul d be r epeat ed f or each t abl e ent r y of t he r out er t o be br oadcast . The
maximum size of t his packet is 512 byt es.
The RIP pr ot ocol r el ies on t he t r anspor t -l ayer pr ot ocol of t he User Dat agr am Pr ot ocol
(UDP, discussed in t he next sect ion on t r anspor t -l ayer pr ot ocol s). In t his wil l be t he
specif icat ion f or t he l engt h of t he RIP packet . Al so, f or t hose int er est ed, RIP oper at es
on UDP por t number 520 (por t number s ar e discussed in t he UDP sect ion).
RIP Fiel d Descr ipt ions

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 103
Default Router and Gateways
On a TCP/IP net wor k, t her e is a concept known as t he default route. Except f or
pr opr iet ar y impl ement at ions, t his is not par t of any ot her net wor k pr ot ocol (XNS,
Appl eTal k, IPX, et c.). The def aul t r out e can be maint ained in t wo pl aces: t he r out er and
t he endst at ion.
For an endst at ion t hat does not suppor t t he act ive or passive f unct ions of t he RIP
pr ot ocol , t her eby al l owing it t o f ind a r out e dynamical l y, t he def aul t r out er
(commonl y cal l ed a default gateway) is assigned t o it . This is t he 32-bit addr ess of t he
r out er t he wor kst at ion shoul d r out e t o if r emot e r out ing is necessar y. The IP l ayer in
t he endst at ion woul d det er mine t hat t he dest inat ion net wor k is not l ocal and t hat
t he ser vices of a r out er must be used. Inst ead of impl ement ing t he RIP pr ot ocol , t he
endst at ion may submit t he packet t o t he def aul t r out er as assigned by t he def aul t
r out e number . The r out er wil l t ake car e of ensur ing t he packet wil l r each it s f inal
dest inat ion. If t hat r out er does not have t he best r out e, it wil l send a message (using
t he ICMP pr ot ocol ) t o t he endst at ion t o inf or m it of a bet t er r out e. This wil l be
expl ained l at er .
A r out er may al so be assigned a def aul t r out e. It is indicat ed as 0.0.0.0 in it s r out ing
t abl e. Ther e is no subnet mask associat ed wit h it . This is impl ement ed f or when a r out er
r eceives a packet and does not have t he net wor k number in it s t abl e. The r out er wil l
f or war d t he packet t o anot her r out er f or which it has an assigned def aul t r out e. This
means t hat when a r out er has r eceived a packet t o r out e, and it s t abl e does not cont ain
t he net wor k number indicat ed in t he r eceived packet , it wil l f or war d t he packet t o it s
def aul t r out er , hoping t hat t he def aul t r out er wil l have t he net wor k number in it s
t abl e and wil l be abl e t o pr oper l y f or war d t he packet . The def aul t r out er wil l r eceive
t he packet and, if t he net wor k number is in it s t abl e, it wil l f or war d t he packet . If t he
net wor k number is not in it s t abl e wit h t he best r out e, it , t oo, may have a def aul t
r out er , and it wil l f or war d t he packet t o t hat r out er . If t her e is no r out e and t her e is
not anot her def aul t r out e, t he l ast r out er wil l send a cont r ol message (t hr ough ICMP)
back t o t he or iginat ing st at ion indicat ing it coul d not f or war d t he packet .
The pr obl em wit h def aul t r out es in wor kst at ions is t hat a wor kst at ions def aul t r out er
may go down and t he wor kst at ion wil l not know if t her e is anot her r out er on t he
net wor k. The net wor k number may change or t her e may be a bet t er pat h f or t he
wor kst at ion t o t ake. The def aul t gat eway al l ows f or t he el iminat ion of r out ing t abl es
in t he net wor k st at ion and r out er s by al l owing gr oups of net wor ks t o become avail abl e
t hr ough t he def aul t r out e.
Def aul t Rout er and Gat eways

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 104
Disadvantages of the RIPv1 Protocol
As not ed ear l ier , t he accept ance of RIP in t he Int er net communit y was based on it s
impl ement at ion int o t he popul ar Ber kel ey 4BSD Unix oper at ing syst em t hr ough a
pr ocess known as routed (Pr onounced Rout e - d, t wo wor ds). Unf or t unat el y, it was
impl ement ed bef or e t he r apid gr owt h of TCP/IP. RIP had many disadvant ages t hat wer e
not consider ed l imit ing at t he t ime it became accept ed. Bef or e RIP was impl ement ed, some
r out er t abl es had t o be const r uct ed manual l y. RIP al l owed t hese t abl es t o be updat ed
dynamical l y, which was a r eal advant age. The disadvant ages f ol l ow.
RIP, based on a simpl e hop count , under st ands onl y t he shor t est r out e t o a dest inat ion,
which may not be t he f ast est r out e. RIP under st ands onl y hop count s. For exampl e,
t her e may be t wo pat hs t o a dest inat ion: one t hat t r aver ses t wo T1 l ines (t hr ee hops)
and anot her t hat has t wo hops, but is a 9600 baud ser ial l ine. RIP woul d pick t he 9600
baud l ine, because it s shor t er (t wo hops). Ther e ar e var iat ions of RIP t hat al l ow t he
net wor k administ r at or t o assign an ar bit r ar y RIP hop count or cost t o a r out e t o
disal l ow f or t his. This sol ves one pr obl em, but cr eat es anot her . This incr ement ed RIP
number adds t o t he upper l imit of a 15-hop diamet er in RIP, which cr eat es anot her
pr obl em. The number of hops t hat a net wor k may be dist anced f r om any net wor k st at ion
is l imit ed t o 15a hop count of 16 is consider ed unr eachabl e. If you add addit ional hops
t o a pat h, you decr ease t he t ot al number of r out er s al l owed in a pat h.
Disadvant ages of t he RIPv1 Pr ot ocol
RIPv1 onl y under st ands t he shor t est r out e t o a dest inat ion, based on a simpl e
count of r out er hops.
It depends on ot her r out er s f or comput ed r out ing updat es.
Rout ing t abl es can get l ar ge and t hese ar e br oadcast ed ever y 30 seconds.
Dist ances ar e based on hops, not on r eal cost s (such as t he speed of a l ink).
Pat ched wit h spl it hor izon, poison r ever se, hol d-down t imer s, t r igger ed
updat es.
It cont inues t o be a r out er -t o-r out er conf igur at ion. One r out er is f ul l y
dependent on t he next r out er t o impl ement t he same opt ions.
Fix one pr obl em and ot her s appear .
Wit h RIP, r out ing t abl e updat es ar e onl y as accur at e as t he r out er t hat submit t ed
t hem. If any r out er made a comput at ional er r or in updat ing it s r out ing t abl e, t his er r or
wil l be r eceived and pr ocessed by al l ot her r out er s.
What may al so be appar ent is t he f act t hat t he r out ing t abl es coul d get ver y l ar ge. If
t he net wor k consist ed of 300 dif f er ent net wor ks (not uncommon in l ar ger
cor por at ions), each r out ing t abl e of ever y r out er woul d have 300 ent r ies. Since RIP
wor ks wit h UDP (connect ionl ess t r anspor t -l ayer ser vice), t he maximum dat agr am size of
a RIP packet is 512 byt es (576 byt es, incl uding al l media header s). This al l ows f or a
maximum of 25 <net wor k number , dist ance> combinat ions in each packet . Ther ef or e, it
woul d t ake 13 packet s f r om each r out er t o br oadcast it s r out ing t abl e t o al l ot her
r out er s on al l t he l ocal net wor ks in t he int er net . This woul d be br oadcast ever y 30
seconds by each of t he 300 r out er s. Al l t his, and t he possibil it y t hat not hing had
changed f r om t he pr evious updat e! This is an unnecessar y consumpt ion of bandwidt h,
especial l y over sl ow-speed ser ial l ines.
This l eads t o t he second disadvant age. RIPv1 nor mal l y br oadcast s (dat al ink physical
addr ess of al l FFs) t o t he net wor k ever y 30 seconds, even acr oss sl ower -speed ser ial
l inks. This makes t he dat al ink pass t he packet up t o t he upper -l ayer pr ot ocol s on al l
st at ions on t he net wor k, even if t he st at ions do not suppor t RIP.
Ever y t ime we sol ved one pr obl em, anot her popped up.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 105
Scaling with RIP
Her e is wher e RIP r eal l y shows of f t he l imit at ions. Tr y and buil d a l ar ge net wor k
based on RIP. RIP was designed f or smal l st abl e net wor ks. It st at es t his in t he Xer ox
document at ion. RIP does not handl e gr owt h ver y wel l . This pr obl em is t wof ol d. The
f ir st l imit at ion is t hat a dest inat ion net wor k may be no mor e t han 15 hops away in
diamet er (a dist ance of 16 in any r out ing t abl e indicat es t he net wor k is unr eachabl e).
Car ef ul pl anning is needed t o impl ement l ar ge-scal e net wor ks based on t he RIP
pr ot ocol .
The ot her scal ing pr obl em is t he pr opagat ion of r out ing inf or mat ion. Four t er ms need t o
be under st ood her e, f or t hey ar e used quit e f r equent l y: split horizon, hold-down timer,
poisoned reverse, and triggered updates.
Ref er t o t he sl ide. Wit h r out er A dir ect l y at t ached t o net wor k z, it adver t ises t hat
r out e t hr ough all it s por t s as a dist ance of 1 (what ever t he RIP-assigned cost of t he por t
t hat at t aches t o t hat net wor k is). Rout er B r eceives t his and updat es it s t abl e as
net wor k z1 wit h a dist ance of 2. Rout er B t hen br oadcast s it s t abl e (at t he 30-second
updat e t imer ) and r out er C r eceives t his and updat es it s t abl e as net wor k n wit h a
dist ance of 3. Not ice t hat al l r out er s br oadcast al l t he inf or mat ion in t heir t abl es
t hr ough al l por t s (even t he por t s f r om which t hey r eceived t he updat e).
Why woul d r out er B br oadcast a r eachabil it y of net wor k z when r out er A al r eady has
a dir ect at t achment t o it ? Woul dnt t his conf use r out er A if net wor k z is l ocat ed?
Nor mal l y it woul d, but r emember t hat t he onl y changes t hat a r out er wil l make t o it s
t abl es is when t he hop-count dist ance is l ower , is a new ent r y, or if t he next hop r out er
pat h t aken t o a net wor k changes it s hop count . Since t hat hop count is higher , r out er A
wil l simpl y ignor e t hat par t icul ar ent r y in t he updat e t abl e.
Using t he or iginal al gor it hm, a ser ious pr obl em occur s when r out er A l oses it
r eachabil it y t o net wor k z. It wil l updat e it s t abl e ent r y f or t hat net wor k wit h a
dist ance of 16 (16 indicat es not r eachabl e), but wil l wait t o br oadcast t his inf or mat ion
unt il t he next schedul ed RIP updat e. So f ar , so good, but if r out er B br oadcast s it s
r out ing t abl e bef or e r out er A (not ice t hat not al l r out er s br oadcast t heir t abl es at
t he same t ime), r out er A wil l t hen see t hat r out er B has a shor t er pat h t o net wor k z
t han it does (a dist ance of 2 f or r out er B ver sus a dist ance of 16 f or r out er A). Rout er A
wil l change it s ent r y f or net wor k z. Now, r out er A, on it s next RIP updat e br oadcast ,
wil l announce t hat it has a pat h t o net wor k z wit h a dist ance of 3 (2 f r om t he t abl e
ent r y r eceived f r om r out er B pl us 1 t o r each r out er B). Ther e is now a l oop bet ween
r out er s A and B. A packet dest ined f or net wor k z wil l be passed bet ween r out er s A and
B unt il t he TTL count er is 0. When r out er B r eceives a packet dest ined f or net wor k z, it
wil l f or war d t he packet t o r out er A; r out er A wil l f or war d it back t o r out er B; and
t his wil l cont inue unt il t he TTL f iel d r eaches 0. This is known as looping. The RIP
pr ot ocol wor ks ext r emel y wel l in a st abl e envir onment (an envir onment wher e r out er s
and t heir net wor ks r ar el y change). The pr ocess of cl ear ing out dead r out es and
pr oviding al t er nat e pat hs is known as convergence.
Scal ing wit h RIP
Even f ut ur e RIP updat es wil l not quickl y f ix t he conver gence in t his case. Each updat e
(ever y 30-second def aul t ) wil l add 1 t o t he t abl e ent r y, and it wil l t ake a f ew updat es
t o out dat e t he ent r y in t hese r out er s. This is known as slow convergence, and it causes
er r or s in r out ing t abl es and r out ing l oops t o occur . What if you had a net wor k
diamet er of 15 r out er s and each was exact l y opposit e on t he t imer t o br oadcast it s
updat e? In ot her wor ds, when one r out er br oadcast s it s t abl e, t he r eceiving r out er just
f inished it s br oadcast . The l ost r out e coul d t ake many minut es t o updat e t hose r out er s
at t he end of t he net wor k.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 106
Routers and Subnet Masks
Fr om t he pr evious discussion on choosing a subnet mask, a r out ing pr ot ocol known as
RIP ver sion 1, or RIP1, r equir es t hat a subnet mask be unif or m acr oss an ent ir e net wor k
ID. An addr ess assignment of 150.1.0.0 must cont ain one net wor k mask. The f aul t her e is
t he inabil it y of RIP1 t o suppl y a subnet mask ent r y in it s r out ing updat es t o be consumed
by ot her r out er s. Ther ef or e, RIP1 is f or ced t o make assumpt ions. It assumes t hat t he mask
is t he same f or t he l ear ned subnet of t he same net wor k ID as it s conf igur ed por t s. This
means t hat if a subnet r out e is l ear ned on a por t t hat has t he same net wor k ID as t he
por t , RIP wil l appl y t he assigned mask t o t hat l ear ned r out e as t he por t . If t he l ear ned
subnet r out e has a dif f er ent net wor k ID t han t he por t it l ear ned t he subnet r out e
f r om, it assumes t he l ear ned subnet r out e is not subnet t ed and f al l s back t o appl ying
t he nat ur al mask f or t hat cl ass.
Her es an exampl e: A r out er has t wo por t s. Por t 1 is assigned an addr ess of 150.1.1.1 wit h
a subnet mask of 255.255.255.0. Por t 2 has an addr ess of 160.1.1.1 wit h a subnet mask of
255.255.255.0. If t he r out er l ear ns of a r out e 150.1.3.0, t hen it wil l appl y t he 24-bit
subnet mask because it has t he same net wor k ID as it s por t . However , if t he r out er
l ear ns a subnet r out e of 175.1.6.0, t his net wor k ID is not on eit her one of it s por t s and it
wil l appl y a nat ur al subnet mask of 255.255.0.0 t o t hat addr ess bef or e updat ing it s
t abl e. That is f or l ear ned r out es.
How about r out ing updat es? When does a r out er appl y t he subnet mask t o a r out e and
t hen incl ude it in t he r out ing updat e? The same r ul e appl ies. Using t he net wor k number s
f r om t he pr eceding exampl e, when t he r out er woul d l ike t o br oadcast it s t abl e, it wil l
appl y t he subnet mask of 255.255.255.0 t o t he l ear ned r out e of 150.1.3.0 when it sends it s
updat e out Por t 1. However , it wil l send t he addr ess of 150.1.0.0 when sending t he
updat e out Por t 2. Por t 2 has a dif f er ent net wor k ID associat ed wit h t hat por t and,
t her ef or e, t he nat ur al mask is appl ied bef or e sending out t he t abl e.
This is why RIP1 suppor t s onl y one subnet mask f or net wor k ID.
The next sect ion gives mor e exampl es of addr ess assignment and Var iabl e-Lengt h Subnet
Masks (VLSM).
Rout er s and Subnet Masks

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 107
RIP Fixes
RIP Fixes
Spl it Hor izonRul e st at es t hat a r out er wil l not r ebr oadcast a l ear ned
r out e back over t he int er f ace f r om which t he r out e was l ear ned.
Hol d-Down Timer Rul e st at es t hat when a r out er r eceives inf or mat ion
about a net wor k t hat is unr eachabl e, t he r out er must ignor e al l subsequent
inf or mat ion about t hat net wor k f or a conf igur abl e amount of t ime.
Poisoned Rever se and t r igger ed updat esRul e st at es t hat a r out er is al l owed
t o r ebr oadcast a l ear ned r out e over t he int er f ace f r om which it l ear ned it , but
t he met r ic is set t o 16. A t r igger ed updat e al l ows a r out er t o br oadcast it s
t abl e when a net wor k is f ound t o be down.
To over come t he l imit at ions, a f ew r ul es wer e added t o t he IP RIP al gor it hm:
Spl it hor izon. Impl ement ed by ever y pr ot ocol t hat uses a var iat ion of RIP (Appl eTal k,
IPX, XNS, and IP), t his st at es t hat a r out er wil l not br oadcast a l ear ned r out e back
t hr ough a por t f r om which it was r eceived. Ther ef or e, r out er B wil l not br oadcast t he
ent r y of net wor k z back t o r out er A. This keeps r out er B f r om br oadcast ing t he
r eachabil it y of net wor k z back t o r out er A, t her eby el iminat ing t he possibil it y of a
l ower hop count being int r oduced when net wor k z becomes disabl ed. The ent r y in
r out er Bs updat e t o r out er A woul d not incl ude an ent r y f or net wor k z.
Hol d-down t imer . This r ul e st at es t hat once a r out er r eceives inf or mat ion about a
net wor k t hat cl aims a known net wor k is unr eachabl e, it must ignor e al l f ut ur e updat es
t hat incl ude an ent r y (a pat h) t o t hat net wor k (t ypical l y, f or 60 seconds). Not al l
vendor s suppor t t his in t heir r out er s. If one vendor does suppor t it and anot her does
not , r out ing l oops may occur .
Poison r ever se and t r igger ed updat es. These ar e t he l ast t wo r ul es t hat hel p t o
el iminat e t he sl ow conver gence pr obl em. They st at e t hat once t he r out er det ect s a
disabl ed net wor k connect ion, t he r out er shoul d keep t he pr esent ent r y in it s r out ing
t abl e and t hen br oadcast net wor k unr eachabl e (met r ic of 16) in it s updat es. These
r ul es become ef f icient when al l r out er s in t he int er net par t icipat e using triggered
updates, which al l ow a r out er t o br oadcast it s r out ing t abl e immediat el y f ol l owing
r eceipt of t his net wor k down inf or mat ion. The t wo most common ar e split horizon and
poison reverse.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 108
Split Horizon Demonstrated
In t he sl ide, t her e ar e t hr ee r out er s, l abel ed A, B, C, and f our subnet s, l abel ed W, X, Y,
Z. Upon st ar t up, t he r out er s l ear n of t heir immediat e subnet s. Rout er A l ear ns about
subnet s Y and Z. Rout er B l ear ns about subnet s X and Y. Rout er C l ear ns about subnet s
W and X. The r out er s may or may not aut omat ical l y br oadcast t heir t abl es out af t er
init ial izat ion (t his is vender independent ). Rout er C t r ansmit s it s t abl e cont aining
subnet s W and X. It wil l t r ansmit t his inf or mat ion out t he por t s connect ing t o subnet s
W and X. Rout er B wil l t r ansmit it s t abl e cont aining subnet X and Y out bot h of it s
por t s, and r out er A wil l t r ansmit it s t abl e cont aining subnet s Y and Z out bot h of it s
por t s. Al l of t he cost s in t hese t abl es ar e set t o 1. So f ar , so good.
Rout er C picks up t he inf or mat ion t hat r out er B t r ansmit t ed out and makes some
decisions. It wil l add t o each ent r y t he cost associat ed wit h t he por t on which it
r eceived t he inf or mat ion. In t his case, t hat por t was assigned a cost of 1. Ther ef or e, it
now has t wo ent r ies in t he r eceived t abl e, each wit h a cost of 2. It t hen compar es it t o
it s t abl e. It al r eady has a ent r y f or subnet X and it has a cost of 1, so it discar ds t hat
inf or mat ion. The next ent r y is f or subnet Y wit h a cost of 2. It does not have t hat
ent r y, so it wil l add t his ent r y t o it s t abl e wit h a cost of 2. Rout er C f igur es it is now
compl et e. Event ual l y, r out er C wil l updat e it s t abl e wit h t he ent r y f or subnet Z
(pr opagat ed by r out er B af t er r out er B r eceived t his inf or mat ion). Rout er C now has
t he ent r ies in it s t abl e of subnet Z, cost 3; subnet Y, cost 2; subnet X, cost 1; and subnet
W, cost 1).
Spl it Hor izon Demonst r at ed
The per iodic t imer has expir ed (ever y 30 seconds) and r out er C is r eady t o br oadcast it s
t abl e. Out t he por t associat ed wit h subnet W, it wil l l ist t he ent r ies f or subnet s W, X,
Y, and Z. However , on t he por t associat ed wit h subnet X, it wil l onl y incl ude t hose
ent r ies f or subnet X (some r out er s do not incl ude t his ent r y if t hey know of anot her
r out er on t his segment ) and subnet W. It wil l not incl ude t he ent r ies f or subnet s Y and
Z. This is known as spilt horizon. The r ul e f or spl it hor izon is not t o r ebr oadcast a known
r out e back over t he por t t hat t he r out er l ear ned it on. Poisoned reverse al l ows f or t he
net wor k number t o be r ebr oadcast out , but it wil l incl ude a 16 in t he hop count so no
ot her r out er can updat e it s t abl es. This is used t o avoid r out ing l oops in oddl y l ooped
net wor ks.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 109
RIP Version 2
In November , 1994, RIP was modif ied wit h some addit ions (ext ensions) t o over come some
of it s shor t comings. RIP ver sion 1 cont inues t o exist on many r out er s and as of t his
wr it ing, cont inues t o out number OSPF net wor ks. However , t her e is no r eason not t o
impl ement ver sion 2 of t he pr ot ocol . Ver sion 2 is backwar d compat ibl e wit h ver sion 1 and
cont ains al l of t he capabil it ies of t he ver sion 1 pr ot ocol .
RIP ver sion 2 impl ement ed t he f ol l owing f eat ur es:
Aut hent icat ionsimpl e t ext passwor d
Subnet masking
Next host
Mul t icast t o al l ow f or var iabl e-l engt h subnet masks t o be impl ement ed
Rout e t agt o pr ovide a met hod of separ at ing RIP r out es f r om ext er nal l y
l ear ned r out es
Compat ibil it y swit cht o al l ow f or int er oper abil it y wit h ver sion 1 r out er s
Not ice t hat t he same f or mat is used f or RIPv1 and RIPv2. Appar ent l y, t her e was some
t hought when buil ding RIPv1 t hat f ut ur e pr ot ocol s of RIP may be dif f er ent and t hat
mor e inf or mat ion is t o be car r ied in t he packet . The or iginal packet indicat ed t hat t he
f iel d must be set t o 0, and not r eser ved. Now you can see why. If not , we wil l r evisit t his
in t he subnet mask t opic of t his sect ion.
RIP Ver sion 2

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 110
Authentication
Ther e r eal l y is not r oom in t he RIP updat e dat agr am f or aut hent icat ion. But since t his
has become commonpl ace (OSPF), r oom was made f or it . The addr ess f amil y ident if ier
(AFI) is used f or aut hent icat ion. If t he AFI cont ains a 0xFFFF, t hen t he f ir st ent r y in
t he r out e ent r y l ist is t he passwor d t o be used f or aut hent icat ion. The header of t he
RIP dat agr am changes as shown in t he sl ide. The aut hent icat ion t ype is t ype 2 (simpl e
passwor d) and t he next 16 byt es cont ain t his passwor d (any amount of char act er s up t o
16 byt es). RIPv1 wil l ignor e t his ent r y (t he f ir st ent r y), f or t he AFI is not set t o an
addr ess f amil y of IP.
If a RIPv2 r out er is conf igur ed wit h no aut hent icat ion, it wil l accept and pr ocess bot h
RIPv1 and v2 unaut hent icat ed messages and discar d aut hent icat ed messages.. If t he
RIPv2 r out er is conf igur ed f or aut hent icat ion, it wil l accept RIPv1 and v2 messages t hat
pass aut hent icat ion. Remember , not al l v1 impl ement at ions f ol l ow t he RFC. They may
pl ay wit h t he f iel ds and st il l be abl e t o be pr ocessed by RIPv1 r out er s! This is not
r ecommended. Unaut hent icat ed RIPv2 messages wil l be discar ded.
Aut hent icat ion

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 111
Subnet Mask Field
This is what is making RIP st ick ar ound a l it t l e l onger . Yes, it st il l has pr obl ems wit h
scal ing and st il l needs spl it hor izon and poisoned r ever se t o oper at e pr oper l y. But t o
use t he addr ess scheme mor e ef f icient l y, RIP ver sion 2 now has t he abil it y t o suppor t
mul t ipl e subnet masks per net wor k addr ess. As we l ear ned in ot her sect ions of t his book,
one of t he biggest pr obl ems wit h RIP was it s inabil it y t o suppor t a subnet mask in t he
r out ing updat e. This l ed t o t he shor t coming of one subnet mask per net wor k ID. Subnet
masking r eal l y ext ends t he l if e of RIP. RIP v1 does not indicat e a subnet mask on a r out e
ent r y. This can cr eat e many pr obl ems, t wo of which ar e l ear ning and updat ing. How
does RIPv1 know how t o appl y a subnet mask f or a l ear ned IP addr ess? How does RIP
pr ovide a mask f or it s updat es? Good quest ions! The answer is not r eal good t hough. RIP
assumed t hat t he IP addr ess uses t he same subnet mask as it does pr oviding t he IP
net wor k ID por t ion of t he addr ess is t he same as it s own and t her e is a subnet mask
appl ied t o it s int er f ace.
For exampl e, a r out er has t wo int er f aces: Int er f ace 1 has an IP addr ess of 130.1.1.1 and a
subnet mask of 255.255.255.0. Int er f ace 2 has an IP addr ess of 205.1.1.1 and a subnet mask
of 255.255.255.0. When int er f ace 1 r eceives a r out ing updat e, any ent r y t hat has t he
same net wor k ID as it s own, 130.1.x.x, wil l appl y t he subnet mask t hat is conf igur ed t o
it s por t t o t hose ent r ies. You wil l see an ent r y in t he r out ing t abl e f or t hat l ear ned
addr ess. So, if a RIPv1 updat e was r eceived on int er f ace 1 and t he updat e cont ained t he
ent r y 130.1.4.0, t hen t he int er f ace wil l r ecor d 130.1.4.0 in it s r out ing t abl e. However , if
int er f ace 1 r eceived 155.1.1.0 on t hat int er f ace, it woul d onl y pl ace 155.1.0.0 int o it s
t abl e because it does not know t he subnet mask f or t he addr ess of 155.1.0.0. You must be
saf e when you assume.
Subnet Mask Fiel d
When t he r out er must t r ansmit it s t abl e, how does it know t o appl y a mask t o any of t he
ent r ies in t he t abl e? It wil l depend on t he int er f ace f r om which it is t r ansmit t ed. On
int er f ace 1, t he r out er wil l t r ansmit t wo ent r ies: 150.1.1.0 and 200.1.1.0.
So, RIPv1 and subnet masks did not under st and each ot her . RIPv2 f ixes t hat . Not ice in
t he sl ide t hat t he f or mat of t he RIP dat agr am is pr eser ved. The t wo f iel ds in RIPv1 t hat
st at ed must be 0 ar e not used f or t he subnet mask and next -hop ent r ies. Each r out e
ent r y in t he dat agr am wil l have an associat ed subnet mask wit h it . If t he f iel d cont ains
a 0, t her e is not a subnet mask associat ed f or t he r out e ent r y. Al so, in coor dinat ion
wit h RIPv1 r out er s, a mask t hat is shor t er t han t he Cl asss nat ur al mask shoul d never
be adver t ised.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 112
Route Tag and Next-Hop Fields
The r out e t ag ent r y is used t o adver t ise r out es t hat wer e l ear ned ext er nal l y (not in
t his IGP). OSPF has t his capabil it y and al l ows t he OSPF IGP t o l ear n about r out es
ext er nal t o t he IGP. For exampl e, if t he r out es wer e l ear ned via BGP-4 ( a r out ing
pr ot ocol used bet ween aut onomous syst ems), t he r out e t ag ent r y coul d be used f or
set t ing t he aut onomous syst em f r om which t he r out es wer e l ear ned.
The next -hop f iel d al l ows t he r out er t o l ear n wher e t he next hop is f or t he specif ic
r out e ent r y. If t he ent r y is 0.0.0.0, t hen t he sour ce addr ess of t he updat e shoul d be used
f or t he r out e. Over a point -t o-point l ink (t o r out er s connect ed by a ser ial l ine) t her e is
not much use f or t his ent r y (t he next hop coul d be ext r act ed f r om t he sour ce IP addr ess
in t he IP header of t he packet ). This f iel d does have consider abl e use in inst ances wher e
t her e ar e mul t ipl e r out er s on a singl e LAN segment using dif f er ent IGPs t o
communicat e t o mul t ipl e LANs.
Rout e Tag and Next -Hop Fiel ds

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 113
Multicast Support
A key impr ovement f or t he RIP pr ot ocol is t he abil it y t o use a mul t icast addr ess f or it s
packet s and f or it s dat agr am IP header . The mul t icast addr ess f or RIPv2 is 224.0.0.9 wit h
a MAC addr ess of 01-00-5E-00-00-09. Of cour se, t his must be mapped t o an Et her net
mul t icast addr ess (f or mor e inf or mat ion on t his, pl ease r ef er t o Par t Six, BOOTP, DHCP,
RSVP, and SNMP in t his book, or RFC 1700).
Mul t icast Suppor t
RIPv2 uses t he mul t icast addr ess of 224.0.0.9 t o mul t icast , does not br oadcast
it s t abl e.
MAC addr ess of 01-00-5E-00-00-09.
Det ail s of t his conver sion ar e cover ed in RFC 1700 and t he mul t icast
sect ion of t his book.
RIPv1 uses a br oadcast addr ess in bot h t he IP header and t he MAC header .
IGMP is not used f or t his mul t icast suppor t .
If you r ead t he sect ion on mul t icast ing, you know t hat t he benef it s of mul t icast ar e
gr eat . RIPv1 uses a br oadcast addr ess t hat not onl y int er r upt s t he NIC but t he IP
ser vice l ayer as wel l , even if t he packet is not dest ined f or t hat host . Why int er r upt
t he host when t he packet /dat agr am is dest ined f or some ot her host ? Al l br oadcast
packet s must be r eceived and pr ocessed. Not a pr obl em when RIPv1 was int r oduced t o t he
IP communit y (t her e wer e not many host s t o cont end wit h).
Mul t icast al l ows onl y t hose host s t hat have specif ied t heir NICs t o r eceive and pr ocess
mul t icast packet s. Al l ot her mul t icast packet s wil l be ignor ed.
Even t hough mul t icast is used, it is not IGMP (Int er net Gr oup Management Pr ot ocol )
and is not t o be used f or t he addr ess in a l ocal mul t icast addr ess. This means t he packet
wil l never l eave t he net wor k it was t r ansmit t ed on (i.e., it wil l not be f or war ded by
r out er s).

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 114
RIPv2 Compatibility with RIPv1
RIPv2 Compat ibil it y wit h RIPv1
Conf igur at ion par amet er s on t he r out er f or :
RIPv1 onl yVer sion 1 messages wil l be sent
RIPv1 compat ibil it yRIP 2 messages as br oadcast
RIPv2Messages ar e mul t icast
NoneNo RIP messages ar e sent
So, if al l of t hese new f eat ur es ar e used, how do we communicat e wit h ver sion 1 RIP
r out er s? Ther e ar e t wo sides t o t his st or y. Some simpl e r ul es appl y:
If a RIPv2 r out er r eceives a RIPv1 updat e, it wil l pr ocess it as a v1 updat e and
does not t r y t o conver t any of t he inf or mat ion r eceived int o RIP f eat ur es.
If a RIPv1 r equest is r eceived by a RIPv2, t he RIPv2 r out er shoul d r espond wit h a
ver sion 1 r esponse.
Now, t her e ar e many changes (mul t icast , br oadcast , et c.) t o which a v2 r out er coul d
r espond. Ther ef or e, dur ing t he conf igur at ion of a v2 r out er , t her e wil l be
conf igur at ion par amet er s t hat al l ow f or t he v2 r out er t o act in many dif f er ent ways:
RIP-1onl y ver sion 1 messages wil l be sent
RIP-1 compat ibil it yRIP 2 messages ar e sent wit h br oadcast addr esses (IP header
and MAC)
RIP-2messages ar e mul t icast
Noneno RIP messages ar e sent
Al t hough not r equir ed, some r out er s have impl ement ed a r eceive par amet er l ist ing
which al l ows f or RIP-1 onl y, RIP-2 onl y, or bot h.
Al so, f or compat ibil it y, RFC 1058 st at ed t hat t he ver sion f iel d shoul d be used in t he
f ol l owing f or mat :
Any ver sion f iel d of 0discar d t he ent ir e packet .
Any ver sion f iel d of 1 and MBZ f iel ds t hat ar e not 0 ar e discar ded.
Any ver sion gr eat er t han 1 shoul d not be discar ded simpl y because t he MBZ
f iel ds cont ains a val ue ot her t han 0.
Ther ef or e, r out er s t hat st r ict l y adher e t o RFC 1058 may be abl e t o pr ocess RIPv2
updat es and buil d r out ing t abl es based on t hat inf or mat ion. RIPv1 r out er s wil l ignor e
t he subnet mask and next -hop f iel d. They wil l al so ignor e t he r out e t ag f iel d (it is a
r eser ved f iel d in RIPv1). RIPv1 wil l ignor e any AFI t hat is set t o FFFF (f or RIPv2
aut hent icat ion) and t he r out e t hat appl ies t o t he AFI. (For RIPv2, it wil l be t he f ir st
ent r y of a RIPv2 dat agr am. Al l ot her ent r ies wil l be val id RIP r out e ent r ies).

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 115
Open Shortest Path First (OSPF, RFC 2178)
Open Shor t est Pat h Fir st (OSPF, RFC 2178)
Shor t est -pat h r out es based on t r ue met r ics, not just a hop count .
Comput es t he r out es onl y when t r igger ed t o or ever y 30 minut es (whichever is
l ess).
Pair s a net wor k addr ess ent r y wit h a subnet mask.
Al l ows f or r out ing acr oss equal pat hs.
Suppor t s ToS.
Per mit s t he inject ion of ext er nal r out es (ot her ASs).
Aut hent icat es r out e exchanges.
Quick conver gence.
Dir ect suppor t f or mul t icast in bot h t he IP header and t he MAC header .
The major shor t comings of t he RIP pr ot ocol ar e:
The maximum dist ance bet ween t wo st at ions (t he met r ic, measur ed in r out er
hops) is 15 hops. A dest inat ion (net wor k ID) whose hop count is 16 is consider ed
unr eachabl e.
The cost t o a dest inat ion net wor k is measur ed in hops. RIP det er mines a r out e
based on a hop count t hat does not t ake int o consider at ion any ot her
measur ement s except f or t he number of r out er s bet ween t he sour ce and
dest inat ion net wor ks. A t wo-hop high-speed net wor k wil l be bypassed f or a one-
hop l ow-speed l ink. A r out er can be t r icked int o t aking a bet t er pat h by adjust ing
t he hop-count met r ic on t he r out er por t , but t his r educes t he avail abl e diamet er .
RIP updat es it ent ir e t abl e on a per iodic basis consuming bandwidt h using t he
br oadcast addr ess. (RIPv1; RIPv2 uses mul t icast or br oadcast ).
RIP sends it s updat e in a 576-byt e dat agr am. If t her e ar e mor e ent r ies t han 512
byt es, mul t ipl e dat agr ams must be sent . For exampl e, 300 ent r ies r equir e 12 back-
t o-back 512-byt e dat agr ams.
RIP suf f er s f r om sl ow conver gence. In t he wor se case, a RIP updat e can t ake
over 15 minut es end t o end. This can cause bl ackhol es, l oops, et c.
RIPv1 does not suppor t VLSM.
The f ir st shor t est -pat h-f ir st r out ing pr ot ocol was devel oped and used in t he ARPAnet
packet swit ching net wor k al l t he way back in 1978. This r esear ch wor k was devel oped
and used in many ot her r out ing pr ot ocol t ypes and pr ot ot ypes. One of t hose is OSPF.
OSPF Feat ur es
Shor t est -pat h r out es ar e based on t r ue met r ics, not just a hop count .
The r out ing t abl es ar e updat ed onl y when needed, or ever y 30 minut es using a
mul t icast addr ess.
A net wor k addr ess ent r y is pair ed wit h a subnet mask.
Rout ing acr oss equal pat hs is al l owed, per f or ming l oad bal ancing.
Type of Ser vice (ToS) r out ing is suppor t ed.
The inject ion of ext er nal r out es is per mit t ed (r out es f r om ot her aut onomous
syst ems).
Rout e exchanges ar e aut hent icat ed.
Quick conver gence is r eal ized.
Mul t icast is dir ect l y suppor t ed.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 116
An OSPF Network
The f ol l owing diagr am is a pict ur e on OSPF t opol ogy. OSPF int r oduces many new
concept s. OSPF has ar eas, and r uns met r ics based on t r ue cost s. OSPF does not br oadcast
it s t abl e out ; onl y l ink inf or mat ion is sent t o a specif ic r out er .
The met r ics assigned ar e based on a number set by t he net wor k administ r at or . It shoul d
be based on t he speed of t he l inea l ower cost f or higher -speed l ines. For exampl e, if
wor kst at ion A want s t o conver se wit h wor kst at ion Z, OSPF wil l pr oduce a r out ing
t abl e t hat r out es t he dat agr am over t he t wo T1 l ines inst ead of t he 56k l ine.
The name f or t his r out ing pr ot ocol is el usive. Shor t est pat h f ir st ? Shoul dnt any
r out ing pr ot ocol t r y t he shor t est pat h f ir st ? This pr ot ocol evol ved af t er many year s of
r esear ch on t he Int er net and was t he aggr egat e of many r out ing pr ot ocol s. It was a
Xer ox Net wor k Syst ems pr ot ocol and was widel y dist r ibut ed t hr ough t he Ber kel ey
Unix syst em. RIP was not invent ed on t he Int er net ; however , OSPF was.
An OSPF Net wor k

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 117
A Routing Protocol Comparison
When r eading t hr ough t he f ol l owing sect ions on t he OSPF pr ot ocol , keep one main
goal in mind: net wor k design. OSPF al l ows us t o buil d ver y ef f icient net wor ks t hr ough
segment ing of an aut onomous syst em int o smal l gr oups cal l ed areas, var iabl e-l engt h
subnet masks, Type of Ser vice r out ing, and a host of ot her bet t er ment s compar ed t o t he
RIP pr ot ocol . It was ment ioned at t he beginning of t his sect ion t hat t her e ar e t wo t ypes
of r out ing met hods: IGP and EGP. The t abl e compar es RIP wit h OSPF.
Funct ion/Feat ur e RIPv1 RIPv2 OSPF
St andar d number RFC 1058 RFC 1723 RFC 2178
Link-st at e pr ot ocol No No Yes
Lar ge r ange of met r ics Hop count
(16=Inf init y)
Hop count
(16=Inf init y)
Yes, based on
165535
Updat e pol icy Rout e t abl e ever y
30 seconds
Rout e t abl e ever y
30 seconds
Link-st at e
changes, or ever y
30 seconds
Updat e addr ess Br oadcast Br oadcast , mul t icast Mul t icast
Dead int er val 300 seconds t ot al 300 seconds t ot al 300 seconds
t ot al , but
usual l y much
l ess
Suppor t s aut hent icat ion No Yes Yes
Conver gence t ime Var iabl e (based on
number
of r out er s dead
int er val )
Var iabl e (based on
number
of r out er s dead
int er val )
Media del ay +
dead int er val
Var iabl e-l engt h subnet s No Yes Yes
Suppor t s super net t ing No Yes Yes
Type of Ser vice (TOS) No No Yes
Mul t ipat h r out ing No No Yes
Net wor k diamet er 15 hops 15 hops 65535 possibl e
Easy t o use Yes Yes No
A Rout ing Pr ot ocol Compar ison
Funct ion/Feat ur e RIPv1 RIPv2 OSPF
St andar d number RFC 1058 RFC 1723 RFC 2178
Link-st at e Pr ot ocol No No Yes
Lar ge r ange of met r ics Hop count
(16=Inf init y)
Hop count
(16=Inf init y)
Yes, based
on 165535
Updat e pol icy Rout e t abl e
ever y
30 seconds
Rout e t abl e
ever y
30 seconds
Link-st at e
changes or
ever y
30 minut es
Updat e addr ess Br oadcast Br oadcast ,
mul t icast
Mul t icast
Dead int er val 300 seconds
t ot al
300 seconds
t ot al
Up t o 300
seconds
t ot al ;
usual l y
shor t er
Suppor t s
aut hent icat ion
No Yes Yes
Conver gence t ime Var iabl e based
on
(number of
r out er s
dead
int er val )
Var iabl e based
on
(number of
r out er s
dead
int er val )
Media del ay
+
dead
int er val
Var iabl e-l engt h
subnet s
No Yes Yes
Suppor t s super net t ing No Yes Yes
Type of Ser vice (TOS) No No Yes
Mul t ipat h r out ing No No Yes
Net wor k diamet er 15 hops 15 hops N/A but up
t o 65535
Easy t o use Yes Yes No

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 118
OSPF Overview
Ther e ar e t wo t ypes of st andar dized IGPs: RIP (ver sions 1 or 2) and OSPF. Like RIP, OSPF
is an IGP, which means t hat it is designed t o r un int er nal l y t o a singl e aut onomous
syst em (AS). (An AS is descr ibed as t hose net wor ks and r out er s gr ouped int o a singl e
domain under one aut hor it y.) It exchanges r out ing inf or mat ion wit hin a singl e
aut onomous syst em. It can be used in smal l , medium, or l ar ge int er net wor ks, but t he
most dr amat ic ef f ect s wil l be r eadil y not iced on l ar ge IP net wor ks. As opposed t o RIP (a
dist ance vect or pr ot ocol ), OSPF is a l ink-st at e pr ot ocol . It maint ains t he st at e of ever y
l ink in t he domain.
The f ol l owing is a simpl e al gor it hm f or OSPF:
Upon init ial izat ion, each r out er r ecor ds inf or mat ion about al l it s int er f aces.
Each r out er buil ds a packet known as t he Link St at e Adver t isement (LSA).
The packet cont ains a l ist ing of al l r ecent l y seen r out er s and t heir cost s.
LSAs ar e r est r ict ed t o being f or war ded onl y in t he or iginat ed ar ea.
Received LSAs ar e f l ooded t o al l ot her r out er s.
Each r out er makes a copy of t he most r ecent l y seen LSA.
Each r out er has compl et e knowl edge of t he t opol ogy of t he ar ea t o which it
bel ongs.
Adjacencies ar e f or med bet ween a designat ed r out er (and backup DR) and ot her
r out er s on a net wor k.
Shor t est -pat h t r ees ar e const r uct ed af t er r out er s exchange t heir dat abases.
Rout er al gor it hm updat es onl y when changes occur (or ever y 30 minut es,
whichever is shor t er ).
OSPF Over view
Upon init ial izat ion, each r out er r ecor ds inf or mat ion about al l it s int er f aces.
Each r out er buil ds a packet known as t he Link St at e Adver t isement (LSA).
Cont ains a l ist ing of al l r ecent l y seen r out er s and t heir cost
LSAs ar e r est r ict ed t o being f or war ded onl y in t he or ginat ed ar ea
Received LSAs ar e f l ooded t o al l ot her r out er s.
Each r out er makes a copy of t he most r ecent l y seen LSA
Each r out er has compl et e knowl edge of t he t opol ogy of t he ar ea t o which it
bel ongs.
Adjacencies ar e f or med bet ween a Designat ed Rout er (and Backup DR) and
ot her r out er s on a net wor k.
Shor t est Pat h Tr ees ar e const r uct ed af t er r out er s exchange t heir dat abases.
Rout er al gor it hm onl y when changes occur (or ever y 30 minut es, whichever is
shor t er ).
This inf or mat ion is f l ooded t o al l r out er s in t he domain. Flooding is t he pr ocess of
r eceiving t he inf or mat ion on one por t and t r ansmit t ing it t o al l ot her act ive por t s on
t he r out er . In t his way, al l r out er s r eceive t he same inf or mat ion and can comput e t heir
own r out es. This inf or mat ion is st or ed in a dat abase cal l ed t he link-state database, which
is ident ical on ver y r out er in t he AS (or ever y ar ea if t he domain in spl it int o mul t ipl e
ar eas). Based on inf or mat ion in t he l ink-st at e dat abase, an al gor it hm known as t he
Dykst r a al gor it hm r uns and pr oduces a shor t est -pat h t r ee based on t he met r ics, using
it sel f as t he r oot of t he t r ee. The inf or mat ion t his pr oduces is used t o buil d t he r out ing
t abl e.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 119
OSPF Media Support
OSPF suppor t s br oadcast and nonbr oadcast mul t iaccess (NBMA), and point -t o-point
net wor ks. Br oadcast net wor ks, l ike Et her net , Token Ring, and FDDI, can suppor t one, or
mor e net wor k at t achment s t oget her wit h t he abil it y t o addr ess a singl e message t o al l
t hose at t achment s; a br oadcast net wor k. Al t er -nat ivel y, non-br oadcast net wor ks, l ike
X.25, ATM or Fr ame Rel ay, suppor t one, or many host s but do not possess a met hod f or
br oadcast ing. Point -t o-point is exact l y t hat , a l ink t hat has t wo connect ion point s. Two
r out er s connect ed t oget her t hr ough a ser ial l ine (56k t hr ough T1) is an exampl e of a
point -t o-point l ink. Ther e can be no ot her connect ions in bet ween t hese t wo point s.
OSPF Media Suppor t
Br oadcast Net wor ks such as Et her net , Token Ring, and FDDI.
Non-br oadcast Mul t iaccess (NBMA)access t hat does not suppor t br oadcast
but al l ows f or mul t ipl e st at ion access such as ATM, Fr ame Rel ay, and X.25.
Point -t o-Point Links t hat onl y have t wo net wor k at t achment s, such as t wo
r out er s connect ed by a ser ial l ine.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 120
Router Types
When t her e is onl y one ar ea, t her e is basical l y onl y one special ized t ype of r out er : t he
ones t hat deal wit h ext er nal r out es. When an OSPF envir onment is spl it int o mul t ipl e
ar eas, mul t ipl e r out er s ar e r equir ed. Ther e ar e six t ypes of r out er s in an OSPF
envir onment :
Backbone Rout er (BR): A r out er t hat has an int er f ace t o t he backbone.
Ar ea Bor der Rout er (ABR): A r out er t hat has int er f aces t o mul t ipl e ar eas.
Aut onomous Syst em Boundar y Rout er (ASBR): A r out er t hat exchanges r out ing
inf or mat ion wit h r out er s t hat ar e at t ached t o dif f er ent aut onomous syst ems.
Int er nal Rout er (IR): A r out er whose at t achment s al l bel ong t o t he same ar ea.
Designat ed Rout er (DR): One r out er on a subnet t hat is sel ect ed as t he designat ed
r out er . Al l ot her r out er s on t he subnet f or m an adjacency (a l ogical point -t o-point
connect ion on a subnet ) t o t his r out er . Inf or mat ion about net wor ks t o and f r om t he
subnet is t r ansf er r ed over t he DR. The DR gener at es net wor k LSA on behal f of it s
subnet and f l oods t his inf or mat ion t hr oughout it s ar ea. This adver t isement in t he DR
ident if ies al l r out er s adjacent t o t his DR and r ecor ds t he l ink-st at es of al l t he r out er s
cur r ent l y at t ached t o t he net wor k.
Rout er Types
Backup Designat or Rout er (BDR): Backs up t he DR in case t he DR f ail s.
Some of t hese r out er t ypes have over l apping r ol es. For exampl e, an ABR can al so be a
backbone r out er .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 121
Router Names and Routing Methods
Rout er Names and Rout ing Met hods
Thr ee t ypes of r out ing in an OSPF net wor k:
Int r a-Ar ea r out ingRout ing wit hin a singl e ar ea
Int er -Ar ea r out ingRout ing wit hin t wo ar eas of t he same AS
Int er -AS r out ingRout ing bet ween AS syst ems
Ther e ar e t hr ee t ypes of r out ing in an OSPF net wor k:
Int r a-ar ea r out ing. Rout ing wit hin a singl e ar ea.
Int er -ar ea r out ing. Rout ing bet ween t wo ar eas.
Int er -AS r out ing. Rout ing bet ween aut onomous syst ems.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 122
Message Types
OSPF r out er s pass messages t o each ot her in t he f or m of Link-St at e Adver t isement s
(LSAs). Each l ink-st at e adver t isement descr ibes a piece of t he OSPF r out ing domain. Al l
l ink-st at e adver t isement s ar e t hen f l ooded t hr oughout t he OSPF r out ing domain, but
wit hin a singl e ar ea. A singl e ar ea can be an ent ir e OSPF domain. The f l ooding
al gor it hm is r el iabl e, ensur ing t hat al l r out er s have t he same col l ect ion of l ink-st at e
adver t isement s.
Type 1Rout er Links Adver t isement : This message is f l ooded wit hin an ar ea
and cont ains inf or mat ion about neighbor s r out er l inks (basical l y t he IP addr ess
of an int er f ace and t he cost associat ed wit h t hat int er f ace). Ever y r out er
or iginat es a r out er l inks adver t isement .
Type 2Net wor k Links Adver t isement : This message is f l ooded wit hin an ar ea.
It is gener at ed by t he designat ed r out er (DR) and incl udes inf or mat ion on al l
r out er s on t his mul t iaccess net wor k. Whenever t he r out er is el ect ed t he DR, it
or iginat es a net wor k l inks adver t isement .
Type 3Summar y Links Adver t isement : Fl ooded int o an ar ea by an Ar ea Bor der
Rout er (ABR). This message descr ibes r eachabl e net wor ks f r om out side t he ar ea
(in ot her ar eas of t he OSPF domain).
Type 4AS Boundar y Rout er Summar y Link Adver t isement : This message is
f l ooded int o an ar ea by an ABR. The message descr ibes t he cost f r om t his r out er
t o an AS Boundar y Rout er .
Message Types
OSPF r out er s communicat e by sending Link St at e Adver t isement s (LSAs) t o
each ot her .
Type 1Rout er Links Adver t isement
Type 2Net wor k Links Adver t isement
Type 3Summar y Links Adver t isement
Type 4AS Boundar y Rout er Summar y Link Adver t isement
Type 5AS Ext er nal Link Adver t isement
Type 6Mul t icast Gr oup Member ship LSA
LSAs cont ain sequence number s t o det ect ol d and dupl icat e LSAs.
Type 5AS Ext er nal Link Adver t isement :
This message is f l ooded t o al l ar eas except st ub ar eas (expl ained l at er ). It
descr ibes an ext er nal net wor k r eachabl e via t he AS Boundar y Rout er t hat
gener at ed it .
Type 6Mul t icast Gr oup Member ship LSAs: Al l ows mul t icast -enabl ed OSPF
r out er t o dist r ibut e IGMP (mul t icast gr oup inf or mat ion).
One l ast t hing about LSAs: They cont ain 32-bit sequence number s. This number is used t o
det ect ol d and dupl icat e LSA packet s. Each new LSA uses an incr ement ed sequence
number ; t her ef or e, OSPF r out er s keep t heir LSA dat abases cur r ent by updat ing t hem
wit h an LSA of a higher sequence number . This al so al l ows t he OSPF r out er t o f l ush
out ol d ent r ies.
Anot her met hod empl oyed by OSPF on it s LSA dat abase is t he age f iel d. Each LSA ent r y
has an expir at ion t imer t hat can expir e, al l owing t he dat abase t o pur ge ol d ent r ies.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 123
Metrics (Cost)
Met r ics (Cost )
Ref er ence RFC 1253
Met r ic = 10
n8 / int er f ace speed
Exampl es:
=> 100 Mbps 1
10 Mbps 10
E1 48
T1 65
64 kbps 1562
19.2 kbps 5208
9.6 kbps 10416
A cost is associat ed wit h t he out put side of each r out er int er f ace. This cost is a
conf igur abl e par amet er on t he r out er . When LSAs ar e t r ansf er r ed bet ween r out er s,
t he cost of t he individual l inks is added as wel l . The cost of a l ink is t he cost associat ed
on t he out bound l ink and t his inf or mat ion is added up in a r out er (r eceiving LSAs)
bef or e Dykst r a r uns. Mul t ipl e pat hs can be f ound t o a dest inat ion and t he pat h wit h
t he l owest cost wil l be pl aced in t he r out ing t abl e. Simpl y st at ed, t he l ower t he cost of
a r out er por t , t he mor e l ikel y t he int er f ace is t o be used t o f or war d dat a t r af f ic.
Accor ding t o RFC 1253 (OSPF Ver sion 2 MIB), t he f ol l owing is a r ecommendat ion f or
assigning cost s t o l inks in an OSPF envir onment :
For costing a link, there is a default value that can be used. It is only a recommendation
and any number can be used. For example, if you are using a higher-speed link (such as
those available with the ATM protocol) room should be left to compensate for this. This
yields a number having the following typical values:
Metric = 10n8 /interface speed
Network type/bit rateMetric
Speed Cost
>= 100 Mbps 1
Et her net /802.3 10
E1 (2.048 Mbps) 48
T1 (ESF or 1.544
Mbps)
65
64 kbps 1562
56 kbps 1785
19.2 kbps 5208
9.6 kbps 10416

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 124
Generic Packet Format
As of t his wr it ing, t her e ar e seven t ypes of adver t isement s. Al l OSPF packet s have t he
same header , but t he body of t he packet is dif f er ent and t his is not ed by t he LSA specif ic
f iel d.
Gener ic Packet For mat

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 125
The Hello Protocol
Rout er s per iodical l y t r ansmit Hel l o packet s t o not onl y f ind ot her OSPF r out er s on
t heir subnet but al so t o t r ansmit and make sur e t hat cer t ain par amet er s ar e set t o t he
same val ues wit hin al l t he r out er s on t hat subnet . The Hel l o packet f or mat is shown
her e. The Hel l o packet st ays on t he l ocal subnet ; it is not f or war ded by t he r out er . The
Hel l o packet cont ains:
The r out er s sel ect ion of t he DR (designat ed r out er ) and BDR (backup
designat ed r out er )
The r out er s pr ior it y used t o det er mine t he DR and BDR
Conf igur abl e t imer s t hat incl ude t he Hel l o Int er val (t ime a r out er expect s t o
hear hel l os) and t he Rout er DeadInt er val (t he t ime per iod bef or e a r out er is
decl ar ed down)
A l ist of neighbor ing r out er s t hat t his r out er has r eceived hel l os f r om
The most basic exchange bet ween r out er s is cal l ed t he Hel l o pr ot ocol . This pr ot ocol
al l ows OSPF r out er s t o discover one anot her (in a singl e ar ea) and al l ows f or t he
buil ding of r el at ionships bet ween r out er s. This is t he pr ot ocol t hat al l ows f or t he DR
and BDR t o be sel ect ed. Once t he DR is sel ect ed, adjacencies ar e f or med (discussed next ).
The Hel l o Pr ot ocol
For mul t iaccess net wor ks, when a r out er t r ansmit s a Hel l o packet it is sent using t he
ALL-SPF-Rout er s (which means al l OSPF r out er s) mul t icast addr ess of 224.0.0.5
OSPF r out er s buil d and maint ain t heir r el at ionships by per iodic exchanges of Hel l o
packet s. Incl uded in t he t r ansmit t ed Hel l o packet s is a l ist of al l t he r out er s a r out er
has hear d f r om (i.e., r eceived Hel l o packet s f r om). When a r out er sees it s addr ess in a
r eceived Hel l o packet , it knows t hat t he r out er t hat t r ansmit t ed t hat packet has seen
it . Once t his is accompl ished, t he DR and t he BDR ar e sel ect ed. Any DR wit h a pr ior it y
of 0 count s it sel f out of t he sel ect ion. Ther e is one DR and DBR per subnet or LAN
segment .
These packet s ar e cont inual l y sent ever y Hel l o per iod specif ied in t he packet . This is
how a r out er can det ect t hat anot her r out er is down (DeadInt er val ), which it uses t o
wait and buil d a new dat abase wit h t he Dykst r a al gor it hm.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 126
Adjacency
Af t er t he Hel l o discover y pr ocess has al l owed f or t he DR and BDR t o be sel ect ed,
r out er s on a singl e LAN segment det er mine whet her t o f or m an adjacency wit h one
anot her . An adjacency is impor t ant because it enabl es t wo r out er s t o al l ow t he
exchange of r out ing inf or mat ion t hr ough l ink-st at e adver t isement s. The f ol l owing ar e
t he r equir ement s f or est abl ishing an adjacency:
The l ink is a point -t o-point l ink or a vir t ual l ink (discussed l at er ).
The r out er is t he DR or BDR.
The neighbor is t he DR or BDR.
So, you can see t hat if t he r out er is t he DR or BDR, an adjacency is f or med bet ween t he
DR/BDR and an at t ached r out er . If t hese condit ions ar e not met , t hen an adjacency is
not f or med. That is, not al l r out er s f or m adjacencies wit h each ot her , onl y wit h t he DR
and BDR or a point -t o-point l ink.
As t he adjacency is f or med, t he adjacent r out er s dat abases must become
synchr onized. That is, each must cont ain t he exact same inf or mat ion. Ther e is a ser ies
of st eps bef or e f ul l adjacency. The r eason f or t his is t o synchr onize t he l ink-st at e
dat abase. The adjacent r out er s t r ansmit t o adjacent neighbor s a summar y l ist of LSAs
using t he database description packet. The r out er t akes t his inf or mat ion, compar es it t o it s
own LSA dat abase, and t hen buil ds a r equest l ist of LSAs t hat ar e in t he r eceived
summar y l ist but not in it s LSA dat abase, and LSAs t hat ar e in t he dat abase but not in
t he r eceived inf or mat ion f r om it s adjacent neighbor .
Adjacency
This newl y buil d r equest l ist is t hen t r ansmit t ed t o it s neighbor using t he Link St at e
r equest packet . Each r out er t hat r eceives t his r equest l ist r esponds t o each r equest ed
r ecor d in t he l ist . The r out er t hat r eceived t he r equest packet r esponds wit h a Link
St at e Updat e packet . Neighbor s ar e consider ed t o be fully adjacent when t hey have
r eceived al l r esponses t o t he r equest s and become f ul l y adjacent on a one-on-one basis
wit h each r out er t hat has f or med an adjacency. Af t er t he r out er s become f ul l y
adjacent , each wil l r un t he SPF al gor it hm using t he inf or mat ion suppl ied in t he
dat abase. The out come of t he al gor it hm is OSPF r out es, which ar e added t o t he r out ing
t abl e.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 127
Maintaining the Database
Af t er t he al gor it hm is r un, t he dat abases ar e cont inual l y checked f or synchr onizat ion
bet ween adjacencies using LSAs and t he f l ooding pr ocedur e. The f l ooding pr ocedur e is
simpl e: Receive an LSA, check f or t he inf or mat ion in t he dat abase, and det er mine
whet her or not t o f or war d it t o anot her adjacency using a LSA. To ensur e r el iabil it y,
t he f l ooding pr ocedur e uses an acknowl edgment pr ocedur e.
Rel iabil it y is al so buil t int o t he pr ot ocol . When an LSA is t r ansmit t ed, it is
acknowl edged. An unacknowl edged packet is r et r ansmit t ed by t he issuing r out er unt il
it is acknowl edged.
Ever y LSA cont ains an age f iel d. This f iel d is used t o age ol d ent r ies in t he dat abase. If
an ent r y is aged out , t his inf or mat ion is f l ooded t hr oughout t he domain (a singl e ar ea)
and t he Dykst r a al gor it hm is r un again t o buil d a new r out er t abl e.
Sequence number s ar e gener at ed f or al l LSAs. When a r out er t r ansmit s an LSA, it
appl ies a sequence number t o it . In t his way, t he r eceiving r out er wil l know if it is
r eceiving t he most r ecent inf or mat ion f r om anot her r out er . The sequence number is 32
bit s l ong and is assigned t o an LSA in ascending or der .
Maint aining t he Dat abase
Af t er Dykst r a r uns, t he dat abase is checked f or consist ency.
Uses t he f l ooding pr ocedur e:
Receive an LSA
Check f or t he inf or mat ion in t he dat abase
Det er mine whet her or not t o f or war d t his LSA t o an adjacency
Rel iabil it y checked using an acknowl edgment pr ocedur e.
Each LSA cont ains an age ent r y.
Sequence number s ar e gener at ed f or ever y LSA.
Changes in t he LSA dat abase r equir e a r er unning of t he SPF al gor it hm and an updat e of
t he r out ing t abl e depending on t he out come of t he al gor it hm.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 128
OSPF Areas
OSPF uses a concept known as an area. Ref er t o Sl ide 140.0. An ar ea is a gr ouping of
cont iguous net wor ks and it s associat ed r out er s t hat have int er f aces bel onging t o t hose
net wor ks and host s. An OSPF aut onomous syst em can simpl y be one ar ea (in t his case, it
must be t he backbone ar ea) or it can consist of many ar eas. Each ar ea r uns it s own copy
of t he l ink-st at e r out ing al gor it hm, al l owing f or each ar ea t o buil d it s own
t opol ogical dat abase. It is impor t ant t o not e t hat an ar ea l imit s t he f l ooding of an LSA.
LSAs do not l eave t he ar ea f r om which t hey or iginat ed. Fur t her mor e, spl it t ing a domain
int o ar eas al l ows f or r out ing t r af f ic bandwidt h savings as wel l .
Each ar ea is ident if ied wit h a 32-bit number known as t he area ID. This number is
f or mat t ed in t he same manner as an IP addr ess; however , it has not hing t o do wit h t he IP
addr essing scheme of your net wor k. It simpl y ident if ies an ar ea. Common ar ea IDs ar e
0.0.0.0 (a singl e ar ea must be conf igur ed wit h t he ar ea ID of 0.0.0.0, or a mul t ipl e ar ea
must have one of it s ar eas l abel ed 0.0.0.0, known as Ar ea 0). Ot her ar ea IDs ar e 1.1.1.1 t o
ident if y ar ea 1, or 0.0.0.1 t o ident if y ar ea 1. Ther e is no st r ict met hod t o accompl ish ar ea
ID number ing except f or ar ea 0.0.0.0.
Fur t her mor e, each r out er in an ar ea is assigned an r out er ID r egar dl ess of it s ar ea ID
assignment . This number is a 32-bit number t hat uniquel y ident if ies t hat r out er in t he
aut onomous syst em. Typical l y, t he r out er ID is chosen f r om t he IP addr ess assignment s
of one of t he r out er int er f aces.
The t opol ogy of an ar ea in not known t o any ot her ar ea. This means t hat t he int er nal
r out er s of an ar ea do not cont ain any inf or mat ion about t he OSPF t opol ogy out side
t heir ar ea, giving t he benef it of r educed r out ing over head. A singl e ar ea t hat is spr ead
over spar se envir onment s (WAN l inks) must cont ain t he same t opol ogy dat abase f or t he
ent ir e ar ea no mat t er how l ar ge it has become. So how does an ar ea det er mine r out es
t hat ar e not wit hin it s ar ea? This is accompl ished via t he backbone ar ea and t he
summar y l inks adver t isement .
ABRs pl ay an impor t ant r ol e in an OSPF net wor k. Since ar eas do not know t he t opol ogy
in ar eas ot her t han t heir own, some mechanism must be pr ovided t o al l ow net wor k
r eachabil it y inf or mat ion t o t r aver se dif f er ent ar eas. Af t er al l , it woul dnt do much
good t o be abl e t o dynamical l y r out e in your own ar ea and t hen have t o st at ical l y
point t o net wor ks in ot her ar eas. ABRs compact t he t opol ogical inf or mat ion f or an ar ea
and t r ansmit it t o t he backbone ar ea. Rout er s in t he backbone ar ea make sur e t hat it is
f or war ded t o t he ar eas t hat ar e at t ached t o it . In or der t o accompl ish t his, ABRs r un
mul t ipl e copies of t he OSPF al gor it hm, one f or each ar ea (incl uding t he backbone ar ea).
Ar eas al so al l ow f or t he advant ages of hier ar chical t opol ogies t o be buil t .
OSPF Ar eas

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 129
The Backbone Area
The Backbone Ar ea
Ther e must be at l east one ar ea in an OSPF net wor k.
It is cal l ed t he backbone ar ea
Designat ed by ar ea ID of 0.0.0.0.
Pr imar y r esponsibil it y t o pr opagat e inf or mat ion bet ween ar eas.
Has t he same at t r ibut es as any ot her ar ea.
Any net wor k t opol ogy can make up t he backbone.
It can be used as a r eal net wor k wit h at t achment s.
One of t he ar eas is a special ized ar ea. It is known as t he backbone ar ea and is l abel ed as
0.0.0.0 or Ar ea 0. When a domain is spl it int o ar eas, t he ar eas communicat e wit h one
anot her t hr ough t he backbone ar ea. This ar ea cont ains t hose r out er s and net wor ks not
cont ained in any ot her ar ea and r out er s t hat connect t o mul t ipl e ar eas (An ABR,
expl ained next ). It s pr imar y r esponsibil it y is t o dist r ibut e r out ing inf or mat ion bet ween
ar eas. The backbone ar ea cont ains al l t he pr oper t ies of it s ar ea, it s t opol ogy is not
known by any ot her ar ea, and it does not know t he t opol ogy of any ot her ar ea. Okay,
now t hat we have t he dist r ibut ion ar ea (if you wil l ), what causes t he inf or mat ion t o be
in t he backbone ar ea? The ABR accompl ishes t his.
The backbone ar ea has al l t he at t r ibut es of any t ypical ar ea. This incl udes t he f act
t hat it s t opol ogy is not known t o any ot her ar ea at t ached t o it . The t opol ogies of t he
ar eas t hat at t ach t o t he backbone ar e not known t o any backbone r out er as wel l . It
l ooks l ike any ot her ar ea except f or it s ar ea number assignment 0.0.0.0.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 130
The Area Border Router (ABR)
Ther e is a special r out er t ype known as t he Ar ea Bor der Rout er . It s job is t o connect an
ar ea t o t he backbone and t o summar ize it s ar ea t opol ogy inf or mat ion (f or al l ar eas
t hat it connect s t o) t o t he backbone ar ea, wher e it is r eceived by ot her ABRs t o be
incl uded in t heir t abl es. ABRs al so r eceive ot her ar ea summar ies f r om t he backbone and
pr opagat e t his t o t heir ar eas. ABRs ar e par t of t he backbone ar ea; t her ef or e, ABRs
bel ong t o a minimum of t wo ar eas: t heir own and t he backbone ar ea. If t her e is onl y one
ar ea in t he AS (t he backbone ar ea), t her e ar e no ABRs.
Since an ABR bel ongs t o t wo or mor e ar eas, it has a separ at e dat abase f or each ar ea t o
which it bel ongs. It al so execut es a singl e copy of t he r out ing al gor it hm f or each ar ea
t o which it bel ongs. For a t ypical ABR, it maint ains connect ions t o it s ar ea and t o t he
backbone ar ea. For it s ar ea, it r eceives f l ooded LSAs t hat ar e wit hin it s ar ea and
maint ains a synchr onized dat abase f or t he ar ea. The ot her copy of t he al gor it hm r uns
f or t he at t achment t o t he backbone. ABRs do not f l ood l ear ned inf or mat ion about it s
ar ea t o t he backbone. It summar izes t his inf or mat ion using summar y l ink adver t isement s.
These adver t isement s ar e pushed t o ot her ABRs on t he backbone, al l owing t hose ar eas
t o l ear n about each ot her wit hout dir ect l y par t icipat ing in t he backbones r out ing
adver t isement s (r emember , t he backbone is a r eal ar ea, t oo!).
Since, ar ea r eachabil it y inf or mat ion is pr opagat ed onl y over t he backbone ar ea, ever y
ar ea must t ouch t he backbone t hr ough t he use of an ABR. An ar ea is not al l owed t o be
segment ed f r om t he backbone. A special condit ion does exist t o al l ow an ar ea t o be
ext ended of f an ar ea t hat is not t he backbone t hr ough a concept known as a virtual link.
The Ar ea Bor der Rout er (ABR)
Connect s an ar ea (or ar eas) t o t he backbone.
Summar izes it s ar ea t opol ogy t o t he backbone.
Pr opagat es summar ized inf or mat ion f r om t he backbone int o it s ar ea.
Final r out er t hat r eceives an ar eas LSA.
ABRs do not f l ood LSA inf or mat ion int o t he backbone
Onl y pr oduces summar ies t o t he backbone f or t he backbone t o pr opagat e
t o ot her ar eas
Uses t he net wor k summar y LSA.
Summar ized inf or mat ion is pr opagat ed in an ar ea by t he DR and it s adjacencies.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 131
Virtual Link
A vir t ual l ink is shown in t he sl ide. The backbone must be cont iguous. This means t hat
an ABR must connect dir ect l y t o t he backbone and not t o anot her ar ea. Ar ea-t o-ar ea
communicat ion is not al l owed dir ect l y, onl y t hr ough t he backbone. However , t her e
wil l be designs t hat f or ce t he cr eat ion of an ar ea t hat wil l not have dir ect
connect ivit y t o t he backbone. This makes t he backbone is no l onger cont iguous.
Backbone connect ivit y is r est or ed t hr ough a vir t ual l ink.
Vir t ual l inks can be conf igur ed bet ween any t wo ABR r out er s t hat have an common
int er f ace t o a nonbackbone ar ea. The vir t ual l ink is conf igur ed on each ABR and act s
l ike a point -t o-point l ink. Vir t ual l inks bel ong t o t he backbone. The r out ing pr ot ocol
t r af f ic t hat f l ows al ong t he vir t ual l ink uses int r a-ar ea r out ing onl y.
As shown in t he sl ide, t he t wo endpoint s of t he l ink ar e ABRs and t he l ink is conf igur ed
in bot h r out er s. The t wo ABRs used in t he vir t ual l ink al so must bel ong t o a common
ar ea, not t he backbone ar ea.
Simpl y st at ed, a vir t ual l ink is l ike a point -t o-point l ink bet ween t wo f ul l y adjacent
ABRs t hat al l ows an ar ea t o r eceive and t r ansmit summar y inf or mat ion (l ear n r out es
wit hin t he AS) when it is not dir ect l y connect ed t o t he backbone ar ea. That s simpl y
st at ed?
Vir t ual Link

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 132
Inter-Area Routing
Rout ing a packet bet ween ar eas invol ves t r ansmit t ing a packet f r om it s sour ce,
t hr ough it s int er nal ar ea t o t he ABR. The ABR t r ansmit s t he packet over t he backbone
ar ea t o anot her ABR, wher e it is t r ansmit t ed int er nal l y on t he ar ea t o t he dest inat ion
host . Ar eas cannot r out e dir ect l y t o ot her ar eas!
Again, t he backbone ar ea is a special ar ea. It s main f unct ion is t o dist r ibut e inf or mat ion
f r om ar eas t o ot her ar eas. It consist s of net wor ks t hat ar e not cont ained in any ot her
def ined ar ea, and r out er s t hat ar e at t ached t o an ar ea or ar eas.
Why do ar eas? Br eaking t he AS int o r out abl e ar eas gr eat l y r educes t he amount of
over head in t he f or m of r out ing inf or mat ion updat es t hat need t o be dist r ibut ed
t hr oughout t he AS. Whil e t his may not seem l ike much, r emember , t hat each ar ea can be
unique. One ar ea can have a major it y of WAN l inks, whil e ot her s ar e most l y net wor ks,
and ot her s ar e a combinat ion of mul t ipl e net wor k t ypes. Why make t he updat e pr ocess
ver y compl ex, and why bot her ot her ar eas wit h your inf or mat ion? Remember , when t he
r out ing al gor it hm r uns, ever y r out er in an ar ea must r un it . If one r out er in an ar ea
r uns t he al gor it hm, t he r out er s in ot her ar eas may not have t o r un it . Dykst r a r uns in
one ar ea onl y. ABR wil l have a minimum of t wo copies of t he Dykst r a, one f or each ar ea
it connect s t o.
Int er -Ar ea Rout ing

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 133
Information from Other Autonomous Systems
Inf or mat ion f r om ot her Aut onomous Syst ems
Uses t he ASBR.
Ot her ASs accor ding t o OSPF may simpl y be a RIP net wor k wit hin t he same
OSPF domain.
Ext er nal LSA used.
Type 1The pr ef er r ed r out e and used when consider ing t he int er nal cost of
t he AS.
Type 2Adver t ising t he same met r ic as was adver t ised by t he ASBR.
These ar e used t o cal cul at e t he shor t est pat h t o t he ASBR.
Now, what about t al king t o ot her aut onomous syst ems (out side of t he OSPF domain)?
Thr ough t he use of a special r out er t ypet he Aut onomous Syst em Boundar y Rout er
(ASBR)OSPF net wor ks can communicat e wit h ot her ASs. This adds anot her l evel of
hier ar chy t o t he OSPF r out ing. The f ir st is t he int r a-ar ea r out ing. The second l evel is
ar ea-t o-ar ea r out ing t hr ough t he backbone. The t hir d l evel is ext er nal aut onomous
syst ems.
ASBRs r un t he OSPF pr ot ocol and some t ype of Ext er ior Gat eway Pr ot ocol (such as
Bor der Gat eway Pr ot ocol def ined in RFC 1403, BGP, or even RIP). RIP is seen as an
ext er nal net wor k and it s r out es ar e impor t ed int o a Link St at e Dat abase as such. An
ext er nal AS need not be anot her AS in t he sense of a BGP. OSPF t r eat s any r out ing
pr ot ocol unl ike it sel f as an ext er nal AS. This t ype of pr ot ocol al l ows f or inf or mat ion
t o be exchanged bet ween ASs. The EGP t ype of pr ot ocol onl y r uns on t he int er f aces
t hat ar e bet ween t he ASs. OSPF r uns on t he int er f aces int er nal t o t he AS. An ASBR
does not have t o dir ect l y at t ach t o t he backbone.
To al l ow f or t his, anot her t ype of adver t isement is used, known as t he Ext er nal Links
Adver t isement . Each ASBR in t he AS gener at es one of t he adver t isement s. This is t he
onl y adver t isement t hat is f l ooded int o ever y ar ea in t he AS. These adver t isement s
descr ibe r out es t hat ar e ext er nal t o t he AS. Ther e is one ent r y f or ever y ext er nal
r out e. As you can see, t his coul d quickl y f il l up a r out ing t abl e wit h ext er nal r out es.
The ext er nal r out e uses one of t wo avail abl e t ypes of met r ics: Type 1 or Type 2. Type 1
met r ics ar e t he pr ef er r ed r out e and ar e used when consider ing t he int er nal cost of t he
AS. This means t hat Type 1 met r ics incl ude t he Link St at e Met r ic as wel l as t he met r ic
t hat was assigned t o it . Ther ef or e, any r out er t hat r eceives t his t ype of updat e f or an
ext er nal r out e must use t he int er nal (AS) met r ics t o r each t he ASBR adver t ising t hat
ext er nal r out e. So, t he comput at ion f or cost t o r each t hat r out e uses met r ics t hat ar e
int er nal t o t he AS and t he AS t hat was suppl ied in t he adver t isement .
Type 2 met r ics ar e t he same met r ics t hat wer e adver t ised by t he ASBR. Int er nal AS
met r ics ar e not added t o t he ASBR met r ic f or t he r out e when comput ing a pat h (based
on cost ) f or t hat ext er nal r out e. (t hat is, t o r each t he ASBR adver t ising t hat ext er nal
r out e).

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 134
Stub Areas
Ext er nal l ink adver t isement s coul d quickl y f il l up a r out ing t abl e. In some inst ances, a
major it y of t he ent r ies in t he r out ing t abl e wil l simpl y be r out es ext er nal t o t he OSPF
domain. Ther e is one ent r y f or ever y ext er nal r out e. As you can see, t his coul d quickl y
f il l up a r out ing t abl e wit h ext er nal r out es.
St ub ar eas wer e cr eat ed t o r educe t hese ent r ies. If an ar ea has a singl e ent r y or exit
point t o or f r om t hat ar ea t hat is used f or al l ext er nal t r af f ic, it can be conf igur ed as
a st ub ar ea. A st ub ar ea bl ocks t he impor t at ion of t he AS Ext er nal Link Adver t isement s
int o t he ar ea, t her eby r educing t he number of ent r ies in t he st ub ar eas dat abase.
St ub Ar eas

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 135
RFCs Related to OSPF
2178 DS: J. Moy, OSPF Ver sion 2, 07/22/97 (211 pages) (.t xt f or mat ) (obsol et es RFC 1583).
2154 ES: M. Mur phy, B. Badger , A. Wel l ingt on, OSPF wit h Digit al Signat ur es, 06/16/97
(29 pages) (.t xt f or mat ).
1850 DS: F. Baker , R. Col t un, OSPF Ver sion 2 Management Inf or mat ion Base, 11/03/95.
(80 pages) (.t xt f or mat ) (Obsol et es RFC 1253).
1793 PS: J. Moy, Ext ending OSPF t o Suppor t Demand Cir cuit s, 04/19/95 (31 pages) (.t xt
f or mat ).
1765 E: J. Moy, OSPF Dat abase Over f l ow, 03/02/95 (9 pages) (.t xt f or mat ).
1745 PS: K. Var adhan, S. Har es, Y. Rekht er , BGP4/IDRP f or IPOSPF Int er act ion,
12/27/94 (19 pages) (.t xt f or mat ).
1587 PS: R. Col t un, V. Ful l er , The OSPF NSSA Opt ion, 03/24/94 (17 pages) (.t xt f or mat ).
1586 I: O. deSouza, M. Rodr igues, Guidel ines f or Running OSPF Over Fr ame Rel ay
Net wor ks, 03/24/94 (6 pages) (.t xt f or mat ).
1585 I: J. Moy, MOSPF: Anal ysis and Exper ience, 03/24/94 (13 pages) (.t xt f or mat ).
1584 PS: J. Moy, Mul t icast Ext ensions t o OSPF, 03/24/94 (102 pages) (.t xt , .ps f or mat s).
1403 PS: K. Var adhan, BGP OSPF Int er act ion, 01/14/93 (17 pages) (.t xt f or mat )
(obsol et es RFC 1364).
1370 PS: Int er net Ar chit ect ur e Boar d, Appl icabil it y St at ement f or OSPF, 10/23/92 (2
pages) (.t xt f or mat ).

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 136
Static versus Dynamic Routing
The l ast t opic of discussion is t he abil it y of r out ing pr ot ocol s t o accept inf or mat ion f or
t heir t abl es f r om t wo sour ces: t he net wor k or a user .
Al t hough t he RIP pr ot ocol al l ows f or aut omat ic updat es f or r out ing t abl es, manual
ent r ies ar e st il l al l owed and ar e known as static entries. These ent r ies must be ent er ed
manual l y. A def aul t r out e is a st at ic ent r y. An endst at ion t hat is conf igur ed wit h a
def aul t r out er is said t o have a st at ic r out e ent r y. St at ic r out es can be conf igur ed t o
be incl uded or not incl uded in a dynamic updat e. St at ic r out es r ef er t o t he pr ocess of
manual l y pl acing an ent r y in t he t abl e. For any given r out er , t he net wor k
administ r at or may updat e t hat t abl e wit h a st at ic r out e. St at ic r out es over r ide
dynamic r out es.
St at ic t abl es have many disadvant ages. Fir st , as discussed ear l ier , st at ic t abl es ar e not
meant f or l ar ge net wor ks t hat incur many changes such as gr owt h. As t he t opol ogy
changes, al l t he t abl es must be manual l y r econf igur ed. Second, in t he case of r out er
f ail ur e, t he t abl es have no way of updat ing t hemsel ves. The r out e wil l be disabl ed, but
no al t er nat ive r out e is put in pl ace. Cisco empl oys a concept cal l ed a floating static route
t hat al l ows f or t his. Dynamic t abl es over come t he disadvant ages of st at ic ent r ies.
The pr imar y advant age t hat a st at ic ent r y may have is f or secur it y, f or st at ic t abl es
can be conf igur ed not t o br oadcast t heir r out es t o ot her r out er s. In t his way, user s can
cust omize t heir r out er s t o become par t icipant s on t he net wor k wit hout t heir net wor k
ident it y being br oadcast t o ot her r out er s on t he net wor k. St at ic r out es
St at ic ver sus Dynamic Rout ing
Ent r ies in a r out ing t abl e can be st at ic (manual l y ent er ed by t he net wor k
administ r at or ) or dynamic (l ear ned t hr ough a r out ing pr ot ocol such as RIP).
St at ic ent r ies:
In t he wor kst at ion f or eit her :
Def aul t Gat eway (r out er )used by indir ect r out ing
Pl ace a st at ic r out e in f or one t hat is not l ear ned t hr ough RIP,
et c.
In t he r out er :
Ent er ed as 0.0.0.0 and t he next hop (no subnet ) t o indicat e a def aul t
r out e
Rout er s can br oadcast t his inf or mat ion t o t heir net wor ks t o l et al l
know which is t he def aul t r out er al so al l ow a user t o updat e a r out ing
t abl e wit h a net wor k ent r y t hat wil l be used in endst at ions wit h t he
dynamic f unct ion t ur ned of f . This al l ows t he user t o maint ain t he
r out ing t abl e.
A def aul t r out er is one t hat al l ot her s l ook t o f or net wor ks
t hat ar e not in t heir t abl es
St at ic r out es can be used t o incr ease secur it y on t he net wor k
Any IP net wor k addr ess can be manual l y ent er ed int o t he r out ing t abl e
The r out er administ r at or suppl ies:
IP Net wor k addr ess
Subnet mask
Next hop int er f ace (t he IP addr ess of t he next r out er s int er f ace
t o get t o t hat net wor k)
St at ic ent r ies ar e al so used in var ious IP t opol ogies. For exampl e, in a hub-and-spoke
t opol ogy wher e a business has a cent r al ized cor por at e of f ice and many r emot e of f ices
(such as a bank), t her e r eal l y is no r eason t o f ul l y enabl e RIP at t he br anch of f ices.
Why not t ur n RIP suppl y (t he abil it y t o br oadcast r out es but not l ist en f or any) at t he
r emot e br anch and add a def aul t r out e, in t he r emot e br anch r out er , point ing t o t he
upst r eam r out er l ocat ed at t he cor por at e of f ice. In t his way, t he upst r eam r out er
dynamical l y l ear ns about al l t he r emot e of f ices (and l ear ns when t hey go away) and
t he br anch of f ice has one simpl e ent r y in it s t abl e (besides it s at t ached subnet s): a
def aul t r out e t o t he upst r eam r out er . Since t her e is no ot her pat h besides t hat one l ink
t o t he upst r eam r out er , t he r out er simpl y passes on any packet s t hat it r eceives f r om it s
at t ached wor kst at ion on t he net wor k. This r educes t he amount of memor y and
pr ocessor power needed at t he r emot e br anch, enabl ing a cheaper r out er t o be pl aced
out t her e.
This is al so an exampl e of why OSPF need not be t ur ned on f or a compl et e net wor k.
Ther e is no r eason what soever t o r un OSPF out at t he br anch of f ices; t her e ar e pl ent y
of r easons t o r un it at t he cor por at e of f ices. OSPF wil l simpl y pul l in t he RIP net wor ks
as ext er nal net wor ks (but t his coul d possibl y buil d l ar ge r out ing t abl es).

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 137
Remote Networks
Ther e ar e t imes when net wor ks must be connect ed when t hey ar e geogr aphical l y
separ at ed. This means t hat net wor ks cannot be connect ed by t he convent ional means of
a LAN int er connect . Imagine t r ying t o cabl e a net wor k t oget her wit h one subnet in
Cal if or nia and anot her in Vir ginia. Et her net cannot st r et ch t hat f ar . The onl y
f easibl e way of doing t his is by using some t ype of WAN ser vice f r om t he t el ephone
company. AT&T, MCI, and Spr int al l pr ovide WAN ser vices f or dat a net wor ks. They come
in many f or ms, but again, f or simpl icit y, t his book wil l expl ain point -t o-point ser ial
l ines. The choices avail abl e ar e Fr ame Rel ay, Swit ched Mul t imegabit Dat a Ser vice
(SMDS, pr imar il y used in met r opol it an ar eas and not cr oss count r y), Int egr at ed Ser vice
Digit al Net wor k (ISDN), or l eased l ines. For simpl icit y r easons, l eased l ines wil l be
expl ained her e. The sl ide shows net wor ks connect ed via ser ial l ines.
Just as t he r out er has physical connect or s t o connect t o a LAN, t he r out er has a
connect ion t hat enabl es t his t ype of connect ion. Inst ead of t he LAN int er f ace on t he
r out er , t he r out er wil l have a ser ial l ine int er f ace. The connect or f or t his is usual l y a
V.35, EIA-232 (f or mer l y RS-232-D), or an RS-449 connect or . The connect ion wil l t hen be
connect ed t o a device known as a Dat a Ser vice Unit /Cust omer Ser vice Unit (DSU/CSU).
This is a box t hat r eceives t he ser ial signal f r om t he r out er and r epeat s it t o t he
t el ephone swit ching of f ice.
The l eased l ine is a special l y condit ioned l ine t hat is pr ovided by t he phone company.
This l ine has been condit ioned t o handl e high-speed digit al t r af f ic. It is not t he nor mal
l ine t hat is used wit h voice swit ching. This l ine is per manent l y swit ched t o pr ovide a
connect ion bet ween t wo point s. Ther ef or e, it is somet imes cal l ed a point-to-point l ink. It is
anal ogous t o dial ing a number , r eceiving a connect ion, and never hanging up.
Remot e Net wor ks
The r out er at t he r emot e end wil l al so be at t ached t o a DSU/CSU. It wil l be abl e t o
r eceive t he signal s gener at ed at t he r emot e end. The t ypical speeds at which t hese l ines
r un var y. The most common ar e 56 Kbps and T1 (1 .544 Mbps) l ines, cal l ed leased lines
because t he cust omer does not own t he l ine. It is l eased f r om t he phone company and t he
r at es var y depending on t he l engt h of t he l ine. Rat es ar e usual l y cheaper f or shor t
r uns (t he ot her point of t he net wor k is a f ew mil es away) and mor e expensive f or l onger
r uns. Rat es al so var y depending on t he speed of t he l ine.
The ser ial l ine pr ovides a simpl e int er connect bet ween t wo r out er s t hat cannot be
connect ed dir ect l y by a LAN. The r eal pr obl em in using t hem in an IP int er net is t hat
t hey consume a f ul l net wor k number or a subnet number . Ther e have been met hods t o
over come t his using var iabl e-l engt h subnet masking, which is avail abl e wit h t he
r out ing al gor it hms of OSPF and RIPv2. Ot her wise, t hey gener al l y act as a f ul l net wor k
even when t her e ar e onl y t wo point s connect ed.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 138
Datagram Routing
Now t hat r out ing f undament al s, t he RIP and OSPF pr ot ocol s, and r out ing t abl es have
been discussed, t he sl ide shows a r out ed packet using dir ect and indir ect r out ing. This is
r egar dl ess of t he r out ing pr ot ocol . In t his sl ide, we can see t hat a PC (endst at ion A) is
t r ying t o pass a dat agr am t o a host machine, cal l ed host D. The host machine is one hop
(one r out er ) away. The IP l ayer of t he PC (endst at ion A) knows t hat it must use a
r out er (t he sour ce and dest inat ion net wor k addr esses ar e dif f er ent ), and wil l use RIP
or t he def aul t gat eway t o det er mine t he IP addr ess of t he r out er t o use. Upon
det er mining t he r out er s physical addr ess, it wil l physical l y (MAC l ayer ) addr ess t he
packet t o t he r out er at por t B. The sour ce and dest inat ion IP addr esses in t he IP header
of t his dat agr am wil l be t he PC as t he sour ce, and t he dest inat ion IP addr ess as t he
host . The sour ce (PC) and f inal dest inat ion (t he host ) IP addr esses wil l be embedded int o
t he IP header and wil l not change t hr oughout t he r out ing of t his dat agr am.
Dat agr am Rout ing
The r out er wil l r eceive t his packet and ext r act t he net wor k number f r om t he f inal
dest inat ion IP addr ess in t he r eceived IP header . The physical addr ess header s wil l be
st r ipped. The ext r act ed net wor k number wil l be compar ed t o t he r out er s int er nal
r out ing t abl e.
The r out er wil l det er mine t hat t he dest inat ion net wor k can be r eached dir ect l y
t hr ough one of it s por t s (t he dest inat ion net wor k is dir ect l y at t ached). The r out er wil l
det er mine t he dest inat ion st at ions physical addr ess t hr ough it s ARP t abl e (or it may
r equest it t hr ough t he ARP pr ocess). The r out er wil l t hen buil d a packet wit h t he
or iginal dat agr am sent by endst at ion A t o submit t o host D. The physical sour ce addr ess
wil l be t he r out er s, t he physical dest inat ion addr ess wil l be host Ds. The packet is
t hen t r ansmit t ed t o host D.
Not ice t hr oughout t his t hat onl y t he MAC addr esses changed; t he IP addr esses in t he IP
header st ayed t he same. The r out er wil l change t he TTL and t he CRC in t he IP header ,
but t hat is t he onl y t hing t hat changes in t he IP header .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Part Three
I nternet Protocol Version 6 (I Pv6)
Chapter 139
Introduction
The next IP. Ver sion 6. Compl et el y r edone IPv4. If you hear st at ement s l ike t his,
ignor e or cor r ect t hem. IPv6 is not a new net wor k l ayer pr ot ocol . Remember t his, if
anyt hing, about IPv6: It is an evol ut ionar y st ep f or IP. Cal mer heads pr evail ed dur ing
t he t wo year s of IPng wor king gr oup and IPv6 has become an ef f icient IPv4 t hat is
ext ensibl e.
IPv4 has pr oven t o be a r obust net wor k l ayer pr ot ocol and t her e have been ver y f ew
changes t o it over t he l ast 20 year s. The biggest pr obl em wit h IPv4 was t he addr essing,
and t hese ar e t he changes t hat wer e made. The addr essing has not changed, but t he
met hods of empl oying t he 32-bit addr essing have. IPv6 is a dir ect r esul t of t he shor t ages
of t he addr ess space of IPv4. IPv6 is not r evol ut ionar y. It is t he next st ep in t he
dat agr am del iver y pr ot ocol known as IP. It is not a r epl acement f or IPv4 per se, but
t her e ar e many new and some r evised f unct ions of t he pr ot ocol t hat impr ove upon it .
Cur r ent l y, t her e ar e enough f ixes and ext ensions t o t he IPv4 pr ot ocol (not t hat t her e
ar e many pr obl ems wit h t he pr ot ocol ) t o make it l ast wel l int o t he year 2000. I have
hear d over t he year s, why impl ement a new ver sion of IP when t his one is wor king just
f ine? IPv4 simpl y put a Band-Aid a pr obl em wit hin a t ime per iod of need t o f ur t her
enhance t he Int er net t o r each mor e peopl e and business r equir ement s.
As you r ead t hr ough t his sect ion, you shoul d st ar t t o under st and t hat t he t iming of
t his upgr ade t o IP is about r ight . The capabil it ies of IPv6 r equir e a much mor e
sophist icat ed comput er t han was r equir ed wit h IPv4. Gener al l y, IPv4 coul d r un on l ow-
power ed r out er s and endst at ions. The ver sat il it y of IPv6 wil l make use of t he higher -
power ed r out er s and wor kst at ions.
Int r oduct ion
An evol ut ion of IPv4.
Buil ds on IPv4.
Most not abl e change is addr ess changes t o 128 bit s.
Dynamic envir onment .
Requir es a much mor e sophist icat ed oper at ing envir onment .
Over 58 ot her pr ot ocol s have changed wit h it .
Wil l r un as isl ands using IPv4 as t he backbone.
Cannot simpl y f l ip a swit ch t o conver t .
When we changed IP, we did not change t he f unct ion of any ot her pr ot ocol again, t he
advant age of modul ar pr ot ocol s. TCP and UDP st ayed t he same. Yes, t he sof t war e cal l s
t o t he IP int er f ace ar e dif f er ent : t he socket int er f ace known as Ber kel ey socket s
(Unix), or f or PCs t he Winsock int er f ace. But t he basic f unct ions of TCP/UDP and t he
appl icat ions t hat use t hem ar e t he same. The ot her pr ot ocol s t hat have t o change ar e
t hose t hat dir ect l y int er f ace wit h IP. These ar e Domain Name Ser ver , DHCP, OSPF, RIP,
ICMP, and ot her s.
You wil l hear a l ot about IPv6 over t he next f ew year s, and IPv6 impl ement at ions wil l
cont inue t o r emain as isl ands in t he IPv4 Int er net . This is t he cor r ect appr oach f or IPv6.
You cannot f l ip t he swit ch as we did in Januar y 1983 wit h IPv4. The Int er net of t oday
is ext r emel y l ar ge and ver y commer cial . Ther e ar e st il l quit e a f ew st udies in pr ogr ess
t o det er mine IPv6 addr essing al l ocat ion, ef f ect s of IPv6 on IPv4 net wor ks, t unnel ing,
and so on. Sl ow-but -sur e impl ement at ion. Test bef or e impl ement ing. Appl y appl icat ions
t hat have a need in t he mar ket pl ace t o IPv6. Wor k out t he kinks bef or e
commer cial izat ion.
What ever happened t o IPv5? Wel l , it exist s and is known as t he Int er net St r eam
Pr ot ocol (ST2) and is def ined in RFC 1819. ST2 is an exper iment al r esour ce r eser vat ion
pr ot ocol int ended t o pr ovide end-t o-end r eal -t ime guar ant ees over an int er net . It
al l ows appl icat ions t o buil d mul t idest inat ion simpl ex dat a st r eams wit h a desir ed
qual it y of ser vice. The r evised ver sion of ST2 specif ied in RFC 1819 is cal l ed ST2+.
ST2 oper at es at t he same l ayer as connect ionl ess IP. It has been devel oped t o suppor t
t he ef f icient del iver y of dat a st r eams t o singl e or mul t ipl e dest inat ions in appl icat ions
t hat r equir e guar ant eed qual it y of ser vice. ST2 is par t of t he IP pr ot ocol f amil y and
ser ves as an adjunct t o, not a r epl acement f or , IP. The r evised ver sion of ST2 specif ied in
RFC 1819 is cal l ed ST2+. The main appl icat ion ar eas of t he pr ot ocol ar e t he r eal -t ime
t r anspor t of mul t imedia dat a (e.g., digit al audio and video packet st r eams, dist r ibut ed
simul at ion/gaming) acr oss int er net s. ST2 can be used t o r eser ve bandwidt h f or r eal -t ime
st r eams acr oss net wor k r out es.
IPv6 (cont inued)
IPv5 exist s and is known as t he St r eams 2 (ST2) Pr ot ocol :
RFC 1819
Oper at es at t he same l ayer as IP
Devel oped as an IP l ayer f or r eal -t ime appl icat ions
Incl udes QoS capabil it ies
IPv6 t r ul y wor ks on t he f iner aspect s of IPv4.
Requir es a dynamic envir onment :
Many discover y opt ions, incl uding:
Aut oconf igur at ion
Finding t he maximum pat h MTU
Finding ot her wor kst at ions wit hout ARP
Finding r out er s
The f oundat ion of IPv6 is IPv4. Like most gr eat t hings in l if e, you buil d upon a
f oundat ion, somet hing t hat you know wor ks. Car s, over t he year s, ar e st il l buil t in t he
same f ashion and st il l have t ir es, t r ansmissions, engines, and bodies. But af t er many
year s, t he ext ensions of t hose basics have l ed t o mor e t han just basic t r anspor t at ion.
Many ef f iciencies and add-ons have been appl ied t o t he basic car t o make it saf er , bet t er
f or t he envir onment , and so f or t h.
The biggest change t hat you wil l not ice t hr oughout t his t ext is t he wor d dynamic.
Rout er s and host s discover y each ot her dynamical l y, host s can conf igur e t hemsel ves
dynamical l y. Ther e is even a r epl acement f or t he DHCP pr ot ocol t hat enf or ces (and
ef f icient l y uses) IP addr essing. And, of cour se, t he biggest change of al l f or IP: t he
addr ess! Pl acing IPv6-capabl e nodes on a net wor k wit h ot her IPv6 nodes and IPv6
r out er s wil l enabl e an IPv6 net wor k t o be est abl ished immediat el y via dynamics.
Neighbor discover y pr ot ocol s init iat e and f ind t he nodes on t he net wor k, nodes can
aut oconf igur e t heir addr esses, and r out er s simpl y have t o have t heir int er f aces
conf igur ed and enabl ed, and of f we go. IPv4 net wor ks pr evail , however ; pr obabl y about
99.99 per cent of al l net wor ks ar e IPv4. Ther ef or e, we must make IPv6 wor k wit hin t he
bounds of t he exist ing IPv4 net wor k.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 140
IPv6 Features
IPv6 Feat ur es
Ext ended addr essing capabil it ies.
Header f or mat simpl icat ion.
Impr oved suppor t f or ext ensions and opt ions.
Fl ow l abel capabil it y.
Aut hent icat ion and pr ivacy capabil it ies.
IPv6 r out ing simil ar t o IPv4 r out ing using CIDR.
OSPF, RIP, IDRP, and IS-IS can be used wit h minor modif icat ions
Widespr ead impl ement at ion of IPv6 wil l be phased in f or t he next coupl e of year s. IPv6
is up and r unning t oday, however , t hr ough a ser ies of isl ands t hat r un aut onomousl y
and al so use par t of t he cur r ent IPv4 Int er net . It is known as t he 6Bone and compl et e
inf or mat ion can be f ound at :
www.6bone.net .
IPv6 can be gr ouped int o t he f ol l owing cat egor ies:
Expanded addr essing capabil it ies. IPv6 incr eases t he IP addr ess size f r om 32 bit s
t o 128 bit s t o suppor t mor e l evel s of addr essing hier ar chy, a much gr eat er number
of addr essabl e nodes, and simpl er aut oconf igur at ion of addr esses. Ther e ar e t hr ee
t ypes of addr esses: unicast , anycast , and mul t icast . The scal abil it y of mul t icast
r out ing is impr oved by adding a scope f iel d t o mul t icast addr esses. Ther e is no
br oadcast addr ess def ined.
Header f or mat simpl if icat ion. To make IPv6 mor e ef f icient , some of t he header
f iel ds have been dr opped and t he header is a st at ic 40 byt es.
Impr oved suppor t f or ext ensions and opt ions. Since t he IP header is a st at ic 40
byt es and changes in t he header cannot be made, t he concept of header ext ensions
is in. This pr ovides gr eat er f l exibil it y f or int r oducing new opt ions in t he f ut ur e.
Fl ow l abel ing capabil it y. A new capabil it y is added t o enabl e t he l abel ing of
packet s bel onging t o par t icul ar t r af f ic f l ows f or which t he sender r equest s
special handl ing, such as nondef aul t qual it y of ser vice or r eal -t ime ser vice.
Aut hent icat ion and pr ivacy capabil it ies. Added suppor t f or aut hent icat ion,
dat a int egr it y, and opt ional dat a conf ident ial it y t hr ough t he ext ensions.
IPv6 r out ing uses t he concept of pr ef ix r out ing. Ever y addr ess has an associat ed pr ef ix
which is simpl y a mask ident if ier t o indicat e how many of t he bit s, st ar t ing f r om t he l ef t
ar e used f or r out ing and how many bit s ar e used t o ident if y a host . The r out er s wil l use
t he pr ef ix in or der t o buil d r out ing t abl es. End st at ions make t he pr ef ix simil ar t o
t odays subnet mask.
The exist ing r out ing pr ot ocol s can empl oy IPv6 addr esses as wel l . Ther e is no need t o
specif ical l y upgr ade your net wor k t o empl oy Int er domain Rout ing Pr ot ocol t o use IPv6.
The exist ing r out ing pr ot ocol s most l y have t o change t o under st and 128-bit addr essing.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 141
From IPv4 to IPv6
IPv6 was not t he r esul t of one meet ing. Many pr oposal s wer e devel oped and al gor it hms
wer e exper iment ed wit h bef or e being pr esent ed.
One pr oposal t hat had a l ot of suppor t want ed t o r epl ace IP wit h t he ISO
(Int er -nat ional Or ganizat ion f or St andar dizat ion) OSI CLNP Pr ot ocol . ISO
CLNP (Connect ionl ess Pr ot ocol ), which was demonst r at ed as TUBA (TCP
and UDP over Bigger Addr esses. RFCs 1247, 1526, and 1561).
Wit h many changes t o t he TCP and IP l ayer s, IP ver sion 7 (al so known as
TP/IX. RFC 1475) event ual l y evol ved int o t he CATNIP (RFC 1707).
IP in IP evol ved int o IPAE (IP Addr ess Encapsul at ion). It pr oposed r unning
t wo l ayer s of t he IP pr ot ocol , one f or t he wor l dwide backbone and one f or
t he r egional IP net wor ks. This event ual l y evol ved int o Simpl e IP, or SIP.
This moved t he addr ess t o 64 bit s and did away wit h some of t he unused
f eat ur es of ICMP.
Dur ing 1992 and 1993, t he Pip int er net pr ot ocol , devel oped at Bl eacher , was
one of t he candidat e r epl acement s f or IP. It had many impr ovement s in
r out ing st r at egies and in mid-1993, Pip was mer ged wit h t he Simpl e Int er net
Pr ot ocol (SIP), cr eat ing SIPP (SIP Pl us).
SIPP (RFC 1710) is a new ver sion of IP designed t o be an evol ut ionar y st ep
f r om IPv4. It can be inst al l ed as a nor mal sof t war e upgr ade in int er net
devices and is int er oper abl e wit h t he cur r ent IPv4.
Fr om IPv4 t o IPv6
Buil t up t o t he IPv6 specif icat ion t hat we have t oday using var ious pr oposal
submissions such as:
ISO CLNPdemonst r at ed as TUBA (TCP and UDP over Bigger Addr esses)
IP ver sion 7 (aka TP/IX, RFC 1475)
IP in IPevol ved t o IP addr ess encapsul at ion
PIPmer ged int o SIP cr eat ing SIPP (RFC 1710)
Whil e it is t r ue t hat IPv6 sol ves t he addr essing pr obl em, as you can see f r om t he
pr eceding l ist , it has a f ew ot her pr oper t ies t hat impr oved upon t he IPv4 pr ot ocol .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 142
IP Version Numbers According to RFC 1700
The f ol l owing t abl e ident if ies t he IP ver sion number s. Ther e ar e mor e t han you
pr obabl y t hought !
IP Ver sion Number s Accor ding t o RFC 1700
Decimal Keywor d Ver sion Ref er ences
0 Reser ved
13 Unassigned
4 IP Int er net Pr ot ocol RFC 791
5 ST ST Dat agr am Mode RFC 1190, JWF
6 IPv6 RFC 1883
7 TP/IX TP/IX: The Next
Int er net
8 PIP The P Int er net
Pr ot ocol
9 TUBA TCP and UDP over
Bigger Addr esses
1014 Unassigned
15 Reser ved156

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 143
IPv6 Header
Not ice t he dif f er ences bet ween IPv4 and IPv6 header s. IPv6 seems t o be missing a f ew
opt ions, but t hey ar e t her e; t hey just cannot be seen (yet !). In f act , t he onl y f iel d t hat
seems t o not have changed or moved posit ions is t he VERS f iel d. This f iel d was t o pl ay a
gr eat r ol e. It was going t o be used as t he del ineat ing f act or t o det er mine if a r eceived
IP packet was based on IPv4 or IPv6. In ot her wor ds, t he Et her Type f iel d of an Et her net
packet woul d r emain as 0800(h) and t he ver sion f iel d of t he header woul d det er mine t he
pr ocessing of a r eceived IP dat agr am. This changed and IPv6 has it s own Type (f or
Et her net packet s) f iel d: 86DD(h) (and SAP in IEEE 802 net wor ks).
The int er net pr ot ocol (ver sion 4) uses f our key mechanisms t o pr ovide it s ser vice: Type of
Ser vice (TOS), Time t o Live (TTL), Opt ions, Fr agment at ion, Pr ot ocol and Header
Checksum. However , in l ooking at t he sl ide, t hese f iel ds ar e missing.
These mechanisms wer e pr eviousl y discussed, but t he opt ions f iel d is f ur t her descr ibed
her e. The Opt ions pr ovide f or cont r ol f unct ions needed or usef ul in some sit uat ions but
unnecessar y f or t he most common communicat ions. The opt ions incl ude pr ovisions f or
t imest amps, secur it y, and special r out ing (st r ict and l oose sour ce r out enot hing t o do
wit h Token Ring). However , over t he year s, it was not iced t hat t hese opt ions f iel ds wer e
not being used by t he major it y of Int er net host s f or var ious r easons. Fir st , IP dat agr ams
t hat cont ain opt ions cannot be simpl y f or war ded; t hey r equir e special at t ent ion. They
ar e pl aced in anot her queue and t he r out er oper at es on t his queue separ at el y f r om t he
r eceived dat agr am queue. Second, if t he opt ions f iel ds wer e not used ver y of t en, many
impl ement er s of r out er s did not opt imize t heir sof t war e t o oper at e on dat agr ams t hat
incl uded special opt ions. This gener al l y r esul t ed in a per f or mance penal t y on t he
r out er .
IPv6 Header
So, why have t hem? Wel l , t heir f unct ions are used in some cases. IP mul t icast ing, f or
exampl e, uses t he l oose sour ce r out e opt ion when incor por at ing t he t unnel ing
mechanism f or DVMRP (r ef er t o Par t V, Mul t icast ing, t o under st and mor e IPv6
decided t o al l ow f or it t o be ext ensibl e, so IPv6 impl ement s t he concept of an extension
header.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 144
IPv4 Options A Review
IPv4 Opt ions A Review
Secur it y
Loose sour ce r out ing
St r ict sour ce r out ing
Recor d r out e
St r eam ID
Int er net t imest amp
Wit h t he IP header becoming f ixed, al l of t he opt ions f iel ds in t he header wer e not
el iminat ed compl et el y, t hey mer el y changed f or ms. Basical l y, IPv4 opt ions ar e now IP
header ext ensions. The f ol l owing ar e t he IPv4 opt ions:
Secur it y. Used t o car r y secur it y, compar t ment at ion, user gr oup (TCC), and
handl ing r est r ict ion codes compat ibl e wit h DOD r equir ement s.
Loose sour ce r out ing. Var iabl e in l engt h and used t o r out e t he int er net
dat agr am based on inf or mat ion suppl ied by t he sour ce. Not al l t he r out ing hops
wil l be in t his f iel d. This opt ion al l ows some f l exibil it y in pr oviding a pat h.
St r ict sour ce r out ing. Var iabl e in l engt h and used t o r out e t he int er net
dat agr am based on inf or mat ion suppl ied by t he sour ce. The r out ing inf or mat ion
pr ovided in t his f iel d must be expl icit l y f ol l owed.
Recor d r out e. Var iabl e in l engt h and used t o t r ace t he r out e an int er net
dat agr am t akes.
St r eam ID. Used t o car r y t he st r eam ident if ier .
Int er net t imest amp. The t imest amp is a r ight -just if ied, 32-bit f iel d t hat indicat es
a t ime in mil l iseconds since midnight UT (Univer sal Time). Ther e ar e pl acehol der s
f or mul t ipl e t imest amps and a f l ags f iel d t o indicat e t imest amps onl y. A t imest amp
is pr eceded wit h t he int er net addr ess of t he r egist er ing ent it y, t he int er net
addr ess f iel ds ar e pr especif ied, or an IP modul e onl y r egist er s it s t imest amp if it
mat ches it s own addr ess wit h t he next specif ied int er net addr ess. This can be used
f or measur ement s of t he t r anspor t l ayer pr ot ocol s and ot her ut il it ies.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 145
IPv4 and IPv6 Header Differences
The f ir st t hing t o not ice about t he IPv6 header is t hat it is a st at ic 40 byt es in l engt h.
The l engt h of t he packet header is not var iabl e in l engt h. The checksum was r emoved.
IP f ir st r an over copper ser ial l ines t hat t ended t o be noisy (st at ic in voice speak).
Checksums ar e al l over t he TCP/IP pr ot ocol suit e and al l over t he access met hods of
FDDI, Et her net , and Token Ring. The r emoval of t he checksum al so al l owed f or al l
syst ems t hat f or war ded IP dat agr ams t o speed up because t hey do not have t o comput e
t he checksum at ever y hop.
Ipv4 and Ipv6 Header Dif f er ences
IPv6 header is a st at ic 40 byt es in l engt h.
Tot al l engt h f iel d is r epl aced wit h payl oad l engt h.
IPv6 al l ows f or jumbogr ams (l ar ger t han 64k).
Ext ension header s.
TTL f iel d is r epl aced wit h t he hop l imit .
Many IPv4 opt ions wer e moved t o independent pr ot ocol s.
IPv4s t ot al -l engt h f iel d is r epl aced wit h a payl oad l engt h. No signif icant changes her e
except t hat IPv6 is a st at ic 40 byt es, so t he payl oad l engt h is t r ul y a measur ement of t he
payl oad and t he IPv6 header is not incl uded as par t of t he sum. This f iel d is 16 bit s in
l engt h, which al l ows f or a maximum of 65,355 byt e payl oad. However , IPv6 al l ows f or a
new concept known as jumbo datagrams (jumbogr ams), which al l ows f or var ious net wor k
at t achment s such as I/O connect ions bet ween high-speed comput er s t hat can pr ocess
dat a segment s higher t han 64k (see RFC 2146).
One of t he mor e int er est ing changes t o IP wit h ver sion 6 is t he concept of concatenated
headers. This is accompl ished using t he next header f iel d on t he IPv6 header . In IPv6, t he
pr ot ocol t ype f iel d is set and t hat header woul d immediat el y f ol l ow. For exampl e, if
t he payl oad was UDP t hen t he pr ot ocol t ype is set t o 17(decimal ) and t he UDP header
woul d immediat el y f ol l ow.
The Time t o Live (TTL) f iel d is one of t he mor e ver sat il e f iel ds in IP. It is used t o pr event
dat agr ams f r om const ant l y l ooping, keep packet s on a l ocal net wor k, used in mul t icast
dat agr ams t o indicat e scope (hear ing r ange), and pr obabl y has many ot her pr ivat e uses
as wel l . In IPv6, t his f iel d is r enamed t o Hop Limit , because it is r eal l y used as a count -
down-by-1 count er . The or iginal int ent ion of t he f iel d was t o indicat e a t ime (in
seconds). It coul d be used, f or exampl e, by a r out er . If t he r out er cannot f or war d t he
packet wit hin t he amount of t ime indicat ed in t he TTL f iel d, it shoul d discar d t he
dat agr am and gener at e an ICMP message. However , over t ime, most r out er del ays wer e
measur ed in mil l iseconds, not seconds. The accept ed decr ement of t he f iel d was set t o 1,
and t her ef or e became a hop count and not an indicat ion of t ime.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 146
IPv6 Extension Headers
Since t he f iel ds on t he pr eceeding sl ide wer e del et ed f r om use in t he IPv6 header how
do we cont inue t heir use? For exampl e, how do we indicat e t he pr ot ocol of t he next
header ?
The IPv6 header is st r aight f or war d. Some of t he opt ions f or IPv4 wer e bet t er ser ved by
ot her TCP/IP pr ot ocol s and some wer e kept as a par t of IPv6 and ar e now known as IPv6
ext ension header s. These ext ension header s al l ow f or IPv6 t o become ext ensibl e beyond
a specif ied (and l imit ed) opt ions f iel d. It can be modif ied at l at er dat es t o incl ude ot her
opt ions. The cur r ent IPv6 specif icat ion cal l s f or t he f ol l owing header s (in t he or der
t hey shoul d appear in t he dat agr am):
IPv6 header (not dir ect l y par t of t he ext ensions but shown her e t o show header
or der ).
Hop-by-Hop Opt ions (RFC 1883). The Hop-by-Hop Opt ions header is used t o car r y
opt ional inf or mat ion t hat must be examined by ever y node al ong a packet s
del iver y pat h. One of t he opt ions is t he jumbo dat agr am opt ion.
Dest inat ion Opt ions (RFC 1883). The Dest inat ion Opt ions header is used t o car r y
opt ional inf or mat ion t hat needs be examined onl y by a packet s dest inat ion
node(s).
Rout ing (Type 0) (RFC 1883). The Rout ing header is used by an IPv6 sour ce t o l ist
one or mor e int er mediat e nodes t o be visit ed on t he way t o a packet s
dest inat ion. This f unct ion is ver y simil ar t o IPv4s Sour ce Rout e opt ions.
Fr agment (RFC 1883). The Fr agment header is used by an IPv6 sour ce t o send
packet s l ar ger t han woul d f it in t he pat h MTU t o t heir dest inat ions.
Aut hent icat ion (RFC 1826).
Encapsul at ing Secur it y Payl oad (RFC 1827).
Upper -l ayer header . (not par t of t he ext ension header , but shown her e t o show
or der ).
IPv6 Ext ension Header s
Fr om end-t o-end communicat ion, t hese f iel ds shoul d be ignor ed by al l st at ions t hat may
r eceive it . These f iel ds ar e gener al l y buil t and consumed by t he sour ce and dest inat ion
st at ions onl y. The except ion is t he hop-by-hop opt ions f iel d, which may be r eviewed by
r out er s in t he pat h t o t he dest inat ion.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 147
Fragmentation
Anot her missing f iel d deal s wit h f r agment at ion was discour aged in IPv4. It cont inues t o
be discour aged in IPv6, but t he onus of pr ot ocol was passed t o t he sour ce node inst ead of
t he r out er , l ike in IPv4. In or der t o send a packet t hat is t oo l ar ge t o f it in t he MTU of
t he pat h t o it s dest inat ion, a sour ce node may divide t he packet int o f r agment s and send
each f r agment as a separ at e packet , t o be r eassembl ed at t he dest inat ion.
Fr agment at ion causes pr obl ems mainl y due t o ef f iciency of t he r out er s and endst at ions.
Any missing f r agment causes t he whol e TCP segment t o be r et r ansmit t ed (RFC 1122, page
58). This cr eat es bandwidt h pr obl ems, memor y pr obl ems, and CPU cycl es. In IPv4 it
consumes consider abl e r esour ces on t he r out er (f r agment at ion) and host (r eassembl y).
IPv6 encour ages impl ement ing RFC 1191. This is t he specif icat ion f or dynamic path MTU
discovery, or having t he host dynamical l y f ind out maximum packet sizes f or t he pat h t o
t he dest inat ion (t hat is, det er mine t he net wor ks t hat t he dat agr am wil l t r ansit ). MTU
is t he acr onym f or maximum transmit unit, or how l ar ge a dat agr am can I t r ansmit t o t he
dest inat ion st at ion. By enabl ing t his, we el iminat e t he packet ident if icat ion, t he
cont r ol f l ags, and t he f r agment of f set . Any l ost f r agment means al l t he f r agment s in
t he segment must be r et r ansmit t ed (RFC 1122, page 58).
Fr agment at ion
Most host s simpl y avoid t he pr obl em of discover ing t he maximum size of a packet on t he
dest inat ion pat h (if not l ocal ) and set t he packet size t o 576 byt es (t he accept ed
minimum packet size f or most IP net wor ks), even t hough RFC 1191 pr esent s a simpl e way
t o det er mine t his. Some impl ement at ions t r ansmit a l ar ge packet and wait t o see if an
ICMP dat agr am t oo big message is r et ur ned. The or iginat ing host wil l r et ur n t o using
576-byt e packet s. Picking t he r ight size is a ver y compl ex mat t er and most host s st ick t o
576 byt es f or nonl ocal dest inat ion host s.
This el iminat es f r agment at ion and associat ed pr obl ems. However , t his al so cr eat es an
inef f iciency in t hat some net wor ks al l ow f or l ar ge packet sizes. Imagine t r ansf er r ing
inf or mat ion bet ween Token Ring net wor ks separ at ed by an FDDI backbone. Not al l
net wor ks ar e Et her net . Why move t he size down t o 512 byt es just because t he dat a
t r aver ses r out er s? Ther e can be consider abl e consequences if t he f il e is 100 Mbyt es in
l engt h. Ther ef or e, MTU discover y is mor e ef f icient t han f r agment at ion by spr eading t he
r esponsibil it y ar ound t o mul t ipl e ent it ies.
Pat h MTU discover y is discussed in RFC 1191. It changed par t of t he ICMP RFC 793 in
t hat it r ecommends using one of t he pr eviousl y unused header f iel ds as t he next -hop
MTU-size indicat or . This is an int er est ing aspect of ICMP f or IPv6 in t hat it r eal l y does
impr ove upon pr evious exper ience and knowl edge and does not int end t o r epl ace.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 149
IPv6 Addressing
The addr essing of IPv6 is pr obabl y t he best -known f eat ur e of IPv6. Ask anyone about
t he dif f er ences bet ween IPv4 and IPv6, and t he f ir st r esponse wil l be t he change f r om 32-
bit t o 128-bit addr essing. Whil e it is t r ue t hat t he addr essing was changed t o 128 bit s,
t her e ar e many mor e f eat ur es about t he addr ess space and it s al l ocat ion t hat wer e
car ef ul l y cr af t ed. The f ir st expansion of t he addr ess space was t o 64 bit s. It was l at er
incr eased t o 128 bit s. It was pr oven t hat 64 bit s was easil y adequat e but 128 bit s was t he
f inal out come. IPv6 addr esses pr ovide t he same f unct ion as IPv4: ident if ier s f or
int er f aces and set s of int er f aces. Even t hough 128 bit s ar e wr it t en f or use, cur r ent l y
onl y 15 per cent of t he avail abl e addr ess space is al l ocat ed f or use. Ther e ar e t hr ee
t ypes of addr esses:
Unicast . An ident if ier f or a singl e int er f ace. A unique addr ess del iver ed t o a
singl e dest inat ion.
Anycast . New f or IP (ver sion 6), an anycast addr ess is an ident if ier f or a set of
int er f aces (t ypical l y bel onging t o dif f er ent nodes). This is simil ar t o a mul t icast ,
but a packet sent t o an anycast addr ess is del iver ed t o one of t he int er f aces
ident if ied by t hat addr ess (t he near est one, accor ding t o t he r out ing pr ot ocol s
measur e of dist ance).
Mul t icast . An ident if ier f or a set of int er f aces (t ypical l y bel onging t o dif f er ent
nodes). A packet sent t o a mul t icast addr ess is del iver ed t o al l int er f aces
ident if ied by t hat addr ess.
IPv6 Addr essing
Unicast ident if ies a singl e int er f ace.
Anycast new f or IPv6, it ident if ies a set of int er f aces usual l y bel onging t o
dif f er ent nodes. Used t o del iver dat agr ams t o t he near est of t he int er f aces.
Mul t icast an ident if ier bel onging t o a gr oup of int er f aces. IPv6 ext ensivel y
uses t he mul t icast int er f ace.
Ther e is no br oadcast addr ess in IPv6.
In IPv6, a br oadcast addr ess is not def ined. It was super seded by mul t icast addr esses.
In IPv4, we ident if ied addr esses by t heir 32-bit val ue, nor mal l y, wr it t en in a f or m known
as dotted-decimal notation; f or exampl e, 132.1.8.10. An IPv6 addr ess is wr it t en in
hexadecimal and consist s of gr oupings of 8 cont aining 4 hexadecimal digit s or 8 gr oups of
16 bit s each. This t akes t he f or m:
xxxx : xxxx : xxxx : xxxx : xxxx : xxxx : xxxx : xxxx
FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 is an exampl e of an IPv6 addr ess. Anot her
exampl e is t he f ol l owing unicast addr ess:
1080:0000:0000:0000:0008:0800:200C:417A
Since wr it ing an IPv6 addr ess has become unwiel dy (DNS becomes ver y impor t ant her e),
t her e ar e pr ovisions al l owed t o condense t he addr ess int o it s smal l est avail abl e f or m.
Ther ef or e, t he pr eceding unicast addr ess can be compr essed int o:
1080:0:0:0:8:800:200C:417A
or even
1080::8:800:200C:417A
The doubl e col on has special signif icance. It is a demar cat ion point f or compr essing
l eading 0s. Not ice her e t hat onl y l eading 0s can be compr essed and t he :: symbol can be
used onl y once dur ing t he compr ession.
Ther ef or e if you had t he addr ess of :
1080:0:0:5698:0:0:9887:1234
you cannot wr it e it as:
1080::5698::9887:1234
The al gor it hm t hat r uns t he expansion f or t he addr ess woul d get conf used. How many
0s go in each of t he col on-compr essed sl ot s? The cor r ect way t o compr ess t his addr ess
woul d be t o compr ess one or t he ot her sides.
IPv6 Addr essing (cont inued)
1080::5698:0:0:9887:1234 or 1080:0:0:5698:: 9887:1234164
As wit h IPv4, t he f ir st f ew bit s of t he IPv6 addr ess t el l s somet hing about t he addr ess
(t his has not hing t o do wit h Cl ass addr essing). The t abl e in Sect ion 165 shows t his. This
t ime we ar e not deal ing wit h cl asses or addr esses, mor e so wher e t he addr ess has been
assigned an addr ess t ype and is known as t he f or mat pr ef ix.
To get t he amount of space used is simpl e. The f or mul a is 1 / 2
n
X, wher e x is t he number
of bit s used. For exampl e, if t he f ir st 8 bit s ar e 0000 0000, t hen t his is 1 / 2
n
8, or 1/256.
IPv6 Addr essing (cont inued)
The f ir st f ew bit s ar e indicat or s (as shown in a moment ).
They do not r egist er as a Cl ass of addr ess as in IPv4.
Simil ar t o CIDR, pr ef ixes ar e used t o indicat e t he r out ing.
Special addr esses ar e r eser ved:
Unspecif ied addr ess
Loopback addr ess
Embedded IPv4 addr ess
Mul t icast addr ess
Pr ef ixes ar e al so used in t his envir onment just l ike in t he CIDR envir onment . A /30
indicat es t he f ir st 30 bit s ar e used f or r out ing. Al so not ice t hat f iel ds in cer t ain t ypes
of addr esses ar e given names t o f ur t her ident if y t he subaddr ess por t ions. Ref er t o sl ide
165 f or an exampl e.
Ther e ar e t hr ee addr ess t ypes t hat ar e assigned out of t he 0000 0000 f or mat pr ef ix space.
These ar e t he unspecif ied addr ess, t he l oopback addr ess, and t he IPv6 addr esses wit h
embedded IPv4 addr esses. This al l ocat ion suppor t s t he dir ect al l ocat ion of pr ovider
addr esses, l ocal use addr esses, and mul t icast addr esses. Space is r eser ved f or NSAP
addr esses, IPX addr esses, and geogr aphic addr esses. The r emainder of t he addr ess space is
unassigned f or f ut ur e use. This can be used f or expansion of exist ing use (e.g., addit ional
pr ovider addr esses, et c.) or new uses (e.g., separ at e l ocat or s and ident if ier s).
A val ue of FF (11111111) ident if ies an addr ess as a mul t icast addr ess; any ot her val ue
ident if ies an addr ess as a unicast addr ess. Mul t icast addr esses ar e used ext ensivel y
t hr oughout aut oconf igur at ion of addr esses and neighbor discover y. Anycast addr esses
ar e t aken f r om t he unicast addr ess space, and ar e not synt act ical l y dist inguishabl e
f r om unicast addr esses.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 150
IPv6 Addressing Prefix
IPv6 Addr essing Pr ef ix
Al l ocat ion Pr ef ix (binar y) Fr act ion of Addr ess
Space
Reser ved 0000 0000 1/256
Unassigned 0000 0001 1/256
Reser ved f or NSAP
Al l ocat ion 0000 001 1/128
Reser ved f or IPX
Al l ocat ion 0000 010 1/128
Unassigned 0000 011 1/128
Unassigned 0001 1/16
Unassigned 001 1/8
Pr ovider -based
Unicast addr ess 010 1/8
Unassigned 011 1/8
Reser ved f or geogr aphic-based
unicast addr esses 100 1/8
Unassigned 101 1/8
Unassigned 110 1/8
Unassigned 1110 1/16
Unassigned 1111 1110 0 1/512
Link l ocal use
Addr esses 1111 1110 10 1/1024
Sit e Local Use Addr esses 1111
1110 11 1/1024
Mul t icast Addr esses 1111 1111 1/256166

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 151
6Bone Test Addressing
Ther e is an addr ess t hat is r eser ved f or t est ing IPv6 on t he IPv6 Backbone (6Bone). The
f ol l owing sl ide shows t he IPv6 (6Bone) t est addr essing as assigned by IANA.
6Bone Test Addr essing

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 152
Provider-Based IPv6 Addressing
Like t odays int er net , IP addr esses wil l be handed out by an int er net ser vice pr ovider
(an ISP such as MindSpr ingt m, MCIt m, AT&Tt m, Concent r ic Net wor kst m, and any of t he
ot her t housands of int er net connect ivit y pr ovider s out t her e). Connect ion of a
commer cial ent it y dir ect l y t o t he Int er net wil l not be al l owed, unl ess t hat ent it y is
an ISP. The addr ess shown on t his sl ide was ext r act ed f r om t he pr evious sl ide f or it is
t he most common addr ess f or mat t hat wil l be used (except f or t he mul t icast addr esses).
The f ir st 3 bit s ident if y t he addr ess as a pr ovider -or ient ed unicast addr ess. The registry ID
ident if ies t he int er net addr ess r egist r y (cur r ent l y Int er NIC [f or t he Amer icas], APNIC
[f or Asia-Pacif ic], and RIPE [f or Eur ope] which assigns pr ovider ident if ier s, indicat ed by
t he provider ID f iel d, t o int er net ser vice pr ovider s, which t hen assigns por t ions of t he
addr ess space t o subscr iber s. This is a pr ocess simil ar t o t he addr ess assignment pol icy
used wit h CIDR and descr ibed in RFC 2050. The subscriber ID dist inguishes among mul t ipl e
subscr iber s at t ached t o t he int er net ser vice pr ovider ident if ied by t he pr ovider ID. This
is l ike a cust omer number . The subnet ID ident if ies a specif ic physical l ink. Ther e can be
mul t ipl e subnet s on t he same physical l ink; however , a specif ic subnet cannot span
mul t ipl e physical l inks. The interface ID ident if ies a singl e int er f ace among t he gr oup of
int er f aces ident if ied by t he subnet pr ef ix.
Pr ovide-Based IPv6 Addr essing

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 153
Local-Use IPv6 Addressing
This addr essing is used exact l y as t he name impl ies: l ocal l y. This can be subnet l ocal or
subscr iber l ocal , which gives t he t wo names link local and site local. The sl ide shows t he
f or mat of t hese t wo addr essing t ypes. Not ice t hat bot h addr essing t ypes use t he
r eser ved pr ef ix f or mat of FE.
This is an indicat or , if you wil l , such t hat t he int er net wil l not at t empt t o r out e
packet s t hat ar e designat ed as l ocal . You can t hink of t hese addr esses as t he pr ivat e
addr esses used in IPv4.
St at ions t hat ar e not conf igur ed using a pr ovider based addr ess or a sit e l ocal addr ess
use t he l ink l ocal addr ess. This is an addr ess t hat can be used bet ween t wo st at ions on a
singl e l ink or net wor k. This t ype of addr ess wil l not be pr ocessed by a r out er , so it
cannot span subnet s. It can be used by a st at ion t hat is st ar t ing up and does not know it s
l ocat ion on t he net wor k. Basical l y, it is t he concat enat ion of it s 48-bit MAC addr ess
and t he wel l -known l ink l ocal pr ef ix of FE80::48-bit MAC addr ess. When t he make
addr ess cannot be used, a ser ial number or some ot her unique ident if icat ion of t he car d
can be used.
A sit e l ocal addr ess is used t o al l ow a sit e t o conf igur e it s net wor k wit hout being
connect ed t o t he Int er net . Unl ike IPv4, a sit e can devise and impl ement a compl et e
addr essed Int er net net wor k. This wil l al l ow t hat sit e t o communicat e wit h al l
int er f aces at t he sit e (it may span gl obal l y); however , none of t hese st at ions may
communicat e over t he Int er net . Ther e may be many r easons f or t his; f or exampl e, some
companies may not want connect ion t o t he Int er net unt il a specif ied t ime in t he f ut ur e.
I wit nessed t his at a bank t hat set up it s compl et e int er net based on pr ivat e addr essing
IPv4, t hat is). Pr obl em is it did not use t he RFC 1918 pr ivat e addr ess space al l ocat ion t o
accompl ish t his. The sit e was up and oper at ional f or t wo year s wit hout a hit ch (wel l ,
not t oo many!). When connect ion t o t he Int er net was desir ed, t he bank had a choice of
pr oviding f or Net wor k Addr ess Tr ansl at ion (NAT, RFC 1631) or r eaddr essing it s
net wor k. A l ot of t hought went int o it and based on many f act or sscal abil it y, peer -t o-
peer communicat ion, and ot her st he bank r eaddr essed it s sit e.
Local -Use IPv6 Addr essing
This woul d not have occur r ed wit h IPv6 sit e l ocal addr essing. The addr essing al l ows
f or any ent it y t o pick any number out of t he bl ue and conf igur e it s sit e (in t his case, al l
of it s company l ocat ions). If , at some l at er t ime, t he bank is assigned a gl obal pr ovider
addr ess pr ef ix, it s net wor k wil l not have t o be compl et el y r enumber ed.
Sit e l ocal addr esses may not be r out ed over t he Int er net , wit hout having a dif f er ent
pr ef ix assigned, such as a gl obal -pr ovider -based pr ef ix. The subnet ID is what you ar e
suspect ing. It is an ID assigned t o a subnet .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 154
IPv6 Addresses with Embedded IPv4 Addresses
A t r ansit ioning st r at egy t hat al l ows movement f r om IPv4 t o IPv6 wil l be key t o t he
successf ul impl ement at ion of IPv6IPv6 wil l never be accept ed if a one-t ime compl et e
cut over needs t o be appl ied. IPv4 is wor king, st umbl ing wit h addr essing and r out ing
t abl e expl osion, but wor king. It is embedded. Ther ef or e, inst al l at ions must be al l owed
t o t r y bef or e t hey buy int o it . This is why ot her pr ot ocol s t hat have t r ied t o over t ake
TCP/IP have f ail ed (OSI). You must have a compat ibl e pr ocedur e in pl ace. A gr eat
exampl e, is Micr osof t when it int r oduced Windows 95. It al l owed f or most Windows 3.x
pr ogr ams t o r un. Anot her gr eat exampl e is OS/2. It did not r un t he ver y popul ar
Windows 3.1 pr ogr ams ver y wel l and basical l y r equir ed a major cut over t o make it
wor k. We now see wher e Windows 95 is and OS/2 is not , so I t hink you know how
impor t ant it is f or IPv6 t o be backwar ds compat ibl e wit h IPv4. A t r ansit ion scheme is
pr ovided cour t esy of RFC 1933 and is not t hat dif f icul t t o r ead.
IPv6 host s can use t he IPv4 net wor k as a vir t ual int er f ace t hat enabl es t hese host s t o
r each ot her host s t hr ough t unnel s. The addr ess t hat is used t o al l ow f or t his is a
special t ype of l ink l ocal addr ess cal l ed t he IPv4-compat ibl e addr ess, shown in Sl ide
169. Al so needed f or t he t r ansit ion is f or host s t o become dual st ack (suppor t ing bot h
IPv4 and IPv6 IP st acks) and t unnel ing. To al l ow f or t his, a mechanism is pr ovided in t he
IPv6 addr essing st r uct ur e.
IPv6 Addr essing wit h Embedded IPv6 Addr esses
IPv4-compat ibl e IPv6 addr ess-0::0:IPv4 addr ess.
Ther e was anot her addr ess met hod known as t he IPv4 mapped addr ess t hat woul d al l ow
f or t r ansl at ion, but t his is out of f avor and t he met hod t oday is t he pr eceding st at ed
addr ess scheme.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 155
Unicast Addresses
The unicast addr ess space is a cont iguous bit -wise, maskabl e addr ess t hat is simil ar t o
t he addr essing scheme used in IPv4 CIDR. The addr ess t ypes f or unicast addr essing ar e
shown in t he sl ide.
An expect ed t o be ver y common t ype of addr ess is wher e t he IEEE 802.x (or Et her net )
LAN MAC addr esses wil l be used as shown in t he sl ide. The IEEE 802.x MAC addr ess is 48
bit s in l engt h and because of it s r egist r y, ever y car d has a unique number assigned t o it .
However , wher e t hese addr esses ar e not avail abl e, E.164 (t el ephone) addr esses coul d be
used.
An int er est ed point is t hat by using t he IEEE 802.x MAC addr ess, an IPv6 node coul d
simpl y l ist en t o t he cabl e pl ant f or r out er adver t isement s, which woul d yiel d t he
subnet ID f or it sel f . Put t ing t he t wo t oget her woul d give it a unique addr ess t o use.
This is aut oconf igur at ion.
Ref er t o t he sl ide. Gl obal communicat ion using IPv6 is pr ovided by t he unicast
addr essing scheme of a gl obal -based pr ovider . The f ir st 3 bit s ident if y t he addr ess as a
pr ovider -or ient ed unicast addr ess. The registry ID ident if ies t he int er net addr ess r egist r y
(cur r ent l y IANA, RIPE, APNIC, and INTERNIC), which assigns pr ovider ident if ier s,
indicat ed by t he provider ID f iel d, t o int er net ser vice pr ovider s, which t hen assign
por t ions of t he addr ess space t o subscr iber s. This is a pr ocess simil ar t o t he addr ess
assignment pol icy used wit h CIDR and descr ibed in RFC 2050. The subscriber ID
dist inguishes among mul t ipl e subscr iber s at t ached t o t he int er net ser vice pr ovider
ident if ied by t he pr ovider ID. This is l ike a cust omer number .
Unicast Addr esses
The subnet ID ident if ies a specif ic physical l ink. Ther e can be mul t ipl e subnet s on t he
same physical l ink; however , a specif ic subnet cannot span mul t ipl e physical l inks. The
interface ID ident if ies a singl e int er f ace among t he gr oup of int er f aces ident if ied by t he
subnet pr ef ix.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 156
Autoconfiguration
Aut oconf igur at ion is t he abil it y of an IPv6 node t o st ar t up and dynamical l y at t ain it s
node and net wor k addr esses. Ther e ar e t wo t ypes of aut oconf igur at ion:
St at ef ul . Some ext er nal device assist s t he node at st ar t up t o det er mine it s
net wor k addr ess (pr ef ix), node addr ess, and per haps some r out er addr esses. A
consider at ion of t his is f or DHCP t o enabl e t he conf igur ing of an init ial izing
node.
St at el ess. This means t hat t he node wil l conf igur e it sel f and f ind it s r esour ces
on t he net wor k t hr ough t he use of mul t icast addr esses. This al l ows t he node t o
st ar t up and send out r equest messages t o which ot her nodes wil l r espond. The
node can t hen det er mine it s net wor k addr ess and pr ef ix and node addr ess based on
t hese r esponses. IPv6 nodes st ar t t his behavior by joining t he al l -nodes mul t icast
gr oup upon st ar t up. This is accompl ished by init ial izing t he int er f ace t o t he al l -
nodes mul t icast addr ess of FF02::1. These nodes can sol icit inf or mat ion f r om
r out er s using t he al l -r out er s mul t icast addr ess of FF02::2 as t he dest inat ion and
t heir own l ink l ocal addr esses as t he sour ce.
Aut oconf igur at ion
St at el ess aut oconf igur at ion.
Init ial izing host s join t he al l -nodes mul t icast addr ess of FE02::1
St at el ess aut oconf igur at ion al l ows f or a node t o st ar t up using t he l ink-
l ocal pr ef ix and some sor t of t oken.
This wil l pr obabl y be t he 48-bit Et her net addr ess
Addr ess woul d be FE80::48-bit addr ess (mul t icast )
Host s send a sol icit at ion message t o al l -r out er s using t he al l -r out er s
mul t icast addr ess of FF02::2.
Used t o det er mine t he nodes r out ing pr ef ix and ot her r out ing
par amet er s
St at ef ul aut oconf igur at ion uses.
St at el ess aut oconf igur at ion has it s advant ages in t hat it is r eal l y aut omat ic and ver y
simpl e t o use. However , t his t ype of conf igur at ion is vul ner abl e t o hacker s who coul d
simpl y pl ace t heir net wor k st at ion on t he subnet and immediat el y gain access t o t he
r esour ces on t hat subnet . St at ef ul aut oconf igur at ion was devel oped t o combat such a
t hr eat .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 157
Neighbor Discovery
Neighbor Discover y
RFC 1970.
Ver y ext ensive and best t o r ead RFC.
Nodes used Neighbor Discover y t o det er mine l ink-l ayer addr esses f or
neighbor s.
Finds l ink-l ocal host s and r out er s.
Det ect s which neighbor s ar e r eachabl e and det ect s l ink-l ayer addr ess
changes.
ARP is not used wit h IPv6.
This is t he r obust r epl acement f or ARP (IPv4)
Neighbor Discover y is pr esent ed in RFC 1970. Al t hough it uses ICMP, do not expect t o
f ind it s l ist ing in ICMPv6 RFC (RFC 1885).
The Addr ess Resol ut ion Pr ot ocol is not used wit h IPv6. It is par t of t he Neighbor
Discover y pr ot ocol . Nodes (host s and r out er s) use Neighbor Discover y t o det er mine t he
l ink-l ayer addr esses f or neighbor s known t o r eside on at t ached l inks and t o quickl y
pur ge cached val ues t hat become inval id. Host s al so use Neighbor Discover y t o f ind
neighbor ing r out er s t hat ar e wil l ing t o f or war d packet s on t heir behal f .
Nodes use t he pr ot ocol t o act ivel y keep t r ack of which neighbor s ar e r eachabl e and
which ar e not , and t o det ect changed l ink-l ayer addr esses. When a r out er or t he pat h
t o a r out er f ail s, a host act ivel y sear ches f or f unct ioning al t er nat es.
This sounds l ike a happy medium bet ween ARP f or IPv4 and t he met hods empl oyed by ES-
IS pr ocedur es of t he CLNP (Connect ionl ess Net wor k Pr ot ocol ) f r om t he OSI suit e. In ES-
IS (par t of t he r out ing updat e pr ot ocol f or t he OSI pr ot ocol suit e), t he act ive
endst at ions send Hel l o packet s t o which t he act ive r out er s on a net wor k l ist en and
buil d a dat abase of . In t his dat abase is a l ist ing of al l t he endst at ions t hat t he OSI
r out er has hear d f r om. The OSI r out er al so t r ansmit s a packet t o al l ow it sel f t o be
known on t he net wor k as wel l . The wor kst at ions r ecor d t he r out er s addr ess so t hat it
can send packet s t o it , eit her t he f ir st packet t r ansmit t ed l ocal l y or al l of f -net wor k
f or war ding. The OSI r out er wil l inf or m t he node about t he l ocat ion of t he dest inat ion
st at ion. It was once r ecommended t hat CLNP r epl ace IPv4. However , CLNP was act ual l y
a cl one of IP, basical l y out dat ed by t he t ime t he IPng gr oup f or med in 1992, and pushed
aside. Anyway, t he IPv6 Neighbor Discover y pr ot ocol cor r esponds t o a combinat ion of
t he IPv4 pr ot ocol s ARP (RFC 826), ICMP Rout er Discover y (RFC 1256), and ICMP Redir ect
(RFC 791).
A quest ion t hat may be asked her e is: Wit h al l t he dependency on dynamical l y
discover ing l ink-l ayer addr esses bet ween host s and r out er s, how can an ICMP message
be sent , if t he media (l ink-l ayer ) addr ess is not yet known (i.e., t he Neighbor Discover y
pr ocedur es have not yet det er mined t he l ink-l ayer addr esses f or al l dependencies on a
node l ocal l ink)? This is easil y sol ved by using a wel l -known IPv6 mul t icast addr ess.
ICMP cannot wor k wit hout t he media addr ess being known.
However , a special mul t icast addr ess at t he MAC l ayer has been invent ed. Al l st at ions
shoul d be l ist ening t o t heir special MAC mul t icast addr ess. This is f or med by pl acing
3333 and t he l ast 32 bit s of t heir IPv6 addr ess as one of t he addr esses t o l ist en f or on
t he NIC car d. Ther ef or e, if an addr ess of 3333 is r eceived by t he NIC, it wil l pr ocess t he
l ast 32 bit s as wel l . If t his mat ches it s addr ess, it wil l pass it on t o t he IPv6 IP l ayer of
it s upper -l ayer sof t war e.
Wit h t he except ion of Non-Br oadcast Mul t iaccess (NBMA) net wor ks (ATM Fr ame Rel ay,
+ X.25) or if a l ink-l ayer int er act ion is specif ied in anot her document , RFC 1970 appl ies
t o al l l ink-l ayer t ypes. However , because ND uses l ink-l ayer mul t icast f or some of it s
ser vices, it is possibl e t hat on some l ink t ypes (e.g., NBMA l inks), al t er nat ive pr ot ocol s
or mechanisms t o impl ement t hose ser vices wil l be specif ied (in t he appr opr iat e document
cover ing t he oper at ion of IP over a par t icul ar l ink t ype). The ser vices descr ibed in t his
document t hat ar e not dir ect l y dependent on mul t icast (e.g., Redir ect s, Next -Hop
det er minat ion, Neighbor Unr eachabil it y Det ect ion, et c.) ar e expect ed t o be pr ovided as
specif ied in t his document . The det ail s of how one uses ND on NBMA l inks is an ar ea f or
f ur t her st udy.
Neighbor Discover y (cont inued)
In IPv6, Discover y messages use t he var ious mul t icast addr ess assignment s f or
r out er discover y, neighbor discover y, et c.
The media (MAC) addr ess is a mul t icast addr ess as wel l :
33-33-l ast 32 bit s of t he IPv6 addr ess
RFC 1970 appl ies t o al l l ink-l ayer t ypes except NBMA and var ious pr opr iet ar y
int er f aces.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 158
Neighbor Discovery Types
Neighbor Discover y Types
Rout er Discover y
Pr ef ix Discover y
Par amet er Discover y
Addr ess Aut oconf igur at ion
Addr ess Resol ut ion
Next -Hop det er minat ion
Neighbor Unr eachabil it y Det ect ion
Dupl icat e Addr ess Det ect ion
Redir ect
This pr ot ocol sol ves a set of pr obl ems r el at ed t o t he int er act ion bet ween nodes
at t ached t o t he same l ink. It def ines mechanisms f or sol ving each of t he f ol l owing
pr obl ems:
Rout er Discover y. This pr ot ocol al l ows host s t o l ocat e and ident if y r out er s on
t heir l ocal l ink.
Pr ef ix Discover y. How host s discover t he set of addr ess pr ef ixes t hat def ine
which dest inat ions ar e on-l ink f or an at t ached l ink. (Nodes use pr ef ixes t o
dist inguish dest inat ions t hat r eside on-l ink f r om t hose onl y r eachabl e t hr ough a
r out er .)
Par amet er Discover y. How a node l ear ns such l ink par amet er s as t he l ink MTU
or such Int er net par amet er s as t he hop-l imit val ue t o pl ace in out going packet s.
Addr ess Aut oconf igur at ion. How nodes aut omat ical l y conf igur e an addr ess f or
an int er f ace.
Addr ess Resol ut ion. How nodes det er mine t he l ink-l ayer addr ess of an on-l ink
dest inat ion (e.g., a neighbor ) given onl y t he dest inat ions IP addr ess.
Next -Hop Det er minat ion. The al gor it hm f or mapping an IP dest inat ion addr ess
int o t he IP addr ess of t he neighbor t o which t r af f ic f or t he dest inat ion shoul d be
sent . The next -hop can be a r out er or t he dest inat ion it sel f .
Neighbor Unr eachabil it y Det ect ion. How nodes det er mine t hat a neighbor is no
l onger r eachabl e. For neighbor s used as r out er s, al t er nat e def aul t r out er s can
be t r ied. For bot h r out er s and host s, addr ess r esol ut ion can be per f or med again.
Dupl icat e Addr ess Det ect ion. How a node det er mines t hat an addr ess it wishes
t o use is not al r eady in use by anot her node.
Redir ect . How a r out er inf or ms a host of a bet t er f ir st -hop node t o r each a
par t icul ar dest inat ion.
Al so cont ained in RFC 792 is t he or iginal ICMP r edir ect message in which a r out er sends
t o a host st at ing, I wil l f or war d t he packet t hat you sent t o me t o my next hop por t .
However , t her e is a bet t er pat h t o t he dest inat ion t hat you indicat ed and it is t hr ough
Rout er X.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 159
Neighbor Discovery and IPv4
The IPv6 Neighbor Discover y pr ot ocol cor r esponds t o a combinat ion of t he IPv4
pr ot ocol s ARP, ICMP Rout er Discover y, and ICMP Redir ect . In IPv4 t her e is no gener al l y
agr eed upon pr ot ocol or mechanism f or Neighbor Unr eachabil it y Det ect ion, al t hough
Host s Requir ement s RFC 1122 and 1123 does specif y some possibl e al gor it hms f or Dead
Gat eway Det ect ion (a subset of t he pr obl ems t hat Neighbor Unr eachabil it y Det ect ion
t ackl es). Rout er Discover y is par t of t he base pr ot ocol set ; t her e is no need f or host s t o
snoop t he r out ing pr ot ocol s. Rout er adver t isement s car r y l ink-l ayer addr esses; no
addit ional packet exchange is needed t o r esol ve t he r out er s l ink-l ayer addr ess. Rout er
adver t isement s car r y pr ef ixes f or a l ink; t her e is no need t o have a separ at e mechanism
t o conf igur e t he net mask. Rout er adver t isement s enabl e Addr ess Aut oconf igur at ion.
Rout er s can adver t ise an MTU f or host s t o use on t he l ink, ensur ing t hat al l nodes use
t he same MTU val ue on l inks l acking a wel l -def ined MTU.
Addr ess r esol ut ion mul t icast s ar e spr ead over 4 bil l ion (2
n
32) mul t icast addr esses,
gr eat l y r educing addr ess r esol ut ion-r el at ed int er r upt s on nodes ot her t han t he
t ar get . Mor eover , non-IPv6 machines shoul d not be int er r upt ed at al l . Redir ect s
cont ain t he l ink-l ayer addr ess of t he new f ir st hop; separ at e addr ess r esol ut ion is not
needed upon r eceiving a r edir ect .
Mul t ipl e pr ef ixes can be associat ed wit h t he same l ink. By def aul t , host s l ear n al l on-
l ink pr ef ixes f r om Rout er Adver t isement s. However , r out er s may be conf igur ed t o omit
some or al l pr ef ixes f r om Rout er Adver t ise-ment s. In such cases, host s assume t hat
dest inat ions ar e of f -l ink and send t r af f ic t o r out er s. A r out er can t hen issue r edir ect s
as appr opr iat e.
Neighbor Discover y and IPv4
IPv6 Neighbor Discover y combines IPv4 pr ot ocol s of ARP, ICMP Rout er
Discover y, and ICMP Redir ect .
IPv4 has no agr eed-upon met hod f or Dead Gat eway Det ect ion and Neighbor
Unr eachabil it y det ect ion.
IPv6 assumes a r edir ect next hop is on-l inkon t he same l ink t hat it r esides.
IPv6 det ect s hal f l ink f ail ur es (neighbor s t hat ar e suspect or t hat have gone
away).
IPv6 Rout er adver t isement s do not cont ain a Pr ef er ence f iel d.
Using l ink-l ocal addr esses t o ident if y r out er s means t hat t his r el at ionship is
maint ained even if t he pr ovider addr ess changes.
Addr ess r esol ut ion is accompl ished at t he ICMP l ayer .
Unl ike IPv4, t he r ecipient of an IPv6 r edir ect assumes t hat t he new next hop is on-l ink
(t he same subnet as it sel f ). In IPv4, a host ignor es r edir ect s specif ying a next -hop t hat is
not on-l ink accor ding t o t he l inks net wor k mask. The IPv6 r edir ect mechanism is
anal ogous t o t he r edir ect f acil it y. It is expect ed t o be usef ul on nonbr oadcast and
shar ed media l inks in which it is undesir abl e or impossibl e f or nodes t o know al l pr ef ixes
f or on-l ink dest inat ions.
Neighbor Unr eachabil it y Det ect ion is par t of t he base signif icant l y impr oving t he
r obust ness of packet del iver y in t he pr esence of f ail ing r out er s, par t ial l y f ail ing or
par t it ioned l inks and nodes t hat change t heir l ink-l ayer addr esses. For inst ance, mobil e
nodes can move of f -l ink wit hout l osing any connect ivit y due t o st al e ARP caches.
Unl ike ARP, Neighbor Discover y det ect s hal f -l ink f ail ur es (using Neighbor Unr each-
abil it y Det ect ion) and avoids sending t r af f ic t o neighbor s wit h which t wo-way
connect ivit y is absent . Unl ike in IPv4 Rout er Discover y t he Rout er Adver t isement
messages do not cont ain a pr ef er ence f iel d. The pr ef er ence f iel d is not needed t o handl e
r out er s of dif f er ent st abil it y; t he Neighbor Unr eachabil it y Det ec-t ion wil l det ect
dead r out er s and swit ch t o a wor king one. The use of l ink-l ocal addr esses t o uniquel y
ident if y r out er s (f or Rout er Adver t isement and Redir ect messages) makes it possibl e f or
host s t o maint ain t he r out er associat ions in t he event of t he sit e r enumber ing t o use
new gl obal pr ef ixes.
Using t he Hop-Limit -equal -t o-255 t r ick, Neighbor Discover y is immune t o of f -l ink sender s
t hat accident al l y or int ent ional l y send ND messages. In IPv4, of f -l ink sender s can send
bot h ICMP Redir ect s and Rout er Adver t isement messages. Pl acing addr ess r esol ut ion at
t he ICMP l ayer makes t he pr ot ocol mor e media independent t han ARP and makes it
possibl e t o use st andar d IP aut hent icat ion and secur it y mechanisms as appr opr iat e.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 160
Address Resolution
The pur pose of addr ess r esol ut ion is t o det er mine t he l ink-l evel addr ess of a
dest inat ion given onl y it s IP addr ess. This is per f or med onl y f or t hose IP addr esses t hat
ar e l ocal (hop count set t o 1 f or t hese messages). When a mul t icast abl e int er f ace
st ar t s, it must join bot h t he al l -nodes mul t icast gr oup and t he sol icit ed-node mul t icast
gr oup. This enabl es t he node t o r eceive and pr ocess packet s wit hout having al l of it s
addr essing est abl ished. In f act , a node must keep t he mul t icast addr esses unt il al l
addr essing has been r esol ved. Addr ess r esol ut ion consist s of sending a Neighbor
Sol icit at ion message and wait ing f or a Neighbor Adver t isement using mul t icast
addr essing. The sol icit at ion is sent t o t he sol icit ed-node mul t icast addr ess
cor r esponding t o t he t ar get addr ess. The sol icit ed-node mul t icast addr ess is a l ink-
l ocal scope mul t icast addr ess t hat is comput ed as a f unct ion of t he sol icit ed t ar get s
addr ess. The sol icit ed-node mul t icast addr ess is f or med by t aking t he l ow-or der 32 bit s
of t he t ar get IP addr ess and appending t hose bit s t o t he 96-bit pr ef ix FF02:0:0:0:0:1 t o
pr oduce a mul t icast addr ess wit hin t he r ange of FF02::1:0:0 t o FF02:: 1:FFFF:FFFF. For
exampl e, t he sol icit ed node mul t icast addr ess cor r esponding t o t he IP addr ess
4037::01:800:200E:8C6C is FF02::1: 200E:8C6C. IP addr esses t hat dif f er onl y in t he high-
or der bit s (e.g., due t o mul t ipl e high-or der pr ef ixes associat ed wit h dif f er ent pr ovider s)
wil l map t o t he same sol icit ed-node addr ess, t her eby r educing t he number of mul t icast
addr esses a node must join. In r esponse t o t his r equest (t he sender may send it mul t ipl e
t imes if no r esponse is f ound wit hin a cer t ain per iod of t ime), a Neighbor Adver t isement
shoul d be gener at ed by t he r emot e node. The or iginat ing node shoul d r eceive t his
packet and updat e it s Neighbor cache wit h t he inf or mat ion in t he r eceived Neighbor
Adver t isement (t he l ink-l ayer inf or mat ion). The MAC addr ess is set as pr eviousl y
indicat ed by t aking t he l ow-or der 32 bit s of t he t ar get IPv6 addr ess and pr epending 3333
t o t hat addr ess, which is t he IPv6 al l -nodes MAC mul t icast addr ess.
Addr ess Resol ut ion
Pur pose is t o det er mine t he l ink l evel -addr ess of a dest inat ion given onl y it s
IP addr ess.
Consist s of sending a Neighbor Sol icit at ion message and wait ing f or a r epl y.
Al l nodes st ar t up by joining t he al l -nodes mul t icast addr ess and t he
sol icit ed node mul t icast addr ess
Sol icit ed node addr ess is t aking t he 96 bit pr ef ix FF02:0:0:0:0:1 and
pl acing t he l ow or der 32 bit s of t he dest inat ion IP addr ess t o t his
This al l ows f or a r ange of FF02::1:0:0 t hr ough FF02::1:FFFF:FFFF
The f ul l t ar get addr ess is embedded in t he ICMP packet
One mor e check is accompl ished each t ime a Neighbor cache (l ink-l ayer inf or mat ion)
ent r y is accessed whil e t r ansmit t ing a unicast packet : The sender checks Neighbor
Unr each-abil it y Det ect ion-r el at ed inf or mat ion accor ding t o t he Neighbor
Unr eachabil it y Det ect ion al gor it hm. This is not so much a pr ot ocol as keeping an eye on
t he pr ogr ession of t he upper -l ayer pr ot ocol s wit h t his addr ess. This unr eachabil it y
check might r esul t in t he sender t r ansmit t ing a unicast Neighbor Sol icit at ion t o ver if y
t hat t he neighbor is st il l r eachabl e.
If at some point communicat ion ceases t o pr oceed, as det er mined by t he Neighbor
Unr eachabil it y Det ect ion al gor it hm, next -hop det er minat ion may need t o be per f or med
again. For exampl e, t r af f ic t hr ough a f ail ed r out er shoul d be swit ched t o a wor king
r out er . Likewise, it may be possibl e t o r er out e t r af f ic dest ined f or a mobil e node t o a
mobil it y agent .
Not e t hat when a node r edoes next -hop det er minat ion, t her e is no need t o discar d t he
compl et e Dest inat ion cache ent r y. In f act , it is gener al l y benef icial t o r et ain such
cached inf or mat ion as t he PMTU and r ound-t r ip t imer val ues t hat may al so be kept in
t he Dest inat ion cache ent r y.
Next -hop det er minat ion is done t he f ir st t ime t r af f ic is sent t o a dest inat ion. As l ong as
subsequent communicat ion t o t hat dest inat ion pr oceeds successf ul l y, t he Dest inat ion
cache ent r y cont inues t o be used. Al l of t his is det ail ed f ur t her l at er in t he book.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 161
Methods of Deploying IPv6
Met hods of Depl oying IPv6
Dual IP l ayer a node t hat is r unning bot h t he IPv4 and IPv6 TCP/IP pr ot ocol
st acks.
IPv6 over IPv4 t unnel t he pr ocess of t aking an IPv6 dat agr am and wr apping
an IPv4 header on it f or t r ansit acr oss IPv4 r out er s.
Conf igur ed t unnel IPv4 t unnel endpoint addr ess is det er mined by t he
encapsul at ing node
Aut omat ic t unnel IPv4 t unnel endpoint is det er mined f r om t he IPv4
addr ess of t he IPv6 packet
Tr ansit ion consist s of :
IPv4-onl y node
IPv6 wil l not be cut over in an hour s t ime. A per iod of t r ansit ion wil l t ake pl ace. In
or der t o ef f ect t he t r ansit ion some suggest ed met hods ar e pr ovided:
Dual IP l ayer . IPv4 and IPv6 r unning at t he net wor k l ayer in bot h host s and/or
r out er s. These nodes have t he abil it y t o send and r eceive bot h IPv4 and IPv6
dat agr ams. This r equir es t hat a node be conf igur ed wit h bot h an IPv4 and IPv6
addr ess t hat may or may not be r el at ed. In t his way, IPv4-onl y host s can access
ser vices t hat exist on an IPv6 host .
IPv6 over IPv4 t unnel ing. This is t he pr ocess of t aking an IPv6 dat agr am and
wr apping an IPv4 header on it f or t r ansit acr oss IPv4 host s or r out er s. Two
met hods ar e avail abl e: configured and automatic. These nodes ar e conf igur ed wit h
an IPv4-compat ibl e IPv6 addr ess. This is t hat special unicast addr ess t hat has a 96-
bit pr ef ix of al l 0s. The next 32 bit s is an IPv4 addr ess.
Conf igur ed t unnel ing is when t he IPv4 t unnel endpoint addr ess is det er mined by
t he encapsul at ing node.
Aut omat ic t unnel ing is when t he IPv4 t unnel endpoint is det er mined f r om t he
IPv4 addr ess of t he IPv6 packet . A node may be capabl e of aut omat ic and/or
conf igur ed t unnel ing. Aut omat ic t unnel ing uses t he IPv4-compat ibl e addr ess
scheme as shown in t he sl ide. A node does not have t o suppor t dual st ack IP t o
suppor t t unnel ing.
The t r ansit ion wil l al so have special nodes:
IPv4-onl y node. A node t hat onl y under st ands IPv4.
IPv4/IPv6 node. A node t hat is r unning dual IP st acks and under st ands bot h IPv4
and IPv6.
IPv6-onl y node. A node t hat under st ands IPv6 onl y.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 162
IPv6 Tunneling Introduction
IPv6 Tunnel ing Int r oduct ion
Host t o Rout er
Rout er t o Rout er
Rout er t o Host
Host t o Host
Tunnel ing is ver y simpl y t he met hod of t r anspor t ing IPv6 packet s over IPv4 r out ing
t opol ogies. It is being used t oday wit h t he 6Bone (www/6Bone.com). Two scenar ios occur
her e. The f ir st one is t he f ol l owing t wo t unnel ing met hods:
Host t o Rout er : Dual -st ack IP host s can t unnel IPv6 packet s t o an int er mediar y
dual -st ack IP r out er t hat is r eachabl e via an IPv4 inf r ast r uct ur e.
Rout er t o Rout er : A r out er t hat is r unning t he dual -st ack IP int er connect ed by
an IPv4 inf r ast r uct ur e can t unnel IPv6 dat agr ams bet ween r out er s.
Wit h t hese t ypes of t unnel s, t he t unnel endpoint is an int er mediar y r out er t hat must
decapsul at e t he IPv6 packet and f or war d it t o it s f inal dest inat ion. The endpoint of t he
t unnel is dif f er ent f r om t he dest inat ion of t he packet being t unnel ed. Ther ef or e, t he
addr ess in t he IPv6 packet being t unnel ed does not pr ovide t he IPv4 addr ess of t he
t unnel endpoint . The t unnel endpoint addr ess must be det er mined f r om inf or mat ion
t hat is conf igur ed on t he node per f or ming t he t unnel ing. This is t he conf igur ed t unnel
appr oach. The endpoint is expl icit l y conf igur ed.
Tunnel s ar e char act er ized by t wo endpoint IPv4 addr esses. The IPv4 pr ot ocol ident if ier
is 41, t he assigned payl oad t ype number f or IPv6.
Rout er t o Host : Dual -st ack IP r out er s can t unnel IPv6 packet s t o t heir f inal
dest inat ion dual -st ack IP host .
Host t o Host : Dual -st ack IP host s can t unnel IPv6 packet s bet ween t hemsel ves
over an IPv6 inf r ast r uct ur e (wit hout t he use of a r out er ).
These t wo t ypes pr ovide f or t unnel ing al l t he way t o a f inal dest inat ion. In t hese cases,
t he t unnel endpoint is t he node t o which t he IPv6 packet is addr essed. This is aut omat ic
t unnel ing and it simpl y al l ows f or IPv6 packet s t hat ar e t o be sent t o IPv6 dest inat ions
using t he IPv4-compat ibl e addr ess and l ocat ed r emot el y (of f -l ink) t o be encapsul at ed in
IPv4 header s and sent t hr ough t he IPv4 inf r ast r uct ur e.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 163
IPv6 Tunnel Addressing
Now, which t ype of t unnel ing is used wher e, and how does t his t hing wor k? Wel l , it
depends on t he addr ess of t he dest inat ion. If t he addr ess is an IPv6 addr ess and t he
dest inat ion is l ocal (on-l ink), t hen it simpl y sends t he packet . If t he addr ess of t he end
node is an IPv4 addr ess and it r esides on a dif f er ent subnet , t hen an IPv4 r out er must be
used.
The key t o al l of t his is t he special addr ess 0:0:0:0:0:0:<IPv4 32-bit addr ess>. IPv4-
compat ibl e r out er .
Dual IP st ack host s wil l r ecognize t he special addr ess and immediat el y encapsul at e t he
packet wit h an IPv4 header . This is cal l ed an end-to-end t unnel . The r eceiving st at ion
wil l decapsul at e t he dat agr am (st r ip of f t he IPv4 header ) and r ead it as an IPv6
dat agr am.
IPv6-onl y host s can al so use t he IPv4 Int er net t hr ough t he use of dual -st ack IP r out er s.
The IPv6-onl y host wil l t r ansmit t he IP dat agr am as an IPv6 dat agr am. The dual -st ack
IP r out er wil l r ecognize t he special addr ess and wr ap it in an IPv4 header (using t he
l ast 32 bit s of t he special addr ess in t he IPv4 dest inat ion IP addr ess).
Final l y, if t he addr ess is an IPv6 addr ess but not of t he special addr ess, a conf igur ed
t unnel can be used inst ead of an aut omat ic t unnel (which r ecognizes t he special
addr ess). This r equir es conf igur at ion in t he IPv6 host t o al l ow f or t his. This is a mor e or
l ess manual conf igur at ion and t el l s t he IPv6 host wher e t o send t he packet .
IPv6 Tunnel Addr essing

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 164
IPv6 and IPv4 Dual-Stack Strategy
The f ol l owing sl ide shows t he IPv6 and IPv4 dual -st ack capabil it y of a host . Based on
t he Et her Type f iel d of t he r eceived packet , t he NIC sof t war e can hand of f t he
decapsul at ed packet t o eit her of t he TCP/IP sof t war e st acks.
Since t he Et her net t ype f iel d has a new number f or IPv6, t his met hod is ver y easy t o
impl ement . When a packet is r eceived, t he t ype f iel d is checked. If t he t ype f iel d cont ains
0800 (in hex) t he packet is handed of f t o t he IPv4 pr ot ocol st ack, ot her wise t he t ype
f iel d cont ains 86DD, t hen t he packet is handed of f t o t he IPv6 st ack.
IPv6 and IPv4 Dual -St ack St r at egy

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 165
IPv6 Tunneling
The sl ide shows an IPv6 t unnel ing st r at egy. IPv6 and IPv4 nodes can peacef ul l y coexist
on a net wor k using t unnel ing. This sl ide shows an IPv4/IPv6 r out er t hat can at t ach t o
an IPv4 r out er . Not ice her e t hat IPv4 and IPv6 host s can exist wit h t he IPv6/IPv4
r out er s. However , an IPv6-onl y host cannot make use of t he IPv4 r out er . This is shown
on t he r ight side in t he middl e of t he sl ide. An IPv6 host is sit uat ed behind an IPv4
r out er . These t wo devices have no met hod of communicat ing.
The f l owchar t s in t he f ol l owing sect ion give f ul l descr ipt ions f or exampl es t hat can be
used wit h t his sl ide.

IPv6 Tunnel ing

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 166
IPv6 Tunneling
This sl ide shows f our possibl e met hods of IPv6 t unnel ing dat a f l ow.
IPv6 Tunnel ing

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 167
IPv6 Tunneling Flowchart 1
This sl ide shows IPv6 t unnel ing when t he end node addr ess is an IPv4-compat ibl e IPv6
addr ess.
IPv6 Tunnel ing Fl owchar t 1

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 168
This sl ide shows IPv6 t unnel ing when t he end node is an IPv6-onl y addr ess.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 169
This sl ide shows t unnel ing IPv6 when t he end node addr ess is an IPv4 addr ess.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 170
Anycast Addressing
Anycast Addr essing
Simil ar t o a mul t icast addr ess.
Addr ess is sent t o a gr oup addr ess (anycast ) but t he r out er del iver s t he
dat agr am t o t he near est member of t he gr oup.
Pr ovides f or appl icat ions such as f il e and pr int ser ver s, t ime ser ver s, name
ser ver s, DHCP, et c.
Simil ar t o t he Net War e pr ot ocol of Get Near est Ser ver r equest .
An anycast addr ess is simil ar t o a mul t icast addr ess. The except ion her e is t hat a packet
sent t o an anycast addr ess is r out ed t o t he near est int er f ace having t hat addr ess,
using dist ance as a f act or .
A sour ce node sends a dat agr am addr essed as an anycast addr ess. This addr ess wil l be
r ecognized by al l dest inat ions of a given t ype. The r out ing syst em is key her e; it is t he
r out ing syst em t hat del iver s t he dat agr am t o t he near est ser ver . This has appl icat ions
t o f ind ser ver s of t ype f il e/pr int , t imer , name, DHCP, and so f or t h.
This concept may sound f amil iar t o t hose who know t he Novel l Net War e pr ot ocol .
Funct ional l y, it is impl ement ed dif f er ent l y, but t he concept is t he same.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 171
Multicasting for IPv6
Mul t icast ing f or IP st ar t ed in 1988 wit h IGMP. IANA al so assigned a new cl ass of
addr essing known as Cl ass D addr essing. Mul t icast ing is car r ied over t o IPv6 and it s
addr essing al l ows f or mor e gr anul ar it y. Mul t icast ing is used ext ensivel y wit h IPv6. The
f or mat of t he addr ess is shown in t he sl ide. The f ir st 8 bit s must be set t o FF. The next 4
bit s ar e cal l ed t he flag bits, of which onl y one is def ined. The T bit is t he t r ansient bit .
Set t ing t his t o 1 indicat es t he mul t icast addr ess is not per manent l y assigned by t he
IANA. A 0 indicat es it is per manent l y assigned.
The scope is 4 bit s in l engt h and cont r ol s t he hear ing r ange of t he mul t icast addr ess.
It per f or ms t he same f unct ion as t he TTL f iel d in an IPv4 mul t icast packet . The
f ol l owing t abl e indicat es what scopes ar e cur r ent l y assigned.
Scope Range
0 Reser ved
1 Node l ocal scope
2 Link l ocal scope
3 Unassigned
4 Unassigned
5 Sit e l ocal scope
6 Unassigned
7 Unassigned
8 Or ganizat ion l ocal scope
9 Unassigned
A Unassigned
B Unassigned
C Unassigned
D Unassigned
E Gl obal scope
F Reser ved
Mul t icast ing f or IPv6
Not ice t hat in IPv6 mul t icast addr esses, weaving t he scope in as par t of t he addr ess
makes it possibl e t o have mul t ipl e mul t icast addr esses f or t he same f unct ion. The f ir st
par t of t he addr ess is t he mul t icast addr ess ident if ier , but t he scope is incl uded in t he
over al l addr ess. This al l ows f or mul t ipl e mul t icast addr esses t o be assigned t o t he same
f unct ion. For exampl e, t her e is one mul t icast addr ess l ooking f or al l DHCP ser ver s in a
r adius of 3 hops. Anot her woul d al l ow f or a r adius of 10 hops, but it is st il l t he same
mul t icast f unct ion.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 172
IPv6 Routing
IPv6 Rout ing
Exist ing r out ing pr ot ocol s (OSPF, RIP, IDRD, et c.) ar e st r aight f or war d
ext ensions of IPv4 r out ing.
IPv6 incl udes new r out ing ext ensions such as:
Pr ovider sel ect ion
Host mobil it y
Aut o-r eaddr essing
OSPF:
Cr eat es a separ at e l ink-st at e dat abase
Makes r oom f or t he 128-bit addr ess
Cannot int er oper at e wit h IPv4
Rout ing in IPv6 is al most ident ical t o IPv4 r out ing under CIDR except t hat t he
addr esses ar e 128-bit IPv6 addr esses inst ead of 32-bit IPv4 addr esses. Wit h ver y
st r aight f or war d ext ensions, al l of IPv4s r out ing al gor it hms (OSPF, RIP, IDRP, ISIS, et c.)
can used t o r out e IPv6.
IPv6 al so incl udes simpl e r out ing ext ensions t hat suppor t power f ul new r out ing
f unct ional it y. These capabil it ies incl ude:
Pr ovider sel ect ion (based on pol icy, per f or mance, cost , et c.)
Host mobil it y (r out e t o cur r ent l ocat ion)
Aut o-r eaddr essing (r out e t o new addr ess)
The new r out ing f unct ional it y is obt ained by cr eat ing sequences of IPv6 addr esses using
t he IPv6 Rout ing opt ion. The Rout ing opt ion is used by an IPv6 sour ce t o l ist one or mor e
int er mediat e nodes (or t opol ogical gr oup) t o be visit ed on t he way t o a packet s
dest inat ion. This f unct ion is ver y simil ar in f unct ion t o IPv4s Loose Sour ce and Recor d
Rout e opt ion.
OSPFv6 f or IPv6, l ike IPv4, wil l r un dir ect l y on t op of IPv6. OSPFv6 wil l r un as a
separ at e pr ot ocol just l ike any ot her ships in t he night t ype of pr ot ocol in a
mul t ipr ot ocol r out er . It wil l have a separ at e l ink-st at e dat abase t han OSPFv4. In
shor t , not hing wil l be shar ed bet ween OSPFv4 and OSPFv6 (in t he r out er , t hat is). Each
wil l not know t he ot her exist s.
However , in or der t o make IPv6 oper at e wit h OSPFv6, some changes ar e necessar y. Most
not abl y wil l be t he 128-bit addr ess. Rout er IDs, l inks, and ar eas wil l be associat ed wit h
an 128-bit number .
RIP made it t hr ough as wel l . How coul d we f or get good ol d RIP? Hey, it s st il l a good,
decent pr ot ocol f or smal l net wor ks and is ver y easy t o impl ement . And, wit h t he advent
of RIP2, RIP is al ive and wel l . As wit h t he advant age of VLSM wit h RIP2, t he dominance
of RIP cont inues and ext ensions f or 128 bit addr essing have been pr ovided.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 173
RIPng
The packet f or mat is shown in t he sl ide and it is r epr esent ed by RFC 2080. Not ice t hat
t he same amount of space is t aken up f or t he r out e t abl e ent r ies as IPv4 (160 bit s per
ent r y). One f eat ur e t hat was added ext ended t he packet size t o beyond t he l imit of 576
byt es as in RIPv1 and v2. It was not ed t hat t hese updat e packet s wil l never t r aver se a
r out er , and t her ef or e t he l imit on t he Rout e Tabl e Ent r ies (RTE) is simpl y l imit ed by t he
MTU of t he medium over which t he pr ot ocol is being used.
The f or mul a is:
# of RTE = (MTU - sizeof (IPv6_hdr s) - UDP_hdr l en - RIPng_hdr l en)) / RTE_Size
The 8-bit subnet mask is used t o ident if y t he number of bit s in t he pr ef ix. Since t her e ar e
8 bit s, t his gives us t he capabil it y of a 256-bit pr ef ix, which is mor e t han enough f or t he
128 bit s of IPv6.
Legend
hdr s header s
hdr l en header l engt h
RIPng

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 174
ICMP
Like IPv4, IPv6 does not pr ovide er r or det ect ion. This is a f unct ion of ICMP. ICMP f or
IPv6 has been addr essed as wel l .
Int er net Cont r ol Message Pr ot ocol (ICMP) f or IPv6 is f ound in RFCs 1885 and 1970. ICMP
f or IPv6 is expl ained in RFC 1885, but t he individual f unct ions of ICMP f or IPv6 (f or
exampl e, pat h MTU discover y) ar e det ail ed in exist ing RFCs such as RFC 1191. Hopef ul l y,
you ar e not t oo conf used? If you ar e, wel come t o t he wor l d of RFCs. IPv6 and it s
ext ension pr ot ocol s used pr evious RFCs if t hey wer e f ound r el evant t o t he pr ot ocol .
ICMPv6 is an IPv4 ext ension. It is or iginal l y document ed in RFC 792 and is an int egr al
par t of t he IP. Al ong t he year s, ot her f unct ions t hat ut il ize ICMP wer e added, such as
r out er discover y (RFC 1256). ICMPv6 is a ver sion of ICMP f or IPv6 (seeing a v6 af t er a
pr ot ocol name is a ver y common way of specif ying which ver sion of IP you ar e
r epr esent ing when expl aining t he pr ot ocol ). Ther e ar e cur r ent l y t wo RFCs t hat def ine
al l t he ICMP f unct ions f or IPv6: RFC 1885 and RFC 1970. RFC 1885 pr ovides f or
inf or mat ion on new f unct ions and names t he ol der f unct ions t hat made it t hr ough t he
r eview pr ocess. RFC 1970 incl udes t he discover y pr ot ocol s of RFC 1256 and a f ew ot her
discover y pr ot ocol s. It al so incl udes t he r edir ect message.
ICMPv6, as def ined in RFCs 1885 and 1970, is cur r ent l y using cont r ol and inf or mat ion
messages pr eviousl y def ined in RFCs 791, 1112, and 1191. Ther ef or e, t he pr ocedur es f or
cer t ain ICMP f unct ions cont inue t o be def ined in t heir r espect ive RFCs. You must r ead
t he or iginal RFCs t o f ul l y expl ain t he pr ocedur es used.
As indicat ed in t he pr evious t ext on IP, t he Int er net Pr ot ocol is an unr el iabl e
pr ot ocol . ICMP is an add-on pr ot ocol t hat does not make IP r el iabl e, but is a cont r ol
message pr ot ocol , t he pur pose of which is t o pr ovide f eedback about pr obl ems in t he
communicat ion envir onment . Ther e ar e st il l no guar ant ees t hat a dat agr am wil l be
del iver ed or a cont r ol message wil l be r et ur ned. Some dat agr ams may st il l be
undel iver ed wit hout any r epor t of t heir l oss. The higher -l evel pr ot ocol s t hat use IPv6
must st il l impl ement t heir own r el iabil it y pr ocedur es if r el iabl e communicat ion is
r equir ed.
The ICMP messages t ypical l y r epor t er r or s in t he pr ocessing of dat agr ams. To avoid t he
pr obl em of ICMP messages about ICMP messages, none ar e sent .
ICMP
Found in RFC 1885 and or iginal l y f ound in RFC 792.
The f unct ions of ICMP ar e expl ained in 1885, but many ot her RFCs ar e
r ef er enced:
1970 f or Neighbor Discover y
1191 f or Pat h MTU Discover y
IPv4 ext ension.
Cont inues t o pr ovide some maint enance f or an unr el iabl e IPv6.
No ICMPv6 messages ar e sent f or ICMPv6 er r or s.
ICMPv6 is used by IPv6 nodes t o r epor t er r or s encount er ed in pr ocessing packet s, and t o
per f or m ot her int er net -l ayer f unct ions, such as diagnost ics (ICMPv6 ping) and
mul t icast member ship r epor t ing. ICMPv6 is an int egr al par t of IPv6 and must be f ul l y
impl ement ed by ever y IPv6 node.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 175
ICMPv6 Encapsulation
The f ol l owing sl ide shows t he encapsul at ion of ICMP in IPv6.
ICMPv6 Encapsul at ion

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 176
ICMPv6 and ICMPv4
ICMPv6 cl eaned up ICMPv4, mainl y any cont r ol messages t hat wer e not used (gone f r om
being specif ical l y ident if ied as ICMP messages ar e t imest amp, t imest amp r epl y, sour ce
quench, inf or mat ion r equest and r epl y). Most of t hese pr ocedur es ar e incor por at ed int o
ot her pr ot ocol s. For exampl e, sour ce quench is not used anymor e, f or ot her mechanisms,
such as TCP sl ow st ar t and congest ion cont r ol , wer e f ound t o be mor e usef ul . Why
put t he onus on t he r out er s when a mechanism is bet t er def ined and mor e usef ul
el sewher e? Al so, cer t ain codes f or a specif ic t ype have been moved or el iminat ed (f or
exampl e, sour ce r out e f ail ed code f or t he Dest inat ion Unr eachabl e Type). The addr ess
f iel ds, obviousl y, had t o be ext ended t o handl e ICMPv6 128-bit addr essing. The
mul t icast cont r ol f unct ions of IGMP wer e al so incl uded in ICMPv6 t o al l ow f or t he
gr oup member ship Quer y, Repor t , and Ter minat ion. Wit h al l of t he changes just
discussed, ICMPv6 is not backwar ds compat ibl e wit h ICMPv4. It uses t he next -header
f unct ion of IP and t he next -header t ype of 56. One l ast change is t hat ICMPv4 messages
copied t he or iginal IP header and 64 bit s of dat a in t he r et ur ned message. The except ion
t o t his is Echo Request or Echo Repl y. ICMPv6 al l ows f or a maximum of 576 byt es of dat a
t o be copied f r om t he of f ending dat agr am.
The f or mat of t he ICMPv6 header is shown in t he sl ide. It is t he same f or mat as ICMPv4.
The t ype f iel d indicat es t he t ype of t he message. It s val ue det er mines t he f or mat of t he
r emaining dat a. Er r or messages ar e ident if ied as such by 0 a 0 in t he high-or der bit of
t heir message Type f iel d val ues. Thus, er r or messages have message Types f r om 0 t o 127;
inf or mat ional messages have message Types f r om 128 t o 255. The code f iel d depends on
t he message t ype and f ur t her ident if ies t he ICMP message. The checksum f iel d is used t o
det ect dat a cor r upt ion in t he ICMPv6 message and par t s of t he IPv6 header . For t he most
par t , t he dest inat ion addr ess is set t o t he sour ce addr ess of t he pr eviousl y r eceived
of f ending packet .
ICMPv6 and ICMPv4
Cl eaned up ICMPv4.
Timest amp, sour ce quench, and inf or mat ion r equest and r epl y wer e
del et ed (picked up by ot her pr ot ocol s)
El iminat ed unused codes and t ypes.
IGMP is moved int o ICMPv6.
ICMPv6 is not compat ibl e wit h ICMPv4; however , it is t he same f or mat
ICMPv6 does copy mor e of t he of f ending dat agr am when sending an er r or
message.
Er r or messages have t ypes f r om 0127 and inf or mat ional messages have t ypes
f r om 128255.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 177
ICMPv6 Error Messages
ICMPv6 Er r or Messages
Dest inat ion Unr eachabl e:
No r out e t o dest inat ion
Communicat ion wit h dest inat ion administ r at ivel y pr ohibit ed
Not a neighbor
Addr ess Unr eachabl e
Por t Unr eachabl e
Packet Too Big:
Ret ur ns t he l ar gest packet size avail abl e f or t he f or war ded por t
Dest inat ion Unr eachabl e
Type: 1
Code:
0 No Rout e t o Dest inat ion. Ther e was no cor r esponding r out e in t he
r out er s f or war ding t abl e (onl y f or r out er s t hat do not possess a def aul t
r out e ent r y).
1 Communicat ion wit h Dest inat ion Administ r at ivel y Pr ohibit ed. For
exampl e, a f ir ewal l or ot her r est r ict ive administ r at ive command.
2 Not a Neighbor . Ther e was an at t empt t o del iver t he dat agr am t o a
neighbor t hat was indicat ed in t he st r ict sour ce r out ing ent r ies, but t he
next hop indicat ed is not a neighbor of t his r out er .
3 Addr ess Unr eachabl e. The r out er coul d not r esol ve t he l ink-l ayer
addr ess f or t he indicat ed net wor k addr ess.
4 Por t Unr eachabl e. The dest inat ion does not have a ser vice por t avail abl e
(not a har dwar e por t !). For exampl e, t he dat agr am is int ended f or TCP, but
al l avail abl e r esour ces ar e t aken f or TCP (t her e ar e no l ist ener por t s
avail abl e). Or , t he dat agr am was sent t o a ser vice por t t hat t he dest inat ion
does not suppor t ; f or exampl e, whois, or f inger , or t he r out e daemon.
The f ir st 32 bit s af t er t he ICMP header ar e unused and must be init ial ized t o 0 by
t he sender and ignor ed by t he r eceiver . Dest inat ion Unr eachabl e messages
gener al l y or iginat e f r om a r out er , but can al so be gener at ed by t he or iginat ed
node. They ar e gener at ed f or any r eason except congest ion. Ther e ar e no ICMP
messages t o indicat e congest ion (ot her pr ot ocol s monit or and r epor t t his
condit ion).
Packet Too Big
Type: 2
Code: 0
The f ir st 32 bit s af t er t he ICMP header indicat e t he maximum t r ansmission
unit (MTU) f or t he sel ect ed f or war ded (next hop) por t . This er r or message is
impor t ant , f or dat agr ams do not necessar il y have t o be 576 byt es in size.
FDDI-t o-Token-Ring t opol ogies, f or exampl e, do ver y wel l wit h st r eaming
l ar ge packet s. This is an indicat or of t he size of a packet t o be f or war ded
al ong t he pat h f r om sour ce t o dest inat ion. This is t he pat h MTU discover y
pr ocedur e, which is out l ined in RFC 1191. This er r or message al so pr ovides
an except ion t o t he r ul es: It can be sent in r esponse t o a packet r eceived
wit h an IPv6 mul t icast dest inat ion addr ess, or a l ink-l ayer mul t icast or
l ink-l ayer br oadcast addr ess.
Time Exceeded
Type: 3
Code:
0 Hop l imit exceeded in t r ansit
1 Fr agment r eassembl y t ime exceeded
The f ir st 32 bit s of t he ICMP message ar e specif ied as unused f or al l code
val ues and must be init ial ized t o 0 by t he sender and ignor ed by t he
r eceiver . This can be sent if a r out er r eceives a packet wit h a hop l imit of 0,
or a r out er decr ement s a packet s hop l imit t o 0. The packet t hen must be
discar ded, and an ICMPv6 Time Exceeded message wit h Code 0 must be sent t o
t he sour ce of t he packet . This indicat es eit her a r out ing l oop or t oo smal l
an init ial hop l imit val ue.
ICMPv6 Er r or Messages (cont inued)
Time Exceeded.
Hop l imit exceeded in t r ansit
Fr agment r eassembl y t ime exceeded
Par amet er Pr obl em.
Er r oneous header f iel d encount er ed
Unr ecognized nest header t ype encount er ed
Unr ecognized IPv6 opt ion
Par amet er Pr obl em
Type: 4
Code:
0 Er r oneous header f iel d encount er ed
1 Unr ecognized Next Header t ype encount er ed
2 Unr ecognized IPv6 opt ion encount er ed
The f ir st 32 bit s of t he ICMP message compr ise a point er t hat ident if ies t he
oct et of f set wit hin t he invoking packet wher e t he er r or was det ect ed. It
point s beyond t he end of t he ICMPv6 packet if t he f iel d in er r or is l ar ger
t han t he 576-byt e l imit of an ICMPv6 er r or message.
If an IPv6 node cannot pr ocess t he dat agr am due t o some er r or in t he header s, it must
discar d t he packet and shoul d send an ICMPv6 Par amet er Pr obl em message t o t he
packet s sour ce, indicat ing t he t ype and l ocat ion of t he pr obl em. A point er f iel d is
pr ovided t o indicat e t he t ype of pr obl em. The point er f iel d indicat es t he point in t he
or iginat ing header wher e t he er r or was det ect ed. For exampl e, an ICMPv6 message wit h
Type f iel d = 4, Code f iel d = 1, and Point er f iel d = 40, woul d indicat e t hat t he IPv6
ext ension header f ol l owing t he IPv6 header of t he or iginal packet hol ds an
unr ecognized Next Header f iel d val ue.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 178
ICMP Informational Messages
Echo Request
Type: 128
Code: 0
The f ir st 16 bit s of t he ICMP message ar e an ident if ier t o aid in t he
const r uct ion of an Echo Repl y t o an Echo Request . It may cont ain a 0. The
next 16 bit s ar e a sequence number t o aid in mat ching specif ical l y mul t ipl e
echo r equest s f r om t he same sour ce. It , t oo, may cont ain a 0.
The r emaining message is opt ion dat a t hat may have been t yped in on t he
r equest and is echoed on t he r epl y.
This is t he PING command t hat you may have t yped in. For exampl e, PING
192.1.1.1 is an echo r equest t o an echo ser ver r esiding on host 192.1.1.1.
Echo Repl y
Type: 129
Code: 0
The f ir st 16 bit s (af t er t he ICMP header ) compr ise an ident if ier f iel d f r om
t he pr eviousl y r eceived Echo Request message, which is used t o mat ch
r epl ies wit h r equest s. The next 16 bit s compr ise a sequence number f r om t he
node t hat sent t he echo r equest number message. This is usef ul t o mat ch
mul t ipl e r equest s f r om t he same host .
The r est of t he message cont ains echoed dat a copied f r om t he r eceived echo
r equest .
ICMP Inf or mat ional Messages
Echo Request
Echo Repl y
Good ol PING

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 179
ICMP and Neighbor Discovery
ICMP and Neighbor Discover y
Rout er Sol icit at ion
Rout er Adver t isement
Neighbor Sol icit at ion
Neighbor Adver t isement
Redir ect
Addr ess r esol ut ion is accompl ished via Neighbor Discover y messages, which ar e
gener at ed and pr ocessed by ICMP. The f ol l owing ar e t hose messages:
Rout er Sol icit at ion. Host s send Rout er Sol icit at ions in or der t o pr ompt r out er s
t o gener at e Rout er Adver t isement s quickl y.
Rout er Adver t isement . Rout er s send out Rout er Adver t isement messages
per iodical l y, or in r esponse t o Rout er Sol icit at ions. These messages cont ain
inf or mat ion r el at ed t o t he l ocal pr ef ixes and if t he r out er can act as a def aul t
r out er .
Neighbor Sol icit at ion. Nodes send Neighbor Sol icit at ions t o r equest t he l ink-
l ayer addr ess of a t ar get node whil e al so pr oviding t heir own l ink-l ayer addr ess
t o t he t ar get . Neighbor Sol icit at ions ar e mul t icast when t he node needs t o
r esol ve an addr ess and unicast when t he node seeks t o ver if y t he r eachabil it y of
a neighbor .
Neighbor Adver t isement . A node sends Neighbor Adver t isement s in r esponse t o
Neighbor Sol icit at ions, and sends unsol icit ed Neighbor Adver t isement s in or der t o
(unr el iabl y) pr opagat e new inf or mat ion quickl y. For exampl e, if a node has
det er mined some changes, such a l ink-l evel addr ess change, it can quickl y r el ay
t his inf or mat ion t o it s neighbor s.
Redir ect . Rout er s send Redir ect packet s t o inf or m a host of a bet t er f ir st -hop
node on t he pat h t o a dest inat ion. Host s can be r edir ect ed t o a bet t er f ir st -hop
r out er , but can al so be inf or med by a r edir ect t hat t he dest inat ion is in f act a
neighbor . The l at t er is accompl ished by set t ing t he ICMP Tar get Addr ess equal t o
t he ICMP Dest inat ion Addr ess.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 180
ICMPv6 and Multicast
Gr oup Member ship messages
The f unct ions of IGMP wer e moved int o ICMPv6. The ICMPv6 Gr oup Member ship
messages ar e used t o convey inf or mat ion about mul t icast gr oup member ship f r om
nodes t o t heir neighbor ing r out er s. Pl ease r ef er t o Par t Six f or mor e inf or mat ion
on t he IGMP f unct ions. This f unct ion of ICMPv6 al l ows f or IGMP messages t o be
sent . These ar e Gr oup Member ship messages f or Quer y, Repor t s, and Reduct ion (or
l eaving a gr oup wit h a t er minat ion message). Due t o t he dynamic nat ur e of t he
IPv6 and it s Neighbor Discover y pr ot ocol s (r out er s and host s), IGMP f unct ions
wer e moved int o t he ICMP pr ot ocol suit e. For exampl e, when a node init ial izes (in
an IPv6 envir onment ), it must immediat el y join t he al l -nodes mul t icast addr ess on
t hat int er f ace, as wel l as t he sol icit ed-node mul t icast addr ess cor r esponding t o
each of t he IP addr esses assigned t o t he int er f ace.
In t he IPv6 header t he Dest inat ion Addr ess is set as f ol l ows: In a Gr oup
Member ship Quer y message, t he mul t icast addr ess of t he gr oup being quer ied, or
t he Link-Local Al l -Nodes mul t icast addr ess. In a Gr oup Member ship Repor t or a
Gr oup Member ship Reduct ion message, t he mul t icast addr ess of t he gr oup being
r epor t ed or t er minat ed.
ICMPv6 and Mul t icast
Gr oup Member ship messages
Gr oup Member ship Quer y
Gr oup Member ship Repor t
Gr oup Member ship Reduct ion (Leave Gr oup)
The hop l imit is set t o 1 t o ensur e t his message does not l eave t he l ocal subnet wor k. The
ICMPv6 f iel ds ar e set as f ol l ows:
Type:
130Gr oup Member ship Quer y
131Gr oup Member ship Repor t
132Gr oup Member ship Reduct ion
Code: 0
The f ir st 16 bit s af t er t he ICMP header ar e used f or t he Maximum Response Del ay.
In Quer y messages, it is t he maximum t ime t hat r esponding Repor t messages may be
del ayed, in mil l iseconds. In Repor t and Reduct ion messages, t his f iel d is init ial ized
t o 0 by t he sender and ignor ed by r eceiver s. The next 16 bit s ar e unused and t hey
ar e init ial ized t o 0 by t he sender and ignor ed by r eceiver s. The r est of t he message
is f il l ed wit h t he Mul t icast Addr ess, which is t he addr ess of t he mul t icast gr oup
t o which t he message is being sent . In Quer y messages, t he Mul t icast Addr ess f iel d
may be 0, impl ying a quer y f or al l gr oups.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 181
IPv6 Cache Entries
IPv6 Cache Ent r ies
Dest inat ion cachecont ains l ink l ayer inf or mat ion about dest inat ions t o
which dat a has been r ecent l y sent .
Neighbor cachecont ains l ink-l ayer inf or mat ion about a neighbor .
Pr ef ix List cachecr eat ed f r om r out er adver t isement s, t his is a l ist ing of
l ocal pr ef ixes.
Rout er List cachecont ains inf or mat ion about t hose r out er s t o which
packet s may be sent .
Al l of t he f ol l owing caches ar e buil t in par t by t he Neighbor Discover y pr ocess.
Inst ead of t he simpl ex ARP cache used wit h IPv4, IPv6 maint ains f our caches. (Act ual l y,
f our caches may not be maint ained. Impl ement er s can int egr at e t his inf or mat ion any
way t hey wish, incl uding simpl y using one l ar ge t abl e or f our l inked t abl es in one
dat abase, but al l t he r equir ed inf or mat ion must be gat her ed and maint ained. The
ent r ies ar e shown her e separ at el y f or simpl icit y r easons.)
Dest inat ion cache. This cache cont ains inf or mat ion about dest inat ions t o which
t r af f ic has been r ecent l y sent . It incl udes bot h l ocal and r emot e dest inat ions
and associat es an IPv6 addr ess of a dest inat ion wit h t hat of t he neighbor t owar d
which t he packet s ar e sent . This cache is updat ed wit h inf or mat ion l ear ned f r om
ICMP Redir ect messages. Ot her inf or mat ion such as t he Pat h MTU (PMTU) and
r ound-t r ip t imer s maint ained by t r anspor t pr ot ocol s can be in t his cache. Ent r ies
ar e cr eat ed by t he next -hop det er minat ion pr ocedur e.
Neighbor cache. A r ecor d t hat cont ains inf or mat ion about individual neighbor s
(host or a r out er may be an ent r y) t o which t r af f ic has been r ecent l y sent . It
cont ains such inf or mat ion as t he neighbor s l ink-l ayer addr ess, an indicat ion of
whet her t he neighbor is a host or a r out er , and a point er t o any queued packet s
wait ing f or addr ess r esol ut ion t o compl et e. This inf or mat ion is al so used by t he
Neighbor Unr eachabil it y pr ot ocol .
Pr ef ix List cache. Cr eat ed f r om inf or mat ion r eceived in Rout er Adver t isement s,
t his is a l ist ing of t he l ocal pr ef ixes and an individual expir at ion t imer t hat
def ines a set of addr esses t hat ar e on-l ink. Nodes r eceive and st or e t his
inf or mat ion t hat is t r ansmit t ed f r om a r out er in t his cache. This enabl es a node t o
det er mine a r emot e dest inat ion. A special inf init y t imer val ue specif ies t hat a
pr ef ix r emains val id f or ever , unl ess a new (f init e) val ue is r eceived in a
subsequent adver t isement . For exampl e, t he pr ef ix of t he l ocal l ink t o which a
node is at t ached is consider ed t o be on t he pr ef ix l ist wit h an inf init e inval idat ion
t imer , r egar dl ess of whet her r out er s ar e adver t ising a pr ef ix f or it . Received
r out er adver t isement s cannot change t his val ue.
Rout er List cache. Buil t f r om r eceived r out er adver t isement s, t his l ist cont ain
inf or mat ion about t hose r out er s t o which packet s may be sent . Rout er List ent r ies
point t o ent r ies in t he Neighbor cache; t he al gor it hm f or sel ect ing a def aul t
r out er f avor s r out er s known t o be r eachabl e over t hose whose r eachabil it y is
suspect . Each ent r y is mat ed wit h an associat ed expir at ion t imer val ue (ext r act ed
f r om Rout er Adver t isement s). This t imer is used t o del et e ent r ies t hat t he node
has not r eceived adver t isement s f r om.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 182
IPv6 Algorithm
IPv6 Al gor it hm
Easier if you under st and RFC 1970.
To t r ansmit a dat agr am, t he sour ce must consul t t he dest inat ion cache, pr ef ix
l ist , and t he def aul t r out er .
It needs t o det er mine t he next hop
A sour ce f ir st l ooks in t he dest inat ion cache f or a mat ching ent r y t o t he
dest inat ion IP addr ess.
If one is not f ound her e, consul t t he pr ef ix l ist cache
Local addr ess, t he next hop is simpl y t hat of t he dest inat ion IP addr ess
If you ar e l ooking f or mor e inf or mat ion on how IPv6 r out es dat agr ams, you must f ir st
r ead RFC 1970. This is a ver y impor t ant RFC f or your under st anding of t he IPv6 r out ing
al gor it hm. It cont ains t he Neighbor Discover y mechanism and incl udes ever yt hing on
IPv6 subnet s, such as host s and r out er s. IPv6 does not use ARP; it uses Neighbor
Discover y.
IPv6 needs t he pr eviousl y l ist ed cache ent r ies t o assist in r out ing a dat agr am. If an IPv6
node needs t o t r ansmit a dat agr am, it must f ir st f ind out t he next hop t owar ds t he
dest inat ion (known as next-hop determination). In ot her wor ds, it must det er mine if t he
dest inat ion st at ion is l ocal or r emot e, and t her ef or e sends t he packet dir ect l y t o t he
dest inat ion or ut il izes a r out er . This pr ocess uses t he Pr ef ix List cache and t he
Dest inat ion cache. Once t he next hop is known, it must det er mine t he next hops l ink-
l ayer addr ess.
To r out e a dat agr am in IPv6, we consul t t he Dest inat ion cache, t he Pr ef ix List , and t he
Def aul t Rout er List t o det er mine t he IP addr ess of t he appr opr iat e next hop. The next -
hop det er minat ion is invoked t o cr eat e a Dest inat ion Cache ent r y. The r esul t s of next -
hop det er minat ion comput at ions ar e saved in t he Dest inat ion cache (which al so cont ains
updat es l ear ned f r om Redir ect messages).
Ther ef or e, a sending node f ir st l ooks in t he Dest inat ion cache f or a mat ching ent r y t o
t he dest inat ion IP addr ess. If one is not f ound, t he Pr ef ix List cache is consul t ed. The
sending node compar es t he dest inat ion pr ef ix mask wit h t he ent r ies in t he Pr ef ix List
cache. If a mat ch is f ound, it is t hen det er mined whet her t he dest inat ion is l ocal or
r emot e. If it is l ocal , t hen t he next -hop addr ess is simpl y t he dest inat ion addr ess of t he
dat agr am; ot her wise, t he dest inat ion is r emot e and t he node must sel ect a r out er f r om
t he def aul t r out er l ist . If t her e ar e no ent r ies in t he def aul t r out er l ist , t hen t he
dest inat ion is assumed t o be l ocal . The r esul t s of t his next -hop det er minat ion l ookup
ar e st or ed in t he Dest inat ion cache (al ong wit h r eceived ICMP r edir ect s).
Once t he next hop has been det er mined, t he cor r esponding ent r y is added t o t he
Dest inat ion cache and t he Neighbor cache is used t o det er mine t he media addr ess of t hat
next -hop neighbor .
Once t he IP addr ess of t he next -hop node is known, t he sender examines t he Neighbor
cache f or l ink-l ayer inf or mat ion about t hat neighbor . If no ent r y exist s, t he sender
cr eat es one, and t hen st ar t s t he addr ess r esol ut ion pr ocedur e t o compl et e t he ent r y.
The dat agr am t o be t r ansmit t ed must wait f or t his t o compl et e. Once t he neighbor ent r y
is compl et e, t his ent r y wil l be used f or subsequent t r ansf er s t o t hat dest inat ion
st at ion. No ot her pr ocedur es ar e needed.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 183
RFCs Related to IPv6
1883: Descr ibes t he IPv6 pr ot ocol (RFC 2147 updat es [does not r epl ace] RFC 1883).
2147 PS: D. Bor man, TCP and UDP over IPv6 Jumbogr ams, 05/23/97, (3 pages) (.t xt f or mat )
(updat es RFC 1883).
2133 I: R. Gil l igan, S. Thomson, J. Bound, W. St evens, Basic Socket Int er f ace Ext ensions
f or IPv6, 04/21/97 (32 pages).
2080 PS: G. Mal kin, R. Minnear , RIPng f or IPv6, 01/10/97 (19 pages).
2073 PS: Y. Rekht er , P. Lot hber g, R. Hinden, S. Deer ing, J. Post el , An IPv6 Pr ovider -
Based Unicast Addr ess For mat , 01/08/97 (7 pages).
2030 I: D. Mil l s, Simpl e Net wor k Time Pr ot ocol (SNTP) Ver sion 4 f or IPv4, IPv6, and OSI,
10/30/96 (18 pages).
2019 PS: M. Cr awf or d, Tr ansmission of IPv6 Packet s Over FDDI, 10/17/96 (6 pages).
1972 PS: M. Cr awf or d, A Met hod f or t he Tr ansmission of IPv6 Packet s Over Et her net
Net wor ks, 08/16/96 (4 pages).
1971 PS: S. Thomson, T. Nar t en, IPv6 St at el ess Addr ess Aut oconf igur at ion, 08/16/96 (23
pages).
1970 PS: T. Nar t en, E. Nor dmar k, W. Simpson, Neighbor Discover y f or IP Ver sion 6 (IPv6),
08/16/96 (82 pages).
1933 PS: R. Gil l igan, E. Nor dmar k, Tr ansit ion Mechanisms f or IPv6 Host s and Rout er s,
04/08/96 (22 pages).
1924 I: R. El z, A Compact Repr esent at ion of IPv6 Addr esses, 04/01/96 (6 pages).
1897 E: R. Hinden, J. Post el , IPv6 Test ing Addr ess Al l ocat ion, 01/25/96 (4 pages).
1888 E: J. Bound, B. Car pent er , D. Har r ingt on, J. Houl dswor t h, A. Ll oyd, OSI NSAPs and
IPv6, 08/16/96 (16 pages).
1887 I: Y. Rekht er , T. Li, An Ar chit ect ur e f or IPv6 Unicast Addr ess Al l ocat ion, 01/04/96
(25 pages).
1885 PS: A. Cont a, S. Deer ing, Int er net Cont r ol Message Pr ot ocol (ICMPv6) f or t he
Int er net Pr ot ocol Ver sion 6 (IPv6), 01/04/96 (20 pages).
1884 PS: R. Hinden, S. Deer ing, IP Ver sion 6 Addr essing Ar chit ect ur e, 01/04/96 (18 pages)
(.t xt f or mat ).
1883 PS: S. Deer ing, R. Hinden, Int er net Pr ot ocol , Ver sion 6 (IPv6) Specif icat ion,
01/04/96 (37 pages) (updat ed by RFC 2147).
1881 I: I. IESG, IPv6 Addr ess Al l ocat ion Management , 12/26/95 (2 pages).
1809 I: C. Par t r idge, Using t he Fl ow Label Fiel d in IPv6, 06/14/95 (6 pages).

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Part Four
Beyond the I P Layer
Chapter 184
Internet Control Message Protocol (ICMP)
The job of IP is t o addr ess and r out e (l ocal or r emot e) a dat agr am. That s it . Once
t r ansmit t ed, IP l ooks f or t he next packet t o t r ansmit or r eceive. Since IP is a
connect ionl ess, unr el iabl e del iver y ser vice, al l owing r out er s and host s on an int er net
t o oper at e independent l y, t her e ar e cer t ain inst ances when er r or s wil l occur . Some of
t hese er r or s coul d be: a packet is not r out ed t o t he dest inat ion net wor k, t he r out er is
t oo congest ed t o handl e any mor e packet s, or a host may not be f ound on t he int er net .
Ther e is no pr ovision in IP t o gener at e er r or messages or cont r ol messages; ICMP is t he
pr ot ocol t hat handl es t hese inst ances f or IP. The pur pose of t hese cont r ol messages is t o
pr ovide f eedback about pr obl ems in t he communicat ion envir onment , not t o make IP
r el iabl e.
ICMP does not use a t r anspor t l ayer and r uns dir ect l y on t op of IP. Ther ef or e, ICMP is
an unr el iabl e f unct ion and no ICMP er r or message is sent f or an ICMP message.
For exampl e, when a t r ansmit t ing st at ion t r ansmit s a packet using indir ect r out ing t o a
r emot e dest inat ion, what happens if a f inal r out er cannot f ind t he endst at ion (t he
endst at ion is not in t he r out er s ARP cache and it does not r espond t o t he r out er s ARP
r equest )? This is one of t he r easons f or t he ICMP ser vice. The r out er sends an ICMP
message back t o t he or iginat or of t he dat agr am, endst at ion A, t hat t he dest inat ion
node cannot be f ound. This er r or message is t hen t r ansmit t ed t o t he user .
Not ice t hat each ICMP message has a Type f iel d and a Code f iel d. The Type f iel d
ident if ies t he ICMP dat agr am and t he Code f iel d pr ovides f ur t her gr anul ar it y. For
exampl e, Type Code 3 indicat es t hat t he dest inat ion is unr eachabl e, but a Code f iel d of 1
gives us a f ur t her cl ue t hat t he dest inat ion host (and not t he por t or net wor k) is
unr eachabl e. This coul d mean t he net wor k was f ound but no st at ion r esponded t o an
ARP r equest when t r ansmit t ed by t he sending r out er . The r eceiver of t hat ICMP
dat agr am woul d t hen post a message eit her t o a scr een or t o a l og f il e int er pr et ing t he
ICMP message. Tr y t his on your own. Tr y pinging a device t hat you know does not exist .
Int er net Cont r ol Message Pr ot ocol (ICMP)
ICMP wil l al so copy t he f ir st 64 bit s (IPv6 incr eases t his t o 512 byt es) of dat a f r om t he
or iginal dat agr am int o it s own. This pr ovides some inf or mat ion about t he of f ending
dat agr am and can be used in t r oubl eshoot ing. ICMPv6 pr ovides mor e of t he or iginal
dat a.
The sl ide shows t he f or mat f or ICMP and t he encapsul at ion inside of IP. ICMP r epor t s on
many ent it ies on an int er net . As t he t abl e in t he sl ide shows, t her e ar e many f unct ions
of ICMP as indicat ed by t he use of a Code f iel d. ICMP dat agr ams ar e r out abl e since t hey
use IP t o del iver t heir messages. IP r esides on t op of IP and does not use TCP or UDP f or
it s t r anspor t . ICMP is a separ at e pr ot ocol f r om IP, but it is an int egr al par t of IPs
oper at ion.
ICMP is ext ensibl e beyond cont r ol mechanisms as you wil l see next .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 185
ICMP PING
Ask anyone invol ved in t r oubl eshoot ing an IP net wor k and he or she wil l t el l you t he
most -used appl icat ion is t he PING appl icat ionone of t he most common uses f or ICMP is
t he PING pr ogr am. Ping (not or iginal l y named, but commonl y cal l ed Packet Int er net
Gr oper ) is an ICMP message t hat t r ies t o l ocat e ot her st at ions on t he int er net t o see if
t hey ar e act ive or t o see if a pat h is up. PING is an echo pr ogr am. The or iginat or of a
dat agr am sends a PING r equest and t he dest inat ion st at ion shoul d echo t his r equest .
Inf or mat ion can be cont ained in t he PING dat agr am, which t he dest inat ion st at ion
shoul d echo. PING has t he f ol l owing f or mat (using Windows 95):
Usage
ping [-t] [-a] [-n count] [-l size] [-f] [-i TTL] [-v TOS]
[-r count] [-s count] [[-j host-list] | [-k host-list]]
[-w timeout] destination-list
Opt ions
-t Ping t he specif ied host unt il int er r upt ed
-a Resol ve addr esses t o host names
-n count Number of echo r equest s t o send
-l size Send buf f er size
-f Set Dont Fr agment f l ag in packet
-i TTL Time t o Live
-v TOS Type of Ser vice
-r count Recor d r out e f or count hops
-s count Timest amp f or count hops
-j host -l ist Loose sour ce r out e al ong host -l ist
-k host -l ist St r ict sour ce r out e al ong host -l ist
-w t imeout Timeout in mil l iseconds t o wait f or each r epl y
Not ice t hat you can t est many t hings al ong t he pat h t o a dest inat ion using t he PING
command; f or exampl e, t iming, sour ce r out e, r out e r ecor ding, and dat a. Anot her use of
t he PING command is t o check f or net wor k del ays al ong a pat h. The r esponse t o a PING
r equest can r epor t t he r esponse del ay (usual l y measur ed in mil l iseconds).
A l ot of net wor k management sof t war e uses t his command t o det er mine t he st at us of a
given st at ion. Net wor k management sof t war e wil l buil d maps t o show t he t opol ogy and
pl acement of net wor k st at ions. Using col or s (gr een f or act ive, yel l ow f or possibl e
er r or s, and r ed f or not r esponding), a net wor k manager can t r ace pr obl ems on t he
net wor k. A l ot of t he wor k is done t hr ough t he use of t he PING ut il it y.
ICMP PING

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 186
More ICMP Functions
ICMP has added f unct ions over t he year s as indicat ed by RFCs 1256 (Rout er Discover y)
and 1393 (ICMP Tr acer out e). ICMP r unning in a r out er can r espond t o a host s r equest
t o f ind t he subnet addr ess mask f or it s net wor k. A host , upon st ar t up, can r equest of a
r out er t he subnet mask assigned t o t he net wor k.
Al t hough not r eal l y used anymor e (t her e ar e bet t er met hods f or cont r ol l ing t r af f ic,
such as t he Sl ow St ar t al gor it hm discussed in a moment ). Source quench is t he
endst at ions abil it y t o indicat e t o t he or iginat or of a message t hat t he host cannot
accept t he r at e at which t he sender is submit t ing t he packet s. A sour ce quench packet is
cont inual l y gener at ed t o t he or iginat or unt il t he r at e of dat a f l ow sl ows down. The
int ended r ecipient of a sour ce quench wil l cont inue t o sl ow down it s dat a r at e unt il it
r eceives no mor e sour ce quench packet s. The st at ion t hat was r equest ed t o sl ow down
wil l t hen st ar t t o incr ease t he dat a r at e again. This is simil ar t o a f l ow cont r ol , except
t hat it is mor e l ike t hr ot t l e cont r ol t he dat a is not st opped, mer el y sl owed down and
t hen incr eased again. It is gener at ed by any net wor k st at ion on t he int er net t o indicat e
t hat t he node cannot handl e t he r at e of t he incoming dat a. This ICMP t ype was not
incl uded in ICMPv6. It was f ound t hat ot her pr ot ocol s handl e congest ion bet t er t han
f or cing t he r out er s t o handl e it .
Ther e ar e many ot her uses of t he ICMP pr ot ocol . When a r out er r eceives a dat agr am, it
may det er mine a bet t er r out er t hat can pr ovide a shor t er r out e t o t he dest inat ion
net wor k. This is an ICMP Redir ect , and t his message inf or ms t he sender of a bet t er r out e.
If t he TTL f iel d is 0, a r out er wil l inf or m t he or iginat or of t his t hr ough an ICMP
message (Time Exceeded). A user s wor kst at ion can r equest a t imest amp f r om a r out er ,
asking it t o r epeat t he t ime when it r eceived a packet . This is used f or measur ing del ay
t o a dest inat ion.
Mor e ICMP Funct ions
ICMP has added f unct ions beyond what is in t he RFC.
Separ at e RFCs such as 1256 (Rout er Discover y) and 1393 (t r acer out e) have
been added as separ at e RFCs.
Sour ce Quench is not used anymor e.
The summar y of ICMP message t ypes ar e:
Echo Request and Repl y (PING)
Dest inat ion Unr eachabl e (host or net wor k)
Sour ce Quenchsl ow down t he r at e of t r ansmission
Redir ect (t el l a host t o t ake a bet t er pat h)
Time Exceeded (TTL decr ement ed t o 0)
Par amet er pr obl em
Timest amp and Repl yr ecor d t he t ime a dat agr am ar r ived/send t he
inf or mat ion back t o t he or iginat or
Inf or mat ion Request and Repl ynot impl ement ed
Summar y of Message Types
0 Echo Repl y
3 Dest inat ion Unr eachabl e
4 Sour ce Quench
5 Redir ect (t her e is a bet t er r out e message)
8 Echo
11 Time Exceeded (TTL)
12 Par amet er Pr obl em
13 Timest amp
14 Timest amp Repl y
15 Inf or mat ion Request
16 Inf or mat ion Repl y

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 187
User Datagram Protocol (UDP)
A t r anspor t l ayer al l ows communicat ion t o exist bet ween net wor k st at ions. Dat a is
handed down t o t his l ayer f r om an upper -l evel appl icat ion. The t r anspor t l ayer t hen
envel opes t he dat a wit h it s header s and gives it t o t he IP l ayer f or t r ansmission ont o
t he net wor k. Ther e ar e t wo t r anspor t -l ayer pr ot ocol s in TCP/IP: UDP and TCP.
The f unct ional it y of UDP shoul d sound f amil iar . It is a connect ionl ess, unr el iabl e
t r anspor t ser vice. It does not issue an acknowl edgment t o t he sender upon t he r eceipt
of dat a. It does not pr ovide or der t o t he incoming packet s, and may l ose packet s or
dupl icat e t hem wit hout issuing an er r or message t o t he sender . This shoul d sound l ike
t he IP pr ot ocol . The onl y of f er ing t hat UDP has is t he assignment and management of
por t number s t o uniquel y ident if y t he individual appl icat ions t hat r un on a net wor k
st at ion and a checksum f or simpl ex er r or det ect ion. UDP t ends t o r un f ast er t han TCP,
f or it has l ow over head (8 byt es in it s header compar ed t o TCPs t ypical 40 byt es). It is
used f or appl icat ions t hat do not need a r el iabl e t r anspor t . Some exampl es ar e net wor k
management , name ser ver , or appl icat ions t hat have buil t -in r el iabil it y.
Any appl icat ion pr ogr am t hat incor por at es t he use of UDP as it s t r anspor t -l evel ser vice
must pr ovide an acknowl edgment and sequence syst em t o ensur e t hat packet s ar r ive,
and t hat t hey ar r ive in t he same or der as t hey wer e sent .
As shown in t he sl ide, an appl icat ions dat a is encapsul at ed in a UDP header . The
t r anspor t l ayer has it s own header , independent of al l ot her l ayer s, t hat it pr ef aces t o
t he dat a handed t o it f r om it s upper -l ayer pr ot ocol . The UDP header and it s dat a ar e
t hen encapsul at ed in an IP header . The IP pr ot ocol woul d t hen send t he dat agr am t o
t he dat a-l ink l ayer , which woul d t hen encapsul at e t he dat agr am wit h it s header s
(and/or t r ail er s) and send t he dat a t o t he physical l ayer f or act ual t r ansmission.
Upon r eceipt of t he packet , t he dat al ink woul d int er pr et t he addr ess as it s own, st r ip
of f it s header (and/or t r ail er s), and submit t he packet t o t he IP l ayer . IP woul d accept
t he packet based on t he cor r ect IP addr ess in t he IP header , st r ip of f it s header , and
submit t he packet t o t he UDP-l ayer sof t war e. The UDP l ayer accept s t he packet and
now has t o demul t ipl ex t he packet based on t he por t number in t he UDP header .
Looking at t he sl ide, t he packet header f or UDP is smal l (t he minimum packet size is 8
byt es), but f unct ional . The message l engt h indicat es t he size of t he UDP header and it s
dat a in byt es. The checksum is used t o check f or t he val idit y of t he UDP header and
dat a. It does not have t o be impl ement ed and woul d be set t o 0 if not impl ement ed. UDP
is pr imar il y used by appl icat ions t o simpl y pr ovide f or an appl icat ion MUX at t he
t r anspor t l ayer . This is descr ibed next .
User Dat agr am Pr ot ocol (UDP)

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 188
Multiplexing and Demultiplexing
UDP accept s dat a f r om t he appl icat ion l ayer , f or mat s it (UDP header ) wit h it s
inf or mat ion, and pr esent s it t o t he IP l ayer f or net wor k del iver y. UDP wil l al so accept
dat a f r om t he IP l ayer and, depending on t he por t val ue, pr esent it t o t he appr opr iat e
appl icat ion. As shown in t he sl ide, UDP is r esponsibl e f or dir ect ing t he r est of t he packet
(af t er st r ipping of f it s header s) t o t he cor r ect pr ocess accor ding t o t he por t number
assigned in t he UDP header . This pr ocess is cal l ed demultiplexing. Ther e ar e many
dif f er ent t ypes of por t number s t o indicat e any appl icat ion r unning on t he net wor k
st at ion. UDP r eads t he Dest inat ion Por t f iel d of t he UDP header (demul t ipl ex) and gives
t he dat a t o t he appl icat ion. When t he appl icat ion (ident if ied by t he por t number )
init ial izes, t he st at ions oper at ing syst em wor ks in conjunct ion wit h it and pr ovides a
buf f er ar ea in which inf or mat ion may be st or ed. UDP wil l pl ace t he dat a in t his ar ea f or
r et r ieval by t he appl icat ion. UDP does pr ovide one er r or mechanism f or por t s t hat ar e
not val id. It can gener at e an ICMP Por t Unr eachabl e message t o be sent t o t he
or iginat or of t he packet .
Since t he TCP/IP pr ot ocol suit e incl udes appl icat ions t hat ar e specif ical l y wr it t en t o it
(TFTP, Domain Name Ser vice, et c.), t her e ar e st at ical l y assigned por t number s t hat
ident if y t hese appl icat ions. Cer t ain por t number s ar e r eser ved and cannot be used by
any unknown appl icat ion. The r eser ved por t number s ar e specif ied in RFC 1700.
Mul t ipl exing and Demul t ipl exing

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 189
Port Numbers
Review RFC 814. Since many net wor k appl icat ions may be r unning on t he same machine,
a met hod is needed t o al l ow access t o t hese appl icat ions, even t hough t hey r eside on t he
same machine and t he machine cont ains one IP addr ess. One IP addr ess and many
appl icat ions? How do we decide which dat agr am bel ongs t o which appl icat ion?
It woul d not be advant ageous t o assign each pr ocess an IP addr ess, nor t o change t he IP
addr essing scheme t o incl ude a mar ker t o ident if y a unique appl icat ion in t he machine.
Inst ead, bot h t he TCP and UDP pr ot ocol s pr ovide a concept known as ports (somet imes
mist akenl y cal l ed sockets, which is not cor r ect ). Por t s, al ong wit h an IP addr ess, al l ow
any appl icat ion in any machine on an int er net t o be uniquel y ident if ied.
Ther e ar e t hr ee dif f er ent t ypes of por t number s: assigned, registered, and dynamic. The RFC
of assigned number s (RFC 1700 at t he t ime of t his wr it ing) cont ains assigned and
r egist er ed number s. The f ir st 1024 por t s ar e assigned and in specif ic use and shoul d not
be used by any appl icat ion. The r emaining addr esses can be dynamic and r egist er ed (16
bit s al l ows f or 65,535 por t s) and can be used f r eel y, al t hough IANA does r equest t hat
vendor s r egist er t heir appl icat ion por t number s wit h t hem.
When a st at ion wishes t o communicat e t o a r emot e appl icat ion, it must ident if y t hat
appl icat ion in t he dat agr am. For exampl e, if a st at ion needed t o use a simpl e f il e
t r ansf er pr ot ocol known as trivial file transfer program (TFTP) on t he st at ion 130.1.1.1, it
woul d addr ess t he dat agr am t o st at ion 130.1.1.1 and inser t destination port number 69 in
t he UDP header . The source port number ident if ies t he appl icat ion on t he l ocal st at ion
t hat r equest ed t he f il e t r ansf er , and al l r esponse packet s gener at ed by t he dest inat ion
st at ion woul d be addr essed t o t hat por t number on t he sour ce st at ion. Gener al l y, t he
sour ce por t is r andoml y gener at ed by t he sour ce st at ion. If t he sour ce por t is not used
(br oadcast RIP updat e t abl es), it shoul d be set t o 0. So, when t he IP l ayer demul t ipl exes
t he packet and hands it t o UDP, UDP wil l pass t he dat a t o t he l ocal l y assigned por t
number f or it t o pr ocess t he dat a.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 190
Assigned, Registered, and Dynamic Port Numbers
Assigned, Regist er ed, and Dynamic Por t Number s
RFC 1700.
FTP sit e: f t p://f t p.isi.edu/in-not es/iana/assignment s.
Up-t o-dat e assignment s of number s
Assigned number s r ange f r om 01023.
Assigned ar e r eser ved by IANA and cannot be used
Used f or TCP, IP, UDP, and var ious appl icat ions such as TELNET
Regist er ed number s r ange f r om 102465535, and t hese ar e companies t hat have
r egist er ed t heir appl icat ion.
Dynamic por t number s al so r ange f r om 102465535.
Ref er ence RFC 1700 and t he FTP sit e f t p://f t p.isi.edu/in-not es/iana/assignment s (point
your URL t o t his addr ess on your br owser ). In t he TCP/IP pr ot ocol , UDP por t number s
come in t hr ee f l avor s: assigned, registered, and dynamic. Assigned number s come in t he
r ange of 01023 and ar e f ul l y cont r ol l ed by t he Int er net Assigned Number s Aut hor it y
(r ef er t o RFC 1700). These ar e number s t hat deal wit h pr ot ocol s such as TELNET, FTP,
Net wor k Time Pr ot ocol (NTP), and so on. No mat t er which impl ement at ion of TCP/IP (i.e.,
which vendor s TCP) is in use, t hose appl icat ions l ist ed beside t he por t number wil l
al ways be t he same (t hey ar e known as well-known port numbers). These ar e assigned by a
cent r al aut hor it y. In t his case, RFC 1700 spel l s out which pr ocesses ar e assigned t o
which por t number s. Assigned por t number s (t hose f or mal l y r eser ved t hr ough Int er net
Addr ess Number s Aut hor it y) r ange f r om 01023 f or TCP/UDP por t number s. Af t er t hat ,
any appl icat ion may use any por t number beyond 1023 but l ess t han 65,535. Some
companies have r egist er ed t heir por t number s wit h IANA and ot her companies r espect
t his by not using t he same por t number .
Her es an exampl e of an assigned por t number : If st at ion A want s t o access t he TFTP
pr ocess on st at ion B, it cal l s it in t he UDP header wit h a dest inat ion por t number of 69
(decimal ). The sour ce st at ion r equest ing TFTP ser vices al so has a por t number t hat is
dynamical l y assigned by it s TCP/IP st ack. RFC 1700 suggest s met hods f or assist ance in
assigning a dynamic por t number . In t his way, t he ser ver and cl ient can communicat e
wit h one anot her using t he por t number s t o uniquel y ident if y t he ser vice f or t hat
dat agr am.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 191
Dynamic Port Numbers
TCP/IP al so impl ement s dynamic por t number s. Since t he Por t Number f iel d in t he UDP
header is 16 bit s l ong, 65,535 por t s (minus t he assigned por t assignment s) ar e avail abl e
f or individual use. This r ange can be used f or r egist er ed and dynamic por t s. One use f or
a dynamic por t is as a sour ce st at ion t hat is r equest ing t he ser vices of TFTP on a r emot e
st at ion. The sour ce st at ion dynamical l y assigns it sel f an avail abl e por t number
(usual l y above 1024 t o use so t hat t he r emot e st at ion knows what por t t o access when
it t r ansf er s t he f il e). In ot her wor ds, if a user init iat es a t r ivial f il e t r ansf er (TFTP),
t he TFTP r equest packet sent t o t he TFTP ser ver incl udes in it s UDP header a dynamic
por t number of t he r equest ing net wor k st at ion t hat want ed t he TFTP, cal l ed t he
sour ce por t . Let s say it is assigned por t 2000. The dest inat ion por t number woul d be 69.
In t his way, t he ser ver wil l accept t he packet , give it t o t he TFTP pr ocess in t he host
and, when t he host r esponds, it wil l know how t o addr ess t he por t number in t he
r esponse packet . In t he r esponse packet , t he ser ver woul d f il l out t he UDP header wit h
a dest inat ion por t of 2000, sour ce por t of 69, and send t he packet back t o t he r equest ing
st at ion.
Anot her use is when net wor k vendor s impl ement pr opr iet ar y schemes on t heir devices;
f or exampl e, a pr opr iet ar y scheme f or a net wor k st at ion t o boot or a pr opr iet ar y scheme
t o al l ow net wor k management st at ist ics t o be gat her ed. Al l t hese appl icat ions ar e
val id and may r un on any TCP envir onment using a dynamic por t assignment .
Dynamic Por t Number s
The disadvant age of dynamic por t s occur s when a br oadcast IP dat agr am is t r ansmit t ed
t o t he net wor k using a dynamic por t . This por t coul d be used by anot her vendor on t he
net wor k, and anot her net wor k st at ion may invoke a pr ocess t o accommodat e t hat
r equest . This is r ar e, but has been known t o happen.
Dynamic por t number s ar e assigned by t he TCP/IP sof t war e at t he l ocal wor kst at ion,
and can be dupl icat ed f r om wor kst at ion t o wor kst at ion wit hout r espect t o t he
appl icat ion. This is because an appl icat ion on any net wor k st at ion is uniquel y ident if ied
by t he IP addr ess (net wor k number , host number ) and t he por t number . When t aken as a
whol e number , it is cal l ed t he socket number, and cannot be dupl icat ed on an IP net wor k
except by negl igence.
Final not e: Some peopl e l ike t o use t he t er ms port and socket int er changeabl y. You can,
but pr oper IP semant ics st at e t hat a por t number and a socket number ar e not t he same
t hing, as indicat ed in t he pr eceding par agr aph.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 192
Transmission Control Protocol (TCP)
Tr ansmission Cont r ol Pr ot ocol (TCP)
The pr ot ocol r esponsibl e f or t he r el iabl e t r ansmission and r ecept ion of dat a.
Unr el iabl e ser vice is pr ovided by UDP.
Tr anspor t l ayer pr ot ocol .
Can r un mul t ipl e appl icat ions using t he same t r anspor t .
Mul t ipl ex t hr ough por t number s
TCP is al so a t r anspor t -l ayer pr ot ocol . Unl ike t he UDP pr ot ocol , t he pur pose of t he
t r anspor t -l ayer sof t war e TCP is t o al l ow dat a t o be r el iabl y exchanged wit h anot her
st at ion on t he net wor k. It , t oo, pr ovides t he demul t ipl exes of por t number s t o ident if y
an appl icat ion in t he host , but al so pr ovides r el iabl e t r anspor t of dat a, incl uding many
dif f er ent opt ions t hat may or may not be sent by t he or iginat ing st at ion. A
communicat ions f acil it y needs t o be abl e t o r el iabl y t r ansf er dat a bet ween t wo point s.
Imagine set t ing up a communicat ions syst em t hat onl y al l owed f or unr el iabl e dat a
t r ansf er t he post of f ice t r ansf er s most of it s mail in t his manner . When you mail a
l et t er , you have no idea if it r eal l y r eached it s dest inat ion unl ess you make t he ef f or t
t o check. Shoul d make you a l it t l e ner vous on t hat cr it ical dat a. This is f ur t her
exempl if ied by a packet swit ch net wor k in which t he same communicat ion channel is
used by mul t ipl e ent it ies al l vying f or t he same pat h, and each header cont ains it s own
dir ect ional inf or mat ion.
TCP/IP host s or iginal l y wer e connect ed via t el ephone l ines (commonl y known as serial
l ines). This mode of communicat ion was not t he same in t he ear l y 1970s as it is t oday. The
l ines wer e noisy and wer e not condit ioned t o handl e high-speed dat a. Ther ef or e, t he
TCP pr ot ocol has st r ict er r or -det ect ion al gor it hms buil t in t o ensur e t he int egr it y of
t he dat a. The f ol l owing par agr aphs expl ain t he TCP pr ot ocol and show how it s
st r ict ness in it s st r uct ur e ensur es t he int egr it y of t he dat a.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 193
TCP Details
Not al l net wor ks use a separ at e t r anspor t -l ayer sof t war e t o conver se on a net wor k.
The best exampl e of t his is Novel l wit h it s LAN wor kgr oup oper at ing syst em of Net War e.
Net War e r el ies on t he net wor k-l ayer sof t war e t o t r anspor t dat a and t he Net War e
Cor e Pr ot ocol (as an appl icat ion) t o pr ovide t he sequence number ing of t he packet s.
Ther e is not hing wr ong wit h t his, and it gener al l y speeds up t he communicat ion pr ocess
bet ween t wo st at ions on t he net wor k. The over head of t he r ol e of t r anspor t l ayer is
diminished, but t hose t ypes of pr ot ocol s wer e devel oped on high-speed, l ow-er r or -r at e
media such as Et her net . TCP was not , and is much mor e r obust in it s t r anspor t -l ayer
pr ot ocol . TCP is act ual l y a pr ot ocol and not a separ at e piece of sof t war e.
The pr ot ocol of TCP uses sequence number s and acknowl edgment s t o r el iabl y conver se
wit h ot her st at ions on t he net wor k. Sequence number s ar e used t o det er mine t he
or der ing of t he dat a in t he packet s and t o f ind missing packet s. Since packet s on an
int er net may not ar r ive in t he same sequence in which t hey wer e sent (f or exampl e, a
singl e packet in a ser ies of packet s being t r ansmit t ed was discar ded by a r out er ),
sequencing t he dat a in t he packet s ensur es t hat t he packet s ar e r ead in t he same or der
in which t hey wer e sent . Al so, a r eceiving st at ion may r eceive t wo of t he same packet s.
The sequence number wit h acknowl edgment s is used t o al l ow a r el iabl e t ype of
communicat ion. This pr ocess is cal l ed full duplex, f or each side of a connect ion maint ains
it s own sequence number f or t he ot her side.
TCP is a byt e-or ient ed sequencing pr ot ocol . Ot her pr ot ocol s such as Novel l Net War e
ar e packet -or ient ed sequencing pr ot ocol s. This appl ies a sequence number t o each packet
t r ansmit t ed and not t o each dat a byt e in t he packet . Byt e or ient ed means t hat ever y
byt e in each packet is assigned a sequence number . This does not mean t hat TCP t r ansmit s
a packet cont aining onl y 1 byt e. TCP wil l t r ansmit dat a (many byt es) and assign t he
packet one sequence number . Assigning one sequence number per byt e in t he packet may
sound r epet it ious, but r emember t hat TCP/IP was f ir st impl ement ed over noisy ser ial
l ines and not r el iabl e high-speed LANs.
The sl ide shows t wo dat agr ams t hat have been t r ansmit t ed. Nor mal l y, each TCP
segment is 512 or 536 byt es in l engt h (but can be l ar ger ). The shor t number of byt es in
t his pict ur e is shown f or cl ar it y onl y. Each dat agr am is assigned one sequence number
accor ding t o t he number of byt es in t he TCP Dat a f iel d. Not ice how t he sequence
number jumps by t he same amount of byt es t hat ar e in each packet . The r eceiver of t hese
dat agr ams wil l count t he amount of byt es r eceived and incr ement it s sequence number
of r eceived packet s. The f ir st packet r eceived has a sequence number of 40 and cont ains 4
byt es. The r eceiver expect s t he next sequence number t o be 44. It is, and t hat packet
cont ains 7 byt es of dat a. The r eceiver expect s t he next packet t o be sequence number of
51. It is. This is how t he byt e sequencing of TCP wor ks.
The sl iding window scheme is discussed l at er . Fir st , t he TCP header def init ions.
TCP Det ail s

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 194
TCP Fields
The sl ide shows t he TCP header f iel ds as encapsul at ed in a IP dat agr am.
Sour ce por t . The por t number (appl icat ion) of t he or iginat ing st at ion.
Dest inat ion por t . The por t number (appl icat ion) f or t he r eceiving st at ion.
Sequence number . A number assigned t o a TCP dat agr am t o indicat e t he beginning
byt e number of a packet unl ess t he SYN bit is set . If t his bit is set , t he sequence
number is t he init ial sequence number (ISN) and t he f ir st dat a byt e is ISN + 1.
Acknowl edgment number . A Number sent by t he dest inat ion st at ion t o t he
sour ce st at ion, acknowl edging r eceipt of a pr eviousl y r eceived packet or packet s.
This number indicat es t he next sequence number t he dest inat ion st at ion expect s
t o r eceive. Once a connect ion is est abl ished, t his f iel d is al ways set .
Dat a of f set . Indicat es how l ong t he TCP header is (i.e., t he number of 32-bit
wor ds in t he TCP header ). It indicat es wher e t he TCP header ends and t he dat a
begins.
Reser ved. Reser ved f or f ut ur e use. Must be set t o 0.
TCP Fiel ds
Cont r ol bit s:
URG Ur gent point er : Used t o send a message t o t he
dest inat ion t hat ur gent dat a is wait ing t o be sent t o
it . This coul d be sent t o a dest inat ion st at ion, when
t he dest inat ion st at ion has cl osed t he Receive
window t o t he sender . However , t he r eceiver wil l
st il l accept packet s wit h t his bit set .
ACK If set , t his packet cont ains an acknowl edgment t o a
pr eviousl y sent dat agr am(s).
PSH Push f unct ion: Immediat el y sends dat a when r ead t he
segment .
RST Reset t he connect ion. One f unct ion f or t his is t o not
accept a connect ion r equest .
SYN Used at st ar t up and t o est abl ish sequence number .
FIN No mor e dat a is coming f r om t he sender of t he
connect ion.
Window. The number of dat a oct et s beginning wit h t he one indicat ed in t he
Acknowl edgment f iel d t hat t he sender of t his segment is wil l ing t o accept . It
indicat es t he avail abl e buf f er s (memor y) on t he r eceiver .
Checksum. An er r or -det ect ion number .
Ur gent point er . The ur gent point er point s t o t he sequence number of t he byt e
f ol l owing t he ur gent dat a. This f iel d is int er pr et ed onl y in segment s wit h t he
URG bit set .
Opt ions. Var iabl e in l engt h, it al l ows f or TCP opt ions t o be pr esent ed. These ar e:
End of Opt ion List , No Oper at ion, and Maximum Segment Size (MSS).

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 195
TCP Services
TCP Ser vices
Basic dat a t r ansf er
Rel iabil it y
Fl ow cont r ol
Mul t ipl exing
Connect ions
Pr ecedence and secur it y
As not ed ear l ier , t he pr imar y pur pose of TCP is t o pr ovide r el iabl e, secur abl e l ogical
cir cuit or connect ion ser vice bet ween pair s of pr ocesses. Pr oviding t his ser vice on t op of
a l ess-r el iabl e int er net communicat ions syst em r equir es f acil it ies in t he f ol l owing
ar eas, which ar e f ul l y descr ibed in t he next f ew sect ions:
Basic dat a t r ansf er
Rel iabil it y
Fl ow cont r ol
Mul t ipl exing
Connect ions
Pr ecedence and secur it y

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 196
TCP Connection Establishment
Unl ike it s br ot her UDP, TCP pr ovides f or r el iabl e connect ions. A TCP connect ion
bet ween t wo st at ions on a net wor k must be est abl ished bef or e any dat a is al l owed t o
pass bet ween t he t wo. Appl icat ions such as TELNET and FTP communicat e using TCP
t hr ough a ser ies of f unct ion cal l s. This may seem a l it t l e conf using now, but t he
f unct ions ar e ver y simpl e. These cal l s incl ude OPEN and CLOSE a connect ion, SEND and
RECEIVE (inf or mat ion) t o t hat connect ion, and STATUS t o r eceive inf or mat ion f or a
connect ion.
When a connect ion t o a r emot e st at ion is needed, an appl icat ion wil l r equest TCP t o
pl ace an OPEN cal l . Ther e ar e t wo t ypes of OPEN cal l : passive and active. A passive OPEN
is a cal l t o al l ow connect ions t o be accept ed f r om a r emot e st at ion. This usual l y occur s
when an appl icat ion st ar t s on a net wor k st at ion (such as TELNET, FTP), and it wil l
indicat e t o TCP t hat it is wil l ing t o accept connect ions f r om ot her st at ions on t he
net wor k. TCP wil l not e t he appl icat ion t hr ough it s por t assignment and wil l al l ow
connect ions t o come in. The number of connect ions al l owed depends on t he number of
passive OPENs issued. This passive end of t he TCP act ions is known as t he responder TCP. It
wil l open up connect ion sl ot s t o accept any incoming connect ion r equest . This may be
t hought of as t he ser ver end of TCP. These passive OPEN cal l s do not wait f or any
par t icul ar st at ion r equest .
An act ive OPEN is made when a connect ion at t empt t o a r emot e net wor k st at ion is
needed. Ref er r ing t o t he sl ide, st at ion A wishes t o connect t o st at ion B. St at ion A issues
an act ive OPEN cal l t o st at ion B. In or der f or t he connect ion t o be made, st at ion B must
al r eady have issued a passive OPEN r equest t o al l ow incoming connect ions t o be
est abl ished. In t he connect ion at t empt packet is t he por t number t hat st at ion A wishes
t o use on st at ion B. St at ion Bs oper at ing syst em wil l spawn a separ at e pr ocess on it s
syst em t o maint ain t hat connect ion. This pr ocess wil l act as if it is r unning l ocal l y on
t hat st at ion. TCP wil l t hen await anot her incoming connect ion r equest . This pr ocess is
simil ar t o t he way a mul t it asking oper at ing syst em handl es mul t ipl e appl icat ions.
TCP Connect ion Est abl ishment

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 197
The Three-Way Handshake
A connect ion wil l onl y be act ive af t er t he sender and r eceiver exchange a f ew cont r ol
packet s t o est abl ish t he connect ion. This is known as t he three-way handshake. It s pur pose
t o synchr onize each endpoint at t he st ar t of a TCP connect ion wit h a sequence number
and acknowl edgment number .
Ref er t o sl ide 215. St at ion A wil l pl ace an act ive OPEN cal l t o TCP t o r equest
connect ion t o a r emot e net wor k st at ions appl icat ion. St at ion A wil l buil d a TCP
header wit h t he SYN (t he sync bit shown was shown pr eviousl y in t he TCP Header
f iel ds) bit set and t hen assign an init ial sequence number (it does not al ways st ar t at 0
and can st ar t at any number ; I have chosen 100) and pl ace it in t he Sequence Number
f iel d. Ot her f iel ds wil l be set in t he TCP header (not per t inent t o us at t his t ime) and
t he packet wil l be given t o IP f or t r ansmission t o st at ion B.
St at ion B wil l r eceive t his packet and not ice it is a connect ion at t empt . If st at ion B can
accept a new connect ion it wil l acknowl edge st at ion A by buil ding a new packet .
St at ion B wil l set t he SYN and t he ACK bit s in t he TCP header shown in t he sl ide, pl ace
it s own init ial sequence number (200) in t he Sequence f iel d of t he packet , and t he
Acknowl edgment f iel d wil l be set t o 101 (t he st at ion A sequence number pl us 1,
indicat ing t he next expect ed sequence number ).
St at ion A wil l r eceive t his r esponse packet and not ice it is an acknowl edgment t o it s
connect ion r equest . St at ion A wil l buil d a new packet , set t he ACK bit , f il l in t he
sequence number t o 101, f il l in t he acknowl edgment number t o 200 + 1, and send t he
packet t o st at ion B. Once t his has been est abl ished, t he connect ion is act ive and dat a
and commands f r om t he appl icat ion (such as TELNET) may pass over t he connect ion. As
dat a and commands pass over t he connect ion, each side of t he connect ion wil l maint ain
it s own sequence number t abl es f or dat a being sent and r eceived acr oss t he connect ion.
They wil l al ways be in ascending or der .
Sequence number s do not have t o and pr obabl y wil l not st ar t at 0. However , it is
f undament al l y impor t ant t o not e t hat t hey wil l wr ap t o 0.
The Thr ee-Way Handshake

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 198
TCP Segment
Ever yt hing t hat TCP sends is cal l ed a segment. This inf or mat ional unit can be cont r ol
dat a or user dat a. Segment s ar e used t o est abl ish a connect ion, send and r eceive dat a
and acknowl edgment s, adver t ise window sizes, and cl ose a connect ion. A TCP segment
wil l cont ain t he TCP header (shown in Sl ide 216) and it s dat a. The dat a handed t o TCP
f or t r ansmission is known as a stream; mor e specif ical l y, an unstructured stream. A st r eam is
a f l ow of byt es of dat a and an unst r uct ur ed st r eam is an unknown t ype of dat a f l ow of
byt es. This means t hat TCP has no way of mar king t he dat a t o indicat e t he ending of a
r ecor d or t he t ype of dat a t hat is in t he st r eam. When TCP r eceives a dat ast r eam f r om
t he appl icat ion, it wil l divide t he dat a int o segment s f or t r ansmission t o t he r emot e
net wor k st at ion. A segment can have cont r ol or dat a inf or mat ionit is simpl y an
unst r uct ur ed st r eam of dat a byt es sent t o a dest inat ion.
A TCP segment may be as l ong as 65,535 byt es (or l onger , known as jumbogr ams in IPv6),
but is usual l y much l ess t han t hat . Et her net can onl y handl e 1500 byt es of dat a in t he
Dat a f iel d of t he Et her net packet (Et her net v2.0, 1496 byt es f or IEEE 802.3 using IEEE
802.2). FDDI can handl e a maximum of 4472 byt es of dat a in a packet , and Token Ring
packet size var ies depending on t he speed. For 4 Mbps, t he maximum size is 4472 byt es. For
16 Mbps, t he maximum size of t he packet is 17,800 byt es, but is usual l y set t o 4472 byt es.
To negot iat e a segment size, TCP uses one of t he Opt ions (MSS) f iel ds l ocat ed in t he TCP
header t o indicat e t he l ar gest segment size it can r eceive, and submit s t his packet t o t he
r emot e net wor k st at ion.
TCP Segment
TCP does not car e what t he dat a is; dat a in a TCP segment is consider ed a st r eam. This
st r eam is const r uct ed at t he sender and sent t o t he r eceiver . The r eceiver r econst r uct s
t his st r eam f r om t he var iabl e segment s t hat it r eceives. Once t he connect ion is
est abl ished, TCPs main job is t o maint ain t he connect ion(s). This is accompl ished t hr ough
t he sequence number s, acknowl edgment s and r et r ansmissions, f l ow cont r ol , and window
management .
Since t he connect ion bet ween st at ions A and B is now est abl ished (by way of a
successf ul t hr ee-way handshake), TCP must now manage t he connect ion. The f ir st of
t he management t echniques t o be discussed is sequence numbers.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 199
Sequence Numbers and Acknowledgments
A point shoul d be made r ight up f r ont . Acknowl edgment s do not simpl y r ef er t o a
dat agr am or a TCP segment . TCPs job is t o r econst r uct a piece of dat a t hat was
t r ansmit t ed by t he sender . Ther ef or e, t he acknowl edgment number act ual l y r ef er s t o
t he posit ion in t he st r eam of dat a being sent . Why? Because IP is connect ionl ess and
r et r ansmissions may cont ain a dif f er ent size f r om t he or iginal . The r eceiver col l ect s
inf or mat ion and r econst r uct s an exact copy of t he dat a being sent .
Segment s may al so ar r ive out of or der , and it is TCPs job t o pl ace t hem back in t he
or der in which t hey wer e sent . However , er r or s may occur dur ing t his pr ocess and TCP
wil l onl y ACK t he l ongest cont iguous pr ef ix of t he st r eam t hat has been r eceived
cor r ect l y.
Ref er back t o Sl ide 211. TCP cal cul at es a sequence number f or each byt e of dat a in t he
segment t aken as a sum. For each byt e of dat a t hat is t o be t r ansmit t ed, t he sequence
number incr ement s by 1. Let s say a connect ion was made bet ween st at ions A and B
(r ef er t o Sl ide 217). St at ion A sends a segment t o st at ion B wit h a sequence number of 40
and knows t he segment cont ains 4 byt es; t her ef or e, it incr ement s it s sequence number t o
44. Upon acknowl edgment f r om st at ion B (cont aining t he ACK number of 44), st at ion A
t hen t r ansmit s t he second segment t o st at ion B, which cont ains 7 byt es. St at ion As
sequence number incr ement s t o 51, and it wait s f or an acknowl edgment f r om st at ion B.
Not e her e t hat st at ion A may not necessar il y wait f or an ACK f r om st at ion B.
Sequence Number s and Acknowl edgment s
Sequence number s ar e used t o r eassembl e dat a in t he or der in which it was
sent .
Sequence number s incr ement based on t he number of byt es in t he TCP dat a
f iel d.
Known as a Byt e Sequencing Pr ot ocol
Each segment t r ansmit t ed must be acknowl edged.
Mul t ipl e segment s can be acknowl edged
The ACK (Acknowl edgement ) f iel d indicat es t he next byt e (sequence) number
t he r eceiver expect s t o r eceive.
The sender , no mat t er how many t r anmit t ed segment s, expect s t o r eceive an
ACK t hat is one mor e t han t he number of t he l ast t r ansmit t ed byt e.
Each t r ansmission window wil l cont ain as many byt es as indicat ed by t he dest inat ion
(windows ar e discussed in a moment ). The sequence number is set t o t he number of t he
f ir st byt e in t he dat agr am being sent t he l ast r eceived ACK number f r om t he
dest inat ion. The TCP segment (t he dat a) is t hen given t o IP f or del iver y t o t he net wor k.
Mul t ipl e dat agr ams may be sent wit h one acknowl edgment t o al l r eceived good
segment s. This is cal l ed an inclusive or cumulative ACK. TCP accompl ishes t his
bidir ect ional l y acr oss t he same connect ion. Each dat agr am t r ansmit t ed wil l have t he
TCP header ACK bit set . Wit h t he ACK bit set , TCP wil l r ead t he Acknowl edgment f iel d
t o f ind t he next byt e number of t he segment t hat t he ot her end of t he connect ion
expect s. In ot her wor ds, t he number in t he ACK f iel d equal s t he sequence number of t he
or iginal segment t r ansmit t ed pl us t he number of t he byt es successf ul l y r eceived in t hat
segment pl us 1. The ACK number is st uf f ed int o a dat agr am t o make TCP mor e ef f icient .
Ther e is usual l y not a separ at e dat agr am on t he net wor k used just f or ACK packet s.
Al l dat a byt es up t o but not incl uding t he ACK number ar e consider ed good and
accept ed by t he r eceiver .
Since TCP is a byt e-or ient ed t r anspor t pr ot ocol , sequencing and acknowl edgment s ar e
accompl ished f or each byt e of TCP dat a t o ensur e t he int egr it y of t he dat a and
successf ul del iver y t o t he dest inat ion. LAN pr ot ocol s such as Novel l Net War e and
Xer ox XNS wer e devel oped t o wor k on high-r el iabil it y mediums (shiel ded copper cabl e in
cont r ol l ed envir onment s). Their sequence number s ar e based not on byt es in t heir dat a
segment but on t he number of packet s. TCP ACKs TCP byt es of dat a not packet s,
dat agr ams, or segment s.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 200
Sequence and Acknowledgment Example
As shown in t he sl ide, t he connect ion was est abl ished using an init ial sequence number
f r om t he sender and an init ial sequence number suppl ied by t he r eceiver (t he
dest inat ion). Each side wil l maint ain it s own sequence number , which may be in t he
r ange of 0 t o 2,147,483,647. Each side of a TCP connect ion knows t he upper and l ower
l imit s of t he sequence number s, and once t he l imit has been r eached, it wil l r ol l over t o
0 (each side knows t o incl ude 0). The init ial izat ion sequence number s ar e sel ect ed at
r andom. Each side must ACK each ot her s r eceived dat agr ams.
ACK No. = sequence number + good byt es r ead in t he segment + 1
This is a cl ean, f ast , ef f icient way of det er mining which byt es wer e successf ul l y
r eceived and which wer e not . The sender must r et ain a copy of t r ansmit t ed dat a unt il it
r eceives an acknowl edgment f or t hose byt es f r om t he r emot e net wor k st at ion of a
connect ion.
Acknowl edgment packet s ar e not necessar il y separ at e packet s wit h onl y t he
acknowl edgment number in t he packet . This woul d be inef f icient . For exampl e, if st at ion
A opens a connect ion t o st at ion B, and st at ion A and st at ion B ar e sending dat a t o each
ot her , t he ACK dat agr am can be combined wit h t he r esponse dat a packet . In ot her
wor ds, one dat agr am t r ansmit t ed cont ains t hr ee t hings: t he dat a f r om st at ion B t o
st at ion A, t he acknowl edgment f r om st at ion B of t he dat a pr eviousl y sent f r om st at ion
A, and t he sequence number f or t he dat a B is sending t o A.
Sequence and Acknowl edgment Exampl e
If t he sender does not r eceive an acknowl edgment wit hin a specif ied t ime, it wil l r esend
t he dat a st ar t ing f r om t he f ir st unacknowl edged byt e. TCP wil l t ime-out af t er a
number of unsuccessf ul r et r ansmissions. The r et r ansmission of a dat agr am is
accompl ished using t he Go-back-t o-N r out ine. Any number of out st anding byt es may not
be acknowl edged. When t he dest inat ion st at ion does acknowl edge t he r eceipt of a
ser ies of byt es, t he sour ce wil l l ook at t he ACK number . Al l sequence number s up t o but
not incl uding t he ACK number ar e consider ed r eceived in good condit ion. This means
t hat a sour ce st at ion can st ar t t he sequence number wit h 3 and t hen send t wo
dat agr ams cont aining 100 TCP segment byt es each. When it r eceives an ACK f r om t he
dest inat ion of 203 (3 t o 102, and t hen 102 t o 202, l eaving t he ACK at 203 as t he next
expect ed byt e), it wil l know t hat t he dat a in bot h dat agr ams pr eviousl y sent ar e
consider ed r eceived in good condit ion.
The number of out st anding packet s al l owed is t he next t opic of discussion.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 201
TCP Flow and Window Management
Two f unct ions ar e r equir ed of TCP in or der f or t he pr ot ocol t o manage t he dat a over a
connect ion: flow control and transmission control. Do not conf use t hese f unct ions wit h t he
ICMP sour ce quench mechanism. Sour ce quench is f or a host t o inf or m t he sour ce of
t r ansmissions t hat t he host is f ul l and t he host woul d l ike t he sender t o sl ow it s r at e
of t r ansmission.
For t hose r eader s who do not under st and f l ow cont r ol , it is a mechanism used t o
cont r ol t he f l ow of dat a. For exampl e, if dat a is being r eceived at a dest inat ion st at ion
f ast er t han t hat st at ion can accept it , it needs t o t el l t he sour ce st at ion t o sl ow down
or t o st op compl et el y unt il it can cl ear out some space (r epl enish buf f er s).
How many segment s may be out st anding at any one t ime? Dat a management using a
window is accompl ished as shown in t he f ol l owing sl ide. Dat a f or TCP t o t r ansmit t o
t he r emot e net wor k st at ion wil l be accept ed by TCP f r om an appl icat ion. This dat a wil l
be pl aced sequent ial l y in memor y wher e it wil l wait t o be sent acr oss a connect ion t o a
r emot e st at ion (f or IP t o send t he packet ). TCP pl aces a window over t his dat a in
which t o st r uct ur e t he dat a: dat a sent and acknowl edged, dat a sent but not
acknowl edged, and dat a wait ing t o be sent . This is cal l ed a sliding window, f or t he
window wil l sl ide up t he dat a segment as each dat a packet is sent and acknowl edged.
Ref er t o sl ide 219. Sequence number s 100104 have been t r ansmit t ed t o t he dest inat ion
st at ion and t he dest inat ion st at ion has acknowl edged r eceipt of t hese segment s.
Packet s cont aining sequence number s 105108 have been t r ansmit t ed by t he sour ce
st at ion, but it has not r eceived an acknowl edgment . Segment s cont aining sequence
number s 109114 ar e st il l in t he sour ce st at ion and ar e wait ing t o be sent . Packet s
cont aining 115118 ar e not yet in t he window.
The impor t ant t hing t o not ice is t he bl ack box cover ing t he segment s. This is t he
window. It wil l const ant l y move in ascending sequence or der upon r eceipt of
acknowl edgment s f r om t he dest inat ion st at ion.
This window size is var iabl e t hr ough t he use of t he Window Size f iel d in t he TCP header
of an acknowl edgment . When t he r eceiving st at ion (t he dest inat ion st at ion) is r unning
l ow on buf f er space (an ar ea of memor y in which t o st or e incoming dat a), it can inf or m
t he sender t o sl ow it s t r ansmission r at e t o t he amount of dat a it can accept . This is
accompl ished t hr ough t he Window f iel d in t he TCP header packet . This f iel d wil l
cont ain t he number of byt es (by indicat ing t he r ange of sequence number s) t hat t he
dest inat ion st at ion is wil l ing t o accept . Sl ide 212 shows t he TCP header , specif ical l y,
t he Window f iel d in t he TCP header .
When t he r emot e net wor k st at ion cannot accept any mor e dat a, it may set t his Window
f iel d t o a 0. It wil l cont inue t o submit t hese 0 packet s unt il it can again accept dat a
(t hat is, t he sender can send dat a t o a host , and t his host shoul d r espond wit h t he ACK
set t o t he pr evious ACK sent and a window set t o 0). When buf f er space is f r eed up, it
can again submit a packet wit h t he window size set t o a number ot her t han 0 t o indicat e
it can again accept dat a. However , if t he ur gent bit is set , t his indicat es t o t he r eceiver
t hat t he sender has ur gent dat a wait ing t o send.
TCP Fl ow and Window Management
This connect ion management t echnique al l ows TCP t o maint ain cont r ol of t he dat a
t r ansf er by inf or ming TCP on t he sending side how much dat a t he r eceiver is wil l ing t o
accept . This enabl es bot h a sender and r eceiver of dat a t o maint ain consist ent dat a
f l ow over t he connect ion.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 202
TCP Retransmission
One l ast f unct ion t o discuss is TCPs capabil it y t o know when t o send a r et r ansmission
of a packet . This is a f air l y compl ex subject t hat wil l onl y be br ief l y discussed her e.
Since dat a r uns on an Int er net t hat has var ying del ays caused by r out er s and l ow- or
high-speed net wor ks, it is near l y impossibl e t o det er mine an exact t imer del ay f or an
acknowl edgment . The acknowl edgment coul d show up one t ime in a mat t er of
mil l iseconds, or it coul d show up in a mat t er of seconds. The t ime is var iabl e is due t o
t he het er ogeneous nat ur e of t he Int er net . TCP accommodat es t his var ying del ay by
using an adapt ive r et r ansmission al gor it hm. This al l ot t ed t ime is dynamic (not hel d t o
one number ) and is accompl ished as f ol l ows: When TCP submit s a packet t o be sent , TCP
r ecor ds t he t ime of t he t r ansmission and t he sequence number of t he segment . When TCP
r eceives an acknowl edgment t o t hat segment , it wil l again r ecor d t he t ime. Using t his
del t a, TCP buil ds a sampl e r ound-t r ip del ay t ime. TCP uses t his t ime t o buil d an aver age
t ime f or a packet t o be sent and an acknowl edgment t o be r eceived. When it cal cul at es
a new val ue f r om anot her sampl e, it wil l sl owl y change it s t imer del ay f or t he wait ing
of t he ACK packet .
TCP Ret r ansmission
TCP wil l r et r ansmit a segment upon expir at ion of an adapt ive t r ansmission
t imer .
The t imer is var iabl e.
When TCP t r ansmit s a segment , it r ecor ds t he t ime of t r ansmission and t he
sequence number of t he segment .
When TCP r eceives an acknowl edgment , it r ecor ds t he t ime.
This al l ows TCP t o buil d a sampl e r ound-t r ip del ay t ime.
TCP wil l buil d an aver age del ay t ime f or a packet t o be sent and r eceived.
The t imer is sl owl y changed t o al l ow f or t he var ying dif f er ences in t he
Int er net .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 203
Slow Start and Congestion Avoidance
Ot her f eat ur es of TCP ar e t he slow start and congestion avoidance mechanisms. Or iginal
ver sions of TCP woul d st ar t a connect ion wit h t he sender t r ansmit t ing mul t ipl e
segment s int o t he net wor k, up t o t he window size adver t ised by t he r eceiver (set up
dur ing t he t hr ee-way handshake). Local subnet s wer e not af f ect ed as much as
communicat ion bet ween subnet s. If t her e ar e r out er s and sl ower l inks bet ween t he
sender and t he r eceiver , pr obl ems can ar ise. A huge amount of dat a coul d possibl y be
sent at st ar t up. The met hod t o avoid t his is cal l ed t he slow start. When congest ion
occur s, TCP must sl ow it s t r ansmission r at e of packet s int o t he net wor k, and t hen
invoke sl ow st ar t and/or congest ion cont r ol t o get t hings going again. In pr act ice, t hey
ar e impl ement ed t oget her .
Sl ow st ar t oper at es by obser ving t hat t he r at e at which new packet s shoul d be
t r ansmit t ed on t he net wor k is t he r at e at which t he acknowl edgment s ar e r et ur ned.
Sl ow st ar t adds anot her window t o t he sender s TCP: t he Congestion window. This is not
adver t ised in t he TCP header ; it is assumed. When a new connect ion is est abl ished wit h a
l ocal or r emot e host , t he congest ion window is init ial ized t o one segment . Segment sizes
ar e var iabl e depending on t he comput er or LAN t ype used, but t he def aul t , t ypical l y
536 (yes, 536 f or it t he segment size [TCP l ayer ] t hat we ar e wor king wit h) or 512, coul d
be used. Each t ime an ACK is r eceived, t he Congest ion window is incr eased by one
segment . The sender can t r ansmit up t o t he minimum of t he Congest ion window and t he
adver t ised window. The dist inct ion her e is t hat t he congest ion window is f l ow cont r ol
imposed by the sender, whil e t he Adver t ised window is f l ow cont r ol imposed by the receiver.
Sl ow St ar t and Congest ion Avoidance
Bef or e t his, TCP woul d st ar t t o t r ansmit as much dat a as was al l owed in t he
adver t ised window.
A new window was added cal l ed t he congest ion window.
It is not negot iat ed, it is assumed. It st ar t s out wit h one segment
Segment size is var iabl e, but usual l y set t o 512 or 536 byt es
Mul t ipl y t his by t he mil l ions of host s t hat ar e conver sing on t he Int er net
and you can see t hat immediat e congest ion f ol l ows.
Sl ow st ar t init ial izes a congest ion window of 1 segment .
Each subsequent ACK incr ement s t his window expot ent ial l y (1, 2, 4, 8,
et c.) event ual l y t o t he adver t ised window size
As l ong as t her e ar e no t ime-out s or dupl icat e ACKs dur ing t he t r ansmission
bet ween t wo st at ions, it st ays at t he adver t ised window size.
The sender st ar t s by t r ansmit t ing one segment and wait ing f or it s ACK. When t hat ACK
is r eceived, t he Congest ion window is incr ement ed f r om 1 t o 2, and 2 segment s can be
sent . When each of t hose 2 segment s is acknowl edged, t he Congest ion window is
incr eased t o 4. This r at e cont inues t o incr ease exponent ial l y unt il t he TCP Adver t ised
window size is met . Once t he Congest ion window size equal s t he Adver t ised window size,
segment s ar e cont inual l y t r ansf er r ed bet ween st at ions using t he window size f or
congest ion cont r ol on t he wor kst at ions (just as if sl ow st ar t had never been invoked).
However , upon congest ion (as indicat ed by dupl icat e ACKs or t ime-out s), t he al gor it hm
kicks back in but st ar t s up anot her al gor it hm as wel l (known as congestion control). When
congest ion occur s, a compar ison is made bet ween t he congest ion window size and t he
TCP adver t ised window size. Whichever is smal l er , t his number is t hen hal ved and saved
in a var iabl e known as t he slow-start threshold. This val ue must be at l east 2 segment s
unl ess t he congest ion was a t ime-out and t hen t he congest ion window is set t o 1 (sl ow
st ar t ). The TCP sender t hen can eit her st ar t up sl ow st ar t or congest ion avoidance.
Once ACKs ar e r eceived, t he congest ion window is incr eased. Once t he congest ion
window mat ches t he val ue saved in t he sl ow-st ar t t hr eshol d, t he sl ow-st ar t al gor it hm
st ops and t he congest ion avoidance al gor it hm st ar t s. This al gor it hm al l ows f or mor e
cont r ol l ed (l inear , not exponent ial l ike t he sl ow-st ar t al gor it hm) gr owt h in
t r ansmission in t hat it mul t ipl es t he segment size by 2, divides t his val ue by t he
congest ion window size, and t hen cont inual l y incr eases t he r at e based on t his
al gor it hm each t ime an ACK is r eceived. This al l ows f or gr owt h on t he TCP connect ion
but at a mor e cont r ol l ed r at e
The ef f ect s of t hese al gor it hms wer e dr amat ic on t he Int er net . Al l ver sions of TCP/IP
sof t war e now incl ude t hese al gor it hms and t heir ef f ect s ar e not onl y based on r emot e
connect ions. These al gor it hms ar e pl aced int o act ion bet ween t wo st at ions on a l ocal
subnet as wel l .
Sl ow St ar t and Congest ion Avoidance (cont inued)
Upon congest ion (dupl icat e ACKs or t ime-out ), t he al gor it hm kicks back in.
A compar ison is made bet ween t he congest ion window size and t he
adver t ised window size
Whichever is smal l er , is hal ved and saved as t he sl ow-st ar t t hr eshol d
The val ue must be at l east 2 segment s unl ess t he congest ion was a t ime-
out , and t hen t he congest ion window is set t o 1 (sl ow st ar t )
The TCP sender can st ar t up in sl ow st ar t or congest ion avoidance
If t he congest ion val ue mat ches (or is gr eat er t han) t he val ue of sl ow-st ar t
t hr eshol d, t he congest ion avoidance al gor it hm st ar t s; ot her wise, sl ow st ar t is
br ought up.
Upon r eceipt of ACKs, t he congest ion window is incr eased.
Al l ows f or a mor e l inear gr owt h in t r ansmission r at e.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 204
Termination
Final l y, TCP must be abl e t o gr acef ul l y t er minat e a connect ion. This is accompl ished
using t he FIN bit in t he TCP header . Since TCP of f er s a f ul l -dupl ex connect ion, each
side of t he connect ion must cl ose t he connect ion. Ref er t o sl ide 225 f or t wo
communicat ing devices, endst at ion A and host st at ion B. The appl icat ion r unning on
endst at ion A indicat es t o host B t hat it wishes t o cl ose a connect ion by sending a packet
t o host st at ion B wit h t he FIN bit set . Host st at ion B acknowl edges t hat packet and no
l onger accept s dat a f r om endst at ion A. However , host st at ion B does accept dat a f r om
it s appl icat ion t o send t o endst at ion A. Endst at ion A cont inues t o accept dat a f r om host
st at ion B. This way, st at ion A can, at a minimum, accept a FIN packet f r om host st at ion B
t o compl et el y cl ose t he connect ion. To f inal ize t he cl osing of t his connect ion, host
st at ion B sends a packet t o endst at ion A wit h t he FIN bit set . Endst at ion A ACKs t his
packet and t he connect ion is cl osed. If no ACK is r eceived, FINs ar e r et r ansmit t ed and
wil l event ual l y t ime-out if t her e is no r esponse.
Ter minat ion

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 205
Real-Time Protocol and the Real-Time Control
Protocol
Mul t imedia over t he Int er net . It used t o be t hat dat a was simpl y moved over t he
Int er net in or der f or peopl e t o communicat e wit h one anot her . Moving dat a such as a
f il e or an email is r el at ivel y simpl e and ver y f or giving. Ot her appl icat ions, such as
viewing a video cl ip as it is being downl oaded t o your net wor k st at ion, r equir e special
at t ent ion. This t ype of dat a movement is not ver y f or giving. Dr opped packet s cause
f aded pict ur es and jer ky or int er mit t ent audio.
Some exampl es of mul t imedia ar e t he t r ansmission of cor por at e messages t o empl oyees,
video- and audio-conf er encing f or r emot e meet ings and t el ecommut ing, l ive t r ansmission
of mul t imedia t r aining, communicat ion of st ock quot es t o br oker s, updat es on t he l at est
el ect ion r esul t s, col l abor at ive comput ing wit h t imes such as el ect r onic whit eboar ding,
t r ansmission over net wor ks of l ive TV or r adio news and ent er t ainment pr ogr ams, and
many ot her s. Al l of t his is gener al l y gr ouped int o one cat egor y known as multimedia.
Dat a t r ansf er , whet her it is t ext or voice and video can be cl assif ied as r eal -t ime and
nonr eal -t ime. Mul t imedia can be bot h r eal -t ime and non-r eal t ime dat a. Real t ime is t he
abil it y t o see and hear dat a as it is happening. For exampl e, viewing a video cl ip as it is
being downl oaded t o your net wor k st at ion is cl assif ied as r eal t ime. A camer a t hat is
capt ur ing a speech and, in conjunct ion wit h IP video ser ver s, is dist r ibut ing t he capt ur ed
dat a t o t housands of deskt ops f or immediat e viewing is anot her exampl e. Voice and video
r equir e special consider at ions. Let me be mor e specif ic: Real -t ime appl icat ions have
specif ic r equir ement s, as you wil l see in a moment .
Real -Time Pr ot ocol and t he Real -Time Cont r ol Pr ot ocol
Mul t imedia dat a is becoming commonpl ace on t he Int er net .
A communicat ion pl at f or m is needed t o suppor t t his new t ype of dat a.
Cl assif ied as r eal - and nonr eal -t ime.
Real t ime is t he abil it y t o use t he inf or mat ion as it is being t r ansf er r ed
(e.g., el ect r onic whit eboar ds, videoconf er encing, et c.)
Nonr eal -t ime is known as st or e-and-f or war d, which means t he ent ir e
dat a f il e is t r ansf er r ed t o be used at a l at er t ime
Exampl es ar e CBT, video pl ayback, et c.
RTP pr ovides end-t o-end del iver y ser vice f or r eal -t ime appl icat ions.
The RFC consist s of RTP and it s cont r ol pr ot ocol RTCP
Ser vices ar e pr ovided t hr ough payl oad t ype ident if icat ion, sequence
number ing, t imest amping, and del iver y monit or ing.
Nonr eal -t ime is t he abil it y t o t r ansf er dat a and view it at a l at er dat e. Rel at ivel y
speaking, t ime is not a consider at ion. You can downl oad a mul t imedia f il e and view it at
your l eisur e. Anot her nonr eal -t ime exampl e is Web br owser s. It make t ake a f ew seconds
or minut es t o view t he Web page, but once al l t he dat a is r eceived, t he Web page is
accur at e, not f uzzy or incompl et e.
RTP pr ovides end-t o-end dat a del iver y f or r eal -t ime (t ime-sensit ive) appl icat ions such as
t hose r equir ed by t r anspor t ing voice and video. It accompl ishes t his t hr ough payl oad
t ype ident if icat ion, sequence number ing, t imest amping, and del iver y monit or ing. It does
not pr ovide any qual it y-of -ser vice guar ant ees.
Real -t ime dat a r equir es special t r eat ment , and pr ot ocol s have been devel oped t o
handl e it . An ear l y at t empt t o move r eal -t ime dat a acr oss IP net wor ks was adopt ed as
St r eams 2 (ST2) pr ot ocol (RFC 1819). It was known as IP ver sion 5 and was t he IP
r epl acement f or st r eaming dat a. IPv4 handl ed del iver y of nonr eal -t ime dat a and ST2
was t he IP pr ot ocol t o handl e r eal -t ime st r eaming. It incl uded t he abil it y t o do
mul t icast , t r anspor t , and qual it y of ser vice in one pr ot ocol . However , t he abil it y of ST2
t o scal e was l imit ed due t o it s r equir ement of st at ic (manual ) binding t o end node
addr esses. Besides, t he user communit y want ed t he abil it y t o do bot h bur st y dat a and
st r eaming dat a over a common IP l ayer . Ther ef or e, t he IETF wor king gr oups came out
wit h mul t ipl e pr ot ocol s: RSVP, mul t icast suppor t , and a new st r eaming pr ot ocol known
as t he Real -Time Tr anspor t Pr ot ocol , or RTP.
RTP r esides at t he same l ayer as TCP. RTP is mor e an ar chit ect ur e t han a pr ot ocol and,
as st at ed in t he RFC, [RTP] is a pr ot ocol f r amewor k t hat is del iber at el y not compl et e.
The RFC incl udes descr ipt ions of t hose f unct ions t hat shoul d be common acr oss
appl icat ions t hat devel op t owar d RTP. It pr ovides a f r amewor k f or a pr ot ocol in t hat it
def ines t he r ol es, oper at ions, and message f or mat s. Appl icat ions wr it t en t owar d RTP
usual l y incor por at e t he f unct ions of RTP, t her eby adding t o t he RTP.
RTP f ol l ows t he ar chit ect ur e known as application layer framing, which al l ows f or a mor e
cooper at ive r el at ionship bet ween pr ot ocol l ayer s t han a st r ict adher ence t o t hem. RTP
is consider ed t o be adapt abl e and is of t en impl ement ed in t he appl icat ion r at her t han a
separ at e pr ot ocol , such as TCP. RTP r epl aces t he TCP l ayer f or appl icat ions and in most
cases, RTP wor ks wit h t he UDP l ayer f or socket addr esses (mul t ipl exing) and checksum
capabil it y. RTP wor ks in conjunct ion wit h a cont r ol pr ot ocol known as t he Real -Time
Cont r ol Pr ot ocol (RTCP). Por t number 5004 has been r egist er ed f or RTP and 5005 f or
RTCP. The sour ce and dest inat ion por t ar e t he same f or t he sender and t he r eceiver f or
RTP.
Fr om t he pr eceding t ext , your mind has pr obabl y wander ed and now you ar e t hinking
about mul t imedia and mul t icast . This is t he r ight way of t hinking in t hat audio and
video ar e gener al l y used in gr oup r eceiver s. RTP is designed f or mul t icast oper at ion.
This is obvious in one sender t o many r eceiver s but al so f or t he cont r ol pr ot ocol t hat is
used f or f eedback of cont r ol inf or mat ion.
Feedback is not simpl y del iver ed t o t he sender . If f eedback is t r ansmit t ed in mul t icast ,
al l par t icipant s in t he mul t icast r eceive t his inf or mat ion. Feedback is sent by a r eceiver
of t he mul t icast but t he f eedback inf or mat ion is sent wit h an IP mul t icast dest inat ion.
This has many advant ages. It al l ows al l t hose invol ved in t he mul t icast gr oup t o
r eceive t he f eedback inf or mat ion and pr ocess it . This al so al l ows any r eceiver s who ar e
exper iencing dif f icul t ies t o det er mine if t he pr obl em is unique t o t hem or mor e
widespr ead.
Real -Time Pr ot ocol (cont inued)
An ear l y pr ot ocol t ied t o r eal -t ime dat a was cal l ed St r eams 2 (RFC 1819).
It combined t he abil it y t o do mul t icast , t r anspor t , and QoS int o one
l ayer -3 pr ot ocol
Good st ar t but not used much
Pr ot ocol s of St r eams 2 wer e devel oped separ at el y and ar e now out as RTP,
RTCP, RSVP.
Al l can be used over t he exist ing IPv4 inf r ast r uct ur e
RTP r esides at t he same l ayer as TCP (RTP wit h IPv4 uses UDP).
RTP is mor e of a st r uct ur e or f r amewor k t han it is a pr ot ocol .
Del iber at el y l ef t incompl et e
Fol l ows an ar chit ect ur e cal l ed appl icat ion l ayer f r aming.
Designed wit h mul t icast in mind.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 206
Translators
The RTP pr ot ocol is open, which al l ows f or many dif f er ent encoding schemes t o be used.
This pr ovides many advant ages. Some pr ot ocol schemes ar e bet t er used in dif f er ent
t opol ogies t han ot her s. Mixer s and t r ansl at or s ar e used t o compensat e f or dif f er ences
in encoding schemes, and t r ansmission and r ecept ion r at es. Tr ansl at or s and mixer s r eside
in t he middl e of a mul t imedia net wor k, and ar e net wor k at t achment s l ike any ot her
at t achment . Their appl icat ion makes t hem r eside l ogical l y bet ween sender s and
r ecipient s and t hey pr ocess t he RTP inf or mat ion as t hey r eceive it and t hen r et r ansmit
t he inf or mat ion. The t r ansl at or f unct ions ar e t he easiest t o expl ain, so we wil l st ar t
t her e.
As shown in t he sl ide, a t r ansl at or simpl y t r ansl at es f r om one payl oad f or mat t o
anot her . Take t he exampl e of a net wor k st at ion t hat woul d l ike t o par t icipat e in a
st r eam but is l ocat ed beyond a WAN l ink t hat pr ovides ver y l it t l e bandwidt h. The high-
speed wor kst at ions coul d simpl y r educe t heir capabil it ies t o pr ovide f or t he l ow-
bandwidt h l ink, but wit h t he t r ansl at or t hey do not have t o. The t r ansl at or can simpl y
r eceive t he high-bandwidt h signal and t r ansl at e it t o a l ow-bandwidt h signal f or t he
r emot e net wor k st at ion. In t his way, r eceiver s of high-qual it y l inks can cont inue using
t hem, whil e r eceiver s of l ow-bandwidt h l inks par t icipat e as wel l .
Tr ansl at or s

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 207
Mixers
Mixer s per f or m a vit al ser vice. Mixer s do not int ake a sour ce st r eam and t r ansl at e it t o
anot her t ype of st r eam. Mixer s combine mul t ipl e sour ce st r eams int o one singl e st r eam
and pr eser ve t he or iginal f or mat . For exampl e, if you wer e having a audio conf er ence
bet ween f our net wor k st at ions, and anot her net wor k st at ion over a l ow-speed l ink
woul d l ike t o join, t he mixer woul d simpl y pul l t he t hr ee net wor k st at ions int o one
singl e st r eam inst ead of t hr ee f or communicat ion t o t he net wor k st at ion over t he l ow-
speed l ink. As shown in t he sl ide, a digit al audio conver sat ion is being car r ied on
bet ween f our wor kst at ions, each consuming 64 kbps f or t heir own per sonal use. When
t he f if t h net wor k st at ion want s t o join t he conver sat ion, but it s l ink is onl y 64 kbps,
t he mixer combines al l f our higher -speed audio signal s int o one 64 kbps st r eam. This
al l ows t he net wor k st at ion over t he l ow-speed l ink t o join t he conver sat ion and t he
ot her net wor k st at ions maint ain t heir high-speed and pr obabl y high-qual it y audio
l inks.
Basical l y, mixer s and t r ansl at or s al l ow f or var iances t o occur in an mul t imedia st r eam.
Whet her it is t r ansl at ing st r eams f r om one f or mat t o anot her , or al l owing f or t he
mixing of signal s t o accommodat e f or dif f er ences, t hese t wo t ypes of devices ar e ver y
much a par t of t he RTP pr ot ocol .
Mixer s

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 208
RTP Message Format
Ver s indicat es t he ver sion, which as of t his wr it ing is 2 (ver sion 1 was t he dr af t spec and
0 was used f or t he publ ic domain Visual Audio Tool [VAT]). The P bit indicat es t hat
padding is used at t he end of t he dat agr am and t he l ast byt e indicat es how many byt es
of padding. The X bit is t he ext ension bit , which indicat es t hat t he RTP f ixed header is
f ol l owed by an ext ension header . This has l imit ed use, but it does al l ow f or
ext ensibil it y. An ext ension mechanism is pr ovided t o al l ow individual impl ement at ions
t o exper iment wit h new payl oad-f or mat -independent f unct ions t hat r equir e addit ional
inf or mat ion t o be car r ied in t he RTP dat a packet header . The sequence number is 16 bit s
l ong and incr ement s by 1 f or each message sent . The st ar t number is l ike TCP and can be
st ar t ed anywher e wit hin a 16-bit r ange. The t imest amp indicat es a number r ef l ect ive of
t he t ime of t he t r ansmission of t he f ir st byt e in t he RTP dat a packet and incr ement s
sequent ial l y. Timest amps ar e used t o exact t he t iming as it was sent f r om t he sour ce.
Sever al messages may have t he same t imest amp, which coul d indicat e t hey wer e sent at
t he same t ime and bel ong t o t he same video f r ame.
Synchr onizat ion Sour ce f iel d is a 32-bit number t hat indicat es t he or iginat or of t he
message t hat inser t ed t he sequence number and t he t imest amp f or t he dat a so as not t o
be dependent on t he IP addr ess. As shown in t he pr evious sl ide on mixer s, t her e ar e t wo
sour ces of audio dat a. Each packet wil l cont ain t heir addr ess f or t he packet s t hat t hey
send. The sel ect ion of t he ident if ier is beyond t he scope of t his book, but t her e is a
r andom number gener at ed f or t his f iel d by t he sour ce, t her eby al l ows each sour ce t o be
unique. If t wo sour ces do sel ect t he same ident if ier , RTP does have t he mechanisms wit h
which t o det ect and cor r ect t his. This f iel d coul d indicat e an al t er nat e sour ce if t he
r eceived message was or iginat ed by a mixer . If t he t wo packet s ent er ed a mixer , t he mixer
woul d inser t it s 32-bit number as t he sour ce and push t he pr evious SSRC number s int o
t he Cont r ibut ing Sour ce Ident if ier .
RTP Message For mat
The Cont r ibut ing Sour ce Ident if ier indicat es a sour ce or sour ces (t he or iginal IDs of t he
sour ces) of a st r eam of RTP packet s t hat wer e invol ved in t he combined st r eam pr oduced
by a mixer .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 209
Support for Time-Sensitive Apps
RTP suppor t s sequencing, t imest amps, synchr onizes dif f er ent st r eams (audio or video),
and cont ains inf or mat ion descr ibing RTPs payl oad t ype. Inf or mat ion descr ibing t he
payl oad t ype al l ows RTP t o suppor t mul t ipl e compr ession t ypes such as MPEG and H.261.
In f act , an RTP r eceiver can r eceive inf or mat ion t hat is encoded by t wo dif f er ent
met hods and has t he abil it y t o pr oduce one singl e st r eam f r om t his. This is a pr ocess
known as mixing. It is expl ained l at er .
A digit ized audio signal may be pr oduced using an simpl ex encoding scheme known as
pulse code modulation (PCM). Say, f or exampl e, t hat PCM buil ds 160 byt e packet s ever y 20
mil l iseconds f or a sampl ed voice st r eam. This inf or mat ion is t r ansmit t ed t hr ough an
Int er net using IP. The digit izing of t he voice signal is ver y sensit ive t o t ime. The
r ecept ion of t he st r eam of voice must be put back int o t he or iginal t iming in which it was
t r ansmit t ed; ot her wise, t her e wil l be an uneven f l ow f or voice at t he r eceiver and it
wil l not be r eceived as it was spoken at t he or iginat or . IP does not car e about t iming,
sequencing, or del ays. It onl y has t o del iver t he dat a. IP wil l pr obabl y del iver t hese
packet s at dif f er ent t imes and may del iver t hem in var ying or der . Ther ef or e, an RTP
appl icat ion must put t he packet s back in t he or iginal or der and r eappl y t he t iming
bet ween t he packet s. RTP pr ovides inf or mat ion on t his but does not accompl ish t his
dir ect l y. Timest amps, which mar k t he r el at ive beginning of t he event , ar e pr ovided wit h
t he packet and t his pr ovides enough inf or mat ion t o t he appl icat ion t o r ebuil d t he
or iginal audio st r eam.
Suppor t f or Time-Sensit ive Apps

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 210
Payload Type
The next f iel d is t he payl oad t ype. Payl oad t ypes ar e l ist ed in t he f ol l owing t abl e:
Payl oad Type
The t ext page indicat es t he wide r ange of suppor t f or audio and video payl oad
t ypes f or RTP.
0 PCMU audio 1622 Unassigned audio
1 1016 audio 23 RGB8 video
2 G721 audio 24 HDCC video
3 GSM audio 25 Cel B video
4 Unassigned audio 26 JPEG video
5 DVI4 audio (4 kHz) 27 CUSM video
6 DBI4 audio (16 kHz) 28 nv video
7 LPC audio 29 PicW video
8 PCMA audio 30 CPV video
9 G722 audio 31 H261 video
10 L16 audio (st er eo) 32 MPV video
11 L16 audio (mono) 33 MP2T video
12 TPS0 audio 3471 Unassigned video
13 VSC audio 7276 Reser ved
14 MPA audio 7795 Unassigned
15 G728 audio 96127 Dynamic
Not t hat you woul d car e about al l of t hese payl oad t ypes, but t her e ar e a f ew t hat you
shoul d r ecognize.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 211
Providing Control for RTP
RTCP (Real -Time Cont r ol Pr ot ocol ) is t he cont r ol mechanism f or RTP and it pr ovides
inf or mat ion, in t he f or m of f eedback, on net wor k condit ions and r ecept ion qual it y.
Using RTCP al l ows RTP appl icat ions t o adapt t o var iances in t he media. For exampl e, a
r out er car r ying t he st r eam coul d become over l oaded and sl ow down t he f or war ding of
packet s. Anot her appl icat ion on t he net wor k is using consider abl e bandwidt h and t he
r eceiver s of RTP cannot r eceive as many packet s as quickl y as t hey want t o. RTCP
al l ows f or cont r ol inf or mat ion t o be dist r ibut ed t o not onl y t he ser ver but al so t he
r eceiver s. This al l ows f or r eceiver s and sender s t o make t heir own decisions about t he
qual it y. Anot her f eat ur e of RTCP is t he gat her ing of user inf or mat ion. RTCP r epor t s
who t hat ar e at t ending a session.
RTP can wor k al one, but usual l y does not . RTP r el ies on RTCP t o cont r ol inf or mat ion.
The message f or mat t hat RTP uses is t he same f or mat f or al l of it s message.
Pr oviding Cont r ol f or RTP

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 212
Sender Reports
Repor t s f or RTCP al l ow sender s and r eceiver s t o communicat e wit h each ot her f or
qual it y r easons. Each sender sends a r epor t giving st at ist ics f or it s t r ansmissions.
Receiver s consume t his dat a and al so send out r epor t s t o indicat e how wel l t hey ar e
r eceiving dat a. The sender s use t his dat a t o t une t heir t r ansmissions.
Ther e ar e t wo t ypes of r epor t s t hat RTP r eceiver s may send: Sender and Receiver r epor t s
(SR and RR, r espect ivel y). The t ype of r epor t sent depends on whet her t he r eceiver is
al so a sender . RTP r eceiver s pr ovide r ecept ion qual it y f eedback using t he RTCP r epor t s.
The sender r epor t t el l s r eceiver s what t hey shoul d have r eceived. The V is f or t he
ver sion number , which shoul d be set t o 2. The R Cnt is t he r eceiver bl ock count and
cont ains t he number of r eceiver bl ocks in t he message. The Lengt h f iel d indicat es t he
l engt h of t he packet in byt es.
Bot h t ypes of r epor t s ar e ver y simil ar . The onl y dif f er ence bet ween t he t wo r epor t s,
besides t he packet t ype, is t he 20-byt e sender inf or mat ion sect ion in t he Sender r epor t .
The Sender r epor t is issued t o l et t he r eceiver know what shoul d have been r eceived.
Bot h t he SR and RR can incl ude f r om 0 t o 31 bl ocks (not ice t he bl ocks ar e simpl y
r epl icat ed); 1 bl ock f or each of t he synchr onizat ion sour ces f r om which t he r eceiver
has r eceived RTP dat a packet s since it s l ast r epor t .
The SSRC f iel d t ies t he Sender r epor t t o any RTP dat a packet s t he sour ce may have
sent . The NTP t imest amp is t he act ual t ime of day. It is used as a cont r ol t o measur e t he
del t a f or t imest amps ext r act ed f r om r ecept ion r epor t s. This al l ows f or an est imat e t o be
made as t o t he r ound-t r ip pr opagat ion del ay t o t hose r eceiver s. The RTP t imest amp
al l ows r eceiver s t o put t his message in an or der r el at ive t o t he RTP packet s. The l ast
f iel ds indicat e t he number of packet s and byt es t he sender has t r ansmit t ed.
Sender Repor t s
The next sect ions ar e r eceiver bl ocks. In t he Sender r epor t , t hey al l ow t he sender t o
r epor t it s t r ansmit t ed dat a but al so any RTP dat a t hat is has r eceived. Each bl ock
r epr esent s one r emot e sour ce. The bl ock indicat es t he f r act ion of packet s f r om t hat
sour ce t hat wer e l ost since t he l ast r epor t and t he t ot al number of packet s l ost since
incept ion. The Ext ended Highest Sequence Number Received is t he highest sequence
number f r om t hat sour ce. The Int er ar r ival Jit t er f iel d al l ows f or t he r eceiver t o
est imat e t he var iance of t he sour ces int er ar r ival t imes. A high val ue indicat es t hat
t his r eceiver is r eceiving a st r eam of packet s ir r egul ar l y.
The l ast t wo f iel ds indicat e when t he l ast r epor t f r om t his sour ce ar r ived.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 213
Receiver Reports
The Receiver r epor t is basical l y t he same as t he Sender r epor t , wit h t he except ion t hat
t he sender inf or mat ion is st r ipped out . The Packet Type f iel d is set t o 201.
Receiver Repor t s

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 214
Source Description Packet
The SSDP is used t o pr ovide mor e inf or mat ion about t he sour ce. The RTP header is used
and t he packet t ype is set t o 202. The f ir st f iel d cont ains t he SSRC or CSRC ident if ier of
t he sour ce. Appl icat ions ar e f r ee t o put t heir own it ems in as wel l . The canonical name
(CNAME) is t he most impor t ant f iel d in t he packet and t he ot her f iel ds may or may not
be f il l ed out . Since SSRC ident if ier s can be dupl icat ed, t he RTP pr ot ocol pr ovides
mechanisms t o det ect and cor r ect t his dupl icat ion. Ther ef or e, t he CNAME f ur t her
ident if ies a sour ce using t he f or mat of user @domain-name.
Sour ce Descr ipt ion Packet

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 215
Bye Message (Packet)
In or der f or a sour ce t o l eave a conf er ence, it uses t he Bye packet . Event ual l y, al l
par t icipant s in t he conf er ence woul d not ice t he sour ce is missing, but t his message
al l ows t his t o be quickl y l ear ned. Incl uded in t he packet is a f iel d t hat al l ows t he
sour ce t o ident if y t he r eason t hat it is l eaving. This f iel d is opt ional .
Bye Message (Packet )

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 216
Application-Specific Message
Appl icat ion-Specif ic Message
Used by an appl icat ion t o send and r eceive it s own messages.
Al l ows f or uniqueness t o an appl icat ion.
Al l ows f or t he RTCP pr ot ocol t o be ext ensibl e.
This t ype of message al l ows f or exper iment at ion of t he RTCP pr ot ocol . It al l ows f or
appl icat ion devel oper s t o pl ace t heir own messages in a packet t o be used by a r eceiver
or sender of t heir appl icat ion. This is anot her exampl e of how t his pr ot ocol is r eal l y
not f inished and never wil l be, which al l ows f or uniqueness and ext ensibil it y.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 217
Caveats
Caveat s
RTP does not pr ovide any QoS capabil it ies.
RTP does not guar ant ee del iver y or out -of -sequence packet s.
RTP is onl y a f r amewor k.
Mol ded int o an appl icat ion
RTP is ext ensibl e.
Mor e inf or mat ion can be added t o t he packet passed bet ween RTP
cl ient s and ser ver s
RTP does not pr ovide f or any Qual it y of Ser vice (QoS) par amet er s such as t hose t hat
al l ow f or t imel y del iver y. RTP does not guar ant ee del iver y or in-sequence packet s. It
pr ovides sequencing, but mer el y f or t he t r anspor t sequencing of pl acing t he or der of
packet s in oper at ions l ike decoding; however , t he packet s can be decoded out of
r eceiving sequence. Like most ot her TCP/IP pr ot ocol s, a pr ot ocol is a pr ot ocol and not
t wo pr ot ocol s. RTP expect s ot her TCP/IP pr ot ocol s t o pr ovide f or QoS ser vices.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 218
RFCs
To see what is pl aying on t he MBONE:
www.pr ecept .com/cgi-bin/ipt v/ipt vmain.pl
or
www.cil ea.it /col l abor a/MBone/agenda.ht ml
RTP and RTCP ar e cont ained in RFC 1889.
RFCs
RFC 1889The Real -Time Pr ot ocol (t his incl udes t he RTCP pr ot ocol as wel l ).

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 219
Selected TCP/IP Applications
This sect ion gives you an int r oduct ion t o TELNET, FTP, TFTP, SMTP (incl uding POP),
and DNS.
Ther e can be many appl icat ions wr it t en f or t he TCP/IP envir onment , and many exist
t oday. Ther e ar e wor d pr ocessing syst ems, CAD/CAM syst ems, mail syst ems, and so on. The
seven most common appl icat ions (besides Web appl icat ions) t hat r un on t he TCP/IP
net wor k syst em ar e:
TELNET (Remot e Ter minal Emul at ion)
Sel ect ed TCP/IP Appl icat ions
Remot e Ter minal Emul at ion (TELNET)
Post Of f ice Pr ot ocol (POP)
These appl icat ions ar e f ul l y document ed in t he RFCs and al most al ways ar e del iver ed
wit h any TCP/IP pr ot ocol suit e in t he mar ket t oday. This means t hat you can swit ch t o
al most any t ype of comput er using TCP appl icat ions sof t war e and t he commands and
f unct ions of t hese pr ogr ams wil l be t he same.
The appl icat ions wer e specif ical l y wr it t en f or TCP/IP and basical l y pr ovide al most al l
t he appl icat ions t hat user s need t o access any net wor k. Dat abase pr ogr ams, wor d
pr ocessing pr ogr ams, and so f or t h, ar e al l viabl e pr ogr ams, but ar e not per t inent t o t he
oper at ion of a TCP/IP net wor k. Using t he f or egoing appl icat ion, a user can f ind any
ot her needed appl icat ion on t he Int er net . The ones just l ist ed ar e t he bar e minimum
needed t o cr eat e a net wor ked user envir onment in which al l user s can act ivel y
communicat e and shar e dat a wit h each ot her acr oss t he net wor k.
One nice t hing about t hese avail abl e net wor k appl icat ions is t hat t hey r un on TCP/IP
no mat t er which oper at ing syst em is being used. The commands, t heir connect ion
t echniques, t he commands t hat cont r ol t he appl icat ion, and t he int er f ace t o t he user
al most al ways wil l be t he same. So, if you nor mal l y wor k wit h Unix and t hen swit ch f or
a day t o DOS, t he same FTP commands t hat oper at ed on t he Unix machine wil l be t her e
in t he DOS machine. It is har d t o say t hat wit h most appl icat ions t oday. The discussion
st ar t s wit h t he TELNET pr ot ocol .
The pr ot ocol s ar e cover ed br ief l y. Pl ease r ef er t o t he TCP/IP books l ist ed at t he back of
t his book f or mor e inf or mat ion about t hese pr ot ocol s.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 220
TELNET
The TELNET connect ion simpl y al l ows a t er minal ser vice over t he TCP/IP net wor k as if
t he t er minal wer e dir ect l y connect ed. Remember t hat comput er s and t er minal s wer e
connect ed by a cabl e and t he t er minal s wer e dir ect l y at t ached t o t he host comput er .
The TELNET ser vice pr ovides a t er minal ser vice f or t he net wor k. It al l ows f or any
t er minal t o at t ach t o any comput er over t he net wor k. It can emul at e many dif f er ent
t ypes of t er minal s, depending on t he manuf act ur er of t he TELNET pr ogr am. Ther e ar e
TELNET pr ogr ams t hat emul at e DEC VTxxx ser ies of t er minal s, IBM 3270 and 5250
t er minal s, and mor e.
The advant age t o t he TELNET pr ogr am is t hat a user may l og on t o any host on t he
TCP/IP int er net (pr ovided secur it y opt ions ar e al l owed). Sessions ar e set up over t he
TCP/IP net wor k.
The sl ide shows a t ypical TELNET connect ion on a TCP/IP net wor k.
The TELNET pr ot ocol uses TCP as it s t r anspor t . The user st ar t s t he TELNET pr ot ocol at
his or her wor kst at ion, usual l y by t yping TELNET <domain name or IP addr ess>. The
TELNET appl icat ion may be st ar t ed wit h or wit hout an ar gument . The ar gument al l ows
a simpl er pr ocedur e t o be invoked so t hat t he TELNET pr ocess wil l aut omat ical l y t r y t o
connect t o t he host signif ied by t he ar gument st at ement . The TELNET appl icat ion
st ar t s and at t empt s t o est abl ish a connect ion t o t he r emot e device (by accessing t he
ser vices of t he Domain Name Ser ver or dir ect l y wit h t he IP addr ess; DNS wil l be
discussed l at er ). If an ar gument is not suppl ied, t he TELNET appl icat ion wait s f or t he
user t o issue an OPEN command connect ion using t he DNS or an IP addr ess.
TELNET

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 221
TELNET Options
TELNET Opt ions
Each side of t he connect ion r equest s or t el l s it s par t ner t he opt ions it want s
or can do.
Opt ions ar e f or mat t ed in:
WILL or WONT <opt ion>
DO or DONT <opt ion>
Negot iat es opt ions such t hat symmet r y can be set up bet ween t wo st at ions.
Opt ions incl ude:
Abil it y t o echo
Ter minal t ype
Set t ing l ine mode so t hat gr oups of char act er s can be sent
The TELNET pr ogr am is ext ensibl e t hr ough t he use of opt ions. Each side of t he
connect ion r equest s or t el l s t he r emot e end of t he connect ion which of t hese opt ions it
can suppor t and which one t he r emot e end shoul d suppor t . This pr ovides f or symmet r y.
The TELNET pr ot ocol was wr it t en so t hat it woul d wor k on a var iet y of oper at ing
syst ems. Ther ef or e, bef or e a connect ion is made t o t he r emot e device, t he TELNET
pr ot ocol has some wor k t o do in or der t o synchr onize t he connect ion wit h t he r emot e
device. For exampl e, t he DOS oper at ing syst em f or per sonal comput er s r equir es t hat a
CR-LF (car r iage r et ur n-l ine f eed) be used t o t er minat e a l ine of t ext . Ot her syst ems
such as Unix r equir e a l ine of t ext t o be t er minat ed wit h an LF. Anot her exampl e is t he
echoing of char act er s. Upon connect ion at t empt , t he TELNET pr ot ocol wil l negot iat e
wit h t he r emot e device as t o who wil l do t he echoing of t yped char act er s t o t he
init iat or of a connect ion. Dur ing t he connect ion at t empt bet ween a sour ce and
dest inat ion st at ion, t he t wo st at ions wil l communicat e opt ions. These opt ions indicat e
how each end of t he connect ions wil l r espond on t he TELNET connect ion. These opt ions
incl ude:
1. The abil it y t o change f r om 7-bit t ext t o 8-bit binar y
2. Al l owing one side or t he ot her t o echo char act er s
3. Specif ying a t er minal t ype
4. Request ing t he st at us of a TELNET opt ion f r om t he r emot e connect ion
5. Set t ing a t iming mar k t o synchr onize t wo ends of a connect ion
6. The abil it y t o t er minat e a r ecor d wit h an EOR code
7. Set t ing l ine mode so t hat st r ings of char act er s may be sent inst ead of a
char act er -at -a-t ime t r ansmit
8. St opping t he go-ahead signal af t er dat a
The opt ions ar e negot iat ed bet ween t he t wo net wor k st at ions in t he f ol l owing manner :
Request Response
WILL <opt ion> DO or DONT <opt ion>
For exampl e, WILL ECHO f r om st at ion A is r equest ing t hat st at ion A pr ovide t he
echoing of char act er s. The r esponse wil l eit her be DO ECHO, meaning t he r emot e end
agr ees, or DONT ECHO, meaning t he r emot e end wil l not al l ow st at ion A t o echo.
Agr eement bet ween t he t wo TELNET ends communicat ed f or a DO <opt ion> wil l be
r esponded t o wit h a WILL <opt ion> or WONT <opt ion>. An exampl e of t his opt ion
negot iat ion: If t he TELNET appl icat ion is r unning on a DOS per sonal comput er which is
set up f or l ocal echo, upon t he connect ion set up t he TELNET opt ion f r om t he PC wil l be
WILL ECHO and t he r esponse shoul d be DO ECHO. If t he PC had been set up wit hout t he
l ocal echo opt ion and you wish t he r emot e end t o pr ovide echo, t he PC shoul d negot iat e
echo wit h DO ECHO and t he r esponse wil l be WILL ECHO.
Using WILL, WONT, DO, and DONT pr ovides symmet r y. Eit her side of t he connect ion
can pr ovide t he command or t he r esponse. One side pr ovides ser vices in exact l y t he same
manner as t he ot her side.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 222
File Transfer Protocol (FTP)
TELNET pr ovides user s wit h t he abil it y t o act as a l ocal t er minal even t hough user s
ar e not dir ect l y at t ached t o t he host . One ot her TCP/IP appl icat ion t hat pr ovides
net wor k ser vices f or user s on a net wor k is a file transfer protocol. Wit h TCP/IP, t her e ar e
t hr ee popul ar t ypes of f il e access pr ot ocol s in use: FTP, Tr ivial Fil e Tr ansf er Pr ot ocol
(TFTP), and Net wor k Fil e Syst em (NFS). This FTP pr ot ocol pr ovides f or f il es t o be
t r ansf er r ed r el iabl y acr oss t he net wor k under t he compl et e cont r ol of t he user . FTP is
t r ansact ion based. Ever y command is r epl ied t o using a number scheme simil ar t o t he
SMTP pr ot ocol (discussed in a moment ).
FTP is ver y r obust . Remember t he pr evious discussion on por t s and socket s and how t hey
ar e est abl ished and used. The FTP pr ot ocol act ual l y uses t wo por t assignment s (and
t her ef or e t wo connect ions): 20 and 21. Remember t hat most connect ions bet ween t wo
net wor k st at ions ar e made via one sour ce por t and one dest inat ion por t . A net wor k
st at ion want ing a connect ion t o a r emot e net wor k st at ion must connect t o t wo por t s
on t he dest inat ion st at ion in or der f or FTP t o wor k.
Por t 20 is used f or t he init ial set up of t he connect ion and as t he cont r ol connect ion. No
dat a passes over t his cir cuit except f or cont r ol inf or mat ion. Por t 21 is used f or user
dat a (t he f il e t o be t r ansf er r ed) t o pass over t he connect ion.
Simil ar t o t he TELNET ar gument s, simpl y t yping FTP <domain name or IP addr ess> wil l
est abl ish t he connect ion. The command l ine shoul d t hen r ead FTP> (t his depends on
your appl icat ion). Wit h t he advent of Windows and Windows-l ike oper at ing syst ems, FTP
now has a GUI int er f ace in or der t o t ake some of t he har shness out of t he pr ot ocol .
Af t er t he connect ion is est abl ished, t he ser ver pr ocess await s a command f r om t he
cl ient . To t r ansf er a f il e f r om t he ser ver t o t he cl ient , t he user t ypes in get <a name of
a f il e>, which is t r ansmit t ed over t o t he r emot e net wor k st at ion. Wit h t his, a second
connect ion is est abl ished bet ween t he ser ver and cl ient FTP pr ocess. It is known as t he
data connection. Now we have t wo connect ions, but onl y dur ing t he f il e t r ansf er pr ocess.
Once t he f il e is t r ansf er r ed, t he dat a connect ion por t is cl osed.
This is t he wel l -known (or assigned) FTP dat a por t . Fr om a user s st andpoint , t o
est abl ish a connect ion bet ween it sel f and a r emot e st at ion, t he command is simil ar t o
TELNET: FTP <domain name or IP addr ess>. A user coul d al so t ype in FTP and wait f or
t he FTP pr ompt . At t he pr ompt , t he user woul d use t he OPEN command t o est abl ish t he
connect ion.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 223
FTP Commands
The f ol l owing ar e t he avail abl e commands in FTP. Ther e ar e a l ot of commands l ist ed
but , in r eal it y, onl y a f ew ar e used. They ar e:
open Open a connect ion t o a r emot e r esour ce.
cl ose Cl ose a connect ion t o a r emot e r esour ce.
bye End t his FTP session.
binar y Indicat e t hat t he f il e t r ansf er wil l be a f il e of binar y t ype (i.e., execut abl e
f il e, Lot us f il e, et c.).
get Get a f il e f r om t he r emot e r esour ce; get <f il ename> mget <mul t ipl e f il es,
wil dcar ds incl uded>.
put Put a f il e t o t he r emot e r esour ce; put <f il ename> mput <mul t ipl e f il es,
wil dcar ds incl uded>.
cd Change dir ect or y on t he r emot e device; t o change t he dir ect or y on t he l ocal
end, use l cd.
dir Get a dir ect or y l ist ing on t he r emot e device; t o get a dir ect or y l ist ing on t he
l ocal end, use l dir .
hash Displ ay hash mar ks on t he scr een t o indicat e a f il e is being t r ansf er r ed.
FTP Commands
opencr eat es a connect ion bet ween t wo host s.
cl osecl oses a connect ion bet ween t wo host s.
byeends t he FTP session.
binar yindicat e t hat t he f il e is binar y dat a.
get get t he r emot e f il e.
mget wil dcar d t o get mul t ipl e f il es.
put put s a f il e t o t he r emot e r esour ce.
mput wil dcar d t o put mul t ipl e f il es.
cdchange dir ect or y on t he r emot e device.
dir get a dir ect or y l ist ing on t he r emot e device.
l dir get a l ocal dir ect or y.
hashdispl ay hash mar ks dur ing t he t r ansf er .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 224
FTP Data Transfer
FTP Dat a Tr ansf er
C:\WINDOWS>ftp
ftp> open mnauglepc
Connected to mnauglepc.
220 mnauglepc FTP service (NEWT v4.01)
ready for new user.
User (mnauglepc:(none)): mnaugle
331 mnaugle, please enter your password.
Password:
230 User mnaugle logged in.
ftp> pwd
257 c:\ is the current directory.
ftp> lcd
Local directory now C:\WINDOWS
ftp> get autoexec.bat autoexec.002
200 PORT command successful.
150 Opening ASCII mode data connection
for autoexec.bat.
226 File transfer complete.
1911 bytes received in 0.00 seconds
(1911000.00 Kbytes/sec)
ftp> bye
221 Goodbye.
Ref er t o t he sl ide. Commands such as t he f ol l owing ar e sent over t he cont r ol por t .
Once t he connect ion is est abl ished, f il e t r ansf er act ual l y occur s over t he dat a por t . If
a user want s t o est abl ish an FTP connect ion bet ween 148.1.1.2 and an FTP ser ver pr ocess
on 148.1.1.19, t he f ol l owing sequence of event s t ake pl ace on a DOS PC (f or ot her
oper at ing syst ems, t he pr ompt woul d change, but t he commands ar e al l t he same in ever y
FTP impl ement at ion):
C> FTP or FTP <domain name or IP addr ess>
If mul t ipl e f il es ar e needed, t he user can use t he commands MGET or MPUT, which
st ands f or Mul t ipl e GET and Mul t ipl e PUT, r espect ivel y. If t he f il e we want is a binar y
f il e (a spr eadsheet and an appl icat ion ar e exampl es of binar y f il es), t he user has t o t ype
in t he keywor d binar y at t he FTP pr ompt . This indicat es t o t he FTP pr ogr am t hat t he
f il e t o be t r ansf er r ed is a binar y f il e. Any of t he commands may be ent er ed at t he FTP
pr ompt . The pr ot ocol is t r ansact ion based and t he number s pr eceding each l ine ar e f or
t he node t o int er pr et t he next command. The t ext is f or human consumpt ion.
C:\WINDOWS>f t p
f t p> open mnaugl epc
Connect ed t o mnaugl epc.
220 mnaugl epc FTP ser vice (NEWT v4.01) r eady f or new user .
User (mnaugl epc:(none)): mnaugl e
331 mnaugl e, pl ease ent er your passwor d.
Passwor d:
230 User mnaugl e l ogged in.
f t p> pwd
257 c:\ is t he cur r ent dir ect or y.
f t p> l cd
Local dir ect or y now C:\WINDOWS
f t p> get aut oexec.bat aut oexec.002
200 PORT command successf ul .
150 Opening ASCII mode dat a connect ion f or aut oexec.bat .
226 Fil e t r ansf er compl et e.
1911 byt es r eceived in 0.00 seconds (1911000.00 Kbyt es/sec)
f t p> bye
221 Goodbye.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 225
Trivial File Transfer Program (TFTP)
An al t er nat ive t o t he FTP pr ogr am is t he TFTP pr ogr am. This is a simpl ex f il e t r ansf er
pr ogr am and is pr imar il y used t o boot st r ap diskl ess net wor k wor kst at ions (t he pr ogr am
is smal l enough t o f it in a ROM chip on t he diskl ess wor kst at ion t o init iat e a boot acr oss
t he net wor k) or even net wor k component s (net wor k br idges and r out er s). The FTP
pr ogr am is an ext r emel y r obust and compl ex pr ogr am, and sit uat ions exist t hat r equir e
f il e t r ansf er capabil it ies wit hout compl exit y. Hence, FTP is al so a l ar ger f il e. TFTP is a
smal l f il e and pr ovides a mor e r est r ict ive f il e t r ansf er (f or exampl e, no user
aut hent icat ion); it is al so a smal l er execut abl e sof t war e pr ogr am.
Ther e ar e dif f er ences bet ween FTP and TFTP. TFTP does not pr ovide a r el iabl e ser vice;
t her ef or e, it uses t he t r anspor t ser vices of UDP inst ead of TCP. It al so r est r ict s it s
dat agr am size t o 512 byt es, and ever y dat agr am must be acknowl edged (no mul t ipl e-
packet windowing). Ther e ar e no windows f or packet s t o be acknowl edged. It coul d be
said t hat it has a window of 1.
The pr ot ocol is ver y simpl e. The f ir st packet t r ansmit t ed f r om t he cl ient pr ocess t o t he
ser ver pr ocess is a cont r ol packet , which specif ies t he f il ename and whet her it is t o be
r ead f r om or wr it t en t o t he r emot e wor kst at ion (GET or PUT command). Subsequent
packet s ar e dat a packet s and f il e t r ansf er is accompl ished wit h 512 byt es t r ansf er r ed at
one t ime. The init ial dat a packet is special l y mar ked wit h a number of 1. Each
subsequent dat a is incr ement ed by 1. This is t he sequence number ing syst em f or TFTP. The
r eceiving st at ion wil l acknowl edge t his packet immediat el y upon r eceipt , using t his
number . Any packet of l ess t han 512 byt es in l engt h signif ies t he end of t he t r ansf er .
Er r or messages may be t r ansmit t ed in pl ace of t he dat a in t he dat a f iel d, but any er r or
message wil l t er minat e t he t r ansmission. Al so not ice t hat onl y one connect ion is made
t o t he r emot e r esour ce. FTP has one f or dat a and one f or cont r ol inf or mat ion. FTP is a
ver y r obust pr ot ocol , one t hat can handl e many t ypes of t r ansf er s over var ious (not so
good) media t ypes. The commands of GET and PUT ar e used t he same as in t he FTP
pr ogr am.
Tr ivial Fil e Tr ansf er Pr ogr am (TFTP)
A simpl ex f il e t r ansf er pr ogr am.
Uses UDP.
Tr ansf er s 512 byt es at a t ime.
Tr ansf er s one segment at a t ime.
Acknowl edged by t he appl icat ion.
Any dat agr am l ess t han 512 byt es indicat es t he l ast dat agr am in t he t r ansf er .
Popul ar f or net wor k boot ing of devices.
The sequencing of t he dat a is accompl ished t hr ough t he TFTP appl icat ion, not t he
t r anspor t -l ayer ser vice of UDP. UDP pr ovides onl y unr el iabl e, connect ionl ess ser vice.
TFTP keeps t r ack of t he sequencing of t he bl ocks of dat a and t he acknowl edgment s
t hat shoul d be r eceived. For t hose r eader s f amil iar wit h Net War e, t his is t he same t ype
of t r ansact ion accompl ished bet ween t he Net War e Cor e Pr ot ocol (NCP, not using Bur st
mode) and it s under l ying del iver y syst em, IPX.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 226
Domain Name Service (DNS)
Read RFCs 1034 and 1035. These cont ain t he bul k of t he DNS inf or mat ion and ar e
suppl ement ed by RFCs 15351537. DNS has many uses, but it s main f unct ion cont inues t o
be t he mapping of IP addr ess t o human-usabl e names.
Ther e ar e mil l ions of host s on t he Int er net t oday r epr esent ing even mor e mil l ions of
user s. Most user s have no idea what t he under l ying pr ot ocol s ar e doing, nor do t hey
car e. But most of t hem woul d if t hey had t o memor ize IP addr esses and det er mine ot her
f unct ions such as mail . Act ual l y, most woul d be f r ust r at ed by t he number ing syst em
and t he Int er net woul d not be as popul ar as it is. When t he Int er net was young, an
ear l y met hod of mapping t he 32-bit addr ess t o a host name r equir ed downl oading a f il e
maint ained by (at t he t ime) t he Net wor k Inf or mat ion Cent er (NIC). It was a singl e f il e
(host s.t xt ) t hat cont ained a simpl e mapping of Int er net addr esses t o host names. This f il e
was usual l y cont ained in t he /et c subdir ect or y on a wor kst at ion and var ious TCP/IP
appl icat ions coul d access t he inf or mat ion in t his f il e. Not having t his f il e meant t hat a
user had t o t ype in t he 32-bit addr ess f or connect ivit y t o a r emot e host . Secondl y,
popul at ion of t he Int er net was becoming ver y diver se and mor e aut onomous. In t he 1980s
t he Int er net was known as t he ARPAnet (now shut down) and t he host s wer e pr imar il y
t ime shar ed. Mor e and mor e connect ions t o t he Int er net wer e sit es t hat had LANs
inst al l ed and connect ed t o t hese LANs wer e mainf r ame and minicomput er s or even
per sonal comput er s. These sit es wer e administ er ing t heir own names and addr esses in t he
host s.t xt f il e, but had t o wait f or t he NIC t o change host s.t xt t o make changes visibl e
t o t he Int er net at l ar ge. Last l y, wit h t he addit ions of mor e sit es t o t he Int er net , t he
appl icat ions on t he Int er net wer e get t ing mor e sophist icat ed and cr eat ing a need f or a
gener al -pur pose name ser vice.
Af t er many exper iment al RFCs, t he gl obal name syst em f or t he Int er net became known
as t he Domain Name Syst em (DNS). DNS is compr ised of t hr ee component s: a name server, a
database, and a name resolver. Name ser ver s make inf or mat ion avail abl e t o t he r esol ver s.
The inf or mat ion t he name ser ver s cont ain ar e IP addr esses, al iases, mail inf or mat ion,
and so f or t h. The r esol ver s usual l y r eside on user s wor kst at ions and ar e embedded in
t he appl icat ions of TCP such as TELNET and FTP. They ar e not separ at e pr ogr ams. The
name ser ver is a separ at e pr ogr am and r esides anywher e on a net wor k answer ing quer ies
f r om t he r esol ver s. The domain ser ver s each maint ain a por t ion of t he hier ar chical
dat abase under separ at e administ r at ive aut hor it y and cont r ol . Redundancy is obt ained
by t r ansf er r ing dat a bet ween cooper at ing ser ver s (pr imar y mast er s and secondar y
mast er s).
Your sit e may not r equir e a DNS. You may have just a f ew host s and can depend on
anot her DNS t o suppl y t he inf or mat ion you need. For t he Int er net it sel f , it must have
t he DNS syst em. A gr eat exampl e on t he dependency of DNS was when a cor r upt ed
dat abase (cont aining dir ect ions t o ot her host s) f il e was post ed on t he nine r oot
ser ver s (expl ained in a moment ). Mil l ions of on-l iner s wer e wit hout t he capabil it y of
at t aching or communicat ing wit h ot her host s on t he net wor k f or hour s. Wit hout
inf or mat ion (t he IP addr ess) of a r emot e syst em, t wo nodes cannot communicat e. We
coul d l ook up t he inf or mat ion in t he Int er NIC dat abase, but wit hout pr ior knowl edge
on how t o quer y t heir dat abase manual l y, one is l it er al l y l ost on t he Int er net . DNS
pr ovides inf or mat ion about host s, not user s, on t he Int er net .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 227
DNS Structure
The Domain Name Space is ver y much l ike a f il e syst em on Unix or DOS. It st ar t s wit h a
r oot and br anches at t ach f r om t his r oot t o give an endl ess ar r ay of pat hs. Each br anch
in t he f il e syst em is given a dir ect or y name, wher eas in DNS it is cal l ed a label. Each
l abel can be 63 char act er s in l engt h, but most ar e f ar l ess t han t hat . This means t hat
each t ext wor d bet ween t he dot s can be 63 char act er s in l engt h, wit h t he t ot al domain
name (al l t he l abel s) l imit ed t o 255 byt es in over al l l engt h assuming a scr een l ine
l engt h of 80 char act er s t his is just 3 scr een l ines.
The IP pr ot ocol mandat es t he use of IP addr esses. Any user may use t his addr ess t o
connect t o any ser vice on t he net wor k; however , f or a user t o r emember t he addr esses
of al l t he net wor k ser ver s on t he net wor k is an impossibl e t ask. User s ar e mor e l ikel y
t o r emember names t han t hey ar e t o r emember number s.
For t hose f amil iar wit h dat abase envir onment s, t he domain name ser ver is simpl y a
dat abase (consist ing of inf or mat ion such as names and IP addr esses, and much mor e) t o
which any st at ion on t he net wor k can make quer ies using t he domain name r esol ver . The
domain name syst em is not necessar il y compl ex, but it is invol ved. It is based on a
hier ar chical st r uct ur e as shown in t he sl ide. The assignment of names is r el at ivel y
simpl e and is accompl ished via t he Int er net Regist r ies wit h t he ul t imat e aut hor it y being
IANA. The domain name is simpl y t hat : a name assigned t o a domain For exampl e, isi.edu,
cisco.com, and 3Com.com r epr esent t he domain name at t hose companies or educat ional
inst it ut ions. The naming wit hin t hose domains (naming of t he host s) is l ef t up t o t hose
individual s who ar e assigned t hose domain names. The Int er NIC does not car e. The
hier ar chical st r uct ur e al l ows host s t o have t he same name as l ong as t hey ar e in
dif f er ent br anches of t he st r uct ur e or in dif f er ent domains.
DNS St r uct ur e

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 228
DNS Components
DNS does much mor e t han t he name-t o-addr ess t r ansl at ion. It al so al l ows f or :
The Domain Name Space and r esour ce r ecor ds. This is t he dat abase of gr ouped
names and addr esses t hat ar e st r ict l y f or mat t ed using a t r ee-st r uct ur ed name
space and dat a associat ed wit h t he names. The domain syst em consist s of separ at e
set s of l ocal inf or mat ion cal l ed zones. The dat abase is divided up int o sect ions
cal l ed zones, which ar e dist r ibut ed among t he name ser ver s. Whil e name ser ver s
can have sever al opt ional f unct ions and sour ces of dat a, t he essent ial t ask of a
name ser ver is t o answer quer ies using dat a in it s zones. Concept ual l y, each node
and l eaf of t he domain name space t r ee names a set of inf or mat ion, and quer y
oper at ions ar e at t empt s t o ext r act specif ic t ypes of inf or mat ion f r om a par t icul ar
set . A quer y names t he domain name of int er est and descr ibes t he t ype of r esour ce
inf or mat ion t hat is desir ed.
DNS Component s
Domain Name Space and r esour ce r ecor ds
Name ser ver s
Resol ver s
Name ser ver s. These ar e wor kst at ions t hat cont ain a dat abase of inf or mat ion
about host s in zones. This inf or mat ion can be about wel l -known ser vices, mail
exchanger , or host inf or mat ion. A name ser ver may cache st r uct ur e or set
inf or mat ion about any par t of t he domain t r ee, but in gener al , a par t icul ar name
ser ver has compl et e inf or mat ion about a subset of t he domain space, and point er s
t o ot her name ser ver s t hat can be used t o l ead t o inf or mat ion f r om any par t of
t he domain t r ee. Name ser ver s know t he par t s of t he domain t r ee f or which t hey
have compl et e inf or mat ion; a name ser ver is said t o be an aut hor it y f or t hese
par t s of t he name space. Aut hor it at ive inf or mat ion is or ganized int o unit s cal l ed
zones, and t hese zones can be aut omat ical l y dist r ibut ed t o t he name ser ver s t hat
pr ovide r edundant ser vice f or t he dat a in a zone. The name ser ver must
per iodical l y r ef r esh it s zones f r om mast er copies in l ocal f il es or f or eign name
ser ver s.
Resol ver s. These ar e pr ogr ams t hat gener al l y r eside on user s wor kst at ions and
send r equest s over t he net wor k t o ser ver s on behal f of t he user s. Resol ver s must
be abl e t o access at l east one name ser ver and use t hat name ser ver s inf or mat ion
t o answer a quer y dir ect l y, or pur sue t he quer y using r ef er r al s t o ot her name
ser ver s.
When a DNS ser ver r esponds t o a r esol ver , t he r equest er at t empt s a connect ion t o t he
host using t he IP addr ess and not t he name. The pr eceding exampl e coul d have used onl y
par t of a name: host . This is known as a relative name. It is par t of a l ar ger name known as
t he absolute name. The absol ut e name f or t he pr eceding exampl e coul d be
host .r esear ch.Naugl e.com. This name woul d be in t he domain name ser ver . Most
r esol ver s wil l st ep t hr ough a pr econf igur ed l ist of suf f ixes (in or der of conf igur ed
input ), append it t o t he name, and at t empt a l ookup when t he f ul l DNS (absol ut e) name
is not specif ied.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 229
Domain Structure
DNS is hier ar chical in st r uct ur e, as shown pr eviousl y. A domain is a subt r ee of t he
domain name space. The advant age of t his st r uct ur e is t hat at t he bot t om, t he net wor k
administ r at or can assign t he names.
Fr om t he r oot , t he assigned t op-l evel domains (TLD) ar e as f ol l ows:
GOV Gover nment body.
EDU Educat ional body.
COM Commer cial ent it y.
MIL Mil it ar y.
ORG Any ot her or ganizat ion not pr eviousl y l ist ed.
CON Any count r y using t he ISO st andar d 3166 f or names of count r ies As st at ed in RFC
1591, t he IANA is not in t he business of what is and what is not a count r y.
Ther ef or e, it is up t o ISO t o det er mine who is on t hat l ist .
Now l et s l ook at t he gener al ized f or mat f or a domain name.
Going down t he t r ee, we can pick out a domain name, such as r esear ch.Naugl e.com. This
woul d signif y t he Resear ch depar t ment (which is a subdomain of domain Naugl e.com) at
Naugl e Ent er pr ises, which is def ined as a commer cial ent it y of t he Int er net . Naugl e.com
can be a node in t he domain act ing as a name ser ver , or t her e may be dif f er ent name
ser ver s f or Naugl e.com.
A user at wor kst at ion 148.1.1.2 t ypes in t he TELNET command and t he domain name of
host 1.r esear ch.Naugl e.com. This wor kst at ion must have t he domain name r esol ver
inst al l ed on it . This pr ogr am woul d send out t he t r ansl at ion r equest t o a domain name
ser ver t o r esol ve t he host name-t o-IP addr ess. If t he host name is f ound, t he domain name
ser ver woul d r et ur n t he IP addr ess t o t he wor kst at ion. If t he name is not f ound, t he
ser ver may sear ch f or t he name el sewher e and r et ur n t he inf or mat ion t o t he r equest ing
wor kst at ion, or r et ur n t he addr ess of a name ser ver t hat t he wor kst at ion (if abl e) can
quer y t o get mor e inf or mat ion. Mor e on t hat in a moment . A domain cont ains al l host s
whose domain names ar e wit hin a cer t ain domain. A domain name is a sequence of l abel s
separ at ed by dot s. A domain is a subdomain of anot her domain if it is cont ained wit hin
t hat domain. This r el at ionship can be t est ed by seeing if t he subdomains name ends wit h
t he cont aining domains name. For exampl e, r esear ch.Naugl e.com is a subdomain of
Naugl e.com. Naugl e.com is a subdomain of .com, and (r oot ).
Domain St r uct ur e
Ther e ar e special ser ver s on t he Int er net t hat pr ovide guidance t o al l name ser ver s.
These ar e known as r oot name ser ver s and, as of t his wr it ing, t her e ar e nine of t hem.
They do not cont ain al l inf or mat ion about ever y host on t he Int er net , but t hey do
pr ovide dir ect ion as t o wher e domains ar e l ocat ed (t he IP addr ess of t he name ser ver f or
t he upper most domain a ser ver is r equest ing). The r oot name ser ver is t he st ar t ing point
t o f ind any domain on t he Int er net . If access t o t he r oot ser ver s ceased, t r ansmission
over t he Int er net woul d event ual l y come t o a hal t .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 230
Name Servers
The pr ogr ams t hat keep inf or mat ion about t he domain name space ar e cal l ed name
servers. The name r esol ver s do not usual l y st or e inf or mat ion, nor ar e t hey pr ogr ammed
wit h inf or mat ion l ike a name ser ver . Al l inf or mat ion is kept in t he ser ver .
Name ser ver s keep inf or mat ion about some par t of t he name space, cal l ed a zone. Name
ser ver s can be aut hor it at ive about one or mor e zones. Being aut hor it at ive means t hat
t his ser ver is al l -knowing about t he zone. A ser ver can be aut hor it at ive f or mor e t han
one zone, and it can be a pr imar y name ser ver f or one zone and a secondar y name ser ver
f or anot her . However , t hese f unct ions r ar el y cr oss; name ser ver s ar e eit her pr imar y or
secondar y f or t he zones t hey l oad.
Ther e ar e t wo t ypes of name ser ver s: primary masters and secondary masters. The pr imar y
mast er buil ds it s dat abase f r om f il es t hat wer e pr econf igur ed on it s host s, cal l ed zone or
database files. The name ser ver r eads t hese f il es and buil ds a dat abase f or t he zone it is
aut hor it at ive f or . Secondar y mast er s can pr ovide inf or mat ion t o r esol ver s just l ike t he
pr imar y mast er s, but t hey get t heir inf or mat ion f r om t he pr imar y. Any updat es t o t he
dat abase ar e pr ovided by t he pr imar y. This syst em was set up f or ease of use. It is al so
impor t ant t o not e t hat t her e shoul d be mor e t han one name ser ver per zone or domain.
Name Ser ver s
Let s t ake a simpl e exampl e. You ar e host on domain Naugl e.com. Specif ical l y,
host 1.r esear ch.Naugl e.com. You ar e l ooking f or a host named l abhost .bnr .ca.us. You
t ype in TELNET l abhost .bnr .ca.us. The name ser ver on your net wor k is a pr imar y and is
not aut hor it at ive f or t he .us domain. Your name ser ver t hen sends out a quer y t o t he
r oot ser ver t hat it knows about and t hat r oot ser ver r ef er s you t o t he name ser ver f or
t he .us domain. Your name ser ver wil l send out a r equest t o t hat name ser ver f or .ca.
The .ca name ser ver r ef er s you t o anot her name ser ver aut hor it at ive f or t he domain
bnr .ca. Your ser ver t hen sends one f inal r equest t o t hat ser ver f or inf or mat ion on
l abhost .bnr .ca. That ser ver r esponds wit h t he IP addr ess, which your ser ver r et ur ns t o
your wor kst at ion. The TELNET pr ot ocol t hen uses t hat IP addr ess t o at t empt a
connect ion t o your r equest ed dest inat ion. A point t o br ing out her e is t hat t he
inf or mat ion in t he name ser ver dat abase is not dynamic in t hat it does not know of t he
st at us of any st at ion (t hat st at ion may be t ur ned of f , not accept ing any new
connect ions, et c). The name ser ver f unct ion simpl y r esponds t o r equest s f or inf or mat ion
t hat is cont ained in it s dat abase.
Name Ser ver s (cont inued)

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 231
Query Function Types
Ther e ar e t wo t ypes of quer ies issued: recursive and iterative.
Recur sive quer ies r eceived by a ser ver f or ces t hat ser ver t o f ind t he inf or mat ion
r equest ed or post a message back t o t he quer ier t hat t he inf or mat ion cannot be f ound.
It er at ive quer ies al l ow t he ser ver t o sear ch f or t he inf or mat ion and pass back t he best
inf or mat ion it knows about . This is t he t ype t hat is used bet ween ser ver s. Cl ient s used
t he r ecur sive quer y. This is shown in t he sl ide.
Gener al l y (but not al ways), a ser ver -t o-ser ver quer y is it er at ive and a cl ient -r esol ver -
t o-ser ver quer y is r ecur sive.
You shoul d al so not e t hat a ser ver can be quer ied or it can be t he per son pl acing a
quer y. Ther ef or e, a ser ver cont ains bot h t he ser ver and cl ient f unct ions.
A ser ver can t r ansmit eit her t ype of quer y. If it is handed a r ecur sive quer y f r om a
r emot e sour ce, it must t r ansmit ot her quer ies t o f ind t he specif ied name, or send a
message back t o t he or iginat or of t he quer y t hat t he name coul d not be f ound.
Quer y Funct ion Types

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 232
Example DNS Database
Exampl e DNS Dat abase
Recor ds in t he dat abase incl ude:
Ahost s IP addr ess
PTRhost s domain name, host ident if ied by it s IP addr ess
CNAMEhost s canonical name, host ident if ied by an al ias domain name
MXhost s or domains mail exchanger
NShost s or domains name ser ver (s)
SOAIndicat es aut hor it y f or t he domain
TXTgener ic t ext r ecor d
SRVser vice l ocat ion r ecor d
RPt ext name of t he per son r esponsibl e f or t he domain DNS
A dat abase is made up of r ecor ds and t he DNS is a dat abase. Ther ef or e, common r esour ce
r ecor d t ypes in t he DNS dat abase ar e:
A Host s IP addr ess,
PTR Host s domain name, host ident if ied by it s IP addr ess
CNAME Host s canonical name, host ident if ied by an al ias domain name
MX Host s or domains mail exchanger
NS Host s or domains name ser ver (s)
SOA Indicat es aut hor it y f or t he domain
TXT Gener ic t ext r ecor d
SRV Ser vice l ocat ion r ecor d
RP Responsibl e per son
When a r esol ver s r equest s inf or mat ion f r om t he ser ver , incl uded in t he r equest wil l be
one of t he pr eceding t ypes. In t his way, t he ser ver wil l know exact l y what t he r esol ver
is r equest ing; t his coul d be a mail ser ver , an IP addr ess t r ansl at ion, or simpl y a r equest
f or some gener ic inf or mat ion.
I am not going t o expl ain all t he r ecor ds in t he dat abase, but some of t he mor e usef ul
ones ar e discussed next .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 233
SOA Record
The St ar t of Aut hor it y r ecor d is t he f ir st ent r y in t he dat abase f il e. This r ecor d
indicat es t hat t he name ser ver is t he best -avail abl e sour ce of inf or mat ion f or t his
domain. For exampl e:
Naugl e.com. IN SOA ns1.Naugl e.com Mat t .NT1Ser ver .Naugl e.com.(
1567 ;Ser ial
18000 ;Ref r esh af t er 5
hour s
3600 ;Ret r y af t er 1 hour
604800 ;Expir e af t er 1
week
86400 ;Minimum TTL of 1
day
The numer ic ent r ies above ar e indicat ed in seconds.
Not ice t hat anyt hing f ol l owing a semicol on is ignor ed. The f ir st ent r y on t he f ir st l ine
indicat es t he domain t his ser ver is aut hor it at ive f or : Naugl e.com. The next f iel d
indicat es t he cl ass of dat a in Int er net (ot her t ypes ar e def ined, but not used t oday). The
f ir st name af t er t he SOA indicat es t he pr imar y name ser ver f or t his domain, and t he
f iel d af t er t his indicat es t he per son t o cont act . Repl ace t he f ir st . wit h t he @ symbol
and send an email t her e f or mor e inf or mat ion. The inf or mat ion cont ained in t he
par ent heses is f or t he secondar y name ser ver . For exampl e, t he ser ial number on t he
pr imar y name ser ver shoul d be incr ement ed when new inf or mat ion is pl aced in t he
dat abase. In t his way, t he secondar y ser ver s wil l know t hey have ol d inf or mat ion and
shoul d be updat ed by t his pr imar y.
SOA Recor d
Not ice t hat some domain names ar e wr it t en wit h or wit hout a dot at t he end. The ones
wit h a dot on t he end ar e known as absolute names and t hey specif y a domain name
exact l y as it l ies in t he hier ar chy name space st ar t ing f r om t he r oot . Those names t hat
do not end wit h a dot ar e domain names t hat may t r ail f r om some ot her domain. This is
again, best exempl if ied t hr ough t he dir ect or y syst em. To change dir ect or ies in DOS or
Unix, you use t he CD (CHDIR) command. Wit h t his you can specif y dir ect l y f r om t he r oot
which dir ect or y you woul d l ike t o change t o, or you can change dir ect or ies r el at ive t o
anot her dir ect or y. You do not have t o t ype in t he f ul l dir ect or y pat hname each t ime
you want t o change dir ect or ies.
This is t he same f or DNS using t he dot t o signif y t he f ul l pat hname (wit h t he dot ) and
r el at ive t o anot her pat hname (wit hout t he dot ).

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 234
Name Server Records
Name Ser ver Recor ds
Naugl e.com. IN NS ns0.Naugl e.com.
The next ent r y in our ser ver dat abase is f or name ser ver r esour ce r ecor ds. If you have
f ive name ser ver s in your domain, you shoul d l ist t hem her e.
The pr eceding ent r ies indicat e t hat t her e ar e f ive name ser ver s f or domain Naugl e.com.
Name ser ver s can be mul t ihomed (one st at ion connect ed t o mor e t han one subnet ).

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 235
Address Records
The f ol l owing indicat es t he name-t o-IP-addr ess mappings:
Local host .Naugl e.com. IN A 127.0.0.1
Dat abaseSer ver .Naugl e.com. IN A 128.1.1.1
HRSer ver .Naugl e.com. IN A 128.1.15.1
EngSer ver .Naugl e.com. IN A 128.1.59.150
NS0.Naugl e.com. IN A 128.1.1.2
; Al iases
NT1Ser ver .Naugl e.com IN CNAME DBSer ver .Naugl e.com.
NT2.Naugl e.com IN CNAME HRSer ver .Naugl e.com.
NT3.Naugl e.com IN CNAME EngSer ver .Naugl e.com.
Addr ess Recor ds
Local Host .Naugl e.com. IN A 127.0.0.1
Dat abaseSer ver .Naugl e.com. IN A 128.1.1.1
HRSer ver .Naugl e.com. IN A 128.1.15.1
EngSer ver .Naugl e.com. IN A 128.1.59.150
;Al iases
NT1.Naugl e.com. IN CNAME DBSer ver .Naugl e.com.
NT2.Naugl e.com. IN CNAME HRSer ver .Naugl e.com.
This f il e has new t ypes: A (addr ess) and CNAME (canonical name). The A r ecor d t ype
st ands f or Addr ess (A f or 32-bit addr ess, and AAAA f or IPv6 addr esses). Ther e can be
mor e t han one addr ess f or a name, as in t he case of a mul t ihomed host (a host wit h a
connect ion t o mor e t han one subnet ). This coul d be st at ed as:
;mul t homed host s
NT5.Naugl e.com IN A 128.1.60.5
IN A 128.1.61.5
Name ser ver s wil l r et ur n t he cl osest addr ess t o t he r equest er , depending on t he
r equest er s addr ess. If t hey ar e on t he same net wor k, t he name ser ver wil l pl ace t he
cl osest addr ess f ir st . Since t he DNS has no idea of r out e t abl es, if t he r equest er and it s
net wor k addr ess ar e dif f er ent , it wil l r et ur n bot h addr esses. Wit h each subsequent
addr ess, it wil l r ever se t he IP addr esses in t he r esponse t o pr ovide some bal ance.
Al iases ar e just t hat , a name f or anot her name. When a r equest comes in and t he ser ver
f inds a CNAME r ecor d, it r epl aces t he name wit h t he CNAME. It wil l t hen do anot her
l ookup, f ind t he addr ess, and r et ur n t his t o t he r equest er .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 236
Mail Exchange Records (MX)
One of t he l ar gest uses of t he Int er net is email , and DNS pl ays a major r ol e in t his as
wel l . It does not send or r eceive mail , but it does pr ovide inf or mat ion on t he mail
ser ver s f or a given name. In t he dat abase is a r esour ce r ecor d of MX. DNS uses t his
singl e t ype of r esour ce r ecor d f or mail r out ing. It specif ies a mail exchanger f or a
domain name. This mail exchanger is a host t hat wil l eit her pr ocess t he mail or f or war d
it on. Pr ocessing is simpl y t he t ask of pr oviding f or del iver y t o t he addr essee or
pr oviding a pat h t o anot her mail t r anspor t . It may al so f or war d t he mail t o it s f inal
dest inat ion or pass it on t o anot her mail exchanger in cl oser pr oximit y of t he r ecipient
using SMTP (expl ained next ). An exampl e r ecor d is:
engineer ing.naugl e.com. IN MX 5 mail .naugl e.com.
What t he pr eceding r ecor d st at es is t he mail exchanger f or t he domain
engineer ing.naugl e.com is mail .naugl e.com. The number (5, in t his case) is a pr ecedence
val ue. It can r ange f r om 0 t o 65535. If t her e is onl y one MX f or a domain, t his f iel d is
usel ess. For exampl e:
engineer ing.naugl e.com. IN MX 5 mail 1.naugl e.com.
Mail Exchange Recor ds (MX)
engineer ing.naugl e.com. IN MX 5 mail .naugl e.com.
enginer ing.naugl e.com. IN MX 10 mail 2.naugl e.com.
A mail pr ogr am (such as SMTP) shoul d use t he mail exchanger wit h t he l owest val ue
f ir st . If t his f ail s, t he next one associat ed wit h t hat domain is used. If t her e ar e no
r ecor ds associat ed wit h a domain or host , t he mail must be abl e t o del iver t he message
dir ect l y, and some ver sions of mail sender s have t his capabil it y. The most common mail
t r anspor t out t her e t oday is cal l ed sendmail.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 237
Playing with the Database
Pl aying wit h t he Dat abase
nsl ookup <domain name> <IP Addr ess>
Go t o Web sit e:
://ds/int er nic.net /cool /dns.ht ml
Use t his t o see if a domain name is al r eady assigned!!
Ther e is a pr ogr am avail abl e (not usual l y avail abl e on Windows 95, but is on al l Unix
syst ems) cal l ed nslookup. This is a pr ogr am t hat t r ansmit s quer ies t o a specif ied name
ser ver . If you have t his pr ogr am, you can use it and anot her name ser ver t o suppl y
inf or mat ion t o you.
nsl ookup <domain name such as st ar bur st com.com) 198.49.25.10
Wit h t he pr eceding command and ar gument s you ar e asking a name ser ver whose addr ess
is 198.49.25.10 (t his is one of t he Int er NICs name ser ver s) t o suppl y inf or mat ion about a
domain such as st ar bur st com.com.
If you have access t o t he Web, t hen head up t o t he Int er NIC (US, RIPE f or Eur ope, and
APNIC f or Asia Pacif ic) Point your br owser t o:
ds.int er nic.net /cool /dns.ht ml .
Al l t he r ecor ds f or t he domains t hat it is aut hor it at ive f or (which ar e al l t he t op-
l evel domains: .com, .net , et c.) ar e t her e. Check any inf or mat ion pl us t he ANY r adio
dial but t on and see what comes back.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 238
WHOIS Command
Anot her usef ul ut il it y is WHOIS. This command is incl uded wit h most Unix syst ems, but
f or t hose who do not have access t o t heir Unix syst ems or ar e using Windows, t he
Int er NIC pr ovides t his f unct ion at :
rs.internic.net/cgi-bin/whois
>Whois ascend.com
Ascend Communicat ions, Inc.
ASCEND-DOM
1275 Har bor Bay Pkwy
Al ameda, CA 94502
Domain name: ASCEND.COM
Administ r at ive cont act , t echnical cont act , zone cont act :
Rochon, Lyl e LR88
l r ochon@ASCEND.COM (510) 769-6001
Recor d l ast updat ed on 10-Jul -97.
Recor d cr eat ed on 05-Dec-90.
Dat abase l ast updat ed on 3-Aug-97
04:39:20 EDT.
Domain ser ver s in l ist ed or der :
DRAWBRIDGE.ASCEND.COM
198.4.92.1
NS.UU.NET
WHOIS Command
Enabl es you t o get mor e inf or mat ion on domain names, net wor ks, et c., on t he
Web.
://ds.int er nic.net /cgi-bin/whois.
whois ascend.com (wit hout t he quot es).
Det ail s Ascend.com domain such as:
Administ r at ive cont act (who t o cal l )
Domain ser ver s
Can det er mine IP addr ess bl ocks.
WHOIS net 192.1
BBN Cor por at ion NETBLK-BBN-CNETBLK BBN-NCETBLK 192.1.0.0-
192.1.255.255
Let s say you want ed t o f ind out who owned t he 192.1 Cl ass C bl ock of addr esses. At t he
whois ser ver you woul d t ype in whois net 192.1 and a l ist ing woul d f ol l ow:
BBN Cor por at ion
NETBLK-BBN-CNETBLK BBN-CNET
BLK 192.1.0.0 - 192.1.255.255
Act ual l y, t her e was a l ot mor e inf or mat ion l ist ed but it was t oo much f or t his page. Tr y
it your sel f and see what happens! You can use t he Int er NICs whois ser ver as shown
pr eviousl y or TELNET int o t heir ser ver by t yping Tel net whois.int er nic.net . Af t er you
have a connect ion, t ype in t he command WHOIS and you shoul d get t he WHOIS pr ompt .
Fr om t her e you can check on per son (whois pe r obbins), domain (whois dom
baynet wor ks.com), and net wor k number s (whois net 192.32). Pr et t y cool st uf f and ver y,
ver y open!

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 239
More DNS Information
DNS is avail abl e t hr ough a pr ogr am known as BIND (Ber kel ey Int er net Name Domain,
and not pr onounced BIN-DEE). It is avail abl e on most Unix and Windows NT syst ems. It is
cust omizabl e t hr ough exampl e f il es t hat ar e incl uded. Most impl ement at ions simpl y set
up f or t heir host s and point t o an upst r eam r oot name ser ver f or r ef er ence t o ot her
sit es on t he Int er net .
BIND (DNS) ships wit h most ver sions of Unix, but if f or some r eason it does not , you can
downl oad BIND f r om t he f ol l owing sit e:
www.isc.or g
This sit e al so cont ains inf or mat ion on DHCP and Windows NT por t of BIND (not
suppor t ed).
Ther e ar e many sit es ar ound t he Web t o assist you (f or a smal l char ge) wit h DNS. DNS
can be a daunt ing t ask, especial l y f or l ar ge inst al l at ions. You may want t o consul t
hel p f or your f ir st inst al l . Ot her wise, once you get t he hang of it and r ead a f ew books
on DNS, you wil l see how simpl ist ic it is. One of t he best (and onl y) books about t his is
DNS and BIND by Paul Al bit z and Cr icket Liu (ORiel l y) ISBN 1-56592-236-0.
Mor e DNS Inf or mat ion
2136 PS: P. Vixie, S. Thomson, Y. Rekht er , J. Bound, Dynamic Updat es in t he
Domain Name Syst em (DNS UPDATE), 04/21/97 (26 pages).
2137 PS: D. East l ake, Secur e Domain Name Syst em Dynamic Updat e, 04/21/97
(11 pages) (.t xt f or mat ).
1996 PS: P. Vixie, A Mechanism f or Pr ompt Not if icat ion of Zone Changes (DNS
NOTIFY), 08/28/96 (7 pages) (.t xt f or mat ).
1995 PS: M. Oht a, Incr ement al Zone Tr ansf er in DNS, 08/28/96 (8 pages) (.t xt
f or mat ).
www.isc.or g
DNS and BIND
Book by Paul Al bit z and Cr icket Liu
ISBN 1-56592-236-0

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 240
Simple Mail Transfer Protocol (SMTP)
Today known as El ect r onic Mail , or email .
RFCs 821, 822, 974.
Email st il l cannot t r anspor t packages and ot her it ems.
Email is ver y f ast and guar ant ees del iver y.
Thr ee pr ot ocol s ar e used f or t odays email :
SMTPoper at es over TCP
POPoper at es over TCP
DNSoper at es over UDP
SMTP al l ows f or t he sending/r eceiving of email .
POP al l ows us t o int er mit t ent l y r et r ieve email .
DNS makes it simpl e.
RFC 822 def ines t he st r uct ur e f or t he message, and RFC 821 specif ies t he pr ot ocol t hat
is used t o exchange t he mail bet ween t wo net wor k st at ions. It t r ul y is amazing how ol d
t he or iginal mail pr ot ocol is, and it is st il l in use t oday.
So we have email t o send t o one anot her , compl et el y bypassing t he post al syst em. Ther e
ar e some who cal l t he post al syst em snail mail . Tr ue, if st at ed wit hout emot ion;
ot her wise, I cal l t hese peopl e who st at e t hat ar r ogant . Many peopl e t oday st il l
immensel y enjoy r eceiving a handwr it t en l et t er f r om a f amil y member , f r iend, or a
business cor r espondence t hr ough t he post al syst em. Suf f ice it t o say t hat t he post al
syst em wil l be her e f or many year s t o come.
Al so, I have t he har dest t ime sending packages t hr ough t he email syst em and some I do
get t hr ough (at t achment s) get banged up al ong t he way. Yes, t he post al syst em is ol d
and cr anky, but it wor ks, and in some cases bet t er t han email . But t his is an el ect r onic
discussion and I wil l keep it at t hat . Email does have many, many advant ages and one of
t he t op advant ages is speed. The biggest disadvant age: l ack of emot ion. Like ever yt hing
el se, email has it s pl ace, but it is not 100 per cent of t he pie; it is mer el y anot her f or m of
communicat ion.
In or der t o send and r eceive mail bet ween user s, t her e ar e act ual l y t wo pr ot ocol s
(possibl y t hr ee) t hat ar e used:
SMTP: Used f or t he act ual t r anspor t of mail bet ween t wo ent it ies (mail ser ver s).
POP (Post Of f ice Pr ot ocol ): A pr ot ocol t hat al l ows singl e user s t o col l ect
t heir mail on one ser ver .
DNS: Used t o ident if y t he mail host s f or a domain or host name.
Mail can be sent and r eceived using onl y SMTP, but t he ot her pr ot ocol invol vement
makes it much easier t o use and is mor e ef f icient . This sect ion wil l concent r at e on SMTP
and POP. The hooks int o DNS wer e al r eady expl ained in t he Mail Exchanger sect ion of
DNS and ar e shown again on sl ide 264. SMTP was cr eat ed f ir st and t hen POP, so I wil l
st ar t wit h t he SMTP pr ot ocol . This is a pr ot ocol t hat al l ows user s t o t r ansmit messages
(mail ) bet ween ot her user s. It is one of t he most widel y used appl icat ions of t he TCP/IP
pr ot ocol .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 241
SMTP Functions
The pr ot ocol is r el at ivel y simpl e. A message wil l be cr eat ed, pr oper l y addr essed, and
sent f r om a l ocal appl icat ion t o t he SMTP appl icat ion, which wil l st or e t he message.
The ser ver wil l t hen check (at per iodic int er val s) t o see if t her e ar e any messages t o
del iver . If t her e ar e, t he mail ser ver wil l t r y t o del iver t he message. If t he int ended
r ecipient is not avail abl e at t he t ime of del iver y, t he mail ser ver wil l t r y again l at er .
The mail ser ver wil l t r y a f ew t imes t o del iver t he message and, if it cannot , wil l eit her
del et e t he message or r et ur n it t o t he sender .
The addr ess has t he gener al f or mat of l ocal -par t @domain-name. By t his, you shoul d
r ecognize t he domain name f or mat . For exampl e, an addr ess at t he SMTP header coul d
be mat t @engineer ing.naugl e.com. This woul d indicat e t hat t he message is addr essed t o a
user named Mat t in t he domain of engineer ing.naugl e.com. When DNS is used t o l ook up
t he mail handl er f or Mat t , it wil l have some sor t of ent r y l ike:
engineer ing.naugl e.co IN MX 10
NT1mail _ser ver .engineer ing.naugl e.com.
Fr om t his, t he name wil l be l ooked up and t he mail wil l be del iver ed t o t hat host .
Ther e ar e t wo ent it ies t o t his syst em, t he sender SMTP and t he receiver SMTP, t hat ar e
used t o t r anspor t mail bet ween t wo syst ems. The sender SMTP wil l est abl ish
communicat ions wit h a r eceiver SMTP. At t achment s ar e al l owed wit h Int er net email
but not dir ect l y wit h t he pr ot ocol used in SMTP (sendmail pr ot ocol ). The Int er net
email mail er pr ogr am
SMTP Funct ions
A message is cr eat ed, pr oper l y addr essed, and t r ansmit t ed using SMTP sender ,
which t r ansmit s it t o an SMTP r eceiver , which st or es t he f il e.
Addr ess has t he f or mat of :
l ocal -par t @domain-name
Exampl e: mat t @naugl e.com
Mail ser vice r ecor d in DNS:
naugl e.com IN MX 10 NT1mail _ser ver .eng.naugl e.com
SMTP was set up t o handl e onl y t ext .
Based on t he hist or y of t he pr ot ocol
Email appl icat ions conver t using a var iet y of pr ot ocol s l ike MIME
(Mul t ipur pose Int er net Mail Ext ensions).
SMTP (or mor e specif ic, sendmail ) can onl y handl e t ext . Ther ef or e, most email
appl icat ions conver t an at t achment t o t ext bef or e sending. A common t ype is MIME
(Mul t ipur pose Int er net Mail Ext ensions, beyond t he scope of t his book). At t he r eceiver ,
t he email appl icat ion conver t s t he at t achment back t o it s or iginal f or mat .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 242
SMTP Flow
The SMTP design is based on t he f ol l owing model of communicat ion:
Once you have f il l ed out t he header and body sect ion of your mail message, t he sender
SMTP est abl ishes t wo-way communicat ion t o a r eceiver SMTP. The r eceiver SMTP may be
eit her t he ul t imat e dest inat ion or a t r ansient st op on t he way t o t he f inal dest inat ion.
Commands ar e sent t o t he r eceiver by t he sender SMTP and SMTP r epl ies ar e sent f r om
t he r eceiver SMTP t o t he sender SMTP in r esponse t o each of t he commands.
Once t wo-way communicat ion has been est abl ished, a ser ies of commands (of which you
can see oper at e using some mail appl icat ions) ar e issued. The sender SMTP wil l send a
HELLO (HELO) command ident if ying who it is using it s domain name t o t he r eceiver . The
r eceiver acknowl edges t his wit h a r epl y using it s domain name. Next , t he ser ver issues a
MAIL command t o t he r eceiver . In t his wil l be t he ident if icat ion of t he per son (pl ace, or
t hing) sending t he mail . The r eceiver acknowl edges t his wit h an OK. The sender SMTP
t hen sends a RCPT command t o t he r eceiver , using t he int ended r eceiver name as an
ar gument . Each r ecipient in t he l ist is sent t o t he r eceiver one at a t ime, and each t ime
t he r eceiver acknowl edges wit h an OK f or t hose r ecipient s t hat it knows about . For
t hose t hat it does not know about (dif f er ent domain name), it wil l send back a dif f er ent
r epl y t hat it is f or war ding t he message on. For any int ended r ecipient s r eceived f r om
t he SMTP sender f or which it has no account , t he r eceiver wil l r epl y t o t he sender t hat
no such user (s) exist s. Af t er t he int ended r ecipient s have been ACKd or NACKd, t he
SMTP sender sends t he DATA command and t he SMTP r eceiver wil l OK t his and indicat e
what t he end of message ident if ier shoul d be. Once t his is r eceived (t he ending
ident if ier ), t he SMTP r eceiver wil l r epl y wit h an OK. Not ice t hat al l dat a is r eceived,
t he ending ident if ier is r eceived, and t hen a r epl y message is sent by t he r eceiver .
SMTP Fl ow
If ever yt hing went okay, t he sender ends t he connect ion wit h a QUIT command. The
SMTP r eceiver wil l r epl y indicat ing t hat t he communicat ion channel is cl osed. The
minimum commands t hat a r eceiver must suppor t ar e HELO, MAIL, RCPT, DATA, RSET,
NOOP, and QUIT.
Depending on t he mail pr ogr am t hat you use, t he t r ansact ion bet ween a r ecipient and
sender of mail has been t he same since RFC 821 was wr it t en. The int er f ace al l ows you t o
compl et e t he mail message, f il l ing in t he header (addr esses and subject ) and t he body
(t ext ) of t he l et t er . When you pr ess t he Send but t on, t he f ol l owing t r ansact ion t akes
pl ace. Some mail pr ogr ams act ual l y pl ace t he mail commands and st at e number s on
displ ay whil e t he t r ansact ion is t aking pl ace. It shoul d be not ed her e t hat sending mail
is immediat e. It may get queued f or a smal l l engt h of t ime on dif f er ent r out er s, and
t r ansient mail ser ver s, but not f or l ong. This is f or t he t r anspor t of mail . Most
el ect r onic mail t oday is sent via SMTP and wil l r eside on your mail ser ver host unt il
you r et r ieve it using POP (discussed next ). Today, r et r ieving your mail does not mean
t hat you have t o r un t he SMTP pr ot ocol . A ser ver host wil l accept mail messages
dir ect ed t o you on your behal f . Then you can sign on any t ime you want and r et r ieve
your mail .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 243
DNS Interaction for Mail
The f ol l owing sl ide shows t he int er act ion wit h DNS f or t he mail ser vice.
A r ecor d known as t he MX r ecor d in DNS ident if ies a mail exchanger f or t he pur pose of
ident if ying host s f or r ecipient s. A mail exchanger is a host t hat wil l eit her pr ocess or
f or war d mail f or t he domain name. Pr ocessing means t hat t he host wil l del iver it t he
host t o which it is addr essed or hand it of f t o anot her t r anspor t , such as UUCP or
BITNET. For war ding means t hat t he host wil l f or war d t he message on t o t he f inal
dest inat ion or t o anot her mail exchanger cl oser t o t he dest inat ion.
Ther e can be mul t ipl e ent r ies f or a mail exchanger in a DNS. Each MX ent r y wil l have a
pr ecedence number beside it and t his signal s t he sender which mail host it shoul d t r y
f ir st . If t he pr ecedence val ue is equal among MX r ecor ds, t hen t he sender wil l
r andoml y pick one f r om t he l ist . Once t he mail sender has successf ul l y del iver ed t he
mail t o one of t he MX host s, it s job is done. It is t he job of t he MX host t o make sur e it is
f or war ded on t o it s f inal dest inat ion. If t her e ar e no MX r ecor ds f or a domain name, it
is up t o t he mail er app as t o what happens next . Some wil l t r y t o del iver it t o t he IP
addr ess of t he mail dest inat ion.
DNS Int er act ion f or Mail

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 244
Post Office Protocol (POP)
The or iginal mail pr ogr am RFC 821 (which is t he one in use t oday) was set up t o send
messages dir ect l y t o a user l ogged in t o a t er minal , as wel l as st or e t hese messages t o a
mail box. The commands al l owed f or t he r eceiver t o det er mine if t he user was l ogged on
t o a t er minal (not a PC), if t hey wer e accept ing messages, and if t hey wer e not , is t her e a
mail box t o del iver some mail t o. Ther e wer e no message at t achment s and messages wer e
sent and r eceived in 7-bit ASCII (8t h bit was set t o 0); t her ef or e, t his woul d not al l ow
f or binar y messages t o be sent (i.e., no at t achment s). In f act , t he or iginal message was
not t o exceed 1000 char act er s (however , impl ement at ions t hat coul d go beyond t his
bar r ier wer e st r ongl y encour aged t o do so).
So, t o oper at e mail , t he host must be oper at ional (abl e t o r eceive) al l t he t ime. Today,
t er minal s do exist , but mor e commonl y, per sonal comput er s have t aken t heir pl ace.
Ther ef or e, t he f inal r ecipient wil l be t he per sonal comput er . The per sonal comput er
wil l have bot h SMTP and POP. Even t hough a per sonal comput er wil l r et r ieve it s mail
via POP, it wil l st il l use t he SMTP f unct ions t o send it s mail . Since SMTP expect s t o be
abl e t o del iver mail immediat el y, t his woul d mean t hat al l user s woul d have t o have
t heir per sonal comput er s on 100 per cent of t he t ime in or der t o accept mail . Second, t o
r eceive and r ead your mail , you must l og on t o a specif ic host .
To oper at e a mail ser ver gener al l y r equir es t hat t he mail ser ver is avail abl e f or a
major it y of t he t ime, has t he abil it y t o st or e many mail messages, and is abl e t o f ul l y
r un SMTP and accept mail f r om an SMTP sender . Whil e t his may have been f easibl e f or
sit uat ions l ike t er minal -t o-host connect ivit y, it is not f easibl e f or sit uat ions t hat we
have t oday; namel y, per sonal comput er s and mobil e wor ker s. SMTP is a ver y r obust
t r ansact ion-or ient ed pr ot ocol and r equir es t he st at ement s pr eviousl y discussed t o
oper at e f ul l y.
SMTP is set up t o send and r eceive mail by host s t hat ar e up f ul l t ime.
No r ul es f or t hose host s t hat ar e int er mit t ent on t he LAN
POP emul at es you as a host on t he net wor k.
It r eceives SMTP mail f or you t o r et r ieve l at er
POP account s ar e set up f or you by an ISP or your company.
POP r et r ieves your mail and downl oads it t o your per sonal comput er when
you sign on t o your POP account .
What we need is t he abil it y f or SMTP t o oper at e (dr op of f t he mail , l ike a PO Box at t he
post of f ice), and t hen anot her pr ot ocol t o downl oad t o our per sonal comput er s (we
dr op by t he post of f ice and r et r ieve our mail f r om t he post of f ice box.). POP is t he
pr ot ocol t o al l ow f or t his. Mail can be del iver ed t o a dr op-of f point and POP al l ows us
t o l og in and r et r ieve our mail .
When you sign up wit h an Int er net Ser vice Pr ovider , a POP account is assigned t o you;
f or exampl e, mnaugl e@POP3.ISP1.com. You use t his when conf igur ing your mail pr ogr am.
Al so, when sending mail you must give t he SMTP ser ver name t o t he conf igur at ion
pr ogr am as wel l . The pr ot ocol of POP3 is not used f or sending mail .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 245
POP Operation
POP3 shoul d be viewed onl y t o retrieve your mail f r om t he mail dr op-of f point . Sending
mail is a dif f er ent st or y. Your per sonal comput er st il l has t he abil it y t o est abl ish a TCP
connect ion t o a r el ay host (int er mediat e mail host ) t o send mail . Ther ef or e, you shoul d
consider your host as having t he abil it y t o be an SMTP sender , and t he SMTP pr ot ocol
expl ained ear l ier appl ies. However , t o r et r ieve your mail , POP3 comes int o pl ay.
The cl ient (your PC wit h a mail appl icat ion such as Eudor a), once est abl ished wit h
TCP/IP on it s net wor k, buil ds a connect ion t o t he POP3 ser ver . The POP3 ser ver
conf igur at ion is buil t dur ing t he inst al l at ion of your mail pr ogr am on t he PC. The
connect ion bet ween your PC and t he POP3 ser ver is a TCP connect ion on TCP por t 110.
Simil ar t o SMTP, once t he connect ion is est abl ished, t he ser ver wil l r espond wit h a
gr eet ing l ike POP3 ser ver r eady.
The POP3 pr ot ocol t hen ent er s t he aut hent icat ion st at e. Dur ing t his phase, you must
ident if y your sel f wit h a user name and passwor d. The RFC does not indicat e which
aut hent icat ion mechanism you shoul d use. The most common is t he simpl e
user name/passwor d combinat ion. However , ot her opt ions ar e avail abl e, such as Ker ber os
and APOP, which ar e beyond t he scope of t his book. Once you have been
aut hent icat ed, t he POP3 ser ver put s an excl usive l ock on your mail box, ensur ing t hat
no ot her t r ansact ions t ake pl ace on t he messages whil e you ar e r et r ieving your mail .
The ser ver now ent er s t he t r ansact ion st at e in which each of t he messages in your
mail box is assigned a number . This al l ows your cl ient POP t o indicat e how many messages
ar e in your mail box. Each message can be r et r ieved one at a t ime or al l can be r et r ieved.
Fur t her mor e, you can inst r uct your cl ient POP t o del et e messages as t hey ar e
r et r ieved. This can be good and bad. It woul d be nice t o hol d on t o your messages as a
backup on t he ser ver , but t his r equir es disk space t hat can be depl et ed quickl y.
Fr om her e, you r et r ieve your messages and, depending on how you conf igur ed you PC
mail pr ogr am, t he messages ar e mar ked f or del et ion af t er your session. Af t er you
r et r ieve your messages, your mail pr ogr am wil l send t he QUIT command, which cl oses
t he POP3 session down. Then t he UPDATE pr ocess begins on t he ser ver , which is
housekeeping wor k on t he ser ver (del et ing messages, et c.).
Fr om her e, you can r ead your messages l ocal l y on your PC. You ar e now disconnect ed
f r om t he POP3 ser ver and you can manipul at e t he messages l ocal l y. Ther e ar e many
ot her opt ions avail abl e f or POP3 which may or may not be impl ement ed; however , f r om a
user s point of view, t hey ar e not not iced.
POP Oper at ion

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 246
SMTP, DNS, and POP Topology
The f ol l owing sl ide shows t he r el at ionship bet ween SMTP, DNS, and POP. In t his
exampl e, mail is sent f r om your PC t o Joes PC. In or der t o accompl ish t his, t he send mail
(SMTP) pr ogr am is est abl ished t o t he SMTP ser ver on your ISP. A DNS l ookup is
accompl ished using t he r oot DNS ser ver t o f ind t he domain of t he int ended r ecipient . A
cal l is made t o r ecipient s DNS t o f ind t he mail ser ver (which coul d be t he same ser ver as
t he DNS). Once t he mail ser ver is f ound (it s IP addr ess is f ound), mail is sent t o t hat
ser ver . The POP f unct ion del iver s it t o your mail box on t hat mail ser ver so t hat when
Joes PC r et r ieves mail , your mail message wil l be wait ing.
SMTP, DNS, and POP Topol ogy

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Part Five
I P Multicast
Chapter 247
Introduction
Wit h addr essing, as I have ment ioned bef or e, t her e ar e t hr ee t ypes wit h IPv4: point -t o-
point (unicast ), point -t o-mul t ipoint (mul t icast ), and point -t o-al l -mul t ipoint s
(br oadcast ). But mul t icast as it per t ains t o IP is much mor e t han a simpl e addr ess; it s
what enabl es IP t o del iver mul t imedia over a packet swit ched net wor k wit h ver y l it t l e
bandwidt h consumpt ion (r el at ive t o pushing t he dat a t o t he same r ecipient s using
unicast ).
You wil l of t en hear t he pseudo-t echnical t er m push or pull t echnol ogy. This means you
have t o go and get t he inf or mat ion of f t he Int er net (pul l ), or t he inf or mat ion comes t o
you (push). Ther e is a vast ar r ay of inf or mat ion in t he Int er net and f inding it can be a
daunt ing t ask. Push t echnol ogy means t hat inf or mat ion is sent t o you. An exampl e of
t his can be an inf or mat ion news ser vice t hat r et r ieves inf or mat ion on cer t ain subject s
t hr oughout t he day. A l ot of r eader s have pr obabl y hear d of Point Cast . This is an
exampl e of a pseudo-push t echnol ogy t hat wil l event ual l y be a f ul l -bl own push
t echnol ogy. Whenever inf or mat ion changes on t hat news ser ver , st or ies r el at ed t o
your r equest s ar e pushed down t o your wor kst at ion, saving you t he t r oubl e of f inding
and downl oading t he inf or mat ion.
Anot her excit ing evol ut ion is t he abil it y t o have voice and video r un over an IP
net wor k. I know, it can be accompl ished t oday, but I am not f ond of viewing a 2" 2"
f uzzy scr een t hat has incr edibl e del ay and non-l ip sync audio. It is l ike wat ching an ol d
Japanese movie t hat has been conver t ed t o Engl ish. Fr ame r ecept ion at 5 f ps is not gr eat .
It is f un t o exper iment , but unt il it appear s l ike CATV (cabl e TV), user s wil l not
consider it as a ser ious r equir ement f or t he LAN inf r ast r uct ur e.
Int r oduct ion
Anot her advancement on t he Int er net is voice and video over IP. Repl icat ing a separ at e
st r eam of dat a f or ever y user r equest t o a singl e video sour ce woul d easil y over l oad
t he Int er net . The abil it y t o t r ansmit one packet and have it r epl icat ed at cer t ain point s
al ong t he many pat hs t o separ at e dest inat ions is a much mor e ef f icient syst em of
dist r ibut ing dat a, voice, and video. Mul t icast ing al l ows t his as wel l .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 248
Multicast Components
Ther e ar e f our component s t o a mul t icast net wor k: mul t icast -enabl ed host NIC,
mul t icast -enabl ed TCP/IP sof t war e, mul t icast -enabl ed inf r ast r uct ur e (r out er s,
swit ches, et c.), and mul t icast -enabl ed appl icat ions.
Do not conf use t he oper at ion of IP mul t icast as a st andal one appl icat ion. This oper at es
on t he ver y same wor kst at ion t hat you ar e using t oday t o access IP appl icat ions and/or
t he Int er net . IP mul t icast peacef ul l y coexist s wit h your IP appl icat ions.
IP mul t icast usual l y does not oper at e al one; t her e ar e ot her pr ot ocol s t hat ar e used in
conjunct ion wit h it t o pr ovide f or VVD (voice, video, and dat a) over IP. Such pr ot ocol s
ar e Real Time Pr ot ocol (RTP) and t he Real Time Cont r ol Pr ot ocol (RTCP), Real Time
St r eaming Pr ot ocol (RTSP), and Resour ce Reser vat ion Pr ot ocol (RSVP). Simil ar t o t his is
IP. Ther e ar e many component s t o t he TCP/IP net wor k and IP is simpl y one of t he
component s. It pr ovides f or dat agr am del iver y. IP mul t icast is al so a component of many.
IP mul t icast is based on a f ew pr ot ocol s, but it is al l t he ot her necessar y component s
t hat r eal l y make it wor k.
Ber kel ey Socket s f or Mul t icast pr ovides an API set t hat easil y enabl es most Unix host s
t o become mul t icast r eady, and Micr osof t is suppor t ing mul t icast in it s socket s int er f ace
known as WinSock 2.0. Wit h t he APIs in pl ace, mul t icast appl icat ions can be buil t .
Mul t icast Component s

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 249
Multicast Caveats
Mul t icast Caveat s
Mul t icast is not simpl y a t ur n it on and it wor ks pr ot ocol .
Much t hought must go int o impl ement ing a mul t icast net wor k
Ther e ar e many pr ot ocol s t hat r un wit h mul t icast .
Mul t icast r equir es as much t hought t o impl ement as OSPF.
Many dif f er ent t ypes of pr ot ocol s can be impl ement ed and some ar e st il l
exper iment al
WAN net wor ks as wel l as LANs must be consider ed.
Fr ame r el ay is st il l onl y par t ial l y mul t icast r eady
The Int er net is not mul t icast r eady
Ther e is a l ear ning cur ve wit h mul t icast .
Mul t icast t r ansmission and r ecept ion can t ake pl ace anywher e it is enabl ed. Ther e ar e,
however , a f ew obst r uct ions in t he pat h t o widespr ead impl ement at ion of mul t icast :
r out er s and swit ches must be mul t icast r eady; t he backbone of your int er net must be
mul t icast r eady; t he WAN must be mul t icast r eady; and so on and so on. Add t o t his t he
gener al l ack of knowl edge and ampl e st udies on t he ef f ect s of mul t icast and you
shoul d be abl e t o see why impl ement at ion is sl ow. The Unicast f or war ding Int er net
cur r ent l y pl ays a par t in mul t icast , but onl y as a t r anspor t bet ween mul t icast -enabl ed
net wor ks. Tunnel s can be buil t acr oss t he Int er net using t he l oose sour ce r out ing
f eat ur e of IP. In t his way, t wo isl ands of mul t icast can be connect ed t oget her t o
pr ovide connect ivit y. Ot her wise, t he Int er net (at t he t ime of t his wr it ing) is not
mul t icast -enabl ed and pr obabl y wont be f or some year s t o come.
Many cor por at e net wor ks have moved t o f r ame r el ay as t heir WAN pr ot ocol , which
consist s of t he cust omer device (cal l ed t he CPE f or cust omer pr emise equipment , usual l y
a r out er ) and t he f r ame r el ay pr ovider s equipment (f r ame r el ay swit ches). Making t he
f r ame r el ay cl oud mul t icast r eady, however , is not t hat easy. Ther e ar e many st udies
and t est s t hat have t o be per f or med t o see how mul t icast r eact s t o an exist ing net wor k
t hat has many cust omer s al r eady enabl ed who expect 99.999 per cent upt ime. The f r ame
r el ay pr ovider s wil l mul t icast -enabl e t heir WAN net wor ks, but it may not happen f or a
whil e.
Cor por at e net wor ks ar e not mul t icast -enabl ed eit her . These envir onment s have just
r edone t heir t opol ogies t o al l ow f or ATM and LAN swit ches t o be empl oyed and ar e
now l ooking at mul t icast . Most cor por at e envir onment s do not even r eal ize t hat t heir
r out er s ar e mul t icast -r eady and bel ieve t hat new equipment must be pur chased bef or e
mul t icast is enabl ed. Al l r out er s suppor t t he mul t icast pr ot ocol of IGMP. Most r out er s
suppor t t he mul t icast r out ing pr act ice of DMVRP, PIM, and a f ew suppor t MOSPF. These
wil l be discussed in det ail l at er but suf f ice it t o say, t hese ar e sof t war e f eat ur es t hat
can be t ur ned on, but ver y car ef ul l y. Mul t icast may be an ext ension of t he IP pr ot ocol ,
but r out ing mul t icast packet s is a dif f er ent st or y.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 250
Unicast (versus Multicast)
For exampl e, l et s say t hat t he end of t he mont h sal es r epor t is compl et e and needs t o
be t r ansmit t ed t o 200 f il e ser ver s ar ound t he count r y. Wit h unicast addr essing, one
coul d wr it e a simpl e scr ipt t hat woul d init iat e a f il e t r ansf er t o each of t he 200 f il e
ser ver s. If t he f il e is 2 MB in l engt h, you now have a 400 MB f il e t r ansf er t hat wil l
unnecessar il y consume bot h t ime and bandwidt h.
Enabl ing mul t icast woul d push t hat one f il e t o t he 200 f il e ser ver s simul t aneousl y,
r educing t he number of f il e t r ansf er s f r om 200 t o 1, and t he size of t he f il e f r om 400 MB
t o 2 MB.
One exampl e in which mul t icast f il e t r ansf er is used ext ensivel y is sof t war e
dist r ibut ion. Micr osof t and ot her appl icat ion companies upgr ade t heir sof t war e at l east
t wice a year a daunt ing t ask in l ar ge envir onment s. If t he upgr ade is 20 MB and must
be dist r ibut ed t o 50,000 deskt ops, it woul d r equir e 1000 bil l ion byt es t o be del iver ed.
Assuming t he t r ansf er occur s at 512,000 bit s per second, t he upgr ade woul d t ake 180
days t o compl et e. And just when you compl et ed one upgr ade, t he next one is r eady.
However , using r el iabl e mul t icast ing, t he f il e coul d be del iver ed t o 50,000 deskt ops as a
singl e st r eam. This means one t r ansf er l ooks l ike 50,000. Wit h mul t icast , t he same
t r ansmission woul d compl et e in 5.2 hour s. (This number assumes no r eal -t ime er r or s such
as r et r ansmissions. Ret r ansmission cost s ar e var iabl e depending on t he number of cl ient s
r equest ing, t he st at us of t he l ines, et c.) Even so, t he wor st cost is l ess t han 25 per cent
of t he or iginal pass. The exampl e is t heor y, but if put int o pr act ice I bel ieve t hat it
woul d be ar ound t he number indicat ed. Even if it t ook 10 hour s t o compl et e, l ook at t he
al t er nat ive.
Unicast (Ver sus Mul t icast )
Ther ef or e, t he advant ages t o mul t icast -enabl ed appl icat ions and net wor ks ar e t ime
savings and scal eabl e bandwidt h.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 251
Multicast (versus Unicast)
As not ed f r om t he sl ide, mul t icast is one st r eam of packet s t hat is hear d by many
r eceiver s al l using t he same IP mul t icast addr ess as t heir r eceiving IP int er f ace. IP
mul t icast pl aces t he bur den of packet r epl icat ion on t he net wor k via t he IP mul t icast
addr ess and r out er s t hat ar e abl e t o f or war d r eceived mul t icast packet s t o mor e t han
one por t .
Mul t icast (ver sus Unicast )

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 252
Multicasting Type
Ther e ar e t wo t ypes of dat a t r ansmission nor mal l y associat ed wit h mul t icast ing: real-
time and nonreal-time.
Real -t ime t r ansmission is t he abil it y t o wor k wit h t he inf or mat ion whil e it is being
t r ansmit t ed. Two exampl es of t his ar e video and voice t r ansmissions. Nonr eal -t ime
t r ansmission is t he abil it y t o t r ansf er t he inf or mat ion f or use at a l at er t ime, dir ect l y
af t er t he t r ansf er or days l at er . Exampl es incl ude CBT f il es, kiosk, or any t ype of dat a
f il e. Bot h t ypes of t r ansmission have t heir pur poses in t he mul t icast ar ena. However ,
nonr eal -t ime t r ans missions ar e mor e appl icabl e t oday because t heir use is not immediat e.
Mul t icast ing Types
Two t ypes of dat a mul t icast ing:
Real -t ime and nonr eal -t ime
Real -t ime t r ansf er s ar e t hose t hat ar e used as t he t r ansf er is occur r ing.
Exampl es incl ude voice and video such as voice over IP, movies, video
conf er encing, et c.
Nonr eal -t ime ar e t hose t r ansf er s t hat ar e mul t icast but t he dat a is used at a
l at er t ime.
Kiosk, CBI, st or e-and-f or war d video
Real -t ime t r ansf er s such as video and voice ar e st il l in t he exper iment al st age.
Tr ansf er r ing inf or mat ion acr oss a net wor k t hat is packet swit ched wit hout some
capabil it y f or pr ior it y is exper iment al . In some envir onment s, it wor ks r at her wel l (on a
singl e subnet ), but when t r anspor t ed acr oss an int er net , t he qual it y det er ior at es and
t her ef or e t he int er est in t he pr oduct s wanes. Ther e ar e pr ot ocol s t hat ar e
exper iment al (RSVP) t hat shoul d assist r eal -t ime mul t icast pr ot ocol s by pr oviding
bandwidt h t o t he appl icat ion inst ead of t o t he net wor k.
Some r eal -t ime mul t icast t r ansf er s use a simpl ex appr oach t hat makes it r eal near
r eal -t imet hey buf f er t he incoming dat a f or about 30 seconds and st ar t t he pl ay.
Whil e t he inf or mat ion is being used, t he appl icat ion cont inues t o buf f er t he incoming
dat a f or pl ayback. Not per f ect , but it s bet t er t han not hing.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 253
Addressing Type Review
Addr essing Type Review
IPv4 has t hr ee addr ess t ypes:
Unicast : A one-t o-one IP t r ansf er
Br oadcast : A one-t o-al l IP t r ansf er
Mul t icast : A one-t o-many-but -not -al l t r ansf er
The exampl e given in t he pr eceding sect ion is simpl e, but ver y r eal . However , t her e ar e
many appl icat ions t oday t hat r equir e a one-t o-many or many-t o-many t ype of
t r ansmission and r ecept ion (e.g., audio and video, st ock t icker , wor kgr oup appl icat ions,
el ect r onic whit eboar ds, et c.). Al l of t hese appl icat ions can have one or mor e sender s
and one or mor e r eceiver s. In IPv4, t her e ar e t hr ee t ypes of addr esses:
Unicast : A unique addr ess t hat al l ows one host t o r eceive a dat agr am.
Br oadcast : An addr ess t hat al l ows ever y host t o r eceive a dat agr am.
Mul t icast : An addr ess t hat al l ows a specif ic gr oup t o r eceive a dat agr am.
Unicast is t he abil it y t o uniquel y ident if y a host on a subnet or int er net . The
t r ansmission and r ecept ion is accompl ished in a one-t o-one r el at ionship. A br oadcast
addr ess is exact l y t hat : An addr ess t hat is r eceived by ever y host on t he subnet . Rout er s
(wit h except ions l ike DHCP and BOOTP) wil l not f or war d dat agr ams t hat have a l ocal
br oadcast addr ess. A mul t icast addr ess is one t hat al l ows a specif ic gr oup of host s t o
r eceive a dat agr am, whil e al l ot her s ignor e t he dat agr am. For t his conver sat ion, we
wil l st ay wit h mul t icast ing as it appl ies t o t he IP pr ot ocol .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 254
Introduction to IP Multicast
Accor ding t o RFC 1112, Host Ext ensions f or IP Mul t icast ing, t he f ol l owing is t he
descr ipt ion of IP mul t icast ing:
IP multicasting is the transmission of an IP datagram to a host group, a set of zero or more
hosts identified by a single IP destination address. A multicast datagram is delivered to all
members of its destination host group with the same best-effort reliability as regular unicast
IP datagrams; i.e., the datagram is not guaranteed to arrive intact at all members of the
destination group or in the same order relative to other datagrams.
The membership of a host group is dynamic; that is, hosts may join and leave groups at any
time. There is no restriction on the location or number of members in a host group. A host may
be a member of more than one group at a time. A host need not be a member of a group to
send datagrams to it.
As you l ear n mor e about IP mul t icast ing, you wil l r eal ize, t hat t his pr ot ocol is simpl y
an ext ension of t he IP pr ot ocol it sel f . It does not r epl ace t he IP pr ot ocol and, in f act , it
adds a f ew f unct ions t o t he IP pr ot ocol t o al l ow a host t o send and r eceive mul t icast
dat agr ams. This is simil ar t o t he way ICMP wor ks wit h IP.
Int r oduct ion t o IP Mul t icast
RFC 1112.
IP mul t icast is t he t r ansmission of an IP dat agr am t o a host gr oup, a set of
zer o or mor e host s ident if ied by a singl e IP dest inat ion addr ess.
Member ship is dynamic; host s may join and l eave at any t ime.
No r est r ict ion on t he l ocat ion or t he number of member s in a gr oup.
A host need not be a member of a gr oup t o send dat agr ams t o it .
IP mul t icast is not a separ at e pr ot ocol , but an ext ension of t he IP pr ot ocol .
A host can pr ovide t hr ee l evel s of suppor t :
No suppor t , send onl y, and send/r eceive
Ther e ar e t hr ee l evel s associat ed wit h mul t icast :
Level 0: No suppor t f or mul t icast .
Level 1: The abil it y t o send mul t icast but not r eceive.
Level 2: The abil it y t o bot h send and r eceive mul t icast packet s.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 255
Extensions to the IP Service Interface
The nor mal IP t r ansmission l ogic is as simpl e as:
If the IP destination is on the same local network, send the datagram locally directly to the
destination. If not, send the datagram locally to a router.
Since mul t icast ing is not hing mor e t han an ext ension of t he IP pr ot ocol , t he l ogic is
simpl y expanded:
If the IP destination is on the same local network or if it is a host group, send the datagram
directly to the destination. If neither, send the datagram locally to a router.
Not ice t hat t he mul t icast host does not specif ical l y l ook f or a r out er , even t hough
member s of t he host gr oup may be mul t ipl e hops away. Mul t icast dat agr ams ar e not
addr essed t o a r out er , but mul t icast dat agr ams can be r eached t hr ough an
int er net t hey do not have t o r emain l ocal . Mul t icast dat agr ams t hat span subnet s
r equir e r out er s and t hese r out er s must be r unning a special mul t icast ing pr ot ocol (a
f ew of which wil l be expl ained next . When a host t r ansmit s a mul t icast packet , it simpl y
t r ansmit s t he packet out it s int er f ace using t he nor mal IP dat agr am t r ansmission
(shown). In t his way, al l t he host s t hat bel ong t o t he same gr oup on t he l ocal net wor k
r eceive and pr ocess t his dat agr am. If t he TTL f iel d (known as t he scope ) is gr eat er t han
1, t he mul t icast r out er s r eceive and f or war d t his packet out t heir int er f aces t owar ds
al l ot her net wor ks t hat bel ong t o t hat gr oup. (How t he r out er det er mines which
int er f aces bel ong t o t hat gr oup is discussed in t he sect ion, DVMRP.) Ther ef or e, t he
r out er is al so a member of t he host gr oup. The r eceiving r out er decr ement s t he TTL and
f or war ds t he packet as a l ocal mul t icast on it s net wor ks t hat ar e par t icipat ing in t hat
gr oup.
In mul t icast ing, a r out er is consider ed par t of t he gr oup as wel l as individual host s.
Ext ensions t o t he IP Ser vice Int er f ace
An addit ion t o t he IP int er f ace f or sending dat agr ams is simpl y l ooking t o see
if t he dest inat ion is a host gr oup.
If it is, t hen f or war d t he dat agr am t o t he host gr oup int er f aces
The r out er is a member of t he mul t icast gr oup.
A r out er is simpl y anot her mul t icast int er f ace (a host ).
The r out er is used t o simpl y make a det er minat ion if it shoul d f or war d t he
packet based on t he gr oup addr ess and not t he net wor k addr ess.
A f iel d in t he dat agr am packet det er mines how f ar t he packet shoul d be
f or war ded.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 256
Receiving Multicast Datagrams
Receiving Mul t icast Dat agr ams
Dat agr ams ar e r eceived l ike unicast dat agr ams wit h t he except ion t hat a host
must join a gr oup bef or e it can r eceive mul t icast dat agr ams.
The IP Ser vice Int er f ace was ext ended t o incl ude t wo new oper at ions:
JoinHost Gr oup (gr oup-addr ess, int er f ace)
LeaveHost Gr oup (gr oup-addr ess, int er f ace)
The r eceiver must join each mul t icast gr oup f r om which it wishes t o r eceive
mul t icast dat agr ams.
When t he st at ion no l onger want s t o r eceive mul t icast dat agr ams f or a
gr oup, it issues t he LeaveHost Gr oup.
Mul t icast IP dat agr ams ar e r eceived using t he same Receive IP oper at ion as nor mal ,
unicast dat agr ams. However , bef or e any dat agr ams dest ined t o a par t icul ar gr oup can
be r eceived, an upper -l ayer pr ot ocol (an appl icat ion) must ask t he IP modul e t o join t hat
gr oup. Thus, t he IP ser vice int er f ace must be ext ended t o pr ovide t wo new oper at ions:
JoinHost Gr oup (gr oup-addr ess, int er f ace) and LeaveHost Gr oup (gr oup-addr ess,
int er f ace).
The JoinHost Gr oup oper at ion r equest s t hat t his host become a member of t he host gr oup
ident if ied by gr oup-addr ess on t he given net wor k int er f ace. The LeaveGr oup
oper at ion r equest s t hat t his host give up it s member ship in t he host gr oup ident if ied by
gr oup-addr ess on t he given net wor k int er f ace. The int er f ace specif ies a unique
int er f ace f or t hose IP host s having mor e t han one int er f ace. If you have mor e t han one
int er f ace, you can join t he same gr oup on each of t he int er f aces; however , t his wil l
al l ow you t o r eceive dupl icat e mul t icast dat agr ams. Mor e t han one appl icat ion may
r equest t o join t he same gr oup; t he por t number s wil l dif f er ent iat e t he appl icat ions.
The possibil it y exist s f or each oper at ion t o not wor k. Since an appl icat ion can join any
gr oup, mul t ipl e appl icat ions or one appl icat ion may join many gr oups, which can l ead t o
r esour ce pr obl ems. JoinHost Gr oup may f ail due t o l ack of l ocal r esour ces. A mul t icast
member ship may per sist even af t er an appl icat ion has r equest ed t he LeaveHost Gr oup, due
t o t he f act t hat ot her appl icat ions may be using t hat host gr oup. Remember , a gr oup is a
r ange of host s t hat can r eceive and t r ansmit IP dat agr ams using a specif ic IP cl ass D
addr ess. A gr oup of host s al l use t he same (unique) cl ass D addr ess t o indicat e t he gr oup.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 257
Address Format
We know al l about t he addr ess f or mat s of Cl asses A, B, and C. The addr ess f or mat t hat
al l ows f or mul t icast addr ess is known as t he Cl ass D addr ess. It is r eser ved by IANA and
has a r ange of 224.0.0.0 t o 239.255.255.255. This al l ows f or 228 bit s (gr oups) f or mul t icast
addr essing. The base addr ess, 224.0.0.0, is r eser ved and cannot be assigned t o any gr oup.
Fur t her mor e, IANA has r eser ved t he r ange of 224.0.0.1 t hr ough 224.0.0.255 f or t he use of
r out ing pr ot ocol s, t opol ogy discover y, and maint enance pr ot ocol s. What is int er est ing
is t hat no r out er t hat r eceives a dat agr am wit h t his addr ess r ange is al l owed t o
f or war d it . It must eit her consume or discar d (f il t er ) t he dat agr am. Ot her addr esses of
int er est accor ding t o RFC 1700 ar e:
224.0.0.0 Base Addr ess (Reser ved) [RFC1112]
224.0.0.1 Al l Syst ems on This Subnet [RFC1112]
224.0.0.2 Al l Rout er s on This Subnet
224.0.0.3 Unassigned
224.0.0.4 DVMRP Rout er s [RFC1075]
224.0.0.5 OSPFIGP OSPFIGP Al l Rout er s [RFC1583]
224.0.0.6 OSPFIGP OSPFIGP Designat ed
Rout er s
[RFC1583]
224.0.0.7 ST Rout er s [RFC1190]
224.0.0.8 ST Host s [RFC1190]
224.0.0.9 RIP2 Rout er s [RFC1723]
224.0.0.10 IGRP Rout er s [Cisco]
224.0.0.11 Mobil e-Agent s
224.0.0.12 DHCP Ser ver / Rel ay Agent [RFC1884]
224.0.0.12224.0.0.255 Unassigned [IANA]
Addr ess For mat
IP mul t icast addr esses ar e Cl ass D addr esses.
They r ange f r om 224.0.0.0 t hr ough 239.255.255.255.
The addr ess of 224.0.0.0 is r eser ved.
The addr ess r ange of 224.0.0.1 t hr ough 224.0.0.255 is r eser ved f or t he use of
r out ing pr ot ocol s.
Not necessar il y gener ic mul t icast dat agr ams. OSPF uses 224.0.0.5 as an
Al l OSPFRout er s mul t icast addr ess.
The r eser ved r anges ar e not al l owed t o be f or war ded by a r out er .
It must eit her consume or discar d t he dat agr am.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 258
Mapping to an Ethernet or IEEE 802.X MAC Address
Net wor k int er f ace car ds ar e not int er est ed in any t ype of Layer 3 addr essing. NICs
r eceive and t r ansmit dat a on t he net wor k using MAC (Media Access Cont r ol ) or
har dwar e addr esses. Ther ef or e, some t ype of mapping must be used t o map an IP mul t icast
addr ess t o a MAC addr ess. But t he NIC pl ays an impor t ant r ol e in r eceiving mul t icast
packet s. Somehow, t her e has t o be a MAC addr ess f or mul t icast , and one f or al l
mul t icast packet s is not ef f icient . You shoul d not e t hat up t o 32 dif f er ent IP mul t icast
gr oups may be conver t ed t o t he same MAC addr ess. The upper 5 bit s of t he IP addr ess ar e
ignor ed. It l ooks l ike t he upper 9 bit s, but t he f ir st f our bit s of a Cl ass D addr ess ar e
al ways 1110 (which conver t s t o a 224 in decimal , t he st ar t ing number f or Cl ass D
addr esses), and since 9 bit s ar e displ aced in t his pr ocedur e, onl y t he next 5 bit s ar e
r eal l y ignor ed. If you r ead t hr ough RFC 1700 you wil l see t hat most of t he assigned
addr esses wil l not be af f ect ed by t his pr ocedur e.
When used on an Et her net or IEEE 802 net wor k, t he 23 l ow-or der bit s of t he IP
mul t icast addr ess ar e pl aced in t he l ow-or der 23 bit s of t he Et her net or IEEE 802 net
mul t icast addr ess. The IANA has been al l ocat ed a r eser ved bl ock of MAC l ayer
addr esses. Ther ef or e, a mul t icast MAC addr ess al ways begins wit h 01-00-5E (hex).
For exampl e, r ef er t o t he sl ide. The IP mul t icast addr ess 224.0.1.88 is mapped int o a MAC
addr ess (conver t ed t o hex). Fir st , t he IP addr ess must be conver t ed t o hex (it is usual l y
wr it t en in dot t ed decimal not at ion as shown). The addr ess 224 is E0 in hex, 0 is 00 in hex,
1 is 01 in hex, and 88 is 58 in hex. However , onl y t he l ow-or der 23 bit s ar e used.
Ther ef or e, t he IP addr ess of 224.0.1.88 conver t ed t o a MAC addr ess is 01-00-5E-00-01-88.
Mapping t o an Et her net or IEEE 802 MAC Addr ess
Hex
01-00-5E-00-00-00
Binary
0 23 47
| | |
0000 0001 0000 0000 0101 1110 0xxx xxxx xxxx xxxx xxxx xxxx
| |
Multicast bit 0=Internet multicast
1 = Assigned by IANA for other
uses
In or der f or t he NIC car d t o r eceive or t r ansmit mul t icast packet s, t he f ol l owing
f unct ions must be invoked t o pl ace t he mul t icast addr ess in t he NIC car d and t o r emove
it .
JoinLocal Gr oup (mapped gr oup addr ess): Al l ows t he l ink l ayer t o r eceive
mul t icast packet s f or a par t icul ar host gr oup.
LeaveLocal Gr oup (mapped gr oup addr ess): Al l ows t he l ink l ayer t o st op
r eceiving mul t icast packet s f or a par t icul ar host gr oup.
The mapped gr oup addr ess is t he MAC addr ess t hat is mapped f r om t he host gr oup
mul t icast addr ess.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 259
A Converted IP Multicast Address
The sl ide shows an IP mul t icast addr ess and it s MAC addr ess equival ent .
A Conver t ed IP Mul t icast Addr ess

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 260
Protocols
Review RFC 1112. Nat ur al l y, t her e ar e a f ew pr ot ocol s invol ved in or der t o make
mul t icast ing wor k. We wil l st ar t out wit h t he most pr eval ent pr ot ocol s and t hen wor k
our way int o ot her s. No mat t er which r out er -r out er pr ot ocol is used, one pr ot ocol is
used wit h al l of t hem: t he Int er net Gr oup Management Pr ot ocol (IGMP). To suppor t
IGMP, a host must join t he al l -host s gr oup (addr ess 224.0.0.1) on each net wor k
int er f ace at init ial izat ion t ime and must r emain a member f or as l ong as t he host is
act ive. Ther ef or e, t her e is at l east one mul t icast addr ess t hat ever y mul t icast host
shoul d be a member of .
IGMP is t he pr ot ocol t hat r uns bet ween mul t icast host s and t heir adjacent mul t icast
r out er s. (Rout er manuf act ur er s can choose whet her t o impl ement mul t icast or not .
Rout er s t hat par t icipat e in mul t icast must r un a mul t icast pr ot ocol (beyond RIP2, OSPF,
et c.) Most major r out er manuf act ur er s have or ar e in t he pr ocess of impl ement ing t hese
pr ot ocol s.) IGMP is used t o keep neighbor ing mul t icast r out er s inf or med of t he host
gr oup member ships pr esent on a par t icul ar l ocal net wor k. The IGMP header is used f or
al l mul t icast communicat ion, whet her it is bet ween host s or r out er s.
In or der f or an int er f ace t o r eceive a mul t icast dat agr am, it must have pr eviousl y been
set up t o r eceive and pr ocess mul t icast dat agr ams. Since IGMP does not use a t r anspor t
l ayer such as TCP or UDP, t he IP Pr ot ocol f iel d is set t o 2 (as r eser ved by IANA RFC
1700) in or der t o ident if y t he pr ocess (IGMP) using t he IP ser vice. Ther ef or e, bef or e any
mul t icast packet s ar e r eceived, t he upper -l ayer sof t war e must ensur e t hat IP and t he
MAC l ayer int er f aces ar e set up t o r eceived mul t icast dat agr ams.
Pr ot ocol s
IGMP is t he f r aming pr ot ocol used wit h al l ot her pr ot ocol s t o t r ansf er
inf or mat ion.
IGMP r uns bet ween host s and host s, host s and r out er s, and r out er s and
r out er s.
Used t o al l ow host s t o communicat e wit h r out er s and f or r out er s t o
communicat e wit h ot her r out er s
To suppor t IGMP, a host must join t he al l -host s mul t icast addr ess of 224.0.0.1.
IGMP r uns on al l host s.
A host may be a member of mor e t han one gr oup; in f act , t her e is no upper l imit on t he
number of gr oups al l owed (except f or t he upper l imit of t he IP mul t icast addr ess). NICs
have a ver y l imit ed capabil it y f or r eceiving mul t icast packet s. In ot her wor ds, when t he
user inst al l s t he ver sion of IP f or mul t icast , it must al so be abl e t o set up t he NIC t o
r eceive mul t icast packet s as wel l . Each host gr oup wil l have a dif f er ent mul t icast
addr ess and t her ef or e it wil l be mapped t o a mul t icast MAC addr ess as wel l (discussed
pr eviousl y). But t he NIC car d may onl y be abl e t o hol d a f init e number of mul t icast
addr esses. In t his case, check wit h t he manuf act ur er . Some have impl ement ed t he abil it y
t o r eceive al l mul t icast packet s. In t his way, it wil l be up t o t he IP l ayer sof t war e t o
f il t er out unwant ed packet s.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 261
IGMP Header
The IGMP r out er pl aces quer ies t o it s subnet s and t he host s t hat bel ong t o a gr oup
specif ied in t he quer y r esponse r epor t . The IGMP header s f or ver sion 1 and ver sion 2 ar e
shown in t he sl ide (you wil l f ind bot h t ypes on your net wor k). The Type f iel d can be one
of f our t ypes:
0x11: Member ship Quer y
0x16: Ver sion 2 Member ship Repor t
0x17: Leave Gr oupf or IGMP ver sion 1 compat ibil it y (expl ained l at er in t he
sect ion)
0x12: Ver sion 1 Member ship Repor t f or backwar d compat ibil it y
IGMP ver sion 2 has a dif f er ent header t han ver sion 1. The Ver sion and Type f iel ds of a
ver sion 1 header ar e combined int o one f iel d cal l ed t he Type f iel d. To al l ow a mul t icast
r out er t o det er mine t he dif f er ence bet ween t he t wo, a new Type f iel d was cr eat ed f or
Ver sion 2Member ship Repor t Message. IGMP ver sion 1 and ver sion 2 r out er s may
coexist . An IGMP ver sion 2 r out er must be abl e t o act as a ver sion 1 IGMP r out er . To
det er mine t his, t he Max Response Time f iel d is set t o 0 in al l quer ies (t his maps t o t he
unused f iel d in ver sion 1).
The member ship quer y packet has t wo t ypes: Gener al Quer y (used t o l ear n gr oup
member s of any gr oup on an at t ached net wor k) Gr oup Specif ic Quer y (used t o
l ear n member s of a specif ic gr oup).
How do you t el l t he dif f er ence bet ween t he t wo? This is det er mined by t he gr oup
addr ess in t he IGMP header . A gener al quer y uses al l 0s in t he Gr oup Addr ess f iel d and
t he specif ic quer y uses t he exact gr oup addr ess. Bot h of t hese messages ar e sent using
t he IP header addr ess 224.0.0.1 and a mapped mul t icast MAC addr ess 01-00-5E-00-00-01
(r eview t he conver sion met hod, expl ained pr eviousl y).
The Leave Gr oup message is new t o IGMP ver sion 2. It al l ows a r out er t o immediat el y
det er mine if t her e ar e any member s of a gr oup l ef t on it s int er f ace t hat r eceived t he
Leave Gr oup message. This is expl ained in a moment .
IGMP Header

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 262
Router Functions of IGMP
Mul t icast r out er s use IGMP t o l ear n which gr oups have member s on each of t he
r out er s int er f aces. This inf or mat ion wil l in t ur n be used t o buil d mul t icast t r ees f or
f or war ding mul t icast dat a. It wil l al so have a t imer f or each of t hose gr oup
member ships. A r out er t hat r uns IGMP is al so a member of any host gr oup t hat has
member s on one or mor e of it s int er f aces. The mul t icast r out er keeps a l ist of t he
member ships on it s int er f aces and not t he individual host s t hat bel ong t o t hat gr oup.
Ther e r eal l y is no need t o keep t r ack of t he host s. Simpl e enough: If onl y one host on a
r out er int er f ace wishes t o join a gr oup, t he r out er has t o f or war d mul t icast dat agr ams
on t hat int er f ace. It does not mat t er if t her e ar e 100 host s or 1 on t hat int er f ace; t he
r out er must be a member of t hat gr oup as wel l and f or war d mul t icast dat agr ams out
t hat int er f ace. The mul t icast r out er wil l know if t her e ar e any member s of a gr oup l ef t
on it s int er f ace by sending a quer y packet out t hat int er f ace.
For IGMP ver sion 2, a mul t icast r out er may assume one of t wo r ol es: querier or nonquerier.
Al l mul t icast r out er s, upon init ial izing, assume t hey ar e t he quer ier r out er . Since
mul t icast r out er s per iodical l y t r ansmit a quer y t o f ind host s f or gr oups, t he new
r out er wil l event ual l y r eceive a quer y if t her e is anot her r out er pr oviding t his
f unct ion. If t he r out er r eceives anot her quer y message f r om anot her r out er and onl y if
t hat r out er has a l ower IP addr ess, t he new r out er wil l assume t he r ol e as a
nonquer ier . If t he new r out er has a l ower IP addr ess, it wil l assume t he r ol e of quer ier
and t he ot her r out er wil l assume t he r ol e of nonquer ier .
Rout er Funct ions of IGMP
When a host r eceives a quer y, it wil l set del ay t imer s f or each gr oup t o which it bel ongs
(set bet ween 0 and t he t imer indicat ed in t he Max Response Time f iel d of t he r eceived
quer y). For a host wit h mor e t han one int er f ace, each int er f ace maint ains it s own
t imer s. When t he t ime is up, t he host r esponds wit h a ver sion 2 Member ship Repor t . The
TTL f iel d of t he IP header wil l be set t o 1. This ensur es t hat t he packet wil l not be
f or war ded beyond t hat l ocal net wor k on which it was t r ansmit t ed. If t he host r eceives
a r epor t f r om anot her host in t he same gr oup, t he host wil l st op it s t imer and wil l not
send a r epor t . This is t o conser ve bandwidt h and pr ocessing t ime, and avoids having
dupl icat e r epor t s on t he net wor k. Al l of t his is accompl ished using mul t icast
addr essing. 224.0.0.2 is t he al l -r out er s mul t icast addr ess and 224.0.0.1 is t he al l -host s
addr ess.
If t he r out er r eceives a r epor t or r epor t s, it wil l add t he gr oup t o it s int er nal l ist ,
not ing t he int er f ace on which it r eceived t he r epor t . It t hen set s a t imer f or t he next
quer y message. If it r eceives mor e r epor t s f or a gr oup, t hen t he t imer wil l be r eset t o t he
max val ue and r est ar t ed. If no r epor t s ar e r eceived bef or e t his t imer expir es, t hen t he
r out er assumes t her e ar e no member s f or t hat gr oup and it wil l not f or war d r emot el y
r eceived mul t icast dat agr ams on t he int er f ace.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 263
HostJoin
When a host joins a mul t icast gr oup, it immediat el y t r ansmit s a ver sion 2 Member ship
Repor t t wo or t hr ee t imes (r emember , IGMP does not use ICMP or TCP). This is done in
case t hat host is t he f ir st member of t he gr oup and it is r epeat ed in case t he f ir st r epor t
get s l ost or cl obber ed.
When a host l eaves a gr oup (IGMPv2), it t r ansmit s a Leave Gr oup message. A host may or
may not be abl e t o det er mine if it is t he l ast member of a gr oupt his is a st or age and
pr ocessing decision on t he par t of t he impl ement er . A host t hat can det er mine if it is t he
l ast host in t he gr oup wil l t r ansmit t he Leave Gr oup message. Ot her impl ement at ions
t hat cannot det er mine t his may or may not send t his message. The mul t icast r out er wil l
det er mine if any host s exist f or a gr oup by t he quer y message anyway. When a mul t icast
r out er r eceives t his message, it wil l send gr oup-specif ic quer ies t o t he gr oup being l ef t .
If no r epor t s ar e r eceived, t hen t he mul t icast r out er wil l assume t her e ar e no member s
l ef t in t hat gr oup and it wil l not f or war d any mul t icast dat agr ams f or t hat gr oup out
t hat int er f ace.
IGMPv2 is a pr el iminar y dr af t specif icat ion as of t his wr it ing and can be f ound at t he
Int er NIC (ds.int er nic.net ) under Draft RFCs. It most l y cont ains t he abil it y t o conser ve
bandwidt h by al l owing a host t o el ect t o r eceive t r af f ic f r om specif ied sour ces (IP
addr esses) of a mul t icast gr oup. Al t er nat ivel y, it al l ows a host t o specif y which sour ces
it does not want t o r eceive inf or mat ion f r om. What is a sour ce? It is simpl y a host t hat
or iginat ed a mul t icast dat agr am. Ther e may be many sour ces in any one gr oup. Wit h
IGMP ver sions 1 and 2, a host is r equir ed t o r eceive al l inf or mat ion f or a gr oup of which
it is a member , no mat t er which sour ce t r ansmit t ed it . Al so, t he Leave Gr oup message is
enhanced t o al l ow a host t o specif y which sour ces it no l onger wishes t o r eceive
inf or mat ion f r om. The mul t icast r out er wil l r eceive t his and possibl y st op sending
inf or mat ion t o t hat gr oup f r om t hat sour ce.
Now t hat we under st and how t he host oper at es wit h IP mul t icast and how a host
int er act s wit h a mul t icast r out er , we need t o l ear n how mul t icast act ual l y oper at es.
Fir st , we wil l st udy t he al gor it hms and t hen we wil l t ake an in-dept h l ook at one
mul t icast pr ot ocol : t he Dist ance Vect or Mul t icast Rout ing Pr ot ocol , or DVMRP. The
dr af t RFC used is ver sion 3 of DVMRP.
Host Join

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 264
Multicast Algorithms
A l ot of peopl e do not even r eal ize t hat t hey have al r eady wor ked wit h mul t icast ing.
If you have wor ked wit h t he Spanning Tr ee al gor it hm f or br idging or t he Open Shor t est
Pat h Fir st (OSPF) pr ot ocol f or IP r out ing updat es, you have al r eady wor ked wit h a
mul t icast al gor it hm.
IP mul t icast ing f or subnet r out ing uses t he f ol l owing pr ot ocol s:
Dist ance Vect or Mul t icast Rout ing Pr ot ocol (DVMRP)
Mul t icast Open Shor t est Pat h Fir st (MOSPF)
Pr ot ocol Independent Mul t icast (PIM)
Spar se mode
Dense mode
Ther e ar e essent ial l y t hr ee f or war ding al gor it hms t hat can be used wit h IP
mul t icast ing:
Fl ooding
Spanning Tr ee
Simpl e Spanning Tr ee
Rever se Pat h Br oadcast ing
Rever se Pat h Mul t icast ing (most widel y impl ement ed)
Cor e-Based Tr ees (Used in spar se envir onment s [envir onment s t hat do not have a
densel y popul at ed envir onment of host s], CBT is a t ype of spanning t r ee al gor it hm
but dif f er ent enough t o mer it it s own cat egor y).
The pur pose of al l t he al gor it hms is t o buil d a mul t icast t r ee f or t he f or war ding of
mul t icast dat agr ams. Some al gor it hms (CBT and somet imes PIM-SM) buil d onl y one t r ee
t hat al l member s of t he gr oup shar e, even if t he t r ee does not suppl y t he most ef f icient
(shor t est pat h) r out e bet ween al l member s of t he gr oup. Ot her pr ot ocol s buil d shor t est
pat h t r ees t hat al l ow f or t he shor t est pat h f or al l member s in t he gr oup (DVMRP,
OSPF). Ther e can and wil l be mul t ipl e mul t icast t r ees buil t f or each sour ce/gr oup on a
net wor k. These t r ees ar e buil t dynamical l y when t he f ir st mul t icast dat agr am ar r ives
f r om t he sour ce (wit h t he except ion of MOSPF).
Mul t icast Al gor it hms
IP mul t icast pr ot ocol s.
Pr ot ocol Independent Mul t icast (PIM)
Dense mode
Spar se mode
For war ding al gor it hm.
Fl ooding.
Spanning t r ee.
Simpl e spanning t r ee (one mul t icast t r ee f or al l gr oups)
Rever se pat h f or war ding
Rever se pat h mul t icast ing
Cor e-based t r ees.
Mul t icast dat agr ams do not necessar il y f ol l ow t he unicast dat agr ams pat h. The
mul t icast t r ee t hat is buil t is a dynamic l ogical t r ee t hat a r out er wil l buil d t o
f or war d mul t icast dat agr ams t o it s r eceiver s.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 265
Leaves, Branches, and the Root
A f ew t er ms shoul d be expl ained bef or e we cont inue. Those f amil iar wit h spanning t r ees
al r eady under st and about l eaves, br anches, and t he r oot . For t hose who ar e not , r ead
on.
Ref er t o t he sl ide. It shows t he l eaves, br anches, and t he r oot of a spanning t r ee. The
l eaves ar e simpl y t he endpoint s of t he t r ee. If t her e ar e no ot her f or war ding pat hs
beyond a r out er pat h, t hen t he int er f ace is consider ed a leaf int er f ace. If t her e ar e mor e
f or war ding pat hs t o a host gr oup, t hen t he int er f ace is consider ed a branch. The root is
t he sour ce of t he mul t icast t r ansmission. Ther e can be many sour ces f or a mul t icast
net wor k.
Pict ur e a t r ee. A t r ee has a r oot , a t r unk, br anches, and l eaves. Leaves ar e t he
out er most par t of t he t r ee; in f act , t hey ar e endpoint s. The br anches cont ain t he
l eaves, but l eaves cannot cont ain br anches. The r oot is t he sour ce of al l l if e in t he
t r ee. Lose t he r oot and t he t r ee dies.
Leaves, Br anches, and t he Root

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 266
Spanning Tree and Flooding
The simpl est and most inef f icient al gor it hm f or IP mul t icast f or war ding is flooding.
Essent ial l y, when a mul t icast r out er r eceives a mul t icast dat agr am, it wil l f ir st check
t o see if it has r eceived t his ver y same dat agr am bef or e. If it has, it wil l discar d t he
dat agr am. However , if it has not , t he dat agr am wil l be f or war ded t o al l int er f aces on
t he mul t icast r out er except f or t he one on which t he dat agr am was r eceived. You can
see how simpl e t his woul d be t o impl ement . Ther e ar e not many r esour ces r equir ed t o
impl ement t his al gor it hm. However , t he f l ooding al gor it hm does not scal e wel l . As
your net wor k gr ows, t he f l ooding al gor it hm becomes a r esour ce hog and is ver y
inef f icient . It gener at es a l ar ge number of dupl icat e packet s and it f or war ds out al l
t he int er f aces t hat it has conf igur ed, even if t her e ar e no host s downst r eam t hat
bel ong t o t hat mul t icast gr oup. The downst r eam r out er s have t o pr ocess t he dat agr am
as wel l , and t he r out er al so has t o maint ain a t abl e f or each packet r ecent l y r eceived
(a t imer mechanism woul d have t o be est abl ished t o cl ean up t he t abl e as wel l ).
Ther ef or e, t he spanning t r ee al gor it hms l ook mor e appeal ing. They r equir e mor e l ogic in
t he mul t icast r out er s, but t he t r ade-of f in ef f iciency is wel l wor t h t he pr ice. The f ir st
al gor it hm t hat was invoked was a simpl e spanning t r ee. It cr eat ed one spanning t r ee out
of t he cur r ent Int er net t opol ogy.
Once t he spanning t r ee was buil t , if a mul t icast r out er r eceived a mul t icast dat agr am,
it woul d f or war d t he dat agr am out each of it s spanning t r ee int er f aces, except t he one
on which it r eceived t he dat agr am. We have el iminat ed t he l oops pr ovided f or us in t he
simpl ex f l ooding al gor it hm and t he r out er is not t axed wit h maint aining t abl es f or
r ecent l y f or war ded packet s (dupl icat es). Al t hough t he spanning t r ee adds mor e
maint enance t r af f ic on t he net wor k (t o maint ain t he spanning t r ee t opol ogy), and has
mor e over head pr ocessing in t he r out er , t he ef f iciencies pr ovided ar e bet t er t han t he
f l ooding al gor it hm. This met hod has it dr awbacks, however , in t hat it may not pr ovide
t he best pat hs t o al l dest inat ions based on t he gr oup addr ess and t he sour ce. It simpl y
f or war ds mul t icast dat agr ams out it s spanning t r ee int er f aces wit hout r egar d t o gr oup
addr ess and t he sour ce and whet her t her e ar e any r ecipient s on any par t of t he
spanning t r ee. In ot her wor ds, t he compl et e spanning t r ee sees al l mul t icast s even if
t her e ar e no member s.
Spanning Tr ee and Fl ooding

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 267
Reverse Path Forwarding (RPF)
Since t he spanning t r ee was bet t er but st il l not ef f icient or scal eabl e, many ot her
mul t icast pr ot ocol s wer e t est ed and exper iment ed, but t he pr ot ocol t hat is used wit h
mul t icast ing is Rever se Pat h For war ding, or RPF. This al gor it hm pr ovides a gr oup-
specif ic spanning t r ee. That is, f or each gr oup sour ce (t he host t hat is or iginat ing t he
mul t icast dat agr am), a separ at e dist inct spanning t r ee is buil t bet ween t hat sour ce and
al l t he pot ent ial host r ecipient s.
This al gor it hm t hat you ar e about t o l ear n may seem backwar ds, and in a way it is. We
know t hat mul t icast ing is based on a (sour ce, gr oup) pair . If a mul t icast dat agr am is
r eceived on a r out er s int er f ace, t he r out er t hen det er mines if t he int er f ace t hat t he
dat agr am was r eceived on is t he shor t est pat h back t o t he sour ce. Sounds l ike t he
opposit e of RIP? Wel l , it is. If t he r out er det er mines t hat t he int er f ace does pr ovide t he
shor t est pat h back t o t he sour ce, it f or war ds t he r eceived dat agr am on ever y act ive
int er f ace except t he one on which it r eceived t he dat agr am. Ot her wise, t he r out er
det er mines t hat t he int er f ace does not pr ovide t he shor t est pat h back t o t he sour ce,
and it discar ds t he dat agr am. The int er f ace det er mined t o be t he shor t est pat h back t o
t he sour ce is cal l ed t he parent link. The int er f ace on which t he r out er f or war ds t he
mul t icast dat agr am is cal l ed t he child link.
Wher e does t he r out er get t his inf or mat ion t o al l ow it t o make a decision on what is
t he shor t est pat h back t he sour ce? The r out ing t abl es of t he r out er . If you ar e using a
l ink-st at e r out ing updat e pr ot ocol such as OSPF, each r out er maint ains a r out ing t abl e
f or whol e net wor k, mul t icast or unicast . If you ar e using a dist ance-vect or pr ot ocol
such as RIP or RIP2, a r out ing updat e is needed. We wil l expl ain it in f ur t her det ail in
our discussion of DVMRP.
RPF cont ains many advant ages over t he mechanism pr eviousl y descr ibed. It is simpl e t o
impl ement . Mul t icast dat agr ams ar e f or war ded over mul t ipl e l inks since RDF al l ows
f or buil ding separ at e spanning t r ees f or each sour ce and gr oup pair .
Rever se Pat h For war ding (RPF)

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 268
Pruning and Grafting (Definition)
Some mul t icast f or war ding al gor it hms, such as DVMRP, br oadcast (f l oods) t he f ir st
packet t hat it r eceives and t hen wait s f or Pr une messages f r om t he downst r eam
int er f aces. The Pr une messages come back f r om mul t icast r out er s in r esponse t o
r eceiving unwant ed mul t icast t r af f ic at t he l eaves of t he mul t icast t r ee; t her ef or e,
f inding t he l eaf net wor ks f or any mul t icast t r ee is impor t ant . These r out er s t hat
connect t o l eaf net wor ks st ar t t he pruning pr ocess by ident if ying which downst r eam
int er f aces do not bel ong t o t he mul t icast gr oup. Rout er s t hat ident if y t hese int er f aces
pr une t hose int er f aces. If af t er pr uning it s own int er f aces, t he r out er f inds t hat none
of it s int er f aces bel ong t o t hat gr oup, it wil l send a Pr une message upst r eam t o it s
neighbor . If t he r out er cont inues t o r eceive mul t icast dat agr ams f or t hat sour ce, it
wil l cont inue t o send Pr une messages (incr easing t he del t a bet ween t hem) unt il t he
mul t icast t r af f ic f or t hat gr oup st ops.
A pr une l if et ime is about t wo hour s.
To join new r eceiver s back ont o t he t r ee, t he Graft message is sent . This message is sent
hop by hop t o each mul t icast r out er . Each message is acknowl edged bet ween r out er s t o
ensur e t hat it was r eceived, t her eby guar ant eeing end-t o-end del iver y. Rout er s t hat
r eceive Gr af t messages can make a ser ies of decisions.
If t he r eceiving r out er has a pr une st at e f or t he (sour ce, gr oup) pair , t hen it
acknowl edges t he Gr af t message and sends a Gr af t message of it s own t o it s upst r eam
r out er . If t he r out er has some pr uned downst r eam int er f aces but not a pr uned upst r eam
int er f ace, it simpl y adds t hat int er f ace t o t he l ist of downst r eam int er f aces in it s
r out ing t abl e. It wil l al so send an acknowl edgment t o t he sour ce of t he Gr af t message.
If t he r out er has no st at e (pr uned or ot her wise) f or t he (sour ce, gr oup) pair , t hen any
r eceived dat agr ams f or t he (sour ce, gr oup) pair shoul d be aut omat ical l y f l ooded. A
gr af t acknowl edgment is sent t o t he sour ce of t he Gr af t message as wel l .
Pr uning and Gr af t ing (Def init ion)

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 269
Reverse Path Multicasting (RPM)
The al gor it hm t hat uses pr uning and gr af t ing is how RPM was devised. Act ual l y, a f ew
ot her pr ot ocol s wer e devel oped, but RPM is used in many mul t icast al gor it hms,
especial l y dist ance-vect or such as Dist ance Vect or Mul t icast Rout ing Pr ot ocol
(DVMRP). RPM al l ows us t o t r im t he t r ee so t hat mul t icast dat agr ams ar r ive on t hose
br anches and l eaf segment s t hat have act ive par t icipant s. The al gor it hm basical l y
f or war ds t he f ir st mul t icast packet of ever y (sour ce, gr oup) pair t o al l par t icipat ing
r out er s in t he spanning t r ee (sour ce, gr oup). This al gor it hm is assist ed by t he IGMP
pr ot ocol t o det er mine which segment s have act ive host gr oups. Using IGMP, mul t icast
r out er s can det er mine t he gr oup member ships on each l eaf subnet wor k. In t his way, a
mul t icast r out er can det er mine whet her any of it s segment s have act ive host gr oups. If
a host gr oup is not act ive, t he r out er does not f or war d a mul t icast dat agr am out t hat
int er f aceit is t r uncat ed.
RPM al l ows t he r out er t o t r ansmit a Prune message back t hr ough t he int er f ace on
which it r eceived t he mul t icast dat agr am (it s par ent l ink) t hat al l ows it s upst r eam
neighbor t o basical l y shut of f t hat int er f ace t o t hat downst r eam r out er no need t o
f or war d mul t icast dat agr ams t o t he r out er if it is onl y going t o t hr ow t hem away.
Pr une messages ar e onl y sent once f or each mul t icast packet t he r out er does not have a
gr oup int er f ace f or . If t hat upst r eam r out er does not have any l eaf net wor ks f or a host
gr oup and ot her br anch int er f aces al l sent back a Pr une message, t hen t hat upst r eam
r out er may send a Pr une message t o it s upst r eam r out er (it s par ent l ink) as wel l . The
next upst r eam r out er woul d t hen shut of f it s int er f ace t o t hat downst r eam r out er .
You can pr une al l t he way back t o t he r oot .
This cascading of Pr une messages cr eat es a t r ue spanning t r ee t opol ogy t hat wil l onl y
f or war d mul t icast dat agr ams t o t hose int er f aces t hat have act ive gr oup host s. How do
we gr ow back a br anch or cr eat e l eaves? Per iodical l y, t he pr une int er f aces ar e r emoved
f r om t he r out er s t abl e and t he br anches and l eaves gr ow back. This al l ows t he
f or war ding of mul t icast dat agr ams down t hose br anches, r esul t ing in a new st r eam of
Pr une messages t o cr eat e t he t r ue spanning t r ee.
This al gor it hm el iminat es most pr obl ems except f or one: scal ing. It st il l does not al l ow
f or gr owing t he net wor k t o t housands or t ens of t housands of r out er s wit h hundr eds
or t housands of mul t icast gr oups. The f ir st mul t icast packet is r eceived by al l r out er s,
and t hen const ant pr uning messages ar e needed t o keep t he spanning t r ee ef f icient .
Rever se Pat h Mul t icast ing (RPM)

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 270
Core-Based Tree (CBT)
The pr evious al gor it hms buil d spanning t r ees based on a sour ce host , and mul t ipl e t r ees
can be buil t f r om dif f er ent sour ces. The sour ce host is basical l y t he r oot of t he
spanning t r ee and t he spanning t r ee br anches out f r om t he sour ce. If t her e ar e many
sour ces, t her e ar e many r oot s. If t her e ar e many mul t icast s, each has it s own mul t icast
t r ee. CBT buil ds a singl e f or war ding t r ee t hat is shar ed by al l member s of a gr oup. The
cor e of t his t r ee (t he r oot ) is based on t he cor e r out er and not t he sour ce of t he
mul t icast dat agr am.
CBT wor ks on a concept t hat buil ds a backbone consist ing of at l east one cor e r out er .
Mul t icast messages f or a gr oup ar e t r ansmit t ed in t his dir ect ion. Any host t hat wishes
t o r eceive mul t icast inf or mat ion f or a specif ic gr oup t r ansmit s a Join message and
t r ansmit s it t owar ds t he cor e backbone. Each sour ce must be conf igur ed wit h at l east
one IP addr ess of t he cor e r out er s. The cor e consist s of at l east one r out er t hat act s as
t he cor e. Ther e can be mul t ipl e r out er s act ing as cor e r out er s and, if so, t he l inks t hat
connect t hese cor e r out er s become t he cor e backbone.
If t her e ar e mul t ipl e gr oups in t he net wor k, t hen mul t ipl e t r ees may be buil t . It is not
t he concept of one mul t icast t r ee f or al l gr oups. However , t her e is onl y one mul t icast
t r ee f or each gr oup.
Af t er issuing t he Join message, each int er mediat e r out er mar ks t he int er f ace and
mul t icast gr oup and t hen f or war ds t he message t owar ds t he cor e. In doing t his, t he
r out er is abl e t o f or war d mul t icast dat a t owar ds t he cor e f or t hat gr oup. When t he
cor e r out er s r eceive t his dat a, t hey wil l mul t icast t he dat a back out al l por t s, except
t he one on which it r eceived t he dat a.
Cor e-Based Tr ee (CBT)
This al gor it hm may simpl y st ay an ar chit ect ur e f or which ot her pr ot ocol s wil l be
devel oped. To become a pr ot ocol , issues of dynamic sel ect ion of t he cor e backbone and
management must be set t l ed. The most not abl e pr ot ocol using it is t he Pr ot ocol
Independent Mul t icast (PIM) Spar se Mode (discussed l at er ). Ther e ar e advant ages and
disadvant ages of t he al gor it hm: Since each gr oup is based on a singl e t r ee r oot ed at t he
cor e, st at e inf or mat ion on t he r out er is easier t o maint ain, t her eby r equir ing f ewer
r esour ces on t he r out er . Inf or mat ion t hat must be passed bet ween r out er s t o maint ain
t hese st at es is al so l ess, r esul t ing in bet t er ef f iciency of t he bandwidt h. However , since
al l individual dat a and cont r ol messages t r avel t owar ds a specif ic cor e, congest ion may
be inevit abl e.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 271
Distance Vector Multicast Routing Protocol (DVMRP)
The f ol l owing t ext about t he DVMRP r out ing pr ot ocol is al igned wit h t he DVMRP
ver sion 3 specif icat ion, which as of t his wr it ing is st il l a dr af t RFC. DVMRP uses t he
Rever se Pat h Mul t icast ing (RPM) al gor it hm t o dynamical l y buil d mul t icast del iver y
t r ees and det er mine t he r out er s posit ion in t he mul t icast t r ee in r ef er ence t o t he
sour ce subnet of a mul t icast dat agr am. DMVRP is a br oadcast and pr une mul t icast
r out ing pr ot ocol . It uses Rever se Pat h For war ding t o see if a mul t icast dat agr am
shoul d be f or war ded downst r eam. A mul t icast f or war ding t r ee is buil t bet ween a
sour ce and al l member s of t he gr oup (r eceiver s). For t hose f amil iar wit h t his pr ot ocol , it
shoul d be not ed up f r ont t hat t he l at est ver sion of t his pr ot ocol f or Unix, mr out ed 3.5,
is al so based on RPM, which is signif icant l y dif f er ent f r om pr evious ver sions in t he ar eas
of packet f or mat , t unnel ing, and so f or t h.
In or der f or DVMRP t o wor k, t wo t abl es must be buil t : a unicast r out e t abl e and a
f or war ding r out e t abl e. The unicast r out e t abl e is used t o det er mine if a mul t icast
dat agr am was r eceived on t he cor r ect por t (t he upst r eam int er f ace). The f or war ding
t abl e is used t o det er mine on which int er f aces of a r out er , a r out er shoul d f or war d a
mul t icast dat agr am (t he downst r eam int er f ace).
To buil d t he unicast r out ing t abl e, DVMRPs pass r out e r epor t s t o each ot her cont aining
ent r ies f or sour ce subnet s. This t abl e is pr ocessed l ike RIP and t he shor t est dist ance
back t o a sour ce is comput ed and pl aced in t he t abl e. The f or war ding t abl e is buil t by
br oadcast ing t he f ir st mul t icast dat agr am r eceived and t hen wait ing f or ot her r out er s
t o send back Pr une and Gr af t messages t o indicat e who and who does not want t he
dat agr am. Why not simpl y use t he unicast r out ing t abl e? This is accompl ished t o al l ow
mul t icast t r af f ic t o f ol l ow a dif f er ent pat h t han t he unicast t r af f ic and f or t he
suppor t of a t unnel int er f ace, which unicast t r af f ic does not under st and.
DVMRP r out er s suppor t t wo t ypes of int er f aces: router and tunnel. The mul t icast r out er
int er f ace is obvious, but t he t unnel int er f ace is not so obvious. To al l ow f or
nonmul t icast r out er s t o exist in a mul t icast net wor k, t he concept of t unnel s is used.
Mul t icast dat agr ams ar e encapsul at ed in unicast IP packet s (using IP in IP) and t hese ar e
send over t he unicast r out er s. Cont ained in t he IP header is a r out e l ist t hat t he
unicast r out er s shoul d use. The l ast ent r y in t his l ist is t he end of t he t unnel and is a
r out er t hat again suppor t s IP mul t icast . The l ast r out er st r ips of f t he unicast
inf or mat ion and sends t he dat agr am on.
DVMRP is a pr ot ocol t hat uses a dist ance-vect or dist r ibut ed r out ing al gor it hm in or der
f or each r out er t o det er mine t he dist ance f r om it sel f t o any IP mul t icast t r af f ic sour ce.
When DVMRP det er mines t his, it cr eat es IP mul t icast del iver y t r ees bet ween a sour ce
and it s dist r ibut ed gr oup host s.
DVMRP uses t he Rever se Pat h Mul t icast ing (RPM).
Br oadcast and Pr une.
DVMRP buil ds t wo r out ing t abl es:
Unicast and f or war ding r out e t abl es
Unicast r out ing t abl e is buil t by passing r out e r epor t s.
Two t ypes of int er f aces suppor t ed:
Rout er and Tunnel
Tunnel s exist t o al l ow mul t icast t o l ive in a nonmul t icast wor l d.
An IP mul t icast packet is wr apped in an IPv4 unicast packet

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 272
DVMRP and IGMP
The f ol l owing sl ide shows t he compar ison bet ween t he mul t icast r out ing pr ot ocol of
DVMRP and t he host member ship pr ot ocol IGMP. The pr ot ocol of IGMP r uns bet ween t he
host s and t he r out er s, and t he DVMRP pr ot ocol r uns bet ween t he r out er s.
However , it shoul d be not ed t hat wit h IPv4, t he encapsul at ion of DVMRP dat a is
accompl ished using an IP encapsul at ion pr ot ocol of 2, which is IGMP. If you pl ace a
pr ot ocol anal yzer on t he net wor k you wil l see DVMRP communicat ing using IP
pr ot ocol t ype 2 f or IGMP encapsul at ion. This does not mean t hat IGMP is r unning
bet ween r out er s; it is simpl y using t he IGMP encapsul at ion t o send it s dat a.

DVMRP and IGMP

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 273
Neighbor Discovery
A DVMRP r out er can and does discover neighbor DVMRP r out er s t hr ough a pr ocess
known as Neighbor Discover y using t he probe packet. When a DVMRP r out er is
init ial ized, it t r ansmit s t hese discover y packet s t o inf or m ot her DVMRP r out er s t hat it
is oper at ional . These messages ar e sent per iodical l y (ever y 10 seconds) t o t he Al l
DVMRP Rout er s mul t icast addr ess. Each of t he messages shoul d cont ain t he l ist of
neighbor DVMRP r out er s t hat it knows about on t hat int er f ace. Ot her r out er s on
ot her int er f aces ar e not incl uded in t his l ist ing; t his is l ocal onl y. Rout er s shoul d see
t heir IP addr esses in t heir neighbor s messages.
The pr obe packet s al l ow ot her DVMRP r out er s t o discover each ot her and t o al so
det ect when a neighbor r out er no l onger exist s. If a DVMRP r out er does not det ect t his
message f r om a neighbor wit hin 35 seconds, it consider s t hat neighbor t o be down.
Cont ained in t his message is a l ist ing of al l ot her DVMRP neighbor r out er s t hat t he
r out er knows about . If a r out er does not r eceive any Pr obe messages, it consider s t he
subnet t o be a l eaf net wor k onl y.
Neighbor Discover y

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 274
Route Reports
Unicast r out ing inf or mat ion is sent bet ween neighbor s using a special packet cal l ed a
route report. Cont ained in t he r out e r epor t is a l ist ing of unicast (sour ce) subnet s and
t heir masks, and t he met r ic (cost ) associat ed wit h each subnet . A r out e l ear ned t hr ough
r out e r epor t s shoul d be r ef r eshed wit hin 140 seconds (2 r epor t int er val + 20), af t er
which it can be r epl aced wit h t he next best r out e t o t he same sour ce. If no updat e and
no al t er nat ive r out e exist s and 200 seconds have passed, t he r out e is discar ded f r om t he
r out ing t abl e.
A r out e r epor t is sent out ever y 60 seconds, and any number of r out e r epor t s can be sent
at any t ime dur ing t his int er val . In t his way, a r out er is not consumed by a per iodic
updat e l ike RIP t hat coul d consist of t housands of r out es. At any t ime dur ing t his
int er val , f l ash updat es can be sent . These r epor t s indicat e changes in t he net wor k but
onl y cont ain t he sour ce subnet t hat changed. This r educes t he l oop changes and ot her
cat ast r ophes when pat hs f or sour ce net wor ks change.
Rout e Repor t s

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 275
Receiving a Route Report
Receiving a r out e r epor t is a dif f er ent mat t er . Ther e ar e many checks done on t he
r eceived inf or mat ion. Rout e r epor t s ar e pr ocessed onl y by t hose sent by a known
neighbor ; ot her wise, t hey ar e discar ded. Gener al l y, t wo r ul es ar e f ol l owed: If t he
r out e ent r y is new and t he met r ic is l ess t han inf init y, t he r out e is added. That s t he
simpl e one. The second r ul e is t ougher and is shown in t he t abl e.
If t he r out e ent r y exist s, per f or m t he f ol l owing checks:
If New Met r ic < inf init y AND New
met r ic > exist ing met r ic
If t he same neighbor is r epor t ing it , updat e t he
ent r y; ot her wise, discar d t he ent r y.
met r ic < exist ing met r ic
Updat e t he ent r y wit h t he r out e and if necessar y,
updat e t he r epor t ing neighbor .
met r ic = exist ing met r ic
Ref r esh t he r out e and if t he new neighbor has a
l ower IP addr ess, updat e t hat ent r y.
If New Met r ic = inf init y AND New
gat eway = exist ing gat eway
Rout e is now unr eachabl e, updat e t he ent r y.
If New Met r ic = inf init y AND New
gat eway not equal t o exist ing
gat eway
Ignor e
If New met r ic is bet ween r out e
inf init y and 2x inf init y
Neighbor consider s t he r eceiving r out er t o be
upst r eam f or t he indicat ed and t hat r out er is
dependent on t he r eceiving r out er f or t he r out e
indicat ed. If t he r eceiving neighbor r out er
consider s t hat r out er t o be downst r eam, t he
r eceiving r out er mar ks t hat neighbor as dependent
f or t hat r out e; ot her wise, discar d t he packet , f or a
dependent r out er cannot be consider ed t o be
upst r eam.
If t he met r ic is gr eat er t han 2x
inf init y
Ignor e

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 276
DVMRP Tables
DVMRP Tabl es
DVMRP r out e t abl e cont ains Sour ce subnet s and Fr om Gat eways.
This t abl e cont ains ent r ies used t o det er mine if a sour ces mul t icast
packet s wer e r eceived on t he cor r ect int er f ace
For war ding t abl e.
Used t o det er mine which int er f aces a mul t icast packet shoul d be
f or war ded on
When an IP mul t icast dat agr am is r eceived by a r out er r unning DVMRP, it f ir st l ooks
up t he sour ce net wor k in it s DVMRP unicast r out ing t abl e . That s r ight ! In or der t o
ensur e t hat al l DVMRP r out er s have a consist ent view of t he unicast pat h back t o a
sour ce, a unicast r out ing t abl e is pr opagat ed t o al l DVMRP r out er s as an int egr al par t
of t he pr ot ocol . This is a separ at e unicast r out ing t abl e f or DVMRP. Act ual l y, t her e
ar e t wo t abl es used in mul t icast r out ing: a routing t abl e and a forwarding t abl e. The
DVMRP routing t abl e cont ains Sour ce Subnet s and Fr om Gat eways. It has t he shor t est -
pat h sour ce-r oot ed spanning t r ee t o ever y par t icipat ing sour ce subnet in t he int er net .
Compar e t his wit h ent r ies f r om a t ypical IGP t abl e such as RIP, which cont ains
Dest inat ions and Next -Hop Gat eways. The forwarding t abl e is cr eat ed because t he
r out ing t abl e is not awar e of gr oup member ships. The f ol l owing t abl e shows a simpl e
DVMRP r out ing t abl e.
Sour ce Subnet Subnet Mask Fr om Gat eway Met r ic St at us TTL
150.1.0.0 255.255.0.0 150.1.1.1 5 UP 400
150.2.0.0 255.255.0.0 150.1.2.1 3 UP 350
A simpl e DVMRP r out ing t abl e.
Sour ce subnet : The subnet wor k t hat cont ains a host sour ce.
Subnet mask: The subnet mask of t he Sour ce Subnet .
Fr om-gat eway: The immediat e upst r eam r out er t hat l eads back t o t he sour ce
subnet .
Met r ic: hops (r out er s) t o t he sour ce subnet .
TTL (Time t o Live): Indicat es how l ong t he ent r y in t he t abl e st ays bef or e being
r emoved.
Sour ce Subnet Mul t icast Gr oup TTL Upst r eam Por t Downst r eam Por t s
150.1.0.0 224.0.1.1 430 1 2,3
150.2.0.0 224.0.1.2
224.0.2.5 500
300 1
3 3
5
A DVMRP f or war ding t abl e.
Any int er f ace t hat is designat ed a l eaf net wor k, or any downst r eam r out er s f or t he
sour ce gr oup wil l be incl uded in t he downst r eam por t s. The upst r eam por t is det er mined
by t he unicast r out ing t abl e in t hat if t his int er f ace has t he shor t est r out e back t o t he
sour ce subnet of t his gr oup, it is r egist er ed as t he upst r eam int er f ace wit h t hat por t
designat ion. The f or war ding t abl e is cr eat ed t o r epr esent t he l ocal r out er s
under st anding of t he shor t est -pat h sour ce-r oot ed del iver y t r ee f or each (sour ce,
gr oup) pair .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 277
DVMRP Route Tables
To buil d a unicast r out e t abl e, t he upst r eam DVMRP r out er is dependent on ot her
downst r eam r out er s f or inf or mat ion. The inf or mat ion t hat is sent t o ot her DVMRP
r out er s is cal l ed a route report. The met r ics in t he r out e r epor t s ar e t he most impor t ant
f iel ds of t he r epor t . This not onl y buil ds t he sour ce subnet wor k t abl e (indicat ing t he
sour ce subnet wor ks and t heir r eachabil it y), but al so al l ows f or t he buil ding of a
f or war ding t abl e t hat indicat es t o t he r out er which downst r eam r out er s ar e depending
on t hat upst r eam r out er f or f or war ding mul t icast dat agr ams t o t hem. Upst r eam r out er s
send r out e r epor t s t o t heir downst r eam neighbor s indicat ing sour ce subnet s and t heir
met r ics. Like RIP, t he met r ic t o a sour ce subnet is t he cumul at ive cost of al l t he
incoming int er f aces so f ar . The r out e r epor t s wil l be sent t o a DVMRPs neighbor
r out er . Cont ained in t his l ist ar e sour ce subnet s and met r ics (in t he r ange of 131).
If a downst r eam r out er wishes t o indicat e t o an upst r eam r out er t hat it is dependent on
it f or r eceiving mul t icast dat agr ams f or a par t icul ar sour ce subnet , t hat downst r eam
r out er wil l echo t he r out e back t o t he upst r eam neighbor wit h a met r ic higher t han 32.
Inf init y f or DVMRP is consider ed t o be 32. Ther ef or e, t he downst r eam neighbor wil l add
32 t o t he incoming met r ic and echo t his back t o t he upst r eam r out er . This r el ies on a
t echnique known as poison reverse. When t he upst r eam r out er r eceives t his updat e, and
sees t he met r ic f or t he sour ce subnet wor k in t he r ange bet ween inf init y t o t wice
inf init y, t hen t he upst r eam r out er wil l add t he downst r eam r out er t o a l ist of
dependent r out er s f or t hat sour ce. The val ue of inf init y is 32 and indicat es t hat a
sour ce net wor k is not r eachabl e. The r ange of met r ics may be bet ween 163. The
or iginal met r ic of t he sour ce is 131, 32 means not r eachabl e, and 3363 is t he poison
r ever se met r ic of a downst r eam r out er t el l ing it s upst r eam r out er t hat it want s t o be
added t o it s t abl e f or mul t icast dat agr ams of a given sour ce.
DVMRP Rout e Tabl es
To buil d a unicast r out e t abl e, a DVMRP t abl e is dependent on ot her
downst r eam r out er s or inf or mat ion.
Met r ics ar e dif f er ent t han t hose used by t ypical t abl es.
Rel ies on t he pr ot ocol of poison r ever se.
Met r ics r ange f r om 1 t hr ough 63.
Inf init y is a r out e wit h a hop count of 32.
131 is t he or iginal met r ic of t he sour ce.
32 is inf init y.
3363 is t he poison r ever se met r ic of a downst r eam r out er t el l ing it s upst r eam
r out er t hat it want s t o be added t o t he downst r eam t abl e.
Why not just use t he exist ing unicast r out ing t abl e l ike a RIP2 t abl e? The r eason is
t hat not al l r out er s wil l be r unning DVMRP and mul t icast r out er s must be abl e t o
int er act wit h nonmul t icast r out er s. In or der t o accompl ish t his, we must buil d t unnel s
acr oss nonmul t icast r out er s. Wit h t unnel s, we ef f ect ivel y f or ce t he pat h t hat t he
mul t icast dat agr am wil l t ake. The t unnel may t ake one r out e, but a r egul ar unicast
packet may t ake anot her r out e pat h. Wit h t his, a r out er s unicast t abl e may not
coincide wit h a DVMRP r out er s unicast t abl e. Ther ef or e, we use t he unicast
inf or mat ion in DVMRP excl usivel y t o det er mine t he shor t est r out e back t o t he sour ce
subnet of a mul t icast dat agr am.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 278
DVMRP Tunneling
RFC 2003 descr ibes IP encapsul at ion or t unnel ing. It is not necessar y and can be t he
case many t imes, t o have al l r out er s r unning a mul t icast pr ot ocol . The quest ion is, how
do you get mul t icast dat agr ams t hr ough t he Int er net ? Most r out er s on t he Int er net
ar e not r unning a mul t icast pr ot ocol . The answer is tunneling. Wit h t unnel ing, you buil d
isl ands of mul t icast aut onomous net wor ks and t hey communicat e wit h one anot her
over t he Int er net by t unnel ing t he mul t icast dat agr am over t he Int er net .
DVMRP suppor t s t he abil it y t o t unnel a mul t icast dat agr am t hr ough nonmul t icast
r out er s. The mul t icast dat agr am is encapsul at ed in a unicast IP packet and addr essed t o
t he r out er s t hat do suppor t nat ive mul t icast r out ing. In ot her wor ds, we wr ap t he
mul t icast packet in an IP header and t el l it which pat h t o t ake t o a dest inat ion
mul t icast r out er .
To encapsul at e an IP dat agr am using IP-in-IP encapsul at ion, an IP header is inser t ed
bef or e t he exist ing IP dat agr am header . The sour ce and dest inat ion addr ess of t he out er
IP header ar e descr ibed in t he input and out put of t he t unnel or t he t unnel endpoint s.
The or iginal IP header cont ains t he IP sour ce and dest inat ion addr ess of t he or iginat or
and f inal dest inat ion of t he dat agr am.
DVMRP Tunnel ing

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 279
IP-in-IP Packet Format
The sl ide shows IP-in-IP packet encapsul at ion f or t unnel ing.
IP-in-IP Packet For mat

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 280
Protocol-Independent Multicast (PIM)
DVMRP pr ovides gr eat mechanisms f or mul t icast ing. Using t he l at est ver sions of
IGMP and DVMRP, a f ul l y f unct ional mul t icast t r ee can be dynamical l y buil t and
ut il ized f or voice, video, and dat a. Ther e is, however , a disadvant age t o DVMRP: It does
not scal e wel l . DVMRP is a dist ance-vect or mul t icast r out ing updat e pr ot ocol . DVMRP
br oadcast s t he f ir st mul t icast packet it r eceives f r om t he sour ce and t hen pr unes t he
t r ee based on f eedback f r om ot her r out er s. DVMRP is known as a dense mode mul t icast
pr ot ocol , and is most ef f icient when t he cl ient s ar e densel y l ocat ed on t he net wor k. It
does not scal e wel l when t he pr ot ocol is being used over WAN l inks, or when t her e ar e
simpl y a f ew cl ient s scat t er ed t hr oughout t he cust omer s net wor k. This br oadcast and
pr une mechanism, al ong wit h mul t icast r out ing updat es, causes unnecessar y over head
over l ow-bandwidt h media t ypes. Fur t her mor e, DVMRP r out ing t abl es ar e based on a
RIP-l ike updat e. DVMRP al so r equir es t he r out er s t o keep st at e inf or mat ion. This
incl udes gr oup and sour ce inf or mat ion t hat is used t o cal cul at e a t r ee.
If al l t he member s of a mul t icast gr oup ar e l ocat ed in a bandwidt h-r ich r egion
(suppor t ed by high-speed LANs and not l ow-speed WANs), t hen it shoul d be suppor t ed by
a dense mode pr ot ocol such as DVMRP, MOSPF, or PIM-Dense Mode (DM). This can be
l imit ing in t hat t he scope of t he gr oup cannot incl ude any member s beyond t he scope of
t he domain wit hout pl acing t he unnecessar y bur den of Br oadcast and Pr une messages
and possibl y mul t icast r out ing updat es over t he l ink t hat incl udes t hat r emot e
r eceiver .
Pr ot ocol -Independent Mul t icast (PIM)
DVMRP is a good pr ot ocol , but it does not scal e wel l .
Ext r a over head wit h t he RIP-l ike buil t r out ing t abl e.
Rout e r epor t s
Known as a dense-mode pr ot ocol .
Inef f icient over l ess densel y popul at ed net wor ks
PIM of f er s t wo ver sions:
Dense mode (simil ar t o DVMRP)
Spar se mode
PIM of f er s t wo ver sions f or mul t icast r out ing: dense mode and sparse mode.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 281
PIMDense Mode (PIM-DM)
PIMDense Mode (PIM-DM)
Simil ar t o DVMRP but does not buil d it s own unicast r out ing t abl e.
Less compl ex t han DVMRP.
It wil l cont inue t o br oadcast packet s unt il Pr une messages ar e r eceived
Accept s dupl icat e packet s in a t r ade of f f or ef f iciency.
Assumes al l downst r eam int er f aces want t o r eceive al l mul t icast packet s.
Thr ee mechanisms used t o buil d a mul t icast t r ee:
Pr une
Gr af t
Leaf Net wor k det ect ion
Dense Mode is t he easiest t o expl ain, especial l y if you have r ead t he pr evious sect ion on
DVMRP. It f unct ions simil ar t o DVMRP in t hat it uses RPM t o buil d sour ce-r out ed
mul t icast t r ees. However , unl ike DVMRP, PIM does not r el y on a independent unicast
r out ing pr ot ocol .
When a mul t icast packet ar r ives on a PIM-DM int er f ace, it is f or war ded t o al l
int er f aces unt il t he br anches ar e specif ical l y pr uned. Unl ike DVMRP, PIM-DM wil l
cont inue t o f or war d mul t icast packet s unt il specif ic Pr une messages ar e r eceived. No
t abl es ar e buil d f r om t hese pr une messages. DVMRP uses a r out ing t abl e t o det er mine if
t her e ar e downst r eam r out er s t hat want t o r eceive t he mul t icast dat agr ams f or a
specif ic gr oup. DVMRP, r el ying on a r out ing t abl e t hat is sent t o al l mul t icast r out er s,
is mor e sel ect ive when it f or war ds messages dur ing t he const r uct ion of a sour ce-r oot ed
mul t icast t r ee. The r easoning behind t his is t hat simpl icit y and pr ot ocol independence
ar e consider ed a higher pr ior it y t han addit ional over head caused by packet dupl icat ion.
Buil ding a unicast r out ing t abl e vir t ual l y el iminat es dupl icat e packet s. PIM-DM
accept s dupl icat e packet s as an al t er nat ive t o not become dependent on a unicast
r out ing pr ot ocol , and t her ef or e avoids buil ding yet anot her r out ing dat abase. PIM-DM
assumes t hat al l downst r eam int er f aces want t o r eceive mul t icast dat agr ams. PIM was
act ual l y buil t f or spar se-mode mul t icast net wor ks and DM was added f or simpl e
f unct ional it y. PIM-DM does not cont ain t he concept of r endezvous point s and t her e ar e
no per iodic joins (however , t he Join message is st il l used). Ther e cur r ent l y is a dr af t RFC
t o al l ow f or bor der r out er s, which al l ow PIM and DVMRP int er oper abil it y. (The RFC
can be f ound at net web.usc.edu/pim/.)
PIM-DM is l ess compl ex t han DVMRP. Ther e ar e t hr ee mechanisms t hat PIM-DM uses t o
buil d a mul t icast t r ee: Pr une, Gr af t , and Leaf net wor k det ect ion.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 282
PIMDense Mode Operation
When a mul t icast dat agr am is r eceived, it s incoming int er f ace is l ooked up in t he
unicast r out ing t abl e; t her ef or e, t he r out er must be r unning some t ype of unicast
r out ing pr ot ocol (r emember t he name, Protocol Independent Mul t icast ). If t he r eceiver
int er f ace is t he one on which t he r out er f or war ds unicast dat agr ams back t o t hat
subnet , t he mul t icast dat agr am is accept ed and f or war ded t o al l por t s except t he
incoming int er f ace. If not , t he dat agr am is simpl y discar ded wit hout er r or messages
being sent (sil ent l y discar ded). Fr om her e, t he r out er checks f or a f or war ding st at e f or
t he gr oup addr ess. If t her e is not an ent r y f or t he gr oup addr ess, t he r out er adds one.
The r out er checks t he out going int er f ace l ist t o see whet her it shoul d f or war d t he
dat agr am. This l ist cont ains a l ist ing of int er f aces f r om which t he r out er has hear d
gr oup member ship or PIM r out er messages. The PIM-DM r out er s messages can be Hel l o,
Pr une, Join, or Gr af t . If t her e is an act ive int er f ace(s), t he r out er f or war ds t he
dat agr am out t hose int er f aces. If no int er f aces ar e indicat ed, a Pr une message is sent .
The int ended r eceiver r out er of t hat Pr une message wil l be pl aced in t he message (not
in t he IP header ). The downst r eam r out er knows t his addr ess by doing an RPF l ookup in
t he unicast r out ing t abl e. When t he r eceiver r out er r eceives t his Pr une r equest , it wil l
schedul e a del et ion of t hat LAN int er f ace f or t hat gr oup, which means it inser t s a
del ay bef or e del et ion. It is wait ing t o see if any ot her r out er s r espond. Ot her r out er s
on t he subnet wil l al so r eceive t his Pr une message and wil l in t ur n send a Join message
t o t hat r out er , f or cing it t o cancel t he del et ion of t he LAN int er f ace f or t he (sour ce,
gr oup) pair . Just because one r out er pr unes doesnt mean t her e ar ent ot her r out er s on
t hat same LAN t hat want t o cont inue r eceiving inf or mat ion f or t he gr oup addr ess.
PIMDense Mode Oper at ion
No ent r ies in t he out going l ist coul d be a r esul t of no gr oup member s on t he int er f ace
and t he r out er not r eceiving any PIM-Hel l o messages f r om ot her r out er s l ocat ed on
t hat subnet (t his al l ows f or l eaf net wor k det ect ion, in t hat in absence of t hese
messages, onl y mul t icast host s r eside on a subnet ). A r out er wil l keep t r ack of t he l eaf
member s (l ocal -gr oup dat abase buil t by IGMP) and wil l al so cont ain a l ist ing of r out er s
as wel l . When a r out er is not hear d f r om wit hin a specif ied amount of t ime, t he r out er
del et es t hat r out er s ent r y f r om t he l ist .
Pr uned st at es f or any mul t icast ent r y ar e event ual l y t imed out , f or cing al l mul t icast
dat agr ams t o be f or war ded on al l int er f aces again, unt il t he mul t icast t r ees ar e
pr uned.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 283
Adding Interfaces
A r out er can add int er f aces f or which it r eceived a Gr af t message (r ejoin a br anch f or a
gr oup) or an IGMP member ship r epor t . If t he r out er al r eady has st at e inf or mat ion about
a gr oup (it has buil t an ent r y f or t he gr oup), it simpl y adds or r ef r eshes t he int er f ace
ent r y on which t he IGMP message or Gr af t message was r eceived. If t he out going l ist
ent r y is empt y, t he r out er wil l send a Gr af t message upst r eam t owar ds t he sour ce. Any
r out er t hat r eceives t his message wil l use t hat r eceived int er f ace as t he out going
int er f ace f or t he exist ing (sour ce, gr oup) pair .
If t he r out er has no st at e inf or mat ion at al l f or t he (sour ce, gr oup) pair , it wil l do
not hing, f or it knows t hat PIM-DM r out er s wil l del iver a mul t icast dat agr am t o al l
int er f aces when cr eat ing a st at e f or t he gr oup.
PIM-Gr af t messages ar e posit ive acknowl edged. A PIM-Gr af t message is unicast t o t he
upst r eam r out er . The upst r eam r out er changes t he Gr af t message int o a Gr af t ACK and
sends it back t o t he or iginat ing r out er .
Adding Int er f aces
Rout er s add int er f aces by using t he Gr af t message.
When a r out er r eceives a Gr af t it wil l make one of t he f ol l owing decisions:
If t he r out er al r eady has inf or mat ion about t he gr oup, it simpl y adds or
r ef r eshes t he int er f ace f or t hat gr oup.
If t he out going l ist is empt y (but it knows about t he gr oup) t hat r out er
wil l send a Gr af t message upst r eam.
If t he r out er does not know about t he gr oup, it wil l do not hing wit h
t he r eceived Gr af t message knowing t hat mul t icast dat agr ams f or an
unknown gr oup wil l al ways be f or war ded and it wil l wait f or t hose
f r ames.
Gr af t messages ar e acknowl edged by each r out er t o t he sour ce of t he Gr af t
message.
It is unicast t o upst r eam r out er s.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 284
PIMSparse Mode (PIM-SM)
PIMSpar se Mode (PIM-SM)
Used in spar sel y popul at ed mul t icast net wor ks.
Uses t he concept of a r endezvous point :
A pl aces wher e al l sour ces and dest inat ions meet each ot her
Rout er s f ind RP f or a gr oup addr ess and unicast dat agr ams t o t he RP t o be
r edist r ibut ed.
Al l PIM r out er s f ind each ot her .
One r out er is sel ect ed t he Designat ed Rout er (DR) by IGMPv2.
When a new neighbor is f ound, t he RP addr ess is sent t o it by it s DR.
The DR is al so r esponsibl e f or sending Join/Pr une commands f or it s l ocal
r eceiver s and sour ces.
PIM-SM was designed t o r est r ict mul t icast t r af f ic onl y t o t hose r out er s t hat have a
need f or t he mul t icast packet . In PIM-SM, a specif ic r out er (f or r edundancy and
scal abil it y, some PIM-SM impl ement at ions al l ow f or mor e t han one r endezvous point ,
but t hat is beyond t he scope of t his book) is known as t he rendezvous point (RP). Sender s
and r eceiver s join a mul t icast gr oup by r egist er ing at t he r endezvous r out er . Rout er s
f ind out t heir RP (expl ained l at er on sl ide 313) and t hen send r eceived mul t icast
dat agr ams as unicast dat agr ams t o t he RP. The RP r out er r edist r ibut es mul t icast
dat agr ams out t he gr oup t r ees t hat it has buil t . A r endezvous point is simpl y an IP
addr ess of a singl e r out er and is used by sender s t o announce t hemsel ves and f or
r eceiver s t o f ind out about new sender s f or a gr oup.
Al l r out er s r unning PIM per iodical l y (ever y 30 seconds by def aul t ) t r ansmit Hel l o
messages t o each ot her , f or t he pur pose of discover ing ot her PIM r out er s using 224.0.0.13
(ALL_ PIM_ROUTERS gr oup addr ess). This is l ocal mul t icast t hat is in t he r ange of not
being al l owed t o t r aver se a r out er . When a PIM r out er r eceives t his message, it st or es
t he IP addr ess f or t hat neighbor . Each PIM r out er ent r y wil l have it s own t imer f or
r epeat Hel l o messages. This t ime is incl uded in t he r eceived Hel l o message and t he
r out er wil l not e t his t ime in it s t abl e (set t o 3.5 * Hel l o Per iod (30 seconds) or def aul t
t o 105 seconds). If t he r out er does not per iodical l y hear f r om t he neighbor , it wil l t ime-
out and del et e t hat neighbor f r om t he t abl e. When t he DR (sel ect ed by IGMPv2)
r eceives a new ent r y (a new r out er ), it unicast s it s most r ecent RP addr ess inf or mat ion
t o t he new neighbor .
A r out er known as t he designated router (t he DR, usual l y an IGMPv2 f unct ion) is
r esponsibl e f or sending Join/Pr une commands t o t he RP on behal f of it s l ocal r eceiver s
and sour ces. The choice of t he DR is not based on t he IGMP quer ier , nor is it based on t he
l ong-t er m, l ast -hop r out er f or t he gr oup. The r out er wit h t he highest IP addr ess wit hin
al l t he r eceived Hel l o messages is el ect ed DR. The l ast -hop r out er is t he l ast r out er t o
r eceive mul t icast messages bef or e t hey ar e del iver ed t o t he l ocal r eceiver s. If t his is t he
case, t hen t his r out er wil l be t he DR.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 285
Types of Multicast Trees Using PIM-SM
Mul t icast t r ees ar e st il l buil t using PIM, but t her e ar e t wo t ypes:
Shar ed Tr ee (Rendezvous Point (RP) r oot ed t r ees): Indicat ed by a (*,G) in t he
r out ing t abl e, which indicat es a shar ed t r ee f or t he mul t icast Gr oup G.
Sour ce-Root ed Tr ee (or SRT t r ee): Indicat ed by a (S,G) in t he r out ing t abl e. A
sour ce-r oot ed t r ee has been buil t f or t he mul t icast Gr oup G and is sour ced by t he
IP addr ess(es).
Like al l ot her mul t icast r out ing pr ot ocol s, PIM conveys it s messages in IGMP header
dat a packet s. If a host (r eceiver ) want s t o join a gr oup, it wil l convey it s member ship
inf or mat ion t hr ough IGMP. When a PIM r out er r eceives t his IGMP message, t he DR l ooks
up t he associat ed RP. The DR cr eat es a wil dcar d ent r y f or t he gr oup, which is wr it t en
as (*,G). The DR cr eat es a Join/Pr une message (bot h Join and Pr une ent r ies ar e incl uded
in t he same message). The f l owchar t f or t his pr ocess is shown in t he sl ide. PIM wor ks in
conjunct ion wit h IGMP.
For a given (sour ce, gr oup) a mul t icast t r ee is init ial l y buil t ar ound t he RP r out er . This
init ial t r ee is cal l ed a shared tree in t hat al l member s of t he gr oup conver se using t his
singl e shar ed t r ee (al beit , it may not be t he shor t est pat h bet ween a sour ce and a host ).
It is easy t o const r uct , r educes t he amount of over head in t he r out er (t abl es, st at e
inf or mat ion, et c.), and is easy t o impl ement ; however , it may not be ef f icient . Shar ed
t r ees ar e buil t based on t he cent er point r endezvous r out er . This shar ed t r ee may not
al l ow f or t he shor t est t r ee t o be buil t bet ween a sour ce and some r eceiver host s.
Types of Mul t icast Tr ees using PIM-SM
Two t ypes of t r ees can be buil t :
Shar ed Tr ee (RP r oot ed t r ees)
Sour ce Root ed Tr ees
The PIM pr ot ocol can adapt her e as wel l . Based on t he dat a r at e, af t er t he shar ed t r ee
is const r uct ed (af t er meet ing at t he r endezvous point ) bet ween a host r eceiver and a
sour ce, it can change f r om being a shar ed t r ee t o a shor t est -pat h t r ee. The r out er sends
a Join command dir ect l y t o t he sour ce and a mul t icast t r ee is buil t . The or iginal pat h
t hr ough t he r endezvous r out er is t or n down.
An impor t ant point needs t o be br ought out her e: PIM, l ike ot her mul t icast al gor it hms,
uses RPF. Since PIM-SM uses bot h sour ce-r oot ed t r ees and RP-r oot ed t r ees (expl ained
l at er ), t he RPF check is done dif f er ent l y f or sour ce t r ees and shar ed t r ees. If a PIM
r out er has a sour ce-r oot t r ee st at e, it does t he RPF check f r om t he sour ce IP addr ess of
t he mul t icast packet . If t he r out er has a shar ed-t r ee st at e (and no expl icit sour ce-t r ee
st at e), it does t he RPF check on t he RPs addr ess (which is known when member s join t he
gr oup).
PIM-SM uses t he RPF l ookup f unct ion t o det er mine wher e it needs t o send Joins and
Pr unes.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 286
Joining a Group
Ar out er wit h dir ect l y connect ed neighbor s must f ir st join t he shar ed t r ee. When t he
DR get s a member ship not if icat ion f r om a host , it l ooks up t he associat ed RP f or t hat
gr oup (mor e inf or mat ion on t he RP is coming up). The DR cr eat es a wil dcar d mul t icast
ent r y f or t he gr oup in t he f or m of (*,G). If t her e is not a specif ic mat ch f or t he gr oup,
t he packet is f or war ded accor ding t o t his ent r y. The RP addr ess is cont ained in a special
f iel d in t he r out e ent r y and is incl uded in per iodic Join/Pr une messages.
The DR sends a Join message t o t he pr imar y RP. The (*,G) ent r y indicat es a (any sour ce,
gr oup) pair . The int er mediat e r out er (B) f or war ds t he unicast PIM-JOIN message. Rout er
B al so cr eat es a f or war ding cache ent r y f or t he (*,G) pair , so t hat t hey wil l know how
t o f or war d mul t icast dat agr ams f or t he gr oup.
The sl ide shows t he sequence of joining a gr oup.
Joining a Gr oup

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 287
A Host Sending to a Group
When a host t r ansmit s a mul t icast packet t o a specif ic gr oup, t he designat ed r out er
(chosen by IGMPv2) f or war ds t he mul t icast dat agr am as a unicast dat agr am t o t he RP.
This unicast dat agr am is t he mul t icast dat agr am encapsul at ed as a PIM-SM-Regist er
packet . This t ype of packet inf or ms t he RP of a new sour ce. The RP st r ips of f t he
encapsul at ed (r egist er ) header s and r edist r ibut es t he mul t icast dat agr am out t he
del iver y t r ee. The act ive RP f or t hat sour ce t r ansmit s PIM-JOIN messages back t o t he
sour ce st at ions DR. The r out er s l ying bet ween t he sour ces DR and t he RP maint ain t he
pat h inf or mat ion by t he r eceived PIM-JOIN messages. This is done so t hat when
nonr egist er ed encapsul at ed packet s ar e r eceived, t hey wil l know what int er f aces t o
f or war d t hem on. The RP wil l send t he unicast dat agr am back out as a mul t icast
dat agr am acr oss t he gr oups mul t icast t r ee. The sour ces DR wil l cont inue t o
encapsul at e t he mul t icast dat agr ams and send t hem t o t he RP. When t he DR r eceives a
Regist er -St op message f r om t he RP (t he RP sends t hese messages if t he RP has no
downst r eam r eceiver s f or t he gr oup or f or t hat sour ce) it wil l al so send Regist er -St op
messages if t he RP has al r eady joined t he (S,G) t r ee and is r eceiving t he dat a packet s
nat ivel y (unencapsul at ed). A t imer is used by t he DR and if t his t imer expir es, it wil l
st ar t t o r esend t he mul t icast dat agr ams encapsul at ed in Regist er messages.
The sl ide shows t he sequence of a host sending t o a gr oup.
A Host Sending t o a Gr oup

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 288
Converting to a Source-Rooted Tree
The init ial t r ee buil t in PIM-SM is t he shar ed RP-t r ee. However , based on dat a
t hr eshol ds t hat ar e r el at ive t o t ime, t he t r ee can be conver t ed t o sour ce-r oot ed t r ees.
Conver t ing t o a Sour ce-Root ed Tr ee

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 289
Rendezvous Points
PIM-SM uses specif ic r out er s known as t he rendezvous point (RP) t o st ar t out t he
shar ed t r ee. Sender s and r eceiver s join a mul t icast gr oup by r egist er ing at t heir
r endezvous r out er . A r endezvous point is simpl y an IP addr ess of a singl e r out er . These
point s ar e used by sender s t o announce t hemsel ves and f or r eceiver s t o f ind out about
new sender s f or a gr oup.
Wher e and how is t he RP f ound? Ther e is one r out er in a singl e PIM domain (a
cont iguous set of r out er s t hat al l impl ement PIM) cal l ed t he bootstrap router (BSR). This
r out er is r esponsibl e f or sending out Boot st r ap messages. The BSR is dynamical l y
el ect ed and dist r ibut es inf or mat ion about t he RP. BSR inf or mat ion is sent t o each
r out er in t he PIM domain. To f ind out about RPs, al l r out er s wit hin a PIM domain
col l ect Boot st r ap messages and st or e t he inf or mat ion cont ained in t he BSR messages.
If a r out er wishes t o wor k as an RP, it becomes a candidate RP (C-RP). C-RPs send out
Adver t isement messages t o t he BSR f or t he domain. Inside t he adver t isement s ar e t he
Gr oup Addr ess and t he Gr oup Mask (pr ef ix) f iel ds f or which it can become t he RP; in
ot her wor ds, what gr oup addr ess r anges it can suppor t as an RP. This r ange can be one
gr oup t o al l gr oups. This al l ows t he BSR t o dist r ibut e RP inf or mat ion t o ot her PIM
r out er s in t he domain using t he Al l -PIM-Rout er s message.
Rendezvous Point s
PIM-SM uses specif ic r out er s known as RP t o st ar t out a shar ed t r ee.
Sender s and r eceiver s join a mul t icast gr oup by r egist er ing t he gr oup addr ess
wit h t heir RP.
RP is simpl y one or mor e r out er s associat ed wit h a mul t icast addr ess.
One r out er in t he PIM-SM domain is known as t he Boot st r ap Rout er (BSR).
A simpl e el ect ion pr ocess is used t o det er mine t he one BSR
The BSR dist r ibut es inf or mat ion about t he RP
PIM r out er s col l ect and st or e BSR inf or mat ion
A r out er t hat wishes t o become an RP sends out messages indicat ing t his and
f or what gr oups.
The BSR dist r ibut es t his inf or mat ion.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 290
Comparison of Sparse- and Dense-Mode Protocols
Spar se Mode Dense Mode
Requir es expl icit joining of sender s and
r eceiver s. Does not send packet s wher e
t hey have not been r equest ed.
Sends and st or es expl icit pr une
inf or mat ion in r esponse t o unwant ed
packet s.
St or es shar ed-t r ee join inf or mat ion in
ant icipat ion of dat a packet s.
St at el ess unt ol l dat a packet s ar e sent .
Rel ies on an RP init ial l y f or sender s and
r eceiver s t o meet and buil d a shar ed t r ee.
No RP, t he br oadcast nat ur e of t he
pr ot ocol buil ds t he t r ee.
Unicast pr ot ocol independent . Unicast pr ot ocol dependent .
Requir es per iodic r ef r eshing of expl icit
Join/Pr une messages.
No per iodic updat es on Pr une messages,
event dr iven.
PIM-Spar se Mode is model ed af t er t he Cor e-Based Tr ee al gor it hm. However , t he
dif f er ence bet ween t he t wo is t hat CBT uses one t r ee, cent er ed at a cor e r out er ,
inst ead of at t he sour ce of a mul t icast dat agr am. CBT buil ds a singl e t r ee f or al l
member s in a gr oup.
Compar ison of Spar se- and Dense-Mode Pr ot ocol s
Spar se Mode Dense Mode
Requir es expl icit joining of sender s and
r eceiver s
Sends and st or es expl icit pr une st at e and
r eceiver s inf or mat ion in r esponse t o
unwant ed packet s
Does not send packet s wher e t hey have
not been r equest ed
Br oadcast s t he f ir st mul t icast packet
St or es shar ed-t r ee join inf or mat ion in
ant icipat ion of dat a packet s
St at el ess unt il dat a packet s ar e sent
Rel ies on an RP init ial l y f or sender s and
r eceiver s t o meet and buil d a shar ed t r ee
No RP, t he br oadcast nat ur e of t he
pr ot ocol buil ds t he t r ee
Unicast pr ot ocol independent Unicast pr ot ocol dependent
Requir es per iodic r ef r eshing of expl icit
Join/Pr une messages
No per iodic updat es on Pr une messages;
event dr iven

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 291
Multicast Open Shortest Path First (MOSPF)
Review RFC 1584. If you ar e not f amil iar wit h t he OSPF (RFC 1583) pr ot ocol , pl ease
r eview t he sect ion on t hat pr ot ocol . Ther e ar e assumpt ions about t hat pr ot ocol t hat
ar e made her e.
Modif icat ions have been made t o t he OSPF r out ing pr ot ocol t hat have enabl ed t he
pr ot ocol t o r out e IP mul t icast dat agr ams. Ther e ar e t hr ee t ypes of r out ing pr ovided:
int r a-ar ea r out ing, int er -ar ea r out ing, and int er -aut onomous syst em r out ing.
Int r a-ar ea r out ing is t he most basic r out ing al gor it hm pr ovided. It r uns in a singl e OSPF
ar ea and suppor t s t he f or war ding of mul t icast dat agr ams wit hin a singl e ar ea. This
coul d be a singl e ar ea in a mul t ipl e ar ea of an OSPF aut onomous syst em, or it coul d be a
singl e aut onomous syst em when t her e is onl y one ar ea in t he OSPF t opol ogy.
Int er -ar ea r out ing is an OSPF t opol ogy t hat is spl it int o sever al r out ing ar eas
connect ed t hr ough a common ar ea known as t he backbone ar ea. Decisions on f or war ding
mul t icast dat agr ams ar e st il l det er mined as in t he int r a-ar ea r out ing; t he inf or mat ion
cont ained in t he f or war ding cache is used. The dif f er ence bet ween t he t wo is t he
met hod of f or war ding gr oup member ship inf or mat ion and t he met hod of const r uct ing
t he int er -ar ea mul t icast t r ee. Sel ect ed Ar ea Bor der Rout er s (ABRs) ar e conf igur ed t o
per f or m a f unct ion known as int er -ar ea mul t icast r out er s. These r out er s ar e
r esponsibl e f or t he f or war ding of gr oup member ship inf or mat ion and mul t icast
dat agr ams bet ween ar eas.
An ext ension of OSPF [RFC 1584] Mar ch 1994.
A new LSA [gr oup-member ship-LSA] is used t o descr ibe t he l ocat ion of
mul t icast dest inat ions.
A mul t icast packet s pat h is cal cul at ed using a shor t est -pat h t r ee based on
t he IP dat agr ams sour ce and dest inat ion.
It is not based on a Br oadcast and Pr une
Mul t icast Host s join/l eave via IGMP [RFC 1112] f acil it ies.
Br anches of t he t r ee not cont aining mul t icast member s ar e pr uned f r om t he
t r ee.
Vendor specif ic impl ement at ions can do r out e pr uning f or bet t er member
administ r at ion.
Thr ee t ypes of r out ing ar e pr ovided:
Int r a-ar ea, int er -ar ea, and int er -aut onomous syst em r out ing
Int er -aut onomous r out ing invol ves a sour ce and dest inat ion pat h t hat is out side at
l east one aut onomous syst em (AS). Sel ect ed Aut onomous Syst em Boundar y Rout er s
(ASBRs) ar e sel ect ed as int er -AS mul t icast f or war der s. MOSPF makes t he assumpt ion
t hat each int er -AS mul t icast f or war der is r unning a mul t icast r out ing pr ot ocol (such
as PIM or DVMRP) t hat uses t he RPF f or war ding mechanism. This is t he met hod used by
MOSPF t o l eave it s AS and r out e t o anot her AS t hat coul d be r unning anot her r out ing
pr ot ocol , or t o get acr oss t he unicast Int er net (since MSOPF does not suppor t t unnel s).

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 292
MOSPF Differences
MOSPFdif f er s f r om DVMRP and PIM is many ways, but it shoul d be not ed r ight up
f r ont t hat MOSPF does not br oadcast t he f ir st mul t icast packet it r eceives. The
pr ot ocol buil ds a sour ce-r oot ed, shor t est -pat h t r ee on demand when it r eceives t he
f ir st mul t icast packet and t hen pr unes t he br anches not associat ed wit h t his gr oup.
Al so, MOSPF does not al l ow f or t unnel ing as DVMRP does. Mul t icast dat agr ams ar e
sent in nat ive mode and ar e not encapsul at ed (DVMRP uses IP-in-IP encapsul at ion f or
t unnel ing).
A dif f er ence bet ween OSPF and MOSPF is t hat MOSPF does not al l ow f or equal -cost
mul t ipat hs. Ther e ar e t ie-br eaking r ul es t hat have been ident if ied f or pat hs t hat ar e
f ound t o be equal when cal cul at ing t he shor t est -pat h t r ee. One of t hese r ul es is t hat ,
given an equal -cost pat h t o a dest inat ion, t he r out er or LAN wit h t he higher IP addr ess
wil l be chosen. The second t ie-br eaking r ul e is t hat a br oadcast -or ient ed net wor k is
al ways chosen over WAN r out er s (point -t o-point l inks).
MOSPF Dif f er ences
MOSPF dif f er s f r om DVMRP and PIM:
It does not br oadcast t he f ir st mul t icast packet it r eceives
Mul t icast is an int egr al par t of t he pr ot ocol .
The pr ot ocol buil ds a sour ce-r oot ed t r ee on-demand and t hen pr unes
br anches.
Mul t icast member s ar e par t of t he l ink st at e dat abase.
Rout es ar e comput ed l ike r eal r out es and t hey ar e put int o t he f or war ding
cache.
MOSPF does not al l ow f or equal cost mul t ipat h:
Tie-br eaking al gor it hms have been put int o pl ace
MOSPF r out es shoul d be t he DR and BDR in any mixed (i.e., non-MOSPF)
envir onment s.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 293
MOSPF Caveats
OSPF al l ows f or an aut onomous syst em t o be spl it int o ar eas. Pr obl ems may occur
when using MOSPF in a mul t i-ar ea OSPF t opol ogy, f or t he abil it y of a r out er t o have
compl et e knowl edge of t he ent ir e aut onomous syst em is l ost and incompl et e shor t est -
pat h t r ees ar e buil t . Mul t icast s wil l st il l get t hr ough, but t hey may t ake t he most
ef f icient pat hs.
MOSPF Caveat s
MOSPF onl y oper at es ef f ect ivel y in pur e OSPF envir onment s, wher eas most
net wor ks combine:
Dif f er ent IGPs, such as RIP wit h OSPF
IGPs wit h EGPs, such as BGP-4 wit h EGPs
MOSPF assumes net wor k t opol ogy in a mul t i-ar ea t opol ogy.
MOSPF is known as a dense-mode mul t icast pr ot ocol .
MOSPF can scal e t o l ar ge number s of mul t icast gr oups but it comes at a cost
of pr ocessing r esour ces.
MOSPF has been impl ement ed by a f ew vendor s.
No abil it y t o t unnel mul t icast dat agr ams t hr ough nonmul t icast r out er s
(MOSPF r out er s can f or war d unicast ).

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 294
Local-Group Database and the Group-Membership
LSA
MOSPF pr ovides f or t he abil it y t o f or war d mul t icast dat agr ams f r om one IP subnet t o
anot her . A new OSPF l ink-st at e adver t isement (gr oup-member ship LSA) has been added
t o accommodat e t his by al l owing a sour ce-r oot ed, pr uned, shor t est -pat h t r ee t o be
buil t . This new LSA augment s t he l ink-st at e dat abase; t her ef or e, t he MOSPF dat abase is
t he l ink-st at e dat abase of OSPF but wit h ent r ies t hat per t ain t o mul t icast net wor ks.
The new LSA pl aces t he l ocat ion of mul t icast dest inat ions in t he dat abase. Using t his
inf or mat ion, MOSPF can buil d a shor t est -pat h t r ee f or a sour ce gr oup. MOSPF is an
ext ension of OSPF and MOSPF r out er s wil l int er oper at e in nonmul t icast r out er s when
f or war ding unicast dat agr ams.
An MOSPF r out er bases it s f or war ding decision on t he cont ent s of a dat a cache known
as t he forwarding cache. Each ent r y in t he cache r epr esent s a sour ce/dest inat ion
combinat ion (and possibl y ToS). This f or war ding cache is buil t f r om t wo component s: a
l ocal gr oup dat abase (buil t by IGMP) dat agr ams shor t est -pat h t r ee.
The l ocal -gr oup dat abase keeps t r ack of t he l ocal member ship f or t he r out er s dir ect l y
at t ached t o net wor ks. These ent r ies ar e pair ed in t he f or m of (gr oup, at t ached
net wor k). The at t ached net wor k is t he IP addr ess of t he net wor k, and t he gr oup is t he
IP mul t icast addr ess of t he mul t icast gr oup. Al l we have t o have is one host on t hat
net wor k indicat ing member ship and t he r out er wil l pl ace an ent r y in t he l ocal -gr oup
dat abase. Simil ar t o t he ot her mul t icast r out ing pr ot ocol s, t his dat abase al l ows t he
r out er t o det er mine which por t (s) it shoul d f or war d a r eceived mul t icast dat agr am. The
IGMP pr ot ocol assist s in buil ding t his dat abase.
To al l ow f or mul t icast dat agr ams t o be f or war ded t o al l member s of t he gr oup in an
ar ea, t he l ocal -gr oup dat abase is f l ooded t hr oughout t he ar ea (incl uding being
r eceived by ABRs) using t he gr oup-member ship LSA. Ther e is a separ at e gr oup-member ship
LSA f or each mul t icast gr oup in t he r out er s gr oup dat abase. The r out er s gr oup-
member ship LSA f or a specif ied gr oup l ist s t hose l ocal r out er por t s (i.e., t he r out er
it sel f and/or any dir ect l y connect ed t r ansit net wor ks) t hat shoul d not be pr uned f r om
t he gr oups dat agr am shar ed t r ees.
Local -Gr oup Dat abase and t he Gr oup-Member ship LSA
New LSA devised:
Gr oup-member ship LSA
Based on IGMP r epor t s
Augment s t he l ink-st at e dat abase:
Ther e is not a separ at e dat abase f or t hese LSAs
Separ at e gr oup member ship LSA sent f or each gr oup t o which a host bel ongs.
Mul t icast t r ee is devel oped f r om t his t abl e.
Ent r ies ar e pair ed (gr oup, at t ached net wor k).
Local -gr oup dat abase is f l ooded t hr oughout t he ar ea.
Rout er int er f aces ar e incl uded as par t of a gr oup.
ABRs al so r eceive t hese LSAs.
ABRs ar e incl uded in al most al l mul t icast t r ees:
Wil dcar d f eat ur e t o ensur e t hat t hey know about al l mul t icast t r ees,
which enabl es t hem t o buil d summar y inf or mat ion t o send t o t he backbone

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 295
Role of the DR and the BDR
Rol e of t he DR and t he BDR
The DR issues Host Member ship quer ies f or t he net wor ks at t ached t o it f or
which it is t he DR.
An MOSPF t hat is not t he DR ignor es r epor t s.
Pr event s unnecessar y r epl icat ion of packet s.
The BDR per f or ms t he same f unct ions as t he DR except t hat it does not
t r ansmit quer ies unt il t he DR goes away.
Set non-MOSPF r out er s wit h a pr ior it y of 0 t o ensur e t hey do not become t he
DR or BDR.
It is t he designat ed r out er (DR) t hat issues t he Host Member ship Quer ies f or t he
net wor ks at t ached t o it . An MOSPF r out er ignor es r epor t s f or t hose net wor ks not
el ect ed t he DR. Any r esponses (IGMP r epor t s) r eceived f r om t he net wor ks buil ds ent r ies
based on gr oups, in t he dat abase. A gr oup addr ess (member ) in t his dat abase wil l be
del et ed when t he DR does not r eceive a r epor t f r om t hat member . In a mul t icast
envir onment , it is ver y impor t ant t hat t he DR is a mul t icast -enabl ed r out er .
Having t he DR become t he quer ier pr event s unnecessar y r epl icat ion of packet s. This
pr event s mul t icast dat agr ams f r om being r epl icat ed as t hey ar e del iver ed t o l ocal -
gr oup member s. This al l ows f or dif f er ent ent r ies in t he l ocal -gr oup dat abase f or t he
DRs in t he aut onomous syst em, which means t hat each r out er in t he aut onomous syst em
has a dif f er ent l ocal -gr oup dat abase. However , t he MOSPF l ink-st at e dat abase and t he
dat agr am shor t est -pat h t r ees ar e ident ical in each r out er bel onging t o t he aut onomous
syst em.
The backup designat ed r out er (BDR) per f or ms t he same f unct ions as t he DR. It does not
send out a quer y, but it pr ocesses t he IGMP r epor t s (host r esponses) so t hat it wil l
cont ain a compl et e pict ur e of t he DR. In case t he DR f ail s, t he BDR can t ake over . One
wor d of caut ion: You never want an non-MOSPF r out er t o become t he DR or BDR. To
disabl e t hese r out er s f r om becoming t he DR or BDR, set t heir pr ior it y t o 0. Wit hout t he
DR or BDR being an MOSPF r out er , MOSPF cannot oper at e pr oper l y.
When an IGMP r epor t is r eceived, t he DR (al l ot her r out er s except f or t he BDR discar d
t his message) does some simpl e er r or checking (making sur e t he addr ess is not in t he l ocal
use r ange of 224.0.0.0 244.0.0.255). If t her e is not an ent r y in t he l ocal -gr oup dat abase,
it cr eat es one (using t he f or mat of IP gr oup addr ess, at t ached net wor k number ) and set s
t he age ent r y t o 0. In t he l ocal -gr oup dat abase, t her e is onl y one ent r y per mul t icast
addr ess, even if mul t ipl e host s r epor t member ship. The DR may t r ansmit a new gr oup-
member ship LSA. Gr oup-member ship LSAs ar e onl y f l ooded t o t hose neighbor s t hat have
indicat ed (t hr ough t heir dat abase descr ipt ion packet s) t hat t hey ar e mul t icast r eady.
This is accompl ished by set t ing t he MC (Mul t icast Capabl e) bit in t he OSPF Opt ions f iel d
of al l Hel l o packet s, Dat abase Descr ipt ion packet s, and al l l ink-st at e adver t isement s.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 296
The Local-Group Database
The l ocal -gr oup dat abase consist s of t hr ee component s:
Mul t icast gr oup: A Cl ass D IP addr ess.
At t ached net wor k: The IP addr ess of t he at t ached net wor k t hat cont ains t he
mul t icast gr oup.
Age: The number of seconds since an IGMP Host Member ship r epor t has been seen.
Ot her r out er s f ind out about l ocal -gr oup member s t hr ough t he gr oup-member ship LSA.
Ther e is one LSA f or each mul t icast gr oup t hat has one or mor e ent r ies in t he l ocal -
gr oup dat abase.
The l ink-st at e dat abase indicat es which r out er s/t r ansit net wor ks have at t ached gr oup
member s.
The Local -Gr oup Dat abase
Buil t in t he DR and BDR.
Consist s of t hr ee component s:
A mul t icast gr oupa Cl ass D addr ess
At t ached net wor kt he IP addr ess of t he at t ached net wor k t hat
cont ains t he mul t icast gr oup
Aget he number of seconds since an IGMP Host Member ship r epor t has
been seen
Fl ooded t hr oughout t he AS (or singl e ar ea).
Assist s in buil ding t he l ink-st at e dat abase and t he shor t est -pat h t r ee.
Facil it at es in t he del iver y of l ocal mul t icast dat agr ams.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 297
Operation
Oper at ion
When t he f ir st mul t icast dat agr am (cont aining t he sour ce net , mul t icast
dest inat ion) is r eceived by a r out er , it wil l f ind t he sour ce subnet in t he l ink-
st at e dat abase.
A sour ce-r oot ed mul t icast t r ee is buil t using t he Rout er LSAs and t he
Net wor k LSAs and t he Dykst r a al gor it hm.
Once t he t r ee is buil t , it is pr uned using t he inf or mat ion f r om t he gr oup-
member ship LSAs.
Final r esul t of t he Dykst r a al gor it hm is t he pr uned shor t est -pat h t r ee t hat is
r oot ed at t he sour ce.
Based on t his, an ent r y is made in t he f or war ding cache of t he r out er .
The l ocal -gr oup dat abase enabl es t he l ocal del iver y of mul t icast dat agr ams. The
dat agr ams shor t est -pat h t r ee enabl es t he del iver y of mul t icast dat agr ams t o dist ant
(i.e., not dir ect l y at t ached) gr oup member s. Bot h of t hese ar e used in t he cal cul at ion of
t he f or war ding cache.
The f ol l owing ar e st andar d assumpt ions when using MOSPF:
Al l MOSPF r out er s wit hin t he same ar ea cal cul at e t he same shor t est -pat h t r ee
f or a given mul t icast dat agr am. This is accompl ished via synchr onized l ink-st at e
dat abases.
Link-st at e dat abases can be synchr onized using t he new gr oup-member ship LSA.
Wit h each r out er in an ar ea having t he same dat abase, each r out er shoul d be abl e
t o buil d a sour ce-r oot ed, shor t est -pat h, mul t icast t r ee wit hout having t o
br oadcast t he f ir st mul t icast packet .
The shor t est -pat h mul t icast t r ee is buil t on demand. This means t hat t he t r ee
is buil t when a r out er r eceives a mul t icast dat agr am f or t he f ir st t ime f or a given
mul t icast gr oup. An MOSPF r out er does not aut omat ical l y f or war d t he f ir st
mul t icast dat agr am l ike DVMRP does. Since t he synchr onized l ink-st at e dat abase
cont ains gr oup-member ship LSAs, t his al l ows a MOSPF r out er t o per f or m
br oadcast t he f ir st dat agr am in it s memor y and t he t r ee is buil t on demand. The
r out er s al r eady know wher e t he act ive gr oup member ships ar e and can buil d t he
t r ee wit hout f or war ding t he f ir st dat agr am and t hen wait ing f or Pr une messages.
When t he f ir st mul t icast dat agr am ar r ives (at any r out er ), t he sour ce subnet (IP
addr ess of t he sour ce) is l ocat ed in t he l ink-st at e dat abase. This is somet imes cal l ed t he
MOSPF link-state database, but t he singl e dat abase (l ink-st at e dat abase) cont ains ent r ies
f or bot h unicast and mul t icast . A sour ce-r oot ed mul t icast t r ee is cal cul at ed using t he
r out er LSAs and t he net wor k LSAs using t he Dykst r a al gor it hm (same as unicast OSPF).
Once t he t r ee is buil t , it is pr uned (t o el iminat e l inks t hat do not cont ain at l east one
member of a gr oup) using t he gr oup-member ship LSAs. The f inal r esul t of t he Dykst r a
al gor it hm is t he pr uned shor t est -pat h t r ee t hat is r oot ed at t he sour ce (r emember , OSPF
cal cul at es it s shor t est -pat h t r ee using it sel f as t he r oot ). This shor t est -pat h t r ee is
used t o under st and which por t s shoul d be used f or t he f or war ding of mul t icast
dat agr ams t hat ar e dist ant (i.e., no l ocal -gr oup member ship, but t her e ar e member s of
t he gr oup downst r eam f r om t his r out er ), and which por t s shoul d r eceive which
mul t icast dat agr am (sour ce).
Now we have t wo sour ces of inf or mat ion: t he sour ce-r out ed shor t est -pat h t r ee and t he
l ocal -gr oup dat abase. Bot h of t hese ar e used t o det er mine t he f or war ding cache, which
is t he onl y pl ace t he r out er wil l l ook t o det er mine f or war ding of a mul t icast
dat agr am.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 298
Forwarding Cache
The f or war ding cache is used t o det er mine how t o f or war d a mul t icast dat agr am. A
mul t icast dat agr am may be del iver ed l ocal l y or it may be f or war ded on a br anch t o
anot her mul t icast r out er . I ment ioned bef or e t hat upon r eceipt of a mul t icast
dat agr am, Dykst r a r uns and t he r esul t is a pr uned, sour ce-r oot ed t r ee. The f or war ding
cache is buil t using t he shor t est -pat h t r ee buil t by t he Dykst r a al gor it hm and t he
ent r ies in t he l ocal -gr oup dat abase. The r out er f ir st f inds it s posit ion in t he shor t est -
pat h t r ee. Once t he r out er discover s it s posit ion, it wil l cr eat e a ent r y in t he
f or war ding cache t hat cont ains t he (sour ce, gr oup) pair , t he upst r eam node, and t he
downst r eam int er f aces.
For war ding Cache
Used t o det er mine t he cor r ect pat h on which t o f or war d a mul t icast
dat agr am.
Ent r ies ar e pl aced her e by t he shor t est -pat h t r ee buil t using t he Dykst r a
al gor it hm and t he l ocal -gr oup dat abase.
Rout er must f ind it s posit ion in t he shor t est -pat h t r ee.
Rout er cr eat es an ent r y t hat consist s of t he (sour ce, gr oup) pair , t he upst r eam
node, and t he downst r eam int er f aces.
The f ol l owing ent r ies ar e pl aced int o t he f or war ding cache:
Sour ce net wor k: The net wor k number of t he sour ce.
Dest inat ion mul t icast gr oup: A known dest inat ion gr oup addr ess t o which
mul t icast dat agr ams ar e cur r ent l y being f or war ded.
Upst r eam node: The int er f ace t hat dat agr ams addr essed t o (sour ce, gr oup)
shoul d be r eceived on.
List of downst r eam int er f aces: The int er f ace(s) t hat a mul t icast dat agr am
(indexed by sour ce, gr oup) shoul d be f or war ded on.
List of downst r eam neighbor s: To assist in t he f or war ding of mul t icast
dat agr ams in a hybr id (mixed OSPF and MOSPF) net wor k.
TTL: The number of hops t he dat agr am wil l t r avel t o r each any out l ying gr oup
member s. This pr ovides f or ef f iciency in t hat t he r out er can discar d a mul t icast
dat agr am if t he r eceived TTL is l ess t han t his TTL.
TTLs ar e used by t r ansmit t ing host s t o r est r ict t he f or war ding of a mul t icast dat agr am.
This al l ows f or ef f iciency in t hat a mul t icast dat agr am wil l onl y be f or war ded (over
r out er s) t he number of hops indicat ed by t he TTL of t he r eceived dat agr am. Not ice t hat
in t he f or war ding cache, each of t he downst r eam neighbor s is l abel ed wit h a TTL (Time
t o Live) val ue. The is an opt imizing f eat ur e in t hat if a MOSPF r out er r eceives a
mul t icast dat agr am whose TTL is l ower t han t he ent r y in it s r out ing t abl e, t he r out er
wil l discar d t he dat agr am. The inf or mat ion cont ained in t he cache r emains st abl e unt il
one of t wo t hings happens: An OSPF t opol ogy change f or ces t he cache t o be f l ushed (al l
ent r ies ar e del et ed and ar e not pl aced back int o t his cache unt il r eceipt of a mul t icast
dat agr am which wil l buil d a new ent r y); or a gr oup-member ship LSA is r eceived t hat
cont ains a change in t he member s of a gr oup. A new t r ee wil l have t o be const r uct ed
based on t his inf or mat ion.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 299
Inter-Area MOSPF Routing
The basic al gor it hm f or MOSPF wor ks in a singl e ar ea. Int er -ar ea r out ing f or mul t icast
invol ves a sour ce and one or mor e dest inat ion gr oups in dif f er ent ar eas. The f or war ding
of mul t icast dat agr ams bet ween ar eas is st il l decided by t he inf or mat ion cont ained in
t he f or war ding cache. The pr obl em is t he abil it y t o accur at el y buil d a compl et e
shor t est -pat h t r ee because det ail ed inf or mat ion about t he ot her ar eas t opol ogy is not
known (in OSPF it is summar ized, in MOSPF it is not known). Fur t her mor e, since LSAs ar e
not f l ooded t o dif f er ent ar eas, t he gr oup LSA is not pr opagat ed t o ot her ar eas. To
compensat e f or t his unknown inf or mat ion, est imat es ar e made by using t he wil dcar d
f eat ur e of t he Ar ea Bor der Rout er (new t o MOSPF) and t he summar y l ink
adver t isement s pr ovided by t he ABR. Af t er a f ew int r oduct ions, how MOSPF over comes
t hese l imit at ions is expl ained.
In a mul t icast t opol ogy t hat is r epr esent ed by mul t ipl e ar eas, a new f unct ion wit hin t he
ABR, cal l ed inter-area multicast forwarders, is impl ement ed. These f or war der s pass gr oup
inf or mat ion and al l ow f or t he abil it y of mul t icast dat agr ams t o cr oss ar eas. It is t he
ABR t hat is conf igur ed t o per f or m t his f unct ion. For war der s r uns as a separ at e f unct ion
of t he ABR and ar e used onl y f or mul t icast dat agr ams.
ABRs impl ement ing t he mul t icast f or war der summar ize t heir ar eas gr oup inf or mat ion
(how is expl ained in a moment ) and send it t o t he backbone ar ea t hr ough t he use of
gr oup-member ship LSAs, which ar e inject ed int o t he backbone ar ea. The backbone
r out er s r eceive t his inf or mat ion and incl ude it in t heir l ink-st at e dat abase by gr oup and
t he r out er it r eceived it f r om. The backbone r out er s pr ocess t his inf or mat ion but do not
f or war d any mul t icast inf or mat ion on t o any ot her mul t icast ABRs. Fur t her mor e, no
inf or mat ion r egar ding t he backbones gr oup member ship is f or war ded t o any ar ea. It is
asymmet r ical . Inf or mat ion f l ows int o t he backbone, but t he backbone does not f l ow t he
inf or mat ion int o ot her ar eas. So how does inf or mat ion f l ow bet ween ar eas, or f r om t he
backbone t o an ar ea? So how does t he mul t icast f or war der know of t he gr oups in it s
ar ea and know when t o pass inf or mat ion f r om t he backbone t o an ar ea? This invol ves
t he concept known as t he wildcard receiver.
Int er -Ar ea MOSPF Rout ing
Basic al gor it hm f or MOSPF wor ks in a singl e ar ea.
Topol ogies t hat incl ude mul t ipl e ar eas have a new f unct ion in t he ABR known
as t he int er -ar ea mul t icast f or war der :
Passes gr oup inf or mat ion and al l ows f or t he abil it y of mul t icast
dat agr ams t o cr oss ar eas
ABRs summar ize t heir ar eas gr oup inf or mat ion and inject t his inf or mat ion
int o t he backbone.
Backbone r out er s r ecor d t his inf or mat ion in t heir l ink-st at e dat abase and t he
r out er f r om which t hey r eceived t his inf or mat ion.
Inf or mat ion is asymmet r ic.
Int er -ar ea mul t icast f or war der s ar e ABR wil dcar d r eceiver s.
MOSPF r out er s may indicat e t hey want t o r eceive al l mul t icast dat agr ams r egar dl ess of
t he dest inat ion. They can indicat e t his t hr ough t heir r out er -LSA using a newl y def ined
bit in t he r t ype f iel d known as t he W bit, or wildcard bit. This bit is used wit h int er -ar ea
mul t icast f or war der s (ABRs) and per mit s a MOSPF r out er t o r eceive al l mul t icast
t r af f ic in an ar ea r egar dl ess of t he gr oup. MOSPF r out er s t hat empl oy t his f unct ion
ensur e t hat t hey r emain on al l pr uned mul t icast t r ees, t hus al l owing t hem t o r eceive
al l mul t icast dat agr ams r egar dl ess of gr oup member ship. By def aul t , al l mul t icast
f or war der ABRs ar e wil dcar d r eceiver s.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 300
Inter-Area Multicast Example
Having t he mul t icast f or war der s as wil dcar ds enabl es t hem t o r eceive mul t icast
dat agr ams f r om t he backbone and any mul t icast f or war der t o be incl uded in any
mul t icast t r ee buil t in t heir ar ea. When a mul t icast dat agr am is t o be f or war ded, it is
r eceived by t he ABR (mul t icast f or war der ) f or f or war ding t o t he backbone. The
backbone r out er s know which gr oups ar e act ive in which ar eas, and since t he ABR is
par t of t he backbone t hey can r eceive t he inf or mat ion f r om t he backbone t o be
f or war ded t o t heir ar ea.
The backbone r out er s do not impl ement t he wil dcar d f unct ion, f or t hese r out er s
inher ent l y know about al l mul t icast gr oups t hr ough t he mul t icast ABRs f l owing
summar y inf or mat ion int o t he backbone, which is r eceived by t he backbone r out er s.
How is t he f or war ding cache buil t based on t hese assumpt ions? It depends on whet her
t he sour ce and a r out er buil ding t he t r ee ar e in t he same ar ea or not . The f or war ding
of mul t icast inf or mat ion is st il l accompl ished using t he f or war ding cache, but an
accur at e pict ur e cannot be dr awn.
If t he sour ce and t he r out er per f or ming t he cal cul at ion ar e in t he same ar ea, t he
wil dcar d f eat ur e of t he ABR comes int o pl ay. This f or ces t he r out er t o be incl uded in
al l mul t icast comput at ions, which al l ows f or t he br anches of t he ABR t o be incl uded in
t he shor t est -pat h t r ee. The ABR wil l not be pr uned.
If t he sour ce and t he r out er per f or ming t he cal cul at ion ar e in dif f er ent ar eas, t hen
t he summar y l ink adver t isement s ar e used. This f or ces t he int er -ar ea mul t icast
f or war der s of t he ABR t o be incl uded in t he cal cul at ed t r ee.
A f inal not e: Ar ea Bor der Rout er s have separ at e l ink-st at e dat abases f or each ar ea
t hey at t ach t ot his is a nor mal OSPF pr ocess. For mul t icast , however , t his means t hat
each mul t icast f or war der must buil d a separ at e f or war ding t r ee f or each ar ea t hey
at t ach t o. But al l of t he ar eas f or war ding inf or mat ion is cont ained in one f or war ding
cache and as soon as t his is buil t , t he shor t est -pat h t r ees f or each ar ea ar e dismant l ed.
Ther e is no need f or t hem once t he f or war ding cache cont ains al l t he inf or mat ion
needed f or f or war ding mul t icast dat agr ams.
Int er -Ar ea Mul t icast Exampl e

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 301
Inter-Area Shortest-Path Tree
The f ol l owing sl ide show t he pat h bet ween ar eas. Not ice t hat t he ABRs ar e wil dcar d
r eceiver s. This al l ows t hem t o be incl uded in al l t r ees t hat ar e buil t .
Int er -Ar ea Shor t est -Pat h Tr ee

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 302
Inter-Autonomous System Multicast
This t ype of mul t icast r out ing invol ves a sour ce and dest inat ion t hat r eside in
dif f er ent aut onomous syst ems. This incl udes t he abil it y of r out ing bet ween an MOSPF
domain and a DVMRP domain, but wit hin t he same AS. This is simil ar in t he way OSPF
t r eat s RIP. Bot h OSPF and RIP can be used in t he same AS, but t hey ar e t r eat ed as
separ at e r out ing domains.
Just as in t he int er -ar ea mul t icast r out ing, conf igur ed Aut onomous Syst em Boundar y
Rout er s ar e conf igur ed t o per f or m t he int er -AS mul t icast f or war der f unct ion. This
wor ks under t he assumpt ion t hat each int er -AS mul t icast f or war der empl oys a
mul t icast f or war ding pr ot ocol t hat uses Rever se Pat h For war ding, such as DVMRP or
PIM. The mul t icast ASBRs use t he wil dcar d capabil it y. Wit h t his, each ASBR act s as a
mul t icast wil dcar d r eceiver f or each of it s at t ached ar eas. This ensur es t hat t he int er -
AS mul t icast f or war der s ar e incl uded in al l mul t icast t r ees. They ar e not pr uned.
Most of t he oper at ion of t his r out er is simil ar t o t he int er -ar ea mul t icast f or war der .
However , t her e is one case in which it is dif f er ent : If t he sour ce of t he mul t icast
dat agr am and t he r out er making t he cal cul at ion ar e in dif f er ent ASs. Again, t he
det ail s of each AS t opol ogy wil l not be known. To compensat e f or t his, inf or mat ion can
be assumed by using t he Summar y-ASBR l ink and t he AS Ext er nal l inks, which descr ibe
t he sour ce subnet . Af t er t he cal cul at ion is done, t he mul t icast t r ee begins at t he int er -
AS mul t icast f or war der , wit h al l br anches st emming f r om t his r out er .
Int er -Aut onomous Syst em Mul t icast
Invol ves sour ce and dest inat ions t hat r eside in dif f er ent aut onomous syst ems.
ASBRs per f or m a new f unct ion known as Int er -AS mul t icast f or war der .
ASBRs use t he wil dcar d mechanism:
Al l ows ASBRs t o be incl uded in al l mul t icast t r ees

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 303
Multicast Conclusion
Mul t icast Concl usion
MOSPF r equir es t hat you r un OSPF or MOSPF net wor k.
MOSPF conver ges inst ant l y.
MOSPF does not suppor t t unnel s dir ect l y.
MOSPF scal es wel l .
MOSPF wor ks in spar sel y popul at ed ar eas as wel l as dense.
Mul t icast ing is coming and it is t aking many f or ms on an int er net or t he Int er net . We
have voice, video, and dat a mul t icast ing. Ther e is one common pr ot ocol message f or mat ,
and t hat is IGMP. PIM and DVMRP use t his f r aming f or t heir messages as wel l . MOSPF
uses it s own LSA f or communicat ing bet ween r out er s. However , al l mul t icast
appl icat ions conf or m t o IGMP t o r egist er t hemsel ves on t he l ocal subnet .
Al l of t he pr ot ocol s have t heir own advant ages and disadvant ages. MOSPF r equir es
t hat you ar e r unning OSPF. A RIPv1 or RIPv2 net wor k cannot simpl y inst al l MOSPF. If
t he sit e chooses t o use RIP, it must use PIM or DVMRP. MOSPF conver ges inst ant l y,
wher eas PIM and DVMRP may have r out ing l oops dur ing a sl ow conver gence. However ,
inst al l ing MOSPF is not a simpl e t ask, f or MOSPF is OSPF wit h mul t icast ext ensions;
t her ef or e, al l of t he r ul es wit h OSPF st il l appl y. MOSPF does not suppor t t unnel s. It
expect s some t ype of ot her pr ot ocol such as DVMRP t o be r unning on t he M-ASBR
r out er s. DVMRP does not scal e wel l and neit her does PIM wit hout some t uning. DVMRP
and MOSPF wor k bet t er in densel y popul at ed envir onment s, wher eas PIM has t wo modes
of oper at ion: spar se and dense mode. PIM al l ows f or dupl icat e packet s in dense mode, in
f avor of a simpl er pr ot ocol t hat is not dependent on a unicast r out ing mechanism. You
r eal l y must consider al l t he opt ions bef or e pl acing a mul t icast pr ot ocol on your
net wor k.
One of t he t hings you must t hink about wit h mul t icast is not onl y r eceiving dat a, but
how t o r espond t hat dat a. Yes, mul t icast ing does al l ow f or one st at ion t o send one
dat a-st r eam t o be r eceived by l it er al l y t ens of t housands of r eceiver s. But what if
t her e is a need f or acknowl edgment of t hat dat a? This poses a consider abl e pr obl em: one
sender , mul t ipl e r eceiver s. If t he number of r eceiver s is 2000 and t hey al l need t o send
some t ype of Receiver St at us message back t o t he sender , t he sender must be abl e t o
handl e t his t ype of back-channel inf or mat ion f l owespecial l y if t he st at us is l ong.
The inabil it y t o handl e t his is cal l ed implosion, dur ing which t he or iginat or is over r un
by t he back channel .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 304
RFCs to Be Reviewed
2236 Int er net Gr oup Management Pr ot ocol , Ver sion 2. W. Fenner . November 1997.
(For mat : TXT=51048 byt es) (Updat es RFC1112) (St at us: PROPOSED STANDARD).
2201 Cor e Based Tr ees (CBT) Mul t icast Rout ing Ar chit ect ur e. A.Bal l ar die. Sept ember
1997. (For mat : TXT=38040 byt es) (St at us: EXPERIMENTAL).
2189 Cor e Based Tr ees (CBT ver sion 2) Mul t icast Rout ing. A. Bal l ar die. Sept ember 1997.
(For mat : TXT=52043 byt es) (St at us: EXPERIMENTAL).
2117 Pr ot ocol Independent Mul t icast -Spar se Mode (PIM-SM): Pr ot ocol Specif icat ion. D.
Est r in, D. Far inacci, A. Hel my, D. Thal er , S. Deer ing, M. Handl ey, V. Jacobson, C. Liu, P.
Shar ma, L. Wei. June 1997. (For mat : TXT=151886 byt es) (St at us: EXPERIMENTAL).
1700 ASSIGNED NUMBERS. J. Reynol ds,J. Post el . Oct ober 1994. (For mat : TXT=458860
byt es) (Obsol et es RFC1340) (Al so STD0002) (St at us: STANDARD).
1584 Mul t icast Ext ensions t o OSPF. J. Moy. Mar ch 1994. (For mat : TXT=262463, PS=426358
byt es) (St at us: PROPOSED STANDARD).
1469 IP Mul t icast over Token-Ring Local Ar ea Net wor ks. T. Pusat er i. June 1993. (For mat :
TXT=8189 byt es) (St at us: PROPOSED STANDARD).
1458 Requir ement s f or Mul t icast Pr ot ocol s. R. Br audes & S. Zabel e. May 1993. (For mat :
TXT=48106 byt es) (St at us: INFORMATIONAL).
1112 Host ext ensions f or IP mul t icast ing. S.E. Deer ing. Aug-01-1989. (For mat : TXT=39904
byt es) (Obsol et es RFC0988, RFC1054) (Updat ed by RFC2236) (St at us: STANDARD).
1075 Dist ance Vect or Mul t icast Rout ing Pr ot ocol . D. Wait zman, C.Par t r idge, S.E.
Deer ing. Nov-01-1988. (For mat : TXT=54731 byt es) (St at us: EXPERIMENTAL).
Mul t icast dr af t s t hese can be obt ained f r om many sour ces. The one t hat I used
is:ht t p://inf o.int er net .isi.edu:80/in-dr af t s/id-abst r act s.ht ml Dist ance Vect or Mul t icast
Rout ing Pr ot ocol , T. Pusat er i, 08/11/1998, <dr af t -iet f -idmr -dvmr p-v3-07.t xt ,.ps>. This
document is an updat e t o Ver sion 1 of t he pr ot ocol specif ied in RFC 1075.
Domain Wide Mul t icast Gr oup Member ship Repor t s, Bil l Fenner , 08/07/1998, <dr af t -iet f -
idmr -member ship-r epor t s-01.t xt ,.ps>. Domain Wide Mul t icast Gr oup Member ship Repor t s
al l ow t his inf or mat ion t o be l ear ned in a f ashion simil ar t o IGMP at t he domain l evel .
Int er net Gr oup Management Pr ot ocol , Ver sion 3, St eve Deer ing, B. Cain, A.
Thyagar ajan, 12/03/1997, <dr af t -iet f -idmr -igmp-v3-00.t xt >. This document specif ies
Ver sion 3 of t he Int er net Gr oup Management Pr ot ocol , IGMPv3. Ver sion 3 of IGMP adds
suppor t f or sour ce f il t er ing.PIM Ver sion 2 DR El ect ion Pr ior it y Opt ion, L. Wei,
03/05/1998, <dr af t -iet f -idmr -pimv2-dr -pr ior it y-00.t xt >. This dr af t specif ies t he DR
El ect ion Pr ior it y Opt ion in PIMver sion 2 Hel l o messages.
IGMP Mul t icast Rout er Discover y, B. Cain, Shant am Biswas, 03/12/1998, <dr af t -iet f -
idmr -igmp-mr disc-00.t xt >. Companies have been pr oposing IGMP snooping t ype schemes
f or l ayer -2 br idging devices. A met hod f or discover y mul t icast capabl e r out er s is
necessar y f or t hese schemes.
Cor e Based Tr ees (CBT ver sion 3) Mul t icast Rout ingPr ot ocol Specif icat ion, <dr af t -
iet f -idmr -cbt -spec-v3-01.t xt >. This specif icat ion super cedes and obsol et es RFC 2189.
RFCs t o Be Reviewed
2236 Int er net Gr oup Management Pr ot ocol , Ver sion 2. W. Fenner . November
1997. (For mat : TXT=51048 byt es) (Updat es RFC1112) (St at us: PROPOSED
STANDARD).
2201 Cor e Based Tr ees (CBT) Mul t icast Rout ing Ar chit ect ur e. A.Bal l ar die.
Sept ember 1997. (For mat : TXT=38040 byt es) (St at us:EXPERIMENTAL).
2189 Cor e Based Tr ees (CBT ver sion 2) Mul t icast Rout ing. A. Bal l ar die.
Sept ember 1997. (For mat : TXT=52043 byt es) (St at us: EXPERIMENTAL).
2117 Pr ot ocol Independent Mul t icast -Spar se Mode (PIM-SM): Pr ot ocol
Specif icat ion. D. Est r in, D. Far inacci, A. Hel my, D. Thal er , S. Deer ing, M.
Handl ey, V. Jacobson, C. Liu, P. Shar ma, L. Wei. June 1997. (For mat : TXT=151886
byt es) (St at us: EXPERIMENTAL).
1700 ASSIGNED NUMBERS. J. Reynol ds,J. Post el . Oct ober 1994. (For mat :
TXT=458860 byt es) (Obsol et es RFC1340) (Al so STD0002) (St at us: STANDARD).
1584 Mul t icast Ext ensions t o OSPF. J. Moy. Mar ch 1994. (For mat : TXT=262463,
PS=426358 byt es) (St at us: PROPOSED STANDARD).
1469 IP Mul t icast over Token-Ring Local Ar ea Net wor ks. T. Pusat er i. June
1993. (For mat : TXT=8189 byt es) (St at us: PROPOSED STANDARD).
1458 Requir ement s f or Mul t icast Pr ot ocol s. R. Br audes & S. Zabel e. May 1993.
(For mat : TXT=48106 byt es) (St at us: INFORMATIONAL).
1112 Host ext ensions f or IP mul t icast ing. S. Deer ing. Aug-01-1989. (For mat :
TXT=39904 byt es) (Obsol et es RFC0988, RFC1054) (Updat ed by RFC2236) (St at us:
STANDARD).
1075 Dist ance Vect or Mul t icast Rout ing Pr ot ocol . D. Wait zman, C.Par t r idge,
S. Deer ing. Nov-01-1988. (For mat : TXT=54731 byt es). (St at us: EXPERIMENTAL).
Mul t icast dr af t s t hese can be obt ained f r om many sour ces. The one t hat I
used is:ht t p://inf o.int er net .isi.edu:80/in-dr af t s/id-abst r act s.ht ml Dist ance
Vect or Mul t icast Rout ing Pr ot ocol , T. Pusat er i, 08/11/1998, <dr af t -iet f -idmr -
dvmr p-v3-07.t xt ,.ps>. This document is an updat e t o Ver sion 1 of t he pr ot ocol
specif ied in RFC 1075.
Domain Wide Mul t icast Gr oup Member ship Repor t s, Bil l Fenner , 08/07/1998,
<dr af t -iet f -idmr -member ship-r epor t s-01.t xt ,.ps>.
Int er net Gr oup Management Pr ot ocol , Ver sion 3, St eve Deer ing, B. Cain, A.
Thyagar ajan, 12/03/1997, <dr af t -iet f -idmr -igmp-v3-00.t xt >.
PIM Ver sion 2 DR El ect ion Pr ior it y Opt ion, L. Wei, 03/05/1998, <dr af t -iet f -idmr -
pimv2-dr -pr ior it y-00.t xt >.
IGMP Mul t icast Rout er Discover y, B. Cain, Shant am Biswas, 03/12/1998, <dr af t -
iet f -idmr -igmp-mr disc-00.t xt >.
Cor e Based Tr ees (CBT ver sion 3) Mul t icast Rout ing Pr ot ocol Specif icat ion
<dr af t -iet f -idmr -cbt -spec-v3-01.t xt >.
Web Sit es
www.ipmul t icast .com
www.mbone.com

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Part Six
BOOTP, DHCP, RSVP, and SNMP
Chapter 305
Boot Protocol (BOOTP)
This pr ot ocol has been ar ound a l ong t ime. It was most of t en used wit h diskl ess
wor kst at ions. It enabl ed t hese wor kst at ions t o get t heir conf igur at ion and boot f il es
t o r emot el y boot over t he net wor k. The best exampl e of t his was SUN wor kst at ions and
t heir Net wor k Fil e Syst em (NFS). These diskl ess net wor k st at ions coul d boot over t he
net wor k (using a smal l boot st r ap pr ot ocol f ound in a PROM). Wit h t his t hey coul d get
t heir conf igur at ion par amet er s such as t heir IP addr ess and subnet mask and t hen
per f or m t he boot sequence t o boot up t heir machine f r om a r emot e ser ver .
The Boot st r ap Pr ot ocol (BOOTP) is a UDP/IP-based cl ient -ser ver appl icat ion or iginal l y
pr omot ed t o al l ow diskl ess cl ient s t o boot r emot el y f r om a ser ver on t he same net wor k
or f r om a ser ver on a dif f er ent net wor k f or t he pur pose of obt aining t he name of a f il e
t o be l oaded int o memor y and execut ed, an IP addr ess, and t he addr ess of it s boot ser ver .
The RFC f or BOOTP is RFC 951, but t her e have been a f ew suppl ement al RFCs since t hen
t o cl ear up some l oosel y def ined f eat ur es of t he pr ot ocol t hat can l ead t o
misint er pr et at ion and event ual l y incompat ibil it ies bet ween vendor s suppor t ing t he
pr ot ocol . The most r ecent one is RFC 1542, Cl ar if icat ions and Ext ensions f or t he
Boot st r ap Pr ot ocol . Ot her conf igur at ion inf or mat ion such as t he l ocal subnet mask,
t he l ocal t ime of f set , t he addr esses of def aul t r out er s, and t he addr esses of var ious
Int er net ser ver s can al so be communicat ed t o a host using BOOTP.
Boot Pr ot ocol (BOOTP)
RFC 951.
Updat ed by RFCs 1395, 1497, 1532, and 1542
Or iginat ed many year s ago as a met hod of boot ing diskl ess wor kst at ions on a
LAN.
Wor ks as micr ocode in a PROM.
Wor kst at ion boot s a simpl e oper at ing syst em.
Just enough t o send out Boot messages t o a BOOTP ser ver
Usual l y oper at es in t wo st ages:
Fir st , it get s it s IP addr ess
Next , it uses t he TFTP pr ot ocol t o boot it s f ul l oper at ing image

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 306
BOOTP Operation
The basic oper at ion is as f ol l ows:
Ther e is a singl e packet t ype exchanged bet ween t he cl ient and t he ser ver . One f iel d in
t he packet is cal l ed t he opcode and can have one of t wo val ues: BOOTREQUEST or
BOOTREPLY. The cl ient br oadcast s a BOOTREQUEST packet t hat cont ains t he cl ient s
har dwar e addr ess and it s IP addr ess if known. The BOOTREQUEST may cont ain t he name
of t he ser ver t he cl ient wishes t o r espond. This is t o f or ce t he BOOTREQUEST packet t o
a par t icul ar ser ver f r om which t o obt ain it s inf or mat ion. This may occur if t her e ar e
many ser ver s on t he net wor k or if t her e is mor e t han one image (ol der /newer ) ver sion
t hat coul d be sent t o t he cl ient . Inside t he BOOTREQUEST may be a gener ic f il ename t o
be boot ed. Simpl e names l ike ipboot or unixboot ar e used. When t he ser ver r epl ies wit h a
BOOTREPLY, it r epl aces t his ent r y wit h t he f ul l pat hname by which t he f il e can be
l ocat ed on t hat ser ver .
If t he cl ient does not know it s IP addr ess, t he ser ver must possess a dat abase of MAC-t o-
IP addr ess mappings. Once a mat ch is f ound, t his IP addr ess is pl aced in a f iel d in t he
BOOTREPLY packet .
BOOTP Oper at ion

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 307
BOOTP Field Definitions
Fiel d Byt es Descr ipt ion
op 1 Packet oper at ion code/message t ype. 1 = BOOTREQUEST, 2 =
BOOTREPLY
ht ype 1 Har dwar e addr ess t ype, same as ARP sect ion in Assigned
Number s RFC. For exampl e, 1 = 10 Mb Et her net .
hl en 1 Har dwar e addr ess l engt h. For exampl e, 6 (byt es) f or 10 Mb
Et her net .
hops 1 Cl ient set s t o 0 and opt ional l y used by gat eways in BOOTP
Rel ay.
xid 4 Tr ansact ion ID. A r andom number used t o mat ch t his boot
r equest wit h t he r esponses it gener at es.
secs 2 Fil l ed in by t he cl ient , indicat ing t he number of seconds t hat
have el apsed since t he cl ient st ar t ed t r ying t o boot .
ciaddr 4 Cl ient IP addr ess; f il l ed in by cl ient in BOOTREQUEST, if known.
yiaddr 4 Your (cl ient ) IP addr ess; f il l ed in by t he ser ver if t he cl ient
doesnt know it s own addr ess (i.e., ciaddr was a 0).
siaddr 4 Ser ver IP addr ess, r et ur ned in t he BOOTREPLY by t he ser ver .
giaddr 4 The gat eways IP addr ess of t he por t t hat r eceived t he f ir st
BOOTREQUEST. It is used in t he BOOTREPLY f unct ion.
chaddr 16 The cl ient s har dwar e (MAC) addr ess. It is f il l ed in by t he
cl ient .
sname 64 Opt ional . The ser ver host name being r equest ed by t he cl ient .
Al l ot her ser ver s woul d t hen ignor e t his packet .
f il e 128 The boot f il ename. The gener ic name in t he BOOTREQUEST.
Vend 64 This is an opt ional vendor -specif ic f iel d. Exampl es of it s use
coul d be a ser ial number , ver sion number , et c. It is gener al l y
ignor ed by BOOTP.
BOOTP Fiel d Def init ions

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 308
Client Side (BOOTREQUEST)
The f ol l owing is t he ser ies of st eps t aken by t he cl ient t o buil d a BOOTREQUEST
packet :
1. The IP dest inat ion addr ess (in t he IP header , not t he BOOTP f iel ds) is set t o
255.255.255.255. Opt ional l y, it may set t he addr ess t o t he ser ver s IP addr ess, if it is
known.
2. The IP sour ce addr ess is set t o it s IP addr ess (if known); ot her wise, it is set t o 0.
3. The UDP por t number s ar e set t o 67 f or UDP dest inat ion por t (t he ser ver ) and
68 f or t he UDP sour ce por t (t he cl ient ).
4. The op f iel d is set t o 1 (BOOT-REQUEST).
5. The ht ype is set t o t he har dwar e addr ess t ype (bit l engt h) and t he hl en is set t o
t he l engt h of t he har dwar e addr ess.
6. xid is set t o a r andom number .
7. secs is set t o t he number of seconds t hat have el apsed since t he cl ient st ar t ed
boot ing.
8. The ciaddr is set t o an IP addr ess of t he cl ient (if known); ot her wise, it is set t o
0 and t he chaddr is set t o t he cl ient s har dwar e addr ess.
9. If t he cl ient wishes t o r est r ict boot ing t o a par t icul ar ser ver name, it wil l set
t his name in t he Sname f iel d; ot her wise, t he Sname f iel d is set t o 0.
10. The Fil e f iel d can be set t o 0 t o indicat e t o t he ser ver t hat it wishes t o boot
f r om t he def aul t f il e f or it s machine. Set t ing t his f iel d t o 0 coul d al so indicat e
t hat t he cl ient is int er est ed in f inding out cl ient /ser ver /gat eway IP addr esses and
does not car e about a f il e f r om which t o boot . The f iel d coul d be set t o a simpl e
gener ic name such as ipboot or unixboot , indicat ing t hat it wishes t o boot t he
named pr ogr am conf igur ed f or t he cl ient . Final l y, t he f iel d can be set t o t he f ul l
pat hname of t he ser ver on which t he boot f il e r esides.
11. The Vend f iel d is set t o what ever t he vendor wishes. However , it is
r ecommended t hat t he f ir st 4 byt es be set t o a magic number (t hat is, you pick it ).
This al l ows t he ser ver t o det er mine what kind of inf or mat ion it is seeing in t his
f iel d.
If no r epl y is r eceived by t he cl ient wit hin a pr eset l engt h of t ime, t he cl ient wil l
r et r ansmit t he r equest up t o an administ er ed amount of t imes. The r et r ansmission is
r egul at ed in t hat it wil l r andoml y send r et r ansmission r equest s. This is t o ensur e t hat
t he net wor k wil l not be f l ooded wit h r equest s shoul d cl ient s somehow sync t heir
t r ansmissions (pur el y by coincidence). Bef or e r et r ansmission, t he Secs f iel d is updat ed.
Cl ient Side (BOOTREQUEST)

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 309
Server Side
When t he ser ver r eceives t he packet , a ser ies of decisions t akes pl ace:
If t he UDP dest inat ion por t is not set t o 67, t hen t he ser ver wil l discar d t he
packet .
If t he Ser ver f iel d (sname) is set t o 0 or mat ches our name, f ur t her pr ocess t he
packet .
If t he ser ver name does not mat ch our name, but t he name is l ocal on t he
net wor k, t hen discar d t he packet .
If t he ser ver name is not on t he l ocal net wor k, t he ser ver may choose t o
f or war d t he packet t o t hat ser ver . Usual l y, t his is accompl ished via t he BOOTP
r el ay ser vice (expl ained in a moment ).
If t he Ciaddr f iel d is 0, t hen t he cl ient does not know it s IP addr ess, so t he
ser ver wil l l ook t his up in it s dat abase If no mat ch is f ound f or t his chaddr , t hen
discar d t he packet . Ot her wise, t he Yiaddr f iel d is f il l ed in on t he r esponse packet .
The Fil ename f iel d is t hen checked. If t his f iel d cont ains a 0, t hen t he cl ient is
eit her not int er est ed in a boot f il e or wishes t o use t he def aul t boot f il e. If t her e
is a f il ename specif ied, or a def aul t f il e is f ound, or t he f iel d cont ains a f ul l -
l engt h pat hname, t hen t he Fil e f iel d is r epl aced wit h t he f ul l -l engt h pat hname
of t he sel ect ed boot f il e. If t he f iel d is set t o a non-0 and no mat ch is f ound f or
t his f iel d on t his ser ver , t hen t he cl ient is asking f or a f il e t hat t he ser ver does
not have, and t he ser ver wil l discar d t he packet .
Final l y, t he Vend f iel d is checked and if a r ecognized t ype of dat a is pr ovided,
cl ient -specif ic act ions shoul d be t aken and a r esponse f r om t hese act ions is pl aced
in t he Vend Dat a f iel d of t he Repl y packet . This f iel d, f or exampl e coul d cont ain
conf igur at ion opt ions t hat can be passed t o t he boot f il e t hat wil l be t r ansmit t ed
t o t he cl ient af t er t he BOOTP is f inished.
Ser ver Side
The Siaddr f iel d is set t o t he ser ver s addr ess and t he Op f iel d is set t o a
BOOTREPLY. The UDP dest inat ion por t is set t o 68 (BOOTP cl ient ).
If t he Ciaddr addr ess of t he BOOT-REQUEST is set t o a non-0 addr ess, t hen t he
packet is IP r out ed back t o t he cl ient . However , if t he Giaddr is set t o a non-0,
t hen t he BOOTREPLY is sent dir ect l y t o t his r out er and t he UDP dest inat ion por t
is set t o BOOTPS (67). Ot her wise, t he cl ient is l ocal and t he BOOTREPLY is send
back t o t he cl ient on t he l ocal LAN.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 310
Chicken-or-the-Egg? Dilemma
A quest ion shoul d come t o mind her e f or t hose who have been f ol l owing al ong: If t he
cl ient does not yet know it s IP addr ess, how is it going t o r espond t o t he ser ver s ARP
r equest when t he ser ver decides t o r espond? Wel l , if t he cl ient knows it s IP addr ess (as
indicat ed in t he Ciaddr f iel d), t he BOOTREPLY can be sent as a nor mal IP packet , since
t he cl ient wil l r espond t o ARPs. But if t he cl ient does not yet know it s IP addr ess, t hen
t he cl ient cannot r espond t o ARPs sent by t he ser ver . Ther e ar e t wo opt ions avail abl e:
If t he ser ver has t he capabil it y t o manual l y const r uct an ARP ent r y in it s t abl e f or
t his cl ient , it wil l do so using t he Chaddr and Yiaddr f iel ds t hat it is r esponding wit h in
it s BOOTREPLY (BSD Unix has t his capabil it y). The ser ver wil l t hen r epl y using IP
ser vices and skip t he ARP pr ocess. If t he ser ver does not have t his capabil it y, t hen it
simpl y sends t he BOOTREPLY wit h t he IP addr ess set t o Br oadcast (B). This event is
shown in t he t abl e.
Chicken-or -t he-Egg? Dil emma
If t he cl ient does not yet know it s IP addr ess, how does it r espond t o ARP
r equest s dur ing a ser ver r esponse?
If t he cl ient knows it s IP addr ess, t his is not a pr obl em.
Two opt ions:
Simpl y send t he r epl y set t o br oadcast
The ser ver can manual l y const r uct t he ARP ent r y using t he f iel ds in
t he r eceived r equest
ciaddr giaddr B UDP Dest inat ion IP Dest inat ion Link Dest inat ion
non-0 X X BOOTCl ient (68) ciaddr nor mal
0.0.0.0 non-0 X BOOTPSer ver giaddr nor mal
0.0.0.0 0.0.0.0 0 BOOTPCl ient (68) yiaddr chaddr
0.0.0.0 0.0.0.0 1 BOOTPCl ient (68) 255.255.255.255 br oadcast X

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 311
BOOTP Relay Agents (or BOOTP Gateway)
The BOOTP oper at ion al so consider s t he possibil it y t hat cl ient s and ser ver s may not be
on t he same IP net wor k or subnet (t hose net wor k segment s not separ at ed by a r out er ).
Ther ef or e, some kind of r el ay agent is needed t o f or war d t he BOOTP messages. This t ype
of ser vice is most commonl y f ound as par t of t he r out er f unct ion; however , it is mor e
t han a r out er simpl y r eceiving a BOOTP message and f or war ding it on t o t he next
segment . Basical l y, t he r out er r eceives t he message, pr ocesses it as if t he message was
addr essed t o it , and t hen sends out a new BOOTP message t o t he appr opr iat e f or war ded
por t .
The f or war ding (scope) of a BOOTP or DHCP packet can be l imit ed by conf igur ing t he
r out er t o l imit t he scope. Each r out er incr ement s t he TTL f iel d. If t he r eceived packet
has it s l imit al r eady set in t he TTL f iel d, t he packet wil l be discar ded. Al so, t he r out er
must be conf igur ed as t o which por t s t he r out er shoul d f or war d t his packet on. It is not
simpl y f or war ded t o one por t . When t he r out er f or war ds t he packet on, if it is t he f ir st
r out er t o do so, it wil l pl ace it s addr ess in t he Giaddr f iel d of t he packet . It knows t hat
it is t he f ir st r out er because t his f iel d is set t o 0.0.0.0. When a r out er f or war ds t he
packet , it f or war ds it set t o Br oadcast .
Cisco enabl es t his f eat ur e as IP hel per -addr ess. This f eat ur e al l ows f or mor e t han just
BOOTP packet s t o be f or war ded acr oss t he r out er . Basical l y, any UDP br oadcast
addr ess can be f or war ded acr oss t he r out er .
BOOTP Rel ay Agent s (Or BOOTP Gat eway)
Used when r equest s and ser ver s ar e not on t he same net wor k.
Separ at ed by a r out er
Need some t ype of agent t hat can f or war d t hese r equest s over a r out er :
Rout er must be awar e of t his because r out er s do not f or war d messages
addr essed in br oadcast
Rout er r eceives a message and r esends it as if t he r out er had sent it :
Pl aces it s addr ess in t he Giaddr f iel d
Can set t he scope f iel d t o l imit t he f or war ding of t he r equest .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 312
Dynamic Host Configuration Protocol (DHCP)
Which came f ir st , BOOTP or DHCP? Which one does bot h? Why do you hear about
BOOTP ever y t ime somet hing is wr it t en about DHCP? Since t he pr ot ocol is based on a
br oadcast mechanism, why and how do t hese pr ot ocol s oper at e in a r out ed envir onment ?
In f act , why do we need anot her conf igur at ion mechanism when we have DRARP
(Dynamic Rever se Addr ess Resol ut ion Pr ot ocol ) and ICMP (Int er net Cont r ol Message
Pr ot ocol )? DRARP addr esses t he pr obl em of IP addr ess assignment and host s can use
ICMP t o f ind out t he subnet mask f or a net wor k and t o dynamical l y discover r out er s,
r ight ? And, since we consider a r out er t o somet imes be a host , does DHCP pr ovide
conf igur at ion inf or mat ion f or a r out er ? Or , have you f or got t en about t hose
capabil it ies?
DHCP buil ds on t he BOOTP pr ot ocol .
Pr obabl y best known f or it s IP addr ess l easing capabil it y.
Conf igur ed as:
DHCP Cl ient
DHCP Ser ver
BOOTP Rel ay Agent
Binding
DHCP is gaining consider abl e at t ent ion due t o a number of f act or s: t ight addr ess
al l ocat ion r est r ict ions, which r equir es ef f icient assignment or r eassignment of IP
addr esses (IP addr esses ar e in shor t suppl y and ar e handed out ver y car ef ul l y. DHCP
of f er s us t he capabil it y of handing t hem out st at ist ical l y based on pr obabil it y.
Ther ef or e, we can have many user s and not as many IP addr esses.).
This chapt er expl ains t he DHCP pr ot ocol . The DHCP pr ot ocol f or t he pur poses of t his
wr it ing can f ul l y int er oper at e wit h BOOTP ser ver s and cl ient s.
Ter ms used in t he DHCP pr ot ocol ar e as f ol l ows:
DHCP Cl ient : A host t hat is r equest ing conf igur at ion inf or mat ion.
DHCP Ser ver : A DHCP host s t hat suppl ies conf igur at ion par amet er s t o a
r equest ing host .
BOOTP Rel ay Agent : The pr ot ocol t hat al l ows BOOTP and DHCP packet s t o
t r aver se a r out er .
Binding: Conf igur at ion par amet er s, incl uding an IP addr ess, t hat ar e bound t o a
host .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 313
DHCP
DHCP pr ovides a t r anspor t mechanism f or passing conf igur at ion inf or mat ion (t hat is
l ocat ed on a ser ver ) t o r equest ing host s on a TCP/IP net wor k. What kind of par amet er s
ar e used f or t his inf or mat ion? The par amet er inf or mat ion is based on t he host
r equir ement s RFCs (RFCs 1122, 1123, 1112, et c.) Af t er being suppl ied wit h t his
conf igur at ion inf or mat ion, t he host shoul d be abl e t o communicat e wit h any ot her host
on t he Int er net .
It is t r ue t hat DHCP is based on BOOTP, but it adds much mor e f unct ional it y incl uding
t he abil it y t o l ease IP net wor k addr esses. DHCP al so uses some of t he f eat ur es of
BOOTP (r el ay agent , f or f or war ding t he messages acr oss r out er s) and is int er oper abl e
wit h exist ing BOOTP cl ient s (RFC 1534 descr ibes t he int er oper abil it y f unct ions of
BOOTP and DHCP). The DHCP messages ar e in t he exact same f or mat as BOOTP. Ref er t o
t he sl ide. DHCP adds t he abil it y t o suppor t l eased IP addr esses and ot her f unct ions.
This al l ows r equest ing st at ions t o get t heir IP addr esses f r om a ser ver and t hen r et ur n
t hem when t hey ar e f inished. These added f unct ions ar e descr ibed in RFC 2132.
DHCP consist s of t wo par t s: a pr ot ocol f or del iver ing host -specif ic conf igur at ion
par amet er s, and t he abil it y t o al l ocat e IP addr esses. It is based on a cl ient /ser ver model
in which t he host r equest s inf or mat ion f r om a ser ver . A host can ask a specif ic ser ver t o
suppl y inf or mat ion t o it , or it may simpl y r el y on any ser ver t o r el ay inf or mat ion t o it .
A ser ver must be pr econf igur ed t o handl e a specif ic cl ient s r equest , or t he ser ver wil l
ignor e t he r equest .
The f ir st ser vice pr ovided by DHCP is st at ic st or age of net wor k par amet er s f or
r equest ing cl ient s. This inf or mat ion is st or ed in a dat abase (or t abl e) on a host ser ver .
The ent r ies ar e keyed. This means t hat a unique ident if ier is used t o singl e out t he
par amet er s of a r equest ing host . This ident if ier is st at ed as t he cl ient ident if ier (or
Chaddr ), and t he assigned net wor k addr ess, and uniquel y ident if ies t he l ease bet ween
t he cl ient and t he ser ver f or DHCP.
DHCP
Pr ovides a t r anspor t mechanism f or passing conf igur at ion inf or mat ion t o
r equest ing host s.
Conf igur at ion inf or mat ion is based on t hat specif ied in RFCs 1112, 1122, and
1123.
DHCP and BOOTP ar e int er oper abl e.
DHCP messages ar e in t he same f or mat as BOOTP.
DHCP is consider ed t o do t wo t hings:
IP addr ess al l ocat ion
Del iver y of conf igur at ion inf or mat ion
Conf igur at ion inf or mat ion is st or ed in a dat abase t abl e on t he DHCP ser ver :
Cl ient specif ies which par amet er s it is l ooking f or in t he Vendor
Ext ensions f iel d of t he r equest packet

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 314
IP Address Allocation
IP Addr ess Al l ocat ion
Aut omat ic Al l ocat ion: per manent l y assigns an IP addr ess t o a st at ion.
Dynamic Al l ocat ion: assigns an IP addr ess t o a r equest ing st at ion f or specif ied
amount of t ime.
Manual Al l ocat ion: pr econf igur es t he ser ver t o give t he r equest ing st at ion
t he same IP addr ess ever y t ime it r equest s it .
The next ser vice t hat DHCP pr ovides f or is IP addr ess al l ocat ion. Thr ee met hods ar e
suppor t ed: aut omat ic al l ocat ion, dynamic al l ocat ion, and manual al l ocat ion.
Aut omat ic al l ocat ion per manent l y assigns an IP addr ess t o a r equest ing host . Dynamic
al l ocat ion gives an IP addr ess t o a r equest ing host f or a specif ic amount of t ime.
Manual al l ocat ion is t he abil it y t o r econf igur e an IP addr ess f or a host , and t he ser ver
simpl y r el ays t hat inf or mat ion when t he host r equest s it s IP addr ess. This dif f er s f r om
aut omat ic al l ocat ion in t hat wit h manual al l ocat ion, t he IP addr ess is pr econf igur ed
f or t he host by t he syst em administ r at or , wher eas t he aut omat ic al l ocat ion gives an
ar bit r ar y addr ess (f r om a pool of IP addr esses) t o a r equest ing host . In ot her wor ds, t he
host is not pr econf igur ed wit h t he IP addr ess f or t hat host .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 315
DHCP Messages
The f ol l owing message t ypes ar e used wit h cl ient /ser ver int er act ion:
DHCPDISCOVER : This is a cl ient br oadcast t hat is used t o l ocat e avail abl e
ser ver s. It may be f or war ded by r out er s t o al l ow f or ser ver segment s.
DHCPOFFER : This is a ser ver -t o-cl ient r esponse t o a DHCPDISCOVER message
wit h an of f er of conf igur at ion par amet er s.
DHCPREQUEST : This is a cl ient message t o ser ver s f or :
Request ing of f er ed par amet er s f r om one ser ver and impl icit l y decl ining
of f er s f r om al l ot her s.
Conf ir ming cor r ect ness of pr eviousl y al l ocat ed addr esses, (e.g., syst em
r eboot ).
Ext ending t he l ease on a par t icul ar net wor k addr ess.
DHCPACK : This is a ser ver -t o-cl ient message t hat cont ains conf igur at ion
par amet er s, incl uding a commit t ed net wor k addr ess.
DHCPNAK : This is a ser ver -t o-cl ient message indicat ing t he cl ient s not ion of
net wor k addr ess is incor r ect (e.g., cl ient has moved t o new subnet ) or a cl ient s
l ease has expir ed.
DHCPDECLINE : This is a cl ient -t o-ser ver message indicat ing a net wor k addr ess
is al r eady in use.
DHCPRELEASE : This is a cl ient -t o-ser ver message r el inquishing a net wor k
addr ess and cancel ing t he r emaining l ease.
DHCPINFORM: New wit h RFC 2131, t his is a cl ient -t o-ser ver message asking
onl y f or l ocal conf igur at ion par amet er s; t he cl ient al r eady has an ext er nal l y
conf igur ed net wor k addr ess.
DHCP Messages
DHCPDISCOVER
DHCPOFFER
DHCPREQUEST
DHCPACK
DHCPNAK
DHCPDECLINE
DHCPRELEASE
DHCPINFORM

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 316
DHCP Operation
Fir st , a cl ient t r ansmit s a DHCPDISCOVER message on it s l ocal physical subnet . Bot h
t he IP dest inat ion addr ess and t he MAC dest inat ion addr ess ar e set t o br oadcast . The IP
sour ce addr ess is set t o 0x00000000 and t he MAC sour ce addr ess is set t o Chaddr , or t he
cl ient s har dwar e addr ess.
The cl ient may pl ace in t his message some opt ions t hat incl ude an IP addr ess and t he
l ease dur at ion. If t he cl ient has pl aced a suggest ed IP addr ess in t he Opt ions f iel d, t he
cl ient has been pr eviousl y conf igur ed using DHCP and is now r est ar t ing and woul d l ike
t o use t hat addr ess again. If t he cl ient was manual l y conf igur ed wit h an IP addr ess, t he
cl ient shoul d use t he DHCPINFORM message inst ead of t he DHCPREQUEST message. One
f eat ur e t hat t he cl ient may use is t o obt ain a specif ic l ist of par amet er s. The cl ient may
indicat e t his by using t he par amet er r equest l ist , which indicat es t o t he ser ver which
par amet er s, by t ag number , t he cl ient is specif ical l y int er est ed in. See RFC 2132 f or mor e
inf or mat ion on DHCP opt ions.
This message wil l be picked up by t he r out er s t hat impl ement t he BOOTP r el ay agent
and f or war ded t o ot her net wor k segment s. Again, you can l imit t he scope (how many
r out er s it can t r aver se). The Hops f iel d (set t o 0 by t he cl ient ) is incr ement ed (usual l y
by 1) wit h each r out er and t he administ r at or of t he r out er set s t he maximum hop count .
If t he r eceived packet has a hop count of 2 and t he Max Hops par amet er conf igur ed in
t he r out er is 3, t he r out er wil l set t he Hops f iel d t o 3 and f or war d t he packet . If t he
r eceived packet al r eady has a 3 in t he Hops f iel d, t he r out er is not al l owed t o
incr ement t he f iel d t o a 4 and it wil l discar d t he packet . This is known as t he scope
(r ange) of t he DHCP packet .
DHCP Oper at ion
Each act ive ser ver t hat r eceives t his message may r espond wit h a DHCPOFFER message
t hat incl udes an IP addr ess in t he Yiaddr f iel d of t he packet . Not al l ser ver s wil l
r espond. Some may be pr econf igur ed t o not r espond t o cer t ain r equest s, and ot her s may
not have t he binding f or t hat cl ient . It may al so appear in var ious Opt ion f iel ds as wel l .
The ser ver does not have t o t ake t he of f er ed IP addr ess of f t he avail abl e l ist , but it
does hel p when t he ser ver does r emove t his of f er ed IP addr ess f r om it s avail abil it y pool .
At t his t ime, t he ser ver may check f or cur r ent use of t he of f er ed IP addr ess by sending
an ICMP ECHO r equest using t he of f er ed IP addr ess. This is conf igur abl e.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 317
DHCP Responses
Responses f r om t he ser ver can be addr esses in a f ew dif f er ent ways:
If t he Giaddr f iel d of t he r eceived cl ient packet is set t o 0 and t he Ciaddr f iel d
is set t o a non-0, t hen r esponses ar e t o be sent as unicast t o t he cl ient using t he
yiaddr as t he dest inat ion IP addr ess and t he chaddr as t he dest inat ion MAC
addr ess. (Giaddr f iel d set t o 0 indicat es t he cl ient is on t he l ocal subnet ).
If t he Giaddr f iel d is set t o a non-0 val ue, t hen t he r esponse is sent t o t he
BOOTP Rel ay agent using t he IP addr ess indicat ed by t he Giaddr f iel d.
If t he br oadcast bit was set , t hen t he ser ver br oadcast s (IP and MAC addr esses)
it s r esponses t o t he cl ient . Using t he B bit al l ows t he cl ient t o indicat e t o a
pot ent ial ser ver t hat it cannot r eceive unicast IP dat agr ams bef or e it s TCP/IP
conf igur at ion has been set .
If t he ser ver r eceives a DHCPREQUEST messages wit h an inval id r equest ed IP addr ess,
t he ser ver shoul d r espond t o t he cl ient wit h a DHCPNAK message and r epor t t his er r or
in a l og.
The cl ient may r eceive one or mor e of f er s f r om dif f er ent ser ver s. The cl ient wil l sel ect
one of t he ser ver s f r om t he r esponses t hat cl osel y mat ch it s or iginal r equest
par amet er s. If t he cl ient does not r eceive a r esponse t o it s DHCPREQUEST, it wil l t ime-
out , and r et r ansmit a DHCPREQUEST message.
To r espond t o a DHCPOFFER, t he cl ient t r ansmit s a DHCPREQUEST. In t he Opt ions f iel d
of t his message is t he ser ver ident if ier (t he ser ver s IP addr ess) indicat ing which ser ver
t he cl ient has sel ect ed. Al l ot her ser ver s wil l par t ial l y ignor e t his message. However ,
t hose decl ined ser ver s do use t his message t o indicat e t hat t he cl ient wil l not be using
t heir ser vices, and t his r el eases t he of f er ed IP addr ess back t o t he avail abl e pool .
The sel ect ed ser ver commit s t his binding t o a pl ace in memor y wher e it wil l be st or ed. (A
binding is a key t hat is used t o l ook up inf or mat ion. For exampl e, t he pr eceding ent r y
coul d be an IP-addr ess-t o-cl ient -har dwar e addr ess.) The ser ver wil l r espond t o t he
cl ient wit h a DHCPACK message cont aining al l t he cl ient s conf igur at ion par amet er s.
This binding is indicat ed as t he client identifier, and t he assigned IP addr ess.
When t he cl ient r eceives t he DHCPACK, it wil l per f or m some f inal checks, such as
ARPing f or t he newl y assigned IP addr ess t o ensur e t hat no one el se is assigned t o t his
addr ess. If t her e ar e any inconsist encies, t he cl ient wil l send a DHCPDECLINE message
t o t he ser ver and af t er wait ing 10 seconds (it shoul d wait at l east 10 seconds), it wil l
r est ar t t he conf igur at ion pr ocess. Al so, if t he ser ver t r ansmit t ed a DHCPNAK message
t o t he cl ient , t he cl ient wil l r est ar t (af t er 10 seconds).
DHCP Responses

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 318
Releasing an IP Address
To gr acef ul l y st op using t he assigned IP addr ess, t he cl ient shoul d t r ansmit a
DHCPRELEASE message t o t he ser ver (using t he same keyed binding t hat it used t o get
t he addr ess f r om t hat ser ver ). This may occur bef or e t he l ease dur at ion is up.
Rel easing an IP Addr ess

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 319
DHCP Shortcuts
DHCP Shor t cut s
A cl ient may skip t he DHCPDISCOVER if it knows t he ser ver addr ess t hat it
want s t o t al k t o.
Ser ver wil l r espond wit h a DHCP ACK.
If t he ser ver r esponds wit h a DHCPNAK, t he cl ient cannot use t he par amet er s
it specif ied in t he DHCPREQUEST:
Rest ar t wit h DHCPDISCOVER
DHCPINFORM message can be used by a cl ient t o inf or m a ser ver t hat it has an
IP addr ess but woul d l ike some par amet er s.
Repl y is in unicast
A simpl er appr oach is used f or t hose cl ient s t hat wer e pr eviousl y ser viced by DHCP. The
cl ient may skip t he DHCP Discover message and inst ead t r ansmit a DHCPREQUEST
message. A ser ver wil l t hen r espond wit h a DHCPACK message t o f il l in t he cl ient s
conf igur at ion par amet er s. If any of t he consist ency checks come back as inval id, t he
ser ver wil l r espond wit h a DHCPNAK message, meaning t hat t he cl ient may not r euse
t he r equest ed IP addr ess. The cl ient wil l r est ar t t he pr ocess using t he l onger met hod
(i.e., st ar t ing wit h DHCPDISCOVER).
The DHCPINFORM message can be used by t he cl ient t o inf or m a ser ver t hat it al r eady
has an IP addr ess (t hr ough a manual conf igur at ion pr ocess) but it woul d l ike a
downl oad of some conf igur at ion par amet er s t hat may be set f or it in t he ser ver bindings.
The r epl y f r om t he ser ver is unicast (a major dif f er ence f r om al l of t he ot her DHCP
messages, which ar e br oadcast ) dir ect l y back t o t he cl ient .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 320
Lease Duration
Timer s bet ween t he ser ver and cl ient may be dif f er ent . Ther e is not a synchr onizat ion
of t imer s bet ween cl ient s and ser ver s using DHCP. This may l ead t o a pr obl em in t hat
t he ser ver assumes t he l ease is up bef or e t he cl ient does (because of t he possibil it y of
t he inaccur acy of t he cl ocks). To compensat e f or t his, t he DHCP ser ver may r et ur n a
l ease smal l er t han r equest ed by t he cl ient . But t his is onl y in r esponse t o t he cl ient .
The ser ver wr it es t he or iginal t ime int o it s binder y. This may or may not be
accompl ished; it depends on how t he devel oper int er pr et ed t he RFC.
A cl ient t r ansmit s a DHCPREQUEST f or t he use of an IP addr ess f or a cer t ain per iod of
t ime. The ser ver guar ant ees not t o hand out an al l ocat ed IP addr ess t hat is in use by
anot her cl ient . Fur t her mor e, t he ser ver wil l t r y t o r eal l ocat e t he same IP addr ess t o a
r equest ing cl ient each t ime it r equest s an IP addr ess. The l engt h of t ime t hat a cl ient
uses an IP addr ess is known as t he lease. If a cl ient needs t o ext end t he l ease, it may
submit t hese r equest s t o t he ser ver . It is under st ood bet ween t he cl ient and t he ser ver
t hat if t he ser ver does not r eceive a message f r om t he cl ient indicat ing t hat t he cl ient
woul d l ike t o ext end t he l ease, t he ser ver assumes t hat t he cl ient is no l onger using
t he IP addr ess, and t he l ease expir es. However , a DHCP ser ver does not aut omat ical l y
r euse expir ed l eased IP addr esses. The ser ver wil l cont inue down t he number of IP
addr esses and assign t hose t hat have not been assigned unt il it exhaust s it s l ist of IP
addr esses. When t his occur s, t he ser ver wil l r eal l ocat e an IP addr ess t hat was
pr eviousl y assigned but has expir ed. The ser ver may pr obe t he net wor k t o see if t he
addr ess is st il l being used by simpl y sending an ICMP ECHO r equest and wait ing f or a
r epl y. As anot her consist ency check, t he host wit h t he newl y assigned addr ess may issue
an ARP t o see if t he addr ess has al r eady been assigned t o anot her host . Not ice, however ,
t he RFC pl aces t hese checks as SHOULD, which means t he impl ement er of t he pr ot ocol
shoul d impl ement t he f eat ur e, but it is not r equir ed. You may want t o ask bef or e
impl ement ing a specif ic vendor s DHCP code.
Lease Dur at ion
The l engt h of t ime t hat a cl ient has sol e use of an IP addr ess is known as a
l ease.
Lease dur at ion is negot iat ed bet ween t he cl ient and t he ser ver dur ing t he
Request /Of f er pr ot ocol .
Ther e is no synchr onizat ion of t imer s bet ween t he ser ver and a cl ient :
A ser ver may gr ant a smal l er t ime t han r equest ed t o t he cl ient , but
wr it e t he or iginal t ime in it s dat abase.
To ext end t he l ease, t he cl ient must r equest t his of t he ser ver :
If t her e is not an ext ension r equest , t he l ease expir es.
Times ar e based on a 32-bit int eger :
Dif f er ent impl ement at ions al l ow f or dif f er ent maximum l engt hs.
DHCP impl ement at ions may var y, but t he l ease t ime is a 32-bit unsigned int eger . This
number is expr essed in seconds, which al l ows f or a l ease t ime in t he r ange of 1 second t o
(appr oximat el y) 136 year sl onger t han I pl an t o be in t his business! Accor ding t o RFC
2131, t her e is no minimum l ease t ime r equir ement .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 321
Efficiencies
Cl ient s usual l y do not need al l t he conf igur at ion par amet er s t hat ar e avail abl e using
DHCP. To buil d some ef f iciency int o t his pr ot ocol , t he pr ot ocol assumes def aul t s. Host
r equir ement RFCs (1122, 1123) name t he def aul t f or t he par amet er s. When t he cl ient
r eceives t he DHCPNAK packet s t hat cont ain conf igur at ion inf or mat ion, a l ot of t he
inf or mat ion wil l not be incl uded. The host assumes t hat def aul t val ue f or anyt hing
not cont ained in t he DHCPNAK message.
Anot her quest ion shoul d have come int o your mind by now (if you wer e paying
at t ent ion). If a host is using DHCP f or it s init ial conf igur at ion, how does it know t o
accept TCP/IP packet s when TCP/IP has not been f ul l y init ial ized in t he host ? To wor k
ar ound t his pr obl em, DHCP uses t he Fl ags f iel d. The f iel d is 16 bit s in l engt h, but onl y 1
bit is used. The ot her 15 must be set t o 0. The bit t hat is used is cal l ed t he Broadcast bit, or
B bit. Any st at ion t hat cannot r eceive unicast dat agr ams (usual l y sent by BOOTP Rel ay
agent s and ser ver s on DHCPOFFER, DHCPACK, and DHCPNAK messages) must set t his bit
on DHCPDISCOVER and DHCPREQUEST messages. DHCP ser ver s pr ocessing t he r equest
wil l mar k t his bit and t r ansmit t heir r esponses as br oadcast in bot h t he IP header and
t he MAC header .
If t he br oadcast bit is set t o 0, t he r esponses of t he ser ver wil l be t r ansmit t ed as
unicast , wit h t he IP addr ess set t o Yiaddr and t he MAC dest inat ion addr ess set t o
Chaddr .
Final l y, a cl ient may use t he DHCPRELEASE message t o gr acef ul l y shut down or t o
indicat e t o t he DHCP ser ver t hat t he cl ient no l onger needs t he IP addr ess assigned by
t he ser ver . The cl ient does not have t o use t his message and may simpl y l et t he l ease
expir e.
Ef f iciencies
Not al l par amet er s ar e needed:
Ext ensive use of def aul t s
Set accor ding t o t he Host Requir ement RFCs 1122, 1123
Host assumes t he def aul t val ue f or anyt hing not cont ained in t he DHCPACK
message.
DHCP makes use of t he Fl ags f iel d t o wor k ar ound t he chicken-and-t he-egg
pr obl em of IP addr ess and ARP r esponses.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 322
Operational Tables
Oper at ional Tabl es
The page cont ains t he DHCP f iel ds and t he pr ocesses t hat set or r eset t he
f iel ds.
Oper at ional Tabl es (cont inued)
The page cont ains t he DHCP f iel ds and t he pr ocesses t hat set or r eset t he
f iel ds.
Fiel d DHCPOFFER DHCPACK DHCPNAK
op BOOTREPLY BOOTREPLY BOOTREPLY
ht ype (Fr om RFC
1700,AssignedNumber s)
hl en (Har dwar e addr ess
l engt hin oct et s)
hops 0 0 0
xid xid f r om cl ient xid f r om cl ient xid f r om cl ient
DHCPDISCOVER
message
DHCPREQUEST
message
DHCPREQUEST
message
secs 0 0 0
ciaddr 0 ciaddr f r om 0
DHCPREQUEST
or 0
yiaddr IP addr ess
of f er ed t o cl ient
IP addr ess
assigned t o
cl ient
0
siaddr IP addr ess of
next
IP addr ess of
next
0
boot st r ap ser ver boot st r ap ser ver
f l ags f l ags f r om cl ient f l ags f r om cl ient f l ags f r om cl ient
DHCPDISCOVER
message
DHCPREQUEST
message
DHCPREQUEST
message
giaddr giaddr f r om
cl ient
giaddr f r om
cl ient
giaddr f r om
cl ient
DHCPDISCOVER
message
DHCPREQUEST
message
DHCPREQUEST
message
chaddr chaddr f r om
cl ient
chaddr f r om
cl ient
chaddr f r om
cl ient
DHCPDISCOVER
message
DHCPREQUEST
message
DHCPREQUEST
message
sname Ser ver host name
or opt ions
Ser ver host name
or opt ions
(unused)
f il e Cl ient boot
f il ename
Cl ient boot
f il ename
(unused)
or opt ions or opt ions
opt ions opt ions opt ions (unused)
Fiel d DHCPDISCOVER
DHCPINFORM
DHCPREQUEST DHCPDELCINE
DHCPRELEASE
op BOOTREQUEST BOOTREQUEST BOOTREQUEST
ht ype (f r om RFC 1700,
Assigned Number s)
(f r om RFC 1700, Assigned
Number s)
(f r om RFC 1700,
Assigned Number s)
hl en (Har dwar e addr ess
l engt h in oct et s)
(Har dwar e addr ess l engt h in
oct et s)
(Har dwar e addr ess
l engt h in oct et s)
hops 0 0 0
xid Sel ect ed by cl ient xid f r om ser ver Sel ect ed by cl ient
DHCPOFFER message
secs 0 or seconds since DHCP 0 or seconds since DHCP 0
pr ocess has st ar t ed pr ocess has st ar t ed
ciaddr 0 (DHCPDISCOVER) or
cl ient s net wor k addr ess
(DHCPINFORM)
0 or cl ient s net wor k addr ess
(bound/r enew/r ebind)
(DHCPRELEASE)
0 (DHCPDECLINE) or
cl ient s net wor k
addr ess
yiaddr 0 0 0
siaddr 0 0 0
f l ags Set Br oadcast bit if
cl ient
Set Br oadcast bit if cl ient 0
r equir es a br oadcast
r esponse
r equir es a br oadcast r esponse
giaddr 0 0 0
chaddr Cl ient s har dwar e
addr ess
Cl ient s har dwar e addr ess
Cl ient s har dwar e
addr ess
sname Opt ions, if indicat ed in
sname/f il e opt ion;
ot her wise, unused
Opt ions, if indicat ed in
sname/f il e opt ion; ot her wise,
unused
(unused)
f il e Opt ions, if indicat ed in
sname/f il e opt ion;
ot her wise, unused
Opt ions, if indicat ed in
sname/f il e opt ion; ot her wise,
unused
(unused)
Opt ions Opt ions Opt ions (unused)

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 323
RFCs to Be Reviewed
RFCs t o Be Reviewed
951: Boot st r ap Pr ot ocol (BOOTP)
1534: Int er oper at ion bet ween DHCP and BOOTP
2131: Dynamic Host Conf igur at ion Pr ot ocol (DHCP)
2132: DHCP and BOOTP Vendor Ext ensions
951: Boot st r ap Pr ot ocol (BOOTP). This incl udes inf or mat ion on t he Rel ay
Agent .
1534: Int er oper at ion bet ween DHCP and BOOTP.
2131: Dynamic Host Conf igur at ion Pr ot ocol (DHCP). (obsol et es 1541)
2132: DHCP Opt ions and BOOTP Vendor Ext ensions. (obsol et es 1533)

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 324
Resource Reservation Protocol (RSVP)
QoS (Qual it y of Ser vice) is cur r ent l y l imit ed t o manual it ems such as f il t er s, pr ot ocol
pr ior it izat ion (f ancy f il t er s), compr ession, net wor k design, and f at pipes. Most of t hese
t echniques ar e appl ied t o WAN por t s. Whil e t hese int er im sol ut ions wor k wel l , many
appl icat ions such as voice and video ar e r unning on LANs and WANs. Ther e is anot her
st ep t o pr oviding QoS wit h br oadcast net wor ksRSVP. RSVP pr ovides a gener al f acil it y
f or cr eat ing and maint aining dist r ibut ed r eser vat ion st at es acr oss unicast or mul t icast
envir onment s. It is not supposed t o be t he QoS t hat r ival s ATMs guar ant eed QoS. It
shows pr omise as t he f ir st of many ent r ies int o buil ding QoS f or exist ing br oadcast -
or ient ed net wor ks wit hout having t o t ear out a net wor k and r epl ace it wit h ATM.
Qual it y of Ser vice has never been buil t int o most pr ot ocol s t hat ar e cur r ent l y r unning
on net wor ks t oday. When Et her net was invent ed in t he l at e 1970s, 10 Megabit s seemed a
huge-enough pipe t o give any bandwidt h-hungr y appl icat ion mor e t han enough r oom.
However , a bandwidt h-hungr y appl icat ion is not t he cul pr it ; t he cul pr it is mil l ions of
bandwidt h-hungr y users. Per sonal izing t he comput er was not t hought t o have a gr eat
impact on t he business wor l d. Mainf r ames and minicomput er s wer e expect ed t o cont inue
t o be t he comput ing sour ce of choice; however , t he PC changed t hat . Af t er a f ew year s,
t he per sonal comput er became abl e t o handl e sophist icat ed gr aphics, and many dif f er ent
opt ions of voice and video soon became avail abl e. Connect ion t o t he Int er net became a
must -have as wel l .
Resour ce Reser vat ion Pr ot ocol (RSVP)
QoS abil it ies on most IP net wor ks ar e usual l y about f il t er s, pr ot ocol
pr ior it izat ion (f ancy f il t er s), compr ession, and f at pipes (f ast or gigabit
Et her net ).
QoS never seemed l ike a pr essing issue unt il t he Web.
Cannot cont inue t o simpl y pr ovide f or f at t er pipes.
We must f ind a way t o al l ow mul t imedia t o wor k on t he exist ing
inf r ast r uct ur e.
ATM is not an al t er nat ive f or most impl ement at ions.
Shar ed Et her net and Token Ring net wor ks coul d not pr ovide t he bandwidt h necessar y
t o suppor t not onl y bandwidt h-int ensive appl icat ions t hat ar e net wor k awar e, but t he
mil l ions of per sonal comput er user s as wel l . Et her net has since scal ed t o 100 Megabit s
per second and Gigabit Et her net is making inr oads as wel l . The vir t ual l y l imit l ess
scal abil it y of t he ATM pr ot ocol is t he f ir st commer cial pr ot ocol t hat has QoS
scal eabl e par amet er s buil t in; however , ATM is st il l l ess t han 1 per cent of al l deskt op
inst al l at ions. And t her e ar e many consumer s t hat wil l not t ear down t heir Et her net
or Token Ring net wor ks and r epl ace it wit h ATM just t o get QoS and scal eabl e
bandwidt h. Consumer s want QoS, but t hey want it wit h t heir exist ing net wor ks.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 325
Alternatives
Al t er nat ives
Et her net al l ows us some scal ing wit h t hr ee speeds.
ToS of f er s dif f er ent pat hs based on an appl icat ion r equest .
RSVP is a pr ot ocol usef ul wher e impr oved Qual it y of Ser vice (QoS) woul d
enhance t r ansmission of an appl icat ions dat ast r eam and cr eat e higher
r el iabil it y of it s r ecept ion at t he r eceiving endst at ion(s).
An exampl e wher e RSVP woul d be appr opr iat e woul d be an appl icat ion f or
st r eaming video t o t he deskt op, in a mul t icast envir onment , in a r out ed
inf r ast r uct ur e.
Since it s incept ion, IP has had a f iel d known as Type of Ser vice (ToS). The ToS is f or
int er net ser vice qual it y sel ect ion and is specif ied al ong t he abst r act par amet er s of
pr ecedence, del ay, t hr oughput , r el iabil it y, and cost . These abst r act par amet er s ar e
mapped int o t he act ual ser vice par amet er s of t he par t icul ar net wor ks t he dat agr am
t r aver ses. Fil e t r ansf er s coul d t ake a high-del ay net wor k whil e t er minal access coul d
t ake one wit h l ow del ay (r ef er t o Par t III, t he IP Pr ot ocol ). In or der t o pr ovide f or t his,
r out er vendor s have t o pr ovide f or ToS in t heir r out er s, and appl icat ion vendor s have
t o buil d t his int o t heir appl icat ions. For r out er s, t his can r equir e t he maint enance of
mul t ipl e r out ing t abl es f or each ToS. The appl icat ion pr ogr am is t he pr ogr am t hat set s
t hese bit s and in t he past , most appl icat ion pr ogr ams moved dat a and t her e r eal l y was
no demand f or ToS. Over t he year s, we simpl y came up wit h f ast er net wor ks t o
compensat e f or t he mil l ions of new user s and bandwidt h-hungr y appl icat ionst he easy
way t o suppor t QoS is t o manipul at e t he bandwidt h.
Gigabit Et her net now al l ows us t hr ee choices f or Et her net : 10, 100, or 1000 Mbps. This
al l ows f or scal ing but not f or dat a QoS. Bandwidt h is simpl y one f act or in t he
equat ion. Al so, what comes af t er gigabit Et her net (t he cur r ent Pr oposal is 10 gigabit
Et her net )? Af t er t his we ar e f inal l y moving int o t he capabil it ies of ATM; however , we
st il l r un int o cust omer r esist ance t o ATM conver sion. They wil l pl ace ATM on t he
backbone and possibl y use it f or t he WAN, but not t o t he deskt op. We cannot keep
pr oducing mor e bandwidt h wit hout giving some consider at ion t o t aming t he
appl icat ions.
RSVP is t he f ir st widel y known pr ot ocol t o al l ow f or some t ype of QoS on an exist ing
br oadcast -or ient ed net wor k. As of t his wr it ing, it is st il l an RFC dr af t , wit h t he l at est
ver sion being t he f unct ional specif icat ion of May 1997. It can be used wit h IPv6 or IPv4.
RSVP cover s t he QoS por t ion of pr ot ocol s opt imized f or r eal -t ime, st r eaming, mul t imedia
issues. It oper at es dir ect l y on t op of IP and suppor t s bot h unicast and mul t icast
pr ot ocol s. The oper at ion of RSVP appear s t o have f ar gr eat er advant ages when used in
a mul t icast net wor k. It is not a t r anspor t pr ot ocol , but a cont r ol pr ot ocol l ike ICMP or
IGMP. Wit h IPv4, RSVP oper at es wit h UDP, but wit h IPv6, it wil l oper at e on t op of IP
using t he ext ension header concept .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 326
Where It Will Be Used
Let s be up f r ont : RSVP is not designed t o pr ovide QoS f or t he ent ir e Int er net . It s
or iginal design was t o al l ow QoS f or mul t imedia appl icat ions on smal l er net wor ks. It is
designed t o al l ow appl icat ions t o choose among mul t ipl e, cont r ol l ed l evel s of del iver y
ser vice f or t heir dat a packet s. It r eser ves net wor k r esour ces al ong t he t r ansmission
pat h of a dat ast r eam. It communicat es bet ween sending and r eceiving host s, but t he
cr eat ion of t he r eser vat ion is accompl ished by t he r eceiving host and onl y in one
dir ect ion f or dat a f l ows. Once t he r eser vat ion is made, r out er s bet ween t he sender and
r eceiver maint ain t he r eser vat ion. Final l y, it is not a r epl acement f or any of t he QoS
of f er ings in ATM. Many see it as t he migr at or y st ep in moving t o ATM.
Like ToS in t he IP header (IPv4), appl icat ions must be RSVP awar e. The user appl icat ion is
t he one t hat makes use of RSVP. As of t his wr it ing, t her e ar e just a f ew appl icat ions
t hat make use of RSVP; f or exampl e, WinSock (t he API f or Windows appl icat ions) is QoS
awar e st ar t ing wit h WinSock 2. Appl icat ions t hat ar e not RSVP awar e may be abl e t o
use RSVP t ool -kit s or dial er pr ogr ams, which ar e secondar y appl icat ions t hat can make
a r equest f or you bef or e st ar t ing your appl icat ion. Appl icat ions such as t hose t hat ar e
making use of ot her Int er net pr ot ocol s (such as Real Time Pr ot ocol (RTP), and t he Real
Time St r eaming Pr ot ocol (RTSP) ar e bet t er suit ed t o RSVP.
Wher e It Wil l Be Used
RSVP cover s t he QoS por t ion of pr ot ocol s opt imized f or r eal -t ime, st r eaming,
and mul t imedia issues:
RTSP: Real -Time St r eaming Pr ot ocol App Layer
RTP: Real -Time Tr anspor t Pr ot ocol s (RFC 1889)
RTCP: Fl ow/Cont r ol Mechanisms (RFC 1890)
RSVP: IETF Dr af t -14 (QoS)

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 327
Operation
Oper at ion
A basic RSVP r eser vat ion r equest (Resv message) consist s of a flowspec and a
filter spec t hat t oget her ar e cal l ed a flow descriptor.
flowspec def ines:
Ser vice cl ass desir ed (Guar ant eed or Cont r ol l ed-l oad)
Reser vat ion r equest ed (Rspec)
Descr ipt ion of t he dat a f l ow (Tspec)
filter spec, wit h t he session specif icat ion, def ines t he dat a f l ow t o r eceive t he
QoS def ined by t he flowspec.
Reser vat ion r equest s ar e made by t he r eceiver , not t he sender . Why? The r eceiver
bet t er under st ands it s l ocal par amet er s (such as LAN t ype) and is bet t er abl e t o make
an int el l igent r equest t han a ser ver ; ot her wise, we woul d have t o conf igur e t he ser ver
t o know ever y aspect of it s possibl e r eceiver s. For exampl e, if a ser ver must make a
bandwidt h r eser vat ion, how woul d it know t hat a r eceiver is on Et her net , Token Ring,
FDDI, or ATM? How woul d a ser ver know t he t ype of comput er making t he r eser vat ion?
Why does t his mat t er ? Speed. An ATM st at ion shoul d be abl e t o make a r equest l ar ger
t han an Et her net st at ion simpl y because t he bandwidt h is avail abl e. An appl icat ion on a
host uses RSVP t o r equest specif ic QoS f r om t he net wor k f or par t icul ar dat ast r eams or
f l ows f r om t he appl icat ion.
The oper at ion of RSVP is based on t wo concept s: flows and reservations. RSVP r eser ves
r esour ces based on a f l ow. Fl ows ar e t r af f ic st r eams (dat a) f r om a sender t o a r eceiver ,
or possibl y t o mul t ipl e r eceiver s. The f l ow is def ined by t he dest inat ion IP addr ess and,
opt ional l y, a dest inat ion por t . RSVP may al so def ine t he f l ow by using t he Fl ow Label
f iel d in t he IPv6 header in conjunct ion wit h t he sour ce IP addr ess. In combinat ion wit h
t he f l ow, RSVP det er mines t he QoS t hat a f l ow r equir es. QoS det er mines t he net wor k
r esour ces f or t he f l ow. RSVP does not int er pr et t he f l owspec, but it does give t hat
inf or mat ion t o host s and r out er s al ong t he f l ows pat h. Those syst ems can examine t he
f l owspec t o see if t hey have t he r esour ces t o accept t he r eser vat ion, and if t hey accept
it t hey use t he f l owspec t o r eser ve t he r equir ed r esour ces.
As st at ed bef or e, t he r eceiver s using RSVP act ual l y make t he r eser vat ions. This is t o
al l eviat e t he ser ver f r om being t he over al l administ r at or of al l t he possibl e r eceiver s.
Some r eceiver s ar e l ocat ed on Et her net , ot her s on Token Ring (speed dif f er ences). Some
may want t o l eave t he f l ow at any t ime. Receiver s have bet t er independent cont r ol
over t hemsel ves and t his al l ows f or f l exibil it y in RSVP.
The r eser vat ion is spl it int o t wo f unct ions: one is per f or med by t he sender , and one is
per f or med by t he r eceiver . Having t he r eceiver make t he r eser vat ion l eads t o a
quest ion: How does t he r eceiver know t he pat h by which t he f l ow wil l be f or war ded?
The sender wil l send Pat h messages t hat wil l f ol l ow a pat h f r om t he sender and be
pr opagat ed by r out er s. The Pat h message descr ibes t he f l ow t o any possibl e r eceiver s,
and al l ows r out er s t o get pr epar ed f or a possibl e f l ow. It ident if ies t he f l ow t o t he
r out er s and al er t s t he r out er s t o t he possibil it y of incoming r eser vat ion r equest s. For
mul t icast , a Pat h message is sent t o a dest inat ion mul t icast addr ess.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 328
Path Messages
When a sender t r ansmit s a Pat h message, it wil l be r eceived by r out er s al ong t he pat h.
A r out er inser t s it s own IP addr ess as t he messages l ast hop. As t he Pat h message is
pr opagat ed t hr ough t he net wor k, each r out er not es t he pr evious r out er s addr ess and
t hen inser t s it s own IP addr ess bef or e f or war ding t he Pat h message on. Having each
r out er not e t he l ast r out er s IP addr ess, f or a f l ow, al l ows a r out er t hat r eceives a
r eser vat ion r equest t o know how t o f or war d t hat r equest back in t he dir ect ion of t he
sender . This ensur es t hat t he r eceiver s wil l t ake t he cor r ect pat h f or a par t icul ar
f l ow. Why? Most net wor k designs have mor e t han one pat h and a r eceiver may make a
r eser vat ion in a pat h t hat t he sender did not specif y.
Pat h messages can be sent at any t ime and r out er s maint ain t he pat h st at e in what is
known as a soft st at e. Rout er s maint ain t he pat h inf or mat ion onl y f or a cer t ain per iod
of t ime, af t er which t hey wil l del et e t he st at e. This al l ows f or dynamic f l exibil it y in
t he pat h. A new pat h (via t opol ogy changes) may be set up t hat r ender s t he ol d pat h
obsol et e. A r out er may f ail in t he pat h and no al t er nat e pat h is avail abl e; t her ef or e,
t he pat h inf or mat ion is obsol et e and needs t o be del et ed.
Pat h Messages
Two f undament al RSVP message t ypes: Path and Resv messages.
Path messages descr ibe:
Pr evious hop IP (RSVP_HOP or PHOP)
For mat of t he dat a t o come (Sender Templ at e w/f il t er spec)
Tr af f ic char act er ist ics of t he dat ast r eam (Sender Tspec) and Adspec
(OPWA)
Sent end-t o-end f r om app host sender t o app host receiver, al ong exist ing r out es,
wit h t he same addr essing as dat a packet s.
Path messages st or e path state in each node al ong t he way (used by Resv
messages)

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 329
RSVP and Routers
RSVP al so r uns in r out er s and wor ks in conjunct ion wit h t he r equest s being
t r ansmit t ed by a net wor k appl icat ion. RSVP is used in r out er s t o f or war d QoS r equest s
t o al l st at ions al ong t he pat h or pat hs of t hat par t icul ar f l ow. It is al so up t o t he
r out er s t o est abl ish and maint ain an RSVP st at e. In ot her wor ds, if an appl icat ion makes
an RSVP r equest , each r out er must f or war d it t o anot her r out er en r out e t o t he
sour ce; yes, t he r ever se pat h, r eceiver t o sender .
An RSVP pr ocess uses t he l ocal r out e t abl e t o obt ain r out es.
QoS is impl ement ed by a col l ect ion of mechanisms known as traffic control. This incl udes
t hr ee mechanisms:
Packet cl assif ier : Det er mines t he QoS cl ass and possibl y t he r out er f or each
packet .
Admission cont r ol : Det er mines if r esour ces ar e avail abl e t o accept or r eject a
r equest .
Packet schedul er : Achieves t he pr omised QoS f or each out going int er f ace.
The sl ide shows a bl ock diagr am f or RSVP. Two modul es wit hin RSVP known as admission
control and policy control ar e ut il ized by a RSVP r equest . Admission cont r ol det er mines
whet her t he node has t he avail abl e r esour ces t o accept t he r equest (sounds l ike Cal l
Admission Cont r ol under ATM, r ight ?). Pol icy cont r ol det er mines t he per mission r ight s
of t he r equest er . If eit her of t hese checks f ail , t he r equest is discar ded and a message is
sent back t o t he r equest er (t he appl icat ion t hat made t he r equest ) indicat ing t he t ype
of f ail ur e. If bot h of t hese checks cl ear , t hen par amet er s ar e set in t he packet cl assif ier
and t he packet schedul er in hopes of obt aining t he r esour ces r equir ed by t he r equest .
RSVP and Rout er s

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 330
RSVP Requests
RSVP Request s
Resv messages: r eser vat ion r equest s sent hop by hop f r om host receiver(s) t o host
sender al ong t he r ever se pat h.
Each RSVP-speaking r eceiver node f or war ds a Resv message t o t he unicast
addr ess of t he pr evious RSVP hop.
Resv messages cr eat e and maint ain r eser vat ion st at es in each node al ong t he
pat h(s).
The most basic RSVP r equest consist s of a f l ow descr ipt or . A f l ow descr ipt or cont ains:
f l owspec: A r eser vat ion r equest t hat def ines a desir ed QoS and is used t o set
par amet er s in a nodes packet schedul er .
f il t er spec: Used t o def ine t he set of packet s t o r eceive QoS as def ined in t he
f l ow spec and t o set par amet er s in t he packet cl assif ier .
RSVP is based on sessions and def ines a session as a dat a f l ow wit h a par t icul ar
dest inat ion and t r anspor t -l ayer pr ot ocol . Each session is maint ained independent l y. It is
def ined by a combinat ion of :
Dest inat ion addr ess: A mul t icast or unicast dest inat ion addr ess.
Pr ot ocol ID :(Pr ot ocol ID is 46)
Dest inat ion por t : TCP or UDP por t number or an appl icat ion-specif ic por t number .
This may be omit t ed when t he dest inat ion addr ess is mul t icast .
Ther e ar e t wo message t ypes sent bet ween sender s and r eceiver s f or r eser vat ion of
r esour ces. These messages ar e not sent r el iabl y because t he pr ogr am uses IP dir ect l y:
Pat h: Sent downst r eam by t he RSVP sender host . This message is f or war ded by
r out er s using t he unicast /mul t icast r out ing t abl e. These messages st or e pat h
st at e in each f or war ding node. This inf or mat ion incl udes t he unicast IP addr ess of
t he pr evious hop node. This is used t o r out e t he Resv (sent by a r eceiver in r esponse
t o a Pat h message) messages in t he r ever se pat h. In addit ion, t he Pat h message
cont ains inf or mat ion on t he f or mat of dat a packet s t hat t he sender wil l
gener at e, t he t r af f ic char act er ist ics of t he dat af l ow, and may car r y adver t ising
inf or mat ion known as One Pass wit h Adver t ising (OPWA). This is known as an
Adspec and al l ows Pat h messages t o gat her inf or mat ion en r out e t o t he r eceiver
t hat t he r eceiver can use t o pr edict end-t o-end ser vice.
Resv: Sent upst r eam by t he r eceiver t o t he sender . They can eit her be dist inct or
shar ed, al l owing f or unique r eser vat ions t o occur f or r eceiver s or a singl e shar ed
r eser vat ion t hat is shar ed among al l packet s of sel ect ed sender s. These messages
ar e sent upst r eam al ong t he t r ee unt il it r eaches a point wher e an exist ing
r eser vat ion is equal or gr eat er t han t hat being r equest ed. At t hat point , t he
r eser vat ion is al r eady in pl ace and does not need t o be f or war ded any f ur t her .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 331
Reservation Style
In t his r eser vat ion r equest is a set of opt ions t hat ar e col l ect ivel y known as t he
reservation style. These opt ions al l ow f or shared or unique (distinct) r eser vat ions. Exampl es
of shar ed r eser vat ions ar e f or t hose invoking t he use of mul t icast . Video and audio apps
t hat make use of mul t icast ar e gr eat exampl es of t his. Why have mul t ipl e r eser vat ions
f or t hese r eceiver s when one guar ant eed pipe wil l do? The dist inct t ype of r eser vat ion is
f or one-on-one appl icat ions such as a smal l deskt op-t o-deskt op videoconf er ence or when
some ot her t ype of high-pr ior it y, l ow-l oss dat a st r eam is needed.
Reser vat ion St yl e
RSVP uses sever al r eser vat ion st yl es t o f it a var iet y of appl icat ions wit hin
Resv messages:
Styles ar e col l ect ive set s of opt ions incl uded in t he Resv r equest message
One opt ion concer ns t he t r eat ment of r eser vat ions as distinct or shared
Anot her opt ion cont r ol s t he sel ect ion of sender s, be t hat an expl icit
l ist or a wil dcar d impl ement at ion:
Wil dcar d-Fil t er (WF) st yl e
Fixed-Fil t er (FF) st yl e
Shar ed- Expl icit (SE) st yl e
A r eceiver may r equest a conf ir mat ion and wil l indicat e t his in t he Resv message al ong
wit h it s addr ess. One t he r eser vat ion is conf ir med eit her unique or mer ged, a
conf ir mat ion message is sent .
The basic r eser vat ion is compl et ed in one pass. This means t hat t he Resv message is sent
f r om one r out er t o anot her in t he r ever se pat h t o t he sender . Each r out er al ong t he
way has t he r ight t o r eject an Resv r equest .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 332
RSVP Control
These opt ions al so al l ow f or t he cont r ol of t he sel ect ion of sender s: explicit, which
al l ows f or a sel ect ed gr oup of sender s (each f il t er spec must mat ch exact l y one sender );
or a wildcard t hat impl icit l y sel ect s al l t he sender s t o t he session (no f il t er spec is
needed). These st yl es def ine how r eser vat ions ar e t r eat ed f r om dif f er ent sender s wit hin
t he same session, and if t he r equest s need t o meet a specif ic cr it er ia or not . Ther e ar e
t hr ee t ypes:
Wil dcar d f il t er t ype: Impl ies bot h t he shar ed r eser vat ion and t he wil dcar d
sender sel ect ion. This cr eat es a singl e r eser vat ion shar ed by f l ows f r om al l
upst r eam neighbor s. You can t hink of t his as a big pipe, compl et el y independent of
t he number of sender s using it , which is shar ed by mul t ipl e input s t o t he pipe. The
size is simpl y t he l ar gest of t he r esour ce r equest s f r om al l r eceiver s; it
aut omat ical l y ext ends t o new sender s as t hey appear .
Fixed Fil t er : Impl ies dist inct r eser vat ion and expl icit sender sel ect ion. This
al l ows a r eser vat ion t o be set up f or packet s f r om a par t icul ar sender , which ar e
not shar ed wit h ot her sender s packet s, even f r om t he same session. This st yl e can
quickl y use up al l avail abl e r esour ces.
Shar ed Expl icit : This impl ies shar ed r eser vat ion and expl icit sender . It cr eat es a
singl e r eser vat ion shar ed by sel ect ed, not al l , upst r eam neighbor s.
RSVP Cont r ol

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 333
Disabling a Reservation
Disabl ing a Reser vat ion
Pat hTear : Received by al l r eceiver s downst r eam and del et es t he pat h st at e in
each node.
ResvTear : del et es t he r eser vat ion st at e and t r avel s upst r eam t owar ds al l
sender s f r om it s point of init iat ion:
This message specif ies st yl es and f il t er s
Fl owspecs ar e ignor ed
Reser vat ions ar e r emoved by Teardown messages. This is not r equir ed, but is
r ecommended. If a r eser vat ion is not r emoved by t he appl icat ion, it wil l event ual l y be
r emoved by t he r out er sa Ref r esh message has not been r eceived and wit hin a cer t ain
amount of t ime, t he r eser vat ion must be r emoved. Ther e ar e t wo t ypes of Tear down
messages:
Pat hTear : Received by al l r eceiver s downst r eam (f r om t he point of init iat ion, not
necessar il y t he sender ) and del et es t he pat h st at e (in r out er s, f or exampl e) and
al l dependent r eser vat ion st at e in each node t hat r eceives t his inf or mat ion.
ResvTear : Del et es r eser vat ion st at e and t r avel s upst r eam t owar ds al l sender s
f r om it s point of init iat ion (again, not necessar il y t he f inal r eceiver ). This message
specif ies st yl e and f il t er s. Any f l owspec is ignor ed.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 334
Handling Errors
RSVP messages ar e sent unr el iabl y because t he pr ogr am uses IP dir ect l y, simil ar t o
IGMP or ICMP. The er r or messages t hat RSVP uses ar e Pat hEr r and ResvEr r . This is a
simpl ex pr ocess in t hat an er r or message is sent upst r eam t o t he sender t hat cr eat ed t he
er r or .
Handl ing Er r or s
RSVP messages ar e unr el iabl e.
Er r or messages ar e sent using t he Pat hEr r and ResvEr r .
Simpl ex pr ocess t hat is sent upst r eam t o t he sender t hat cr eat ed t he er r or .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 335
Merging Flowspecs
One l ast st at ement shoul d be made her e, a point t hat shoul d have come up as a quest ion
about mul t ipl e r eser vat ions being made and t he avail abil it y of r esour ces t o handl es
such r equest s. Given t he st at e of t odays r out er s, woul dnt we simpl y r un out of
r esour ces wit hin a shor t amount of t ime? The quest ion is har d t o answer and depends on
t he manuf act ur er of t he r out er . Some r out er s ar e high per f or mance, possess mul t ipl e
pr ocessor s (some of t hem on t he I/O car d), and have l ot s of memor y, high-speed
int er f aces, and so on.
Mer ging Fl owspecs
RSVP wil l accommodat e t r anspar ent oper at ions t hr ough non-RSVP-capabl e
devices or cl ouds.
One Pass Wit h Adver t ising (OPWA) is an RSVP enhancement t hat may be used
t o pr edict end-t o-end QoS.
RSVP wil l mer ge r eser vat ions as t hey t r avel upst r eam t o opt imize net wor k
r esour ces.
RSVP uses st yl es t o def ine specif ic opt ions desir ed by t he appl icat ion.
Some r out er vendor s do not suppor t t his. Ther ef or e, it is har d t o t el l how t his cont r ol
pr ot ocol (RSVP) is going t o wor k on r out er s.
Ther e ar e some ef f iciencies in t he RSVP pr ot ocol it sel f . One of t hem is cal l ed merging
flowspecs. Mul t ipl e r eser vat ion r equest s f r om dif f er ent next hops f or t he same session
and wit h t he same f il t er spec wil l have onl y one r eser vat ion on t hat int er f ace.
Cont ained in t he Resv message f or war ded t o a pr evious hop is t he l ar gest of t he
f l owspecs r equest ed by t he next hops t o which t he dat a f l ow wil l be sent . In ot her
wor ds, f l owspecs can be cumul at ive or mer ged.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 336
A Simple Example
An RSVP mul t icast exampl e is given wit h t he t hought of r eal -t ime and nonr eal -t ime.
Mul t icast t ends t o be a bandwidt h hog and as so, is t he f ir st exampl e used.
Bef or e a session can be cr eat ed, it must be ident if ied. This is accompl ished using t he
Dest Addr ess, Pr ot ocol ID and Dest Por t [opt ional ], which must be pr opagat ed t o al l t he
sender s and r eceiver s. The f ol l owing occur s dur ing a session set up:
The r eceiver joins a mul t icast gr oup using IGMP.
An RSVP-awar e appl icat ion st ar t s t o send Pat h messages t o t he mul t icast
dest inat ion addr ess, which wil l be r eceived by al l r eceiver s in t he mul t icast
gr oup.
A r eceiver sends a Resv message, specif ying t he desir ed f l ow descr ipt or s. These
wil l be r eceived by t he sender .
The sender st ar t s sending t he dat a packet s.
Once t he r equest has been accept ed and pr ocessed, t he r esour ces ar e r eser ved, but t hey
ar e in a soft state. A sof t st at e is one t hat has an ent r y, but r equir es some maint enance t o
st ay al ive. If t his maint enance is not appl ied, t he ent r y wil l be del et ed. This sof t st at e
maint ains t he r eser vat ion, and it is t he Pat h and Resv messages t hat ar e used t o
maint ain t his sof t st at e. This means t he r esour ces est abl ished can be modif ied
dynamical l y as changes occur . This sof t st at e is maint ained by RSVP sending r ef r esh
messages al ong t he pat h t o indicat e t o t he r out er s and nodes t o keep t he r esour ces
maint ained. If t hese Ref r esh messages ar e not r eceived, an RSVP r esour ce t imes out and
is del et ed.
A Simpl e Exampl e
This sl ide shows t he f l ow of t he act ual r eser vat ion message f r om t he RSVP App host .
A Simpl e Exampl e (cont inued)

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 337
Issues
Wont a r out er become over whel med wit h each r eceiver making RSVP r equest s?
No. Fir st , any r out er has t he capabil it y of r eject ing a r equest . Second, RSVP is
maint ained in t he r out er via a sof t st at e. A r eser vat ion wil l be t or n down when it is not
needed. Thir d, RSVP al l ows f or t he concept of merging. This al l ows r equest s t o be
mer ged t oget her (shar ed) when a r eser vat ion equal ing t he size of t he r equest is
al r eady in pl ace.
Wil l RSVP wor k in ar eas t hat do not suppor t it ?
Yes. The abil it y t o simpl y f l ip a swit ch and al l r out er s on t he Int er net ar e RSVP
capabl e is not a r eal it y. In 1983, we did f l ip a swit ch and al l r out er s (IMPs) and host s
wer e r unning t he TCP/IP pr ot ocol , but t oday we have mil l ions of r out er s connect ed t o
t he Int er net , and moving sl owl y is t he met hod. Ther ef or e, RSVP wil l be impl ement ed
sl owl y on t he Int er net .
We al so need some RSVP-awar e apps.
RSVP wor ks wit h non-RSVP envir onment s; however , t he non-RSVP envir onment s cannot
pr ovide any r eser vat ion. RSVP Pat h messages ar e f or war ded wit hout pr obl ems because
t hey use t heir l ocal unicast of mul t icast r out ing t abl es. In t he Pat h message is t he IP
addr ess of t he l ast RSVP-capabl e node bef or e t he message t r aver sed a non-RSVP node.
In t his way, a Resv message is t hen f or war ded dir ect l y t o t he next RSVP-capabl e r out er
on t he pat h back t owar ds t he sour ce. Fur t her mor e, t her e is a bit set t ing t hat RSVP
sends t o t he l ocal t r af f ic cont r ol mechanism when it knows t hat t her e ar e non-RSVP
nodes hops in t he pat h t o a given sender . This al l ows t he r out er t o combine t his wit h
ot her sour ces of inf or mat ion t o f or ewar d a message al ong t he pat h t o r eceiver s using
Adspecs.
Issues
Rout er s have t he capabil it y of r eject ing a r equest and r equest s can be mer ged.
Wor ks in ar eas t hat ar e not suppor t ing it .
To make use of RSVP, appl icat ions must be RSVP awar e, and t her e ar e f ew:
Apps may be r ewr it t en t o use QoS-sensit ive APIs such as WinSock 2
Exist ing apps may use RSVP Dial er pr ogr ams or t ool kit s inst ead
Int r anet ver sus Int er net usage.
Int er net ISPs coming up wit h bil l ing pr ocedur es f or cl ient s who desir e
QoS capabil it ies

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 338
RSVP Summary
RSVP Summar y
Resour ce ReSer Vat ion Pr ot ocol (RSVP) is a pr ot ocol used t o r eser ve net wor k
r esour ces al ong t he t r ansmission pat h(s) of a dat ast r eam:
The goal being t o obt ain opt imal QoS f or t hat appl icat ion inst ance
RSVP communicat es bet ween sending and r eceiving host s wit h t he r eceiver s
cr eat ing t he act ual r eser vat ion f or t he session:
Reser vat ions ar e made by r eceiver s upstream back t owar ds t he sender (s)
The f ocus of r eser vat ions is on Net wor k l ayer r esour ces in
int er connect ing devices (i.e., r out er s, or devices act ing as r out er s)
The f ol l owing sl ide summar izes t he chapt er .
The f ol l owing sl ide is a cont inuat ion of t he summar y.
RSVP Summar y (cont inued)
RSVP oper at es on t op of IP, occupying t he pl ace of a Tr anspor t pr ot ocol and
wor ks as an internet control pr ot ocol simil ar t o ICMP.
Suppor t s unicast and mul t icast pr ot ocol s:
Designed t o accommodat e l ar ge, het er ogeneous gr oups of user s wit h
dynamic member ships and t opol ogy
RSVP is unidir ect ional , or onl y makes r eser vat ions in one dir ect ion f or dat a
f l ows.
Once a r eser vat ion is made, it s maint ained by using sof t st at e in t he r out er s:
Sof t st at e pr ovides gr acef ul suppor t f or member ship changes and
adapt at ion t o r out ing changes

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 339
Conclusion
Individual user demands f or bet t er IP ser vice ar e dr iving t he need f or some t ype of
bandwidt h r eser vat ion. Most of us cont inue t o use t he phone as t he st andar d t o
compar e t o. The Int er net cont inues t o del iver y any t ype of dat a based on a f ir st -come-
f ir st -ser ved basis. The Int er net r out er s st il l dr op an ext r aor dinar y amount of packet s
over t he Int er net , causing r et r ansmissions. Mor e appl icat ions ar e r unning over t he
Int er net ever y day. Mul t imedia appl icat ions ar e t he ones t hat r equir e QoS onl y because
t he user s demand it . We have expect ed it due t o t he t el ephone and cabl e TV net wor ks.
RSVP wil l al l ow f or t his t o exist , but it wil l r emain onl y in pocket s of net wor ks and
not t hr oughout t he Int er net . RSVP wil l pl ace gr eat demands on t he r out er s. Todays
r out er s have yet t o pr ove t hey can handl e anyt hing mor e t han simpl e dat a f or war ding,
and t hey ar e not doing that ver y wel l . Fast er r out er s ar e coming ont o t he mar ket and
wil l hel p al l eviat e t he pr obl em.
The Int er net is becoming channel ized, which means t hat t her e wil l be st r eams of dat a
r unning acr oss t he Int er net t hat a user can t une in t o. The point t hat I am t r ying t o
make her e is t hat QoS is made up of many f act or s, and RSVP is simpl y one of t he f act or s.
Do not t hink t hat by appl ying RSVP, al l your t r oubl es wil l disappear . You must
cont inue t o appl y t he ot her f act or s as wel l , such as compr ession, f il t er s, pr ot ocol
pr ior it izat ion, net wor k design, OSPF, IP addr ess summar ies, and so f or t h. One mor e t hing:
Mul t imedia r eal l y r equir es (f or best oper at ion) t hat mul t icast be enabl ed. Onl y
r ecent l y have ISPs st ar t ed t o mul t icast enabl e t heir net wor ks (even wit h t he ent ir e
Int er net being nonmul t icast ). St r eaming r eal -t ime dat a acr oss t he Int er net is not ver y
ef f icient .
Concl usion
RSVP is one ar ea addr essing QoS issues t hat ar e dr iving f or ces f or f ut ur e
net wor king r equir ement s:
Web-based ever yt hingwave of t he f ut ur e
Real -t ime video apps and pr ot ocol avail abil it y
Int egr at ion of voice and dat a capabil it ies, avail abil it y of mul t imedia
t echnol ogy, mul t icast net wor ksal l onl y incr eases t he demand f or QoS
f eat ur es
Specif icat ions such as RSVP wil l onl y aid in br idging t he gap bet ween Layer 2
and Layer 3 QoS capabil it ies.
View www.isi.edu/r svp.
Last l y, you shoul d be awar e t hat RSVP is not an at t empt t o r ecover l ost gr ound f r om
ATM as some Et her net zeal ot s woul d have you bel ieve. ATM and ot her sof t war e and
har dwar e t echnol ogies wil l cont inue t o int egr at e. RSVP is t he f ir st at t empt t o pr ovide
f or some t ype of Qual it y of Ser vice based on a user -by-user need.
The RSVP homepage can be f ound at : www.isi.edu/r svp

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 340
Simple Network Management Protocol (SNMP)
Net wor k Management can be br oken down int o f ive dist inct cat egor ies:
Account management : Gat her s inf or mat ion on which user s or depar t ment s ar e
empl oying which net wor k ser vices.
Faul t management : Incl udes t r oubl eshoot ing, f inding, and cor r ect ing f ail ed or
damaged component s, monit or ing equipment f or ear l y pr obl em indicat or s, and
t r acking down dist r ibut ed pr obl ems.
Secur it y: Incl udes aut hor izat ion, access cont r ol , dat a encr ypt ing, and
management of encr ypt ing keys.
Conf igur at ion management : Tr acks har dwar e and sof t war e inf or mat ion.
Incl uded wit h t his ar e administ r at ion t asks, such as day-t o-day monit or ing and
maint enance of t he cur r ent physical and l ogical st at e of t he net wor k, as wel l as
r ecognit ion and r egist r at ions of appl icat ions and ser vices on t he net wor k.
Per f or mance: The monit or ing of t r af f ic on t he net wor k.
Net wor k management is divided int o f ive cat egor ies:
Account management
Faul t management
Secur it y
Conf igur at ion management
Per f or mance

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 341
SNMP Elements
Ther e ar e sever al el ement s t hat compr ise SNMP and t hey al l must wor k t oget her in
or der f or SNMP t o oper at e.
Management ser ver : The net wor k st at ion t hat r uns t he management appl icat ion
t o monit or or cont r ol t he management cl ient s.
Management cl ient s: The net wor k st at ion t hat cont ains t he agent (a sof t war e
component ), which enabl es t he management ser ver t o cont r ol and monit or t hem.
The agent can be l ocat ed in any dir ect l y at t ached net wor k device such as r out er ,
a PC, a swit ch, et c.
SNMP: A Request /Response pr ot ocol t hat al l ows f or t he exchange of inf or mat ion
bet ween t he ser ver and an agent . This pr ot ocol does not def ine t he it ems t hat can
be managed.
MIB: The Management Inf or mat ion Base. A col l ect ion of object s t hat cont ain
inf or mat ion t hat wil l be ut il ized by a net wor k management ser ver . It cont ains
al l of t his inf or mat ion under an ent it y known as object. Simil ar object s ar e pl aced
t oget her t o f or m gr oups. In ot her wor ds, t he MIB is a dat abase. It is a col l ect ion
of object s f or med int o gr oups, each of which cont ains inf or mat ion t hat wil l be
given based on a r equest f r om a management st at ion.
SNMP El ement s

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 342
SNMP Manager
An SNMP manager is a sof t war e appl icat ion t hat quer ies t he agent s f or inf or mat ion, or
set s inf or mat ion on t he cl ient agent . The r et ur ned inf or mat ion is t hen st or ed in a
dat abase t o be manipul at ed by ot her appl icat ion sof t war e t hat is not def ined by SNMP.
The inf or mat ion gat her ed can be used t o displ ay gr aphs of how many byt es of
inf or mat ion ar e t r ansmit t ed out a por t , how many er r or s have occur r ed, and so f or t h.
SNMP simpl y set s or gat her s inf or mat ion in a node.
Ther ef or e, t he ser ver wil l be compr ised of t wo t hings:
Management appl icat ions: Appl icat ions t hat can r eceive and pr ocess t he
inf or mat ion gat her ed by t he SNMP manager . These appl icat ions ar e t he ones t hat
have some t ype of user int er f ace t o al l ow t he net wor k manager t o manipul at e
t he SNMP pr ot ocol ; f or exampl e, set t he SNMP node t hat it woul d l ike t o t al k t o,
send t hat node inf or mat ion, get inf or mat ion f r om t hat node, and so on.
Dat abases: The inf or mat ion t hat is st or ed in t he dat abase is f r om t he
conf igur at ion, per f or mance, and audit dat a of t he agent s. Ther e ar e mul t ipl e
dat abases on t he ser ver : t he MIB dat abase, t he Net wor k El ement dat abase, and
t he Management Appl icat ion dat abases (Topol ogy dat abase, Hist or y Log, Monit or
Logs).
Al l of t his r uns on t op of SNMP. It is not necessar y f or SNMP t o oper at e, but it does
al l ow f or t he human f act or t o f it in.
SNMP Manager

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 343
Agent
Agent s ar e simpl e el ement s t hat have access t o a net wor ks el ement s (r out er , swit ch,
PC, et c.) MIB. Agent s ar e t he int er f ace f r om t he net wor k management ser ver t o t he
cl ient MIB. They per f or m ser ver -r equest ed f unct ions. When a ser ver r equest s
inf or mat ion f r om a cl ient , it wil l buil d it s SNMP r equest (expl ained in a moment ) and
send it , unicast , t o t he cl ient . The agent r eceives t his r equest , pr ocesses it , r et r ieves or
set s t he inf or mat ion in t he MIB of t he cl ient , and gener at es some t ype of r esponse t o
t he ser ver . Usual l y, agent s onl y t r ansmit inf or mat ion when r equest ed by a ser ver .
However , t her e is one inst ance in which an agent wil l t r ansmit unsol icit ed inf or mat ion.
It is known as a trap.
Ther e ar e cer t ain t hings on a net wor k st at ion t hat may f or ce it t o immediat el y not if y
t he ser ver . Some of t hese t r aps ar e def ined by t he RFC. Things such as col d/war m st ar t
and aut hent icat ion f ail ur e ar e t r aps t hat ar e sent t o t he ser ver . Most agent
appl icat ions t oday per mit t he use of user -def ined t r aps. This means t hat t he net wor k
administ r at or of an SNMP compl iant device can conf igur e t he r out er t o send t r aps t o
t he ser ver when cer t ain condit ions ar e met . For exampl e, a r out er may send a t r ap t o
t he ser ver when it s memor y buf f er s const ant l y over f l ow or when t oo many ICMP
r edir ect s have been sent .
Anot her t ype of agent is known as t he proxy agent. This al l ows one st at ion t o become an
agent f or anot her net wor k st at ion t hat does not suppor t SNMP. Basical l y, pr oxy
agent s ser ver as t r ansl at or s bet ween ser ver s and non-SNMP capabl e cl ient s (f or
secur it y, l imit ed r esour ces, et c.).
Agent

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 344
Management Information Base (MIB)
The MIB is a col l ect ion of object s t hat cont ain specif ic inf or mat ion t hat t oget her f or m
a gr oup. You can t hink of a MIB as a dat abase t hat cont ains cer t ain inf or mat ion t hat
was eit her pr eset (dur ing conf igur at ion of t he node) or was gat her ed by t he agent and
pl aced int o t he MIB. Simpl y st at ed, t he MIB is a dat abase t hat cont ains inf or mat ion
about t he cl ient t hat is cur r ent l y pl aced on it .
The st r uct ur e of management inf or mat ion is def ined in RFC 1155 and def ines t he f or mat
of t he MIB object s. This incl udes t he f ol l owing:
Management Inf or mat ion Base (MIB)
Col l ect ion of object s t hat cont ain specif ic inf or mat ion t hat t oget her f or m a
gr oup.
St r uct ur e of Management Inf or mat ion is specif ied in RFC 1155.
The object s cont ain t he f ol l owing:
Synt ax
Access
St at us
Descr ipt ion
Index
Def Val
Val ue not at ion
Synt ax Requir ed. The abst r act not at ion f or t he object t ype. This def ines t he
dat a t ype t hat model s t he object .
Access Requir ed. Def ines t he minimal l evel of suppor t r equir ed f or t he object
t ypes. Must be one of r ead-onl y, r ead-wr it e, wr it e-onl y, or not
accessibl e.
St at us Requir ed. The st at us of t he MIB ent r y. Can be mandat or y, opt ional ,
obsol et e, or depr ecat ed (r emoved).
Descr ipt ion Opt ional . A t ext descr ipt ion of t he object t ype.
Index Pr esent onl y if t he object t ype cor r esponds t o a r ow in a t abl e.
Def Val Opt ional . Def ines a def aul t val ue t hat may be assigned t o t he object
when a new inst ance is cr eat ed by an agent .
Val ue Not at ion The name of t he object , which is an Object Ident if ier .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 345
Example MIB Entry
Exampl e MIB Ent r y
Object:
IfOperStatus {ifEntry 8}

Syntax:
INTEGER {
up (1) ready to pass packets
down(2),
testing (3) in some test mode
}
Definition:
The current operational state of the
interface. The testing (3) state indicates
that no operational packets can be
passed.
Access:
Read-only.
Status:
Mandatory.
Object :
-------
ifOperStatus { ifEntry 8 }
Syntax:
INTEGER {
up(1), ready to pass packets
down(2),
testing(3) in some test mode
}
Def init ion:
The cur r ent oper at ional st at e of t he int er f ace. The t est ing(3) st at e indicat es
t hat no oper at ional packet s can be passed.
Access:
Read-onl y.
St at us:
Mandat or y.

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 346
The Protocol of SNMP
SNMP is t he pr ot ocol t hat is used bet ween a manager and a cl ient . SNMP uses a ser ies
of SNMP commands and pr ot ocol dat a unit s (PDUs) t o send and r eceive management
inf or mat ion. SNMP was event ual l y t o be migr at ed t o t he OSI management scheme
(which never came about ). Ther ef or e a encoding scheme known as Abst r act Synt ax
Not at ion, or ASN.1, was used. Onl y t he INTEGER, OCTET, STRING, OBJECT IDENTIFIER,
NULL, SEQUENCE, AND SEQUENCE OF ar e used. Ther e ar e mor e encodings, but t hey ar e
not used.
SNMP uses UDP as it s t r anspor t l ayer .
The f ol l owing ar e t he SNMP pr ot ocol dat a unit (PDU Packet ) t ypes:
Get Request . Request s an agent t o r et ur n at t r ibut e val ues f or a l ist of managed
object s.
Get Next Request . Used t o t r aver se a t abl e of object s. Since t he object at t r ibut es
ar e st or ed in l exicogr aphical or der , t he r esul t of t he pr evious Get Next Request
can be used as an ar gument in a subsequent Get Next -Request . In t his way, a
manager can go t hr ough a var iabl e-l engt h t abl e unt il it has ext r act ed al l t he
inf or mat ion f or t he same t ypes of object s.
Get Response. Ret ur ns at t r ibut e val ues f or t he sel ect ed object s or er r or
indicat ions f or such condit ions as inval id object name or nonexist ent object .
Set Request . Used t o change t he at t r ibut e val ues of sel ect ed object s.
Tr ap. Used by t he agent . Tr aps ar e used t o r epor t cer t ain er r or condit ions and
changes of st at e t o t he managing pr ocess. The condit ions ar e col d-st ar t , war m-
st ar t , l ink-up, l ink-down, EGP neighbor l oss (not much use f or t his one anymor e),
and aut hent icat ion f ail ur e.
The pr ot ocol of SNMP
SNMP pr ovides f or a simpl e aut hent icat ion pr ocess bet ween t he cl ient and t he ser ver .
This is known as t he community string and it must mat ch bet ween a cl ient and t he ser ver .
This st r ing is embedded in t he pr ot ocol packet and if eit her side has a dif f er ent ent r y,
t he r eceived SNMP packet is discar ded. This communit y st r ing is manual l y conf igur ed on
t he ser ver and t he cl ient . The pr obl em is t hat it is not encr ypt ed in any way when it is
t r ansmit t ed. Any pr ot ocol anal yzer t hat is on t he same l ink as t his packet can see t he
communit y st r ing name. It is pl ain t ext .

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Chapter 347
SNMP Encapsulation
The f ol l owing sl ide shows t he encapsul at ion of an SNMP packet .The communit y st r ing
is a simpl e passwor d pr ot ect ion mechanism. Most ar e set t o publ ic f or r ead access and
pr ivat e f or r ead-wr it e access. This f iel d is est abl ished at set up t ime.
The var iabl e binding indicat es which gr oups or which object s in t he gr oups ar e being
r equest ed f or inf or mat ion.
SNMP Encapsul at ion

Illustrated TCP/IP
ISBN: 0471196568 Pub Date: 11/01/98
Index
A
ABR. See Ar ea Bor der Rout er .
Absol ut e name, 329
Account management , 476
ACK, 248, 285, 290293, 295299, 402
Acknowl edgement , 290291, 295
exampl e, 292293
f iel d, 285
number , 284
Adapt ive r et r ansmission al gor it hm, 295
Addr ess
aggr egat ion, 113, 114
al l ocat ion, 9697
assignat ion. See Int er f ace.
aut oconf igur at ion, 235
def init ions, 113114
ef f iciency, 115116
f iel ds, 84
f or mat , 368
pr obl ems, 108110
r ecor ds, 338339
r esol ut ion, 235, 238239
schemes, 67
t er ms, 113114
Addr ess assignment , 95, 97, 105, 123. See also Int er net Assigned Number s Aut hor it y;
Int er net Ser vice Pr ovider addr esses.
r el axat ion, 123124
Addr ess f amil y ident if ier (AFI), 169
Addr ess Resol ut ion Pr ot ocol (ARP), 39, 46, 100101, 106, 107, 146, 147, 236, 237, 438,
439. See also Pr oxy ARP; Rever se Addr ess Resol ut ion Pr ot ocol .
cache, 263
oper at ion, 102104
packet f or mat , 101102
pr ot ocol . See Appl eTal k.
r epl y packet , 103
r ul es, 104105
t abl e, 104, 146, 204
Addr ess Unr eachabl e, 257
Addr essabl e st at ions, 144
Addr essing, 50, 51
t ype r eview, 363364
Adjacency, 189190
Adjacent r out er s, 189
Admission cont r ol , 459
Advanced Resear ch Pr oject Agency (ARPA), 11, 12
AFI. See Addr ess f amil y ident if ier .
Agent s, 477
Al l Subnet s Br oadcast (ASB), 140
AND oper at ion, 86
ANDing, 81, 86
Anycast , 220
addr essing, 249
API, 358, 456
APNIC, 28, 96, 226, 230, 342
APOP, 352
Appl eTal k, 8, 101, 157, 158, 165
ARP pr ot ocol , 101
Appl eTal k Remot e Access (ARA), 8
Appl icat ion-specif ic message, 315
ARA. See Appl eTal k Remot e Access.
Ar ea Bor der Rout er (ABR), 181, 182, 184, 192196, 411, 422425
Ar ea ID, 191
ARP. See Addr ess Resol ut ion Pr ot ocol .
ARPA. See Advanced Resear ch Pr oject Agency.
ARPAnet , 8, 11, 14, 24, 100, 111, 154, 175, 325
Net wor king Gr oup, 12
r out ing t abl es, 80
AS. See Aut onomous Syst em.
ASB. See Al l Subnet s Br oadcast .
ASBR. See Aut onomous Syst em Boundar y Rout er .
ASCII, 31, 323, 350
Assigned por t number s, 278, 279
Asynchr onous Tr ansf er Mode (ATM), 27, 38, 144, 180, 186, 234, 359, 456459, 462, 475
ATM. See Asynchr onous Tr ansf er Mode.
Aut hent icat ion, 167, 169, 174, 209, 217
t ype, 169
Aut oconf igur at ion, 231232. See also St at ef ul aut oconf igur at ion; St at el ess
aut oconf igur at ion.
Aut omat ic t unnel ing, 240
Aut onomous Syst em (AS), 42, 45, 111, 140, 179, 181, 195197, 411, 412, 426
Ext er nal Link Adver t isement , 184, 198
inf or mat ion, 197
Aut onomous Syst em Boundar y Rout er (ASBR), 181, 197, 412, 425
Summar y Link Adver t isement , 184
Aut o-r eaddr essing, 252
B
B bit . See Br oadcast .
Backbone, 14, 15, 193, 194, 195. See also FDDI.
ar ea, 193
communicat ion, 20
connect ivit y, 195
net wor k, 13
pr ovider , 124
Backbone Rout er (BR), 181, 422
Backup Designat ed Rout er (BDR), 179, 182, 187189
r ol e, 417
Banyan. See VINES.
BDR. See Backup Designat ed Rout er .
Because It s Time Net wor k (BITNET), 12, 13, 349
Ber kel ey Int er net Name Domain (BIND), 344
Best -ef f or t del iver y ser vice. See Connect ionl ess best -ef f or t del iver y ser vice.
Best -ef f or t r el iabil it y, 364
BGP. See Bor der Gat eway Pr ot ocol .
BIND. See Ber kel ey Int er net Name Domain.
BITNET. See Because It s Time Net wor k.
Boot Pr ot ocol (BOOTP), 39, 49, 105, 106, 172, 429, 430, 437
dil emma, 438439
f iel d def init ions, 434, 437
gat eway, 439440
oper at ion, 431
r el ay agent s, 439441, 445, 451
BOOTP. See Boot Pr ot ocol .
BOOTREPLY, 431, 434, 438, 439
BOOTREQUEST, 431436, 438
Boot st r ap r out er (BSR), 409
Bor der Gat eway Pr ot ocol (BGP), 42, 145, 171, 197
Bor der r out er s, 399
BR. See Backbone Rout er .
Br oadcast , 364
addr esses, 174
bit (B bit ), 451
packet , 76
Br oadcast ing, 75
BSR. See Boot st r ap r out er .
Business net wor ks, 127
Bye message, 314
C
Cache. See For war ding cache.
ent r ies. See Int er net Pr ot ocol IPv6.
CAD/CAM syst ems, 316
Cal if or nia Educat ional Resear ch Net wor k (CERFnet ), 13
Cal l Admission Cont r ol , 462
Candidat e RP (C-RP), 409
Canonical name (CNAME), 313, 339
CATNIP, 211
CBT. See Cor e-Based Tr ee.
CERFnet . See Cal if or nia Educat ional Resear ch Net wor k.
Checksum, 214, 285
f iel ds, 6162
CIDR. See Cl assl ess Int er -Domain Rout ing.
Cir cuit swit ching, 2728. See also Vir t ual cir cuit swit ching.
CIX. See Commer cial Int er net eXchange.
Cl ass A, 132
exampl e, 126
net wor ks, 131
subnet t ing exampl e, 8182
Cl ass A addr ess, 6772, 75, 7981, 87, 94, 95, 108, 109, 133
f or mat , 368
r eview, 7778
Cl ass addr esses/addr essing, 138, 139, 222
Cl ass B, 132
exhaust ion, 110
net wor k, 85, 131
pr ef ix, 135
Cl ass B addr ess, 41, 6770, 7273, 7983, 87, 94, 102, 108, 109, 117, 133
f or mat , 368
r eview, 7778
Cl ass C, 132, 135, 136
assignment , 124
net wor k, 93, 111, 131
Cl ass C addr ess, 6770, 7475, 7981, 87, 88, 93, 94, 108, 109, 115, 121, 123125, 131,
133, 135, 137, 343
f or mat , 368
r eview, 7778
Cl ass D addr ess, 6870, 7576, 367, 369, 418
r eview, 7778
Cl ass D addr essing, 250
Cl ass E addr ess, 6870, 95
Cl ass ident if icat ion, 6970
Cl assf ul addr esses, 115
Cl assf ul addr essing, 67
Cl assf ul IP addr ess r eview, 94
Cl assf ul net wor k addr essing scheme, 66
Cl assl ess Int er -Domain Rout ing (CIDR), 66, 109, 110, 113115, 130132, 223, 230, 251
r out er domain, 140
VLSM, compar ison, 138139
Cl assl ess IP, 67
addr essing, 113
Cl assl ess net wor k addr essing scheme, 66
Cl ient side, 435436
CLNP. See Connect ionl ess Pr ot ocol .
Cl osed syst em, 11
CME. See Cust omer pr emise equipment .
CNAME. See Canonical name.
CNRI. See Cor por at ion f or Nat ional Resear ch Init iat ives.
Commer cial Int er net eXchange (CIX), 14
Common pr ef ix, det er minat ion, 127128
Communicat ion wit h Dest inat ion, 257
Compat ibil it y swit ch, 167
Comput er Science Net wor k (CSNET), 12, 13
Concat enat ed header s, 215
Concent r ic Net wor ks, 226
Conf igur at ion management , 474
Conf igur ed t unnel ing, 240
Congest ion avoidance, 296298
Congest ion cont r ol , 298
Connect ionl ess best -ef f or t del iver y ser vice, 5051
Connect ionl ess Pr ot ocol (CLNP), 210, 233
Connect ionl ess t r anspor t -l ayer ser vice, 48
Cont r ol bit s, 284
Conver gence, 163
Conver sion, exampl e, 8687
Conver t ed IP mul t icast addr ess, 371
Cor e-Based Tr ee (CBT), 378, 386387, 410
f il es, 362
Cor por at ion f or Nat ional Resear ch Init iat ives (CNRI), 23
CRC. See Cycl ic Redundancy Check.
C-RP. See Candidat e RP.
CSNET. See Comput er Science Net wor k.
CSRC, 313
Cumul at ive ACK, 291
Cust omer pr emise equipment (CME), 359
Cycl ic Redundancy Check (CRC), 61, 62, 147, 148, 204
D
DARPA. See Depar t ment of Def ense Advanced Resear ch Pr oject s Agency.
Dat a encapsul at ion. See Layer s.
Dat a of f set , 284
Dat a Ser vice Unit /Cust omer Ser vice Unit (DSU/CSU), 202, 203
Dat a t r ansf er , 50, 219, 285
Dat abase
descr ipt ion packet , 189
f il es, 332, 336
maint enance, 190191
Dat agr ams, 52, 56, 58, 59, 63, 126, 150, 175, 218, 249, 274, 279, 368, 381. See also
Int er net Pr ot ocol .
f r agment at ion, 50
r eceiving. See Mul t icast .
Dat al ink l ayer , 52
DBR, 188
DDN. See Def ense Dat a Net wor k.
Dead Gat eway Det ect ion, 236
DECnet , 6, 7
Def aul t gat eways, 158159
Def aul t r out er s, 158159, 235
Def ense Dat a Net wor k (DDN), 12
Demul t ipl exing, 277
Dense Mode, 378, 398. See also Pr ot ocol -Independent Mul t icast Dense Mode.
Depar t ment of Def ense Advanced Resear ch Pr oject s Agency (DARPA), 912, 14, 22
Int er net , 12
Designat ed Rout er (DR), 181, 182, 184, 187189, 403407. See also Backup designat ed
r out er .
r ol e, 417
Dest inat ion Addr ess, 103, 261, 463, 469. See Addr ess Resol ut ion Pr ot ocol .
f iel ds, 6465
Dest inat ion cache, 254
Dest inat ion mul t icast gr oup, 421
Dest inat ion opt ions, 216
Dest inat ion por t , 284, 463, 469
number , 278
Dest inat ion Unr eachabl e Type, 356
DHCP. See Dynamic Host Conf igur at ion Pr ot ocol .
Diagr am r out ing, 203204
Dial -in user s, 25
Dir ect r out ing, 145146
Dir ect ed br oadcast , 95
Diskl ess wor kst at ions, 105
Dist ance Vect or Mul t icast Rout ing Pr ot ocol (DVMRP), 213, 366, 377, 378, 382384,
387389, 398, 399, 412, 419, 425, 427
r out e t abl es, 394395
t abl es, 393394
t unnel ing, 396
Dist ance vect or s, 149151
Dist ance-vect or al gor it hms, 154
Dist inct r eser vat ions, 464
DMVRP, 359
DNS. See Domain Name Ser vice.
Domain Name Ser vice (DNS), 39, 49, 221, 277, 316318, 325326, 339, 340, 345, 346
component s, 328329
dat abase, exampl e, 335
inf or mat ion, 344
int er act ion. See Mail .
Micr osyst ems, 2
st r uct ur e, 327328
t opol ogy, 353
Domain st r uct ur e, 330331
DOS, 17, 64, 156, 317, 319, 320, 323, 327, 337
Dot t ed decimal not at ion syst em, 67
Dot t ed-decimal not at ion, 221
Downst r eam int er f aces/neighbor s, 421
DR. See Designat ed Rout er .
Dr af t RFCs, 377, 387
DRARP. See Dynamic Rever se Addr ess Resol ut ion Pr ot ocol .
DSU/CSU. See Dat a Ser vice Unit /Cust omer Ser vice Unit .
Dual IP l ayer /st ack, 239, 242
Dual st ack IP, 240, 241
Dual -st ack st r at egy. See Int er net Pr ot ocol IPv4; Int er net Pr ot ocol IPv6.
Dupl icat e Addr ess Det ect ion, 235
DVMRP. See Dist ance Vect or Mul t icast Rout ing Pr ot ocol .
Dykst r a, 185, 196
al gor it hm, 45, 188, 190, 419, 420
Dynamic Host Conf igur at ion Pr ot ocol (DHCP), 39, 49, 105, 106, 145, 172, 208, 231,
249, 344, 429, 439443, 450, 451
messages, 444
oper at ion, 445446
r esponses, 446447
ser ver s, 251, 452
shor t cut s, 449
Dynamic por t number s, 278281
Dynamic Rever se Addr ess Resol ut ion Pr ot ocol (DRARP), 440
Dynamic r out ing, compar ison. See St at ic r out ing.
E
ECHO, 446, 450
Echo Repl y/Request , 260
Ef f iciencies, 451452
EGP. See Ext er ior Gat eway Pr ot ocol .
Embedded IPv4 addr esses. See Int er net Pr ot ocol IPv6.
Encapsul at ing Secur it y Payl oad, 217
Endst at ion, 107, 145
End-t o-end er r or checking, 48
Er r or -det ect ion al gor it hms, 282
Er r or -det ect ion number , 285
ES-IS pr ocedur es, 233
Et her net , 7, 12, 38, 52, 56, 66, 100, 101, 180, 202, 214, 230, 369, 456, 457, 459
addr ess, mapping, 369370
mapping, 76
mul t icast addr ess, 172
packet header s, 57
packet s, 104, 212
Type f iel d, 101
Et her Type, 104, 105
f iel d, 212, 243
Ext ension header , 213
Ext ensions/opt ions, suppor t , 209
Ext er ior Gat eway Pr ot ocol (EGP), 4142, 145, 153, 177, 483
Ext r anet s, 2021
F
Faul t management , 476
FDDI, 7, 38, 52, 100, 180, 214, 457
backbone, 218
net wor k, 57
st at ion, 57
FDDI-t o-Token-Ring t opol ogies, 257
Feder al Net wor k Council (FNC), 141
Fil e Tr ansf er Pr ot ocol (FTP), 4, 30, 39, 49, 56, 103, 141, 279, 286, 316, 317, 320321,
324, 327
commands, 322
dat a t r ansf er , 323
Fil t er spec, 463
Fir ewal l s, 21
Fixed f il t er , 465466
Fl ag bit s, 250
Fl oat ing st at ic r out e, 200
Fl ooding, 45, 180, 378, 380381
Fl ow cont r ol , 285, 294
Fl ow l abel , 219
Fl ow l abel ing capabil it y, 209
Fl owspec, 463, 467
mer ging, 468469
FNC. See Feder al Net wor k Council .
For war ding cache, 415, 420421
For war ding t abl e, 393, 394
Fr agment at ion, 51, 5760, 212, 217218. See also Dat agr ams.
Fr ame Rel ay, 52, 180, 234
specif icat ion, 31
swit ches, 359
FTP. See Fil e Tr ansf er Pr ot ocol .
Ful l dupl ex, 283
Ful l -dupl ex connect ion, 299
G
Gat eway t o Gat eway Pr ot ocol (GGP), 154
Gat eways. See Boot Pr ot ocol ; Def aul t gat eways.
Gener ic packet f or mat , 186187
GGP. See Gat eway t o Gat eway Pr ot ocol .
Gl obal addr essing, 4
Gl obal r out ing t abl es, 111, 115, 125
Gr af t ing, def init ion, 383384
Gr oup
host , sending, 406407
joining, 405406
Member ship messages, 262
Gr oup-addr ess, 367
Gr oup-Member ship LSA, 415416, 418
Gr oup-specif ic quer ies, 376
H
Handl ing er r or s, 468
Header f or mat simpl if icat ion, 209
Header l engt h, 5556
Hel l o pr ot ocol , 187188
Hol d-down t imer , 161, 165
Hop count , 160, 162, 238, 445
Hop l imit , 215, 237
Hop-by-Hop opt ions, 216
Hop-count dist ance, 162
Hop-count ent r y, 152
Host addr esses, 77, 78, 120
Host bit s, 81
Host f il e, 64
Host ID, 73, 82, 83, 86, 87, 90, 92, 93
Host mobil it y, 252
Host number , 82
Host t o Host , 241
Host t o Rout er , 241
Host Join, 376377
I
IAB. See Int er net Act ivit ies Boar d.
IANA. See Int er net Assigned Number s Aut hor it y.
ICB. See Int er nat ional Cooper at ion Boar d.
ICCB. See Int er net Conf igur at ion Cont r ol Boar d.
ICMP. See Int er net Cont r ol Message Pr ot ocol .
ICMPv4. See Int er net Cont r ol Message Pr ot ocol ICMPv4.
ICMPv6. See Int er net Cont r ol Message Pr ot ocol ICMPv6.
IDRP, 251
I-Ds. See Int er net Dr af t s.
IEEE 802 net wor ks, 212, 230
IEEE 802.X MAC addr ess, mapping, 369370
IESG. See Int er net Engineer ing St eer ing Gr oup.
IETF. See Int er net Engineer ing Task For ce.
IGMP. See Int er net Gr oup Management Pr ot ocol .
IGP. See Int er ior Gat eway Pr ot ocol .
IMP. See Int er f ace Message Pr ocessor ; Int er net Message Pr ocessor .
Incl usive ACK, 291
Indir ect r out ing, 147148
Inf init y t imer val ue, 264
Inf or mat ion Sciences Inst it ut e (ISI), 141
In-l ine r out er , 116
In-sequence packet s, 315
Int egr at ed Ser vice Digit al Net wor k (ISDN), 202
Int er -Ar ea MOSPF r out ing, 422423
Int er -Ar ea Mul t icast
exampl e, 423424
f or war der s, 422424
Int er -ar ea r out ing, 183, 196
Int er -Ar ea Shor t est -Pat h Tr ee, 425
Int er ar r ival Jit t er , 311
Int er -AS mul t icast f or war der , 412, 426
Int er -AS r out ing, 183
Int er -Aut onomous Syst em Mul t icast , 426
Int er domain Rout ing Pr ot ocol , 210
Int er f ace addit ion, 402
Int er f ace addr ess assignat ion, 93
Int er f ace ID, 226, 231
Int er f ace Message Pr ocessor (IMP), 12, 13, 100, 472
Int er ior Gat eway Pr ot ocol (IGP), 4042, 44, 145, 150, 171, 177, 179
Int er nal Rout er (IR), 181
Int er nat ional Cooper at ion Boar d (ICB), 22
Int er nat ional Or ganizat ion f or St andar dizat ion (ISO), 38, 210
Int er net , 11, 2021, 25, 472
gover ning body, 2124
r out ing, 132
r out ing t abl es, 85, 130, 138
t imel ine, 26
t imest amp, 214
Int er net Act ivit ies Boar d (IAB), 2123, 154
Int er net Ar chit ect ur e Boar d, 23
Int er net Assigned Number s Aut hor it y (IANA), 15, 21, 96, 124, 135, 138, 141, 225, 230,
250, 327, 368, 369
addr ess bl ock assignment s, 142144
IANA-assigned RFC number s, 139
Int er net Conf igur at ion Cont r ol Boar d (ICCB), 22
Int er net Cont r ol Message Pr ot ocol (ICMP), 39, 46, 58, 60, 158, 159, 215, 237,
254255, 271272, 365, 440, 446, 450, 457, 468, 479
dat agr am, 271
f unct ions, 274275
header , 260, 262
inf or mat ional messages, 260
message, 234
neighbor discover y, 261
PING, 272273
Redir ect , 233, 236, 265
Rout er Discover y, 233, 236
Int er net Cont r ol Message Pr ot ocol (ICMP)ICMPv4, 256
Int er net Cont r ol Message Pr ot ocol (ICMP) ICMPv6, 256
encapsul at ion, 255
er r or messages, 257259
mul t icast , 262263
Int er net Dr af t s (I-Ds), 31
Int er net Engineer ing St eer ing Gr oup (IESG), 23, 31, 141
Int er net Engineer ing Task For ce (IETF), 2224, 31, 32, 301
Int er net Gr oup Management Pr ot ocol (IGMP), 39, 46, 173, 250, 256, 262, 359, 372,
384, 389, 401, 402, 417, 418, 427, 468, 469
header , 373374
IGMPv2, 376, 377, 403, 406
r out er f unct ions, 375376
Int er net Message Pr ocessor (IMP), 44
Int er net Of f icial Pr ot ocol St andar ds (STD 1), 34
Int er net Pr ot ocol (IP), 12, 50, 141, 165, 206, 215, 290, 421. See also Cl assl ess IP;
Nat ive IP; Tr ansmission Cont r ol Pr ot ocol /Int er net Pr ot ocol .
addr essed net wor ks, 40
addr essing, 208
al t er nat ives, 457
dat a f iel d, 61
dat agr am, 57, 58, 103, 121, 366
header , 53, 55, 104, 147, 204, 388, 396, 400
IP-addr ess-t o-cl ient -har dwar e addr ess, 447
IP-addr ess-t o-physical -st at ion-addr ess, 100
IP-in-IP encapsul at ion, 396, 397, 412
IP-in-IP packet f or mat , 397
IP-r el at ed pr ot ocol s, 4647
IP-t o-physical -addr ess mapping, 146
l ayer , 51, 52, 58, 68, 148, 203, 211, 269, 301
mul t icast ing, 213, 378
net wor k, 64
opt ions f iel ds, 6364
over view, 4041
packet , 212
par amet er s, 49
ser vice int er f ace, ext ensions, 365366
sour ce addr ess, 445
ver sion number s, 211
video ser ver s, 300
Int er net Pr ot ocol Addr ess Encapsul at ion (IPAE), 211
Int er net Pr ot ocol (IP) addr esses, 17, 43, 6870, 80, 85, 92, 102, 103, 106, 108, 113, 115,
116, 126, 130, 132, 146, 157, 170, 191, 204, 235, 238, 242, 265, 266, 305, 318, 331, 333, 335,
375, 403, 405, 419, 431, 436, 441, 443, 446, 448, 450, 452, 459, 460, 463. See also Cl ass-
or ient ed IP addr esses; Local l oopback IP addr ess.
al l ocat ion, 443
assignment (ol d met hod), 111113
assignment s, 192
f or mat , 6869
management , 49
r el easing, 448
r est r ict ions, 95
r eview, 110. See also Cl assf ul IP addr ess r eview.
scheme, 66
Int er net Pr ot ocol (IP) IPv4, 6, 39, 41, 57, 63, 66, 69, 108, 206211, 220223, 227230,
253, 389, 457, 458
addr ess space, l if e ext ension, 110
dual -st ack st r at egy, 243
embedded addr esses. See Int er net Pr ot ocol IPv6.
header , 5354, 242
IPv6 header dif f er ences, 214215
neighbor discover y, 236237
opt ions, r eview, 213214
r out er s, 139, 244
t unnel ing, 240
Int er net Pr ot ocol (IP) IPv6, 6, 39, 41, 63, 65, 69, 77, 206211, 253, 457
addr ess, embedded IPv4 addr esses, 228229
al gor it hm, 265266
cache ent r ies, 263264
dat agr am, 242
depl oyment met hods, 239240
dual -st ack st r at egy, 243
ext ension header s, 216217
f eat ur es, 209210
mul t icast ing, 250251
RFCs, 266267
r out er s, 244
r out ing, 251252
t unnel addr essing, 242
Int er net Pr ot ocol (IP) IPv6 addr essing, 220223. See also Local -use IPv6 addr essing;
Pr ovider -based IPv6 addr essing.
pr ef ix, 224
st r uct ur e, 229
Int er net Pr ot ocol (IP) IPv6 header , 212213
dif f er ences. See Int er net Pr ot ocol IPv4.
Int er net Pr ot ocol (IP) IPv6 t unnel ing, 240, 241, 244248
Int er net Pr ot ocol (IP) Mul t icast , 68, 302, 355357
addr ess, 361, 369. See also Conver t ed IP mul t icast addr ess.
caveat s, 359
compar ison. See Unicast .
component s, 357358
f or war ding, 380
Int er net Pr ot ocol (IP) r out ing, 144145
al gor it hms, 148
t abl es, 153
Int er net Regist r y (IR), 75, 9697, 115, 138. See also Local IRs; Regional IRs.
Int er net Resear ch Gr oup, 22
Int er net Resear ch Task For ce (IRTF), 23
Int er net Ser vice Pr ovider (ISP), 1618, 21, 25, 42, 66, 67, 72, 75, 96, 97, 115, 116,
121125, 127, 130, 133, 135, 137139, 226, 350, 353, 475
Int er net Ser vice Pr ovider (ISP) addr esses, 135136
assignment , 121122
exampl e, 137138
Int er net Societ y (ISOC), 23, 24, 141
Int er net St r eam Pr ot ocol (ST2), 207, 301
Int er NIC, 28, 135, 226, 230, 327, 342
dat abase, 326
Int r a-ar ea r out ing, 183, 411
Int r anet s, 2021
Int r aNet War e, 4
I/O connect ions, 215
IP. See Int er net Pr ot ocol .
IPAE. See Int er net Pr ot ocol Addr ess Encapsul at ion.
IPX, 6, 146, 157, 158, 165
pr ot ocol , 5
IR. See Int er nal Rout er ; Int er net Regist r y.
IRTF. See Int er net Resear ch Task For ce.
ISDN. See Int egr at ed Ser vice Digit al Net wor k.
ISI. See Inf or mat ion Sciences Inst it ut e.
ISIS, 251
ISO. See Int er nat ional Or ganizat ion f or St andar dizat ion.
ISOC. See Int er net Societ y.
ISP. See Int er net Ser vice Pr ovider .
It er at ive quer ies, 334
J
Java, 18
JoinHost Gr oup, 367
JoinLocal Gr oup, 370
Jumbo dat agr ams (jumbogr ams), 215
K
Ker ber os, 352
L
LAN. See Local Ar ea Net wor k.
LAN-t o-LAN connect ivit y, 27
LAN-t o-WAN connect ivit y, 27
Lar ge-scal e net wor ks, 161
LAT. See Local Ar ea Tr anspor t .
Layer s, dat a encapsul at ion, 5253
Leaf int er f ace, 379
Leaf net wor k det ect ion, 401
Lease dur at ion, 450451
Leased l ines, 203
Leased-l ine user s, 25
LeaveHost Gr oup, 367
LeaveLocal Gr oup, 370
Leaves, 379
Lengt h f iel ds. See Tot al l engt h f iel ds.
Link l ocal , 227
Link St at e Adver t isement (LSA), 179, 182, 184, 189, 190, 194, 417419, 421423, 427.
See also Gr oup Member ship LSA.
dat abase, 185, 191
packet s, 184
Link-l ayer addr esses, 234, 237
Link-l ayer br oadcast addr ess, 258
Link-l ayer mul t icast , 258
Link-l evel addr ess change, 261
Link-Local Al l -Nodes mul t icast addr ess, 262
Link-st at e dat abase, 45, 419, 424
Link-st at e pr ot ocol , 45
Link-st at e r out ing, 382
al gor it hm, 191
Local Ar ea Net wor k (LAN), 7, 12, 47, 71, 90, 100, 101, 105, 106, 111, 146, 171, 188, 203,
230, 282, 283, 297, 325, 359, 398, 412, 456
inf r ast r uct ur e, 357
int er connect , 202
int er f ace, 400, 401
physical -addr ess-t o-IP addr ess t abl e, 102
pr ot ocol , 38, 291
t r af f ic, 148
Local Ar ea Tr anspor t (LAT), 67, 146
Local IRs, 96
Local l oopback IP addr ess, 94
Local -gr oup dat abase, 415416, 418
Local -use IPv6 addr essing, 227228
Logical addr esses, 84
Longest mat ch r ul e, 120121
Loopback, 72
Loop-back f unct ion, 95
Loose sour ce r out e (LSR), 63
Loose sour ce r out ing, 213
LSA. See Link St at e Adver t isement .
LSR. See Loose sour ce r out e.
M
MAC. See Media Access Cont r ol .
Mail , DNS int er act ion, 349
Mail exchange (MX) r ecor ds, 340341, 349
Management appl icat ions, 478
Management Inf or mat ion Base (MIB), 477, 479, 480
ent r y, exampl e, 481
Management ser ver /cl ient s, 477
Mask yiel ds, 117
Masks, 82, 87, 116118
Mat ch r ul e. See Longest mat ch r ul e.
Maximum Segment Size (MSS), 285, 290
Maximum Tr ansmission Unit (MTU), 57, 216, 217, 235, 236, 253, 254, 257
discover y. See Pat h MTU discover y.
MBONE, 316, 428
Media Access Cont r ol (MAC), 174
addr esses, 76, 100, 102, 105, 172, 204, 227, 230, 238, 370372, 446. See also IEEE
082.X MAC addr ess.
header , 452
mul t icast addr ess, 234, 238
Media Access Cont r ol (MAC) l ayer , 76, 203
int er f aces, 372
Media addr ess, 234
MERIT Net wor k, 14
Message t ypes, 184185
Met r ics, 150, 157, 185186, 197
MIB. See Management Inf or mat ion Base.
Micr osegment ing, 111
Micr osubnet t ing, 111
Mil it ar y net wor k (MILNET), 12
MILNET. See Mil it ar y net wor k.
MIME. See Mul t ipur pose Int er net Mail Ext ensions.
Mixer s, 304
Mobil it y agent , 239
MOSPF. See Mul t icast Open Shor t est Pat h Fir st .
MPEG, 306
MSS. See Maximum Segment Size.
MTU. See Maximum Tr ansmission Unit .
Mul t iaccess net wor ks, 188
Mul t i-ar ea OSPF t opol ogy, 414
Mul t icast , 167, 220, 364, 460, 463. See also Int er -Ar ea Mul t icast ; Int er -Aut onomous
Syst em Mul t icast ; Int er net Cont r ol Message Pr ot ocol ICMPv6; Int er net Pr ot ocol
Mul t icast ; Pr ot ocol -Independent Mul t icast .
addr esses, 74, 76, 250, 263. See also Conver t ed IP Mul t icast addr ess.
al gor it hms, 378
appl icat ion, 140
compar ison. See Unicast .
member ship r epor t ing, 255
packet s, 373
suppor t , 172173
t r ee t ypes, PIM-SM usage, 404405
Mul t icast dat agr ams, 365, 381, 387, 394, 396, 419
r eceiving, 367
Mul t icast Open Shor t est Pat h Fir st (MOSPF), 359, 378, 398, 411412, 415, 417, 423
caveat s, 414
dif f er ences, 412413
r out ing. See Int er -Ar ea MOSPF r out ing.
Mul t icast ing, 357. See also Int er net Pr ot ocol IPv6; Rever se Pat h Mul t icast ing.
t ype, 362363
Mul t imedia, 300
Mul t inet t ing, 93
Mul t ipl e-packet windowing, 324
Mul t ipl exing, 277, 285
Mul t ipur pose Int er net Mail Ext ensions (MIME), 346
Mul t isubnet br oadcast s, 139
MX. See Mail exchange.
N
Name ser ver s, 326, 329, 332333
dat abase, manipul at ion, 341342
r ecor ds, 337
Name-t o-addr ess t r ansl at ion, 328
Name-t o-IP-addr ess mapping, 338
Name-t o-net wor k addr ess t r ansl at ion ser vice, 49
NAPs. See Net wor k Access Point s.
NAT. See Net wor k Addr ess Tr ansl at ion.
Nat ional Science Foundat ion (NSF), 13, 15
Nat ive IP, 4
Nat ur al mask, 80, 126, 171
NBMA. See Non-Br oadcast Mul t iaccess.
NCP. See Net War e Cor e Pr ot ocol .; Net wor k Cont r ol Pr ogr am.
NCSA. See U.S. Nat ional Cent er f or Super comput er Appl icat ions.
Neighbor Adver t isement , 238, 261
Neighbor cache, 264
Neighbor Discover y, 233234, 390. See also Int er net Cont r ol Message Pr ot ocol ;
Int er net Pr ot ocol IPv4.
pr ocess, 263
t ypes, 235
Neighbor Sol icit at ion, 238, 261
Neighbor Unr eachabil it y Det ect ion, 234236, 239
Neighbor Unr eachabil it y pr ot ocol , 264
Net BIOS, 4, 146
Net scape Navigat or , 2, 16
Net War e Cor e Pr ot ocol (NCP), 282, 324
Net War e (Novel l ), 2, 3, 57, 146, 157, 250, 282, 291
int er f ace, 5
wor kst at ions, 4
Net wor k Access Point s (NAPs), 15, 125
Net wor k Addr ess Tr ansl at ion (NAT), 95, 228
Net wor k addr esses, 82, 86, 91, 93
Net wor k Cont r ol Pr ogr am (NCP), 11
Net wor k Fil e Syst em (NFS), 320, 432
Net wor k ID, 69, 81, 91, 107, 109, 114, 119, 120, 153, 163, 164, 170, 175
Net wor k Links Adver t isement , 184
Net wor k mask, 80
Net wor k number , 7274, 146, 148, 153
Net wor k pr ef ix, 78
Net wor k pr ot ocol s, 52
Net wor k Time Pr ot ocol (NTP), 279, 310
Net wor k Wor king Gr oup, 33
Net wor k-l ayer sof t war e, 282
New Yor k St at e Educat ional Resear ch Net wor k (NYSERnet ), 13
Next -Hop det er minat ion, 234, 235
Next -hop f iel ds, 171172
Next -Hop Gat eways, 393
Next -hop neighbor , 265
NFS. See Net wor k Fil e Syst em.
NIC, 74, 76, 173, 234, 326, 357, 369, 370, 372. See also Int er NIC.
sof t war e, 243
No Rout e t o Dest inat ion, 257
Non-Br oadcast Mul t iaccess (NBMA), 180, 234
Noncont iguous bit pat t er n, 129
Non-IPv6 machines, 236
Non-r eal t ime dat a, 300
t r ansmission, 362
Not a Neighbor , 257
NSF. See Nat ional Science Foundat ion.
NSFnet , 1316, 22
NTP. See Net wor k Time Pr ot ocol .
NYSERnet . See New Yor k St at e Educat ional Resear ch Net wor k.
O
Of f -l ink sender s, 237
Of f set , 5859
One Pass wit h Adver t ising (OPWA), 461
On-l ink dest inat ion, 235, 237
Open Shor t est Pat h Fir st (OSPF), 39, 4345, 61, 9092, 109, 113, 114, 118, 120, 145, 146,
153, 167, 169, 171, 175176, 185, 199, 201, 203, 251, 252, 372, 378, 382, 414, 415, 419, 427
ar eas, 191192
aut onomous syst em, 191
domain, 197, 198
media suppor t , 180181
net wor k, 176177, 183, 192
over view, 179180
packet s, 186
r out er s, 184, 187, 188
r out es, 190
r out ing pr ot ocol , 56
r out ing updat es, 68
t opol ogy, 192, 411, 421. See also Mul t i-ar ea OPSF t opol ogy.
Oper at ion, 419420. See also Resour ce Reser vat ion Pr ot ocol .
Oper at ional t abl es, 453454
Opt ions, 55
OPWA. See One Pass wit h Adver t ising.
Or iginat or , 64
OSI, 228
OSI model , 38, 40
OSI suit e, 233
OSPF. See Open Shor t est Pat h Fir st .
P
Packet cl assif ier , 461
Packet Int er net Gr oper (PING), 272. See also Int er net Cont r ol Message Pr ot ocol .
Packet Radio, 24
Packet Sat el l it e, 24
r esear ch, 22
Packet schedul er , 461
Packet t ype, 312
Packet s, 144, 151, 162, 168, 314
swit ching, 2728
Par amet er discover y, 235
Par ent l ink, 382
Pat h messages, 460461
Pat h MTU (PMTU), 239, 264
discover y, 217, 218, 258
Pat hTear , 467
Payl oad t ype, 308
PCM. See Pul se Code Modul at ion.
Peer ing, 25
Peer -t o-peer , 8
Physical addr esses, 84, 100
Physical -addr ess-t o-IP-addr ess t abl e. See Local Ar ea Net wor k.
PIM. See Pr ot ocol Independent Mul t icast .
PIM-DN. See Pr ot ocol -Independent Mul t icast Dense Mode.
PIM-SM. See Pr ot ocol -Independent Mul t icast Spar se Mode.
PING, 46, 260. See also Int er net Cont r ol Message Pr ot ocol .
dat agr am, 272
r equest , 272, 273
PMTU. See Pat h MTU.
Point s of Pr esence (POPs), 16, 25
Point -t o-point connect ion, 181
Point -t o-point l ink, 92, 171, 180, 189, 412
Point -t o-point ser ial l ines, 202
Poison r ever se, 165, 395
Poisoned r ever se, 161, 167
POP. See Post Of f ice Pr ot ocol .
POPs. See Point s of Pr esence.
Por t , 153, 163
Por t number s, 277, 278, 280. See also Assigned por t number s; Dynamic por t number s;
Regist er ed por t number s.
Por t Unr eachabl e, 257, 277
Post Of f ice Pr ot ocol (POP), 49, 318, 319, 345, 348, 350351
oper at ion, 351352
POP3, 351, 352
t opol ogy, 353
Pr ecedence, 55, 285
Pr ef ix List , 265
cache, 264, 265
Pr ef ixes, 116117. See also Cl ass B; Int er net Pr ot ocol IPv6 t unnel ing; Net wor k
pr ef ix.
assignment s, 133134
det er minat ion. See Common pr ef ix.
discover y, 235
l engt h, 130
Pr imar y mast er s, 332
Pr ivacy capabil it ies, 209
Pr ivat e int er net , 20
Pr obe packet , 390
Pr ocess-t o-pr ocess communicat ions, 11
Pr opr iet ar y syst em, 11
Pr ot ocol and Header Checksum, 212
Pr ot ocol f iel ds, 6162
Pr ot ocol ID, 463, 469
Pr ot ocol Independent Mul t icast (PIM), 359, 398, 426, 427
Pr ot ocol suit e, 39, 50, 99, 214, 277
Pr ot ocol -Independent Mul t icast Dense Mode (PIM-DM), 398, 399
oper at ion, 400401
pr ot ocol s, compar ison. See Pr ot ocol -Independent Mul t icast Spar se Mode.
Pr ot ocol -Independent Mul t icast Spar se Mode (PIM-SM), 378, 387, 403, 406, 408, 409
pr ot ocol s, PIM-DM pr ot ocol compar ison, 410
usage. See Mul t icast .
Pr ot ocol s, 372373
Pr ovider ID, 230
Pr ovider sel ect ion, 251
Pr ovider -based IPv6 addr essing, 226
Pr ovider -or ient ed unicast addr ess, 226
Pr oxy ARP, 82, 107108
Pr uning, def init ion, 383384
Pul se Code Modul at ion (PCM), 306
Push/Pul l t echnol ogy, 356
Q
Qual it y of Ser vice (QoS), 27, 28, 46, 315, 456459, 461, 463, 474, 475
Quer y f unct ion t ypes, 334
R
RARP. See Rever se Addr ess Resol ut ion Pr ot ocol .
Real Time Cont r ol Pr ot ocol (RTCP), 39, 47, 48, 300302, 309, 310, 357
pr ot ocol , 315
Real Time Pr ot ocol (RTP), 39, 47, 48, 300302, 357, 458
caveat s, 315
cont r ol , pr oviding, 309
message f or mat , 305306
pr ot ocol , 303, 304
Real Time St r eaming Pr ot ocol (RTSP), 357, 458
Real -t ime dat a, 300
t r ansmission, 362
Real -t ime st r eaming, 301
Real -t ime t r ansf er s, 363
Real -t ime t r anspor t , 207
Receiver r epor t s, 312
Receiver SMTP, 346
Recor d r out e, 214
Recur sive quer ies, 334
Redir ect s, 234, 235, 237, 261, 264
Regional IRs, 96
Regist er ed por t number s, 278, 279
Remot e net wor ks, 202203
Rendevous point (RP), 399, 403407, 409. See also Candidat e RP.
Request f or Comment s (RFCs), 2831, 53, 57, 66, 67, 78, 80, 82, 95, 96, 101, 109111,
113, 115, 116, 123, 132, 139141, 154, 169, 172, 174176, 186, 197, 199, 211, 215, 217219,
226, 228, 233236, 253, 254, 265267, 274, 277279, 301, 316, 317, 325, 326, 345, 348, 350,
351, 364, 369, 372, 396, 411, 428, 430, 441, 442, 444, 450, 451, 455, 457, 479. See also
Dr af t RFCs; Int er net Pr ot ocol IPv6.
announcement s, 32
Edit or , 31
number s. See Int er net Assigned Number s Aut hor it y.
r equir ement s, 37
r eview, 428, 455
st udy, 30
submission, 3132
updat es, 32
Request f or Comment s (RFCs) f or mat , 3334
r equir ement s, 3536
Reser vat ions, 459
disabl ing, 467
st yl e. See Resour ce Reser vat ion Pr ot ocol .
Resol ver s, 329
Resour ce Reser vat ion Pr ot ocol (RSVP), 39, 46, 48, 172, 301, 357, 363, 429, 456459,
468
al t er nat ives, 457
cont r ol , 465466
exampl e, 469471
issues, 472
oper at ion, 459460
r equest s, 463464
Resour ce Reser vat ion Pr ot ocol (RSVP) (Continued)
r out er s, 461462
st yl e, 464465
summar y, 473474
usage, l ocat ion, 458
ResvTear , 467
Rever se Addr ess Resol ut ion Pr ot ocol (RARP), 105107. See also Dynamic Rever se
Addr ess Resol ut ion Pr ot ocol .
Rever se Pat h Br oadcast ing, 378
Rever se Pat h For war ding (RPF), 381382, 400, 405, 412, 425
Rever se Pat h Mul t icast ing (RPM), 378, 384385, 387, 399
RFCs. See Request f or Comment s.
RIP. See Rout ing Inf or mat ion Pr ot ocol .
RIPE, 28, 96, 226, 230, 342
RIPng. See Rout ing Inf or mat ion Pr ot ocol .
Root , 379
Rout abl e pr ot ocol , 43
Rout e aggr egat ion, 126127, 129130
Rout e r epor t s, 391, 394
r eceiving, 392
Rout e Tabl e Ent r ies (RTE), 253
Rout e t ag, 167, 171172
Rout er Adver t isement , 237, 261, 264
Rout er IDs, 252
Rout er Links Adver t isement , 184
Rout er List cache, 264
Rout er Sol icit at ion, 261
Rout er t o Host , 241
Rout er t o Rout er , 241
Rout er DeadInt er val , 187
Rout er s, 12, 28, 50, 60, 63, 82, 126, 144, 152, 162166, 385, 386, 388, 390. See also
Def aul t r out er s; Resour ce Reser vat ion Pr ot ocol .
al gor it hm, 180
discover y, 235
names, 183
por t , 175
t ypes, 181182
updat ing, 151, 152
vendor s, 106
Rout ing, 50, 216. See also Int er net Pr ot ocol r out ing.
met hods, 183
pr ocess, f l owchar t , 148149
t abl e, 190, 201, 393
updat e, 164
Rout ing Inf or mat ion Pr ot ocol (RIP), 40, 4345, 60, 145, 146, 150, 153, 155, 156, 160,
163, 165, 167, 170, 175179, 201, 251, 252, 381, 391, 394
f iel d descr ipt ions, 157158
f ixes, 165
net wor k, 60
oper at ional t ypes, 155156
pr ot ocol , 150, 158, 172, 200
RIPng, 253
scal ing, 161163
updat e t abl es, 278
Rout ing Inf or mat ion Pr ot ocol (RIP1) RIPv1, 9092, 119, 154155, 161, 163, 164, 168,
169, 171, 173, 174, 252, 382
pr ot ocol , disadvant ages, 160161
RIPv2 compat ibil it y, 173174
Rout ing Inf or mat ion Pr ot ocol (RIP2) RIPv2, 9092, 109, 145, 167169, 171, 173, 174,
203, 252, 372, 382
compat ibil it y. See Rout ing Inf or mat ion Pr ot ocol (RIP) RIPv1.
t abl e, 395
Rout ing pr ot ocol s, 4043, 90, 149150
compar ison, 177178
RP. See Rendevous point .
RPF. See Rever se Pat h For war ding.
RPM. See Rever se Pat h Mul t icast ing.
RSVP. See Resour ce Reser vat ion Pr ot ocol .
RTCP. See Real Time Cont r ol Pr ot ocol .
RTE. See Rout e Tabl e Ent r ies.
RTP. See Real Time Pr ot ocol .
RTSP. See Real Time St r eaming Pr ot ocol .
S
SAP, 212
Secondar y mast er s, 332
Sender r epor t s, 310311
Sender SMTP, 346
Sequence number s, 287, 288, 290291
exampl e, 292293
Ser ial l ine, 171
Ser ver side, 435436
Ser vice t ype, 5556
Shar ed expl icit , 466
Shar ed r eser vat ions, 464
Shar ed RP-t r ee, 408
Shar ed t r ee, 404
Shar ewar e, 18
Shor t est -pat h sour ce-r oot ed del iver y t r ee, 394
Shor t est -pat h t r ee, 404, 414, 415, 419
Simpl e Int er net Pr ot ocol Pl us (SIPP), 211
Simpl e Int er net Pr ot ocol (SIP), 211
Simpl e Mail Tr ansf er Pr ot ocol (SMTP), 39, 49, 103, 316, 317, 320, 340, 341, 345, 350,
351. See also Receiver SMTP; Sender SMTP.
f l ow, 347348
f unct ions, 346
t opol ogy, 353
Simpl e Net wor k Management Pr ot ocol (SNMP), 39, 172, 429, 476
el ement s, 477
encapsul at ion, 484
manager , 478
pr ot ocol , 482483
Simpl e Spanning Tr ee, 378
SIP. See Simpl e Int er net Pr ot ocol .
SIPP. See Simpl e Int er net Pr ot ocol Pl us.
Sit e l ocal , 227, 228
6Bone, 209, 225, 241
Sl ow st ar t , 296298
SMDS. See Swit ched Mul t imegabit Dat a Ser vice.
SMTP. See Simpl e Mail Tr ansf er Pr ot ocol .
SNA. See Syst em Net wor k Ar chit ect ur e.
SOA. See St ar t of Aut hor it y.
Socket number , 281
Sof t st at e, 460
Sol icit ed-node mul t icast addr ess, 238
Sour ce descr ipt ion packet , 313
Sour ce f iel ds, 6465
Sour ce net wor ks, 391, 421
Sour ce por t , 278, 284
Sour ce quench, 274
Sour ce r out ing, 214
Sour ce subnet s, 388, 393, 394
Sour ce-Root ed Tr ee (SRT), 404, 420
conver sion, 408
Spanning t r ee, 378381
t opol ogy, 385
Spar se Mode, 378, 398. See also Pr ot ocol -Independent Mul t icast Spar se Mode.
SPF al gor it hm, 190, 191
Spl it hor izon, 161, 165, 167
demonst r at ion, 166167
SRI. See St anf or d Resear ch Inst it ut e.
SRT. See Sour ce-Root ed Tr ee.
SSDP, 313
SSR. See St r ict sour ce r out e.
SSRC number s, 306, 310, 313
ST2. See Int er net St r eam Pr ot ocol .
St ar t of Aut hor it y (SOA) r ecor d, 336
St at ef ul aut oconf igur at ion, 231, 232
St at el ess aut oconf igur at ion, 231, 232
St at ic ent r ies, 200
St at ic r out ing, dynamic r out ing compar ison, 200201
STD 1. See Int er net Of f icial Pr ot ocol St andar ds.
St r eam, 289
St r eam ID, 214
St r eams 2 pr ot ocol , 53
St r ict sour ce r out e (SSR), 63
St ub ar eas, 198
Subnet ID, 226, 228, 231
Subnet masking, 167
Subnet masks, 84, 90, 111, 117, 119, 123, 163164. See also Var iabl e-l engt h subnet
masks.
decisions, 9192
f iel d, 170171
number , 88
t empl at e, 8586
Subnet s, 43, 88, 95, 107, 117118, 120, 121, 139, 145, 166, 167, 226. See also Sour ce
subnet s.
bit s, 89
number , 82, 86
r est r ict ions, 9091
special consider at ions, 139140
Subnet t ing, 7879, 85, 111
exampl es, 8283. See also Cl ass A; Cl ass B; Cl ass C.
r easons, 80
Subnet wor k, 100
Subscr iber ID, 226, 230
Sub-subnet s, 120
Summar y Links Adver t isement , 184
Super net t ing, 113115, 124125
Swit ched Mul t imegabit Dat a Ser vice (SMDS), 202
Syst em Net wor k Ar chit ect ur e (SNA), 2, 6, 7
ar chit ect ur e, 5
T
T1 l ines, 160, 181
TAR command, 17
Tar get Addr ess, 261
TCP. See Tr ansmission Cont r ol Pr ot ocol .
TCP and UDP over Bigger Addr esses (TUBA), 210
TCP/IP. See Tr ansmission Cont r ol Pr ot ocol /Int er net Pr ot ocol .
Tel enet , 49
TELNET, 4, 39, 55, 56, 103, 279, 286, 288, 316318, 321, 326, 330, 333, 343
opt ions, 319320
pr ot ocol , 49
Ter minat ion, 299
TFTP. See Tr ivial Fil e Tr ansf er Pr ogr am.
Thr ee-way handshake, 287288
Thr oughput , 55
Time Exceeded, 258, 259, 275
Time l ef t t o del et e, 153
Time t o Live (TTL), 6062, 147, 162, 204, 212, 215, 250, 274, 366, 376, 421, 439
Time-out s, 298, 299
Time-sensit ive appl icat ions, suppor t , 306307
Timest amp, 274, 307, 310, 311
TLD. See Top-l evel domain.
Token Ring, 7, 38, 52, 56, 63, 66, 100, 180, 212, 214, 219, 457
net wor ks, 218, 456
st at ion, 57
Top-l evel domain (TLD), 124, 330
TOS. See Type of Ser vice.
Tot al l engt h f iel ds, 5556
TP/IX, 211
Tr acer out e, 64
Tr ansl at or s, 303
Tr ansmission cont r ol , 294
Tr ansmission Cont r ol Pr ot ocol (TCP), 4, 12, 31, 47, 49, 51, 53, 61, 102, 103, 141, 154,
206, 210, 211, 255, 257, 272, 275, 279283, 294, 295, 301, 305, 318, 372, 376
dat agr am, 284
det ail s, 282283
f iel ds, 284285
f l ow, 293295
header , 283, 284, 287, 294
r et r ansmission, 295296
segment , 289290
ser vices, 285
Tr ansmission Cont r ol Pr ot ocol (TCP) connect ion, 351
est abl ishment , 286287
pat h, 57
Tr ansmission Cont r ol Pr ot ocol /Int er net Pr ot ocol (TCP/IP), 2, 214
appl icat ions, 316317
impl ement at ions, 107
int er net suppor t subnet masking, 108
net wor k, 102, 439
or igins, 916
pr ot ocol , 38, 100, 216, 317, 345
pr ot ocol document s, 2829
sof t war e st acks, 243
st ack, 71
st andar d appl icat ions, 49
st at ion, 86
Tr anspor t Cont r ol Pr ot ocol , 39
Tr anspor t Layer Pr ot ocol s, 4748
Tr anspor t -l ayer sof t war e, 281
Tr ees. See Int er -Ar ea Shor t est -Pat h Tr ee.
conver sion. See Sour ce-r oot ed t r ee.
t ypes. See Mul t icast .
Tr igger ed updat es, 161, 165
Tr ivial Fil e Tr ansf er Pr ogr am (TFTP), 39, 277, 278, 280, 316, 317, 320, 324
TTL. See Time t o Live.
TUBA. See TCP and UDP over Bigger Addr esses.
Tunnel , 388
endpoint s, 396
Tunnel ing, 63, 412. See also Aut omat ic t unnel ing; Conf igur ed t unnel ing; Dist ance
Vect or Mul t icast Rout ing Pr ot ocol ; Int er net Pr ot ocol IPv4; Int er net Pr ot ocol
IPv6 t unnel ing.
Type of Ser vice (TOS), 55, 175, 177, 212, 415, 421, 457, 458
f iel ds, 56
U
UDP. See User Dat agr am Pr ot ocol .
Unicast , 220, 363, 463
addr esses, 230231. See also Pr ovider -or ient ed unicast addr ess.
IP Mul t icast compar ison, 360362
t abl e, 395
Unique r eser vat ions, 464
Univer sal Time (UT), 214
Unst r uct ur ed st r eam, 289
Upper -l ayer header , 217
Upper -l ayer pr ot ocol s, 239, 276, 367
Upper -l ayer sof t war e, 75, 234
Upst r eam node, 421
Ur gent point er , 285
U.S. Nat ional Cent er f or Super comput er Appl icat ions (NCSA), 16
User Dat agr am Pr ot ocol (UDP), 39, 4648, 51, 53, 61, 158, 160, 206, 210, 275276,
277279, 281, 286, 324, 372, 435, 440, 457
dest inat ion por t , 437, 438
header , 215, 276, 277, 280
l ayer , 302
User t o User Copy (UUCP), 12, 13, 349
UT. See Univer sal Time.
UUCP. See User t o User Copy.
V
Var iabl e Lengt h Subnet Masks (VLSM), 66, 92, 111, 113115, 119120, 124, 164, 175,
252
compar ison. See Cl assl ess Int er -Domain Rout ing.
Var iabl e-l engt h masks, 139
Var iabl e-l engt h subnet , 167
VAT. See Visual Audio Tool .
Vect or , 149
VERS f iel d, 53, 212
Ver sion number , 54
VINES (Banyan), 6
Vir t ual cir cuit swit ching, 27
Vir t ual l ink, 194, 195
Visual Audio Tool (VAT), 305
VLSM. See Var iabl e Lengt h Subnet Masks.
VMS oper at ing syst em, 8
W
WAN. See Wide Ar ea Net wor k.
Web. See Wor l d Wide Web.
Wel l -known por t number s, 279
WGs. See Wor king Gr oups.
WHOIS command, 342343
Wide Ar ea Net wor k (WAN), 7, 144, 202, 359, 398, 412, 456
l inks, 192, 196, 303, 398
pr ot ocol , 38
Wil dcar d f il t er t ype, 465
Window management , 293295
Wor king Gr oups (WGs), 31
Wor l d Wide Web (WWW / Web), 1620
br owser , 28
capabil it ies, 24
page, 17, 18
pr ogr amming, 2
WWW. See Wor l d Wide Web.
X
X.25, 7, 49, 52, 180, 234
Xer ox document at ion, 161
Xer ox Net wor k Syst em (XNS), 6, 7, 43, 154, 157, 158, 165, 291
XNS. See Xer ox Net wor k Syst em.
Z
Zones, 328, 329, 332

TCP Representation

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

TCP Representation

Hochgeladen von

Copyright:

Verfügbare Formate

Illustrated TCP/IP

Das könnte Ihnen auch gefallen