Charles M. Kozierok The TCP-IP Guide

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

IP CIDR Addressing Example

The multiple hierarchical levels of CIDR make the technology seem rather complicated.

However, understanding how CIDR works really is not that difficult, assuming you already

know how subnetting is done. In particular, if you know how VLSM functions, you basically

already know how CIDR does, since they are pretty much the same thing. They differ only

in the way that the hierarchical division of networks is accomplished, and the terminology.

To show how CIDR works better, let's take an example that will illustrate the power of

classless addressing: its ability to selectively subdivide a large block of addresses into

smaller ones that suit the needs of various organizations. Since address allocation in CIDR

typically starts with larger blocks owned by larger Internet Service Providers (ISPs), let's

start there as well.

Suppose we have an ISP that is just starting up. It's not a “major” ISP, but a moderate-sized

one with only a few customers, so it needs only a relatively small allocation. It begins with

the block 71.94.0.0/15. The “/15” on the end of the block address tells us that this is a block

of addresses where the first 15 bits are the network ID and the last 17 the host ID. Of

course, this block was obtained from a larger ISP, carved from a larger block of addresses

by that ISP. For example, 71.94.0.0/15 would be equal to half of the address block

71.92.0.0/14, a quarter of the block 71.88.0.0/13, and so on.

19 13 8,190 /19 255.255.224.0 — 1/8 32

20 12 4,094 /20 255.255.240.0 — 1/16 16

21 11 2,046 /21 255.255.248.0 — 1/32 8

22 10 1,022 /22 255.255.252.0 — 1/64 4

23 9 510 /23 255.255.254.0 — 1/128 2

24 8 254 /24 255.255.255.0 — 1/256 1

25 7 126 /25 255.255.255.128 — — 1/2

26 6 62 /26 255.255.255.192 — — 1/4

27 5 30 /27 255.255.255.224 — — 1/8

28 4 14 /28 255.255.255.240 — — 1/16

29 3 6 /29 255.255.255.248 — — 1/32

30 2 2 /30 255.255.255.252 — — 1/64

Table 56: CIDR Address Blocks and “Classful” Address Equivalents (Page 2 of 2)

# of Bits

For

Network

# of Bits

For Host

# of Hosts Per

Network

Prefix

Length

in Slash

Notation

Equivalent

Subnet Mask

# of Equivalent

“Classful” Addressing

Networks

Class

Our ISP's block is equal in size to two Class Bs and has a total of 131,070 possible host

addresses. This ISP can choose to divide this block in a variety of ways, depending on the

needs of its clients and its own internal use. However, this ISP is just starting up, so it is not

even sure of what its ultimate needs will be. Let's say it expects to resell about half of its

address space to other ISPs, but isn't sure what sizes they will need yet. Of the other half, it

plans to split it into four different sizes of blocks to match the needs of different-sized

organizations.

To imagine how the ISP divides its address space, we can consider the analogy of cutting

up a pie. The ISP will first “cut the pie in half” and reserve one half for its future ISP

customers. It will then cut the other half into some large pieces and some small pieces. This

is illustrated in Figure 83. (Okay, it’s a square pie. I wanted to show the individual small

blocks to scale. Sue me. ☺)

The actual process of division might follow this progression (illustrated in Figure 84).:

Figure 83: Example Hierarchical Division Of A /15 CIDR Address Block

This diagram shows one method by which an ISP with a relatively large /15 address block (131,070 hosts)

might choose to hierarchically divide it. In this case it is first divided in half into two /16 blocks. One is

reserved, while the other is divided into four /18 blocks. Each of those is divided into blocks of a different size,

to allow allocation to organizations requiring up to 62, 126, 254 or 510 hosts respectively.

Subnetwork #0

71.94.0.0/16

65,534 Hosts

Sub-Subnetwork #1-0, 71.95.0.0/18

16,382 Hosts, Divided Into

32 /23 Blocks of 510 Hosts Each

Sub-Subnetwork #1-1, 71.95.64.0/18

16,382 Hosts, Divided Into

64 /24 Blocks of 254 Hosts Each

Sub-Subnetwork #1-2, 71.95.128.0/18

16,382 Hosts, Divided Into

