IGP Unreachable Prefix Announcement
Extracted elements (24)
IGP summarization at ABRs and ASBRs suppresses individual prefix state, leaving routers outside the area/domain unaware when a summarized prefix becomes unreachable. UPA is introduced to carry this unreachability signal across area and domain boundaries in a backward-compatible manner, enabling fast-convergence mechanisms such as BGP PIC Edge.
IS-IS UPA advertisements SHOULD be placed in LSPs dedicated to this type of advertisement. Because the unit of flooding in IS-IS is an LSP, co-locating UPAs in dedicated LSPs minimizes the number of LSPs that must be updated when UPAs are advertised and withdrawn.
UPA does not address area or domain partitions. When an area partitions and multiple ABRs/ASBRs each cover only a portion of the summarized prefix space, each ABR/ASBR generates UPAs only for destinations locally unreachable, potentially redirecting traffic to an alternative egress — but if that egress is also in the partitioned area, traffic will still be dropped, mirroring behavior without UPA.
UPA is intended as an event-driven signal of the transition from reachable to unreachable, not a persistent state. Leaving UPA advertisements indefinitely would result in stale information in link-state databases across all routers in the area.
Existing IS-IS nodes that do not support UPA will not use UPA advertisements during route calculation but will continue to flood them within the area, enabling backward-compatible deployment without requiring a network-wide upgrade.
For OSPFv3 prefixes advertised via legacy Inter-Area-Prefix-LSA, AS-External-LSA, and NSSA-LSA, UPA is signaled using their corresponding extended LSAs. This requires support of OSPFv3 Extended LSAs in sparse mode as specified in Section 6.2 of RFC 8362.
An ABR or ASBR MUST withdraw a previously advertised UPA when the reason for which the UPA was generated ceases (e.g., prefix reachability is restored or its metric falls below the configured threshold).
Even if the reasons for unreachability persist, UPA advertisements SHOULD be withdrawn after a sufficient time for the UPA to be flooded network-wide and acted upon. Implementations SHOULD provide a configuration option to specify the UPA lifetime at the originating ABR or ASBR.
For IS-IS UPA propagation across levels, the normal requirement that a prefix be reachable in the source level before propagation MUST NOT be applied, because UPAs propagate unreachability. The original metric value MUST be preserved, and the cost to reach the UPA originator MUST NOT be added when readvertising.
For OSPF UPA propagation, the normal requirement that a prefix be reachable in the source area MUST NOT be applied. When readvertising, the original LSInfinity metric MUST be preserved and the cost to reach the UPA originator MUST NOT be added.
Generation and propagation of UPA at an ABR or ASBR is optional and SHOULD be controlled by a configuration knob; it SHOULD be disabled by default.
Implementations SHOULD limit the number of UPA advertisements that can be originated at a given time, and SHOULD provide a configuration option to set that limit.
In IS-IS, any prefix advertisement with a metric value greater than 0xFE000000 MUST be used when advertising UPA. A prefix advertised with the U-Flag MUST have its metric set to a value larger than 0xFE000000; if the metric is less than or equal to 0xFE000000, both U-Flag and UP-Flag MUST be ignored.
In OSPFv2, a prefix advertised with U-Flag or UP-Flag MUST have its metric set to LSInfinity; if the metric is not equal to LSInfinity, both flags MUST be ignored. For default algorithm 0 prefixes, the unreachable prefix MUST also be advertised in the base OSPFv2 LSA (Summary-LSA, AS-external-LSA, or NSSA AS-external-LSA).
In OSPFv3, a prefix advertised with U-Flag or UP-Flag MUST have its metric set to LSInfinity and the NU-bit set in the PrefixOptions of the parent TLV. If either condition is not met, both flags MUST be ignored.
Processing of received UPAs is optional and SHOULD be controlled by receiver configuration. Applications using UPA MUST NOT use the absence of a UPA to infer that prefix reachability has been restored; they must rely on their own mechanisms to verify reachability.
The originating node MUST NOT set the UP-Flag without also setting the U-Flag in IS-IS. The receiving node MUST ignore the UP-Flag if the U-Flag is not set.
The originating OSPF node MUST NOT set the UP-Flag without also setting the U-Flag. The receiving node MUST ignore the UP-Flag if the U-Flag is not set.
When an ABR or ASBR advertises UPA in OSPFv2 or OSPFv3, it MUST set the LSA age to a value lower than MaxAge and set the metric to LSInfinity (0xFFFFFF). Standard OSPFv2/OSPFv3 flooding procedures apply.
Two new bits are defined in the IS-IS IPv4/IPv6 Extended Reachability Attribute Flags (RFC 7794): U-Flag (bit 5) indicates the prefix is unreachable; UP-Flag (bit 6) indicates the prefix is unreachable due to a planned event such as planned maintenance.
Two new bits are defined in the OSPFv2 and OSPFv3 Prefix Extended Flags Sub-TLV (RFC 9792): U-Flag (bit 0) indicates the prefix is unreachable; UP-Flag (bit 1) indicates unreachability due to a planned event.
Two new bits are registered in each of the 'OSPFv2 Prefix Extended Flags' and 'OSPFv3 Prefix Extended Flags' registries: bit 0 (U-Flag) and bit 1 (UP-Flag), both referencing RFC 9929 Section 4.2.
Two new bits are registered in the 'IS-IS Bit Values for Prefix Attribute Flags Sub-TLV' registry: bit 5 (U-Flag, Unreachable Prefix Flag) and bit 6 (UP-Flag, Unreachable Planned Prefix Flag), both referencing RFC 9929 Section 3.2.
UPA introduces the possibility that an attacker could inject a false but apparently valid UPA to incorrectly signal prefix unreachability. This risk is no greater than existing risks of injecting other false IGP advertisements and can be mitigated by existing IS-IS authentication (RFC 5304, RFC 5310, RFC 7794), OSPFv2 security extensions (RFC 7474, RFC 7684), and OSPFv3 authentication/confidentiality (RFC 4552).