draft-ietf-bess-mvpn-extranet-06.txt   draft-ietf-bess-mvpn-extranet-07.txt 
BESS Working Group Y. Rekhter, Ed. BESS Working Group Y. Rekhter, Ed.
Internet-Draft E. Rosen, Ed. Internet-Draft E. Rosen, Ed.
Updates: 6513,6514,6625 (if approved) Juniper Networks, Inc. Updates: 6513,6514,6625 (if approved) Juniper Networks, Inc.
Intended status: Standards Track R. Aggarwal Intended status: Standards Track R. Aggarwal
Expires: July 15, 2016 Arktan Expires: October 14, 2016 Arktan
Y. Cai Y. Cai
Microsoft Microsoft
T. Morin T. Morin
Orange Orange
January 12, 2016 April 12, 2016
Extranet Multicast in BGP/IP MPLS VPNs Extranet Multicast in BGP/IP MPLS VPNs
draft-ietf-bess-mvpn-extranet-06 draft-ietf-bess-mvpn-extranet-07
Abstract Abstract
Previous RFCs specify the procedures necessary to allow IP multicast Previous RFCs specify the procedures necessary to allow IP multicast
traffic to travel from one site to another within a BGP/MPLS IP VPN traffic to travel from one site to another within a BGP/MPLS IP VPN
(Virtual Private Network). However, it is sometimes desirable to (Virtual Private Network). However, it is sometimes desirable to
allow multicast traffic whose source is in one VPN to be received by allow multicast traffic whose source is in one VPN to be received by
systems that are in another VPN. This is known as a "Multicast VPN systems that are in another VPN. This is known as a "Multicast VPN
(MVPN) extranet". This document updates RFCs 6513, 6514, and 6625 by (MVPN) extranet". This document updates RFCs 6513, 6514, and 6625 by
specifying the procedures that are necessary in order to provide MVPN specifying the procedures that are necessary in order to provide MVPN
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 15, 2016. This Internet-Draft will expire on October 14, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 38 skipping to change at page 2, line 38
Spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1. Ambiguity: P-tunnel with 2.1. Ambiguity: P-tunnel with
Extranet/Non-Extranet Flows . . . . . . . . . . . . . . . 13 Extranet/Non-Extranet Flows . . . . . . . . . . . . . . . 13
2.2. Ambiguity: P-tunnel with Multiple 2.2. Ambiguity: P-tunnel with Multiple
Extranet Flows . . . . . . . . . . . . . . . . . . . . . 15 Extranet Flows . . . . . . . . . . . . . . . . . . . . . 15
2.3. Preventing Misdelivery in These 2.3. Preventing Misdelivery in These
Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 17 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.1. Do Not Deliver Packets from the 'Wrong' P-tunnel . . 17 2.3.1. Do Not Deliver Packets from the 'Wrong' P-tunnel . . 17
2.3.2. Policies to Prevent Ambiguity on a P-tunnel . . . . . 19 2.3.2. Policies to Prevent Ambiguity on a P-tunnel . . . . . 19
3. Extranet Transmission Models . . . . . . . . . . . . . . . . 20 3. Extranet Transmission Models . . . . . . . . . . . . . . . . 20
3.1. Transmitting an Extranet C-flow on a Single PMSI . . . . 20 3.1. Transmitting an Extranet C-flow on a Single PMSI . . . . 21
3.1.1. Without Extranet Separation . . . . . . . . . . . . . 21 3.1.1. Without Extranet Separation . . . . . . . . . . . . . 21
3.1.2. With Extranet Separation . . . . . . . . . . . . . . 21 3.1.2. With Extranet Separation . . . . . . . . . . . . . . 21
3.2. Transmitting an Extranet C-flow over Multiple PMSIs . . . 21 3.2. Transmitting an Extranet C-flow over Multiple PMSIs . . . 22
4. Distribution of Routes that Match 4. Distribution of Routes that Match
C-S/C-RP Addresses . . . . . . . . . . . . . . . . . . . . . 22 C-S/C-RP Addresses . . . . . . . . . . . . . . . . . . . . . 22
4.1. UMH-Eligible Routes . . . . . . . . . . . . . . . . . . . 22 4.1. UMH-Eligible Routes . . . . . . . . . . . . . . . . . . . 22
4.1.1. Extranet Separation . . . . . . . . . . . . . . . . . 23 4.1.1. Extranet Separation . . . . . . . . . . . . . . . . . 23
4.2. Distribution of Unicast Routes 4.2. Distribution of Unicast Routes
Matching C-RPs and DRs . . . . . . . . . . . . . . . . . 23 Matching C-RPs and DRs . . . . . . . . . . . . . . . . . 24
4.3. Route Targets and Ambiguous 4.3. Route Targets and Ambiguous
UMH-Eligible Routes . . . . . . . . . . . . . . . . . . . 24 UMH-Eligible Routes . . . . . . . . . . . . . . . . . . . 25
4.4. Dynamically Marking Extranet 4.4. Dynamically Marking Extranet
Routes . . . . . . . . . . . . . . . . . . . . . . . . . 26 Routes . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.4.1. The Extranet Source Extended 4.4.1. The Extranet Source Extended
Community . . . . . . . . . . . . . . . . . . . . . . 26 Community . . . . . . . . . . . . . . . . . . . . . . 26
4.4.2. Distribution of Extranet Source Extended 4.4.2. Distribution of Extranet Source Extended
Community . . . . . . . . . . . . . . . . . . . . . . 27 Community . . . . . . . . . . . . . . . . . . . . . . 28
4.5. The 'Extranet Separation' Extended Community . . . . . . 28 4.5. The 'Extranet Separation' Extended Community . . . . . . 29
5. Origination and Distribution of BGP A-D Routes . . . . . . . 29 5. Origination and Distribution of BGP A-D Routes . . . . . . . 29
5.1. Route Targets of UMH-eligible Routes and A-D 5.1. Route Targets of UMH-eligible Routes and A-D
Routes . . . . . . . . . . . . . . . . . . . . . . . . . 29 Routes . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2. Considerations for Particular Inclusive Tunnel 5.2. Considerations for Particular Inclusive Tunnel
Types . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Types . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.2.1. RSVP-TE P2MP or Ingress 5.2.1. RSVP-TE P2MP or Ingress
Replication . . . . . . . . . . . . . . . . . . . . . 31 Replication . . . . . . . . . . . . . . . . . . . . . 32
5.2.2. Ingress Replication . . . . . . . . . . . . . . . . . 32 5.2.2. Ingress Replication . . . . . . . . . . . . . . . . . 32
6. When PIM is the PE-PE C-multicast Control Plane . . . . . . . 33 6. When PIM is the PE-PE C-multicast Control Plane . . . . . . . 34
6.1. Provisioning VRFs with RTs . . . . . . . . . . . . . . . 34 6.1. Provisioning VRFs with RTs . . . . . . . . . . . . . . . 35
6.1.1. Incoming and Outgoing Extranet RTs . . . . . . . . . 34 6.1.1. Incoming and Outgoing Extranet RTs . . . . . . . . . 35
6.1.2. UMH-eligible Routes and RTs . . . . . . . . . . . . . 35 6.1.2. UMH-eligible Routes and RTs . . . . . . . . . . . . . 36
6.1.3. PIM C-Instance Reverse Path Forwarding 6.1.3. PIM C-Instance Reverse Path Forwarding
Determination . . . . . . . . . . . . . . . . . . . . 35 Determination . . . . . . . . . . . . . . . . . . . . 36
6.2. Single PMSI per C-flow Model . . . . . . . . . . . . . . 36 6.2. Single PMSI per C-flow Model . . . . . . . . . . . . . . 36
6.2.1. Forming the MI-PMSIs . . . . . . . . . . . . . . . . 36 6.2.1. Forming the MI-PMSIs . . . . . . . . . . . . . . . . 36
6.2.2. S-PMSIs . . . . . . . . . . . . . . . . . . . . . . . 39 6.2.2. S-PMSIs . . . . . . . . . . . . . . . . . . . . . . . 39
6.2.3. Sending PIM Control Packets . . . . . . . . . . . . . 40 6.2.3. Sending PIM Control Packets . . . . . . . . . . . . . 41
6.2.4. Receiving PIM Control Packets . . . . . . . . . . . . 41 6.2.4. Receiving PIM Control Packets . . . . . . . . . . . . 41
6.2.5. Sending and Receiving Data Packets . . . . . . . . . 41 6.2.5. Sending and Receiving Data Packets . . . . . . . . . 41
6.3. Multiple PMSIs per C-flow Model . . . . . . . . . . . . . 41 6.3. Multiple PMSIs per C-flow Model . . . . . . . . . . . . . 42
6.3.1. Forming the MI-PMSIs . . . . . . . . . . . . . . . . 42 6.3.1. Forming the MI-PMSIs . . . . . . . . . . . . . . . . 42
7. When BGP is the PE-PE C-multicast Control Plane . . . . . . . 43 7. When BGP is the PE-PE C-multicast Control Plane . . . . . . . 44
7.1. Originating C-multicast Routes . . . . . . . . . . . . . 44 7.1. Originating C-multicast Routes . . . . . . . . . . . . . 44
7.2. Originating A-D Routes Without Extranet 7.2. Originating A-D Routes Without Extranet
Separation . . . . . . . . . . . . . . . . . . . . . . . 44 Separation . . . . . . . . . . . . . . . . . . . . . . . 45
7.2.1. Intra-AS I-PMSI A-D Routes . . . . . . . . . . . . . 44 7.2.1. Intra-AS I-PMSI A-D Routes . . . . . . . . . . . . . 45
7.2.2. S-PMSI A-D Routes . . . . . . . . . . . . . . . . . . 45 7.2.2. S-PMSI A-D Routes . . . . . . . . . . . . . . . . . . 46
7.2.3. Source Active A-D Routes . . . . . . . . . . . . . . 46 7.2.3. Source Active A-D Routes . . . . . . . . . . . . . . 46
7.2.3.1. When Inter-Site Shared Trees Are Used . . . . . . 46 7.2.3.1. When Inter-Site Shared Trees Are Used . . . . . . 46
7.2.3.2. When Inter-Site Shared Trees Are Not Used . . . . 46 7.2.3.2. When Inter-Site Shared Trees Are Not Used . . . . 47
7.3. Originating A-D Routes With Extranet Separation . . . . . 47 7.3. Originating A-D Routes With Extranet Separation . . . . . 47
7.3.1. Intra-AS I-PMSI A-D Routes . . . . . . . . . . . . . 47 7.3.1. Intra-AS I-PMSI A-D Routes . . . . . . . . . . . . . 47
7.3.2. S-PMSI A-D Routes . . . . . . . . . . . . . . . . . . 48 7.3.2. S-PMSI A-D Routes . . . . . . . . . . . . . . . . . . 48
7.3.3. Source Active A-D Routes . . . . . . . . . . . . . . 49 7.3.3. Source Active A-D Routes . . . . . . . . . . . . . . 50
7.4. Determining the Expected P-tunnel for a C-flow . . . . . 49 7.4. Determining the Expected P-tunnel for a C-flow . . . . . 50
7.4.1. (C-S,C-G) S-PMSI A-D Routes . . . . . . . . . . . . . 51 7.4.1. (C-S,C-G) S-PMSI A-D Routes . . . . . . . . . . . . . 52
7.4.2. (C-S,C-*) S-PMSI A-D Routes . . . . . . . . . . . . . 52 7.4.2. (C-S,C-*) S-PMSI A-D Routes . . . . . . . . . . . . . 52
7.4.3. (C-*,C-G) S-PMSI A-D Routes . . . . . . . . . . . . . 52 7.4.3. (C-*,C-G) S-PMSI A-D Routes . . . . . . . . . . . . . 52
7.4.4. (C-*,C-*) S-PMSI A-D Routes . . . . . . . . . . . . . 53 7.4.4. (C-*,C-*) S-PMSI A-D Routes . . . . . . . . . . . . . 54
7.4.5. I-PMSI A-D Routes . . . . . . . . . . . . . . . . . . 53 7.4.5. I-PMSI A-D Routes . . . . . . . . . . . . . . . . . . 54
7.5. Packets Arriving from the Wrong P-tunnel . . . . . . . . 54 7.5. Packets Arriving from the Wrong P-tunnel . . . . . . . . 55
8. Multiple Extranet VRFs on the same 8. Multiple Extranet VRFs on the same
PE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 PE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56
10. Security Considerations . . . . . . . . . . . . . . . . . . . 56 10. Security Considerations . . . . . . . . . . . . . . . . . . . 56
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 57 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58
12. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 58 12. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 58
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 58 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 59
13.1. Normative References . . . . . . . . . . . . . . . . . . 58 13.1. Normative References . . . . . . . . . . . . . . . . . . 59
13.2. Informative References . . . . . . . . . . . . . . . . . 59 13.2. Informative References . . . . . . . . . . . . . . . . . 60
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61
1. Introduction 1. Introduction
Previous RFCs ([RFC6513], [RFC6514]) specify the procedures necessary Previous RFCs ([RFC6513], [RFC6514]) specify the procedures necessary
to allow IP multicast traffic to travel from one site to another to allow IP multicast traffic to travel from one site to another
within a BGP/MPLS IP VPN (Virtual Private Network). However, it is within a BGP/MPLS IP VPN (Virtual Private Network). However, it is
sometimes desirable to allow multicast traffic whose source is in one sometimes desirable to allow multicast traffic whose source is in one
VPN to be received by systems that are in another VPN. This is known VPN to be received by systems that are in another VPN. This is known
as an "extranet MVPN". This document specifies the procedures that as an "extranet MVPN". This document specifies the procedures that
are necessary in order to provide Extranet MVPN functionality. are necessary in order to provide Extranet MVPN functionality.
skipping to change at page 5, line 31 skipping to change at page 5, line 31
"Source-Specific Multicast" (SSM) C-group addresses" (i.e., to "Source-Specific Multicast" (SSM) C-group addresses" (i.e., to
C-group addresses in the SSM group address range), but will never C-group addresses in the SSM group address range), but will never
call them "extranet C-groups". call them "extranet C-groups".
N.B.: Any source of traffic for an extranet C-group is considered N.B.: Any source of traffic for an extranet C-group is considered
to be an extranet C-source, and any receiver of traffic addressed to be an extranet C-source, and any receiver of traffic addressed
to an extranet C-group is considered to be an extranet C-receiver. to an extranet C-group is considered to be an extranet C-receiver.
o Extranet C-RP: a multicast Rendezvous Point (RP) for an extranet o Extranet C-RP: a multicast Rendezvous Point (RP) for an extranet
C-group; it is allowed by policy to receive PIM register messages C-group; it is allowed by policy to receive PIM register messages
[RFC4601] from outside its VPN, and to send multicast data packets [RFC7761] from outside its VPN, and to send multicast data packets
to extranet C-receivers outside its VPN. to extranet C-receivers outside its VPN.
o Host(C-S,A): the host (or if C-S is an "anycast address", the set o Host(C-S,A): the host (or if C-S is an "anycast address", the set
of hosts) denoted by the address C-S in the context of VPN-A. For of hosts) denoted by the address C-S in the context of VPN-A. For
example, if a particular C-source in VPN A has address C-S, then example, if a particular C-source in VPN A has address C-S, then
Host(C-S,A) refers to that C-source. Host(C-S,A) refers to that C-source.
o SAFI-n route: a BGP route whose Address Family Identifier (AFI) is o SAFI-n route: a BGP route whose Address Family Identifier (AFI) is
either 1 (IPv4) or 2 (IPv6), and whose Subsequent Address Family either 1 (IPv4) or 2 (IPv6), and whose Subsequent Address Family
Identifier (SAFI) is "n". Identifier (SAFI) is "n".
skipping to change at page 11, line 17 skipping to change at page 11, line 17
Therefore it is NOT RECOMMENDED to allow an extranet C-source to Therefore it is NOT RECOMMENDED to allow an extranet C-source to
transmit non-extranet C-flows. However, the Service Provider (SP) transmit non-extranet C-flows. However, the Service Provider (SP)
has no control over the set of C-flows transmitted by a given has no control over the set of C-flows transmitted by a given
C-source, and can do no more than communicate this recommendation to C-source, and can do no more than communicate this recommendation to
its customers. (Alternatively, the customer and SP may coordinate on its customers. (Alternatively, the customer and SP may coordinate on
setting up filters to prevent unauthorized flows from being sent to a setting up filters to prevent unauthorized flows from being sent to a
customer site; such a procedure is outside the scope of this customer site; such a procedure is outside the scope of this
document.) See the "Security Considerations" section (Section 10) document.) See the "Security Considerations" section (Section 10)
for additional discussion of this issue. for additional discussion of this issue.
Whenever a VPN is provisioned, there is a risk that errors in
provisioning may result in an unintended cross-connection of VPNs.
This would create a security problem for the customers. When
provisioning an extranet, attention to detail is particularly
important, as extranet intentionally cross-connects VPNs. Care must
always be taken to ensure that the cross-connections are according to
the policy agreed upon by the SP and its customers.
Additionally, if one is connecting two VPNs that have overlapping
address spaces, one has to be sure that the inter-VPN traffic neither
originates from nor is destined to the part of the address space that
is in the overlap. Other problems that can arise due to overlapping
address spaces are discussed in Section 2.
2. Extranets and Overlapping Address Spaces 2. Extranets and Overlapping Address Spaces
As specified in [RFC4364], the address space of one VPN may overlap As specified in [RFC4364], the address space of one VPN may overlap
with the address space of another. A given address may be with the address space of another. A given address may be
"ambiguous", in that it denotes one system within VPN-A and a "ambiguous", in that it denotes one system within VPN-A and a
different system within VPN-B. In the notation of Section 1.1, if an different system within VPN-B. In the notation of Section 1.1, if an
address C-S is ambiguous between VPNs A and B, then Host(C-S,A) != address C-S is ambiguous between VPNs A and B, then Host(C-S,A) !=
Host(C-S,B). However, any given address C-S MUST be unambiguous Host(C-S,B). However, any given address C-S MUST be unambiguous
(i.e., MUST denote a single system) in the context of a given VPN. (i.e., MUST denote a single system) in the context of a given VPN.
skipping to change at page 23, line 39 skipping to change at page 24, line 10
UMH-eligible routes both for extranet C-sources for non-extranet UMH-eligible routes both for extranet C-sources for non-extranet
C-sources, then the VRF MUST be configured not only with its "default C-sources, then the VRF MUST be configured not only with its "default
RD", but also with an "extranet RD". The exported UMH-eligible RD", but also with an "extranet RD". The exported UMH-eligible
routes MUST contain the extranet RD in their NLRIs. routes MUST contain the extranet RD in their NLRIs.
4.2. Distribution of Unicast Routes Matching C-RPs and DRs 4.2. Distribution of Unicast Routes Matching C-RPs and DRs
Consider a C-source, C-S, that may transmit to a particular extranet Consider a C-source, C-S, that may transmit to a particular extranet
C-group, C-G. C-group, C-G.
In order to follow the procedures of [RFC4601], In order to follow the procedures of [RFC7761],
o the "first hop designated router" (DR) of C-S needs to be able to o the "first hop designated router" (DR) of C-S needs to be able to
unicast "PIM Register Messages" to a C-RP that services C-G; unicast "PIM Register Messages" to a C-RP that services C-G;
o the C-RPs servicing C-G need to be able to unicast "PIM Register- o the C-RPs servicing C-G need to be able to unicast "PIM Register-
Stop Messages" to the DR of C-S. Stop Messages" to the DR of C-S.
It follows that if a VRF contains C-S, but does not contain a C-RP It follows that if a VRF contains C-S, but does not contain a C-RP
for C-G, then the VRF MUST import a unicast route matching a C-RP for for C-G, then the VRF MUST import a unicast route matching a C-RP for
C-G. Note that the unicast route matching the C-RP is needed whether C-G. Note that the unicast route matching the C-RP is needed whether
skipping to change at page 56, line 29 skipping to change at page 57, line 7
10. Security Considerations 10. Security Considerations
The security considerations of [RFC6513] and [RFC6514] are The security considerations of [RFC6513] and [RFC6514] are
applicable. applicable.
As is the case with any application of technology based upon As is the case with any application of technology based upon
[RFC4364], misconfiguration of the RTs may result in VPN security [RFC4364], misconfiguration of the RTs may result in VPN security
violations (i.e., may result in a packet being delivered to a VPN violations (i.e., may result in a packet being delivered to a VPN
where, according to policy, it is not supposed to go). where, according to policy, it is not supposed to go).
In those cases where the set of extranet sources of a particular VRF
is manually configured, improper configuration of the VRF can result
in VPN security violations -- traffic from a host that is not an
extranet source may be treated as if it were traffic from an extranet
source.
Section 4.4 specifies the optional use of a new Extended Community,
the Extranet Source Extended Community. Security considerations
regarding the use and distribution of that Extended Community are
discussed in that section.
The procedures of this document do not provide encryption of the data The procedures of this document do not provide encryption of the data
flows that are sent across the SP backbone network. Hence these flows that are sent across the SP backbone network. Hence these
procedures do not by themselves ensure the privacy or integrity of procedures do not by themselves ensure the privacy or integrity of
the data against attacks on the backbone network. the data against attacks on the backbone network.
In general, different VPNs are allowed to have overlapping IP address In general, different VPNs are allowed to have overlapping IP address
spaces, i.e., a host in one VPN may have the same IP address as a spaces, i.e., a host in one VPN may have the same IP address as a
host in another. This is safe because the customer routes from a host in another. This is safe because the customer routes from a
given VPN do not pass into other VPNs. Even if there is overlapping given VPN do not pass into other VPNs. Even if there is overlapping
address space among VPNs, the routes that are known at any given VPN address space among VPNs, the routes that are known at any given VPN
site are unambiguous, as long as the address space of that VPN is site are unambiguous, as long as the address space of that VPN is
unambiguous. However, this is not necessarily true when extranet unambiguous. However, this is not necessarily true when extranet
service is provided. If an extranet C-receiver in VPN-R is to be service is provided. If an extranet C-receiver in VPN-R is to be
able to receive multicast traffic from an extranet C-source in VPN-S, able to receive multicast traffic from an extranet C-source in VPN-S,
then the address of the VPN-S extranet C-source must be imported into then the address of the VPN-S extranet C-source must be imported into
one or more VPN-R VRFs. If that address is also the address of a one or more VPN-R VRFs. If that address is also the address of a
VPN-R non-extranet C-source, then a system attempting to receive an VPN-R non-extranet C-source, then a system attempting to receive an
extranet C-flow from the VPN-R extranet C-source may instead receive extranet C-flow from the VPN-R extranet C-source may instead receive
a non-extranet C-flow from the VPN-S C-source. This would result in a non-extranet C-flow from the VPN-S C-source. Otherwise a a VPN
a VPN security violation. security violation may result.
To avoid this, this document specifies that if a route is imported That is, when provisioning an extranet between two VPNs that have
into a given VRF, all addresses that match that route must be overlapping address spaces, one must ensure that the IP addresses of
unambiguous in the context of that VRF. Improper provisioning of the the extranet sources and the extranet receivers are not from the
RTs may cause this rule to be violated, and hence result in a VPN overlapping part of the address space. This document specifies that
security violation. if a route is imported into a given VRF, all addresses that match
that route must be unambiguous in the context of that VRF. Improper
provisioning of the extranet source addresses, or improper
provisioning of the RTs, may cause this rule to be violated, and may
result in a VPN security violation.
It is possible that a given multicast C-source is the source of It is possible that a given multicast C-source is the source of
multiple flows, some of which are intended to be extranet C-flows, multiple flows, some of which are intended to be extranet C-flows,
and some of which are intended to be non-extranet flows. However, and some of which are intended to be non-extranet flows. However,
the procedures of this document will allow any C-receiver that is the procedures of this document will allow any C-receiver that is
able to receive the extranet C-flows from a given C-source to also able to receive the extranet C-flows from a given C-source to also
receive the non-extranet C-flows from that source. As a result, VPN receive the non-extranet C-flows from that source. As a result, VPN
security violations may result if any system is a C-source for both security violations may result if any system is a C-source for both
extranet and non-extranet C-flows. However, the set of C-flows extranet and non-extranet C-flows. However, the set of C-flows
transmitted by a given C-source is not under the control of the SP. transmitted by a given C-source is not under the control of the SP.
skipping to change at page 57, line 33 skipping to change at page 58, line 27
matches the address of both an extranet C-source and a non-extranet matches the address of both an extranet C-source and a non-extranet
C-source. If such a route is exported from a VPN-S VRF and imported C-source. If such a route is exported from a VPN-S VRF and imported
by a VPN-R VRF, C-receivers contained in VPN-R will be able to by a VPN-R VRF, C-receivers contained in VPN-R will be able to
receive C-flows from the non-extranet C-sources whose addresses match receive C-flows from the non-extranet C-sources whose addresses match
that route. This may result in VPN security violations. Service that route. This may result in VPN security violations. Service
providers who offer the extranet MVPN service must make sure that providers who offer the extranet MVPN service must make sure that
this is clearly understood by the customers who administer the this is clearly understood by the customers who administer the
distribution of routes from CE to PE routers. distribution of routes from CE to PE routers.
If the address ambiguities described in Sections 2.1 and 2.2 are not If the address ambiguities described in Sections 2.1 and 2.2 are not
prohibited by policy, VRFs must be able to discard traffic that prohibited by deployment of the policies described in Section 2.3.2,
arrives on the wrong P-tunnel; otherwise VPN security violations may VRFs must be able to discard traffic that arrives on the wrong
occur. P-tunnel (as specified in Section 2.3.1 and Section 7.5). Otherwise
VPN security violations may occur.
Section 4.4 specifies the optional use of a new Extended Community,
the Extranet Source Extended Community. Security considerations
regarding the use and distribution of that Extended Community are
discussed in that section.
11. Acknowledgments 11. Acknowledgments
The authors wish to thank DP Ayyadevara, Robert Kebler, Padmini The authors wish to thank DP Ayyadevara, Robert Kebler, Padmini
Misra, Rayen Mohanty, Maria Napierala, Karthik Subramanian, and Kurt Misra, Rayen Mohanty, Maria Napierala, Karthik Subramanian, and Kurt
Windisch for their contributions to this work. Windisch for their contributions to this work.
We also wish to thank Lizhong Jin and Rishabh Parekh for their We also wish to thank Lizhong Jin and Rishabh Parekh for their
reviews and comments. reviews and comments.
Special thanks to Jeffrey (Zhaohui) Zhang for his careful review and Special thanks to Jeffrey (Zhaohui) Zhang for his careful review and
for providing the ascii art appearing in Section 2. for providing the ascii art appearing in Section 2.
12. Contributor Addresses 12. Contributor Addresses
Below is a list of other contributing authors in alphabetical order: Below is a list of other contributing authors in alphabetical order:
Wim Henderickx Wim Henderickx
Alcatel-Lucent Nokia
Copernicuslaan 50 Copernicuslaan 50
Antwerp 2018 Antwerp 2018
Belgium Belgium
Email: wim.henderickx@alcatel-lucent.com Email: wim.henderickx@nokia.com
Praveen Muley Praveen Muley
Alcatel-Lucent Nokia
Email: Praveen.Muley@alcatel-lucent.com Email: Praveen.Muley@nokia.com
Ray Qiu Ray Qiu
Juniper Networks, Inc. Juniper Networks, Inc.
1194 North Mathilda Avenue 1194 North Mathilda Avenue
Sunnyvale, CA 94089 Sunnyvale, CA 94089
United States United States
Email: rqiu@juniper.net Email: rqiu@juniper.net
IJsbrand Wijnands IJsbrand Wijnands
skipping to change at page 59, line 13 skipping to change at page 60, line 5
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
February 2006, <http://www.rfc-editor.org/info/rfc4360>. February 2006, <http://www.rfc-editor.org/info/rfc4360>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <http://www.rfc-editor.org/info/rfc4364>. 2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601,
DOI 10.17487/RFC4601, August 2006,
<http://www.rfc-editor.org/info/rfc4601>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <http://www.rfc-editor.org/info/rfc6513>. 2012, <http://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<http://www.rfc-editor.org/info/rfc6514>. <http://www.rfc-editor.org/info/rfc6514>.
[RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R.
Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes",
RFC 6625, DOI 10.17487/RFC6625, May 2012, RFC 6625, DOI 10.17487/RFC6625, May 2012,
<http://www.rfc-editor.org/info/rfc6625>. <http://www.rfc-editor.org/info/rfc6625>.
[RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP
Extended Communities", RFC 7153, DOI 10.17487/RFC7153, Extended Communities", RFC 7153, DOI 10.17487/RFC7153,
March 2014, <http://www.rfc-editor.org/info/rfc7153>. March 2014, <http://www.rfc-editor.org/info/rfc7153>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <http://www.rfc-editor.org/info/rfc7761>.
13.2. Informative References 13.2. Informative References
[MVPN-IR] Rosen, E., Subramanian, K., and Z. Zhang, "Ingress [MVPN-IR] Rosen, E., Subramanian, K., and Z. Zhang, "Ingress
Replication Tunnels in Multicast VPN", internet-draft Replication Tunnels in Multicast VPN", internet-draft
draft-ietf-bess-ir-02, October 2015. draft-ietf-bess-ir-03, April 2016.
[RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast [RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast
Rendevous Point (RP) mechanism using Protocol Independent Rendevous Point (RP) mechanism using Protocol Independent
Multicast (PIM) and Multicast Source Discovery Protocol Multicast (PIM) and Multicast Source Discovery Protocol
(MSDP)", RFC 3446, DOI 10.17487/RFC3446, January 2003, (MSDP)", RFC 3446, DOI 10.17487/RFC3446, January 2003,
<http://www.rfc-editor.org/info/rfc3446>. <http://www.rfc-editor.org/info/rfc3446>.
[RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source
Discovery Protocol (MSDP)", RFC 3618, Discovery Protocol (MSDP)", RFC 3618,
DOI 10.17487/RFC3618, October 2003, DOI 10.17487/RFC3618, October 2003,
 End of changes. 36 change blocks. 
63 lines changed or deleted 88 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/