Charles M. Kozierok The TCP-IP Guide

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

TCP/IP Address Resolution For IP Multicast Addresses

Like most discussions of address resolution, the preceding sections all focus on unicast

communication, where a datagram is sent from one source device to one destination

device. Whether direct mapping or dynamic resolution is used for resolving a network layer

address, it is a relatively simple matter to resolve addresses when there is only one

intended recipient of the datagram. TCP/IP uses ARP for its dynamic resolution scheme,

which is designed for unicast resolution only.

However, the Internet Protocol also supports multicasting of datagrams, as I explain in the

topics on IP multicasting and IP multicast addressing. In this situation, the datagram must

be sent to multiple recipients, which complicates matters considerably. We need to

establish a relationship of some sort between the IP multicast group address and the

addresses of the devices at the data link layer. We could do this by converting the IP

multicast datagram to individual unicast transmissions at the data link layer, each using

ARP for resolution, but this would be horribly inefficient.

Direct Mapping Technique for IEEE 802 Multicast MAC Addresses

When possible, IP makes use of the multicast addressing and delivery capabilities of the

underlying network to deliver multicast datagrams on a physical network. Perhaps surpris-

ingly, even though ARP employs dynamic resolution, multicast address resolution is done

using a version of the direct mapping technique. By defining a mapping between IP

multicast groups and data link layer multicast groups we enable physical devices to know

when to pay attention to multicasted datagrams.

The most commonly used multicast-capable data link addressing scheme is the IEEE 802

addressing system best known for it use in Ethernet networks. These data link layer

addresses have 48 bits, arranged into two blocks of 24. The upper 24 bits are arranged into

a block called the organizationally unique identifier (OUI), with different values assigned to

individual organizations; the lower 24 bits are then used for specific devices.

The Internet Assigned Number Authority (IANA) itself has an OUI that it uses for mapping

multicast addresses to IEEE 802 addresses. This OUI is "01:00:5E". To form a mapping for

Ethernet, 24 bits are used for this OUI and the 25th (of the 48) is always zero. This leaves

23 bits of the original 48 to encode the multicast address. To do the mapping, the lower-

order 23 bits of the multicast address are used as the last 23 bits of the Ethernet address

starting with "01:00:5E" for sending the multicast message. This process is illustrated in

Figure 51.

Key Concept: IP multicast addresses are resolved to IEEE 802 (Ethernet) MAC

addresses using a direct mapping technique that uses 23 of the 28 bits in the IP

multicast group address.

Dealing With Multiple IP Addresses Mapped To One Multicast Hardware Address

Of course, there are 28 unique bits in IP multicast addresses, so this is a “bit” of a problem.

☺ What it means is that there is no unique mapping between IP multicast addresses and

Ethernet multicast addresses. Since 5 of the 28 bits of the multicast group cannot be

encoded in the Ethernet address, 32 (2

) different IP multicast addresses map onto each

possible Ethernet multicast address. In theory, this would be a problem, but in practice, it

isn't. The chances of any two IP multicast addresses on a single network mapping to the

same Ethernet multicast address at the same time are pretty small.

Still, it is possible that two IP multicast groups might be in use on the same physical network

and might map to the same data link layer multicast address. For this reason, devices must

not assume that all multicast messages they receive are for their groups; they must pass up

the messages to the IP layer to check the full IP multicast address to make sure they really

were supposed to get the multicast datagram they received. If they accidentally get one that

was intended for a multicast group they are not a member of, they discard it. This happens

infrequently so the relative lack of efficiency is not a large concern.

Figure 51: Mapping of Multicast IP Addresses to IEEE 802 Multicast MAC Addresses

IP multicast addresses consist of the bit string “1110” followed by a 28-bit multicast group address. To create a

48-bit multicast IEEE 802 (Ethernet) address, the top 24 bits are filled in with the IANA’s multicast OUI, 01-00-

5E, the 25th bit is zero, and the bottom 23 bits of the multicast group are put into the bottom 23 bits of the

MAC address. This leaves 5 bits (shown in pink) that are not mapped to the MAC address, meaning that 32

