IPv6 Interior Gateway Protocols
| Every modern IPv4 IGP has either an IPv6 version counterpart or an extension that enables it to support IPv6. The following subsections review the four IGPs available on Cisco routers: RIPng, EIGRP for IPv6, OSPFv3, and IS-IS for IPv6. Routing Information Protocol next-generationRIP is a simple protocol in the distance vector family. That means it is simple to understand and configure, but it also means it does have some limitations. The main ones are convergence times and scaling. RIPng is basically RIP version 2 (RFC 2453) extended to handle IPv6 prefixes and next hops. Support for IPv6The IPv6 version of RIP is described in RFC 2080. It is called RIPng (RIP next generation); this reflects the code name used for the next-generation IP protocol. It has been argued that RIP should be left to "Rest In Peace." Because it is an easy protocol to implement, it was the first protocol to be supported by vendors, and therefore it saw some deployment in the early days of IPv6. Now that OSPF and IS-IS are supported, RIP is used in small deployments (for example, in a multihomed host or to pass on a default route from an ISP to a customer's CPE). There is not much new and exciting about RIPng. It supports split horizon and poison reverse as its IPv4 counterpart. It has the same limitations, such as a maximum hop count of 15, and does counting to infinity for certain routing loops. The differences between RIP (used for IPv4) and RIPng are as follows:
RIP does not directly support multiple instances of the protocol on a link. There is no instance identifier or anything like that in the message format, so if you require this functionality you will have to run RIP on a different UDP port, or use a different RIP multicast address (default FF02::9). The Cisco IOS implementation supports a maximum of four RIPng instances. Configuration ExampleConfiguring RIP on Cisco routers is straightforward. It requires that RIP be enabled on each interface, as illustrated here: interface Ethernet0/0 ipv6 address 2001:200::2/64 ipv6 rip foo enable end You can change the metric and summary information on a per-interface basis. The IPv6 router RIP mode allows for configuration of redistribution, distribute lists, and knobs for tuning RIP behavior. For example, poison reverse and split horizon can be turned on or off, and the default RIP timers can be changed for better convergence times. To verify that RIP works correctly, you can use the show command shown in Example 4-1. Example 4-1. Checking RIP Status
The show ipv6 rip command shows the status of the RIP process(es). The output includes most of the details you need to know; timers, redistribution status, and on which interfaces RIP is enabled. Routing information is stored in a local database called a routing table, also referred to as Routing Information Base (RIB). The RIB essentially contains all routes available for selection. Essentially, it is the sum of all routes learned via dynamic RPs (including RIP, for instance), all directly attached networks (networks that a given router has interfaces connected to), and any additional configured routes such as static routes. There is one RIB for IPv4, and a separate one for IPv6. There may be more than one if the VPN feature is enabled (see Chapter 7, "VPN IPv6 Architecture and Services"). Example 4-2. Rip Database Display
In addition, each RP, such as RIPng, has its own database, which you can view. The show ipv6 rip database command lists the routing database for RIP. You might see entries in this database that are not in the IPv6 RIB. For example, the RIB might already have a route with a better administrative distance. The keyword installed after a prefix indicates that it is installed in the RIB. EIGRP for IPv6The Cisco proprietary Enhanced Interior Gateway Protocol (EIGRP) was developed to bridge the gap between the traditional distance vector protocols (IGRP, RIP) and the advanced link-state protocols (OSPF, IS-IS). It integrates some of the proven capabilities of the latter to improve the operation and the scalability of the former. Nevertheless, the intent was to avoid some of the topological constraints that are sometimes associated with link-state protocols. The result is a simple yet fast converging, resilient, and scalable routing protocol that is largely adopted in many enterprise networks as well as the edge of some ISP networks. The protocol is extensively discussed in the book EIGRP Network Design Solutions, by Ivan Pepelnjak; but in summary, EIGRP is a distance vector routing protocol based on IGRP that offers the following improvements:
To meet the routing needs of enterprise networks, EIGRP has a modular design with protocol-independent core functionality and protocol-dependent modules that enable it to be used for IPv4, IPX, and AppleTalk. Support for IPv6The large deployed base for EIGRP drove the demand for extending its capabilities to support IPv6. The modular implementation of EIGRP simplifies the implementation. It requires the introduction of another protocol-dependent module for IPv6 (protocol identifier 88 was chosen, the same as IPv4) and three new TLVs (IPv6_REQUEST_TYPE [0X0401], IPv6_METRIC_TYPE [0X0402] and IPv6_EXTERIOR_TYPE [0X0403]). EIGRP for IPv4 and EIGRP for IPv6 have strong similarities. Both implement the "diffusing update algorithm," developed by J. J. Garcia-Luna-Aceves based on work by E. W. Dijkstra and C. S. Scholten in 1980. A few differences exist due to some specific aspects of IPv6:
EIGRP for IPv6 will be enabled to operate within virtual private networks (VPNs) in a similar way as EIGRP for IPv4. Scalability characteristics of EIGRP for IPv6 differ from EIGRP for IPv4 mainly due to the need for extra memory resources. Configuration ExampleSimilar to all other IPv6 RPs, EIGRP for IPv6 is enabled on a per-interface basis. If a router is able to acquire its ID from an IPv4 address existent on it, the EIGRP for IPv6 protocol configuration is simple, as illustrated here: interface Ethernet0 ipv6 enable ipv6 eigrp 100Note The EIGRP process does not start on an interface unless the ipv6 enable command is present under that interface. If the router is IPv6 only, a router ID has to be explicitly configured under the EIGRP process, as illustrated here: ipv6 router eigrp 100 Router-id 10.10.10.1Note When configured, the EIGRP process is by default shut down and an explicit no shutdown is necessary to get it started. Once configured, you can use the following show command to display EIGRP-relevant operational parameters. Example 4-3. Displaying EIGRP Parameters
When established, adjacencies are pointing to the link-local address of the neighbor, as shown in Example 4-4. Example 4-4. EIGRP Neighbor Status
The EIGRP for IPv6 topology is independent of IPv4, and when queried, the all-links option should be used to view all equal-cost paths when present, as shown in the following show command. Example 4-5. EIGRP Topology
With minor syntax modifications, the commands available for tweaking or troubleshooting EIGRP for IPv4 are available for IPv6, too. For example, the command that enables MD5 authentication for a given interface would in this case be ipv6 authentication mode eigrp 100 md5. Considering their similar mode of operation, you should use the same configuration and troubleshooting guidelines for IPv6 as for IPv4, such as those discussed in the book EIGRP Network Design Solutions, by Ivan Pepelnjak. OSPFv3OSPF is an IGP used to distribute routing information between routers of a single autonomous system. OSPF is based on link-state technology, described briefly in the "Overview" section. The IPv4 version is specified in RFC 2328. Routers running OSPF advertise link state, link prefix/mask, link weight, and other local connectivity parameters in link-state advertisements (LSAs). These LSAs are flooded reliably to other routers in the network to ensure that every OSPF router has a complete and consistent view of the topology. On broadcast and Non-Broadcast Multiple Access (NBMA) networks, a designated router (DR), elected during neighboring relationship establishment (Hello protocol) can help reduce the amount of control traffic necessary for this operation, by acting as a relay between OSPF routers for LSAs. A backup designated router (BDR) is also elected. The BDR picks up the functions of a failed DR with no need of a new election process. OSPF allows sets of networks to be grouped together into regions called areas. A router maintains a topology database for each area it participates in, and the topology of an area is hidden from the rest of the autonomous system. Areas constitute a useful concept that enables a two-level routing hierarchy, a concept that helps improve scalability. Routers do not need to maintain a topology database for areas they do not belong to, which leads to significant reduction in routing traffic. Route summarization can occur on the area borders, another way to reduce the routing traffic. For securing routing distribution and installation, OSPFv2 defines fields AuType and Authentication in its protocol header (RFC 2328). Finally, OSPF has built-in support for classless interdomain routing (CIDR). (Each route distributed by OSPF has a destination and mask.) For in-depth information on OSPF, refer to the book OSPF: Anatomy of an Internet Routing Protocol, by John T. Moy. Support for IPv6OSPFv3 extends OSPF to provide support for IPv6, as specified in RFC 2740. The basic mechanisms already used by OSPFv2, such as flooding, DR election, area support, SPF calculations, and so on, remain applicable to OSPFv3. Neighboring routers are still identified by the 32-bit router ID in OSPFv3. However, changes in protocol semantics between IPv4 and IPv6, as well as changes in the address format, have led to significant changes in OSPFv3 compared to OSPFv2. The two versions of the OSPF protocol operate independently of each other, on disjoint databases. There is no backward compatibility from OSPFv3 to OSPFv2. Extensions have been proposed to adapt OSPFv3 as an "integrated model," where OSPFv3 would be extended to calculate IPv4 routes. This is still a work in progress at the IETF. Two proposals are being discussed: "Multi-topology routing in OSPFv3" (Internet Draft; Sina Mirtorabi, Abhay Roy) and "Support of address families in OSPFv3" (Internet Draft; Mirtorabi, S., et al.). A Cisco implementation is already available that provides a unified command-line interface (CLI), as shown in Example 4-6. Example 4-6. Unified OSPF Configuration Example
A main goal of OSPFv3 was to create a routing protocol independent of any specific network layer. To achieve this, OSPFv3's inter-router messages have been redesigned, and addressing semantics have been removed from OSPF packets and from the basic LSAs. In OSPFv3, LSAs such as router LSAs and network LSAs only carry topology information. The following LSAs have been created to carry IPv6 addresses and prefixes:
The following LSAs have been modified:
OSPFv3 runs on a per-link basis rather than on a perIP subnet basis as in OSPFv2. When OSPF peering occurs over a physical link, OSPF packets are sent using the interface link-local unicast address as source. The flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol itself, instead relying on IPv6's Authentication Header (AH) and Encapsulating Security Payload (ESP). Most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4, even with the larger IPv6 addresses. OSPFv3 supports the ability to run multiple OSPF protocol instances on a single link. The OSPFv3 packet header includes an 8-bit instance ID used to demultiplex the protocol packets. Each OSPFv3 process sets its configured instance value in the OSPFv3 packets that it sends, and ignores received packets with instance values from other OSPFv3 processes. Instance IDs can control communication between routers sharing a physical network and OSPF area, without relying on complex authentication schemes or access lists, as needed in the past. It enables the providers to run separate OSPF routing domains even though they have one or more physical network segments in common. Configuration ExampleConfiguring OSPFv3 on Cisco routers on a broadcast network is straightforward. It requires just enabling OSPF on each interface participating in the OSPF area, as illustrated in Example 4-7. Example 4-7. OSPF Configuration Example
On NBMA interfaces, the neighbor is explicitly configured. Example 4-8. OSPF Configuration on Interface
In addition, if the OSPF router does not have an IPv4 address configured, a router ID must be configured. This is done under IPv6 router mode. Other useful options can be configured under IPv6 router mode, such as enabling routes summarization at an area boundary or enabling authentication for an OSPF area, as illustrated in Example 4-9. Example 4-9. OSPF Options
Finally, to verify proper OSPF configuration, you can use the following show command. Example 4-10. OSPF Status
The show commands display the process ID and OSPF router ID, the configured LSA timer values, the number of areas, and details about each. IS-IS for IPv6The Intermediate System-to-Intermediate System (IS-IS) protocol is described in ISO Standard 10589. This link-state, OSI routing protocol was not originally developed for IP but rather to provide the routing functionality between the routers of Connectionless Network Protocol (CLNP)-based networks. With the addition of IPv4 support (RFC 1195), the protocol, sometimes referred to as Integrated IS-IS (I/IS-IS), was widely adopted as the IGP of choice for many ISP and large enterprise networks. (For more information, refer to the book IS-IS: Deployment in IP Networks, by Russ White and Alvaro Retana. In many respects, IS-IS is similar to OSPF, but some terminology and implementation differences do exist. For example, packet encoding in IS-IS is Type Length Value (TLV) based and makes the protocol easily extensible. Nested TLVs also offer granularity in the protocol extensions. The link state, link prefix/mask, link weight, and other local connectivity parameters are advertised in link state packets (LSPs). Unlike the OSPF LSAs that are exchanged at the IP level, the IS-IS LSPs are exchanged at layer 2. This makes IS-IS less vulnerable to spoofing or other attacks. Note Before deploying IS-IS in an IPv6 network using tunnels, it is important to make sure that the tunneling mechanisms used can forward the IS-IS LSPs. Similar to OSPF, IS-IS also elects a DR, called a designated intermediate system (DIS). The DIS, however, does not select a BDR. Should the DIS fail, a new DIS election process is started. Notably, IS-IS does not have direct support for NBMA networks. IS-IS implements a two-level routing hierarchy as well, an important feature for scalability. Despite that, most IS-IS deployments are rather flat. Unlike OSPF, where interfaces are bound to areas (thus enabling routers to belong to multiple areas), in IS-IS the routers belong to a single area. A router (called intermediate system, or IS) performing intra-area functions is a level 1 router. A router performing inter-area functions is a level 2 router. IS-IS, like OSPF, supports authentication, it supports CIDR, and it transports MPLS traffic engineering link information. Both protocols are deployed in enterprise as well as ISP networks (with OSPF more common in enterprise networks, and IS-IS more common in large ISP networks). Support for IPv6The third network protocol supported by I/IS-IS is IPv6 (draft-ietf-isis-ipv6-02.txt). The implementation required a new protocol ID (0X8E) that was set to be used by the IPv6 routers to signal their capability to support ISISv6 and two new TLVs: IPv6_Reachability (0XEC) and IPv6_Interface_Address (0XE8). Extending IS-IS to support IPv6 is an exercise similar to extending it to support IPv4, unlike OSPF where a new protocol had to be developed. For this reason, IS-ISv6 is operationally similar to IS-ISv4. Few IPv6-specific differences exist. Neighbors are listed in the adjacency table with their link-local address. Because the link-local is used in the Hello packets, adjacencies can be built between neighbors even if they do not share the same prefix. From a user perspective, a new address family was added for IPv6. Most configuration commands available for IS-ISv4 are also available for IS-ISv6 with minimal format changes. IS-IS uses a single topology and runs the same SPF calculation for all protocols supported. This mode of operation leads to certain deployment constraints. Single TopologyBy default, IS-IS runs with a single topology for all protocols supported and a single instance of the SPF calculation per level (1 = area, 2 = domain). This could be a benefit in that fewer resources are being used by the routers to operate it. On the other hand, the single topology mode comes with some restrictions:
This need for capabilities consistency raises this question: What will happen when an IS-ISv4 network is migrated to the IS-ISv4+IS-ISv6 network? Because routers are configured with the additional IPv6 address family, the adjacencies will be dropped until the consistency is reestablished. To avoid impacting the operating IPv4 service, you can disable the adjacency checking. Note To avoid inconsistencies in the operational network, only disable adjacency checking during the migration process. MultitopologyIS-IS was later enhanced to support independent topologies and SPF calculations for each protocol (draft-ietf-isis-wg-multi-topology.txt). In this case, various routers can support different sets of address families. To add multitopology support for IPv6, a new Multi_Topology_Reachable_IPv6_Prefixes TLV is defined. The multitopology operation can be enabled under the IPv6 address family. In this mode of operation, you can set the IPv6 metric independently of the IPv4 one. To facilitate the migration from single topology to multitopology, you can enable a transition mode. In this case, both types of TLVs are advertised in LSPs. Larger LSPs are thus traded off for a smooth transition. Configuration ExampleThe simplest way to configure a router to run IS-IS for IPv6 is to enable the protocol on an interface with an IPv6 address. No changes are needed to the configuration of the IS-IS process for IPv4, as illustrated in Example 4-11. Example 4-11. IS-IS Configuration Example
Note You must configure IPv6 on the interface for the IS-ISv6 process to start. In this example, IS-IS is operating in single-topology mode. The show ipv6 protocol command indicates that IS-IS is running on the interface (highlighted below). The adjacencies built with other routers show both IP protocol addresses, as highlighted in Example 4-12. Example 4-12. ISIS Neighbor Status
The IPv6 adjacency is identified through the link-local address, so the global prefix configured on the interface is not relevant for it. A look at the database reveals the capabilities of the neighbors. The following output obtained from the show isis command illustrates the level 1 circuit of the Router2 neighbor. Example 4-13. IS-IS Database
The protocol ID number 8E indicates the support for IPv6. Because in this case IS-IS runs a single topology, no distinction is made in the output between IPv4 and IPv6. By the same token, there is no output for show isis ipv6 topology. Further protocol customization can be done similar to IPv4, from enabling authentication and summarization to adjusting metrics. The important thing to remember is that in the single-topology mode, you cannot configure the changes on a per-protocol basis. If the network design requires the two IP protocols to operate independently at the cost of more router resources used by the two instances of the protocol, you can migrate IS-IS to a multitopology mode. In this case, you specifically configure the IPv6 address family under the IS-IS process, as shown in the configuration excerpt in Example 4-14. Example 4-14. Migrating IS-IS to Multitopology Mode
The transition option is elected to allow routers in different modes to coexist during the migration. You should remote this option when the migration is completed. With the change to the new operation mode, the outputs of the show commands reflect the existence of two distinct topologies for the two IP protocols. Example 4-15. Multitopology IS-IS Neighbor Details
You can now view the IPv6-specific topology. Example 4-16. Multitopology IS-IS Topology
The database information also reflects the multitopology mode of operation. Example 4-17. Mutiltopology IS-IS Database
Again, the configuration can be detailed further as it is done in IPv4. In this mode, however, you can tweak the IS-IS operation independently for each protocol with commands such as isis ipv6 metric that adjust the metric on an interface only for IPv6. |
EAN: 2147483647
Pages: 130