idnits 2.17.1 draft-ietf-lisp-rfc6833bis-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 9 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 4, 2018) is 2245 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) ** Downref: Normative reference to an Experimental RFC: RFC 6831 ** Downref: Normative reference to an Experimental RFC: RFC 6836 ** Downref: Normative reference to an Experimental RFC: RFC 6837 ** Downref: Normative reference to an Experimental RFC: RFC 8060 ** Downref: Normative reference to an Experimental RFC: RFC 8111 ** Obsolete normative reference: RFC 8113 (Obsoleted by RFC 9304) == Outdated reference: A later version (-19) exists of draft-ermagan-lisp-nat-traversal-13 == Outdated reference: A later version (-13) exists of draft-ietf-lisp-eid-mobility-01 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-introduction-13 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-mn-01 == Outdated reference: A later version (-38) exists of draft-ietf-lisp-rfc6830bis-09 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-14 == Outdated reference: A later version (-09) exists of draft-ietf-lisp-signal-free-multicast-08 Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Fuller 3 Internet-Draft D. Farinacci 4 Intended status: Standards Track Cisco Systems 5 Expires: September 5, 2018 A. Cabellos (Ed.) 6 UPC/BarcelonaTech 7 March 4, 2018 9 Locator/ID Separation Protocol (LISP) Control-Plane 10 draft-ietf-lisp-rfc6833bis-08 12 Abstract 14 This document describes the Control-Plane and Mapping Service for the 15 Locator/ID Separation Protocol (LISP), implemented by two new types 16 of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server 17 -- that provides a simplified "front end" for one or more Endpoint ID 18 to Routing Locator mapping databases. 20 By using this control-plane service interface and communicating with 21 Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and 22 Egress Tunnel Routers (ETRs) are not dependent on the details of 23 mapping database systems, which facilitates modularity with different 24 database designs. Since these devices implement the "edge" of the 25 LISP infrastructure, connect directly to LISP-capable Internet end 26 sites, and comprise the bulk of LISP-speaking devices, reducing their 27 implementation and operational complexity should also reduce the 28 overall cost and effort of deploying LISP. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 5, 2018. 47 Copyright Notice 49 Copyright (c) 2018 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 66 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 67 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 5 68 5. LISP IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 7 69 5.1. LISP Control Packet Type Allocations . . . . . . . . . . 9 70 5.2. Map-Request Message Format . . . . . . . . . . . . . . . 10 71 5.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 13 72 5.4. Map-Reply Message Format . . . . . . . . . . . . . . . . 15 73 5.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 19 74 5.6. Map-Register Message Format . . . . . . . . . . . . . . . 22 75 5.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 25 76 5.8. Encapsulated Control Message Format . . . . . . . . . . . 26 77 6. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 28 78 6.1. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 28 79 7. Routing Locator Reachability . . . . . . . . . . . . . . . . 29 80 7.1. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 31 81 8. Interactions with Other LISP Components . . . . . . . . . . . 32 82 8.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 32 83 8.2. EID-Prefix Configuration and ETR Registration . . . . . . 33 84 8.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 35 85 8.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 35 86 8.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . 36 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 88 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 89 10.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 37 90 10.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 37 91 10.3. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 38 92 10.4. LISP Address Type Codes . . . . . . . . . . . . . . . . 38 93 10.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 38 94 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 95 11.1. Normative References . . . . . . . . . . . . . . . . . . 39 96 11.2. Informative References . . . . . . . . . . . . . . . . . 40 97 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 43 98 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 43 99 B.1. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 43 100 B.2. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 43 101 B.3. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 44 102 B.4. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 44 103 B.5. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 44 104 B.6. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 44 105 B.7. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 45 106 B.8. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 45 107 B.9. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 45 108 B.10. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 45 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 111 1. Introduction 113 The Locator/ID Separation Protocol [I-D.ietf-lisp-introduction] and 114 [I-D.ietf-lisp-rfc6830bis] specifies an architecture and mechanism 115 for replacing the addresses currently used by IP with two separate 116 name spaces: Endpoint IDs (EIDs), used within sites; and Routing 117 Locators (RLOCs), used on the transit networks that make up the 118 Internet infrastructure. To achieve this separation, LISP defines 119 protocol mechanisms for mapping from EIDs to RLOCs. In addition, 120 LISP assumes the existence of a database to store and propagate those 121 mappings globally. Several such databases have been proposed; among 122 them are the Content distribution Overlay Network Service for LISP 123 (LISP-CONS) [LISP-CONS], LISP-NERD (a Not-so-novel EID-to-RLOC 124 Database) [RFC6837], LISP Alternative Logical Topology (LISP+ALT) 125 [RFC6836], and LISP Delegated Database Tree (LISP-DDT) [RFC8111]. 127 The LISP Mapping Service defines two new types of LISP-speaking 128 devices: the Map-Resolver, which accepts Map-Requests from an Ingress 129 Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a 130 mapping database; and the Map-Server, which learns authoritative EID- 131 to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes 132 them in a database. 134 This LISP Control-Plane Mapping Service can be used by many different 135 encapsulation-based or translation-based data-planes which include 136 but are not limited to the ones defined in LISP RFC 6830bis 137 [I-D.ietf-lisp-rfc6830bis], LISP-GPE [I-D.lewis-lisp-gpe], VXLAN 138 [RFC7348], and VXLAN-GPE [I-D.quinn-vxlan-gpe]. 140 Conceptually, LISP Map-Servers share some of the same basic 141 configuration and maintenance properties as Domain Name System (DNS) 142 [RFC1035] servers; likewise, Map-Resolvers are conceptually similar 143 to DNS caching resolvers. With this in mind, this specification 144 borrows familiar terminology (resolver and server) from the DNS 145 specifications. 147 Note that while this document assumes a LISP+ALT database mapping 148 infrastructure to illustrate certain aspects of Map-Server and Map- 149 Resolver operation, the Mapping Service interface can (and likely 150 will) be used by ITRs and ETRs to access other mapping database 151 systems as the LISP infrastructure evolves. 153 The LISP Mapping Service is an important component of the LISP 154 toolset. Issues and concerns about the deployment of LISP for 155 Internet traffic are discussed in [I-D.ietf-lisp-rfc6830bis]. 157 2. Requirements Notation 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [RFC2119]. 163 3. Definition of Terms 165 Map-Server: A network infrastructure component that learns of EID- 166 Prefix mapping entries from an ETR, via the registration mechanism 167 described below, or some other authoritative source if one exists. 168 A Map-Server publishes these EID-Prefixes in a mapping database. 170 Map-Request: A LISP Map-Request is a control-plane message to query 171 the mapping system to resolve an EID. A LISP Map-Request can also 172 be sent to an RLOC to test for reachability and to exchange 173 security keys between an encapsulator and a decapsulator. This 174 type of Map-Request is also known as an RLOC-Probe Request. 176 Map-Reply: A LISP Map-Reply is a control-plane message returned in 177 response to a Map-Request sent to the mapping system when 178 resolving an EID. A LISP Map-Reply can also be returned by a 179 decapsulator in response to a Map-Request sent by an encapsulator 180 to test for reachability. This type of Map-Reply is known as a 181 RLOC-Probe Reply. 183 Encapsulated Map-Request: A LISP Map-Request carried within an 184 Encapsulated Control Message (ECM), which has an additional LISP 185 header prepended. Sent to UDP destination port 4342. The "outer" 186 addresses are routable IP addresses, also known as RLOCs. Used by 187 an ITR when sending to a Map-Resolver and by a Map-Server when 188 forwarding a Map-Request to an ETR. 190 Map-Resolver: A network infrastructure component that accepts LISP 191 Encapsulated (ECM) Map-Requests, typically from an ITR, and 192 determines whether or not the destination IP address is part of 193 the EID namespace; if it is not, a Negative Map-Reply is returned. 194 Otherwise, the Map-Resolver finds the appropriate EID-to-RLOC 195 mapping by consulting a mapping database system. 197 Negative Map-Reply: A LISP Map-Reply that contains an empty 198 Locator-Set. Returned in response to a Map-Request if the 199 destination EID does not exist in the mapping database. 200 Typically, this means that the "EID" being requested is an IP 201 address connected to a non-LISP site. 203 Map-Register message: A LISP message sent by an ETR to a Map-Server 204 to register its associated EID-Prefixes. In addition to the set 205 of EID-Prefixes to register, the message includes one or more 206 RLOCs to reach ETR(s). The Map-Server uses these RLOCs when 207 forwarding Map-Requests (re-formatted as Encapsulated Map- 208 Requests). An ETR MAY request that the Map-Server answer Map- 209 Requests on its behalf by setting the "proxy Map-Reply" flag 210 (P-bit) in the message. 212 Map-Notify message: A LISP message sent by a Map-Server to an ETR 213 to confirm that a Map-Register has been received and processed. 214 An ETR requests that a Map-Notify be returned by setting the 215 "want-map-notify" flag (M-bit) in the Map-Register message. 216 Unlike a Map-Reply, a Map-Notify uses UDP port 4342 for both 217 source and destination. Map-Notify messages are also sent to ITRs 218 by Map-Servers when there are RLOC-set changes. 220 For definitions of other terms, notably Ingress Tunnel Router (ITR), 221 Egress Tunnel Router (ETR), and Re-encapsulating Tunnel Router (RTR), 222 refer to the LISP Data-Plane specification 223 [I-D.ietf-lisp-rfc6830bis]. 225 4. Basic Overview 227 A Map-Server is a device that publishes EID-Prefixes in a LISP 228 mapping database on behalf of a set of ETRs. When it receives a Map 229 Request (typically from an ITR), it consults the mapping database to 230 find an ETR that can answer with the set of RLOCs for an EID-Prefix. 231 To publish its EID-Prefixes, an ETR periodically sends Map-Register 232 messages to the Map-Server. A Map-Register message contains a list 233 of EID-Prefixes plus a set of RLOCs that can be used to reach the 234 ETRs. 236 When LISP+ALT is used as the mapping database, a Map-Server connects 237 to the ALT network and acts as a "last-hop" ALT-Router. Intermediate 238 ALT-Routers forward Map-Requests to the Map-Server that advertises a 239 particular EID-Prefix, and the Map-Server forwards them to the owning 240 ETR, which responds with Map-Reply messages. 242 When LISP-DDT [RFC8111] is used as the mapping database, a Map-Server 243 sends the final Map-Referral messages from the Delegated Database 244 Tree. 246 A Map-Resolver receives Encapsulated Map-Requests from its client 247 ITRs and uses a mapping database system to find the appropriate ETR 248 to answer those requests. On a LISP+ALT network, a Map-Resolver acts 249 as a "first-hop" ALT-Router. It has Generic Routing Encapsulation 250 (GRE) tunnels configured to other ALT-Routers and uses BGP to learn 251 paths to ETRs for different prefixes in the LISP+ALT database. The 252 Map-Resolver uses this path information to forward Map-Requests over 253 the ALT to the correct ETRs. On a LISP-DDT network [RFC8111], a Map- 254 Resolver maintains a referral-cache and acts as a "first-hop" DDT- 255 node. The Map-Resolver uses the referral information to forward Map- 256 Requests. 258 Note that while it is conceivable that a Map-Resolver could cache 259 responses to improve performance, issues surrounding cache management 260 will need to be resolved so that doing so will be reliable and 261 practical. As initially deployed, Map-Resolvers will operate only in 262 a non-caching mode, decapsulating and forwarding Encapsulated Map 263 Requests received from ITRs. Any specification of caching 264 functionality is left for future work. 266 Note that a single device can implement the functions of both a Map- 267 Server and a Map-Resolver, and in many cases the functions will be 268 co-located in that way. Also, there can be ALT-only nodes and DDT- 269 only nodes, when LISP+ALT and LISP-DDT are used, respectively, to 270 connect Map-Resolvers and Map-Servers together to make up the Mapping 271 System. 273 Detailed descriptions of the LISP packet types referenced by this 274 document may be found in [I-D.ietf-lisp-rfc6830bis]. 276 5. LISP IPv4 and IPv6 Control-Plane Packet Formats 278 The following UDP packet formats are used by the LISP control plane. 280 0 1 2 3 281 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 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 |Version| IHL |Type of Service| Total Length | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Identification |Flags| Fragment Offset | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Time to Live | Protocol = 17 | Header Checksum | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Source Routing Locator | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Destination Routing Locator | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 / | Source Port | Dest Port | 294 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 \ | UDP Length | UDP Checksum | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | | 298 | LISP Message | 299 | | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 0 1 2 3 303 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 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 |Version| Traffic Class | Flow Label | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Payload Length | Next Header=17| Hop Limit | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | | 310 + + 311 | | 312 + Source Routing Locator + 313 | | 314 + + 315 | | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | | 318 + + 319 | | 320 + Destination Routing Locator + 321 | | 322 + + 323 | | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 / | Source Port | Dest Port | 326 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 \ | UDP Length | UDP Checksum | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | | 330 | LISP Message | 331 | | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 When a UDP Map-Request, Map-Register, or Map-Notify (when used as a 335 notification message) are sent, the UDP source port is chosen by the 336 sender and the destination UDP port number is set to 4342. When a 337 UDP Map-Reply Map-Notify (when used as an acknowledgement to a Map- 338 Register), or Map-Notify-Ack are sent, the source UDP port number is 339 set to 4342 and the destination UDP port number is copied from the 340 source port of either the Map-Request or the invoking data packet. 341 Implementations MUST be prepared to accept packets when either the 342 source port or destination UDP port is set to 4342 due to NATs 343 changing port number values. 345 The 'UDP Length' field will reflect the length of the UDP header and 346 the LISP Message payload. 348 The UDP checksum is computed and set to non-zero for all messages 349 sent to or from port 4342. It MUST be checked on receipt, and if the 350 checksum fails, the control message MUST be dropped. 352 The format of control messages includes the UDP header so the 353 checksum and length fields can be used to protect and delimit message 354 boundaries. 356 5.1. LISP Control Packet Type Allocations 358 This section defines the LISP control message formats and summarizes 359 for IANA the LISP Type codes assigned by this document. For 360 completeness, this document references the LISP Shared Extension 361 Message assigned by [RFC8113]. Message type definitions are: 363 Reserved: 0 b'0000' 364 LISP Map-Request: 1 b'0001' 365 LISP Map-Reply: 2 b'0010' 366 LISP Map-Register: 3 b'0011' 367 LISP Map-Notify: 4 b'0100' 368 LISP Map-Notify-Ack: 5 b'0101' 369 LISP Map-Referral: 6 b'0110' 370 LISP Encapsulated Control Message: 8 b'1000' 371 Not Assigned 9-14 b'1001'- b'1110' 372 LISP Shared Extension Message: 15 b'1111' [RFC8113] 374 Values in the "Not Assigned" range can be assigned according to 375 procedures in [RFC8126]. Documents that request for a new LISP 376 packet type MAY indicate a preferred value in Section 10.4. 378 Protocol designers experimenting with new message formats SHOULD use 379 the LISP Shared Extension Message Type and request a [RFC8113] sub- 380 type assignment. 382 All LISP control-plane messages use Address Family Identifiers (AFI) 383 [AFI] or LISP Canonical Address Format (LCAF) [RFC8060] formats to 384 encode either fixed or variable length addresses. This includes 385 explicit fields in each control message or part of EID-records or 386 RLOC-records in commonly formatted messages. 388 The LISP control-plane describes how other data-planes can encode 389 messages to support the SMR and RLOC-probing procedures of the LISP 390 data-plane defined in [I-D.ietf-lisp-rfc6830bis]. This control-plane 391 specification itself does not offer such functionality and other 392 data-planes can use their own mechanisms that do not rely on the LISP 393 control-plane. 395 5.2. Map-Request Message Format 397 0 1 2 3 398 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 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 |Type=1 |A|M|P|S|p|s|m|I| Rsvd |L|D| IRC | Record Count | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Nonce . . . | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | . . . Nonce | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Source-EID-AFI | Source EID Address ... | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | ... | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | ITR-RLOC-AFI n | ITR-RLOC Address n ... | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 / | Reserved | EID mask-len | EID-Prefix-AFI | 415 Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 \ | EID-Prefix ... | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Map-Reply Record ... | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 Packet field descriptions: 423 Type: 1 (Map-Request) 425 A: This is an authoritative bit, which is set to 0 for UDP-based Map- 426 Requests sent by an ITR. It is set to 1 when an ITR wants the 427 destination site to return the Map-Reply rather than the mapping 428 database system. 430 M: This is the map-data-present bit. When set, it indicates that a 431 Map-Reply Record segment is included in the Map-Request. 433 P: This is the probe-bit, which indicates that a Map-Request SHOULD 434 be treated as a Locator reachability probe. The receiver SHOULD 435 respond with a Map-Reply with the probe-bit set, indicating that 436 the Map-Reply is a Locator reachability probe reply, with the 437 nonce copied from the Map-Request. See RLOC-Probing 438 [I-D.ietf-lisp-rfc6830bis] for more details. 440 S: This is the Solicit-Map-Request (SMR) bit. See Solicit-Map- 441 Request (SMRs) [I-D.ietf-lisp-rfc6830bis] for details. 443 p: This is the PITR bit. This bit is set to 1 when a PITR sends a 444 Map-Request. 446 s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is 447 sending a Map-Request in response to a received SMR-based Map- 448 Request. 450 m: This is the LISP mobile-node m-bit. This bit is set by xTRs that 451 operate as a mobile node as defined in [I-D.ietf-lisp-mn]. 453 I: This is the xTR-ID bit. When this bit is set, what is appended to 454 the Map-Request is a 128-bit xTR router-ID. See LISP PubSub usage 455 procedures in [I-D.rodrigueznatal-lisp-pubsub] for details. 457 Rsvd: This field MUST be set to 0 on transmit and MUST be ignored on 458 receipt. 460 L: This is the local-xtr bit. It is used by an xTR in a LISP site to 461 tell other xTRs in the same site that it is local to the site. 462 That is, that it is part of the RLOC-set for the LISP site. 464 D: This is the dont-map-reply bit. It is used in the SMR procedure 465 described in [I-D.ietf-lisp-rfc6830bis]. When an xTR sends an SMR 466 Map-Request message, it doesn't need a Map-Reply returned. When 467 this bit is set, the receiver of the Map-Request does not return a 468 Map-Reply. 470 IRC: This 5-bit field is the ITR-RLOC Count, which encodes the 471 additional number of ('ITR-RLOC-AFI', 'ITR-RLOC Address') fields 472 present in this message. At least one (ITR-RLOC-AFI, ITR-RLOC- 473 Address) pair MUST be encoded. Multiple 'ITR-RLOC Address' fields 474 are used, so a Map-Replier can select which destination address to 475 use for a Map-Reply. The IRC value ranges from 0 to 31. For a 476 value of 0, there is 1 ITR-RLOC address encoded; for a value of 1, 477 there are 2 ITR-RLOC addresses encoded, and so on up to 31, which 478 encodes a total of 32 ITR-RLOC addresses. 480 Record Count: This is the number of records in this Map-Request 481 message. A record is comprised of the portion of the packet that 482 is labeled 'Rec' above and occurs the number of times equal to 483 Record Count. For this version of the protocol, a receiver MUST 484 accept and process Map-Requests that contain one or more records, 485 but a sender MUST only send Map-Requests containing one record. 486 Support for requesting multiple EIDs in a single Map-Request 487 message will be specified in a future version of the protocol. 489 Nonce: This is an 8-octet random value created by the sender of the 490 Map-Request. This nonce will be returned in the Map-Reply. The 491 security of the LISP mapping protocol critically depends on the 492 strength of the nonce in the Map-Request message. The nonce 493 SHOULD be generated by a properly seeded pseudo-random (or strong 494 random) source. See [RFC4086] for advice on generating security- 495 sensitive random data. 497 Source-EID-AFI: This is the address family of the 'Source EID 498 Address' field. 500 Source EID Address: This is the EID of the source host that 501 originated the packet that caused the Map-Request. When Map- 502 Requests are used for refreshing a Map-Cache entry or for RLOC- 503 Probing, an AFI value 0 is used and this field is of zero length. 505 ITR-RLOC-AFI: This is the address family of the 'ITR-RLOC Address' 506 field that follows this field. 508 ITR-RLOC Address: This is used to give the ETR the option of 509 selecting the destination address from any address family for the 510 Map-Reply message. This address MUST be a routable RLOC address 511 of the sender of the Map-Request message. 513 EID mask-len: This is the mask length for the EID-Prefix. 515 EID-Prefix-AFI: This is the address family of the EID-Prefix 516 according to [AFI] and [RFC8060]. 518 EID-Prefix: This prefix is 4 octets for an IPv4 address family and 519 16 octets for an IPv6 address family when the EID-Prefix-AFI is 1 520 or 2, respectively. For other AFIs [AFI], the length varies and 521 for the LCAF AFI the format is defined in [RFC8060]. When a Map- 522 Request is sent by an ITR because a data packet is received for a 523 destination where there is no mapping entry, the EID-Prefix is set 524 to the destination IP address of the data packet, and the 'EID 525 mask-len' is set to 32 or 128 for IPv4 or IPv6, respectively. 526 When an xTR wants to query a site about the status of a mapping it 527 already has cached, the EID-Prefix used in the Map-Request has the 528 same mask length as the EID-Prefix returned from the site when it 529 sent a Map-Reply message. 531 Map-Reply Record: When the M-bit is set, this field is the size of a 532 single "Record" in the Map-Reply format. This Map-Reply record 533 contains the EID-to-RLOC mapping entry associated with the Source 534 EID. This allows the ETR that will receive this Map-Request to 535 cache the data if it chooses to do so. 537 5.3. EID-to-RLOC UDP Map-Request Message 539 A Map-Request is sent from an ITR when it needs a mapping for an EID, 540 wants to test an RLOC for reachability, or wants to refresh a mapping 541 before TTL expiration. For the initial case, the destination IP 542 address used for the Map-Request is the data packet's destination 543 address (i.e., the destination EID) that had a mapping cache lookup 544 failure. For the latter two cases, the destination IP address used 545 for the Map-Request is one of the RLOC addresses from the Locator-Set 546 of the Map-Cache entry. The source address is either an IPv4 or IPv6 547 RLOC address, depending on whether the Map-Request is using an IPv4 548 or IPv6 header, respectively. In all cases, the UDP source port 549 number for the Map-Request message is a 16-bit value selected by the 550 ITR/PITR, and the UDP destination port number is set to the well- 551 known destination port number 4342. A successful Map-Reply, which is 552 one that has a nonce that matches an outstanding Map-Request nonce, 553 will update the cached set of RLOCs associated with the EID-Prefix 554 range. 556 One or more Map-Request ('ITR-RLOC-AFI', 'ITR-RLOC-Address') fields 557 MUST be filled in by the ITR. The number of fields (minus 1) encoded 558 MUST be placed in the 'IRC' field. The ITR MAY include all locally 559 configured Locators in this list or just provide one locator address 560 from each address family it supports. If the ITR erroneously 561 provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map- 562 Request. 564 Map-Requests can also be LISP encapsulated using UDP destination 565 port 4342 with a LISP Type value set to "Encapsulated Control 566 Message", when sent from an ITR to a Map-Resolver. Likewise, Map- 567 Requests are LISP encapsulated the same way from a Map-Server to an 568 ETR. Details on Encapsulated Map-Requests and Map-Resolvers can be 569 found in Section 5.8. 571 Map-Requests MUST be rate-limited. It is RECOMMENDED that a Map- 572 Request for the same EID-Prefix be sent no more than once per second. 574 An ITR that is configured with mapping database information (i.e., it 575 is also an ETR) MAY optionally include those mappings in a Map- 576 Request. When an ETR configured to accept and verify such 577 "piggybacked" mapping data receives such a Map-Request and it does 578 not have this mapping in the map-cache, it MAY originate a "verifying 579 Map-Request", addressed to the map-requesting ITR and the ETR MAY add 580 a Map-Cache entry. If the ETR has a Map-Cache entry that matches the 581 "piggybacked" EID and the RLOC is in the Locator-Set for the entry, 582 then it MAY send the "verifying Map-Request" directly to the 583 originating Map-Request source. If the RLOC is not in the Locator- 584 Set, then the ETR MUST send the "verifying Map-Request" to the 585 "piggybacked" EID. Doing this forces the "verifying Map-Request" to 586 go through the mapping database system to reach the authoritative 587 source of information about that EID, guarding against RLOC-spoofing 588 in the "piggybacked" mapping data. 590 5.4. Map-Reply Message Format 592 0 1 2 3 593 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 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 |Type=2 |P|E|S| Reserved | Record Count | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Nonce . . . | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | . . . Nonce | 600 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | | Record TTL | 602 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 R | Locator Count | EID mask-len | ACT |A| Reserved | 604 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 c | Rsvd | Map-Version Number | EID-Prefix-AFI | 606 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 r | EID-Prefix | 608 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | /| Priority | Weight | M Priority | M Weight | 610 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | o | Unused Flags |L|p|R| Loc-AFI | 612 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | \| Locator | 614 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 Packet field descriptions: 618 Type: 2 (Map-Reply) 620 P: This is the probe-bit, which indicates that the Map-Reply is in 621 response to a Locator reachability probe Map-Request. The 'Nonce' 622 field MUST contain a copy of the nonce value from the original 623 Map-Request. See RLOC-probing [I-D.ietf-lisp-rfc6830bis] for more 624 details. 626 E: This bit indicates that the ETR that sends this Map-Reply message 627 is advertising that the site is enabled for the Echo-Nonce Locator 628 reachability algorithm. See Echo-Nonce [I-D.ietf-lisp-rfc6830bis] 629 for more details. 631 S: This is the Security bit. When set to 1, the following 632 authentication information will be appended to the end of the Map- 633 Reply. The details of signing a Map-Reply message can be found in 634 [I-D.ietf-lisp-sec]. 636 0 1 2 3 637 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 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | AD Type | Authentication Data Content . . . | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 Reserved: This field MUST be set to 0 on transmit and MUST be 643 ignored on receipt. 645 Record Count: This is the number of records in this reply message. 646 A record is comprised of that portion of the packet labeled 647 'Record' above and occurs the number of times equal to Record 648 Count. 650 Nonce: This is a 24-bit value set in a Data-Probe packet, or a 651 64-bit value from the Map-Request is echoed in this 'Nonce' field 652 of the Map-Reply. When a 24-bit value is supplied, it resides in 653 the low-order 64 bits of the 'Nonce' field. 655 Record TTL: This is the time in minutes the recipient of the Map- 656 Reply will store the mapping. If the TTL is 0, the entry SHOULD 657 be removed from the cache immediately. If the value is 658 0xffffffff, the recipient can decide locally how long to store the 659 mapping. 661 Locator Count: This is the number of Locator entries. A Locator 662 entry comprises what is labeled above as 'Loc'. The Locator count 663 can be 0, indicating that there are no Locators for the EID- 664 Prefix. 666 EID mask-len: This is the mask length for the EID-Prefix. 668 ACT: This 3-bit field describes Negative Map-Reply actions. In any 669 other message type, these bits are set to 0 and ignored on 670 receipt. These bits are used only when the 'Locator Count' field 671 is set to 0. The action bits are encoded only in Map-Reply 672 messages. The actions defined are used by an ITR or PITR when a 673 destination EID matches a negative Map-Cache entry. Unassigned 674 values SHOULD cause a Map-Cache entry to be created, and when 675 packets match this negative cache entry, they will be dropped. 676 The current assigned values are: 678 (0) No-Action: The map-cache is kept alive, and no packet 679 encapsulation occurs. 681 (1) Natively-Forward: The packet is not encapsulated or dropped 682 but natively forwarded. 684 (2) Send-Map-Request: The packet invokes sending a Map-Request. 686 (3) Drop/No-Reason: A packet that matches this map-cache entry is 687 dropped. An ICMP Destination Unreachable message SHOULD be 688 sent. 690 (4) Drop/Policy-Denied: A packet that matches this map-cache 691 entry is dropped. The reason for the Drop action is that a 692 Map-Request for the target-EID is being policy denied by 693 either an xTR or the mapping system. 695 (5) Drop/Authentication-Failure: A packet that matches this map- 696 cache entry is dropped. The reason for the Drop action is 697 that a Map-Request for the target-EID fails an authentication 698 verification-check by either an xTR or the mapping system. 700 A: The Authoritative bit, when sent, is always set to 1 by an ETR. 701 When a Map-Server is proxy Map-Replying for a LISP site, the 702 Authoritative bit is set to 0. This indicates to requesting ITRs 703 that the Map-Reply was not originated by a LISP node managed at 704 the site that owns the EID-Prefix. 706 Map-Version Number: When this 12-bit value is non-zero, the Map- 707 Reply sender is informing the ITR what the version number is for 708 the EID record contained in the Map-Reply. The ETR can allocate 709 this number internally but MUST coordinate this value with other 710 ETRs for the site. When this value is 0, there is no versioning 711 information conveyed. The Map-Version Number can be included in 712 Map-Request and Map-Register messages. See Map-Versioning 713 [I-D.ietf-lisp-rfc6830bis] for more details. 715 EID-Prefix-AFI: Address family of the EID-Prefix according to [AFI] 716 and [RFC8060]. 718 EID-Prefix: This prefix is 4 octets for an IPv4 address family and 719 16 octets for an IPv6 address family. 721 Priority: Each RLOC is assigned a unicast Priority. Lower values 722 are more preferable. When multiple RLOCs have the same Priority, 723 they MAY be used in a load-split fashion. A value of 255 means 724 the RLOC MUST NOT be used for unicast forwarding. 726 Weight: When priorities are the same for multiple RLOCs, the Weight 727 indicates how to balance unicast traffic between them. Weight is 728 encoded as a relative weight of total unicast packets that match 729 the mapping entry. For example, if there are 4 Locators in a 730 Locator-Set, where the Weights assigned are 30, 20, 20, and 10, 731 the first Locator will get 37.5% of the traffic, the 2nd and 3rd 732 Locators will get 25% of the traffic, and the 4th Locator will get 733 12.5% of the traffic. If all Weights for a Locator-Set are equal, 734 the receiver of the Map-Reply will decide how to load-split the 735 traffic. See RLOC-hashing [I-D.ietf-lisp-rfc6830bis] for a 736 suggested hash algorithm to distribute the load across Locators 737 with the same Priority and equal Weight values. 739 M Priority: Each RLOC is assigned a multicast Priority used by an 740 ETR in a receiver multicast site to select an ITR in a source 741 multicast site for building multicast distribution trees. A value 742 of 255 means the RLOC MUST NOT be used for joining a multicast 743 distribution tree. For more details, see [RFC6831]. 745 M Weight: When priorities are the same for multiple RLOCs, the 746 Weight indicates how to balance building multicast distribution 747 trees across multiple ITRs. The Weight is encoded as a relative 748 weight (similar to the unicast Weights) of the total number of 749 trees built to the source site identified by the EID-Prefix. If 750 all Weights for a Locator-Set are equal, the receiver of the Map- 751 Reply will decide how to distribute multicast state across ITRs. 752 For more details, see [RFC6831]. 754 Unused Flags: These are set to 0 when sending and ignored on 755 receipt. 757 L: When this bit is set, the Locator is flagged as a local Locator to 758 the ETR that is sending the Map-Reply. When a Map-Server is doing 759 proxy Map-Replying for a LISP site, the L-bit is set to 0 for all 760 Locators in this Locator-Set. 762 p: When this bit is set, an ETR informs the RLOC-Probing ITR that the 763 locator address for which this bit is set is the one being RLOC- 764 probed and MAY be different from the source address of the Map- 765 Reply. An ITR that RLOC-probes a particular Locator MUST use this 766 Locator for retrieving the data structure used to store the fact 767 that the Locator is reachable. The p-bit is set for a single 768 Locator in the same Locator-Set. If an implementation sets more 769 than one p-bit erroneously, the receiver of the Map-Reply MUST 770 select the first Locator. The p-bit MUST NOT be set for Locator- 771 Set records sent in Map-Request and Map-Register messages. 773 R: This is set when the sender of a Map-Reply has a route to the 774 Locator in the Locator data record. This receiver MAY find this 775 useful to know if the Locator is up but not necessarily reachable 776 from the receiver's point of view. See also EID-Reachability 777 [I-D.ietf-lisp-rfc6830bis] for another way the R-bit MAY be used. 779 Locator: This is an IPv4 or IPv6 address (as encoded by the 'Loc- 780 AFI' field) assigned to an ETR. Note that the destination RLOC 781 address MAY be an anycast address. A source RLOC can be an 782 anycast address as well. The source or destination RLOC MUST NOT 783 be the broadcast address (255.255.255.255 or any subnet broadcast 784 address known to the router) and MUST NOT be a link-local 785 multicast address. The source RLOC MUST NOT be a multicast 786 address. The destination RLOC SHOULD be a multicast address if it 787 is being mapped from a multicast destination EID. 789 5.5. EID-to-RLOC UDP Map-Reply Message 791 A Map-Reply returns an EID-Prefix with a prefix length that is less 792 than or equal to the EID being requested. The EID being requested is 793 either from the destination field of an IP header of a Data-Probe or 794 the EID record of a Map-Request. The RLOCs in the Map-Reply are 795 routable IP addresses of all ETRs for the LISP site. Each RLOC 796 conveys status reachability but does not convey path reachability 797 from a requester's perspective. Separate testing of path 798 reachability is required. See RLOC-reachability 799 [I-D.ietf-lisp-rfc6830bis] for details. 801 Note that a Map-Reply MAY contain different EID-Prefix granularity 802 (prefix + length) than the Map-Request that triggers it. This might 803 occur if a Map-Request were for a prefix that had been returned by an 804 earlier Map-Reply. In such a case, the requester updates its cache 805 with the new prefix information and granularity. For example, a 806 requester with two cached EID-Prefixes that are covered by a Map- 807 Reply containing one less-specific prefix replaces the entry with the 808 less-specific EID-Prefix. Note that the reverse, replacement of one 809 less-specific prefix with multiple more-specific prefixes, can also 810 occur, not by removing the less-specific prefix but rather by adding 811 the more-specific prefixes that, during a lookup, will override the 812 less-specific prefix. 814 When an EID moves out of a LISP site [I-D.ietf-lisp-eid-mobility], 815 the database mapping system may have overlapping EID-prefixes. Or 816 when a LISP site is configured with multiple sets of ETRs that 817 support different EID-prefix lengths, the database mapping system may 818 have overlapping EID-prefixes. When overlapping EID-prefixes exist, 819 a Map-Request with an EID that best matches any EID-Prefix MUST be 820 returned in a single Map-Reply message. For instance, if an ETR had 821 database mapping entries for EID-Prefixes: 823 10.0.0.0/8 824 10.1.0.0/16 825 10.1.1.0/24 826 10.1.2.0/24 828 A Map-Request for EID 10.1.1.1 would cause a Map-Reply with a record 829 count of 1 to be returned with a mapping record EID-Prefix of 830 10.1.1.0/24. 832 A Map-Request for EID 10.1.5.5 would cause a Map-Reply with a record 833 count of 3 to be returned with mapping records for EID-Prefixes 834 10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24. 836 Note that not all overlapping EID-Prefixes need to be returned but 837 only the more-specific entries (note that in the second example above 838 10.0.0.0/8 was not returned for requesting EID 10.1.5.5) for the 839 matching EID-Prefix of the requesting EID. When more than one EID- 840 Prefix is returned, all SHOULD use the same Time to Live value so 841 they can all time out at the same time. When a more-specific EID- 842 Prefix is received later, its Time to Live value in the Map-Reply 843 record can be stored even when other less-specific entries exist. 844 When a less-specific EID-Prefix is received later, its map-cache 845 expiration time SHOULD be set to the minimum expiration time of any 846 more-specific EID-Prefix in the map-cache. This is done so the 847 integrity of the EID-Prefix set is wholly maintained and so no more- 848 specific entries are removed from the map-cache while keeping less- 849 specific entries. 851 Map-Replies SHOULD be sent for an EID-Prefix no more often than once 852 per second to the same requesting router. For scalability, it is 853 expected that aggregation of EID addresses into EID-Prefixes will 854 allow one Map-Reply to satisfy a mapping for the EID addresses in the 855 prefix range, thereby reducing the number of Map-Request messages. 857 Map-Reply records can have an empty Locator-Set. A Negative Map- 858 Reply is a Map-Reply with an empty Locator-Set. Negative Map-Replies 859 convey special actions by the sender to the ITR or PITR that have 860 solicited the Map-Reply. There are two primary applications for 861 Negative Map-Replies. The first is for a Map-Resolver to instruct an 862 ITR or PITR when a destination is for a LISP site versus a non-LISP 863 site, and the other is to source quench Map-Requests that are sent 864 for non-allocated EIDs. 866 For each Map-Reply record, the list of Locators in a Locator-Set MUST 867 appear in the same order for each ETR that originates a Map-Reply 868 message. The Locator-Set MUST be sorted in order of ascending IP 869 address where an IPv4 locator address is considered numerically 'less 870 than' an IPv6 locator address. 872 When sending a Map-Reply message, the destination address is copied 873 from one of the 'ITR-RLOC' fields from the Map-Request. The ETR can 874 choose a locator address from one of the address families it 875 supports. For Data-Probes, the destination address of the Map-Reply 876 is copied from the source address of the Data-Probe message that is 877 invoking the reply. The source address of the Map-Reply is one of 878 the local IP addresses chosen to allow Unicast Reverse Path 879 Forwarding (uRPF) checks to succeed in the upstream service provider. 880 The destination port of a Map-Reply message is copied from the source 881 port of the Map-Request or Data-Probe, and the source port of the 882 Map-Reply message is set to the well-known UDP port 4342. 884 5.6. Map-Register Message Format 886 This section specifies the encoding format for the Map-Register 887 message. The message is sent in UDP with a destination UDP port of 888 4342 and a randomly selected UDP source port number. 890 The Map-Register message format is: 892 0 1 2 3 893 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 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 |Type=3 |P|S|I| Reserved |E|T|a|m|M| Record Count | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | Nonce . . . | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | . . . Nonce | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 | Key ID | Algorithm ID | Authentication Data Length | 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 ~ Authentication Data ~ 904 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | | Record TTL | 906 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 R | Locator Count | EID mask-len | ACT |A| Reserved | 908 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 c | Rsvd | Map-Version Number | EID-Prefix-AFI | 910 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 r | EID-Prefix | 912 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | /| Priority | Weight | M Priority | M Weight | 914 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | o | Unused Flags |L|p|R| Loc-AFI | 916 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | \| Locator | 918 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 Packet field descriptions: 922 Type: 3 (Map-Register) 924 P: This is the proxy Map-Reply bit. When set to 1, an ETR sends a 925 Map-Register message requesting the Map-Server to proxy a Map- 926 Reply. The Map-Server will send non-authoritative Map-Replies on 927 behalf of the ETR. 929 S: This is the security-capable bit. When set, the procedures from 930 [I-D.ietf-lisp-sec] are supported. 932 I: This is the xTR-ID bit. When this bit is set, what is appended to 933 the Map-Register is a 128-bit xTR router-ID and then a 64-bit 934 site-ID. See LISP NAT-Traversal procedures in 935 [I-D.ermagan-lisp-nat-traversal] for details. 937 Reserved: This field MUST be set to 0 on transmit and MUST be 938 ignored on receipt. 940 E: This is the Map-Register EID-notify bit. This is used by a First- 941 Hop-Router (FHR) which discovers a dynamic-EID. This EID-notify 942 based Map-Register is sent by the FHR to the same site xTR that 943 propogates the Map-Register to the mapping system. The site xTR 944 keeps state to later Map-Notify the FHR after the EID has moves 945 away. See [I-D.ietf-lisp-eid-mobility] for a detailed use-case. 947 T: This is the use-TTL for timeout bit. When set to 1, the xTR wants 948 the Map-Server to time out registrations based on the value in the 949 "Record TTL" field of this message. 951 a: This is the merge-request bit. When set to 1, the xTR requests to 952 merge RLOC-records from different xTRs registering the same EID- 953 record. See signal-free multicast 954 [I-D.ietf-lisp-signal-free-multicast] for one use case example. 956 m: This is the mobile-node bit. When set to 1, the registering xTR 957 supports the procedures in [I-D.ietf-lisp-mn]. 959 M: This is the want-map-notify bit. When set to 1, an ETR is 960 requesting a Map-Notify message to be returned in response to 961 sending a Map-Register message. The Map-Notify message sent by a 962 Map-Server is used to acknowledge receipt of a Map-Register 963 message. 965 Record Count: This is the number of records in this Map-Register 966 message. A record is comprised of that portion of the packet 967 labeled 'Record' above and occurs the number of times equal to 968 Record Count. 970 Nonce: This 8-octet 'Nonce' field is set to 0 in Map-Register 971 messages if no Map-Notify message is expected to acknowledge it. 972 Since the Map-Register message is authenticated, the 'Nonce' field 973 is not currently used for any security function but MAY be in the 974 future as part of an anti-replay solution. 976 Key ID: This is a configured key-id value that corresponds to a 977 shared-secret password that is used to authenticate the sender. 978 Multiple shared-secrets can be used to roll over keys in a non- 979 disruptive way. 981 Algorithm ID: This is the configured Message Authentication Code 982 (MAC) algorithm value used for the authentication function. See 983 Algorithm ID Numbers in the Section 10.4 for codepoint 984 assignments. 986 Authentication Data Length: This is the length in octets of the 987 'Authentication Data' field that follows this field. The length 988 of the 'Authentication Data' field is dependent on the MAC 989 algorithm used. The length field allows a device that doesn't 990 know the MAC algorithm to correctly parse the packet. 992 Authentication Data: This is the message digest used from the output 993 of the MAC algorithm. The entire Map-Register payload is 994 authenticated with this field preset to 0. After the MAC is 995 computed, it is placed in this field. Implementations of this 996 specification MUST include support for HMAC-SHA-1-96 [RFC2404], 997 and support for HMAC-SHA-256-128 [RFC4868] is RECOMMENDED. 999 The definition of the rest of the Map-Register can be found in 1000 Section 5.4. 1002 5.7. Map-Notify/Map-Notify-Ack Message Format 1004 This section specifies the encoding format for the Map-Notify and 1005 Map-Notify-Ack messages. The messages are sent inside a UDP packet 1006 with source and destination UDP ports equal to 4342. 1008 The Map-Notify and Map-Notify-Ack message formats are: 1010 0 1 2 3 1011 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 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 |Type=4/5| Reserved | Record Count | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | Nonce . . . | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | . . . Nonce | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | Key ID | Algorithm ID | Authentication Data Length | 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 ~ Authentication Data ~ 1022 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 | | Record TTL | 1024 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 R | Locator Count | EID mask-len | ACT |A| Reserved | 1026 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 c | Rsvd | Map-Version Number | EID-Prefix-AFI | 1028 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 r | EID-Prefix | 1030 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 | /| Priority | Weight | M Priority | M Weight | 1032 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 | o | Unused Flags |L|p|R| Loc-AFI | 1034 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 | \| Locator | 1036 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 Packet field descriptions: 1040 Type: 4/5 (Map-Notify/Map-Notify-Ack) 1042 The Map-Notify message has the same contents as a Map-Register 1043 message. See the Map-Register section for field descriptions. 1045 The Map-Notify-Ack message has the same contents as a Map-Notify 1046 message. It is used to acknowledge the receipt of a Map-Notify and 1047 for the sender to stop retransmitting a Map-Notify with the same 1048 nonce. 1050 5.8. Encapsulated Control Message Format 1052 An Encapsulated Control Message (ECM) is used to encapsulate control 1053 packets sent between xTRs and the mapping database system. 1055 0 1 2 3 1056 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 1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 / | IPv4 or IPv6 Header | 1059 OH | (uses RLOC addresses) | 1060 \ | | 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 / | Source Port = xxxx | Dest Port = 4342 | 1063 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 \ | UDP Length | UDP Checksum | 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 LH |Type=8 |S|D|E|M| Reserved | 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 / | IPv4 or IPv6 Header | 1069 IH | (uses RLOC or EID addresses) | 1070 \ | | 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 / | Source Port = xxxx | Dest Port = yyyy | 1073 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 \ | UDP Length | UDP Checksum | 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 LCM | LISP Control Message | 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 Packet header descriptions: 1081 OH: The outer IPv4 or IPv6 header, which uses RLOC addresses in the 1082 source and destination header address fields. 1084 UDP: The outer UDP header with destination port 4342. The source 1085 port is randomly allocated. The checksum field MUST be non- 1086 zero. 1088 LH: Type 8 is defined to be a "LISP Encapsulated Control Message", 1089 and what follows is either an IPv4 or IPv6 header as encoded by 1090 the first 4 bits after the 'Reserved' field. 1092 Type: 8 (Encapsulated Control Message (ECM)) 1094 S: This is the Security bit. When set to 1, the procedures from 1095 [I-D.ietf-lisp-sec] are followed. 1097 D: This is the DDT-bit. When set to 1, the sender is requesting a 1098 Map-Referral message to be returned. The details of this 1099 procedure are described in [RFC8111]. 1101 E: This is the to-ETR bit. When set to 1, the Map-Server's 1102 intention is to forward the ECM to an authoritative ETR. 1104 M: This is the to-MS bit. When set to 1, a Map-Request is being 1105 sent to a co-located Map-Resolver and Map-Server where the 1106 message can be processed directly by the Map-Server versus the 1107 Map-Resolver using the LISP-DDT procedures in [RFC8111]. 1109 0 1 2 3 1110 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 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 | AD Type | Authentication Data Content . . . | 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 IH: The inner IPv4 or IPv6 header, which can use either RLOC or EID 1116 addresses in the header address fields. When a Map-Request is 1117 encapsulated in this packet format, the destination address in 1118 this header is an EID. 1120 UDP: The inner UDP header, where the port assignments depend on the 1121 control packet being encapsulated. When the control packet is 1122 a Map-Request or Map-Register, the source port is selected by 1123 the ITR/PITR and the destination port is 4342. When the 1124 control packet is a Map-Reply, the source port is 4342 and the 1125 destination port is assigned from the source port of the 1126 invoking Map-Request. Port number 4341 MUST NOT be assigned to 1127 either port. The checksum field MUST be non-zero. 1129 LCM: The format is one of the control message formats described in 1130 this section. At this time, only Map-Request messages are 1131 allowed to be control-plane (ECM) encapsulated. In the future, 1132 PIM Join/Prune messages [RFC6831] might be allowed. 1133 Encapsulating other types of LISP control messages is for 1134 further study. When Map-Requests are sent for RLOC-Probing 1135 purposes (i.e., the probe-bit is set), they MUST NOT be sent 1136 inside Encapsulated Control Messages. 1138 6. Changing the Contents of EID-to-RLOC Mappings 1140 In the LISP architecture ITRs/PITRs use a local map-cache to store 1141 EID-to-RLOC mappings for forwarding. When an ETR updates a mapping a 1142 mechanism is required to inform ITRs/PITRs that are using such 1143 mappings. 1145 The LISP data-plane defines several mechanism to update mappings 1146 [I-D.ietf-lisp-rfc6830bis]. This document specifies the Solicit-Map 1147 Request (SMR), a control-plane push-based mechanism. An additional 1148 control-plane mechanism based on the Publish/subscribe paradigm is 1149 specified in [I-D.rodrigueznatal-lisp-pubsub]. 1151 6.1. Solicit-Map-Request (SMR) 1153 Soliciting a Map-Request is a selective way for ETRs, at the site 1154 where mappings change, to control the rate they receive requests for 1155 Map-Reply messages. SMRs are also used to tell remote ITRs to update 1156 the mappings they have cached. 1158 Since the ETRs don't keep track of remote ITRs that have cached their 1159 mappings, they do not know which ITRs need to have their mappings 1160 updated. As a result, an ETR will solicit Map-Requests (called an 1161 SMR message) from those sites to which it has been sending 1162 encapsulated data for the last minute. In particular, an ETR will 1163 send an SMR to an ITR to which it has recently sent encapsulated 1164 data. This can only occur when both ITR and ETR functionality reside 1165 in the same router. 1167 An SMR message is simply a bit set in a Map-Request message. An ITR 1168 or PITR will send a Map-Request when they receive an SMR message. 1169 Both the SMR sender and the Map-Request responder MUST rate-limit 1170 these messages. Rate-limiting can be implemented as a global rate- 1171 limiter or one rate-limiter per SMR destination. 1173 The following procedure shows how an SMR exchange occurs when a site 1174 is doing Locator-Set compaction for an EID-to-RLOC mapping: 1176 1. When the database mappings in an ETR change, the ETRs at the site 1177 begin to send Map-Requests with the SMR bit set for each Locator 1178 in each Map-Cache entry the ETR caches. 1180 2. A remote ITR that receives the SMR message will schedule sending 1181 a Map-Request message to the source locator address of the SMR 1182 message or to the mapping database system. A newly allocated 1183 random nonce is selected, and the EID-Prefix used is the one 1184 copied from the SMR message. If the source Locator is the only 1185 Locator in the cached Locator-Set, the remote ITR SHOULD send a 1186 Map-Request to the database mapping system just in case the 1187 single Locator has changed and may no longer be reachable to 1188 accept the Map-Request. 1190 3. The remote ITR MUST rate-limit the Map-Request until it gets a 1191 Map-Reply while continuing to use the cached mapping. When 1192 Map-Versioning as described in [I-D.ietf-lisp-rfc6830bis] is 1193 used, an SMR sender can detect if an ITR is using the most up-to- 1194 date database mapping. 1196 4. The ETRs at the site with the changed mapping will reply to the 1197 Map-Request with a Map-Reply message that has a nonce from the 1198 SMR-invoked Map-Request. The Map-Reply messages SHOULD be rate- 1199 limited. This is important to avoid Map-Reply implosion. 1201 5. The ETRs at the site with the changed mapping record the fact 1202 that the site that sent the Map-Request has received the new 1203 mapping data in the Map-Cache entry for the remote site so the 1204 Locator-Status-Bits are reflective of the new mapping for packets 1205 going to the remote site. The ETR then stops sending SMR 1206 messages. 1208 For security reasons, an ITR MUST NOT process unsolicited Map- 1209 Replies. To avoid Map-Cache entry corruption by a third party, a 1210 sender of an SMR-based Map-Request MUST be verified. If an ITR 1211 receives an SMR-based Map-Request and the source is not in the 1212 Locator-Set for the stored Map-Cache entry, then the responding Map- 1213 Request MUST be sent with an EID destination to the mapping database 1214 system. Since the mapping database system is a more secure way to 1215 reach an authoritative ETR, it will deliver the Map-Request to the 1216 authoritative source of the mapping data. 1218 When an ITR receives an SMR-based Map-Request for which it does not 1219 have a cached mapping for the EID in the SMR message, it may not send 1220 an SMR-invoked Map-Request. This scenario can occur when an ETR 1221 sends SMR messages to all Locators in the Locator-Set it has stored 1222 in its map-cache but the remote ITRs that receive the SMR may not be 1223 sending packets to the site. There is no point in updating the ITRs 1224 until they need to send, in which case they will send Map-Requests to 1225 obtain a Map-Cache entry. 1227 7. Routing Locator Reachability 1229 This document defines several control-plane mechanisms for 1230 determining RLOC reachability. Please note that additional data- 1231 plane reachability mechanisms are defined in 1232 [I-D.ietf-lisp-rfc6830bis]. 1234 1. An ITR MAY receive an ICMP Network Unreachable or Host 1235 Unreachable message for an RLOC it is using. This indicates that 1236 the RLOC is likely down. Note that trusting ICMP messages may 1237 not be desirable, but neither is ignoring them completely. 1238 Implementations are encouraged to follow current best practices 1239 in treating these conditions [I-D.ietf-opsec-icmp-filtering]. 1241 2. When an ITR participates in the routing protocol that operates in 1242 the underlay routing system, it can determine that an RLOC is 1243 down when no Routing Information Base (RIB) entry exists that 1244 matches the RLOC IP address. 1246 3. An ITR MAY receive an ICMP Port Unreachable message from a 1247 destination host. This occurs if an ITR attempts to use 1248 interworking [RFC6832] and LISP-encapsulated data is sent to a 1249 non-LISP-capable site. 1251 4. An ITR MAY receive a Map-Reply from an ETR in response to a 1252 previously sent Map-Request. The RLOC source of the Map-Reply is 1253 likely up, since the ETR was able to send the Map-Reply to the 1254 ITR. 1256 5. An ITR/ETR pair can use the 'RLOC-Probing' mechanism described 1257 below. 1259 When ITRs receive ICMP Network Unreachable or Host Unreachable 1260 messages as a method to determine unreachability, they will refrain 1261 from using Locators that are described in Locator lists of Map- 1262 Replies. However, using this approach is unreliable because many 1263 network operators turn off generation of ICMP Destination Unreachable 1264 messages. 1266 If an ITR does receive an ICMP Network Unreachable or Host 1267 Unreachable message, it MAY originate its own ICMP Destination 1268 Unreachable message destined for the host that originated the data 1269 packet the ITR encapsulated. 1271 Also, BGP-enabled ITRs can unilaterally examine the RIB to see if a 1272 locator address from a Locator-Set in a mapping entry matches a 1273 prefix. If it does not find one and BGP is running in the Default- 1274 Free Zone (DFZ), it can decide to not use the Locator even though the 1275 Locator-Status-Bits indicate that the Locator is up. In this case, 1276 the path from the ITR to the ETR that is assigned the Locator is not 1277 available. More details are in [I-D.meyer-loc-id-implications]. 1279 Optionally, an ITR can send a Map-Request to a Locator, and if a Map- 1280 Reply is returned, reachability of the Locator has been determined. 1281 Obviously, sending such probes increases the number of control 1282 messages originated by Tunnel Routers for active flows, so Locators 1283 are assumed to be reachable when they are advertised. 1285 This assumption does create a dependency: Locator unreachability is 1286 detected by the receipt of ICMP Host Unreachable messages. When a 1287 Locator has been determined to be unreachable, it is not used for 1288 active traffic; this is the same as if it were listed in a Map-Reply 1289 with Priority 255. 1291 The ITR can test the reachability of the unreachable Locator by 1292 sending periodic Requests. Both Requests and Replies MUST be rate- 1293 limited. Locator reachability testing is never done with data 1294 packets, since that increases the risk of packet loss for end-to-end 1295 sessions. 1297 7.1. RLOC-Probing Algorithm 1299 RLOC-Probing is a method that an ITR or PITR can use to determine the 1300 reachability status of one or more Locators that it has cached in a 1301 Map-Cache entry. The probe-bit of the Map-Request and Map-Reply 1302 messages is used for RLOC-Probing. 1304 RLOC-Probing is done in the control plane on a timer basis, where an 1305 ITR or PITR will originate a Map-Request destined to a locator 1306 address from one of its own locator addresses. A Map-Request used as 1307 an RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or to 1308 the mapping database system as one would when soliciting mapping 1309 data. The EID record encoded in the Map-Request is the EID-Prefix of 1310 the Map-Cache entry cached by the ITR or PITR. The ITR MAY include a 1311 mapping data record for its own database mapping information that 1312 contains the local EID-Prefixes and RLOCs for its site. RLOC-probes 1313 are sent periodically using a jittered timer interval. 1315 When an ETR receives a Map-Request message with the probe-bit set, it 1316 returns a Map-Reply with the probe-bit set. The source address of 1317 the Map-Reply is set according to the procedure described in 1318 [I-D.ietf-lisp-rfc6830bis]. The Map-Reply SHOULD contain mapping 1319 data for the EID-Prefix contained in the Map-Request. This provides 1320 the opportunity for the ITR or PITR that sent the RLOC-probe to get 1321 mapping updates if there were changes to the ETR's database mapping 1322 entries. 1324 There are advantages and disadvantages of RLOC-Probing. The greatest 1325 benefit of RLOC-Probing is that it can handle many failure scenarios 1326 allowing the ITR to determine when the path to a specific Locator is 1327 reachable or has become unreachable, thus providing a robust 1328 mechanism for switching to using another Locator from the cached 1329 Locator. RLOC-Probing can also provide rough Round-Trip Time (RTT) 1330 estimates between a pair of Locators, which can be useful for network 1331 management purposes as well as for selecting low delay paths. The 1332 major disadvantage of RLOC-Probing is in the number of control 1333 messages required and the amount of bandwidth used to obtain those 1334 benefits, especially if the requirement for failure detection times 1335 is very small. 1337 8. Interactions with Other LISP Components 1339 8.1. ITR EID-to-RLOC Mapping Resolution 1341 An ITR is configured with one or more Map-Resolver addresses. These 1342 addresses are "Locators" (or RLOCs) and MUST be routable on the 1343 underlying core network; they MUST NOT need to be resolved through 1344 LISP EID-to-RLOC mapping, as that would introduce a circular 1345 dependency. When using a Map-Resolver, an ITR does not need to 1346 connect to any other database mapping system. In particular, the ITR 1347 need not connect to the LISP+ALT infrastructure or implement the BGP 1348 and GRE protocols that it uses. 1350 An ITR sends an Encapsulated Map-Request to a configured Map-Resolver 1351 when it needs an EID-to-RLOC mapping that is not found in its local 1352 map-cache. Using the Map-Resolver greatly reduces both the 1353 complexity of the ITR implementation and the costs associated with 1354 its operation. 1356 In response to an Encapsulated Map-Request, the ITR can expect one of 1357 the following: 1359 o An immediate Negative Map-Reply (with action code of "Natively- 1360 Forward", 15-minute Time to Live (TTL)) from the Map-Resolver if 1361 the Map-Resolver can determine that the requested EID does not 1362 exist. The ITR saves the EID-Prefix returned in the Map-Reply in 1363 its cache, marks it as non-LISP-capable, and knows not to attempt 1364 LISP encapsulation for destinations matching it. 1366 o A Negative Map-Reply, with action code of "Natively-Forward", from 1367 a Map-Server that is authoritative for an EID-Prefix that matches 1368 the requested EID but that does not have an actively registered, 1369 more-specific ID-prefix. In this case, the requested EID is said 1370 to match a "hole" in the authoritative EID-Prefix. If the 1371 requested EID matches a more-specific EID-Prefix that has been 1372 delegated by the Map-Server but for which no ETRs are currently 1373 registered, a 1-minute TTL is returned. If the requested EID 1374 matches a non-delegated part of the authoritative EID-Prefix, then 1375 it is not a LISP EID and a 15-minute TTL is returned. See 1376 Section 8.2 for discussion of aggregate EID-Prefixes and details 1377 of Map-Server EID-Prefix matching. 1379 o A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or 1380 possibly from a Map-Server answering on behalf of the ETR. See 1381 Section 8.4 for more details on Map-Resolver message processing. 1383 Note that an ITR MAY be configured to both use a Map-Resolver and to 1384 participate in a LISP+ALT logical network. In such a situation, the 1385 ITR SHOULD send Map-Requests through the ALT network for any EID- 1386 Prefix learned via ALT BGP. Such a configuration is expected to be 1387 very rare, since there is little benefit to using a Map-Resolver if 1388 an ITR is already using LISP+ALT. There would be, for example, no 1389 need for such an ITR to send a Map-Request to a possibly non-existent 1390 EID (and rely on Negative Map-Replies) if it can consult the ALT 1391 database to verify that an EID-Prefix is present before sending that 1392 Map-Request. 1394 8.2. EID-Prefix Configuration and ETR Registration 1396 An ETR publishes its EID-Prefixes on a Map-Server by sending LISP 1397 Map-Register messages. A Map-Register message includes 1398 authentication data, so prior to sending a Map-Register message, the 1399 ETR and Map-Server SHOULD be configured with a shared secret or other 1400 relevant authentication information. A Map-Server's configuration 1401 SHOULD also include a list of the EID-Prefixes for which each ETR is 1402 authoritative. Upon receipt of a Map-Register from an ETR, a Map- 1403 Server accepts only EID-Prefixes that are configured for that ETR. 1404 Failure to implement such a check would leave the mapping system 1405 vulnerable to trivial EID-Prefix hijacking attacks. As developers 1406 and operators gain experience with the mapping system, additional, 1407 stronger security measures MAY be added to the registration process. 1409 In addition to the set of EID-Prefixes defined for each ETR that MAY 1410 register, a Map-Server is typically also configured with one or more 1411 aggregate prefixes that define the part of the EID numbering space 1412 assigned to it. When LISP+ALT is the database in use, aggregate EID- 1413 Prefixes are implemented as discard routes and advertised into ALT 1414 BGP. The existence of aggregate EID-Prefixes in a Map-Server's 1415 database means that it MAY receive Map Requests for EID-Prefixes that 1416 match an aggregate but do not match a registered prefix; Section 8.3 1417 describes how this is handled. 1419 Map-Register messages are sent periodically from an ETR to a Map- 1420 Server with a suggested interval between messages of one minute. A 1421 Map-Server SHOULD time out and remove an ETR's registration if it has 1422 not received a valid Map-Register message within the past 1423 three minutes. When first contacting a Map-Server after restart or 1424 changes to its EID-to-RLOC database mappings, an ETR MAY initially 1425 send Map-Register messages at an increased frequency, up to one every 1426 20 seconds. This "quick registration" period is limited to 1427 five minutes in duration. 1429 An ETR MAY request that a Map-Server explicitly acknowledge receipt 1430 and processing of a Map-Register message by setting the "want-map- 1431 notify" (M-bit) flag. A Map-Server that receives a Map-Register with 1432 this flag set will respond with a Map-Notify message. Typical use of 1433 this flag by an ETR would be to set it for Map-Register messages sent 1434 during the initial "quick registration" with a Map-Server but then 1435 set it only occasionally during steady-state maintenance of its 1436 association with that Map-Server. Note that the Map-Notify message 1437 is sent to UDP destination port 4342, not to the source port 1438 specified in the original Map-Register message. 1440 Note that a one-minute minimum registration interval during 1441 maintenance of an ETR-Map-Server association places a lower bound on 1442 how quickly and how frequently a mapping database entry can be 1443 updated. This MAY have implications for what sorts of mobility can 1444 be supported directly by the mapping system; shorter registration 1445 intervals or other mechanisms might be needed to support faster 1446 mobility in some cases. For a discussion on one way that faster 1447 mobility MAY be implemented for individual devices, please see 1448 [I-D.ietf-lisp-mn]. 1450 An ETR MAY also request, by setting the "proxy Map-Reply" flag 1451 (P-bit) in the Map-Register message, that a Map-Server answer Map- 1452 Requests instead of forwarding them to the ETR. See 1453 [I-D.ietf-lisp-rfc6830bis] for details on how the Map-Server sets 1454 certain flags (such as those indicating whether the message is 1455 authoritative and how returned Locators SHOULD be treated) when 1456 sending a Map-Reply on behalf of an ETR. When an ETR requests proxy 1457 reply service, it SHOULD include all RLOCs for all ETRs for the EID- 1458 Prefix being registered, along with the routable flag ("R-bit") 1459 setting for each RLOC. The Map-Server includes all of this 1460 information in Map-Reply messages that it sends on behalf of the ETR. 1461 This differs from a non-proxy registration, since the latter need 1462 only provide one or more RLOCs for a Map-Server to use for forwarding 1463 Map-Requests; the registration information is not used in Map- 1464 Replies, so it being incomplete is not incorrect. 1466 An ETR that uses a Map-Server to publish its EID-to-RLOC mappings 1467 does not need to participate further in the mapping database 1468 protocol(s). When using a LISP+ALT mapping database, for example, 1469 this means that the ETR does not need to implement GRE or BGP, which 1470 greatly simplifies its configuration and reduces its cost of 1471 operation. 1473 Note that use of a Map-Server does not preclude an ETR from also 1474 connecting to the mapping database (i.e., it could also connect to 1475 the LISP+ALT network), but doing so doesn't seem particularly useful, 1476 as the whole purpose of using a Map-Server is to avoid the complexity 1477 of the mapping database protocols. 1479 8.3. Map-Server Processing 1481 Once a Map-Server has EID-Prefixes registered by its client ETRs, it 1482 can accept and process Map-Requests for them. 1484 In response to a Map-Request (received over the ALT if LISP+ALT is in 1485 use), the Map-Server first checks to see if the destination EID 1486 matches a configured EID-Prefix. If there is no match, the Map- 1487 Server returns a Negative Map-Reply with action code "Natively- 1488 Forward" and a 15-minute TTL. This MAY occur if a Map Request is 1489 received for a configured aggregate EID-Prefix for which no more- 1490 specific EID-Prefix exists; it indicates the presence of a non-LISP 1491 "hole" in the aggregate EID-Prefix. 1493 Next, the Map-Server checks to see if any ETRs have registered the 1494 matching EID-Prefix. If none are found, then the Map-Server returns 1495 a Negative Map-Reply with action code "Natively-Forward" and a 1496 1-minute TTL. 1498 If any of the registered ETRs for the EID-Prefix have requested proxy 1499 reply service, then the Map-Server answers the request instead of 1500 forwarding it. It returns a Map-Reply with the EID-Prefix, RLOCs, 1501 and other information learned through the registration process. 1503 If none of the ETRs have requested proxy reply service, then the Map- 1504 Server re-encapsulates and forwards the resulting Encapsulated Map- 1505 Request to one of the registered ETRs. It does not otherwise alter 1506 the Map-Request, so any Map-Reply sent by the ETR is returned to the 1507 RLOC in the Map-Request, not to the Map-Server. Unless also acting 1508 as a Map-Resolver, a Map-Server SHOULD never receive Map-Replies; any 1509 such messages SHOULD be discarded without response, perhaps 1510 accompanied by the logging of a diagnostic message if the rate of 1511 Map-Replies is suggestive of malicious traffic. 1513 8.4. Map-Resolver Processing 1515 Upon receipt of an Encapsulated Map-Request, a Map-Resolver 1516 decapsulates the enclosed message and then searches for the requested 1517 EID in its local database of mapping entries (statically configured 1518 or learned from associated ETRs if the Map-Resolver is also a Map- 1519 Server offering proxy reply service). If it finds a matching entry, 1520 it returns a LISP Map-Reply with the known mapping. 1522 If the Map-Resolver does not have the mapping entry and if it can 1523 determine that the EID is not in the mapping database (for example, 1524 if LISP+ALT is used, the Map-Resolver will have an ALT forwarding 1525 table that covers the full EID space), it immediately returns a 1526 negative LISP Map-Reply, with action code "Natively-Forward" and a 1527 15-minute TTL. To minimize the number of negative cache entries 1528 needed by an ITR, the Map-Resolver SHOULD return the least-specific 1529 prefix that both matches the original query and does not match any 1530 EID-Prefix known to exist in the LISP-capable infrastructure. 1532 If the Map-Resolver does not have sufficient information to know 1533 whether the EID exists, it needs to forward the Map-Request to 1534 another device that has more information about the EID being 1535 requested. To do this, it forwards the unencapsulated Map-Request, 1536 with the original ITR RLOC as the source, to the mapping database 1537 system. Using LISP+ALT, the Map-Resolver is connected to the ALT 1538 network and sends the Map-Request to the next ALT hop learned from 1539 its ALT BGP neighbors. The Map-Resolver does not send any response 1540 to the ITR; since the source RLOC is that of the ITR, the ETR or Map- 1541 Server that receives the Map-Request over the ALT and responds will 1542 do so directly to the ITR. 1544 8.4.1. Anycast Map-Resolver Operation 1546 A Map-Resolver can be set up to use "anycast", where the same address 1547 is assigned to multiple Map-Resolvers and is propagated through IGP 1548 routing, to facilitate the use of a topologically close Map-Resolver 1549 by each ITR. 1551 Note that Map-Server associations with ETRs SHOULD NOT use anycast 1552 addresses, as registrations need to be established between an ETR and 1553 a specific set of Map-Servers, each identified by a specific 1554 registration association. 1556 9. Security Considerations 1558 The 2-way LISP header nonce exchange documented in 1559 [I-D.ietf-lisp-rfc6830bis] can be used to avoid ITR spoofing attacks. 1561 To publish an authoritative EID-to-RLOC mapping with a Map-Server, an 1562 ETR includes authentication data that is a hash of the message using 1563 a pair-wise shared key. An implementation MUST support use of HMAC- 1564 SHA-1-96 [RFC2104] and SHOULD support use of HMAC-SHA-256-128 1565 [RFC6234] (SHA-256 truncated to 128 bits). 1567 As noted in Section 8.2, a Map-Server SHOULD verify that all EID- 1568 Prefixes registered by an ETR match the configuration stored on the 1569 Map-Server. 1571 The currently defined authentication mechanism for Map-Register 1572 messages does not provide protection against "replay" attacks by a 1573 "man-in-the-middle". Additional work is needed in this area. 1575 [I-D.ietf-lisp-sec] defines a proposed mechanism for providing origin 1576 authentication, integrity, anti-replay protection, and prevention of 1577 man-in-the-middle and "overclaiming" attacks on the Map-Request/Map- 1578 Reply exchange. Work is ongoing on this and other proposals for 1579 resolving these open security issues. 1581 While beyond the scope of securing an individual Map-Server or Map- 1582 Resolver, it SHOULD be noted that a BGP-based LISP+ALT network (if 1583 ALT is used as the mapping database infrastructure) can take 1584 advantage of standards work on adding security to BGP. 1586 A complete LISP threat analysis has been published in [RFC7835]. 1587 Please refer to it for more security related details. 1589 10. IANA Considerations 1591 This section provides guidance to the Internet Assigned Numbers 1592 Authority (IANA) regarding registration of values related to this 1593 LISP control-plane specification, in accordance with BCP 26 1594 [RFC8126]. 1596 There are three namespaces (listed in the sub-sections below) in LISP 1597 that have been registered. 1599 o LISP IANA registry allocations SHOULD NOT be made for purposes 1600 unrelated to LISP routing or transport protocols. 1602 o The following policies are used here with the meanings defined in 1603 BCP 26: "Specification Required", "IETF Review", "Experimental 1604 Use", and "First Come First Served". 1606 10.1. LISP UDP Port Numbers 1608 The IANA registry has allocated UDP port number 4342 for the LISP 1609 control-plane. IANA has updated the description for UDP port 4342 as 1610 follows: 1612 lisp-control 4342 udp LISP Control Packets 1614 10.2. LISP Packet Type Codes 1616 It is being requested that the IANA be authoritative for LISP Packet 1617 Type definitions and that it refers to this document as well as 1618 [RFC8113] as references. 1620 Based on deployment experience of [RFC6830], the Map-Notify-Ack 1621 message, message type 5, was added to this document. This document 1622 requests IANA to add it to the LISP Packet Type Registry. 1624 10.3. LISP ACT and Flag Fields 1626 New ACT values can be allocated through IETF review or IESG approval. 1627 Four values have already been allocated by [RFC6830]. This 1628 specification changes the name of ACT type 3 value from "Drop" to 1629 "Drop/No-Reason" as well as adding two new ACT values, the "Drop/ 1630 Policy-Denied" (type 4) and "Drop/Authentication-Failure" (type 5). 1632 In addition, LISP has a number of flag fields and reserved fields, 1633 such as the LISP header flags field [I-D.ietf-lisp-rfc6830bis]. New 1634 bits for flags in these fields can be implemented after IETF review 1635 or IESG approval, but these need not be managed by IANA. 1637 10.4. LISP Address Type Codes 1639 LISP Canonical Address Format (LCAF) [RFC8060] is an 8-bit field that 1640 defines LISP-specific encodings for AFI value 16387. LCAF encodings 1641 are used for specific use-cases where different address types for 1642 EID-records and RLOC-records are required. 1644 The IANA registry "LISP Canonical Address Format (LCAF) Types" is 1645 used for LCAF types, the registry for LCAF types use the 1646 Specification Required policy [RFC8126]. Initial values for the 1647 registry as well as further information can be found in [RFC8060]. 1649 Therefore, there is no longer a need for the "LISP Address Type 1650 Codes" registry requested by [RFC6830]. This document requests to 1651 remove it. 1653 10.5. LISP Algorithm ID Numbers 1655 In [RFC6830], a request for a "LISP Key ID Numbers" registry was 1656 submitted. This document renames the registry to "LISP Algorithm ID 1657 Numbers" and requests the IANA to make the name change. 1659 The following Algorithm ID values are defined by this specification 1660 as used in any packet type that references a 'Algorithm ID' field: 1662 Name Number Defined in 1663 ----------------------------------------------- 1664 None 0 n/a 1665 HMAC-SHA-1-96 1 [RFC2404] 1666 HMAC-SHA-256-128 2 [RFC4868] 1668 Number values are in the range of 0 to 255. The allocation of values 1669 is on a first come first served basis. 1671 11. References 1673 11.1. Normative References 1675 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 1676 ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November 1677 1998, . 1679 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1680 "Randomness Requirements for Security", BCP 106, RFC 4086, 1681 DOI 10.17487/RFC4086, June 2005, 1682 . 1684 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 1685 384, and HMAC-SHA-512 with IPsec", RFC 4868, 1686 DOI 10.17487/RFC4868, May 2007, 1687 . 1689 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 1690 Locator/ID Separation Protocol (LISP)", RFC 6830, 1691 DOI 10.17487/RFC6830, January 2013, 1692 . 1694 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 1695 Locator/ID Separation Protocol (LISP) for Multicast 1696 Environments", RFC 6831, DOI 10.17487/RFC6831, January 1697 2013, . 1699 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 1700 "Locator/ID Separation Protocol Alternative Logical 1701 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 1702 January 2013, . 1704 [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to 1705 Routing Locator (RLOC) Database", RFC 6837, 1706 DOI 10.17487/RFC6837, January 2013, 1707 . 1709 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 1710 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 1711 February 2017, . 1713 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 1714 Smirnov, "Locator/ID Separation Protocol Delegated 1715 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 1716 May 2017, . 1718 [RFC8113] Boucadair, M. and C. Jacquenet, "Locator/ID Separation 1719 Protocol (LISP): Shared Extension Message & IANA Registry 1720 for Packet Type Allocations", RFC 8113, 1721 DOI 10.17487/RFC8113, March 2017, 1722 . 1724 11.2. Informative References 1726 [AFI] IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY 1727 NUMBERS http://www.iana.org/assignments/address-family- 1728 numbers/address-family-numbers.xhtml?, Febuary 2007. 1730 [I-D.ermagan-lisp-nat-traversal] 1731 Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, 1732 F., and C. White, "NAT traversal for LISP", draft-ermagan- 1733 lisp-nat-traversal-13 (work in progress), September 2017. 1735 [I-D.ietf-lisp-eid-mobility] 1736 Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, 1737 F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a 1738 Unified Control Plane", draft-ietf-lisp-eid-mobility-01 1739 (work in progress), November 2017. 1741 [I-D.ietf-lisp-introduction] 1742 Cabellos-Aparicio, A. and D. Saucez, "An Architectural 1743 Introduction to the Locator/ID Separation Protocol 1744 (LISP)", draft-ietf-lisp-introduction-13 (work in 1745 progress), April 2015. 1747 [I-D.ietf-lisp-mn] 1748 Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP 1749 Mobile Node", draft-ietf-lisp-mn-01 (work in progress), 1750 October 2017. 1752 [I-D.ietf-lisp-rfc6830bis] 1753 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 1754 Cabellos-Aparicio, "The Locator/ID Separation Protocol 1755 (LISP)", draft-ietf-lisp-rfc6830bis-09 (work in progress), 1756 February 2018. 1758 [I-D.ietf-lisp-sec] 1759 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 1760 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14 1761 (work in progress), October 2017. 1763 [I-D.ietf-lisp-signal-free-multicast] 1764 Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", 1765 draft-ietf-lisp-signal-free-multicast-08 (work in 1766 progress), February 2018. 1768 [I-D.ietf-opsec-icmp-filtering] 1769 Gont, F., Gont, G., and C. Pignataro, "Recommendations for 1770 filtering ICMP messages", draft-ietf-opsec-icmp- 1771 filtering-04 (work in progress), July 2013. 1773 [I-D.lewis-lisp-gpe] 1774 Lewis, D., Lemon, J., Agarwal, P., Kreeger, L., Quinn, P., 1775 Smith, M., Yadav, N., and F. Maino, "LISP Generic Protocol 1776 Extension", draft-lewis-lisp-gpe-04 (work in progress), 1777 December 2017. 1779 [I-D.meyer-loc-id-implications] 1780 Meyer, D. and D. Lewis, "Architectural Implications of 1781 Locator/ID Separation", draft-meyer-loc-id-implications-01 1782 (work in progress), January 2009. 1784 [I-D.quinn-vxlan-gpe] 1785 Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F., 1786 Smith, M., Agarwal, P., Yong, L., Xu, X., Elzur, U., Garg, 1787 P., and D. Melman, "Generic Protocol Extension for VXLAN", 1788 draft-quinn-vxlan-gpe-04 (work in progress), February 1789 2015. 1791 [I-D.rodrigueznatal-lisp-pubsub] 1792 Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., 1793 Cabellos-Aparicio, A., Barkai, S., Farinacci, D., 1794 Boucadair, M., Jacquenet, C., and s. 1795 stefano.secci@lip6.fr, "Publish/Subscribe Functionality 1796 for LISP", draft-rodrigueznatal-lisp-pubsub-02 (work in 1797 progress), March 2018. 1799 [LISP-CONS] 1800 Brim, S., Chiappa, N., Farinacci, D., Fuller, V., Lewis, 1801 D., and D. Meyer, "LISP-CONS: A Content distribution 1802 Overlay Network Service for LISP", Work in Progress, April 1803 2008. 1805 [RFC1035] Mockapetris, P., "Domain names - implementation and 1806 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1807 November 1987, . 1809 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1810 Hashing for Message Authentication", RFC 2104, 1811 DOI 10.17487/RFC2104, February 1997, 1812 . 1814 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1815 Requirement Levels", BCP 14, RFC 2119, 1816 DOI 10.17487/RFC2119, March 1997, 1817 . 1819 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 1820 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 1821 DOI 10.17487/RFC6234, May 2011, 1822 . 1824 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 1825 "Interworking between Locator/ID Separation Protocol 1826 (LISP) and Non-LISP Sites", RFC 6832, 1827 DOI 10.17487/RFC6832, January 2013, 1828 . 1830 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 1831 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 1832 eXtensible Local Area Network (VXLAN): A Framework for 1833 Overlaying Virtualized Layer 2 Networks over Layer 3 1834 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 1835 . 1837 [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID 1838 Separation Protocol (LISP) Threat Analysis", RFC 7835, 1839 DOI 10.17487/RFC7835, April 2016, 1840 . 1842 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1843 Writing an IANA Considerations Section in RFCs", BCP 26, 1844 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1845 . 1847 Appendix A. Acknowledgments 1849 The authors would like to thank Greg Schudel, Darrel Lewis, John 1850 Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver, 1851 Fabio Maino, and members of the lisp@ietf.org mailing list for their 1852 feedback and helpful suggestions. 1854 Special thanks are due to Noel Chiappa for his extensive work on 1855 caching with LISP-CONS, some of which may be used by Map-Resolvers. 1857 Appendix B. Document Change Log 1859 [RFC Editor: Please delete this section on publication as RFC.] 1861 B.1. Changes to draft-ietf-lisp-rfc6833bis-08 1863 o Posted March 2018. 1865 o Added RLOC-probing algorithm. 1867 o Added Solicit-Map Request algorithm. 1869 o Added several mechanisms (from 6830bis) regarding Routing Locator 1870 Reachability. 1872 o Added port 4342 to IANA Considerations section. 1874 B.2. Changes to draft-ietf-lisp-rfc6833bis-07 1876 o Posted December 2017. 1878 o Make it more clear in a couple of places that RLOCs are used to 1879 locate ETRs more so than for Map-Server Map-Request forwarding. 1881 o Make it clear that "encapsualted" for a control message is an ECM 1882 based message. 1884 o Make it more clear what messages use source-port 4342 and which 1885 ones use destinatino-port 4342. 1887 o Don't make DDT references when the mapping transport system can be 1888 of any type and the referneced text is general to it. 1890 o Generalize text when referring to the format of an EID-prefix. 1891 Can use othe AFIs then IPv4 and IPv6. 1893 o Many editorial changes to clarify text. 1895 o Changed some "must", "should", and "may" to capitalized. 1897 o Added definitions for Map-Request and Map-Reply messages. 1899 o Ran document through IDNITs. 1901 B.3. Changes to draft-ietf-lisp-rfc6833bis-06 1903 o Posted October 2017. 1905 o Spec the I-bit to include the xTR-ID in a Map-Request message to 1906 be consistent with the Map-Register message and to anticipate the 1907 introduction of pubsub functionality to allow Map-Requests to 1908 subscribe to RLOC-set changes. 1910 o Updated references for individual submissions that became working 1911 group documents. 1913 o Updated references for working group documents that became RFCs. 1915 B.4. Changes to draft-ietf-lisp-rfc6833bis-05 1917 o Posted May 2017. 1919 o Update IANA Considerations section based on new requests from this 1920 document and changes from what was requested in [RFC6830]. 1922 B.5. Changes to draft-ietf-lisp-rfc6833bis-04 1924 o Posted May 2017. 1926 o Clarify how the Key-ID field is used in Map-Register and Map- 1927 Notify messages. Break the 16-bit field into a 8-bit Key-ID field 1928 and a 8-bit Algorithm-ID field. 1930 o Move the control-plane codepoints from the IANA Considerations 1931 section of RFC6830bis to the IANA Considerations section of this 1932 document. 1934 o In the "LISP Control Packet Type Allocations" section, indicate 1935 how message Types are IANA allocated and how experimental RFC8113 1936 sub-types should be requested. 1938 B.6. Changes to draft-ietf-lisp-rfc6833bis-03 1940 o Posted April 2017. 1942 o Add types 9-14 and specify they are not assigned. 1944 o Add the "LISP Shared Extension Message" type and point to RFC8113. 1946 B.7. Changes to draft-ietf-lisp-rfc6833bis-02 1948 o Posted April 2017. 1950 o Clarify that the LISP control-plane document defines how the LISP 1951 data-plane uses Map-Requests with either the SMR-bit set or the 1952 P-bit set supporting mapping updates and RLOC-probing. Indicating 1953 that other data-planes can use the same mechanisms or their own 1954 defined mechanisms to achieve the same functionality. 1956 B.8. Changes to draft-ietf-lisp-rfc6833bis-01 1958 o Posted March 2017. 1960 o Include references to new RFCs published. 1962 o Remove references to self. 1964 o Change references from RFC6830 to RFC6830bis. 1966 o Add two new action/reasons to a Map-Reply has posted to the LISP 1967 WG mailing list. 1969 o In intro section, add refernece to I-D.ietf-lisp-introduction. 1971 o Removed Open Issues section and references to "experimental". 1973 B.9. Changes to draft-ietf-lisp-rfc6833bis-00 1975 o Posted December 2016. 1977 o Created working group document from draft-farinacci-lisp 1978 -rfc6833-00 individual submission. No other changes made. 1980 B.10. Changes to draft-farinacci-lisp-rfc6833bis-00 1982 o Posted November 2016. 1984 o This is the initial draft to turn RFC 6833 into RFC 6833bis. 1986 o The document name has changed from the "Locator/ID Separation 1987 Protocol (LISP) Map-Server Interface" to the "Locator/ID 1988 Separation Protocol (LISP) Control-Plane". 1990 o The fundamental change was to move the control-plane messages from 1991 RFC 6830 to this document in an effort so any IETF developed or 1992 industry created data-plane could use the LISP mapping system and 1993 control-plane. 1995 o Update control-plane messages to incorporate what has been 1996 implemented in products during the early phase of LISP development 1997 but wasn't able to make it into RFC6830 and RFC6833 to make the 1998 Experimental RFC deadline. 2000 o Indicate there may be nodes in the mapping system that are not MRs 2001 or MSs, that is a ALT-node or a DDT-node. 2003 o Include LISP-DDT in Map-Resolver section and explain how they 2004 maintain a referral-cache. 2006 o Removed open issue about additional state in Map-Servers. With 2007 [RFC8111], Map-Servers have the same registration state and can 2008 give Map-Resolvers complete information in ms-ack Map-Referral 2009 messages. 2011 o Make reference to the LISP Threats Analysis RFC [RFC7835]. 2013 Authors' Addresses 2015 Vince Fuller 2016 Cisco Systems 2018 EMail: vaf@vaf.net 2020 Dino Farinacci 2021 Cisco Systems 2023 EMail: farinacci@gmail.com 2025 Albert Cabellos 2026 UPC/BarcelonaTech 2027 Campus Nord, C. Jordi Girona 1-3 2028 Barcelona, Catalunya 2029 Spain 2031 EMail: acabello@ac.upc.edu