idnits 2.17.1 draft-ietf-lisp-rfc6833bis-15.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 1722 has weird spacing: '...-Denied entry...' == Line 1727 has weird spacing: '...Failure entr...' -- The document date (September 18, 2018) is 2037 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-18 == Outdated reference: A later version (-19) exists of draft-ermagan-lisp-nat-traversal-14 == 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-05 == 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-02 == 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 == Outdated reference: A later version (-09) exists of draft-rodrigueznatal-lisp-oam-08 -- 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: 0 errors (**), 0 flaws (~~), 14 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: March 22, 2019 UPC/BarcelonaTech 7 September 18, 2018 9 Locator/ID Separation Protocol (LISP) Control-Plane 10 draft-ietf-lisp-rfc6833bis-15 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, connect directly to LISP-capable 26 Internet end sites, and comprising the bulk of LISP-speaking devices, 27 reducing their implementation and operational complexity should also 28 reduce the overall cost and effort of deploying LISP. 30 This document obsoletes RFC 6830 and 6833. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on March 22, 2019. 49 Copyright Notice 51 Copyright (c) 2018 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 68 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 69 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 6 70 5. LISP IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 7 71 5.1. LISP Control Packet Type Allocations . . . . . . . . . . 9 72 5.2. Map-Request Message Format . . . . . . . . . . . . . . . 10 73 5.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 13 74 5.4. Map-Reply Message Format . . . . . . . . . . . . . . . . 15 75 5.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 19 76 5.6. Map-Register Message Format . . . . . . . . . . . . . . . 22 77 5.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 25 78 5.8. Encapsulated Control Message Format . . . . . . . . . . . 27 79 6. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 29 80 6.1. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 29 81 7. Routing Locator Reachability . . . . . . . . . . . . . . . . 30 82 7.1. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 32 83 8. Interactions with Other LISP Components . . . . . . . . . . . 33 84 8.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 33 85 8.2. EID-Prefix Configuration and ETR Registration . . . . . . 34 86 8.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 36 87 8.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 37 88 8.4.1. Anycast Operation . . . . . . . . . . . . . . . . . . 37 89 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37 90 10. Changes since RFC 6833 . . . . . . . . . . . . . . . . . . . 38 91 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 92 11.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 39 93 11.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 39 94 11.3. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 40 95 11.4. LISP Address Type Codes . . . . . . . . . . . . . . . . 40 96 11.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 41 98 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 99 12.1. Normative References . . . . . . . . . . . . . . . . . . 41 100 12.2. Informative References . . . . . . . . . . . . . . . . . 42 101 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 46 102 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 46 103 B.1. Changes to draft-ietf-lisp-rfc6833bis-15 . . . . . . . . 46 104 B.2. Changes to draft-ietf-lisp-rfc6833bis-14 . . . . . . . . 46 105 B.3. Changes to draft-ietf-lisp-rfc6833bis-13 . . . . . . . . 46 106 B.4. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . 46 107 B.5. Changes to draft-ietf-lisp-rfc6833bis-11 . . . . . . . . 46 108 B.6. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . 47 109 B.7. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . 47 110 B.8. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 47 111 B.9. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 47 112 B.10. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 48 113 B.11. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 48 114 B.12. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 48 115 B.13. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 49 116 B.14. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 49 117 B.15. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 49 118 B.16. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 49 119 B.17. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 49 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 122 1. Introduction 124 The Locator/ID Separation Protocol [I-D.ietf-lisp-rfc6830bis] (see 125 also [I-D.ietf-lisp-introduction]) specifies an architecture and 126 mechanism for dynamic tunneling by logically separating the addresses 127 currently used by IP in two separate name spaces: Endpoint IDs 128 (EIDs), used within sites; and Routing Locators (RLOCs), used on the 129 transit networks that make up the Internet infrastructure. To 130 achieve this separation, LISP defines protocol mechanisms for mapping 131 from EIDs to RLOCs. In addition, LISP assumes the existence of a 132 database to store and propagate those mappings globally. Several 133 such databases have been proposed; among them are the Content 134 distribution Overlay Network Service for LISP-NERD (a Not-so-novel 135 EID-to-RLOC Database) [RFC6837], LISP Alternative Logical Topology 136 (LISP-ALT) [RFC6836], and LISP Delegated Database Tree (LISP-DDT) 137 [RFC8111]. 139 The LISP Mapping Service defines two new types of LISP-speaking 140 devices: the Map-Resolver, which accepts Map-Requests from an Ingress 141 Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a 142 mapping database; and the Map-Server, which learns authoritative EID- 143 to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes 144 them in a database. 146 This LISP Control-Plane Mapping Service can be used by many different 147 encapsulation-based or translation-based Data-Planes which include 148 but are not limited to the ones defined in LISP RFC 6830bis 149 [I-D.ietf-lisp-rfc6830bis], LISP-GPE [I-D.ietf-lisp-gpe], VXLAN 150 [RFC7348], VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe], GRE [RFC2890], GTP 151 [GTP-3GPP], ILA [I-D.herbert-intarea-ila], and Segment Routing (SRv6) 152 [RFC8402]. 154 Conceptually, LISP Map-Servers share some of the same basic 155 configuration and maintenance properties as Domain Name System (DNS) 156 [RFC1035] servers; likewise, Map-Resolvers are conceptually similar 157 to DNS caching resolvers. With this in mind, this specification 158 borrows familiar terminology (resolver and server) from the DNS 159 specifications. 161 Note this document doesn't assume any particular database mapping 162 infrastructure to illustrate certain aspects of Map-Server and Map- 163 Resolver operation, the Mapping Service interface can (and likely 164 will) be used by ITRs and ETRs to access other mapping database 165 systems as the LISP infrastructure evolves. 167 The LISP Mapping Service is an important component of the LISP 168 toolset. Issues and concerns about the deployment of LISP for 169 Internet traffic are discussed in [I-D.ietf-lisp-rfc6830bis], 170 [RFC7215], and [I-D.rodrigueznatal-lisp-oam]. 172 This document obsoletes RFC 6830 and 6833. 174 2. Requirements Notation 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in [RFC2119] and 179 [RFC8174]. 181 3. Definition of Terms 183 Map-Server: A network infrastructure component that learns of EID- 184 Prefix mapping entries from an ETR, via the registration mechanism 185 described below, or some other authoritative source if one exists. 186 A Map-Server publishes these EID-Prefixes in a mapping database. 188 Map-Request: A LISP Map-Request is a Control-Plane message to query 189 the mapping system to resolve an EID. A LISP Map-Request can also 190 be sent to an RLOC to test for reachability and to exchange 191 security keys between an encapsulator and a decapsulator. This 192 type of Map-Request is also known as an RLOC-Probe Request. 194 Map-Reply: A LISP Map-Reply is a Control-Plane message returned in 195 response to a Map-Request sent to the mapping system when 196 resolving an EID. A LISP Map-Reply can also be returned by a 197 decapsulator in response to a Map-Request sent by an encapsulator 198 to test for reachability. This type of Map-Reply is known as a 199 RLOC-Probe Reply. 201 Encapsulated Map-Request: A LISP Map-Request carried within an 202 Encapsulated Control Message (ECM), which has an additional LISP 203 header prepended. Sent to UDP destination port 4342. The "outer" 204 addresses are routable IP addresses, also known as RLOCs. Used by 205 an ITR when sending to a Map-Resolver and by a Map-Server when 206 forwarding a Map-Request to an ETR. 208 Map-Resolver: A network infrastructure component that accepts LISP 209 Encapsulated (ECM) Map-Requests, typically from an ITR, and 210 determines whether or not the destination IP address is part of 211 the EID namespace; if it is not, a Negative Map-Reply is returned. 212 Otherwise, the Map-Resolver finds the appropriate EID-to-RLOC 213 mapping by consulting a mapping database system. 215 Negative Map-Reply: A LISP Map-Reply that contains an empty 216 Locator-Set. Returned in response to a Map-Request if the 217 destination EID is not registered in the mapping system, is policy 218 denied or fails authentication. 220 Map-Register message: A LISP message sent by an ETR to a Map-Server 221 to register its associated EID-Prefixes. In addition to the set 222 of EID-Prefixes to register, the message includes one or more 223 RLOCs to reach ETR(s). The Map-Server uses these RLOCs when 224 forwarding Map-Requests (re-formatted as Encapsulated Map- 225 Requests). An ETR MAY request that the Map-Server answer Map- 226 Requests on its behalf by setting the "proxy Map-Reply" flag 227 (P-bit) in the message. 229 Map-Notify message: A LISP message sent by a Map-Server to an ETR 230 to confirm that a Map-Register has been received and processed. 231 An ETR requests that a Map-Notify be returned by setting the 232 "want-map-notify" flag (M-bit) in the Map-Register message. 233 Unlike a Map-Reply, a Map-Notify uses UDP port 4342 for both 234 source and destination. Map-Notify messages are also sent to ITRs 235 by Map-Servers when there are RLOC-set changes. 237 For definitions of other terms, notably Ingress Tunnel Router (ITR), 238 Egress Tunnel Router (ETR), and Re-encapsulating Tunnel Router (RTR), 239 refer to the LISP Data-Plane specification 240 [I-D.ietf-lisp-rfc6830bis]. 242 4. Basic Overview 244 A Map-Server is a device that publishes EID-Prefixes in a LISP 245 mapping database on behalf of a set of ETRs. When it receives a Map 246 Request (typically from an ITR), it consults the mapping database to 247 find an ETR that can answer with the set of RLOCs for an EID-Prefix. 248 To publish its EID-Prefixes, an ETR periodically sends Map-Register 249 messages to the Map-Server. A Map-Register message contains a list 250 of EID-Prefixes plus a set of RLOCs that can be used to reach the 251 ETRs. 253 When LISP-ALT [RFC6836] is used as the mapping database, a Map-Server 254 connects to the ALT network and acts as a "last-hop" ALT-Router. 255 Intermediate ALT-Routers forward Map-Requests to the Map-Server that 256 advertises a particular EID-Prefix, and the Map-Server forwards them 257 to the owning ETR, which responds with Map-Reply messages. 259 When LISP-DDT [RFC8111] is used as the mapping database, a Map-Server 260 sends the final Map-Referral messages from the Delegated Database 261 Tree. 263 A Map-Resolver receives Encapsulated Map-Requests from its client 264 ITRs and uses a mapping database system to find the appropriate ETR 265 to answer those requests. On a LISP-ALT network, a Map-Resolver acts 266 as a "first-hop" ALT-Router. It has Generic Routing Encapsulation 267 (GRE) tunnels configured to other ALT-Routers and uses BGP to learn 268 paths to ETRs for different prefixes in the LISP-ALT database. The 269 Map-Resolver uses this path information to forward Map-Requests over 270 the ALT to the correct ETRs. On a LISP-DDT network [RFC8111], a Map- 271 Resolver maintains a referral-cache and acts as a "first-hop" DDT- 272 node. The Map-Resolver uses the referral information to forward Map- 273 Requests. 275 Note that while it is conceivable that a Map-Resolver could cache 276 responses to improve performance, issues surrounding cache management 277 will need to be resolved so that doing so will be reliable and 278 practical. As initially deployed, Map-Resolvers will operate only in 279 a non-caching mode, decapsulating and forwarding Encapsulated Map 280 Requests received from ITRs. Any specification of caching 281 functionality is out of scope for this document. 283 Note that a single device can implement the functions of both a Map- 284 Server and a Map-Resolver, and in many cases the functions will be 285 co-located in that way. Also, there can be ALT-only nodes and DDT- 286 only nodes, when LISP-ALT and LISP-DDT are used, respectively, to 287 connecting Map-Resolvers and Map-Servers together to make up the 288 Mapping System. 290 5. LISP IPv4 and IPv6 Control-Plane Packet Formats 292 The following UDP packet formats are used by the LISP control plane. 294 0 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 |Version| IHL |Type of Service| Total Length | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Identification |Flags| Fragment Offset | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Time to Live | Protocol = 17 | Header Checksum | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Source Routing Locator | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Destination Routing Locator | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 / | Source Port | Dest Port | 308 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 \ | UDP Length | UDP Checksum | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | | 312 | LISP Message | 313 | | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 0 1 2 3 317 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 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 |Version| Traffic Class | Flow Label | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Payload Length | Next Header=17| Hop Limit | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | | 324 + + 325 | | 326 + Source Routing Locator + 327 | | 328 + + 329 | | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | | 332 + + 333 | | 334 + Destination Routing Locator + 335 | | 336 + + 337 | | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 / | Source Port | Dest Port | 340 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 \ | UDP Length | UDP Checksum | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | | 344 | LISP Message | 345 | | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 When a UDP Map-Request, Map-Register, or Map-Notify (when used as a 349 notification message) are sent, the UDP source port is chosen by the 350 sender and the destination UDP port number is set to 4342. When a 351 UDP Map-Reply, Map-Notify (when used as an acknowledgement to a Map- 352 Register), or Map-Notify-Ack are sent, the source UDP port number is 353 set to 4342 and the destination UDP port number is copied from the 354 source port of either the Map-Request or the invoking data packet. 355 Implementations MUST be prepared to accept packets when either the 356 source port or destination UDP port is set to 4342 due to NATs 357 changing port number values. 359 The 'UDP Length' field will reflect the length of the UDP header and 360 the LISP Message payload. Implementations should follow the 361 procedures from [RFC8085] to determine the maximum size used for any 362 LISP control message. 364 The UDP checksum is computed and set to non-zero for all messages 365 sent to or from port 4342. It MUST be checked on receipt, and if the 366 checksum fails, the control message MUST be dropped [RFC1071]. 368 The format of control messages includes the UDP header so the 369 checksum and length fields can be used to protect and delimit message 370 boundaries. 372 5.1. LISP Control Packet Type Allocations 374 This section defines the LISP control message formats and summarizes 375 for IANA the LISP Type codes assigned by this document. For 376 completeness, this document references the LISP Shared Extension 377 Message assigned by [RFC8113]. Message type definitions are: 379 Reserved: 0 b'0000' 380 LISP Map-Request: 1 b'0001' 381 LISP Map-Reply: 2 b'0010' 382 LISP Map-Register: 3 b'0011' 383 LISP Map-Notify: 4 b'0100' 384 LISP Map-Notify-Ack: 5 b'0101' 385 LISP Map-Referral: 6 b'0110' 386 Not Assigned 7 b'0111' 387 LISP Encapsulated Control Message: 8 b'1000' 388 Not Assigned 9-14 b'1001'- b'1110' 389 LISP Shared Extension Message: 15 b'1111' [RFC8113] 391 Values in the "Not Assigned" range can be assigned according to 392 procedures in [RFC8126]. Documents that request for a new LISP 393 packet type may indicate a preferred value. 395 Protocol designers experimenting with new message formats SHOULD use 396 the LISP Shared Extension Message Type and request a [RFC8113] sub- 397 type assignment. 399 All LISP Control-Plane messages use Address Family Identifiers (AFI) 400 [AFI] or LISP Canonical Address Format (LCAF) [RFC8060] formats to 401 encode either fixed or variable length addresses. This includes 402 explicit fields in each control message or part of EID-records or 403 RLOC-records in commonly formatted messages. 405 The LISP control-plane describes how other data-planes can encode 406 messages to support the SMR and RLOC-probing procedures. 408 5.2. Map-Request Message Format 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 |Type=1 |A|M|P|S|p|s|m|I| Rsvd |L|D| IRC | Record Count | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Nonce . . . | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | . . . Nonce | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Source-EID-AFI | Source EID Address ... | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | ... | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | ITR-RLOC-AFI n | ITR-RLOC Address n ... | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 / | Reserved | EID mask-len | EID-Prefix-AFI | 428 Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 \ | EID-Prefix ... | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Map-Reply Record ... | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 Packet field descriptions: 436 Type: 1 (Map-Request) 438 A: This is an authoritative bit, which is set to 0 for UDP-based Map- 439 Requests sent by an ITR. It is set to 1 when an ITR wants the 440 destination site to return the Map-Reply rather than the mapping 441 database system. 443 M: This is the map-data-present bit. When set, it indicates that a 444 Map-Reply Record segment is included in the Map-Request. 446 P: This is the probe-bit, which indicates that a Map-Request SHOULD 447 be treated as a Locator reachability probe. The receiver SHOULD 448 respond with a Map-Reply with the probe-bit set, indicating that 449 the Map-Reply is a Locator reachability probe reply, with the 450 nonce copied from the Map-Request. See RLOC-Probing Section 7.1 451 for more details. 453 S: This is the Solicit-Map-Request (SMR) bit. See Solicit-Map- 454 Request (SMRs) Section 6.1 for details. 456 p: This is the PITR bit. This bit is set to 1 when a PITR sends a 457 Map-Request. 459 s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is 460 sending a Map-Request in response to a received SMR-based Map- 461 Request. 463 m: This is the LISP mobile-node m-bit. This bit is set by xTRs that 464 operate as a mobile node as defined in [I-D.ietf-lisp-mn]. This 465 bit can be ignored if an implementation does not support 466 [I-D.ietf-lisp-mn]. 468 I: This is the xTR-ID bit. When this bit is set, what is appended to 469 the Map-Request is a 128-bit xTR router-ID. See LISP PubSub usage 470 procedures in [I-D.ietf-lisp-pubsub] for details. This bit can be 471 ignored if an implementation does not support 472 [I-D.ietf-lisp-pubsub]. 474 Rsvd: This field MUST be set to 0 on transmit and MUST be ignored on 475 receipt. 477 L: This is the local-xtr bit. It is used by an xTR in a LISP site to 478 tell other xTRs in the same site that it is part of the RLOC-set 479 for the LISP site. The L-bit is set to 1 when the RLOC is the 480 sender's IP address. 482 D: This is the dont-map-reply bit. It is used in the SMR procedure 483 described in Section 6.1. When an xTR sends an SMR Map-Request 484 message, it doesn't need a Map-Reply returned. When this bit is 485 set, the receiver of the Map-Request does not return a Map-Reply. 487 IRC: This 5-bit field is the ITR-RLOC Count, which encodes the 488 additional number of ('ITR-RLOC-AFI', 'ITR-RLOC Address') fields 489 present in this message. At least one (ITR-RLOC-AFI, ITR-RLOC- 490 Address) pair MUST be encoded. Multiple 'ITR-RLOC Address' fields 491 are used, so a Map-Replier can select which destination address to 492 use for a Map-Reply. The IRC value ranges from 0 to 31. For a 493 value of 0, there is 1 ITR-RLOC address encoded; for a value of 1, 494 there are 2 ITR-RLOC addresses encoded, and so on up to 31, which 495 encodes a total of 32 ITR-RLOC addresses. 497 Record Count: This is the number of records in this Map-Request 498 message. A record is comprised of the portion of the packet that 499 is labeled 'Rec' above and occurs the number of times equal to 500 Record Count. For this version of the protocol, a receiver MUST 501 accept and process Map-Requests that contain one or more records, 502 but a sender MUST only send Map-Requests containing one record. 504 Support for processing multiple EIDs in a single Map-Request 505 message will be specified in a future version of the protocol. 507 Nonce: This is an 8-octet random value created by the sender of the 508 Map-Request. This nonce will be returned in the Map-Reply. The 509 security of the LISP mapping protocol critically depends on the 510 strength of the nonce in the Map-Request message. The nonce 511 SHOULD be generated by a properly seeded pseudo-random (or strong 512 random) source. See [RFC4086] for advice on generating security- 513 sensitive random data. 515 Source-EID-AFI: This is the address family of the 'Source EID 516 Address' field. 518 Source EID Address: This is the EID of the source host that 519 originated the packet that caused the Map-Request. When Map- 520 Requests are used for refreshing a Map-Cache entry or for RLOC- 521 Probing, an AFI value 0 is used and this field is of zero length. 523 ITR-RLOC-AFI: This is the address family of the 'ITR-RLOC Address' 524 field that follows this field. 526 ITR-RLOC Address: This is used to give the ETR the option of 527 selecting the destination address from any address family for the 528 Map-Reply message. This address MUST be a routable RLOC address 529 of the sender of the Map-Request message. 531 EID mask-len: This is the mask length for the EID-Prefix. 533 EID-Prefix-AFI: This is the address family of the EID-Prefix 534 according to [AFI] and [RFC8060]. 536 EID-Prefix: This prefix is 4 octets for an IPv4 address family and 537 16 octets for an IPv6 address family when the EID-Prefix-AFI is 1 538 or 2, respectively. For other AFIs [AFI], the length varies and 539 for the LCAF AFI the format is defined in [RFC8060]. When a Map- 540 Request is sent by an ITR because a data packet is received for a 541 destination where there is no mapping entry, the EID-Prefix is set 542 to the destination IP address of the data packet, and the 'EID 543 mask-len' is set to 32 or 128 for IPv4 or IPv6, respectively. 544 When an xTR wants to query a site about the status of a mapping it 545 already has cached, the EID-Prefix used in the Map-Request has the 546 same mask length as the EID-Prefix returned from the site when it 547 sent a Map-Reply message. 549 Map-Reply Record: When the M-bit is set, this field is the size of a 550 single "Record" in the Map-Reply format. This Map-Reply record 551 contains the EID-to-RLOC mapping entry associated with the Source 552 EID. This allows the ETR that will receive this Map-Request to 553 cache the data if it chooses to do so. 555 5.3. EID-to-RLOC UDP Map-Request Message 557 A Map-Request is sent from an ITR when it needs a mapping for an EID, 558 wants to test an RLOC for reachability, or wants to refresh a mapping 559 before TTL expiration. For the initial case, the destination IP 560 address used for the Map-Request is the data packet's destination 561 address (i.e., the destination EID) that had a mapping cache lookup 562 failure. For the latter two cases, the destination IP address used 563 for the Map-Request is one of the RLOC addresses from the Locator-Set 564 of the Map-Cache entry. The source address is either an IPv4 or IPv6 565 RLOC address, depending on whether the Map-Request is using an IPv4 566 or IPv6 header, respectively. In all cases, the UDP source port 567 number for the Map-Request message is a 16-bit value selected by the 568 ITR/PITR, and the UDP destination port number is set to the well- 569 known destination port number 4342. A successful Map-Reply, which is 570 one that has a nonce that matches an outstanding Map-Request nonce, 571 will update the cached set of RLOCs associated with the EID-Prefix 572 range. 574 One or more Map-Request ('ITR-RLOC-AFI', 'ITR-RLOC-Address') fields 575 MUST be filled in by the ITR. The number of fields (minus 1) encoded 576 MUST be placed in the 'IRC' field. The ITR MAY include all locally 577 configured Locators in this list or just provide one locator address 578 from each address family it supports. If the ITR erroneously 579 provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map- 580 Request. 582 Map-Requests can also be LISP encapsulated using UDP destination 583 port 4342 with a LISP Type value set to "Encapsulated Control 584 Message", when sent from an ITR to a Map-Resolver. Likewise, Map- 585 Requests are LISP encapsulated the same way from a Map-Server to an 586 ETR. Details on Encapsulated Map-Requests and Map-Resolvers can be 587 found in Section 5.8. 589 Map-Requests MUST be rate-limited. It is RECOMMENDED that a Map- 590 Request for the same EID-Prefix be sent no more than once per second. 591 However, recommendations from [RFC8085] SHOULD be considered. 593 An ITR that is configured with mapping database information (i.e., it 594 is also an ETR) MAY optionally include those mappings in a Map- 595 Request. When an ETR configured to accept and verify such 596 "piggybacked" mapping data receives such a Map-Request and it does 597 not have this mapping in the Map-Cache, it MAY originate a "verifying 598 Map-Request", addressed to the map-requesting ITR and the ETR MAY add 599 a Map-Cache entry. If the ETR has a Map-Cache entry that matches the 600 "piggybacked" EID and the RLOC is in the Locator-Set for the entry, 601 then it MAY send the "verifying Map-Request" directly to the 602 originating Map-Request source. If the RLOC is not in the Locator- 603 Set, then the ETR MUST send the "verifying Map-Request" to the 604 "piggybacked" EID. Doing this forces the "verifying Map-Request" to 605 go through the mapping database system to reach the authoritative 606 source of information about that EID, guarding against RLOC-spoofing 607 in the "piggybacked" mapping data. 609 5.4. Map-Reply Message Format 611 0 1 2 3 612 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 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 |Type=2 |P|E|S| Reserved | Record Count | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Nonce . . . | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | . . . Nonce | 619 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | | Record TTL | 621 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 R | Locator Count | EID mask-len | ACT |A| Reserved | 623 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 c | Rsvd | Map-Version Number | EID-Prefix-AFI | 625 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 r | EID-Prefix | 627 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | /| Priority | Weight | M Priority | M Weight | 629 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | o | Unused Flags |L|p|R| Loc-AFI | 631 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | \| Locator | 633 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 Packet field descriptions: 637 Type: 2 (Map-Reply) 639 P: This is the probe-bit, which indicates that the Map-Reply is in 640 response to a Locator reachability probe Map-Request. The 'Nonce' 641 field MUST contain a copy of the nonce value from the original 642 Map-Request. See RLOC-probing Section 7.1 for more details. When 643 the probe-bit is set to 1 in a Map-Reply message, the A-bit in 644 each EID-record included in the message MUST be set to 1. 646 E: This bit indicates that the ETR that sends this Map-Reply message 647 is advertising that the site is enabled for the Echo-Nonce Locator 648 reachability algorithm. See Echo-Nonce [I-D.ietf-lisp-rfc6830bis] 649 for more details. 651 S: This is the Security bit. When set to 1, the following 652 authentication information will be appended to the end of the Map- 653 Reply. The details of signing a Map-Reply message can be found in 654 [I-D.ietf-lisp-sec]. 656 0 1 2 3 657 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 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | AD Type | Authentication Data Content . . . | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 Reserved: This field MUST be set to 0 on transmit and MUST be 663 ignored on receipt. 665 Record Count: This is the number of records in this reply message. 666 A record is comprised of that portion of the packet labeled 667 'Record' above and occurs the number of times equal to Record 668 Count. 670 Nonce: This is a 24-bit value set in a Data-Probe 671 [I-D.ietf-lisp-rfc6830bis] or a 64-bit value from the Map-Request 672 is echoed in this 'Nonce' field of the Map-Reply. When a 24-bit 673 value is supplied, it resides in the low-order 64 bits of the 674 'Nonce' field. 676 Record TTL: This is the time in minutes the recipient of the Map- 677 Reply will store the mapping. If the TTL is 0, the entry MUST be 678 removed from the cache immediately. If the value is 0xffffffff, 679 the recipient can decide locally how long to store the mapping. 681 Locator Count: This is the number of Locator entries. A Locator 682 entry comprises what is labeled above as 'Loc'. The Locator count 683 can be 0, indicating that there are no Locators for the EID- 684 Prefix. 686 EID mask-len: This is the mask length for the EID-Prefix. 688 ACT: This 3-bit field describes Negative Map-Reply actions. In any 689 other message type, these bits are set to 0 and ignored on 690 receipt. These bits are used only when the 'Locator Count' field 691 is set to 0. The action bits are encoded only in Map-Reply 692 messages. They are used to tell an ITR or PITR why a empty 693 locator-set was returned from the mapping system and how it stores 694 the map-cache entry. 696 (0) No-Action: The Map-Cache is kept alive, and no packet 697 encapsulation occurs. 699 (1) Natively-Forward: The packet is not encapsulated or dropped 700 but natively forwarded. 702 (2) Send-Map-Request: The Map-Cache entry is created and flagged 703 that any packet matching this entry invokes sending a Map- 704 Request. 706 (3) Drop/No-Reason: A packet that matches this Map-Cache entry is 707 dropped. An ICMP Destination Unreachable message SHOULD be 708 sent. 710 (4) Drop/Policy-Denied: A packet that matches this Map-Cache 711 entry is dropped. The reason for the Drop action is that a 712 Map-Request for the target-EID is being policy denied by 713 either an xTR or the mapping system. 715 (5) Drop/Authentication-Failure: A packet that matches this Map- 716 Cache entry is dropped. The reason for the Drop action is 717 that a Map-Request for the target-EID fails an authentication 718 verification-check by either an xTR or the mapping system. 720 A: The Authoritative bit, when sent, is always set to 1 by an ETR. 721 When a Map-Server is proxy Map-Replying for a LISP site, the 722 Authoritative bit is set to 0. This indicates to requesting ITRs 723 that the Map-Reply was not originated by a LISP node managed at 724 the site that owns the EID-Prefix. 726 Map-Version Number: When this 12-bit value is non-zero, the Map- 727 Reply sender is informing the ITR what the version number is for 728 the EID record contained in the Map-Reply. The ETR can allocate 729 this number internally but MUST coordinate this value with other 730 ETRs for the site. When this value is 0, there is no versioning 731 information conveyed. The Map-Version Number can be included in 732 Map-Request and Map-Register messages. See Map-Versioning 733 [I-D.ietf-lisp-6834bis] for more details. 735 EID-Prefix-AFI: Address family of the EID-Prefix according to [AFI] 736 and [RFC8060]. 738 EID-Prefix: This prefix is 4 octets for an IPv4 address family and 739 16 octets for an IPv6 address family. 741 Priority: Each RLOC is assigned a unicast Priority. Lower values 742 are more preferable. When multiple RLOCs have the same Priority, 743 they may be used in a load-split fashion. A value of 255 means 744 the RLOC MUST NOT be used for unicast forwarding. 746 Weight: When priorities are the same for multiple RLOCs, the Weight 747 indicates how to balance unicast traffic between them. Weight is 748 encoded as a relative weight of total unicast packets that match 749 the mapping entry. For example, if there are 4 Locators in a 750 Locator-Set, where the Weights assigned are 30, 20, 20, and 10, 751 the first Locator will get 37.5% of the traffic, the 2nd and 3rd 752 Locators will get 25% of the traffic, and the 4th Locator will get 753 12.5% of the traffic. If all Weights for a Locator-Set are equal, 754 the receiver of the Map-Reply will decide how to load-split the 755 traffic. See RLOC-hashing [I-D.ietf-lisp-rfc6830bis] for a 756 suggested hash algorithm to distribute the load across Locators 757 with the same Priority and equal Weight values. 759 M Priority: Each RLOC is assigned a multicast Priority used by an 760 ETR in a receiver multicast site to select an ITR in a source 761 multicast site for building multicast distribution trees. A value 762 of 255 means the RLOC MUST NOT be used for joining a multicast 763 distribution tree. For more details, see [RFC6831]. 765 M Weight: When priorities are the same for multiple RLOCs, the 766 Weight indicates how to balance building multicast distribution 767 trees across multiple ITRs. The Weight is encoded as a relative 768 weight (similar to the unicast Weights) of the total number of 769 trees built to the source site identified by the EID-Prefix. If 770 all Weights for a Locator-Set are equal, the receiver of the Map- 771 Reply will decide how to distribute multicast state across ITRs. 772 For more details, see [RFC6831]. 774 Unused Flags: These are set to 0 when sending and ignored on 775 receipt. 777 L: When this bit is set, the Locator is flagged as a local Locator to 778 the ETR that is sending the Map-Reply. When a Map-Server is doing 779 proxy Map-Replying for a LISP site, the L-bit is set to 0 for all 780 Locators in this Locator-Set. 782 p: When this bit is set, an ETR informs the RLOC-Probing ITR that the 783 locator address for which this bit is set is the one being RLOC- 784 probed and may be different from the source address of the Map- 785 Reply. An ITR that RLOC-probes a particular Locator MUST use this 786 Locator for retrieving the data structure used to store the fact 787 that the Locator is reachable. The p-bit is set for a single 788 Locator in the same Locator-Set. If an implementation sets more 789 than one p-bit erroneously, the receiver of the Map-Reply MUST 790 select the first Locator. The p-bit MUST NOT be set for Locator- 791 Set records sent in Map-Request and Map-Register messages. 793 R: This is set when the sender of a Map-Reply has a route to the 794 Locator in the Locator data record. This receiver may find this 795 useful to know if the Locator is up but not necessarily reachable 796 from the receiver's point of view. See also EID-Reachability 797 Section 7.1 for another way the R-bit may be used. 799 Locator: This is an IPv4 or IPv6 address (as encoded by the 'Loc- 800 AFI' field) assigned to an ETR. Note that the destination RLOC 801 address MAY be an anycast address. A source RLOC can be an 802 anycast address as well. The source or destination RLOC MUST NOT 803 be the broadcast address (255.255.255.255 or any subnet broadcast 804 address known to the router) and MUST NOT be a link-local 805 multicast address. The source RLOC MUST NOT be a multicast 806 address. The destination RLOC SHOULD be a multicast address if it 807 is being mapped from a multicast destination EID. 809 5.5. EID-to-RLOC UDP Map-Reply Message 811 A Map-Reply returns an EID-Prefix with a prefix length that is less 812 than or equal to the EID being requested. The EID being requested is 813 either from the destination field of an IP header of a Data-Probe or 814 the EID record of a Map-Request. The RLOCs in the Map-Reply are 815 routable IP addresses of all ETRs for the LISP site. Each RLOC 816 conveys status reachability but does not convey path reachability 817 from a requester's perspective. Separate testing of path 818 reachability is required. See RLOC-reachability Section 7.1 for 819 details. 821 Note that a Map-Reply MAY contain different EID-Prefix granularity 822 (prefix + length) than the Map-Request that triggers it. This might 823 occur if a Map-Request were for a prefix that had been returned by an 824 earlier Map-Reply. In such a case, the requester updates its cache 825 with the new prefix information and granularity. For example, a 826 requester with two cached EID-Prefixes that are covered by a Map- 827 Reply containing one less-specific prefix replaces the entry with the 828 less-specific EID-Prefix. Note that the reverse, replacement of one 829 less-specific prefix with multiple more-specific prefixes, can also 830 occur, not by removing the less-specific prefix but rather by adding 831 the more-specific prefixes that, during a lookup, will override the 832 less-specific prefix. 834 When an EID moves out of a LISP site [I-D.ietf-lisp-eid-mobility], 835 the database mapping system may have overlapping EID-prefixes. Or 836 when a LISP site is configured with multiple sets of ETRs that 837 support different EID-prefix lengths, the database mapping system may 838 have overlapping EID-prefixes. When overlapping EID-prefixes exist, 839 a Map-Request with an EID that best matches any EID-Prefix MUST be 840 returned in a single Map-Reply message. For instance, if an ETR had 841 database mapping entries for EID-Prefixes: 843 2001:db8::/16 844 2001:db8:1::/24 845 2001:db8:1:1::/32 846 2001:db8:1:2::/32 848 A Map-Request for EID 2001:db8:1:1::1 would cause a Map-Reply with a 849 record count of 1 to be returned with a mapping record EID-Prefix of 850 2001:db8:1:1::/32. 852 A Map-Request for EID 2001:db8:1:5::5 would cause a Map-Reply with a 853 record count of 3 to be returned with mapping records for EID- 854 Prefixes 2001:db8:1::/24, 2001:db8:1:1::/32, 2001:db8:1:2::/32. Note 855 filling out the /24 with more-specifics that exist in the mapping 856 system. 858 Note that not all overlapping EID-Prefixes need to be returned but 859 only the more-specific entries (note that in the second example above 860 2001:db8::/16 was not returned for requesting EID 2001:db8:1:5::5) 861 for the matching EID-Prefix of the requesting EID. When more than 862 one EID-Prefix is returned, all SHOULD use the same Time to Live 863 value so they can all time out at the same time. When a more- 864 specific EID-Prefix is received later, its Time to Live value in the 865 Map-Reply record can be stored even when other less-specific entries 866 exist. When a less-specific EID-Prefix is received later, its Map- 867 Cache expiration time SHOULD be set to the minimum expiration time of 868 any more-specific EID-Prefix in the Map-Cache. This is done so the 869 integrity of the EID-Prefix set is wholly maintained and so no more- 870 specific entries are removed from the Map-Cache while keeping less- 871 specific entries. 873 Map-Replies SHOULD be sent for an EID-Prefix no more often than once 874 per second to the same requesting router. For scalability, it is 875 expected that aggregation of EID addresses into EID-Prefixes will 876 allow one Map-Reply to satisfy a mapping for the EID addresses in the 877 prefix range, thereby reducing the number of Map-Request messages. 879 Map-Reply records can have an empty Locator-Set. A Negative Map- 880 Reply is a Map-Reply with an empty Locator-Set. Negative Map-Replies 881 convey special actions by the sender to the ITR or PITR that have 882 solicited the Map-Reply. There are two primary applications for 883 Negative Map-Replies. The first is for a Map-Resolver to instruct an 884 ITR or PITR when a destination is for a LISP site versus a non-LISP 885 site, and the other is to source quench Map-Requests that are sent 886 for non-allocated EIDs. 888 For each Map-Reply record, the list of Locators in a Locator-Set MUST 889 appear in the same order for each ETR that originates a Map-Reply 890 message. The Locator-Set MUST be sorted in order of ascending IP 891 address where an IPv4 locator address is considered numerically 'less 892 than' an IPv6 locator address. 894 When sending a Map-Reply message, the destination address is copied 895 from one of the 'ITR-RLOC' fields from the Map-Request. The ETR can 896 choose a locator address from one of the address families it 897 supports. For Data-Probes, the destination address of the Map-Reply 898 is copied from the source address of the Data-Probe message that is 899 invoking the reply. The source address of the Map-Reply is one of 900 the local IP addresses chosen to allow Unicast Reverse Path 901 Forwarding (uRPF) checks to succeed in the upstream service provider. 902 The destination port of a Map-Reply message is copied from the source 903 port of the Map-Request or Data-Probe, and the source port of the 904 Map-Reply message is set to the well-known UDP port 4342. 906 5.6. Map-Register Message Format 908 This section specifies the encoding format for the Map-Register 909 message. The message is sent in UDP with a destination UDP port of 910 4342 and a randomly selected UDP source port number. 912 The Map-Register message format is: 914 0 1 2 3 915 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 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 |Type=3 |P|S|I| Reserved |E|T|a|m|M| Record Count | 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | Nonce . . . | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 | . . . Nonce | 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 | Key ID | Algorithm ID | Authentication Data Length | 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 ~ Authentication Data ~ 926 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | | Record TTL | 928 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 R | Locator Count | EID mask-len | ACT |A| Reserved | 930 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 c | Rsvd | Map-Version Number | EID-Prefix-AFI | 932 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 r | EID-Prefix | 934 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 | /| Priority | Weight | M Priority | M Weight | 936 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | o | Unused Flags |L|p|R| Loc-AFI | 938 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 | \| Locator | 940 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 Packet field descriptions: 944 Type: 3 (Map-Register) 946 P: This is the proxy Map-Reply bit. When set to 1, an ETR sends a 947 Map-Register message requesting the Map-Server to proxy a Map- 948 Reply. The Map-Server will send non-authoritative Map-Replies on 949 behalf of the ETR. 951 S: This is the security-capable bit. When set, the procedures from 952 [I-D.ietf-lisp-sec] are supported. 954 I: This is the xTR-ID bit. When this bit is set, what is appended to 955 the Map-Register is a 128-bit xTR router-ID and then a 64-bit 956 site-ID. See LISP NAT-Traversal procedures in 957 [I-D.ermagan-lisp-nat-traversal] for details. 959 Reserved: This field MUST be set to 0 on transmit and MUST be 960 ignored on receipt. 962 E: This is the Map-Register EID-notify bit. This is used by a First- 963 Hop-Router (FHR) which discovers a dynamic-EID. This EID-notify 964 based Map-Register is sent by the FHR to the same site xTR that 965 propogates the Map-Register to the mapping system. The site xTR 966 keeps state to later Map-Notify the FHR after the EID has moves 967 away. See [I-D.ietf-lisp-eid-mobility] for a detailed use-case. 969 T: This is the use-TTL for timeout bit. When set to 1, the xTR wants 970 the Map-Server to time out registrations based on the value in the 971 "Record TTL" field of this message. 973 a: This is the merge-request bit. When set to 1, the xTR requests to 974 merge RLOC-records from different xTRs registering the same EID- 975 record. See signal-free multicast [RFC8378] for one use case 976 example. 978 m: This is the mobile-node bit. When set to 1, the registering xTR 979 supports the procedures in [I-D.ietf-lisp-mn]. This bit can be 980 ignored if an implementation does not support [I-D.ietf-lisp-mn] 982 M: This is the want-map-notify bit. When set to 1, an ETR is 983 requesting a Map-Notify message to be returned in response to 984 sending a Map-Register message. The Map-Notify message sent by a 985 Map-Server is used to acknowledge receipt of a Map-Register 986 message. 988 Record Count: This is the number of records in this Map-Register 989 message. A record is comprised of that portion of the packet 990 labeled 'Record' above and occurs the number of times equal to 991 Record Count. 993 Nonce: This 8-octet 'Nonce' field is set to 0 in Map-Register 994 messages if no Map-Notify message is expected to acknowledge it. 995 Since the Map-Register message is authenticated, the 'Nonce' field 996 is not currently used for any security function but may be in the 997 future as part of an anti-replay solution. 999 Key ID: This is a configured key-id value that corresponds to a 1000 shared-secret password that is used to authenticate the sender. 1002 Multiple shared-secrets can be used to roll over keys in a non- 1003 disruptive way. 1005 Algorithm ID: This is the configured Message Authentication Code 1006 (MAC) algorithm value used for the authentication function. See 1007 Algorithm ID Numbers in the Section 11.5 for codepoint 1008 assignments. 1010 Authentication Data Length: This is the length in octets of the 1011 'Authentication Data' field that follows this field. The length 1012 of the 'Authentication Data' field is dependent on the MAC 1013 algorithm used. The length field allows a device that doesn't 1014 know the MAC algorithm to correctly parse the packet. 1016 Authentication Data: This is the message digest used from the output 1017 of the MAC algorithm. The entire Map-Register payload is 1018 authenticated with this field preset to 0. After the MAC is 1019 computed, it is placed in this field. Implementations of this 1020 specification MUST include support for HMAC-SHA-1-96 [RFC2404], 1021 and support for HMAC-SHA-256-128 [RFC4868] is RECOMMENDED. 1023 The definition of the rest of the Map-Register can be found in EID- 1024 record description in Section 5.4. 1026 5.7. Map-Notify/Map-Notify-Ack Message Format 1028 This section specifies the encoding format for the Map-Notify and 1029 Map-Notify-Ack messages. The messages are sent inside a UDP packet 1030 with source and destination UDP ports equal to 4342. 1032 The Map-Notify and Map-Notify-Ack message formats are: 1034 0 1 2 3 1035 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 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 |Type=4/5| Reserved | Record Count | 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 | Nonce . . . | 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 | . . . Nonce | 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 | Key ID | Algorithm ID | Authentication Data Length | 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 ~ Authentication Data ~ 1046 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 | | Record TTL | 1048 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 R | Locator Count | EID mask-len | ACT |A| Reserved | 1050 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 c | Rsvd | Map-Version Number | EID-Prefix-AFI | 1052 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 r | EID-Prefix | 1054 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | /| Priority | Weight | M Priority | M Weight | 1056 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 | o | Unused Flags |L|p|R| Loc-AFI | 1058 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 | \| Locator | 1060 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 Packet field descriptions: 1064 Type: 4/5 (Map-Notify/Map-Notify-Ack) 1066 The Map-Notify message has the same contents as a Map-Register 1067 message. See the Map-Register section for field descriptions. 1069 The Map-Notify-Ack message has the same contents as a Map-Notify 1070 message. It is used to acknowledge the receipt of a Map-Notify and 1071 for the sender to stop retransmitting a Map-Notify with the same 1072 nonce. 1074 A Map-Server sends an unsolicited Map-Notify message (one that is not 1075 used as an acknowledgment to a Map-Register message) that follows the 1076 Congestion Control And Relability Guideline sections of [RFC8085]. A 1077 Map-Notify is retransmitted until a Map-Notify-Ack is received by the 1078 Map-Server with the same nonce used in the Map-Notify message. If a 1079 Map-Notify-Ack is never received by the Map-Server, it issues a log 1080 message. An implementation SHOULD retransmit up to 3 times at 3 1081 second retransmission intervals, after which time the retransmission 1082 interval is exponentially backed-off for another 3 retransmission 1083 attempts. After this time, an xTR can only get the RLOC-set change 1084 by later querying the mapping system or by RLOC-probing one of the 1085 RLOCs of the existing cached RLOC-set to get the new RLOC-set. 1087 5.8. Encapsulated Control Message Format 1089 An Encapsulated Control Message (ECM) is used to encapsulate control 1090 packets sent between xTRs and the mapping database system. 1092 0 1 2 3 1093 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 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 / | IPv4 or IPv6 Header | 1096 OH | (uses RLOC addresses) | 1097 \ | | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 / | Source Port = xxxx | Dest Port = 4342 | 1100 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 \ | UDP Length | UDP Checksum | 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 LISP |Type=8 |S|D|E|M| Reserved | 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 / | IPv4 or IPv6 Header | 1106 IH | (uses RLOC or EID addresses) | 1107 \ | | 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 / | Source Port = xxxx | Dest Port = yyyy | 1110 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 \ | UDP Length | UDP Checksum | 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 LCM | LISP Control Message | 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 Packet header descriptions: 1118 OH: The outer IPv4 or IPv6 header, which uses RLOC addresses in the 1119 source and destination header address fields. 1121 UDP: The outer UDP header with destination port 4342. The source 1122 port is randomly allocated. The checksum field MUST be non- 1123 zero. 1125 LISP: Type 8 is defined to be a "LISP Encapsulated Control Message", 1126 and what follows is either an IPv4 or IPv6 header as encoded by 1127 the first 4 bits after the 'Reserved' field. 1129 Type: 8 (Encapsulated Control Message (ECM)) 1131 S: This is the Security bit. When set to 1, the field following 1132 the 'Reserved' field will have the following Authentication 1133 Data format and follow the procedures from [I-D.ietf-lisp-sec]. 1135 0 1 2 3 1136 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 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 | AD Type | Authentication Data Content . . . | 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 D: This is the DDT-bit. When set to 1, the sender is requesting a 1142 Map-Referral message to be returned. The details of this 1143 procedure are described in [RFC8111]. 1145 E: This is the to-ETR bit. When set to 1, the Map-Server's 1146 intention is to forward the ECM to an authoritative ETR. 1148 M: This is the to-MS bit. When set to 1, a Map-Request is being 1149 sent to a co-located Map-Resolver and Map-Server where the 1150 message can be processed directly by the Map-Server versus the 1151 Map-Resolver using the LISP-DDT procedures in [RFC8111]. 1153 IH: The inner IPv4 or IPv6 header, which can use either RLOC or EID 1154 addresses in the header address fields. When a Map-Request is 1155 encapsulated in this packet format, the destination address in 1156 this header is an EID. 1158 UDP: The inner UDP header, where the port assignments depend on the 1159 control packet being encapsulated. When the control packet is 1160 a Map-Request or Map-Register, the source port is selected by 1161 the ITR/PITR and the destination port is 4342. When the 1162 control packet is a Map-Reply, the source port is 4342 and the 1163 destination port is assigned from the source port of the 1164 invoking Map-Request. Port number 4341 MUST NOT be assigned to 1165 either port. The checksum field MUST be non-zero. 1167 LCM: The format is one of the control message formats described in 1168 this section. At this time, only Map-Request messages are 1169 allowed to be Control-Plane (ECM) encapsulated. In the future, 1170 PIM Join/Prune messages [RFC6831] might be allowed. 1171 Encapsulating other types of LISP control messages is for 1172 further study. When Map-Requests are sent for RLOC-Probing 1173 purposes (i.e., the probe-bit is set), they MUST NOT be sent 1174 inside Encapsulated Control Messages. 1176 6. Changing the Contents of EID-to-RLOC Mappings 1178 In the LISP architecture ITRs/PITRs use a local Map-Cache to store 1179 EID-to-RLOC mappings for forwarding. When an ETR updates a mapping a 1180 mechanism is required to inform ITRs/PITRs that are using such 1181 mappings. 1183 The LISP Data-Plane defines several mechanism to update mappings 1184 [I-D.ietf-lisp-rfc6830bis]. This document specifies the Solicit-Map 1185 Request (SMR), a Control-Plane push-based mechanism. An additional 1186 Control-Plane mechanism based on the Publish/subscribe paradigm is 1187 specified in [I-D.ietf-lisp-pubsub]. 1189 6.1. Solicit-Map-Request (SMR) 1191 Soliciting a Map-Request is a selective way for ETRs, at the site 1192 where mappings change, to control the rate they receive requests for 1193 Map-Reply messages. SMRs are also used to tell remote ITRs to update 1194 the mappings they have cached. 1196 Since the ETRs don't keep track of remote ITRs that have cached their 1197 mappings, they do not know which ITRs need to have their mappings 1198 updated. As a result, an ETR will solicit Map-Requests (called an 1199 SMR message) to those sites to which it has been sending encapsulated 1200 data for the last minute. In particular, an ETR will send an SMR to 1201 an ITR to which it has recently sent encapsulated data. This can 1202 only occur when both ITR and ETR functionality reside in the same 1203 router. 1205 An SMR message is simply a bit set in a Map-Request message. An ITR 1206 or PITR will send a Map-Request when they receive an SMR message. 1207 Both the SMR sender and the Map-Request responder MUST rate-limit 1208 these messages. Rate-limiting can be implemented as a global rate- 1209 limiter or one rate-limiter per SMR destination. 1211 The following procedure shows how an SMR exchange occurs when a site 1212 is doing Locator-Set compaction for an EID-to-RLOC mapping: 1214 1. When the database mappings in an ETR change, the ETRs at the site 1215 begin to send Map-Requests with the SMR bit set for each Locator 1216 in each Map-Cache entry the ETR caches. 1218 2. A remote ITR that receives the SMR message will schedule sending 1219 a Map-Request message to the source locator address of the SMR 1220 message or to the mapping database system. A newly allocated 1221 random nonce is selected, and the EID-Prefix used is the one 1222 copied from the SMR message. If the source Locator is the only 1223 Locator in the cached Locator-Set, the remote ITR SHOULD send a 1224 Map-Request to the database mapping system just in case the 1225 single Locator has changed and may no longer be reachable to 1226 accept the Map-Request. 1228 3. The remote ITR MUST rate-limit the Map-Request until it gets a 1229 Map-Reply while continuing to use the cached mapping. When 1230 Map-Versioning as described in [I-D.ietf-lisp-6834bis] is used, 1231 an SMR sender can detect if an ITR is using the most up-to-date 1232 database mapping. 1234 4. The ETRs at the site with the changed mapping will reply to the 1235 Map-Request with a Map-Reply message that has a nonce from the 1236 SMR-invoked Map-Request. The Map-Reply messages MUST be rate- 1237 limited according to procedures in [RFC8085]. This is important 1238 to avoid Map-Reply implosion. 1240 5. The ETRs at the site with the changed mapping record the fact 1241 that the site that sent the Map-Request has received the new 1242 mapping data in the Map-Cache entry for the remote site so the 1243 Locator-Status-Bits are reflective of the new mapping for packets 1244 going to the remote site. The ETR then stops sending SMR 1245 messages. 1247 For security reasons, an ITR MUST NOT process unsolicited Map- 1248 Replies. To avoid Map-Cache entry corruption by a third party, a 1249 sender of an SMR-based Map-Request MUST be verified. If an ITR 1250 receives an SMR-based Map-Request and the source is not in the 1251 Locator-Set for the stored Map-Cache entry, then the responding Map- 1252 Request MUST be sent with an EID destination to the mapping database 1253 system. Since the mapping database system is a more secure way to 1254 reach an authoritative ETR, it will deliver the Map-Request to the 1255 authoritative source of the mapping data. 1257 When an ITR receives an SMR-based Map-Request for which it does not 1258 have a cached mapping for the EID in the SMR message, it SHOULD NOT 1259 send an SMR-invoked Map-Request. This scenario can occur when an ETR 1260 sends SMR messages to all Locators in the Locator-Set it has stored 1261 in its Map-Cache but the remote ITRs that receive the SMR may not be 1262 sending packets to the site. There is no point in updating the ITRs 1263 until they need to send, in which case they will send Map-Requests to 1264 obtain a Map-Cache entry. 1266 7. Routing Locator Reachability 1268 This document defines several Control-Plane mechanisms for 1269 determining RLOC reachability. Please note that additional Data- 1270 Plane reachability mechanisms are defined in 1271 [I-D.ietf-lisp-rfc6830bis]. 1273 1. An ITR may receive an ICMP Network Unreachable or Host 1274 Unreachable message for an RLOC it is using. This indicates that 1275 the RLOC is likely down. Note that trusting ICMP messages may 1276 not be desirable, but neither is ignoring them completely. 1277 Implementations are encouraged to follow current best practices 1278 in treating these conditions [I-D.ietf-opsec-icmp-filtering]. 1280 2. When an ITR participates in the routing protocol that operates in 1281 the underlay routing system, it can determine that an RLOC is 1282 down when no Routing Information Base (RIB) entry exists that 1283 matches the RLOC IP address. 1285 3. An ITR may receive an ICMP Port Unreachable message from a 1286 destination host. This occurs if an ITR attempts to use 1287 interworking [RFC6832] and LISP-encapsulated data is sent to a 1288 non-LISP-capable site. 1290 4. An ITR may receive a Map-Reply from an ETR in response to a 1291 previously sent Map-Request. The RLOC source of the Map-Reply is 1292 likely up, since the ETR was able to send the Map-Reply to the 1293 ITR. 1295 5. An ITR/ETR pair can use the 'RLOC-Probing' mechanism described 1296 below. 1298 When ITRs receive ICMP Network Unreachable or Host Unreachable 1299 messages as a method to determine unreachability, they will refrain 1300 from using Locators that are described in Locator lists of Map- 1301 Replies. However, using this approach is unreliable because many 1302 network operators turn off generation of ICMP Destination Unreachable 1303 messages. 1305 If an ITR does receive an ICMP Network Unreachable or Host 1306 Unreachable message, it MAY originate its own ICMP Destination 1307 Unreachable message destined for the host that originated the data 1308 packet the ITR encapsulated. 1310 Also, BGP-enabled ITRs can unilaterally examine the RIB to see if a 1311 locator address from a Locator-Set in a mapping entry matches a 1312 prefix. If it does not find one and BGP is running in the Default- 1313 Free Zone (DFZ), it can decide to not use the Locator even though the 1314 Locator-Status-Bits indicate that the Locator is up. In this case, 1315 the path from the ITR to the ETR that is assigned the Locator is not 1316 available. More details are in [I-D.meyer-loc-id-implications]. 1318 Optionally, an ITR can send a Map-Request to a Locator, and if a Map- 1319 Reply is returned, reachability of the Locator has been determined. 1320 Obviously, sending such probes increases the number of control 1321 messages originated by Tunnel Routers for active flows, so Locators 1322 are assumed to be reachable when they are advertised. 1324 This assumption does create a dependency: Locator unreachability is 1325 detected by the receipt of ICMP Host Unreachable messages. When a 1326 Locator has been determined to be unreachable, it is not used for 1327 active traffic; this is the same as if it were listed in a Map-Reply 1328 with Priority 255. 1330 The ITR can test the reachability of the unreachable Locator by 1331 sending periodic Requests. Both Requests and Replies MUST be rate- 1332 limited. Locator reachability testing is never done with data 1333 packets, since that increases the risk of packet loss for end-to-end 1334 sessions. 1336 7.1. RLOC-Probing Algorithm 1338 RLOC-Probing is a method that an ITR or PITR can use to determine the 1339 reachability status of one or more Locators that it has cached in a 1340 Map-Cache entry. The probe-bit of the Map-Request and Map-Reply 1341 messages is used for RLOC-Probing. 1343 RLOC-Probing is done in the control plane on a timer basis, where an 1344 ITR or PITR will originate a Map-Request destined to a locator 1345 address from one of its own locator addresses. A Map-Request used as 1346 an RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or to 1347 the mapping database system as one would when soliciting mapping 1348 data. The EID record encoded in the Map-Request is the EID-Prefix of 1349 the Map-Cache entry cached by the ITR or PITR. The ITR MAY include a 1350 mapping data record for its own database mapping information that 1351 contains the local EID-Prefixes and RLOCs for its site. RLOC-probes 1352 are sent periodically using a jittered timer interval. 1354 When an ETR receives a Map-Request message with the probe-bit set, it 1355 returns a Map-Reply with the probe-bit set. The source address of 1356 the Map-Reply is set according to the procedure described in 1357 [I-D.ietf-lisp-rfc6830bis]. The Map-Reply SHOULD contain mapping 1358 data for the EID-Prefix contained in the Map-Request. This provides 1359 the opportunity for the ITR or PITR that sent the RLOC-probe to get 1360 mapping updates if there were changes to the ETR's database mapping 1361 entries. 1363 There are advantages and disadvantages of RLOC-Probing. The greatest 1364 benefit of RLOC-Probing is that it can handle many failure scenarios 1365 allowing the ITR to determine when the path to a specific Locator is 1366 reachable or has become unreachable, thus providing a robust 1367 mechanism for switching to using another Locator from the cached 1368 Locator. RLOC-Probing can also provide rough Round-Trip Time (RTT) 1369 estimates between a pair of Locators, which can be useful for network 1370 management purposes as well as for selecting low delay paths. The 1371 major disadvantage of RLOC-Probing is in the number of control 1372 messages required and the amount of bandwidth used to obtain those 1373 benefits, especially if the requirement for failure detection times 1374 is very small. 1376 8. Interactions with Other LISP Components 1378 8.1. ITR EID-to-RLOC Mapping Resolution 1380 An ITR is configured with one or more Map-Resolver addresses. These 1381 addresses are "Locators" (or RLOCs) and MUST be routable on the 1382 underlying core network; they MUST NOT need to be resolved through 1383 LISP EID-to-RLOC mapping, as that would introduce a circular 1384 dependency. When using a Map-Resolver, an ITR does not need to 1385 connect to any other database mapping system. In particular, the ITR 1386 need not connect to the LISP-ALT infrastructure or implement the BGP 1387 and GRE protocols that it uses. 1389 An ITR sends an Encapsulated Map-Request to a configured Map-Resolver 1390 when it needs an EID-to-RLOC mapping that is not found in its local 1391 Map-Cache. Using the Map-Resolver greatly reduces both the 1392 complexity of the ITR implementation and the costs associated with 1393 its operation. 1395 In response to an Encapsulated Map-Request, the ITR can expect one of 1396 the following: 1398 o An immediate Negative Map-Reply (with action code of "Natively- 1399 Forward", 15-minute Time to Live (TTL)) from the Map-Resolver if 1400 the Map-Resolver can determine that the requested EID does not 1401 exist. The ITR saves the EID-Prefix returned in the Map-Reply in 1402 its cache, marks it as non-LISP-capable, and knows not to attempt 1403 LISP encapsulation for destinations matching it. 1405 o A Negative Map-Reply, with action code of "Natively-Forward", from 1406 a Map-Server that is authoritative for an EID-Prefix that matches 1407 the requested EID but that does not have an actively registered, 1408 more-specific ID-prefix. In this case, the requested EID is said 1409 to match a "hole" in the authoritative EID-Prefix. If the 1410 requested EID matches a more-specific EID-Prefix that has been 1411 delegated by the Map-Server but for which no ETRs are currently 1412 registered, a 1-minute TTL is returned. If the requested EID 1413 matches a non-delegated part of the authoritative EID-Prefix, then 1414 it is not a LISP EID and a 15-minute TTL is returned. See 1415 Section 8.2 for discussion of aggregate EID-Prefixes and details 1416 of Map-Server EID-Prefix matching. 1418 o A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or 1419 possibly from a Map-Server answering on behalf of the ETR. See 1420 Section 8.4 for more details on Map-Resolver message processing. 1422 Note that an ITR may be configured to both use a Map-Resolver and to 1423 participate in a LISP-ALT logical network. In such a situation, the 1424 ITR SHOULD send Map-Requests through the ALT network for any EID- 1425 Prefix learned via ALT BGP. Such a configuration is expected to be 1426 very rare, since there is little benefit to using a Map-Resolver if 1427 an ITR is already using LISP-ALT. There would be, for example, no 1428 need for such an ITR to send a Map-Request to a possibly non-existent 1429 EID (and rely on Negative Map-Replies) if it can consult the ALT 1430 database to verify that an EID-Prefix is present before sending that 1431 Map-Request. 1433 8.2. EID-Prefix Configuration and ETR Registration 1435 An ETR publishes its EID-Prefixes on a Map-Server by sending LISP 1436 Map-Register messages. A Map-Register message includes 1437 authentication data, so prior to sending a Map-Register message, the 1438 ETR and Map-Server SHOULD be configured with a shared secret or other 1439 relevant authentication information. A Map-Server's configuration 1440 SHOULD also include a list of the EID-Prefixes for which each ETR is 1441 authoritative. Upon receipt of a Map-Register from an ETR, a Map- 1442 Server accepts only EID-Prefixes that are configured for that ETR. 1443 Failure to implement such a check would leave the mapping system 1444 vulnerable to trivial EID-Prefix hijacking attacks. As developers 1445 and operators gain experience with the mapping system, additional, 1446 stronger security measures may be added to the registration process. 1448 In addition to the set of EID-Prefixes defined for each ETR that may 1449 register, a Map-Server is typically also configured with one or more 1450 aggregate prefixes that define the part of the EID numbering space 1451 assigned to it. When LISP-ALT is the database in use, aggregate EID- 1452 Prefixes are implemented as discard routes and advertised into ALT 1453 BGP. The existence of aggregate EID-Prefixes in a Map-Server's 1454 database means that it may receive Map Requests for EID-Prefixes that 1455 match an aggregate but do not match a registered prefix; Section 8.3 1456 describes how this is handled. 1458 Map-Register messages are sent periodically from an ETR to a Map- 1459 Server with a suggested interval between messages of one minute. A 1460 Map-Server SHOULD time out and remove an ETR's registration if it has 1461 not received a valid Map-Register message within the past 1462 three minutes. When first contacting a Map-Server after restart or 1463 changes to its EID-to-RLOC database mappings, an ETR MAY initially 1464 send Map-Register messages at an increased frequency, up to one every 1465 20 seconds. This "quick registration" period is limited to 1466 five minutes in duration. 1468 An ETR MAY request that a Map-Server explicitly acknowledge receipt 1469 and processing of a Map-Register message by setting the "want-map- 1470 notify" (M-bit) flag. A Map-Server that receives a Map-Register with 1471 this flag set will respond with a Map-Notify message. Typical use of 1472 this flag by an ETR would be to set it for Map-Register messages sent 1473 during the initial "quick registration" with a Map-Server but then 1474 set it only occasionally during steady-state maintenance of its 1475 association with that Map-Server. Note that the Map-Notify message 1476 is sent to UDP destination port 4342, not to the source port 1477 specified in the original Map-Register message. 1479 Note that a one-minute minimum registration interval during 1480 maintenance of an ETR-Map-Server association places a lower bound on 1481 how quickly and how frequently a mapping database entry can be 1482 updated. This may have implications for what sorts of mobility can 1483 be supported directly by the mapping system; shorter registration 1484 intervals or other mechanisms might be needed to support faster 1485 mobility in some cases. For a discussion on one way that faster 1486 mobility may be implemented for individual devices, please see 1487 [I-D.ietf-lisp-mn]. 1489 An ETR MAY also request, by setting the "proxy Map-Reply" flag 1490 (P-bit) in the Map-Register message, that a Map-Server answer Map- 1491 Requests instead of forwarding them to the ETR. See Section 7.1 for 1492 details on how the Map-Server sets certain flags (such as those 1493 indicating whether the message is authoritative and how returned 1494 Locators SHOULD be treated) when sending a Map-Reply on behalf of an 1495 ETR. When an ETR requests proxy reply service, it SHOULD include all 1496 RLOCs for all ETRs for the EID-Prefix being registered, along with 1497 the routable flag ("R-bit") setting for each RLOC. The Map-Server 1498 includes all of this information in Map-Reply messages that it sends 1499 on behalf of the ETR. This differs from a non-proxy registration, 1500 since the latter need only provide one or more RLOCs for a Map-Server 1501 to use for forwarding Map-Requests; the registration information is 1502 not used in Map-Replies, so it being incomplete is not incorrect. 1504 An ETR that uses a Map-Server to publish its EID-to-RLOC mappings 1505 does not need to participate further in the mapping database 1506 protocol(s). When using a LISP-ALT mapping database, for example, 1507 this means that the ETR does not need to implement GRE or BGP, which 1508 greatly simplifies its configuration and reduces its cost of 1509 operation. 1511 Note that use of a Map-Server does not preclude an ETR from also 1512 connecting to the mapping database (i.e., it could also connect to 1513 the LISP-ALT network), but doing so doesn't seem particularly useful, 1514 as the whole purpose of using a Map-Server is to avoid the complexity 1515 of the mapping database protocols. 1517 8.3. Map-Server Processing 1519 Once a Map-Server has EID-Prefixes registered by its client ETRs, it 1520 can accept and process Map-Requests for them. 1522 In response to a Map-Request (received over the ALT if LISP-ALT is in 1523 use), the Map-Server first checks to see if the destination EID 1524 matches a configured EID-Prefix. If there is no match, the Map- 1525 Server returns a Negative Map-Reply with action code "Natively- 1526 Forward" and a 15-minute TTL. This can occur if a Map Request is 1527 received for a configured aggregate EID-Prefix for which no more- 1528 specific EID-Prefix exists; it indicates the presence of a non-LISP 1529 "hole" in the aggregate EID-Prefix. 1531 Next, the Map-Server checks to see if any ETRs have registered the 1532 matching EID-Prefix. If none are found, then the Map-Server returns 1533 a Negative Map-Reply with action code "Natively-Forward" and a 1534 1-minute TTL. 1536 If the EID-prefix is either registered or not registered to the 1537 mapping system and there is a policy in the Map-Server to have the 1538 requestor drop packets for the matching EID-prefix, then a Drop/ 1539 Policy-Denied action is returned. If the EID-prefix is registered or 1540 not registered and there is a authentication failure, then a Drop/ 1541 Authentication- failure action is returned. If either of these 1542 actions result as a temporary state in policy or authentication then 1543 a Send-Map-Request action with 1-minute TTL MAY be returned to allow 1544 the requestor to retry the Map-Request. 1546 If any of the registered ETRs for the EID-Prefix have requested proxy 1547 reply service, then the Map-Server answers the request instead of 1548 forwarding it. It returns a Map-Reply with the EID-Prefix, RLOCs, 1549 and other information learned through the registration process. 1551 If none of the ETRs have requested proxy reply service, then the Map- 1552 Server re-encapsulates and forwards the resulting Encapsulated Map- 1553 Request to one of the registered ETRs. It does not otherwise alter 1554 the Map-Request, so any Map-Reply sent by the ETR is returned to the 1555 RLOC in the Map-Request, not to the Map-Server. Unless also acting 1556 as a Map-Resolver, a Map-Server should never receive Map-Replies; any 1557 such messages SHOULD be discarded without response, perhaps 1558 accompanied by the logging of a diagnostic message if the rate of 1559 Map-Replies is suggestive of malicious traffic. 1561 8.4. Map-Resolver Processing 1563 Upon receipt of an Encapsulated Map-Request, a Map-Resolver 1564 decapsulates the enclosed message and then searches for the requested 1565 EID in its local database of mapping entries (statically configured 1566 or learned from associated ETRs if the Map-Resolver is also a Map- 1567 Server offering proxy reply service). If it finds a matching entry, 1568 it returns a LISP Map-Reply with the known mapping. 1570 If the Map-Resolver does not have the mapping entry and if it can 1571 determine that the EID is not in the mapping database (for example, 1572 if LISP-ALT is used, the Map-Resolver will have an ALT forwarding 1573 table that covers the full EID space), it immediately returns a 1574 negative LISP Map-Reply, with action code "Natively-Forward" and a 1575 15-minute TTL. To minimize the number of negative cache entries 1576 needed by an ITR, the Map-Resolver SHOULD return the least-specific 1577 prefix that both matches the original query and does not match any 1578 EID-Prefix known to exist in the LISP-capable infrastructure. 1580 If the Map-Resolver does not have sufficient information to know 1581 whether the EID exists, it needs to forward the Map-Request to 1582 another device that has more information about the EID being 1583 requested. To do this, it forwards the unencapsulated Map-Request, 1584 with the original ITR RLOC as the source, to the mapping database 1585 system. Using LISP-ALT, the Map-Resolver is connected to the ALT 1586 network and sends the Map-Request to the next ALT hop learned from 1587 its ALT BGP neighbors. The Map-Resolver does not send any response 1588 to the ITR; since the source RLOC is that of the ITR, the ETR or Map- 1589 Server that receives the Map-Request over the ALT and responds will 1590 do so directly to the ITR. 1592 8.4.1. Anycast Operation 1594 A Map-Resolver can be set up to use "anycast", where the same address 1595 is assigned to multiple Map-Resolvers and is propagated through IGP 1596 routing, to facilitate the use of a topologically close Map-Resolver 1597 by each ITR. 1599 ETRs MAY have anycast RLOC addresses which are registered as part of 1600 their RLOC-set to the mapping system. However, registrations MUST 1601 use their unique RLOC addresses, xTR-IDs, or distinct authentication 1602 keys to identify security associations with the Map-Servers. 1604 9. Security Considerations 1606 The 2-way LISP header nonce exchange documented in 1607 [I-D.ietf-lisp-rfc6830bis] can be used to avoid ITR spoofing attacks. 1609 To publish an authoritative EID-to-RLOC mapping with a Map-Server, an 1610 ETR includes authentication data that is a hash of the message using 1611 a pair-wise shared key. An implementation MUST support use of HMAC- 1612 SHA-1-96 [RFC2104] and SHOULD support use of HMAC-SHA-256-128 1613 [RFC6234] (SHA-256 truncated to 128 bits). 1615 As noted in Section 8.2, a Map-Server SHOULD verify that all EID- 1616 Prefixes registered by an ETR match the configuration stored on the 1617 Map-Server. 1619 The currently defined authentication mechanism for Map-Register 1620 messages does not provide protection against "replay" attacks by a 1621 "man-in-the-middle". Additional work is needed in this area. 1623 [I-D.ietf-lisp-sec] defines a proposed mechanism for providing origin 1624 authentication, integrity, anti-replay protection, and prevention of 1625 man-in-the-middle and "overclaiming" attacks on the Map-Request/Map- 1626 Reply exchange. Work is ongoing on this and other proposals for 1627 resolving these open security issues. 1629 While beyond the scope of securing an individual Map-Server or Map- 1630 Resolver, it should be noted that a BGP-based LISP-ALT network (if 1631 ALT is used as the mapping database infrastructure) can take 1632 advantage of standards work on adding security to BGP. 1634 A complete LISP threat analysis has been published in [RFC7835]. 1635 Please refer to it for more security related details. 1637 10. Changes since RFC 6833 1639 For implementation considerations, the following changes have been 1640 made to this document since RFC 6833 was published: 1642 o A Map-Notify-Ack message is added in this document to provide 1643 reliability for Map-Notify messages. Any receiver of a Map-Notify 1644 message must respond with a Map-Notify-Ack message. Map-Servers 1645 who are senders of Map-Notify messages, must queue the Map-Notify 1646 contents until they receive a Map-Notify-Ack with the nonce used 1647 in the Map-Notify message. Note that implementations for Map- 1648 Notify-Ack support already exist and predate this document. 1650 o This document is incorporating the codepoint for the Map-Referral 1651 message from the LISP-DDT specification [RFC8111] to indicate that 1652 a Map-Server must send the final Map-Referral message when it 1653 participates in the LISP-DDT mapping system procedures. 1655 o The "m", "I", "L", and "D" bits are added to the Map-Request 1656 message. See Section 5.3 for details. 1658 o The "S", "I", "E", "T", "a", and "m" bits are added to the Map- 1659 Register message. See Section 5.6 for details. 1661 o The 16-bit Key-ID field of the Map-Register message has been split 1662 into a 8-bit Key-ID field and a 8-bit Algorithm-ID field. 1664 o This document adds two new Action values that are in an EID-record 1665 that appear in Map-Reply, Map-Register, Map-Notify, and Map- 1666 Notify-Ack messages. The Drop/Policy-Denied and Drop/Auth-Failure 1667 are the descriptions for the two new action values. See 1668 Section 5.4 for details. 1670 11. IANA Considerations 1672 This section provides guidance to the Internet Assigned Numbers 1673 Authority (IANA) regarding registration of values related to this 1674 LISP Control-Plane specification, in accordance with BCP 26 1675 [RFC8126]. 1677 There are three namespaces (listed in the sub-sections below) in LISP 1678 that have been registered. 1680 o LISP IANA registry allocations should not be made for purposes 1681 unrelated to LISP routing or transport protocols. 1683 o The following policies are used here with the meanings defined in 1684 BCP 26: "Specification Required", "IETF Review", "Experimental 1685 Use", and "First Come First Served". 1687 11.1. LISP UDP Port Numbers 1689 The IANA registry has allocated UDP port number 4342 for the LISP 1690 Control-Plane. IANA has updated the description for UDP port 4342 as 1691 follows: 1693 Keyword Port Transport Layer Description 1694 ------- ---- --------------- ----------- 1695 lisp-control 4342 udp LISP Control Packets 1697 11.2. LISP Packet Type Codes 1699 It is being requested that the IANA be authoritative for LISP Packet 1700 Type definitions and that it refers to this document as well as 1701 [RFC8113] as references. 1703 Based on deployment experience of [RFC6830], the Map-Notify-Ack 1704 message, message type 5, was added to this document. This document 1705 requests IANA to add it to the LISP Packet Type Registry. 1707 Name Number Defined in 1708 ---- ------ ----------- 1709 LISP Map-Notify-Ack 5 RFC6833bis 1711 11.3. LISP ACT and Flag Fields 1713 New ACT values can be allocated through IETF review or IESG approval. 1714 Four values have already been allocated by [RFC6830]. This 1715 specification changes the name of ACT type 3 value from "Drop" to 1716 "Drop/No-Reason" as well as adding two new ACT values, the "Drop/ 1717 Policy-Denied" (type 4) and "Drop/Authentication-Failure" (type 5). 1719 Value Action Description Reference 1720 ----- ------ ----------- --------- 1721 4 Drop/ A Packet matching this Map-Cache RFC6833bis 1722 Policy-Denied entry is dropped because the target 1723 EID is policy-denied by the xTR or 1724 the mapping system. 1726 5 Drop/ A Packet matching this Map-Cache RFC6833bis 1727 Auth-Failure entry is dropped because the 1728 Map-Request for target EID fails an 1729 authentication check by the xTR or 1730 the mapping system. 1732 In addition, LISP has a number of flag fields and reserved fields, 1733 such as the LISP header flags field [I-D.ietf-lisp-rfc6830bis]. New 1734 bits for flags in these fields can be implemented after IETF review 1735 or IESG approval, but these need not be managed by IANA. 1737 11.4. LISP Address Type Codes 1739 LISP Canonical Address Format (LCAF) [RFC8060] is an 8-bit field that 1740 defines LISP-specific encodings for AFI value 16387. LCAF encodings 1741 are used for specific use-cases where different address types for 1742 EID-records and RLOC-records are required. 1744 The IANA registry "LISP Canonical Address Format (LCAF) Types" is 1745 used for LCAF types, the registry for LCAF types use the 1746 Specification Required policy [RFC8126]. Initial values for the 1747 registry as well as further information can be found in [RFC8060]. 1749 Therefore, there is no longer a need for the "LISP Address Type 1750 Codes" registry requested by [RFC6830]. This document requests to 1751 remove it. 1753 11.5. LISP Algorithm ID Numbers 1755 In [RFC6830], a request for a "LISP Key ID Numbers" registry was 1756 submitted. This document renames the registry to "LISP Algorithm ID 1757 Numbers" and requests the IANA to make the name change. 1759 The following Algorithm ID values are defined by this specification 1760 as used in any packet type that references a 'Algorithm ID' field: 1762 Name Number Defined in 1763 ----------------------------------------------- 1764 None 0 RFC6833bis 1765 HMAC-SHA-1-96 1 [RFC2404] 1766 HMAC-SHA-256-128 2 [RFC4868] 1768 Number values are in the range of 0 to 255. The allocation of values 1769 is on a first come first served basis. 1771 12. References 1773 12.1. Normative References 1775 [I-D.ietf-lisp-6834bis] 1776 Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID 1777 Separation Protocol (LISP) Map-Versioning", draft-ietf- 1778 lisp-6834bis-02 (work in progress), September 2018. 1780 [I-D.ietf-lisp-rfc6830bis] 1781 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 1782 Cabellos-Aparicio, "The Locator/ID Separation Protocol 1783 (LISP)", draft-ietf-lisp-rfc6830bis-18 (work in progress), 1784 September 2018. 1786 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 1787 ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November 1788 1998, . 1790 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1791 "Randomness Requirements for Security", BCP 106, RFC 4086, 1792 DOI 10.17487/RFC4086, June 2005, 1793 . 1795 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 1796 384, and HMAC-SHA-512 with IPsec", RFC 4868, 1797 DOI 10.17487/RFC4868, May 2007, 1798 . 1800 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1801 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1802 March 2017, . 1804 12.2. Informative References 1806 [AFI] IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY 1807 NUMBERS http://www.iana.org/assignments/address-family- 1808 numbers/address-family-numbers.xhtml?, Febuary 2007. 1810 [GTP-3GPP] 1811 3GPP, "General Packet Radio System (GPRS) Tunnelling 1812 Protocol User Plane (GTPv1-U)", TS.29.281 1813 https://portal.3gpp.org/desktopmodules/Specifications/ 1814 SpecificationDetails.aspx?specificationId=1699, January 1815 2015. 1817 [I-D.ermagan-lisp-nat-traversal] 1818 Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, 1819 F., and C. White, "NAT traversal for LISP", draft-ermagan- 1820 lisp-nat-traversal-14 (work in progress), April 2018. 1822 [I-D.herbert-intarea-ila] 1823 Herbert, T. and P. Lapukhov, "Identifier-locator 1824 addressing for IPv6", draft-herbert-intarea-ila-01 (work 1825 in progress), March 2018. 1827 [I-D.ietf-lisp-eid-mobility] 1828 Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, 1829 F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a 1830 Unified Control Plane", draft-ietf-lisp-eid-mobility-02 1831 (work in progress), May 2018. 1833 [I-D.ietf-lisp-gpe] 1834 Maino, F., Lemon, J., Agarwal, P., Lewis, D., and M. 1835 Smith, "LISP Generic Protocol Extension", draft-ietf-lisp- 1836 gpe-05 (work in progress), August 2018. 1838 [I-D.ietf-lisp-introduction] 1839 Cabellos-Aparicio, A. and D. Saucez, "An Architectural 1840 Introduction to the Locator/ID Separation Protocol 1841 (LISP)", draft-ietf-lisp-introduction-13 (work in 1842 progress), April 2015. 1844 [I-D.ietf-lisp-mn] 1845 Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP 1846 Mobile Node", draft-ietf-lisp-mn-02 (work in progress), 1847 April 2018. 1849 [I-D.ietf-lisp-pubsub] 1850 Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., 1851 Cabellos-Aparicio, A., Barkai, S., Farinacci, D., 1852 Boucadair, M., Jacquenet, C., and S. Secci, "Publish/ 1853 Subscribe Functionality for LISP", draft-ietf-lisp- 1854 pubsub-00 (work in progress), April 2018. 1856 [I-D.ietf-lisp-sec] 1857 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 1858 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-15 1859 (work in progress), April 2018. 1861 [I-D.ietf-nvo3-vxlan-gpe] 1862 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 1863 Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work 1864 in progress), April 2018. 1866 [I-D.ietf-opsec-icmp-filtering] 1867 Gont, F., Gont, G., and C. Pignataro, "Recommendations for 1868 filtering ICMP messages", draft-ietf-opsec-icmp- 1869 filtering-04 (work in progress), July 2013. 1871 [I-D.meyer-loc-id-implications] 1872 Meyer, D. and D. Lewis, "Architectural Implications of 1873 Locator/ID Separation", draft-meyer-loc-id-implications-01 1874 (work in progress), January 2009. 1876 [I-D.rodrigueznatal-lisp-oam] 1877 Rodriguez-Natal, A., Cabellos-Aparicio, A., Portoles- 1878 Comeras, M., Kowal, M., Lewis, D., and F. Maino, "LISP-OAM 1879 (Operations, Administration and Management): Use cases and 1880 requirements", draft-rodrigueznatal-lisp-oam-08 (work in 1881 progress), June 2018. 1883 [RFC1035] Mockapetris, P., "Domain names - implementation and 1884 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1885 November 1987, . 1887 [RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the 1888 Internet checksum", RFC 1071, DOI 10.17487/RFC1071, 1889 September 1988, . 1891 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1892 Hashing for Message Authentication", RFC 2104, 1893 DOI 10.17487/RFC2104, February 1997, 1894 . 1896 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1897 Requirement Levels", BCP 14, RFC 2119, 1898 DOI 10.17487/RFC2119, March 1997, 1899 . 1901 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 1902 RFC 2890, DOI 10.17487/RFC2890, September 2000, 1903 . 1905 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 1906 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 1907 DOI 10.17487/RFC6234, May 2011, 1908 . 1910 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 1911 Locator/ID Separation Protocol (LISP)", RFC 6830, 1912 DOI 10.17487/RFC6830, January 2013, 1913 . 1915 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 1916 Locator/ID Separation Protocol (LISP) for Multicast 1917 Environments", RFC 6831, DOI 10.17487/RFC6831, January 1918 2013, . 1920 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 1921 "Interworking between Locator/ID Separation Protocol 1922 (LISP) and Non-LISP Sites", RFC 6832, 1923 DOI 10.17487/RFC6832, January 2013, 1924 . 1926 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 1927 "Locator/ID Separation Protocol Alternative Logical 1928 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 1929 January 2013, . 1931 [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to 1932 Routing Locator (RLOC) Database", RFC 6837, 1933 DOI 10.17487/RFC6837, January 2013, 1934 . 1936 [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- 1937 Pascual, J., and D. Lewis, "Locator/Identifier Separation 1938 Protocol (LISP) Network Element Deployment 1939 Considerations", RFC 7215, DOI 10.17487/RFC7215, April 1940 2014, . 1942 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 1943 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 1944 eXtensible Local Area Network (VXLAN): A Framework for 1945 Overlaying Virtualized Layer 2 Networks over Layer 3 1946 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 1947 . 1949 [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID 1950 Separation Protocol (LISP) Threat Analysis", RFC 7835, 1951 DOI 10.17487/RFC7835, April 2016, 1952 . 1954 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 1955 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 1956 February 2017, . 1958 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 1959 Smirnov, "Locator/ID Separation Protocol Delegated 1960 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 1961 May 2017, . 1963 [RFC8113] Boucadair, M. and C. Jacquenet, "Locator/ID Separation 1964 Protocol (LISP): Shared Extension Message & IANA Registry 1965 for Packet Type Allocations", RFC 8113, 1966 DOI 10.17487/RFC8113, March 2017, 1967 . 1969 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1970 Writing an IANA Considerations Section in RFCs", BCP 26, 1971 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1972 . 1974 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1975 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1976 May 2017, . 1978 [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID 1979 Separation Protocol (LISP) Multicast", RFC 8378, 1980 DOI 10.17487/RFC8378, May 2018, 1981 . 1983 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1984 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1985 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1986 July 2018, . 1988 Appendix A. Acknowledgments 1990 The authors would like to thank Greg Schudel, Darrel Lewis, John 1991 Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver, 1992 Fabio Maino, and members of the lisp@ietf.org mailing list for their 1993 feedback and helpful suggestions. 1995 Special thanks are due to Noel Chiappa for his extensive work and 1996 thought about caching in Map-Resolvers. 1998 Appendix B. Document Change Log 2000 [RFC Editor: Please delete this section on publication as RFC.] 2002 B.1. Changes to draft-ietf-lisp-rfc6833bis-15 2004 o Posted mid-September 2018. 2006 o Changes to reflect comments from Colin and Mirja. 2008 B.2. Changes to draft-ietf-lisp-rfc6833bis-14 2010 o Posted September 2018. 2012 o Changes to reflect comments from Genart, RTGarea, and Secdir 2013 reviews. 2015 B.3. Changes to draft-ietf-lisp-rfc6833bis-13 2017 o Posted August 2018. 2019 o Final editorial changes before RFC submission for Proposed 2020 Standard. 2022 o Added section "Changes since RFC 6833" so implementators are 2023 informed of any changes since the last RFC publication. 2025 B.4. Changes to draft-ietf-lisp-rfc6833bis-12 2027 o Posted late July 2018. 2029 o Moved RFC6830bis and RFC6834bis to Normative References. 2031 B.5. Changes to draft-ietf-lisp-rfc6833bis-11 2033 o Posted July 2018. 2035 o Fixed Luigi editorial comments to ready draft for RFC status and 2036 ran through IDNITs again. 2038 B.6. Changes to draft-ietf-lisp-rfc6833bis-10 2040 o Posted after LISP WG at IETF week March. 2042 o Move AD field encoding after S-bit in the ECM packet format 2043 description section. 2045 o Say more about when the new Drop actions should be sent. 2047 B.7. Changes to draft-ietf-lisp-rfc6833bis-09 2049 o Posted March IETF week 2018. 2051 o Fixed editorial comments submitted by document shepherd Luigi 2052 Iannone. 2054 B.8. Changes to draft-ietf-lisp-rfc6833bis-08 2056 o Posted March 2018. 2058 o Added RLOC-probing algorithm. 2060 o Added Solicit-Map Request algorithm. 2062 o Added several mechanisms (from 6830bis) regarding Routing Locator 2063 Reachability. 2065 o Added port 4342 to IANA Considerations section. 2067 B.9. Changes to draft-ietf-lisp-rfc6833bis-07 2069 o Posted December 2017. 2071 o Make it more clear in a couple of places that RLOCs are used to 2072 locate ETRs more so than for Map-Server Map-Request forwarding. 2074 o Make it clear that "encapsualted" for a control message is an ECM 2075 based message. 2077 o Make it more clear what messages use source-port 4342 and which 2078 ones use destinatino-port 4342. 2080 o Don't make DDT references when the mapping transport system can be 2081 of any type and the referneced text is general to it. 2083 o Generalize text when referring to the format of an EID-prefix. 2084 Can use othe AFIs then IPv4 and IPv6. 2086 o Many editorial changes to clarify text. 2088 o Changed some "must", "should", and "may" to capitalized. 2090 o Added definitions for Map-Request and Map-Reply messages. 2092 o Ran document through IDNITs. 2094 B.10. Changes to draft-ietf-lisp-rfc6833bis-06 2096 o Posted October 2017. 2098 o Spec the I-bit to include the xTR-ID in a Map-Request message to 2099 be consistent with the Map-Register message and to anticipate the 2100 introduction of pubsub functionality to allow Map-Requests to 2101 subscribe to RLOC-set changes. 2103 o Updated references for individual submissions that became working 2104 group documents. 2106 o Updated references for working group documents that became RFCs. 2108 B.11. Changes to draft-ietf-lisp-rfc6833bis-05 2110 o Posted May 2017. 2112 o Update IANA Considerations section based on new requests from this 2113 document and changes from what was requested in [RFC6830]. 2115 B.12. Changes to draft-ietf-lisp-rfc6833bis-04 2117 o Posted May 2017. 2119 o Clarify how the Key-ID field is used in Map-Register and Map- 2120 Notify messages. Break the 16-bit field into a 8-bit Key-ID field 2121 and a 8-bit Algorithm-ID field. 2123 o Move the Control-Plane codepoints from the IANA Considerations 2124 section of RFC6830bis to the IANA Considerations section of this 2125 document. 2127 o In the "LISP Control Packet Type Allocations" section, indicate 2128 how message Types are IANA allocated and how experimental RFC8113 2129 sub-types should be requested. 2131 B.13. Changes to draft-ietf-lisp-rfc6833bis-03 2133 o Posted April 2017. 2135 o Add types 9-14 and specify they are not assigned. 2137 o Add the "LISP Shared Extension Message" type and point to RFC8113. 2139 B.14. Changes to draft-ietf-lisp-rfc6833bis-02 2141 o Posted April 2017. 2143 o Clarify that the LISP Control-Plane document defines how the LISP 2144 Data-Plane uses Map-Requests with either the SMR-bit set or the 2145 P-bit set supporting mapping updates and RLOC-probing. Indicating 2146 that other Data-Planes can use the same mechanisms or their own 2147 defined mechanisms to achieve the same functionality. 2149 B.15. Changes to draft-ietf-lisp-rfc6833bis-01 2151 o Posted March 2017. 2153 o Include references to new RFCs published. 2155 o Remove references to self. 2157 o Change references from RFC6830 to RFC6830bis. 2159 o Add two new action/reasons to a Map-Reply has posted to the LISP 2160 WG mailing list. 2162 o In intro section, add refernece to I-D.ietf-lisp-introduction. 2164 o Removed Open Issues section and references to "experimental". 2166 B.16. Changes to draft-ietf-lisp-rfc6833bis-00 2168 o Posted December 2016. 2170 o Created working group document from draft-farinacci-lisp 2171 -rfc6833-00 individual submission. No other changes made. 2173 B.17. Changes to draft-farinacci-lisp-rfc6833bis-00 2175 o Posted November 2016. 2177 o This is the initial draft to turn RFC 6833 into RFC 6833bis. 2179 o The document name has changed from the "Locator/ID Separation 2180 Protocol (LISP) Map-Server Interface" to the "Locator/ID 2181 Separation Protocol (LISP) Control-Plane". 2183 o The fundamental change was to move the Control-Plane messages from 2184 RFC 6830 to this document in an effort so any IETF developed or 2185 industry created Data-Plane could use the LISP mapping system and 2186 Control-Plane. 2188 o Update Control-Plane messages to incorporate what has been 2189 implemented in products during the early phase of LISP development 2190 but wasn't able to make it into RFC6830 and RFC6833 to make the 2191 Experimental RFC deadline. 2193 o Indicate there may be nodes in the mapping system that are not MRs 2194 or MSs, that is a ALT-node or a DDT-node. 2196 o Include LISP-DDT in Map-Resolver section and explain how they 2197 maintain a referral-cache. 2199 o Removed open issue about additional state in Map-Servers. With 2200 [RFC8111], Map-Servers have the same registration state and can 2201 give Map-Resolvers complete information in ms-ack Map-Referral 2202 messages. 2204 o Make reference to the LISP Threats Analysis RFC [RFC7835]. 2206 Authors' Addresses 2208 Vince Fuller 2209 Cisco Systems 2211 EMail: vaf@vaf.net 2213 Dino Farinacci 2214 Cisco Systems 2216 EMail: farinacci@gmail.com 2218 Albert Cabellos 2219 UPC/BarcelonaTech 2220 Campus Nord, C. Jordi Girona 1-3 2221 Barcelona, Catalunya 2222 Spain 2224 EMail: acabello@ac.upc.edu