Senior Acquisitions Editor: Kenyon Brown Development Editor: Kim Wimpsett

FIGURE 3.11

DHCP client four-step process

This is the four-step process a client takes to receive an IP address from a

DHCP server:

1.   The DHCP client broadcasts a DHCP Discover message looking for a

DHCP server (Port 67).

2.  The DHCP server that received the DHCP Discover message sends a

layer 2 unicast DHCP Offer message back to the host.

3.  The client then broadcasts to the server a DHCP Request message

asking for the offered IP address and possibly other information.

4.  The server finalizes the exchange with a unicast DHCP

Acknowledgment message.

DHCP Conflicts

A DHCP address conflict occurs when two hosts use the same IP address.

This sounds bad, and it is! We’ll never even have to discuss this problem

once we get to the chapter on IPv6!

During IP address assignment, a DHCP server checks for conflicts using

the Ping program to test the availability of the address before it’s assigned

from the pool. If no host replies, then the DHCP server assumes that the

IP address is not already allocated. This helps the server know that it’s

providing a good address, but what about the host? To provide extra

protection against that terrible IP conflict issue, the host can broadcast

for its own address!

A host uses something called a gratuitous ARP to help avoid a possible

duplicate address. The DHCP client sends an ARP broadcast out on the

local LAN or VLAN using its newly assigned address to solve conflicts

before they occur.

So, if an IP address conflict is detected, the address is removed from the

DHCP pool (scope), and it’s really important to remember that the

address will not be assigned to a host until the administrator resolves the

conflict by hand!

Please see Chapter 9, “IP Routing,” to check out a DHCP

configuration on a Cisco router and also to find out what happens

when a DHCP client is on one side of a router but the DHCP server is

on the other side on a different network!

Automatic Private IP Addressing (APIPA)

Okay, so what happens if you have a few hosts connected together with a

switch or hub and you don’t have a DHCP server? You can add IP

information by hand, known as static IP addressing, but later Windows

operating systems provide a feature called Automatic Private IP

Addressing (APIPA). With APIPA, clients can automatically self-

configure an IP address and subnet mask—basic IP information that

hosts use to communicate—when a DHCP server isn’t available. The IP

address range for APIPA is 169.254.0.1 through 169.254.255.254. The

client also configures itself with a default Class B subnet mask of

255.255.0.0.

But when you’re in your corporate network working and you have a

DHCP server running, and your host shows that it’s using this IP address

range, it means that either your DHCP client on the host is not working

or the server is down or can’t be reached due to some network issue.

Believe me—I don’t know anyone who’s seen a host in this address range

and has been happy about it!

Now, let’s take a look at the Transport layer, or what the DoD calls the

Host-to-Host layer.

The Host-to-Host or Transport Layer Protocols

The main purpose of the Host-to-Host layer is to shield the upper-layer

applications from the complexities of the network. This layer says to the

upper layer, “Just give me your data stream, with any instructions, and

I’ll begin the process of getting your information ready to send.”

Coming up, I’ll introduce you to the two protocols at this layer:

Transmission Control Protocol (TCP)

User Datagram Protocol (UDP)

In addition, we’ll look at some of the key host-to-host protocol concepts,

as well as the port numbers.

Remember, this is still considered layer 4, and Cisco really

likes the way layer 4 can use acknowledgments, sequencing, and flow

control.

Transmission Control Protocol (TCP)

Transmission Control Protocol (TCP) takes large blocks of information

from an application and breaks them into segments. It numbers and

sequences each segment so that the destination’s TCP stack can put the

segments back into the order the application intended. After these

segments are sent on the transmitting host, TCP waits for an

acknowledgment of the receiving end’s TCP virtual circuit session,

retransmitting any segments that aren’t acknowledged.

Before a transmitting host starts to send segments down the model, the

sender’s TCP stack contacts the destination’s TCP stack to establish a

connection. This creates a virtual circuit, and this type of communication

is known as connection-oriented. During this initial handshake, the two

TCP layers also agree on the amount of information that’s going to be

sent before the recipient’s TCP sends back an acknowledgment. With

everything agreed upon in advance, the path is paved for reliable

communication to take place.

TCP is a full-duplex, connection-oriented, reliable, and accurate protocol,

but establishing all these terms and conditions, in addition to error

checking, is no small task. TCP is very complicated, and so not

surprisingly, it’s costly in terms of network overhead. And since today’s

networks are much more reliable than those of yore, this added reliability

is often unnecessary. Most programmers use TCP because it removes a

lot of programming work, but for real-time video and VoIP, User

Datagram Protocol (UDP) is often better because using it results in less

