0 z
`~ m
`(j)
`a
`m -<
`-0
`:;:;a
`0 ,,
`
`m
`(j)
`(j)
`
`mmmzmm
`>UU_mOZ-<<mmEm<mmOmmmEOZZ.flOZijZO
`
`
`
`:/F-'§t 1
`-
`~ ;}:
`.
`
`., ..... '-
`-: ·:
`';~~'
`
`:: .. >'t'
`
`i
`
`"
`
`. lt. ns
`
`The
`
`w.
`
`Volkswagen Exhibit 1007
`
`Page 1
`
`)>
`0
`0
`(j)
`
`0 z
`)>
`a
`n
`0
`~
`-0
`C
`
`-I -z
`
`C)
`(j)
`m
`:;:;a
`m
`(j)
`
`Volkswagen Exhibit 1007
`Page 1
`
`

`

`-
`
`TCP/IP Illustrated, Volume 1
`
`The Protocols
`
`W. Richard Stevens
`
`A
`TT
`
`ADDISON-WESLEY PUBLISHING COMPANY
`Reading, Massachusetts Menlo Park, California New York
`Don Mills, Ontario Wokingham, England Amsterdam
`Bonn Sydney Singapore Tokyo Madrid . San Juan
`Seoul Milan Mexico City Taipei
`
`Volkswagen Exhibit 1007
`Page 2
`
`

`

`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)
`1.TCP/IP (Computer network protocol) I. Title. II. Series.
`TK5105.55S74 1994
`004.6'2---<lc20
`
`Copyright © 1994 by Addison-Wesley Publishing Company, Inc.
`
`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 written consent of the publisher. Printed in the
`United States of America. Published simultaneously in Canada.
`
`Text printed on recycled and acid-free paper
`
`ISBN 0-201-63346-9
`7 8 9 10 11 12 13 14 15-MA-99989796
`Seventh printing, March 1996
`
`Volkswagen Exhibit 1007
`Page 3
`
`

