draft-ietf-lisp-rfc6833bis-05.txt   draft-ietf-lisp-rfc6833bis-06.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: November 10, 2017 A. Cabellos (Ed.) Expires: April 8, 2018 A. Cabellos (Ed.)
UPC/BarcelonaTech UPC/BarcelonaTech
May 9, 2017 October 5, 2017
Locator/ID Separation Protocol (LISP) Control-Plane Locator/ID Separation Protocol (LISP) Control-Plane
draft-ietf-lisp-rfc6833bis-05 draft-ietf-lisp-rfc6833bis-06
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
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 10, 2017. This Internet-Draft will expire on April 8, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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 (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
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . 13
4.4. Map-Reply Message Format . . . . . . . . . . . . . . . . 14 4.4. Map-Reply Message Format . . . . . . . . . . . . . . . . 15
4.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 18 4.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 19
4.6. Map-Register Message Format . . . . . . . . . . . . . . . 21 4.6. Map-Register Message Format . . . . . . . . . . . . . . . 22
4.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 24 4.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 25
4.8. Encapsulated Control Message Format . . . . . . . . . . . 25 4.8. Encapsulated Control Message Format . . . . . . . . . . . 26
5. Interactions with Other LISP Components . . . . . . . . . . . 27 5. Interactions with Other LISP Components . . . . . . . . . . . 28
5.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 27 5.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 28
5.2. EID-Prefix Configuration and ETR Registration . . . . . . 28 5.2. EID-Prefix Configuration and ETR Registration . . . . . . 29
5.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 30 5.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 31
5.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 30 5.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 31
5.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . 31 5.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . 32
6. Security Considerations . . . . . . . . . . . . . . . . . . . 31 6. Security Considerations . . . . . . . . . . . . . . . . . . . 32
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
7.1. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 32 7.1. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 33
7.2. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 32 7.2. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 33
7.3. LISP Address Type Codes . . . . . . . . . . . . . . . . . 33 7.3. LISP Address Type Codes . . . . . . . . . . . . . . . . . 34
7.4. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . . 33 7.4. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . . 34
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
8.1. Normative References . . . . . . . . . . . . . . . . . . 33 8.1. Normative References . . . . . . . . . . . . . . . . . . 34
8.2. Informative References . . . . . . . . . . . . . . . . . 35 8.2. Informative References . . . . . . . . . . . . . . . . . 36
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 37 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 39
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 37 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 39
B.1. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 37 B.1. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 39
B.2. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 37 B.2. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 39
B.3. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 37 B.3. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 39
B.4. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 38 B.4. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 40
B.5. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 38 B.5. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 40
B.6. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 38 B.6. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 40
B.7. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 38 B.7. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 B.8. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
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 replacing the addresses currently used by IP with two separate for replacing the addresses currently used by IP with two separate
name spaces: Endpoint IDs (EIDs), used within sites; and Routing name spaces: Endpoint IDs (EIDs), used within sites; and Routing
Locators (RLOCs), used on the transit networks that make up the Locators (RLOCs), used on the transit networks that make up the
Internet infrastructure. To achieve this separation, LISP defines Internet infrastructure. To achieve this separation, LISP defines
protocol mechanisms for mapping from EIDs to RLOCs. In addition, protocol mechanisms for mapping from EIDs to RLOCs. In addition,
LISP assumes the existence of a database to store and propagate those LISP assumes the existence of a database to store and propagate those
mappings globally. Several such databases have been proposed; among mappings globally. Several such databases have been proposed; among
them are the Content distribution Overlay Network Service for LISP them are the Content distribution Overlay Network Service for LISP
(LISP-CONS) [LISP-CONS], LISP-NERD (a Not-so-novel EID-to-RLOC (LISP-CONS) [LISP-CONS], LISP-NERD (a Not-so-novel EID-to-RLOC
Database) [RFC6837], LISP Alternative Logical Topology (LISP+ALT) Database) [RFC6837], LISP Alternative Logical Topology (LISP+ALT)
[RFC6836], and LISP Delegated Database Tree (LISP-DDT) [RFC6836], and LISP Delegated Database Tree (LISP-DDT) [RFC8111].
[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
skipping to change at page 5, line 29 skipping to change at page 5, line 29
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
when a Map-Server needs to forward a Map-Request to it. when a Map-Server needs to forward a Map-Request to it.
When LISP+ALT is used as the mapping database, a Map-Server connects When LISP+ALT is used as the mapping database, a Map-Server connects
to the ALT network and acts as a "last-hop" ALT-Router. Intermediate to the ALT network and acts as a "last-hop" ALT-Router. Intermediate
ALT-Routers forward Map-Requests to the Map-Server that advertises a ALT-Routers forward Map-Requests to the Map-Server that advertises a
particular EID-Prefix, and the Map-Server forwards them to the owning particular EID-Prefix, and the Map-Server forwards them to the owning
ETR, which responds with Map-Reply messages. ETR, which responds with Map-Reply messages.
When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping database, a When LISP-DDT [RFC8111] is used as the mapping database, a Map-Server
Map-Server sends the final Map-Referral messages from the Delegated sends the final Map-Referral messages from the Delegated Database
Database Tree. Tree.
A Map-Resolver receives Encapsulated Map-Requests from its client A Map-Resolver receives Encapsulated Map-Requests from its client
ITRs and uses a mapping database system to find the appropriate ETR ITRs and uses a mapping database system to find the appropriate ETR
to answer those requests. On a LISP+ALT network, a Map-Resolver acts to answer those requests. On a LISP+ALT network, a Map-Resolver acts
as a "first-hop" ALT-Router. It has Generic Routing Encapsulation as a "first-hop" ALT-Router. It has Generic Routing Encapsulation
(GRE) tunnels configured to other ALT-Routers and uses BGP to learn (GRE) tunnels configured to other ALT-Routers and uses BGP to learn
paths to ETRs for different prefixes in the LISP+ALT database. The paths to ETRs for different prefixes in the LISP+ALT database. The
Map-Resolver uses this path information to forward Map-Requests over Map-Resolver uses this path information to forward Map-Requests over
the ALT to the correct ETRs. On a LISP-DDT network the ALT to the correct ETRs. On a LISP-DDT network [RFC8111], a Map-
[I-D.ietf-lisp-ddt], a Map-Resolver maintains a referral-cache and Resolver maintains a referral-cache and acts as a "first-hop" DDT-
acts as a "first-hop" DDT-node. The Map-Resolver uses the referral node. The Map-Resolver uses the referral information to forward Map-
information to forward Map-Requests. Requests.
Note that while it is conceivable that a non-LISP-DDT Map-Resolver Note that while it is conceivable that a non-LISP-DDT Map-Resolver
could cache responses to improve performance, issues surrounding could cache responses to improve performance, issues surrounding
cache management will need to be resolved so that doing so will be cache management will need to be resolved so that doing so will be
reliable and practical. As initially deployed, Map-Resolvers will reliable and practical. As initially deployed, Map-Resolvers will
operate only in a non-caching mode, decapsulating and forwarding operate only in a non-caching mode, decapsulating and forwarding
Encapsulated Map Requests received from ITRs. Any specification of Encapsulated Map Requests received from ITRs. Any specification of
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-
skipping to change at page 10, line 10 skipping to change at page 10, line 10
data-plane defined in [I-D.ietf-lisp-rfc6830bis]. This control-plane data-plane defined in [I-D.ietf-lisp-rfc6830bis]. This control-plane
specification itself does not offer such functionality and other specification itself does not offer such functionality and other
data-planes can use their own mechanisms that do not rely on the LISP data-planes can use their own mechanisms that do not rely on the LISP
control-plane. control-plane.
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|I| Rsvd |L|D| IRC | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . | | Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce | | . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source-EID-AFI | Source EID Address ... | | Source-EID-AFI | Source EID Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... | | ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
skipping to change at page 11, line 15 skipping to change at page 11, line 15
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.ietf-lisp-mn]. operate as a mobile node as defined in [I-D.ietf-lisp-mn].
Reserved: This field MUST be set to 0 on transmit and MUST be I: This is the xTR-ID bit. When this bit is set, what is appended to
ignored on receipt. the Map-Request is a 128-bit xTR router-ID. See LISP PubSub usage
procedures in [I-D.rodrigueznatal-lisp-pubsub] for details.
Rsvd: This field MUST be set to 0 on transmit and MUST be 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 [I-D.ietf-lisp-rfc6830bis]. When an xTR sends an SMR described in [I-D.ietf-lisp-rfc6830bis]. When an xTR sends an SMR
Map-Request message, it doesn't need a Map-Reply returned. When Map-Request message, it doesn't need a Map-Reply returned. When
this bit is set, the receiver of the Map-Request does not return a this bit is set, the receiver of the Map-Request does not return a
Map-Reply. Map-Reply.
skipping to change at page 22, line 18 skipping to change at page 23, line 18
[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
ignored on receipt. ignored on receipt.
E: This is the Map-Register EID-notify bit. This is used by a First- E: This is the Map-Register EID-notify bit. This is used by a First-
Hop-Router (FHR) which discovers a dynamic-EID. This EID-notify Hop-Router (FHR) which discovers a dynamic-EID. This EID-notify
based Map-Register is sent by the FHR to the same site xTR that based Map-Register is sent by the FHR to the same site xTR that
propogates the Map-Register to the mapping system. The site xTR propogates the Map-Register to the mapping system. The site xTR
keeps state to later Map-Notify the FHR after the EID has moves keeps state to later Map-Notify the FHR after the EID has moves
away. See [I-D.portoles-lisp-eid-mobility] for a detailed use- away. See [I-D.ietf-lisp-eid-mobility] for a detailed use-case.
case.
T: This is the use-TTL for timeout bit. When set to 1, the xTR wants T: This is the use-TTL for timeout bit. When set to 1, the xTR wants
the Map-Server to time out registrations based on the value in the the Map-Server to time out registrations based on the value in the
"Record TTL" field of this message. "Record TTL" field of this message.
a: This is the merge-request bit. When set to 1, the xTR requests to a: This is the merge-request bit. When set to 1, the xTR requests to
merge RLOC-records from different xTRs registering the same EID- merge RLOC-records from different xTRs registering the same EID-
record. See signal-free multicast record. See signal-free multicast
[I-D.ietf-lisp-signal-free-multicast] for one use case example. [I-D.ietf-lisp-signal-free-multicast] for one use case example.
skipping to change at page 26, line 7 skipping to change at page 27, line 7
and what follows is either an IPv4 or IPv6 header as encoded by and what follows is either an IPv4 or IPv6 header as encoded by
the first 4 bits after the 'Reserved' field. the first 4 bits after the 'Reserved' field.
Type: 8 (Encapsulated Control Message (ECM)) Type: 8 (Encapsulated Control Message (ECM))
S: This is the Security bit. When set to 1, the procedures from S: This is the Security bit. When set to 1, the procedures from
[I-D.ietf-lisp-sec] are followed. [I-D.ietf-lisp-sec] are followed.
D: This is the DDT-bit. When set to 1, the sender is requesting a D: This is the DDT-bit. When set to 1, the sender is requesting a
Map-Referral message to be returned. The details of this Map-Referral message to be returned. The details of this
procedure are described in [I-D.ietf-lisp-ddt]. procedure are described in [RFC8111].
E: This is the to-ETR bit. When set to 1, the Map-Server's E: This is the to-ETR bit. When set to 1, the Map-Server's
intention is to forward the ECM to an authoritative ETR. intention is to forward the ECM to an authoritative ETR.
M: This is the to-MS bit. When set to 1, a Map-Request is being M: This is the to-MS bit. When set to 1, a Map-Request is being
sent to a co-located Map-Resolver and Map-Server where the sent to a co-located Map-Resolver and Map-Server where the
message can be processed directly by the Map-Server versus the message can be processed directly by the Map-Server versus the
Map-Resolver using the LISP-DDT procedures in Map-Resolver using the LISP-DDT procedures in [RFC8111].
[I-D.ietf-lisp-ddt].
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 . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IH: The inner IPv4 or IPv6 header, which can use either RLOC or EID IH: The inner IPv4 or IPv6 header, which can use either RLOC or EID
addresses in the header address fields. When a Map-Request is addresses in the header address fields. When a Map-Request is
encapsulated in this packet format, the destination address in encapsulated in this packet format, the destination address in
skipping to change at page 33, line 50 skipping to change at page 34, line 50
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.
8. References 8. References
8.1. Normative References 8.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, <https://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>. <https://www.rfc-editor.org/info/rfc2104>.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November
1998, <http://www.rfc-editor.org/info/rfc2404>. 1998, <https://www.rfc-editor.org/info/rfc2404>.
[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,
<http://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107,
June 2005, <http://www.rfc-editor.org/info/rfc4107>. June 2005, <https://www.rfc-editor.org/info/rfc4107>.
[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>. <https://www.rfc-editor.org/info/rfc4868>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <https://www.rfc-editor.org/info/rfc5226>.
[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>. <https://www.rfc-editor.org/info/rfc6234>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013, DOI 10.17487/RFC6830, January 2013,
<http://www.rfc-editor.org/info/rfc6830>. <https://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, <https://www.rfc-editor.org/info/rfc6831>.
[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, <https://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>. <https://www.rfc-editor.org/info/rfc6837>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
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>. <https://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>. <https://www.rfc-editor.org/info/rfc7835>.
[RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,
February 2017, <http://www.rfc-editor.org/info/rfc8060>. February 2017, <https://www.rfc-editor.org/info/rfc8060>.
[RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.
Smirnov, "Locator/ID Separation Protocol Delegated
Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111,
May 2017, <https://www.rfc-editor.org/info/rfc8111>.
[RFC8113] Boucadair, M. and C. Jacquenet, "Locator/ID Separation [RFC8113] Boucadair, M. and C. Jacquenet, "Locator/ID Separation
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,
<http://www.rfc-editor.org/info/rfc8113>. <https://www.rfc-editor.org/info/rfc8113>.
8.2. Informative References 8.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-12 (work in progress), March 2017. lisp-nat-traversal-13 (work in progress), September 2017.
[I-D.ietf-lisp-ddt] [I-D.ietf-lisp-eid-mobility]
Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino,
Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp- F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
ddt-09 (work in progress), January 2017. Unified Control Plane", draft-ietf-lisp-eid-mobility-00
(work in progress), May 2017.
[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-00 (work in progress), Mobile Node", draft-ietf-lisp-mn-00 (work in progress),
April 2017. April 2017.
[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-03 (work in progress), (LISP)", draft-ietf-lisp-rfc6830bis-05 (work in progress),
May 2017. August 2017.
[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-13
(work in progress), November 2016. (work in progress), September 2017.
[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-04 (work in draft-ietf-lisp-signal-free-multicast-06 (work in
progress), May 2017. progress), August 2017.
[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.portoles-lisp-eid-mobility]
Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino,
F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
Unified Control Plane", draft-portoles-lisp-eid-
mobility-02 (work in progress), April 2017.
[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,
P., and D. Melman, "Generic Protocol Extension for VXLAN", P., and D. Melman, "Generic Protocol Extension for VXLAN",
draft-quinn-vxlan-gpe-04 (work in progress), February draft-quinn-vxlan-gpe-04 (work in progress), February
2015. 2015.
[I-D.rodrigueznatal-lisp-pubsub]
Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F.,
Cabellos-Aparicio, A., Barkai, S., and D. Farinacci,
"Publish-Subscribe mechanism for LISP", draft-
rodrigueznatal-lisp-pubsub-00 (work in progress), August
2017.
[LISP-CONS] [LISP-CONS]
Brim, S., Chiappa, N., Farinacci, D., Fuller, V., Lewis, Brim, S., Chiappa, N., Farinacci, D., Fuller, V., Lewis,
D., and D. Meyer, "LISP-CONS: A Content distribution D., and D. Meyer, "LISP-CONS: A Content distribution
Overlay Network Service for LISP", Work in Progress, April Overlay Network Service for LISP", Work in Progress, April
2008. 2008.
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 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-05 B.1. Changes to draft-ietf-lisp-rfc6833bis-06
o Posted October 2017.
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
introduction of pubsub functionality to allow Map-Requests to
subscribe to RLOC-set changes.
o Updated references for individual submissions that became working
group documents.
o Updated references for working group documents that became RFCs.
B.2. 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.2. Changes to draft-ietf-lisp-rfc6833bis-04 B.3. 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.3. Changes to draft-ietf-lisp-rfc6833bis-03 B.4. 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.4. Changes to draft-ietf-lisp-rfc6833bis-02 B.5. 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.5. Changes to draft-ietf-lisp-rfc6833bis-01 B.6. 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.6. Changes to draft-ietf-lisp-rfc6833bis-00 B.7. 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.7. Changes to draft-farinacci-lisp-rfc6833bis-00 B.8. 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
skipping to change at page 39, line 17 skipping to change at page 41, line 32
but wasn't able to make it into RFC6830 and RFC6833 to make the but wasn't able to make it into RFC6830 and RFC6833 to make the
Experimental RFC deadline. Experimental RFC deadline.
o Indicate there may be nodes in the mapping system that are not MRs o Indicate there may be nodes in the mapping system that are not MRs
or MSs, that is a ALT-node or a DDT-node. or MSs, that is a ALT-node or a DDT-node.
o Include LISP-DDT in Map-Resolver section and explain how they o Include LISP-DDT in Map-Resolver section and explain how they
maintain a referral-cache. maintain a referral-cache.
o Removed open issue about additional state in Map-Servers. With o Removed open issue about additional state in Map-Servers. With
[I-D.ietf-lisp-ddt], Map-Servers have the same registration state [RFC8111], Map-Servers have the same registration state and can
and can give Map-Resolvers complete information in ms-ack Map- give Map-Resolvers complete information in ms-ack Map-Referral
Referral messages. messages.
o Make reference to the LISP Threats Analysis RFC [RFC7835]. o Make reference to the LISP Threats Analysis RFC [RFC7835].
Authors' Addresses Authors' Addresses
Vince Fuller Vince Fuller
Cisco Systems Cisco Systems
EMail: vaf@vaf.net EMail: vaf@vaf.net
 End of changes. 48 change blocks. 
99 lines changed or deleted 122 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/