different IP addresses may have the same mapped multicast MAC address.

Hexadecimal

Binary

48-bit Multicast-Mapped Hardware Address

(01-00-5E-4D-62-B1)

32-bit Multicast IP Address

(231.205.98.177)

Decimal

Binary

01 00 5E

00000001 00000000 01011110

231 205 98 177

1110 0111 01100010 10110001

11 00 1101

24-bit IANA Multicast OUI

(01-00-5E)

01 00 5E

4D 62 B1

00000001 00000000 10010100

01001101

01100010 10110001

8 1624320 40 48

TCP/IP Address Resolution For IP Version 6

The TCP/IP Address Resolution Protocol (ARP) is a fairly generic protocol for dynamically

resolving network layer addresses into data link layer addresses. Even though it was

designed for IP version 4, the message format allows for variable-length addresses at both

the hardware and network layers. This flexibility means it would have been theoretically

possible to use it for the new version of IP—version 6, or IPv6—that is in our future. Some

minor changes might have been required, but the technique could have been about the

same.

The designers of IPv6 chose not to do this, however. Changing IP is a big job that has been

underway for many years, and represents a rare opportunity to change various aspects of

TCP/IP. The IETF decided to take advantage of the changes in IPv6 to overhaul not only IP

itself, but also many of the protocols that “support” or “assist” IP. In IPv6, the address

resolution job of ARP has been combined with several functions performed by ICMP in the

original TCP/IP suite, supplemented with additional capabilities and defined as the new

Neighbor Discovery (ND) protocol.

The term “neighbor” in IPv6 simply refers to devices on a local network, and as the name

implies, ND is responsible for tasks related to communicating information between

neighbors (among other things). I describe ND briefly in its own section, including a

discussion of the various tasks it performs. Here I want to focus specifically on how ND

performs address resolution.

Basic IPv6 Address Resolution Method

The basic concepts of address resolution in IPv6 ND aren't all that different from those in

IPv4 ARP. Resolution is still dynamic and is based on the use of a cache table that

maintains pairings of IPv6 addresses and hardware addresses. Each device on a physical

network keeps track of this information for its neighbors. When a source device needs to

send an IPv6 datagram to a local network neighbor but doesn't have its hardware address,

it initiates the resolution process. For clarity in the text let's say that, as usual, device A is

trying to send to device B.

Instead of sending an ARP Request message, A creates an ND Neighbor Solicitation

message. Now, here's where the first big change can be seen from ARP. If the underlying

data link protocol supports multicasting, like Ethernet does, the Neighbor Solicitation

message is not broadcast. Instead, it is sent to the solicited-node address of the device

whose IPv6 address we are trying to resolve. So

A won't broadcast the message, it will

multicast it to device B's solicited-node multicast address.

Device B will receive the Neighbor Solicitation and respond back to device A with a

Neighbor Advertisement. This is analogous to the ARP Reply and tells device A the

physical address of B. Device A then adds device B's information to its neighbor cache. For

efficiency, cross-resolution is supported as in IPv4 address resolution. This is done by

having Device A include its own layer two address in the Neighbor Solicitation, assuming it

knows it. Device B will record this along with A's IP address in B's neighbor cache.

Using Solicited-Node Multicast Addresses For Resolution

The solicited-node multicast address is a special mapping that each device on a multicast-

capable network creates from its unicast address; it is described in the topic on IPv6

multicast addresses. The solicited-node address isn't unique for every IPv6 address, but

the odds of any two neighbors on a given network having the same one are small. Each

device that receives a multicasted Neighbor Solicitation must still check to make sure it is

the device whose address the source is trying to resolve. (This is similar to how multicast is

handled in IPv4, with 32 different IP addresses potentially sharing a multicast MAC

address.)

Why bother with this, if devices still have to check each message? Simple: the multicast will

affect at most a small number of devices. With a broadcast, each and every device on the

local network would receive the message, while the use of the solicited-node address

means at most a couple of devices will need to process it. Other devices don't even have to

