IS-IS IPv6 Support and Multi-Topology (TLV 236 / MT ID 2)

IS-IS carries IPv6 routes as well. While OSPF needed a separate protocol, OSPFv3, to support IPv6, IS-IS only needed a couple of new TLVs.

However, if IPv4 and IPv6 are treated as one topology, routing breaks as soon as a link without IPv6 is mixed in. Multi-topology avoids that. This article shows how IS-IS represents IPv6, and what changes between single-topology and multi-topology, verified on IOS XR.

Why IS-IS can carry IPv6

IS-IS is not an IP protocol. It was designed for CLNP in the OSI model, and IP routes are carried inside TLVs (Type-Length-Value), a variable-length container (the basics are in What is IS-IS, and TLVs in Major IS-IS TLVs).

Because the TLV number determines what kind of route is carried, supporting IPv6 only requires defining IPv6 TLVs. RFC 5308 does exactly that: it adds two TLVs and changes neither the PDU format nor the SPF calculation.

The TLVs that express IPv6 reachability

TLV	Name	Contents
236 (0xEC)	IPv6 Reachability	An IPv6 prefix and its metric
232 (0xE8)	IPv6 Interface Address	The router’s IPv6 interface addresses

The structure of TLV 236 is shown below. The metric is 32 bits and spans two rows of the diagram.

The IPv6 Reachability TLV (236) in RFC 5308
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = 236   |    Length     |          Metric ..            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          .. Metric            |U|X|S| Reserve |  Prefix Len   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Prefix ...

There are three flags.

Bit	Name	Meaning
U	up/down bit	The prefix was leaked from a higher level to a lower one (see route leaking)
X	external original bit	The prefix was redistributed from another protocol
S	sub-TLV present bit	Whether sub-TLVs follow

Because the metric is 32 bits, carrying IPv6 assumes extended (wide) metrics. The 6-bit narrow metric only exists in the IPv4 TLVs 128 and 130 (see IS-IS metrics). The path limit MAX_V6_PATH_METRIC is 0xFE000000, and any path exceeding it during SPF is clamped to that value. Link-local addresses must not be advertised in TLV 236.

Single-topology and its limits

Since only TLVs were added, there is still one kind of LSP. A router puts IPv4 routes (TLV 135) and IPv6 routes (TLV 236) side by side in a single LSP, and receivers derive both from one SPF run. That is single-topology (ST).

It is simple, but it assumes IPv4 and IPv6 share the same topology. SPF only uses the information about which router is adjacent to which (TLV 22), and that carries no distinction between IPv4 and IPv6.

Migration to IPv6 usually proceeds one region at a time, which means the topologies almost always differ during the transition.

Multi-topology

RFC 5120 solves this by allowing several topologies. Each topology has an MT ID, and SPF runs independently per MT ID.

MT ID	Purpose
0	The standard topology (IPv4)
1	IPv4 in-band management
2	IPv6 routing topology
3 / 4	IPv4 / IPv6 multicast
5	IPv6 in-band management

Multi-topology uses dedicated TLVs that prepend a two-byte MT ID to the existing ones.

TLV	Name	Non-MT equivalent
229	Multi-Topology	— (advertises the topologies joined)
222	MT Intermediate Systems	22 (extended IS reachability)
235	MT Reachable IPv4 Prefixes	135 (extended IP reachability)
237	MT Reachable IPv6 Prefixes	236 (IPv6 reachability)

The topologies a router belongs to are advertised in TLV 229 inside IIH (hello) packets. However, advertising it is optional when MT ID 0 is the only topology.

Whether an adjacency forms depends on the type of link.

Link type	Rule
point-to-point	A router should not form an adjacency without at least one common MT (SHOULD NOT, 2.1)
broadcast	Routers always form an adjacency, even without a common MT (SHALL, 2.2)

Broadcast always forms an adjacency so that routers on the same LAN can build a consistent pseudonode LSP through the DIS (the DIS and pseudonodes). This article’s lab used only point-to-point links, so the broadcast behaviour was not observed.

Configuration on IOS XR

The IOS XR default is multi-topology. Adding address-family ipv6 unicast is enough, and the LSP then carries TLVs 229, 222 and 237. To use single-topology instead, configure single-topology explicitly.

