draft-ietf-lisp-rfc6833bis-00.txt   draft-ietf-lisp-rfc6833bis-01.txt 
Network Working Group V. Fuller Network Working Group V. Fuller
Internet-Draft D. Farinacci Internet-Draft D. Farinacci
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: June 9, 2017 A. Cabellos (Ed.) Expires: September 29, 2017 A. Cabellos (Ed.)
UPC/BarcelonaTech UPC/BarcelonaTech
December 6, 2016 March 28, 2017
Locator/ID Separation Protocol (LISP) Control-Plane Locator/ID Separation Protocol (LISP) Control-Plane
draft-ietf-lisp-rfc6833bis-00 draft-ietf-lisp-rfc6833bis-01
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
to Routing Locator mapping databases. to Routing Locator mapping databases.
By using this control-plane service interface and communicating with By using this control-plane service interface and communicating with
Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and
Egress Tunnel Routers (ETRs) are not dependent on the details of Egress Tunnel Routers (ETRs) are not dependent on the details of
mapping database systems, which facilitates experimentation with mapping database systems, which facilitates modularity with different
different database designs. Since these devices implement the "edge" database designs. Since these devices implement the "edge" of the
of the LISP infrastructure, connect directly to LISP-capable Internet LISP infrastructure, connect directly to LISP-capable Internet end
end sites, and comprise the bulk of LISP-speaking devices, reducing sites, and comprise the bulk of LISP-speaking devices, reducing their
their implementation and operational complexity should also reduce implementation and operational complexity should also reduce the
the overall cost and effort of deploying LISP. overall cost and effort of deploying LISP.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 9, 2017. This Internet-Draft will expire on September 29, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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
skipping to change at page 2, line 31 skipping to change at page 2, line 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
3. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 5 3. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 5
4. LISP IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 7 4. LISP IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 7
4.1. LISP Control Packet Type Allocations . . . . . . . . . . 9 4.1. LISP Control Packet Type Allocations . . . . . . . . . . 9
4.2. Map-Request Message Format . . . . . . . . . . . . . . . 10 4.2. Map-Request Message Format . . . . . . . . . . . . . . . 10
4.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 12 4.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 12
4.4. Map-Reply Message Format . . . . . . . . . . . . . . . . 14 4.4. Map-Reply Message Format . . . . . . . . . . . . . . . . 14
4.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 18 4.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 18
4.6. Map-Register Message Format . . . . . . . . . . . . . . . 20 4.6. Map-Register Message Format . . . . . . . . . . . . . . . 21
4.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 23 4.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 24
4.8. Encapsulated Control Message Format . . . . . . . . . . . 25 4.8. Encapsulated Control Message Format . . . . . . . . . . . 25
5. Interactions with Other LISP Components . . . . . . . . . . . 27 5. Interactions with Other LISP Components . . . . . . . . . . . 27
5.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 27 5.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 27
5.2. EID-Prefix Configuration and ETR Registration . . . . . . 28 5.2. EID-Prefix Configuration and ETR Registration . . . . . . 28
5.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 30 5.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 30
5.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 30 5.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 30
5.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . 31 5.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . 31
6. Open Issues and Considerations . . . . . . . . . . . . . . . 31 6. Security Considerations . . . . . . . . . . . . . . . . . . . 31
7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.1. Normative References . . . . . . . . . . . . . . . . . . 32
8.1. Normative References . . . . . . . . . . . . . . . . . . 33 7.2. Informative References . . . . . . . . . . . . . . . . . 33
8.2. Informative References . . . . . . . . . . . . . . . . . 34
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 36 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 36
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 36 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 36
B.1. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 36 B.1. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 36
B.2. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 36 B.2. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 36
B.3. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
The Locator/ID Separation Protocol [RFC6830] specifies an The Locator/ID Separation Protocol [I-D.ietf-lisp-introduction] and
architecture and mechanism for replacing the addresses currently used [I-D.ietf-lisp-rfc6830bis] specifies an architecture and mechanism
by IP with two separate name spaces: Endpoint IDs (EIDs), used within for replacing the addresses currently used by IP with two separate
sites; and Routing Locators (RLOCs), used on the transit networks name spaces: Endpoint IDs (EIDs), used within sites; and Routing
that make up the Internet infrastructure. To achieve this Locators (RLOCs), used on the transit networks that make up the
separation, LISP defines protocol mechanisms for mapping from EIDs to Internet infrastructure. To achieve this separation, LISP defines
RLOCs. In addition, LISP assumes the existence of a database to protocol mechanisms for mapping from EIDs to RLOCs. In addition,
store and propagate those mappings globally. Several such databases LISP assumes the existence of a database to store and propagate those
have been proposed; among them are the Content distribution Overlay mappings globally. Several such databases have been proposed; among
Network Service for LISP (LISP-CONS) [LISP-CONS], LISP-NERD (a Not- them are the Content distribution Overlay Network Service for LISP
so-novel EID-to-RLOC Database) [RFC6837], LISP Alternative Logical (LISP-CONS) [LISP-CONS], LISP-NERD (a Not-so-novel EID-to-RLOC
Topology (LISP+ALT) [RFC6836], and LISP Delegated Database Tree Database) [RFC6837], LISP Alternative Logical Topology (LISP+ALT)
(LISP-DDT) [I-D.ietf-lisp-ddt]. [RFC6836], and LISP Delegated Database Tree (LISP-DDT)
[I-D.ietf-lisp-ddt].
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
[RFC6830], LISP-GPE [I-D.lewis-lisp-gpe], VXLAN [RFC7348], and VXLAN- [I-D.ietf-lisp-rfc6830bis], LISP-GPE [I-D.lewis-lisp-gpe], VXLAN
GPE [I-D.quinn-vxlan-gpe]. [RFC7348], and VXLAN-GPE [I-D.quinn-vxlan-gpe].
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
infrastructure to illustrate certain aspects of Map-Server and Map- infrastructure to illustrate certain aspects of Map-Server and Map-
Resolver operation, the Mapping Service interface can (and likely Resolver operation, the Mapping Service interface can (and likely
will) be used by ITRs and ETRs to access other mapping database will) be used by ITRs and ETRs to access other mapping database
systems as the LISP infrastructure evolves. systems as the LISP infrastructure evolves.
Section 6 of this document notes a number of issues with the Map-
Server and Map-Resolver design that are not yet completely understood
and are subjects of further experimentation.
The LISP Mapping Service is an important component of the LISP The LISP Mapping Service is an important component of the LISP
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 [RFC6830]. Internet traffic are discussed in [I-D.ietf-lisp-rfc6830bis].
2. Definition of Terms 2. 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-Resolver: A network infrastructure component that accepts LISP Map-Resolver: A network infrastructure component that accepts LISP
Encapsulated Map-Requests, typically from an ITR, and determines Encapsulated Map-Requests, typically from an ITR, and determines
skipping to change at page 5, line 7 skipping to change at page 4, line 50
Map-Notify message: A LISP message sent by a Map-Server to an ETR Map-Notify message: A LISP message sent by a Map-Server to an ETR
to confirm that a Map-Register has been received and processed. to confirm that a Map-Register has been received and processed.
An ETR requests that a Map-Notify be returned by setting the An ETR requests that a Map-Notify be returned by setting the
"want-map-notify" flag (M-bit) in the Map-Register message. "want-map-notify" flag (M-bit) in the Map-Register message.
Unlike a Map-Reply, a Map-Notify uses UDP port 4342 for both Unlike a Map-Reply, a Map-Notify uses UDP port 4342 for both
source and destination. source and destination.
For definitions of other terms -- notably Map-Request, Map-Reply, For definitions of other terms -- notably Map-Request, Map-Reply,
Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR) -- please Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR) -- please
consult the LISP specification [RFC6830]. consult the LISP specification [I-D.ietf-lisp-rfc6830bis].
3. Basic Overview 3. Basic Overview
A Map-Server is a device that publishes EID-Prefixes in a LISP A Map-Server is a device that publishes EID-Prefixes in a LISP
mapping database on behalf of a set of ETRs. When it receives a Map mapping database on behalf of a set of ETRs. When it receives a Map
Request (typically from an ITR), it consults the mapping database to Request (typically from an ITR), it consults the mapping database to
find an ETR that can answer with the set of RLOCs for an EID-Prefix. find an ETR that can answer with the set of RLOCs for an EID-Prefix.
To publish its EID-Prefixes, an ETR periodically sends Map-Register To publish its EID-Prefixes, an ETR periodically sends Map-Register
messages to the Map-Server. A Map-Register message contains a list messages to the Map-Server. A Map-Register message contains a list
of EID-Prefixes plus a set of RLOCs that can be used to reach the ETR of EID-Prefixes plus a set of RLOCs that can be used to reach the ETR
skipping to change at page 6, line 9 skipping to change at page 6, line 6
caching functionality is left for future work. caching functionality is left for future work.
Note that a single device can implement the functions of both a Map- Note that a single device can implement the functions of both a Map-
Server and a Map-Resolver, and in many cases the functions will be Server and a Map-Resolver, and in many cases the functions will be
co-located in that way. Also, there can be ALT-only nodes and DDT- co-located in that way. Also, there can be ALT-only nodes and DDT-
only nodes, when LISP+ALT and LISP-DDT are used, respectively, to only nodes, when LISP+ALT and LISP-DDT are used, respectively, to
connect Map-Resolvers and Map-Servers together to make up the Mapping connect Map-Resolvers and Map-Servers together to make up the Mapping
System. System.
Detailed descriptions of the LISP packet types referenced by this Detailed descriptions of the LISP packet types referenced by this
document may be found in [RFC6830]. document may be found in [I-D.ietf-lisp-rfc6830bis].
4. LISP IPv4 and IPv6 Control-Plane Packet Formats 4. LISP IPv4 and IPv6 Control-Plane Packet Formats
The following UDP packet formats are used by the LISP control plane. The following UDP packet formats are used by the LISP control plane.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length | |Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 22 skipping to change at page 9, line 22
LISP Map-Request: 1 b'0001' LISP Map-Request: 1 b'0001'
LISP Map-Reply: 2 b'0010' LISP Map-Reply: 2 b'0010'
LISP Map-Register: 3 b'0011' LISP Map-Register: 3 b'0011'
LISP Map-Notify: 4 b'0100' LISP Map-Notify: 4 b'0100'
LISP Map-Notify-Ack: 5 b'0101' LISP Map-Notify-Ack: 5 b'0101'
LISP Map-Referral: 6 b'0110' LISP Map-Referral: 6 b'0110'
LISP Info-Request/Reply: 7 b'0111' LISP Info-Request/Reply: 7 b'0111'
LISP Encapsulated Control Message: 8 b'1000' LISP Encapsulated Control Message: 8 b'1000'
All LISP control-plane messages use Address Family Identifiers (AFI) All LISP control-plane messages use Address Family Identifiers (AFI)
[AFI] or LISP Canonical Address Format (LCAF) [I-D.ietf-lisp-lcaf] [AFI] or LISP Canonical Address Format (LCAF) [RFC8060] formats to
formats to encode either fixed or variable length addresses. This encode either fixed or variable length addresses. This includes
includes explicit fields in each control message or part of EID- explicit fields in each control message or part of EID-records or
records or RLOC-records in commonly formatted messages, RLOC-records in commonly formatted messages,
4.2. Map-Request Message Format 4.2. Map-Request Message Format
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=1 |A|M|P|S|p|s|m| Reserved |L|D| IRC | Record Count | |Type=1 |A|M|P|S|p|s|m| Reserved |L|D| IRC | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . | | Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 10, line 47 skipping to change at page 10, line 47
destination site to return the Map-Reply rather than the mapping destination site to return the Map-Reply rather than the mapping
database system. database system.
M: This is the map-data-present bit. When set, it indicates that a M: This is the map-data-present bit. When set, it indicates that a
Map-Reply Record segment is included in the Map-Request. Map-Reply Record segment is included in the Map-Request.
P: This is the probe-bit, which indicates that a Map-Request SHOULD P: This is the probe-bit, which indicates that a Map-Request SHOULD
be treated as a Locator reachability probe. The receiver SHOULD be treated as a Locator reachability probe. The receiver SHOULD
respond with a Map-Reply with the probe-bit set, indicating that respond with a Map-Reply with the probe-bit set, indicating that
the Map-Reply is a Locator reachability probe reply, with the the Map-Reply is a Locator reachability probe reply, with the
nonce copied from the Map-Request. See RLOC-Probing [RFC6830] for nonce copied from the Map-Request. See RLOC-Probing
more details. [I-D.ietf-lisp-rfc6830bis] for more details.
S: This is the Solicit-Map-Request (SMR) bit. See Solicit-Map- S: This is the Solicit-Map-Request (SMR) bit. See Solicit-Map-
Request (SMRs) [RFC6830] for details. Request (SMRs) [I-D.ietf-lisp-rfc6830bis] for details.
p: This is the PITR bit. This bit is set to 1 when a PITR sends a p: This is the PITR bit. This bit is set to 1 when a PITR sends a
Map-Request. Map-Request.
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.meyer-lisp-mn]. operate as a mobile node as defined in [I-D.meyer-lisp-mn].
Reserved: This field MUST be set to 0 on transmit and MUST be Reserved: This field MUST be set to 0 on transmit and MUST be
ignored on receipt. ignored on 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 local to the site. tell other xTRs in the same site that it is local to the site.
That is, that it is part of the RLOC-set for the LISP site. That is, that it is part of the RLOC-set for the LISP site.
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
described in [RFC6830]. When an xTR sends an SMR Map-Request described in [I-D.ietf-lisp-rfc6830bis]. When an xTR sends an SMR
message, it doesn't need a Map-Reply returned. When this bit is Map-Request message, it doesn't need a Map-Reply returned. When
set, the receiver of the Map-Request does not return a Map-Reply. this bit is set, the receiver of the Map-Request does not return a
Map-Reply.
IRC: This 5-bit field is the ITR-RLOC Count, which encodes the IRC: This 5-bit field is the ITR-RLOC Count, which encodes the
additional number of ('ITR-RLOC-AFI', 'ITR-RLOC Address') fields additional number of ('ITR-RLOC-AFI', 'ITR-RLOC Address') fields
present in this message. At least one (ITR-RLOC-AFI, ITR-RLOC- present in this message. At least one (ITR-RLOC-AFI, ITR-RLOC-
Address) pair MUST be encoded. Multiple 'ITR-RLOC Address' fields Address) pair MUST be encoded. Multiple 'ITR-RLOC Address' fields
are used, so a Map-Replier can select which destination address to are used, so a Map-Replier can select which destination address to
use for a Map-Reply. The IRC value ranges from 0 to 31. For a use for a Map-Reply. The IRC value ranges from 0 to 31. For a
value of 0, there is 1 ITR-RLOC address encoded; for a value of 1, value of 0, there is 1 ITR-RLOC address encoded; for a value of 1,
there are 2 ITR-RLOC addresses encoded, and so on up to 31, which there are 2 ITR-RLOC addresses encoded, and so on up to 31, which
encodes a total of 32 ITR-RLOC addresses. encodes a total of 32 ITR-RLOC addresses.
skipping to change at page 12, line 24 skipping to change at page 12, line 26
field that follows this field. field that follows this field.
ITR-RLOC Address: This is used to give the ETR the option of ITR-RLOC Address: This is used to give the ETR the option of
selecting the destination address from any address family for the selecting the destination address from any address family for the
Map-Reply message. This address MUST be a routable RLOC address Map-Reply message. This address MUST be a routable RLOC address
of the sender of the Map-Request message. of the sender of the Map-Request message.
EID mask-len: This is the mask length for the EID-Prefix. EID mask-len: This is the mask length for the EID-Prefix.
EID-Prefix-AFI: This is the address family of the EID-Prefix EID-Prefix-AFI: This is the address family of the EID-Prefix
according to [AFI] and [I-D.ietf-lisp-lcaf]. according to [AFI] and [RFC8060].
EID-Prefix: This prefix is 4 octets for an IPv4 address family and EID-Prefix: This prefix is 4 octets for an IPv4 address family and
16 octets for an IPv6 address family. When a Map-Request is sent 16 octets for an IPv6 address family. When a Map-Request is sent
by an ITR because a data packet is received for a destination by an ITR because a data packet is received for a destination
where there is no mapping entry, the EID-Prefix is set to the where there is no mapping entry, the EID-Prefix is set to the
destination IP address of the data packet, and the 'EID mask-len' destination IP address of the data packet, and the 'EID mask-len'
is set to 32 or 128 for IPv4 or IPv6, respectively. When an xTR is set to 32 or 128 for IPv4 or IPv6, respectively. When an xTR
wants to query a site about the status of a mapping it already has wants to query a site about the status of a mapping it already has
cached, the EID-Prefix used in the Map-Request has the same mask cached, the EID-Prefix used in the Map-Request has the same mask
length as the EID-Prefix returned from the site when it sent a length as the EID-Prefix returned from the site when it sent a
skipping to change at page 13, line 26 skipping to change at page 13, line 29
configured Locators in this list or just provide one locator address configured Locators in this list or just provide one locator address
from each address family it supports. If the ITR erroneously from each address family it supports. If the ITR erroneously
provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map- provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map-
Request. Request.
Map-Requests can also be LISP encapsulated using UDP destination Map-Requests can also be LISP encapsulated using UDP destination
port 4342 with a LISP Type value set to "Encapsulated Control port 4342 with a LISP Type value set to "Encapsulated Control
Message", when sent from an ITR to a Map-Resolver. Likewise, Map- Message", when sent from an ITR to a Map-Resolver. Likewise, Map-
Requests are LISP encapsulated the same way from a Map-Server to an Requests are LISP encapsulated the same way from a Map-Server to an
ETR. Details on Encapsulated Map-Requests and Map-Resolvers can be ETR. Details on Encapsulated Map-Requests and Map-Resolvers can be
found in [RFC6833]. found in Section 4.8.
Map-Requests MUST be rate-limited. It is RECOMMENDED that a Map- Map-Requests MUST be rate-limited. It is RECOMMENDED that a Map-
Request for the same EID-Prefix be sent no more than once per second. Request for the same EID-Prefix be sent no more than once per second.
An ITR that is configured with mapping database information (i.e., it An ITR that is configured with mapping database information (i.e., it
is also an ETR) MAY optionally include those mappings in a Map- is also an ETR) MAY optionally include those mappings in a Map-
Request. When an ETR configured to accept and verify such Request. When an ETR configured to accept and verify such
"piggybacked" mapping data receives such a Map-Request and it does "piggybacked" mapping data receives such a Map-Request and it does
not have this mapping in the map-cache, it MAY originate a "verifying not have this mapping in the map-cache, it MAY originate a "verifying
Map-Request", addressed to the map-requesting ITR and the ETR MAY add Map-Request", addressed to the map-requesting ITR and the ETR MAY add
skipping to change at page 14, line 38 skipping to change at page 14, line 38
| \| Locator | | \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions: Packet field descriptions:
Type: 2 (Map-Reply) Type: 2 (Map-Reply)
P: This is the probe-bit, which indicates that the Map-Reply is in P: This is the probe-bit, which indicates that the Map-Reply is in
response to a Locator reachability probe Map-Request. The 'Nonce' response to a Locator reachability probe Map-Request. The 'Nonce'
field MUST contain a copy of the nonce value from the original field MUST contain a copy of the nonce value from the original
Map-Request. See RLOC-probing [RFC6830] for more details. Map-Request. See RLOC-probing [I-D.ietf-lisp-rfc6830bis] for more
details.
E: This bit indicates that the ETR that sends this Map-Reply message E: This bit indicates that the ETR that sends this Map-Reply message
is advertising that the site is enabled for the Echo-Nonce Locator is advertising that the site is enabled for the Echo-Nonce Locator
reachability algorithm. See Echo-Nonce [RFC6830] for more reachability algorithm. See Echo-Nonce [I-D.ietf-lisp-rfc6830bis]
details. for more details.
S: This is the Security bit. When set to 1, the following S: This is the Security bit. When set to 1, the following
authentication information will be appended to the end of the Map- authentication information will be appended to the end of the Map-
Reply. The details of signing a Map-Reply message can be found in Reply. The details of signing a Map-Reply message can be found in
[I-D.ietf-lisp-sec]. [I-D.ietf-lisp-sec].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AD Type | Authentication Data Content . . . | | AD Type | Authentication Data Content . . . |
skipping to change at page 16, line 7 skipping to change at page 16, line 7
The current assigned values are: The current assigned values are:
(0) No-Action: The map-cache is kept alive, and no packet (0) No-Action: The map-cache is kept alive, and no packet
encapsulation occurs. encapsulation occurs.
(1) Natively-Forward: The packet is not encapsulated or dropped (1) Natively-Forward: The packet is not encapsulated or dropped
but natively forwarded. but natively forwarded.
(2) Send-Map-Request: The packet invokes sending a Map-Request. (2) Send-Map-Request: The packet invokes sending a Map-Request.
(3) Drop: A packet that matches this map-cache entry is dropped. (3) Drop/No-Reason: A packet that matches this map-cache entry is
An ICMP Destination Unreachable message SHOULD be sent. dropped. An ICMP Destination Unreachable message SHOULD be
sent.
(4) Drop/Policy-Denied: A packet that matches this map-cache
entry is dropped. The reason for the Drop action is that a
Map-Request for the target-EID is being policy denied by
either an xTR or the mapping system.
(5) Drop/Authentication-Failure: A packet that matches this map-
cache entry is dropped. The reason for the Drop action is
that a Map-Request for the target-EID fails an authentication
verification-check by either an xTR or the mapping system.
A: The Authoritative bit, when sent, is always set to 1 by an ETR. A: The Authoritative bit, when sent, is always set to 1 by an ETR.
When a Map-Server is proxy Map-Replying [RFC6833] for a LISP site, When a Map-Server is proxy Map-Replying for a LISP site, the
the Authoritative bit is set to 0. This indicates to requesting Authoritative bit is set to 0. This indicates to requesting ITRs
ITRs that the Map-Reply was not originated by a LISP node managed that the Map-Reply was not originated by a LISP node managed at
at the site that owns the EID-Prefix. the site that owns the EID-Prefix.
Map-Version Number: When this 12-bit value is non-zero, the Map- Map-Version Number: When this 12-bit value is non-zero, the Map-
Reply sender is informing the ITR what the version number is for Reply sender is informing the ITR what the version number is for
the EID record contained in the Map-Reply. The ETR can allocate the EID record contained in the Map-Reply. The ETR can allocate
this number internally but MUST coordinate this value with other this number internally but MUST coordinate this value with other
ETRs for the site. When this value is 0, there is no versioning ETRs for the site. When this value is 0, there is no versioning
information conveyed. The Map-Version Number can be included in information conveyed. The Map-Version Number can be included in
Map-Request and Map-Register messages. See Map-Versioning Map-Request and Map-Register messages. See Map-Versioning
[RFC6830] for more details. [I-D.ietf-lisp-rfc6830bis] for more details.
EID-Prefix-AFI: Address family of the EID-Prefix according to [AFI] EID-Prefix-AFI: Address family of the EID-Prefix according to [AFI]
and [I-D.ietf-lisp-lcaf]. and [RFC8060].
EID-Prefix: This prefix is 4 octets for an IPv4 address family and EID-Prefix: This prefix is 4 octets for an IPv4 address family and
16 octets for an IPv6 address family. 16 octets for an IPv6 address family.
Priority: Each RLOC is assigned a unicast Priority. Lower values Priority: Each RLOC is assigned a unicast Priority. Lower values
are more preferable. When multiple RLOCs have the same Priority, are more preferable. When multiple RLOCs have the same Priority,
they MAY be used in a load-split fashion. A value of 255 means they MAY be used in a load-split fashion. A value of 255 means
the RLOC MUST NOT be used for unicast forwarding. the RLOC MUST NOT be used for unicast forwarding.
Weight: When priorities are the same for multiple RLOCs, the Weight Weight: When priorities are the same for multiple RLOCs, the Weight
indicates how to balance unicast traffic between them. Weight is indicates how to balance unicast traffic between them. Weight is
encoded as a relative weight of total unicast packets that match encoded as a relative weight of total unicast packets that match
the mapping entry. For example, if there are 4 Locators in a the mapping entry. For example, if there are 4 Locators in a
Locator-Set, where the Weights assigned are 30, 20, 20, and 10, Locator-Set, where the Weights assigned are 30, 20, 20, and 10,
the first Locator will get 37.5% of the traffic, the 2nd and 3rd the first Locator will get 37.5% of the traffic, the 2nd and 3rd
Locators will get 25% of the traffic, and the 4th Locator will get Locators will get 25% of the traffic, and the 4th Locator will get
12.5% of the traffic. If all Weights for a Locator-Set are equal, 12.5% of the traffic. If all Weights for a Locator-Set are equal,
the receiver of the Map-Reply will decide how to load-split the the receiver of the Map-Reply will decide how to load-split the
traffic. See RLOC-hashing [RFC6830] for a suggested hash traffic. See RLOC-hashing [I-D.ietf-lisp-rfc6830bis] for a
algorithm to distribute the load across Locators with the same suggested hash algorithm to distribute the load across Locators
Priority and equal Weight values. with the same Priority and equal Weight values.
M Priority: Each RLOC is assigned a multicast Priority used by an M Priority: Each RLOC is assigned a multicast Priority used by an
ETR in a receiver multicast site to select an ITR in a source ETR in a receiver multicast site to select an ITR in a source
multicast site for building multicast distribution trees. A value multicast site for building multicast distribution trees. A value
of 255 means the RLOC MUST NOT be used for joining a multicast of 255 means the RLOC MUST NOT be used for joining a multicast
distribution tree. For more details, see [RFC6831]. distribution tree. For more details, see [RFC6831].
M Weight: When priorities are the same for multiple RLOCs, the M Weight: When priorities are the same for multiple RLOCs, the
Weight indicates how to balance building multicast distribution Weight indicates how to balance building multicast distribution
trees across multiple ITRs. The Weight is encoded as a relative trees across multiple ITRs. The Weight is encoded as a relative
skipping to change at page 17, line 21 skipping to change at page 17, line 31
trees built to the source site identified by the EID-Prefix. If trees built to the source site identified by the EID-Prefix. If
all Weights for a Locator-Set are equal, the receiver of the Map- all Weights for a Locator-Set are equal, the receiver of the Map-
Reply will decide how to distribute multicast state across ITRs. Reply will decide how to distribute multicast state across ITRs.
For more details, see [RFC6831]. For more details, see [RFC6831].
Unused Flags: These are set to 0 when sending and ignored on Unused Flags: These are set to 0 when sending and ignored on
receipt. receipt.
L: When this bit is set, the Locator is flagged as a local Locator to L: When this bit is set, the Locator is flagged as a local Locator to
the ETR that is sending the Map-Reply. When a Map-Server is doing the ETR that is sending the Map-Reply. When a Map-Server is doing
proxy Map-Replying [RFC6833] for a LISP site, the L-bit is set to proxy Map-Replying for a LISP site, the L-bit is set to 0 for all
0 for all Locators in this Locator-Set. Locators in this Locator-Set.
p: When this bit is set, an ETR informs the RLOC-Probing ITR that the p: When this bit is set, an ETR informs the RLOC-Probing ITR that the
locator address for which this bit is set is the one being RLOC- locator address for which this bit is set is the one being RLOC-
probed and MAY be different from the source address of the Map- probed and MAY be different from the source address of the Map-
Reply. An ITR that RLOC-probes a particular Locator MUST use this Reply. An ITR that RLOC-probes a particular Locator MUST use this
Locator for retrieving the data structure used to store the fact Locator for retrieving the data structure used to store the fact
that the Locator is reachable. The p-bit is set for a single that the Locator is reachable. The p-bit is set for a single
Locator in the same Locator-Set. If an implementation sets more Locator in the same Locator-Set. If an implementation sets more
than one p-bit erroneously, the receiver of the Map-Reply MUST than one p-bit erroneously, the receiver of the Map-Reply MUST
select the first Locator. The p-bit MUST NOT be set for Locator- select the first Locator. The p-bit MUST NOT be set for Locator-
Set records sent in Map-Request and Map-Register messages. Set records sent in Map-Request and Map-Register messages.
R: This is set when the sender of a Map-Reply has a route to the R: This is set when the sender of a Map-Reply has a route to the
Locator in the Locator data record. This receiver may find this Locator in the Locator data record. This receiver may find this
useful to know if the Locator is up but not necessarily reachable useful to know if the Locator is up but not necessarily reachable
from the receiver's point of view. See also EID-Reachability from the receiver's point of view. See also EID-Reachability
[RFC6830] for another way the R-bit may be used. [I-D.ietf-lisp-rfc6830bis] for another way the R-bit may be used.
Locator: This is an IPv4 or IPv6 address (as encoded by the 'Loc- Locator: This is an IPv4 or IPv6 address (as encoded by the 'Loc-
AFI' field) assigned to an ETR. Note that the destination RLOC AFI' field) assigned to an ETR. Note that the destination RLOC
address MAY be an anycast address. A source RLOC can be an address MAY be an anycast address. A source RLOC can be an
anycast address as well. The source or destination RLOC MUST NOT anycast address as well. The source or destination RLOC MUST NOT
be the broadcast address (255.255.255.255 or any subnet broadcast be the broadcast address (255.255.255.255 or any subnet broadcast
address known to the router) and MUST NOT be a link-local address known to the router) and MUST NOT be a link-local
multicast address. The source RLOC MUST NOT be a multicast multicast address. The source RLOC MUST NOT be a multicast
address. The destination RLOC SHOULD be a multicast address if it address. The destination RLOC SHOULD be a multicast address if it
is being mapped from a multicast destination EID. is being mapped from a multicast destination EID.
4.5. EID-to-RLOC UDP Map-Reply Message 4.5. EID-to-RLOC UDP Map-Reply Message
A Map-Reply returns an EID-Prefix with a prefix length that is less A Map-Reply returns an EID-Prefix with a prefix length that is less
than or equal to the EID being requested. The EID being requested is than or equal to the EID being requested. The EID being requested is
either from the destination field of an IP header of a Data-Probe or either from the destination field of an IP header of a Data-Probe or
the EID record of a Map-Request. The RLOCs in the Map-Reply are the EID record of a Map-Request. The RLOCs in the Map-Reply are
globally routable IP addresses of all ETRs for the LISP site. Each globally routable IP addresses of all ETRs for the LISP site. Each
RLOC conveys status reachability but does not convey path RLOC conveys status reachability but does not convey path
reachability from a requester's perspective. Separate testing of reachability from a requester's perspective. Separate testing of
path reachability is required. See RLOC-reachability [RFC6830] for path reachability is required. See RLOC-reachability
details. [I-D.ietf-lisp-rfc6830bis] for details.
Note that a Map-Reply may contain different EID-Prefix granularity Note that a Map-Reply may contain different EID-Prefix granularity
(prefix + length) than the Map-Request that triggers it. This might (prefix + length) than the Map-Request that triggers it. This might
occur if a Map-Request were for a prefix that had been returned by an occur if a Map-Request were for a prefix that had been returned by an
earlier Map-Reply. In such a case, the requester updates its cache earlier Map-Reply. In such a case, the requester updates its cache
with the new prefix information and granularity. For example, a with the new prefix information and granularity. For example, a
requester with two cached EID-Prefixes that are covered by a Map- requester with two cached EID-Prefixes that are covered by a Map-
Reply containing one less-specific prefix replaces the entry with the Reply containing one less-specific prefix replaces the entry with the
less-specific EID-Prefix. Note that the reverse, replacement of one less-specific EID-Prefix. Note that the reverse, replacement of one
less-specific prefix with multiple more-specific prefixes, can also less-specific prefix with multiple more-specific prefixes, can also
skipping to change at page 19, line 43 skipping to change at page 20, line 4
than' an IPv6 locator address. than' an IPv6 locator address.
When sending a Map-Reply message, the destination address is copied When sending a Map-Reply message, the destination address is copied
from one of the 'ITR-RLOC' fields from the Map-Request. The ETR can from one of the 'ITR-RLOC' fields from the Map-Request. The ETR can
choose a locator address from one of the address families it choose a locator address from one of the address families it
supports. For Data-Probes, the destination address of the Map-Reply supports. For Data-Probes, the destination address of the Map-Reply
is copied from the source address of the Data-Probe message that is is copied from the source address of the Data-Probe message that is
invoking the reply. The source address of the Map-Reply is one of invoking the reply. The source address of the Map-Reply is one of
the local IP addresses chosen to allow Unicast Reverse Path the local IP addresses chosen to allow Unicast Reverse Path
Forwarding (uRPF) checks to succeed in the upstream service provider. Forwarding (uRPF) checks to succeed in the upstream service provider.
The destination port of a Map-Reply message is copied from the source The destination port of a Map-Reply message is copied from the source
port of the Map-Request or Data-Probe, and the source port of the port of the Map-Request or Data-Probe, and the source port of the
Map-Reply message is set to the well-known UDP port 4342. Map-Reply message is set to the well-known UDP port 4342.
4.6. Map-Register Message Format 4.6. Map-Register Message Format
The usage details of the Map-Register message can be found in This section specifies the encoding format for the Map-Register
specification [RFC6833]. This section solely defines the message message. The message is sent in UDP with a destination UDP port of
format. 4342 and a randomly selected UDP source port number.
The message is sent in UDP with a destination UDP port of 4342 and a
randomly selected UDP source port number.
The Map-Register message format is: The Map-Register message format is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=3 |P|S|I| Reserved |E|T|a|m|M| Record Count | |Type=3 |P|S|I| Reserved |E|T|a|m|M| Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . | | Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 20, line 51 skipping to change at page 21, line 48
| \| Locator | | \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions: Packet field descriptions:
Type: 3 (Map-Register) Type: 3 (Map-Register)
P: This is the proxy Map-Reply bit. When set to 1, an ETR sends a P: This is the proxy Map-Reply bit. When set to 1, an ETR sends a
Map-Register message requesting the Map-Server to proxy a Map- Map-Register message requesting the Map-Server to proxy a Map-
Reply. The Map-Server will send non-authoritative Map-Replies on Reply. The Map-Server will send non-authoritative Map-Replies on
behalf of the ETR. Details on this usage can be found in behalf of the ETR.
[RFC6833].
S: This is the security-capable bit. When set, the procedures from S: This is the security-capable bit. When set, the procedures from
[I-D.ietf-lisp-sec] are supported. [I-D.ietf-lisp-sec] are supported.
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-Register is a 128-bit xTR router-ID and then a 64-bit the Map-Register is a 128-bit xTR router-ID and then a 64-bit
site-ID. See LISP NAT-Traversal procedures in site-ID. See LISP NAT-Traversal procedures in
[I-D.ermagan-lisp-nat-traversal] for details. [I-D.ermagan-lisp-nat-traversal] for details.
Reserved: This field MUST be set to 0 on transmit and MUST be Reserved: This field MUST be set to 0 on transmit and MUST be
skipping to change at page 22, line 7 skipping to change at page 22, line 51
labeled 'Record' above and occurs the number of times equal to labeled 'Record' above and occurs the number of times equal to
Record Count. Record Count.
Nonce: This 8-octet 'Nonce' field is set to 0 in Map-Register Nonce: This 8-octet 'Nonce' field is set to 0 in Map-Register
messages. Since the Map-Register message is authenticated, the messages. Since the Map-Register message is authenticated, the
'Nonce' field is not currently used for any security function but 'Nonce' field is not currently used for any security function but
may be in the future as part of an anti-replay solution. may be in the future as part of an anti-replay solution.
Key ID: This is a configured ID to find the configured Message Key ID: This is a configured ID to find the configured Message
Authentication Code (MAC) algorithm and key value used for the Authentication Code (MAC) algorithm and key value used for the
authentication function. See Key ID Numbers in [RFC6830] for authentication function. See Key ID Numbers in
codepoint assignments. [I-D.ietf-lisp-rfc6830bis] for codepoint 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
authenticated with this field preset to 0. After the MAC is authenticated with this field preset to 0. After the MAC is
computed, it is placed in this field. Implementations of this computed, it is placed in this field. Implementations of this
specification MUST include support for HMAC-SHA-1-96 [RFC2404], specification MUST include support for HMAC-SHA-1-96 [RFC2404],
and support for HMAC-SHA-256-128 [RFC4868] is RECOMMENDED. and support for HMAC-SHA-256-128 [RFC4868] is RECOMMENDED.
The definition of the rest of the Map-Register can be found in The definition of the rest of the Map-Register can be found in
Section 4.4. Section 4.4.
4.7. Map-Notify/Map-Notify-Ack Message Format 4.7. Map-Notify/Map-Notify-Ack Message Format
The usage details of the Map-Notify message can be found in This section specifies the encoding format for the Map-Notify and
specification [RFC6833]. This section solely defines the message Map-Notify-Ack messages. The messages are sent inside a UDP packet
format. with source and destination UDP ports equal to 4342.
The message is sent inside a UDP packet with source and destination
UDP ports equal to 4342.
The Map-Notify and Map-Notify-Ack message format is: The Map-Notify and Map-Notify-Ack message formats are:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=4/5| Reserved | Record Count | |Type=4/5| Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . | | Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce | | . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 25, line 8 skipping to change at page 25, line 8
message. See the Map-Register section for field descriptions. message. See the Map-Register section for field descriptions.
The Map-Notify-Ack message has the same contents as a Map-Notify The Map-Notify-Ack message has the same contents as a Map-Notify
message. It is used to acknowledge the receipt of a Map-Notify and message. It is used to acknowledge the receipt of a Map-Notify and
for the sender to stop retransmitting a Map-Notify with the same for the sender to stop retransmitting a Map-Notify with the same
nonce. nonce.
4.8. Encapsulated Control Message Format 4.8. Encapsulated Control Message Format
An Encapsulated Control Message (ECM) is used to encapsulate control An Encapsulated Control Message (ECM) is used to encapsulate control
packets sent between xTRs and the mapping database system described packets sent between xTRs and the mapping database system.
in [RFC6833].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | IPv4 or IPv6 Header | / | IPv4 or IPv6 Header |
OH | (uses RLOC addresses) | OH | (uses RLOC addresses) |
\ | | \ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = 4342 | / | Source Port = xxxx | Dest Port = 4342 |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 29, line 23 skipping to change at page 29, line 23
how quickly and how frequently a mapping database entry can be how quickly and how frequently a mapping database entry can be
updated. This may have implications for what sorts of mobility can updated. This may have implications for what sorts of mobility can
be supported directly by the mapping system; shorter registration be supported directly by the mapping system; shorter registration
intervals or other mechanisms might be needed to support faster intervals or other mechanisms might be needed to support faster
mobility in some cases. For a discussion on one way that faster mobility in some cases. For a discussion on one way that faster
mobility may be implemented for individual devices, please see mobility may be implemented for individual devices, please see
[I-D.meyer-lisp-mn] [I-D.meyer-lisp-mn]
An ETR may also request, by setting the "proxy Map-Reply" flag An ETR may also request, by setting the "proxy Map-Reply" flag
(P-bit) in the Map-Register message, that a Map-Server answer Map- (P-bit) in the Map-Register message, that a Map-Server answer Map-
Requests instead of forwarding them to the ETR. See [RFC6830] for Requests instead of forwarding them to the ETR. See
details on how the Map-Server sets certain flags (such as those [I-D.ietf-lisp-rfc6830bis] for details on how the Map-Server sets
indicating whether the message is authoritative and how returned certain flags (such as those indicating whether the message is
Locators should be treated) when sending a Map-Reply on behalf of an authoritative and how returned Locators should be treated) when
ETR. When an ETR requests proxy reply service, it should include all sending a Map-Reply on behalf of an ETR. When an ETR requests proxy
RLOCs for all ETRs for the EID-Prefix being registered, along with reply service, it should include all RLOCs for all ETRs for the EID-
the routable flag ("R-bit") setting for each RLOC. The Map-Server Prefix being registered, along with the routable flag ("R-bit")
includes all of this information in Map-Reply messages that it sends setting for each RLOC. The Map-Server includes all of this
on behalf of the ETR. This differs from a non-proxy registration, information in Map-Reply messages that it sends on behalf of the ETR.
since the latter need only provide one or more RLOCs for a Map-Server This differs from a non-proxy registration, since the latter need
to use for forwarding Map-Requests; the registration information is only provide one or more RLOCs for a Map-Server to use for forwarding
not used in Map-Replies, so it being incomplete is not incorrect. Map-Requests; the registration information is not used in Map-
Replies, so it being incomplete is not incorrect.
An ETR that uses a Map-Server to publish its EID-to-RLOC mappings An ETR that uses a Map-Server to publish its EID-to-RLOC mappings
does not need to participate further in the mapping database does not need to participate further in the mapping database
protocol(s). When using a LISP+ALT mapping database, for example, protocol(s). When using a LISP+ALT mapping database, for example,
this means that the ETR does not need to implement GRE or BGP, which this means that the ETR does not need to implement GRE or BGP, which
greatly simplifies its configuration and reduces its cost of greatly simplifies its configuration and reduces its cost of
operation. operation.
Note that use of a Map-Server does not preclude an ETR from also Note that use of a Map-Server does not preclude an ETR from also
connecting to the mapping database (i.e., it could also connect to connecting to the mapping database (i.e., it could also connect to
skipping to change at page 31, line 33 skipping to change at page 31, line 33
A Map-Resolver can be set up to use "anycast", where the same address A Map-Resolver can be set up to use "anycast", where the same address
is assigned to multiple Map-Resolvers and is propagated through IGP is assigned to multiple Map-Resolvers and is propagated through IGP
routing, to facilitate the use of a topologically close Map-Resolver routing, to facilitate the use of a topologically close Map-Resolver
by each ITR. by each ITR.
Note that Map-Server associations with ETRs should not use anycast Note that Map-Server associations with ETRs should not use anycast
addresses, as registrations need to be established between an ETR and addresses, as registrations need to be established between an ETR and
a specific set of Map-Servers, each identified by a specific a specific set of Map-Servers, each identified by a specific
registration association. registration association.
6. Open Issues and Considerations 6. Security Considerations
There are a number of issues with the Map-Server and Map-Resolver
design that are not yet completely understood. Among these are:
o Constants, such as those used for Map-Register frequency,
retransmission timeouts, retransmission limits, Negative Map-Reply
TTLs, et al. are subject to further refinement as more experience
with prototype deployment is gained.
o Convergence time when an EID-to-RLOC mapping changes, and
mechanisms for detecting and refreshing or removing stale, cached
information.
o Deployability and complexity tradeoffs of implementing stronger
security measures in both EID-Prefix registration and Map-Request/
Map-Reply processing.
A discussion of other issues surrounding LISP deployment may also be
found in Section 15 of [RFC6830].
The authors expect that experimentation on the LISP pilot network
will help answer open questions surrounding these and other issues.
7. Security Considerations
The 2-way LISP header nonce exchange documented in [RFC6830] can be The 2-way LISP header nonce exchange documented in
used to avoid ITR spoofing attacks. [I-D.ietf-lisp-rfc6830bis] can be used to avoid ITR spoofing attacks.
To publish an authoritative EID-to-RLOC mapping with a Map-Server, an To publish an authoritative EID-to-RLOC mapping with a Map-Server, an
ETR includes authentication data that is a hash of the message using ETR includes authentication data that is a hash of the message using
a pair-wise shared key. An implementation must support use of HMAC- a pair-wise shared key. An implementation must support use of HMAC-
SHA-1-96 [RFC2104] and should support use of HMAC-SHA-256-128 SHA-1-96 [RFC2104] and should support use of HMAC-SHA-256-128
[RFC6234] (SHA-256 truncated to 128 bits). [RFC6234] (SHA-256 truncated to 128 bits).
During experimental and prototype deployment, all authentication key
configuration will be manual. Should LISP and its components be
considered for IETF standardization, further work will be required to
follow the BCP 107 [RFC4107] recommendations on automated key
management.
As noted in Section 5.2, a Map-Server should verify that all EID- As noted in Section 5.2, a Map-Server should verify that all EID-
Prefixes registered by an ETR match the configuration stored on the Prefixes registered by an ETR match the configuration stored on the
Map-Server. Map-Server.
The currently defined authentication mechanism for Map-Register The currently defined authentication mechanism for Map-Register
messages does not provide protection against "replay" attacks by a messages does not provide protection against "replay" attacks by a
"man-in-the-middle". Additional work is needed in this area. "man-in-the-middle". Additional work is needed in this area.
[I-D.ietf-lisp-sec] defines a proposed mechanism for providing origin [I-D.ietf-lisp-sec] defines a proposed mechanism for providing origin
authentication, integrity, anti-replay protection, and prevention of authentication, integrity, anti-replay protection, and prevention of
skipping to change at page 33, line 5 skipping to change at page 32, line 19
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.
8. References 7. References
8.1. Normative References 7.1. Normative References
[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, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[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,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<http://www.rfc-editor.org/info/rfc2104>. <http://www.rfc-editor.org/info/rfc2104>.
skipping to change at page 33, line 41 skipping to change at page 33, line 10
[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,
<http://www.rfc-editor.org/info/rfc4868>. <http://www.rfc-editor.org/info/rfc4868>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, (SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011, DOI 10.17487/RFC6234, May 2011,
<http://www.rfc-editor.org/info/rfc6234>. <http://www.rfc-editor.org/info/rfc6234>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013,
<http://www.rfc-editor.org/info/rfc6830>.
[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
Locator/ID Separation Protocol (LISP) for Multicast Locator/ID Separation Protocol (LISP) for Multicast
Environments", RFC 6831, DOI 10.17487/RFC6831, January Environments", RFC 6831, DOI 10.17487/RFC6831, January
2013, <http://www.rfc-editor.org/info/rfc6831>. 2013, <http://www.rfc-editor.org/info/rfc6831>.
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
Protocol (LISP) Map-Server Interface", RFC 6833,
DOI 10.17487/RFC6833, January 2013,
<http://www.rfc-editor.org/info/rfc6833>.
[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol Alternative Logical "Locator/ID Separation Protocol Alternative Logical
Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836,
January 2013, <http://www.rfc-editor.org/info/rfc6836>. January 2013, <http://www.rfc-editor.org/info/rfc6836>.
[RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to
Routing Locator (RLOC) Database", RFC 6837, Routing Locator (RLOC) Database", RFC 6837,
DOI 10.17487/RFC6837, January 2013, DOI 10.17487/RFC6837, January 2013,
<http://www.rfc-editor.org/info/rfc6837>. <http://www.rfc-editor.org/info/rfc6837>.
skipping to change at page 34, line 32 skipping to change at page 33, line 37
eXtensible Local Area Network (VXLAN): A Framework for eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3 Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<http://www.rfc-editor.org/info/rfc7348>. <http://www.rfc-editor.org/info/rfc7348>.
[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Threat Analysis", RFC 7835, Separation Protocol (LISP) Threat Analysis", RFC 7835,
DOI 10.17487/RFC7835, April 2016, DOI 10.17487/RFC7835, April 2016,
<http://www.rfc-editor.org/info/rfc7835>. <http://www.rfc-editor.org/info/rfc7835>.
8.2. Informative References [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,
February 2017, <http://www.rfc-editor.org/info/rfc8060>.
7.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-11 (work in progress), August 2016. lisp-nat-traversal-12 (work in progress), March 2017.
[I-D.ietf-lisp-ddt] [I-D.ietf-lisp-ddt]
Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.
Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp- Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp-
ddt-08 (work in progress), September 2016. ddt-09 (work in progress), January 2017.
[I-D.ietf-lisp-lcaf] [I-D.ietf-lisp-introduction]
Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Cabellos-Aparicio, A. and D. Saucez, "An Architectural
Address Format (LCAF)", draft-ietf-lisp-lcaf-22 (work in Introduction to the Locator/ID Separation Protocol
progress), November 2016. (LISP)", draft-ietf-lisp-introduction-13 (work in
progress), April 2015.
[I-D.ietf-lisp-rfc6830bis]
Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos-Aparicio, "The Locator/ID Separation Protocol
(LISP)", draft-ietf-lisp-rfc6830bis-00 (work in progress),
December 2016.
[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-12 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-12
(work in progress), November 2016. (work in progress), November 2016.
[I-D.ietf-lisp-signal-free-multicast] [I-D.ietf-lisp-signal-free-multicast]
Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast",
draft-ietf-lisp-signal-free-multicast-02 (work in draft-ietf-lisp-signal-free-multicast-02 (work in
progress), October 2016. progress), October 2016.
[I-D.lewis-lisp-gpe] [I-D.lewis-lisp-gpe]
Lewis, D., Agarwal, P., Kreeger, L., Maino, F., Quinn, P., Lewis, D., Agarwal, P., Kreeger, L., Maino, F., Quinn, P.,
Smith, M., and N. Yadav, "LISP Generic Protocol Smith, M., and N. Yadav, "LISP Generic Protocol
Extension", draft-lewis-lisp-gpe-02 (work in progress), Extension", draft-lewis-lisp-gpe-02 (work in progress),
July 2014. July 2014.
[I-D.meyer-lisp-mn] [I-D.meyer-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-meyer-lisp-mn-15 (work in progress), Mobile Node", draft-meyer-lisp-mn-16 (work in progress),
July 2016. December 2016.
[I-D.portoles-lisp-eid-mobility] [I-D.portoles-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-portoles-lisp-eid- Unified Control Plane", draft-portoles-lisp-eid-
mobility-01 (work in progress), October 2016. mobility-01 (work in progress), October 2016.
[I-D.quinn-vxlan-gpe] [I-D.quinn-vxlan-gpe]
Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F., Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F.,
Smith, M., Agarwal, P., Yong, L., Xu, X., Elzur, U., Garg, Smith, M., Agarwal, P., Yong, L., Xu, X., Elzur, U., Garg,
skipping to change at page 36, line 19 skipping to change at page 36, line 19
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 on Special thanks are due to Noel Chiappa for his extensive work on
caching with LISP-CONS, some of which may be used by Map-Resolvers. caching with LISP-CONS, some of which may be used by 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-00 B.1. Changes to draft-ietf-lisp-rfc6833bis-01
o Posted March 2017.
o Include references to new RFCs published.
o Remove references to self.
o Change references from RFC6830 to RFC6830bis.
o Add two new action/reasons to a Map-Reply has posted to the LISP
WG mailing list.
o In intro section, add refernece to I-D.ietf-lisp-introduction.
o Removed Open Issues section and references to "experimental".
B.2. 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.2. Changes to draft-farinacci-lisp-rfc6833bis-00 B.3. 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. 53 change blocks. 
160 lines changed or deleted 152 lines changed or added

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