< draft-ietf-lisp-rfc6833bis-12.txt   draft-ietf-lisp-rfc6833bis-13.txt >
Network Working Group V. Fuller Network Working Group V. Fuller
Internet-Draft D. Farinacci Internet-Draft D. Farinacci
Obsoletes: 6833 (if approved) Cisco Systems Obsoletes: 6833 (if approved) Cisco Systems
Intended status: Standards Track A. Cabellos (Ed.) Intended status: Standards Track A. Cabellos (Ed.)
Expires: January 27, 2019 UPC/BarcelonaTech Expires: February 21, 2019 UPC/BarcelonaTech
July 26, 2018 August 20, 2018
Locator/ID Separation Protocol (LISP) Control-Plane Locator/ID Separation Protocol (LISP) Control-Plane
draft-ietf-lisp-rfc6833bis-12 draft-ietf-lisp-rfc6833bis-12
Abstract Abstract
This document describes the Control-Plane and Mapping Service for the This document describes the Control-Plane and Mapping Service for the
Locator/ID Separation Protocol (LISP), implemented by two new types Locator/ID Separation Protocol (LISP), implemented by two new types
of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server
-- that provides a simplified "front end" for one or more Endpoint ID -- that provides a simplified "front end" for one or more Endpoint ID
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 January 27, 2019. This Internet-Draft will expire on February 21, 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 25 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 5 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 6
5. LISP IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 7 5. LISP IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 7
5.1. LISP Control Packet Type Allocations . . . . . . . . . . 9 5.1. LISP Control Packet Type Allocations . . . . . . . . . . 9
5.2. Map-Request Message Format . . . . . . . . . . . . . . . 10 5.2. Map-Request Message Format . . . . . . . . . . . . . . . 10
5.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 13 5.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 13
5.4. Map-Reply Message Format . . . . . . . . . . . . . . . . 15 5.4. Map-Reply Message Format . . . . . . . . . . . . . . . . 15
5.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 19 5.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 19
5.6. Map-Register Message Format . . . . . . . . . . . . . . . 22 5.6. Map-Register Message Format . . . . . . . . . . . . . . . 22
5.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 25 5.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 25
5.8. Encapsulated Control Message Format . . . . . . . . . . . 26 5.8. Encapsulated Control Message Format . . . . . . . . . . . 26
6. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 28 6. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 28
6.1. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 28 6.1. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 28
7. Routing Locator Reachability . . . . . . . . . . . . . . . . 29 7. Routing Locator Reachability . . . . . . . . . . . . . . . . 29
7.1. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 31 7.1. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 31
8. Interactions with Other LISP Components . . . . . . . . . . . 32 8. Interactions with Other LISP Components . . . . . . . . . . . 32
8.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 32 8.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 32
8.2. EID-Prefix Configuration and ETR Registration . . . . . . 33 8.2. EID-Prefix Configuration and ETR Registration . . . . . . 33
8.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 35 8.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 35
8.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 36 8.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 36
8.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . 36 8.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . 36
9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 10. Changes since RFC 6833 . . . . . . . . . . . . . . . . . . . 37
10.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 38 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
10.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 38 11.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 38
10.3. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 38 11.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 38
10.4. LISP Address Type Codes . . . . . . . . . . . . . . . . 39 11.3. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 39
10.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 39 11.4. LISP Address Type Codes . . . . . . . . . . . . . . . . 39
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 11.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 40
11.1. Normative References . . . . . . . . . . . . . . . . . . 39
11.2. Informative References . . . . . . . . . . . . . . . . . 40 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 44 12.1. Normative References . . . . . . . . . . . . . . . . . . 40
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 44 12.2. Informative References . . . . . . . . . . . . . . . . . 41
B.1. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . 44 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 45
B.2. Changes to draft-ietf-lisp-rfc6833bis-11 . . . . . . . . 44 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 45
B.3. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . 44 B.1. Changes to draft-ietf-lisp-rfc6833bis-13 . . . . . . . . 45
B.4. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . 44 B.2. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . 45
B.5. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 44 B.3. Changes to draft-ietf-lisp-rfc6833bis-11 . . . . . . . . 45
B.6. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 45 B.4. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . 45
B.7. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 45 B.5. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . 46
B.8. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 46 B.6. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 46
B.9. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 46 B.7. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 46
B.10. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 46 B.8. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 47
B.11. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 46 B.9. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 47
B.12. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 46 B.10. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 47
B.13. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 47 B.11. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 47
B.14. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 47 B.12. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 B.13. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 48
B.14. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 48
B.15. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction 1. Introduction
The Locator/ID Separation Protocol [I-D.ietf-lisp-introduction] and The Locator/ID Separation Protocol [I-D.ietf-lisp-introduction] and
[I-D.ietf-lisp-rfc6830bis] specifies an architecture and mechanism [I-D.ietf-lisp-rfc6830bis] specifies an architecture and mechanism
for dynamic tunnelling by logically separating the addresses for dynamic tunnelling by logically separating the addresses
currently used by IP in two separate name spaces: Endpoint IDs currently used by IP in two separate name spaces: Endpoint IDs
(EIDs), used within sites; and Routing Locators (RLOCs), used on the (EIDs), used within sites; and Routing Locators (RLOCs), used on the
transit networks that make up the Internet infrastructure. To transit networks that make up the Internet infrastructure. To
achieve this separation, LISP defines protocol mechanisms for mapping achieve this separation, LISP defines protocol mechanisms for mapping
skipping to change at page 3, line 51 skipping to change at page 4, line 5
The LISP Mapping Service defines two new types of LISP-speaking The LISP Mapping Service defines two new types of LISP-speaking
devices: the Map-Resolver, which accepts Map-Requests from an Ingress devices: the Map-Resolver, which accepts Map-Requests from an Ingress
Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a
mapping database; and the Map-Server, which learns authoritative EID- mapping database; and the Map-Server, which learns authoritative EID-
to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes
them in a database. them in a database.
This LISP Control-Plane Mapping Service can be used by many different This LISP Control-Plane Mapping Service can be used by many different
encapsulation-based or translation-based Data-Planes which include encapsulation-based or translation-based Data-Planes which include
but are not limited to the ones defined in LISP RFC 6830bis but are not limited to the ones defined in LISP RFC 6830bis
[I-D.ietf-lisp-rfc6830bis], LISP-GPE [I-D.lewis-lisp-gpe], VXLAN [I-D.ietf-lisp-rfc6830bis], LISP-GPE [I-D.ietf-lisp-gpe], VXLAN
[RFC7348], VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe], and ILA
[RFC7348], VXLAN-GPE [I-D.quinn-vxlan-gpe], and ILA
[I-D.herbert-intarea-ila]. [I-D.herbert-intarea-ila].
Conceptually, LISP Map-Servers share some of the same basic Conceptually, LISP Map-Servers share some of the same basic
configuration and maintenance properties as Domain Name System (DNS) configuration and maintenance properties as Domain Name System (DNS)
[RFC1035] servers; likewise, Map-Resolvers are conceptually similar [RFC1035] servers; likewise, Map-Resolvers are conceptually similar
to DNS caching resolvers. With this in mind, this specification to DNS caching resolvers. With this in mind, this specification
borrows familiar terminology (resolver and server) from the DNS borrows familiar terminology (resolver and server) from the DNS
specifications. specifications.
Note that while this document assumes a LISP-ALT database mapping Note that while this document assumes a LISP-ALT database mapping
skipping to change at page 4, line 32 skipping to change at page 4, line 33
toolset. Issues and concerns about the deployment of LISP for toolset. Issues and concerns about the deployment of LISP for
Internet traffic are discussed in [I-D.ietf-lisp-rfc6830bis], Internet traffic are discussed in [I-D.ietf-lisp-rfc6830bis],
[RFC7215], and [I-D.rodrigueznatal-lisp-oam]. [RFC7215], and [I-D.rodrigueznatal-lisp-oam].
This document obsoletes RFC 6833. This document obsoletes RFC 6833.
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119] and
[RFC8174].
3. Definition of Terms 3. Definition of Terms
Map-Server: A network infrastructure component that learns of EID- Map-Server: A network infrastructure component that learns of EID-
Prefix mapping entries from an ETR, via the registration mechanism Prefix mapping entries from an ETR, via the registration mechanism
described below, or some other authoritative source if one exists. described below, or some other authoritative source if one exists.
A Map-Server publishes these EID-Prefixes in a mapping database. A Map-Server publishes these EID-Prefixes in a mapping database.
Map-Request: A LISP Map-Request is a Control-Plane message to query Map-Request: A LISP Map-Request is a Control-Plane message to query
the mapping system to resolve an EID. A LISP Map-Request can also the mapping system to resolve an EID. A LISP Map-Request can also
skipping to change at page 11, line 17 skipping to change at page 11, line 17
s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is
sending a Map-Request in response to a received SMR-based Map- sending a Map-Request in response to a received SMR-based Map-
Request. Request.
m: This is the LISP mobile-node m-bit. This bit is set by xTRs that m: This is the LISP mobile-node m-bit. This bit is set by xTRs that
operate as a mobile node as defined in [I-D.ietf-lisp-mn]. operate as a mobile node as defined in [I-D.ietf-lisp-mn].
I: This is the xTR-ID bit. When this bit is set, what is appended to I: This is the xTR-ID bit. When this bit is set, what is appended to
the Map-Request is a 128-bit xTR router-ID. See LISP PubSub usage the Map-Request is a 128-bit xTR router-ID. See LISP PubSub usage
procedures in [I-D.rodrigueznatal-lisp-pubsub] for details. procedures in [I-D.ietf-lisp-pubsub] for details.
Rsvd: This field MUST be set to 0 on transmit and MUST be ignored on Rsvd: This field MUST be set to 0 on transmit and MUST be ignored on
receipt. receipt.
L: This is the local-xtr bit. It is used by an xTR in a LISP site to L: This is the local-xtr bit. It is used by an xTR in a LISP site to
tell other xTRs in the same site that it is part of the RLOC-set tell other xTRs in the same site that it is part of the RLOC-set
for the LISP site. The L-bit is set to 1 when the RLOC is the for the LISP site. The L-bit is set to 1 when the RLOC is the
sender's IP address. sender's IP address.
D: This is the dont-map-reply bit. It is used in the SMR procedure D: This is the dont-map-reply bit. It is used in the SMR procedure
skipping to change at page 24, line 7 skipping to change at page 24, line 7
is not currently used for any security function but MAY be in the is not currently used for any security function but MAY be in the
future as part of an anti-replay solution. future as part of an anti-replay solution.
Key ID: This is a configured key-id value that corresponds to a Key ID: This is a configured key-id value that corresponds to a
shared-secret password that is used to authenticate the sender. shared-secret password that is used to authenticate the sender.
Multiple shared-secrets can be used to roll over keys in a non- Multiple shared-secrets can be used to roll over keys in a non-
disruptive way. disruptive way.
Algorithm ID: This is the configured Message Authentication Code Algorithm ID: This is the configured Message Authentication Code
(MAC) algorithm value used for the authentication function. See (MAC) algorithm value used for the authentication function. See
Algorithm ID Numbers in the Section 10.5 for codepoint Algorithm ID Numbers in the Section 11.5 for codepoint
assignments. assignments.
Authentication Data Length: This is the length in octets of the Authentication Data Length: This is the length in octets of the
'Authentication Data' field that follows this field. The length 'Authentication Data' field that follows this field. The length
of the 'Authentication Data' field is dependent on the MAC of the 'Authentication Data' field is dependent on the MAC
algorithm used. The length field allows a device that doesn't algorithm used. The length field allows a device that doesn't
know the MAC algorithm to correctly parse the packet. know the MAC algorithm to correctly parse the packet.
Authentication Data: This is the message digest used from the output Authentication Data: This is the message digest used from the output
of the MAC algorithm. The entire Map-Register payload is of the MAC algorithm. The entire Map-Register payload is
skipping to change at page 28, line 16 skipping to change at page 28, line 16
In the LISP architecture ITRs/PITRs use a local Map-Cache to store In the LISP architecture ITRs/PITRs use a local Map-Cache to store
EID-to-RLOC mappings for forwarding. When an ETR updates a mapping a EID-to-RLOC mappings for forwarding. When an ETR updates a mapping a
mechanism is required to inform ITRs/PITRs that are using such mechanism is required to inform ITRs/PITRs that are using such
mappings. mappings.
The LISP Data-Plane defines several mechanism to update mappings The LISP Data-Plane defines several mechanism to update mappings
[I-D.ietf-lisp-rfc6830bis]. This document specifies the Solicit-Map [I-D.ietf-lisp-rfc6830bis]. This document specifies the Solicit-Map
Request (SMR), a Control-Plane push-based mechanism. An additional Request (SMR), a Control-Plane push-based mechanism. An additional
Control-Plane mechanism based on the Publish/subscribe paradigm is Control-Plane mechanism based on the Publish/subscribe paradigm is
specified in [I-D.rodrigueznatal-lisp-pubsub]. specified in [I-D.ietf-lisp-pubsub].
6.1. Solicit-Map-Request (SMR) 6.1. Solicit-Map-Request (SMR)
Soliciting a Map-Request is a selective way for ETRs, at the site Soliciting a Map-Request is a selective way for ETRs, at the site
where mappings change, to control the rate they receive requests for where mappings change, to control the rate they receive requests for
Map-Reply messages. SMRs are also used to tell remote ITRs to update Map-Reply messages. SMRs are also used to tell remote ITRs to update
the mappings they have cached. the mappings they have cached.
Since the ETRs don't keep track of remote ITRs that have cached their Since the ETRs don't keep track of remote ITRs that have cached their
mappings, they do not know which ITRs need to have their mappings mappings, they do not know which ITRs need to have their mappings
skipping to change at page 37, line 33 skipping to change at page 37, line 33
resolving these open security issues. resolving these open security issues.
While beyond the scope of securing an individual Map-Server or Map- While beyond the scope of securing an individual Map-Server or Map-
Resolver, it SHOULD be noted that a BGP-based LISP-ALT network (if Resolver, it SHOULD be noted that a BGP-based LISP-ALT network (if
ALT is used as the mapping database infrastructure) can take ALT is used as the mapping database infrastructure) can take
advantage of standards work on adding security to BGP. advantage of standards work on adding security to BGP.
A complete LISP threat analysis has been published in [RFC7835]. A complete LISP threat analysis has been published in [RFC7835].
Please refer to it for more security related details. Please refer to it for more security related details.
10. IANA Considerations 10. Changes since RFC 6833
For implementation considerations, the following changes have been
made to this document since RFC 6833 was published:
o A Map-Notify-Ack message is added in this docuemnt to provide
reliability for Map-Notify messages. Any receivers of a Map-
Notify message must respond with a Map-Notify-Ack message. Map-
Servers who are senders of Map-Notify messages, must queue the
Map-Notify contents until they receive a Map-Notify-Ack with the
nonce used in the Map-Notify message.
o This document is incorporating the codepoint for the Map-Referral
message from the LISP-DDT specification [RFC8111] to indicate that
a Map-Server must send the final Map-Referral message when it
participates in the LISP-DDT mapping system procedures.
o The "m", "I", "L", and "D" bits are added to the Map-Request
message. See Section 5.3 for details.
o The "S", "I", "E", "T", "a", and "m" bits are added to the Map-
Register message. See Section 5.6 for details.
o The 16-bit Key-ID field of the Map-Register message has been split
into a 8-bit Key-ID field and a 8-bit Algorithm-ID field.
o This document adds two new Action values that are in an EID-record
that appear in Map-Reply, Map-Register, Map-Notify, and Map-
Notify-Ack messages. The Drop/Policy-Denied and Drop/Auth-Failure
are the descriptions for the two new action values. See
Section 5.4 for details.
11. IANA Considerations
This section provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to this Authority (IANA) regarding registration of values related to this
LISP Control-Plane specification, in accordance with BCP 26 LISP Control-Plane specification, in accordance with BCP 26
[RFC8126]. [RFC8126].
There are three namespaces (listed in the sub-sections below) in LISP There are three namespaces (listed in the sub-sections below) in LISP
that have been registered. that have been registered.
o LISP IANA registry allocations SHOULD NOT be made for purposes o LISP IANA registry allocations SHOULD NOT be made for purposes
unrelated to LISP routing or transport protocols. unrelated to LISP routing or transport protocols.
o The following policies are used here with the meanings defined in o The following policies are used here with the meanings defined in
BCP 26: "Specification Required", "IETF Review", "Experimental BCP 26: "Specification Required", "IETF Review", "Experimental
Use", and "First Come First Served". Use", and "First Come First Served".
10.1. LISP UDP Port Numbers 11.1. LISP UDP Port Numbers
The IANA registry has allocated UDP port number 4342 for the LISP The IANA registry has allocated UDP port number 4342 for the LISP
Control-Plane. IANA has updated the description for UDP port 4342 as Control-Plane. IANA has updated the description for UDP port 4342 as
follows: follows:
Keyword Port Transport Layer Description Keyword Port Transport Layer Description
------- ---- --------------- ----------- ------- ---- --------------- -----------
lisp-control 4342 udp LISP Control Packets lisp-control 4342 udp LISP Control Packets
10.2. LISP Packet Type Codes 11.2. LISP Packet Type Codes
It is being requested that the IANA be authoritative for LISP Packet It is being requested that the IANA be authoritative for LISP Packet
Type definitions and that it refers to this document as well as Type definitions and that it refers to this document as well as
[RFC8113] as references. [RFC8113] as references.
Based on deployment experience of [RFC6830], the Map-Notify-Ack Based on deployment experience of [RFC6830], the Map-Notify-Ack
message, message type 5, was added to this document. This document message, message type 5, was added to this document. This document
requests IANA to add it to the LISP Packet Type Registry. requests IANA to add it to the LISP Packet Type Registry.
Name Number Defined in Name Number Defined in
---- ------ ----------- ---- ------ -----------
LISP Map-Notify-Ack 5 RFC6833bis LISP Map-Notify-Ack 5 RFC6833bis
10.3. LISP ACT and Flag Fields 11.3. LISP ACT and Flag Fields
New ACT values can be allocated through IETF review or IESG approval. New ACT values can be allocated through IETF review or IESG approval.
Four values have already been allocated by [RFC6830]. This Four values have already been allocated by [RFC6830]. This
specification changes the name of ACT type 3 value from "Drop" to specification changes the name of ACT type 3 value from "Drop" to
"Drop/No-Reason" as well as adding two new ACT values, the "Drop/ "Drop/No-Reason" as well as adding two new ACT values, the "Drop/
Policy-Denied" (type 4) and "Drop/Authentication-Failure" (type 5). Policy-Denied" (type 4) and "Drop/Authentication-Failure" (type 5).
Value Action Description Reference Value Action Description Reference
----- ------ ----------- --------- ----- ------ ----------- ---------
4 Drop/ A Packet matching this Map-Cache RFC6833bis 4 Drop/ A Packet matching this Map-Cache RFC6833bis
skipping to change at page 39, line 7 skipping to change at page 39, line 35
Auth-Failure entry is dropped because the Auth-Failure entry is dropped because the
Map-Request for target EID fails an Map-Request for target EID fails an
authentication check by the xTR or authentication check by the xTR or
the mapping system. the mapping system.
In addition, LISP has a number of flag fields and reserved fields, In addition, LISP has a number of flag fields and reserved fields,
such as the LISP header flags field [I-D.ietf-lisp-rfc6830bis]. New such as the LISP header flags field [I-D.ietf-lisp-rfc6830bis]. New
bits for flags in these fields can be implemented after IETF review bits for flags in these fields can be implemented after IETF review
or IESG approval, but these need not be managed by IANA. or IESG approval, but these need not be managed by IANA.
10.4. LISP Address Type Codes 11.4. LISP Address Type Codes
LISP Canonical Address Format (LCAF) [RFC8060] is an 8-bit field that LISP Canonical Address Format (LCAF) [RFC8060] is an 8-bit field that
defines LISP-specific encodings for AFI value 16387. LCAF encodings defines LISP-specific encodings for AFI value 16387. LCAF encodings
are used for specific use-cases where different address types for are used for specific use-cases where different address types for
EID-records and RLOC-records are required. EID-records and RLOC-records are required.
The IANA registry "LISP Canonical Address Format (LCAF) Types" is The IANA registry "LISP Canonical Address Format (LCAF) Types" is
used for LCAF types, the registry for LCAF types use the used for LCAF types, the registry for LCAF types use the
Specification Required policy [RFC8126]. Initial values for the Specification Required policy [RFC8126]. Initial values for the
registry as well as further information can be found in [RFC8060]. registry as well as further information can be found in [RFC8060].
Therefore, there is no longer a need for the "LISP Address Type Therefore, there is no longer a need for the "LISP Address Type
Codes" registry requested by [RFC6830]. This document requests to Codes" registry requested by [RFC6830]. This document requests to
remove it. remove it.
10.5. LISP Algorithm ID Numbers 11.5. LISP Algorithm ID Numbers
In [RFC6830], a request for a "LISP Key ID Numbers" registry was In [RFC6830], a request for a "LISP Key ID Numbers" registry was
submitted. This document renames the registry to "LISP Algorithm ID submitted. This document renames the registry to "LISP Algorithm ID
Numbers" and requests the IANA to make the name change. Numbers" and requests the IANA to make the name change.
The following Algorithm ID values are defined by this specification The following Algorithm ID values are defined by this specification
as used in any packet type that references a 'Algorithm ID' field: as used in any packet type that references a 'Algorithm ID' field:
Name Number Defined in Name Number Defined in
----------------------------------------------- -----------------------------------------------
None 0 RFC6833bis None 0 RFC6833bis
HMAC-SHA-1-96 1 [RFC2404] HMAC-SHA-1-96 1 [RFC2404]
HMAC-SHA-256-128 2 [RFC4868] HMAC-SHA-256-128 2 [RFC4868]
Number values are in the range of 0 to 255. The allocation of values Number values are in the range of 0 to 255. The allocation of values
is on a first come first served basis. is on a first come first served basis.
11. References 12. References
11.1. Normative References 12.1. Normative References
[I-D.ietf-lisp-6834bis] [I-D.ietf-lisp-6834bis]
Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Map-Versioning", draft-ietf- Separation Protocol (LISP) Map-Versioning", draft-ietf-
lisp-6834bis-00 (work in progress), July 2018. lisp-6834bis-00 (work in progress), July 2018.
[I-D.ietf-lisp-rfc6830bis] [I-D.ietf-lisp-rfc6830bis]
Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos-Aparicio, "The Locator/ID Separation Protocol Cabellos-Aparicio, "The Locator/ID Separation Protocol
(LISP)", draft-ietf-lisp-rfc6830bis-14 (work in progress), (LISP)", draft-ietf-lisp-rfc6830bis-14 (work in progress),
skipping to change at page 40, line 25 skipping to change at page 41, line 5
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
384, and HMAC-SHA-512 with IPsec", RFC 4868, 384, and HMAC-SHA-512 with IPsec", RFC 4868,
DOI 10.17487/RFC4868, May 2007, DOI 10.17487/RFC4868, May 2007,
<https://www.rfc-editor.org/info/rfc4868>. <https://www.rfc-editor.org/info/rfc4868>.
11.2. Informative References 12.2. Informative References
[AFI] IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY [AFI] IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY
NUMBERS http://www.iana.org/assignments/address-family- NUMBERS http://www.iana.org/assignments/address-family-
numbers/address-family-numbers.xhtml?, Febuary 2007. numbers/address-family-numbers.xhtml?, Febuary 2007.
[I-D.ermagan-lisp-nat-traversal] [I-D.ermagan-lisp-nat-traversal]
Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino,
F., and C. White, "NAT traversal for LISP", draft-ermagan- F., and C. White, "NAT traversal for LISP", draft-ermagan-
lisp-nat-traversal-14 (work in progress), April 2018. lisp-nat-traversal-14 (work in progress), April 2018.
skipping to change at page 40, line 47 skipping to change at page 41, line 27
Herbert, T. and P. Lapukhov, "Identifier-locator Herbert, T. and P. Lapukhov, "Identifier-locator
addressing for IPv6", draft-herbert-intarea-ila-01 (work addressing for IPv6", draft-herbert-intarea-ila-01 (work
in progress), March 2018. in progress), March 2018.
[I-D.ietf-lisp-eid-mobility] [I-D.ietf-lisp-eid-mobility]
Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino,
F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
Unified Control Plane", draft-ietf-lisp-eid-mobility-02 Unified Control Plane", draft-ietf-lisp-eid-mobility-02
(work in progress), May 2018. (work in progress), May 2018.
[I-D.ietf-lisp-gpe]
Maino, F., Lemon, J., Agarwal, P., Lewis, D., and M.
Smith, "LISP Generic Protocol Extension", draft-ietf-lisp-
gpe-05 (work in progress), August 2018.
[I-D.ietf-lisp-introduction] [I-D.ietf-lisp-introduction]
Cabellos-Aparicio, A. and D. Saucez, "An Architectural Cabellos-Aparicio, A. and D. Saucez, "An Architectural
Introduction to the Locator/ID Separation Protocol Introduction to the Locator/ID Separation Protocol
(LISP)", draft-ietf-lisp-introduction-13 (work in (LISP)", draft-ietf-lisp-introduction-13 (work in
progress), April 2015. progress), April 2015.
[I-D.ietf-lisp-mn] [I-D.ietf-lisp-mn]
Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP
Mobile Node", draft-ietf-lisp-mn-02 (work in progress), Mobile Node", draft-ietf-lisp-mn-02 (work in progress),
April 2018. April 2018.
[I-D.ietf-lisp-pubsub]
Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F.,
Cabellos-Aparicio, A., Barkai, S., Farinacci, D.,
Boucadair, M., Jacquenet, C., and S. Secci, "Publish/
Subscribe Functionality for LISP", draft-ietf-lisp-
pubsub-00 (work in progress), April 2018.
[I-D.ietf-lisp-sec] [I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-15 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-15
(work in progress), April 2018. (work in progress), April 2018.
[I-D.ietf-nvo3-vxlan-gpe]
Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work
in progress), April 2018.
[I-D.ietf-opsec-icmp-filtering] [I-D.ietf-opsec-icmp-filtering]
Gont, F., Gont, G., and C. Pignataro, "Recommendations for Gont, F., Gont, G., and C. Pignataro, "Recommendations for
filtering ICMP messages", draft-ietf-opsec-icmp- filtering ICMP messages", draft-ietf-opsec-icmp-
filtering-04 (work in progress), July 2013. filtering-04 (work in progress), July 2013.
[I-D.lewis-lisp-gpe]
Lewis, D., Lemon, J., Agarwal, P., Kreeger, L., Quinn, P.,
Smith, M., Yadav, N., and F. Maino, "LISP Generic Protocol
Extension", draft-lewis-lisp-gpe-04 (work in progress),
December 2017.
[I-D.meyer-loc-id-implications] [I-D.meyer-loc-id-implications]
Meyer, D. and D. Lewis, "Architectural Implications of Meyer, D. and D. Lewis, "Architectural Implications of
Locator/ID Separation", draft-meyer-loc-id-implications-01 Locator/ID Separation", draft-meyer-loc-id-implications-01
(work in progress), January 2009. (work in progress), January 2009.
[I-D.quinn-vxlan-gpe]
Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F.,
Smith, M., Agarwal, P., Yong, L., Xu, X., Elzur, U., Garg,
P., and D. Melman, "Generic Protocol Extension for VXLAN",
draft-quinn-vxlan-gpe-04 (work in progress), February
2015.
[I-D.rodrigueznatal-lisp-oam] [I-D.rodrigueznatal-lisp-oam]
Rodriguez-Natal, A., Cabellos-Aparicio, A., Portoles- Rodriguez-Natal, A., Cabellos-Aparicio, A., Portoles-
Comeras, M., Kowal, M., Lewis, D., and F. Maino, "LISP-OAM Comeras, M., Kowal, M., Lewis, D., and F. Maino, "LISP-OAM
(Operations, Administration and Management): Use cases and (Operations, Administration and Management): Use cases and
requirements", draft-rodrigueznatal-lisp-oam-08 (work in requirements", draft-rodrigueznatal-lisp-oam-08 (work in
progress), June 2018. progress), June 2018.
[I-D.rodrigueznatal-lisp-pubsub]
Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F.,
Cabellos-Aparicio, A., Barkai, S., Farinacci, D.,
Boucadair, M., Jacquenet, C., and S. Secci, "Publish/
Subscribe Functionality for LISP", draft-rodrigueznatal-
lisp-pubsub-02 (work in progress), March 2018.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the [RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the
Internet checksum", RFC 1071, DOI 10.17487/RFC1071, Internet checksum", RFC 1071, DOI 10.17487/RFC1071,
September 1988, <https://www.rfc-editor.org/info/rfc1071>. September 1988, <https://www.rfc-editor.org/info/rfc1071>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
skipping to change at page 43, line 43 skipping to change at page 44, line 25
Protocol (LISP): Shared Extension Message & IANA Registry Protocol (LISP): Shared Extension Message & IANA Registry
for Packet Type Allocations", RFC 8113, for Packet Type Allocations", RFC 8113,
DOI 10.17487/RFC8113, March 2017, DOI 10.17487/RFC8113, March 2017,
<https://www.rfc-editor.org/info/rfc8113>. <https://www.rfc-editor.org/info/rfc8113>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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>.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The authors would like to thank Greg Schudel, Darrel Lewis, John The authors would like to thank Greg Schudel, Darrel Lewis, John
Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver, Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver,
Fabio Maino, and members of the lisp@ietf.org mailing list for their Fabio Maino, and members of the lisp@ietf.org mailing list for their
feedback and helpful suggestions. feedback and helpful suggestions.
Special thanks are due to Noel Chiappa for his extensive work and Special thanks are due to Noel Chiappa for his extensive work and
thought about caching in Map-Resolvers. thought about caching in Map-Resolvers.
Appendix B. Document Change Log Appendix B. Document Change Log
[RFC Editor: Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on publication as RFC.]
B.1. Changes to draft-ietf-lisp-rfc6833bis-12 B.1. Changes to draft-ietf-lisp-rfc6833bis-13
o Posted August 2018.
o Final editorial changes before RFC submission for Proposed
Standard.
o Added section "Changes since RFC 6833" so implementators are
informed of any changes since the last RFC publication.
B.2. Changes to draft-ietf-lisp-rfc6833bis-12
o Posted late July 2018. o Posted late July 2018.
o Moved RFC6830bis and RFC6834bis to Normative References. o Moved RFC6830bis and RFC6834bis to Normative References.
B.2. Changes to draft-ietf-lisp-rfc6833bis-11 B.3. Changes to draft-ietf-lisp-rfc6833bis-11
o Posted July 2018. o Posted July 2018.
o Fixed Luigi editorial comments to ready draft for RFC status and o Fixed Luigi editorial comments to ready draft for RFC status and
ran through IDNITs again. ran through IDNITs again.
B.3. Changes to draft-ietf-lisp-rfc6833bis-10 B.4. Changes to draft-ietf-lisp-rfc6833bis-10
o Posted after LISP WG at IETF week March. o Posted after LISP WG at IETF week March.
o Move AD field encoding after S-bit in the ECM packet format o Move AD field encoding after S-bit in the ECM packet format
description section. description section.
o Say more about when the new Drop actions should be sent. o Say more about when the new Drop actions should be sent.
B.4. Changes to draft-ietf-lisp-rfc6833bis-09 B.5. Changes to draft-ietf-lisp-rfc6833bis-09
o Posted March IETF week 2018. o Posted March IETF week 2018.
o Fixed editorial comments submitted by document shepherd Luigi o Fixed editorial comments submitted by document shepherd Luigi
Iannone. Iannone.
B.5. Changes to draft-ietf-lisp-rfc6833bis-08 B.6. Changes to draft-ietf-lisp-rfc6833bis-08
o Posted March 2018. o Posted March 2018.
o Added RLOC-probing algorithm. o Added RLOC-probing algorithm.
o Added Solicit-Map Request algorithm. o Added Solicit-Map Request algorithm.
o Added several mechanisms (from 6830bis) regarding Routing Locator o Added several mechanisms (from 6830bis) regarding Routing Locator
Reachability. Reachability.
o Added port 4342 to IANA Considerations section. o Added port 4342 to IANA Considerations section.
B.6. Changes to draft-ietf-lisp-rfc6833bis-07 B.7. Changes to draft-ietf-lisp-rfc6833bis-07
o Posted December 2017. o Posted December 2017.
o Make it more clear in a couple of places that RLOCs are used to o Make it more clear in a couple of places that RLOCs are used to
locate ETRs more so than for Map-Server Map-Request forwarding. locate ETRs more so than for Map-Server Map-Request forwarding.
o Make it clear that "encapsualted" for a control message is an ECM o Make it clear that "encapsualted" for a control message is an ECM
based message. based message.
o Make it more clear what messages use source-port 4342 and which o Make it more clear what messages use source-port 4342 and which
skipping to change at page 45, line 39 skipping to change at page 47, line 5
Can use othe AFIs then IPv4 and IPv6. Can use othe AFIs then IPv4 and IPv6.
o Many editorial changes to clarify text. o Many editorial changes to clarify text.
o Changed some "must", "should", and "may" to capitalized. o Changed some "must", "should", and "may" to capitalized.
o Added definitions for Map-Request and Map-Reply messages. o Added definitions for Map-Request and Map-Reply messages.
o Ran document through IDNITs. o Ran document through IDNITs.
B.7. Changes to draft-ietf-lisp-rfc6833bis-06 B.8. Changes to draft-ietf-lisp-rfc6833bis-06
o Posted October 2017. o Posted October 2017.
o Spec the I-bit to include the xTR-ID in a Map-Request message to o Spec the I-bit to include the xTR-ID in a Map-Request message to
be consistent with the Map-Register message and to anticipate the be consistent with the Map-Register message and to anticipate the
introduction of pubsub functionality to allow Map-Requests to introduction of pubsub functionality to allow Map-Requests to
subscribe to RLOC-set changes. subscribe to RLOC-set changes.
o Updated references for individual submissions that became working o Updated references for individual submissions that became working
group documents. group documents.
o Updated references for working group documents that became RFCs. o Updated references for working group documents that became RFCs.
B.8. Changes to draft-ietf-lisp-rfc6833bis-05 B.9. Changes to draft-ietf-lisp-rfc6833bis-05
o Posted May 2017. o Posted May 2017.
o Update IANA Considerations section based on new requests from this o Update IANA Considerations section based on new requests from this
document and changes from what was requested in [RFC6830]. document and changes from what was requested in [RFC6830].
B.9. Changes to draft-ietf-lisp-rfc6833bis-04 B.10. Changes to draft-ietf-lisp-rfc6833bis-04
o Posted May 2017. o Posted May 2017.
o Clarify how the Key-ID field is used in Map-Register and Map- o Clarify how the Key-ID field is used in Map-Register and Map-
Notify messages. Break the 16-bit field into a 8-bit Key-ID field Notify messages. Break the 16-bit field into a 8-bit Key-ID field
and a 8-bit Algorithm-ID field. and a 8-bit Algorithm-ID field.
o Move the Control-Plane codepoints from the IANA Considerations o Move the Control-Plane codepoints from the IANA Considerations
section of RFC6830bis to the IANA Considerations section of this section of RFC6830bis to the IANA Considerations section of this
document. document.
o In the "LISP Control Packet Type Allocations" section, indicate o In the "LISP Control Packet Type Allocations" section, indicate
how message Types are IANA allocated and how experimental RFC8113 how message Types are IANA allocated and how experimental RFC8113
sub-types should be requested. sub-types should be requested.
B.10. Changes to draft-ietf-lisp-rfc6833bis-03 B.11. Changes to draft-ietf-lisp-rfc6833bis-03
o Posted April 2017. o Posted April 2017.
o Add types 9-14 and specify they are not assigned. o Add types 9-14 and specify they are not assigned.
o Add the "LISP Shared Extension Message" type and point to RFC8113. o Add the "LISP Shared Extension Message" type and point to RFC8113.
B.11. Changes to draft-ietf-lisp-rfc6833bis-02 B.12. Changes to draft-ietf-lisp-rfc6833bis-02
o Posted April 2017. o Posted April 2017.
o Clarify that the LISP Control-Plane document defines how the LISP o Clarify that the LISP Control-Plane document defines how the LISP
Data-Plane uses Map-Requests with either the SMR-bit set or the Data-Plane uses Map-Requests with either the SMR-bit set or the
P-bit set supporting mapping updates and RLOC-probing. Indicating P-bit set supporting mapping updates and RLOC-probing. Indicating
that other Data-Planes can use the same mechanisms or their own that other Data-Planes can use the same mechanisms or their own
defined mechanisms to achieve the same functionality. defined mechanisms to achieve the same functionality.
B.12. Changes to draft-ietf-lisp-rfc6833bis-01 B.13. Changes to draft-ietf-lisp-rfc6833bis-01
o Posted March 2017. o Posted March 2017.
o Include references to new RFCs published. o Include references to new RFCs published.
o Remove references to self. o Remove references to self.
o Change references from RFC6830 to RFC6830bis. o Change references from RFC6830 to RFC6830bis.
o Add two new action/reasons to a Map-Reply has posted to the LISP o Add two new action/reasons to a Map-Reply has posted to the LISP
WG mailing list. WG mailing list.
o In intro section, add refernece to I-D.ietf-lisp-introduction. o In intro section, add refernece to I-D.ietf-lisp-introduction.
o Removed Open Issues section and references to "experimental". o Removed Open Issues section and references to "experimental".
B.13. Changes to draft-ietf-lisp-rfc6833bis-00 B.14. Changes to draft-ietf-lisp-rfc6833bis-00
o Posted December 2016. o Posted December 2016.
o Created working group document from draft-farinacci-lisp o Created working group document from draft-farinacci-lisp
-rfc6833-00 individual submission. No other changes made. -rfc6833-00 individual submission. No other changes made.
B.14. Changes to draft-farinacci-lisp-rfc6833bis-00 B.15. Changes to draft-farinacci-lisp-rfc6833bis-00
o Posted November 2016. o Posted November 2016.
o This is the initial draft to turn RFC 6833 into RFC 6833bis. o This is the initial draft to turn RFC 6833 into RFC 6833bis.
o The document name has changed from the "Locator/ID Separation o The document name has changed from the "Locator/ID Separation
Protocol (LISP) Map-Server Interface" to the "Locator/ID Protocol (LISP) Map-Server Interface" to the "Locator/ID
Separation Protocol (LISP) Control-Plane". Separation Protocol (LISP) Control-Plane".
o The fundamental change was to move the Control-Plane messages from o The fundamental change was to move the Control-Plane messages from
 End of changes. 39 change blocks. 
80 lines changed or deleted 126 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/