draft-ietf-lisp-vpn-02.txt   draft-ietf-lisp-vpn-03.txt 
Network Working Group V. Moreno Network Working Group V. Moreno
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Experimental D. Farinacci Intended status: Experimental D. Farinacci
Expires: November 16, 2018 lispers.net Expires: May 18, 2019 lispers.net
May 15, 2018 November 14, 2018
LISP Virtual Private Networks (VPNs) LISP Virtual Private Networks (VPNs)
draft-ietf-lisp-vpn-02 draft-ietf-lisp-vpn-03
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 November 16, 2018. This Internet-Draft will expire on May 18, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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/license-info) in effect on the date of (https://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 26 skipping to change at page 2, line 26
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are 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 . . . . . . . . . . . . . 6 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 . . . . . . 9
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 VPN Home-IID encoding . . . . . . . . . 10 4.1.3. LISP Extranet Publish/Subscribe Procedures . . . . . 10
4.2. LISP Extranet VPN Data Plane . . . . . . . . . . . . . . 11 4.1.4. LISP Extranet VPN Home-IID encoding . . . . . . . . . 11
4.3. LISP Extranet VPN Multicast Considerations . . . . . . . 11 4.2. LISP Extranet VPN Data Plane . . . . . . . . . . . . . . 12
4.3.1. LISP Extranet VPN Multicast Control Plane . . . . . . 11 4.3. LISP Extranet VPN Multicast Considerations . . . . . . . 12
4.3.2. LISP Extranet VPN Multicast Data Plane . . . . . . . 12 4.3.1. LISP Extranet VPN Multicast Control Plane . . . . . . 12
4.4. LISP Extranet SMR Considerations . . . . . . . . . . . . 12 4.3.2. LISP Extranet VPN Multicast Data Plane . . . . . . . 13
4.5. LISP Extranet RLOC Probing Considerations . . . . . . . . 13 4.4. LISP Extranet SMR Considerations . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4.4.1. Home-IID inclusion in SMR messages . . . . . . . . . 13
5.1. LISP VPNs and LISP Crypto . . . . . . . . . . . . . . . . 13 4.5. LISP Extranet RLOC Probing Considerations . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 5.1. LISP VPNs and LISP Crypto . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 15
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
segmentation is useful in providing fault isolation, enforcing segmentation is useful in providing fault isolation, enforcing
skipping to change at page 4, line 48 skipping to change at page 4, line 48
XTRs. The LISP Instance ID (IID) is used to provide a VPN wide XTRs. The LISP Instance ID (IID) is used to provide a VPN wide
unique identifier that can be used both in the control and data unique identifier that can be used both in the control and data
planes. planes.
The LISP Instance ID is a 32 bit unstructured namespace that The LISP Instance ID is a 32 bit unstructured namespace that
identifies a LISP VPN. The tuple of EID Prefix and IID is referred identifies a LISP VPN. The tuple of EID Prefix and IID is referred
to as an Extended EID (XEID) [RFC8111]. The LISP IID is used in the to as an Extended EID (XEID) [RFC8111]. The LISP IID is used in the
data plane of the LISP header [RFC6830], as well as in the LISP data plane of the LISP header [RFC6830], as well as in the LISP
control plane [RFC8060]. control plane [RFC8060].
An implementation should default to an Instance ID value equal to
zero when LISP VPNs are not in use.
The operation of a LISP VPN is consistent with the operation of LISP The operation of a LISP VPN is consistent with the operation of LISP
in a non-VPN environment as defined in [RFC6830]. The operation of a in a non-VPN environment as defined in [RFC6830]. The operation of a
LISP VPN is here described at a high level in terms of EID LISP VPN is here described at a high level in terms of EID
registrations, EID lookups and traffic forwarding: registrations, EID lookups and traffic forwarding:
EID registration: In a LISP VPN, XTRs that are members of the VPN EID registration: In a LISP VPN, XTRs that are members of the VPN
should be configured with a forwarding context (e.g. VRF) and the should be configured with a forwarding context (e.g. VRF) and the
associated IID for the VPN. Based on this configuration, the ETRs associated IID for the VPN. Based on this configuration, the ETRs
must register the EIDs within the forwarding context as Extended EIDs must register the EIDs within the forwarding context as Extended EIDs
(IID+EID). The LISP mapping system consolidates the registrations (IID+EID). The LISP mapping system consolidates the registrations
skipping to change at page 9, line 44 skipping to change at page 9, line 47
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
connected to the Extranet-VPN may be registered by its ETR in its connected to the Extranet-VPN may be registered by its ETR in its
Home-IID and also in all the IIDs corresponding to the Extranet- Home-IID and also in all the IIDs corresponding to the Extranet-
Subscriber-VPNs defined in the Extranet Policy. When Map-Register Subscriber-VPNs defined in the Extranet Policy. When Map-Register
messages for an EID are issued in IIDs other than the EID's Home-IID, messages for an EID are issued in IIDs other than the EID's Home-IID,
the Home-IID for the EID must be included in the Map-Register. The the Home-IID for the EID must be included in the Map-Register. The
Home-IID must be encoded as described in Section 4.1.3. Home-IID must be encoded as described in Section 4.1.4.
When registering an EID in multiple IIDs, it is advisable to pack the When registering an EID in multiple IIDs, it is advisable to pack the
multiple registrations in a single Map-Register message containing multiple registrations in a single Map-Register message containing
the multiple XEID records. the multiple XEID records.
A Map-Server may be configured with the Extranet Policy. This may A Map-Server may be configured with the Extranet Policy. This may
suffice for the Map-Server to be able to satisfy cross VPN lookups. suffice for the Map-Server to be able to satisfy cross VPN lookups.
In such implementations, ETRs may not be required to register an EID In such implementations, ETRs may not be required to register an EID
across the entire scope of IIDs defined in the Extranet Policy, but across the entire scope of IIDs defined in the Extranet Policy, but
may only require the registration of the EID in its Home-IID. may only require the registration of the EID in its Home-IID.
skipping to change at page 10, line 25 skipping to change at page 10, line 29
source EID. source EID.
When a Map-Request message is forwarded from the Map-Resolver to an When a Map-Request message is forwarded from the Map-Resolver to an
authoritative Map-Server (either directly or by DDT delegation), the authoritative Map-Server (either directly or by DDT delegation), the
IID of the requesting EID must be preserved so that the Map-Reply is IID of the requesting EID must be preserved so that the Map-Reply is
sent in the correct context. sent in the correct context.
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.3. 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.
4.1.3. LISP Extranet VPN Home-IID encoding 4.1.3. LISP Extranet Publish/Subscribe Procedures
When LISP Extranet VPNs are implemented together with LISP Publish/
Subscribe functionality [I-D.ietf-lisp-pubsub], the following
considerations apply.
Subscriptions initiated across VPNs MUST maintain a record of the IID
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
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-
VPN (Home-VPN) where the EID is registered, as defined in
Section 4.1.2. The subscription is maintained in the Home-VPN and
will include a record of the IID of the Extranet-Subscriber-VPN from
which the subscription was initiated.
Any changes in the RLOC set for the EID will be published using a
Map-Notify message. The Map-Notify message will 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.
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
Map-Register, Map-Reply or Map-Notify messages as defined in Map-Reply messages as defined in [RFC6830]. The Home-IID should also
[RFC6830]. be included in Map-Notify messages when LISP Extranet VPNs are
implemented together with LISP Publish/Subscribe functionality
[I-D.ietf-lisp-pubsub].
The additional RLOC containing the Home-IID should use AFI = 16387 The additional RLOC containing the Home-IID should use AFI = 16387
(LCAF) with a List type as described in Section 4.1.3.1. (LCAF) with a List type as described in Section 4.1.4.1.
4.1.3.1. Home-IID encoded in LCAF List type 4.1.4.1. Home-IID encoded in LCAF List type
The Home-IID may be encoded as LCAF AFI of type Instance ID (Type 2). The Home-IID may be encoded as LCAF AFI of type Instance ID (Type 2).
The IID LCAF AFI entry should be nested within a List Type LCAF (Type The IID LCAF AFI entry should be nested within a List Type LCAF (Type
1). The list type is used to include a distinguished name type that 1). The list type is used to include a distinguished name type that
would provide the semantical information that identifies this field would provide the semantical information that identifies this field
as a Home-IID to be used for the purposes of Extranet VPNs. Map- as a Home-IID to be used for the purposes of Extranet VPNs. Map-
Servers and XTRs receiving the encoded messages would leverage the Servers and XTRs receiving the encoded messages would leverage the
semantical information to parse the control plane message properly. semantical information to parse the control plane message properly.
The different LCAF types are documented in [RFC8060]. The logical The different LCAF types are documented in [RFC8060]. The logical
structure of the nested LCAF structure is depicted below: structure of the nested LCAF structure is depicted below:
skipping to change at page 11, line 15 skipping to change at page 11, line 41
AFI = LCAF(16387) AFI = LCAF(16387)
Type = LIST(1) Type = LIST(1)
ITEM1 ITEM1
AFI = Distinguished Name AFI = Distinguished Name
Value = "Home-IID" Value = "Home-IID"
ITEM2 ITEM2
AFI = LCAF(16387) AFI = LCAF(16387)
Type = IID(2) Type = IID(2)
Value = <Home-IID.value> Value = <Home-IID.value>
4.1.3.2. Home-IID encoded in dedicated LCAF Type 4.1.4.2. Home-IID encoded in dedicated LCAF Type
Alternatively, a new dedicated LCAF type could be used in order to Alternatively, a new dedicated LCAF type could be used in order to
include application semantics to the encoding of the IID in a include application semantics to the encoding of the IID in a
purposely structured type. In the future, this document may be purposely structured type. In the future, this document may be
updated to provide details of the definition of structure and updated to provide details of the definition of structure and
semantics for a dedicated LCAF type to be used in this application. semantics for a dedicated LCAF type to be used in this application.
4.2. LISP Extranet VPN Data Plane 4.2. LISP Extranet VPN Data Plane
Traffic will be forwarded according to the procedures outlined in Traffic will be forwarded according to the procedures outlined in
skipping to change at page 12, line 41 skipping to change at page 13, line 22
It is desirable to send a single copy of the Multicast traffic over It is desirable to send a single copy of the Multicast traffic over
the transit network and have the Receiver-ETRs locally replicate the the transit network and have the Receiver-ETRs locally replicate the
traffic to all Receiver-VPNs necessary. This replication is governed traffic to all Receiver-VPNs necessary. This replication is governed
by the Extranet Policy configured at the ETR. Thus, ITRs will by the Extranet Policy configured at the ETR. Thus, ITRs will
encapsulate the traffic with the Instance-ID for the VPN where the encapsulate the traffic with the Instance-ID for the VPN where the
Multicast Source resides. ETRs will receive traffic in the source Multicast Source resides. ETRs will receive traffic in the source
IID and replicate it to the Receiver VPNs per the Extranet Policy. IID and replicate it to the Receiver VPNs per the Extranet Policy.
4.4. LISP Extranet SMR Considerations 4.4. LISP Extranet SMR Considerations
Data driven SMRs need to carry the IID for the VPNs of senders. Data driven SMRs MUST carry the IID for the VPNs of the receivers of
Since the sender's VPN is not known, the ETR must send the SMR to the traffic. Data driven SMRs MAY carry the IID for the VPNs of senders
sending RLOC but replicated to all VPNs defined in the Extranet of traffic if the sender VPN IIDs are known by the ETR generating the
Policy. Multicast optimizations could be used to minimize the amount SMR. If the sender VPN's Instance-ID is not known, the ETR SHOULD
of traffic replicated when sending these SMRs and potentially send the SMR to the RLOC of the sending ITR without the sender VPN's
replicate only at the ITR. An SMR traveling from an Extranet IID.
Subscriber VPN to an Extranet VPN will usually be less susceptible to
being replicated many times than an SMR traveling in the opposite The SMR MUST be replicated to all extranet VPNs that are defined in
direction (provider to subscriber). the Extranet Policy and instantiated at the sending ITR.
When the IID of the sender VPN is known at the ETR, the ETR MAY
include the sender VPN's IID in the SMR and issue a separate SMR for
each sender VPN IID known to the ETR. Multicast optimizations could
be used to minimize the amount of traffic replicated when sending
these SMRs and potentially replicate only at the ITR.
When the IID of the sender VPN is not known at the ETR, the ETR
SHOULD issue a single SMR to each of the sending ITRs. The SMR will
then be replicated at the ITR to all extranet VPNs that are defined
in the Extranet Policy and instantiated at the sending ITR.
4.4.1. Home-IID inclusion in SMR messages
The Instance IDs relevant to the SMR signaling will be encoded in the
SMR Map-request message fields as follows:
Source-EID field: If known by the ETR, this field SHOULD carry the
instance-ID of the traffic source VPN at the ITR with the obsolete
map-cache. This is the IID of the senders of the traffic.
Otherwise, the Instance-ID in this field MUST be the same as the
Instance-ID of the destination VPN at the ETR generating the SMR.
EID-Prefix field: This field carries the Instance-ID of the
destination VPN at the ETR sending the SMR. This is the IID of the
receivers of the traffic. This field must always be set with the IID
of the receivers.
4.5. LISP Extranet RLOC Probing Considerations 4.5. LISP Extranet RLOC Probing Considerations
RLOC Probes must be sent with the IID of the VPN originating the RLOC Probes must be sent with the IID of the VPN originating the
probe. The XTR receiving the probe must identify the VPN for the probe. The XTR receiving the probe must identify the VPN for the
target EID. The XTR receiving the probe should run all verifications target EID. The XTR receiving the probe should run all verifications
as specified in [RFC6830] within the forwarding context corresponding as specified in [RFC6830] within the forwarding context corresponding
to the VPN where the target EID is connected. Once verifications are to the VPN where the target EID is connected. Once verifications are
completed, the reply to the probe should be sent in the IID of the completed, the reply to the probe should be sent in the IID of the
VPN that originated the probe. VPN that originated the probe.
skipping to change at page 14, line 12 skipping to change at page 15, line 14
considerations when implementing this level of key negotiation considerations when implementing this level of key negotiation
granularity. granularity.
6. IANA Considerations 6. IANA Considerations
This document has no IANA implications This document has no IANA implications
7. Acknowledgements 7. Acknowledgements
The authors want to thank Marc Portoles, Vrushali Ashtaputre, Johnson The authors want to thank Marc Portoles, Vrushali Ashtaputre, Johnson
Leong, Jesus Arango, Prakash Jain, Sanjay Hooda, Darrel Lewis and Leong, Jesus Arango, Prakash Jain, Sanjay Hooda, Alberto Rodriguez-
Greg Schudel for their insightful contribution to shaping the ideas Natal, Darrel Lewis and Greg Schudel for their insightful
in this document. contribution to shaping the ideas in this document.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 14, line 42 skipping to change at page 15, line 44
Protocol Specification (Revised)", RFC 4601, Protocol Specification (Revised)", RFC 4601,
DOI 10.17487/RFC4601, August 2006, DOI 10.17487/RFC4601, August 2006,
<https://www.rfc-editor.org/info/rfc4601>. <https://www.rfc-editor.org/info/rfc4601>.
[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.farinacci-lisp-crypto] [I-D.ietf-lisp-pubsub]
Farinacci, D., "LISP Data-Plane Confidentiality", draft- Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F.,
farinacci-lisp-crypto-01 (work in progress), July 2014. Cabellos-Aparicio, A., Barkai, S., Farinacci, D.,
Boucadair, M., Jacquenet, C., and S. Secci, "Publish/
[I-D.farinacci-lisp-mr-signaling] Subscribe Functionality for LISP", draft-ietf-lisp-
Farinacci, D. and M. Napierala, "LISP Control-Plane pubsub-02 (work in progress), November 2018.
Multicast Signaling", draft-farinacci-lisp-mr-signaling-06
(work in progress), February 2015.
[I-D.ietf-lisp-crypto]
Farinacci, D. and B. Weis, "LISP Data-Plane
Confidentiality", draft-ietf-lisp-crypto-10 (work in
progress), October 2016.
[I-D.ietf-lisp-ddt]
Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.
Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp-
ddt-09 (work in progress), January 2017.
[I-D.ietf-lisp-lcaf]
Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", draft-ietf-lisp-lcaf-22 (work in
progress), November 2016.
[I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-15
(work in progress), April 2018.
[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>.
 End of changes. 16 change blocks. 
68 lines changed or deleted 101 lines changed or added

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