IPv6 Essentials

Figure 8-1. An IPv6 routing table

For each route, the router keeps the following entries in the routing table:

IPv6 route

The IPv6 address prefix and prefix length of the destination address.

Next Hop address

The IPv6 address (normally link-local) of the first router along the path to the IPv6 route. If the route is directly connected to the router, there is no need for a Next Hop Address.

Next Hop interface

The physical interface used to reach the next hop.

Metric

A number indicating the total distance to the destination. In RIP, a very simple metric counts the number of hops to the destination. Directly connected routes are usually assigned a metric of 0. RIPng advertises directly connected routes with the configured outgoing metric of the link, normally 1.

101

Timer

The amount of time since the information about the route was last updated.

Route Change flag

Indicates that information about this entry has recently been changed. This flag is needed to control triggered routing updates.

Route Source

The entity that provided the information about the route. For example, this may be a static entry or directly connected, or the source may be RIP, OSPF, etc.

The router periodically distributes information about its routes to its directly connected neighbors using RIPng update messages. Upon receiving RIPng update messages from its neighbor, the router adds the distance between the neighbor and itself (usually 1) to the metric of each route received. The router then processes the newly received route entry using the Bellman-Ford algorithm.

Figure 8-2 provides a closer look at this algorithm.

Figure 8-2. The Bellman-Ford algorithm

Router A receives a routing update from router B and has already added the distance of 1 to each route ri advertised by B. For each route ri, the router steps through the algorithm depicted in Figure 8-2. According to Figure 8-2, the routing table will be updated if the following criteria are true; otherwise, route ri is discarded:

Route ri is new and the metric is reachable

The route, metric, and next hop are added as a new entry to the routing table. The timer is set to zero and the Route Change flag is raised.

Route ri is already known and the next hop is the same as the one in the routing table

If the metric has changed, it is updated and the Route Change flag is raised. The timer is reset to zero in any case.

102

Route ri is already known, but the next hop is different and the metric is smaller than the entry in the routing table

The metric and next hop are updated. The timer is set to zero and the Route Change flag is raised.

Route ri is already known, but the next hop is different and the metric is equal to the one in the routing table

If the routing process allows for multiple equal-cost paths to the same destination in the routing table, the route is treated as a new entry (see above). If the routing process does not provide for multiple equal-cost paths, route ri is discarded. Multiple equal-cost paths allow for load sharing of IPv6 traffic among multiple paths. The algorithm for distributing traffic among these paths is at the discretion of the routing process itself, normally based on the source and destination IPv6 addresses.

The next hop of ri is taken either from the information within the routing update message or from the source IPv6 address of the RIPng packet. See the later section Section 8.1.5 for more information.

When the routers are first initialized, they know only their directly connected routes. This information is passed to all neighbors, processed, and then distributed to the neighbors of the neighbors. Eventually, all IPv6 routes are known by all routers. The routers keep sending update messages periodically to prevent valid routes from expiring.

8.1.2 Limitations of the Protocol

RIPng, like the earlier versions of RIP, is primarily designed for use as an IGP in networks of moderate size. The limitations specified for RIP Versions 1 and 2 apply to RIPng, as well. They are described in the following list:

The RIPng diameter is limited

The longest path to any IPv6 route is limited to a metric of 15 when propagated with RIPng. Normally, the metric is equal to the hop count, assuming the cost of 1 is used for each link crossed. The protocol allows for larger costs to be assigned to any link, thereby limiting the number of hops even further.

Routing loops can cause high convergence time

When IPv6 routes that are no longer valid are being propagated in a looped environment, RIPng depends on "counting to infinity" to eliminate these routes eventually. Counting to infinity is explained in the next section.

The metric does not reflect line speed

RIPng uses a fixed metric normally set to 1 for each link crossed. A route cannot be chosen based on bandwidth or real-time parameters such as measured delay, load, or reliability.

8.1.3 Changes in Topology and Preventing Instability

A change in topology means a newly added route or a route that has gone down. Newly added routes are advertised with the next update message sent by the router with the direct connection to that route. Its neighbors process the route and pass it on to their neighbors. Eventually, all routers know about the newly added route.

