Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

Fragment Offset

1 5/8

(13 bits)

Fragment Offset: When fragmentation of a message occurs, this field

specifies the offset, or position, in the overall message where the data in

this fragment goes. It is specified in units of 8 bytes (64 bits). The first

fragment has an offset of 0. Again, see the discussion of fragmentation for

a description of how the field is used.

TTL 1

Time To Live (TTL): Short version: Specifies how long the datagram is

allowed to “live” on the network, in terms of router hops. Each router decre-

ments the value of the TTL field (reduces it by one) prior to transmitting it. If

the TTL field drops to zero, the datagram is assumed to have taken too

long a route and is discarded.

See below for the longer explanation of TTL.

Protocol 1

Header

Checksum

Header Checksum: A checksum computed over the header to provide

basic protection against corruption in transmission. This is not the more

complex CRC code typically used by data link layer technologies such as

Ethernet; it's just a 16-bit checksum. It is calculated by dividing the header

bytes into words (a word is two bytes) and then adding them together. The

data is not checksummed, only the header. At each hop the device

receiving the datagram does the same checksum calculation and on a

mismatch, discards the datagram as damaged.

Table 57: Internet Protocol Version 4 (IPv4) Datagram Format (Page 2 of 3)

Field Name

Size

(bytes)

Description

oco

tifi

er-

ayer pro

oco

(

genera

y e

ith

er a

ranspor

layer protocol or encapsulated network layer protocol) carried in the

datagram. The values of this field were originally defined by the IETF

“Assigned Numbers” standard, RFC 1700, and are now maintained by the

Internet Assigned Numbers Authority (IANA):

Note that the last two entries are used when IPSec inserts additional

headers into the datagram: the AH or ESP headers.

Value

(Hexadecimal)

Value

(Decimal)

Protocol

00 0 Reserved

01 1 ICMP

02 2 IGMP

03 3 GGP

04 4 IP-in-IP Encapsulation

06 6 TCP

08 8 EGP

11 17 UDP

32 50

Encapsulating Security Payload (ESP)

Extension Header

33 51

Authentication Header (AH)

Extension Header

That’s a pretty big table, because the IP datagram format is pretty important and has a lot of

fields that need explaining. To keep it from being even longer, I decided to move a couple of

the more complex descriptions out of the table.

Time To Live (TTL) Field

Since IP datagrams are sent from router to router as they travel across an internetwork, it is

possible that a situation could result where a datagram gets passed from router A to router

B to router C and then back to router A. Router loops are not supposed to happen, and

rarely do, but are possible.

To ensure that datagrams don't circle around endlessly, the TTL field was intended to be

filled in with a time value (in seconds) when a datagram was originally sent. Routers would

decrease the time value periodically, and if it ever hit zero, the datagram would be

destroyed. This was also intended to be used to ensure that time-critical datagrams

wouldn’t linger past the point where they would be “stale”.

In practice, this field is not used in exactly this manner. Routers today are fast and usually

take far less than a second to forward a datagram; measuring the time that a datagram

“lives” would be impractical. Instead, this field is used as a “maximum hop count” for the

datagram. Each time a router processes a datagram, it reduces the value of the TTL field by

one. If doing this results in the field being zero, the datagram is said to have expired. It is

dropped, and usually an ICMP Time Exceeded message is sent to inform the originator of

the message that this happened.

Source Address 4

Source Address: The 32-bit IP address of the originator of the datagram.

Note that even though intermediate devices such as routers may handle

the datagram, they do not normally put their address into this field—it is

always the device that originally sent the datagram.

Destination

Address

Destination Address: The 32-bit IP address of the intended recipient of

the datagram. Again, even though devices such as routers may be the

intermediate targets of the datagram, this field is always for the ultimate

destination.

Options Variable

Options: One or more of several types of options may be included after

the standard headers in certain IP datagrams. I discuss them in the topic

that follows this one.

Padding Variable

Padding: If one or more options are included, and the number of bits used

for them is not a multiple of 32, enough zero bits are added to “pad out” the

header to a multiple of 32 bits (4 bytes).

Data Variable

Data: The data to be transmitted in the datagram, either an entire higher-

layer message or a fragment of one.

Table 57: Internet Protocol Version 4 (IPv4) Datagram Format (Page 3 of 3)

Field Name

Size

(bytes)

Description

The TTL field is one of the primary mechanisms by which networks are protected from

router loops (see the description of ICMP Time Exceeded messages for more on how TTL

helps IP handle router loops.)

Type Of Service (TOS) Field

This one-byte field was originally intended to provide certain quality of service features for

IP datagram delivery. It allowed IP datagrams to be tagged with information indicating not

only their precedence, but the preferred manner in which they should be delivered. It was

divided into a number of subfields, as shown in Table 58 (and Figure 86).

Figure 86: Internet Protocol Version 4 (IPv4) Datagram Format

This diagram shows graphically the all-important IPv4 datagram format. The first 20 bytes are the fixed IP

header, followed by an optional Options section, and a variable-length Data area. Note that the Type Of

