rfc-4576

Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)

E. Rosen, P. Psenak, P. Pillay-Esnault

date2006-06 streamIETF areartg wgospf statusPROPOSED STANDARD pages7 canonicalhttps://www.rfc-editor.org/rfc/rfc4576 doi10.17487/RFC4576 errataview

This document specifies a procedure that deals with a particular issue that may arise when a Service Provider (SP) provides "BGP/MPLS IP VPN" service to a customer and the customer uses OSPFv2 to advertise its routes to the SP. In this situation, a Customer Edge (CE) Router and a Provider Edge (PE) Router are OSPF peers, and customer routes are sent via OSPFv2 from the CE to the PE. The customer routes are converted into BGP routes, and BGP carries them across the backbone to other PE routers. The routes are then converted back to OSPF routes sent via OSPF to other CE routers. As a result of this conversion, some of the information needed to prevent loops may be lost. A procedure is needed to ensure that once a route is sent from a PE to a CE, the route will be ignored by any PE that receives it back from a CE. This document specifies the necessary procedure, using one of the options bits in the LSA (Link State Advertisements) to indicate that an LSA has already been forwarded by a PE and should be ignored by any other PEs that see it. [STANDARDS-TRACK]

Extracted elements (10)

design-rationale §3

The DN bit is placed in the LSA Options field because a distinct tag value could be used in AS-external LSAs but is not available for summary LSAs. Since PEs must function as OSPF area 0 routers and may receive summary LSAs from other PEs, a mechanism applicable to both summary and AS-external LSAs is required.

routing, vpn, mpls

design-rationale §4

The high-order options bit was chosen for this purpose (credited to Derek Yeung) because OSPFv2 LSAs do not otherwise carry the information needed for a PE to determine that the path to an address prefix in a CE-originated LSA actually passes through another PE router.

routing, vpn

interoperability-note §4

An LSA with the DN bit set is still put in the topological database, aged, flooded, and otherwise handled normally — the DN bit has no effect on LSA handling other than excluding the LSA from the OSPF route calculation on PE routers.

routing, vpn

interoperability-note §4

The DN-bit loop-prevention restriction is analogous to the standard OSPF restriction that inter-area routes learned from area 0 are not passed back to area 0, ensuring consistency with existing OSPF loop-prevention principles.

routing, vpn

normative-requirement §4 MUST

The DN bit MUST be ignored in all other LSA types (i.e., types other than 3, 5, and 7).

routing, vpn

normative-requirement §4 MUST NOT

When a PE receives from a CE router a type 3, 5, or 7 LSA with the DN bit set, the information from that LSA MUST NOT be used during the OSPF route calculation, preventing it from being translated into a BGP route.

routing, vpn, mpls, bgp

normative-requirement §4 MUST

When a type 3, 5, or 7 LSA is sent from a PE to a CE, the DN bit MUST be set. The DN bit MUST be clear in all other LSA types.

routing, vpn, mpls, bgp

protocol-element §4

The DN bit is defined as the high-order bit of the LSA Options field (a previously unused bit). It is used to indicate that an LSA is carrying information about an address prefix whose path includes a PE router.

routing, vpn, mpls

security-consideration §5

An attacker may set the DN bit in an LSA traveling from CE to PE when it should be clear, causing address prefixes in that LSA to become unreachable from other VPN sites. Conversely, an attacker may clear the DN bit when it should be set, potentially causing routing loops. Both attacks can be mitigated by using OSPFv2 cryptographic authentication as specified in RFC 2328 Section D.

security, routing, vpn

wire-format §4

The DN bit occupies the high-order (leftmost) bit position of the 8-bit LSA Options field, as defined in RFC 2328 Section A.2. The layout is: DN | * | DC | EA | N/P | MC | E | *.

routing, vpn