Charles M. Kozierok The TCP-IP Guide

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

Triggered Updates

The routing loop problem we looked at in the previous topic occurred because Router B

advertised Router A's route back to Router A. There's another aspect of the problem that is

also significant: after Router A discovered that the link to Network 1 failed, it had to wait up

to 30 seconds until its next scheduled transmission time to tell other routers about the

failure.

For RIP to work well, when something significant happens we want to tell other routers on

the internetwork immediately. For this reason, a new rule should be added to the basic RIP

router operation: whenever a router changes the metric for a route it is required to (almost)

immediately send out an RIP Response to tell its immediate neighbor routers about the

change. If these routers, seeing this change, update their routing information, they are in

turn required to send out updates. Thus, the change of any network route information

causes cascading updates to be sent throughout the internetwork, significantly reducing the

slow convergence problem. Note that this includes removal of a route due to expiration of

its Timeout timer, since the first step in route removal is setting the route's metric to 16,

which triggers an update.

You probably noticed that I said that triggered updates were sent “almost” immediately. In

fact, before sending a triggered update a route waits a random amount of time, from 1 to 5

seconds. This is done to reduce the load on the internetwork that would result from many

routers sending update messages nearly simultaneously.

Hold-Down

Split horizon tries to solve the “counting to infinity” problem by suppressing the transmission

of invalid information about routes that fail. For extra insurance, we can implement a feature

that changes how devices receiving route information process it in the case of a failed

route. The hold down feature works by having each router start a timer when they first

receive information about a network that is unreachable. Until the timer expires, the router

will discard any subsequent route messages that indicate the route is in fact reachable. A

typical hold-down timer runs for 60 or 120 seconds.

The main advantage of this technique is that a router won't be confused by receiving

spurious information about a route being accessible when it was just recently told that the

route was no longer valid. It provides a period of time for out-of-date information to be

flushed from the system, which is valuable especially on complex internetworks. The

addition of hold-down to split horizon can also help in situations where split horizon alone is

not sufficient to prevent counting to infinity, such as when a trio of routers are linked in a

“triangle”, as discussed earlier.

The main disadvantage of hold-down is that it forces a delay in a router responding to a

route once it is fixed. Suppose that a network “hiccup” causes a route to go down for five

seconds. After the network is up again, routers will want to again know about this. However,

the hold-down timer must expire before the router will try to use that network again. This

makes internetworks using hold-down relatively slow to respond to corrected routes, and

may lead to delays in accessing networks that fail intermittently.

Key Concept: Four special features represent changes to RIP operation that

ameliorate or eliminate the problems with the operation of the basic protocol. Split

horizon and split horizon with poisoned reverse prevent having a router send invalid

route information back to the router from which it originally learned the route. Triggered

updates reduce the slow convergence problem by causing immediate propagation of

changed route information. Finally, hold-down may be used to provide robustness when

information about a failed route is received.

Again, while I called the items above “features”, at least some of them are really necessary

to ensure proper RIP functionality. Therefore, they are generally considered standard parts

of RIP, and most were described even in the earliest RIP documents. However, sometimes

performance or stability issues may arise when these techniques are used, especially in

combination. For this reason different RIP implementations may omit some features. For

example, hold-down slows down route recovery and may not be needed when other

features such as split horizon are used. As always, care must be taken to ensure that all

routers are using the same features, or even greater problems may arise.

Also see the specific section on RIP-2 for a description of the Next Hop feature that helps

reduce convergence and routing problems when RIP is used.

RIP Version-Specific Message Formats and Features

The Routing Information Protocol (RIP) has been in widespread use for over two decades.

During that time, internetworks and internetworking technologies have changed. To keep up

with the times, RIP has also evolved, and today has three different versions. The basic

operation of all three is fairly similar, and was therefore described in the common section on

concepts and operation. As you might expect, there are also some differences between the