Service field is shown as originally defined in the IPv4 standard.

Version

Internet Header

Length (IHL)

Type Of Service (TOS) Total Length (TL)

Flags Fragment Offset

Protocol Header Checksum

Data

4 8 12 16 20 24 28 320

Padding

480 30

Re-

served

Don't

Frag-

ment

(DF)

Mor e

Frag-

ments

(MF)

Precedence

Delay

Throu-

ghput

Reli-

ability

Reserved

Options

Destination Address

Source Address

Time To Live (TTL)

Identification

The lack of quality of service features has been considered a weakness of IP for a long

time. But as we can see in Table 58, these features were built into IP from the start. What's

going on here? The answer is that even though this field was defined in the standard back

in the early 1980s, it was not widely used by hardware and software. For years, it was just

passed around with all zeroes in the bits and mostly ignored.

The IETF, seeing the field unused, attempted to revive its use. In 1998, RFC 2474 redefines

the first six bits of the TOS field to support a technique called Differentiated Services (DS).

Under DS, the values in the TOS field are called codepoints and are associated with

different service levels. This starts to get rather complicated, so refer to RFC 2474 if you

want all the details.

Understanding the IP datagram format is an important part of troubleshooting IP networks.

Be sure to see the following topic on options for more information on how IP options are

used in datagrams, and the topic on fragmenting for some more context on the use of

fragmentation-related fields such as Identification, Fragment Offset, and More Fragments.

Table 58: Original Definition Of IPv4 Type Of Service (TOS) Field

Subfield Name

Size

(bytes)

Description

Precedence

3/8

(3 bits)

1/8

(1 bit)

Delay: Set to 0 to request “normal” delay in delivery; set to 1 if low delay

delivery is requested.

1/8

(1 bit)

Throughput: Set to 0 to request “normal” delivery throughput; set to 1 if

higher throughput delivery is requested.

1/8

(1 bit)

Reliability: Set to 0 to request “normal” reliability in delivery; set to 1 if

higher reliability delivery is requested.

Reserved

2/8

(2 bits)

Reserved: Not used.

rece

ence:

e pr

y o

agram.

ere were

eight defined values, from lowest to highest priority:

Precedence Value Priority Level

000 Routine

001 Priority

010 Immediate

011 Flash

100 Flash Override

101 CRITIC/ECP

110 Internetwork Control

111 Network Control

IP Datagram Options and Option Format

All IP datagrams must include the standard 20-byte header, which contains key information

such as the source and destination address of the datagram, fragmentation control param-

eters, length information and more. In addition to these invariable fields, the creators of

IPv4 included the ability to add options that provide additional flexibility in how IP handles

datagrams. Use of these options is, of course, optional. ☺ However, all devices that handle

IP datagrams must be capable of properly reading and handling them.

The IP datagram may contain zero, one or more options, which makes the total length of

the Options field in the IP header variable. Each of the options can be either a single byte

long, or multiple bytes in length, depending on how much information the option needs to

convey. When more than one option is included they are just concatenated together and put

into the Options field as a whole. Since the IP header must be a multiple of 32 bits, a

Padding field is included if the number of bits in all options together is not a multiple of 32

bits.

IP Option Format

Each IP option has its own subfield format, generally structured as shown in Table 59 and

Figure 87. For most options, all three subfields are used: Option Type, Option Length and

Option Data. For a few simple options, however, this complex substructure is not needed. In

those cases, the option type itself communicates all the information required, so the Option

Type field appears alone, while the Option Length and Option Data subfields are omitted.

Table 59: Internet Protocol Version 4 (IPv4) Option Format

Subfield Name

Size

(bytes)

Description

Option Type 1

Option Length 0 or 1

Option Length: For variable-length options, indicates the size of the entire

option, including all three subfields shown here, in bytes.

Option Data

0 or

Variable

Option Data: For variable-length options, contains data to be sent as part

of the option.

ype:

Thi

bit

ree

“

-su

bfi

”

, accor

to the following format:

Sub-Subfield

Name

Size

(bytes)

Description

Copied

1/8

1 bit)

Copied Flag: This bit is set to 1 if the option is

intended to be copied into all fragments when a

datagram is fragmented; it is cleared to 0 if the

option should not be copied into fragments.

Option Class

2/8

(2 bits)

Option Class: Specifies one of four potential

values that indicate the general category into

which the option belongs. In fact, only two of the

values are used: 0 is for Control options, and 2 for

Debugging and Measurement.

Option

Number

5/8

(5 bits)

Option Number: Specifies the kind of option. 32

different values can be specified for each of the

two option classes. Of these, a few are more

commonly employed. See below for more infor-

mation on the specific options.

IP Options

Table 60 lists the most common IPv4 options, showing the option class, option number and

length for each (a length of 1 indicating an option that consists of only an Option Type field),

and providing a brief description of how each is used.

Figure 87: Internet Protocol Version 4 (IPv4) Option Format

This diagram shows the full field format for an IPv4 option. Note that a few simple options may consist of only

the Option Type subfield, with the Option Length and Option Data subfields omitted.

