`
`'3
`E:
`
`ab
`
`] Z c
`
`:m
`U?-
`I...
`l—:I
`—<
`"G
`7-3K'N.
`\J
`‘n
`T'l'l
`m.
`Ln
`
`1;:
`
`Z £ (
`
`“N
`.k-J.
`"_-’
`6A
`.0
`
`C j ZI
`
`A'
`
`w.
`
`(J?-
`
`m 7
`
`3m m
`
`
`
`
`MICROSOFT - EXHIBIT 1036
`
`MICROSOFT CORP. V.
`
`UNILOC 2017 LLC
`
`IPR2019-01026
`
`i
`
`
`
`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
`
`
`
`
`
`
`M "
`
`10
`
`Introduction
`Chapter I
`
`
`
`
`[
`user data
`
`
`
`
`.'
`*
`
`l_' .—_
`i
`Lapphcallon
`*
`_
`user data
`Elia; I
`
`.—
`_ — _i
`r—
`'
`I
`TCP
`
`l
`_
`t
`_
`TCI’
`'
`'1
`l'“'t'11‘|t
`header
`[pp In! 1(1 1. a a
`
`
`Section 1.7
`
`1.7
`
`Demul
`
`When an
`col stacl
`col box
`
`upper 1;
`takes pl.-
`
`ICMP
`
`
`
`
`.
`
`i... —— — TCI‘ segment —~—|-i
`J
`._
`._
`-
`l
`_ ..
`-
`7]"1
`.
`‘
`hZhlLr
`application data
`ht :Id r
`|
`‘
`i
`‘r
`L'
`I
`_' _
`_ '
`I
`un- —— —— — Ji‘datagram —— — —h-i
`I
`
`' Ethernet |
`IP
`TCP
`a x “_ ti m data
`Ethernet :
`
`l header
`header
`header
`PP La t
`trailer
`I
`
`
`I
`1‘4
`20
`2t]
`'
`"
`"
`4
`f
`5-4-— — — Ethernet frame
`—— — ——u-f
`Lt.._—. _— . 46m 1500 bytes — .—.—..J
`
`..
`
`-
`|I-‘
`|—- 17
`.
`.
`.—'——
`[Ethernet
`
`driver
`
`.t 101119!
`
`ARI1
`_.‘:
`
`
`
`Figure 1.7 Encapsulation uldata as it goes down the protocol stark.
`
`Recall from Figure 1.4 (p. 6) that TCP, UDP, ICMP, and IGMP all send data to H’. W
`must add some type of identifier to the IP header that it generates, to indicate the layer
`to which the data belongs.
`IP handles this by storing an 8-bit value in its header called
`the protocol field. A value of 1 is for ICMP, 2 is for IGMP, 6 indicates TCl’, and 17 is for
`UDP.
`
`Similarly, many different applications can be using 'I‘CP or UDP at any one time.
`The transport layer protocols store an identifier in the headers they generate to identify
`the application. Both TCP and UDP use 16-bit port nmrrlwers to identify applications.
`TCP and UDP store the source port number and the destination port number in their
`respective headers.
`The network interface sends and receives frames on behalf of IP, ARR and KARI).
`There must be some form of identification in the Ethernet header indicating which net-
`work layer protocol generated the data. To handle this there is a '16~bit frame type field
`in the Ethernet header.
`
`When 1.
`ments 1
`number
`
`
`
`
`
`34
`
`W: Internet Protocol
`
`12
`
`IP Header
`
`Chapter 3
`
`Section 3.2
`
`Figure 3.] shows the format of an IP datagram. The normal size of the If’ header is 20
`bytes, unless options are present.
`
`
`
`
`It
`ifl-Ih't
`-
`I
`version
`
`‘
`
`13 to
`31
`
`--
`h
`
`‘
`.
`l
`
`“lhlb'tialr‘
`tib'tt1—ic
`_
`—
`I
`ie. I. e
`.- i
`_\-[. e o service
`,_
`.
`,
`.
`.
`.-
`l
`length
`{T05}
`in hit total ttngth tin bytes)
`
`.
`.
`_
`.
`.
`..
`.
`3-bit
`iii-bit Identification
`lTi-bit fragment ottset
`flags
`
`.‘H '
`'
`r t'
`'
`'
`-
`.
`.
`i
`.
`“I lilrltt in h“
`"
`8-bit protocol
`y
`16-bit headercherksum
`32-bit source ll’address
`I
`32-bit destination 1? address
`
`_ _
`_
`.
`_.
`Y
`L)"
`options {if any}
`__.I’
`
`
`Only 1
`RFC if
`standai
`and a n
`
`Fig
`in the :
`
`tcpctui
`
`.n I.....m.t.
`
`The int
`
`they’re
`by FTP.
`fied for
`is the or
`The
`newer s
`
`tocols 5
`field.
`
`.
`
`
`
`
`
`
`
`'
`
`I
`20 bytes
`‘
`
`.
`
`
`
`r1;
`
`data
`
`Figure 3.]
`
`Il’datagram, showing the fields in the IE‘ header.
`
`We will show the pictures of protocol headers in TCP/IP as in Figure 3.1, The most sit,-
`nificant bit is numbered 0 at the left, and the least significant bit of a 32-bit v
`alue is num—
`bored 31 on the right.
`The 4 bytes in the 32-bit value are transmitted in the order: bits 0-? first, then bits
`8-15, then 16-23, and bits 24-3] last. This is called big endimi byte ordering, which is
`the byte ordering required for all binary integers in the TCP/IP headers as they traverse
`a network. This is called the network trifle order. Machines that store binary integers in
`other formats, such as the iittie eiiii‘iatt format, must convert the header values into the
`network byte order before transmitting the data.
`The current protocol version is 4, so [P is sometimes called [1’an Section 3.10 dis—
`cusses some proposals for a new version of IP.
`The header length is the number of 32-bit words in the header. including any options.
`Since this is a 4‘bit field, it limits the header to 60 bytes.
`In Chapter 8 we'll see that this
`limitation makes some of the options, such as the record route option, useless today.
`The normal value of this field (when no options are present} is 5.
`The type—of—srrefce field (T05) is composed of a 3-bit precedence field (which is
`ignored today}, 4 TOS bits, and an unused bit that must be 0. The 4 TOS bits are: mini-
`mize delay, maximize throughput, maximize reliability, and minimize monetary cost.
`
`
`
`
`
`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' ~est/reply-------..
`
`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
`
`
`
`
`
`265
`Delayed Acknowledgments
`
`
`1023 > svr4.1ogin:
`login > bsdi.1023:
`1023 > svré.loqin:
`
`2:3t1i ack 3 win
`3:4!1) ask 3 win
`. ack 4 win 4096
`
`0:1t1) ack 1 win
`1:2{11 ack 1 win
`ack 2 win 4096
`
`1:2{1} ask 2 win
`2:3[11 ack 2 win
`ack 3 win 4096
`
`3:4(1) ack 4 win
`4:5{1} ack 4 win
`ack 5 win 4096
`
`4:5(1) ack 5 win
`5:?{2} ack 5 win
`ack 7 win 4096
`
`4096
`4096
`
`4096
`4096
`
`4096
`4096
`
`4096
`4096
`
`4096
`4096
`
`7:3?(30) ack 5 win 4096
`. ack 3? win 4096
`3?:44(7) ack 5 win 4096
`. ack 44 win 4096
`
`
`
`
`
`\D'b‘sianu-v.Luis-I'M
`
`.0
`.01649?
`.139955
`
`.458037
`.474336
`.539943
`
`.814582
`.831108
`.940112
`
`.19128?
`.207?01
`.339994
`
`.680646
`.6979?7
`.739974
`
`.799841
`.940176
`.944338
`.140110
`
`(0.
`l0.
`
`(0.
`(0.
`[0.
`
`0165)
`1235)
`
`3181}
`0163)
`0655}
`
`(0.
`i0.
`i0.
`
`(0.
`i0.
`{0.
`
`2746)
`0165)
`1090)
`
`2512)
`0164i
`1323)
`
`i0.
`(0.
`[0.
`
`3407)
`0173)
`0420}
`
`{0.0599}
`(0.1403)
`[0.00421
`[0.1953]
`
`bsdi.
`svrfi.
`bsdi.
`
`bsdi.
`svr4.
`bsdi.
`
`bsdi.
`svrd.
`bsdi.
`
`bsdi
`.1023 > svrd.login:
`svr4
`.1ogin > b3di.1023:
`bsdi.
`1023 > svr4.1ogin:
`
`1023 > svrd.login:
`login > bsdi.1023:
`1023 ) svr4.login:
`
`1023 > svr4.login:
`login > bsdi.1023:
`1023 > svr4.login:
`
`bsdi.
`svr4.
`bsdi.
`
`1023 > svrQ.login:
`login > bsdi.1023:
`1023 > svr4.login:
`svr4.1ogin ) bsdi.1023:
`bsdi.1023 > svrq.login:
`svr4.1ogin > bsdi.1023:
`bsdi.1023 > svr4.1ogin:
`
`Figure 19.2 TCP segments when date typed on Rlogin connection.
`
`plus a CR/LF pair 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 {b
`. Line 19 acknowledges these 7
`bytes.
`Notice how the TCP acknowledgments operate. Line 1 sends the data byte with the
`sequence number 0. Line 2 ACKs this by setting the acknowledgment sequence number
`to 1, the sequence number of the last successfully received byte plus one. (This is also
`called the sequence number of the next expected byte.) Line 2 also sends the data byte
`with a sequence number of 1 from the server to the client. This is ACKed by the client
`in line 3 by setting the acknowledged sequence number to 2.
`
`Delayed Acknowledgments
`
`200 ms to 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 cover in this
`section. Figure 19.3 shows the 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 what data is being transferred.)
`We have labeled the seven ACKs sent from bsdi to svré as delayed ACKs. Nor‘
`mally TCP does not send an ACK the instant it receives data.
`instead, it delays the
`ACK, hoping to have data going in the same direction as the ACK, so the ACK can be
`sent along with the data. {This is sometimes called having the ACK piggyback with the
`data.) Most implementations use a ZOO-ms delay~—that is, TCP will delay an ACK up to
`
`