versions (or we wouldn't need versions!) One of the more important of these is the format

used for RIP messages in each version, and the meaning and use of the fields within that

format.

In this section I describe the message format used by each of the three versions of RIP, as

well as certain specific features not common to all versions. I begin with the original RIP,

also now known as RIP Version 1. I then describe the updated version of RIP called RIP

Version 2 or RIP-2. Finally, I discuss RIPng, also sometimes called RIPv6, the version of

RIP used for IP version 6 (IPv6). (Note that this is not technically a new version of the

original RIP protocol but a new protocol closely based on RIP versions 1 and 2.

RIP Version 1 (RIP-1) Message Format

RIP evolved as an industry standard and was popularized by its inclusion in the Berkeley

Standard Distribution of UNIX (BSD UNIX). This first version of RIP (now sometimes called

RIP-1 to differentiate it from later versions), was eventually standardized in RFC 1058. As

part of this standard the original RIP-1 message format was defined, which of course serves

RIP-1 itself, and is also the basis for the format used in later versions.

RIP-1 Messaging

As explained in the general discussion on RIP operation, route information is exchanged in

RIP through the sending of two different types of RIP messages: RIP Request and the RIP

Response. These are transmitted as regular TCP/IP messages using the User Datagram

Protocol (UDP), using UDP reserved port number 520. This port number is used as follows:

☯ RIP Request messages are sent to UDP destination port 520. They may have a

source port of 520 or may use an ephemeral port number.

☯ RIP Response messages sent in reply to an RIP Request are sent with a source port

of 520, and a destination port equal to whatever source port the RIP Request used.

☯ Unsolicited RIP Response messages (sent on a routine basis and not in response to a

request) are sent with both the source and destination ports set to 520.

RIP-1 Message Format

The basic message format for RIP-1 is described in Table 121 and illustrated in Figure 176.

If you're like me, the first thing that comes to mind looking at this message format is this:

what's with all the extra space? I mean, we have four different fields that are reserved (must

be zero), and even most of the other fields are larger than they need to be (a metric of 1 to

Table 121: RIP Version 1 (RIP-1) Message Format

Field Name

Size

(bytes)

Description

Command 1

Command Type: Identifies the type of RIP message being sent. A value of

1 indicates an RIP Request, while 2 means an RIP Response. Originally,

three other values and commands were also defined: 3 and 4 for the

Traceon and Traceoff commands, and 5 reserved for use by Sun Micro-

systems. These are obsolete and no longer used.

Version 1 Version Number: Set to 1 for RIP version 1.

Must Be Zero 2 Reserved: Field reserved; value must be set to all zeroes.

RIP Entries

20 to 500,

in incre-

ments of

RIP

es:

“b

”

RIP

message cons

s o

RIP

es.

These entries contain the actual route information that the message is conveying.

Each entry is 20 bytes long and has the following subfields:

Subfield

Name

Size

(bytes)

Description

Address

Family

Identifier

Address Family Identifier: A fancy name for a field

that identifies the type of address in the entry. We are

using IP addresses, for which this field value is 2.

Must Be

Zero

Reserved: Field reserved; value must be set to all

zeroes.

Address

IP Address: The address of the route we are sending

information about. No distinction is made between

addresses of different types of devices in RIP, so the

address can be for a network, a subnet or a single host.

It is also possible to send an address of all zeroes,

which is interpreted as the “default route” for other

devices on the network to use for reaching routes with

no specified routing entries. This is commonly used to

allow a network to access the Internet.

Must Be

Zero

Reserved: Field reserved; value must be set to all

zeroes.

Must Be

Zero

Reserved: Field reserved; value must be set to all

zeroes. Yes, two of them in a row. ☺

Metric 4

Metric: The distance for the network indicated by the

IP address in the IP Address field. Values of 1 to 15

indicate the number of hops to reach the network, while

a value of 16 represents “infinity” (an unreachable

destination). See the general discussion of the RIP

algorithm for more information on the use of metrics.

16 needs only 4 bits, not 32.) The command type and version number could easily have

been made only 4 bits each as well (if not less.) And why bother having a two-byte field to

identify the address type when we are only going to deal with IP addresses anyway?

This seeming wastefulness is actually an artifact of the generality of the original RIP design.

The protocol was intended to be able to support routing for a variety of different internet-

working protocols, not just IP. (Remember that it wasn't even originally developed with IP in

mind.) So, the Address Family Identifier was included to specify address type, and RIP

entries were made large enough to handle large addresses. IP only requires 4 bytes per

address so some of the space is not used.

RIP-1 Version-Specific Features

Since RIP version 1 was the first version of the protocol, its features formed the basis for

future RIP versions; it doesn't really have any version-specific features. What RIP-1 has is a

number of limitations, such as a lack of support for specifying classless addresses and no

means for authentication. RIP version 2 was created to address some of RIP-1 short-

comings. As we will see in the next topic, RIP-2's features put to good use those “Must Be

Zero” bytes in the RIP-1 format.

Figure 176: RIP Version 1 (RIP-1) Message Format

The RIP-1 message format can contain up to 25 RIP Entries. Here, RIP Entry #1 is shown here with each of

its constituent subfields.

Command Type Version Number = 1 Must Be Zero

Address Family Identifier = 2 Reserved

IP Address

Reserved

Metric

4 8 12 16 20 24 28 320

...

RIP Entry #2

RIP Entry #N

RIP Entry #1

Key Concept: RIP-1 was the first version of the Routing Information Protocol and is

the simplest in terms of operation and features. The bulk of an RIP-1 message

consists of sets of RIP entries that specify route addresses and the distance to the

route in hops.

RIP Version 2 (RIP-2) Message Format and Features

The original Routing Information Protocol (RIP-1) has a number of problems and limitations.

As the TCP/IP protocol suite evolved and changed, RIP-1's problems were compounded by

it becoming somewhat out of date, unable to handle newer IP features. There were some

who felt that the existence of newer and better interior routing protocols meant that it would

be best to just give up on RIP entirely and move over to something like Open Shortest Path

First (OSPF).

However, RIP's appeal was never its technical superiority, but its simplicity and ubiquity in

industry. By the early 1990s. RIP was already in use in many thousands of networks. For

those who liked RIP, it made more sense to migrate to a newer version that addressed

some of RIP-1's shortcomings than to go to an entirely different protocol. To this end, a new

version of the protocol, RIP Version 2 (RIP-2) was developed, and initially published in RFC

1388 in 1993. It is now defined in RFC 2453, RIP Version 2, published in November 1998.

RIP-2 Version-Specific Features

RIP-2 represents a very modest change to the basic Routing Information Protocol. RIP-2

works in the same basic way as RIP-1 (part of why I was able to describe the operation of

both in the same general section.) In fact, the new features introduced in RIP-2 are

described as extensions to the basic protocol, conveying the fact that they are layered

upon regular RIP-1 functionality. The five key RIP-2 extensions are:

☯ Classless Addressing Support and Subnet Mask Specification: When RIP-1 was

developed, the use of subnets in IP (as described in RFC 950) had not yet been

formally defined. It was still possible to use RIP-1 with subnets, through the use of a

heuristic to determine if the destination is a network, subnet or host. However, there

was no way to clearly specify the subnet mask for an address using RIP-1 messages.

RIP-2 adds explicit support for subnets by allowing a subnet mask within the route

entry for each network address. It also provides support for variable-length subnet

masking (VLSM) and classless addressing (CIDR).

☯ Next Hop Specification: In RIP-2, each RIP entry includes a space where an explicit

IP address can be entered as the next hop router for datagrams intended for the

network in that entry. This feature can help improve efficiency of routing by eliminating

unnecessary extra hops for datagrams sent to certain destinations.

One common use of this field is when the most efficient route to a network is through a

router that is not running RIP. Such a router will not exchange RIP messages and

would therefore not normally be selected by RIP routers as a next hop for any network.

The explicit Next Hop field allows the router to be selected as the next hop regardless

of this situation.

☯ Authentication: RIP-1 included no authentication mechanism, which is a problem

because it could potentially allow a malicious host to muck up an internetwork by

sending bogus RIP messages around. RIP-2 provides a basic authentication scheme,

which allows routers to ascertain the identity of a router before it will accept RIP

messages from it.

☯ Route Tag: Each RIP-2 entry includes a Route Tag field, where additional information

about a route can be stored. This information is propagated along with other data

about the route as RIP entries are sent around the internet. A common use of this field

is when a route is learned from a different autonomous system, to identify the auton-

omous system from which the route was obtained.

☯ Use of Multicasting: To help reduce network load, RIP-2 allows routers to be

configured to use multicasts instead of broadcasts for sending out unsolicited RIP

Response messages. These datagrams are sent out using the special reserved

multicast address 224.0.0.9. All routers on an internetwork must obviously use

multicast if this is to work properly.

As you can see, many of these extensions require more information to be included with

each advertised route. This is where all that “extra space” in the message format of RIP-1

routing entries comes in handy, as we will see shortly.

Key Concept: RIP-2 is the most recent version of RIP used in IPv4. It includes a

number of enhancements over the original RIP-1, including support for subnet masks

and classless addressing, explicit next-hop specification, route tagging, authenti-

cation and multicast. For compatibility, it uses the same basic message format as RIP-1,

putting the extra information required for its new features into some of the unused fields of

the RIP-1 message format.

RIP-2 Messaging

RIP-2 messages are exchanged using the same basic mechanism as RIP-1 messages.

Two different message types exist, RIP Request and RIP Response. They are sent using

the User Datagram Protocol (UDP) using UDP reserved port number 520. The semantics

for the use of this port is the same as for RIP-1. For convenience, I repeat the description

here:

☯ RIP Request messages are sent to UDP destination port 520. They may have a

source port of 520 or may use an ephemeral port number.

☯ RIP Response messages sent in reply to an RIP Request are sent with a source port

of 520, and a destination port equal to whatever source port the RIP Request used.

☯ Unsolicited RIP Response messages (sent on a routine basis and not in response to a

request) are sent with both the source and destination ports set to 520.

RIP-2 Message Format

The basic message format for RIP-2 is also pretty much the same as it was for RIP-1, with

the Version field of course set to 2, to clearly identify the message as being RIP-2. The real

differences are in the individual RIP entries, as you can see in Table 122 and Figure 177.

As you can see, the unused fields allow the new RIP-2 features to be implemented without

changing the basic structure of the RIP entry format. This allows RIP-1 and RIP-2

messages and devices to coexist in the same network. A RIP-2 device can handle both

RIP-1 and RIP-2 messages, and will look at the version number to see which version the

message is. A RIP-1 device should handle both RIP-2 and RIP-1 messages the same way,

simply ignoring the extra RIP-2 fields it doesn't understand.

Table 122: RIP Version 2 (RIP-2) Message Format

Field Name

Size

(bytes)

Description

Command 1

Command Type: Identifies the type of RIP message being sent. A value of

1 indicates an RIP Request, while 2 means an RIP Response.

Version 1 Version Number: Set to 2 for RIP version 2.

Must Be Zero 2 Reserved: Field reserved; value must be set to all zeroes.

Route Table

Entries (RTEs)

20 to 500,

in incre-

ments of

(RTE

)

s w

ith

RIP

“b

”

RIP

message

consists of 1 to 25 sets of route information. In RIP-2 these are labeled Route Table

Entries or RTEs. Each RTE is 20 bytes long and has the following subfields:

Subfield

Name

Size

(bytes)

Description

Address

Family

Identifier

Address Family Identifier: Same meaning as for RIP-

1; value is 2 to identify IP addresses.

Route Tag 2

Route Tag: Additional information to be carried with

this route.

Address

IP Address: Same as in RIP-1: the address of the

route we are sending information about. No distinction

is made between address of different types of devices

in RIP, so the address can be for a network, a subnet or

a single host. It is also possible to send an address of

all zeroes, which is interpreted as the “default route” as

in RIP-1.

Subnet

Mask

Subnet Mask: The subnet mask associated with this

address.

Next Hop 4

Next Hop: Address of the device to use as the next

hop for the network advertised in this entry.

Metric 4

Metric: The distance for the network indicated by the

IP address, as in RIP-1. Values of 1 to 15 indicate the

number of hops to reach the network (as described in

the general discussion of the RIP algorithm) while a

value of 16 represents “infinity” (an unreachable

destination).

Note: Note that if authentication is used, one of the RTEs contains authentication

information, limiting the message to 24 “real” RTEs.

RIPng ("RIPv6") Message Format and Features

The future of TCP/IP is the new Internet Protocol version 6 (IPv6), which makes some very

important changes to IP, especially with regard to addressing. Since IPv6 addresses are

different than IPv4 addresses, everything that works with IP addresses must change to

function under IPv6. This includes routing protocols, which exchange addressing

information.

To ensure a future for the Routing Information Protocol, a new IPv6-compatible version had

to be developed. This new version was published in 1997 in RFC 2080, RIPng for IPv6,

where the ng stands for next generation (IPv6 is also sometimes called “IP next

generation”).

Figure 177: RIP Version 2 (RIP-2) Message Format

The RIP Entries of RIP-1 are called Route Table Entries (RTEs) in RIP-2; the message format can contain up

to 25. The format of RTE #1 is shown here with each of its subfields (the others are summarized to save

space.)

