idnits 2.17.1 draft-ietf-lisp-rfc6833bis-25.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 is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. -- The draft header indicates that this document obsoletes RFC6833, but the abstract doesn't seem to directly say this. It does mention RFC6833 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 16, 2019) is 1775 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) == Missing Reference: 'Key ID' is mentioned on line 1086, but not defined == Unused Reference: 'RFC2104' is defined on line 2216, but no explicit reference was found in the text == Unused Reference: 'RFC6234' is defined on line 2230, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-lisp-6834bis-03 == Outdated reference: A later version (-38) exists of draft-ietf-lisp-rfc6830bis-26 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-18 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-12) exists of draft-ietf-lisp-ecdsa-auth-01 == Outdated reference: A later version (-16) exists of draft-ietf-lisp-eid-anonymity-06 == Outdated reference: A later version (-13) exists of draft-ietf-lisp-eid-mobility-04 == Outdated reference: A later version (-19) exists of draft-ietf-lisp-gpe-06 == 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-05 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-pubsub-03 == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-07 -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 2 errors (**), 0 flaws (~~), 15 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Farinacci 3 Internet-Draft lispers.net 4 Obsoletes: 6830, 6833 (if approved) F. Maino 5 Intended status: Standards Track Cisco Systems 6 Expires: December 18, 2019 V. Fuller 7 vaf.net Internet Consulting 8 A. Cabellos (Ed.) 9 UPC/BarcelonaTech 10 June 16, 2019 12 Locator/ID Separation Protocol (LISP) Control-Plane 13 draft-ietf-lisp-rfc6833bis-25 15 Abstract 17 This document describes the Control-Plane and Mapping Service for the 18 Locator/ID Separation Protocol (LISP), implemented by two new types 19 of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server 20 -- that provides a simplified "front end" for one or more Endpoint ID 21 to Routing Locator mapping databases. 23 By using this Control-Plane service interface and communicating with 24 Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and 25 Egress Tunnel Routers (ETRs) are not dependent on the details of 26 mapping database systems, which facilitates modularity with different 27 database designs. Since these devices implement the "edge" of the 28 LISP Control-Plane infrastructure, connecting EID addressable nodes 29 of a LISP site, their implementation and operational complexity 30 reduces the overall cost and effort of deploying LISP. 32 This document obsoletes RFC 6830 and RFC 6833. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on December 18, 2019. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Scope of Applicability . . . . . . . . . . . . . . . . . 4 69 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 70 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5 71 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 6 72 5. LISP IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 8 73 5.1. LISP Control Packet Type Allocations . . . . . . . . . . 11 74 5.2. Map-Request Message Format . . . . . . . . . . . . . . . 12 75 5.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 14 76 5.4. Map-Reply Message Format . . . . . . . . . . . . . . . . 17 77 5.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 21 78 5.6. Map-Register Message Format . . . . . . . . . . . . . . . 24 79 5.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 28 80 5.8. Encapsulated Control Message Format . . . . . . . . . . . 30 81 6. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 32 82 6.1. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 32 83 7. Routing Locator Reachability . . . . . . . . . . . . . . . . 33 84 7.1. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 35 85 8. Interactions with Other LISP Components . . . . . . . . . . . 36 86 8.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 36 87 8.2. EID-Prefix Configuration and ETR Registration . . . . . . 37 88 8.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 39 89 8.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 40 90 8.4.1. Anycast Operation . . . . . . . . . . . . . . . . . . 40 91 9. Security Considerations . . . . . . . . . . . . . . . . . . . 40 92 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 42 93 11. Changes since RFC 6833 . . . . . . . . . . . . . . . . . . . 43 94 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 95 12.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 44 96 12.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 44 97 12.3. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 44 98 12.4. LISP Address Type Codes . . . . . . . . . . . . . . . . 45 99 12.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 45 100 12.6. LISP Bit Flags . . . . . . . . . . . . . . . . . . . . . 46 101 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 102 13.1. Normative References . . . . . . . . . . . . . . . . . . 49 103 13.2. Informative References . . . . . . . . . . . . . . . . . 50 104 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 55 105 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 55 106 B.1. Changes to draft-ietf-lisp-rfc6833bis-25 . . . . . . . . 55 107 B.2. Changes to draft-ietf-lisp-rfc6833bis-24 . . . . . . . . 55 108 B.3. Changes to draft-ietf-lisp-rfc6833bis-23 . . . . . . . . 56 109 B.4. Changes to draft-ietf-lisp-rfc6833bis-22 . . . . . . . . 56 110 B.5. Changes to draft-ietf-lisp-rfc6833bis-21 . . . . . . . . 56 111 B.6. Changes to draft-ietf-lisp-rfc6833bis-20 . . . . . . . . 56 112 B.7. Changes to draft-ietf-lisp-rfc6833bis-19 . . . . . . . . 56 113 B.8. Changes to draft-ietf-lisp-rfc6833bis-18 . . . . . . . . 57 114 B.9. Changes to draft-ietf-lisp-rfc6833bis-17 . . . . . . . . 57 115 B.10. Changes to draft-ietf-lisp-rfc6833bis-16 . . . . . . . . 57 116 B.11. Changes to draft-ietf-lisp-rfc6833bis-15 . . . . . . . . 57 117 B.12. Changes to draft-ietf-lisp-rfc6833bis-14 . . . . . . . . 57 118 B.13. Changes to draft-ietf-lisp-rfc6833bis-13 . . . . . . . . 58 119 B.14. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . 58 120 B.15. Changes to draft-ietf-lisp-rfc6833bis-11 . . . . . . . . 58 121 B.16. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . 58 122 B.17. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . 58 123 B.18. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 58 124 B.19. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 59 125 B.20. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 59 126 B.21. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 60 127 B.22. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 60 128 B.23. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 60 129 B.24. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 60 130 B.25. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 60 131 B.26. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 61 132 B.27. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 61 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62 135 1. Introduction 137 The Locator/ID Separation Protocol [I-D.ietf-lisp-rfc6830bis] (see 138 also [I-D.ietf-lisp-introduction]) specifies an architecture and 139 mechanism for dynamic tunneling by logically separating the addresses 140 currently used by IP in two separate name spaces: Endpoint IDs 141 (EIDs), used within sites; and Routing Locators (RLOCs), used on the 142 transit networks that make up the Internet infrastructure. To 143 achieve this separation, LISP defines protocol mechanisms for mapping 144 from EIDs to RLOCs. In addition, LISP assumes the existence of a 145 database to store and propagate those mappings across mapping system 146 nodes. Several such databases have been proposed; among them are the 147 Content distribution Overlay Network Service for LISP-NERD (a Not-so- 148 novel EID-to-RLOC Database) [RFC6837], LISP Alternative Logical 149 Topology (LISP-ALT) [RFC6836], and LISP Delegated Database Tree 150 (LISP-DDT) [RFC8111]. 152 The LISP Mapping Service defines two new types of LISP-speaking 153 devices: the Map-Resolver, which accepts Map-Requests from an Ingress 154 Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a 155 mapping database; and the Map-Server, which learns authoritative EID- 156 to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes 157 them in a database. 159 This LISP Control-Plane Mapping Service can be used by many different 160 encapsulation-based or translation-based Data-Planes which include 161 but are not limited to the ones defined in LISP RFC 6830bis 162 [I-D.ietf-lisp-rfc6830bis], LISP-GPE [I-D.ietf-lisp-gpe], VXLAN 163 [RFC7348], VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe], GRE [RFC2890], GTP 164 [GTP-3GPP], ILA [I-D.herbert-intarea-ila], and Segment Routing (SRv6) 165 [RFC8402]. 167 Conceptually, LISP Map-Servers share some of the same basic 168 configuration and maintenance properties as Domain Name System (DNS) 169 [RFC1035] servers; likewise, Map-Resolvers are conceptually similar 170 to DNS caching resolvers. With this in mind, this specification 171 borrows familiar terminology (resolver and server) from the DNS 172 specifications. 174 Note this document doesn't assume any particular database mapping 175 infrastructure to illustrate certain aspects of Map-Server and Map- 176 Resolver operation. The Mapping Service interface can (and likely 177 will) be used by ITRs and ETRs to access other mapping database 178 systems as the LISP infrastructure evolves. 180 LISP is not intended to address problems of connectivity and scaling 181 on behalf of arbitrary communicating parties. Relevant situations 182 are described in the scoping section of the introduction to 183 [I-D.ietf-lisp-rfc6830bis]. 185 This document obsoletes RFC 6830 and 6833. 187 1.1. Scope of Applicability 189 LISP was originally developed to address the Internet-wide route 190 scaling problem [RFC4984]. While there are a number of approaches of 191 interest for that problem, as LISP as been developed and refined, a 192 large number of other LISP uses have been found and are being used. 193 As such, the design and development of LISP has changed so as to 194 focus on these use cases. The common property of these uses is a 195 large set of cooperating entities seeking to communicate over the 196 public Internet or other large underlay IP infrastructures, while 197 keeping the addressing and topology of the cooperating entities 198 separate from the underlay and Internet topology, routing, and 199 addressing. 201 2. Requirements Notation 203 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 204 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 205 "OPTIONAL" in this document are to be interpreted as described in BCP 206 14 [RFC2119] [RFC8174] when, and only when, they appear in all 207 capitals, as shown here. 209 3. Definition of Terms 211 Map-Server: A network infrastructure component that learns of EID- 212 Prefix mapping entries from an ETR, via the registration mechanism 213 described below, or some other authoritative source if one exists. 214 A Map-Server publishes these EID-Prefixes in a mapping database. 216 Map-Request: A LISP Map-Request is a Control-Plane message to query 217 the mapping system to resolve an EID. A LISP Map-Request can also 218 be sent to an RLOC to test for reachability and to exchange 219 security keys between an encapsulator and a decapsulator. This 220 type of Map-Request is also known as an RLOC-Probe Request. 222 Map-Reply: A LISP Map-Reply is a Control-Plane message returned in 223 response to a Map-Request sent to the mapping system when 224 resolving an EID. A LISP Map-Reply can also be returned by a 225 decapsulator in response to a Map-Request sent by an encapsulator 226 to test for reachability. This type of Map-Reply is known as a 227 RLOC-Probe Reply. 229 Encapsulated Map-Request: A LISP Map-Request carried within an 230 Encapsulated Control Message (ECM), which has an additional LISP 231 header prepended. Sent to UDP destination port 4342. The "outer" 232 addresses are routable IP addresses, also known as RLOCs. Used by 233 an ITR when sending to a Map-Resolver and by a Map-Server when 234 forwarding a Map-Request to an ETR. 236 Map-Resolver: A network infrastructure component that accepts LISP 237 Encapsulated (ECM) Map-Requests, typically from an ITR, and 238 determines whether or not the destination IP address is part of 239 the EID namespace; if it is not, a Negative Map-Reply is returned. 241 Otherwise, the Map-Resolver finds the appropriate EID-to-RLOC 242 mapping by consulting a mapping database system. 244 Negative Map-Reply: A LISP Map-Reply that contains an empty 245 Locator-Set. Returned in response to a Map-Request if the 246 destination EID is not registered in the mapping system, is policy 247 denied or fails authentication. 249 Map-Register message: A LISP message sent by an ETR to a Map-Server 250 to register its associated EID-Prefixes. In addition to the set 251 of EID-Prefixes to register, the message includes one or more 252 RLOCs to reach ETR(s). The Map-Server uses these RLOCs when 253 forwarding Map-Requests (re-formatted as Encapsulated Map- 254 Requests). An ETR MAY request that the Map-Server answer Map- 255 Requests on its behalf by setting the "proxy Map-Reply" flag 256 (P-bit) in the message. 258 Map-Notify message: A LISP message sent by a Map-Server to an ETR 259 to confirm that a Map-Register has been received and processed. 260 An ETR requests that a Map-Notify be returned by setting the 261 "want-map-notify" flag (M-bit) in the Map-Register message. 262 Unlike a Map-Reply, a Map-Notify uses UDP port 4342 for both 263 source and destination. Map-Notify messages are also sent to ITRs 264 by Map-Servers when there are RLOC-set changes. 266 For definitions of other terms, notably Ingress Tunnel Router (ITR), 267 Egress Tunnel Router (ETR), and Re-encapsulating Tunnel Router (RTR), 268 refer to the LISP Data-Plane specification 269 [I-D.ietf-lisp-rfc6830bis]. 271 4. Basic Overview 273 A Map-Server is a device that publishes EID-Prefixes in a LISP 274 mapping database on behalf of a set of ETRs. When it receives a Map 275 Request (typically from an ITR), it consults the mapping database to 276 find an ETR that can answer with the set of RLOCs for an EID-Prefix. 277 To publish its EID-Prefixes, an ETR periodically sends Map-Register 278 messages to the Map-Server. A Map-Register message contains a list 279 of EID-Prefixes plus a set of RLOCs that can be used to reach the 280 ETRs. 282 When LISP-ALT [RFC6836] is used as the mapping database, a Map-Server 283 connects to the ALT network and acts as a "last-hop" ALT-Router. 284 Intermediate ALT-Routers forward Map-Requests to the Map-Server that 285 advertises a particular EID-Prefix, and the Map-Server forwards them 286 to the owning ETR, which responds with Map-Reply messages. 288 When LISP-DDT [RFC8111] is used as the mapping database, a Map-Server 289 sends the final Map-Referral messages from the Delegated Database 290 Tree. 292 A Map-Resolver receives Encapsulated Map-Requests from its client 293 ITRs and uses a mapping database system to find the appropriate ETR 294 to answer those requests. On a LISP-ALT network, a Map-Resolver acts 295 as a "first-hop" ALT-Router. It has Generic Routing Encapsulation 296 (GRE) tunnels configured to other ALT-Routers and uses BGP to learn 297 paths to ETRs for different prefixes in the LISP-ALT database. The 298 Map-Resolver uses this path information to forward Map-Requests over 299 the ALT to the correct ETRs. On a LISP-DDT network [RFC8111], a Map- 300 Resolver maintains a referral-cache and acts as a "first-hop" DDT- 301 node. The Map-Resolver uses the referral information to forward Map- 302 Requests. 304 Note that while it is conceivable that a Map-Resolver could cache 305 responses to improve performance, issues surrounding cache management 306 will need to be resolved so that doing so will be reliable and 307 practical. As initially deployed, Map-Resolvers will operate only in 308 a non-caching mode, decapsulating and forwarding Encapsulated Map 309 Requests received from ITRs. Any specification of caching 310 functionality is out of scope for this document. 312 Note that a single device can implement the functions of both a Map- 313 Server and a Map-Resolver, and in many cases the functions will be 314 co-located in that way. Also, there can be ALT-only nodes and DDT- 315 only nodes, when LISP-ALT and LISP-DDT are used, respectively, to 316 connecting Map-Resolvers and Map-Servers together to make up the 317 Mapping System. 319 5. LISP IPv4 and IPv6 Control-Plane Packet Formats 321 The following UDP packet formats are used by the LISP control plane. 323 0 1 2 3 324 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 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 |Version| IHL |Type of Service| Total Length | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Identification |Flags| Fragment Offset | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Time to Live | Protocol = 17 | Header Checksum | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Source Routing Locator | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Destination Routing Locator | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 / | Source Port | Dest Port | 337 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 \ | UDP Length | UDP Checksum | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | | 341 | LISP Message | 342 | | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 IPv4 UDP LISP Control Message 347 0 1 2 3 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 |Version| Traffic Class | Flow Label | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Payload Length | Next Header=17| Hop Limit | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | | 355 + + 356 | | 357 + Source Routing Locator + 358 | | 359 + + 360 | | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | | 363 + + 364 | | 365 + Destination Routing Locator + 366 | | 367 + + 368 | | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 / | Source Port | Dest Port | 371 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 \ | UDP Length | UDP Checksum | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | | 375 | LISP Message | 376 | | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 IPv6 UDP LISP Control Message 381 When a UDP Map-Request, Map-Register, or Map-Notify (when used as a 382 notification message) are sent, the UDP source port is chosen by the 383 sender and the destination UDP port number is set to 4342. When a 384 UDP Map-Reply, Map-Notify (when used as an acknowledgement to a Map- 385 Register), or Map-Notify-Ack are sent, the source UDP port number is 386 set to 4342 and the destination UDP port number is copied from the 387 source port of either the Map-Request or the invoking data packet. 388 Implementations MUST be prepared to accept packets when either the 389 source port or destination UDP port is set to 4342 due to NATs 390 changing port number values. 392 The 'UDP Length' field will reflect the length of the UDP header and 393 the LISP Message payload. LISP is expected to be deployed by 394 cooperating entities communicating over underlays. Deployers are 395 expected to set the MTU according to the specific deployment 396 guidelines to prevent fragmentation of either the inner packet or the 397 outer encapsulated packet. For deployments not aware of the underlay 398 restrictions on path MTU, the message size MUST be limited to 576 399 bytes for IPv4 or 1280 bytes for IPv6 as outlined in [RFC8085]. 401 The UDP checksum is computed and set to non-zero for all messages 402 sent to or from port 4342. It MUST be checked on receipt, and if the 403 checksum fails, the control message MUST be dropped [RFC1071]. 405 The format of control messages includes the UDP header so the 406 checksum and length fields can be used to protect and delimit message 407 boundaries. 409 5.1. LISP Control Packet Type Allocations 411 This section defines the LISP control message formats and summarizes 412 for IANA the LISP Type codes assigned by this document. For 413 completeness, the summary below includes the LISP Shared Extension 414 Message assigned by [I-D.ietf-lisp-rfc8113bis]. Message type 415 definitions are: 417 Reserved: 0 b'0000' 418 LISP Map-Request: 1 b'0001' 419 LISP Map-Reply: 2 b'0010' 420 LISP Map-Register: 3 b'0011' 421 LISP Map-Notify: 4 b'0100' 422 LISP Map-Notify-Ack: 5 b'0101' 423 LISP Map-Referral: 6 b'0110' 424 Unassigned 7 b'0111' 425 LISP Encapsulated Control Message: 8 b'1000' 426 Unassigned 9-14 b'1001'- b'1110' 427 LISP Shared Extension Message: 15 b'1111' 429 Protocol designers experimenting with new message formats are 430 recommended to use the LISP Shared Extension Message Type described 431 in [I-D.ietf-lisp-rfc8113bis]. 433 All LISP Control-Plane messages use Address Family Identifiers (AFI) 434 [AFI] or LISP Canonical Address Format (LCAF) [RFC8060] formats to 435 encode either fixed or variable length addresses. This includes 436 explicit fields in each control message or part of EID-records or 437 RLOC-records in commonly formatted messages. 439 The LISP control-plane describes how other data-planes can encode 440 messages to support the Soliciting of Map-Requests as well as RLOC- 441 probing procedures. 443 5.2. Map-Request Message Format 445 0 1 2 3 446 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 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 |Type=1 |A|M|P|S|p|s|R|R| Rsvd |L|D| IRC | Record Count | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Nonce . . . | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | . . . Nonce | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Source-EID-AFI | Source EID Address ... | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | ... | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | ITR-RLOC-AFI n | ITR-RLOC Address n ... | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 / | Reserved | EID mask-len | EID-Prefix-AFI | 463 Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 \ | EID-Prefix ... | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Map-Reply Record ... | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 Packet field descriptions: 471 Type: 1 (Map-Request) 473 A: This is an authoritative bit, which is set to 0 for UDP-based Map- 474 Requests sent by an ITR. It is set to 1 when an ITR wants the 475 destination site to return the Map-Reply rather than the mapping 476 database system returning a Map-Reply. 478 M: This is the map-data-present bit. When set, it indicates that a 479 Map-Reply Record segment is included in the Map-Request. 481 P: This is the probe-bit, which indicates that a Map-Request SHOULD 482 be treated as a Locator reachability probe. The receiver SHOULD 483 respond with a Map-Reply with the probe-bit set, indicating that 484 the Map-Reply is a Locator reachability probe reply, with the 485 nonce copied from the Map-Request. See RLOC-Probing Section 7.1 486 for more details. This RLOC-probe Map-Request MUST NOT be sent to 487 the mapping system. If a Map-Resolver or Map-Server receives a 488 Map-Request with the probe-bit set, it MUST drop the message. 490 S: This is the Solicit-Map-Request (SMR) bit. See Solicit-Map- 491 Request (SMRs) Section 6.1 for details. 493 p: This is the PITR bit. This bit is set to 1 when a PITR sends a 494 Map-Request. 496 s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is 497 sending a Map-Request in response to a received SMR-based Map- 498 Request. 500 R: This reserved and unassigned bit MUST be set to 0 on transmit and 501 MUST be ignored on receipt. 503 Rsvd: This field MUST be set to 0 on transmit and MUST be ignored on 504 receipt. 506 L: This is the local-xtr bit. It is used by an xTR in a LISP site to 507 tell other xTRs in the same site that it is part of the RLOC-set 508 for the LISP site. The L-bit is set to 1 when the RLOC is the 509 sender's IP address. 511 D: This is the dont-map-reply bit. It is used in the SMR procedure 512 described in Section 6.1. When an xTR sends an SMR Map-Request 513 message, it doesn't need a Map-Reply returned. When this bit is 514 set, the receiver of the Map-Request does not return a Map-Reply. 516 IRC: This 5-bit field is the ITR-RLOC Count, which encodes the 517 additional number of ('ITR-RLOC-AFI', 'ITR-RLOC Address') fields 518 present in this message. At least one (ITR-RLOC-AFI, ITR-RLOC- 519 Address) pair MUST be encoded. Multiple 'ITR-RLOC Address' fields 520 are used, so a Map-Replier can select which destination address to 521 use for a Map-Reply. The IRC value ranges from 0 to 31. For a 522 value of 0, there is 1 ITR-RLOC address encoded; for a value of 1, 523 there are 2 ITR-RLOC addresses encoded, and so on up to 31, which 524 encodes a total of 32 ITR-RLOC addresses. 526 Record Count: This is the number of records in this Map-Request 527 message. A record is comprised of the portion of the packet that 528 is labeled 'Rec' above and occurs the number of times equal to 529 Record Count. For this version of the protocol, a receiver MUST 530 accept and process Map-Requests that contain one or more records, 531 but a sender MUST only send Map-Requests containing one record. 533 Nonce: This is an 8-octet random value created by the sender of the 534 Map-Request. This nonce will be returned in the Map-Reply. The 535 nonce is used as an index to identify the corresponding Map- 536 Request when a Map-Reply message is received. The nonce MUST be 537 generated by a properly seeded pseudo-random (or strong random) 538 source. See [RFC4086] for advice on generating security-sensitive 539 random data. 541 Source-EID-AFI: This is the address family of the 'Source EID 542 Address' field. 544 Source EID Address: This is the EID of the source host that 545 originated the packet that caused the Map-Request. When Map- 546 Requests are used for refreshing a Map-Cache entry or for RLOC- 547 Probing, an AFI value 0 is used and this field is of zero length. 549 ITR-RLOC-AFI: This is the address family of the 'ITR-RLOC Address' 550 field that follows this field. 552 ITR-RLOC Address: This is used to give the ETR the option of 553 selecting the destination address from any address family for the 554 Map-Reply message. This address MUST be a routable RLOC address 555 of the sender of the Map-Request message. 557 EID mask-len: This is the mask length for the EID-Prefix. 559 EID-Prefix-AFI: This is the address family of the EID-Prefix 560 according to [AFI] and [RFC8060]. 562 EID-Prefix: This prefix address length is 4 octets for an IPv4 563 address family and 16 octets for an IPv6 address family when the 564 EID-Prefix-AFI is 1 or 2, respectively. For other AFIs [AFI], the 565 address length varies and for the LCAF AFI the format is defined 566 in [RFC8060]. When a Map-Request is sent by an ITR because a data 567 packet is received for a destination where there is no mapping 568 entry, the EID-Prefix is set to the destination IP address of the 569 data packet, and the 'EID mask-len' is set to 32 or 128 for IPv4 570 or IPv6, respectively. When an xTR wants to query a site about 571 the status of a mapping it already has cached, the EID-Prefix used 572 in the Map-Request has the same mask-length as the EID-Prefix 573 returned from the site when it sent a Map-Reply message. 575 Map-Reply Record: When the M-bit is set, this field is the size of a 576 single "Record" in the Map-Reply format. This Map-Reply record 577 contains the EID-to-RLOC mapping entry associated with the Source 578 EID. This allows the ETR that will receive this Map-Request to 579 cache the data if it chooses to do so. 581 5.3. EID-to-RLOC UDP Map-Request Message 583 A Map-Request is sent from an ITR when it needs a mapping for an EID, 584 wants to test an RLOC for reachability, or wants to refresh a mapping 585 before TTL expiration. For the initial case, the destination IP 586 address used for the Map-Request is the data packet's destination 587 address (i.e., the destination EID) that had a mapping cache lookup 588 failure. For the latter two cases, the destination IP address used 589 for the Map-Request is one of the RLOC addresses from the Locator-Set 590 of the Map-Cache entry. The source address is either an IPv4 or IPv6 591 RLOC address, depending on whether the Map-Request is using an IPv4 592 or IPv6 header, respectively. In all cases, the UDP source port 593 number for the Map-Request message is a 16-bit value selected by the 594 ITR/PITR, and the UDP destination port number is set to the well- 595 known destination port number 4342. A successful Map-Reply, which is 596 one that has a nonce that matches an outstanding Map-Request nonce, 597 will update the cached set of RLOCs associated with the EID-Prefix 598 range. 600 One or more Map-Request ('ITR-RLOC-AFI', 'ITR-RLOC-Address') fields 601 MUST be filled in by the ITR. The number of fields (minus 1) encoded 602 MUST be placed in the 'IRC' field. The ITR MAY include all locally 603 configured Locators in this list or just provide one locator address 604 from each address family it supports. If the ITR erroneously 605 provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map- 606 Request. 608 Map-Requests can also be LISP encapsulated using UDP destination 609 port 4342 with a LISP Type value set to "Encapsulated Control 610 Message", when sent from an ITR to a Map-Resolver. Likewise, Map- 611 Requests are LISP encapsulated the same way from a Map-Server to an 612 ETR. Details on Encapsulated Map-Requests and Map-Resolvers can be 613 found in Section 5.8. 615 Map-Requests MUST be rate-limited to 1 per second per EID-prefix. 616 After 10 retransmits without receiving the corresponding Map-Reply 617 must wait 30 seconds. 619 An ITR that is configured with mapping database information (i.e., it 620 is also an ETR) MAY optionally include those mappings in a Map- 621 Request. When an ETR configured to accept and verify such 622 "piggybacked" mapping data receives such a Map-Request and it does 623 not have this mapping in the Map-Cache, it MAY originate a "verifying 624 Map-Request", addressed to the map-requesting ITR and the ETR MAY add 625 a Map-Cache entry. If the ETR (when it is an xTR co-located as an 626 ITR) has a Map-Cache entry that matches the "piggybacked" EID and the 627 RLOC is in the Locator-Set for the entry, then it MAY send the 628 "verifying Map-Request" directly to the originating Map-Request 629 source. If the RLOC is not in the Locator-Set, then the ETR MUST 630 send the "verifying Map-Request" to the "piggybacked" EID. Doing 631 this forces the "verifying Map-Request" to go through the mapping 632 database system to reach the authoritative source of information 633 about that EID, guarding against RLOC-spoofing in the "piggybacked" 634 mapping data. 636 5.4. Map-Reply Message Format 638 0 1 2 3 639 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 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 |Type=2 |P|E|S| Reserved | Record Count | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | Nonce . . . | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | . . . Nonce | 646 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | | Record TTL | 648 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 R | Locator Count | EID mask-len | ACT |A| Reserved | 650 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 c | Rsvd | Map-Version Number | EID-Prefix-AFI | 652 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 r | EID-Prefix | 654 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | /| Priority | Weight | M Priority | M Weight | 656 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | o | Unused Flags |L|p|R| Loc-AFI | 658 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | \| Locator | 660 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 Packet field descriptions: 664 Type: 2 (Map-Reply) 666 P: This is the probe-bit, which indicates that the Map-Reply is in 667 response to a Locator reachability probe Map-Request. The 'Nonce' 668 field MUST contain a copy of the nonce value from the original 669 Map-Request. See RLOC-probing Section 7.1 for more details. When 670 the probe-bit is set to 1 in a Map-Reply message, the A-bit in 671 each EID-record included in the message MUST be set to 1. 673 E: This bit indicates that the ETR that sends this Map-Reply message 674 is advertising that the site is enabled for the Echo-Nonce Locator 675 reachability algorithm. See Echo-Nonce [I-D.ietf-lisp-rfc6830bis] 676 for more details. 678 S: This is the Security bit. When set to 1, the following 679 authentication information will be appended to the end of the Map- 680 Reply. The details of signing a Map-Reply message can be found in 681 [I-D.ietf-lisp-sec]. 683 0 1 2 3 684 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 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | AD Type | Authentication Data Content . . . | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 Reserved: This unassigned field MUST be set to 0 on transmit and 690 MUST be ignored on receipt. 692 Record Count: This is the number of records in this reply message. 693 A record is comprised of that portion of the packet labeled 694 'Record' above and occurs the number of times equal to Record 695 Count. 697 Nonce: This 64-bit value from the Map-Request is echoed in this 698 'Nonce' field of the Map-Reply. 700 Record TTL: This is the time in minutes the recipient of the Map- 701 Reply will store the mapping. If the TTL is 0, the entry MUST be 702 removed from the cache immediately. If the value is 0xffffffff, 703 the recipient can decide locally how long to store the mapping. 705 Locator Count: This is the number of Locator entries. A Locator 706 entry comprises what is labeled above as 'Loc'. The Locator count 707 can be 0, indicating that there are no Locators for the EID- 708 Prefix. 710 EID mask-len: This is the mask length for the EID-Prefix. 712 ACT: This 3-bit field describes Negative Map-Reply actions. In any 713 other message type, these bits are set to 0 and ignored on 714 receipt. These bits are used only when the 'Locator Count' field 715 is set to 0. The action bits are encoded only in Map-Reply 716 messages. They are used to tell an ITR or PITR why a empty 717 locator-set was returned from the mapping system and how it stores 718 the map-cache entry. 720 (0) No-Action: The Map-Cache is kept alive, and no packet 721 encapsulation occurs. 723 (1) Natively-Forward: The packet is not encapsulated or dropped 724 but natively forwarded. 726 (2) Send-Map-Request: The Map-Cache entry is created and flagged 727 that any packet matching this entry invokes sending a Map- 728 Request. 730 (3) Drop/No-Reason: A packet that matches this Map-Cache entry is 731 dropped. An ICMP Destination Unreachable message SHOULD be 732 sent. 734 (4) Drop/Policy-Denied: A packet that matches this Map-Cache 735 entry is dropped. The reason for the Drop action is that a 736 Map-Request for the target-EID is being policy denied by 737 either an xTR or the mapping system. 739 (5) Drop/Authentication-Failure: A packet that matches this Map- 740 Cache entry is dropped. The reason for the Drop action is 741 that a Map-Request for the target-EID fails an authentication 742 verification-check by either an xTR or the mapping system. 744 A: The Authoritative bit, when set to 1, is always set to 1 by an 745 ETR. When a Map-Server is proxy Map-Replying for a LISP site, the 746 Authoritative bit is set to 0. This indicates to requesting ITRs 747 that the Map-Reply was not originated by a LISP node managed at 748 the site that owns the EID-Prefix. 750 Map-Version Number: When this 12-bit value is non-zero, the Map- 751 Reply sender is informing the ITR what the version number is for 752 the EID record contained in the Map-Reply. The ETR can allocate 753 this number internally but MUST coordinate this value with other 754 ETRs for the site. When this value is 0, there is no versioning 755 information conveyed. The Map-Version Number can be included in 756 Map-Request and Map-Register messages. See Map-Versioning 757 [I-D.ietf-lisp-6834bis] for more details. 759 EID-Prefix-AFI: Address family of the EID-Prefix according to [AFI] 760 and [RFC8060]. 762 EID-Prefix: This prefix is 4 octets for an IPv4 address family and 763 16 octets for an IPv6 address family. 765 Priority: Each RLOC is assigned a unicast Priority. Lower values 766 are more preferable. When multiple RLOCs have the same Priority, 767 they may be used in a load-split fashion. A value of 255 means 768 the RLOC MUST NOT be used for unicast forwarding. 770 Weight: When priorities are the same for multiple RLOCs, the Weight 771 indicates how to balance unicast traffic between them. Weight is 772 encoded as a relative weight of total unicast packets that match 773 the mapping entry. For example, if there are 4 Locators in a 774 Locator-Set, where the Weights assigned are 30, 20, 20, and 10, 775 the first Locator will get 37.5% of the traffic, the 2nd and 3rd 776 Locators will get 25% of the traffic, and the 4th Locator will get 777 12.5% of the traffic. If all Weights for a Locator-Set are equal, 778 the receiver of the Map-Reply will decide how to load-split the 779 traffic. See RLOC-hashing [I-D.ietf-lisp-rfc6830bis] for a 780 suggested hash algorithm to distribute the load across Locators 781 with the same Priority and equal Weight values. 783 M Priority: Each RLOC is assigned a multicast Priority used by an 784 ETR in a receiver multicast site to select an ITR in a source 785 multicast site for building multicast distribution trees. A value 786 of 255 means the RLOC MUST NOT be used for joining a multicast 787 distribution tree. For more details, see [RFC6831]. 789 M Weight: When priorities are the same for multiple RLOCs, the 790 Weight indicates how to balance building multicast distribution 791 trees across multiple ITRs. The Weight is encoded as a relative 792 weight (similar to the unicast Weights) of the total number of 793 trees built to the source site identified by the EID-Prefix. If 794 all Weights for a Locator-Set are equal, the receiver of the Map- 795 Reply will decide how to distribute multicast state across ITRs. 796 For more details, see [RFC6831]. 798 Unused Flags: These are set to 0 when sending and ignored on 799 receipt. 801 L: When this bit is set, the Locator is flagged as a local Locator to 802 the ETR that is sending the Map-Reply. When a Map-Server is doing 803 proxy Map-Replying for a LISP site, the L-bit is set to 0 for all 804 Locators in this Locator-Set. 806 p: When this bit is set, an ETR informs the RLOC-Probing ITR that the 807 locator address for which this bit is set is the one being RLOC- 808 probed and may be different from the source address of the Map- 809 Reply. An ITR that RLOC-probes a particular Locator MUST use this 810 Locator for retrieving the data structure used to store the fact 811 that the Locator is reachable. The p-bit is set for a single 812 Locator in the same Locator-Set. If an implementation sets more 813 than one p-bit erroneously, the receiver of the Map-Reply MUST 814 select the first set p-bit Locator. The p-bit MUST NOT be set for 815 Locator-Set records sent in Map-Request and Map-Register messages. 817 R: This is set when the sender of a Map-Reply has a route to the 818 Locator in the Locator data record. This receiver may find this 819 useful to know if the Locator is up but not necessarily reachable 820 from the receiver's point of view. See also EID-Reachability 821 Section 7.1 for another way the R-bit may be used. 823 Locator: This is an IPv4 or IPv6 address (as encoded by the 'Loc- 824 AFI' field) assigned to an ETR and used by an ITR as a destination 825 RLOC address in the outer header of a LISP encapsualted packet. 827 Note that the destination RLOC address of a LISP encapsulated 828 packet MAY be an anycast address. A source RLOC of a LISP 829 encapsulated packet can be an anycast address as well. The source 830 or destination RLOC MUST NOT be the broadcast address 831 (255.255.255.255 or any subnet broadcast address known to the 832 router) and MUST NOT be a link-local multicast address. The 833 source RLOC MUST NOT be a multicast address. The destination RLOC 834 SHOULD be a multicast address if it is being mapped from a 835 multicast destination EID. 837 Map-Reply MUST be rate-limited, it is RECOMMENDED that a Map-Reply 838 for the same destination RLOC be sent no more than one packets per 3 839 seconds. 841 The Record format, as defined here, is used both in the Map-Reply and 842 Map-Register messages, this includes all the field definitions. 844 5.5. EID-to-RLOC UDP Map-Reply Message 846 A Map-Reply returns an EID-Prefix with a mask-length that is less 847 than or equal to the EID being requested. The EID being requested is 848 either from the destination field of an IP header of a Data-Probe or 849 the EID record of a Map-Request. The RLOCs in the Map-Reply are 850 routable IP addresses of all ETRs for the LISP site. Each RLOC 851 conveys status reachability but does not convey path reachability 852 from a requester's perspective. Separate testing of path 853 reachability is required. See RLOC-reachability Section 7.1 for 854 details. 856 Note that a Map-Reply MAY contain different EID-Prefix granularity 857 (prefix + mask-length) than the Map-Request that triggers it. This 858 might occur if a Map-Request were for a prefix that had been returned 859 by an earlier Map-Reply. In such a case, the requester updates its 860 cache with the new prefix information and granularity. For example, 861 a requester with two cached EID-Prefixes that are covered by a Map- 862 Reply containing one less-specific prefix replaces the entry with the 863 less-specific EID-Prefix. Note that the reverse, replacement of one 864 less-specific prefix with multiple more-specific prefixes, can also 865 occur, not by removing the less-specific prefix but rather by adding 866 the more-specific prefixes that, during a lookup, will override the 867 less-specific prefix. 869 When an EID moves out of a LISP site [I-D.ietf-lisp-eid-mobility], 870 the database mapping system may have overlapping EID-prefixes. Or 871 when a LISP site is configured with multiple sets of ETRs that 872 support different EID-prefix mask-lengths, the database mapping 873 system may have overlapping EID-prefixes. When overlapping EID- 874 prefixes exist, a Map-Request with an EID that best matches any EID- 875 Prefix MUST be returned in a single Map-Reply message. For instance, 876 if an ETR had database mapping entries for EID-Prefixes: 878 2001:db8::/16 879 2001:db8:1::/24 880 2001:db8:1:1::/32 881 2001:db8:1:2::/32 883 A Map-Request for EID 2001:db8:1:1::1 would cause a Map-Reply with a 884 record count of 1 to be returned with a mapping record EID-Prefix of 885 2001:db8:1:1::/32. 887 A Map-Request for EID 2001:db8:1:5::5 would cause a Map-Reply with a 888 record count of 3 to be returned with mapping records for EID- 889 Prefixes 2001:db8:1::/24, 2001:db8:1:1::/32, 2001:db8:1:2::/32, 890 filling out the /24 with more-specifics that exist in the mapping 891 system. 893 Note that not all overlapping EID-Prefixes need to be returned but 894 only the more-specific entries (note that in the second example above 895 2001:db8::/16 was not returned for requesting EID 2001:db8:1:5::5) 896 for the matching EID-Prefix of the requesting EID. When more than 897 one EID-Prefix is returned, all SHOULD use the same Time to Live 898 value so they can all time out at the same time. When a more- 899 specific EID-Prefix is received later, its Time to Live value in the 900 Map-Reply record can be stored even when other less-specific entries 901 exist. When a less-specific EID-Prefix is received later, its Map- 902 Cache expiration time SHOULD be set to the minimum expiration time of 903 any more-specific EID-Prefix in the Map-Cache. This is done so the 904 integrity of the EID-Prefix set is wholly maintained and so no more- 905 specific entries are removed from the Map-Cache while keeping less- 906 specific entries. 908 For scalability, it is expected that aggregation of EID addresses 909 into EID-Prefixes will allow one Map-Reply to satisfy a mapping for 910 the EID addresses in the prefix range, thereby reducing the number of 911 Map-Request messages. 913 Map-Reply records can have an empty Locator-Set. A Negative Map- 914 Reply is a Map-Reply with an empty Locator-Set. Negative Map-Replies 915 convey special actions by the sender to the ITR or PITR that have 916 solicited the Map-Reply. There are two primary applications for 917 Negative Map-Replies. The first is for a Map-Resolver to instruct an 918 ITR or PITR when a destination is for a LISP site versus a non-LISP 919 site, and the other is to source quench Map-Requests that are sent 920 for non-allocated EIDs. 922 For each Map-Reply record, the list of Locators in a Locator-Set MUST 923 appear in the same order for each ETR that originates a Map-Reply 924 message. The Locator-Set MUST be sorted in order of ascending IP 925 address where an IPv4 locator address is considered numerically 'less 926 than' an IPv6 locator address. 928 When sending a Map-Reply message, the destination address is copied 929 from one of the 'ITR-RLOC' fields from the Map-Request. The ETR can 930 choose a locator address from one of the address families it 931 supports. For Data-Probes, the destination address of the Map-Reply 932 is copied from the source address of the Data-Probe message that is 933 invoking the reply. The source address of the Map-Reply is one of 934 the local IP addresses chosen, to allow Unicast Reverse Path 935 Forwarding (uRPF) checks to succeed in the upstream service provider. 936 The destination port of a Map-Reply message is copied from the source 937 port of the Map-Request or Data-Probe, and the source port of the 938 Map-Reply message is set to the well-known UDP port 4342. 940 5.6. Map-Register Message Format 942 This section specifies the encoding format for the Map-Register 943 message. The message is sent in UDP with a destination UDP port of 944 4342 and a randomly selected UDP source port number. 946 The fields below are used in multiple control messages. They are 947 defined for Map-Register, Map-Notify and Map-Notify-Ack message 948 types. 950 The Map-Register message format is: 952 0 1 2 3 953 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 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 |Type=3 |P|S|I| Reserved |E|T|a|R|M| Record Count | 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 | Nonce . . . | 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | . . . Nonce | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | Key ID | Algorithm ID | Authentication Data Length | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 ~ Authentication Data ~ 964 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | | Record TTL | 966 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 R | Locator Count | EID mask-len | ACT |A| Reserved | 968 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 c | Rsvd | Map-Version Number | EID-Prefix-AFI | 970 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 r | EID-Prefix | 972 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | /| Priority | Weight | M Priority | M Weight | 974 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 | o | Unused Flags |L|p|R| Loc-AFI | 976 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | \| Locator | 978 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 Packet field descriptions: 982 Type: 3 (Map-Register) 984 P: This is the proxy Map-Reply bit. When set to 1, an ETR sends a 985 Map-Register message requesting the Map-Server to proxy a Map- 986 Reply. The Map-Server will send non-authoritative Map-Replies on 987 behalf of the ETR. 989 S: This is the security-capable bit. When set, the procedures from 990 [I-D.ietf-lisp-sec] are supported. 992 I: This bit is set to 1 to indicate that a 128 bit xTR-ID and a 64 993 bit Site-ID fields are present at the end of the Map-Register 994 message. If an xTR is configured with an xTR-ID and Site-ID, it 995 MUST set the I bit to 1 and include its xTR-ID and Site-ID in the 996 Map-Register messages it generates. The combination of Site-ID 997 plus xTR-ID uniquely identifies an xTR in a LISP domain and serves 998 to track its last seen nonce. 1000 Reserved: This unassigned field MUST be set to 0 on transmit and 1001 MUST be ignored on receipt. 1003 E: This is the Map-Register EID-notify bit. This is used by a First- 1004 Hop-Router (FHR) which discovers a dynamic-EID. This EID-notify 1005 based Map-Register is sent by the FHR to the same site xTR that 1006 propogates the Map-Register to the mapping system. The site xTR 1007 keeps state to later Map-Notify the FHR after the EID has moves 1008 away. See [I-D.ietf-lisp-eid-mobility] for a detailed use-case. 1010 T: This is the use-TTL for timeout bit. When set to 1, the xTR wants 1011 the Map-Server to time out registrations based on the value in the 1012 "Record TTL" field of this message. Otherwise, the default 1013 timeout described in Section 8.2 is used. 1015 a: This is the merge-request bit. When set to 1, the xTR requests to 1016 merge RLOC-records from different xTRs registering the same EID- 1017 record. See signal-free multicast [RFC8378] for one use case 1018 example. 1020 R: This reserved and unassigned bit MUST be set to 0 on transmit and 1021 MUST be ignored on receipt. 1023 M: This is the want-map-notify bit. When set to 1, an ETR is 1024 requesting a Map-Notify message to be returned in response to 1025 sending a Map-Register message. The Map-Notify message sent by a 1026 Map-Server is used to acknowledge receipt of a Map-Register 1027 message. 1029 Record Count: This is the number of records in this Map-Register 1030 message. A record is comprised of that portion of the packet 1031 labeled 'Record' above and occurs the number of times equal to 1032 Record Count. 1034 Nonce: This 8-octet 'Nonce' field is incremented each time a Map- 1035 Register message is sent. When a Map-Register acknowledgement is 1036 requested, the nonce is returned by Map-Servers in Map-Notify 1037 messages. Since the entire Map-Register message is authenticated, 1038 the 'Nonce' field serves to protect against Map-Register replay 1039 attacks. An ETR that registers to the mapping system SHOULD store 1040 the last nonce sent in persistent storage so when it restarts it 1041 can continue using an incrementing nonce. If the the ETR cannot 1042 support saving the nonce, then when it restarts it MUST use a new 1043 authentication key to register to the mapping system. A Map- 1044 Server MUST track and save in persistent storage the last nonce 1045 received for each ETR xTR-ID and key pair. If a Map-Register is 1046 received with a nonce value that is not greater than the saved 1047 nonce, it drops the Map-Register message and logs the fact a 1048 replay attack could have occurred. 1050 Key ID: A key-id value that identifies a pre-shared secret between 1051 an ETR and a Map-Server. Per-message keys are derived from the 1052 pre-shared secret to authenticate the origin and protect the 1053 integrity of the Map-Register. The Key ID allows to rotate 1054 between multiple pre-shared secrets in a non disruptive way. The 1055 pre-shared secret MUST be unique per each LISP "Site-ID" 1057 Algorithm ID: This field identifies the Key Derivation Function 1058 (KDF) and Message Authentication Code (MAC) algorithms used to 1059 derive the key and to compute the Authentication Data of a Map- 1060 Register. This 8-bit field identifies the KDF and MAC algorithm 1061 pair. See Section 12.5 for codepoint assignments. 1063 Authentication Data Length: This is the length in octets of the 1064 'Authentication Data' field that follows this field. The length 1065 of the 'Authentication Data' field is dependent on the MAC 1066 algorithm used. The length field allows a device that doesn't 1067 know the MAC algorithm to correctly parse the packet. 1069 Authentication Data: This is the output of the MAC algorithm placed 1070 in this field after the MAC computation. The MAC output is 1071 computed as follows: 1073 1: The KDF algorithm is identified by the field 'Algorithm ID' 1074 according to the table in Section 12.5. Implementations of 1075 this specification SHOULD include support for HMAC-SHA256- 1076 128+HKDF-SHA256 [RFC4868]. 1078 2: The MAC algorithm is identified by the field 'Algorithm ID' 1079 according to the table in Section 12.5. 1081 3: The pre-shared secret used to derive the per-message key is 1082 represented by PSK[Key ID], that is the pre-shared secret 1083 identified by the 'Key ID'. 1085 4: The derived per-message key is computed as: per-msg- 1086 key=KDF(nonce+s+PSK[Key ID]). Where the nonce is the value in 1087 the Nonce field of the Map-Register and 's' is a string equal 1088 to "Map-Register Authentication". 1090 5: The MAC output is computed using the MAC algorithm and the 1091 per-msg-key over the entire Map-Register payload (from and 1092 including the LISP message type field through the end of the 1093 last RLOC record) with the authenticated data field preset to 1094 0. 1096 The definition of the rest of the Map-Register can be found in EID- 1097 record description in Section 5.4. When the I-bit is set, the 1098 following fields are added to the end of the Map-Register message: 1100 xTR-ID: xTR-ID is a 128 bit field at the end of the Map-Register 1101 message, starting after the final Record in the message. The xTR- 1102 ID is used to uniquely identify a xTR. The same xTR-ID value MUST 1103 NOT be used in two different xTRs. 1105 Site-ID: Site-ID is a 64 bit field at the end of the Map- Register 1106 message, following the xTR-ID. Site-ID is used to uniquely 1107 identify to which site the xTR that sent the message belongs. 1109 5.7. Map-Notify/Map-Notify-Ack Message Format 1111 This section specifies the encoding format for the Map-Notify and 1112 Map-Notify-Ack messages. The messages are sent inside a UDP packet 1113 with source and destination UDP ports equal to 4342. 1115 The Map-Notify and Map-Notify-Ack message formats are: 1117 0 1 2 3 1118 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 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 |Type=4/5| Reserved | Record Count | 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 | Nonce . . . | 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 | . . . Nonce | 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 | Key ID | Algorithm ID | Authentication Data Length | 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 ~ Authentication Data ~ 1129 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 | | Record TTL | 1131 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 R | Locator Count | EID mask-len | ACT |A| Reserved | 1133 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 c | Rsvd | Map-Version Number | EID-Prefix-AFI | 1135 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 r | EID-Prefix | 1137 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 | /| Priority | Weight | M Priority | M Weight | 1139 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 | o | Unused Flags |L|p|R| Loc-AFI | 1141 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 | \| Locator | 1143 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 Packet field descriptions: 1147 Type: 4/5 (Map-Notify/Map-Notify-Ack) 1149 The Map-Notify message has the same contents as a Map-Register 1150 message. See the Map-Register section for field descriptions and the 1151 Map-Reply section for EID-record and RLOC-record descriptions. 1153 The fields of the Map-Notify are copied from the corresponding Map- 1154 Register to acknowledge its correct processing. In the Map-Notfiy, 1155 the 'Authentication Data' field is recomputed according to the 1156 procedure defined in the previous section. For an unsolicited Map- 1157 Notify, the fields of a Map-Notify used for publish/subscribe are 1158 specified in [I-D.ietf-lisp-pubsub]. 1160 After sending a Map-Register, if a Map-Notify is not received after 1 1161 second the transmitter MUST re-transmit the original Map-Register 1162 with an exponential backoff, the maximum backoff is 1 minute. 1164 The Map-Notify-Ack message has the same contents as a Map-Notify 1165 message. It is used to acknowledge the receipt of a Map-Notify 1166 (solicited or unsolicited) and for the sender to stop retransmitting 1167 a Map-Notify with the same nonce. The fields of the Map-Notify-Ack 1168 are copied from the corresponding Map-Notify message to acknowledge 1169 its correct processing. 1171 A Map-Server sends an unsolicited Map-Notify message (one that is not 1172 used as an acknowledgment to a Map-Register message) that follows the 1173 Congestion Control And Relability Guideline sections of [RFC8085]. A 1174 Map-Notify is retransmitted until a Map-Notify-Ack is received by the 1175 Map-Server with the same nonce used in the Map-Notify message. If a 1176 Map-Notify-Ack is never received by the Map-Server, it issues a log 1177 message. An implementation SHOULD retransmit up to 3 times at 3 1178 second retransmission intervals, after which time the retransmission 1179 interval is exponentially backed-off for another 3 retransmission 1180 attempts. After this time, an xTR can only get the RLOC-set change 1181 by later querying the mapping system or by RLOC-probing one of the 1182 RLOCs of the existing cached RLOC-set to get the new RLOC-set. 1184 5.8. Encapsulated Control Message Format 1186 An Encapsulated Control Message (ECM) is used to encapsulate control 1187 packets sent between xTRs and the mapping database system. 1189 0 1 2 3 1190 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 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 / | IPv4 or IPv6 Header | 1193 OH | (uses RLOC addresses) | 1194 \ | | 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 / | Source Port = xxxx | Dest Port = 4342 | 1197 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 \ | UDP Length | UDP Checksum | 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1200 LISP |Type=8 |S|D|E|M| Reserved | 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 / | IPv4 or IPv6 Header | 1203 IH | (uses RLOC or EID addresses) | 1204 \ | | 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 / | Source Port = xxxx | Dest Port = yyyy | 1207 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1208 \ | UDP Length | UDP Checksum | 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 LCM | LISP Control Message | 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1213 Packet header descriptions: 1215 OH: The outer IPv4 or IPv6 header, which uses RLOC addresses in the 1216 source and destination header address fields. 1218 UDP: The outer UDP header with destination port 4342. The source 1219 port is randomly allocated. The checksum field MUST be non- 1220 zero. 1222 LISP: Type 8 is defined to be a "LISP Encapsulated Control Message", 1223 and what follows is either an IPv4 or IPv6 header as encoded by 1224 the first 4 bits after the 'Reserved' field. 1226 Type: 8 (Encapsulated Control Message (ECM)) 1228 S: This is the Security bit. When set to 1, the field following 1229 the 'Reserved' field will have the following Authentication 1230 Data format and follow the procedures from [I-D.ietf-lisp-sec]. 1232 0 1 2 3 1233 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 1234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1235 | AD Type | Authentication Data Content . . . | 1236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1238 D: This is the DDT-bit. When set to 1, the sender is requesting a 1239 Map-Referral message to be returned. The details of this 1240 procedure are described in [RFC8111]. 1242 E: This is the to-ETR bit. When set to 1, the Map-Server's 1243 intention is to forward the ECM to an authoritative ETR. 1245 M: This is the to-MS bit. When set to 1, a Map-Request is being 1246 sent to a co-located Map-Resolver and Map-Server where the 1247 message can be processed directly by the Map-Server versus the 1248 Map-Resolver using the LISP-DDT procedures in [RFC8111]. 1250 IH: The inner IPv4 or IPv6 header, which can use either RLOC or EID 1251 addresses in the header address fields. When a Map-Request is 1252 encapsulated in this packet format, the destination address in 1253 this header is an EID. 1255 UDP: The inner UDP header, where the port assignments depend on the 1256 control packet being encapsulated. When the control packet is 1257 a Map-Request or Map-Register, the source port is selected by 1258 the ITR/PITR and the destination port is 4342. When the 1259 control packet is a Map-Reply, the source port is 4342 and the 1260 destination port is assigned from the source port of the 1261 invoking Map-Request. Port number 4341 MUST NOT be assigned to 1262 either port. The checksum field MUST be non-zero. 1264 LCM: The format is one of the control message formats described in 1265 this section. Map-Request messages are allowed to be Control- 1266 Plane (ECM) encapsulated. When Map-Requests are sent for RLOC- 1267 Probing purposes (i.e. the probe-bit is set), they MUST NOT be 1268 sent inside Encapsulated Control Messages. PIM Join/Prune 1269 messages [RFC6831] are also allowed to be Control-Plane (ECM) 1270 encapsulated. 1272 6. Changing the Contents of EID-to-RLOC Mappings 1274 In the LISP architecture ITRs/PITRs use a local Map-Cache to store 1275 EID-to-RLOC mappings for forwarding. When an ETR updates a mapping a 1276 mechanism is required to inform ITRs/PITRs that are using such 1277 mappings. 1279 The LISP Data-Plane defines several mechanism to update mappings 1280 [I-D.ietf-lisp-rfc6830bis]. This document specifies the Solicit-Map 1281 Request (SMR), a Control-Plane push-based mechanism. An additional 1282 Control-Plane mechanism based on the Publish/subscribe paradigm is 1283 specified in [I-D.ietf-lisp-pubsub]. 1285 6.1. Solicit-Map-Request (SMR) 1287 Soliciting a Map-Request is a selective way for ETRs, at the site 1288 where mappings change, to control the rate they receive requests for 1289 Map-Reply messages. SMRs are also used to tell remote ITRs to update 1290 the mappings they have cached. 1292 Since ETRs are not required to keep track of remote ITRs that have 1293 cached their mappings, they do not know which ITRs need to have their 1294 mappings updated. As a result, an ETR will solicit Map-Requests 1295 (called an SMR message) to those sites to which it has been sending 1296 LISP encapsulated data packets for the last minute. In particular, 1297 an ETR will send an SMR to an ITR to which it has recently sent 1298 encapsulated data. This can only occur when both ITR and ETR 1299 functionality reside in the same router. 1301 An SMR message is simply a bit set in a Map-Request message. An ITR 1302 or PITR will send a Map-Request when they receive an SMR message. 1303 Both the SMR sender and the SMR responder MUST rate-limit these 1304 messages. It is RECOMMENDED that the SMR sender rate-limits Map- 1305 Request for the same destination RLOC to no more than one packet per 1306 3 seconds. It is RECOMMENDED that the SMR responder rate-limits Map- 1307 Request for the same EID-Prefix to no more than once per 3 seconds. 1309 The following procedure shows how an SMR exchange occurs when a site 1310 is doing Locator-Set compaction for an EID-to-RLOC mapping: 1312 1. When the database mappings in an ETR change, the ETRs at the site 1313 begin to send Map-Requests with the SMR bit set for each Locator 1314 in each Map-Cache entry the ETR (when it is an xTR co-located as 1315 an ITR) caches. 1317 2. A remote ITR that receives the SMR message will schedule sending 1318 a Map-Request message to the source locator address of the SMR 1319 message or to the mapping database system. A newly allocated 1320 random nonce is selected, and the EID-Prefix used is the one 1321 copied from the SMR message. If the source Locator is the only 1322 Locator in the cached Locator-Set, the remote ITR SHOULD send a 1323 Map-Request to the database mapping system just in case the 1324 single Locator has changed and may no longer be reachable to 1325 accept the Map-Request. 1327 3. The remote ITR MUST rate-limit the Map-Request until it gets a 1328 Map-Reply while continuing to use the cached mapping. When 1329 Map-Versioning as described in [I-D.ietf-lisp-6834bis] is used, 1330 an SMR sender can detect if an ITR is using the most up-to-date 1331 database mapping. 1333 4. The site sending SMR messages will reply to the Map-Request with 1334 a Map-Reply message that has a nonce from the SMR-invoked Map- 1335 Request. This is important to avoid Map-Reply implosion. 1337 5. The ETRs at the site with the changed mapping record the fact 1338 that the site that sent the Map-Request has received the new 1339 mapping data in the Map-Cache entry for the remote site so the 1340 Locator-Status-Bits are reflective of the new mapping for packets 1341 going to the remote site. The ETR then stops sending SMR 1342 messages. 1344 For security reasons, an ITR MUST NOT process unsolicited Map- 1345 Replies. To avoid Map-Cache entry corruption by a third party, a 1346 sender of an SMR-based Map-Request MUST be verified. If an ITR 1347 receives an SMR-based Map-Request and the source is not in the 1348 Locator-Set for the stored Map-Cache entry, then the responding Map- 1349 Request MUST be sent with an EID destination to the mapping database 1350 system. Since the mapping database system is a more secure way to 1351 reach an authoritative ETR, it will deliver the Map-Request to the 1352 authoritative source of the mapping data. 1354 When an ITR receives an SMR-based Map-Request for which it does not 1355 have a cached mapping for the EID in the SMR message, it SHOULD NOT 1356 send an SMR-invoked Map-Request. This scenario can occur when an ETR 1357 sends SMR messages to all Locators in the Locator-Set it has stored 1358 in its Map-Cache but the remote ITRs that receive the SMR may not be 1359 sending packets to the site. There is no point in updating the ITRs 1360 until they need to send, in which case they will send Map-Requests to 1361 obtain a Map-Cache entry. 1363 7. Routing Locator Reachability 1365 This document defines several Control-Plane mechanisms for 1366 determining RLOC reachability. Please note that additional Data- 1367 Plane reachability mechanisms are defined in 1368 [I-D.ietf-lisp-rfc6830bis]. 1370 1. An ITR may receive an ICMP Network Unreachable or Host 1371 Unreachable message for an RLOC it is using. This indicates that 1372 the RLOC is likely down. Note that trusting ICMP messages may 1373 not be desirable, but neither is ignoring them completely. 1374 Implementations are encouraged to follow current best practices 1375 in treating these conditions [I-D.ietf-opsec-icmp-filtering]. 1377 2. When an ITR participates in the routing protocol that operates in 1378 the underlay routing system, it can determine that an RLOC is 1379 down when no Routing Information Base (RIB) entry exists that 1380 matches the RLOC IP address. 1382 3. An ITR may receive an ICMP Port Unreachable message from a 1383 destination host. This occurs if an ITR attempts to use 1384 interworking [RFC6832] and LISP-encapsulated data is sent to a 1385 non-LISP-capable site. 1387 4. An ITR may receive a Map-Reply from an ETR in response to a 1388 previously sent Map-Request. The RLOC source of the Map-Reply is 1389 likely up, since the ETR was able to send the Map-Reply to the 1390 ITR. 1392 5. An ITR/ETR pair can use the 'RLOC-Probing' mechanism described 1393 below. 1395 When ITRs receive ICMP Network Unreachable or Host Unreachable 1396 messages as a method to determine unreachability, they will refrain 1397 from using Locators that are described in Locator lists of Map- 1398 Replies. However, using this approach is unreliable because many 1399 network operators turn off generation of ICMP Destination Unreachable 1400 messages. 1402 If an ITR does receive an ICMP Network Unreachable or Host 1403 Unreachable message, it MAY originate its own ICMP Destination 1404 Unreachable message destined for the host that originated the data 1405 packet the ITR encapsulated. 1407 Also, BGP-enabled ITRs can unilaterally examine the RIB to see if a 1408 locator address from a Locator-Set in a mapping entry matches a 1409 prefix. If it does not find one and BGP is running in the Default- 1410 Free Zone (DFZ), it can decide to not use the Locator even though the 1411 Locator-Status-Bits indicate that the Locator is up. In this case, 1412 the path from the ITR to the ETR that is assigned the Locator is not 1413 available. More details are in [I-D.meyer-loc-id-implications]. 1415 Optionally, an ITR can send a Map-Request to a Locator, and if a Map- 1416 Reply is returned, reachability of the Locator has been determined. 1417 Obviously, sending such probes increases the number of control 1418 messages originated by Tunnel Routers for active flows, so Locators 1419 are assumed to be reachable when they are advertised. 1421 This assumption does create a dependency: Locator unreachability is 1422 detected by the receipt of ICMP Host Unreachable messages. When a 1423 Locator has been determined to be unreachable, it is not used for 1424 active traffic; this is the same as if it were listed in a Map-Reply 1425 with Priority 255. 1427 The ITR can test the reachability of the unreachable Locator by 1428 sending periodic Requests. Both Requests and Replies MUST be rate- 1429 limited. Locator reachability testing is never done with data 1430 packets, since that increases the risk of packet loss for end-to-end 1431 sessions. 1433 7.1. RLOC-Probing Algorithm 1435 RLOC-Probing is a method that an ITR or PITR can use to determine the 1436 reachability status of one or more Locators that it has cached in a 1437 Map-Cache entry. The probe-bit of the Map-Request and Map-Reply 1438 messages is used for RLOC-Probing. 1440 RLOC-Probing is done in the control plane on a timer basis, where an 1441 ITR or PITR will originate a Map-Request destined to a locator 1442 address from one of its own locator addresses. A Map-Request used as 1443 an RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or to 1444 the mapping database system as one would when soliciting mapping 1445 data. The EID record encoded in the Map-Request is the EID-Prefix of 1446 the Map-Cache entry cached by the ITR or PITR. The ITR MAY include a 1447 mapping data record for its own database mapping information that 1448 contains the local EID-Prefixes and RLOCs for its site. RLOC-probes 1449 are sent periodically using a jittered timer interval. 1451 When an ETR receives a Map-Request message with the probe-bit set, it 1452 returns a Map-Reply with the probe-bit set. The source address of 1453 the Map-Reply is set to the IP address of the outgoing interface the 1454 Map-Reply destination address routes to. The Map-Reply SHOULD 1455 contain mapping data for the EID-Prefix contained in the Map-Request. 1456 This provides the opportunity for the ITR or PITR that sent the RLOC- 1457 probe to get mapping updates if there were changes to the ETR's 1458 database mapping entries. 1460 There are advantages and disadvantages of RLOC-Probing. The main 1461 benefit of RLOC-Probing is that it can handle many failure scenarios 1462 allowing the ITR to determine when the path to a specific Locator is 1463 reachable or has become unreachable, thus providing a robust 1464 mechanism for switching to using another Locator from the cached 1465 Locator. RLOC-Probing can also provide rough Round-Trip Time (RTT) 1466 estimates between a pair of Locators, which can be useful for network 1467 management purposes as well as for selecting low delay paths. The 1468 major disadvantage of RLOC-Probing is in the number of control 1469 messages required and the amount of bandwidth used to obtain those 1470 benefits, especially if the requirement for failure detection times 1471 is very small. 1473 8. Interactions with Other LISP Components 1475 8.1. ITR EID-to-RLOC Mapping Resolution 1477 An ITR is configured with one or more Map-Resolver addresses. These 1478 addresses are "Locators" (or RLOCs) and MUST be routable on the 1479 underlying core network; they MUST NOT need to be resolved through 1480 LISP EID-to-RLOC mapping, as that would introduce a circular 1481 dependency. When using a Map-Resolver, an ITR does not need to 1482 connect to any other database mapping system. In particular, the ITR 1483 need not connect to the LISP-ALT infrastructure or implement the BGP 1484 and GRE protocols that it uses. 1486 An ITR sends an Encapsulated Map-Request to a configured Map-Resolver 1487 when it needs an EID-to-RLOC mapping that is not found in its local 1488 Map-Cache. Using the Map-Resolver greatly reduces both the 1489 complexity of the ITR implementation and the costs associated with 1490 its operation. 1492 In response to an Encapsulated Map-Request, the ITR can expect one of 1493 the following: 1495 o An immediate Negative Map-Reply (with action code of "Natively- 1496 Forward", 15-minute Time to Live (TTL)) from the Map-Resolver if 1497 the Map-Resolver can determine that the requested EID does not 1498 exist. The ITR saves the EID-Prefix returned in the Map-Reply in 1499 its cache, marks it as non-LISP-capable, and knows not to attempt 1500 LISP encapsulation for destinations matching it. 1502 o A Negative Map-Reply, with action code of "Natively-Forward", from 1503 a Map-Server that is authoritative (within the LISP deployment 1504 Section 1.1) for an EID-Prefix that matches the requested EID but 1505 that does not have an actively registered, more-specific EID- 1506 prefix. In this case, the requested EID is said to match a "hole" 1507 in the authoritative EID-Prefix. If the requested EID matches a 1508 more-specific EID-Prefix that has been delegated by the Map-Server 1509 but for which no ETRs are currently registered, a 1-minute TTL is 1510 returned. If the requested EID matches a non-delegated part of 1511 the authoritative EID-Prefix, then it is not a LISP EID and a 1512 15-minute TTL is returned. See Section 8.2 for discussion of 1513 aggregate EID-Prefixes and details of Map-Server EID-Prefix 1514 matching. 1516 o A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or 1517 possibly from a Map-Server answering on behalf of the ETR. See 1518 Section 8.4 for more details on Map-Resolver message processing. 1520 Note that an ITR may be configured to both use a Map-Resolver and to 1521 participate in a LISP-ALT logical network. In such a situation, the 1522 ITR SHOULD send Map-Requests through the ALT network for any EID- 1523 Prefix learned via ALT BGP. Such a configuration is expected to be 1524 very rare, since there is little benefit to using a Map-Resolver if 1525 an ITR is already using LISP-ALT. There would be, for example, no 1526 need for such an ITR to send a Map-Request to a possibly non-existent 1527 EID (and rely on Negative Map-Replies) if it can consult the ALT 1528 database to verify that an EID-Prefix is present before sending that 1529 Map-Request. 1531 8.2. EID-Prefix Configuration and ETR Registration 1533 An ETR publishes its EID-Prefixes on a Map-Server by sending LISP 1534 Map-Register messages. A Map-Register message includes 1535 authentication data, so prior to sending a Map-Register message, the 1536 ETR and Map-Server MUST be configured with a pre-shared secret used 1537 to derive Map-Register authentication keys. A Map-Server's 1538 configuration SHOULD also include a list of the EID-Prefixes for 1539 which each ETR is authoritative. Upon receipt of a Map-Register from 1540 an ETR, a Map-Server accepts only EID-Prefixes that are configured 1541 for that ETR. Failure to implement such a check would leave the 1542 mapping system vulnerable to trivial EID-Prefix hijacking attacks. 1544 In addition to the set of EID-Prefixes defined for each ETR that may 1545 register, a Map-Server is typically also configured with one or more 1546 aggregate prefixes that define the part of the EID numbering space 1547 assigned to it. When LISP-ALT is the database in use, aggregate EID- 1548 Prefixes are implemented as discard routes and advertised into ALT 1549 BGP. The existence of aggregate EID-Prefixes in a Map-Server's 1550 database means that it may receive Map Requests for EID-Prefixes that 1551 match an aggregate but do not match a registered prefix; Section 8.3 1552 describes how this is handled. 1554 Map-Register messages are sent periodically from an ETR to a Map- 1555 Server with a suggested interval between messages of one minute. A 1556 Map-Server SHOULD time out and remove an ETR's registration if it has 1557 not received a valid Map-Register message within the past 1558 three minutes. When first contacting a Map-Server after restart or 1559 changes to its EID-to-RLOC database mappings, an ETR MAY initially 1560 send Map-Register messages at an increased frequency, up to one every 1561 20 seconds. This "quick registration" period is limited to 1562 five minutes in duration. 1564 An ETR MAY request that a Map-Server explicitly acknowledge receipt 1565 and processing of a Map-Register message by setting the "want-map- 1566 notify" (M-bit) flag. A Map-Server that receives a Map-Register with 1567 this flag set will respond with a Map-Notify message. Typical use of 1568 this flag by an ETR would be to set it for Map-Register messages sent 1569 during the initial "quick registration" with a Map-Server but then 1570 set it only occasionally during steady-state maintenance of its 1571 association with that Map-Server. Note that the Map-Notify message 1572 is sent to UDP destination port 4342, not to the source port 1573 specified in the original Map-Register message. 1575 Note that a one-minute minimum registration interval during 1576 maintenance of an ETR-Map-Server association places a lower bound on 1577 how quickly and how frequently a mapping database entry can be 1578 updated. This may have implications for what sorts of mobility can 1579 be supported directly by the mapping system; shorter registration 1580 intervals or other mechanisms might be needed to support faster 1581 mobility in some cases. For a discussion on one way that faster 1582 mobility may be implemented for individual devices, please see 1583 [I-D.ietf-lisp-mn]. 1585 An ETR MAY also request, by setting the "proxy Map-Reply" flag 1586 (P-bit) in the Map-Register message, that a Map-Server answer Map- 1587 Requests instead of forwarding them to the ETR. See Section 7.1 for 1588 details on how the Map-Server sets certain flags (such as those 1589 indicating whether the message is authoritative and how returned 1590 Locators SHOULD be treated) when sending a Map-Reply on behalf of an 1591 ETR. When an ETR requests proxy reply service, it SHOULD include all 1592 RLOCs for all ETRs for the EID-Prefix being registered, along with 1593 the routable flag ("R-bit") setting for each RLOC. The Map-Server 1594 includes all of this information in Map-Reply messages that it sends 1595 on behalf of the ETR. This differs from a non-proxy registration, 1596 since the latter need only provide one or more RLOCs for a Map-Server 1597 to use for forwarding Map-Requests; the registration information is 1598 not used in Map-Replies, so it being incomplete is not incorrect. 1600 An ETR that uses a Map-Server to publish its EID-to-RLOC mappings 1601 does not need to participate further in the mapping database 1602 protocol(s). When using a LISP-ALT mapping database, for example, 1603 this means that the ETR does not need to implement GRE or BGP, which 1604 greatly simplifies its configuration and reduces its cost of 1605 operation. 1607 Note that use of a Map-Server does not preclude an ETR from also 1608 connecting to the mapping database (i.e., it could also connect to 1609 the LISP-ALT network), but doing so doesn't seem particularly useful, 1610 as the whole purpose of using a Map-Server is to avoid the complexity 1611 of the mapping database protocols. 1613 8.3. Map-Server Processing 1615 Once a Map-Server has EID-Prefixes registered by its client ETRs, it 1616 can accept and process Map-Requests for them. 1618 In response to a Map-Request, the Map-Server first checks to see if 1619 the destination EID matches a configured EID-Prefix. If there is no 1620 match, the Map-Server returns a Negative Map-Reply with action code 1621 "Natively-Forward" and a 15-minute TTL. This can occur if a Map 1622 Request is received for a configured aggregate EID-Prefix for which 1623 no more-specific EID-Prefix exists; it indicates the presence of a 1624 non-LISP "hole" in the aggregate EID-Prefix. 1626 Next, the Map-Server checks to see if any ETRs have registered the 1627 matching EID-Prefix. If none are found, then the Map-Server returns 1628 a Negative Map-Reply with action code "Natively-Forward" and a 1629 1-minute TTL. 1631 If the EID-prefix is either registered or not registered to the 1632 mapping system and there is a policy in the Map-Server to have the 1633 requestor drop packets for the matching EID-prefix, then a Drop/ 1634 Policy-Denied action is returned. If the EID-prefix is registered or 1635 not registered and there is a authentication failure, then a Drop/ 1636 Authentication- failure action is returned. If either of these 1637 actions result as a temporary state in policy or authentication then 1638 a Send-Map-Request action with 1-minute TTL MAY be returned to allow 1639 the requestor to retry the Map-Request. 1641 If any of the registered ETRs for the EID-Prefix have requested proxy 1642 reply service, then the Map-Server answers the request instead of 1643 forwarding it. It returns a Map-Reply with the EID-Prefix, RLOCs, 1644 and other information learned through the registration process. 1646 If none of the ETRs have requested proxy reply service, then the Map- 1647 Server re-encapsulates and forwards the resulting Encapsulated Map- 1648 Request to one of the registered ETRs. It does not otherwise alter 1649 the Map-Request, so any Map-Reply sent by the ETR is returned to the 1650 RLOC in the Map-Request, not to the Map-Server. Unless also acting 1651 as a Map-Resolver, a Map-Server should never receive Map-Replies; any 1652 such messages SHOULD be discarded without response, perhaps 1653 accompanied by the logging of a diagnostic message if the rate of 1654 Map-Replies is suggestive of malicious traffic. 1656 8.4. Map-Resolver Processing 1658 Upon receipt of an Encapsulated Map-Request, a Map-Resolver 1659 decapsulates the enclosed message and then searches for the requested 1660 EID in its local database of mapping entries (statically configured 1661 or learned from associated ETRs if the Map-Resolver is also a Map- 1662 Server offering proxy reply service). If it finds a matching entry, 1663 it returns a LISP Map-Reply with the known mapping. 1665 If the Map-Resolver does not have the mapping entry and if it can 1666 determine that the EID is not in the mapping database (for example, 1667 if LISP-ALT is used, the Map-Resolver will have an ALT forwarding 1668 table that covers the full EID space), it immediately returns a 1669 negative LISP Map-Reply, with action code "Natively-Forward" and a 1670 15-minute TTL. To minimize the number of negative cache entries 1671 needed by an ITR, the Map-Resolver SHOULD return the least-specific 1672 prefix that both matches the original query and does not match any 1673 EID-Prefix known to exist in the LISP-capable infrastructure. 1675 If the Map-Resolver does not have sufficient information to know 1676 whether the EID exists, it needs to forward the Map-Request to 1677 another device that has more information about the EID being 1678 requested. To do this, it forwards the unencapsulated Map-Request, 1679 with the original ITR RLOC as the source, to the mapping database 1680 system. Using LISP-ALT, the Map-Resolver is connected to the ALT 1681 network and sends the Map-Request to the next ALT hop learned from 1682 its ALT BGP neighbors. The Map-Resolver does not send any response 1683 to the ITR; since the source RLOC is that of the ITR, the ETR or Map- 1684 Server that receives the Map-Request over the ALT and responds will 1685 do so directly to the ITR. 1687 8.4.1. Anycast Operation 1689 A Map-Resolver can be set up to use "anycast", where the same address 1690 is assigned to multiple Map-Resolvers and is propagated through IGP 1691 routing, to facilitate the use of a topologically close Map-Resolver 1692 by each ITR. 1694 ETRs MAY have anycast RLOC addresses which are registered as part of 1695 their RLOC-set to the mapping system. However, registrations MUST 1696 use their unique RLOC addresses or distinct authentication keys to 1697 identify security associations with the Map-Servers. 1699 9. Security Considerations 1701 A LISP threat analysis can be found in [RFC7835]. In what follows we 1702 highlight security considerations that apply when LISP is deployed in 1703 environments such as those specified in Section 1.1, where the 1704 following assumptions hold: 1706 1. The Mapping System is secure and trusted, and for the purpose of 1707 this security considerations the Mapping System is considered as 1708 one trusted element. 1710 2. The ETRs have a pre-configured trust relationship with the 1711 Mapping System, which includes some form of shared secret, and 1712 the Mapping System is aware of which EIDs an ETR can advertise. 1713 How those keys and mappings gets established is out of the scope 1714 of this document. 1716 3. LISP-SEC [I-D.ietf-lisp-sec] MUST be implemented. Network 1717 operartors should carefully weight how the LISP-SEC threat model 1718 applies to their particular use case or deployment. If they 1719 decide to ignore a particular recommendation, they should make 1720 sure the risk associated with the corresponding threats is well 1721 understood. 1723 The Map-Request/Map-Reply message exchange can be exploited by an 1724 attacker to mount DoS and/or amplification attacks. Attackers can 1725 send Map-Requests at high rates to overload LISP nodes and increase 1726 the state maintained by such nodes or consume CPU cycles. Such 1727 threats can be mitigated by systematically applying filters and rate 1728 limiters. 1730 The Map-Request/Map-Reply message exchange to inject forged mappings 1731 directly in the ITR EID-to-RLOC map-cache. This can lead to traffic 1732 being redirected to the attacker, see further details in [RFC7835]. 1733 In addition, valid ETRs in the system can perform overclaiming 1734 attacks. In this case, attackers can claim to own an EID-prefix that 1735 is larger than the prefix owned by the ETR. Such attacks can be 1736 addressed by using LISP-SEC [I-D.ietf-lisp-sec]. The LISP-SEC 1737 protocol defines a mechanism for providing origin authentication, 1738 integrity, anti-replay, protection, and prevention of 'man-in-the- 1739 middle' and 'prefix overclaiming' attacks on the Map-Request/Map- 1740 Reply exchange. In addition and while beyond the scope of securing 1741 an individual Map-Server or Map-Resolver, it should be noted that 1742 LISP-SEC can be complemented by additional security mechanisms 1743 defined by the Mapping System Infrastructure. For instance, BGP- 1744 based LISP-ALT [RFC6836] can take advantage of standards work on 1745 adding security to BGP while LISP-DDT [RFC8111] defines its own 1746 additional security mechanisms. 1748 To publish an authoritative EID-to-RLOC mapping with a Map-Server 1749 using the Map-Register message, an ETR includes authentication data 1750 that is a MAC of the entire message using a key derived from the pre- 1751 shared secret. An implementation MUST support HMAC-SHA256-128+HKDF- 1752 SHA256 [RFC4868]. The Map-Register message includes protection for 1753 replay attacks by a man-in-the-middle. However, a compromised ETR 1754 can overclaim the prefix it owns and successfully register it on its 1755 corresponding Map-Server. To mitigate this and as noted in 1756 Section 8.2, a Map-Server MUST verify that all EID-Prefixes 1757 registered by an ETR match the configuration stored on the Map- 1758 Server. 1760 Deployments concerned about manipulations of Map-Request and Map- 1761 Reply messages, and malicious ETR EID prefix overclaiming MUST drop 1762 LISP Control Plane messages that do not contain LISP-SEC material 1763 (S-bit, EID-AD, OTK-AD, PKT-AD). 1765 Encrypting control messages via DTLS [RFC6347] or LISP-crypto 1766 [RFC8061] SHOULD be used to support privacy to prevent eavesdroping 1767 and packet tampering for messages exchanged between xTRs, xTRs and 1768 the mapping system, and nodes that make up the mapping system. 1770 10. Privacy Considerations 1772 As noted by [RFC6973] privacy is a complex issue that greatly depends 1773 on the specific protocol use-case and deployment. As noted in 1774 section 1.1 of [I-D.ietf-lisp-rfc6830bis] LISP focuses on use-cases 1775 where entities communicate over the public Internet while keeping 1776 separate addressing and topology. In what follows we detail the 1777 privacy threats introduced by the LISP Control Plane, the analysis is 1778 based on the guidelines detailed in [RFC6973]. 1780 LISP can use long-lived identifiers (EIDs) that survive mobility 1781 events. Such identifiers bind to the RLOCs of the nodes, which 1782 represents the topological location with respect to the specific LISP 1783 deployments. In addition, EID-to-RLOC mappings are typically 1784 considered public information within the LISP deployment when 1785 control-plane messages are not encrypted, and can be eavesdropped 1786 while Map-Request messages are sent to the corresponding Map- 1787 Resolvers or Map-Register messages to Map-Servers. 1789 In this context, attackers can correlate the EID with the RLOC and 1790 track the corresponding user topological location and/or mobility. 1791 This can be achieved by off-path attackers, if they are 1792 authenticated, by querying the mapping system. Deployments concerned 1793 about this threat can use access control-lists or stronger 1794 authentication mechanisms [I-D.ietf-lisp-ecdsa-auth] in the mapping 1795 system to make sure that only authorized users can access this 1796 information (data minimization). Use of ephemeral EIDs 1797 [I-D.ietf-lisp-eid-anonymity] to achieve anonymity is another 1798 mechanism to lessen persistency and identity tracking. 1800 11. Changes since RFC 6833 1802 For implementation considerations, the following changes have been 1803 made to this document since RFC 6833 was published: 1805 o A Map-Notify-Ack message is added in this document to provide 1806 reliability for Map-Notify messages. Any receiver of a Map-Notify 1807 message must respond with a Map-Notify-Ack message. Map-Servers 1808 who are senders of Map-Notify messages, must queue the Map-Notify 1809 contents until they receive a Map-Notify-Ack with the nonce used 1810 in the Map-Notify message. Note that implementations for Map- 1811 Notify-Ack support already exist and predate this document. 1813 o This document is incorporating the codepoint for the Map-Referral 1814 message from the LISP-DDT specification [RFC8111] to indicate that 1815 a Map-Server must send the final Map-Referral message when it 1816 participates in the LISP-DDT mapping system procedures. 1818 o The "m", "I", "L", and "D" bits are added to the Map-Request 1819 message. See Section 5.3 for details. 1821 o The "S", "I", "E", "T", "a", and "m" bits are added to the Map- 1822 Register message. See Section 5.6 for details. 1824 o The 16-bit Key-ID field of the Map-Register message has been split 1825 into a 8-bit Key-ID field and a 8-bit Algorithm-ID field. 1827 o This document adds two new Action values that are in an EID-record 1828 that appear in Map-Reply, Map-Register, Map-Notify, and Map- 1829 Notify-Ack messages. The Drop/Policy-Denied and Drop/Auth-Failure 1830 are the descriptions for the two new action values. See 1831 Section 5.4 for details. 1833 12. IANA Considerations 1835 This section provides guidance to the Internet Assigned Numbers 1836 Authority (IANA) regarding registration of values related to this 1837 LISP Control-Plane specification, in accordance with BCP 26 1838 [RFC8126]. 1840 There are three namespaces (listed in the sub-sections below) in LISP 1841 that have been registered. 1843 o LISP IANA registry allocations should not be made for purposes 1844 unrelated to LISP routing or transport protocols. 1846 o The following policies are used here with the meanings defined in 1847 BCP 26: "Specification Required", "IETF Review", "Experimental 1848 Use", and "First Come First Served". 1850 12.1. LISP UDP Port Numbers 1852 The IANA registry has allocated UDP port number 4342 for the LISP 1853 Control-Plane. IANA has updated the description for UDP port 4342 as 1854 follows: 1856 Keyword Port Transport Layer Description 1857 ------- ---- --------------- ----------- 1858 lisp-control 4342 udp LISP Control Packets 1860 12.2. LISP Packet Type Codes 1862 It is being requested that the IANA be authoritative for LISP Packet 1863 Type definitions and it is requested to replace the [RFC6830] 1864 registry message references with the RFC number assigned to this 1865 document. 1867 Based on deployment experience of [RFC6830], the Map-Notify-Ack 1868 message, message type 5, was added by this document. This document 1869 requests IANA to add it to the LISP Packet Type Registry. 1871 Name Number Defined in 1872 ---- ------ ----------- 1873 LISP Map-Notify-Ack 5 RFC6833bis 1875 12.3. LISP ACT and Flag Fields 1877 New ACT values can be allocated through IETF review or IESG approval. 1878 Four values have already been allocated by [RFC6830], IANA is 1879 requested to replace the [RFC6830] reference for this registry with 1880 the RFC number assigned to this document and the [RFC6830]. Action 1881 values references with the RFC number assigned to this document. 1882 This specification changes the name of ACT type 3 value from "Drop" 1883 to "Drop/No-Reason" as well as adding two new ACT values, the "Drop/ 1884 Policy-Denied" (type 4) and "Drop/Authentication-Failure" (type 5). 1886 +-------+--------------------+-------------------------+------------+ 1887 | Value | Action | Description | Raeference | 1888 +-------+--------------------+-------------------------+------------+ 1889 | 4 | Drop/Policy-Denied | A packet matching this | RFC6833bis | 1890 | | | Map-Cache entry is | | 1891 | | | dropped because the | | 1892 | | | target EWID is policy- | | 1893 | | | denied by the xTR or | | 1894 | | | the mapping system. | | 1895 | 5 | Drop/Auth-Failure | Packet matching the | RFC6833bis | 1896 | | | Map-Cache entry is | | 1897 | | | dropped beacuse the | | 1898 | | | Map-Request for the | | 1899 | | | target EID fails an | | 1900 | | | authentication check by | | 1901 | | | the xTR or the mapping | | 1902 | | | system. | | 1903 +-------+--------------------+-------------------------+------------+ 1905 LISP Map-Reply Action Values 1907 In addition, LISP has a number of flag fields and reserved fields, 1908 such as the LISP header flags field [I-D.ietf-lisp-rfc6830bis]. New 1909 bits for flags in these fields can be implemented after IETF review 1910 or IESG approval, but these need not be managed by IANA. 1912 12.4. LISP Address Type Codes 1914 LISP Canonical Address Format (LCAF) [RFC8060] is an 8-bit field that 1915 defines LISP-specific encodings for AFI value 16387. LCAF encodings 1916 are used for specific use-cases where different address types for 1917 EID-records and RLOC-records are required. 1919 The IANA registry "LISP Canonical Address Format (LCAF) Types" is 1920 used for LCAF types. The registry for LCAF types use the 1921 Specification Required policy [RFC8126]. Initial values for the 1922 registry as well as further information can be found in [RFC8060]. 1924 Therefore, there is no longer a need for the "LISP Address Type 1925 Codes" registry requested by [RFC6830]. This document requests to 1926 remove it. 1928 12.5. LISP Algorithm ID Numbers 1930 In [RFC6830], a request for a "LISP Key ID Numbers" registry was 1931 submitted. This document renames the registry to "LISP Algorithm ID 1932 Numbers" and requests the IANA to make the name change. 1934 The following Algorithm ID values are defined by this specification 1935 as used in any packet type that references a 'Algorithm ID' field: 1937 Name Number MAC KDF 1938 ------------------------------------------------------- 1939 None 0 None None 1940 HMAC-SHA-1-96-None 1 [RFC2404] None 1941 HMAC-SHA-256-128-None 2 [RFC4868] None 1942 HMAC-SHA256-128+HKDF-SHA2562 3 [RFC4868] [RFC4868] 1944 Number values are in the range of 0 to 255. The allocation of values 1945 is on a first come first served basis. 1947 12.6. LISP Bit Flags 1949 This document asks IANA to create a registry for allocation of bits 1950 in several headers of the LISP control plane, namely in the Map- 1951 Request, Map-Reply, Map-Register, Encapsulated Control Message (ECM) 1952 messages. Bit allocations are also requested for EID-records and 1953 RLOC-records. The registry created should be named "LISP Control 1954 Plane Header Bits". A sub-registry needs to be created per each 1955 message and record. The name of each sub-registry is indicated 1956 below, along with its format and allocation of bits defined in this 1957 document. Any additional bits allocation, requires a specification, 1958 according with [RFC8126] policies. 1960 Sub-Registry: Map-Request Header Bits [Section 5.2]: 1962 0 1 2 3 1963 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 1964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1965 |Type=1 |A|M|P|S|p|s|R|R| Rsvd |L|D| IRC | Record Count | 1966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1967 +----------+---------------+------------+---------------------------+ 1968 | Spec | IANA Name | Bit | Description | 1969 | Name | | Position | | 1970 +----------+---------------+------------+---------------------------+ 1971 | A | map-request-A | 4 | Authoritative Bit | 1972 | M | map-request-M | 5 | Map Data Present Bit | 1973 | P | map-request-P | 6 | RLOC-Probe Request Bit | 1974 | S | map-request-S | 7 | Solicit Map-Request (SMR) | 1975 | | | | Bit | 1976 | p | map-request-p | 8 | Proxy-ITR Bit | 1977 | s | map-request-s | 9 | Solicit Map-Request | 1978 | | | | Invoked Bit | 1979 | L | map-request-L | 17 | Local xTR Bit | 1980 | D | map-request-D | 18 | Don't Map-Reply Bit | 1981 +----------+---------------+------------+---------------------------+ 1983 LISP Map-Request Header Bits 1985 Sub-Registry: Map-Reply Header Bits [Section 5.4]: 1987 0 1 2 3 1988 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 1989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1990 |Type=2 |P|E|S| Reserved | Record Count | 1991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1993 +-----------+-------------+--------------+------------------------+ 1994 | Spec Name | IANA Name | Bit Position | Description | 1995 +-----------+-------------+--------------+------------------------+ 1996 | P | map-reply-P | 4 | RLOC-Probe Bit | 1997 | E | map-reply-E | 5 | Echo Nonce Capable Bit | 1998 | S | map-reply-S | 6 | Security Bit | 1999 +-----------+-------------+--------------+------------------------+ 2001 LISP Map-Reply Header Bits 2003 Sub-Registry: Map-Register Header Bits [Section 5.6]: 2005 0 1 2 3 2006 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 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2008 |Type=3 |P|S|I| Reserved |E|T|a|R|M| Record Count | 2009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2010 +-----------+----------------+--------------+----------------------+ 2011 | Spec Name | IANA Name | Bit Position | Description | 2012 +-----------+----------------+--------------+----------------------+ 2013 | P | map-register-P | 4 | Proxy Map-Reply Bit | 2014 | S | map-register-S | 5 | LISP-SEC Capable Bit | 2015 | I | map-register-I | 6 | xTR-ID present flag | 2016 +-----------+----------------+--------------+----------------------+ 2018 LISP Map-Register Header Bits 2020 Sub-Registry: Encapsulated Control Message (ECM) Header Bits 2021 [Section 5.8]: 2023 0 1 2 3 2024 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 2025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2026 |Type=8 |S|D|E|M| Reserved | 2027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2029 +-----------+-----------+--------------+----------------------------+ 2030 | Spec Name | IANA Name | Bit Position | Description | 2031 +-----------+-----------+--------------+----------------------------+ 2032 | S | ecm-S | 4 | Security Bit | 2033 | D | ecm-D | 5 | LISP-DDT Bit | 2034 | E | ecm-E | 6 | Forward to ETR Bit | 2035 | M | ecm-M | 7 | Destined to Map-Server Bit | 2036 +-----------+-----------+--------------+----------------------------+ 2038 LISP Encapsulated Control Message (ECM) Header Bits 2040 Sub-Registry: EID-Record Header Bits [Section 5.4]: 2042 0 1 2 3 2043 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 2044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2045 | Locator Count | EID mask-len | ACT |A| Reserved | 2046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2048 +-----------+--------------+--------------+-------------------+ 2049 | Spec Name | IANA Name | Bit Position | Description | 2050 +-----------+--------------+--------------+-------------------+ 2051 | A | eid-record-A | 19 | Authoritative Bit | 2052 +-----------+--------------+--------------+-------------------+ 2054 LISP EID-Record Header Bits 2056 Sub-Registry: RLOC-Record Header Bits [Section 5.4]: 2058 0 1 2 3 2059 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 2060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2061 | Unused Flags |L|p|R| Loc-AFI | 2062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2064 +-----------+---------------+--------------+----------------------+ 2065 | Spec Name | IANA Name | Bit Position | Description | 2066 +-----------+---------------+--------------+----------------------+ 2067 | L | rloc-record-L | 13 | Local RLOC Bit | 2068 | p | rloc-record-p | 19 | RLOC-Probe Reply Bit | 2069 | R | rloc-record-R | 19 | RLOC Reachable Bit | 2070 +-----------+---------------+--------------+----------------------+ 2072 LISP RLOC-Record Header Bits 2074 13. References 2076 13.1. Normative References 2078 [I-D.ietf-lisp-6834bis] 2079 Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID 2080 Separation Protocol (LISP) Map-Versioning", draft-ietf- 2081 lisp-6834bis-03 (work in progress), February 2019. 2083 [I-D.ietf-lisp-rfc6830bis] 2084 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 2085 Cabellos-Aparicio, "The Locator/ID Separation Protocol 2086 (LISP)", draft-ietf-lisp-rfc6830bis-26 (work in progress), 2087 November 2018. 2089 [I-D.ietf-lisp-rfc8113bis] 2090 Boucadair, M. and C. Jacquenet, "Locator/ID Separation 2091 Protocol (LISP): Shared Extension Message & IANA Registry 2092 for Packet Type Allocations", draft-ietf-lisp- 2093 rfc8113bis-03 (work in progress), January 2019. 2095 [I-D.ietf-lisp-sec] 2096 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 2097 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-18 2098 (work in progress), June 2019. 2100 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2101 Requirement Levels", BCP 14, RFC 2119, 2102 DOI 10.17487/RFC2119, March 1997, 2103 . 2105 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 2106 ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November 2107 1998, . 2109 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 2110 "Randomness Requirements for Security", BCP 106, RFC 4086, 2111 DOI 10.17487/RFC4086, June 2005, 2112 . 2114 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 2115 384, and HMAC-SHA-512 with IPsec", RFC 4868, 2116 DOI 10.17487/RFC4868, May 2007, 2117 . 2119 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2120 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2121 January 2012, . 2123 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 2124 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 2125 March 2017, . 2127 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2128 Writing an IANA Considerations Section in RFCs", BCP 26, 2129 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2130 . 2132 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2133 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2134 May 2017, . 2136 13.2. Informative References 2138 [AFI] "Address Family Identifier (AFIs)", ADDRESS FAMILY 2139 NUMBERS http://www.iana.org/assignments/address-family- 2140 numbers/address-family-numbers.xhtml?, Febuary 2007. 2142 [GTP-3GPP] 2143 "General Packet Radio System (GPRS) Tunnelling Protocol 2144 User Plane (GTPv1-U)", TS.29.281 2145 https://portal.3gpp.org/desktopmodules/Specifications/ 2146 SpecificationDetails.aspx?specificationId=1699, January 2147 2015. 2149 [I-D.herbert-intarea-ila] 2150 Herbert, T. and P. Lapukhov, "Identifier-locator 2151 addressing for IPv6", draft-herbert-intarea-ila-01 (work 2152 in progress), March 2018. 2154 [I-D.ietf-lisp-ecdsa-auth] 2155 Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA 2156 Authentication and Authorization", draft-ietf-lisp-ecdsa- 2157 auth-01 (work in progress), March 2019. 2159 [I-D.ietf-lisp-eid-anonymity] 2160 Farinacci, D., Pillay-Esnault, P., and W. Haddad, "LISP 2161 EID Anonymity", draft-ietf-lisp-eid-anonymity-06 (work in 2162 progress), April 2019. 2164 [I-D.ietf-lisp-eid-mobility] 2165 Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, 2166 F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a 2167 Unified Control Plane", draft-ietf-lisp-eid-mobility-04 2168 (work in progress), May 2019. 2170 [I-D.ietf-lisp-gpe] 2171 Maino, F., Lemon, J., Agarwal, P., Lewis, D., and M. 2172 Smith, "LISP Generic Protocol Extension", draft-ietf-lisp- 2173 gpe-06 (work in progress), September 2018. 2175 [I-D.ietf-lisp-introduction] 2176 Cabellos-Aparicio, A. and D. Saucez, "An Architectural 2177 Introduction to the Locator/ID Separation Protocol 2178 (LISP)", draft-ietf-lisp-introduction-13 (work in 2179 progress), April 2015. 2181 [I-D.ietf-lisp-mn] 2182 Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP 2183 Mobile Node", draft-ietf-lisp-mn-05 (work in progress), 2184 March 2019. 2186 [I-D.ietf-lisp-pubsub] 2187 Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., 2188 Cabellos-Aparicio, A., Barkai, S., Farinacci, D., 2189 Boucadair, M., Jacquenet, C., and S. Secci, "Publish/ 2190 Subscribe Functionality for LISP", draft-ietf-lisp- 2191 pubsub-03 (work in progress), March 2019. 2193 [I-D.ietf-nvo3-vxlan-gpe] 2194 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 2195 Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-07 (work 2196 in progress), April 2019. 2198 [I-D.ietf-opsec-icmp-filtering] 2199 Gont, F., Gont, G., and C. Pignataro, "Recommendations for 2200 filtering ICMP messages", draft-ietf-opsec-icmp- 2201 filtering-04 (work in progress), July 2013. 2203 [I-D.meyer-loc-id-implications] 2204 Meyer, D. and D. Lewis, "Architectural Implications of 2205 Locator/ID Separation", draft-meyer-loc-id-implications-01 2206 (work in progress), January 2009. 2208 [RFC1035] Mockapetris, P., "Domain names - implementation and 2209 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2210 November 1987, . 2212 [RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the 2213 Internet checksum", RFC 1071, DOI 10.17487/RFC1071, 2214 September 1988, . 2216 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 2217 Hashing for Message Authentication", RFC 2104, 2218 DOI 10.17487/RFC2104, February 1997, 2219 . 2221 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 2222 RFC 2890, DOI 10.17487/RFC2890, September 2000, 2223 . 2225 [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report 2226 from the IAB Workshop on Routing and Addressing", 2227 RFC 4984, DOI 10.17487/RFC4984, September 2007, 2228 . 2230 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 2231 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 2232 DOI 10.17487/RFC6234, May 2011, 2233 . 2235 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 2236 Locator/ID Separation Protocol (LISP)", RFC 6830, 2237 DOI 10.17487/RFC6830, January 2013, 2238 . 2240 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 2241 Locator/ID Separation Protocol (LISP) for Multicast 2242 Environments", RFC 6831, DOI 10.17487/RFC6831, January 2243 2013, . 2245 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 2246 "Interworking between Locator/ID Separation Protocol 2247 (LISP) and Non-LISP Sites", RFC 6832, 2248 DOI 10.17487/RFC6832, January 2013, 2249 . 2251 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 2252 "Locator/ID Separation Protocol Alternative Logical 2253 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 2254 January 2013, . 2256 [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to 2257 Routing Locator (RLOC) Database", RFC 6837, 2258 DOI 10.17487/RFC6837, January 2013, 2259 . 2261 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 2262 Morris, J., Hansen, M., and R. Smith, "Privacy 2263 Considerations for Internet Protocols", RFC 6973, 2264 DOI 10.17487/RFC6973, July 2013, 2265 . 2267 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 2268 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 2269 eXtensible Local Area Network (VXLAN): A Framework for 2270 Overlaying Virtualized Layer 2 Networks over Layer 3 2271 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 2272 . 2274 [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID 2275 Separation Protocol (LISP) Threat Analysis", RFC 7835, 2276 DOI 10.17487/RFC7835, April 2016, 2277 . 2279 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 2280 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 2281 February 2017, . 2283 [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol 2284 (LISP) Data-Plane Confidentiality", RFC 8061, 2285 DOI 10.17487/RFC8061, February 2017, 2286 . 2288 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 2289 Smirnov, "Locator/ID Separation Protocol Delegated 2290 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 2291 May 2017, . 2293 [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID 2294 Separation Protocol (LISP) Multicast", RFC 8378, 2295 DOI 10.17487/RFC8378, May 2018, 2296 . 2298 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 2299 Decraene, B., Litkowski, S., and R. Shakir, "Segment 2300 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 2301 July 2018, . 2303 Appendix A. Acknowledgments 2305 The original authors would like to thank Greg Schudel, Darrel Lewis, 2306 John Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper 2307 Skriver, Fabio Maino, and members of the lisp@ietf.org mailing list 2308 for their feedback and helpful suggestions. 2310 Special thanks are due to Noel Chiappa for his extensive work and 2311 thought about caching in Map-Resolvers. 2313 The current authors would like to give a sincere thank you to the 2314 people who help put LISP on standards track in the IETF. They 2315 include Joel Halpern, Luigi Iannone, Deborah Brungard, Fabio Maino, 2316 Scott Bradner, Kyle Rose, Takeshi Takahashi, Sarah Banks, Pete 2317 Resnick, Colin Perkins, Mirja Kuhlewind, Francis Dupont, Benjamin 2318 Kaduk, Eric Rescorla, Alvaro Retana, Alexey Melnikov, Alissa Cooper, 2319 Suresh Krishnan, Alberto Rodriguez-Natal, Vina Ermagen, Mohamed 2320 Boucadair, Brian Trammell, Sabrina Tanamal, and John Drake. The 2321 contributions they offered greatly added to the security, scale, and 2322 robustness of the LISP architecture and protocols. 2324 Appendix B. Document Change Log 2326 [RFC Editor: Please delete this section on publication as RFC.] 2328 B.1. Changes to draft-ietf-lisp-rfc6833bis-25 2330 o Posted June 2019. 2332 o Added change requested by Mirja describing Record Count in an EID- 2333 record. 2335 o Fixed Requirements Notation section per Pete. 2337 o Added KDF for shared-secret 2339 o Specified several rate-limiters for control messages 2341 B.2. Changes to draft-ietf-lisp-rfc6833bis-24 2343 o Posted February 2019. 2345 o Added suggested text from Albert that Benjamin Kaduk agreed with. 2347 o Added suggested editorial comments from Alvaro's rewview. 2349 o Ran document through IDnits. Fixed bugs found. 2351 B.3. Changes to draft-ietf-lisp-rfc6833bis-23 2353 o Posted December 2018. 2355 o Added to Security Considerations section that deployments that 2356 care about prefix over claiming should use LISP-SEC. 2358 o Added to Security Considerations section that DTLS or LISP-crypto 2359 be used for control-plane privacy. 2361 o Make LISP-SEC a normative reference. 2363 o Make it more clear where field descriptions are spec'ed when 2364 referencing to the same fields in other packet types. 2366 B.4. Changes to draft-ietf-lisp-rfc6833bis-22 2368 o Posted week after IETF November 2018. 2370 o No longer need to use IPSEC for replay attacks. 2372 B.5. Changes to draft-ietf-lisp-rfc6833bis-21 2374 o Posted early November 2018. 2376 o Added I-bit back in because its necessary to use for Map-Register 2377 replay attack scenarios. The Map-Server tracks the nonce per xTR- 2378 ID to detect duplicate or replayed Map-Register messages. 2380 B.6. Changes to draft-ietf-lisp-rfc6833bis-20 2382 o Posted late October 2018. 2384 o Changed description about "reserved" bits to state "reserved and 2385 unassigned". 2387 o Make it more clear how Map-Register nonce processing is performed 2388 in an ETR and Map-Server. 2390 B.7. Changes to draft-ietf-lisp-rfc6833bis-19 2392 o Posted mid October 2018. 2394 o Added Fabio text to the Security Considerations section. 2396 B.8. Changes to draft-ietf-lisp-rfc6833bis-18 2398 o Posted mid October 2018. 2400 o Fixed comments from Eric after more email clarity. 2402 B.9. Changes to draft-ietf-lisp-rfc6833bis-17 2404 o Posted early October 2018. 2406 o Changes to reflect comments from Sep 27th Telechat. 2408 o Added all flag bit definitions as request for allocation in IANA 2409 Considersations section. 2411 o Added an applicability statement in section 1 to address security 2412 concerns from Telechat. 2414 o Moved m-bit description and IANA request to draft-ietf-lisp-mn. 2416 o Moved I-bit description and IANA request to draft-ietf-lisp- 2417 pubsub. 2419 B.10. Changes to draft-ietf-lisp-rfc6833bis-16 2421 o Posted Late-September 2018. 2423 o Re-wrote Security Considerations section. Thanks Albert. 2425 o Added Alvaro text to be more clear about IANA actions. 2427 B.11. Changes to draft-ietf-lisp-rfc6833bis-15 2429 o Posted mid-September 2018. 2431 o Changes to reflect comments from Colin and Mirja. 2433 B.12. Changes to draft-ietf-lisp-rfc6833bis-14 2435 o Posted September 2018. 2437 o Changes to reflect comments from Genart, RTGarea, and Secdir 2438 reviews. 2440 B.13. Changes to draft-ietf-lisp-rfc6833bis-13 2442 o Posted August 2018. 2444 o Final editorial changes before RFC submission for Proposed 2445 Standard. 2447 o Added section "Changes since RFC 6833" so implementators are 2448 informed of any changes since the last RFC publication. 2450 B.14. Changes to draft-ietf-lisp-rfc6833bis-12 2452 o Posted late July 2018. 2454 o Moved RFC6830bis and RFC6834bis to Normative References. 2456 B.15. Changes to draft-ietf-lisp-rfc6833bis-11 2458 o Posted July 2018. 2460 o Fixed Luigi editorial comments to ready draft for RFC status and 2461 ran through IDNITs again. 2463 B.16. Changes to draft-ietf-lisp-rfc6833bis-10 2465 o Posted after LISP WG at IETF week March. 2467 o Move AD field encoding after S-bit in the ECM packet format 2468 description section. 2470 o Say more about when the new Drop actions should be sent. 2472 B.17. Changes to draft-ietf-lisp-rfc6833bis-09 2474 o Posted March IETF week 2018. 2476 o Fixed editorial comments submitted by document shepherd Luigi 2477 Iannone. 2479 B.18. Changes to draft-ietf-lisp-rfc6833bis-08 2481 o Posted March 2018. 2483 o Added RLOC-probing algorithm. 2485 o Added Solicit-Map Request algorithm. 2487 o Added several mechanisms (from 6830bis) regarding Routing Locator 2488 Reachability. 2490 o Added port 4342 to IANA Considerations section. 2492 B.19. Changes to draft-ietf-lisp-rfc6833bis-07 2494 o Posted December 2017. 2496 o Make it more clear in a couple of places that RLOCs are used to 2497 locate ETRs more so than for Map-Server Map-Request forwarding. 2499 o Make it clear that "encapsualted" for a control message is an ECM 2500 based message. 2502 o Make it more clear what messages use source-port 4342 and which 2503 ones use destinatino-port 4342. 2505 o Don't make DDT references when the mapping transport system can be 2506 of any type and the referneced text is general to it. 2508 o Generalize text when referring to the format of an EID-prefix. 2509 Can use othe AFIs then IPv4 and IPv6. 2511 o Many editorial changes to clarify text. 2513 o Changed some "must", "should", and "may" to capitalized. 2515 o Added definitions for Map-Request and Map-Reply messages. 2517 o Ran document through IDNITs. 2519 B.20. Changes to draft-ietf-lisp-rfc6833bis-06 2521 o Posted October 2017. 2523 o Spec the I-bit to include the xTR-ID in a Map-Request message to 2524 be consistent with the Map-Register message and to anticipate the 2525 introduction of pubsub functionality to allow Map-Requests to 2526 subscribe to RLOC-set changes. 2528 o Updated references for individual submissions that became working 2529 group documents. 2531 o Updated references for working group documents that became RFCs. 2533 B.21. Changes to draft-ietf-lisp-rfc6833bis-05 2535 o Posted May 2017. 2537 o Update IANA Considerations section based on new requests from this 2538 document and changes from what was requested in [RFC6830]. 2540 B.22. Changes to draft-ietf-lisp-rfc6833bis-04 2542 o Posted May 2017. 2544 o Clarify how the Key-ID field is used in Map-Register and Map- 2545 Notify messages. Break the 16-bit field into a 8-bit Key-ID field 2546 and a 8-bit Algorithm-ID field. 2548 o Move the Control-Plane codepoints from the IANA Considerations 2549 section of RFC6830bis to the IANA Considerations section of this 2550 document. 2552 o In the "LISP Control Packet Type Allocations" section, indicate 2553 how message Types are IANA allocated and how experimental RFC8113 2554 sub-types should be requested. 2556 B.23. Changes to draft-ietf-lisp-rfc6833bis-03 2558 o Posted April 2017. 2560 o Add types 9-14 and specify they are not assigned. 2562 o Add the "LISP Shared Extension Message" type and point to RFC8113. 2564 B.24. Changes to draft-ietf-lisp-rfc6833bis-02 2566 o Posted April 2017. 2568 o Clarify that the LISP Control-Plane document defines how the LISP 2569 Data-Plane uses Map-Requests with either the SMR-bit set or the 2570 P-bit set supporting mapping updates and RLOC-probing. Indicating 2571 that other Data-Planes can use the same mechanisms or their own 2572 defined mechanisms to achieve the same functionality. 2574 B.25. Changes to draft-ietf-lisp-rfc6833bis-01 2576 o Posted March 2017. 2578 o Include references to new RFCs published. 2580 o Remove references to self. 2582 o Change references from RFC6830 to RFC6830bis. 2584 o Add two new action/reasons to a Map-Reply has posted to the LISP 2585 WG mailing list. 2587 o In intro section, add refernece to I-D.ietf-lisp-introduction. 2589 o Removed Open Issues section and references to "experimental". 2591 B.26. Changes to draft-ietf-lisp-rfc6833bis-00 2593 o Posted December 2016. 2595 o Created working group document from draft-farinacci-lisp 2596 -rfc6833-00 individual submission. No other changes made. 2598 B.27. Changes to draft-farinacci-lisp-rfc6833bis-00 2600 o Posted November 2016. 2602 o This is the initial draft to turn RFC 6833 into RFC 6833bis. 2604 o The document name has changed from the "Locator/ID Separation 2605 Protocol (LISP) Map-Server Interface" to the "Locator/ID 2606 Separation Protocol (LISP) Control-Plane". 2608 o The fundamental change was to move the Control-Plane messages from 2609 RFC 6830 to this document in an effort so any IETF developed or 2610 industry created Data-Plane could use the LISP mapping system and 2611 Control-Plane. 2613 o Update Control-Plane messages to incorporate what has been 2614 implemented in products during the early phase of LISP development 2615 but wasn't able to make it into RFC6830 and RFC6833 to make the 2616 Experimental RFC deadline. 2618 o Indicate there may be nodes in the mapping system that are not MRs 2619 or MSs, that is a ALT-node or a DDT-node. 2621 o Include LISP-DDT in Map-Resolver section and explain how they 2622 maintain a referral-cache. 2624 o Removed open issue about additional state in Map-Servers. With 2625 [RFC8111], Map-Servers have the same registration state and can 2626 give Map-Resolvers complete information in ms-ack Map-Referral 2627 messages. 2629 o Make reference to the LISP Threats Analysis RFC [RFC7835]. 2631 Authors' Addresses 2633 Dino Farinacci 2634 lispers.net 2636 EMail: farinacci@gmail.com 2638 Fabio Maino 2639 Cisco Systems 2641 EMail: fmaino@cisco.com 2643 Vince Fuller 2644 vaf.net Internet Consulting 2646 EMail: vaf@vaf.net 2648 Albert Cabellos 2649 UPC/BarcelonaTech 2650 Campus Nord, C. Jordi Girona 1-3 2651 Barcelona, Catalunya 2652 Spain 2654 EMail: acabello@ac.upc.edu