`
` TCP/IP
`
`[lustre alae
`
`w.
`
`
`
`
`
`\oluy SdIddSONILNdWODIWNOISSSAOUdAATSAM-NOSICGGYV
`
`
`
`UNILOC2017 LLC
`
`
`IPR2019-01026
`i
`
`MICROSOFT CORP. v.
`
`MICROSOFT- EXHIBIT 1036
`
`
`
`
`
`TCP/IP Illustrated, Volume 1
`
`The Protocols
`
`W. Richard Stevens
`
`ADDISON-WESLEY PUBLISHING COMPANY
`Reading, Massachusetts Menlo Park, California New York
`Don Mills, Ontario Wokingham, England Amsterdam Bonn
`Sydney Singapore Tokyo Madrid San Juan
`Paris Seoul Milan Mexico City Tuipei
`
`ii
`
`
`
`UNIX is a technology trademark of X/Open Company, Ltd.
`
`The publisher offers discounts on this book when ordered in quantity for special sales.
`For more information please contact:
`Corporate & Professional Publishing Group
`Addison-Wesley Publishing Company
`One Jacob Way
`Reading, Massachusetts 01867
`
`Library of Congress Cataloging-in-Publication Data
`Stevens, W. Richard
`TCP/IP Illustrated: the protocols/W, Richard Stevens.
`p. cm. -
`(Addison-Wesley professional computing series)
`Includes bibliographical references and index.
`ISBN 0-201-63346-9 (v. 1)
`l.TCP/IP (Computer network protocol) I. Title. II. Series.
`TK5105.55S74 1994
`004.6'2-dc20
`
`Copyright © 1994 by Addison-Wesley Publishing Company
`
`All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or
`transmitted, in any form, or by any means, electronic, mechanical, photocopying, recording, or
`otherwise, without the prior consent of the publisher. Printed in the United States of America.
`Published simultaneously in Canada.
`
`ISBN 0-201-63346-9
`Text printed on recycled paper.
`2 3 4 5 6 7 8 9 CRW 97969594
`Second Printing, February 1994
`
`iii
`
`
`
`Contents
`
`Preface
`
`Introduction
`Chapter 1.
`
`xv
`
`1
`
`Introduction
`1
`1.1
`Layering 1
`1.2
`TCP/IP Layering 6
`1.3
`
`Internet Addresses 7
`1.4
`The Domain Name System 9
`1.5
`Encapsulation
`9
`1.6
`Demultiplexing
`11
`1.7
`
`Client-Server Model 12
`1.8
`Port Numbers 12
`1.9
`
`Standardizati.on Process 14
`1.10
`RFCs 14
`1.11
`Simple Services 15
`. Standard,
`1.12
`The Internet 16
`1.13
`16
`Implementations
`1.14
`17
`
`
`Application Programming Interfaces
`1.15
`Test Network 18
`1.16
`1.17
`Summary 19
`
`vii
`
`
`
`viii
`
`TCP /IP Illustrated
`
`Chapter 2.
`
`Link Layer
`
`Contents
`
`21
`
`2.1
`2.2
`2.3
`2.4
`2.5
`2.6
`2.7
`2.8
`2.9
`2.10
`2.11
`
`21
`Introduction
`Ethernet and IEEE 802 Encapsulation
`Trailer Encapsulation
`23
`SLIP: Serial Line IP
`24
`Compressed SLIP
`25
`PPP: Point-to-Point Protocol
`Loopback Interface
`28
`MTU
`29
`Path MTU
`30
`Serial Line Throughput Calculations
`Summary
`31
`
`26
`
`21
`
`30
`
`Chapter 3.
`
`IP: Internet Protocol
`
`33
`
`3.1
`3.2
`3.3
`3.4
`3.5
`3.6
`3.7
`3.8
`3.9
`3.10
`3.11
`
`42
`
`Introduction
`33
`34
`IP Header
`37
`IP Routing
`Subnet Addressing
`Subnet Mask
`43
`Special Case IP Addresses
`A Subnet Example
`46
`ifconfig Command
`47
`netstat Command
`49
`IP Futures
`49
`Summary
`50
`
`45
`
`Chapter 4.
`
`ARP: Address Resolution Protocol
`
`53
`
`4.1
`4.2
`4.3
`4.4
`4.5
`4.6
`4.7
`4.8
`4.9
`
`Introduction
`53
`An Example
`54
`ARP Cache
`56
`ARP Packet Format
`ARP Examples
`57
`Proxy ARP
`60
`Gratuitous ARP
`arp Command
`Summary
`63
`
`62
`63
`
`56
`
`Chapter 5.
`
`RARP: Reverse Address Resolution Protocol
`
`65
`
`5.1
`5.2
`5.3
`5.4
`5.5
`
`Introduction
`65
`RARP Packet Format
`RARP Examples
`66
`RARP Server Design
`Summary
`68
`
`65
`
`67
`
`
`
`TCP /IP Illustrated
`
`Contents
`
`ix
`
`Chapter 6.
`6.1
`6.2
`6.3
`6.4
`6.5
`6.6
`6.7
`
`Chapter 7.
`7.1
`7.2
`7.3
`7.4
`7.5
`
`ICMP: Internet Control Message Protocol
`
`69
`
`69
`Introduction
`70
`ICMP Message Types
`ICMP Address Mask Request and Reply
`ICMP Timestamp Request and Reply
`ICMP Port Unreachable Error
`77
`4.4BSD Processing of ICMP Messages
`Summary
`83
`
`72
`
`74
`
`81
`
`Ping Program
`
`85
`Introduction
`85
`Ping Program
`IP Record Route Option
`IP Timestamp Option
`Summary
`96
`
`91
`
`95
`
`85
`
`97
`
`111
`
`Chapter 8.
`
`Traceroute Program
`
`8.1
`8.2
`8.3
`8.4
`8.5
`8.6
`
`97
`Introduction
`Traceroute Program Operation
`LAN Output
`99
`WAN Output
`102
`IP Source Routing Option
`Summary
`109
`
`97
`
`104
`
`Chapter 9.
`9.1
`9.2
`9.3
`9.4
`9.5
`9.6
`9.7
`
`IP Routing
`
`111
`Introduction
`112
`Routing Principles
`ICMP Host and Network Unreachable Errors
`To Forward or Not to Forward
`119
`ICMP Redirect Errors
`119
`ICMP Router Discovery Messages
`Summary
`125
`
`123
`
`117
`
`Chapter 10.
`
`Dynamic Routing Protocols
`
`127
`
`10.1
`10.2
`10.3
`10.4
`10.5
`10.6
`10.7
`10.8
`10.9
`
`127
`Introduction
`127
`Dynamic Routing
`128
`Unix Routing Daemons
`RIP: Routing Information Protocol
`RIP Version 2
`136
`137
`OSPF: Open Shortest Path First
`138
`BGP: Border Gateway Protocol
`CIDR: Classless lnterdomain Routing
`141
`Summary
`
`129
`
`140
`
`
`
`x
`
`TCP /IP Illustrated
`
`Chapter 11.
`
`UDP: User Datagram Protocol
`
`Contents
`
`143
`
`11.1
`11.2
`11.3
`11.4
`11.5
`11.6
`11.7
`11.8
`11.9
`11.10
`11.11
`11.12
`11.13
`
`143
`Introduction
`144
`UDP Header
`144
`UDP Checksum
`147
`A Simple Example
`148
`IP Fragmentation
`ICMP Unreachable Error (Fragmentation Required)
`153
`Determining the Path MTU Using Traceroute
`Path MTU Discovery with UDP
`155
`Interaction Between UDP and ARP
`Maximum UDP Datagram Size
`159
`ICMP Source Quench Error
`160
`UDP Server Design
`162
`Summary
`167
`
`157
`
`151
`
`Chapter 12.
`
`Broadcasting and Multlcasting
`
`169
`
`12.1
`12.2
`12.3
`12.4
`12.5
`
`Introduction
`Broadcasting
`Broadcasting
`Multicasting
`Summary
`
`169
`171
`Examples
`175
`178
`
`172
`
`Chapter 13.
`
`IGMP: Internet Group Management Protocol
`
`179
`
`13.1
`13.2
`13.3
`13.4
`13.5
`
`179
`
`Introduction
`IGMP Message
`IGMP Protocol
`An Example
`Summary
`
`180
`180
`183
`186
`
`Chapter 14. DNS: The Domain Name System
`
`187
`
`187
`Introduction
`14.1
`188
`14.2 DNS Basics
`14.3 DNS Message Format
`A Simple Example
`14.4
`Pointer Queries
`14.5
`14.6 Resource Records
`203
`14.7 Caching
`14.8 UDP or TCP
`14.9
`Another Example
`208
`14.10 Summary
`
`206
`206
`
`191
`194
`198
`201
`
`
`
`TCP /IP Illustrated
`
`Contents
`
`xi
`
`Chapter 15.
`15.1
`15.2
`15.3
`15.4
`15.5
`
`Chapter 16.
`16.1
`16.2
`16.3
`16.4
`16.5
`16.6
`16.7
`
`Chapter 17.
`17.1
`17.2
`17.3
`17.4
`
`Chapter 18.
`18.1
`18.2
`18.3
`18.4
`18.5
`18.6
`18.7
`18.8
`18.9
`18.10
`18.11
`18.12
`
`Chapter 19.
`19.1
`19.2
`19.3
`19.4
`19.5
`19.6
`
`TFTP: Trivial File Transfer Protocol
`Introduction
`209
`Protocol
`209
`An Example
`Security
`213
`Summary
`213
`
`211
`
`BOOTP: Bootstrap Protocol
`Introduction
`215
`BOOTP Packet Format
`An Example
`218
`BOOTP Server Design
`BOOTP Through a Router
`Vendor-Specific Information
`Summary
`222
`
`215
`
`219
`220
`221
`
`TCP: Transmission Control Protocol
`223
`Introduction
`223
`TCP Services
`225
`TCP Header
`227
`Summary
`
`TCP Connection Establishment and Termination
`Introduction
`229
`Connection Establishment and Termination
`Timeout of Connection Establishment
`235
`236
`Maximum Segment Size
`TCP Half-Close
`238
`TCP State Transition Diagram
`Reset Segments
`246
`Simultaneous Open
`250
`Simultaneous Close
`252
`TCP Options
`253
`TCP Server Design
`Summary
`260
`
`229
`
`240
`
`254
`
`TCP Interactive Data Flow
`Introduction
`263
`263
`Interactive Input
`Delayed Acknowledgments
`Nagle Algorithm
`267
`Window Size Advertisements
`Summary
`274
`
`265
`
`27 4
`
`209
`
`215
`
`223
`
`229
`
`263
`
`
`
`xii
`
`TCP /IP Illustrated
`
`Chapter 20.
`
`TCP Bulk Data Flow
`
`20.1
`20.2
`20.3
`20.4
`20.5
`20.6
`20.7
`20.8
`20.9
`
`275
`Introduction
`275
`Normal Data Flow
`280
`Sliding Windows
`282
`Window Size
`284
`PUSH Flag
`285
`Slow Start
`Bulk Data Throughput
`292
`Urgent Mode
`Summary
`296
`
`286
`
`Chapter 21.
`
`21.1
`21.2
`21.3
`21.4
`21.5
`21.6
`21.7
`21.8
`21.9
`21.10
`21.11
`21.12
`
`TCP Timeout and Retransmission
`Introduction
`297
`Simple Timeout and Retransmission Example
`Round-Trip Time Measurement
`299
`An RTT Example
`301
`Congestion Example
`306
`310
`Congestion Avoidance Algorithm
`Fast Retransmit and Fast Recovery Algorithm
`Congestion Example (Continued)
`313
`Per-Route Metrics
`316
`ICMP Errors
`317
`Repacketization
`320
`Summary
`321
`
`298
`
`312
`
`Chapter 22.
`
`TCP Persist Timer
`
`22.1
`22.2
`22.3
`22.4
`
`Introduction
`323
`An Example
`323
`Silly Window Syndrome
`Summary
`330
`
`325
`
`Chapter 23.
`
`TCP Keepalive Timer
`
`23.1
`23.2
`23.3
`23.4
`
`Introduction
`331
`Description
`332
`Keepalive Examples
`Summary
`337
`
`333
`
`Chapter 24.
`
`24.1
`24.2
`24.3
`24.4
`
`TCP Futures and Performance
`Introduction
`339
`Path MTU Discovery
`Long Fat Pipes
`344
`Window Scale Option
`
`340
`
`347
`
`Contents
`
`275
`
`297
`
`323
`
`331
`
`339
`
`
`
`TCP /IP Illustrated
`
`Contents
`
`xiii
`
`24.5
`24.6
`24.7
`24.8
`24.9
`
`349
`Timestamp Option
`PAWS: Protection Against Wrapped Sequence Numbers 351
`T/TCP: A TCP Extension for Transactions
`351
`TCP Performance
`354
`Summary
`356
`
`SNMP: Simple Network Management Protocol
`
`359
`
`' Chapter 25.
`25.1
`25.2
`25.3
`25.4
`25.5
`25.6
`25.7
`25.8
`25.9
`25.10
`25.11
`25.12
`25.13
`
`Chapter 26.
`
`Telnet and Rlogln: Remote Login
`
`26.1
`26.2
`26.3
`26.4
`26.5
`26.6
`
`Introduction
`Rlogin Protocol
`Rlogin Examples
`Telnet Protocol
`Telnet Examples
`417
`Summary
`
`389
`391
`396
`401
`406
`
`Chapter 27.
`27.1
`27.2
`27.3
`27.4
`
`Chapter 28.
`28.1
`28.2
`28.3
`28.4
`28.5
`
`FTP: Fiie Transfer Protocol
`
`Introduction
`FTP Protocol
`FTP Examples
`439
`Summary
`
`419
`419
`426
`
`SMTP: Simple Mall Transfer Protocol
`
`441
`
`Introduction
`SMTP Protocol
`SMTP Examples
`SMTP Futures
`459
`Summary
`
`442
`448
`452
`
`359
`Introduction
`360
`Protocol
`Structure of Management Information
`Object Identifiers
`364
`Introduction to the Management Information Base
`Instance Identification
`367
`Simple Examples
`370
`Management Information Base (Continued)
`Additional Examples
`382
`Traps
`385
`ASN.1 and BER
`SNMP Version 2
`Summary
`388
`
`363
`
`372
`
`386
`387
`
`365
`
`389
`
`419
`
`441
`
`
`
`xiv
`
`TCP /IP Illustrated
`
`Chapter 29.
`29.1
`29.2
`29.3
`29.4
`29.5
`29.6
`29.7
`29.8
`
`Chapter 30.
`30.1
`30.2
`30.3
`30.4
`30.5
`30.6
`
`NFS: Network File System
`461
`Introduction
`461
`Sun Remote Procedure Call
`XOR: External Data Representation
`Port Mapper
`465
`NFS Protocol
`467
`NFS Examples
`474
`NFS Version 3
`479
`Summary
`480
`
`465
`
`Other TCP/IP Applications
`481
`Introduction
`481
`Finger Protocol
`483
`Whois Protocol
`Archie, WAIS, Gopher, Veronica, and WWW
`X Window System
`486
`490
`Summary
`
`484
`
`Appendix A.
`A.1
`A.2
`A.3
`A.4
`A.5
`A.6
`
`The tcpdump Program
`BSD Packet Filter
`491
`493
`SunOS Network Interface Tap
`SVR4 Data Link Provider Interface
`495
`t cpdurnp Output
`Security Considerations
`Socket Debug Option
`
`496
`496
`
`494
`
`Appendix B. Computer Clocks
`
`Appendix C. The sock Program
`
`Appendix D. Solutions to Selected Exercises
`
`Appendix E.
`E.1
`E.2
`E.3
`E.4
`E.5
`E.6
`
`Configurable Options
`BSD/386 Version 1.0
`SunOS 4.1 .3
`527
`System V Release 4
`529
`Solaris 2.2
`AIX 3.2.2
`536
`4.4BSD
`537
`
`526
`
`529
`
`Appendix F. Source Code Availability
`
`Bibliography
`
`Index
`
`Contents
`
`461
`
`481
`
`491
`
`499
`
`503
`
`507
`
`525
`
`539
`
`543
`
`555
`
`
`
`Chapter 1
`Introduction
`10
`
`
`Section 1.7
`
`fi
`
`i
`
`1.7
`
`Demul
`
`Whenai
`col stacl
`col box
`upper|
`txt’ pl
`
`NNN
`
`
`
`
`a
`user data
`
`| eed
`
`
`
`
`,
`acipbeation
`L
`F
`
`Pe
`
`y
`a ——
`Appl [|
`
`| header
`user data
`cement e
`
`] ge
`‘TCP
`header
`application da
`
`—_ ——— TCP segment —————
`IP
`y
`Y
`P os
`fer
`oS
`re
`‘
`par
`
`
`
`| abAN|cme>. 1
`hens
`applicationdata
`|
`header
`ICMP
`
`~#___—______ IP datagram
`Ethernet
`=
`driver
`
`
`
`
`
`IP TCP re Ethernet|| Ethernet| i|: application data ;
`| header
`header
`header
`|
`trailer
`.thernet
`ARP
`
`
`
`, 20
`20
`x
`=
`pears:
`Lage
`
`
`
`——_—__— —— Ethernet frame ee|
`[et 46 to1500 bytesa
`
`a he ee
`
`"
`
`Figure 1.7 Encapsulation ofdataas it goes downthe protocolstack.
`
`|
`
`IP
`Recall from Figure 1.4 (p. 6) that TCP, UDP, ICMP, and IGMPall send data to IP.
`must add sometype of identifier to the IP headerthatit generates, to indicate the layer
`to which the data belongs.
`IP handlesthis by storing an 8-bit valuein its headercalled
`the protocol field. A value of 1 is for ICMP, 2 is for IGMP, 6 indicates TCP, and 17 is for
`UDP.
`Similarly, many different applications can be using TCP or UDPat any onetime.
`The transport layer protocols store an identifier in the headers they generate to identify
`the application. Both TCP and UDP use 16-bit port numbers to identify applications.
`TCP and UDPstore the source port number and the destination port numberin their
`respective headers.
`The network interface sends and receives frames on behalf of IP, ARP, and RARP.
`There must be some formof identification in the Ethernet headerindicating which net-
`work layer protocol generated the data. To handle this thereis a 16-bit frame type field
`in the Ethernet header.
`
`Whenv
`ments 1
`number
`
`
`
`
`
`34
`
`IP: Internet Protocol
`
`3.2
`
`IP Header
`
`Chapter3
`
`Section 3.2
`
`Figure 3.1 shows the format of an IP datagram. The normal size of the IP headeris 20
`bytes, unless options are present.
`0
`| abit
`version
`“DI
`
`15 16
`31
`
`[;
`7 | 4
`levit head
`8-bit typ: of
`vi
`.
`|
`length
`(TOS)
`|
`16-bit total length (in bytes)
`“DL
`eade
`DIC type Of service
`cai
`s
`* i
`
`|
`a3:
`ee
`3-bit
`:
`np
`16-bit identification
`:
`13-bit fragment offset
`flags
`
`|
`8-bit
`time
`to live
`|
`i
`|
`
`8-bit protocol | 16-bit headerchecksumsa er ‘ iv | |20bytes
`
`
`
`
`
`
`7
`
`f
`
`Only 1
`RFC 12
`standa
`andan
`Fig
`In the |
`
`tepdu SSaes
`
`The int
`they're
`by FTP,
`fied for
`is the on
`The
`newer §
`
`tocols s
`field.
`
`
`
`
`
`
`32-bit source IP address
`
`32-bit destination IP address
`_
`options(if any)
`
`data
`
`|
`
`|
`: —_|
`/
`
`/
`
`Figure 3.1
`
`IP datagram, showing thefields in the IP header.
`
`Wewill showthepictures of protocol headers in TCP/IP asin Figure 3.1. The mostsig-
`nificant bit is numbered 0 at the left, and the least significant bit of a 32-bit value is num-
`bered 31on the right.
`The 4 bytes in the 32-bit value are transmitted in the order: bits 0-7 first, then bits
`8-15, then 16-23, and bits 24-31 last. This is called big endian byte ordering, whichis
`the byte ordering requiredforall binary integers in the TCP/IP headers as theytraverse
`a network. This is called the network hyte order. Machines that store binaryintegers in
`other formats, such asthelittle endian format, must convert the header values into the
`network byte order before transmitting the data.
`Thecurrent protocol version is 4, so IP is sometimes called IPv4. Section 3.10 dis-
`cusses some proposals for a newversion ofIP.
`The header lengthis the numberof 32-bit wordsin the header, including anyoptions.
`Since this is a 4-bitfield, it limits the headerto 60 bytes.
`In Chapter 8 we'll seethatthis
`limitation makes some of the options, such as the record route option, useless today.
`The normal valueofthis field (when no options are present)is 5,
`The type-of-service field (TOS) is composed of a 3-bit precedence field (which is
`ignored today), 4 TOS bits, and an unusedbit that must be 0. The 4 TOSbits are: mini-
`mize delay, maximize throughput, maximize reliability, and minimize monetarycost.
`
`
`
`
`
`56
`
`ARP· Address Resolution Protocol
`
`Chapter4
`
`The fundamental concept behind ARP is that the network interface has a hardware
`address (a 48-bit value for an Ethernet or token ring interface). Frames exchanged at the
`hardware level must be addressed to the correct interface. But TCP /IP works with its
`own addresses: 32-bit IP addresses. Knowing a host's IP address doesn't let the kernel
`send a frame to that host. The kernel (i.e., the Ethernet driver) must know the destina(cid:173)
`tion's hardware address to send it data. The function of ARP is to provide a dynamic
`mapping between 32-bit IP addresses and the hardware addresses used by various net(cid:173)
`work technologies.
`Point-to-point links don't use ARP. When these links are configured (normally at
`bootstrap time) the kernel must be told of the IP address at each end of the link. Hard(cid:173)
`ware addresses such as Ethernet addresses are not involved.
`
`4.3 ARP Cache
`
`Essential to the efficient operation of ARP is the maintenance of an ARP cnche on each
`host. This cache maintains the recent mappings from Internet addresses to hardware
`addresses. The normal expiration time of an entry in the cache is 20 minutes from the
`time the entry was created.
`We can examine the ARP cache with the arp(8} command. The -a option displays
`all entries in the cache:
`bsdi
`. arp -a
`sun (140.252.13.33) at 8:0:20:3:f6:42
`svr4 (140.252.13.34) at 0:0:c0:c2:9b:26
`
`The 48-bit Ethernet addresses are displayed as six hexadecimal numbers separated by
`colons. We discuss additional features of the arp command in Section 4.8.
`
`4.4 ARP Packet Format
`
`Figure 4.3 shows the format of an ARP request and an ARP reply packet, when used on
`an Ethernet to resolve an IP address. (ARP is general enough to be used on other net(cid:173)
`works and can resolve addresses other than rP addresses. The first four fields following
`the frame type field specify the types and sizes of the finaJ four fields.}
`
`Ethernet
`destination dddr
`
`Ethernet
`source addr
`
`t.1rget
`liCllder
`smdrr
`JP addt
`Ethernet addr
`Elhemet addt
`6
`6
`4
`_ _ __., _ _ _ _ _ _ _ 28byteARI' ~ e s t / r e p l y - - - - - - - . .
`
`target
`JP addr
`
`Figure 4.3 Form11t of ARP request or reply packet when used on an Ethernet.
`
`The first two fields in the Ethernet header are the source and destination Ethernet
`addresses. The special Ethernet destination address of all one bits means the broadcast
`address. All Ethernet interfaces on the cable receive these frames.
`
`
`
`
`
`Section4.5
`
`ARP Examples
`
`57
`
`The 2-byte Ethernet frame type specifies the type of data that follows. For an ARP
`request or an ARP reply, this field is 0x0806.
`The adjectives hardware and protocol are used to describe the fields in the ARP pack(cid:173)
`ets. For example, an ARP request asks for the protocol address (an IP address in this
`case) corresponding to a hardware address (an Ethernet address in this case).
`The hard type field specifies the type of hardware address. Its value is 1 for an Ether(cid:173)
`net. Prot type specifies the type of protocol address being mapped. Its value is 0x0800
`for IP addresses. This is purposely the same value as the type field of an Ethernet frame
`containing an IP datagram. (See Figure 2.1, p. 23.)
`The next two 1-byte fields, hard size and prot size, specify the sizes in bytes of the
`hardware addresses and the protocol addresses. For an ARP request or reply for an IP
`address on an Ethernet they are 6 and 4, respectively.
`The op field specifies whether the operation is an ARP request (a value of 1), ARP
`reply (2), RARP request (3), or RARP reply (4). (We talk about RARP in Chapter 5.)
`This field is required since the frame type field is the same for an ARP request and an
`ARP reply.
`The next four fields that follow are the sender's hardware address (an Ethernet
`address in this example), the sender's protocol address (an IP address), the target hard(cid:173)
`ware address, and the target protocol address. Notice there is some duplication of infor(cid:173)
`mation: the sender's hardware address is available both in the Ethernet header and in
`the ARP request.
`For an ARP request all the fields are filled in except the target hardware address.
`When a system receives an ARP request directed to it, it fills in its hardware address,
`swaps the two sender addresses with the two target addresses, sets the op field to 2, and
`sends the reply.
`
`4.5 ARP Examples
`
`In this section we'll use the tcpdump command to see what really happens with ARP
`when we execute normal TCP utilities such as Telnet. Appendix A contains additional
`details on the t cpd ump program.
`
`Normal Example
`
`To see the operation of ARP we'll execute the telnet command, connecting to the dis(cid:173)
`card server.
`
`bsdi % arp -a
`bsdi % telnet svr4 discard
`Trying 140.252.13.34 ...
`Connected to svr4.
`Escape character is,-]'.
`-1
`telnet> quit
`Connection closed.
`
`verify ARP cache is empty
`connect to the discard seroer
`
`type Control, right bracket to get Telnet client prompt
`and terminate
`
`
`
`
`
`Delayed Acknowledgments
`
`bsdi
`-1023 > svr4.login:
`svr4.
`login > bsdi.1023:
`bsdi.
`1023 > svr4.login:
`
`1023 > svr4.login:
`login > bsdi.1023:
`1023 > svr4.login:
`
`O:1(1) ack 1 win
`1:2(1) ack 1 win
`ack 2 win 4096
`
`1:2(1) ack 2 win
`2:3(1) ack 2 win
`ack 3 win 4096
`
`1023 > svr4.login:
`login > bsdi.1023:
`1023 > svr4.login:
`
`2:3(1) ack 3 win
`3:4(1) ack 3 win
`- ack 4 win 4096
`
`1023 > svr4.login:
`login > bsdi.1023:
`1023 > svr4.login:
`
`3:4(1) ack 4 win
`4:5(1) ack 4 win
`ack 5 win 4096
`
`bsdi.
`svr4.
`bsdi.
`
`bsdi.
`svr4.
`bsdi.
`
`bsdi.
`svr4.
`bsdi.
`
`bsdi.
`svr4.
`bsdi.
`
`1023 > svr4.login:
`login > bsdi.1023:
`1023 > svr4.login:
`svr4.login > bsdi.1023:
`bsdi.1023 > svr4.login:
`svr4.login > bsdi.1023:
`bsdi.1023 > svr4.login:
`Figure 19.2. TCP segments when date typed on Rlogin connection.
`
`200 msto see if there is data to send with the ACK.
`
`There are some subtle points in Figure 19.2 dealing with timing that we'll coverin this
`section. Figure 19.3 showsthe time line for the exchange in Figure 19.2.
`(We have
`deleted all the window advertisements from this time line, and have added a notation
`indicating whatdata is being transferred.)
`We have labeled the seven ACKssent from bsdi to svr4 as delayed ACKs, Nor-
`mally TCP does not send an ACKthe instantit receives data.
`Instead, it delays the
`ACK, hoping to have data going in the samedirection as the ACK, so the ACK can be
`sent along with the data. (This is sometimescalled having the ACK piggyback with the
`data.) Most implementations use a 200-ms delay—thatis, TCP will delay an ACK up to
`
`4096
`4096
`
`4096
`4096
`
`4096
`4096
`
`4096
`4096
`
`4096
`4096
`
`4:5(1) ack 5 win
`5:7(2) ack 5 win
`ack 7 win 4096
`
`7:37(30) ack 5 win 4096
`» ack 37 win 4096
`37:44(7) ack 5 win 4096
`» ack 44 win 4096
`
`(0.
`(0.
`
`(0.
`(0.
`(0.
`
`0165)
`1235)
`
`3181)
`0163)
`0656)
`
`(0.
`(0.
`(0.
`
`(8.
`(0.
`(0.
`
`2746)
`0165)
`1090)
`
`2512)
`0164)
`1323)
`
`(oO.
`(oO.
`(0.
`
`3407)
`0173)
`0420)
`
`(0.0599)
`(0.1403)
`(0.0042)
`(0.1958)
`
`errFEEcoo¢oocooio
`
`+0
`-016497
`.139955
`
`- 458037
`«474386
`- 539943
`
`- 814582
`-831108
`-940112
`
`- 191287
`-207701
`339994
`
`- 680646
`- 697977
`- 739974
`
`799841
`- 940176
`- 944338
`-140110
`
`1 11 2
`
`SesAORwh
`
`plus a CR/LFpair at the end. The next 7 bytes sent from the server to the client (line 18)
`are the client’s prompt on the server host: svr4 %
`. Line 19 acknowledges these 7
`bytes.
`Notice how the TCP acknowledgmentsoperate. Line 1 sendsthe data byte with the
`Sequence number0. Line 2 ACKsthis by setting the acknowledgment sequence number
`to 1, the sequence numberofthe last successfully received byte plus one. (This is also
`called the sequence numberofthe next expected byte.) Line 2 also sendsthe data byte
`with a sequence number of 1 from the serverto the client. This is ACKed by theclient
`in line 3 by setting the acknowledged sequence numberto 2.
`
`Delayed Acknowledgments
`
`