Summary

  • RFC 5308 adds TLV 236 for IPv6 reachability, TLV 232 for IPv6 interface addresses and NLPID 142 for IPv6 protocol support; these are distinct statements, not a combined forwarding receipt.
  • In the standard shared topology, a valid IPv6 SPF path still needs an explicit join to every transit node's applicable IPv6 capability, RIB and FIB. RFC 5120 can make topology participation address-family-specific, but packet delivery remains a separate outcome.

The graph was connected in the wrong language

The route was present at both ends. Its metric was admissible, its prefix length parsed correctly, and SPF chose the expected predecessor. Yet the first packet disappeared at an intermediate system that participated in the ordinary IS-IS graph without providing the IPv6 forwarding context the path assumed.

This is not an incident claim. It is the operational gap exposed by reading two standards together. RFC 5308 extends the usual IS-IS LSP machinery so one intra-domain protocol can carry IPv6 alongside IPv4 and OSI. RFC 5120 later supplies multi-topology membership when operators need independent graphs. In the default graph, adjacency describes IS-IS connectivity. It does not, by itself, assert identical data-plane capability for every address family carried by the database.

The failure is attractive because every isolated record is valid. The origin really advertised an IPv6 prefix. The receiver really computed a path. The intermediate router really was adjacent for the standard topology. What is missing is the join: did every node admitted to the chosen path declare and realize the IPv6 capability the packet needs?

Three codepoints make three different statements

RFC 5308 defines IPv6 Reachability as TLV 236. Each entry carries a prefix, a 32-bit metric, an up/down bit, an external-origin bit and, optionally, sub-TLVs. The U bit records downward movement through the hierarchy. The X bit records redistribution from another routing protocol. The S bit says that a sub-TLV block follows. None is a “forwarding succeeded” bit.

TLV 232 carries IPv6 interface addresses. Its meaning depends on the PDU that contains it. In a Hello, it must contain only link-local addresses assigned to the sending interface. In an LSP, it must contain only non-link-local addresses assigned to the advertising intermediate system. A record that drops the PDU context can convert a neighbor-local address into apparent domain-wide identity, or strip a system address of the scope in which it was asserted.

NLPID 142 is the third statement. A system that supports IPv6 routing through IS-IS must include the IPv6 identifier in its Protocols Supported TLV. This is the most direct capability declaration of the three. It is still a declaration from a routing process. It does not certify that every interface, line card, virtual routing context or current FIB generation is ready to forward an IPv6 packet.

A prefix can be present without entering normal SPF

TLV 236 may appear any number of times in an LSP, including zero. Link-local prefixes must not be advertised through it. Prefix bytes are packed to the minimum length implied by the prefix-length field, so a parser has to retain both the length and the exact significant bytes.

The metric has another boundary. RFC 5308 adopts MAX_V6_PATH_METRIC, 0xFE000000, from the extended-metric work. A prefix advertised with a metric greater than that maximum must not be considered during the normal SPF calculation. The advertisement may exist for another purpose. Database presence is therefore explicitly broader than normal route eligibility.

That distinction should survive telemetry. seen in LSP, syntactically accepted, eligible for normal SPF, best preference, best metric, resolved next hop, installed in RIB, programmed in FIB and packet delivered cannot be collapsed into “route learned.” The RFC itself creates a state in which a prefix is present yet intentionally excluded from the normal IPv6 table.

Shared topology requires a capability invariant

An ordinary IS-IS adjacency can carry LSPs whose contents describe several network-layer protocols. RFC 5308 requires a capable node to advertise IPv6 NLPID, but it does not redefine the standard topology so that a non-IPv6 node automatically disappears from every IPv6 SPF path. That separation is the reason an integrated deployment needs an invariant outside the raw graph: every node that can become transit for an IPv6 path must have the applicable IPv6 control-plane and forwarding capability.

The evidence should be path-specific. A global inventory entry saying “IPv6 enabled” is weaker than a receipt binding the selected predecessor and next hop to the relevant interface, routing context, software capability, FIB generation and packet observation. ECMP makes the requirement wider: all eligible next hops must satisfy it, not merely the member reached by one successful probe.

Authentication does not fill the gap. A correctly authenticated LSP can truthfully report a neighbor relation and an IPv6 prefix while the selected transit node lacks a usable IPv6 forwarding entry. Integrity of the control-plane statement and completeness of the forwarding chain remain separate properties.

Multi-topology changes who belongs to the graph

RFC 5120 makes topology participation explicit in IIHs. On a point-to-point interface, if the remote side does not advertise a topology ID, the local router must not include that neighbor in its LSP for that topology. Routers should not form an adjacency when they share no topology. MT ID 2 is reserved for IPv6 routing, and TLV 237 adds a topology membership field before the IPv6 reachability format inherited from TLV 236.

The broadcast-LAN rule shows why “adjacency exists” remains too coarse. Routers on a LAN still establish adjacency even if they have no multi-topology in common, so that all participants elect the same DIS. Topology-specific reachability must then be constrained by the actual common membership. The base adjacency is real, but it is not authorization to use the neighbor in every topology.

Separate IPv4 and IPv6 topologies can therefore remove a class of false transit assumptions. They also create additional operating state: topology membership, topology-specific overload, TLV 237 advertisements, separate SPF results and potentially separate RIBs. If an interface carries multiple topologies from one address family with overlapping addresses, RFC 5120 says another local mechanism is required to select the correct RIB for an incoming packet. Protocol vocabulary has not made the data-plane choice automatic.

Later preference correction matters

RFC 5308 originally ordered IPv6 preferences using Level 1 up, Level 2 up, Level 2 down and Level 1 down. RFC 7775 later explains that the underlying two-level model does not define a Level 2 inter-area route type, so a “Level 2 down” class should not have been introduced that way. It replaces the preference description with rules aligned to the route types actually supported for TLV 236 and TLV 237.

An implementation review should therefore use RFC 7775 for current preference behavior rather than treating the 2008 list as final. This is another reason to retain the tuple instead of a verdict: TLV, topology, level, U and X bits, source protocol, metric, preference class and SPF generation. A later standards correction can change the interpretation of one field without changing the captured LSP bytes.

The receipt must follow the packet's address family

A non-secret receipt can join node identity, adjacency and PDU type; topology ID; Protocols Supported TLV and IPv6 NLPID; TLV 232 address and Hello-or-LSP context; TLV 236 or 237 prefix, U/X/S bits, metric and sub-TLVs; SPF generation; selected predecessor and next hop; all ECMP members; every transit node's IPv6 capability; RIB choice; FIB generation and programming result; link-local neighbor resolution; probe path; delivery outcome; and rollback decision.

This is more than a richer log. It preserves the authority boundary between a routing process allowed to describe reachability and a forwarding system required to move the packet. The graph can be correct as a graph while the operational claim “IPv6 crosses this path” remains unproved.

Sources