Chapter 5: IPv6 Routing and Issues

Routing in IPv6 is almost identical to routing in IPv4, under CIDR. However, the addresses are 128-bit in IPv6, instead of 32-bit as of in IPv4. Thus, all of IPv4's routing algorithms (OSPF, RIP, IDRP, ISIS, etc.) can used to route IPv6. Nonetheless, to better understand IPv6 routing you must refer to the official IETF routing protocols drafts discussing OSPFv3 and IDRPv2. But there are some issues revolving IPv6 routing and this chapter addresses them.

At glance, this chapter discusses:

• IPv6 routing
• Routing with OSPFv3
• Routing with IDRPv2 and its impact on BGP 4
• Routing issues involving RIP and more
• Interdomain routing
• Intradomain routing

Routing IPv6: Preliminary Considerations:

As mentioned above, the official IETF routing protocols for IPv6 are Open Shorest Path First version 3 (OSPFv3) and InterDomain Routing Protocol version 2 (IDRPv2).

OSPFv3 specifications are very different form the current version, OSPFv2. Starting with the fact that most of the LSA announcements changed (new LSA headers where added). The model also changed, as IPv6 doesn't really use the concept of subnet but of link, with links usually having several prefixes assigned. Further, we wonder if OSPFv3 is really ready to be considered a stable specification, as there were many changes involved in this new release.

As for IDRPv2, here it is the question: should it replace Border Gateway Protocol version 4 (BGP 4)? After all, IDRP, which is an Open System Interconnection (OSI) standard, was for the most part writing by the same people involved with BGP, only that IDRP was written in OSI-parlance. As a matter of fact, being written in OSI-parlance seems not to have attracted much sympathy around the industry. Go figure! A major advantage though is that IDRP supports "routing confederations," which BGP doesn't. But still, the status of the document is rather dubious, as IDRPv2 appears as an IETF draft, but outside of the OSI scope. This makes us wonder about the correctness of the decision to base the IPv6 Exterior Gateway Protocols (EGP) in IDRP instead of BGP since it somewhat shakes the base of the goal of an unique and integrated routing protocol to comprise the 3 network protocols.

One could argue if it wouldn’t be much more efficient to modify BGP-4 to include IPv6 support. Of course, we would still have to deal with the main problem here, with regards to the next hop address field, which would have to be changed. But wouldn’t it be easier to reuse the BGP code already present in software like GateD or even smaller and more manageable MRT?

Finally, the challenge here appears to be on trying to run Route Information Protocol (RIP), even though Telebit already has an IDRPv2 implementation. Although for some RIP is a waste of time, specially if considering its current configurations, where we wish to apply it is not really suitable at all for RIP, such as in the 6-sparguetti-bone. But, we should not forget that RIP is what can be done for the short period, and besides, it can always come handy in the future, since it is actually a good choice if your topology doesn't form loops and you are looking for something simple.

But lets take a look of the routing issues we must deal with before we can really enjoy a full IPv6 implementation

Interdomain Routing

As Christian Huitema wrote in his book "IPv6, The New Internet Protocol," (1996), when the first efforts to develop IPv6 started, the group used to believe that the Internet could crash due to three possible causes:

1. The shortage of network numbers,
2. The explosion of routing tables,
3. The overall shortage of network addresses.

The jump to 128-bit addresses in IPv6 certainly resolve the problem of shortage of network IP addresses, but it doesn’t address the problem of routing tables continuing to grow. Actually, most routers today are not working efficiently, calculating the best route in between destinations, because for that they need to maintain a list of every network on the Internet. Unfortunately, there are so many that the routing tables are way too large already.

In order to resolve this problem, we must aggregate several routing entries, creating routing domains, which implies that we must create some form of hierarchy for the addresses, so that an interdomain routing technology can be deployed to enable users to take advantage of that hierarchy.

A diagram of an OSI intradomain and interdomain routing

In light of these routing domain models, the solution being proposed for IPv6 is to use the provider’s addresses, as these addresses usually are very much in tune with the network topology. All routes would then be exchanged via IDRP, as mentioned at the beginning of this chapter. If a user have any issues or constraint, tunnels could be built, as well as routing headers could be used to build up their special transit routes.

From CIDR to ISPs

