idnits 2.17.1 draft-ietf-lisp-rfc6833bis-17.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC6833, but the abstract doesn't seem to mention this, which it should. -- The abstract seems to indicate that this document obsoletes RFC6830, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1732 has weird spacing: '...-Denied entry...' == Line 1737 has weird spacing: '...Failure entr...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: P: This is the probe-bit, which indicates that a Map-Request SHOULD be treated as a Locator reachability probe. The receiver SHOULD respond with a Map-Reply with the probe-bit set, indicating that the Map-Reply is a Locator reachability probe reply, with the nonce copied from the Map-Request. See RLOC-Probing Section 7.1 for more details. This RLOC-probe Map-Request MUST not be sent to the mapping system. If a Map-Resolver or Map-Server receives a Map-Request with the probe-bit set, it MUST drop the message. -- The document date (October 3, 2018) is 2026 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) == Outdated reference: A later version (-14) exists of draft-ietf-lisp-6834bis-02 == Outdated reference: A later version (-38) exists of draft-ietf-lisp-rfc6830bis-22 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 6071 == Outdated reference: A later version (-13) exists of draft-ietf-lisp-eid-mobility-02 == Outdated reference: A later version (-19) exists of draft-ietf-lisp-gpe-06 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-introduction-13 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-mn-03 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-pubsub-00 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-15 == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-06 -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) -- Obsolete informational reference (is this intentional?): RFC 8113 (Obsoleted by RFC 9304) Summary: 2 errors (**), 0 flaws (~~), 13 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Fuller 3 Internet-Draft D. Farinacci 4 Obsoletes: 6833 (if approved) Cisco Systems 5 Intended status: Standards Track A. Cabellos (Ed.) 6 Expires: April 6, 2019 UPC/BarcelonaTech 7 October 3, 2018 9 Locator/ID Separation Protocol (LISP) Control-Plane 10 draft-ietf-lisp-rfc6833bis-17 12 Abstract 14 This document describes the Control-Plane and Mapping Service for the 15 Locator/ID Separation Protocol (LISP), implemented by two new types 16 of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server 17 -- that provides a simplified "front end" for one or more Endpoint ID 18 to Routing Locator mapping databases. 20 By using this Control-Plane service interface and communicating with 21 Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and 22 Egress Tunnel Routers (ETRs) are not dependent on the details of 23 mapping database systems, which facilitates modularity with different 24 database designs. Since these devices implement the "edge" of the 25 LISP Control-Plane infrastructure, connecting EID addressable nodes 26 of a LISP site, their implementation and operational complexity 27 reduces the overall cost and effort of deploying LISP. 29 This document obsoletes RFC 6830 and 6833. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 6, 2019. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 67 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 68 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 6 69 5. LISP IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 8 70 5.1. LISP Control Packet Type Allocations . . . . . . . . . . 10 71 5.2. Map-Request Message Format . . . . . . . . . . . . . . . 11 72 5.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 14 73 5.4. Map-Reply Message Format . . . . . . . . . . . . . . . . 16 74 5.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 20 75 5.6. Map-Register Message Format . . . . . . . . . . . . . . . 23 76 5.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 26 77 5.8. Encapsulated Control Message Format . . . . . . . . . . . 28 78 6. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 30 79 6.1. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 30 80 7. Routing Locator Reachability . . . . . . . . . . . . . . . . 31 81 7.1. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 33 82 8. Interactions with Other LISP Components . . . . . . . . . . . 34 83 8.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 34 84 8.2. EID-Prefix Configuration and ETR Registration . . . . . . 35 85 8.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 37 86 8.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 38 87 8.4.1. Anycast Operation . . . . . . . . . . . . . . . . . . 38 88 9. Security Considerations . . . . . . . . . . . . . . . . . . . 39 89 10. Changes since RFC 6833 . . . . . . . . . . . . . . . . . . . 40 90 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 91 11.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 41 92 11.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 41 93 11.3. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 41 94 11.4. LISP Address Type Codes . . . . . . . . . . . . . . . . 42 95 11.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 42 96 11.6. LISP Bit Flags . . . . . . . . . . . . . . . . . . . . . 43 97 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 98 12.1. Normative References . . . . . . . . . . . . . . . . . . 46 99 12.2. Informative References . . . . . . . . . . . . . . . . . 46 100 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 51 101 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 51 102 B.1. Changes to draft-ietf-lisp-rfc6833bis-17 . . . . . . . . 51 103 B.2. Changes to draft-ietf-lisp-rfc6833bis-16 . . . . . . . . 51 104 B.3. Changes to draft-ietf-lisp-rfc6833bis-15 . . . . . . . . 51 105 B.4. Changes to draft-ietf-lisp-rfc6833bis-14 . . . . . . . . 52 106 B.5. Changes to draft-ietf-lisp-rfc6833bis-13 . . . . . . . . 52 107 B.6. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . 52 108 B.7. Changes to draft-ietf-lisp-rfc6833bis-11 . . . . . . . . 52 109 B.8. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . 52 110 B.9. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . 52 111 B.10. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 53 112 B.11. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 53 113 B.12. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 53 114 B.13. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 54 115 B.14. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 54 116 B.15. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 54 117 B.16. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 54 118 B.17. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 55 119 B.18. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 55 120 B.19. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 55 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 123 1. Introduction 125 The Locator/ID Separation Protocol [I-D.ietf-lisp-rfc6830bis] (see 126 also [I-D.ietf-lisp-introduction]) specifies an architecture and 127 mechanism for dynamic tunneling by logically separating the addresses 128 currently used by IP in two separate name spaces: Endpoint IDs 129 (EIDs), used within sites; and Routing Locators (RLOCs), used on the 130 transit networks that make up the Internet infrastructure. To 131 achieve this separation, LISP defines protocol mechanisms for mapping 132 from EIDs to RLOCs. In addition, LISP assumes the existence of a 133 database to store and propagate those mappings across mapping system 134 nodes. Several such databases have been proposed; among them are the 135 Content distribution Overlay Network Service for LISP-NERD (a Not-so- 136 novel EID-to-RLOC Database) [RFC6837], LISP Alternative Logical 137 Topology (LISP-ALT) [RFC6836], and LISP Delegated Database Tree 138 (LISP-DDT) [RFC8111]. 140 The LISP Mapping Service defines two new types of LISP-speaking 141 devices: the Map-Resolver, which accepts Map-Requests from an Ingress 142 Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a 143 mapping database; and the Map-Server, which learns authoritative EID- 144 to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes 145 them in a database. 147 This LISP Control-Plane Mapping Service can be used by many different 148 encapsulation-based or translation-based Data-Planes which include 149 but are not limited to the ones defined in LISP RFC 6830bis 150 [I-D.ietf-lisp-rfc6830bis], LISP-GPE [I-D.ietf-lisp-gpe], VXLAN 151 [RFC7348], VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe], GRE [RFC2890], GTP 152 [GTP-3GPP], ILA [I-D.herbert-intarea-ila], and Segment Routing (SRv6) 153 [RFC8402]. 155 Conceptually, LISP Map-Servers share some of the same basic 156 configuration and maintenance properties as Domain Name System (DNS) 157 [RFC1035] servers; likewise, Map-Resolvers are conceptually similar 158 to DNS caching resolvers. With this in mind, this specification 159 borrows familiar terminology (resolver and server) from the DNS 160 specifications. 162 Note this document doesn't assume any particular database mapping 163 infrastructure to illustrate certain aspects of Map-Server and Map- 164 Resolver operation. The Mapping Service interface can (and likely 165 will) be used by ITRs and ETRs to access other mapping database 166 systems as the LISP infrastructure evolves. 168 LISP is not intended to address problems of connectivity and scaling 169 on behalf of arbitrary communicating parties. Relevant situations 170 are described in the scoping section of the introduction to 171 [I-D.ietf-lisp-rfc6830bis]. 173 This document obsoletes RFC 6830 and 6833. 175 2. Requirements Notation 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 179 "OPTIONAL" in this document are to be interpreted as described in BCP 180 14 [RFC2119] [RFC8174] when, and only when, they appear in all 181 capitals, as shown here. 183 3. Definition of Terms 185 Map-Server: A network infrastructure component that learns of EID- 186 Prefix mapping entries from an ETR, via the registration mechanism 187 described below, or some other authoritative source if one exists. 188 A Map-Server publishes these EID-Prefixes in a mapping database. 190 Map-Request: A LISP Map-Request is a Control-Plane message to query 191 the mapping system to resolve an EID. A LISP Map-Request can also 192 be sent to an RLOC to test for reachability and to exchange 193 security keys between an encapsulator and a decapsulator. This 194 type of Map-Request is also known as an RLOC-Probe Request. 196 Map-Reply: A LISP Map-Reply is a Control-Plane message returned in 197 response to a Map-Request sent to the mapping system when 198 resolving an EID. A LISP Map-Reply can also be returned by a 199 decapsulator in response to a Map-Request sent by an encapsulator 200 to test for reachability. This type of Map-Reply is known as a 201 RLOC-Probe Reply. 203 Encapsulated Map-Request: A LISP Map-Request carried within an 204 Encapsulated Control Message (ECM), which has an additional LISP 205 header prepended. Sent to UDP destination port 4342. The "outer" 206 addresses are routable IP addresses, also known as RLOCs. Used by 207 an ITR when sending to a Map-Resolver and by a Map-Server when 208 forwarding a Map-Request to an ETR. 210 Map-Resolver: A network infrastructure component that accepts LISP 211 Encapsulated (ECM) Map-Requests, typically from an ITR, and 212 determines whether or not the destination IP address is part of 213 the EID namespace; if it is not, a Negative Map-Reply is returned. 214 Otherwise, the Map-Resolver finds the appropriate EID-to-RLOC 215 mapping by consulting a mapping database system. 217 Negative Map-Reply: A LISP Map-Reply that contains an empty 218 Locator-Set. Returned in response to a Map-Request if the 219 destination EID is not registered in the mapping system, is policy 220 denied or fails authentication. 222 Map-Register message: A LISP message sent by an ETR to a Map-Server 223 to register its associated EID-Prefixes. In addition to the set 224 of EID-Prefixes to register, the message includes one or more 225 RLOCs to reach ETR(s). The Map-Server uses these RLOCs when 226 forwarding Map-Requests (re-formatted as Encapsulated Map- 227 Requests). An ETR MAY request that the Map-Server answer Map- 228 Requests on its behalf by setting the "proxy Map-Reply" flag 229 (P-bit) in the message. 231 Map-Notify message: A LISP message sent by a Map-Server to an ETR 232 to confirm that a Map-Register has been received and processed. 233 An ETR requests that a Map-Notify be returned by setting the 234 "want-map-notify" flag (M-bit) in the Map-Register message. 235 Unlike a Map-Reply, a Map-Notify uses UDP port 4342 for both 236 source and destination. Map-Notify messages are also sent to ITRs 237 by Map-Servers when there are RLOC-set changes. 239 For definitions of other terms, notably Ingress Tunnel Router (ITR), 240 Egress Tunnel Router (ETR), and Re-encapsulating Tunnel Router (RTR), 241 refer to the LISP Data-Plane specification 242 [I-D.ietf-lisp-rfc6830bis]. 244 4. Basic Overview 246 A Map-Server is a device that publishes EID-Prefixes in a LISP 247 mapping database on behalf of a set of ETRs. When it receives a Map 248 Request (typically from an ITR), it consults the mapping database to 249 find an ETR that can answer with the set of RLOCs for an EID-Prefix. 250 To publish its EID-Prefixes, an ETR periodically sends Map-Register 251 messages to the Map-Server. A Map-Register message contains a list 252 of EID-Prefixes plus a set of RLOCs that can be used to reach the 253 ETRs. 255 When LISP-ALT [RFC6836] is used as the mapping database, a Map-Server 256 connects to the ALT network and acts as a "last-hop" ALT-Router. 257 Intermediate ALT-Routers forward Map-Requests to the Map-Server that 258 advertises a particular EID-Prefix, and the Map-Server forwards them 259 to the owning ETR, which responds with Map-Reply messages. 261 When LISP-DDT [RFC8111] is used as the mapping database, a Map-Server 262 sends the final Map-Referral messages from the Delegated Database 263 Tree. 265 A Map-Resolver receives Encapsulated Map-Requests from its client 266 ITRs and uses a mapping database system to find the appropriate ETR 267 to answer those requests. On a LISP-ALT network, a Map-Resolver acts 268 as a "first-hop" ALT-Router. It has Generic Routing Encapsulation 269 (GRE) tunnels configured to other ALT-Routers and uses BGP to learn 270 paths to ETRs for different prefixes in the LISP-ALT database. The 271 Map-Resolver uses this path information to forward Map-Requests over 272 the ALT to the correct ETRs. On a LISP-DDT network [RFC8111], a Map- 273 Resolver maintains a referral-cache and acts as a "first-hop" DDT- 274 node. The Map-Resolver uses the referral information to forward Map- 275 Requests. 277 Note that while it is conceivable that a Map-Resolver could cache 278 responses to improve performance, issues surrounding cache management 279 will need to be resolved so that doing so will be reliable and 280 practical. As initially deployed, Map-Resolvers will operate only in 281 a non-caching mode, decapsulating and forwarding Encapsulated Map 282 Requests received from ITRs. Any specification of caching 283 functionality is out of scope for this document. 285 Note that a single device can implement the functions of both a Map- 286 Server and a Map-Resolver, and in many cases the functions will be 287 co-located in that way. Also, there can be ALT-only nodes and DDT- 288 only nodes, when LISP-ALT and LISP-DDT are used, respectively, to 289 connecting Map-Resolvers and Map-Servers together to make up the 290 Mapping System. 292 5. LISP IPv4 and IPv6 Control-Plane Packet Formats 294 The following UDP packet formats are used by the LISP control plane. 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 |Version| IHL |Type of Service| Total Length | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Identification |Flags| Fragment Offset | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Time to Live | Protocol = 17 | Header Checksum | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Source Routing Locator | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Destination Routing Locator | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 / | Source Port | Dest Port | 310 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 \ | UDP Length | UDP Checksum | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | | 314 | LISP Message | 315 | | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 0 1 2 3 319 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 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 |Version| Traffic Class | Flow Label | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Payload Length | Next Header=17| Hop Limit | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | | 326 + + 327 | | 328 + Source Routing Locator + 329 | | 330 + + 331 | | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | | 334 + + 335 | | 336 + Destination Routing Locator + 337 | | 338 + + 339 | | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 / | Source Port | Dest Port | 342 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 \ | UDP Length | UDP Checksum | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | | 346 | LISP Message | 347 | | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 When a UDP Map-Request, Map-Register, or Map-Notify (when used as a 351 notification message) are sent, the UDP source port is chosen by the 352 sender and the destination UDP port number is set to 4342. When a 353 UDP Map-Reply, Map-Notify (when used as an acknowledgement to a Map- 354 Register), or Map-Notify-Ack are sent, the source UDP port number is 355 set to 4342 and the destination UDP port number is copied from the 356 source port of either the Map-Request or the invoking data packet. 357 Implementations MUST be prepared to accept packets when either the 358 source port or destination UDP port is set to 4342 due to NATs 359 changing port number values. 361 The 'UDP Length' field will reflect the length of the UDP header and 362 the LISP Message payload. Implementations should follow the 363 procedures from [RFC8085] to determine the maximum size used for any 364 LISP control message. 366 The UDP checksum is computed and set to non-zero for all messages 367 sent to or from port 4342. It MUST be checked on receipt, and if the 368 checksum fails, the control message MUST be dropped [RFC1071]. 370 The format of control messages includes the UDP header so the 371 checksum and length fields can be used to protect and delimit message 372 boundaries. 374 5.1. LISP Control Packet Type Allocations 376 This section defines the LISP control message formats and summarizes 377 for IANA the LISP Type codes assigned by this document. For 378 completeness, the summary below includes the LISP Shared Extension 379 Message assigned by [RFC8113]. Message type definitions are: 381 Reserved: 0 b'0000' 382 LISP Map-Request: 1 b'0001' 383 LISP Map-Reply: 2 b'0010' 384 LISP Map-Register: 3 b'0011' 385 LISP Map-Notify: 4 b'0100' 386 LISP Map-Notify-Ack: 5 b'0101' 387 LISP Map-Referral: 6 b'0110' 388 Not Assigned 7 b'0111' 389 LISP Encapsulated Control Message: 8 b'1000' 390 Not Assigned 9-14 b'1001'- b'1110' 391 LISP Shared Extension Message: 15 b'1111' [RFC8113] 393 Values in the "Not Assigned" range can be assigned according to 394 procedures in [RFC8126]. 396 Protocol designers experimenting with new message formats are 397 recommended to use the LISP Shared Extension Message Type described 398 in [RFC8113]. 400 All LISP Control-Plane messages use Address Family Identifiers (AFI) 401 [AFI] or LISP Canonical Address Format (LCAF) [RFC8060] formats to 402 encode either fixed or variable length addresses. This includes 403 explicit fields in each control message or part of EID-records or 404 RLOC-records in commonly formatted messages. 406 The LISP control-plane describes how other data-planes can encode 407 messages to support the Soliciting of Map-Requests as well as RLOC- 408 probing procedures. 410 5.2. Map-Request Message Format 412 0 1 2 3 413 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 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 |Type=1 |A|M|P|S|p|s|R|R| Rsvd |L|D| IRC | Record Count | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Nonce . . . | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | . . . Nonce | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Source-EID-AFI | Source EID Address ... | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | ... | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | ITR-RLOC-AFI n | ITR-RLOC Address n ... | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 / | Reserved | EID mask-len | EID-Prefix-AFI | 430 Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 \ | EID-Prefix ... | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Map-Reply Record ... | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 Packet field descriptions: 438 Type: 1 (Map-Request) 440 A: This is an authoritative bit, which is set to 0 for UDP-based Map- 441 Requests sent by an ITR. It is set to 1 when an ITR wants the 442 destination site to return the Map-Reply rather than the mapping 443 database system returning a Map-Reply. 445 M: This is the map-data-present bit. When set, it indicates that a 446 Map-Reply Record segment is included in the Map-Request. 448 P: This is the probe-bit, which indicates that a Map-Request SHOULD 449 be treated as a Locator reachability probe. The receiver SHOULD 450 respond with a Map-Reply with the probe-bit set, indicating that 451 the Map-Reply is a Locator reachability probe reply, with the 452 nonce copied from the Map-Request. See RLOC-Probing Section 7.1 453 for more details. This RLOC-probe Map-Request MUST not be sent to 454 the mapping system. If a Map-Resolver or Map-Server receives a 455 Map-Request with the probe-bit set, it MUST drop the message. 457 S: This is the Solicit-Map-Request (SMR) bit. See Solicit-Map- 458 Request (SMRs) Section 6.1 for details. 460 p: This is the PITR bit. This bit is set to 1 when a PITR sends a 461 Map-Request. 463 s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is 464 sending a Map-Request in response to a received SMR-based Map- 465 Request. 467 R: This reserved bit MUST be set to 0 on transmit and MUST be ignored 468 on receipt. 470 Rsvd: This field MUST be set to 0 on transmit and MUST be ignored on 471 receipt. 473 L: This is the local-xtr bit. It is used by an xTR in a LISP site to 474 tell other xTRs in the same site that it is part of the RLOC-set 475 for the LISP site. The L-bit is set to 1 when the RLOC is the 476 sender's IP address. 478 D: This is the dont-map-reply bit. It is used in the SMR procedure 479 described in Section 6.1. When an xTR sends an SMR Map-Request 480 message, it doesn't need a Map-Reply returned. When this bit is 481 set, the receiver of the Map-Request does not return a Map-Reply. 483 IRC: This 5-bit field is the ITR-RLOC Count, which encodes the 484 additional number of ('ITR-RLOC-AFI', 'ITR-RLOC Address') fields 485 present in this message. At least one (ITR-RLOC-AFI, ITR-RLOC- 486 Address) pair MUST be encoded. Multiple 'ITR-RLOC Address' fields 487 are used, so a Map-Replier can select which destination address to 488 use for a Map-Reply. The IRC value ranges from 0 to 31. For a 489 value of 0, there is 1 ITR-RLOC address encoded; for a value of 1, 490 there are 2 ITR-RLOC addresses encoded, and so on up to 31, which 491 encodes a total of 32 ITR-RLOC addresses. 493 Record Count: This is the number of records in this Map-Request 494 message. A record is comprised of the portion of the packet that 495 is labeled 'Rec' above and occurs the number of times equal to 496 Record Count. For this version of the protocol, a receiver MUST 497 accept and process Map-Requests that contain one or more records, 498 but a sender MUST only send Map-Requests containing one record. 499 Support for processing multiple EIDs in a single Map-Request 500 message will be specified in a future version of the protocol. 502 Nonce: This is an 8-octet random value created by the sender of the 503 Map-Request. This nonce will be returned in the Map-Reply. The 504 security of the LISP mapping protocol critically depends on the 505 strength of the nonce in the Map-Request message. The nonce MUST 506 be generated by a properly seeded pseudo-random (or strong random) 507 source. See [RFC4086] for advice on generating security-sensitive 508 random data. 510 Source-EID-AFI: This is the address family of the 'Source EID 511 Address' field. 513 Source EID Address: This is the EID of the source host that 514 originated the packet that caused the Map-Request. When Map- 515 Requests are used for refreshing a Map-Cache entry or for RLOC- 516 Probing, an AFI value 0 is used and this field is of zero length. 518 ITR-RLOC-AFI: This is the address family of the 'ITR-RLOC Address' 519 field that follows this field. 521 ITR-RLOC Address: This is used to give the ETR the option of 522 selecting the destination address from any address family for the 523 Map-Reply message. This address MUST be a routable RLOC address 524 of the sender of the Map-Request message. 526 EID mask-len: This is the mask length for the EID-Prefix. 528 EID-Prefix-AFI: This is the address family of the EID-Prefix 529 according to [AFI] and [RFC8060]. 531 EID-Prefix: This prefix is 4 octets for an IPv4 address family and 532 16 octets for an IPv6 address family when the EID-Prefix-AFI is 1 533 or 2, respectively. For other AFIs [AFI], the length varies and 534 for the LCAF AFI the format is defined in [RFC8060]. When a Map- 535 Request is sent by an ITR because a data packet is received for a 536 destination where there is no mapping entry, the EID-Prefix is set 537 to the destination IP address of the data packet, and the 'EID 538 mask-len' is set to 32 or 128 for IPv4 or IPv6, respectively. 539 When an xTR wants to query a site about the status of a mapping it 540 already has cached, the EID-Prefix used in the Map-Request has the 541 same mask length as the EID-Prefix returned from the site when it 542 sent a Map-Reply message. 544 Map-Reply Record: When the M-bit is set, this field is the size of a 545 single "Record" in the Map-Reply format. This Map-Reply record 546 contains the EID-to-RLOC mapping entry associated with the Source 547 EID. This allows the ETR that will receive this Map-Request to 548 cache the data if it chooses to do so. 550 5.3. EID-to-RLOC UDP Map-Request Message 552 A Map-Request is sent from an ITR when it needs a mapping for an EID, 553 wants to test an RLOC for reachability, or wants to refresh a mapping 554 before TTL expiration. For the initial case, the destination IP 555 address used for the Map-Request is the data packet's destination 556 address (i.e., the destination EID) that had a mapping cache lookup 557 failure. For the latter two cases, the destination IP address used 558 for the Map-Request is one of the RLOC addresses from the Locator-Set 559 of the Map-Cache entry. The source address is either an IPv4 or IPv6 560 RLOC address, depending on whether the Map-Request is using an IPv4 561 or IPv6 header, respectively. In all cases, the UDP source port 562 number for the Map-Request message is a 16-bit value selected by the 563 ITR/PITR, and the UDP destination port number is set to the well- 564 known destination port number 4342. A successful Map-Reply, which is 565 one that has a nonce that matches an outstanding Map-Request nonce, 566 will update the cached set of RLOCs associated with the EID-Prefix 567 range. 569 One or more Map-Request ('ITR-RLOC-AFI', 'ITR-RLOC-Address') fields 570 MUST be filled in by the ITR. The number of fields (minus 1) encoded 571 MUST be placed in the 'IRC' field. The ITR MAY include all locally 572 configured Locators in this list or just provide one locator address 573 from each address family it supports. If the ITR erroneously 574 provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map- 575 Request. 577 Map-Requests can also be LISP encapsulated using UDP destination 578 port 4342 with a LISP Type value set to "Encapsulated Control 579 Message", when sent from an ITR to a Map-Resolver. Likewise, Map- 580 Requests are LISP encapsulated the same way from a Map-Server to an 581 ETR. Details on Encapsulated Map-Requests and Map-Resolvers can be 582 found in Section 5.8. 584 Map-Requests MUST be rate-limited. It is RECOMMENDED that a Map- 585 Request for the same EID-Prefix be sent no more than once per second. 586 However, recommendations from [RFC8085] SHOULD be considered. 588 An ITR that is configured with mapping database information (i.e., it 589 is also an ETR) MAY optionally include those mappings in a Map- 590 Request. When an ETR configured to accept and verify such 591 "piggybacked" mapping data receives such a Map-Request and it does 592 not have this mapping in the Map-Cache, it MAY originate a "verifying 593 Map-Request", addressed to the map-requesting ITR and the ETR MAY add 594 a Map-Cache entry. If the ETR (when it is an xTR co-located as an 595 ITR) has a Map-Cache entry that matches the "piggybacked" EID and the 596 RLOC is in the Locator-Set for the entry, then it MAY send the 597 "verifying Map-Request" directly to the originating Map-Request 598 source. If the RLOC is not in the Locator-Set, then the ETR MUST 599 send the "verifying Map-Request" to the "piggybacked" EID. Doing 600 this forces the "verifying Map-Request" to go through the mapping 601 database system to reach the authoritative source of information 602 about that EID, guarding against RLOC-spoofing in the "piggybacked" 603 mapping data. 605 5.4. Map-Reply Message Format 607 0 1 2 3 608 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 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 |Type=2 |P|E|S| Reserved | Record Count | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Nonce . . . | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | . . . Nonce | 615 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | | Record TTL | 617 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 R | Locator Count | EID mask-len | ACT |A| Reserved | 619 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 c | Rsvd | Map-Version Number | EID-Prefix-AFI | 621 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 r | EID-Prefix | 623 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | /| Priority | Weight | M Priority | M Weight | 625 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | o | Unused Flags |L|p|R| Loc-AFI | 627 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | \| Locator | 629 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 Packet field descriptions: 633 Type: 2 (Map-Reply) 635 P: This is the probe-bit, which indicates that the Map-Reply is in 636 response to a Locator reachability probe Map-Request. The 'Nonce' 637 field MUST contain a copy of the nonce value from the original 638 Map-Request. See RLOC-probing Section 7.1 for more details. When 639 the probe-bit is set to 1 in a Map-Reply message, the A-bit in 640 each EID-record included in the message MUST be set to 1. 642 E: This bit indicates that the ETR that sends this Map-Reply message 643 is advertising that the site is enabled for the Echo-Nonce Locator 644 reachability algorithm. See Echo-Nonce [I-D.ietf-lisp-rfc6830bis] 645 for more details. 647 S: This is the Security bit. When set to 1, the following 648 authentication information will be appended to the end of the Map- 649 Reply. The details of signing a Map-Reply message can be found in 650 [I-D.ietf-lisp-sec]. 652 0 1 2 3 653 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 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | AD Type | Authentication Data Content . . . | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 Reserved: This field MUST be set to 0 on transmit and MUST be 659 ignored on receipt. 661 Record Count: This is the number of records in this reply message. 662 A record is comprised of that portion of the packet labeled 663 'Record' above and occurs the number of times equal to Record 664 Count. 666 Nonce: This 64-bit value from the Map-Request is echoed in this 667 'Nonce' field of the Map-Reply. 669 Record TTL: This is the time in minutes the recipient of the Map- 670 Reply will store the mapping. If the TTL is 0, the entry MUST be 671 removed from the cache immediately. If the value is 0xffffffff, 672 the recipient can decide locally how long to store the mapping. 674 Locator Count: This is the number of Locator entries. A Locator 675 entry comprises what is labeled above as 'Loc'. The Locator count 676 can be 0, indicating that there are no Locators for the EID- 677 Prefix. 679 EID mask-len: This is the mask length for the EID-Prefix. 681 ACT: This 3-bit field describes Negative Map-Reply actions. In any 682 other message type, these bits are set to 0 and ignored on 683 receipt. These bits are used only when the 'Locator Count' field 684 is set to 0. The action bits are encoded only in Map-Reply 685 messages. They are used to tell an ITR or PITR why a empty 686 locator-set was returned from the mapping system and how it stores 687 the map-cache entry. 689 (0) No-Action: The Map-Cache is kept alive, and no packet 690 encapsulation occurs. 692 (1) Natively-Forward: The packet is not encapsulated or dropped 693 but natively forwarded. 695 (2) Send-Map-Request: The Map-Cache entry is created and flagged 696 that any packet matching this entry invokes sending a Map- 697 Request. 699 (3) Drop/No-Reason: A packet that matches this Map-Cache entry is 700 dropped. An ICMP Destination Unreachable message SHOULD be 701 sent. 703 (4) Drop/Policy-Denied: A packet that matches this Map-Cache 704 entry is dropped. The reason for the Drop action is that a 705 Map-Request for the target-EID is being policy denied by 706 either an xTR or the mapping system. 708 (5) Drop/Authentication-Failure: A packet that matches this Map- 709 Cache entry is dropped. The reason for the Drop action is 710 that a Map-Request for the target-EID fails an authentication 711 verification-check by either an xTR or the mapping system. 713 A: The Authoritative bit, when set to 1, is always set to 1 by an 714 ETR. When a Map-Server is proxy Map-Replying for a LISP site, the 715 Authoritative bit is set to 0. This indicates to requesting ITRs 716 that the Map-Reply was not originated by a LISP node managed at 717 the site that owns the EID-Prefix. 719 Map-Version Number: When this 12-bit value is non-zero, the Map- 720 Reply sender is informing the ITR what the version number is for 721 the EID record contained in the Map-Reply. The ETR can allocate 722 this number internally but MUST coordinate this value with other 723 ETRs for the site. When this value is 0, there is no versioning 724 information conveyed. The Map-Version Number can be included in 725 Map-Request and Map-Register messages. See Map-Versioning 726 [I-D.ietf-lisp-6834bis] for more details. 728 EID-Prefix-AFI: Address family of the EID-Prefix according to [AFI] 729 and [RFC8060]. 731 EID-Prefix: This prefix is 4 octets for an IPv4 address family and 732 16 octets for an IPv6 address family. 734 Priority: Each RLOC is assigned a unicast Priority. Lower values 735 are more preferable. When multiple RLOCs have the same Priority, 736 they may be used in a load-split fashion. A value of 255 means 737 the RLOC MUST NOT be used for unicast forwarding. 739 Weight: When priorities are the same for multiple RLOCs, the Weight 740 indicates how to balance unicast traffic between them. Weight is 741 encoded as a relative weight of total unicast packets that match 742 the mapping entry. For example, if there are 4 Locators in a 743 Locator-Set, where the Weights assigned are 30, 20, 20, and 10, 744 the first Locator will get 37.5% of the traffic, the 2nd and 3rd 745 Locators will get 25% of the traffic, and the 4th Locator will get 746 12.5% of the traffic. If all Weights for a Locator-Set are equal, 747 the receiver of the Map-Reply will decide how to load-split the 748 traffic. See RLOC-hashing [I-D.ietf-lisp-rfc6830bis] for a 749 suggested hash algorithm to distribute the load across Locators 750 with the same Priority and equal Weight values. 752 M Priority: Each RLOC is assigned a multicast Priority used by an 753 ETR in a receiver multicast site to select an ITR in a source 754 multicast site for building multicast distribution trees. A value 755 of 255 means the RLOC MUST NOT be used for joining a multicast 756 distribution tree. For more details, see [RFC6831]. 758 M Weight: When priorities are the same for multiple RLOCs, the 759 Weight indicates how to balance building multicast distribution 760 trees across multiple ITRs. The Weight is encoded as a relative 761 weight (similar to the unicast Weights) of the total number of 762 trees built to the source site identified by the EID-Prefix. If 763 all Weights for a Locator-Set are equal, the receiver of the Map- 764 Reply will decide how to distribute multicast state across ITRs. 765 For more details, see [RFC6831]. 767 Unused Flags: These are set to 0 when sending and ignored on 768 receipt. 770 L: When this bit is set, the Locator is flagged as a local Locator to 771 the ETR that is sending the Map-Reply. When a Map-Server is doing 772 proxy Map-Replying for a LISP site, the L-bit is set to 0 for all 773 Locators in this Locator-Set. 775 p: When this bit is set, an ETR informs the RLOC-Probing ITR that the 776 locator address for which this bit is set is the one being RLOC- 777 probed and may be different from the source address of the Map- 778 Reply. An ITR that RLOC-probes a particular Locator MUST use this 779 Locator for retrieving the data structure used to store the fact 780 that the Locator is reachable. The p-bit is set for a single 781 Locator in the same Locator-Set. If an implementation sets more 782 than one p-bit erroneously, the receiver of the Map-Reply MUST 783 select the first set p-bit Locator. The p-bit MUST NOT be set for 784 Locator-Set records sent in Map-Request and Map-Register messages. 786 R: This is set when the sender of a Map-Reply has a route to the 787 Locator in the Locator data record. This receiver may find this 788 useful to know if the Locator is up but not necessarily reachable 789 from the receiver's point of view. See also EID-Reachability 790 Section 7.1 for another way the R-bit may be used. 792 Locator: This is an IPv4 or IPv6 address (as encoded by the 'Loc- 793 AFI' field) assigned to an ETR and used by an ITR as a destination 794 RLOC address in the outer header of a LISP encapsualted packet. 796 Note that the destination RLOC address of a LISP encapsulated 797 packet MAY be an anycast address. A source RLOC of a LISP 798 encapsulated packet can be an anycast address as well. The source 799 or destination RLOC MUST NOT be the broadcast address 800 (255.255.255.255 or any subnet broadcast address known to the 801 router) and MUST NOT be a link-local multicast address. The 802 source RLOC MUST NOT be a multicast address. The destination RLOC 803 SHOULD be a multicast address if it is being mapped from a 804 multicast destination EID. 806 5.5. EID-to-RLOC UDP Map-Reply Message 808 A Map-Reply returns an EID-Prefix with a prefix length that is less 809 than or equal to the EID being requested. The EID being requested is 810 either from the destination field of an IP header of a Data-Probe or 811 the EID record of a Map-Request. The RLOCs in the Map-Reply are 812 routable IP addresses of all ETRs for the LISP site. Each RLOC 813 conveys status reachability but does not convey path reachability 814 from a requester's perspective. Separate testing of path 815 reachability is required. See RLOC-reachability Section 7.1 for 816 details. 818 Note that a Map-Reply MAY contain different EID-Prefix granularity 819 (prefix + length) than the Map-Request that triggers it. This might 820 occur if a Map-Request were for a prefix that had been returned by an 821 earlier Map-Reply. In such a case, the requester updates its cache 822 with the new prefix information and granularity. For example, a 823 requester with two cached EID-Prefixes that are covered by a Map- 824 Reply containing one less-specific prefix replaces the entry with the 825 less-specific EID-Prefix. Note that the reverse, replacement of one 826 less-specific prefix with multiple more-specific prefixes, can also 827 occur, not by removing the less-specific prefix but rather by adding 828 the more-specific prefixes that, during a lookup, will override the 829 less-specific prefix. 831 When an EID moves out of a LISP site [I-D.ietf-lisp-eid-mobility], 832 the database mapping system may have overlapping EID-prefixes. Or 833 when a LISP site is configured with multiple sets of ETRs that 834 support different EID-prefix lengths, the database mapping system may 835 have overlapping EID-prefixes. When overlapping EID-prefixes exist, 836 a Map-Request with an EID that best matches any EID-Prefix MUST be 837 returned in a single Map-Reply message. For instance, if an ETR had 838 database mapping entries for EID-Prefixes: 840 2001:db8::/16 841 2001:db8:1::/24 842 2001:db8:1:1::/32 843 2001:db8:1:2::/32 845 A Map-Request for EID 2001:db8:1:1::1 would cause a Map-Reply with a 846 record count of 1 to be returned with a mapping record EID-Prefix of 847 2001:db8:1:1::/32. 849 A Map-Request for EID 2001:db8:1:5::5 would cause a Map-Reply with a 850 record count of 3 to be returned with mapping records for EID- 851 Prefixes 2001:db8:1::/24, 2001:db8:1:1::/32, 2001:db8:1:2::/32, 852 filling out the /24 with more-specifics that exist in the mapping 853 system. 855 Note that not all overlapping EID-Prefixes need to be returned but 856 only the more-specific entries (note that in the second example above 857 2001:db8::/16 was not returned for requesting EID 2001:db8:1:5::5) 858 for the matching EID-Prefix of the requesting EID. When more than 859 one EID-Prefix is returned, all SHOULD use the same Time to Live 860 value so they can all time out at the same time. When a more- 861 specific EID-Prefix is received later, its Time to Live value in the 862 Map-Reply record can be stored even when other less-specific entries 863 exist. When a less-specific EID-Prefix is received later, its Map- 864 Cache expiration time SHOULD be set to the minimum expiration time of 865 any more-specific EID-Prefix in the Map-Cache. This is done so the 866 integrity of the EID-Prefix set is wholly maintained and so no more- 867 specific entries are removed from the Map-Cache while keeping less- 868 specific entries. 870 Map-Replies SHOULD be sent for an EID-Prefix no more often than once 871 per second to the same requesting router. For scalability, it is 872 expected that aggregation of EID addresses into EID-Prefixes will 873 allow one Map-Reply to satisfy a mapping for the EID addresses in the 874 prefix range, thereby reducing the number of Map-Request messages. 876 Map-Reply records can have an empty Locator-Set. A Negative Map- 877 Reply is a Map-Reply with an empty Locator-Set. Negative Map-Replies 878 convey special actions by the sender to the ITR or PITR that have 879 solicited the Map-Reply. There are two primary applications for 880 Negative Map-Replies. The first is for a Map-Resolver to instruct an 881 ITR or PITR when a destination is for a LISP site versus a non-LISP 882 site, and the other is to source quench Map-Requests that are sent 883 for non-allocated EIDs. 885 For each Map-Reply record, the list of Locators in a Locator-Set MUST 886 appear in the same order for each ETR that originates a Map-Reply 887 message. The Locator-Set MUST be sorted in order of ascending IP 888 address where an IPv4 locator address is considered numerically 'less 889 than' an IPv6 locator address. 891 When sending a Map-Reply message, the destination address is copied 892 from one of the 'ITR-RLOC' fields from the Map-Request. The ETR can 893 choose a locator address from one of the address families it 894 supports. For Data-Probes, the destination address of the Map-Reply 895 is copied from the source address of the Data-Probe message that is 896 invoking the reply. The source address of the Map-Reply is one of 897 the local IP addresses chosen, to allow Unicast Reverse Path 898 Forwarding (uRPF) checks to succeed in the upstream service provider. 899 The destination port of a Map-Reply message is copied from the source 900 port of the Map-Request or Data-Probe, and the source port of the 901 Map-Reply message is set to the well-known UDP port 4342. 903 5.6. Map-Register Message Format 905 This section specifies the encoding format for the Map-Register 906 message. The message is sent in UDP with a destination UDP port of 907 4342 and a randomly selected UDP source port number. 909 The Map-Register message format is: 911 0 1 2 3 912 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 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 |Type=3 |P|S|R| Reserved |E|T|a|R|M| Record Count | 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | Nonce . . . | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | . . . Nonce | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | Key ID | Algorithm ID | Authentication Data Length | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 ~ Authentication Data ~ 923 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | | Record TTL | 925 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 R | Locator Count | EID mask-len | ACT |A| Reserved | 927 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 c | Rsvd | Map-Version Number | EID-Prefix-AFI | 929 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 r | EID-Prefix | 931 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | /| Priority | Weight | M Priority | M Weight | 933 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | o | Unused Flags |L|p|R| Loc-AFI | 935 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | \| Locator | 937 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 Packet field descriptions: 941 Type: 3 (Map-Register) 943 P: This is the proxy Map-Reply bit. When set to 1, an ETR sends a 944 Map-Register message requesting the Map-Server to proxy a Map- 945 Reply. The Map-Server will send non-authoritative Map-Replies on 946 behalf of the ETR. 948 S: This is the security-capable bit. When set, the procedures from 949 [I-D.ietf-lisp-sec] are supported. 951 Reserved: This field MUST be set to 0 on transmit and MUST be 952 ignored on receipt. 954 E: This is the Map-Register EID-notify bit. This is used by a First- 955 Hop-Router (FHR) which discovers a dynamic-EID. This EID-notify 956 based Map-Register is sent by the FHR to the same site xTR that 957 propogates the Map-Register to the mapping system. The site xTR 958 keeps state to later Map-Notify the FHR after the EID has moves 959 away. See [I-D.ietf-lisp-eid-mobility] for a detailed use-case. 961 T: This is the use-TTL for timeout bit. When set to 1, the xTR wants 962 the Map-Server to time out registrations based on the value in the 963 "Record TTL" field of this message. Otherwise, the default 964 timeout described in Section 8.2 is used. 966 a: This is the merge-request bit. When set to 1, the xTR requests to 967 merge RLOC-records from different xTRs registering the same EID- 968 record. See signal-free multicast [RFC8378] for one use case 969 example. 971 R: This reserved bit MUST be set to 0 on transmit and MUST be ignored 972 on receipt. 974 M: This is the want-map-notify bit. When set to 1, an ETR is 975 requesting a Map-Notify message to be returned in response to 976 sending a Map-Register message. The Map-Notify message sent by a 977 Map-Server is used to acknowledge receipt of a Map-Register 978 message. 980 Record Count: This is the number of records in this Map-Register 981 message. A record is comprised of that portion of the packet 982 labeled 'Record' above and occurs the number of times equal to 983 Record Count. 985 Nonce: This 8-octet 'Nonce' field is set to 0 in Map-Register 986 messages if no Map-Notify message is expected to acknowledge it. 987 Since the Map-Register message is authenticated, the 'Nonce' field 988 is not currently used for any security function but may be in the 989 future as part of an anti-replay solution. 991 Key ID: This is a configured key-id value that corresponds to a 992 shared-secret password that is used to authenticate the sender. 993 Multiple shared-secrets can be used to roll over keys in a non- 994 disruptive way. 996 Algorithm ID: This is the configured Message Authentication Code 997 (MAC) algorithm value used for the authentication function. See 998 Algorithm ID Numbers in the Section 11.5 for codepoint 999 assignments. 1001 Authentication Data Length: This is the length in octets of the 1002 'Authentication Data' field that follows this field. The length 1003 of the 'Authentication Data' field is dependent on the MAC 1004 algorithm used. The length field allows a device that doesn't 1005 know the MAC algorithm to correctly parse the packet. 1007 Authentication Data: This is the output of the MAC algorithm. The 1008 entire Map-Register payload (from and including the LISP message 1009 type field through the end of the last RLOC record) is 1010 authenticated with this field preset to 0. After the MAC is 1011 computed, it is placed in this field. Implementations of this 1012 specification MUST include support for either HMAC-SHA-1-96 1013 [RFC2404] and HMAC-SHA-256-128 [RFC4868] where the latter is 1014 RECOMMENDED. 1016 The definition of the rest of the Map-Register can be found in EID- 1017 record description in Section 5.4. 1019 5.7. Map-Notify/Map-Notify-Ack Message Format 1021 This section specifies the encoding format for the Map-Notify and 1022 Map-Notify-Ack messages. The messages are sent inside a UDP packet 1023 with source and destination UDP ports equal to 4342. 1025 The Map-Notify and Map-Notify-Ack message formats are: 1027 0 1 2 3 1028 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 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 |Type=4/5| Reserved | Record Count | 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 | Nonce . . . | 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 | . . . Nonce | 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | Key ID | Algorithm ID | Authentication Data Length | 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 ~ Authentication Data ~ 1039 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 | | Record TTL | 1041 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 R | Locator Count | EID mask-len | ACT |A| Reserved | 1043 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 c | Rsvd | Map-Version Number | EID-Prefix-AFI | 1045 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 r | EID-Prefix | 1047 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 | /| Priority | Weight | M Priority | M Weight | 1049 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 | o | Unused Flags |L|p|R| Loc-AFI | 1051 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 | \| Locator | 1053 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 Packet field descriptions: 1057 Type: 4/5 (Map-Notify/Map-Notify-Ack) 1059 The Map-Notify message has the same contents as a Map-Register 1060 message. See the Map-Register section for field descriptions. 1062 The Map-Notify-Ack message has the same contents as a Map-Notify 1063 message. It is used to acknowledge the receipt of a Map-Notify and 1064 for the sender to stop retransmitting a Map-Notify with the same 1065 nonce. 1067 A Map-Server sends an unsolicited Map-Notify message (one that is not 1068 used as an acknowledgment to a Map-Register message) that follows the 1069 Congestion Control And Relability Guideline sections of [RFC8085]. A 1070 Map-Notify is retransmitted until a Map-Notify-Ack is received by the 1071 Map-Server with the same nonce used in the Map-Notify message. If a 1072 Map-Notify-Ack is never received by the Map-Server, it issues a log 1073 message. An implementation SHOULD retransmit up to 3 times at 3 1074 second retransmission intervals, after which time the retransmission 1075 interval is exponentially backed-off for another 3 retransmission 1076 attempts. After this time, an xTR can only get the RLOC-set change 1077 by later querying the mapping system or by RLOC-probing one of the 1078 RLOCs of the existing cached RLOC-set to get the new RLOC-set. 1080 5.8. Encapsulated Control Message Format 1082 An Encapsulated Control Message (ECM) is used to encapsulate control 1083 packets sent between xTRs and the mapping database system. 1085 0 1 2 3 1086 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 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 / | IPv4 or IPv6 Header | 1089 OH | (uses RLOC addresses) | 1090 \ | | 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 / | Source Port = xxxx | Dest Port = 4342 | 1093 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 \ | UDP Length | UDP Checksum | 1095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 LISP |Type=8 |S|D|E|M| Reserved | 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 / | IPv4 or IPv6 Header | 1099 IH | (uses RLOC or EID addresses) | 1100 \ | | 1101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 / | Source Port = xxxx | Dest Port = yyyy | 1103 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 \ | UDP Length | UDP Checksum | 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 LCM | LISP Control Message | 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 Packet header descriptions: 1111 OH: The outer IPv4 or IPv6 header, which uses RLOC addresses in the 1112 source and destination header address fields. 1114 UDP: The outer UDP header with destination port 4342. The source 1115 port is randomly allocated. The checksum field MUST be non- 1116 zero. 1118 LISP: Type 8 is defined to be a "LISP Encapsulated Control Message", 1119 and what follows is either an IPv4 or IPv6 header as encoded by 1120 the first 4 bits after the 'Reserved' field. 1122 Type: 8 (Encapsulated Control Message (ECM)) 1124 S: This is the Security bit. When set to 1, the field following 1125 the 'Reserved' field will have the following Authentication 1126 Data format and follow the procedures from [I-D.ietf-lisp-sec]. 1128 0 1 2 3 1129 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 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 | AD Type | Authentication Data Content . . . | 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 D: This is the DDT-bit. When set to 1, the sender is requesting a 1135 Map-Referral message to be returned. The details of this 1136 procedure are described in [RFC8111]. 1138 E: This is the to-ETR bit. When set to 1, the Map-Server's 1139 intention is to forward the ECM to an authoritative ETR. 1141 M: This is the to-MS bit. When set to 1, a Map-Request is being 1142 sent to a co-located Map-Resolver and Map-Server where the 1143 message can be processed directly by the Map-Server versus the 1144 Map-Resolver using the LISP-DDT procedures in [RFC8111]. 1146 IH: The inner IPv4 or IPv6 header, which can use either RLOC or EID 1147 addresses in the header address fields. When a Map-Request is 1148 encapsulated in this packet format, the destination address in 1149 this header is an EID. 1151 UDP: The inner UDP header, where the port assignments depend on the 1152 control packet being encapsulated. When the control packet is 1153 a Map-Request or Map-Register, the source port is selected by 1154 the ITR/PITR and the destination port is 4342. When the 1155 control packet is a Map-Reply, the source port is 4342 and the 1156 destination port is assigned from the source port of the 1157 invoking Map-Request. Port number 4341 MUST NOT be assigned to 1158 either port. The checksum field MUST be non-zero. 1160 LCM: The format is one of the control message formats described in 1161 this section. Map-Request messages are allowed to be Control- 1162 Plane (ECM) encapsulated. When Map-Requests are sent for RLOC- 1163 Probing purposes (i.e. the probe-bit is set), they MUST NOT be 1164 sent inside Encapsulated Control Messages. PIM Join/Prune 1165 messages [RFC6831] are also allowed to be Control-Plane (ECM) 1166 encapsulated. 1168 6. Changing the Contents of EID-to-RLOC Mappings 1170 In the LISP architecture ITRs/PITRs use a local Map-Cache to store 1171 EID-to-RLOC mappings for forwarding. When an ETR updates a mapping a 1172 mechanism is required to inform ITRs/PITRs that are using such 1173 mappings. 1175 The LISP Data-Plane defines several mechanism to update mappings 1176 [I-D.ietf-lisp-rfc6830bis]. This document specifies the Solicit-Map 1177 Request (SMR), a Control-Plane push-based mechanism. An additional 1178 Control-Plane mechanism based on the Publish/subscribe paradigm is 1179 specified in [I-D.ietf-lisp-pubsub]. 1181 6.1. Solicit-Map-Request (SMR) 1183 Soliciting a Map-Request is a selective way for ETRs, at the site 1184 where mappings change, to control the rate they receive requests for 1185 Map-Reply messages. SMRs are also used to tell remote ITRs to update 1186 the mappings they have cached. 1188 Since ETRs are not required to keep track of remote ITRs that have 1189 cached their mappings, they do not know which ITRs need to have their 1190 mappings updated. As a result, an ETR will solicit Map-Requests 1191 (called an SMR message) to those sites to which it has been sending 1192 LISP encapsulated data packets for the last minute. In particular, 1193 an ETR will send an SMR to an ITR to which it has recently sent 1194 encapsulated data. This can only occur when both ITR and ETR 1195 functionality reside in the same router. 1197 An SMR message is simply a bit set in a Map-Request message. An ITR 1198 or PITR will send a Map-Request when they receive an SMR message. 1199 Both the SMR sender and the Map-Request responder MUST rate-limit 1200 these messages. Rate-limiting can be implemented as a global rate- 1201 limiter or one rate-limiter per SMR destination. 1203 The following procedure shows how an SMR exchange occurs when a site 1204 is doing Locator-Set compaction for an EID-to-RLOC mapping: 1206 1. When the database mappings in an ETR change, the ETRs at the site 1207 begin to send Map-Requests with the SMR bit set for each Locator 1208 in each Map-Cache entry the ETR (when it is an xTR co-located as 1209 an ITR) caches. 1211 2. A remote ITR that receives the SMR message will schedule sending 1212 a Map-Request message to the source locator address of the SMR 1213 message or to the mapping database system. A newly allocated 1214 random nonce is selected, and the EID-Prefix used is the one 1215 copied from the SMR message. If the source Locator is the only 1216 Locator in the cached Locator-Set, the remote ITR SHOULD send a 1217 Map-Request to the database mapping system just in case the 1218 single Locator has changed and may no longer be reachable to 1219 accept the Map-Request. 1221 3. The remote ITR MUST rate-limit the Map-Request until it gets a 1222 Map-Reply while continuing to use the cached mapping. When 1223 Map-Versioning as described in [I-D.ietf-lisp-6834bis] is used, 1224 an SMR sender can detect if an ITR is using the most up-to-date 1225 database mapping. 1227 4. The site sending SMR messages will reply to the Map-Request with 1228 a Map-Reply message that has a nonce from the SMR-invoked Map- 1229 Request. The Map-Reply messages MUST be rate-limited according 1230 to procedures in [RFC8085]. This is important to avoid Map-Reply 1231 implosion. 1233 5. The ETRs at the site with the changed mapping record the fact 1234 that the site that sent the Map-Request has received the new 1235 mapping data in the Map-Cache entry for the remote site so the 1236 Locator-Status-Bits are reflective of the new mapping for packets 1237 going to the remote site. The ETR then stops sending SMR 1238 messages. 1240 For security reasons, an ITR MUST NOT process unsolicited Map- 1241 Replies. To avoid Map-Cache entry corruption by a third party, a 1242 sender of an SMR-based Map-Request MUST be verified. If an ITR 1243 receives an SMR-based Map-Request and the source is not in the 1244 Locator-Set for the stored Map-Cache entry, then the responding Map- 1245 Request MUST be sent with an EID destination to the mapping database 1246 system. Since the mapping database system is a more secure way to 1247 reach an authoritative ETR, it will deliver the Map-Request to the 1248 authoritative source of the mapping data. 1250 When an ITR receives an SMR-based Map-Request for which it does not 1251 have a cached mapping for the EID in the SMR message, it SHOULD NOT 1252 send an SMR-invoked Map-Request. This scenario can occur when an ETR 1253 sends SMR messages to all Locators in the Locator-Set it has stored 1254 in its Map-Cache but the remote ITRs that receive the SMR may not be 1255 sending packets to the site. There is no point in updating the ITRs 1256 until they need to send, in which case they will send Map-Requests to 1257 obtain a Map-Cache entry. 1259 7. Routing Locator Reachability 1261 This document defines several Control-Plane mechanisms for 1262 determining RLOC reachability. Please note that additional Data- 1263 Plane reachability mechanisms are defined in 1264 [I-D.ietf-lisp-rfc6830bis]. 1266 1. An ITR may receive an ICMP Network Unreachable or Host 1267 Unreachable message for an RLOC it is using. This indicates that 1268 the RLOC is likely down. Note that trusting ICMP messages may 1269 not be desirable, but neither is ignoring them completely. 1270 Implementations are encouraged to follow current best practices 1271 in treating these conditions [I-D.ietf-opsec-icmp-filtering]. 1273 2. When an ITR participates in the routing protocol that operates in 1274 the underlay routing system, it can determine that an RLOC is 1275 down when no Routing Information Base (RIB) entry exists that 1276 matches the RLOC IP address. 1278 3. An ITR may receive an ICMP Port Unreachable message from a 1279 destination host. This occurs if an ITR attempts to use 1280 interworking [RFC6832] and LISP-encapsulated data is sent to a 1281 non-LISP-capable site. 1283 4. An ITR may receive a Map-Reply from an ETR in response to a 1284 previously sent Map-Request. The RLOC source of the Map-Reply is 1285 likely up, since the ETR was able to send the Map-Reply to the 1286 ITR. 1288 5. An ITR/ETR pair can use the 'RLOC-Probing' mechanism described 1289 below. 1291 When ITRs receive ICMP Network Unreachable or Host Unreachable 1292 messages as a method to determine unreachability, they will refrain 1293 from using Locators that are described in Locator lists of Map- 1294 Replies. However, using this approach is unreliable because many 1295 network operators turn off generation of ICMP Destination Unreachable 1296 messages. 1298 If an ITR does receive an ICMP Network Unreachable or Host 1299 Unreachable message, it MAY originate its own ICMP Destination 1300 Unreachable message destined for the host that originated the data 1301 packet the ITR encapsulated. 1303 Also, BGP-enabled ITRs can unilaterally examine the RIB to see if a 1304 locator address from a Locator-Set in a mapping entry matches a 1305 prefix. If it does not find one and BGP is running in the Default- 1306 Free Zone (DFZ), it can decide to not use the Locator even though the 1307 Locator-Status-Bits indicate that the Locator is up. In this case, 1308 the path from the ITR to the ETR that is assigned the Locator is not 1309 available. More details are in [I-D.meyer-loc-id-implications]. 1311 Optionally, an ITR can send a Map-Request to a Locator, and if a Map- 1312 Reply is returned, reachability of the Locator has been determined. 1313 Obviously, sending such probes increases the number of control 1314 messages originated by Tunnel Routers for active flows, so Locators 1315 are assumed to be reachable when they are advertised. 1317 This assumption does create a dependency: Locator unreachability is 1318 detected by the receipt of ICMP Host Unreachable messages. When a 1319 Locator has been determined to be unreachable, it is not used for 1320 active traffic; this is the same as if it were listed in a Map-Reply 1321 with Priority 255. 1323 The ITR can test the reachability of the unreachable Locator by 1324 sending periodic Requests. Both Requests and Replies MUST be rate- 1325 limited. Locator reachability testing is never done with data 1326 packets, since that increases the risk of packet loss for end-to-end 1327 sessions. 1329 7.1. RLOC-Probing Algorithm 1331 RLOC-Probing is a method that an ITR or PITR can use to determine the 1332 reachability status of one or more Locators that it has cached in a 1333 Map-Cache entry. The probe-bit of the Map-Request and Map-Reply 1334 messages is used for RLOC-Probing. 1336 RLOC-Probing is done in the control plane on a timer basis, where an 1337 ITR or PITR will originate a Map-Request destined to a locator 1338 address from one of its own locator addresses. A Map-Request used as 1339 an RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or to 1340 the mapping database system as one would when soliciting mapping 1341 data. The EID record encoded in the Map-Request is the EID-Prefix of 1342 the Map-Cache entry cached by the ITR or PITR. The ITR MAY include a 1343 mapping data record for its own database mapping information that 1344 contains the local EID-Prefixes and RLOCs for its site. RLOC-probes 1345 are sent periodically using a jittered timer interval. 1347 When an ETR receives a Map-Request message with the probe-bit set, it 1348 returns a Map-Reply with the probe-bit set. The source address of 1349 the Map-Reply is set to the IP address of the outgoing interface the 1350 Map-Reply destination address routes to. The Map-Reply SHOULD 1351 contain mapping data for the EID-Prefix contained in the Map-Request. 1352 This provides the opportunity for the ITR or PITR that sent the RLOC- 1353 probe to get mapping updates if there were changes to the ETR's 1354 database mapping entries. 1356 There are advantages and disadvantages of RLOC-Probing. The main 1357 benefit of RLOC-Probing is that it can handle many failure scenarios 1358 allowing the ITR to determine when the path to a specific Locator is 1359 reachable or has become unreachable, thus providing a robust 1360 mechanism for switching to using another Locator from the cached 1361 Locator. RLOC-Probing can also provide rough Round-Trip Time (RTT) 1362 estimates between a pair of Locators, which can be useful for network 1363 management purposes as well as for selecting low delay paths. The 1364 major disadvantage of RLOC-Probing is in the number of control 1365 messages required and the amount of bandwidth used to obtain those 1366 benefits, especially if the requirement for failure detection times 1367 is very small. 1369 8. Interactions with Other LISP Components 1371 8.1. ITR EID-to-RLOC Mapping Resolution 1373 An ITR is configured with one or more Map-Resolver addresses. These 1374 addresses are "Locators" (or RLOCs) and MUST be routable on the 1375 underlying core network; they MUST NOT need to be resolved through 1376 LISP EID-to-RLOC mapping, as that would introduce a circular 1377 dependency. When using a Map-Resolver, an ITR does not need to 1378 connect to any other database mapping system. In particular, the ITR 1379 need not connect to the LISP-ALT infrastructure or implement the BGP 1380 and GRE protocols that it uses. 1382 An ITR sends an Encapsulated Map-Request to a configured Map-Resolver 1383 when it needs an EID-to-RLOC mapping that is not found in its local 1384 Map-Cache. Using the Map-Resolver greatly reduces both the 1385 complexity of the ITR implementation and the costs associated with 1386 its operation. 1388 In response to an Encapsulated Map-Request, the ITR can expect one of 1389 the following: 1391 o An immediate Negative Map-Reply (with action code of "Natively- 1392 Forward", 15-minute Time to Live (TTL)) from the Map-Resolver if 1393 the Map-Resolver can determine that the requested EID does not 1394 exist. The ITR saves the EID-Prefix returned in the Map-Reply in 1395 its cache, marks it as non-LISP-capable, and knows not to attempt 1396 LISP encapsulation for destinations matching it. 1398 o A Negative Map-Reply, with action code of "Natively-Forward", from 1399 a Map-Server that is authoritative for an EID-Prefix that matches 1400 the requested EID but that does not have an actively registered, 1401 more-specific ID-prefix. In this case, the requested EID is said 1402 to match a "hole" in the authoritative EID-Prefix. If the 1403 requested EID matches a more-specific EID-Prefix that has been 1404 delegated by the Map-Server but for which no ETRs are currently 1405 registered, a 1-minute TTL is returned. If the requested EID 1406 matches a non-delegated part of the authoritative EID-Prefix, then 1407 it is not a LISP EID and a 15-minute TTL is returned. See 1408 Section 8.2 for discussion of aggregate EID-Prefixes and details 1409 of Map-Server EID-Prefix matching. 1411 o A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or 1412 possibly from a Map-Server answering on behalf of the ETR. See 1413 Section 8.4 for more details on Map-Resolver message processing. 1415 Note that an ITR may be configured to both use a Map-Resolver and to 1416 participate in a LISP-ALT logical network. In such a situation, the 1417 ITR SHOULD send Map-Requests through the ALT network for any EID- 1418 Prefix learned via ALT BGP. Such a configuration is expected to be 1419 very rare, since there is little benefit to using a Map-Resolver if 1420 an ITR is already using LISP-ALT. There would be, for example, no 1421 need for such an ITR to send a Map-Request to a possibly non-existent 1422 EID (and rely on Negative Map-Replies) if it can consult the ALT 1423 database to verify that an EID-Prefix is present before sending that 1424 Map-Request. 1426 8.2. EID-Prefix Configuration and ETR Registration 1428 An ETR publishes its EID-Prefixes on a Map-Server by sending LISP 1429 Map-Register messages. A Map-Register message includes 1430 authentication data, so prior to sending a Map-Register message, the 1431 ETR and Map-Server SHOULD be configured with a shared secret or other 1432 relevant authentication information. A Map-Server's configuration 1433 SHOULD also include a list of the EID-Prefixes for which each ETR is 1434 authoritative. Upon receipt of a Map-Register from an ETR, a Map- 1435 Server accepts only EID-Prefixes that are configured for that ETR. 1436 Failure to implement such a check would leave the mapping system 1437 vulnerable to trivial EID-Prefix hijacking attacks. As developers 1438 and operators gain experience with the mapping system, additional, 1439 stronger security measures may be added to the registration process. 1441 In addition to the set of EID-Prefixes defined for each ETR that may 1442 register, a Map-Server is typically also configured with one or more 1443 aggregate prefixes that define the part of the EID numbering space 1444 assigned to it. When LISP-ALT is the database in use, aggregate EID- 1445 Prefixes are implemented as discard routes and advertised into ALT 1446 BGP. The existence of aggregate EID-Prefixes in a Map-Server's 1447 database means that it may receive Map Requests for EID-Prefixes that 1448 match an aggregate but do not match a registered prefix; Section 8.3 1449 describes how this is handled. 1451 Map-Register messages are sent periodically from an ETR to a Map- 1452 Server with a suggested interval between messages of one minute. A 1453 Map-Server SHOULD time out and remove an ETR's registration if it has 1454 not received a valid Map-Register message within the past 1455 three minutes. When first contacting a Map-Server after restart or 1456 changes to its EID-to-RLOC database mappings, an ETR MAY initially 1457 send Map-Register messages at an increased frequency, up to one every 1458 20 seconds. This "quick registration" period is limited to 1459 five minutes in duration. 1461 An ETR MAY request that a Map-Server explicitly acknowledge receipt 1462 and processing of a Map-Register message by setting the "want-map- 1463 notify" (M-bit) flag. A Map-Server that receives a Map-Register with 1464 this flag set will respond with a Map-Notify message. Typical use of 1465 this flag by an ETR would be to set it for Map-Register messages sent 1466 during the initial "quick registration" with a Map-Server but then 1467 set it only occasionally during steady-state maintenance of its 1468 association with that Map-Server. Note that the Map-Notify message 1469 is sent to UDP destination port 4342, not to the source port 1470 specified in the original Map-Register message. 1472 Note that a one-minute minimum registration interval during 1473 maintenance of an ETR-Map-Server association places a lower bound on 1474 how quickly and how frequently a mapping database entry can be 1475 updated. This may have implications for what sorts of mobility can 1476 be supported directly by the mapping system; shorter registration 1477 intervals or other mechanisms might be needed to support faster 1478 mobility in some cases. For a discussion on one way that faster 1479 mobility may be implemented for individual devices, please see 1480 [I-D.ietf-lisp-mn]. 1482 An ETR MAY also request, by setting the "proxy Map-Reply" flag 1483 (P-bit) in the Map-Register message, that a Map-Server answer Map- 1484 Requests instead of forwarding them to the ETR. See Section 7.1 for 1485 details on how the Map-Server sets certain flags (such as those 1486 indicating whether the message is authoritative and how returned 1487 Locators SHOULD be treated) when sending a Map-Reply on behalf of an 1488 ETR. When an ETR requests proxy reply service, it SHOULD include all 1489 RLOCs for all ETRs for the EID-Prefix being registered, along with 1490 the routable flag ("R-bit") setting for each RLOC. The Map-Server 1491 includes all of this information in Map-Reply messages that it sends 1492 on behalf of the ETR. This differs from a non-proxy registration, 1493 since the latter need only provide one or more RLOCs for a Map-Server 1494 to use for forwarding Map-Requests; the registration information is 1495 not used in Map-Replies, so it being incomplete is not incorrect. 1497 An ETR that uses a Map-Server to publish its EID-to-RLOC mappings 1498 does not need to participate further in the mapping database 1499 protocol(s). When using a LISP-ALT mapping database, for example, 1500 this means that the ETR does not need to implement GRE or BGP, which 1501 greatly simplifies its configuration and reduces its cost of 1502 operation. 1504 Note that use of a Map-Server does not preclude an ETR from also 1505 connecting to the mapping database (i.e., it could also connect to 1506 the LISP-ALT network), but doing so doesn't seem particularly useful, 1507 as the whole purpose of using a Map-Server is to avoid the complexity 1508 of the mapping database protocols. 1510 8.3. Map-Server Processing 1512 Once a Map-Server has EID-Prefixes registered by its client ETRs, it 1513 can accept and process Map-Requests for them. 1515 In response to a Map-Request (received over the ALT if LISP-ALT is in 1516 use), the Map-Server first checks to see if the destination EID 1517 matches a configured EID-Prefix. If there is no match, the Map- 1518 Server returns a Negative Map-Reply with action code "Natively- 1519 Forward" and a 15-minute TTL. This can occur if a Map Request is 1520 received for a configured aggregate EID-Prefix for which no more- 1521 specific EID-Prefix exists; it indicates the presence of a non-LISP 1522 "hole" in the aggregate EID-Prefix. 1524 Next, the Map-Server checks to see if any ETRs have registered the 1525 matching EID-Prefix. If none are found, then the Map-Server returns 1526 a Negative Map-Reply with action code "Natively-Forward" and a 1527 1-minute TTL. 1529 If the EID-prefix is either registered or not registered to the 1530 mapping system and there is a policy in the Map-Server to have the 1531 requestor drop packets for the matching EID-prefix, then a Drop/ 1532 Policy-Denied action is returned. If the EID-prefix is registered or 1533 not registered and there is a authentication failure, then a Drop/ 1534 Authentication- failure action is returned. If either of these 1535 actions result as a temporary state in policy or authentication then 1536 a Send-Map-Request action with 1-minute TTL MAY be returned to allow 1537 the requestor to retry the Map-Request. 1539 If any of the registered ETRs for the EID-Prefix have requested proxy 1540 reply service, then the Map-Server answers the request instead of 1541 forwarding it. It returns a Map-Reply with the EID-Prefix, RLOCs, 1542 and other information learned through the registration process. 1544 If none of the ETRs have requested proxy reply service, then the Map- 1545 Server re-encapsulates and forwards the resulting Encapsulated Map- 1546 Request to one of the registered ETRs. It does not otherwise alter 1547 the Map-Request, so any Map-Reply sent by the ETR is returned to the 1548 RLOC in the Map-Request, not to the Map-Server. Unless also acting 1549 as a Map-Resolver, a Map-Server should never receive Map-Replies; any 1550 such messages SHOULD be discarded without response, perhaps 1551 accompanied by the logging of a diagnostic message if the rate of 1552 Map-Replies is suggestive of malicious traffic. 1554 8.4. Map-Resolver Processing 1556 Upon receipt of an Encapsulated Map-Request, a Map-Resolver 1557 decapsulates the enclosed message and then searches for the requested 1558 EID in its local database of mapping entries (statically configured 1559 or learned from associated ETRs if the Map-Resolver is also a Map- 1560 Server offering proxy reply service). If it finds a matching entry, 1561 it returns a LISP Map-Reply with the known mapping. 1563 If the Map-Resolver does not have the mapping entry and if it can 1564 determine that the EID is not in the mapping database (for example, 1565 if LISP-ALT is used, the Map-Resolver will have an ALT forwarding 1566 table that covers the full EID space), it immediately returns a 1567 negative LISP Map-Reply, with action code "Natively-Forward" and a 1568 15-minute TTL. To minimize the number of negative cache entries 1569 needed by an ITR, the Map-Resolver SHOULD return the least-specific 1570 prefix that both matches the original query and does not match any 1571 EID-Prefix known to exist in the LISP-capable infrastructure. 1573 If the Map-Resolver does not have sufficient information to know 1574 whether the EID exists, it needs to forward the Map-Request to 1575 another device that has more information about the EID being 1576 requested. To do this, it forwards the unencapsulated Map-Request, 1577 with the original ITR RLOC as the source, to the mapping database 1578 system. Using LISP-ALT, the Map-Resolver is connected to the ALT 1579 network and sends the Map-Request to the next ALT hop learned from 1580 its ALT BGP neighbors. The Map-Resolver does not send any response 1581 to the ITR; since the source RLOC is that of the ITR, the ETR or Map- 1582 Server that receives the Map-Request over the ALT and responds will 1583 do so directly to the ITR. 1585 8.4.1. Anycast Operation 1587 A Map-Resolver can be set up to use "anycast", where the same address 1588 is assigned to multiple Map-Resolvers and is propagated through IGP 1589 routing, to facilitate the use of a topologically close Map-Resolver 1590 by each ITR. 1592 ETRs MAY have anycast RLOC addresses which are registered as part of 1593 their RLOC-set to the mapping system. However, registrations MUST 1594 use their unique RLOC addresses or distinct authentication keys to 1595 identify security associations with the Map-Servers. 1597 9. Security Considerations 1599 The Map-Request/Map-Reply message exchange can be exploited by an 1600 attacker to mount DoS and/or amplification attacks. Attackers can 1601 send Map-Requests at high rates to overload LISP nodes and increase 1602 the state maintained by such nodes or consume CPU cycles. Such 1603 threats can be mitigated by systematically applying filters and rate 1604 limiters. 1606 The 2-way LISP control-plane header nonce exchange can be used to 1607 avoid ITR spoofing attacks, but active on-path attackers (e.g 'man- 1608 in-the-middle') capable of intercepting the nonce can exploit the 1609 Map-Request/Map-Reply message exchange to inject forged mappings 1610 directly in the ITR EID-to-RLOC map-cache. In addition, valid ETRs 1611 in the system can perform overclaiming attacks. In this case, 1612 attackers can claim to own an EID-prefix that is larger than the 1613 prefix owned by the ETR. Such attacks can be addressed by using 1614 LISP-SEC [I-D.ietf-lisp-sec]. The LISP-SEC protocol defines a 1615 mechanism for providing origin authentication, integrity, anti- 1616 replay, protection, and prevention of 'man-in-the-middle' and 'prefix 1617 overclaiming' attacks on the Map-Request/Map-Reply exchange. In 1618 addition and while beyond the scope of securing an individual Map- 1619 Server or Map-Resolver, it should be noted that LISP-SEC can be 1620 complemented by additional security mechanisms defined by the Mapping 1621 System Infrastructure. For instance, BGP-based LISP-ALT [RFC6836] 1622 can take advantage of standards work on adding security to BGP while 1623 LISP-DDT [RFC8111] defines its own additional security mechanisms. 1625 To publish an authoritative EID-to-RLOC mapping with a Map-Server 1626 using the Map-Register message, an ETR includes authentication data 1627 that is a MAC of the entire message using a pair-wise shared key. An 1628 implementation MUST support use of HMAC-SHA-1-96 [RFC2104] and SHOULD 1629 support use of HMAC-SHA-256-128 [RFC6234] (SHA-256 truncated to 128 1630 bits). The Map-Register message is vulnerable to replay attacks by a 1631 man-in-the-middle. Deployments that are concerned with active man- 1632 in-the-middle attacks to the Map-Register message SHOULD use a 1633 transport-level integrity and anti-reply protection mechanism such as 1634 IPSEC [RFC6071]. In addition, a compromised ETR can overclaim the 1635 prefix it owns and successfully register it on its corresponding Map- 1636 Server. To mitigate this and as noted in Section 8.2, a Map-Server 1637 SHOULD verify that all EID-Prefixes registered by an ETR match the 1638 configuration stored on the Map-Server. 1640 A complete LISP threat analysis has been published in [RFC7835]. 1641 Please refer to it for more detailed security related details. 1643 10. Changes since RFC 6833 1645 For implementation considerations, the following changes have been 1646 made to this document since RFC 6833 was published: 1648 o A Map-Notify-Ack message is added in this document to provide 1649 reliability for Map-Notify messages. Any receiver of a Map-Notify 1650 message must respond with a Map-Notify-Ack message. Map-Servers 1651 who are senders of Map-Notify messages, must queue the Map-Notify 1652 contents until they receive a Map-Notify-Ack with the nonce used 1653 in the Map-Notify message. Note that implementations for Map- 1654 Notify-Ack support already exist and predate this document. 1656 o This document is incorporating the codepoint for the Map-Referral 1657 message from the LISP-DDT specification [RFC8111] to indicate that 1658 a Map-Server must send the final Map-Referral message when it 1659 participates in the LISP-DDT mapping system procedures. 1661 o The "m", "I", "L", and "D" bits are added to the Map-Request 1662 message. See Section 5.3 for details. 1664 o The "S", "I", "E", "T", "a", and "m" bits are added to the Map- 1665 Register message. See Section 5.6 for details. 1667 o The 16-bit Key-ID field of the Map-Register message has been split 1668 into a 8-bit Key-ID field and a 8-bit Algorithm-ID field. 1670 o This document adds two new Action values that are in an EID-record 1671 that appear in Map-Reply, Map-Register, Map-Notify, and Map- 1672 Notify-Ack messages. The Drop/Policy-Denied and Drop/Auth-Failure 1673 are the descriptions for the two new action values. See 1674 Section 5.4 for details. 1676 11. IANA Considerations 1678 This section provides guidance to the Internet Assigned Numbers 1679 Authority (IANA) regarding registration of values related to this 1680 LISP Control-Plane specification, in accordance with BCP 26 1681 [RFC8126]. 1683 There are three namespaces (listed in the sub-sections below) in LISP 1684 that have been registered. 1686 o LISP IANA registry allocations should not be made for purposes 1687 unrelated to LISP routing or transport protocols. 1689 o The following policies are used here with the meanings defined in 1690 BCP 26: "Specification Required", "IETF Review", "Experimental 1691 Use", and "First Come First Served". 1693 11.1. LISP UDP Port Numbers 1695 The IANA registry has allocated UDP port number 4342 for the LISP 1696 Control-Plane. IANA has updated the description for UDP port 4342 as 1697 follows: 1699 Keyword Port Transport Layer Description 1700 ------- ---- --------------- ----------- 1701 lisp-control 4342 udp LISP Control Packets 1703 11.2. LISP Packet Type Codes 1705 It is being requested that the IANA be authoritative for LISP Packet 1706 Type definitions and it is requested to replace the [RFC6830] 1707 registry message references with the RFC number assigned to this 1708 document. 1710 Based on deployment experience of [RFC6830], the Map-Notify-Ack 1711 message, message type 5, was added by this document. This document 1712 requests IANA to add it to the LISP Packet Type Registry. 1714 Name Number Defined in 1715 ---- ------ ----------- 1716 LISP Map-Notify-Ack 5 RFC6833bis 1718 11.3. LISP ACT and Flag Fields 1720 New ACT values can be allocated through IETF review or IESG approval. 1721 Four values have already been allocated by [RFC6830], IANA is 1722 requested to replace the [RFC6830] reference for this registry with 1723 the RFC number assigned to this document and the [RFC6830]. Action 1724 values references with the RFC number assigned to this document. 1725 This specification changes the name of ACT type 3 value from "Drop" 1726 to "Drop/No-Reason" as well as adding two new ACT values, the "Drop/ 1727 Policy-Denied" (type 4) and "Drop/Authentication-Failure" (type 5). 1729 Value Action Description Reference 1730 ----- ------ ----------- --------- 1731 4 Drop/ A Packet matching this Map-Cache RFC6833bis 1732 Policy-Denied entry is dropped because the target 1733 EID is policy-denied by the xTR or 1734 the mapping system. 1736 5 Drop/ A Packet matching this Map-Cache RFC6833bis 1737 Auth-Failure entry is dropped because the 1738 Map-Request for target EID fails an 1739 authentication check by the xTR or 1740 the mapping system. 1742 In addition, LISP has a number of flag fields and reserved fields, 1743 such as the LISP header flags field [I-D.ietf-lisp-rfc6830bis]. New 1744 bits for flags in these fields can be implemented after IETF review 1745 or IESG approval, but these need not be managed by IANA. 1747 11.4. LISP Address Type Codes 1749 LISP Canonical Address Format (LCAF) [RFC8060] is an 8-bit field that 1750 defines LISP-specific encodings for AFI value 16387. LCAF encodings 1751 are used for specific use-cases where different address types for 1752 EID-records and RLOC-records are required. 1754 The IANA registry "LISP Canonical Address Format (LCAF) Types" is 1755 used for LCAF types. The registry for LCAF types use the 1756 Specification Required policy [RFC8126]. Initial values for the 1757 registry as well as further information can be found in [RFC8060]. 1759 Therefore, there is no longer a need for the "LISP Address Type 1760 Codes" registry requested by [RFC6830]. This document requests to 1761 remove it. 1763 11.5. LISP Algorithm ID Numbers 1765 In [RFC6830], a request for a "LISP Key ID Numbers" registry was 1766 submitted. This document renames the registry to "LISP Algorithm ID 1767 Numbers" and requests the IANA to make the name change. 1769 The following Algorithm ID values are defined by this specification 1770 as used in any packet type that references a 'Algorithm ID' field: 1772 Name Number Defined in 1773 ----------------------------------------------- 1774 None 0 RFC6833bis 1775 HMAC-SHA-1-96 1 [RFC2404] 1776 HMAC-SHA-256-128 2 [RFC4868] 1778 Number values are in the range of 0 to 255. The allocation of values 1779 is on a first come first served basis. 1781 11.6. LISP Bit Flags 1783 This document asks IANA to create a registry for allocation of bits 1784 in several headers of the LISP control plane, namely in the Map- 1785 Request, Map-Reply, Map-Register, Encapsulated Control Message (ECM) 1786 messages. Bit allocations are also requested for EID-records and 1787 RLOC-records. The registry created should be named "LISP Control 1788 Plane Header Bits". A sub-registry needs to be created per each 1789 message and record. The name of each sub-registry is indicated 1790 below, along with its format and allocation of bits defined in this 1791 document. Any additional bits allocation, requires a specification, 1792 according with [RFC5226] policies. 1794 Sub-Registry: Map-Request Header Bits [Section 5.2]: 1796 0 1 2 3 1797 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 1798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1799 |Type=1 |A|M|P|S|p|s|R|R| Rsvd |L|D| IRC | Record Count | 1800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1802 +----------+---------------+------------+---------------------------+ 1803 | Spec | IANA Name | Bit | Description | 1804 | Name | | Position | | 1805 +----------+---------------+------------+---------------------------+ 1806 | A | map-request-A | 4 | Authoritative Bit | 1807 | M | map-request-M | 5 | Map Data Present Bit | 1808 | P | map-request-P | 6 | RLOC-Probe Request Bit | 1809 | S | map-request-S | 7 | Solicit Map-Request (SMR) | 1810 | | | | Bit | 1811 | p | map-request-p | 8 | Proxy-ITR Bit | 1812 | s | map-request-s | 9 | Solicit Map-Request | 1813 | | | | Invoked Bit | 1814 | L | map-request-L | 17 | Local xTR Bit | 1815 | D | map-request-D | 18 | Don't Map-Reply Bit | 1816 +----------+---------------+------------+---------------------------+ 1818 LISP Map-Request Header Bits 1820 Sub-Registry: Map-Reply Header Bits [Section 5.4]: 1822 0 1 2 3 1823 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 1824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1825 |Type=2 |P|E|S| Reserved | Record Count | 1826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1828 +-----------+-------------+--------------+------------------------+ 1829 | Spec Name | IANA Name | Bit Position | Description | 1830 +-----------+-------------+--------------+------------------------+ 1831 | P | map-reply-P | 4 | RLOC-Probe Bit | 1832 | E | map-reply-E | 5 | Echo Nonce Capable Bit | 1833 | S | map-reply-S | 6 | Security Bit | 1834 +-----------+-------------+--------------+------------------------+ 1836 LISP Map-Reply Header Bits 1838 Sub-Registry: Map-Register Header Bits [Section 5.6]: 1840 0 1 2 3 1841 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 1842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1843 |Type=3 |P|S|R| Reserved |E|T|a|R|M| Record Count | 1844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1846 +-----------+----------------+--------------+----------------------+ 1847 | Spec Name | IANA Name | Bit Position | Description | 1848 +-----------+----------------+--------------+----------------------+ 1849 | P | map-register-P | 4 | Proxy Map-Reply Bit | 1850 | S | map-register-S | 5 | LISP-SEC Capable Bit | 1851 +-----------+----------------+--------------+----------------------+ 1853 LISP Map-Register Header Bits 1855 Sub-Registry: Encapsulated Control Message (ECM) Header Bits 1856 [Section 5.8]: 1858 0 1 2 3 1859 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 1860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1861 |Type=8 |S|D|E|M| Reserved | 1862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1863 +-----------+-----------+--------------+----------------------------+ 1864 | Spec Name | IANA Name | Bit Position | Description | 1865 +-----------+-----------+--------------+----------------------------+ 1866 | S | ecm-S | 4 | Security Bit | 1867 | D | ecm-D | 5 | LISP-DDT Bit | 1868 | E | ecm-E | 6 | Forward to ETR Bit | 1869 | M | ecm-M | 7 | Destined to Map-Server Bit | 1870 +-----------+-----------+--------------+----------------------------+ 1872 LISP Encapsulated Control Message (ECM) Header Bits 1874 Sub-Registry: EID-Record Header Bits [Section 5.4]: 1876 0 1 2 3 1877 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 1878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1879 | Locator Count | EID mask-len | ACT |A| Reserved | 1880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1882 +-----------+--------------+--------------+-------------------+ 1883 | Spec Name | IANA Name | Bit Position | Description | 1884 +-----------+--------------+--------------+-------------------+ 1885 | A | eid-record-A | 19 | Authoritative Bit | 1886 +-----------+--------------+--------------+-------------------+ 1888 LISP EID-Record Header Bits 1890 Sub-Registry: RLOC-Record Header Bits [Section 5.4]: 1892 0 1 2 3 1893 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 1894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1895 | Unused Flags |L|p|R| Loc-AFI | 1896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1898 +-----------+---------------+--------------+----------------------+ 1899 | Spec Name | IANA Name | Bit Position | Description | 1900 +-----------+---------------+--------------+----------------------+ 1901 | L | rloc-record-L | 13 | Local RLOC Bit | 1902 | p | rloc-record-p | 19 | RLOC-Probe Reply Bit | 1903 | R | rloc-record-R | 19 | RLOC Reachable Bit | 1904 +-----------+---------------+--------------+----------------------+ 1906 LISP RLOC-Record Header Bits 1908 12. References 1910 12.1. Normative References 1912 [I-D.ietf-lisp-6834bis] 1913 Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID 1914 Separation Protocol (LISP) Map-Versioning", draft-ietf- 1915 lisp-6834bis-02 (work in progress), September 2018. 1917 [I-D.ietf-lisp-rfc6830bis] 1918 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 1919 Cabellos-Aparicio, "The Locator/ID Separation Protocol 1920 (LISP)", draft-ietf-lisp-rfc6830bis-22 (work in progress), 1921 October 2018. 1923 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 1924 ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November 1925 1998, . 1927 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1928 "Randomness Requirements for Security", BCP 106, RFC 4086, 1929 DOI 10.17487/RFC4086, June 2005, 1930 . 1932 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 1933 384, and HMAC-SHA-512 with IPsec", RFC 4868, 1934 DOI 10.17487/RFC4868, May 2007, 1935 . 1937 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1938 IANA Considerations Section in RFCs", RFC 5226, 1939 DOI 10.17487/RFC5226, May 2008, 1940 . 1942 [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and 1943 Internet Key Exchange (IKE) Document Roadmap", RFC 6071, 1944 DOI 10.17487/RFC6071, February 2011, 1945 . 1947 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1948 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1949 March 2017, . 1951 12.2. Informative References 1953 [AFI] IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY 1954 NUMBERS http://www.iana.org/assignments/address-family- 1955 numbers/address-family-numbers.xhtml?, Febuary 2007. 1957 [GTP-3GPP] 1958 3GPP, "General Packet Radio System (GPRS) Tunnelling 1959 Protocol User Plane (GTPv1-U)", TS.29.281 1960 https://portal.3gpp.org/desktopmodules/Specifications/ 1961 SpecificationDetails.aspx?specificationId=1699, January 1962 2015. 1964 [I-D.herbert-intarea-ila] 1965 Herbert, T. and P. Lapukhov, "Identifier-locator 1966 addressing for IPv6", draft-herbert-intarea-ila-01 (work 1967 in progress), March 2018. 1969 [I-D.ietf-lisp-eid-mobility] 1970 Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, 1971 F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a 1972 Unified Control Plane", draft-ietf-lisp-eid-mobility-02 1973 (work in progress), May 2018. 1975 [I-D.ietf-lisp-gpe] 1976 Maino, F., Lemon, J., Agarwal, P., Lewis, D., and M. 1977 Smith, "LISP Generic Protocol Extension", draft-ietf-lisp- 1978 gpe-06 (work in progress), September 2018. 1980 [I-D.ietf-lisp-introduction] 1981 Cabellos-Aparicio, A. and D. Saucez, "An Architectural 1982 Introduction to the Locator/ID Separation Protocol 1983 (LISP)", draft-ietf-lisp-introduction-13 (work in 1984 progress), April 2015. 1986 [I-D.ietf-lisp-mn] 1987 Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP 1988 Mobile Node", draft-ietf-lisp-mn-03 (work in progress), 1989 October 2018. 1991 [I-D.ietf-lisp-pubsub] 1992 Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., 1993 Cabellos-Aparicio, A., Barkai, S., Farinacci, D., 1994 Boucadair, M., Jacquenet, C., and S. Secci, "Publish/ 1995 Subscribe Functionality for LISP", draft-ietf-lisp- 1996 pubsub-00 (work in progress), April 2018. 1998 [I-D.ietf-lisp-sec] 1999 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 2000 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-15 2001 (work in progress), April 2018. 2003 [I-D.ietf-nvo3-vxlan-gpe] 2004 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 2005 Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work 2006 in progress), April 2018. 2008 [I-D.ietf-opsec-icmp-filtering] 2009 Gont, F., Gont, G., and C. Pignataro, "Recommendations for 2010 filtering ICMP messages", draft-ietf-opsec-icmp- 2011 filtering-04 (work in progress), July 2013. 2013 [I-D.meyer-loc-id-implications] 2014 Meyer, D. and D. Lewis, "Architectural Implications of 2015 Locator/ID Separation", draft-meyer-loc-id-implications-01 2016 (work in progress), January 2009. 2018 [RFC1035] Mockapetris, P., "Domain names - implementation and 2019 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2020 November 1987, . 2022 [RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the 2023 Internet checksum", RFC 1071, DOI 10.17487/RFC1071, 2024 September 1988, . 2026 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 2027 Hashing for Message Authentication", RFC 2104, 2028 DOI 10.17487/RFC2104, February 1997, 2029 . 2031 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2032 Requirement Levels", BCP 14, RFC 2119, 2033 DOI 10.17487/RFC2119, March 1997, 2034 . 2036 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 2037 RFC 2890, DOI 10.17487/RFC2890, September 2000, 2038 . 2040 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 2041 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 2042 DOI 10.17487/RFC6234, May 2011, 2043 . 2045 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 2046 Locator/ID Separation Protocol (LISP)", RFC 6830, 2047 DOI 10.17487/RFC6830, January 2013, 2048 . 2050 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 2051 Locator/ID Separation Protocol (LISP) for Multicast 2052 Environments", RFC 6831, DOI 10.17487/RFC6831, January 2053 2013, . 2055 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 2056 "Interworking between Locator/ID Separation Protocol 2057 (LISP) and Non-LISP Sites", RFC 6832, 2058 DOI 10.17487/RFC6832, January 2013, 2059 . 2061 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 2062 "Locator/ID Separation Protocol Alternative Logical 2063 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 2064 January 2013, . 2066 [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to 2067 Routing Locator (RLOC) Database", RFC 6837, 2068 DOI 10.17487/RFC6837, January 2013, 2069 . 2071 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 2072 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 2073 eXtensible Local Area Network (VXLAN): A Framework for 2074 Overlaying Virtualized Layer 2 Networks over Layer 3 2075 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 2076 . 2078 [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID 2079 Separation Protocol (LISP) Threat Analysis", RFC 7835, 2080 DOI 10.17487/RFC7835, April 2016, 2081 . 2083 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 2084 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 2085 February 2017, . 2087 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 2088 Smirnov, "Locator/ID Separation Protocol Delegated 2089 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 2090 May 2017, . 2092 [RFC8113] Boucadair, M. and C. Jacquenet, "Locator/ID Separation 2093 Protocol (LISP): Shared Extension Message & IANA Registry 2094 for Packet Type Allocations", RFC 8113, 2095 DOI 10.17487/RFC8113, March 2017, 2096 . 2098 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2099 Writing an IANA Considerations Section in RFCs", BCP 26, 2100 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2101 . 2103 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2104 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2105 May 2017, . 2107 [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID 2108 Separation Protocol (LISP) Multicast", RFC 8378, 2109 DOI 10.17487/RFC8378, May 2018, 2110 . 2112 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 2113 Decraene, B., Litkowski, S., and R. Shakir, "Segment 2114 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 2115 July 2018, . 2117 Appendix A. Acknowledgments 2119 The authors would like to thank Greg Schudel, Darrel Lewis, John 2120 Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver, 2121 Fabio Maino, and members of the lisp@ietf.org mailing list for their 2122 feedback and helpful suggestions. 2124 Special thanks are due to Noel Chiappa for his extensive work and 2125 thought about caching in Map-Resolvers. 2127 Appendix B. Document Change Log 2129 [RFC Editor: Please delete this section on publication as RFC.] 2131 B.1. Changes to draft-ietf-lisp-rfc6833bis-17 2133 o Posted early October 2018. 2135 o Changes to reflect comments from Sep 27th Telechat. 2137 o Added all flag bit definitions as request for allocation in IANA 2138 Considersations section. 2140 o Added an applicability statement in section 1 to address security 2141 concerns from Telechat. 2143 o Moved m-bit description and IANA request to draft-ietf-lisp-mn. 2145 o Moved I-bit description and IANA request to draft-ietf-lisp- 2146 pubsub. 2148 B.2. Changes to draft-ietf-lisp-rfc6833bis-16 2150 o Posted Late-September 2018. 2152 o Re-wrote Security Considerations section. Thanks Albert. 2154 o Added Alvaro text to be more clear about IANA actions. 2156 B.3. Changes to draft-ietf-lisp-rfc6833bis-15 2158 o Posted mid-September 2018. 2160 o Changes to reflect comments from Colin and Mirja. 2162 B.4. Changes to draft-ietf-lisp-rfc6833bis-14 2164 o Posted September 2018. 2166 o Changes to reflect comments from Genart, RTGarea, and Secdir 2167 reviews. 2169 B.5. Changes to draft-ietf-lisp-rfc6833bis-13 2171 o Posted August 2018. 2173 o Final editorial changes before RFC submission for Proposed 2174 Standard. 2176 o Added section "Changes since RFC 6833" so implementators are 2177 informed of any changes since the last RFC publication. 2179 B.6. Changes to draft-ietf-lisp-rfc6833bis-12 2181 o Posted late July 2018. 2183 o Moved RFC6830bis and RFC6834bis to Normative References. 2185 B.7. Changes to draft-ietf-lisp-rfc6833bis-11 2187 o Posted July 2018. 2189 o Fixed Luigi editorial comments to ready draft for RFC status and 2190 ran through IDNITs again. 2192 B.8. Changes to draft-ietf-lisp-rfc6833bis-10 2194 o Posted after LISP WG at IETF week March. 2196 o Move AD field encoding after S-bit in the ECM packet format 2197 description section. 2199 o Say more about when the new Drop actions should be sent. 2201 B.9. Changes to draft-ietf-lisp-rfc6833bis-09 2203 o Posted March IETF week 2018. 2205 o Fixed editorial comments submitted by document shepherd Luigi 2206 Iannone. 2208 B.10. Changes to draft-ietf-lisp-rfc6833bis-08 2210 o Posted March 2018. 2212 o Added RLOC-probing algorithm. 2214 o Added Solicit-Map Request algorithm. 2216 o Added several mechanisms (from 6830bis) regarding Routing Locator 2217 Reachability. 2219 o Added port 4342 to IANA Considerations section. 2221 B.11. Changes to draft-ietf-lisp-rfc6833bis-07 2223 o Posted December 2017. 2225 o Make it more clear in a couple of places that RLOCs are used to 2226 locate ETRs more so than for Map-Server Map-Request forwarding. 2228 o Make it clear that "encapsualted" for a control message is an ECM 2229 based message. 2231 o Make it more clear what messages use source-port 4342 and which 2232 ones use destinatino-port 4342. 2234 o Don't make DDT references when the mapping transport system can be 2235 of any type and the referneced text is general to it. 2237 o Generalize text when referring to the format of an EID-prefix. 2238 Can use othe AFIs then IPv4 and IPv6. 2240 o Many editorial changes to clarify text. 2242 o Changed some "must", "should", and "may" to capitalized. 2244 o Added definitions for Map-Request and Map-Reply messages. 2246 o Ran document through IDNITs. 2248 B.12. Changes to draft-ietf-lisp-rfc6833bis-06 2250 o Posted October 2017. 2252 o Spec the I-bit to include the xTR-ID in a Map-Request message to 2253 be consistent with the Map-Register message and to anticipate the 2254 introduction of pubsub functionality to allow Map-Requests to 2255 subscribe to RLOC-set changes. 2257 o Updated references for individual submissions that became working 2258 group documents. 2260 o Updated references for working group documents that became RFCs. 2262 B.13. Changes to draft-ietf-lisp-rfc6833bis-05 2264 o Posted May 2017. 2266 o Update IANA Considerations section based on new requests from this 2267 document and changes from what was requested in [RFC6830]. 2269 B.14. Changes to draft-ietf-lisp-rfc6833bis-04 2271 o Posted May 2017. 2273 o Clarify how the Key-ID field is used in Map-Register and Map- 2274 Notify messages. Break the 16-bit field into a 8-bit Key-ID field 2275 and a 8-bit Algorithm-ID field. 2277 o Move the Control-Plane codepoints from the IANA Considerations 2278 section of RFC6830bis to the IANA Considerations section of this 2279 document. 2281 o In the "LISP Control Packet Type Allocations" section, indicate 2282 how message Types are IANA allocated and how experimental RFC8113 2283 sub-types should be requested. 2285 B.15. Changes to draft-ietf-lisp-rfc6833bis-03 2287 o Posted April 2017. 2289 o Add types 9-14 and specify they are not assigned. 2291 o Add the "LISP Shared Extension Message" type and point to RFC8113. 2293 B.16. Changes to draft-ietf-lisp-rfc6833bis-02 2295 o Posted April 2017. 2297 o Clarify that the LISP Control-Plane document defines how the LISP 2298 Data-Plane uses Map-Requests with either the SMR-bit set or the 2299 P-bit set supporting mapping updates and RLOC-probing. Indicating 2300 that other Data-Planes can use the same mechanisms or their own 2301 defined mechanisms to achieve the same functionality. 2303 B.17. Changes to draft-ietf-lisp-rfc6833bis-01 2305 o Posted March 2017. 2307 o Include references to new RFCs published. 2309 o Remove references to self. 2311 o Change references from RFC6830 to RFC6830bis. 2313 o Add two new action/reasons to a Map-Reply has posted to the LISP 2314 WG mailing list. 2316 o In intro section, add refernece to I-D.ietf-lisp-introduction. 2318 o Removed Open Issues section and references to "experimental". 2320 B.18. Changes to draft-ietf-lisp-rfc6833bis-00 2322 o Posted December 2016. 2324 o Created working group document from draft-farinacci-lisp 2325 -rfc6833-00 individual submission. No other changes made. 2327 B.19. Changes to draft-farinacci-lisp-rfc6833bis-00 2329 o Posted November 2016. 2331 o This is the initial draft to turn RFC 6833 into RFC 6833bis. 2333 o The document name has changed from the "Locator/ID Separation 2334 Protocol (LISP) Map-Server Interface" to the "Locator/ID 2335 Separation Protocol (LISP) Control-Plane". 2337 o The fundamental change was to move the Control-Plane messages from 2338 RFC 6830 to this document in an effort so any IETF developed or 2339 industry created Data-Plane could use the LISP mapping system and 2340 Control-Plane. 2342 o Update Control-Plane messages to incorporate what has been 2343 implemented in products during the early phase of LISP development 2344 but wasn't able to make it into RFC6830 and RFC6833 to make the 2345 Experimental RFC deadline. 2347 o Indicate there may be nodes in the mapping system that are not MRs 2348 or MSs, that is a ALT-node or a DDT-node. 2350 o Include LISP-DDT in Map-Resolver section and explain how they 2351 maintain a referral-cache. 2353 o Removed open issue about additional state in Map-Servers. With 2354 [RFC8111], Map-Servers have the same registration state and can 2355 give Map-Resolvers complete information in ms-ack Map-Referral 2356 messages. 2358 o Make reference to the LISP Threats Analysis RFC [RFC7835]. 2360 Authors' Addresses 2362 Vince Fuller 2363 Cisco Systems 2365 EMail: vaf@vaf.net 2367 Dino Farinacci 2368 Cisco Systems 2370 EMail: farinacci@gmail.com 2372 Albert Cabellos 2373 UPC/BarcelonaTech 2374 Campus Nord, C. Jordi Girona 1-3 2375 Barcelona, Catalunya 2376 Spain 2378 EMail: acabello@ac.upc.edu