Command Type Version Number = 2 Must Be Zero

Address Family Identifier = 2 Route Tag

IP Address

Subnet Mask

Next Hop

Metric

4 8 12 16 20 24 28 320

...

Route Table Entry (RTE) #2

Route Table Entry (RTE) #N

RTE #1

RIPng, which is also occasionally seen as RIPv6 for obvious reasons, was designed to be

as similar as possible to the current version of RIP for IPv4, which is RIP Version 2 (RIP-2).

In fact, RFC 2080 describes RIPng as “the minimum change” possible to RIP to allow it to

work on IPv6. Despite this effort, it was not possible to define RIPng as just a new version

of the older RIP protocol, like RIP-2 was. RIPng is a new protocol, which was necessary

because of the significance of the changes between IPv4 and IPv6—especially the change

from 32-bit to 128-bit addresses in IPv6, which necessitated a new message format.

RIPng Version-Specific Features

Even though RIPng is a new protocol, a specific effort was made to make RIPng like its

predecessors. Its basic operation is almost entirely the same, and it uses the same overall

algorithm and operation, as described in the general section on RIP operation. RIPng also

does not introduce any specific new features compared to RIP-2, except those needed to

implement RIP on IPv6.

RIPng maintains most of the enhancements introduced in RIP-2; some are implemented as

