draft-ietf-lisp-rfc6833bis-07.txt   draft-ietf-lisp-rfc6833bis-08.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 18, 2018 A. Cabellos (Ed.) Expires: September 5, 2018 A. Cabellos (Ed.)
UPC/BarcelonaTech UPC/BarcelonaTech
December 15, 2017 March 4, 2018
Locator/ID Separation Protocol (LISP) Control-Plane Locator/ID Separation Protocol (LISP) Control-Plane
draft-ietf-lisp-rfc6833bis-07 draft-ietf-lisp-rfc6833bis-08
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 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 18, 2018. This Internet-Draft will expire on September 5, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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 35 skipping to change at page 2, line 35
4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 5 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 5
5. LISP IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 7 5. LISP IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 7
5.1. LISP Control Packet Type Allocations . . . . . . . . . . 9 5.1. LISP Control Packet Type Allocations . . . . . . . . . . 9
5.2. Map-Request Message Format . . . . . . . . . . . . . . . 10 5.2. Map-Request Message Format . . . . . . . . . . . . . . . 10
5.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 13 5.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 13
5.4. Map-Reply Message Format . . . . . . . . . . . . . . . . 15 5.4. Map-Reply Message Format . . . . . . . . . . . . . . . . 15
5.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 19 5.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 19
5.6. Map-Register Message Format . . . . . . . . . . . . . . . 22 5.6. Map-Register Message Format . . . . . . . . . . . . . . . 22
5.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 25 5.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 25
5.8. Encapsulated Control Message Format . . . . . . . . . . . 26 5.8. Encapsulated Control Message Format . . . . . . . . . . . 26
6. Interactions with Other LISP Components . . . . . . . . . . . 28 6. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 28
6.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 28 6.1. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 28
6.2. EID-Prefix Configuration and ETR Registration . . . . . . 29 7. Routing Locator Reachability . . . . . . . . . . . . . . . . 29
6.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 31 7.1. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 31
6.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 31 8. Interactions with Other LISP Components . . . . . . . . . . . 32
6.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . 32 8.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 32
7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 8.2. EID-Prefix Configuration and ETR Registration . . . . . . 33
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 8.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 35
8.1. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 33 8.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 35
8.2. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 33 8.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . 36
8.3. LISP Address Type Codes . . . . . . . . . . . . . . . . . 34 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36
8.4. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . . 34 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 10.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 37
9.1. Normative References . . . . . . . . . . . . . . . . . . 34 10.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 37
9.2. Informative References . . . . . . . . . . . . . . . . . 36 10.3. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 38
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 39 10.4. LISP Address Type Codes . . . . . . . . . . . . . . . . 38
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 39 10.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 38
B.1. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 39 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
B.2. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 39 11.1. Normative References . . . . . . . . . . . . . . . . . . 39
B.3. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 40 11.2. Informative References . . . . . . . . . . . . . . . . . 40
B.4. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 40 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 43
B.5. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 40 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 43
B.6. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 40 B.1. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 43
B.7. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 41 B.2. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 43
B.8. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 41 B.3. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 44
B.9. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 41 B.4. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 B.5. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 44
B.6. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 44
B.7. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 45
B.8. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 45
B.9. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 45
B.10. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
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,
skipping to change at page 9, line 25 skipping to change at page 9, line 25
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 Encapsulated Control Message: 8 b'1000' LISP Encapsulated Control Message: 8 b'1000'
Not Assigned 9-14 b'1001'- b'1110' Not Assigned 9-14 b'1001'- b'1110'
LISP Shared Extension Message: 15 b'1111' [RFC8113] LISP Shared Extension Message: 15 b'1111' [RFC8113]
Values in the "Not Assigned" range can be assigned according to Values in the "Not Assigned" range can be assigned according to
procedures in [RFC8126]. Documents that request for a new LISP procedures in [RFC8126]. Documents that request for a new LISP
packet type MAY indicate a preferred value in Section 8.3. packet type MAY indicate a preferred value in Section 10.4.
Protocol designers experimenting with new message formats SHOULD use Protocol designers experimenting with new message formats SHOULD use
the LISP Shared Extension Message Type and request a [RFC8113] sub- the LISP Shared Extension Message Type and request a [RFC8113] sub-
type assignment. type assignment.
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) [RFC8060] formats to [AFI] or LISP Canonical Address Format (LCAF) [RFC8060] formats to
encode either fixed or variable length addresses. This includes encode either fixed or variable length addresses. This includes
explicit fields in each control message or part of EID-records or explicit fields in each control message or part of EID-records or
RLOC-records in commonly formatted messages. RLOC-records in commonly formatted messages.
skipping to change at page 24, line 7 skipping to change at page 24, line 7
is not currently used for any security function but MAY be in the is not currently used for any security function but MAY be in the
future as part of an anti-replay solution. future as part of an anti-replay solution.
Key ID: This is a configured key-id value that corresponds to a Key ID: This is a configured key-id value that corresponds to a
shared-secret password that is used to authenticate the sender. shared-secret password that is used to authenticate the sender.
Multiple shared-secrets can be used to roll over keys in a non- Multiple shared-secrets can be used to roll over keys in a non-
disruptive way. disruptive way.
Algorithm ID: This is the configured Message Authentication Code Algorithm ID: This is the configured Message Authentication Code
(MAC) algorithm value used for the authentication function. See (MAC) algorithm value used for the authentication function. See
Algorithm ID Numbers in the Section 8.3 for codepoint assignments. Algorithm ID Numbers in the Section 10.4 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
skipping to change at page 28, line 5 skipping to change at page 28, line 5
LCM: The format is one of the control message formats described in LCM: The format is one of the control message formats described in
this section. At this time, only Map-Request messages are this section. At this time, only Map-Request messages are
allowed to be control-plane (ECM) encapsulated. In the future, allowed to be control-plane (ECM) encapsulated. In the future,
PIM Join/Prune messages [RFC6831] might be allowed. PIM Join/Prune messages [RFC6831] might be allowed.
Encapsulating other types of LISP control messages is for Encapsulating other types of LISP control messages is for
further study. When Map-Requests are sent for RLOC-Probing further study. When Map-Requests are sent for RLOC-Probing
purposes (i.e., the probe-bit is set), they MUST NOT be sent purposes (i.e., the probe-bit is set), they MUST NOT be sent
inside Encapsulated Control Messages. inside Encapsulated Control Messages.
6. Interactions with Other LISP Components 6. Changing the Contents of EID-to-RLOC Mappings
6.1. ITR EID-to-RLOC Mapping Resolution In the LISP architecture ITRs/PITRs use a local map-cache to store
EID-to-RLOC mappings for forwarding. When an ETR updates a mapping a
mechanism is required to inform ITRs/PITRs that are using such
mappings.
The LISP data-plane defines several mechanism to update mappings
[I-D.ietf-lisp-rfc6830bis]. This document specifies the Solicit-Map
Request (SMR), a control-plane push-based mechanism. An additional
control-plane mechanism based on the Publish/subscribe paradigm is
specified in [I-D.rodrigueznatal-lisp-pubsub].
6.1. Solicit-Map-Request (SMR)
Soliciting a Map-Request is a selective way for ETRs, at the site
where mappings change, to control the rate they receive requests for
Map-Reply messages. SMRs are also used to tell remote ITRs to update
the mappings they have cached.
Since the ETRs don't keep track of remote ITRs that have cached their
mappings, they do not know which ITRs need to have their mappings
updated. As a result, an ETR will solicit Map-Requests (called an
SMR message) from those sites to which it has been sending
encapsulated data for the last minute. In particular, an ETR will
send an SMR to an ITR to which it has recently sent encapsulated
data. This can only occur when both ITR and ETR functionality reside
in the same router.
An SMR message is simply a bit set in a Map-Request message. An ITR
or PITR will send a Map-Request when they receive an SMR message.
Both the SMR sender and the Map-Request responder MUST rate-limit
these messages. Rate-limiting can be implemented as a global rate-
limiter or one rate-limiter per SMR destination.
The following procedure shows how an SMR exchange occurs when a site
is doing Locator-Set compaction for an EID-to-RLOC mapping:
1. When the database mappings in an ETR change, the ETRs at the site
begin to send Map-Requests with the SMR bit set for each Locator
in each Map-Cache entry the ETR caches.
2. A remote ITR that receives the SMR message will schedule sending
a Map-Request message to the source locator address of the SMR
message or to the mapping database system. A newly allocated
random nonce is selected, and the EID-Prefix used is the one
copied from the SMR message. If the source Locator is the only
Locator in the cached Locator-Set, the remote ITR SHOULD send a
Map-Request to the database mapping system just in case the
single Locator has changed and may no longer be reachable to
accept the Map-Request.
3. The remote ITR MUST rate-limit the Map-Request until it gets a
Map-Reply while continuing to use the cached mapping. When
Map-Versioning as described in [I-D.ietf-lisp-rfc6830bis] is
used, an SMR sender can detect if an ITR is using the most up-to-
date database mapping.
4. The ETRs at the site with the changed mapping will reply to the
Map-Request with a Map-Reply message that has a nonce from the
SMR-invoked Map-Request. The Map-Reply messages SHOULD be rate-
limited. This is important to avoid Map-Reply implosion.
5. The ETRs at the site with the changed mapping record the fact
that the site that sent the Map-Request has received the new
mapping data in the Map-Cache entry for the remote site so the
Locator-Status-Bits are reflective of the new mapping for packets
going to the remote site. The ETR then stops sending SMR
messages.
For security reasons, an ITR MUST NOT process unsolicited Map-
Replies. To avoid Map-Cache entry corruption by a third party, a
sender of an SMR-based Map-Request MUST be verified. If an ITR
receives an SMR-based Map-Request and the source is not in the
Locator-Set for the stored Map-Cache entry, then the responding Map-
Request MUST be sent with an EID destination to the mapping database
system. Since the mapping database system is a more secure way to
reach an authoritative ETR, it will deliver the Map-Request to the
authoritative source of the mapping data.
When an ITR receives an SMR-based Map-Request for which it does not
have a cached mapping for the EID in the SMR message, it may not send
an SMR-invoked Map-Request. This scenario can occur when an ETR
sends SMR messages to all Locators in the Locator-Set it has stored
in its map-cache but the remote ITRs that receive the SMR may not be
sending packets to the site. There is no point in updating the ITRs
until they need to send, in which case they will send Map-Requests to
obtain a Map-Cache entry.
7. Routing Locator Reachability
This document defines several control-plane mechanisms for
determining RLOC reachability. Please note that additional data-
plane reachability mechanisms are defined in
[I-D.ietf-lisp-rfc6830bis].
1. An ITR MAY receive an ICMP Network Unreachable or Host
Unreachable message for an RLOC it is using. This indicates that
the RLOC is likely down. Note that trusting ICMP messages may
not be desirable, but neither is ignoring them completely.
Implementations are encouraged to follow current best practices
in treating these conditions [I-D.ietf-opsec-icmp-filtering].
2. When an ITR participates in the routing protocol that operates in
the underlay routing system, it can determine that an RLOC is
down when no Routing Information Base (RIB) entry exists that
matches the RLOC IP address.
3. An ITR MAY receive an ICMP Port Unreachable message from a
destination host. This occurs if an ITR attempts to use
interworking [RFC6832] and LISP-encapsulated data is sent to a
non-LISP-capable site.
4. An ITR MAY receive a Map-Reply from an ETR in response to a
previously sent Map-Request. The RLOC source of the Map-Reply is
likely up, since the ETR was able to send the Map-Reply to the
ITR.
5. An ITR/ETR pair can use the 'RLOC-Probing' mechanism described
below.
When ITRs receive ICMP Network Unreachable or Host Unreachable
messages as a method to determine unreachability, they will refrain
from using Locators that are described in Locator lists of Map-
Replies. However, using this approach is unreliable because many
network operators turn off generation of ICMP Destination Unreachable
messages.
If an ITR does receive an ICMP Network Unreachable or Host
Unreachable message, it MAY originate its own ICMP Destination
Unreachable message destined for the host that originated the data
packet the ITR encapsulated.
Also, BGP-enabled ITRs can unilaterally examine the RIB to see if a
locator address from a Locator-Set in a mapping entry matches a
prefix. If it does not find one and BGP is running in the Default-
Free Zone (DFZ), it can decide to not use the Locator even though the
Locator-Status-Bits indicate that the Locator is up. In this case,
the path from the ITR to the ETR that is assigned the Locator is not
available. More details are in [I-D.meyer-loc-id-implications].
Optionally, an ITR can send a Map-Request to a Locator, and if a Map-
Reply is returned, reachability of the Locator has been determined.
Obviously, sending such probes increases the number of control
messages originated by Tunnel Routers for active flows, so Locators
are assumed to be reachable when they are advertised.
This assumption does create a dependency: Locator unreachability is
detected by the receipt of ICMP Host Unreachable messages. When a
Locator has been determined to be unreachable, it is not used for
active traffic; this is the same as if it were listed in a Map-Reply
with Priority 255.
The ITR can test the reachability of the unreachable Locator by
sending periodic Requests. Both Requests and Replies MUST be rate-
limited. Locator reachability testing is never done with data
packets, since that increases the risk of packet loss for end-to-end
sessions.
7.1. RLOC-Probing Algorithm
RLOC-Probing is a method that an ITR or PITR can use to determine the
reachability status of one or more Locators that it has cached in a
Map-Cache entry. The probe-bit of the Map-Request and Map-Reply
messages is used for RLOC-Probing.
RLOC-Probing is done in the control plane on a timer basis, where an
ITR or PITR will originate a Map-Request destined to a locator
address from one of its own locator addresses. A Map-Request used as
an RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or to
the mapping database system as one would when soliciting mapping
data. The EID record encoded in the Map-Request is the EID-Prefix of
the Map-Cache entry cached by the ITR or PITR. The ITR MAY include a
mapping data record for its own database mapping information that
contains the local EID-Prefixes and RLOCs for its site. RLOC-probes
are sent periodically using a jittered timer interval.
When an ETR receives a Map-Request message with the probe-bit set, it
returns a Map-Reply with the probe-bit set. The source address of
the Map-Reply is set according to the procedure described in
[I-D.ietf-lisp-rfc6830bis]. The Map-Reply SHOULD contain mapping
data for the EID-Prefix contained in the Map-Request. This provides
the opportunity for the ITR or PITR that sent the RLOC-probe to get
mapping updates if there were changes to the ETR's database mapping
entries.
There are advantages and disadvantages of RLOC-Probing. The greatest
benefit of RLOC-Probing is that it can handle many failure scenarios
allowing the ITR to determine when the path to a specific Locator is
reachable or has become unreachable, thus providing a robust
mechanism for switching to using another Locator from the cached
Locator. RLOC-Probing can also provide rough Round-Trip Time (RTT)
estimates between a pair of Locators, which can be useful for network
management purposes as well as for selecting low delay paths. The
major disadvantage of RLOC-Probing is in the number of control
messages required and the amount of bandwidth used to obtain those
benefits, especially if the requirement for failure detection times
is very small.
8. Interactions with Other LISP Components
8.1. ITR EID-to-RLOC Mapping Resolution
An ITR is configured with one or more Map-Resolver addresses. These An ITR is configured with one or more Map-Resolver addresses. These
addresses are "Locators" (or RLOCs) and MUST be routable on the addresses are "Locators" (or RLOCs) and MUST be routable on the
underlying core network; they MUST NOT need to be resolved through underlying core network; they MUST NOT need to be resolved through
LISP EID-to-RLOC mapping, as that would introduce a circular LISP EID-to-RLOC mapping, as that would introduce a circular
dependency. When using a Map-Resolver, an ITR does not need to dependency. When using a Map-Resolver, an ITR does not need to
connect to any other database mapping system. In particular, the ITR connect to any other database mapping system. In particular, the ITR
need not connect to the LISP+ALT infrastructure or implement the BGP need not connect to the LISP+ALT infrastructure or implement the BGP
and GRE protocols that it uses. and GRE protocols that it uses.
skipping to change at page 28, line 44 skipping to change at page 32, line 50
o A Negative Map-Reply, with action code of "Natively-Forward", from o A Negative Map-Reply, with action code of "Natively-Forward", from
a Map-Server that is authoritative for an EID-Prefix that matches a Map-Server that is authoritative for an EID-Prefix that matches
the requested EID but that does not have an actively registered, the requested EID but that does not have an actively registered,
more-specific ID-prefix. In this case, the requested EID is said more-specific ID-prefix. In this case, the requested EID is said
to match a "hole" in the authoritative EID-Prefix. If the to match a "hole" in the authoritative EID-Prefix. If the
requested EID matches a more-specific EID-Prefix that has been requested EID matches a more-specific EID-Prefix that has been
delegated by the Map-Server but for which no ETRs are currently delegated by the Map-Server but for which no ETRs are currently
registered, a 1-minute TTL is returned. If the requested EID registered, a 1-minute TTL is returned. If the requested EID
matches a non-delegated part of the authoritative EID-Prefix, then matches a non-delegated part of the authoritative EID-Prefix, then
it is not a LISP EID and a 15-minute TTL is returned. See it is not a LISP EID and a 15-minute TTL is returned. See
Section 6.2 for discussion of aggregate EID-Prefixes and details Section 8.2 for discussion of aggregate EID-Prefixes and details
of Map-Server EID-Prefix matching. of Map-Server EID-Prefix matching.
o A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or o A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or
possibly from a Map-Server answering on behalf of the ETR. See possibly from a Map-Server answering on behalf of the ETR. See
Section 6.4 for more details on Map-Resolver message processing. Section 8.4 for more details on Map-Resolver message processing.
Note that an ITR MAY be configured to both use a Map-Resolver and to Note that an ITR MAY be configured to both use a Map-Resolver and to
participate in a LISP+ALT logical network. In such a situation, the participate in a LISP+ALT logical network. In such a situation, the
ITR SHOULD send Map-Requests through the ALT network for any EID- ITR SHOULD send Map-Requests through the ALT network for any EID-
Prefix learned via ALT BGP. Such a configuration is expected to be Prefix learned via ALT BGP. Such a configuration is expected to be
very rare, since there is little benefit to using a Map-Resolver if very rare, since there is little benefit to using a Map-Resolver if
an ITR is already using LISP+ALT. There would be, for example, no an ITR is already using LISP+ALT. There would be, for example, no
need for such an ITR to send a Map-Request to a possibly non-existent need for such an ITR to send a Map-Request to a possibly non-existent
EID (and rely on Negative Map-Replies) if it can consult the ALT EID (and rely on Negative Map-Replies) if it can consult the ALT
database to verify that an EID-Prefix is present before sending that database to verify that an EID-Prefix is present before sending that
Map-Request. Map-Request.
6.2. EID-Prefix Configuration and ETR Registration 8.2. EID-Prefix Configuration and ETR Registration
An ETR publishes its EID-Prefixes on a Map-Server by sending LISP An ETR publishes its EID-Prefixes on a Map-Server by sending LISP
Map-Register messages. A Map-Register message includes Map-Register messages. A Map-Register message includes
authentication data, so prior to sending a Map-Register message, the authentication data, so prior to sending a Map-Register message, the
ETR and Map-Server SHOULD be configured with a shared secret or other ETR and Map-Server SHOULD be configured with a shared secret or other
relevant authentication information. A Map-Server's configuration relevant authentication information. A Map-Server's configuration
SHOULD also include a list of the EID-Prefixes for which each ETR is SHOULD also include a list of the EID-Prefixes for which each ETR is
authoritative. Upon receipt of a Map-Register from an ETR, a Map- authoritative. Upon receipt of a Map-Register from an ETR, a Map-
Server accepts only EID-Prefixes that are configured for that ETR. Server accepts only EID-Prefixes that are configured for that ETR.
Failure to implement such a check would leave the mapping system Failure to implement such a check would leave the mapping system
skipping to change at page 29, line 35 skipping to change at page 33, line 42
and operators gain experience with the mapping system, additional, and operators gain experience with the mapping system, additional,
stronger security measures MAY be added to the registration process. stronger security measures MAY be added to the registration process.
In addition to the set of EID-Prefixes defined for each ETR that MAY In addition to the set of EID-Prefixes defined for each ETR that MAY
register, a Map-Server is typically also configured with one or more register, a Map-Server is typically also configured with one or more
aggregate prefixes that define the part of the EID numbering space aggregate prefixes that define the part of the EID numbering space
assigned to it. When LISP+ALT is the database in use, aggregate EID- assigned to it. When LISP+ALT is the database in use, aggregate EID-
Prefixes are implemented as discard routes and advertised into ALT Prefixes are implemented as discard routes and advertised into ALT
BGP. The existence of aggregate EID-Prefixes in a Map-Server's BGP. The existence of aggregate EID-Prefixes in a Map-Server's
database means that it MAY receive Map Requests for EID-Prefixes that database means that it MAY receive Map Requests for EID-Prefixes that
match an aggregate but do not match a registered prefix; Section 6.3 match an aggregate but do not match a registered prefix; Section 8.3
describes how this is handled. describes how this is handled.
Map-Register messages are sent periodically from an ETR to a Map- Map-Register messages are sent periodically from an ETR to a Map-
Server with a suggested interval between messages of one minute. A Server with a suggested interval between messages of one minute. A
Map-Server SHOULD time out and remove an ETR's registration if it has Map-Server SHOULD time out and remove an ETR's registration if it has
not received a valid Map-Register message within the past not received a valid Map-Register message within the past
three minutes. When first contacting a Map-Server after restart or three minutes. When first contacting a Map-Server after restart or
changes to its EID-to-RLOC database mappings, an ETR MAY initially changes to its EID-to-RLOC database mappings, an ETR MAY initially
send Map-Register messages at an increased frequency, up to one every send Map-Register messages at an increased frequency, up to one every
20 seconds. This "quick registration" period is limited to 20 seconds. This "quick registration" period is limited to
skipping to change at page 31, line 5 skipping to change at page 35, line 11
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
the LISP+ALT network), but doing so doesn't seem particularly useful, the LISP+ALT network), but doing so doesn't seem particularly useful,
as the whole purpose of using a Map-Server is to avoid the complexity as the whole purpose of using a Map-Server is to avoid the complexity
of the mapping database protocols. of the mapping database protocols.
6.3. Map-Server Processing 8.3. Map-Server Processing
Once a Map-Server has EID-Prefixes registered by its client ETRs, it Once a Map-Server has EID-Prefixes registered by its client ETRs, it
can accept and process Map-Requests for them. can accept and process Map-Requests for them.
In response to a Map-Request (received over the ALT if LISP+ALT is in In response to a Map-Request (received over the ALT if LISP+ALT is in
use), the Map-Server first checks to see if the destination EID use), the Map-Server first checks to see if the destination EID
matches a configured EID-Prefix. If there is no match, the Map- matches a configured EID-Prefix. If there is no match, the Map-
Server returns a Negative Map-Reply with action code "Natively- Server returns a Negative Map-Reply with action code "Natively-
Forward" and a 15-minute TTL. This MAY occur if a Map Request is Forward" and a 15-minute TTL. This MAY occur if a Map Request is
received for a configured aggregate EID-Prefix for which no more- received for a configured aggregate EID-Prefix for which no more-
skipping to change at page 31, line 39 skipping to change at page 35, line 45
If none of the ETRs have requested proxy reply service, then the Map- If none of the ETRs have requested proxy reply service, then the Map-
Server re-encapsulates and forwards the resulting Encapsulated Map- Server re-encapsulates and forwards the resulting Encapsulated Map-
Request to one of the registered ETRs. It does not otherwise alter Request to one of the registered ETRs. It does not otherwise alter
the Map-Request, so any Map-Reply sent by the ETR is returned to the the Map-Request, so any Map-Reply sent by the ETR is returned to the
RLOC in the Map-Request, not to the Map-Server. Unless also acting RLOC in the Map-Request, not to the Map-Server. Unless also acting
as a Map-Resolver, a Map-Server SHOULD never receive Map-Replies; any as a Map-Resolver, a Map-Server SHOULD never receive Map-Replies; any
such messages SHOULD be discarded without response, perhaps such messages SHOULD be discarded without response, perhaps
accompanied by the logging of a diagnostic message if the rate of accompanied by the logging of a diagnostic message if the rate of
Map-Replies is suggestive of malicious traffic. Map-Replies is suggestive of malicious traffic.
6.4. Map-Resolver Processing 8.4. Map-Resolver Processing
Upon receipt of an Encapsulated Map-Request, a Map-Resolver Upon receipt of an Encapsulated Map-Request, a Map-Resolver
decapsulates the enclosed message and then searches for the requested decapsulates the enclosed message and then searches for the requested
EID in its local database of mapping entries (statically configured EID in its local database of mapping entries (statically configured
or learned from associated ETRs if the Map-Resolver is also a Map- or learned from associated ETRs if the Map-Resolver is also a Map-
Server offering proxy reply service). If it finds a matching entry, Server offering proxy reply service). If it finds a matching entry,
it returns a LISP Map-Reply with the known mapping. it returns a LISP Map-Reply with the known mapping.
If the Map-Resolver does not have the mapping entry and if it can If the Map-Resolver does not have the mapping entry and if it can
determine that the EID is not in the mapping database (for example, determine that the EID is not in the mapping database (for example,
skipping to change at page 32, line 21 skipping to change at page 36, line 27
another device that has more information about the EID being another device that has more information about the EID being
requested. To do this, it forwards the unencapsulated Map-Request, requested. To do this, it forwards the unencapsulated Map-Request,
with the original ITR RLOC as the source, to the mapping database with the original ITR RLOC as the source, to the mapping database
system. Using LISP+ALT, the Map-Resolver is connected to the ALT system. Using LISP+ALT, the Map-Resolver is connected to the ALT
network and sends the Map-Request to the next ALT hop learned from network and sends the Map-Request to the next ALT hop learned from
its ALT BGP neighbors. The Map-Resolver does not send any response its ALT BGP neighbors. The Map-Resolver does not send any response
to the ITR; since the source RLOC is that of the ITR, the ETR or Map- to the ITR; since the source RLOC is that of the ITR, the ETR or Map-
Server that receives the Map-Request over the ALT and responds will Server that receives the Map-Request over the ALT and responds will
do so directly to the ITR. do so directly to the ITR.
6.4.1. Anycast Map-Resolver Operation 8.4.1. Anycast Map-Resolver Operation
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.
7. Security Considerations 9. Security Considerations
The 2-way LISP header nonce exchange documented in The 2-way LISP header nonce exchange documented in
[I-D.ietf-lisp-rfc6830bis] can be 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).
As noted in Section 6.2, a Map-Server SHOULD verify that all EID- As noted in Section 8.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
man-in-the-middle and "overclaiming" attacks on the Map-Request/Map- man-in-the-middle and "overclaiming" attacks on the Map-Request/Map-
skipping to change at page 33, line 19 skipping to change at page 37, line 23
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. IANA Considerations 10. IANA Considerations
This section provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to this Authority (IANA) regarding registration of values related to this
LISP control-plane specification, in accordance with BCP 26 LISP control-plane specification, in accordance with BCP 26
[RFC8126]. [RFC8126].
There are three namespaces (listed in the sub-sections below) in LISP There are three namespaces (listed in the sub-sections below) in LISP
that have been registered. that have been registered.
o LISP IANA registry allocations SHOULD NOT be made for purposes o LISP IANA registry allocations SHOULD NOT be made for purposes
unrelated to LISP routing or transport protocols. unrelated to LISP routing or transport protocols.
o The following policies are used here with the meanings defined in o The following policies are used here with the meanings defined in
BCP 26: "Specification Required", "IETF Review", "Experimental BCP 26: "Specification Required", "IETF Review", "Experimental
Use", and "First Come First Served". Use", and "First Come First Served".
8.1. LISP Packet Type Codes 10.1. LISP UDP Port Numbers
The IANA registry has allocated UDP port number 4342 for the LISP
control-plane. IANA has updated the description for UDP port 4342 as
follows:
lisp-control 4342 udp LISP Control Packets
10.2. LISP Packet Type Codes
It is being requested that the IANA be authoritative for LISP Packet It is being requested that the IANA be authoritative for LISP Packet
Type definitions and that it refers to this document as well as Type definitions and that it refers to this document as well as
[RFC8113] as references. [RFC8113] as references.
Based on deployment experience of [RFC6830], the Map-Notify-Ack Based on deployment experience of [RFC6830], the Map-Notify-Ack
message, message type 5, was added to this document. This document message, message type 5, was added to this document. This document
requests IANA to add it to the LISP Packet Type Registry. requests IANA to add it to the LISP Packet Type Registry.
8.2. LISP ACT and Flag Fields 10.3. LISP ACT and Flag Fields
New ACT values can be allocated through IETF review or IESG approval. New ACT values can be allocated through IETF review or IESG approval.
Four values have already been allocated by [RFC6830]. This Four values have already been allocated by [RFC6830]. This
specification changes the name of ACT type 3 value from "Drop" to specification changes the name of ACT type 3 value from "Drop" to
"Drop/No-Reason" as well as adding two new ACT values, the "Drop/ "Drop/No-Reason" as well as adding two new ACT values, the "Drop/
Policy-Denied" (type 4) and "Drop/Authentication-Failure" (type 5). Policy-Denied" (type 4) and "Drop/Authentication-Failure" (type 5).
In addition, LISP has a number of flag fields and reserved fields, In addition, LISP has a number of flag fields and reserved fields,
such as the LISP header flags field [I-D.ietf-lisp-rfc6830bis]. New such as the LISP header flags field [I-D.ietf-lisp-rfc6830bis]. New
bits for flags in these fields can be implemented after IETF review bits for flags in these fields can be implemented after IETF review
or IESG approval, but these need not be managed by IANA. or IESG approval, but these need not be managed by IANA.
8.3. LISP Address Type Codes 10.4. LISP Address Type Codes
LISP Canonical Address Format (LCAF) [RFC8060] is an 8-bit field that LISP Canonical Address Format (LCAF) [RFC8060] is an 8-bit field that
defines LISP-specific encodings for AFI value 16387. LCAF encodings defines LISP-specific encodings for AFI value 16387. LCAF encodings
are used for specific use-cases where different address types for are used for specific use-cases where different address types for
EID-records and RLOC-records are required. EID-records and RLOC-records are required.
The IANA registry "LISP Canonical Address Format (LCAF) Types" is The IANA registry "LISP Canonical Address Format (LCAF) Types" is
used for LCAF types, the registry for LCAF types use the used for LCAF types, the registry for LCAF types use the
Specification Required policy [RFC8126]. Initial values for the Specification Required policy [RFC8126]. Initial values for the
registry as well as further information can be found in [RFC8060]. registry as well as further information can be found in [RFC8060].
Therefore, there is no longer a need for the "LISP Address Type Therefore, there is no longer a need for the "LISP Address Type
Codes" registry requested by [RFC6830]. This document requests to Codes" registry requested by [RFC6830]. This document requests to
remove it. remove it.
8.4. LISP Algorithm ID Numbers 10.5. LISP Algorithm ID Numbers
In [RFC6830], a request for a "LISP Key ID Numbers" registry was In [RFC6830], a request for a "LISP Key ID Numbers" registry was
submitted. This document renames the registry to "LISP Algorithm ID submitted. This document renames the registry to "LISP Algorithm ID
Numbers" and requests the IANA to make the name change. Numbers" and requests the IANA to make the name change.
The following Algorithm ID values are defined by this specification The following Algorithm ID values are defined by this specification
as used in any packet type that references a 'Algorithm ID' field: as used in any packet type that references a 'Algorithm ID' field:
Name Number Defined in Name Number Defined in
----------------------------------------------- -----------------------------------------------
None 0 n/a None 0 n/a
HMAC-SHA-1-96 1 [RFC2404] HMAC-SHA-1-96 1 [RFC2404]
HMAC-SHA-256-128 2 [RFC4868] HMAC-SHA-256-128 2 [RFC4868]
Number values are in the range of 0 to 255. The allocation of values Number values are in the range of 0 to 255. The allocation of values
is on a first come first served basis. is on a first come first served basis.
9. References 11. References
9.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 11.1. Normative References
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[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, <https://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,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
skipping to change at page 36, line 11 skipping to change at page 40, line 16
Smirnov, "Locator/ID Separation Protocol Delegated Smirnov, "Locator/ID Separation Protocol Delegated
Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111,
May 2017, <https://www.rfc-editor.org/info/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,
<https://www.rfc-editor.org/info/rfc8113>. <https://www.rfc-editor.org/info/rfc8113>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 11.2. Informative References
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
9.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-13 (work in progress), September 2017. lisp-nat-traversal-13 (work in progress), September 2017.
skipping to change at page 36, line 47 skipping to change at page 40, line 47
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-01 (work in progress), Mobile Node", draft-ietf-lisp-mn-01 (work in progress),
October 2017. October 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-07 (work in progress), (LISP)", draft-ietf-lisp-rfc6830bis-09 (work in progress),
November 2017. February 2018.
[I-D.ietf-lisp-sec] [I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14
(work in progress), October 2017. (work in progress), October 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-07 (work in draft-ietf-lisp-signal-free-multicast-08 (work in
progress), November 2017. progress), February 2018.
[I-D.ietf-opsec-icmp-filtering]
Gont, F., Gont, G., and C. Pignataro, "Recommendations for
filtering ICMP messages", draft-ietf-opsec-icmp-
filtering-04 (work in progress), July 2013.
[I-D.lewis-lisp-gpe] [I-D.lewis-lisp-gpe]
Lewis, D., Lemon, J., Agarwal, P., Kreeger, L., Quinn, P., Lewis, D., Lemon, J., Agarwal, P., Kreeger, L., Quinn, P.,
Smith, M., Yadav, N., and F. Maino, "LISP Generic Protocol Smith, M., Yadav, N., and F. Maino, "LISP Generic Protocol
Extension", draft-lewis-lisp-gpe-04 (work in progress), Extension", draft-lewis-lisp-gpe-04 (work in progress),
December 2017. December 2017.
[I-D.meyer-loc-id-implications]
Meyer, D. and D. Lewis, "Architectural Implications of
Locator/ID Separation", draft-meyer-loc-id-implications-01
(work in progress), January 2009.
[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] [I-D.rodrigueznatal-lisp-pubsub]
Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F.,
Cabellos-Aparicio, A., Barkai, S., Farinacci, D., Cabellos-Aparicio, A., Barkai, S., Farinacci, D.,
Boucadair, M., Jacquenet, C., and s. Boucadair, M., Jacquenet, C., and s.
stefano.secci@lip6.fr, "Publish/Subscribe Functionality stefano.secci@lip6.fr, "Publish/Subscribe Functionality
for LISP", draft-rodrigueznatal-lisp-pubsub-01 (work in for LISP", draft-rodrigueznatal-lisp-pubsub-02 (work in
progress), October 2017. progress), March 2018.
[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.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/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,
<https://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[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,
<https://www.rfc-editor.org/info/rfc6234>. <https://www.rfc-editor.org/info/rfc6234>.
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking between Locator/ID Separation Protocol
(LISP) and Non-LISP Sites", RFC 6832,
DOI 10.17487/RFC6832, January 2013,
<https://www.rfc-editor.org/info/rfc6832>.
[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,
<https://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,
<https://www.rfc-editor.org/info/rfc7835>. <https://www.rfc-editor.org/info/rfc7835>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
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-07 B.1. Changes to draft-ietf-lisp-rfc6833bis-08
o Posted March 2018.
o Added RLOC-probing algorithm.
o Added Solicit-Map Request algorithm.
o Added several mechanisms (from 6830bis) regarding Routing Locator
Reachability.
o Added port 4342 to IANA Considerations section.
B.2. Changes to draft-ietf-lisp-rfc6833bis-07
o Posted December 2017. o Posted December 2017.
o Make it more clear in a couple of places that RLOCs are used to o Make it more clear in a couple of places that RLOCs are used to
locate ETRs more so than for Map-Server Map-Request forwarding. locate ETRs more so than for Map-Server Map-Request forwarding.
o Make it clear that "encapsualted" for a control message is an ECM o Make it clear that "encapsualted" for a control message is an ECM
based message. based message.
o Make it more clear what messages use source-port 4342 and which o Make it more clear what messages use source-port 4342 and which
skipping to change at page 39, line 46 skipping to change at page 44, line 11
Can use othe AFIs then IPv4 and IPv6. Can use othe AFIs then IPv4 and IPv6.
o Many editorial changes to clarify text. o Many editorial changes to clarify text.
o Changed some "must", "should", and "may" to capitalized. o Changed some "must", "should", and "may" to capitalized.
o Added definitions for Map-Request and Map-Reply messages. o Added definitions for Map-Request and Map-Reply messages.
o Ran document through IDNITs. o Ran document through IDNITs.
B.2. Changes to draft-ietf-lisp-rfc6833bis-06 B.3. Changes to draft-ietf-lisp-rfc6833bis-06
o Posted October 2017. o Posted October 2017.
o Spec the I-bit to include the xTR-ID in a Map-Request message to o Spec the I-bit to include the xTR-ID in a Map-Request message to
be consistent with the Map-Register message and to anticipate the be consistent with the Map-Register message and to anticipate the
introduction of pubsub functionality to allow Map-Requests to introduction of pubsub functionality to allow Map-Requests to
subscribe to RLOC-set changes. subscribe to RLOC-set changes.
o Updated references for individual submissions that became working o Updated references for individual submissions that became working
group documents. group documents.
o Updated references for working group documents that became RFCs. o Updated references for working group documents that became RFCs.
B.3. Changes to draft-ietf-lisp-rfc6833bis-05 B.4. 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.4. Changes to draft-ietf-lisp-rfc6833bis-04 B.5. 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.5. Changes to draft-ietf-lisp-rfc6833bis-03 B.6. 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.6. Changes to draft-ietf-lisp-rfc6833bis-02 B.7. 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.7. Changes to draft-ietf-lisp-rfc6833bis-01 B.8. 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.8. Changes to draft-ietf-lisp-rfc6833bis-00 B.9. 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.9. Changes to draft-farinacci-lisp-rfc6833bis-00 B.10. 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. 44 change blocks. 
82 lines changed or deleted 325 lines changed or added

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