overhead.

TCP Segment Format

Since the upper layers just send a data stream to the protocols in the

Transport layers, I’ll use

Figure 3.12

to demonstrate how TCP segments a

data stream and prepares it for the Internet layer. When the Internet

layer receives the data stream, it routes the segments as packets through

an internetwork. The segments are handed to the receiving host’s Host-

to-Host layer protocol, which rebuilds the data stream for the upper-layer

applications or protocols.

FIGURE 3.12

TCP segment format

Figure 3.12

shows the TCP segment format and shows the different fields

within the TCP header. This isn’t important to memorize for the Cisco

exam objectives, but you need to understand it well because it’s really

good foundational information.

The TCP header is 20 bytes long, or up to 24 bytes with options. You need

to understand what each field in the TCP segment is in order to build a

strong educational foundation:

Source port This is the port number of the application on the host

sending the data, which I’ll talk about more thoroughly a little later in

this chapter.

Destination port This is the port number of the application requested

on the destination host.

Sequence number A number used by TCP that puts the data back in

the correct order or retransmits missing or damaged data during a

process called sequencing.

Acknowledgment number The value is the TCP octet that is expected

next.

Header length The number of 32-bit words in the TCP header, which

indicates where the data begins. The TCP header (even one including

options) is an integral number of 32 bits in length.

Reserved Always set to zero.

Code bits/flags Controls functions used to set up and terminate a

session.

Window The window size the sender is willing to accept, in octets.

Checksum The cyclic redundancy check (CRC), used because TCP

doesn’t trust the lower layers and checks everything. The CRC checks the

header and data fields.

Urgent A valid field only if the Urgent pointer in the code bits is set. If

so, this value indicates the offset from the current sequence number, in

octets, where the segment of non-urgent data begins.

Options May be 0, meaning that no options have to be present, or a

multiple of 32 bits. However, if any options are used that do not cause the

option field to total a multiple of 32 bits, padding of 0s must be used to

make sure the data begins on a 32-bit boundary. These boundaries are

known as words.

Data Handed down to the TCP protocol at the Transport layer, which

includes the upper-layer headers.

Let’s take a look at a TCP segment copied from a network analyzer:

TCP - Transport Control Protocol

Source Port: 5973

Destination Port: 23

Sequence Number: 1456389907

Ack Number: 1242056456

Offset: 5

Reserved: %000000

Code: %011000

Ack is valid

Push Request

Window: 61320

Checksum: 0x61a6

Urgent Pointer: 0

No TCP Options

TCP Data Area:

vL.5.+.5.+.5.+.5 76 4c 19 35 11 2b 19 35 11 2b 19 35 11

2b 19 35 +. 11 2b 19

Frame Check Sequence: 0x0d00000f

Did you notice that everything I talked about earlier is in the segment? As

you can see from the number of fields in the header, TCP creates a lot of

overhead. Again, this is why application developers may opt for efficiency

over reliability to save overhead and go with UDP instead. It’s also

defined at the Transport layer as an alternative to TCP.

User Datagram Protocol (UDP)

User Datagram Protocol (UDP) is basically the scaled-down economy

model of TCP, which is why UDP is sometimes referred to as a thin

protocol. Like a thin person on a park bench, a thin protocol doesn’t take

up a lot of room—or in this case, require much bandwidth on a network.

UDP doesn’t offer all the bells and whistles of TCP either, but it does do a

fabulous job of transporting information that doesn’t require reliable

delivery, using far less network resources. (UDP is covered thoroughly in

Request for Comments 768.)

So clearly, there are times that it’s wise for developers to opt for UDP

rather than TCP, one of them being when reliability is already taken care

of at the Process/Application layer. Network File System (NFS) handles

its own reliability issues, making the use of TCP both impractical and

redundant. But ultimately, it’s up to the application developer to opt for

using UDP or TCP, not the user who wants to transfer data faster!

UDP does not sequence the segments and does not care about the order

in which the segments arrive at the destination. UDP just sends the

segments off and forgets about them. It doesn’t follow through, check up

on them, or even allow for an acknowledgment of safe arrival—complete

abandonment. Because of this, it’s referred to as an unreliable protocol.

This does not mean that UDP is ineffective, only that it doesn’t deal with

reliability issues at all.

Furthermore, UDP doesn’t create a virtual circuit, nor does it contact the

destination before delivering information to it. Because of this, it’s also

considered a connectionless protocol. Since UDP assumes that the

application will use its own reliability method, it doesn’t use any itself.

This presents an application developer with a choice when running the

Internet Protocol stack: TCP for reliability or UDP for faster transfers.