103

What happens if a route goes down or a router crashes? These routes will time out, as they are no longer being advertised. The question is how long this will take and whether this time is acceptable for the network? The time it takes for all routers to learn the changed topology is called convergence time. To keep the convergence time to a minimum, several measures can be introduced.

8.1.3.1 Route poisoning and the hold-down timer

If an interface goes down on a router, the router does not remove the route(s) associated with that interface immediately. Instead, the router keeps the route in the routing table and raises the metric to 16 (unreachable). A garbage-collection timer, also known as a hold-down timer, determines how long the router keeps this unreachable route in the routing table. The route is now advertised to the neighbors with a metric of 16. The neighbors are running a hold timer as well, so they keep the route in the routing table to inform their respective neighbors of the invalidity of the route. This process is called route poisoning.

8.1.3.2 Split horizon, with or without poison reverse

Let's assume route r1 is directly connected to router A, as shown in Figure 8-3.

Figure 8-3. Convergence of route r1 without split horizon

Router A advertises r1 to its neighbor, router B, with a cost of 1. Router B adds 1 to the cost and lists r1 in its routing table using router A as the next hop. Now r1 goes down. Router A poisons r1 and waits for the update timer to expire before advertising r1 to B with a cost of 16. In the meantime, however, router B advertises r1 back to A with a cost of 2. According to Bellman-Ford, router A changes the entry for r1, using B as the next hop with a metric of 3. Now router A advertises r1 with a cost of 3 (not 16) to router B. Router B adds 1 to the cost and lists r1 in its routing table with a cost of 4. The routers send r1 back and forth, each time raising the cost by 1 until counting to infinity strikes and both reach a cost of 16, declaring r1 invalid. This will take quite some time, however. The core problem lies in the fact that router B advertises routes learned from A back to A. Split horizon prevents this from happening. With split horizon, a router never advertises a route back over its next hop interface. An additional option is split horizon with poison reverse. With this option, a router always advertises a route back over its next hop interface with a metric of 16. In the very unlikely situation that both router A and B have the same route pointing to each other, the routers don't have to wait for a timeout to eliminate this route because reverse poisoning invalidates each of them immediately. Poison reverse can, however, have the disadvantage of increasing the size of routing messages, especially if many destinations have to be advertised back as poisoned.

There are very few situations in which split horizon (with or without poison reverse) cannot be used at all. If there is a point-to-multipoint (also called hub-and-spoke) topology using a single common IPv6 network, split horizon prevents the spoke routers from learning routes advertised by other spoke routers. Split horizon must be turned off at the central router (the hub router).

8.1.3.3 Triggered updates

Any changes in the routing table have to wait to be advertised until the update timer has expired. Triggered updates speed up the process by allowing the changed route entry to be advertised almost immediately. A

104

very small hold timer is introduced before sending the update. Because only the changes are advertised, regular periodic updates need to stay in place.

All these measures speed up convergence, but the world is not perfect. Erroneous information may always come back over larger loops, especially within a large network with a topology containing many loops. The process of counting to infinity will, however, always prevail to eliminate the erroneous information.

8.1.4 Message Format

RIPng is a UDP-based protocol using UDP port number 521; let's call it the RIPng port. The RIPng routing process always listens to messages arriving on this port. With the exception of specific requests, all RIPng messages set the source and destination port to the RIPng port. Specific queries are discussed later in this chapter.

The RIPng message format is shown in Figure 8-4.

Figure 8-4. RIPng message format

The fields of the RIPng message are explained in the following list:

Command (1 byte)

A value of 1 specifies a request message asking the responding system to send all or part of its routing table.

A value of 2 sends an update message containing all or part of the sender's routing table. It may be sent as a response to a previous request or as an unsolicited update used in periodic or triggered routing updates.

Version (1 byte)

The version field is set to a value of 1.

Route Table Entry (RTE) (20 bytes each)

The RIPng header is followed by one or more Route Table Entries, using the format depicted in Figure 8-5.