`

`Section 1.6
`
`Encapsulation
`
`9
`
`.
`.
`In Section 3.4 we'll extend our d
`after describing IP routing. Figure 3 9 :~:iption of IP_ addresses to include subnetting,
`network IDs of all zero bits or all on~ bits. ws the special case IP addresses: host IDs and
`
`1.5
`
`The Domain Name System
`
`h
`Although the network interfaces O
`addresses humans wo k b
`t
`. n a ost, and therefore the host itself, are known by IP
`;.s ~~mg the name of a host. In the TCP /IP world the Domain
`Name System (DNS) • r
`is a 1stn uted database that provides the mapping between IP
`dd
`d h
`ostnames. Chapter 14 looks into the DNS in detail.
`a
`resses an
`1·
`·
`For now we must be aware th t
`a any app 1cation can call a standard library function
`to lo~k u~ the I~ address ( or addresses) corresponding to a given hostname. Similarly a
`function 1s provided to do the re
`I k
`·
`.
`verse oo up-given an IP address, look up the corre-
`spondmg hostname.
`Most applications that take a hostname as an argument also take an IP address.
`When we use the Telnet client in Chapter 4, for example, one time we specify a host(cid:173)
`name and another time we specify an IP address.
`
`1.6 Encapsulation
`
`When an application sends data using TCP, the data is sent down the protocol stack,
`through each layer, until it is sent as a stream of bits across the network. Each layer
`adds information to the data by prepending headers (and sometimes adding trailer
`information) to the data that it receives. Figure 1.7 shows this pro_cess. The unit of data
`that TCP sends to IP is called a TCP segment. The unit of data that IP sends to the net(cid:173)
`work interface is called an IP datagram. The stream of bits that flows across the Ethernet
`is called a frame.
`The numbers at the bottom of the headers and trailer of the Ethernet frame in Fig(cid:173)
`ure 1.7 are the typical sizes of the headers in bytes. We'll have more to say about each of
`these headers in later sections.
`A physical property of an Ethernet frame is that the size of its data must be between
`46 and 1500 bytes. We'll encounter this minimum in Section 4.5 and we cover the maxi-
`mum in Section 2.8.
`
`All the Internet standards and most books on TCP /IP use the term octet instead of byte. The
`use of this cute, but baroque term is historical, since much_ of the ea~ly work on TCP /IP was
`done on systems such as the DEC-10, which did not use ~-bit ~ytes. Smee almost every current
`computer system uses 8-bit bytes, we'll use the term byte m this text.
`
`To be completely accurate in Figure 1.7 we should say th~t the unit of data passed between IP
`and the network interface is a packet. This p_acket c_~ be ei~er an IP datagram or a fragment of
`an IP datagram. We discuss fragmentation m detail m Section 11.5.
`We could draw a nearly identical picture for UDP data. The only changes ar~ that
`the unit of information that UDP passes to IP is called a UDP datagram, and the size of
`the UDP header is 8 bytes.
`
`Volkswagen Exhibit 1007
`Page 4
`
`

`

`~ IP: Internet Protocol
`~:__~~~~~~~----------------------ChapterJ
`.___
`
`3.2
`
`IP Header
`
`Figure 3.1 shows the format of an
`bytes unless options are present.
`'
`
`0
`
`IP d t gram The normal size of the IP header is 20
`a a
`.
`31
`
`15 16
`
`4-bit
`version
`
`14-bit heade1 8-bit type of service
`(TOS)
`length
`
`16-bit total length (in bytes)
`
`16-bit identification
`
`3-bit
`flags
`
`13-bit fragment offset
`
`8-bit time to live
`(TTL)
`
`8-bit protocol
`
`16-bit header checksum
`
`20 bytes
`
`32-bit source IP address
`
`32-bit destination IP address
`
`options (if any)
`
`data
`
`?
`
`,
`7
`
`'7
`'
`
`7
`'
`
`Figure 3.1 IP datagram, showing the fields in the IP header.
`
`We will show the pictures of protocol headers in TCP /IP as in Figure 3.1. The ~oSt sig(cid:173)
`nificant bit is numbered O at the left, and the least significant bit of a 32-bit value IS mun-
`bered 31 on the right.
`b't
`The 4 bytes in the 32-bit value are transmitted in the order: bits 0-7 first, the~chI_s
`8-15, then 16-23, and bits 24-31 last. This is called big endian byte ordering, whi
`IS
`the byte ordering required for all binary integers in the TCP /IP headers as they traver~e
`a network. This is called the network byte order. Machines that store binary int~gers:
`other formats, such as the little endian format, must convert the header values into e
`network byte order before trai:15mitting the data.
`.
`dis-
`The current protocol version is 4, so IP is sometimes called IPv4. Section 3.lO .
`cusses some proposals for a new version of IP.
`.
`The header length is the number of 32-bit words in the header, including any opti:·
`Since this is a 4-bit field, it limits the header to 60 bytes. In Chapter 8 we'll see thatd ys
`limi
`1 s to a ·
`·
`ak
`tation m es some of the options, such as the record route option, use es
`hich is
`The normal value of_ thi~ field (whe~ no options are present) is 5.
`.
`. The type-of-service field (TOS) Is composed of a 3-bit precedence field (w inutl(cid:173)
`i~ored today), ~ T?S bits, and an unused bit that must be O. The 4 TOS bits are: cost.
`nuze delay, maxuruze throughput, maximize reliability, and minimize monetary
`
`Volkswagen Exhibit 1007
`Page 5
`
`

`

`2:22~6~_2T~C~P~: ~Tr~an~sm~is:si~o~n_:.C=:o:n~tr~o~l-=P-r_ot_o_co_I_________________ Chapter 17
`-
`~
`Each TCP segment contains the source and destination po~t number to identt
`t
`.
`d
`. .
`application. These two values, along with the source a dfy he
`sendmg an rece1vmg
`'d
`'f
`h
`.
`n destt
`· the IP header uniquely 1 enh y eac connection.
`•
`dd
`.
`nation IP a
`resses m
`.
`'
`b
`.
`b.
`t'on of an IP address and a port num er 1s sometimes called a
`Th
`socket
`e com ma 1
`. .
`.
`.
`(RFC 793)
`, and later 1t also be
`·
`Thi t m appeared in the original TCP spec1f1cat10n
`. t
`(S
`.
`f
`s er
`.
`came
`used as the name of the Berkeley-derived ~rogrammmg m e~ ace echon 1.15). It is the
`socket pair (the 4_tuple consisting of the chent IP address, che~t port number, server IP
`address, and server port number) that specifies the two end pomts that uniquely identi(cid:173)
`fies each TCP connection in an internet.
`The sequence number identifies the byte in _the ~tream of data from the sending TCP
`to the receiving TCP that the first byte of data m this segment rep_res:nts. If we consider
`the stream of bytes flowing in one direction between two apphcahons, TCP numbers
`each byte with a sequence number. This sequence number is a 32-bit unsigned number
`that wraps back around to 0 after reaching 232 -1.
`When a new connection is being established, the SYN flag is turned on. The
`sequence number field contains the initial sequence number (ISN) chosen PY this host for this
`connection. The sequence number of the first byte of data sent by this host will be the
`ISN plus one because the SYN flag consumes a sequence number. (We describe addi(cid:173)
`tional details on exactly how a connection is established and terminated in the next
`chapter where we'll see that the FIN flag consumes a sequence number also.)
`Since every byte that is exchanged is numbered, the acknowledgment number contains
`the next sequence number that the sender of the acknowledgment expects to receive.
`This is therefore the sequence number plus 1 of the last successfully received byte of
`data. This field is valid only if the ACK flag (described below) is on.
`Sending an ACK costs nothing because the 32-bit acknowledgment number field is
`always part of the header, as is the ACK flag. Therefore we'll see that once a connection
`is established, this field is always set and the ACK flag is always on.
`TCP provides a full-duplex service to the application layer. This means that data can
`be flowing in each direction, independent of the other direction. Therefore, each end of
`a connection must maintain a sequence number of the data flowing in each direction.
`TCP can be described as a sliding-window protocol without selective or negati~e
`ackn~wled_gment~.
`(The sliding window protocol used for data transmission is
`described m Section 20.3.) We say that TCP lacks selective acknowledgments because
`the acknowledgment number in the TCP header means that the sender has successfully
`received up thr~ugh but not including that byte. There is currently no way to acknowl(cid:173)
`edge selected pieces of the data stream. For example, if bytes 1-1024 are received 0~,
`and the next segment contains bytes 2049-3072 the receiver cannot acknowledge this
`new s~gment. All it can send is an ACK with '1025 as the acknowledgment number.
`There 1~ no means for negatively acknowledging a segment. For example, if the seg·
`ment wit~ bytes 1025-2048 did arrive, but had a checksum error, all the receivin~ TCP
`~an send i_s an ACK with 1025 as the acknowledgment number. In Section 21.7 we 11 see
`ow duplicate acknowledgments can help determine that packets have been loSt.
`. d
`b The header length gives the length of the header in 32-bit words. This is require
`6oecbause the length of the options field is variable With a 4-bit field TCP is limited to a
`- yte header. Witho t
`t·
`h
`·
`'
`u op 10ns, owever, the normal size is 20 bytes.
`
`Volkswagen Exhibit 1007
`Page 6
`
`