128 /25 Blocks of 126 Hosts Each

Sub-Subnetwork #1-3, 71.95.192.0/18

16,382 Hosts, Divided Into

256 /26 Blocks of 62 Hosts Each

Full Network

71.94.0.0/15

131,070 Hosts

Figure 84: Hierarchical Address Division Using Classless Addressing (CIDR)

71 0 1 0 1 1 1 1

Host ID

(17 bits, 131,070 Hosts)

Full Network

71.94.0.0/15

First Division: Split 71.94.0.0/15 into Two /16 Subnetworks

Second Division: Split Subnetwork #1 (71.95.0.0/16)

into Four /18 Sub-Subnetworks

71 0 1 0 1 1 1 1

65,534 Hosts

71 0 1 0 1 1 1 1

65,534 Hosts

71 0 1 0 1 1 1 1

1 0 0

16,382 Hosts

71 0 1 0 1 1 1 1

1 0 1

16,382 Hosts

71 0 1 0 1 1 1 1

1 1 0

16,382 Hosts

71 0 1 0 1 1 1 1

1 1 1

16,382 Hosts

71 0 1 0 1 1 1 1

1 0 0 0 0 0 0 0

510 Hosts

71 0 1 0 1 1 1 1

1 0 1 1 1 1 1 1 1

254 Hosts

71 0 1 0 1 1 1 1

1 1 0 1 1 1 1 1 1 1

126 Hosts

71 0 1 0 1 1 1 1

1 1 1 0 0 0 0 0 0 0 0

62 Hosts

71 0 1 0 1 1 1 1

1 0 0 1 1 1 1 1

510 Hosts

...

71 0 1 0 1 1 1 1

1 0 1 0 0 0 0 0 0

254 Hosts

71 0 1 0 1 1 1 1

1 1 0 0 0 0 0 0 0 0

126 Hosts

71 0 1 0 1 1 1 1

1 1 1 1 1 1 1 1 1 1 1

62 Hosts

Sub-Sub-

Subnet #1-0-0

71.95.0.0/23

Third Division: Split Sub-Subnetwork #1-0 (71.95.0.0/18)

Into 32 /23 Sub-Sub-Subnetworks

Sub-Sub-

Subnet #1-0-31

71.95.62.0/23

Third Division: Split Sub-Subnetwork #1-1 (71.95.64.0/18)

Into 64 /24 Sub-Sub-Subnetworks

...

Third Division: Split Sub-Subnetwork #1-2 (71.95.128.0/18)

Into 128 /25 Sub-Sub-Subnetworks

...

Third Division: Split Sub-Subnetwork #1-3 (71.95.192.0/18)

Into 256 /26 Sub-Sub-Subnetworks

...

Subnetwork #0

71.94.0.0/16

Subnetwork #1

71.95.0.0/16

Sub-Subnet #1-0

71.95.0.0/18

Sub-Subnet #1-1

71.95.64.0/18

Sub-Subnet #1-2

71.95.128.0/18

Sub-Subnet #1-3

71.95.192.0/18

Sub-Sub-

Subnet #1-1-0

71.95.64.0/24

Sub-Sub-

Subnet #1-1-63

71.95.64.0/24

Sub-Sub-

Subnet #1-2-0

71.95.128.0/25

Sub-Sub-

Subnet #1-2-127

71.95.191.128/25

Sub-Sub-

Subnet #1-3-0

71.95.192.0/25

Sub-Sub-

Subnet #1-3-255

71.95.255.192/25

... ... ... ...

First Level of Division

The “pie” is initially cut down the middle by using the single left-most host ID bit as an extra

network bit. Let's see our network address block, 71.94.0.0/15 in binary, with the left-most

host ID bit shown highlighted:

01000111 01011110 00000000 00000000

To make the split, we make one network equal to this binary network address with the

highlighted bit remaining zero, and the other one with it changed to a one. This creates two

subnetworks—not subnets as in the “classful” sense of the word, but portions of the original

network—which I have numbered based on the numeric value of what is substituted into the

new network ID bits:

Subnetwork #0: 01000111 01011110 00000000 00000000

Subnetwork #1: 01000111 01011111 00000000 00000000