It’s important to know how this process works because if the segments

arrive out of order, which is commonplace in IP networks, they’ll simply

be passed up to the next layer in whatever order they were received. This

can result in some seriously garbled data! On the other hand, TCP

sequences the segments so they get put back together in exactly the right

order, which is something UDP just can’t do.

UDP Segment Format

Figure 3.13

clearly illustrates UDP’s markedly lean overhead as compared

to TCP’s hungry requirements. Look at the figure carefully—can you see

that UDP doesn’t use windowing or provide for acknowledgments in the

UDP header?

FIGURE 3.13

UDP segment

It’s important for you to understand what each field in the UDP segment

is:

Source port Port number of the application on the host sending the

data

Destination port Port number of the application requested on the

destination host

Length Length of UDP header and UDP data

Checksum Checksum of both the UDP header and UDP data fields

Data Upper-layer data

UDP, like TCP, doesn’t trust the lower layers and runs its own CRC.

Remember that the Frame Check Sequence (FCS) is the field that houses

the CRC, which is why you can see the FCS information.

The following shows a UDP segment caught on a network analyzer:

UDP - User Datagram Protocol

Source Port: 1085

Destination Port: 5136

Length: 41

Checksum: 0x7a3c

UDP Data Area:

..Z......00 01 5a 96 00 01 00 00 00 00 00 11 0000 00

...C..2._C._C 2e 03 00 43 02 1e 32 0a 00 0a 00 80 43 00 80

Frame Check Sequence: 0x00000000

Notice that low overhead! Try to find the sequence number, ack number,

and window size in the UDP segment. You can’t because they just aren’t

there!

Key Concepts of Host-to-Host Protocols

Since you’ve now seen both a connection-oriented (TCP) and

connectionless (UDP) protocol in action, it’s a good time to summarize

the two here.

Table 3.1

highlights some of the key concepts about these

two protocols for you to memorize.

TABLE 3.1

Key features of TCP and UDP

>TCP

>UDP

Sequenced

Unsequenced

Reliable

Unreliable

Connection-oriented

Connectionless

Virtual circuit

Low overhead

Acknowledgments

No acknowledgment

Windowing flow control No windowing or flow control of any type

And if all this isn’t quite clear yet, a telephone analogy will really help you

understand how TCP works. Most of us know that before you speak to

someone on a phone, you must first establish a connection with that

other person no matter where they are. This is akin to establishing a

virtual circuit with the TCP protocol. If you were giving someone

important information during your conversation, you might say things

like, “You know? or “Did you get that?” Saying things like this is a lot like

a TCP acknowledgment—it’s designed to get you verification. From time

to time, especially on mobile phones, people ask, “Are you still there?”

People end their conversations with a “Goodbye” of some kind, putting

closure on the phone call, which you can think of as tearing down the

virtual circuit that was created for your communication session. TCP

performs these types of functions.

Conversely, using UDP is more like sending a postcard. To do that, you

don’t need to contact the other party first, you simply write your message,

address the postcard, and send it off. This is analogous to UDP’s

connectionless orientation. Since the message on the postcard is probably

not a matter of life or death, you don’t need an acknowledgment of its

receipt. Similarly, UDP does not involve acknowledgments.

Let’s take a look at another figure, one that includes TCP, UDP, and the

applications associated to each protocol:

Figure 3.14

(discussed in the

next section).

FIGURE 3.14

Port numbers for TCP and UDP

Port Numbers

TCP and UDP must use port numbers to communicate with the upper

layers because these are what keep track of different conversations

crossing the network simultaneously. Originating-source port numbers

are dynamically assigned by the source host and will equal some number

starting at 1024. Port number 1023 and below are defined in RFC 3232

(or just see

www.iana.org

), which discusses what we call well-known port

numbers.

Virtual circuits that don’t use an application with a well-known port

number are assigned port numbers randomly from a specific range

instead. These port numbers identify the source and destination

application or process in the TCP segment.

The Requests for Comments (RFCs) form a series of notes

about the Internet (originally the ARPAnet) started in 1969. These

notes discuss many aspects of computer communication, focusing on

networking protocols, procedures, programs, and concepts, but they

also include meeting notes, opinions, and sometimes even humor.

You can find the RFCs by visiting

www.iana.org

.

Figure 3.14

illustrates how both TCP and UDP use port numbers. I’ll

cover the different port numbers that can be used next:

Numbers below 1024 are considered well-known port numbers and

are defined in RFC 3232.

Numbers 1024 and above are used by the upper layers to set up

sessions with other hosts and by TCP and UDP to use as source and