However, what network administrators have been trying to do is to slow down the growth of routing tables by deploying Classless Interdomain Routing (CIDR), since CIDR does not consider IP addresses as composed of fixed-length network numbers, but variable-length prefixes, which in turn are assigned in a coordinated way. But when we consider international addressed, supposedly the prefixes of a given country should be consistent and start with the same high-order bits. Unfortunately, this same rule can not be applied to networks, as it will depend on how these networks are connected to the Internet. For instance, some international networks could be leasing direct lines to other country’s providers, which would by-pass, the prefix rule. That’s why the proposition calls for using ISP-based addresses for IPv6.

The problem here is that one could argue (and many do!) that this model would promote a client’s dependency of the ISP, which is indeed a valid concern, as if you were to change providers you would definitely have to change your address or negotiate some deal with both ISPs.

BGP-4 and the IDRP Consideration

The Internet is built out of autonomous systems, where a single entity, such as a large corporation network, manages several subnets, and so forth. A typical example of it is an ISP, the entity, managing several subnets, represented by the customer’s network.

In order to internetwork, these autonomous systems must use what is called Exterior Gateway Protocols (EGP) to exchange reachability information, so that information about the destination for which they accept to relay packets can be described.

EGP is still the primary interdomain routing protocol used on the Internet. It was originally documented in RFC 904 in April 1984, and is still used for communication between the "core" Internet routers. These core Internet routers form the Internet's routing backbone. Information is passed from individual source networks up to the core routers, which pass the information through the backbone until it may again be passed down to the destination network. In some cases, the links between lower-level domains and the core routers are assigned and remain static. In other cases, EGP is used for these links.

Although EGP is a dynamic routing protocol, it uses a very simple design. It does not use metrics and therefore cannot make true intelligent routing decisions. EGP routing updates contain network reachability information. In other words, they specify that certain networks are reachable through certain routers.

EGP updates are sent to neighboring routers at regular intervals. In the updates, each router indicates those networks to which it is directly attached. This network reachability information eventually permeates the EGP environment. The information is used to construct and maintain routing tables.

However, EGP has many weaknesses. For instance, EGP has no way of dealing with the routing loops that can occur in multi-path networks. Another weakness of EGP is that routing updates are often very large and cumbersome. To top that, EGP cannot make intelligent routing decisions because it does not support link metrics. For these reasons, EGP is slowly being phased out of the Internet and being replaced by BGP.

BGP-4, which is the current version of BGP, described in RFC 1771, is a path vector protocol, which actually pretty much already replaced EGP after more than 10 years of being in use. This new version does support the routing table aggregation required by CIDR. BGP allows border routers to announce paths that are described as sets of attributes, the list of autonomous systems it traverses as well as the list of network prefixes it reaches.

Although designed as an inter-domain protocol, BGP may be used both within and between domains. Two BGP neighbors communicating between domains must reside on the same physical network. BGP routers within the same domain communicate with one another for two reasons:

• To ensure that they have a consistent view of the domain
• To determine which BGP router within that domain will serve as the connection point to/from certain external domains

BGP uses TCP as its transport protocol (port 179). Two BGP speaking routers form a TCP connection between one another (peer routers) and exchange messages to open and confirm the connection parameters.

Enabling BGP routing Step-by-step: Here are the steps needed to enable and configure BGP. Assuming that you want to have two routers, ROUTER1 and ROUTER2, talking to BGP and that ROUTER1 and ROUTER2 are in different autonomous systems: Start by defining the router process and define the autonomous system number that the routers belong to. The command used to enable BGP on a router is: router bgp autonomous-system ROUTER1# router bgp 100 ROUTER2# router bgp 200 The above statements indicate that ROUTER1 is running BGP and it belongs to autonomous system 100, and ROUTER2 is running BGP and it belongs to autonomous system 200 and so on. The next step in the configuration process is to define BGP neighbors. The neighbor definition indicates which routers we are trying to talk with BGP.

BGP peers will initially exchange their full BGP routing tables. From then on incremental updates are sent as the routing table changes. BGP keeps a version number of the BGP table and it should be the same for all of its BGP peers. The version number will change whenever BGP updates the table due to some routing information changes. Keep-alive packets are sent to ensure that the connection is alive between the BGP peers and notification packets are sent in response to errors or special conditions.

Multiple BGP speakers enable autonomous systems to serve as transit service for other autonomous systems bordering each other.

