related features. Higher levels of security services, such as edge-
to-edge encryption, authentication, or replay attack, should be
supported. More details on customer requirements for security are
described in [VPNSEC].
Security in an L3VPN service SHOULD be as transparent as possible to
the customer, with the obvious exception of support for remote or
temporary user access, as detailed in section 5.11.2.
L3VPN customers MUST be able to deploy their own internal security
mechanisms in addition to those deployed by the SP, in order to
secure specific applications or traffic at a granularity finer than
that on a site-to-site basis.
If a customer requires QoS support in an L3VPN, then this request
MUST be communicated to the SP either by using unencrypted fields or
via an agreed security association. For example, applications could
send RSVP messages in support of Intserv either in the clear or
encrypted with a key negotiated with the SP. Another case is that
where applications using an IPsec tunnel could copy the DSCP from the
encrypted IP header to the header of the tunnel’s IP header.
5.10. Migration Impact
Often, customers are migrating from an already deployed private
network toward one or more L3VPN solutions. A typical private
network scenario is CE routers connected via real or virtual
circuits. Ideally, minimal incremental cost SHOULD result during the
migration period. Furthermore, if necessary, any disruption of
service SHOULD also be minimized.
A range of scenarios of customer migration MUST be supported. Full
migration of all sites MUST be supported. Support for cases of
partial migration is highly desirable [Y.1311.1] - that is, legacy
private network sites that belong to the L3VPN service SHOULD still
have L3 reachability to the sites that migrate to the L3VPN service.
5.11. Network Access
Every L3 packet exchanged between the customer and the SP over the
access connection MUST appear as it would on a private network
providing an equivalent service to that offered by the L3VPN.
5.11.1. Physical/Link Layer Technology
L3VPNs SHOULD support a broad range of physical and link-layer access
technologies, such as PSTN, ISDN, xDSL, cable modem, leased line,
Ethernet, Ethernet VLAN, ATM, Frame Relay, Wireless local loop, and
mobile radio access. The capacity and QoS achievable may be
dependent on the specific access technology in use.
5.11.2. Temporary Access
The VPN service offering SHOULD allow both permanent and temporary
access to one or more L3VPNs for authenticated users across a broad
range of access technologies. Support for remote or temporary VPN
access SHOULD include ISDN, PSTN dial-in, xDSL, or access via another
SP network. The customer SHOULD be able to choose from alternatives
for authentication of temporary access users. Choices for access
authentication are SP-provided, third-party, or customer-provided
authentication.
A significant number of VPN users may not be permanently attached to
one VPN site: in order to limit access to a VPN to authorized users,
it is first necessary to authenticate them. Authentication SHALL
apply as configured by the customer agent and/or SP where a specific
user may be part of one or more VPNs. The authentication function
SHOULD be used to invoke all actions necessary to join a user to the
VPN automatically.
A user SHOULD be able to access an L3VPN via a network having generic
Internet access.
Mobile users may move within an L3VPN site. Mobile users may also
have temporary connections to different L3VPN sites within the same
VPN. Authentication SHOULD be provided in both of these cases.
5.11.3. Sharing of the Access Network
In a PE-based L3VPN, if the site shares the access network with other
traffic (e.g., access to the Internet), then data security in the
access network is the responsibility of the L3VPN customer.
5.11.4. Access Connectivity
Various types of physical connectivity scenarios MUST be supported,
such as multi-homed sites, backdoor links between customer sites, and
devices homed to two or more SP networks. L3VPN solutions SHOULD
support at least the types of physical or link-layer connectivity
arrangements shown in Figure 2.1. Support for other physical
connectivity scenarios with arbitrary topology is desirable.
Access arrangements with multiple physical or logical paths from a CE
to other CEs and PEs MUST support redundancy and SHOULD support load
balancing. Resiliency uses redundancy to provide connectivity
between a CE site and other CE sites and, optionally, other services.
Load balancing provides a means to perform traffic engineering so
that capacity on redundant links is used to achieve improved
performance during periods when the redundant component(s) are
available.
For multi-homing to a single SP, load balancing capability SHOULD be
supported by the PE across the CE to PE links. For example, in case
(a), load balancing SHOULD be provided by the two PEs over the two
links connecting to the single CE. In case (c), load balancing
SHOULD be provided by the two PEs over the two links connecting to
the two CEs.
In addition, the load-balancing parameters (e.g., the ratio of
traffic on the multiple load-balanced links, or the preferred link)
SHOULD be provisionable based on customer’s requirements. The load-
balancing capability may also be used to achieve resiliency in the
event of access connectivity failures. For example, in case (b) a CE
may connect to two different SPs via diverse access networks.
Resiliency MAY be further enhanced as shown in case (d), where CEs
connected via a "back door" connection connect to different SPs.
Furthermore, arbitrary combinations of the above methods, with a few
examples shown in cases (e) and (f), should be supportable by any
L3VPN approach.
For multi-homing to multiple SPs, load balancing capability MAY also
be supported by the PEs in the different SPs (clearly, this is a more
complex type of load balancing to realize, requiring policy and
service agreements between the SPs to interoperate).
+---------------- +---------------
| |
+------+ +------+
+---------| PE | +---------| PE |
| |router| | |router| SP network
| +------+ | +------+
+------+ | +------+ |
| CE | | | CE | +---------------
|device| | SP network |device| +---------------
+------+ | +------+ |
| +------+ | +------+
| | PE | | | PE |
+---------|router| +---------|router| SP network
+------+ +------+
| |
+---------------- +---------------
(a) (b)
+---------------- +---------------
| |
+------+ +------+ +------+ +------+
| CE |-----| PE | | CE |-----| PE |
|device| |router| |device| |router| SP network
+------+ +------+ +------+ +------+
| | | |
| Backdoor | | Backdoor +---------------
| link | SP network | link +---------------
| | | |
+------+ +------+ +------+ +------+
| CE | | PE | | CE | | PE |
|device|-----|router| |device|-----|router| SP network
+------+ +------+ +------+ +------+
| |
+---------------- +---------------
(c) (d)
+---------------- +---------------
| |
+------+ +------+ +------+ +------+
| CE |-----| PE | | CE |-----| PE |
|device| |router| |device| |router| SP network
+------+\\ +------+ +------+\\ +------+
| \\ | | \\ |
|Back \\ | |Back \\
+---------------
|door \\ | SP network |door \\
+---------------
|link \\ | |link \\ |
+------+ +------+ +------+ +------+
| CE | | PE | | CE | | PE |
|device|-----|router| |device|-----|router| SP network
+------+ +------+ +------+ +------+
| |
+---------------- +---------------
(e) (f)
Figure 2.1. Representative types of access arrangements
5.12. Service Access
Customers MAY also require access to other services, as described in
this section.
5.12.1. Internet Access
Customers SHOULD be able to have L3VPN and Internet access across the
same access network for one or more of the customer’s sites.
Customers SHOULD be able to direct Internet traffic from the set of
sites in the L3VPN to one or more customer sites that have firewalls,
other security-oriented devices, and/or NATs that process all traffic
between the Internet and the customer’s VPN.
L3 VPN Customers SHOULD be able to receive traffic from the Internet
addressed to a publicly accessible resource that is not part of the
VPN, such as an enterprise’s public web server.
As stated in section 5.3, if a customer L3VPN employs private or
non-unique IP addresses, then network address translation (NAT) or a
similar mechanism MUST be provided either by the customer or the SP
in order to allow traffic exchange with devices outside the
customer’s L3VPN.
5.12.2. Hosting, Application Service Provider
A customer SHOULD be able to access hosting, other application
services, or other Application Service Providers (ASP) over an L3
L3VPN service. This MAY require that an ASP participate in one or
more VPNs with the customers that use such a service.
5.12.3. Other Services
In conjunction with a VPN service, a customer MAY also wish to have
access to other services, such as DNS, FTP, HTTP, NNTP, SMTP, LDAP,
VoIP, NAT, LDAP, Videoconferencing, Application sharing, E-business,
Streaming, E-commerce, Directory, Firewall, etc. The resources that
implement these services could be physically dedicated to each VPN.
If the resources are logically shared, then they MUST have access
separated and isolated between VPNs in a manner consistent with the
L3VPN solution to meet this requirement.
5.13. Hybrid VPN Service Scenarios
Intranet or extranet customers have a number of reasons for wanting
hybrid networks that involve more than one VPN solution type. These
include migration, mergers, extranet customers with different VPN
types, the need for different capabilities between different sets of
sites, temporary access, and different availability of VPN solutions
as provided by different service providers.
The framework and solution approaches SHOULD include provisions for
interworking, interconnection, and/or reachability between different
L3VPN solutions in a way that does not overly complicate
provisioning, management, scalability, or performance.
6. Service Provider Network Requirements
This section describes requirements from a service provider
perspective.
6.1. Scalability
[RFC3809] lists projections of L3VPN sizing and scalability
requirements and metrics related to specific solutions.
6.2. Addressing
As described in section 4.2, SPs MUST have support for public and
private IP addresses, IPv4 and IPv6, for both unicast and multicast.
In order to support this range of addressing schemes, SPs require the
following support from L3VPN solutions.
An L3VPN solution MUST be able to assign blocks of addresses from its
own public IP address space to L3VPN customer sites so that
advertisement of routes to other SPs and other sites aggregates
efficiently.
An L3VPN solution MUST be able to use address assignments made by a
customer. These customer-assigned addresses may be public or
private.
If private IP addresses are used, an L3VPN solution MUST provide a
means for an SP to translate such addresses to public IP addresses
for communication with other VPNs by using overlapping addresses or
the Internet.
6.3. Identifiers
A number of identifiers MAY be necessary for SP use in management,
control, and routing protocols. Requirements for at least the
following identifiers are known.
An SP domain MUST be uniquely identified at least within the set of
all interconnected SP networks when supporting a VPN that spans
multiple SPs. Ideally, this identifier should be globally unique
(e.g., an AS number).
An identifier for each VPN SHOULD be unique, at least within each
SP’s network. Ideally, the VPN identifier SHOULD be globally unique
to support the case where a VPN spans multiple SPs (e.g., [RFC2685]).
A CE device SHOULD have a unique identifier, at least within each
SP’s network.
A PE device SHOULD have a unique identifier, at least within each
SP’s network.
The identifier of a device interconnecting SP networks MUST be unique
within the set of aforementioned networks.
Each site interface SHOULD have a unique identifier, at least within
each PE router supporting such an interface.
Each tunnel SHOULD have a unique identifier, at least within each
router supporting the tunnel.
6.4. Discovering VPN Related Information
Configuration of CE and PE devices is a significant task for a
service provider. Solutions SHOULD strive to contain methods that
dynamically allow VPN information to be discovered (or learned) by
the PE and/or CE to reduce configuration complexity. The following
specific requirements apply to intra- and inter-provider VPNs
[VPNDISC].
Every device involved in a VPN SHALL be able to identify and
authenticate itself to other devices in the VPN. After learning the
VPN membership, the devices SHOULD be able to exchange configuration
information securely. The VPN information MUST include at least the
IP address of the PE and may be extensible to provide additional
information.
Each device in a VPN SHOULD be able to determine which other devices
belong to the same VPN. Such a membership discovery scheme MUST
prevent unauthorized access and allow authentication of the source.
Distribution of VPN information SHOULD be limited to those devices
involved in that VPN.
In the case of a PE-based VPN, a solution SHOULD support the means
for attached CEs to authenticate each other and verify that the SP’s
VPN network is correctly configured.
The mechanism SHOULD respond to VPN membership changes in a timely
manner. This is no longer than the provisioning timeframe, typically
on the order of minutes, and could be as short as the timeframe
required for "rerouting", typically on the order of seconds.
Dynamically creating, changing, and managing multiple VPN assignments
to sites and/or customers is another aspect of membership that MUST
be addressed in an L3VPN solution.
6.5. SLA and SLS Support
Typically, a Service Provider offering an L3VPN service commits to
specific Service Level Specifications (SLS) as part of a contract
with the customer, as described in section 4.4 and [RFC3809]. Such a
Service Level Agreement (SLA) implies SP requirements for measuring
Specific Service Level Specifications (SLS) for quality,
availability, response time, and configuration intervals.
6.6. Quality of Service (QoS) and Traffic Engineering
A significant aspect of an L3VPN is support for QoS. Since an SP has
control over the provisioning of resources and configuration of
parameters in at least the PE and P devices and, in some cases, in
the CE device as well, the onus is on the SP to provide either
managed QoS access service, or edge-to-edge QoS service, as defined
in section 4.3.2.
Each L3VPN approach MUST describe the traffic engineering techniques
available for an SP to meet the QoS objectives. These descriptions
of traffic engineering techniques SHOULD quantify scalability and
achievable efficiency. Traffic engineering support MAY be on an
aggregate or per-VPN basis.
QoS policies MUST not be impacted by security mechanisms. For
example, Diffserv policies MUST not be impacted by the use of IPSec
tunnels using the mechanisms explained in RFC 2983 [RFC2983].
As stated in RFC 2475, a mapping function from customer provided
Diffserv marking to marking used in an SP network should be provided
for L3 VPN services.
If a customer requires DSCP transparency, as described in section
5.5.2, an L3VPN service MUST deliver the same value of DSCP field in
the IP header received from the customer to the egress demarcation of
the destination.
6.7. Routing
The distribution of reachability and routing policy SHOULD be
constrained to the sites that are members of the VPN.
Optionally, the exchange of such information MAY use some form of
authentication (e.g., MD5).
Functions to isolate the SP network and customer VPNs from anomalous
routing behavior from a specific set of customer sites SHOULD be
provided. Examples of such functions are controls for route flap
dampening, filters that accept only prefixes configured for a
specific CE, a maximum number of routes accepted for each CE, or a
maximum rate at which route updates can be received from a CE.
When VPN customers use overlapping non-unique IP addresses, the
solution MUST define a means to distinguish between such overlapping
addresses on a per-VPN basis.
Furthermore, the solution SHOULD provide an option that either allows
or prevents advertisement of VPN routes to the Internet.
Ideally, the choice of an SP’s IGP SHOULD not depend on the routing
protocol(s) used between PE and CE routers in a PE-based VPN.
Furthermore, it is desirable that an SP SHOULD have a choice
regarding the IGP routing protocol.
The additional routing burden that an SP must carry should be
articulated in each specific L3VPN solution.
6.8. Isolation of Traffic and Routing
The internal structure of an L3VPN network SHOULD not be visible to
outside networks (e.g., the Internet or any connected VPN).
From a high-level SP perspective, a PE-based L3VPN MUST isolate the
exchange of traffic and routing information to only those sites that
are authenticated and authorized members of a VPN.
In a CE-based VPN, the tunnels that connect the sites effectively
meet this isolation requirement if both traffic and routing
information flow over the tunnels.
An L3VPN solution SHOULD provide a means to meet L3VPN QoS SLA
requirements that isolates VPN traffic from the effects of traffic
offered by non-VPN customers. Also, L3VPN solutions SHOULD provide a
means to isolate the effects that traffic congestion produced by
sites as part of one VPN can have on another VPN.
6.9. Security
This section contains requirements related to securing customer
flows; providing authentication services for temporary, remote, or
mobile users; and protecting service provider resources involved in
supporting an L3VPN. More detailed security requirements are
provided in [VPNSEC].
6.9.1. Support for Securing Customer Flows
In order to meet the general requirement for providing a range of
security options to a customer, each L3VPN solution MUST clearly
spell out the configuration options that can work together and how
they can do so.
When a VPN solution operates over a part of the Internet, it should
support a configurable option to support one or more of the following
standard IPsec methods for securing a flow for a specified subset of
a customer’s VPN traffic:
o Confidentiality, so that only authorized devices can decrypt it
o Integrity, to ensure that the data has not been altered
o Authentication, to ensure that the sender is indeed who he or she
claims to be
o Replay attack prevention.
The above functions SHOULD be applicable to "data traffic" of the
customer, which includes the traffic exchanged between sites between
temporary users and sites, and even between temporary users. It
SHOULD also be possible to apply these functions to "control
traffic", such as routing protocol exchanges, that are not
necessarily perceived by the customer but are nevertheless essential
to maintain his or her VPN.
Furthermore, such security methods MUST be configurable between
different end points, such as CE-CE, PE-PE, and CE-PE. It is also
desirable to configure security on a per-route or per-VPN basis
[VPNSEC].
A VPN solution MAY support one or more encryption schemes, including
AES, and 3DES. Encryption, decryption, and key management SHOULD be