draft-ietf-lisp-rfc6833bis-13.txt   draft-ietf-lisp-rfc6833bis-14.txt 
Network Working Group V. Fuller Network Working Group V. Fuller
Internet-Draft D. Farinacci Internet-Draft D. Farinacci
Obsoletes: 6833 (if approved) Cisco Systems Obsoletes: 6833 (if approved) Cisco Systems
Intended status: Standards Track A. Cabellos (Ed.) Intended status: Standards Track A. Cabellos (Ed.)
Expires: February 25, 2019 UPC/BarcelonaTech Expires: March 15, 2019 UPC/BarcelonaTech
August 24, 2018 September 11, 2018
Locator/ID Separation Protocol (LISP) Control-Plane Locator/ID Separation Protocol (LISP) Control-Plane
draft-ietf-lisp-rfc6833bis-13 draft-ietf-lisp-rfc6833bis-14
Abstract Abstract
This document describes the Control-Plane and Mapping Service for the This document describes the Control-Plane and Mapping Service for the
Locator/ID Separation Protocol (LISP), implemented by two new types Locator/ID Separation Protocol (LISP), implemented by two new types
of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server
-- that provides a simplified "front end" for one or more Endpoint ID -- that provides a simplified "front end" for one or more Endpoint ID
to Routing Locator mapping databases. to Routing Locator mapping databases.
By using this Control-Plane service interface and communicating with By using this Control-Plane service interface and communicating with
Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and
Egress Tunnel Routers (ETRs) are not dependent on the details of Egress Tunnel Routers (ETRs) are not dependent on the details of
mapping database systems, which facilitates modularity with different mapping database systems, which facilitates modularity with different
database designs. Since these devices implement the "edge" of the database designs. Since these devices implement the "edge" of the
LISP Control-Plane infrastructure, connect directly to LISP-capable LISP Control-Plane infrastructure, connect directly to LISP-capable
Internet end sites, and comprising the bulk of LISP-speaking devices, Internet end sites, and comprising the bulk of LISP-speaking devices,
reducing their implementation and operational complexity should also reducing their implementation and operational complexity should also
reduce the overall cost and effort of deploying LISP. reduce the overall cost and effort of deploying LISP.
This document obsoletes RFC 6833. This document obsoletes RFC 6830 and 6833.
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 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 February 25, 2019. This Internet-Draft will expire on March 15, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 10 skipping to change at page 3, line 10
11.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 38 11.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 38
11.3. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 39 11.3. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 39
11.4. LISP Address Type Codes . . . . . . . . . . . . . . . . 39 11.4. LISP Address Type Codes . . . . . . . . . . . . . . . . 39
11.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 40 11.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 40
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
12.1. Normative References . . . . . . . . . . . . . . . . . . 40 12.1. Normative References . . . . . . . . . . . . . . . . . . 40
12.2. Informative References . . . . . . . . . . . . . . . . . 41 12.2. Informative References . . . . . . . . . . . . . . . . . 41
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 45 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 45
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 45 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 45
B.1. Changes to draft-ietf-lisp-rfc6833bis-13 . . . . . . . . 45 B.1. Changes to draft-ietf-lisp-rfc6833bis-14 . . . . . . . . 45
B.2. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . 45 B.2. Changes to draft-ietf-lisp-rfc6833bis-13 . . . . . . . . 45
B.3. Changes to draft-ietf-lisp-rfc6833bis-11 . . . . . . . . 45 B.3. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . 45
B.4. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . 45 B.4. Changes to draft-ietf-lisp-rfc6833bis-11 . . . . . . . . 45
B.5. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . 46 B.5. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . 46
B.6. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 46 B.6. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . 46
B.7. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 46 B.7. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 46
B.8. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 47 B.8. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 46
B.9. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 47 B.9. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 47
B.10. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 47 B.10. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 47
B.11. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 47 B.11. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 47
B.12. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 48 B.12. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 48
B.13. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 48 B.13. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 48
B.14. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 48 B.14. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 48
B.15. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 48 B.15. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 48
B.16. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction 1. Introduction
The Locator/ID Separation Protocol [I-D.ietf-lisp-introduction] and The Locator/ID Separation Protocol [I-D.ietf-lisp-rfc6830bis] (see
[I-D.ietf-lisp-rfc6830bis] specifies an architecture and mechanism also [I-D.ietf-lisp-introduction]) specifies an architecture and
for dynamic tunnelling by logically separating the addresses mechanism for dynamic tunnelling by logically separating the
currently used by IP in two separate name spaces: Endpoint IDs addresses currently used by IP in two separate name spaces: Endpoint
(EIDs), used within sites; and Routing Locators (RLOCs), used on the IDs (EIDs), used within sites; and Routing Locators (RLOCs), used on
transit networks that make up the Internet infrastructure. To the transit networks that make up the Internet infrastructure. To
achieve this separation, LISP defines protocol mechanisms for mapping achieve this separation, LISP defines protocol mechanisms for mapping
from EIDs to RLOCs. In addition, LISP assumes the existence of a from EIDs to RLOCs. In addition, LISP assumes the existence of a
database to store and propagate those mappings globally. Several database to store and propagate those mappings globally. Several
such databases have been proposed; among them are the Content such databases have been proposed; among them are the Content
distribution Overlay Network Service for LISP-NERD (a Not-so-novel distribution Overlay Network Service for LISP-NERD (a Not-so-novel
EID-to-RLOC Database) [RFC6837], LISP Alternative Logical Topology EID-to-RLOC Database) [RFC6837], LISP Alternative Logical Topology
(LISP-ALT) [RFC6836], and LISP Delegated Database Tree (LISP-DDT) (LISP-ALT) [RFC6836], and LISP Delegated Database Tree (LISP-DDT)
[RFC8111]. [RFC8111].
The LISP Mapping Service defines two new types of LISP-speaking The LISP Mapping Service defines two new types of LISP-speaking
skipping to change at page 4, line 28 skipping to change at page 4, line 31
infrastructure to illustrate certain aspects of Map-Server and Map- infrastructure to illustrate certain aspects of Map-Server and Map-
Resolver operation, the Mapping Service interface can (and likely Resolver operation, the Mapping Service interface can (and likely
will) be used by ITRs and ETRs to access other mapping database will) be used by ITRs and ETRs to access other mapping database
systems as the LISP infrastructure evolves. systems as the LISP infrastructure evolves.
The LISP Mapping Service is an important component of the LISP The LISP Mapping Service is an important component of the LISP
toolset. Issues and concerns about the deployment of LISP for toolset. Issues and concerns about the deployment of LISP for
Internet traffic are discussed in [I-D.ietf-lisp-rfc6830bis], Internet traffic are discussed in [I-D.ietf-lisp-rfc6830bis],
[RFC7215], and [I-D.rodrigueznatal-lisp-oam]. [RFC7215], and [I-D.rodrigueznatal-lisp-oam].
This document obsoletes RFC 6833. This document obsoletes RFC 6830 and 6833.
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] and document are to be interpreted as described in [RFC2119] and
[RFC8174]. [RFC8174].
3. Definition of Terms 3. Definition of Terms
skipping to change at page 8, line 18 skipping to change at page 8, line 18
\ | UDP Length | UDP Checksum | \ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| LISP Message | | LISP Message |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When a UDP Map-Request, Map-Register, or Map-Notify (when used as a When a UDP Map-Request, Map-Register, or Map-Notify (when used as a
notification message) are sent, the UDP source port is chosen by the notification message) are sent, the UDP source port is chosen by the
sender and the destination UDP port number is set to 4342. When a sender and the destination UDP port number is set to 4342. When a
UDP Map-Reply Map-Notify (when used as an acknowledgement to a Map- UDP Map-Reply, Map-Notify (when used as an acknowledgement to a Map-
Register), or Map-Notify-Ack are sent, the source UDP port number is Register), or Map-Notify-Ack are sent, the source UDP port number is
set to 4342 and the destination UDP port number is copied from the set to 4342 and the destination UDP port number is copied from the
source port of either the Map-Request or the invoking data packet. source port of either the Map-Request or the invoking data packet.
Implementations MUST be prepared to accept packets when either the Implementations MUST be prepared to accept packets when either the
source port or destination UDP port is set to 4342 due to NATs source port or destination UDP port is set to 4342 due to NATs
changing port number values. changing port number values.
The 'UDP Length' field will reflect the length of the UDP header and The 'UDP Length' field will reflect the length of the UDP header and
the LISP Message payload. the LISP Message payload.
skipping to change at page 9, line 19 skipping to change at page 9, line 19
completeness, this document references the LISP Shared Extension completeness, this document references the LISP Shared Extension
Message assigned by [RFC8113]. Message type definitions are: Message assigned by [RFC8113]. Message type definitions are:
Reserved: 0 b'0000' Reserved: 0 b'0000'
LISP Map-Request: 1 b'0001' LISP Map-Request: 1 b'0001'
LISP Map-Reply: 2 b'0010' LISP Map-Reply: 2 b'0010'
LISP Map-Register: 3 b'0011' LISP Map-Register: 3 b'0011'
LISP Map-Notify: 4 b'0100' LISP Map-Notify: 4 b'0100'
LISP Map-Notify-Ack: 5 b'0101' LISP Map-Notify-Ack: 5 b'0101'
LISP Map-Referral: 6 b'0110' LISP Map-Referral: 6 b'0110'
Not Assigned 7 b'0111'
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. packet type may indicate a preferred value.
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 17, line 46 skipping to change at page 17, line 46
[I-D.ietf-lisp-6834bis] for more details. [I-D.ietf-lisp-6834bis] for more details.
EID-Prefix-AFI: Address family of the EID-Prefix according to [AFI] EID-Prefix-AFI: Address family of the EID-Prefix according to [AFI]
and [RFC8060]. and [RFC8060].
EID-Prefix: This prefix is 4 octets for an IPv4 address family and EID-Prefix: This prefix is 4 octets for an IPv4 address family and
16 octets for an IPv6 address family. 16 octets for an IPv6 address family.
Priority: Each RLOC is assigned a unicast Priority. Lower values Priority: Each RLOC is assigned a unicast Priority. Lower values
are more preferable. When multiple RLOCs have the same Priority, are more preferable. When multiple RLOCs have the same Priority,
they MAY be used in a load-split fashion. A value of 255 means they may be used in a load-split fashion. A value of 255 means
the RLOC MUST NOT be used for unicast forwarding. the RLOC MUST NOT be used for unicast forwarding.
Weight: When priorities are the same for multiple RLOCs, the Weight Weight: When priorities are the same for multiple RLOCs, the Weight
indicates how to balance unicast traffic between them. Weight is indicates how to balance unicast traffic between them. Weight is
encoded as a relative weight of total unicast packets that match encoded as a relative weight of total unicast packets that match
the mapping entry. For example, if there are 4 Locators in a the mapping entry. For example, if there are 4 Locators in a
Locator-Set, where the Weights assigned are 30, 20, 20, and 10, Locator-Set, where the Weights assigned are 30, 20, 20, and 10,
the first Locator will get 37.5% of the traffic, the 2nd and 3rd the first Locator will get 37.5% of the traffic, the 2nd and 3rd
Locators will get 25% of the traffic, and the 4th Locator will get Locators will get 25% of the traffic, and the 4th Locator will get
12.5% of the traffic. If all Weights for a Locator-Set are equal, 12.5% of the traffic. If all Weights for a Locator-Set are equal,
skipping to change at page 18, line 38 skipping to change at page 18, line 38
Unused Flags: These are set to 0 when sending and ignored on Unused Flags: These are set to 0 when sending and ignored on
receipt. receipt.
L: When this bit is set, the Locator is flagged as a local Locator to L: When this bit is set, the Locator is flagged as a local Locator to
the ETR that is sending the Map-Reply. When a Map-Server is doing the ETR that is sending the Map-Reply. When a Map-Server is doing
proxy Map-Replying for a LISP site, the L-bit is set to 0 for all proxy Map-Replying for a LISP site, the L-bit is set to 0 for all
Locators in this Locator-Set. Locators in this Locator-Set.
p: When this bit is set, an ETR informs the RLOC-Probing ITR that the p: When this bit is set, an ETR informs the RLOC-Probing ITR that the
locator address for which this bit is set is the one being RLOC- locator address for which this bit is set is the one being RLOC-
probed and MAY be different from the source address of the Map- probed and may be different from the source address of the Map-
Reply. An ITR that RLOC-probes a particular Locator MUST use this Reply. An ITR that RLOC-probes a particular Locator MUST use this
Locator for retrieving the data structure used to store the fact Locator for retrieving the data structure used to store the fact
that the Locator is reachable. The p-bit is set for a single that the Locator is reachable. The p-bit is set for a single
Locator in the same Locator-Set. If an implementation sets more Locator in the same Locator-Set. If an implementation sets more
than one p-bit erroneously, the receiver of the Map-Reply MUST than one p-bit erroneously, the receiver of the Map-Reply MUST
select the first Locator. The p-bit MUST NOT be set for Locator- select the first Locator. The p-bit MUST NOT be set for Locator-
Set records sent in Map-Request and Map-Register messages. Set records sent in Map-Request and Map-Register messages.
R: This is set when the sender of a Map-Reply has a route to the R: This is set when the sender of a Map-Reply has a route to the
Locator in the Locator data record. This receiver MAY find this Locator in the Locator data record. This receiver may find this
useful to know if the Locator is up but not necessarily reachable useful to know if the Locator is up but not necessarily reachable
from the receiver's point of view. See also EID-Reachability from the receiver's point of view. See also EID-Reachability
Section 7.1 for another way the R-bit MAY be used. Section 7.1 for another way the R-bit may be used.
Locator: This is an IPv4 or IPv6 address (as encoded by the 'Loc- Locator: This is an IPv4 or IPv6 address (as encoded by the 'Loc-
AFI' field) assigned to an ETR. Note that the destination RLOC AFI' field) assigned to an ETR. Note that the destination RLOC
address MAY be an anycast address. A source RLOC can be an address MAY be an anycast address. A source RLOC can be an
anycast address as well. The source or destination RLOC MUST NOT anycast address as well. The source or destination RLOC MUST NOT
be the broadcast address (255.255.255.255 or any subnet broadcast be the broadcast address (255.255.255.255 or any subnet broadcast
address known to the router) and MUST NOT be a link-local address known to the router) and MUST NOT be a link-local
multicast address. The source RLOC MUST NOT be a multicast multicast address. The source RLOC MUST NOT be a multicast
address. The destination RLOC SHOULD be a multicast address if it address. The destination RLOC SHOULD be a multicast address if it
is being mapped from a multicast destination EID. is being mapped from a multicast destination EID.
skipping to change at page 23, line 46 skipping to change at page 23, line 46
message. message.
Record Count: This is the number of records in this Map-Register Record Count: This is the number of records in this Map-Register
message. A record is comprised of that portion of the packet message. A record is comprised of that portion of the packet
labeled 'Record' above and occurs the number of times equal to labeled 'Record' above and occurs the number of times equal to
Record Count. Record Count.
Nonce: This 8-octet 'Nonce' field is set to 0 in Map-Register Nonce: This 8-octet 'Nonce' field is set to 0 in Map-Register
messages if no Map-Notify message is expected to acknowledge it. messages if no Map-Notify message is expected to acknowledge it.
Since the Map-Register message is authenticated, the 'Nonce' field Since the Map-Register message is authenticated, the 'Nonce' field
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 11.5 for codepoint Algorithm ID Numbers in the Section 11.5 for codepoint
skipping to change at page 28, line 28 skipping to change at page 28, line 28
6.1. Solicit-Map-Request (SMR) 6.1. Solicit-Map-Request (SMR)
Soliciting a Map-Request is a selective way for ETRs, at the site Soliciting a Map-Request is a selective way for ETRs, at the site
where mappings change, to control the rate they receive requests for where mappings change, to control the rate they receive requests for
Map-Reply messages. SMRs are also used to tell remote ITRs to update Map-Reply messages. SMRs are also used to tell remote ITRs to update
the mappings they have cached. the mappings they have cached.
Since the ETRs don't keep track of remote ITRs that have cached their Since the ETRs don't keep track of remote ITRs that have cached their
mappings, they do not know which ITRs need to have their mappings mappings, they do not know which ITRs need to have their mappings
updated. As a result, an ETR will solicit Map-Requests (called an updated. As a result, an ETR will solicit Map-Requests (called an
SMR message) from those sites to which it has been sending SMR message) to those sites to which it has been sending encapsulated
encapsulated data for the last minute. In particular, an ETR will data for the last minute. In particular, an ETR will send an SMR to
send an SMR to an ITR to which it has recently sent encapsulated an ITR to which it has recently sent encapsulated data. This can
data. This can only occur when both ITR and ETR functionality reside only occur when both ITR and ETR functionality reside in the same
in the same router. router.
An SMR message is simply a bit set in a Map-Request message. An ITR 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. 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 Both the SMR sender and the Map-Request responder MUST rate-limit
these messages. Rate-limiting can be implemented as a global rate- these messages. Rate-limiting can be implemented as a global rate-
limiter or one rate-limiter per SMR destination. limiter or one rate-limiter per SMR destination.
The following procedure shows how an SMR exchange occurs when a site The following procedure shows how an SMR exchange occurs when a site
is doing Locator-Set compaction for an EID-to-RLOC mapping: is doing Locator-Set compaction for an EID-to-RLOC mapping:
skipping to change at page 29, line 37 skipping to change at page 29, line 37
Replies. To avoid Map-Cache entry corruption by a third party, a 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 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 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- Locator-Set for the stored Map-Cache entry, then the responding Map-
Request MUST be sent with an EID destination to the mapping database Request MUST be sent with an EID destination to the mapping database
system. Since the mapping database system is a more secure way to system. Since the mapping database system is a more secure way to
reach an authoritative ETR, it will deliver the Map-Request to the reach an authoritative ETR, it will deliver the Map-Request to the
authoritative source of the mapping data. authoritative source of the mapping data.
When an ITR receives an SMR-based Map-Request for which it does not 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 have a cached mapping for the EID in the SMR message, it SHOULD NOT
an SMR-invoked Map-Request. This scenario can occur when an ETR 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 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 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 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 until they need to send, in which case they will send Map-Requests to
obtain a Map-Cache entry. obtain a Map-Cache entry.
7. Routing Locator Reachability 7. Routing Locator Reachability
This document defines several Control-Plane mechanisms for This document defines several Control-Plane mechanisms for
determining RLOC reachability. Please note that additional Data- determining RLOC reachability. Please note that additional Data-
Plane reachability mechanisms are defined in Plane reachability mechanisms are defined in
[I-D.ietf-lisp-rfc6830bis]. [I-D.ietf-lisp-rfc6830bis].
1. An ITR MAY receive an ICMP Network Unreachable or Host 1. An ITR may receive an ICMP Network Unreachable or Host
Unreachable message for an RLOC it is using. This indicates that Unreachable message for an RLOC it is using. This indicates that
the RLOC is likely down. Note that trusting ICMP messages may the RLOC is likely down. Note that trusting ICMP messages may
not be desirable, but neither is ignoring them completely. not be desirable, but neither is ignoring them completely.
Implementations are encouraged to follow current best practices Implementations are encouraged to follow current best practices
in treating these conditions [I-D.ietf-opsec-icmp-filtering]. in treating these conditions [I-D.ietf-opsec-icmp-filtering].
2. When an ITR participates in the routing protocol that operates in 2. When an ITR participates in the routing protocol that operates in
the underlay routing system, it can determine that an RLOC is the underlay routing system, it can determine that an RLOC is
down when no Routing Information Base (RIB) entry exists that down when no Routing Information Base (RIB) entry exists that
matches the RLOC IP address. matches the RLOC IP address.
3. An ITR MAY receive an ICMP Port Unreachable message from a 3. An ITR may receive an ICMP Port Unreachable message from a
destination host. This occurs if an ITR attempts to use destination host. This occurs if an ITR attempts to use
interworking [RFC6832] and LISP-encapsulated data is sent to a interworking [RFC6832] and LISP-encapsulated data is sent to a
non-LISP-capable site. non-LISP-capable site.
4. An ITR MAY receive a Map-Reply from an ETR in response to a 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 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 likely up, since the ETR was able to send the Map-Reply to the
ITR. ITR.
5. An ITR/ETR pair can use the 'RLOC-Probing' mechanism described 5. An ITR/ETR pair can use the 'RLOC-Probing' mechanism described
below. below.
When ITRs receive ICMP Network Unreachable or Host Unreachable When ITRs receive ICMP Network Unreachable or Host Unreachable
messages as a method to determine unreachability, they will refrain messages as a method to determine unreachability, they will refrain
from using Locators that are described in Locator lists of Map- from using Locators that are described in Locator lists of Map-
skipping to change at page 33, line 9 skipping to change at page 33, line 9
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 8.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 8.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.
skipping to change at page 33, line 33 skipping to change at page 33, line 33
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
vulnerable to trivial EID-Prefix hijacking attacks. As developers vulnerable to trivial EID-Prefix hijacking attacks. As developers
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 8.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
skipping to change at page 34, line 21 skipping to change at page 34, line 21
this flag by an ETR would be to set it for Map-Register messages sent this flag by an ETR would be to set it for Map-Register messages sent
during the initial "quick registration" with a Map-Server but then during the initial "quick registration" with a Map-Server but then
set it only occasionally during steady-state maintenance of its set it only occasionally during steady-state maintenance of its
association with that Map-Server. Note that the Map-Notify message association with that Map-Server. Note that the Map-Notify message
is sent to UDP destination port 4342, not to the source port is sent to UDP destination port 4342, not to the source port
specified in the original Map-Register message. specified in the original Map-Register message.
Note that a one-minute minimum registration interval during Note that a one-minute minimum registration interval during
maintenance of an ETR-Map-Server association places a lower bound on maintenance of an ETR-Map-Server association places a lower bound on
how quickly and how frequently a mapping database entry can be how quickly and how frequently a mapping database entry can be
updated. This MAY have implications for what sorts of mobility can updated. This may have implications for what sorts of mobility can
be supported directly by the mapping system; shorter registration be supported directly by the mapping system; shorter registration
intervals or other mechanisms might be needed to support faster intervals or other mechanisms might be needed to support faster
mobility in some cases. For a discussion on one way that faster mobility in some cases. For a discussion on one way that faster
mobility MAY be implemented for individual devices, please see mobility may be implemented for individual devices, please see
[I-D.ietf-lisp-mn]. [I-D.ietf-lisp-mn].
An ETR MAY also request, by setting the "proxy Map-Reply" flag An ETR MAY also request, by setting the "proxy Map-Reply" flag
(P-bit) in the Map-Register message, that a Map-Server answer Map- (P-bit) in the Map-Register message, that a Map-Server answer Map-
Requests instead of forwarding them to the ETR. See Section 7.1 for Requests instead of forwarding them to the ETR. See Section 7.1 for
details on how the Map-Server sets certain flags (such as those details on how the Map-Server sets certain flags (such as those
indicating whether the message is authoritative and how returned indicating whether the message is authoritative and how returned
Locators SHOULD be treated) when sending a Map-Reply on behalf of an Locators SHOULD be treated) when sending a Map-Reply on behalf of an
ETR. When an ETR requests proxy reply service, it SHOULD include all ETR. When an ETR requests proxy reply service, it SHOULD include all
RLOCs for all ETRs for the EID-Prefix being registered, along with RLOCs for all ETRs for the EID-Prefix being registered, along with
skipping to change at page 35, line 17 skipping to change at page 35, line 17
8.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 can 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-
specific EID-Prefix exists; it indicates the presence of a non-LISP specific EID-Prefix exists; it indicates the presence of a non-LISP
"hole" in the aggregate EID-Prefix. "hole" in the aggregate EID-Prefix.
Next, the Map-Server checks to see if any ETRs have registered the Next, the Map-Server checks to see if any ETRs have registered the
matching EID-Prefix. If none are found, then the Map-Server returns matching EID-Prefix. If none are found, then the Map-Server returns
a Negative Map-Reply with action code "Natively-Forward" and a a Negative Map-Reply with action code "Natively-Forward" and a
1-minute TTL. 1-minute TTL.
If the EID-prefix is either registered or not registered to the If the EID-prefix is either registered or not registered to the
skipping to change at page 35, line 47 skipping to change at page 35, line 47
If any of the registered ETRs for the EID-Prefix have requested proxy If any of the registered ETRs for the EID-Prefix have requested proxy
reply service, then the Map-Server answers the request instead of reply service, then the Map-Server answers the request instead of
forwarding it. It returns a Map-Reply with the EID-Prefix, RLOCs, forwarding it. It returns a Map-Reply with the EID-Prefix, RLOCs,
and other information learned through the registration process. and other information learned through the registration process.
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.
8.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-
skipping to change at page 37, line 26 skipping to change at page 37, line 26
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-
Reply exchange. Work is ongoing on this and other proposals for Reply exchange. Work is ongoing on this and other proposals for
resolving these open security issues. resolving these open security issues.
While beyond the scope of securing an individual Map-Server or Map- While beyond the scope of securing an individual Map-Server or Map-
Resolver, it SHOULD be noted that a BGP-based LISP-ALT network (if Resolver, it should be noted that a BGP-based LISP-ALT network (if
ALT is used as the mapping database infrastructure) can take ALT is used as the mapping database infrastructure) can take
advantage of standards work on adding security to BGP. advantage of standards work on adding security to BGP.
A complete LISP threat analysis has been published in [RFC7835]. A complete LISP threat analysis has been published in [RFC7835].
Please refer to it for more security related details. Please refer to it for more security related details.
10. Changes since RFC 6833 10. Changes since RFC 6833
For implementation considerations, the following changes have been For implementation considerations, the following changes have been
made to this document since RFC 6833 was published: made to this document since RFC 6833 was published:
skipping to change at page 38, line 27 skipping to change at page 38, line 27
11. IANA Considerations 11. IANA Considerations
This section provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to this Authority (IANA) regarding registration of values related to this
LISP Control-Plane specification, in accordance with BCP 26 LISP Control-Plane specification, in accordance with BCP 26
[RFC8126]. [RFC8126].
There are three namespaces (listed in the sub-sections below) in LISP There are three namespaces (listed in the sub-sections below) in LISP
that have been registered. that have been registered.
o LISP IANA registry allocations SHOULD NOT be made for purposes o LISP IANA registry allocations should not be made for purposes
unrelated to LISP routing or transport protocols. unrelated to LISP routing or transport protocols.
o The following policies are used here with the meanings defined in o The following policies are used here with the meanings defined in
BCP 26: "Specification Required", "IETF Review", "Experimental BCP 26: "Specification Required", "IETF Review", "Experimental
Use", and "First Come First Served". Use", and "First Come First Served".
11.1. LISP UDP Port Numbers 11.1. LISP UDP Port Numbers
The IANA registry has allocated UDP port number 4342 for the LISP The IANA registry has allocated UDP port number 4342 for the LISP
Control-Plane. IANA has updated the description for UDP port 4342 as Control-Plane. IANA has updated the description for UDP port 4342 as
skipping to change at page 40, line 30 skipping to change at page 40, line 30
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.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-lisp-6834bis] [I-D.ietf-lisp-6834bis]
Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Map-Versioning", draft-ietf- Separation Protocol (LISP) Map-Versioning", draft-ietf-
lisp-6834bis-00 (work in progress), July 2018. lisp-6834bis-02 (work in progress), September 2018.
[I-D.ietf-lisp-rfc6830bis] [I-D.ietf-lisp-rfc6830bis]
Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos-Aparicio, "The Locator/ID Separation Protocol Cabellos-Aparicio, "The Locator/ID Separation Protocol
(LISP)", draft-ietf-lisp-rfc6830bis-14 (work in progress), (LISP)", draft-ietf-lisp-rfc6830bis-16 (work in progress),
July 2018. August 2018.
[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 45, line 19 skipping to change at page 45, line 19
Fabio Maino, and members of the lisp@ietf.org mailing list for their Fabio Maino, and members of the lisp@ietf.org mailing list for their
feedback and helpful suggestions. feedback and helpful suggestions.
Special thanks are due to Noel Chiappa for his extensive work and Special thanks are due to Noel Chiappa for his extensive work and
thought about caching in Map-Resolvers. thought about caching in Map-Resolvers.
Appendix B. Document Change Log Appendix B. Document Change Log
[RFC Editor: Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on publication as RFC.]
B.1. Changes to draft-ietf-lisp-rfc6833bis-13 B.1. Changes to draft-ietf-lisp-rfc6833bis-14
o Posted September 2018.
o Changes to reflect comments from Genart, RTGarea, and Secdir
reviews.
B.2. Changes to draft-ietf-lisp-rfc6833bis-13
o Posted August 2018. o Posted August 2018.
o Final editorial changes before RFC submission for Proposed o Final editorial changes before RFC submission for Proposed
Standard. Standard.
o Added section "Changes since RFC 6833" so implementators are o Added section "Changes since RFC 6833" so implementators are
informed of any changes since the last RFC publication. informed of any changes since the last RFC publication.
B.2. Changes to draft-ietf-lisp-rfc6833bis-12 B.3. Changes to draft-ietf-lisp-rfc6833bis-12
o Posted late July 2018. o Posted late July 2018.
o Moved RFC6830bis and RFC6834bis to Normative References. o Moved RFC6830bis and RFC6834bis to Normative References.
B.3. Changes to draft-ietf-lisp-rfc6833bis-11 B.4. Changes to draft-ietf-lisp-rfc6833bis-11
o Posted July 2018. o Posted July 2018.
o Fixed Luigi editorial comments to ready draft for RFC status and o Fixed Luigi editorial comments to ready draft for RFC status and
ran through IDNITs again. ran through IDNITs again.
B.4. Changes to draft-ietf-lisp-rfc6833bis-10 B.5. Changes to draft-ietf-lisp-rfc6833bis-10
o Posted after LISP WG at IETF week March. o Posted after LISP WG at IETF week March.
o Move AD field encoding after S-bit in the ECM packet format o Move AD field encoding after S-bit in the ECM packet format
description section. description section.
o Say more about when the new Drop actions should be sent. o Say more about when the new Drop actions should be sent.
B.5. Changes to draft-ietf-lisp-rfc6833bis-09 B.6. Changes to draft-ietf-lisp-rfc6833bis-09
o Posted March IETF week 2018. o Posted March IETF week 2018.
o Fixed editorial comments submitted by document shepherd Luigi o Fixed editorial comments submitted by document shepherd Luigi
Iannone. Iannone.
B.6. Changes to draft-ietf-lisp-rfc6833bis-08 B.7. Changes to draft-ietf-lisp-rfc6833bis-08
o Posted March 2018. o Posted March 2018.
o Added RLOC-probing algorithm. o Added RLOC-probing algorithm.
o Added Solicit-Map Request algorithm. o Added Solicit-Map Request algorithm.
o Added several mechanisms (from 6830bis) regarding Routing Locator o Added several mechanisms (from 6830bis) regarding Routing Locator
Reachability. Reachability.
o Added port 4342 to IANA Considerations section. o Added port 4342 to IANA Considerations section.
B.7. Changes to draft-ietf-lisp-rfc6833bis-07 B.8. 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 47, line 5 skipping to change at page 47, line 13
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.8. Changes to draft-ietf-lisp-rfc6833bis-06 B.9. 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.9. Changes to draft-ietf-lisp-rfc6833bis-05 B.10. 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.10. Changes to draft-ietf-lisp-rfc6833bis-04 B.11. 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.11. Changes to draft-ietf-lisp-rfc6833bis-03 B.12. 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.12. Changes to draft-ietf-lisp-rfc6833bis-02 B.13. 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.13. Changes to draft-ietf-lisp-rfc6833bis-01 B.14. 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.14. Changes to draft-ietf-lisp-rfc6833bis-00 B.15. 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.15. Changes to draft-farinacci-lisp-rfc6833bis-00 B.16. 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. 47 change blocks. 
72 lines changed or deleted 81 lines changed or added

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