draft-ietf-lisp-vpn-06.txt   draft-ietf-lisp-vpn-07.txt 
Network Working Group V. Moreno Network Working Group V.M. Moreno
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Experimental D. Farinacci Intended status: Experimental D.F. Farinacci
Expires: February 4, 2021 lispers.net Expires: 27 January 2022 lispers.net
August 3, 2020 26 July 2021
LISP Virtual Private Networks (VPNs) LISP Virtual Private Networks (VPNs)
draft-ietf-lisp-vpn-06 draft-ietf-lisp-vpn-07
Abstract Abstract
This document describes the use of the Locator/ID Separation Protocol This document describes the use of the Locator/ID Separation Protocol
(LISP) to create Virtual Private Networks (VPNs). LISP is used to (LISP) to create Virtual Private Networks (VPNs). LISP is used to
provide segmentation in both the LISP data plane and control plane. provide segmentation in both the LISP data plane and control plane.
These VPNs can be created over the top of the Internet or over These VPNs can be created over the top of the Internet or over
private transport networks, and can be implemented by Enterprises or private transport networks, and can be implemented by Enterprises or
Service Providers. The goal of these VPNs is to leverage the Service Providers. The goal of these VPNs is to leverage the
characteristics of LISP - routing scalability, simply expressed characteristics of LISP - routing scalability, simply expressed
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 February 4, 2021. This Internet-Draft will expire on 27 January 2022.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3
3. LISP Virtual Private Networks (VPNs) . . . . . . . . . . . . 4 3. LISP Virtual Private Networks (VPNs) . . . . . . . . . . . . 4
3.1. The LISP IID in the Control Plane . . . . . . . . . . . . 6 3.1. The LISP IID in the Control Plane . . . . . . . . . . . . 6
3.2. The LISP IID in the Data Plane . . . . . . . . . . . . . 7 3.2. The LISP IID in the Data Plane . . . . . . . . . . . . . 7
3.3. Locator Network Segmentation . . . . . . . . . . . . . . 7 3.3. Locator Network Segmentation . . . . . . . . . . . . . . 7
3.4. Multicast in LISP VPN environments . . . . . . . . . . . 8 3.4. Multicast in LISP VPN environments . . . . . . . . . . . 8
4. LISP VPN Extranet . . . . . . . . . . . . . . . . . . . . . . 8 4. LISP VPN Extranet . . . . . . . . . . . . . . . . . . . . . . 8
4.1. LISP Extranet VPN Control Plane . . . . . . . . . . . . . 9 4.1. LISP Extranet VPN Control Plane . . . . . . . . . . . . . 9
4.1.1. LISP Extranet VPN Map Register Procedures . . . . . . 9 4.1.1. LISP Extranet VPN Map Register Procedures . . . . . . 10
4.1.2. LISP Extranet VPN Map Lookup Procedures . . . . . . . 10 4.1.2. LISP Extranet VPN Map Lookup Procedures . . . . . . . 10
4.1.3. LISP Extranet Publish/Subscribe Procedures . . . . . 10 4.1.3. LISP Extranet Publish/Subscribe Procedures . . . . . 11
4.1.4. LISP Extranet VPN Home-IID encoding . . . . . . . . . 11 4.1.4. LISP Extranet VPN Home-IID encoding . . . . . . . . . 11
4.2. LISP Extranet VPN Data Plane . . . . . . . . . . . . . . 12 4.2. LISP Extranet VPN Data Plane . . . . . . . . . . . . . . 12
4.3. LISP Extranet VPN Multicast Considerations . . . . . . . 12 4.3. LISP Extranet VPN Multicast Considerations . . . . . . . 12
4.3.1. LISP Extranet VPN Multicast Control Plane . . . . . . 12 4.3.1. LISP Extranet VPN Multicast Control Plane . . . . . . 13
4.3.2. LISP Extranet VPN Multicast Data Plane . . . . . . . 13 4.3.2. LISP Extranet VPN Multicast Data Plane . . . . . . . 13
4.4. LISP Extranet SMR Considerations . . . . . . . . . . . . 13 4.4. LISP Extranet SMR Considerations . . . . . . . . . . . . 14
4.4.1. Home-IID inclusion in SMR messages . . . . . . . . . 13 4.4.1. Home-IID inclusion in SMR messages . . . . . . . . . 14
4.5. LISP Extranet RLOC Probing Considerations . . . . . . . . 14 4.5. LISP Extranet RLOC Probing Considerations . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5.1. LISP VPNs and LISP Crypto . . . . . . . . . . . . . . . . 14 5.1. LISP VPNs and LISP Crypto . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
Network virtualization creates multiple, logically separated Network virtualization creates multiple, logically separated
topologies across one common physical infrastructure. These topologies across one common physical infrastructure. These
logically separated topologies are known as Virtual Private Networks logically separated topologies are known as Virtual Private Networks
(VPNs) and are generally used to create closed groups of end-points. (VPNs) and are generally used to create closed groups of end-points.
Network reachability within a VPN is restricted to the addresses of Network reachability within a VPN is restricted to the addresses of
the end-points that are members of the VPN. This level of the end-points that are members of the VPN. This level of
skipping to change at page 4, line 16 skipping to change at page 4, line 19
Home-IID - In the context of cross VPN connectivity, a particular EID Home-IID - In the context of cross VPN connectivity, a particular EID
will be registered with multiple Instance-IDs, the Home-IID will be registered with multiple Instance-IDs, the Home-IID
identifies the Instance-ID associated to the Forwarding Context (VRF) identifies the Instance-ID associated to the Forwarding Context (VRF)
to which an EID is actually connected. to which an EID is actually connected.
Extranet-VPN - In the context of cross VPN connectivity, a VPN that Extranet-VPN - In the context of cross VPN connectivity, a VPN that
is reachable by all Extranet-Subscriber-VPNs and can reach all is reachable by all Extranet-Subscriber-VPNs and can reach all
Extranet-Subscriber-VPNs. Extranet-Subscriber-VPNs.
Extranet-Subscriber-VPN - The VPNs that can reach the Extranet- Extranet-Subscriber-VPN - The VPNs that can reach the Extranet-VPN,
Provider-VPN, but cannot reach each other. but cannot reach each other.
Extranet Policy - The definition of which VPNs share reachability Extranet Policy - The definition of which VPNs share reachability
information with each other in the context of cross VPN connectivity. information with each other in the context of cross VPN connectivity.
May be structured as a group of Extranet-Subscriber-VPNs that May be structured as a group of Extranet-Subscriber-VPNs that
subscribe to an Extranet-VPN. subscribe to an Extranet-VPN.
3. LISP Virtual Private Networks (VPNs) 3. LISP Virtual Private Networks (VPNs)
A LISP VPN is a collection of LISP Sites building an Overlay Network. A LISP VPN is a collection of LISP Sites building an Overlay Network.
These sites share a common control plane, the LISP Mapping System. These sites share a common control plane, the LISP Mapping System.
skipping to change at page 5, line 45 skipping to change at page 6, line 5
encapsulation header is removed and the IID received in the header is encapsulation header is removed and the IID received in the header is
used to identify the forwarding context to use to do a forwarding used to identify the forwarding context to use to do a forwarding
lookup for the decapsulated traffic. lookup for the decapsulated traffic.
A more formal description of the Control and Data Plane procedures A more formal description of the Control and Data Plane procedures
for a LISP VPN is documented in the following sections. for a LISP VPN is documented in the following sections.
In order to create VPNs, the following segmentation functions must be In order to create VPNs, the following segmentation functions must be
provided: provided:
o Device Segmentation. The forwarding tables of the devices must be * Device Segmentation. The forwarding tables of the devices must be
segmented so that independent forwarding decisions can be made for segmented so that independent forwarding decisions can be made for
each virtual network. Virtual Routing and Forwarding (VRF) each virtual network. Virtual Routing and Forwarding (VRF)
contexts may be used to create multiple instances of Layer 3 contexts may be used to create multiple instances of Layer 3
routing tables virtualization (segmentation) at the device level. routing tables virtualization (segmentation) at the device level.
If the EID space is in a Layer 2 address family (e.g. MAC If the EID space is in a Layer 2 address family (e.g. MAC
addresses), then Layer 2 contexts such as VLANs or bridge domains addresses), then Layer 2 contexts such as VLANs or bridge domains
may be used to segment the device. We generalize the concept of may be used to segment the device. We generalize the concept of
separate forwarding tables as forwarding contexts. separate forwarding tables as forwarding contexts.
o Data Plane Segmentation. Data Plane Forwarding separation is * Data Plane Segmentation. Data Plane Forwarding separation is
necessary for the devices to maintain virtual network semantics at necessary for the devices to maintain virtual network semantics at
forwarding time. Data plane separation can be maintained across forwarding time. Data plane separation can be maintained across
network paths using either single-hop path segmentation (hop-by- network paths using either single-hop path segmentation (hop-by-
hop) or multi-hop path segmentation. Single-hop path segmentation hop) or multi-hop path segmentation. Single-hop path segmentation
mechanisms include constructs such as 802.1q VLAN trunks, multi- mechanisms include constructs such as 802.1q VLAN trunks, multi-
hop mechanisms include MPLS, LISP, VXLAN and GRE tunnels. hop mechanisms include MPLS, LISP, VXLAN and GRE tunnels.
o Control Plane Segmentation. In order to correctly populate the * Control Plane Segmentation. In order to correctly populate the
multiple forwarding tables in the segmented network devices, the multiple forwarding tables in the segmented network devices, the
control plane needs to be segmented so that the different updates control plane needs to be segmented so that the different updates
that are conveyed by the control plane contain the necessary that are conveyed by the control plane contain the necessary
virtual network semantics to discriminate between information virtual network semantics to discriminate between information
relevant to one segment vs another. Control plane segmentation is relevant to one segment vs another. Control plane segmentation is
key to allowing sites to use overlapping network prefixes in these key to allowing sites to use overlapping network prefixes in these
logically separate topologies. BGP/MPLS VPNs (ref RFC 4364) are logically separate topologies. BGP/MPLS VPNs (ref RFC 4364) are
an example of this control plane segmentation. an example of this control plane segmentation.
3.1. The LISP IID in the Control Plane 3.1. The LISP IID in the Control Plane
skipping to change at page 9, line 20 skipping to change at page 9, line 28
header. Upon decapsulation at the ETR, traffic is handed directly to header. Upon decapsulation at the ETR, traffic is handed directly to
the destination VPN's forwarding context based on the IID used in the the destination VPN's forwarding context based on the IID used in the
header. header.
A more formal description of the Control and Data Plane procedures A more formal description of the Control and Data Plane procedures
for a LISP VPN Extranet is documented in the following sections. for a LISP VPN Extranet is documented in the following sections.
4.1. LISP Extranet VPN Control Plane 4.1. LISP Extranet VPN Control Plane
In order to achieve reachability across VPNs, EID mapping entries in In order to achieve reachability across VPNs, EID mapping entries in
the Extranet Provider VPN must be accessible for lookups initiated the Extranet-VPN must be accessible for lookups initiated from an
from an Extranet Subscriber VPN and vice-versa. Extranet-Subscriber-VPN and vice-versa.
The definition of which VPNs share reachability information is The definition of which VPNs share reachability information is
governed by configurable Extranet Policy. The Extranet Policy will governed by configurable Extranet Policy. The Extranet Policy will
simply state which VPNs are extranet subscribers to a particular simply state which VPNs are extranet-subscribers to a particular
extranet provider VPN. There may be multiple provider VPNs in a LISP extranet-VPN. There may be multiple Extranet-VPNs in a LISP network
network and a VPN may subscribe to multiple provider VPNs. A and a VPN may subscribe to multiple Extranet-VPNs. An Extranet-
subscriber VPN may act as a provider VPN to provide reachability subscriber-VPN may act as an Extranet-VPN to provide reachability
across subscriber VPNs, this effectively merges the subscriber VPNs across Extranet-subscriber-VPNs, this effectively merges the
together, a scenario that is usually better achieved by creating a Extranet-subscriber-VPNs together, a scenario that is usually better
single subscriber VPN. achieved by creating a single Extranet-subscriber-VPN.
The Instance-ID (IID) for the VPN to which an EID is connected is The Instance-ID (IID) for the VPN to which an EID is connected is
referred to as the Home-IID of the EID. As cross VPN registrations referred to as the Home-IID of the EID. As cross VPN registrations
and lookups take place, the Home-IID for an EID must be preserved and and lookups take place, the Home-IID for an EID must be preserved and
communicated in any pertinent LISP messages. communicated in any pertinent LISP messages.
4.1.1. LISP Extranet VPN Map Register Procedures 4.1.1. LISP Extranet VPN Map Register Procedures
An ETR may register EIDs in their Home-IID as well as in the other An ETR may register EIDs in their Home-IID as well as in the other
IIDs within the scope of the Extranet Policy. For example, an EID IIDs within the scope of the Extranet Policy. For example, an EID
skipping to change at page 10, line 35 skipping to change at page 10, line 50
Map-Reply messages must use the IID of the requesting EID and must Map-Reply messages must use the IID of the requesting EID and must
also include the Home-IID of the destination EID. The Home-IID is a also include the Home-IID of the destination EID. The Home-IID is a
parameter of the destination EID, part of the mapping and must be parameter of the destination EID, part of the mapping and must be
encoded as described in Section 4.1.4. The mapping obtained in the encoded as described in Section 4.1.4. The mapping obtained in the
Map-Reply must be cached in the forwarding context of the requesting Map-Reply must be cached in the forwarding context of the requesting
EID, which is identified by the IID for the requesting EID. The EID, which is identified by the IID for the requesting EID. The
mappings cached will contain the Home-IID of the destination EID mappings cached will contain the Home-IID of the destination EID
whenever this destination EID is cached outside of its Home-IID. whenever this destination EID is cached outside of its Home-IID.
Since each IID at the Map Server has a complete set of EIDs in the
scope of the extranet policy, the deterination of a covering prefix
in the case of a non-LISP or external destination is straightforward
and follows the proceedures delineated in the procedures for a
negative map reply in [RFC6833].When the Map Server determines that
the requested destination EID is either not an EID or not registered
it must calculate the covering prefix for the requested EID and reply
in one of two ways:
- With a Negative Map Reply per the procedures outlined in [RFC6833].
If using a PeTR, the Home-IID for the PeTR must be configured at the
requesting ITR.
- WIth a Map Reply mapping the calculated EID covering prefix to the
RLOCs of a configured or registered PeTR. The Map Reply must contain
the Home-IID of the registered PeTR.
4.1.3. LISP Extranet Publish/Subscribe Procedures 4.1.3. LISP Extranet Publish/Subscribe Procedures
When LISP Extranet VPNs are implemented together with LISP Publish/ When LISP Extranet VPNs are implemented together with LISP Publish/
Subscribe functionality [I-D.ietf-lisp-pubsub], the following Subscribe functionality [I-D.ietf-lisp-pubsub], the following
considerations apply. considerations apply.
Subscriptions initiated across VPNs MUST maintain a record of the IID Subscriptions initiated across VPNs MUST maintain a record of the IID
from which the subscription was requested. An ITR that issues a Map- from which the subscription was requested. An ITR that issues a Map-
Request with the N-bit set from an Extranet-Subscriber-VPN will use Request with the N-bit set from an Extranet-Subscriber-VPN will use
the IID of the Extranet-Subscriber-VPN as the IID for the XEID it the IID of the Extranet-Subscriber-VPN as the IID for the XEID it
subscribes to. The Map-Request is routed to the Extranet-Provider- subscribes to. The Map-Request is routed to the Extranet-VPN (Home-
VPN (Home-VPN) where the EID is registered, as defined in VPN) where the EID is registered, as defined in Section 4.1.2. The
Section 4.1.2. The subscription is maintained in the Home-VPN and subscription is maintained in the Home-VPN and will include a record
will include a record of the IID of the Extranet-Subscriber-VPN from of the IID of the Extranet-Subscriber-VPN from which the subscription
which the subscription was initiated. was initiated.
Any changes in the RLOC set for the EID will be published using a Any changes in the RLOC set for the EID will be published using a
Map-Notify message. The Map-Notify message will include the Map-Notify message. The Map-Notify message will include the
Extranet-Subscriber-VPN IID in the XEID and it will also include the Extranet-Subscriber-VPN IID in the XEID and it will also include the
IID of the Home-VPN (Home-IID) encoded as specified in Section 4.1.4. IID of the Home-VPN (Home-IID) encoded as specified in Section 4.1.4.
4.1.4. LISP Extranet VPN Home-IID encoding 4.1.4. LISP Extranet VPN Home-IID encoding
The Home-IID is an attribute of the EID-RLOC mapping. The Home-IID The Home-IID is an attribute of the EID-RLOC mapping. The Home-IID
must be encoded as an additional RLOC within the record carried in must be encoded as an additional RLOC within the record carried in
skipping to change at page 15, line 48 skipping to change at page 16, line 32
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
<https://www.rfc-editor.org/info/rfc4607>. <https://www.rfc-editor.org/info/rfc4607>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-lisp-pubsub] [I-D.ietf-lisp-pubsub]
Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F.,
Cabellos-Aparicio, A., Barkai, S., Farinacci, D., Cabellos-Aparicio, A., Barkai, S., Farinacci, D.,
Boucadair, M., Jacquenet, C., and S. Secci, "Publish/ Boucadair, M., Jacquenet, C., and S. Secci, "Publish/
Subscribe Functionality for LISP", draft-ietf-lisp- Subscribe Functionality for LISP", Work in Progress,
pubsub-02 (work in progress), November 2018. Internet-Draft, draft-ietf-lisp-pubsub-02, 3 November
2018, <http://www.ietf.org/internet-drafts/draft-ietf-
lisp-pubsub-02.txt>.
[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
of Interpretation", RFC 6407, DOI 10.17487/RFC6407, of Interpretation", RFC 6407, DOI 10.17487/RFC6407,
October 2011, <https://www.rfc-editor.org/info/rfc6407>. October 2011, <https://www.rfc-editor.org/info/rfc6407>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013, DOI 10.17487/RFC6830, January 2013,
<https://www.rfc-editor.org/info/rfc6830>. <https://www.rfc-editor.org/info/rfc6830>.
skipping to change at page 17, line 10 skipping to change at page 17, line 41
[RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID
Separation Protocol (LISP) Multicast", RFC 8378, Separation Protocol (LISP) Multicast", RFC 8378,
DOI 10.17487/RFC8378, May 2018, DOI 10.17487/RFC8378, May 2018,
<https://www.rfc-editor.org/info/rfc8378>. <https://www.rfc-editor.org/info/rfc8378>.
Authors' Addresses Authors' Addresses
Victor Moreno Victor Moreno
Cisco Systems Cisco Systems
170 Tasman Drive 170 Tasman Drive
San Jose, California 95134 San Jose, California 95134
USA United States of America
Email: vimoreno@cisco.com Email: vimoreno@cisco.com
Dino Farinacci Dino Farinacci
lispers.net lispers.net
San Jose, CA 95120 San Jose, CA 95120
USA United States of America
Email: farinacci@gmail.com Email: farinacci@gmail.com
 End of changes. 23 change blocks. 
49 lines changed or deleted 67 lines changed or added

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