Before sending an information to other external autonomous systems it is necessary to ensure reachability for networks within other autonomous systems. This is accomplished by a combination of internal BGP peering between routers inside an autonomous system and by redistributing BGP information to Internal Gateway Protocols (IGP) running in the autonomous system.

When BGP is running between routers belonging to two different autonomous systems, it is usually called an Exterior BGP (EBGP) and for BGPs running between routers in the same autonomous system, it can be called Interior BGP (IBGP).

Since BGP was designed and optimized to handle 32-bit addresses, BGP-4 could not easily be upgraded to work with IPv6. Therefore, the EGP protocol used by IPv6 could not be based on BGP but on IDRP instead, which actually, was first designed as a component of the OSI protocols defined by ISO. But the major difference between BGP and IDRP is in its vocabulary. As Huitema describes in the above mentioned book, ‘IDRP is defined in the ISO standard 10747, and the real name is, according to ISO, the Protocol for Exchange of InterDomain Routeing Information among Intermediate Systems to Support Forwarding of ISO 8473 PDUs

BGP Neighbors/Peers

Two BGP routers become border routers, neighbors or peers once they establish a TCP connection between one another. The TCP connection is essential in order for the two peer routers to start exchanging routing updates.

When two BGP border routers try to become neighbors, they will have first to bring up the TCP connection between one another and then send open messages in order to exchange values, such as the autonomous system number. Other information may include the BGP version they are running, such as version 3 or 4, the BGP router ID and the keep-alive hold time, etc. After these values are confirmed and accepted the neighbor connection will be established. Any state other than established is an indication that the two routers did not become neighbors and hence the BGP updates will not be exchanged.

Establishing a TCP connection via neighbor command: neighbor ip-address remote-as number The remote-as number is the anonymous system number of the router you are trying to connect to via BGP. The ip-address is the next hop directly connected address for EBGP and any IP address on the other router for IBGP.

In the example above (step-by-step), it is essential that the two IP addresses used in the neighbor command of the peer routers be able to reach one another. One sure way to verify reachability is an extended ping between the two IP addresses. The extended ping forces the pinging router to use as source the IP address specified in the neighbor command rather than the IP address of the interface the packet is going out from.

Resetting a neighbor connection: It is very important to reset the neighbor connection in case any bgp configuration changes are made in order for the new parameters to take effect. clear ip bgp address (where address is the neighbor address) clear ip bgp * (clear all neighbor connections)

By default, BGP sessions begin using BGP-4 and negotiating downward to earlier versions if necessary. To prevent negotiations and force the BGP version used to communicate with a neighbor, perform the following task in router configuration mode, as shown in the Step-by-step section below:

Forcing BGP version used to communicate with neighbor: neighbor {ip address|peer-group-name} version value An example of the neighbor command configuration, as depicted on figure 5.3 is described bellow: RTA# router bgp 100 neighbor 129.213.1.1 remote-as 200 RTB# router bgp 200 neighbor 129.213.1.2 remote-as 100 neighbor 175.220.1.2 remote-as 200 RTC# router bgp 200 neighbor 175.220.212.1 remote-as 200

BGP and Loopback Interfaces

Using a loopback interface to define neighbors is commonly used with IBGP rather than EBGP. Normally the loopback interface is used to make sure that the IP address of the neighbor stays up and is independent of a hardware that might be flaky. In the case of EBGP, most of the time the peer routers are directly connected and loopback does not apply.

If the IP address of a loopback interface is used in the neighbor command, some extra configuration needs to be done on the neighbor router. The neighbor router needs to tell BGP that it is using a loopback interface rather than a physical interface to initiate the BGP neighbor TCP connection. The command used to indicate a loopback interface is:

neighbor ip-address update-source interface

The following example describes figure 5.4 and helps to illustrate the use of this command.

Indicating a loopback interface

RTA#

router bgp 100

neighbor 190.225.11.1 remote-as 100

neighbor 190.225.11.1 update-source int loopback 1

RTB#

router bgp 100

neighbor 150.212.1.1 remote-as 100

In the figure 5.4, RTA and RTB are running internal BGP inside autonomous system 100. RTB is using in its neighbor command the loopback interface of RTA (150.212.1.1); in this case RTA has to force BGP to use the loopback IP address as the source in the TCP neighbor connection. RTA will do so by adding the update-source int loopback configuration (neighbor 190.225.11.1 update-source int loopback 1) and this statement force BGP to use the ip address of its loopback interface when talking to neighbor 190.225.11.1.