bother checking the Neighbor Solicitation message at all.

Key Concept: Address resolution in IPv6 uses the new Neighbor Discovery (ND)

protocol instead of the Address Resolution Protocol. A device trying to send an IPv6

datagram sends a Neighbor Solicitation message to get the address of another

device, which responds with a Neighbor Advertisement. When possible, the request is sent

using a special type of multicast address rather than broadcast, to improve efficiency.

This is actually a fairly simplified explanation of how resolution works in IPv6—the Neighbor

Discovery protocol is quite complicated. Neighbor solicitations and advertisements are also

used for other functions such as testing reachability of nodes and determining if duplicate

addresses are in use. There are many special cases and issues that ND addresses to

ensure that no problems result during address resolution. ND also supports proxied

address resolution.

Note: Even though I put this topic where it would be near the other discussions of

address resolution, the Neighbor Discovery protocol really isn't a “layer

connection” or “lower level” protocol like ARP. It is analogous to ICMP in its role

and function, and in fact makes use of ICMP(v6) messages. One advantage of this archi-

tectural change is that there is less dependence on the characteristics of the physical

network, so resolution is accomplished in a way more similar to other network support activ-

ities. Thus it is possible to make use of facilities that can be applied to all IP datagram

transmissions, such as IP security features. The section on ND contains much more infor-

mation on this subject.

Reverse Address Resolution and the TCP/IP Reverse Address

Resolution Protocol (RARP)

The TCP/IP Address Resolution Protocol (ARP) is used when a device needs to determine

the layer two (hardware) address of some other device but has only its layer three (network,

IP) address. It broadcasts a hardware layer request and the target device responds back

with the hardware address matching the known IP address. In theory, it is also possible to

use ARP in the exact opposite way. If we know the hardware address of a device but not its

IP address, we could broadcast a request containing the hardware address and get back a

response containing the IP address.

The Motivation For Reverse Address Resolution

Of course the obvious question is: why would we ever need to do this? Since we are

dealing with communication on an IP internetwork, we are always going to know the IP

address of the destination of the datagram we need to send—it's right there in the datagram

itself. We also know our own IP address as well. Or do we?

In a traditional TCP/IP network, every normal host on a network knows its IP address

because it is stored somewhere on the machine. When you turn on your PC, the TCP/IP

protocol software reads the IP address from a file, which allows your PC to “learn” and start

using its IP address. However, there are some devices, such as diskless workstations, that

don't have any means of storing an IP address where it can be easily retrieved. When these

units are powered up they know their physical address only (because it's wired into the

hardware) but not their IP address.

The problem we need to solve here is what is commonly called bootstrapping in the

computer industry. This refers to the concept of starting something from a zero state; it is

analogous to “pulling yourself up by your own bootstraps”. This is seemingly impossible,

just as it seems paradoxical to use a TCP/IP protocol to configure the IP address that is

needed for TCP/IP communications. However, it is indeed possible to do this, by making

use of broadcasts, which allow local communication even when the target's address is not

known.

The Reverse Address Resolution Protocol (RARP)

The first method devised to address the bootstrapping problem in TCP/IP was the

backwards use of ARP I mentioned above. This technique was formalized in RFC 903, A

Reverse Address Resolution Protocol (RARP), published in 1984. Where ARP allows

device A to say “I am device A and I have device B's IP address, device B please tell me

your hardware address”, RARP is used by device A to say “I am device A and I am sending

this broadcast using my hardware address, can someone please tell me my IP

address?”.The two-step operation of RARP is illustrated in Figure 52.

The next question then is: who knows A's IP address if device A doesn't? The answer is

that a special RARP server must be configured to listen for RARP requests and issue

replies to them. Each physical network where RARP is in use must have RARP software

running on at least one machine.

RARP is not only very similar to ARP, it basically is ARP. What I mean by this is that RFC

903 doesn't define a whole new protocol from scratch, it just describes a new method for

using ARP to perform the opposite of its normal function. RARP uses ARP messages in

exactly the same format as ARP, but uses different opcodes to accomplish its reverse

function. Just as in ARP, a request and reply are used in an exchange. The meaning of the

address fields is the same too: the sender is the device transmitting a message while the

target is the one receiving it.

Figure 52: Operation of the Reverse Address Resolution Protocol (RARP)

RARP, as the name suggests, works like ARP but in reverse, so this diagram is similar to Figure 47. Here,

instead of Device A providing the IP address of another device and asking for its hardware address, it is

providing its own hardware address and asking for an IP address it can use. The answer, in this case, is

provided by Device D, which is serving as an RARP server for this network.

Device A

IP Addr: Un kn own

Hardware Addr: #213

Device B

IP Addr: IPB

Hardware Addr: #79

Device D

IP Addr: IPD

Hardware Addr: #114

RARP Server

Device C

IP Addr: IPC

Hardware Addr: #46

My H/W Addr Is #213,

What Is My IP Addr?

#213, You Are IPA

Key Concept: The Reverse Address Resolution Protocol (RARP) is the earliest and

simplest protocol designed to allow a device to obtain an IP address for use on a

TCP/IP network. It is based directly on ARP and works in basically the same way, but

in reverse: a device sends a request containing its hardware address and a device set up

as an RARP server responds back with the device’s assigned IP address.

RARP General Operation

Here are the steps followed in a RARP transaction (illustrated in Figure 53):

1. Source Device Generates RARP Request Message: The source device generates

an RARP Request message. Thus, it uses the value 3 for the Opcode in the message.

It puts its own data link layer address as both the Sender Hardware Address and also

the Target Hardware Address. It leaves both the Sender Protocol Address and the

Target Protocol Address blank, since it doesn't know either.

2. Source Device Broadcasts RARP Request Message: The source broadcasts the

ARP Request message on the local network.

3. Local Devices Process RARP Request Message: The message is received by each

device on the local network and processed. Devices that are not configured to act as

RARP servers ignore the message.

Figure 53: Reverse Address Resolution Protocol (RARP) Operation

RARP uses a simple request/reply exchange to allow a device to obtain an IP address.

Client

RARP Request

1. Generate RARP

Request Frame

3. Process RARP

Request Frame

4. Generate RARP

Reply Frame

RARP Server

5. Send RARP Reply Frame

6. Process RARP

Reply Frame

2. Broadcast RARP

Request Frame

RARP Reply

4. RARP Server Generates RARP Reply Message: Any device on the network that is

set up to act as an RARP server responds to the broadcast from the source device. It

generates an RARP Reply using an Opcode value of 4. It sets the Sender Hardware

Address and Sender Protocol Address to its own hardware and IP address of course,

since it is the sender of the reply. It then sets the Target Hardware Address to the

hardware address of the original source device. It looks up in a table the hardware

address of the source, determines that device's IP address assignment, and puts it

into the Target Protocol Address field.

5. RARP Server Sends RARP Reply Message: The RARP server sends the RARP

Reply message unicast to the device looking to be configured.

6. Source Device Processes RARP Reply Message: The source device processes the

reply from the RARP server. It then configures itself using the IP address in the Target

Protocol Address supplied by the RARP server.

It is possible that more than one RARP server may respond to any request, if two or more

are configured on any local network. The source device will typically use the first reply and

discard the others.

Limitations of RARP

RARP is the earliest and most rudimentary of the class of technologies I call host configu-

ration protocols, which I describe in general terms in a dedicated section. As the first of

these protocols, RARP was a useful addition to the TCP/IP protocol in the early 1980s, but

has several shortcomings, the most important of which are:

☯ Low-Level Hardware Orientation: RARP works using hardware broadcasts. This

means that if you have a large internetwork with many physical networks, you need an

RARP server on every network segment. Worse, if you need reliability to make sure

RARP keeps running even if one RARP server goes down, you need two on each

physical network. This makes centralized management of IP addresses difficult.

☯ Manual Assignment: RARP allows hosts to configure themselves automatically, but

the RARP server must still be set up with a manual table of bindings between

hardware and IP addresses. These must be maintained for each server, which is again

a lot of work on an administrator.

☯ Limited Information: RARP only provides a host with its IP address. It cannot provide

other needed information such as, for example, a subnet mask or default gateway.

Today, the importance of host configuration has increased since the early 1980s. Many

organizations assign IP addresses dynamically even for hosts that have disk storage,

because of the many advantages this provides in administration and efficient use of

address space. For this reason, RARP has been replaced by two more capable technol-

ogies that operate at higher layers in the TCP/IP protocol stack: BOOTP and DHCP. They

are discussed in the application layer section on host configuration protocols.

TCP/IP Internet Layer (OSI Network Layer) Protocols

The first two layers of the OSI Reference Model, the physical layer and data link layer, deal

primarily with physical network details. The various LAN, WLAN and WAN protocols

function primarily at these two layers to connect devices to create networks, and perform

functions such as physical connection and signaling, media access control and local

delivery of data between devices on the same network. Above these layers, we move

beyond the hardware aspects of networking and closer to the more abstract realm of

software-related network functions.

The third OSI layer is the network layer. We are of course talking about networks in this

Guide, and it is no coincidence that the layer bearing that name is one of the most important

in comprehending how networks function. It is here that we find protocols that tie networks

together to create internetworks, and also where cross-network addressing and routing are

performed. The network layer is also called the internet layer in the TCP/IP model.

In this section I provide details for the various TCP/IP protocols that reside architecturally at

the TCP/IP internet layer / OSI network layer. Much of the focus here is on the all-important

Internet Protocol; the section covering IP includes extensive coverage of IP version 4, IP

version 6, and IP-related protocols such as IPSec, Mobile IP and IP Network Address

Translation (NAT). The following three subsections cover IP support protocols such as the

Internet Control Message Protocol (ICMP) and IPv6 Neighbor Discovery (ND) protocol, and

the complete set of IP routing protocols.

Internet Protocol (IP/IPv4, IPng/IPv6) and IP-Related Protocols

(IP NAT, IPSec, Mobile IP)

The idea of singling out any one protocol as being more important than the others in a

network is kind of pointless, if you think about it. The protocols and technologies work as a

team to accomplish the goal of communication across the network. Like any team, no single

member can get the job done alone, no matter how good they are. Still, if we were to try to

pick a “most valuable player” in the world of networking, a good case could be made that we

have it here in this section: the TCP/IP Internet Protocol (IP).

Even though it gets “second billing” in the name of the TCP/IP protocol suite, IP is in fact the

“workhorse” of TCP/IP. It implements key network-layer functions including addressing,

datagram handling and routing, and is the foundation upon which other TCP/IP protocols

are built. Even the ones lower in the TCP/IP architecture such as ARP and PPP are easier

to understand when you know how IP works. In addition to the main functions implemented

by the IP protocol itself, there are also several protocols that have been developed over the

years that I call “IP-Related” because they are based on IP but add new functionality or

capabilities for special purposes.

In this section I provide considerable coverage of the TCP/IP Internet Protocol and to

several protocols that are closely related to IP. I begin with a section that takes a general

look at IP concepts and provides an overview of how IP works. I then have a large section

that looks at IP version 4, the current version of the protocol that is in use on TCP/IP

networks everywhere. Following this I look at the “next generation” of IP, IP version 6. I then

provide sections covering three IP-related protocols: the IP Network Address Translation

protocol (IP NAT), the IP Security protocol set (IPSec), and the adaptation of IP for mobile

devices (Mobile IP).

Note: The primary focus in this section is on the current version of IP, IPv4,

because it is the one that is in widest use at the present time. I would therefore

advise reading the IPv4 section before proceeding to the other sub-sections here,

unless you are already familiar with it. To avoid duplication, the section on IP version 6 is

structured primarily to show how IPv6 differs from IPv4. Similarly, the sections on IP NAT,

IPSec and Mobile IP build upon some of the concepts in the IPv4 section.

Background Information: If you have not yet read the introductory section

describing TCP/IP in general terms, you may find it helpful to review it before

proceeding here.