105

Figure 8-5. Format of a Route Table Entry

Each RTE describes the route to be advertised by using the IPv6 Prefix (16 bytes) and its Prefix Length (1 byte). The metric field (1 byte) contains the metric used by the sender for this route. A valid metric has a value between 1 and 15. A metric of 16 describes the route as unreachable by the sending router.

Each RTE contains a Route Tag field, as well. It may be used to carry additional information about a route learned from another routing protocol—e.g., BGP. A router importing external routes into RIPng may set this tag. RIPng will preserve and redistribute this tag within its routing domain. Information within this tag can be used to redistribute the route out of the RIP domain. RIPng itself makes no use of this tag.

The number of RTEs within single updates depends on the MTU of the medium between two neighboring routers. The formula is:

number of RTEs = Int ((MTU - length of IPv6 headers - UDP_hdrlen - RIPng_hdrlen)/RTE_size)

8.1.5 Next Hop

If you are familiar with RIPv2, you probably miss the field for the next hop address. Not to worry: RIPng provides this feature, too. With RIPv2, each entry has a designated field specifying the next-hop address. This would not be very economical for RIPng because it would nearly double the size of each RTE. As shown in Figure 8-6, a specially constructed RTE, the next hop RTE, is introduced to indicate the next hop's IPv6 address. All subsequent RTEs use this next hop IPv6 address until the end of the message has been reached or another next hop RTE is encountered.

Figure 8-6. The next hop RTE

The next hop RTE is identified by a value of 0xFF in the metric field of the RTE. The IPv6 address within the RTE is now identified as the next hop IPv6 address to be used by the subsequent RTE. The route tag and the prefix length are set to zero on sending and ignored on reception.

Specifying a value of 0:0:0:0:0:0:0:0 in the prefix field of the next hop RTE indicates that the next hop IPv6 address should be set to the source IPv6 address of the RIPng message. The purpose of naming a specific next hop is to eliminate unnecessary routing hops. For example, routers A, B, and C are directly connected on a common subnet. Router C does not run RIPng. Assume that router A somehow knows a route ri using router C as its next hop. Router A could advertise ri to B with the next hop address

106

of Router C. Router B can now forward traffic for ri directly to Router C, therefore avoiding the unnecessary hop through Router A.

The next hop IPv6 address must always be a link-local address (starting with a prefix of FE80). If there is no next hop RTE, or if the received next hop address is not link-local, it should be considered

0:0:0:0:0:0:0:0.

8.1.6 Addressing Considerations and the Default Route

Any prefix with a length of zero is considered to be a default route, but normally, a prefix of 0:0:0:0:0:0:0:0 with a prefix length of zero is used. A default route is used if the route to the destination is not explicitly listed in the routing table. The next hop router for the default route is called the default router. Sending traffic to the default router assumes that the default router knows all the routes or has a default router itself. It is at the discretion of the implementer to determine if and how such a path of default routers should be implemented. The mechanism of default routers is usually used to lead the way out of the autonomous system or to lead traffic from remote sites to central sites. The advantage of distributing the default route is to reduce the number of routing updates to be distributed throughout the system. Default routes should not be propagated further than intended—that is, they should not leave the autonomous system. A metric is assigned to the default route at its origin to establish precedence among multiple default routers. RIPng handles a default route in exactly the same way as any other destination.

8.1.7 Timers

RIPng implements different timers to control updates of the routing information. The name and purpose of these timers are specified in the following list:

Update timer

By default, every 30 seconds the RIPng process wakes up on each interface to send an unsolicited routing response to the neighboring routers. This response contains the entire routing table except routes that follow the split horizon rule.

Timeout timer

Each time a route entry is updated, the timeout time for this route entry is reset to zero. If the route entry reaches 180 seconds (default value) without another update, it is considered to have expired. The metric is set to 16 and the garbage collection process begins. In addition, the Route Change flag is raised to indicate a change. The output process uses this flag to trigger an update.

Garbage collection timer (sometimes referred to as hold-down timer)