they were in RIP-2, while others appear in a modified form. Here's specifically how the five

extensions in RIP-2 are implemented in RIPng:

☯ Classless Addressing Support and Subnet Mask Specification: In IPv6 all

addresses are classless, and specified using an address and a prefix length, instead

of a subnet mask. Thus, a field for the prefix length is provided for each entry instead

of a subnet mask field.

☯ Next Hop Specification: This feature is maintained in RIPng, but implemented differ-

ently. Due to the large size of IPv6 addresses, including a Next Hop field in the format

of RIPng RTEs would almost double the size of every entry. Since Next Hop is an

optional feature, this would be wasteful. Instead, when a Next Hop is needed, it is

specified in a separate routing entry.

☯ Authentication: RIPng does not include its own authentication mechanism. It is

assumed that if authentication and/or encryption are needed, they will be provided

using the standard IPSec features defined for IPv6 at the IP layer. This is more

efficient than having individual protocols like RIPng perform authentication.

☯ Route Tag: This field is implemented the same way as it is in RIP-2.

☯ Use of Multicasting: RIPng uses multicasts for transmissions, using reserved IPv6

multicast address FF02::9.

RIPng Messaging

There are two basic RIPng message types, RIP Request and RIP Response, which are

exchanged using the User Datagram Protocol (UDP) as with RIP-1 and RIP-2. Since RIPng

is a new protocol, it cannot use the same UDP reserved port number 520 used for RIP-1/

RIP-2. Instead, RIPng uses well-known port number 521. The semantics for the use of this

port is the same as those used for port 520 in RIP-1 and RIP-2. For convenience, here are

the rules again:

☯ RIP Request messages are sent to UDP destination port 521. They may have a

source port of 521 or may use an ephemeral port number.