Since bit #16 is now also part of the network address, these are “/16” networks, the size of

a “classful” Class B network. So, the subnetworks are:

Subnetwork #0: 71.94.0.0/16

Subnetwork #1: 71.95.0.0/16

You’ll notice that the “#0” subnetwork has the same IP address as the larger network it

came from; this is always true of the subnetwork 0 in a network.

Second Level of Division

Let's say we set aside subnetwork #0 above for future ISP allocations. We then choose to

divide the second subnetwork, into four. These we will then further subdivide into different

sizes to meet our customer needs. To divide into four groups we need two more bits from

the host ID of subnetwork #1, shown highlighted and underlined next to the original subnet

bit:

01000111 01011111 00

000000 00000000

These two bits are replaced by the patterns 00, 01, 10 and 11 to get four sub-subnetworks.

They will be “/18” networks of course, since we took two extra bits from the host ID of a “/

16”:

Sub-subnetwork #1-0: 01000111 01011111 00000000 00000000

(71.95.0.0/18)

Sub-subnetwork #1-1: 01000111 01011111 01000000 00000000

(71.95.64.0/18)

Sub-subnetwork #1-2: 01000111 01011111 10

000000 00000000

(71.95.128.0/18)

Sub-subnetwork #1-3: 01000111 01011111 11

000000 00000000

(71.95.192.0/18)

Each of these has 16,382 addresses.

Third Level of Division

We now take each of the four /18 networks above and further subdivide it. We want to make

each of these contain a number of blocks of different sizes corresponding to our potential

customers. One way to do this would be as follows:

☯ Larger Organizations: Customers needing up to 510 addresses require a /23

network. We divide sub-subnetwork #1-0, 71.95.0.0/18 by taking five bits from the host

ID field:

01000111 01011111 00000000 00000000

We substitute into these five bits 00000, 00001, 00010 and so on, giving us 32

different /23 networks in this block, each containing 9 bits for the host ID, for 510 hosts.

The first will be sub-sub-subnetwork #1-0-0, 71.95.0.0/23; the second sub-sub-

subnetwork #1-0-1, 71.95.2.0/23; the last will be sub-sub-subnetwork #1-0-31:

71.95.62.0/23.

☯ Medium-Sized Organizations: For customers needing up to 254 addresses, we

divide sub-subnetwork #1-1, 71.95.64.0/18, by taking six bits from the host ID field:

01000111 01011111 01

000000 00000000

This gives us 64 different /24 networks. The first will be sub-sub-subnetwork #1-1-0,

71.95.64.0/24, the second sub-sub-subnetwork #1-1-1, 71.95.65.0/24, and so on.

☯ Smaller Organizations: For customers with up to 126 hosts, we divide sub-

subnetwork #1-2, 71.95.128.0/18, by taking seven bits from the host ID field:

01000111 01011111 10000000 00000000

Seven bits allow 128 of these /25 networks within our /18 block. The first will be

71.95.128.0/25, the second 71.95.128.128/25, the third 71.95.129.0/25, and so on.

☯ Very Small Organizations: For customers with up to 60 hosts, we divide sub-

subnetwork #1-3, 71.95.192.0/18, by taking eight bits from the host ID field:

01000111 01011111 11000000 00000000

This gives us 256 different /26 networks within our /18 block. The first will be

71.95.192.0/26, the second 71.95.192.64/26, and so on.

Other Alternatives for Dividing the Network

Above all else, CIDR is about flexibility—this is only one of many different ways to slice up

this pie (sheet of brownies, whatever!) The ISP might decide that creating four different

sizes of customer networks in advance was not the right way to go. They might instead just

take the tack of dividing the pie in half, dividing it in half again, and so on, as many times as

needed to create “pie slices” of the right size. Alternately, if most of their customers need

around 50, 100, 200 or 500 hosts, the example above might be the easiest to administer.

It would still be possible for the ISP to further divide any of the smaller blocks further if they

needed. They could split a /26 sub-sub-subnetwork into four /28 sub-sub-sub-subnetworks

for very small customers, for example. Also, an individual customer of this ISP could do the

same thing, dividing their own block to suit the internal structure of their network.

IP Datagram Encapsulation and Formatting