Note that RTA has used the physical interface IP address (190.225.11.1) of RTB as a neighbor and that is why RTB does not need to do any special configuration.

CAUTION: An important point to remember is that BGP will not accept updates that have originated from its own anonymous system. This is to insure a loop free interdomain topology.

Much more can be said about BGP’s configuration. For more information, we suggest you to check the URL http://www.alef0.cz/techtips/bgp/, which can provide you with a vast information about BGP, not intended for this chapter.

A final recommendation, BGP will not accept updates that have originated from its own anonymous system, which insures a loop free interdomain topology.

Intradomain Routing

Interior routing protocols are used to compute the routes and maintain connectivity within a routing domain or autonomous system. The technology is reliable and only need some revisions and updates. That’s what IETF is doing, preparing updates for OSPF and RIP, as well as some IPv6 extensions for other protocols, such as IS-IS, which is discussed in this section.

Updating Open Shortest Path First

Open Shortest Path First (OSPF) is still the recommended protocol for intradomain routing. As a link state protocol, all routers maintain a copy of a database that contains link state records describing the status of the network area to which they belong. No much changed on OSPF in its IPv6 version, which were mostly done to accommodate IPv6’s new address format.

Therefore, OSPF will be able to run on top of IPv6, but the IPv6 link state database will not be shared with the IPv4 one. Both IPv4 and IPv6 versions of OSPF will be running in parallel. There were very few minor changes for OSPF’s IPv6 version from the IPv4 one. They are:

• Link state records will be identified by a 128-bit field
• The routers in the network will be identified by one of their 128-bit addresses
• The network area will be identified by a 128-bit field
• The IPv6 OSPF will not use a 32-bit network mask to qualify the subnets prefixe.

Updating Routing Information Protocol

Interior gateway (or routing) protocols (IGP) are protocols which manage routing within an autonomous system, as discussed earlier in this chapter. Even though the Internet has no clear interior routing protocol "leader," Routing Information Protocol (RIP) is still very popular, although Open Shortest Path First (OSPF) seems to be the current recommended protocol, while the IS-IS discussed earlier and the proprietary EIGRP are also in some use. Older protocols such as hello and gateD are being abandoned due to technical obsolesce and inefficient, as Uyless Black ponders in his book "TCP/IP & Related Protocols", 1995, also by McGraw-Hill. Thus, something needed to be done to RIP if we were to consider it as a routing protocol option. The attempt is made with RIPv2.

RIPv2

As you probably already know, RIP uses distance-vector metrics for routing. Thus, the cost of a route in RIP is measured by the number of hops in the route, regardless of the state of the specific hops (links). With RIPv2, a packet is composed of a 32-bit header and a set of address + metric pairs describing reachable destinations. Some additional information to the route information, including some security considerations, as specified on RFC1723, is added. With that, RIP again can be considered as one of the routing protocols of choice, especially for being small, requiring very little code, and being easy to implement. All these features certainly make RIP useful for small network nodes, with memory limitations to afford more efficient protocols.

RIP operates by having each node periodically broadcast the "distance" from itself to other nodes. The metric used for the distance is simply the hop count. RIP nodes use the information broadcasted by other nodes to build routing tables from themselves to all the other nodes in the network. In essence, the network discovers its own topology through successive iterations of routing information broadcasts.

RIP has some problems, however. The iterative nature of RIP can cause routing loops in cases where the network has not yet "stabilized", leading to possible message congestion, as pointed by Huitema, in "Routing in the Internet," 1995, by Prentice Hall. Another problem with RIP is the so called "counting to infinity" problem, in which the network "discovers" a certain type of broken link only by the network nodes successively incrementing the distance metric until a value of "infinite" is reached. Because of this known problem, the value of "infinity" is set to a small value in RIP (16). This solves the problem in a way, but it can still cause slow network convergence after certain types of errors. Also, by choosing a low "infinite" value has another unfortunate effect: it limits the use of the distance metric to hop counts, because more meaningful metrics would require a larger numeric space.

Nonetheless, a version of RIP has been defined for IPv6. It was decided to keep the basics identical to RIPv2, with the new header being a straightforward extension of the RIPv2 header. This makes RIP easy to implement for IPv6 networks, although it is far from an ideal protocol.

