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