draft-ietf-lisp-rfc6833bis-14.txt   draft-ietf-lisp-rfc6833bis-15.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: March 15, 2019 UPC/BarcelonaTech Expires: March 22, 2019 UPC/BarcelonaTech
September 11, 2018 September 18, 2018
Locator/ID Separation Protocol (LISP) Control-Plane Locator/ID Separation Protocol (LISP) Control-Plane
draft-ietf-lisp-rfc6833bis-14 draft-ietf-lisp-rfc6833bis-15
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 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 15, 2019. This Internet-Draft will expire on March 22, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 34
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 6 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 6
5. LISP IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 7 5. LISP IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 7
5.1. LISP Control Packet Type Allocations . . . . . . . . . . 9 5.1. LISP Control Packet Type Allocations . . . . . . . . . . 9
5.2. Map-Request Message Format . . . . . . . . . . . . . . . 10 5.2. Map-Request Message Format . . . . . . . . . . . . . . . 10
5.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 13 5.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 13
5.4. Map-Reply Message Format . . . . . . . . . . . . . . . . 15 5.4. Map-Reply Message Format . . . . . . . . . . . . . . . . 15
5.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 19 5.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 19
5.6. Map-Register Message Format . . . . . . . . . . . . . . . 22 5.6. Map-Register Message Format . . . . . . . . . . . . . . . 22
5.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 25 5.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 25
5.8. Encapsulated Control Message Format . . . . . . . . . . . 26 5.8. Encapsulated Control Message Format . . . . . . . . . . . 27
6. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 28 6. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 29
6.1. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 28 6.1. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 29
7. Routing Locator Reachability . . . . . . . . . . . . . . . . 29 7. Routing Locator Reachability . . . . . . . . . . . . . . . . 30
7.1. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 31 7.1. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 32
8. Interactions with Other LISP Components . . . . . . . . . . . 32 8. Interactions with Other LISP Components . . . . . . . . . . . 33
8.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 32 8.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 33
8.2. EID-Prefix Configuration and ETR Registration . . . . . . 33 8.2. EID-Prefix Configuration and ETR Registration . . . . . . 34
8.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 35 8.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 36
8.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 36 8.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 37
8.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . 36 8.4.1. Anycast Operation . . . . . . . . . . . . . . . . . . 37
9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37
10. Changes since RFC 6833 . . . . . . . . . . . . . . . . . . . 37 10. Changes since RFC 6833 . . . . . . . . . . . . . . . . . . . 38
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
11.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 38 11.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 39
11.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 38 11.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 39
11.3. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 39 11.3. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 40
11.4. LISP Address Type Codes . . . . . . . . . . . . . . . . 39 11.4. LISP Address Type Codes . . . . . . . . . . . . . . . . 40
11.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 40 11.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 41
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
12.1. Normative References . . . . . . . . . . . . . . . . . . 40 12.1. Normative References . . . . . . . . . . . . . . . . . . 41
12.2. Informative References . . . . . . . . . . . . . . . . . 41 12.2. Informative References . . . . . . . . . . . . . . . . . 42
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 45 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 46
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 45 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 46
B.1. Changes to draft-ietf-lisp-rfc6833bis-14 . . . . . . . . 45 B.1. Changes to draft-ietf-lisp-rfc6833bis-15 . . . . . . . . 46
B.2. Changes to draft-ietf-lisp-rfc6833bis-13 . . . . . . . . 45 B.2. Changes to draft-ietf-lisp-rfc6833bis-14 . . . . . . . . 46
B.3. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . 45 B.3. Changes to draft-ietf-lisp-rfc6833bis-13 . . . . . . . . 46
B.4. Changes to draft-ietf-lisp-rfc6833bis-11 . . . . . . . . 45 B.4. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . 46
B.5. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . 46 B.5. Changes to draft-ietf-lisp-rfc6833bis-11 . . . . . . . . 46
B.6. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . 46 B.6. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . 47
B.7. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 46 B.7. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . 47
B.8. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 46 B.8. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 47
B.9. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 47 B.9. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 47
B.10. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 47 B.10. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 48
B.11. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 47 B.11. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 48
B.12. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 48 B.12. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 48
B.13. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 48 B.13. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 49
B.14. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 48 B.14. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 49
B.15. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 48 B.15. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 49
B.16. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 48 B.16. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 B.17. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
1. Introduction 1. Introduction
The Locator/ID Separation Protocol [I-D.ietf-lisp-rfc6830bis] (see The Locator/ID Separation Protocol [I-D.ietf-lisp-rfc6830bis] (see
also [I-D.ietf-lisp-introduction]) specifies an architecture and also [I-D.ietf-lisp-introduction]) specifies an architecture and
mechanism for dynamic tunnelling by logically separating the mechanism for dynamic tunneling by logically separating the addresses
addresses currently used by IP in two separate name spaces: Endpoint currently used by IP in two separate name spaces: Endpoint IDs
IDs (EIDs), used within sites; and Routing Locators (RLOCs), used on (EIDs), used within sites; and Routing Locators (RLOCs), used on the
the transit networks that make up the Internet infrastructure. To transit networks that make up the Internet infrastructure. To
achieve this separation, LISP defines protocol mechanisms for mapping achieve this separation, LISP defines protocol mechanisms for mapping
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 20 skipping to change at page 4, line 20
[GTP-3GPP], ILA [I-D.herbert-intarea-ila], and Segment Routing (SRv6) [GTP-3GPP], ILA [I-D.herbert-intarea-ila], and Segment Routing (SRv6)
[RFC8402]. [RFC8402].
Conceptually, LISP Map-Servers share some of the same basic Conceptually, LISP Map-Servers share some of the same basic
configuration and maintenance properties as Domain Name System (DNS) configuration and maintenance properties as Domain Name System (DNS)
[RFC1035] servers; likewise, Map-Resolvers are conceptually similar [RFC1035] servers; likewise, Map-Resolvers are conceptually similar
to DNS caching resolvers. With this in mind, this specification to DNS caching resolvers. With this in mind, this specification
borrows familiar terminology (resolver and server) from the DNS borrows familiar terminology (resolver and server) from the DNS
specifications. specifications.
Note that while this document assumes a LISP-ALT database mapping Note this document doesn't assume any particular database mapping
infrastructure to illustrate certain aspects of Map-Server and Map- infrastructure to illustrate certain aspects of Map-Server and Map-
Resolver operation, the Mapping Service interface can (and likely Resolver operation, the Mapping Service interface can (and likely
will) be used by ITRs and ETRs to access other mapping database will) be used by ITRs and ETRs to access other mapping database
systems as the LISP infrastructure evolves. systems as the LISP infrastructure evolves.
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].
skipping to change at page 8, line 27 skipping to change at page 8, line 27
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. Implementations should follow the
procedures from [RFC8085] to determine the maximum size used for any
LISP control message.
The UDP checksum is computed and set to non-zero for all messages The UDP checksum is computed and set to non-zero for all messages
sent to or from port 4342. It MUST be checked on receipt, and if the sent to or from port 4342. It MUST be checked on receipt, and if the
checksum fails, the control message MUST be dropped [RFC1071]. checksum fails, the control message MUST be dropped [RFC1071].
The format of control messages includes the UDP header so the The format of control messages includes the UDP header so the
checksum and length fields can be used to protect and delimit message checksum and length fields can be used to protect and delimit message
boundaries. boundaries.
5.1. LISP Control Packet Type Allocations 5.1. LISP Control Packet Type Allocations
skipping to change at page 11, line 13 skipping to change at page 11, line 13
Request (SMRs) Section 6.1 for details. Request (SMRs) Section 6.1 for details.
p: This is the PITR bit. This bit is set to 1 when a PITR sends a p: This is the PITR bit. This bit is set to 1 when a PITR sends a
Map-Request. Map-Request.
s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is
sending a Map-Request in response to a received SMR-based Map- sending a Map-Request in response to a received SMR-based Map-
Request. Request.
m: This is the LISP mobile-node m-bit. This bit is set by xTRs that m: This is the LISP mobile-node m-bit. This bit is set by xTRs that
operate as a mobile node as defined in [I-D.ietf-lisp-mn]. operate as a mobile node as defined in [I-D.ietf-lisp-mn]. This
bit can be ignored if an implementation does not support
[I-D.ietf-lisp-mn].
I: This is the xTR-ID bit. When this bit is set, what is appended to I: This is the xTR-ID bit. When this bit is set, what is appended to
the Map-Request is a 128-bit xTR router-ID. See LISP PubSub usage the Map-Request is a 128-bit xTR router-ID. See LISP PubSub usage
procedures in [I-D.ietf-lisp-pubsub] for details. procedures in [I-D.ietf-lisp-pubsub] for details. This bit can be
ignored if an implementation does not support
[I-D.ietf-lisp-pubsub].
Rsvd: This field MUST be set to 0 on transmit and MUST be ignored on Rsvd: This field MUST be set to 0 on transmit and MUST be ignored on
receipt. receipt.
L: This is the local-xtr bit. It is used by an xTR in a LISP site to L: This is the local-xtr bit. It is used by an xTR in a LISP site to
tell other xTRs in the same site that it is part of the RLOC-set tell other xTRs in the same site that it is part of the RLOC-set
for the LISP site. The L-bit is set to 1 when the RLOC is the for the LISP site. The L-bit is set to 1 when the RLOC is the
sender's IP address. sender's IP address.
D: This is the dont-map-reply bit. It is used in the SMR procedure D: This is the dont-map-reply bit. It is used in the SMR procedure
skipping to change at page 11, line 48 skipping to change at page 12, line 4
value of 0, there is 1 ITR-RLOC address encoded; for a value of 1, value of 0, there is 1 ITR-RLOC address encoded; for a value of 1,
there are 2 ITR-RLOC addresses encoded, and so on up to 31, which there are 2 ITR-RLOC addresses encoded, and so on up to 31, which
encodes a total of 32 ITR-RLOC addresses. encodes a total of 32 ITR-RLOC addresses.
Record Count: This is the number of records in this Map-Request Record Count: This is the number of records in this Map-Request
message. A record is comprised of the portion of the packet that message. A record is comprised of the portion of the packet that
is labeled 'Rec' above and occurs the number of times equal to is labeled 'Rec' above and occurs the number of times equal to
Record Count. For this version of the protocol, a receiver MUST Record Count. For this version of the protocol, a receiver MUST
accept and process Map-Requests that contain one or more records, accept and process Map-Requests that contain one or more records,
but a sender MUST only send Map-Requests containing one record. but a sender MUST only send Map-Requests containing one record.
Support for requesting multiple EIDs in a single Map-Request
Support for processing multiple EIDs in a single Map-Request
message will be specified in a future version of the protocol. message will be specified in a future version of the protocol.
Nonce: This is an 8-octet random value created by the sender of the Nonce: This is an 8-octet random value created by the sender of the
Map-Request. This nonce will be returned in the Map-Reply. The Map-Request. This nonce will be returned in the Map-Reply. The
security of the LISP mapping protocol critically depends on the security of the LISP mapping protocol critically depends on the
strength of the nonce in the Map-Request message. The nonce strength of the nonce in the Map-Request message. The nonce
SHOULD be generated by a properly seeded pseudo-random (or strong SHOULD be generated by a properly seeded pseudo-random (or strong
random) source. See [RFC4086] for advice on generating security- random) source. See [RFC4086] for advice on generating security-
sensitive random data. sensitive random data.
skipping to change at page 13, line 41 skipping to change at page 13, line 43
Map-Requests can also be LISP encapsulated using UDP destination Map-Requests can also be LISP encapsulated using UDP destination
port 4342 with a LISP Type value set to "Encapsulated Control port 4342 with a LISP Type value set to "Encapsulated Control
Message", when sent from an ITR to a Map-Resolver. Likewise, Map- Message", when sent from an ITR to a Map-Resolver. Likewise, Map-
Requests are LISP encapsulated the same way from a Map-Server to an Requests are LISP encapsulated the same way from a Map-Server to an
ETR. Details on Encapsulated Map-Requests and Map-Resolvers can be ETR. Details on Encapsulated Map-Requests and Map-Resolvers can be
found in Section 5.8. found in Section 5.8.
Map-Requests MUST be rate-limited. It is RECOMMENDED that a Map- Map-Requests MUST be rate-limited. It is RECOMMENDED that a Map-
Request for the same EID-Prefix be sent no more than once per second. Request for the same EID-Prefix be sent no more than once per second.
However, recommendations from [RFC8085] SHOULD be considered.
An ITR that is configured with mapping database information (i.e., it An ITR that is configured with mapping database information (i.e., it
is also an ETR) MAY optionally include those mappings in a Map- is also an ETR) MAY optionally include those mappings in a Map-
Request. When an ETR configured to accept and verify such Request. When an ETR configured to accept and verify such
"piggybacked" mapping data receives such a Map-Request and it does "piggybacked" mapping data receives such a Map-Request and it does
not have this mapping in the Map-Cache, it MAY originate a "verifying not have this mapping in the Map-Cache, it MAY originate a "verifying
Map-Request", addressed to the map-requesting ITR and the ETR MAY add Map-Request", addressed to the map-requesting ITR and the ETR MAY add
a Map-Cache entry. If the ETR has a Map-Cache entry that matches the a Map-Cache entry. If the ETR has a Map-Cache entry that matches the
"piggybacked" EID and the RLOC is in the Locator-Set for the entry, "piggybacked" EID and the RLOC is in the Locator-Set for the entry,
then it MAY send the "verifying Map-Request" directly to the then it MAY send the "verifying Map-Request" directly to the
skipping to change at page 19, line 49 skipping to change at page 19, line 49
When an EID moves out of a LISP site [I-D.ietf-lisp-eid-mobility], When an EID moves out of a LISP site [I-D.ietf-lisp-eid-mobility],
the database mapping system may have overlapping EID-prefixes. Or the database mapping system may have overlapping EID-prefixes. Or
when a LISP site is configured with multiple sets of ETRs that when a LISP site is configured with multiple sets of ETRs that
support different EID-prefix lengths, the database mapping system may support different EID-prefix lengths, the database mapping system may
have overlapping EID-prefixes. When overlapping EID-prefixes exist, have overlapping EID-prefixes. When overlapping EID-prefixes exist,
a Map-Request with an EID that best matches any EID-Prefix MUST be a Map-Request with an EID that best matches any EID-Prefix MUST be
returned in a single Map-Reply message. For instance, if an ETR had returned in a single Map-Reply message. For instance, if an ETR had
database mapping entries for EID-Prefixes: database mapping entries for EID-Prefixes:
10.0.0.0/8 2001:db8::/16
10.1.0.0/16 2001:db8:1::/24
10.1.1.0/24 2001:db8:1:1::/32
10.1.2.0/24 2001:db8:1:2::/32
A Map-Request for EID 10.1.1.1 would cause a Map-Reply with a record A Map-Request for EID 2001:db8:1:1::1 would cause a Map-Reply with a
count of 1 to be returned with a mapping record EID-Prefix of record count of 1 to be returned with a mapping record EID-Prefix of
10.1.1.0/24. 2001:db8:1:1::/32.
A Map-Request for EID 10.1.5.5 would cause a Map-Reply with a record A Map-Request for EID 2001:db8:1:5::5 would cause a Map-Reply with a
count of 3 to be returned with mapping records for EID-Prefixes record count of 3 to be returned with mapping records for EID-
10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24. Prefixes 2001:db8:1::/24, 2001:db8:1:1::/32, 2001:db8:1:2::/32. Note
filling out the /24 with more-specifics that exist in the mapping
system.
Note that not all overlapping EID-Prefixes need to be returned but Note that not all overlapping EID-Prefixes need to be returned but
only the more-specific entries (note that in the second example above only the more-specific entries (note that in the second example above
10.0.0.0/8 was not returned for requesting EID 10.1.5.5) for the 2001:db8::/16 was not returned for requesting EID 2001:db8:1:5::5)
matching EID-Prefix of the requesting EID. When more than one EID- for the matching EID-Prefix of the requesting EID. When more than
Prefix is returned, all SHOULD use the same Time to Live value so one EID-Prefix is returned, all SHOULD use the same Time to Live
they can all time out at the same time. When a more-specific EID- value so they can all time out at the same time. When a more-
Prefix is received later, its Time to Live value in the Map-Reply specific EID-Prefix is received later, its Time to Live value in the
record can be stored even when other less-specific entries exist. Map-Reply record can be stored even when other less-specific entries
When a less-specific EID-Prefix is received later, its Map-Cache exist. When a less-specific EID-Prefix is received later, its Map-
expiration time SHOULD be set to the minimum expiration time of any Cache expiration time SHOULD be set to the minimum expiration time of
more-specific EID-Prefix in the Map-Cache. This is done so the any more-specific EID-Prefix in the Map-Cache. This is done so the
integrity of the EID-Prefix set is wholly maintained and so no more- integrity of the EID-Prefix set is wholly maintained and so no more-
specific entries are removed from the Map-Cache while keeping less- specific entries are removed from the Map-Cache while keeping less-
specific entries. specific entries.
Map-Replies SHOULD be sent for an EID-Prefix no more often than once Map-Replies SHOULD be sent for an EID-Prefix no more often than once
per second to the same requesting router. For scalability, it is per second to the same requesting router. For scalability, it is
expected that aggregation of EID addresses into EID-Prefixes will expected that aggregation of EID addresses into EID-Prefixes will
allow one Map-Reply to satisfy a mapping for the EID addresses in the allow one Map-Reply to satisfy a mapping for the EID addresses in the
prefix range, thereby reducing the number of Map-Request messages. prefix range, thereby reducing the number of Map-Request messages.
skipping to change at page 23, line 30 skipping to change at page 23, line 30
T: This is the use-TTL for timeout bit. When set to 1, the xTR wants T: This is the use-TTL for timeout bit. When set to 1, the xTR wants
the Map-Server to time out registrations based on the value in the the Map-Server to time out registrations based on the value in the
"Record TTL" field of this message. "Record TTL" field of this message.
a: This is the merge-request bit. When set to 1, the xTR requests to a: This is the merge-request bit. When set to 1, the xTR requests to
merge RLOC-records from different xTRs registering the same EID- merge RLOC-records from different xTRs registering the same EID-
record. See signal-free multicast [RFC8378] for one use case record. See signal-free multicast [RFC8378] for one use case
example. example.
m: This is the mobile-node bit. When set to 1, the registering xTR m: This is the mobile-node bit. When set to 1, the registering xTR
supports the procedures in [I-D.ietf-lisp-mn]. supports the procedures in [I-D.ietf-lisp-mn]. This bit can be
ignored if an implementation does not support [I-D.ietf-lisp-mn]
M: This is the want-map-notify bit. When set to 1, an ETR is M: This is the want-map-notify bit. When set to 1, an ETR is
requesting a Map-Notify message to be returned in response to requesting a Map-Notify message to be returned in response to
sending a Map-Register message. The Map-Notify message sent by a sending a Map-Register message. The Map-Notify message sent by a
Map-Server is used to acknowledge receipt of a Map-Register Map-Server is used to acknowledge receipt of a Map-Register
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
skipping to change at page 26, line 5 skipping to change at page 26, line 5
Type: 4/5 (Map-Notify/Map-Notify-Ack) Type: 4/5 (Map-Notify/Map-Notify-Ack)
The Map-Notify message has the same contents as a Map-Register The Map-Notify message has the same contents as a Map-Register
message. See the Map-Register section for field descriptions. message. See the Map-Register section for field descriptions.
The Map-Notify-Ack message has the same contents as a Map-Notify The Map-Notify-Ack message has the same contents as a Map-Notify
message. It is used to acknowledge the receipt of a Map-Notify and message. It is used to acknowledge the receipt of a Map-Notify and
for the sender to stop retransmitting a Map-Notify with the same for the sender to stop retransmitting a Map-Notify with the same
nonce. nonce.
A Map-Server sends an unsolicited Map-Notify message (one that is not
used as an acknowledgment to a Map-Register message) that follows the
Congestion Control And Relability Guideline sections of [RFC8085]. A
Map-Notify is retransmitted until a Map-Notify-Ack is received by the
Map-Server with the same nonce used in the Map-Notify message. If a
Map-Notify-Ack is never received by the Map-Server, it issues a log
message. An implementation SHOULD retransmit up to 3 times at 3
second retransmission intervals, after which time the retransmission
interval is exponentially backed-off for another 3 retransmission
attempts. After this time, an xTR can only get the RLOC-set change
by later querying the mapping system or by RLOC-probing one of the
RLOCs of the existing cached RLOC-set to get the new RLOC-set.
5.8. Encapsulated Control Message Format 5.8. Encapsulated Control Message Format
An Encapsulated Control Message (ECM) is used to encapsulate control An Encapsulated Control Message (ECM) is used to encapsulate control
packets sent between xTRs and the mapping database system. packets sent between xTRs and the mapping database system.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | IPv4 or IPv6 Header | / | IPv4 or IPv6 Header |
OH | (uses RLOC addresses) | OH | (uses RLOC addresses) |
skipping to change at page 29, line 16 skipping to change at page 30, line 16
accept the Map-Request. accept the Map-Request.
3. The remote ITR MUST rate-limit the Map-Request until it gets a 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-Reply while continuing to use the cached mapping. When
Map-Versioning as described in [I-D.ietf-lisp-6834bis] is used, Map-Versioning as described in [I-D.ietf-lisp-6834bis] is used,
an SMR sender can detect if an ITR is using the most up-to-date an SMR sender can detect if an ITR is using the most up-to-date
database mapping. database mapping.
4. The ETRs at the site with the changed mapping will reply to the 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 Map-Request with a Map-Reply message that has a nonce from the
SMR-invoked Map-Request. The Map-Reply messages SHOULD be rate- SMR-invoked Map-Request. The Map-Reply messages MUST be rate-
limited. This is important to avoid Map-Reply implosion. limited according to procedures in [RFC8085]. This is important
to avoid Map-Reply implosion.
5. The ETRs at the site with the changed mapping record the fact 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 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 mapping data in the Map-Cache entry for the remote site so the
Locator-Status-Bits are reflective of the new mapping for packets Locator-Status-Bits are reflective of the new mapping for packets
going to the remote site. The ETR then stops sending SMR going to the remote site. The ETR then stops sending SMR
messages. messages.
For security reasons, an ITR MUST NOT process unsolicited Map- For security reasons, an ITR MUST NOT process unsolicited Map-
Replies. To avoid Map-Cache entry corruption by a third party, a Replies. To avoid Map-Cache entry corruption by a third party, a
skipping to change at page 35, line 35 skipping to change at page 36, line 35
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
mapping system and there is a policy in the Map-Server to have the mapping system and there is a policy in the Map-Server to have the
requestor drop packets for the matching EID-prefix, then a Drop/ requestor drop packets for the matching EID-prefix, then a Drop/
Policy-Denied action is returned. If the EID-prefix is registered or Policy-Denied action is returned. If the EID-prefix is registered or
not registered and there is a authentication failure, then a Drop/ not registered and there is a authentication failure, then a Drop/
Authentication- failure action is returned. If either of these Authentication- failure action is returned. If either of these
actions result as a temporary state in policy or authentication then actions result as a temporary state in policy or authentication then
a Send-Map-Request action with 1-minute TTL MAY be returned to allow a Send-Map-Request action with 1-minute TTL MAY be returned to allow
the reqeustor to retry the Map-Request. the requestor to retry the Map-Request.
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
skipping to change at page 36, line 36 skipping to change at page 37, line 36
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.
8.4.1. Anycast Map-Resolver Operation 8.4.1. Anycast 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 ETRs MAY have anycast RLOC addresses which are registered as part of
addresses, as registrations need to be established between an ETR and their RLOC-set to the mapping system. However, registrations MUST
a specific set of Map-Servers, each identified by a specific use their unique RLOC addresses, xTR-IDs, or distinct authentication
registration association. keys to identify security associations with the Map-Servers.
9. 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
skipping to change at page 37, line 43 skipping to change at page 38, line 43
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:
o A Map-Notify-Ack message is added in this document to provide o A Map-Notify-Ack message is added in this document to provide
reliability for Map-Notify messages. Any receiver of a Map-Notify reliability for Map-Notify messages. Any receiver of a Map-Notify
message must respond with a Map-Notify-Ack message. Map-Servers message must respond with a Map-Notify-Ack message. Map-Servers
who are senders of Map-Notify messages, must queue the Map-Notify who are senders of Map-Notify messages, must queue the Map-Notify
contents until they receive a Map-Notify-Ack with the nonce used contents until they receive a Map-Notify-Ack with the nonce used
in the Map-Notify message. in the Map-Notify message. Note that implementations for Map-
Notify-Ack support already exist and predate this document.
o This document is incorporating the codepoint for the Map-Referral o This document is incorporating the codepoint for the Map-Referral
message from the LISP-DDT specification [RFC8111] to indicate that message from the LISP-DDT specification [RFC8111] to indicate that
a Map-Server must send the final Map-Referral message when it a Map-Server must send the final Map-Referral message when it
participates in the LISP-DDT mapping system procedures. participates in the LISP-DDT mapping system procedures.
o The "m", "I", "L", and "D" bits are added to the Map-Request o The "m", "I", "L", and "D" bits are added to the Map-Request
message. See Section 5.3 for details. message. See Section 5.3 for details.
o The "S", "I", "E", "T", "a", and "m" bits are added to the Map- o The "S", "I", "E", "T", "a", and "m" bits are added to the Map-
skipping to change at page 40, line 35 skipping to change at page 41, line 35
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-02 (work in progress), September 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-16 (work in progress), (LISP)", draft-ietf-lisp-rfc6830bis-18 (work in progress),
August 2018. September 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>.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
384, and HMAC-SHA-512 with IPsec", RFC 4868, 384, and HMAC-SHA-512 with IPsec", RFC 4868,
DOI 10.17487/RFC4868, May 2007, DOI 10.17487/RFC4868, May 2007,
<https://www.rfc-editor.org/info/rfc4868>. <https://www.rfc-editor.org/info/rfc4868>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
12.2. Informative References 12.2. Informative References
[AFI] IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY [AFI] IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY
NUMBERS http://www.iana.org/assignments/address-family- NUMBERS http://www.iana.org/assignments/address-family-
numbers/address-family-numbers.xhtml?, Febuary 2007. numbers/address-family-numbers.xhtml?, Febuary 2007.
[GTP-3GPP] [GTP-3GPP]
3GPP, "General Packet Radio System (GPRS) Tunnelling 3GPP, "General Packet Radio System (GPRS) Tunnelling
Protocol User Plane (GTPv1-U)", TS.29.281 Protocol User Plane (GTPv1-U)", TS.29.281
https://portal.3gpp.org/desktopmodules/Specifications/ https://portal.3gpp.org/desktopmodules/Specifications/
skipping to change at page 45, line 19 skipping to change at page 46, 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-14 B.1. Changes to draft-ietf-lisp-rfc6833bis-15
o Posted mid-September 2018.
o Changes to reflect comments from Colin and Mirja.
B.2. Changes to draft-ietf-lisp-rfc6833bis-14
o Posted September 2018. o Posted September 2018.
o Changes to reflect comments from Genart, RTGarea, and Secdir o Changes to reflect comments from Genart, RTGarea, and Secdir
reviews. reviews.
B.2. Changes to draft-ietf-lisp-rfc6833bis-13 B.3. 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.3. Changes to draft-ietf-lisp-rfc6833bis-12 B.4. 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.4. Changes to draft-ietf-lisp-rfc6833bis-11 B.5. 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.5. Changes to draft-ietf-lisp-rfc6833bis-10 B.6. 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.6. Changes to draft-ietf-lisp-rfc6833bis-09 B.7. 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.7. Changes to draft-ietf-lisp-rfc6833bis-08 B.8. 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.8. Changes to draft-ietf-lisp-rfc6833bis-07 B.9. 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 13 skipping to change at page 48, line 16
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.9. Changes to draft-ietf-lisp-rfc6833bis-06 B.10. 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.10. Changes to draft-ietf-lisp-rfc6833bis-05 B.11. 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.11. Changes to draft-ietf-lisp-rfc6833bis-04 B.12. 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.12. Changes to draft-ietf-lisp-rfc6833bis-03 B.13. 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.13. Changes to draft-ietf-lisp-rfc6833bis-02 B.14. 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.14. Changes to draft-ietf-lisp-rfc6833bis-01 B.15. 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.15. Changes to draft-ietf-lisp-rfc6833bis-00 B.16. 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.16. Changes to draft-farinacci-lisp-rfc6833bis-00 B.17. 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. 41 change blocks. 
101 lines changed or deleted 138 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/