This timer is set for 120 seconds for each route entry that has timed out (see timeout timer) or been received with a metric of 16. Only upon expiration of this timer will the route entry finally be removed from the routing table. If a new update to this route arrives before the garbage collection timer expires, the route is replaced and the garbage collection timer is cleared.

8.1.8 Packet Processing

Let's have a look at how the router processes incoming and outgoing RIPng messages.

8.1.8.1 Request message

A request message asks a router to respond with all or part of its routing table by specifying the requested RTE. The incoming request is processed as follows.

107

If there is exactly one RTE with a prefix of zero, a prefix length of zero, and a metric of 16, the request is for the entire routing table, and the router responds by sending the entire routing table. Figure 8-7 shows a trace of such a request message.

Figure 8-7. RIPng request message asking for the entire routing table

Otherwise, the request message is processed one RTE at a time. If the RTE's coresponding prefix is found in the routing table, the RTE's metric is placed into the metric field of the RTE; otherwise, a metric of 16 is placed into the metric field, indicating that the route is unknown. Once all RTEs have been processed, the command field in the RIPng header is changed to response and the newly formed response message is sent back to the requestor.

There are two types of request messages, General and Specific, which are handled differently by the receiving router.

A General Request is sent by a router that has just come up and wants to fill its routing table quickly. The router sends out a General Request message, asking all directly connected neighbors to send their entire routing table. The neighbors each reply with a response message containing the entire routing table, using the split horizon rule.

A Specific Request message is sent by a monitoring station asking for all or part of the routing table. The queried router replies to the requestor by sending the requested information from its routing table. Split horizon is not used because it is assumed that the requestor is using the requested information for diagnostic purposes only.

108

Table 8-1 summarizes the characteristics of the two types of requests.

Table 8-1. RIPng request messages

Request

IPv6 source address

IPv6

destination

Source

Destination

Use

split

horizon

in

type

address

UDP port

UDP port

response?

General

Link-local

address of

ff02::9 (multicast)

RIPng

port

RIPng

port

Yes

the requestor's sending

(521)

(521)

interface

Specific

Global

or

site-local

Global

or

site-local

Any

except

RIPng

port

No

unicast

address of the

unicast

address of the

the

RIPng

(521)

requestor

queried router

port

8.1.8.2 Response message

A response message carries routing information to be processed by the receiving router by using the Bellman-Ford Algorithm (see the earlier section Section 8.1.1). A response message is accepted by a router only if the IPv6 source address is a link-local address of a directly connected neighbor and the UDP source and destination ports are set to the RIPng port. In addition, the hop count must be set to 255 to guarantee that the response has not traveled over any intermediate node.

Once the response message is accepted, each RTE must be checked for its validity. The test includes the prefix itself (not a multicast or link-local address), the prefix length (between 0 and 128), and the metric (between 1 and 16). If the RTE is accepted, the metric of the incoming interface is added to the metric of the RTE. The RTE is now passed to the Bellman-Ford process as described in the earlier section Section 8.1.1. Figure 8-8 shows a trace of a response message.

109

Figure 8-8. RIPng response message

The above rules for receiving and validating a response message do not apply for a response to a specific query. The hop count may be less than 255, and the source IPv6 address is not a link-local address. The diagnostic station uses the received RTE not for routing, but to provide input into its diagnostic software. It is entirely up to the implementer of such software to determine the validity of a response message.

There are two types of response messages: Unsolicited and Solicited. An Unsolicited Response message is sent by a periodic or triggered update process. The periodic update process examines the entire routing table upon expiration of the Update Timer on any given interface. The triggered update process wakes up as soon as the Route Change flag is raised and examines only routes with the Route Change flag set. Both processes then proceed with the following: if the examined route entry has a link-local address or should not be used because of split horizon processing, skip it. Otherwise, put the prefix, prefix length, and metric into the RTE, and put the RTE into the response message. If the maximum MTU has been reached, send the packet and build a new packet.

A Solicited Response message is sent as a response to a request message. See the earlier section Section 8.1.8.1 for more detail.

110