Several other routing protocols have been or are being developed under the auspices of the International Organization for Standardization (ISO). ISO refers to the Intermediate System to Intermediate System Intradomain Routing Exchange Protocol (IS-IS) as ISO 10589. The American National Standards Institute (ANSI) X3S3.3 (network and transport layers) committee was the motivating force behind ISO standardization of IS-IS. Other ISO protocols associated with routing include ISO 9542 (End System-to-Intermediate

OSI’s ES-IS/IS-IS Routing Protocols

In OSI terminology, an end system (ES) is a (primarily) non-routing network device, whereas an intermediate system (IS) is a (primarily) routing device. All end systems in a particular routing domain (called an "area" in OSI terminology) have full access to all other end systems in the domain.

The International Organization for Standardization (ISO) has been working on several different routing protocols. Included among these are:

• ISO 9542 End System to Intermediate System (ES-IS), for use with ConnectionLess Network Protocol (CLNP). This protocol describes how ESs communicates with ISs in a connectionless environment.
• ISO 10589 Intermediate System to Intermediate System (IS-IS), an intradomain routing protocol. This protocol describes how routers communicate with other routers in the same domain.
• IDRP (IS-IS Inter-Domain Routing Protocol). This protocol describes how routers communicate with routers in different domains.

These three routing protocols form a hierarchical routing structure, where information flows from ESs to ISs using ISO 9542. ISs exchange information with other ISs in the same domain using ISO 10589, and with ISs in different domains using IDRP. To make things more complex, OSI actually have two separate versions of the ES-IS protocol. One version describes ES-IS operation on broadcast (for example, IEEE 802.3) and point-to-point subnetworks. The other version describes ES-IS operation over "general" (not broadcast or point-to-point) subnetworks (for example, X.25). The broadcast/point-to-point version is the only one of the two discussed in this chapter for its relevance.

ES-IS is simply a means for end systems and intermediate systems to find one another. ES-IS accomplishes this through "hello" packets. Hello packets convey subnets and network-layer address information. Through these exchanges, all ESs and ISs on a particular subnets can learn the physical (subnet) address and the network address of all attached network devices. Configuration information is discarded when it becomes too old.

ISO 10589 (intradomain IS-IS) is a link-state, hierarchical routing protocol based on the DECnet Phase V routing algorithm. Like ES-IS, ISO 10589 can operate over a variety of subnets, including broadcast LANs, WANs, and point-to-point links.

To simplify router design and operation, ISO 10589 distinguishes between Level 1 and Level 2 routers (ISs). Level 1 ISs know how to communicate with other Level 1 ISs in the same area. An area is a logical portion of a routing domain defined by common Level 1 ISs. Level 2 ISs know how to communicate with ISs in other areas. To summarize, Level 1 ISs form Level 1 areas; Level 2 ISs route between Level 1 areas.

Level 2 ISs form an intradomain routing backbone, getting to other Level 2 ISs by traversing only Level 2 ISs. The backbone simplifies design because Level 1 ISs now only need to know how to get to the nearest Level 2 IS. An additional benefit is that the backbone routing protocol can change without impacting the intra-area routing protocol.

ISO 10589 uses a single one-octet metric with a maximum value of 1024. Any single link can have a maximum value of 64. Path lengths are calculated by summing link values. Maximum metric values were set at these levels to provide the granularity to support various link types while at the same time ensuring that the shortest path algorithm used for route computation would be reasonably efficient. Recall that link state algorithms tend to require substantial computation. The metric is arbitrary and typically assigned by a network administrator.

IS-IS was initially defined as an OSI-specific routing protocol. As OSI and TCP/IP tend to coexist in many networks, a version of IS-IS that can run in both worlds was created. This version of OSI is called "dual IS-IS." Dual IS-IS consists of the standard OSI version of the protocol plus options to support IP environments.

The primary benefit of dual IS-IS is reduced CPU utilization. Link state algorithms are CPU intensive. With dual IS-IS, the routing algorithm is only run one time, and only one set of routing updates (with both IP and OSI information) is sent. While it is difficult to rationalize the different "network views" held by IP and OSI protocols (for example, IP considers "networks;" OSI considers "areas"), dual IS-IS is of utility in mixed environments. It is particularly useful on backbones where both types of traffic are common.

From Here:

The next chapter, "IPv6 Addressing, reviews the IPv4 addressing architecture, the different forms of IP addressing and IP subnetting. It also introduces IPv6 addressing, discussing unicast, anycast and multicast addresses and address resolution using DNS.