has an OSPF route type of "external".
- The route is from a different domain from the domain of the
OSPF instance.
The rules for determining whether a route is from a domain different
from that of a particular OSPF instance are the following. The OSPF
Domain Identifier Extended Communities attribute carried by the route
is compared with the OSPF Domain Identifier Extended Communities
attribute(s) with which the OSPF instance has been configured (if
any). In general, when two such attributes are compared, all eight
bytes must be compared. Thus, two OSPF Domain Identifier Extended
Communities attributes are regarded as equal if and only if one of
the following three conditions holds:
1. They are identical in all eight bytes.
2. They are identical in their lower-order six bytes (value
field), but one attribute has two high-order bytes (type field)
of 0005 and the other has two high-order bytes (type field) of
8005. (This condition is for backward compatibility.)
3. The lower-order six bytes (value field) of both attributes
consist entirely of zeroes. In this case, the two attributes
are considered identical irrespective of their type fields, and
they are regarded as representing the NULL Domain Identifier.
If a VPN-IPv4 route has an OSPF Domain Identifier Extended
Communities attribute, we say that that route is in the identified
domain. If the value field of the Extended Communities attribute
consists of all zeroes, then the identified domain is the NULL
domain, and the route is said to belong to the NULL domain. If the
route does not have an OSPF Domain Identified Extended Communities
attribute, then the route belongs to the NULL domain.
Every OSPF instance is associated with one or more Domain
Identifiers, though possibly only with the NULL domain identifier.
If an OSPF instance is associated with a particular Domain
Identifier, we will say that it belongs to the identified domain.
If a VPN-IPv4 route is to be redistributed to a particular instance,
it must be determined whether that route and that OSPF instance
belong to the same domain. A route and an OSPF instance belong to
the same domain if and only if one of the following conditions holds:
1. The route and the OSPF instance each belong to the NULL domain.
2. The domain to which the route belongs is the domain to which
the OSPF instance belongs. (That is, the route’s Domain
Identifier is equal to the OSPF instance’s domain identifier,
as determined by the definitions given earlier in this
section.)
If the route and the VRF do not belong to the same domain, the route
is treated as an external route.
If an external route is redistributed into an OSPF instance, the
route may or may not be advertised to a particular CE, depending on
the configuration and on the type of area to which the PE/CE link
belongs. If the route is advertised, and the PE/CE link belongs to a
NSSA area, it is advertised in a type 7 LSA. Otherwise, if the route
is advertised, it is advertised in a type 5 LSA. The LSA will be
originated by the PE.
The DN bit (Section 4.2.5.1) MUST be set in the LSA. The VPN Route
Tag (see Section 4.2.5.2) MUST be placed in the LSA, unless the use
of the VPN Route Tag has been turned off by configuration.
By default, a type 2 metric value is included in the LSA, unless the
options field of the OSPF Route Type Extended Communities attribute
of the VPN-IPv4 route specifies that the metric should be type 1.
By default, the value of the metric is taken from the MED attribute
of the VPN-IPv4 route. If the MED is not present, a default metric
value is used. (The default type 1 metric and the default type 2
metric MAY be different.)
Note that this way of handling external routes makes every PE appear
to be an ASBR attached to all the external routes. In a multihomed
site, this can result in a number of type 5 LSAs containing the same
information.
4.2.8.2. Summary Routes
If a route and the VRF into which it is imported belong to the same
domain, then the route should be treated as if it had been received
in an OSPF type 3 LSA. This means that the PE will report the route
in a type 3 LSA to the CE. (Note that this case is possible even if
the VPN-IPv4 route carries an area number identical to that of the CE
router. This means that if an area is "partitioned" such that the
two pieces are connected only via the VPN backbone, it appears to be
two areas, with inter-area routes between them.)
4.2.8.3. NSSA Routes
NSSA routes are treated the same as external routes, as described in
Section 4.2.8.1.
5. IANA Considerations
Section 11 of [EXTCOMM] calls upon IANA to create a registry for BGP
Extended Communities Type Field and Extended Type Field values.
Section 4.2.6 of this document assigns new values for the BGP
Extended Communities Extended Type Field. These values all fall
within the range of values that [EXTCOMM] states "are to be assigned
by IANA, using the ’First Come, First Served’ policy defined in RFC
2434".
The BGP Extended Communities Extended Type Field values assigned in
Section 4.2.6 of this document are as follows:
- OSPF Domain Identifier: Extended Types 0005, 0105, and 0205.
- OSPF Route Type: Extended Type 0306
- OSPF Router ID: Extended Type 0107
6. Security Considerations
Security considerations that are relevant in general to BGP/MPLS IP
VPNS are discussed in [VPN] and [VPN-AS]. We discuss here only those
security considerations that are specific to the use of OSPF as the
PE/CE protocol.
A single PE may be running OSPF as the IGP of the SP backbone
network, as well as running OSPF as the IGP of one or more VPNs.
This requires the use of multiple, independent OSPF instances, so
that routes are not inadvertently leaked between the backbone and any
VPN. The OSPF instances for different VPNs must also be independent
OSPF instances, to prevent inadvertent leaking of routes between
VPNs.
OSPF provides a number of procedures that allow the OSPF control
messages between a PE and a CE to be authenticated. OSPF
"cryptographic authentication" SHOULD be used between a PE and a CE.
It MUST be implemented on each PE.
In the absence of such authentication, it is possible that the CE
might not really belong to the VPN to which the PE assigns it. It
may also be possible for an attacker to insert spoofed messages on
the PE/CE link, in either direction. Spoofed messages sent to the CE
could compromise the routing at the CE’s site. Spoofed messages sent
to the PE could result in improper VPN routing, or in a denial-of-
service attack on the VPN.
7. Acknowledgements
Major contributions to this work have been made by Derek Yeung and
Yakov Rekhter.
Thanks to Ross Callon, Ajay Singhal, Russ Housley, and Alex Zinin for
their review and comments.
8. Normative References
[EXTCOMM] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006.
[OSPFv2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPF-DN] Rosen, E., Psenak, P., and P. Pillay-Esnault, "Using a Link
State Advertisement (LSA) Options Bit to Prevent Looping in
BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4576,
June 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[VPN] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
9. Informative References
[BGP] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RIP] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November
1998.
[VPN-AS] Rosen, E., "Applicability Statement for BGP/MPLS IP Virtual
Private Networks (VPNs)", RFC 4365, February 2006.
Authors’ Addresses
Eric C. Rosen
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719
EMail: erosen@cisco.com
Peter Psenak
Cisco Systems
BA Business Center, 9th Floor
Plynarenska 1
Bratislava 82109
Slovakia
EMail: ppsenak@cisco.com
Padma Pillay-Esnault
Cisco Systems
3750 Cisco Way
San Jose, CA 95134
EMail: ppe@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).