Tcpdump output 23:55:58.367717 OSI, IS-IS, length: 97 L1 Lan IIH, hlen: 27, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0) source-id: 0000.0000.0003, holding time: 40s, Flags: [Level 1, Level 2] lan-id: 0000.0000.0003.02, Priority: 64, PDU length: 97 Protocols supported TLV #129, length: 2 NLPID(s): IPv4 (0xcc), IPv6 (0x8e) [… ] Restart Signaling TLV #211, length: 3 Flags [none], Remaining holding time 0s Checksum TLV #12, length: 2 checksum: 0x0000 (unverified) Authentication TLV #10, length: 17 HMAC-MD5 password: 887d36216cc6b0c842b1b25a1b11880d It is the authors’ opinion that the Checksum TLV should be present per default in IIHs and SNPs if no authentication or simple text authentication is configured. Users should not need to configure it as they do now. It should be rather a default option of the router OS. Once HMAC-MD5 authentication is configured for SNPs and IIHs, the Checksum TLV #12 should be omitted entirely because the 128-bit MD5 checksum is much stronger than the Fletcher checksum. Unfortunately not all IS-IS implementations follow the open spirit of ISO 10589 where an unknown TLV is silently ignored. Those imple- mentations tend to log error messages about the unknown TLV and refuse to take adja- cencies up, which left the implementers with not many choices and causes contemporary IS-IS implementation to be as gentle as possible with introduction of new TLVs. IS-IS is ignorant of the Network Layer prefixes that it transports. RFC 1195 defined a set of TLVs that are used to carry IPv4 Prefixes. Similarly, IS-IS needs a set of TLVs for carrying IPv6 related information. These are discussed in the next section. 13.4 IPv6 Extensions The most important TLV for multi-protocol operation is the Protocols Supported TLV #129, illustrated in Figure 13.9. The Protocols Supported TLV #129 lists all the protocols 370 13. IS-IS Extensions Type Length NLPID 129 Bytes 1 1 1 NLPID 0xCC 0x8E 1 FIGURE 13.9. The Protocols Supported TLV #129 lists all protocols that the router supports that an individual router supports. This TLV is found both in IIHs and LSPs. However, it will be shown later that the inclusion of this TLV in the router’s LSP is a next to useless exercise. The TLV contains a list of one-byte Network Layer Protocol ID (NLPID). Each major Network Protocol has an NLPID assigned. In modern networks, you will most likely see the NLPID for IPv4 (ϭ 0xCC), CLNS (ϭ 0x81) or IPv6 (ϭ 0x8E). The IPv6 extensions are specified in draft-ietf-isis-ipv6-06. This Internet draft men- tions two TLVs which are aligned to their IPv4 counterparts, but just bigger in size. A nice touch of the IS-IS WG was to emphasize this similarity by picking a similar number for this TLV. Figure 13.10 illustrates the IPv6 Interface TLV #232. The TLV shares the semantics of its little sibling, the IPv4 Address TLV #132 that is described in Chapter 5, “Neighbour Discovery and Handshaking”, in Figure 5.14. The TLV holds one or several IPv6 addresses that are assigned on the sending inter- face. Hence the TLV is in multiples of 16 bytes. Typically only a single address, the IPv6 link-local address, is conveyed. Surprisingly, there is not much to configure in order to run IPv6 over IS-IS. Configuring an IPv6 Address and activating the IS-IS on that interface is enough. The router starts to send IIHs that contain the IPv6 address on that interface, plus the IPv6 NLPID in the Protocol Supported TLV #129. The tcpdump output highlights the IPv6 additions. Tcpdump output 23:55:58.367717 OSI, IS-IS, length: 72 L1 Lan IIH, hlen: 27, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0) source-id: 1921.6800.1008, holding time: 40s, Flags: [ L1L2 IS] lan-id: 1921.6800.1008.02, Priority: 64, PDU length: 72 Protocols supported TLV #129, length: 2 NLPID(s): IPv4 (0xcc), IPv6 (0x8e) [… ] IPv4 Interface address(es) TLV #132, length: 4 IPv4 interface address: 172.16.33.237 IPv6 Interface address(es) TLV #232, length: 16 IPv6 interface address: fe80::7777:69ff:fea0:8001 Area address(es) TLV #1, length: 4 Area address (length: 3): 49.0001 IPv6 Extensions 371 TLV Type TLV Length IP6 Address 232 Bytes 1 1 16 16 N * 16 IP6 Address FIGURE 13.10. The IPv6 Interface Address #232 shares similar semantics to the IPv4 Interface Address TLV #132 After the adjacency has formed, the router sends an updated LSP that contains the sec- ond IPv6 TLV that is defined in draft-ietf-isis-ipv6-06. Figure 13.11 illustrates the IPv6 Reachability TLV. The TLV structure does seem similar and is borrowed from the Extended IPv4 Reachability TLV #135 explained in Figure 12.11 of Chapter 12, “IP Reachability Information”. TLV #236 is not as densely packed as TLV #135, but mostly because the maximum prefix length of an IPv6 prefix (128 bytes) could not be stuffed into a single byte along with the Flag bit information like the Up/Down bit and Sub-TLV Indicator bit. Tcpdump output is shown below for the IPv6 Reachability TLV. 372 13. IS-IS Extensions TLV Type TLV Length metric Reserved Prefix optional all-subTLVs Length optional subTLV Type U/D optional subTLV Length optional subTLV Value 236 Bytes 1 1 4 1 0–16 1 1 1–246 E S Prefix Length 1 1 metric Reserved Prefix optional all-subTLVs Length optional subTLV Type U/D optional subTLV Length optional subTLV Value 4 1 0–16 1 1 1Ϫ* E S Prefix Length 1 1 FIGURE 13.11. The IPv6 Reachability TLV #236 took the Extended IPv4 Reachability TLV #135 as its blueprint Tcpdump output 01:15:43.232457 OSI, IS-IS, length: 182 L2 LSP, hlen: 27, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0) lsp-id: 1921.6800.1008.00-00, seq: 0x00000033, lifetime: 65530s chksum: 0xdde3 (correct), PDU length: 182, Flags: [ L1L2 IS ] Area address(es) TLV #1, length: 4 Area address (length: 3): 49.0001 Protocols supported TLV #129, length: 2 NLPID(s): IPv4 (0xcc), IPv6 (0x8e) [… ] IPv6 Reachability TLV #236, length: 22 IPv6 prefix: 2001:600::3/128, Distribution: up, Metric: 0, Internal, no sub-TLVs Extended IS Reachability TLV #22, length: 17 IS Neighbor: 1921.6800.1021.00, Metric: 250000, sub-TLVs present (6) IPv4 interface address subTLV #6, length: 4, 172.16.33.237 In the following two sections there will be IPv6 configuration examples for both IOS and JUNOS. 13.4.1 IOS Configuration In IOS the configuration is aligned to the IPv4 style: configuring an IP address and acti- vating IS-IS on the router is enough. For IPv6, the ipv6 address and the ipv6 router isis configuration command include the IPv6 prefix in the router’s link-state database and rebuilds the router’s LSP. IOS configuration For including an IPv6 Address in IS-IS all you need to do is configure the ipv6 router isis keyword in the interface stanza. London# show running-config [… ] interface FastEthernet0/0 [… ] ipv6 address 2001:708:0:FF19::1/64 ipv6 router isis ! Next you may want to verify that the prefix gets installed in the link-state database. IOS command output You need to spot on IPv6 prefixes in the show isis database detail output. IPv6 Extensions 373 London#show isis database detail IS-IS Level-2 LSP LSPID LSP LSP LSP Holdtime ATT/P/OL Seq Num Checksum Frankfurt.00-00 0x00000023 0xBA64 3555 0/0/0 Area Address: 49.0001 NLPID: 0xCC 0x8E Router ID: 192.168.1.8 IP Address: 192.168.1.8 Hostname: Frankfurt Metric: 250000 IS-Extended Washington.00 [ ] Metric: 250000 IPv6 2001:708:0:FF19::2/64 [ ] Finally you need to check if the route made its way in the IPv6 routing table. IOS command output The show ipv6 route isis command limits the output to the isis installed routes. London# show ipv6 route isis IPv6 Routing Table - 9 entries Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 I2 2001:708:0:FF19::2/64 [115/13] via FE80::2A0:A5FF:FE12:3398, GigabitEthernet2/0 [… ] The JUNOS configuration is similar, but simpler than the IOS configuration. 13.4.2 JUNOS Configuration In JUNOS you need to configure two different stanzas. First, you need to configure the IPv6 address on a logical interface. Next, you add “family ISO” in order to be able to exchange IS-IS PDUs over that link. Finally, that interface is added to the interface list that the IS-IS router builds when IS-IS is enabled. JUNOS configuration As soon as family inet6 is configured on a referenced iso interface JUNOS starts to announce IPv6 Reachability Information. 374 13. IS-IS Extensions hannes@Frankfurt> show configuration [… ] interfaces { so-1/2/0.0 { unit 0 { [… ] family iso; family inet6 { address 2001:708:0:FF19::2/64; } } } } protocols { isis { interface so-0/1/2.0; } } JUNOS command output IP6 Reachability Information are indicated by the V6 prefix string of the show isis database detail operational command output. hannes@Frankfurt> show isis database detail [ ] Frankfurt.00-00 Sequence: 0x23, Checksum: 0xba64, Lifetime: 3433 secs IS neighbor: Washington.00 Metric: 250000 [… ] V6 prefix: 2001:708:0:FF19::2/64 Metric: 0 Internal Up Finally you can verify if the route was installed in the main routing table. You can dis- play the route using the show route table inet6.0 operational level command. JUNOS command output The show route table inet6.0 protocol isis limits the output to isis installed routes. hannes@Frankfurt> show route table inet6.0 protocol isis inet6.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) ϩϭActive Route, ϪϭLast Active, * ϭ Both 2001:708:0:FF19::2 *[IS-IS/18] 00:24:29, metric 15 > to fe80::203:fdff:fec8:3c00 via so-1/2/0.0 So far it was assumed that the router is running IPv4 and IPv6 in dual mode. Dual mode is a term borrowed from RFC 1195 which means that two protocols share a single SPF topology calculation and there is an assumption that the topology is congruent. That assumption may not be always correct, and there are scenarios where the dual assump- tion breaks even simple things like adjacency formation. IPv6 Extensions 375 13.4.3 Deployment Scenarios RFC 1195 introduced the Protocol Supported TLV #129. The TLV is used for two purposes: • Convey the supported protocols during adjacency formation in IIHs • Convey the supported protocols for SPF pruning in IIHs During adjacency formation, both routers verify that they have a common set of protocols on a link. The reason is simple: if one side supports IPv6 only and the other side supports IPv4 only then there is no reason to let the adjacency go Up. That behaviour violates ISO 10589, which mandates that adjacency formation should be decoupled from any Network Layer reachability protocol. However, the deployed reality moves things into a different per- spective. If there is no common Network Layer protocol then the system does not let the adjacency come Up. Figure 13.12 illustrates why there are good reasons to do so. On almost all links in the network in the figure, both IPv4 and IPv6 are supported. But the link between London and Frankfurt is misconfigured. London only runs IPv6 and Frankfurt only runs IPv4. Assume for a moment that the routers comply with the spirit of ISO 10589 and then the adjacency between London and Frankfurt goes Up. From Washington’s perspective, the shortest path to London is now via Frankfurt (1). However, if traffic is relayed via Frankfurt then it gets sent back because from Frankfurt’s perspec- tive the way back to Washington is the shortest path. A routing loop is created. The JUNOS and IOS implementation of IS-IS both offer protection from such faults. However, they cannot protect from every fault. Consider what happens if London addi- tionally activates IPv4 on its link to Frankfurt. Because the adjacency does find a com- mon protocol, which is IPv4, it takes the adjacency Up. Unfortunately the problem still persists. There is a routing loop for traffic from Washington to London. More restrictive adjacency management (for example) could mandate that all NLPIDs inside the Protocols Supported TLV #129 need to match – however, that might be highly disruptive when, for example, another Network Layer protocol is added. The problem is that there is no way for the IS-IS router to tell remote routers that the underlying link does not support IPv6. That implies that all links need to carry both IPv4 and IPv6. That raises the question if it is necessary to upgrade a network from IPv4 to IPv6 all at once on a flag day. We want to discourage any flag day transitions – in our pro- fessional careers, the authors have never, ever seen a flag-day migration that worked well. Typically what has happened, even in the best-planned migrations, is that one hour before that maintenance window closes, all the changes have to be undone because of persistent problems in the network. Even if a decision to go forward was made, then there were creeping errors in the entire network for the next few days. We still are not sure if these experiences are related to flaky routing software, or if it is just a fact that Murphy’s Law always bites on flag days. There are two approaches to IPv6 and the flag day problem: • change the protocols and make the SPF calculation aware of a link that supports IPv6 • deploy IPv6 based on a “convex” topology Changing the underlying protocols to support several SPF calculations is an approach that is described in the “Multi Topology Extensions” after this section. We focus here on 376 13. IS-IS Extensions IPv6 Extensions 377 oc192/STM-64 87000 oc12/STM-4 600000 oc192/STM-64 250000 oc768/STM-256 22000 oc768/STM-256 22000 oc48/STM-16 315000 oc48/STM-16 315000 oc192/STM-64 26000 6464 64 64 4 6 64 IPv4 only circuit IPv6 only circuit dual circuit Pennsauken Frankfurt London Washington New York Paris 4 664 64 64 64 64 64 6464 1 2 FIGURE 13.12. Protocol dependent adjacency management is imperative to avoid routing loops deploying a convex style. Figure 13.13 illustrates how the IPv6 protocol is enabled in four steps. First, IPv6 is activated on the link between Pennsauken and London (1). Next, Pennsauken to New York is included (2). In the next two steps, (3) and (4), it is important to include all nodes in expanding circles. Whenever there is a mesh, it needs to be included in the circle, otherwise it may be outside the best path. Convex topologies are not always easy to compute (at least not for humans). In mod- erate to complex topologies it is recommended to let the router figure out where the link topology can carry IPv6 and where it can not. A similar problem exists for IPv4 unicast topologies. There are links and nodes that do support multicast processing and others that 378 13. IS-IS Extensions New York London Pennsauken Frankfurt London Washington New York Paris 2 3 4 1 FIGURE 13.13. Convex topologies are required to rollout IPv6 in an incremental fashion do not. For learning about the per-protocol processing capabilities of an IS-IS network the IETF has defined the multi topology extensions. 13.5 Multi Topology Extensions The IGP evaluates all the paths in a single topology per level and selects by means of the SPF algorithm the best path among all the feasible paths. Topology discovery and SPF calculation is carried out in a protocol neutral fashion because it is done at the OSI-RM Layer 2. If we load the topology with a certain protocol (for example IP) reachability information then the assumption is that the circuits that are supposed to provide reachability between routers can also carry the respective protocol. Since the first IP migra- tions, it was clear to the ISP community that a new paradigm was needed in order to avoid flag-day style migrations. What is necessary to get around the assumptions of RFC 1195 is a proper per-address family orientation rather than a pure per-link orientation. As a result of that, a per-protocol SPF calculation is required also, which means additional CPU load. Today multiple SPF runs are easy to do because plenty of processing power is available on router control plane CPUs. The multi topology extensions remodel existing TLVs and augment them with a so-called Topology ID. Each router in a given topology maintains its adjacencies and runs a per-topology SPF calculation. A topology is the set of joined nodes. The specification mentions a list of well-known topologies, which are: • IPv4 Unicast (#0) • In-Band Management (#1) • IPv6 Unicast (#2) • Multicast (#3) • IETF Consensus (#4-#3995) • Experimental (#3996-#4095) We will focus here on the IPv4 and IPv6 Unicast topology. Consider Figure 13.14. The black lines indicate link membership in the IPv6 topology. And the gray line indi- cates membership to the IPv4 topology. Note that the two topologies are neither con- gruent nor convex. Using regular TLVs, it would not be possible to build multiple topologies and run an SPF calculation based on it. The multi topology extensions first describe an extension to carry the set of supported protocols in the Hello. Figure 13.15 shows the structure of the Topology Supported TLV #229, which is a vector of 12-bit wide Topology IDs. After activating multi topology support on a link, it should carry all the topologies that the underlying circuit is able to relay. The tcpdump output shows a IIH after multi topology activation. IPv6 Extensions 379 . activating the IS-IS on that interface is enough. The router starts to send IIHs that contain the IPv6 address on that interface, plus the IPv6 NLPID in the Protocol Supported TLV #129. The tcpdump. acti- vating IS-IS on the router is enough. For IPv6, the ipv6 address and the ipv6 router isis configuration command include the IPv6 prefix in the router’s link-state database and rebuilds the router’s. if the route made its way in the IPv6 routing table. IOS command output The show ipv6 route isis command limits the output to the isis installed routes. London# show ipv6 route isis IPv6 Routing