The primary job of the Internet Protocol is the delivery of data between devices over an

internetwork. On its journey between two hosts in an internet, this data may travel across

many physical networks. To help ensure that the data is sent and received properly, it is

encapsulated within a message called an IP datagram. This datagram includes several

fields that help manage the operation of IP and ensure that data gets where it needs to go.

In this section I take a look at how the Internet Protocol takes data passed to it from higher

layers and packages it for transmission. I begin with a general discussion of IP datagrams

and encapsulation. I then describe the general format of IP datagrams, including the fields

used in the IP header and how they are interpreted. I also include a brief discussion of IP

datagram options and their use.

Background Information: this section assumes at least passing familiarity with IP

addressing concepts. It also makes reference to the section on datagram fragmen-

tation and reassembly.

Note: IP datagrams are sometimes called IP packets. Whether “datagram” or

“packet” is the preferred term seems to depend on whom you ask; even the

standards don’t use one term exclusively. On the other hand, I have seen IP

datagrams called IP frames, and that’s definitely not correct! The topic on messages and

names in the fundamentals chapter describes these terms more completely.

IP Datagram Encapsulation

In the chapter describing the OSI Reference Model, I looked at several ways that protocols

at various layers in a networking protocol stack interact with each other. One of the most

important concepts in inter-protocol operation is that of encapsulation. Most data originates

within the higher layers of the OSI model. The protocols at these layers pass the data down

to lower layers for transmission, usually in the form of discrete messages. Upon receipt,

each lower-level protocol takes the entire contents of the message received and encapsu-

lates it into its own message format, adding a header and possibly a footer that contain

important control information. Encapsulation is explained in general terms in a separate

topic.

A good analogy for how encapsulation works is a comparison to sending a letter enclosed

in an envelope. You might write a letter and put it in a white envelope with a name and

address, but if you gave it to a courier for overnight delivery, they would take that envelope

and put it in a larger delivery envelope. (I actually have written a complete description of this

sort of analogy, if you are interested.)

Due to the prominence of TCP/IP, the Internet Protocol is one of the most important places

where data encapsulation occurs on a modern network. Data is passed to IP typically from

one of the two main transport layer protocols: TCP or UDP. This data is already in the form

of a TCP or UDP message with TCP or UDP headers. This is then encapsulated into the

body of an IP message, usually called an IP datagram or IP packet. Encapsulation and

formatting of an IP datagram is also sometimes called packaging—again, the implied

comparison to an envelope is obvious. The process is shown in Figure 85.

Figure 85: IP Datagram Encapsulation

This is an adaptation of Figure 15, the very similar drawing for the OSI Reference Model as a whole, showing

specifically how data encapsulation is accomplished in TCP/IP. As you can see, an upper layer message is

packaged into a TCP or UDP message. This then becomes the payload of an IP datagram, which is shown

here simply with one header (things can get a bit more complex than this.) The IP datagram is then passed

down to layer 2 where it is in turn encapsulated into some sort of LAN, WAN or WLAN frame, then converted

to bits and transmitted at the physical layer.

Layer

TCP /

UDP

Upper

Layers

Upper

Layers

Upper Layer Message

TCP/UDP Message

IP Datagram

Layer 2 Frame

Layer

1 011011001001 011

Layer 2

Header

TCP/UDP

Header

Upper

Layer

Headers

Upper Layer

(Application) Data

Layer 2

Footer

Header

TCP/UDP

Header

Upper

Layer

Headers

Upper Layer

(Application) Data

TCP/UDP

Header

Upper

Layer

Headers

Upper Layer

(Application) Data

Upper

Layer

Headers

Upper Layer

(Application) Data

Layer

TCP /

UDP

If the message to be transmitted is too large for the size of the underlying network, it may

first be fragmented. This is analogous to splitting up a large delivery into multiple smaller

envelopes or boxes. In this case, each IP datagram carries only part of the higher-layer

message. The receiving device must reassemble the message from the IP datagrams. So,

a datagram doesn't always carry a full higher-layer message; it may hold only part of one.

The IP datagram is somewhat similar in concept to a frame used in Ethernet or another data

link layer. The important difference, of course, is that IP datagrams are designed to facilitate

