throbber

`
`'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
`
`

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket