Charles M. Kozierok The TCP-IP Guide

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

Note: Both Router Advertisement and Router Solicitation messages may include

an optional layer two address of the device sending the message. This is used to

update address resolution caches to save time when address resolution is needed

later on.

IPv6 ND Host-Host Communication Functions: Address Resolution,

Next-Hop Determination, Neighbor Unreachability Detection and

Duplicate Address Detection

The delivery of datagrams in IP can be divided into two methods: direct and indirect.

Indirect datagram delivery requires that routers provide help to hosts, which leads to the

host-router discovery functions we examined in the previous topic. Direct delivery of

datagrams is performed from one host to another on the same network. This doesn't require

the use of routers, but necessitates other IPv6 ND protocol functions that involve Next-Hop

Determination communication directly between local hosts.

Next-Hop Determination

The first task that any host must perform when it wants to send a datagram is Next-Hop

Determination. This is the process by which a device looks at the destination address in a

datagram and decides whether direct or indirect delivery are required. In early IPv4 this was

done by looking at the class of the address, and later on, by using the subnet mask. In IPv6,

the prefix information obtained from local routers is compared to the destination of the

datagram to determine if the destination device is local or distant. If it is local, the next hop

is the same as the destination address; if it is non-local, the next hop is chosen from the

device's list of local routers (which are determined either by manual configuration or using

the host-router discovery features of ND.)

For efficiency purposes, hosts do not perform this next-hop determination for each and

every datagram. They maintain a destination cache that contains information about what

the next hop should be for recent devices to which datagrams have been sent. Each time a

next hop determination is performed for a particular destination, information from that deter-

mination is entered into the cache, so it can be used the next time datagrams are sent to

that device.

Address Resolution

If a host determines that the destination of a datagram is in fact local, it will then need to

send the datagram to that device. The actual transmission will occur using whatever

physical layer and data link layer technology has been used to implement the local network.

This requires that we know the layer two address of the destination, even though we only

generally have the layer three address from the datagram. Getting from the layer three

address to the layer two address is known as the address resolution problem.

In IPv6, the ND protocol is responsible for address resolution. When a host wants to get the

layer two address of a datagram destination it sends a Neighbor Solicitation ICMPv6

message containing the IP address of the device whose layer two address it wishes to

determine. That device responds back with a Neighbor Advertisement message that

contains its layer two address. Instead of using a broadcast that would disrupt each device

on the local network, the solicitation is sent using a special multicast to the destination

device's solicited-node address. A more complete description of address resolution in IPv6

can be found in the general section on address resolution.

Note also that even though this discussion does concentrate on communication between

hosts, address resolution may also be done when a host needs to send a datagram to a

local router and has no entry for it in its destination cache. In the context of address

resolution, a destination device is “just a neighbor”. Whether it is a host or a router only

matters in terms of what happens after the datagram has been sent and received. In other

words, these “host-to-host” functions are so named only because they are not specific to

the communication between hosts and routers like the tasks in the preceding topic.

Updating Neighbors Using Neighbor Advertisement Messages

Devices do not routinely send Neighbor Advertisements the way routers send Router

Advertisements. There really isn't any need for this: neighbors don't change much over

time, and resolution will occur naturally over time as devices send datagrams to each other.

In addition, having advertisements sent regularly by so many devices on a network would

be wasteful.

A host may, however, send an unsolicited Neighbor Advertisement under certain conditions

where it feels it is necessary to immediately provide updated information to other neighbors

on the local network. A good example of this is a hardware failure—in particular, the failure

of a network interface card. When the card is replaced, the device's layer two (MAC)

address will change. Assuming this can be detected by the device's IP layer, it can send out

an unsolicited Neighbor Advertisement message to tell other devices to update their

resolution caches with the new MAC address.

Neighbor Unreachability Detection and the Neighbor Cache

Neighbor Solicitation and Neighbor Advertisement messages are most often associated

with address resolution, but also have other purposes. One of these is Neighbor Unreach-

ability Detection. Each device maintains information about each of its neighbors and

updates it dynamically as network conditions change. The information is kept for both host

and router devices that are neighbors on the local network.

Knowing that a device has become unreachable is important because a host can adapt its

behavior accordingly. In the case of an unreachable host, a device may wait a certain

period of time before trying to send datagrams to an unreachable host instead of flooding

the network with repeated attempts to send to the host. An unreachable router, on the other

hand, is a signal that the device needs to find a new router to use, if an alternate is

available.

Each host maintains a neighbor cache that contains information about neighboring devices.

Each time a host receives a datagram from a neighbor, it knows the neighbor is reachable

at that particular moment, so the device makes an entry in the cache for the neighbor to

indicate this. Of course, receiving a datagram from a neighbor now only means the

neighbor is reachable now; the more time that elapses since the last datagram was

received, the greater the chance that something has happened to make the neighbor no

longer reachable.

For this reason, neighbor reachability information must be considered temporary. Each time

a neighbor is entered into the cache as reachable, a timer is started. When the timer

expires, the reachability information for that neighbor is considered stale, and reachability is

no longer assumed for that neighbor. When a new datagram is received from the neighbor

in question the timer is reset and the cache is again set to indicate that the device is

reachable. The amount of time a host should consider a neighbor reachable before expiring

it is communicated by a local router using a field in a Router Advertisement message.

A host can also dynamically seek out a neighbor if it needs to know its reachability status. It

sends a Neighbor Solicitation to the device and waits for a Neighbor Advertisement in

response. It then updates the cache accordingly.

Duplicate Address Detection

The last use of the two messages we have been discussing here is for Duplicate Address

Detection. When a host uses the IPv6 autoconfiguration facility, one of the steps in the

process is to ensure that the address it is trying to use doesn't already exist on the network.

This is done by sending a Neighbor Solicitation message to the address the device wishes

to use. If a Neighbor Advertisement is received in reply the address is already in use.

Key Concept: The second of the two main functional groups of the Neighbor

Discovery protocol is the set of host-host communication functions. Two ICMPv6

messages are defined, Neighbor Advertisement and Neighbor Solicitation, which

enable a variety of types of essential communication between adjacent hosts on a local

network. These include address resolution, determining the next hop to which a datagram

should be sent, and also the assessment of a neighboring device’s reachability.

IPv6 ND Redirect Function

The last of the major responsibilities of the IPv6 Neighbor Discovery protocol is the redirect

function. This is used by a router to inform a host of a better route to use for datagrams sent

to a particular destination. An argument could be made that the redirect function should be

part of the host-router group since it represents a form of communication between routers

and regular hosts. However, it is somewhat different from the other “discovery” functions

and so the standard treats it separately.

Routers are responsible for detecting situations where a host on the local network has

made an inefficient first-hop routing decision, and then attempting to correct it. For example,

consider a network that has two routers on it, R1 and R2. A host H1 wants to send a

datagram to device X2 on another network that is connected to H1's network through router

R2. If H1 sends the datagram to R1, R1 will of course know it has to go through R2 and will

send it there. Seeing that R2 was also on the local network, R1 therefore knows that H1

made a poor initial routing decision: the datagram should have been sent to R2 directly, not

R1. If this sounds very similar to ICMPv4 redirect feature, that’s because it is.

In response, R1 will create a special Redirect ICMPv6 message. This message will tell H1

that for any subsequent datagrams to be sent to X2 should be first sent to R2 instead of R1.

It is also possible that a router may determine other situations where the first hop from a

particular host should be different and will advise the host using a Redirect message. This

is illustrated in Figure 170.

Figure 170: ND Host Redirection Using an ICMPv6 Redirect Message

H1 sends to R1 an IPv6 datagram destined for a device on network N2. However, R1 notices that R2 is on the

same network as the source device and is a more direct route to N2. It forwards the datagram on to R2 but

also sends an ICMPv6 Redirect message back to H1 to tell it to use R2 next time.

Network N1

Internet

Network N2

Re dir e ct

IPv6

Datagram Delivery

Continues

Only routers send Redirect messages, not hosts. Hosts are responsible for looking for

these Redirect messages and processing them. A host receiving such a message will look

in it to see which destination's datagram led to the redirect, and which new first hop the

router is saying the host should use in the future for that destination. In this case, H1 will

see that R1 is saying any further datagrams to X2 should be sent to R2 instead of R1. H1

will update its destination cache for X2 accordingly.

Key Concept: The Neighbor Discovery protocol redirect function allows a router to

tell a host to use a different router for future transmissions to a particular destination.

It is similar to the IPv4 redirect feature and is implemented using ICMPv6 Redirect

messages.

When a router sends a Redirect, it may also include in the message the data link layer

address of the destination to which it is redirecting. This address is used by the host to

update its address resolution cache, if necessary. This may save bandwidth in the future by

eliminating an address resolution cycle, when the redirected host tries to send to the new,

redirected location. In our example, R1 may include R2’s own layer two address in the

redirect. This can be used by H1 the next time it has a datagram for X2.

IPv6 also supports authentication of Redirect messages, to prevent unauthorized devices

from causing havoc by sending inappropriate Redirects. A host may be configured to

discard Redirects that are not properly authenticated.

TCP/IP Routing Protocols (Gateway Protocols)

Routing is not just one of the most important activities that takes place at the network layer:

it is the function that really defines layer three of the OSI Reference Model. Routing is what

enables small local networks to be linked together to form potentially huge internetworks

that can span cities, countries or even the entire globe. It is the job done by special devices

called routers, which forward datagrams from network to network, allowing any device to

send to any other even if the source has no idea where the destination is.

Routing is a complicated subject. The short summary of the process is that routers decide

how to forward a datagram based on its destination address, which is compared to infor-

mation the router keeps in special routing tables. These tables contain entries for each of

the networks the router knows about, telling the router which adjacent router the datagram

should be sent to in order for it to reach its eventual destination.

As you can imagine, routing tables are critically important to the routing process. It is

possible for these tables to be manually maintained by network administrators, but this is

tedious, time-consuming and doesn't allow routers to deal with changes or problems in the

internetwork. Instead, most modern routers are designed with functionality that lets them

share route information with other routers, so they can keep their routing tables up to date

automatically. This information exchange is accomplished through the use of routing

protocols.

In this section I provide a description of the most common routing (or gateway) protocols

used in TCP/IP. I begin with an overview of various concepts that are important to know in

order to understand how routing protocols work. I then describe the TCP/IP routing

protocols themselves in two subsections. The first covers interior routing protocols, which

are used between routers in an autonomous system, and the second looks at exterior

routing protocols, used between autonomous systems.

If you don't understand what an autonomous system is or the difference between an interior

and exterior protocol, then you know why I included an overview topic on concepts first. In

fact, it is really much easier to understand routing protocols once you have a good

background on the entire process of routing.

You may notice that in the title of this section I refer to both routing protocols and gateway

protocols. These terms are interchangeable, and in fact, the word gateway appears in the

name of several of the protocols. This is an artifact of the historical use of the term gateway

in early TCP/IP standards to refer to the devices we now call routers. Today, the term

gateway normally refers not to a router, but to a different type of network interconnection

device, so this can be particularly confusing. The term “routing protocol” is now preferred,

and is the one I use.

Note: Some of the protocols in this section are generic enough that they could be

applied to support the routing of any network layer protocol. They are most often

associated with IP, however, as TCP/IP is by far the most popular internetworking

protocol suite, and that is my assumption in describing them. Also, this section focuses

primarily on the routing protocols used in Internet Protocol version 4. There is limited

discussion of IPv6 versions of the protocols at this time.

Note: Strictly speaking, an argument could be made that some routing protocols

don't belong in layer three. For example, many of them send messages using TCP

or UDP at layer four. Despite this, routing is inherently a layer three activity and for

this reason, it is traditional to consider routing protocols part of layer three.

Note: Like all topics related to routing, routing protocols are generally quite

complex. I cover the major ones here in more detail than most general networking

references, but even so, you should recognize that I am only scratching the

surface, especially of the more complicated ones like OSPF. You can check out the refer-

enced Internet standards (RFCs) for more details if you desire. I should also point out that

there are still more routing protocols in use on IP networks that I do not cover here, such as

IS-IS (which is actually an OSI protocol and not formally part of TCP/IP).

Overview Of Key Routing Protocol Concepts: Architectures,

Protocol Types, Algorithms and Metrics

Routing protocols play an important part in the overall process of routing in an internetwork.

It is therefore easiest to understand them in the scope of an overall discussion of routing.

It's difficult to describe the individual TCP/IP routing protocols without some background

information on how routing protocols work. For this reason, I feel it is worth taking a brief

look at key routing protocol concepts here, so that you will have more luck making sense of

the rest of the routing protocol topics in this section.

Routing Protocol Architectures

Let's start with a look at routing protocol architectures. In this context, the word architecture

refers to the way that an internetwork is structured. Once we have a number of networks

and routers we wish to connect together, there are any number of ways that we can do this.

The architecture we choose is based on the way that routers are linked up, and this has an

impact on the way that routing is done, and how routing protocols operate.

Core Architecture

TCP/IP and the Internet were developed simultaneously, so TCP/IP routing protocols

evolved as the Internet itself did. Early architecture of the Internet consisted of a small

number of core routers that contained comprehensive information about the internetwork.

When the Internet was very small, it was expanded by adding more routers to this core.

However, each time the core was expanded, the amount of routing information that needed

to be maintained grew.

Eventually, the core became too large, so a two-level hierarchy was formed to allow further

expansion. Non-core routers were located on the periphery of the core and contained only

partial routing information; they relied on the core routers for transmissions that went across

the internetwork. A special routing protocol called the Gateway-to-Gateway Protocol (GGP)

was used within the core of the internetwork, while another protocol called the Exterior

Gateway Protocol (EGP) was used between non-core and core routers. The non-core

routers were sometimes single, stand-alone routers that connected a single network to the

core, or they could be sets of routers for an organization.

This architecture served for a while, but itself did not scale very well as the Internet grew.

The problem was mainly due to the fact that there was only a single level to the archi-

tecture: every router in the core had to communicate with every other. Even with peripheral

routers being kept outside the core, the amount of traffic in the core kept growing.

Autonomous System (AS) Architecture

To resolve the limitations of the early core system, a new architecture was created that

moved away from the centralized concept of a core towards an architecture that was better

suited to a larger and growing internetwork. This decentralized architecture treats the

Internet as a set of independent groups, which each group called an autonomous system

(AS). An AS consists of a set of routers and networks controlled by a particular organization

or administrative entity, which uses a single consistent policy for internal routing.

The power of this system is that routing on the internetwork as a whole occurs between

ASes and not individual routers. Information is only shared between one or maybe a couple

of routers in each AS, not every router in each AS. The details of routing within an AS are

also hidden from the rest of the internetwork. This provides both flexibility for each AS to do

routing as it sees fit (thus the name autonomous) and efficiency for the overall internetwork.

Each AS has its own number, and the numbers are globally managed to make sure they are

unique across an internetwork (such as the Internet).

Key Concept: Large, modern TCP/IP internetworks can contain thousands of

routers. To better manage routing in such an environment, routers are grouped into

constructs called autonomous systems. Each autonomous system (AS) consists of a

group of routers managed independently by a particular organization or entity.

Modern Protocol Types: Interior and Exterior Routing Protocols

The different nature of routing within an AS and between ASes can be seen in the fact that

distinct sets of TCP/IP routing protocols are used for each type:

☯ Interior Routing Protocols: These protocols are used to exchange routing infor-

mation between routers within an autonomous system. Interior routing protocols are

not used between ASes.

☯ Exterior Routing Protocols: These protocols are used to exchange routing infor-

mation between autonomous systems. They may in some cases be used between

routers within an AS, but primarily deal with exchanging information between auton-

omous systems.

Key Concept: Interior routing protocols are used to share routing information within

an autonomous system; each AS may use a different interior routing protocol

because the system is, as the name says, autonomous. Exterior routing protocols

convey routing data between autonomous systems; each AS must use the same exterior

protocol to ensure that they can communicate.

Since autonomous systems are just sets of routers, this means that ASes are connected by

linking a router in one AS to a router in another AS. Architecturally, an AS consists of a set

of routers with two different types of connectivity:

☯ Internal Routers: Some routers in an AS connect only to other routers in the same

AS. These run interior routing protocols.

☯ Border Routers: Some routers in an AS connect both to routers within the AS and to

routers in one or more other ASes. These devices are responsible for passing traffic

between the AS and the rest of the internetwork. They run both interior and exterior

routing protocols.

Due to its advantages, the autonomous system architecture, an example of which can be

seen in Figure 171, has become the standard for TCP/IP networks, most notably the

Internet. The division of routing protocols into the interior and exterior classifications has

thus also become standard, and all modern TCP/IP routing protocols are first subdivided by

type in this manner. You can see this reflected in the subsection titles in the rest of this

section on routing protocols.

Routing Protocol Algorithms and Metrics

Another key differentiation of routing protocols is on the basis of the algorithms and metrics

they use. An algorithm refers to a method that the protocol uses for determining the best

route between any pair of networks, and for sharing routing information between routers. A

Figure 171: TCP/IP Autonomous System (AS) Routing Architecture

This diagram shows a simplified internet organized into three autonomous systems (ASes), each of which is

managed independently of the others. Communication within each AS is done using an interior routing

protocol chosen by that AS’s administrators (blue links); communication between ASes must be done using a

common exterior routing protocol (red links). Internal routers are shown in blue and border routers in red.

Autonomous System #2

Autonomous System #1 Autonomous System #3

R2A

R1A

R1C

R1B

R2D

R2C

R2E

R2B