transmission across an internetwork, while data link layer frames are used only for direct

delivery within a physical network. The fields included in the IP header are used to manage

internetwork datagram delivery. This includes key information for delivery such as the

address of the destination device, identification of the type of frame, and control bits. The

header follows a specific format described in the following topic.

After data is encapsulated into an IP datagram, it is passed down to the data link layer for

transmission across the current “hop” of the internetwork. There, it is of course further

encapsulated, IP header and all, into a data link layer frame such as an Ethernet frame. An

IP datagram may be encapsulated into many such data link layer frames as it is routed

across the internetwork; on each hop the IP datagram is removed from the data link layer

frame and then repackaged into a new one for the next hop. The IP datagram, however, is

not changed (except for some control fields) until it reaches its final destination.

IP Datagram General Format

Data transmitted over an internet using IP is carried in messages called IP datagrams. Like

all network protocol messages, IP uses a specific format for its datagrams. We are of

course looking here at IP version 4 and so we will examine the IPv4 datagram format, which

was defined in RFC 791 along with the rest of IPv4.

The IPv4 datagram is conceptually divided into two pieces: the header and the payload.

The header contains addressing and control fields, while the payload carries the actual data

to be sent over the internetwork. Unlike some message formats, IP datagrams do not have

a footer following the payload.

Even though IP is a relatively simple, connectionless, “unreliable” protocol, the IPv4 header

carries a fair bit of information, which makes it rather large. At a minimum, it is 20 bytes

long, and with options can be significantly longer. The IP datagram format is described in

Table 57 and illustrated in Figure 86.

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

Field Name

Size

(bytes)

Description

Version

1/2

(4 bits)

Version: Identifies the version of IP used to generate the datagram. For

IPv4, this is of course the number 4. The purpose of this field is to ensure

compatibility between devices that may be running different versions of IP.

In general, a device running an older version of IP will reject datagrams

created by newer implementations, under the assumption that the older

version may not be able to interpret the newer datagram correctly.

IHL

1/2

(4 bits)

Internet Header Length (IHL): Specifies the length of the IP header, in 32-

bit words. This includes the length of any options fields and padding. The

normal value of this field when no options are used is 5 (5 32-bit words =

5*4 = 20 bytes). Contrast to the longer Total Length field below.

TOS 1

Type Of Service (TOS): A field designed to carry information to provide

quality of service features, such as prioritized delivery, for IP datagrams. It

was never widely used as originally defined, and its meaning has been

subsequently redefined for use by a technique called Differentiated

Services (DS). See below for more information.

TL 2

Total Length (TL): Specifies the total length of the IP datagram, in bytes.

Since this field is 16 bits wide, the maximum length of an IP datagram is

65,535 bytes, though most are much smaller.

Identification 2

Identification: This field contains a 16-bit value that is common to each of

the fragments belonging to a particular message; for datagrams originally

sent unfragmented it is still filled in, so it can be used if the datagram must

be fragmented by a router during delivery. This field is used by the recipient

to reassemble messages without accidentally mixing fragments from

different messages. This is needed because fragments may arrive from

multiple messages mixed together, since IP datagrams can be received out

of order from any device. See the discussion of IP message fragmentation.

Flags

3/8

(3 bits)

ags:

ree con

ags,

wo o

are use

o manage

ragmen

(as described in the topic on fragmentation), and one that is reserved:

Subfield

Name

Size

(bytes)

Description

Reserved 1/8 (1 bit) Reserved: Not used.

DF 1/8 (1 bit)

Don't Fragment: When set to 1, specifies that the

datagram should not be fragmented. Since the

fragmentation process is generally “invisible” to

higher layers, most protocols don't care about this

and don't set this flag. It is, however, used for testing

the maximum transmission unit (MTU) of a link.

MF 1/8 (1 bit)

More Fragments: When set to 0, indicates the last

fragment in a message; when set to 1, indicates that

more fragments are yet to come in the fragmented

message. If no fragmentation is used for a message,

then of course there is only one “fragment” (the whole

message), and this flag is 0. If fragmentation is used,

all fragments but the last set this flag to 1 so the

recipient knows when all fragments have been sent.