Enabling IPv6 in IS-IS on IOS XR
router isis 1
 address-family ipv6 unicast
  metric-style wide
 !
 interface GigabitEthernet0/0/0/0
  address-family ipv6 unicast
   metric 10
  !
 !
!

On IOS XR, whether an adjacency forms is decided by the topologies configured on the interface. With single-topology in place, removing IPv6 from an interface leaves it unable to participate in any topology, so the adjacency goes down, IPv4 included.

Verification on real devices

Lab environment

Four XRd routers (IOS XR 26.1.1) in a square: a single area 49.0001, all routers level-2-only, all links point-to-point, metric-style wide, and metric 100 on the R1-R4 link only.

IS-IS IPv6 and multi-topology lab topology

R1-R4 uses 100 because, with a plain square, R1 reaches R3 over two equal-cost paths of 20 and a traceroute could not show that the path changed. With this design, IPv4 always takes R1-R2-R3 (cost 20). When IPv6 cannot use R2-R3, it takes R1-R4-R3 (cost 110) instead.

Router	Lo0 (IPv4)	Lo1 (IPv6)
R1	1.1.1.1/32	2001:db8:1::1/128
R2	2.2.2.2/32	2001:db8:2::2/128
R3	3.3.3.3/32	2001:db8:3::3/128
R4	4.4.4.4/32	2001:db8:4::4/128

Traffic is measured between R1 and R3, with both IPv4 and IPv6 ping and traceroute captured at every STEP.

The STEPs

STEP	Change	What it shows
0	IPv4 only (initial state)	The IPv4 routes and the LSP contents
1	Enable IPv6 on every router and link	That the default is MT (TLVs 229 / 222 / 237)
2	`single-topology` on every router	That the TLVs change to 236 / 232
3	Remove IPv6 from R2-R3 (still ST)	That the link becomes unusable under ST
4	Remove `single-topology` everywhere (to MT)	That only IPv6 detours and connectivity returns
5	Restore IPv6 on R2-R3	That both topologies match and the shortest path returns
6	Put `single-topology` back on R2 only	How a mismatch between routers breaks things
7	Return R2 to MT	That it recovers
8	Make R1-R4 a link with no common MT	That no adjacency forms (RFC 5120, 2.1)
9	Restore R1-R4	That it recovers
10	Set the IPv6 metric of R1-R2 to 1000	That each topology can take a different path

The LSP contents differ between ST and MT (STEP 1 and 2)

STEP 1 is the state right after adding address-family ipv6 unicast. Two MT: lines appear in R1’s LSP, and the IPv6 routes and IS reachability are carried as MT (IPv6 Unicast). The IOS XR default is multi-topology.