Table 60: Internet Protocol Version 4 (IPv4) Options (Page 1 of 2)

Option

Class

Option

Number

Length

(bytes)

Option

Name

Description

001

End Of

Options List

An option containing just a single zero byte, used to

mark the end of a list of options.

0 1 1 No Operation

A “dummy option” used as “internal padding” to align

certain options on a 32-bit boundary when required.

0211 Security

An option provided for the military to indicate the

security classification of IP datagrams.

0 3 Variable

Loose Source

Route

One of two options for source routing of IP datagrams.

See below for an explanation.

4 8 12 16 20 24 28 320

Option Type

480

Option Length

Option Data

Cop-

ied

Option

Class

Option Number

Key Concept: Each IPv4 datagram has a 20-byte mandatory header, and may also

include one or more options. Each option has its own field format, and most are

variable in size.

IP Options and Source Routing

Normally, IP datagrams are routed without any specific instructions from devices regarding

the path a datagram should take from the source to the destination. It's the job of routers,

using routing protocols, to figure out those details. In some cases, however, it may be

advantageous to have the source of a datagram specify the route a datagram takes through

the network. This is called source routing.

There are two IP options that support source routing. In each, the option includes a list of IP

addresses specifying the routers that must be used, to reach the destination. When strict

source routing is used, this means that the path specified in the option must be used

07Variable Record Route

This option allows the route used by a datagram to be

recorded within the header for the datagram itself. If a

source device sends a datagram with this option in it,

each router that “handles” the datagram adds its IP

address to this option. The recipient can then extract

the list of IP addresses to see the route taken by the

datagram.

Note that the length of this option is set by the origi-

nating device. It cannot be enlarged as the datagram

is routed, and if it “fills up” before it arrives at its desti-

nation, only a partial route will be recorded.

0 9 Variable

Strict Source

Route

One of two options for source routing of IP datagrams.

See below for an explanation.

24Variable Timestamp

This option is similar to the Record Route option.

However, instead of each device that handles the

datagram inserting its IP address into the option, it

puts in a timestamp, so the recipient can see how long

it took for the datagram to travel between routers.

As with the Record Route option, the length of this

option is set by the originating device and cannot be

enlarged by intermediate devices.

2 18 12 Traceroute

Used in the enhanced implementation of the

traceroute utility, as described in RFC 1393. Also see

the topic on the ICMP Traceroute messages.

Table 60: Internet Protocol Version 4 (IPv4) Options (Page 2 of 2)

Option

Class

Option

Number

Length

(bytes)

Option

Name

Description

exactly, in sequence, with no other routers permitted to handle the datagram at all. In

contrast, loose source routing specifies a list of IP addresses that must be followed in

sequence, but having intervening hops in between the devices on the list is allowed.

For full details on the exact structure used by each option type, please refer to RFC 791.

IP Datagram Size, Maximum Transmission Unit (MTU), Fragmentation

and Reassembly

IP's main responsibility is to deliver data between internetworked devices. As we saw in the

preceding section, this requires that data received from higher layers be encapsulated into

IP datagrams for transmission. These datagrams are then passed down to the data link

layer where they are sent over physical network links.

In order for this to work properly, each datagram must be small enough to fit within the

frame format of the underlying technology. If the message is bigger than the maximum

frame size of the underlying network, it may be necessary to break up an IP message into

several datagrams, a process called fragmentation. The datagrams are then sent individ-

ually and reassembled into the original message.

The Internet Protocol is designed to manage datagram size, and to allow fragmentation and

reassembly in a seamless manner. In this section I explore issues related to managing the

size of IP datagrams. I start with an overview of datagram size issues and the important

concept of a network's maximum transmission unit (MTU), discussing why fragmentation is

necessary. I then describe the process by which IP messages to be transmitted are

fragmented by the source device and possibly routers along the path to the destination, and

then outline how they are reassembled by the recipient.

Background Information: Explaining fragmentation and reassembly requires

some understanding of the basic format of IP datagrams and some of the fields

they contain. If you haven't yet read the topic describing IP datagram general

format you may wish to review it before proceeding here.

IP Datagram Size, the Maximum Transmission Unit (MTU), and Fragmentation

Overview

As the core network layer protocol of the TCP/IP protocol suite, IP is designed to implement

potentially large internetworks of devices. When we work with IP we get used to the concept

of hosts being able to send information back and forth even though they may be quite far

away and the data may need to travel across many devices between them. Even though we

can usually consider the TCP/IP internet to be like a large, abstract “virtual network” of

devices, we must always remember that underneath the network layer, data always travels

across one or more physical networks. The implementation of the Internet Protocol must

take this reality into account as well.

In order to send messages using IP we encapsulate the higher-layer data into IP

datagrams. These datagrams must then be sent down to the data link layer, where they are

further encapsulated into the frames of whatever technology is going to be used to physi-

cally convey them, either directly to their destination, or indirectly to the next intermediate

step in their journey to their intended recipient. The data link layer implementation puts the

entire IP datagram into the data portion (the payload) of its frame format, just as IP puts