OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol
Extracted elements (26)
Domain IDs distinguish OSPFv3 instances and determine whether an incoming VPN-IPv6 route is inter-area or external. Two Domain IDs match if all 8 bytes are identical, or both are NULL; a route with no Domain ID attribute is treated as NULL.
Of the two loop prevention mechanisms from RFC 4577 (DN-bit and OSPF tag), only the DN-bit option is supported in the OSPFv3 implementation because OSPFv3 loop scenarios are identical to OSPFv2 topologies.
OSPFv3 sham link endpoints are 128-bit IPv6 addresses rather than 32-bit Router IDs (as in OSPFv2), necessitating explicit configuration. Multiple OSPFv3 instances can be established across a single sham link, using the Instance ID in the protocol packet header to demultiplex them.
Sham links are needed when two customer sites are connected by an intra-area backdoor link, because OSPF route preference rules would favor that link over the inter-area VPN backbone path. The sham link makes the VPN backbone appear as an intra-area link to compete correctly.
OSPFv3 operates on a per-link basis (unlike OSPFv2's per-IP-subnet model), allowing multiple OSPFv3 instances over a single PE-CE interface all associated with the same VRF. This changes the RFC 4577 constraint that each interface belongs to no more than one OSPF instance.
The OSPFv3 PE-CE architecture described in this document is fully compatible with RFC 5838 (Support of Address Families in OSPFv3), which differentiates AFs using reserved ranges of OSPFv3 Instance IDs.
A MED attribute SHOULD be set to the value of the OSPFv3 metric associated with the route plus 1 when the OSPFv3 route is redistributed into MP-BGP.
All address families (AFs) redistributed from OSPFv3 into BGP on a PE MUST contain the BGP Extended Communities Attributes as described in Section 4.4.
All OSPFv3 instances running on the same PE interface MUST be associated with the same VRF. Configurations where a PE interface is associated with multiple VRFs are out of scope.
Each instance of OSPFv3 MUST be associated with a single VRF. Multiple instances may populate a common VRF but do not leak routes to one another unless configured to do so.
Each OSPFv3 instance MUST have a primary Domain ID that is transported with the VPN-IPv6 route in a BGP attribute over the VPN backbone. The Domain ID MUST be configured on a per-OSPFv3 instance basis.
Each OSPFv3 route added to the VRF routing table on a PE router MUST have corresponding BGP Extended Communities Attributes that contain and preserve the OSPFv3 information of the original route.
If the next-hop interface for a route is a sham link, the PE SHOULD NOT redistribute that route into BGP as a VPN-IPv6 route. Any other route advertised in an LSA transmitted over a sham link MUST be redistributed into BGP.
OSPFv3 sham link endpoint addresses MUST be configured (they cannot default to the 32-bit Router ID as in OSPFv2) and MUST be distributed by BGP as routable VPN IPv6 addresses with a 128-bit prefix length.
Sham link endpoint addresses MUST NOT be advertised by OSPFv3. If there is no BGP route to the sham link endpoint address, the sham link appears to be down.
The DN-bit MUST be clear in all other LSA types (i.e., types other than Inter-area-prefix, NSSA, and AS-External LSAs sent PE-to-CE).
The DN-bit MUST be set in Inter-area-prefix LSAs, NSSA LSAs, and AS-External LSAs when these are originated from a PE to a CE, to prevent those prefixes from being re-advertised into BGP. Any LSA with the DN-bit set must not be used for route calculations on PE routers.
When forwarding a packet whose preferred route has the sham link as its next-hop interface, the packet MUST be forwarded according to the corresponding BGP route as defined in RFC 4364 and RFC 4659.
A PE advertises an IPv6 route as an Inter-Area-Prefix (type 0x2003) LSA when the Domain ID matches and the source LSA was Intra-Area-Prefix (0x2009) or Inter-Area-Prefix (0x2003). The PE represents itself as an ABR regardless of whether source and destination area numbers match.
A PE considers an IPv6 route to be external (advertised as AS-External-LSA 0x4005 or NSSA-LSA 0x2007) when the Domain ID differs from the local instance, when the source LSA was AS-External or NSSA, or when the route was not learned from OSPFv3.
Route Type field encoding maps OSPFv3 LSA types to BGP route type codes: 3=Inter-area-prefix (0x2003), 5=External (0x4005), 7=NSSA (0x2007), 1 or 2=Intra-area-prefix (0x2009).
IANA has marked the OSPFv3 Route Attributes (0x0004) entry in the BGP IPv6 Address Specific Extended Community registry as deprecated. The BGP Extended Communities Attributes used in this document were previously registered.
The OSPFv3 PE-CE extensions in this document do not introduce any new security concerns beyond those already defined in Section 6 of RFC 4577 (OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP VPNs).
OSPF Domain Identifier Extended Communities Attribute: 2-byte type field (0x0005, 0x0105, or 0x0205) followed by a 6-byte Domain Identifier field. Default value is 0 (NULL).
OSPF Route Type Extended Communities Attribute: 2-byte type field (0x0306), 4-byte Area Number, 1-byte Route Type, and 1-byte Options. The Options E-bit (bit 1) indicates Type-2 external metric when set; clear means Type-1. This attribute MUST be present.
OSPF Router ID Extended Communities Attribute: 2-byte type field (0x0107) followed by a 4-byte Router ID and 2 unused bytes. Setting this field is OPTIONAL with a default value of 0.