STEP 1: R1's LSP (default, multi-topology)
R1.00-00            * 0x0000000b   0xa55e        1100 /*            0/0/0
  Area Address:   49.0001
  LSP MTU:        1492
  NLPID:          0xcc
  NLPID:          0x8e
  MT:             Standard (IPv4 Unicast)
  MT:             IPv6 Unicast                                 0/0/0
  IP Address:     1.1.1.1
  IPv6 Address:   2001:db8:1::1
  Hostname:       R1
  Metric: 10         IS-Extended R2.00
  Metric: 100        IS-Extended R4.00
  Metric: 10         MT (IPv6 Unicast) IS-Extended R2.00
  Metric: 100        MT (IPv6 Unicast) IS-Extended R4.00
  Metric: 0          IP-Extended 1.1.1.1/32
  Metric: 10         IP-Extended 10.0.12.0/24
  Metric: 100        IP-Extended 10.0.14.0/24
  Metric: 10         MT (IPv6 Unicast) IPv6 2001:db8:0:12::/64
  Metric: 100        MT (IPv6 Unicast) IPv6 2001:db8:0:14::/64

The capture agrees. No.103 of the attached STEP 1 R1-R2 capture is R1’s LSP, carrying TLVs 229, 222, 232 and 237. TLV 229 lists the two topologies it belongs to.

STEP 1 No.103: TLV 229 in R1's LSP (tshark -V)
    Multi Topology (t=229, l=4)
        Type: 229
        Length: 4
        IPv4 Unicast Topology (0x000)
        IPv6 Unicast Topology (0x002)

Download the pcap of the packet in the tshark output above (No.103 LSP)

Adding single-topology in STEP 2 removes the MT: lines and the MT-tagged routes, and the IPv6 prefixes appear as plain TLV 236 entries.

STEP 2: R1's LSP (single-topology)
R1.00-00            * 0x00000010   0xd251        1094 /*            0/0/0
  Area Address:   49.0001
  LSP MTU:        1492
  NLPID:          0xcc
  NLPID:          0x8e
  IP Address:     1.1.1.1
  IPv6 Address:   2001:db8:1::1
  Hostname:       R1
  Metric: 10         IS-Extended R2.00
  Metric: 100        IS-Extended R4.00
  Metric: 0          IP-Extended 1.1.1.1/32
  Metric: 10         IP-Extended 10.0.12.0/24
  Metric: 100        IP-Extended 10.0.14.0/24
  Metric: 10         IPv6 2001:db8:0:12::/64
  Metric: 100        IPv6 2001:db8:0:14::/64
  Metric: 0          IPv6 2001:db8:1::1/128

Download the pcap of R1's LSP in STEP 2 (No.46, TLV 236)

When the topologies do not match (STEP 3 and 4)

In STEP 3, IPv6 was removed from R2-R3 while single-topology was still in place. The link drops out of IS-IS entirely, and the device states why.

STEP 3: R2's Gi0/0/0/1 (IPv6 removed while single-topology is set)
GigabitEthernet0/0/0/1      Enabled
  Adjacency Formation:      Disabled (No cfg topology can participate)
  Prefix Advertisement:     Enabled
  Bandwidth:                1000000
  
  Circuit Type:             level-2-only (Configured: level-1-2)
  Media Type:               P2P
  Circuit Number:           0

Because the adjacency is down, IPv4 can no longer use the link either. The traceroute from R1 to R3 went via R4 for both IPv4 and IPv6.

STEP 3: R1 to R3 (both IPv4 and IPv6 go via R4)
RP/0/RP0/CPU0:R1#traceroute 3.3.3.3 source 1.1.1.1 timeout 1 probe 2 maxttl 4

Type escape sequence to abort.
Tracing the route to 3.3.3.3

 1  10.0.14.4 11 msec  6 msec 
 2  10.0.34.3 11 msec  * 

Removing single-topology in STEP 4 brings the adjacency back, and IPv4 and IPv6 now take different paths: IPv4 the shortest R1-R2-R3, IPv6 the R1-R4-R3 detour because R2-R3 has no IPv6.

STEP 4: R1 to R3 (IPv4)
RP/0/RP0/CPU0:R1#traceroute 3.3.3.3 source 1.1.1.1 timeout 1 probe 2 maxttl 4

Type escape sequence to abort.
Tracing the route to 3.3.3.3

 1  10.0.12.2 7 msec  5 msec 
 2  10.0.23.3 10 msec  * 

STEP 4: R1 to R3 (IPv6)
RP/0/RP0/CPU0:R1#traceroute ipv6 2001:db8:3::3 source 2001:db8:1::1 timeout 1 probe 2 maxttl 4

Type escape sequence to abort.
Tracing the route to 2001:db8:3::3

 1  2001:db8:0:14::4 8 msec 6 msec
 2  2001:db8:3::3 13 msec 11 msec

The physical topology is unchanged; SPF simply runs over a different topology per address family. That is what multi-topology does.

When routers disagree (STEP 6)

In STEP 6, only R2 was returned to single-topology. R2 disappears from the IPv6 topology. R1’s IPv6 routing table still holds the loopbacks of R3 and R4, but R2’s own 2001:db8:2::2/128 is gone.

STEP 6: the tail of R1's IPv6 routes (only R2 is single-topology)
i L2 2001:db8:0:23::/64 
      [115/120] via fe80::5054:ff:fe8f:a536, 00:01:45, GigabitEthernet0/0/0/1
i L2 2001:db8:0:34::/64 
      [115/110] via fe80::5054:ff:fe8f:a536, 00:01:45, GigabitEthernet0/0/0/1
L    2001:db8:1::1/128 is directly connected,
      00:20:31, Loopback1
i L2 2001:db8:3::3/128 
      [115/110] via fe80::5054:ff:fe8f:a536, 00:01:45, GigabitEthernet0/0/0/1
i L2 2001:db8:4::4/128 
      [115/100] via fe80::5054:ff:fe8f:a536, 00:01:45, GigabitEthernet0/0/0/1

IPv4 still takes the shortest R1-R2-R3, and only IPv6 detours around R2. Forgetting to change one router during a migration produces exactly this kind of failure.

No adjacency forms without a common MT (STEP 8)

In STEP 8, the R1-R4 link was put into IS-IS with IPv6 only on R1 and IPv4 only on R4, leaving no topology in common. The adjacency goes down and syslog gives the reason.

STEP 8: syslog on R1
RP/0/RP0/CPU0:Sep 20 15:44:20.621 UTC: isis[1003]: %ROUTING-ISIS-5-ADJCHANGE : ISIS (1): Adjacency to R4 (GigabitEthernet0/0/0/1) (L2) Down, No common topology 

No common topology is section 2.1 of RFC 5120 turned into a log message. The capture shows the same. R1’s IIH advertises only the IPv6 topology in TLV 229 (No.11), while R4’s IIH has no TLV 229 at all (No.12) — which matches the rule that advertising it is optional when MT ID 0 is the only topology. The result is that no topology is shared.

STEP 8 No.11: R1's IIH (advertises only the IPv6 topology)
    IPv6 Interface address(es) (t=232, l=16)
        Type: 232
        Length: 16
        IPv6 interface address: fe80::5054:ff:fef9:cbbf
    IPv6 Global Interface Address (t=233, l=16)
        Type: 233
        Length: 16
        IPv6 Global interface address: 2001:db8:0:14::1
    Multi Topology (t=229, l=2)
        Type: 229
        Length: 2
        IPv6 Unicast Topology (0x002)
    Unknown code (t=21, l=4)

STEP 8 No.12: R4's IIH (only an IPv4 address, no TLV 229)
    Area address(es) (t=1, l=4)
        Type: 1
        Length: 4
        Area address (3): 49.0001
    IP Interface address(es) (t=132, l=4)
        Type: 132
        Length: 4
        IPv4 interface address: 10.0.14.4
    Unknown code (t=21, l=4)

Download the pcap of the packet in the tshark output above (No.11 IIH)

Download the pcap of the peer's IIH (No.12, without TLV 229)

Each topology can have its own metric (STEP 10)

Multi-topology lets each topology carry its own metric. In STEP 10, only the IPv6 metric of the R1-R2 link was set to 1000. Both address families remain enabled on every link, yet the paths diverge.

STEP 10: changing the metric for IPv6 only
router isis 1
 interface GigabitEthernet0/0/0/0
  address-family ipv6 unicast
   metric 1000
  !
 !
!

STEP 10: R1 to R3 (IPv4, via R2)
RP/0/RP0/CPU0:R1#traceroute 3.3.3.3 source 1.1.1.1 timeout 1 probe 2 maxttl 4

Type escape sequence to abort.
Tracing the route to 3.3.3.3

 1  10.0.12.2 7 msec  5 msec 
 2  10.0.23.3 61 msec  * 

STEP 10: R1 to R3 (IPv6, via R4)
RP/0/RP0/CPU0:R1#traceroute ipv6 2001:db8:3::3 source 2001:db8:1::1 timeout 1 probe 2 maxttl 4

Type escape sequence to abort.
Tracing the route to 2001:db8:3::3

 1  2001:db8:0:14::4 6 msec 6 msec
 2  2001:db8:3::3 11 msec 9 msec

This allows operations such as separating the circuits used by IPv4 and IPv6, or steering only one of them onto a higher-bandwidth path.

Verification configs and show output

Everything below was collected from all four routers at every STEP. The verification config is the ..._run.txt file (the final state is the one from the last STEP).

File	Contents
`..._show.txt`	`show version` / `show interface description` / `show route` / `show route ipv6` / `show isis` / `show isis interface` / `show isis neighbors detail` / `show isis topology` / `show isis database detail` / `show isis spf-log` and more
`..._ping.txt`	IPv4 and IPv6 `ping` (50 packets) and `traceroute` from R1 and R3
`..._clear.txt`	A record of the counters cleared for that STEP (`clear counters interface`)
`..._log.txt`	`show logging` limited to the range of that STEP
`..._run.txt`	`show running-config` at that STEP (the verification config for that STEP)
`..._commit.cfg`	Only the configuration actually committed in that STEP
`..._trace.txt`	`show isis trace all \| include ADJ`. The trace buffer accumulates from boot, so the STEP 10 file covers the whole test (each file is over 400 KB, so only the four STEP 10 files are attached)

STEP 0: IPv4 only (initial state)

Router	show output	ping	clear	syslog	running-config
R1	show	ping	clear	log	run
R2	show	—	clear	log	run
R3	show	ping	clear	log	run
R4	show	—	clear	log	run

STEP 1: enable IPv6 on every router and link

Router	show output	ping	committed config	syslog	running-config
R1	show	ping	commit	log	run
R2	show	—	commit	log	run
R3	show	ping	commit	log	run
R4	show	—	commit	log	run

STEP 2: single-topology on every router

Router	show output	ping	committed config	syslog	running-config
R1	show	ping	commit	log	run
R2	show	—	commit	log	run
R3	show	ping	commit	log	run
R4	show	—	commit	log	run

STEP 3: remove IPv6 from R2-R3 (still ST)

Router	show output	ping	committed config	syslog	running-config
R1	show	ping	—	log	run
R2	show	—	commit	log	run
R3	show	ping	commit	log	run
R4	show	—	—	log	run

STEP 4: remove single-topology everywhere (to MT)

Router	show output	ping	committed config	syslog	running-config
R1	show	ping	commit	log	run
R2	show	—	commit	log	run
R3	show	ping	commit	log	run
R4	show	—	commit	log	run

STEP 5: restore IPv6 on R2-R3

Router	show output	ping	committed config	syslog	running-config
R1	show	ping	—	log	run
R2	show	—	commit	log	run
R3	show	ping	commit	log	run
R4	show	—	—	log	run

STEP 6: put single-topology back on R2 only

Router	show output	ping	committed config	syslog	running-config
R1	show	ping	—	log	run
R2	show	—	commit	log	run
R3	show	ping	—	log	run
R4	show	—	—	log	run

STEP 7: return R2 to MT

Router	show output	ping	committed config	syslog	running-config
R1	show	ping	—	log	run
R2	show	—	commit	log	run
R3	show	ping	—	log	run
R4	show	—	—	log	run

STEP 8: make R1-R4 a link with no common MT

Router	show output	ping	committed config	syslog	running-config
R1	show	ping	commit	log	run
R2	show	—	—	log	run
R3	show	ping	—	log	run
R4	show	—	commit	log	run

STEP 9: restore R1-R4

Router	show output	ping	committed config	syslog	running-config
R1	show	ping	commit	log	run
R2	show	—	—	log	run
R3	show	ping	—	log	run
R4	show	—	commit	log	run

STEP 10: set the IPv6 metric of R1-R2 to 1000 (final state)

Router	show output	ping	committed config	syslog	running-config	trace
R1	show	ping	commit	log	run	trace
R2	show	—	commit	log	run	trace
R3	show	ping	—	log	run	trace
R4	show	—	—	log	run	trace

Packet captures were taken per STEP.

STEP	R1-R2	R2-R3	R1-R4
0	pcap	pcap	pcap
1	pcap	pcap	pcap
2	pcap	pcap	pcap
3	pcap	pcap	pcap
4	pcap	pcap	pcap
5	pcap	pcap	pcap
6	pcap	pcap	pcap
7	pcap	pcap	pcap
8	pcap	pcap	pcap
9	pcap	pcap	pcap
10	pcap	pcap	pcap

References

Standard	Title	Summary
RFC 5308	Routing IPv6 with IS-IS	Defines TLV 236 (IPv6 Reachability) and TLV 232 (IPv6 Interface Address). The metric is 32 bits, with the U (up/down), X (external original) and S (sub-TLV present) bits. `MAX_V6_PATH_METRIC` is 0xFE000000. Advertising link-local addresses is prohibited.
RFC 5120	M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)	Defines TLVs 229, 222, 235 and 237 along with MT IDs. Section 7.5 reserves MT ID 0 for the standard topology and MT ID 2 for the IPv6 routing topology. Section 2.1 says a point-to-point router should not form an adjacency without a common MT, and section 2.2 says broadcast routers always form one.