destination addresses in the segment.

TCP Session: Source Port

Let’s take a minute to check out analyzer output showing a TCP session I

captured with my analyzer software session now:

TCP - Transport Control Protocol

Source Port: 5973

Destination Port: 23

Sequence Number: 1456389907

Ack Number: 1242056456

Offset: 5

Reserved: %000000

Code: %011000

Ack is valid

Push Request

Window: 61320

Checksum: 0x61a6

Urgent Pointer: 0

No TCP Options

TCP Data Area:

vL.5.+.5.+.5.+.5 76 4c 19 35 11 2b 19 35 11 2b 19 35 11

2b 19 35 +. 11 2b 19

Frame Check Sequence: 0x0d00000f

Notice that the source host makes up the source port, which in this case is

5973. The destination port is 23, which is used to tell the receiving host

the purpose of the intended connection (Telnet).

By looking at this session, you can see that the source host makes up the

source port by using numbers from 1024 to 65535. But why does the

source make up a port number? To differentiate between sessions with

different hosts because how would a server know where information is

coming from if it didn’t have a different number from a sending host?

TCP and the upper layers don’t use hardware and logical addresses to

understand the sending host’s address as the Data Link and Network

layer protocols do. Instead, they use port numbers.

TCP Session: Destination Port

You’ll sometimes look at an analyzer and see that only the source port is

above 1024 and the destination port is a well-known port, as shown in the

following trace:

TCP - Transport Control Protocol

Source Port: 1144

Destination Port: 80 World Wide Web HTTP

Sequence Number: 9356570

Ack Number: 0

Offset: 7

Reserved: %000000

Code: %000010

Synch Sequence

Window: 8192

Checksum: 0x57E7

Urgent Pointer: 0

TCP Options:

Option Type: 2 Maximum Segment Size

Length: 4

MSS: 536

Option Type: 1 No Operation

Option Type: 1 No Operation

Option Type: 4

Length: 2

Opt Value:

No More HTTP Data

Frame Check Sequence: 0x43697363

And sure enough, the source port is over 1024, but the destination port is

80, indicating an HTTP service. The server, or receiving host, will change

the destination port if it needs to.

In the preceding trace, a “SYN” packet is sent to the destination device.

This Synch (as shown in the output) sequence is what’s used to inform

the remote destination device that it wants to create a session.

TCP Session: Syn Packet Acknowledgment

The next trace shows an acknowledgment to the SYN packet:

TCP - Transport Control Protocol

Source Port: 80 World Wide Web HTTP

Destination Port: 1144

Sequence Number: 2873580788

Ack Number: 9356571

Offset: 6

Reserved: %000000

Code: %010010

Ack is valid

Synch Sequence

Window: 8576

Checksum: 0x5F85

Urgent Pointer: 0

TCP Options:

Option Type: 2 Maximum Segment Size

Length: 4

MSS: 1460

No More HTTP Data

Frame Check Sequence: 0x6E203132

Notice the

Ack is valid

, which means that the source port was accepted

and the device agreed to create a virtual circuit with the originating host.

And here again, you can see that the response from the server shows that

the source is 80 and the destination is the 1144 sent from the originating

host—all’s well!

Table 3.2

gives you a list of the typical applications used in the TCP/IP

suite by showing their well-known port numbers and the Transport layer

protocols used by each application or process. It’s really key to memorize

this table.

Table 3.2

Key protocols that use TCP and UDP

>TCP

>UDP

Telnet 23

SNMP 161

SMTP 25

TFTP 69

HTTP 80

DNS 53

FTP 20, 21 BooTPS/DHCP 67

DNS 53

HTTPS 443 NTP 123

SSH 22

POP3 110

IMAP4 143

Notice that DNS uses both TCP and UDP. Whether it opts for one or the

other depends on what it’s trying to do. Even though it’s not the only

application that can use both protocols, it’s certainly one that you should

make sure to remember in your studies.

What makes TCP reliable is sequencing, acknowledgments,

and flow control (windowing). UDP does not have reliability.

Okay—I want to discuss one more item before we move down to the

Internet layer—session multiplexing. Session multiplexing is used by both

TCP and UDP and basically allows a single computer, with a single IP

address, to have multiple sessions occurring simultaneously. Say you go

to

www.lammle.com

and are browsing and then you click a link to

another page. Doing this opens another session to your host. Now you go

to

www.lammle.com/forum

from another window and that site opens a

window as well. Now you have three sessions open using one IP address

because the Session layer is sorting the separate requests based on the

Transport layer port number. This is the job of the Session layer: to keep

application layer data separate!