idnits 2.17.1 draft-ietf-lisp-rfc6833bis-03.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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 9 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 304: '... Implementations MUST be prepared to a...' RFC 2119 keyword, line 313: '...ol messages. It MUST be checked on re...' RFC 2119 keyword, line 314: '... fails, the packet MUST be dropped....' RFC 2119 keyword, line 389: '...ch indicates that a Map-Request SHOULD...' RFC 2119 keyword, line 390: '...achability probe. The receiver SHOULD...' (44 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 14, 2017) is 2563 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) == Unused Reference: 'RFC4107' is defined on line 1355, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 6234 ** Downref: Normative reference to an Experimental RFC: RFC 6831 ** Downref: Normative reference to an Experimental RFC: RFC 6836 ** Downref: Normative reference to an Experimental RFC: RFC 6837 ** Downref: Normative reference to an Informational RFC: RFC 7348 ** Downref: Normative reference to an Informational RFC: RFC 7835 ** Downref: Normative reference to an Experimental RFC: RFC 8060 ** Obsolete normative reference: RFC 8113 (Obsoleted by RFC 9304) == Outdated reference: A later version (-19) exists of draft-ermagan-lisp-nat-traversal-12 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-introduction-13 == Outdated reference: A later version (-38) exists of draft-ietf-lisp-rfc6830bis-02 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-12 == Outdated reference: A later version (-09) exists of draft-ietf-lisp-signal-free-multicast-03 == Outdated reference: A later version (-04) exists of draft-lewis-lisp-gpe-02 Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Fuller 3 Internet-Draft D. Farinacci 4 Intended status: Standards Track Cisco Systems 5 Expires: October 16, 2017 A. Cabellos (Ed.) 6 UPC/BarcelonaTech 7 April 14, 2017 9 Locator/ID Separation Protocol (LISP) Control-Plane 10 draft-ietf-lisp-rfc6833bis-03 12 Abstract 14 This document describes the Control-Plane and Mapping Service for the 15 Locator/ID Separation Protocol (LISP), implemented by two new types 16 of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server 17 -- that provides a simplified "front end" for one or more Endpoint ID 18 to Routing Locator mapping databases. 20 By using this control-plane service interface and communicating with 21 Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and 22 Egress Tunnel Routers (ETRs) are not dependent on the details of 23 mapping database systems, which facilitates modularity with different 24 database designs. Since these devices implement the "edge" of the 25 LISP infrastructure, connect directly to LISP-capable Internet end 26 sites, and comprise the bulk of LISP-speaking devices, reducing their 27 implementation and operational complexity should also reduce the 28 overall cost and effort of deploying LISP. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on October 16, 2017. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 66 3. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 5 67 4. LISP IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 7 68 4.1. LISP Control Packet Type Allocations . . . . . . . . . . 9 69 4.2. Map-Request Message Format . . . . . . . . . . . . . . . 10 70 4.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 12 71 4.4. Map-Reply Message Format . . . . . . . . . . . . . . . . 14 72 4.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 18 73 4.6. Map-Register Message Format . . . . . . . . . . . . . . . 21 74 4.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 24 75 4.8. Encapsulated Control Message Format . . . . . . . . . . . 25 76 5. Interactions with Other LISP Components . . . . . . . . . . . 27 77 5.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 27 78 5.2. EID-Prefix Configuration and ETR Registration . . . . . . 28 79 5.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 30 80 5.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 30 81 5.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . 31 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 31 83 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 84 7.1. Normative References . . . . . . . . . . . . . . . . . . 32 85 7.2. Informative References . . . . . . . . . . . . . . . . . 33 86 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 36 87 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 36 88 B.1. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 36 89 B.2. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 36 90 B.3. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 36 91 B.4. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 37 92 B.5. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 37 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 95 1. Introduction 97 The Locator/ID Separation Protocol [I-D.ietf-lisp-introduction] and 98 [I-D.ietf-lisp-rfc6830bis] specifies an architecture and mechanism 99 for replacing the addresses currently used by IP with two separate 100 name spaces: Endpoint IDs (EIDs), used within sites; and Routing 101 Locators (RLOCs), used on the transit networks that make up the 102 Internet infrastructure. To achieve this separation, LISP defines 103 protocol mechanisms for mapping from EIDs to RLOCs. In addition, 104 LISP assumes the existence of a database to store and propagate those 105 mappings globally. Several such databases have been proposed; among 106 them are the Content distribution Overlay Network Service for LISP 107 (LISP-CONS) [LISP-CONS], LISP-NERD (a Not-so-novel EID-to-RLOC 108 Database) [RFC6837], LISP Alternative Logical Topology (LISP+ALT) 109 [RFC6836], and LISP Delegated Database Tree (LISP-DDT) 110 [I-D.ietf-lisp-ddt]. 112 The LISP Mapping Service defines two new types of LISP-speaking 113 devices: the Map-Resolver, which accepts Map-Requests from an Ingress 114 Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a 115 mapping database; and the Map-Server, which learns authoritative EID- 116 to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes 117 them in a database. 119 This LISP Control-Plane Mapping Service can be used by many different 120 encapsulation-based or translation-based data-planes which include 121 but are not limited to the ones defined in LISP RFC 6830bis 122 [I-D.ietf-lisp-rfc6830bis], LISP-GPE [I-D.lewis-lisp-gpe], VXLAN 123 [RFC7348], and VXLAN-GPE [I-D.quinn-vxlan-gpe]. 125 Conceptually, LISP Map-Servers share some of the same basic 126 configuration and maintenance properties as Domain Name System (DNS) 127 [RFC1035] servers; likewise, Map-Resolvers are conceptually similar 128 to DNS caching resolvers. With this in mind, this specification 129 borrows familiar terminology (resolver and server) from the DNS 130 specifications. 132 Note that while this document assumes a LISP+ALT database mapping 133 infrastructure to illustrate certain aspects of Map-Server and Map- 134 Resolver operation, the Mapping Service interface can (and likely 135 will) be used by ITRs and ETRs to access other mapping database 136 systems as the LISP infrastructure evolves. 138 The LISP Mapping Service is an important component of the LISP 139 toolset. Issues and concerns about the deployment of LISP for 140 Internet traffic are discussed in [I-D.ietf-lisp-rfc6830bis]. 142 2. Definition of Terms 144 Map-Server: A network infrastructure component that learns of EID- 145 Prefix mapping entries from an ETR, via the registration mechanism 146 described below, or some other authoritative source if one exists. 147 A Map-Server publishes these EID-Prefixes in a mapping database. 149 Map-Resolver: A network infrastructure component that accepts LISP 150 Encapsulated Map-Requests, typically from an ITR, and determines 151 whether or not the destination IP address is part of the EID 152 namespace; if it is not, a Negative Map-Reply is returned. 153 Otherwise, the Map-Resolver finds the appropriate EID-to-RLOC 154 mapping by consulting a mapping database system. 156 Encapsulated Map-Request: A LISP Map-Request carried within an 157 Encapsulated Control Message, which has an additional LISP header 158 prepended. Sent to UDP destination port 4342. The "outer" 159 addresses are globally routable IP addresses, also known as RLOCs. 160 Used by an ITR when sending to a Map-Resolver and by a Map-Server 161 when forwarding a Map-Request to an ETR. 163 Negative Map-Reply: A LISP Map-Reply that contains an empty 164 Locator-Set. Returned in response to a Map-Request if the 165 destination EID does not exist in the mapping database. 166 Typically, this means that the "EID" being requested is an IP 167 address connected to a non-LISP site. 169 Map-Register message: A LISP message sent by an ETR to a Map-Server 170 to register its associated EID-Prefixes. In addition to the set 171 of EID-Prefixes to register, the message includes one or more 172 RLOCs to be used by the Map-Server when forwarding Map-Requests 173 (re-formatted as Encapsulated Map-Requests) received through the 174 database mapping system. An ETR may request that the Map-Server 175 answer Map-Requests on its behalf by setting the "proxy Map-Reply" 176 flag (P-bit) in the message. 178 Map-Notify message: A LISP message sent by a Map-Server to an ETR 179 to confirm that a Map-Register has been received and processed. 180 An ETR requests that a Map-Notify be returned by setting the 181 "want-map-notify" flag (M-bit) in the Map-Register message. 182 Unlike a Map-Reply, a Map-Notify uses UDP port 4342 for both 183 source and destination. 185 For definitions of other terms -- notably Map-Request, Map-Reply, 186 Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR) -- please 187 consult the LISP specification [I-D.ietf-lisp-rfc6830bis]. 189 3. Basic Overview 191 A Map-Server is a device that publishes EID-Prefixes in a LISP 192 mapping database on behalf of a set of ETRs. When it receives a Map 193 Request (typically from an ITR), it consults the mapping database to 194 find an ETR that can answer with the set of RLOCs for an EID-Prefix. 195 To publish its EID-Prefixes, an ETR periodically sends Map-Register 196 messages to the Map-Server. A Map-Register message contains a list 197 of EID-Prefixes plus a set of RLOCs that can be used to reach the ETR 198 when a Map-Server needs to forward a Map-Request to it. 200 When LISP+ALT is used as the mapping database, a Map-Server connects 201 to the ALT network and acts as a "last-hop" ALT-Router. Intermediate 202 ALT-Routers forward Map-Requests to the Map-Server that advertises a 203 particular EID-Prefix, and the Map-Server forwards them to the owning 204 ETR, which responds with Map-Reply messages. 206 When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping database, a 207 Map-Server sends the final Map-Referral messages from the Delegated 208 Database Tree. 210 A Map-Resolver receives Encapsulated Map-Requests from its client 211 ITRs and uses a mapping database system to find the appropriate ETR 212 to answer those requests. On a LISP+ALT network, a Map-Resolver acts 213 as a "first-hop" ALT-Router. It has Generic Routing Encapsulation 214 (GRE) tunnels configured to other ALT-Routers and uses BGP to learn 215 paths to ETRs for different prefixes in the LISP+ALT database. The 216 Map-Resolver uses this path information to forward Map-Requests over 217 the ALT to the correct ETRs. On a LISP-DDT network 218 [I-D.ietf-lisp-ddt], a Map-Resolver maintains a referral-cache and 219 acts as a "first-hop" DDT-node. The Map-Resolver uses the referral 220 information to forward Map-Requests. 222 Note that while it is conceivable that a non-LISP-DDT Map-Resolver 223 could cache responses to improve performance, issues surrounding 224 cache management will need to be resolved so that doing so will be 225 reliable and practical. As initially deployed, Map-Resolvers will 226 operate only in a non-caching mode, decapsulating and forwarding 227 Encapsulated Map Requests received from ITRs. Any specification of 228 caching functionality is left for future work. 230 Note that a single device can implement the functions of both a Map- 231 Server and a Map-Resolver, and in many cases the functions will be 232 co-located in that way. Also, there can be ALT-only nodes and DDT- 233 only nodes, when LISP+ALT and LISP-DDT are used, respectively, to 234 connect Map-Resolvers and Map-Servers together to make up the Mapping 235 System. 237 Detailed descriptions of the LISP packet types referenced by this 238 document may be found in [I-D.ietf-lisp-rfc6830bis]. 240 4. LISP IPv4 and IPv6 Control-Plane Packet Formats 242 The following UDP packet formats are used by the LISP control plane. 244 0 1 2 3 245 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 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 |Version| IHL |Type of Service| Total Length | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Identification |Flags| Fragment Offset | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Time to Live | Protocol = 17 | Header Checksum | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Source Routing Locator | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Destination Routing Locator | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 / | Source Port | Dest Port | 258 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 \ | UDP Length | UDP Checksum | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | | 262 | LISP Message | 263 | | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 0 1 2 3 267 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 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 |Version| Traffic Class | Flow Label | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Payload Length | Next Header=17| Hop Limit | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | | 274 + + 275 | | 276 + Source Routing Locator + 277 | | 278 + + 279 | | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | | 282 + + 283 | | 284 + Destination Routing Locator + 285 | | 286 + + 287 | | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 / | Source Port | Dest Port | 290 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 \ | UDP Length | UDP Checksum | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | | 294 | LISP Message | 295 | | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 The LISP UDP-based messages are the Map-Request and Map-Reply 299 messages. When a UDP Map-Request is sent, the UDP source port is 300 chosen by the sender and the destination UDP port number is set to 301 4342. When a UDP Map-Reply is sent, the source UDP port number is 302 set to 4342 and the destination UDP port number is copied from the 303 source port of either the Map-Request or the invoking data packet. 304 Implementations MUST be prepared to accept packets when either the 305 source port or destination UDP port is set to 4342 due to NATs 306 changing port number values. 308 The 'UDP Length' field will reflect the length of the UDP header and 309 the LISP Message payload. 311 The UDP checksum is computed and set to non-zero for Map-Request, 312 Map-Reply, Map-Register, and Encapsulated Control Message (ECM) 313 control messages. It MUST be checked on receipt, and if the checksum 314 fails, the packet MUST be dropped. 316 The format of control messages includes the UDP header so the 317 checksum and length fields can be used to protect and delimit message 318 boundaries. 320 4.1. LISP Control Packet Type Allocations 322 This section will be the authoritative source for allocating LISP 323 Type values and for defining LISP control message formats. For 324 Shared Extension types, see [RFC8113]. Current allocations are: 326 Reserved: 0 b'0000' 327 LISP Map-Request: 1 b'0001' 328 LISP Map-Reply: 2 b'0010' 329 LISP Map-Register: 3 b'0011' 330 LISP Map-Notify: 4 b'0100' 331 LISP Map-Notify-Ack: 5 b'0101' 332 LISP Map-Referral: 6 b'0110' 333 LISP Info-Request/Reply: 7 b'0111' 334 LISP Encapsulated Control Message: 8 b'1000' 335 Not Assigned 9-14 b'1001'- b'1110' 336 LISP Shared Extension Message: 15 b'1111' [RFC8113] 338 All LISP control-plane messages use Address Family Identifiers (AFI) 339 [AFI] or LISP Canonical Address Format (LCAF) [RFC8060] formats to 340 encode either fixed or variable length addresses. This includes 341 explicit fields in each control message or part of EID-records or 342 RLOC-records in commonly formatted messages. 344 The LISP control-plane describes how other data-planes can encode 345 messages to support the SMR and RLOC-probing procedures of the LISP 346 data-plane defined in [I-D.ietf-lisp-rfc6830bis]. This control-plane 347 specification itself does not offer such functionality and other 348 data-planes can use their own mechanisms that do not rely on the LISP 349 control-plane. 351 4.2. Map-Request Message Format 353 0 1 2 3 354 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 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 |Type=1 |A|M|P|S|p|s|m| Reserved |L|D| IRC | Record Count | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Nonce . . . | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | . . . Nonce | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Source-EID-AFI | Source EID Address ... | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | ... | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | ITR-RLOC-AFI n | ITR-RLOC Address n ... | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 / | Reserved | EID mask-len | EID-Prefix-AFI | 371 Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 \ | EID-Prefix ... | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Map-Reply Record ... | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 Packet field descriptions: 379 Type: 1 (Map-Request) 381 A: This is an authoritative bit, which is set to 0 for UDP-based Map- 382 Requests sent by an ITR. It is set to 1 when an ITR wants the 383 destination site to return the Map-Reply rather than the mapping 384 database system. 386 M: This is the map-data-present bit. When set, it indicates that a 387 Map-Reply Record segment is included in the Map-Request. 389 P: This is the probe-bit, which indicates that a Map-Request SHOULD 390 be treated as a Locator reachability probe. The receiver SHOULD 391 respond with a Map-Reply with the probe-bit set, indicating that 392 the Map-Reply is a Locator reachability probe reply, with the 393 nonce copied from the Map-Request. See RLOC-Probing 394 [I-D.ietf-lisp-rfc6830bis] for more details. 396 S: This is the Solicit-Map-Request (SMR) bit. See Solicit-Map- 397 Request (SMRs) [I-D.ietf-lisp-rfc6830bis] for details. 399 p: This is the PITR bit. This bit is set to 1 when a PITR sends a 400 Map-Request. 402 s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is 403 sending a Map-Request in response to a received SMR-based Map- 404 Request. 406 m: This is the LISP mobile-node m-bit. This bit is set by xTRs that 407 operate as a mobile node as defined in [I-D.meyer-lisp-mn]. 409 Reserved: This field MUST be set to 0 on transmit and MUST be 410 ignored on receipt. 412 L: This is the local-xtr bit. It is used by an xTR in a LISP site to 413 tell other xTRs in the same site that it is local to the site. 414 That is, that it is part of the RLOC-set for the LISP site. 416 D: This is the dont-map-reply bit. It is used in the SMR procedure 417 described in [I-D.ietf-lisp-rfc6830bis]. When an xTR sends an SMR 418 Map-Request message, it doesn't need a Map-Reply returned. When 419 this bit is set, the receiver of the Map-Request does not return a 420 Map-Reply. 422 IRC: This 5-bit field is the ITR-RLOC Count, which encodes the 423 additional number of ('ITR-RLOC-AFI', 'ITR-RLOC Address') fields 424 present in this message. At least one (ITR-RLOC-AFI, ITR-RLOC- 425 Address) pair MUST be encoded. Multiple 'ITR-RLOC Address' fields 426 are used, so a Map-Replier can select which destination address to 427 use for a Map-Reply. The IRC value ranges from 0 to 31. For a 428 value of 0, there is 1 ITR-RLOC address encoded; for a value of 1, 429 there are 2 ITR-RLOC addresses encoded, and so on up to 31, which 430 encodes a total of 32 ITR-RLOC addresses. 432 Record Count: This is the number of records in this Map-Request 433 message. A record is comprised of the portion of the packet that 434 is labeled 'Rec' above and occurs the number of times equal to 435 Record Count. For this version of the protocol, a receiver MUST 436 accept and process Map-Requests that contain one or more records, 437 but a sender MUST only send Map-Requests containing one record. 438 Support for requesting multiple EIDs in a single Map-Request 439 message will be specified in a future version of the protocol. 441 Nonce: This is an 8-octet random value created by the sender of the 442 Map-Request. This nonce will be returned in the Map-Reply. The 443 security of the LISP mapping protocol critically depends on the 444 strength of the nonce in the Map-Request message. The nonce 445 SHOULD be generated by a properly seeded pseudo-random (or strong 446 random) source. See [RFC4086] for advice on generating security- 447 sensitive random data. 449 Source-EID-AFI: This is the address family of the 'Source EID 450 Address' field. 452 Source EID Address: This is the EID of the source host that 453 originated the packet that caused the Map-Request. When Map- 454 Requests are used for refreshing a Map-Cache entry or for RLOC- 455 Probing, an AFI value 0 is used and this field is of zero length. 457 ITR-RLOC-AFI: This is the address family of the 'ITR-RLOC Address' 458 field that follows this field. 460 ITR-RLOC Address: This is used to give the ETR the option of 461 selecting the destination address from any address family for the 462 Map-Reply message. This address MUST be a routable RLOC address 463 of the sender of the Map-Request message. 465 EID mask-len: This is the mask length for the EID-Prefix. 467 EID-Prefix-AFI: This is the address family of the EID-Prefix 468 according to [AFI] and [RFC8060]. 470 EID-Prefix: This prefix is 4 octets for an IPv4 address family and 471 16 octets for an IPv6 address family. When a Map-Request is sent 472 by an ITR because a data packet is received for a destination 473 where there is no mapping entry, the EID-Prefix is set to the 474 destination IP address of the data packet, and the 'EID mask-len' 475 is set to 32 or 128 for IPv4 or IPv6, respectively. When an xTR 476 wants to query a site about the status of a mapping it already has 477 cached, the EID-Prefix used in the Map-Request has the same mask 478 length as the EID-Prefix returned from the site when it sent a 479 Map-Reply message. 481 Map-Reply Record: When the M-bit is set, this field is the size of a 482 single "Record" in the Map-Reply format. This Map-Reply record 483 contains the EID-to-RLOC mapping entry associated with the Source 484 EID. This allows the ETR that will receive this Map-Request to 485 cache the data if it chooses to do so. 487 4.3. EID-to-RLOC UDP Map-Request Message 489 A Map-Request is sent from an ITR when it needs a mapping for an EID, 490 wants to test an RLOC for reachability, or wants to refresh a mapping 491 before TTL expiration. For the initial case, the destination IP 492 address used for the Map-Request is the data packet's destination 493 address (i.e., the destination EID) that had a mapping cache lookup 494 failure. For the latter two cases, the destination IP address used 495 for the Map-Request is one of the RLOC addresses from the Locator-Set 496 of the Map-Cache entry. The source address is either an IPv4 or IPv6 497 RLOC address, depending on whether the Map-Request is using an IPv4 498 or IPv6 header, respectively. In all cases, the UDP source port 499 number for the Map-Request message is a 16-bit value selected by the 500 ITR/PITR, and the UDP destination port number is set to the well- 501 known destination port number 4342. A successful Map-Reply, which is 502 one that has a nonce that matches an outstanding Map-Request nonce, 503 will update the cached set of RLOCs associated with the EID-Prefix 504 range. 506 One or more Map-Request ('ITR-RLOC-AFI', 'ITR-RLOC-Address') fields 507 MUST be filled in by the ITR. The number of fields (minus 1) encoded 508 MUST be placed in the 'IRC' field. The ITR MAY include all locally 509 configured Locators in this list or just provide one locator address 510 from each address family it supports. If the ITR erroneously 511 provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map- 512 Request. 514 Map-Requests can also be LISP encapsulated using UDP destination 515 port 4342 with a LISP Type value set to "Encapsulated Control 516 Message", when sent from an ITR to a Map-Resolver. Likewise, Map- 517 Requests are LISP encapsulated the same way from a Map-Server to an 518 ETR. Details on Encapsulated Map-Requests and Map-Resolvers can be 519 found in Section 4.8. 521 Map-Requests MUST be rate-limited. It is RECOMMENDED that a Map- 522 Request for the same EID-Prefix be sent no more than once per second. 524 An ITR that is configured with mapping database information (i.e., it 525 is also an ETR) MAY optionally include those mappings in a Map- 526 Request. When an ETR configured to accept and verify such 527 "piggybacked" mapping data receives such a Map-Request and it does 528 not have this mapping in the map-cache, it MAY originate a "verifying 529 Map-Request", addressed to the map-requesting ITR and the ETR MAY add 530 a Map-Cache entry. If the ETR has a Map-Cache entry that matches the 531 "piggybacked" EID and the RLOC is in the Locator-Set for the entry, 532 then it may send the "verifying Map-Request" directly to the 533 originating Map-Request source. If the RLOC is not in the Locator- 534 Set, then the ETR MUST send the "verifying Map-Request" to the 535 "piggybacked" EID. Doing this forces the "verifying Map-Request" to 536 go through the mapping database system to reach the authoritative 537 source of information about that EID, guarding against RLOC-spoofing 538 in the "piggybacked" mapping data. 540 4.4. Map-Reply Message Format 542 0 1 2 3 543 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 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 |Type=2 |P|E|S| Reserved | Record Count | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | Nonce . . . | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | . . . Nonce | 550 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | | Record TTL | 552 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 R | Locator Count | EID mask-len | ACT |A| Reserved | 554 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 c | Rsvd | Map-Version Number | EID-Prefix-AFI | 556 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 r | EID-Prefix | 558 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | /| Priority | Weight | M Priority | M Weight | 560 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | o | Unused Flags |L|p|R| Loc-AFI | 562 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | \| Locator | 564 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 Packet field descriptions: 568 Type: 2 (Map-Reply) 570 P: This is the probe-bit, which indicates that the Map-Reply is in 571 response to a Locator reachability probe Map-Request. The 'Nonce' 572 field MUST contain a copy of the nonce value from the original 573 Map-Request. See RLOC-probing [I-D.ietf-lisp-rfc6830bis] for more 574 details. 576 E: This bit indicates that the ETR that sends this Map-Reply message 577 is advertising that the site is enabled for the Echo-Nonce Locator 578 reachability algorithm. See Echo-Nonce [I-D.ietf-lisp-rfc6830bis] 579 for more details. 581 S: This is the Security bit. When set to 1, the following 582 authentication information will be appended to the end of the Map- 583 Reply. The details of signing a Map-Reply message can be found in 584 [I-D.ietf-lisp-sec]. 586 0 1 2 3 587 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 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | AD Type | Authentication Data Content . . . | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 Reserved: This field MUST be set to 0 on transmit and MUST be 593 ignored on receipt. 595 Record Count: This is the number of records in this reply message. 596 A record is comprised of that portion of the packet labeled 597 'Record' above and occurs the number of times equal to Record 598 Count. 600 Nonce: This is a 24-bit value set in a Data-Probe packet, or a 601 64-bit value from the Map-Request is echoed in this 'Nonce' field 602 of the Map-Reply. When a 24-bit value is supplied, it resides in 603 the low-order 64 bits of the 'Nonce' field. 605 Record TTL: This is the time in minutes the recipient of the Map- 606 Reply will store the mapping. If the TTL is 0, the entry SHOULD 607 be removed from the cache immediately. If the value is 608 0xffffffff, the recipient can decide locally how long to store the 609 mapping. 611 Locator Count: This is the number of Locator entries. A Locator 612 entry comprises what is labeled above as 'Loc'. The Locator count 613 can be 0, indicating that there are no Locators for the EID- 614 Prefix. 616 EID mask-len: This is the mask length for the EID-Prefix. 618 ACT: This 3-bit field describes Negative Map-Reply actions. In any 619 other message type, these bits are set to 0 and ignored on 620 receipt. These bits are used only when the 'Locator Count' field 621 is set to 0. The action bits are encoded only in Map-Reply 622 messages. The actions defined are used by an ITR or PITR when a 623 destination EID matches a negative Map-Cache entry. Unassigned 624 values should cause a Map-Cache entry to be created, and when 625 packets match this negative cache entry, they will be dropped. 626 The current assigned values are: 628 (0) No-Action: The map-cache is kept alive, and no packet 629 encapsulation occurs. 631 (1) Natively-Forward: The packet is not encapsulated or dropped 632 but natively forwarded. 634 (2) Send-Map-Request: The packet invokes sending a Map-Request. 636 (3) Drop/No-Reason: A packet that matches this map-cache entry is 637 dropped. An ICMP Destination Unreachable message SHOULD be 638 sent. 640 (4) Drop/Policy-Denied: A packet that matches this map-cache 641 entry is dropped. The reason for the Drop action is that a 642 Map-Request for the target-EID is being policy denied by 643 either an xTR or the mapping system. 645 (5) Drop/Authentication-Failure: A packet that matches this map- 646 cache entry is dropped. The reason for the Drop action is 647 that a Map-Request for the target-EID fails an authentication 648 verification-check by either an xTR or the mapping system. 650 A: The Authoritative bit, when sent, is always set to 1 by an ETR. 651 When a Map-Server is proxy Map-Replying for a LISP site, the 652 Authoritative bit is set to 0. This indicates to requesting ITRs 653 that the Map-Reply was not originated by a LISP node managed at 654 the site that owns the EID-Prefix. 656 Map-Version Number: When this 12-bit value is non-zero, the Map- 657 Reply sender is informing the ITR what the version number is for 658 the EID record contained in the Map-Reply. The ETR can allocate 659 this number internally but MUST coordinate this value with other 660 ETRs for the site. When this value is 0, there is no versioning 661 information conveyed. The Map-Version Number can be included in 662 Map-Request and Map-Register messages. See Map-Versioning 663 [I-D.ietf-lisp-rfc6830bis] for more details. 665 EID-Prefix-AFI: Address family of the EID-Prefix according to [AFI] 666 and [RFC8060]. 668 EID-Prefix: This prefix is 4 octets for an IPv4 address family and 669 16 octets for an IPv6 address family. 671 Priority: Each RLOC is assigned a unicast Priority. Lower values 672 are more preferable. When multiple RLOCs have the same Priority, 673 they MAY be used in a load-split fashion. A value of 255 means 674 the RLOC MUST NOT be used for unicast forwarding. 676 Weight: When priorities are the same for multiple RLOCs, the Weight 677 indicates how to balance unicast traffic between them. Weight is 678 encoded as a relative weight of total unicast packets that match 679 the mapping entry. For example, if there are 4 Locators in a 680 Locator-Set, where the Weights assigned are 30, 20, 20, and 10, 681 the first Locator will get 37.5% of the traffic, the 2nd and 3rd 682 Locators will get 25% of the traffic, and the 4th Locator will get 683 12.5% of the traffic. If all Weights for a Locator-Set are equal, 684 the receiver of the Map-Reply will decide how to load-split the 685 traffic. See RLOC-hashing [I-D.ietf-lisp-rfc6830bis] for a 686 suggested hash algorithm to distribute the load across Locators 687 with the same Priority and equal Weight values. 689 M Priority: Each RLOC is assigned a multicast Priority used by an 690 ETR in a receiver multicast site to select an ITR in a source 691 multicast site for building multicast distribution trees. A value 692 of 255 means the RLOC MUST NOT be used for joining a multicast 693 distribution tree. For more details, see [RFC6831]. 695 M Weight: When priorities are the same for multiple RLOCs, the 696 Weight indicates how to balance building multicast distribution 697 trees across multiple ITRs. The Weight is encoded as a relative 698 weight (similar to the unicast Weights) of the total number of 699 trees built to the source site identified by the EID-Prefix. If 700 all Weights for a Locator-Set are equal, the receiver of the Map- 701 Reply will decide how to distribute multicast state across ITRs. 702 For more details, see [RFC6831]. 704 Unused Flags: These are set to 0 when sending and ignored on 705 receipt. 707 L: When this bit is set, the Locator is flagged as a local Locator to 708 the ETR that is sending the Map-Reply. When a Map-Server is doing 709 proxy Map-Replying for a LISP site, the L-bit is set to 0 for all 710 Locators in this Locator-Set. 712 p: When this bit is set, an ETR informs the RLOC-Probing ITR that the 713 locator address for which this bit is set is the one being RLOC- 714 probed and MAY be different from the source address of the Map- 715 Reply. An ITR that RLOC-probes a particular Locator MUST use this 716 Locator for retrieving the data structure used to store the fact 717 that the Locator is reachable. The p-bit is set for a single 718 Locator in the same Locator-Set. If an implementation sets more 719 than one p-bit erroneously, the receiver of the Map-Reply MUST 720 select the first Locator. The p-bit MUST NOT be set for Locator- 721 Set records sent in Map-Request and Map-Register messages. 723 R: This is set when the sender of a Map-Reply has a route to the 724 Locator in the Locator data record. This receiver may find this 725 useful to know if the Locator is up but not necessarily reachable 726 from the receiver's point of view. See also EID-Reachability 727 [I-D.ietf-lisp-rfc6830bis] for another way the R-bit may be used. 729 Locator: This is an IPv4 or IPv6 address (as encoded by the 'Loc- 730 AFI' field) assigned to an ETR. Note that the destination RLOC 731 address MAY be an anycast address. A source RLOC can be an 732 anycast address as well. The source or destination RLOC MUST NOT 733 be the broadcast address (255.255.255.255 or any subnet broadcast 734 address known to the router) and MUST NOT be a link-local 735 multicast address. The source RLOC MUST NOT be a multicast 736 address. The destination RLOC SHOULD be a multicast address if it 737 is being mapped from a multicast destination EID. 739 4.5. EID-to-RLOC UDP Map-Reply Message 741 A Map-Reply returns an EID-Prefix with a prefix length that is less 742 than or equal to the EID being requested. The EID being requested is 743 either from the destination field of an IP header of a Data-Probe or 744 the EID record of a Map-Request. The RLOCs in the Map-Reply are 745 globally routable IP addresses of all ETRs for the LISP site. Each 746 RLOC conveys status reachability but does not convey path 747 reachability from a requester's perspective. Separate testing of 748 path reachability is required. See RLOC-reachability 749 [I-D.ietf-lisp-rfc6830bis] for details. 751 Note that a Map-Reply may contain different EID-Prefix granularity 752 (prefix + length) than the Map-Request that triggers it. This might 753 occur if a Map-Request were for a prefix that had been returned by an 754 earlier Map-Reply. In such a case, the requester updates its cache 755 with the new prefix information and granularity. For example, a 756 requester with two cached EID-Prefixes that are covered by a Map- 757 Reply containing one less-specific prefix replaces the entry with the 758 less-specific EID-Prefix. Note that the reverse, replacement of one 759 less-specific prefix with multiple more-specific prefixes, can also 760 occur, not by removing the less-specific prefix but rather by adding 761 the more-specific prefixes that, during a lookup, will override the 762 less-specific prefix. 764 When an ETR is configured with overlapping EID-Prefixes, a Map- 765 Request with an EID that best matches any EID-Prefix MUST be returned 766 in a single Map-Reply message. For instance, if an ETR had database 767 mapping entries for EID-Prefixes: 769 10.0.0.0/8 770 10.1.0.0/16 771 10.1.1.0/24 772 10.1.2.0/24 774 A Map-Request for EID 10.1.1.1 would cause a Map-Reply with a record 775 count of 1 to be returned with a mapping record EID-Prefix of 776 10.1.1.0/24. 778 A Map-Request for EID 10.1.5.5 would cause a Map-Reply with a record 779 count of 3 to be returned with mapping records for EID-Prefixes 780 10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24. 782 Note that not all overlapping EID-Prefixes need to be returned but 783 only the more-specific entries (note that in the second example above 784 10.0.0.0/8 was not returned for requesting EID 10.1.5.5) for the 785 matching EID-Prefix of the requesting EID. When more than one EID- 786 Prefix is returned, all SHOULD use the same Time to Live value so 787 they can all time out at the same time. When a more-specific EID- 788 Prefix is received later, its Time to Live value in the Map-Reply 789 record can be stored even when other less-specific entries exist. 790 When a less-specific EID-Prefix is received later, its map-cache 791 expiration time SHOULD be set to the minimum expiration time of any 792 more-specific EID-Prefix in the map-cache. This is done so the 793 integrity of the EID-Prefix set is wholly maintained and so no more- 794 specific entries are removed from the map-cache while keeping less- 795 specific entries. 797 Map-Replies SHOULD be sent for an EID-Prefix no more often than once 798 per second to the same requesting router. For scalability, it is 799 expected that aggregation of EID addresses into EID-Prefixes will 800 allow one Map-Reply to satisfy a mapping for the EID addresses in the 801 prefix range, thereby reducing the number of Map-Request messages. 803 Map-Reply records can have an empty Locator-Set. A Negative Map- 804 Reply is a Map-Reply with an empty Locator-Set. Negative Map-Replies 805 convey special actions by the sender to the ITR or PITR that have 806 solicited the Map-Reply. There are two primary applications for 807 Negative Map-Replies. The first is for a Map-Resolver to instruct an 808 ITR or PITR when a destination is for a LISP site versus a non-LISP 809 site, and the other is to source quench Map-Requests that are sent 810 for non-allocated EIDs. 812 For each Map-Reply record, the list of Locators in a Locator-Set MUST 813 appear in the same order for each ETR that originates a Map-Reply 814 message. The Locator-Set MUST be sorted in order of ascending IP 815 address where an IPv4 locator address is considered numerically 'less 816 than' an IPv6 locator address. 818 When sending a Map-Reply message, the destination address is copied 819 from one of the 'ITR-RLOC' fields from the Map-Request. The ETR can 820 choose a locator address from one of the address families it 821 supports. For Data-Probes, the destination address of the Map-Reply 822 is copied from the source address of the Data-Probe message that is 823 invoking the reply. The source address of the Map-Reply is one of 824 the local IP addresses chosen to allow Unicast Reverse Path 825 Forwarding (uRPF) checks to succeed in the upstream service provider. 827 The destination port of a Map-Reply message is copied from the source 828 port of the Map-Request or Data-Probe, and the source port of the 829 Map-Reply message is set to the well-known UDP port 4342. 831 4.6. Map-Register Message Format 833 This section specifies the encoding format for the Map-Register 834 message. The message is sent in UDP with a destination UDP port of 835 4342 and a randomly selected UDP source port number. 837 The Map-Register message format is: 839 0 1 2 3 840 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 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 |Type=3 |P|S|I| Reserved |E|T|a|m|M| Record Count | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | Nonce . . . | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | . . . Nonce | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | Key ID | Authentication Data Length | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 ~ Authentication Data ~ 851 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | | Record TTL | 853 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 R | Locator Count | EID mask-len | ACT |A| Reserved | 855 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 c | Rsvd | Map-Version Number | EID-Prefix-AFI | 857 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 r | EID-Prefix | 859 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 | /| Priority | Weight | M Priority | M Weight | 861 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | o | Unused Flags |L|p|R| Loc-AFI | 863 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | \| Locator | 865 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 Packet field descriptions: 869 Type: 3 (Map-Register) 871 P: This is the proxy Map-Reply bit. When set to 1, an ETR sends a 872 Map-Register message requesting the Map-Server to proxy a Map- 873 Reply. The Map-Server will send non-authoritative Map-Replies on 874 behalf of the ETR. 876 S: This is the security-capable bit. When set, the procedures from 877 [I-D.ietf-lisp-sec] are supported. 879 I: This is the xTR-ID bit. When this bit is set, what is appended to 880 the Map-Register is a 128-bit xTR router-ID and then a 64-bit 881 site-ID. See LISP NAT-Traversal procedures in 882 [I-D.ermagan-lisp-nat-traversal] for details. 884 Reserved: This field MUST be set to 0 on transmit and MUST be 885 ignored on receipt. 887 E: This is the Map-Register EID-notify bit. This is used by a First- 888 Hop-Router (FHR) which discovers a dynamic-EID. This EID-notify 889 based Map-Register is sent by the FHR to the same site xTR that 890 propogates the Map-Register to the mapping system. The site xTR 891 keeps state to later Map-Notify the FHR after the EID has moves 892 away. See [I-D.portoles-lisp-eid-mobility] for a detailed use- 893 case. 895 T: This is the use-TTL for timeout bit. When set to 1, the xTR wants 896 the Map-Server to time out registrations based on the value in the 897 "Record TTL" field of this message. 899 a: This is the merge-request bit. When set to 1, the xTR requests to 900 merge RLOC-records from different xTRs registering the same EID- 901 record. See signal-free multicast 902 [I-D.ietf-lisp-signal-free-multicast] for one use case example. 904 m: This is the mobile-node bit. When set to 1, the registering xTR 905 supports the procuedures in [I-D.meyer-lisp-mn]. 907 M: This is the want-map-notify bit. When set to 1, an ETR is 908 requesting a Map-Notify message to be returned in response to 909 sending a Map-Register message. The Map-Notify message sent by a 910 Map-Server is used to acknowledge receipt of a Map-Register 911 message. 913 Record Count: This is the number of records in this Map-Register 914 message. A record is comprised of that portion of the packet 915 labeled 'Record' above and occurs the number of times equal to 916 Record Count. 918 Nonce: This 8-octet 'Nonce' field is set to 0 in Map-Register 919 messages. Since the Map-Register message is authenticated, the 920 'Nonce' field is not currently used for any security function but 921 may be in the future as part of an anti-replay solution. 923 Key ID: This is a configured ID to find the configured Message 924 Authentication Code (MAC) algorithm and key value used for the 925 authentication function. See Key ID Numbers in 926 [I-D.ietf-lisp-rfc6830bis] for codepoint assignments. 928 Authentication Data Length: This is the length in octets of the 929 'Authentication Data' field that follows this field. The length 930 of the 'Authentication Data' field is dependent on the MAC 931 algorithm used. The length field allows a device that doesn't 932 know the MAC algorithm to correctly parse the packet. 934 Authentication Data: This is the message digest used from the output 935 of the MAC algorithm. The entire Map-Register payload is 936 authenticated with this field preset to 0. After the MAC is 937 computed, it is placed in this field. Implementations of this 938 specification MUST include support for HMAC-SHA-1-96 [RFC2404], 939 and support for HMAC-SHA-256-128 [RFC4868] is RECOMMENDED. 941 The definition of the rest of the Map-Register can be found in 942 Section 4.4. 944 4.7. Map-Notify/Map-Notify-Ack Message Format 946 This section specifies the encoding format for the Map-Notify and 947 Map-Notify-Ack messages. The messages are sent inside a UDP packet 948 with source and destination UDP ports equal to 4342. 950 The Map-Notify and Map-Notify-Ack message formats are: 952 0 1 2 3 953 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 |Type=4/5| Reserved | Record Count | 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 | Nonce . . . | 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | . . . Nonce | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | Key ID | Authentication Data Length | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 ~ Authentication Data ~ 964 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | | Record TTL | 966 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 R | Locator Count | EID mask-len | ACT |A| Reserved | 968 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 c | Rsvd | Map-Version Number | EID-Prefix-AFI | 970 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 r | EID-Prefix | 972 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | /| Priority | Weight | M Priority | M Weight | 974 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 | o | Unused Flags |L|p|R| Loc-AFI | 976 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | \| Locator | 978 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 Packet field descriptions: 982 Type: 4/5 (Map-Notify/Map-Notify-Ack) 984 The Map-Notify message has the same contents as a Map-Register 985 message. See the Map-Register section for field descriptions. 987 The Map-Notify-Ack message has the same contents as a Map-Notify 988 message. It is used to acknowledge the receipt of a Map-Notify and 989 for the sender to stop retransmitting a Map-Notify with the same 990 nonce. 992 4.8. Encapsulated Control Message Format 994 An Encapsulated Control Message (ECM) is used to encapsulate control 995 packets sent between xTRs and the mapping database system. 997 0 1 2 3 998 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 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 / | IPv4 or IPv6 Header | 1001 OH | (uses RLOC addresses) | 1002 \ | | 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1004 / | Source Port = xxxx | Dest Port = 4342 | 1005 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 \ | UDP Length | UDP Checksum | 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 LH |Type=8 |S|D|E|M| Reserved | 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 / | IPv4 or IPv6 Header | 1011 IH | (uses RLOC or EID addresses) | 1012 \ | | 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 / | Source Port = xxxx | Dest Port = yyyy | 1015 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 \ | UDP Length | UDP Checksum | 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 LCM | LISP Control Message | 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 Packet header descriptions: 1023 OH: The outer IPv4 or IPv6 header, which uses RLOC addresses in the 1024 source and destination header address fields. 1026 UDP: The outer UDP header with destination port 4342. The source 1027 port is randomly allocated. The checksum field MUST be non- 1028 zero. 1030 LH: Type 8 is defined to be a "LISP Encapsulated Control Message", 1031 and what follows is either an IPv4 or IPv6 header as encoded by 1032 the first 4 bits after the 'Reserved' field. 1034 Type: 8 (Encapsulated Control Message (ECM)) 1036 S: This is the Security bit. When set to 1, the procedures from 1037 [I-D.ietf-lisp-sec] are followed. 1039 D: This is the DDT-bit. When set to 1, the sender is requesting a 1040 Map-Referral message to be returned. The details of this 1041 procedure are described in [I-D.ietf-lisp-ddt]. 1043 E: This is the to-ETR bit. When set to 1, the Map-Server's 1044 intention is to forward the ECM to an authoritative ETR. 1046 M: This is the to-MS bit. When set to 1, a Map-Request is being 1047 sent to a co-located Map-Resolver and Map-Server where the 1048 message can be processed directly by the Map-Server versus the 1049 Map-Resolver using the LISP-DDT procedures in 1050 [I-D.ietf-lisp-ddt]. 1052 0 1 2 3 1053 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 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | AD Type | Authentication Data Content . . . | 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 IH: The inner IPv4 or IPv6 header, which can use either RLOC or EID 1059 addresses in the header address fields. When a Map-Request is 1060 encapsulated in this packet format, the destination address in 1061 this header is an EID. 1063 UDP: The inner UDP header, where the port assignments depend on the 1064 control packet being encapsulated. When the control packet is 1065 a Map-Request or Map-Register, the source port is selected by 1066 the ITR/PITR and the destination port is 4342. When the 1067 control packet is a Map-Reply, the source port is 4342 and the 1068 destination port is assigned from the source port of the 1069 invoking Map-Request. Port number 4341 MUST NOT be assigned to 1070 either port. The checksum field MUST be non-zero. 1072 LCM: The format is one of the control message formats described in 1073 this section. At this time, only Map-Request messages are 1074 allowed to be encapsulated. In the future, PIM Join/Prune 1075 messages [RFC6831] might be allowed. Encapsulating other types 1076 of LISP control messages is for further study. When Map- 1077 Requests are sent for RLOC-Probing purposes (i.e., the probe- 1078 bit is set), they MUST NOT be sent inside Encapsulated Control 1079 Messages. 1081 5. Interactions with Other LISP Components 1083 5.1. ITR EID-to-RLOC Mapping Resolution 1085 An ITR is configured with one or more Map-Resolver addresses. These 1086 addresses are "Locators" (or RLOCs) and must be routable on the 1087 underlying core network; they must not need to be resolved through 1088 LISP EID-to-RLOC mapping, as that would introduce a circular 1089 dependency. When using a Map-Resolver, an ITR does not need to 1090 connect to any other database mapping system. In particular, the ITR 1091 need not connect to the LISP+ALT infrastructure or implement the BGP 1092 and GRE protocols that it uses. 1094 An ITR sends an Encapsulated Map-Request to a configured Map-Resolver 1095 when it needs an EID-to-RLOC mapping that is not found in its local 1096 map-cache. Using the Map-Resolver greatly reduces both the 1097 complexity of the ITR implementation and the costs associated with 1098 its operation. 1100 In response to an Encapsulated Map-Request, the ITR can expect one of 1101 the following: 1103 o An immediate Negative Map-Reply (with action code of "Natively- 1104 Forward", 15-minute Time to Live (TTL)) from the Map-Resolver if 1105 the Map-Resolver can determine that the requested EID does not 1106 exist. The ITR saves the EID-Prefix returned in the Map-Reply in 1107 its cache, marks it as non-LISP-capable, and knows not to attempt 1108 LISP encapsulation for destinations matching it. 1110 o A Negative Map-Reply, with action code of "Natively-Forward", from 1111 a Map-Server that is authoritative for an EID-Prefix that matches 1112 the requested EID but that does not have an actively registered, 1113 more-specific ID-prefix. In this case, the requested EID is said 1114 to match a "hole" in the authoritative EID-Prefix. If the 1115 requested EID matches a more-specific EID-Prefix that has been 1116 delegated by the Map-Server but for which no ETRs are currently 1117 registered, a 1-minute TTL is returned. If the requested EID 1118 matches a non-delegated part of the authoritative EID-Prefix, then 1119 it is not a LISP EID and a 15-minute TTL is returned. See 1120 Section 5.2 for discussion of aggregate EID-Prefixes and details 1121 of Map-Server EID-Prefix matching. 1123 o A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or 1124 possibly from a Map-Server answering on behalf of the ETR. See 1125 Section 5.4 for more details on Map-Resolver message processing. 1127 Note that an ITR may be configured to both use a Map-Resolver and to 1128 participate in a LISP+ALT logical network. In such a situation, the 1129 ITR should send Map-Requests through the ALT network for any EID- 1130 Prefix learned via ALT BGP. Such a configuration is expected to be 1131 very rare, since there is little benefit to using a Map-Resolver if 1132 an ITR is already using LISP+ALT. There would be, for example, no 1133 need for such an ITR to send a Map-Request to a possibly non-existent 1134 EID (and rely on Negative Map-Replies) if it can consult the ALT 1135 database to verify that an EID-Prefix is present before sending that 1136 Map-Request. 1138 5.2. EID-Prefix Configuration and ETR Registration 1140 An ETR publishes its EID-Prefixes on a Map-Server by sending LISP 1141 Map-Register messages. A Map-Register message includes 1142 authentication data, so prior to sending a Map-Register message, the 1143 ETR and Map-Server must be configured with a shared secret or other 1144 relevant authentication information. A Map-Server's configuration 1145 must also include a list of the EID-Prefixes for which each ETR is 1146 authoritative. Upon receipt of a Map-Register from an ETR, a Map- 1147 Server accepts only EID-Prefixes that are configured for that ETR. 1148 Failure to implement such a check would leave the mapping system 1149 vulnerable to trivial EID-Prefix hijacking attacks. As developers 1150 and operators gain experience with the mapping system, additional, 1151 stronger security measures may be added to the registration process. 1153 In addition to the set of EID-Prefixes defined for each ETR that may 1154 register, a Map-Server is typically also configured with one or more 1155 aggregate prefixes that define the part of the EID numbering space 1156 assigned to it. When LISP+ALT is the database in use, aggregate EID- 1157 Prefixes are implemented as discard routes and advertised into ALT 1158 BGP. The existence of aggregate EID-Prefixes in a Map-Server's 1159 database means that it may receive Map Requests for EID-Prefixes that 1160 match an aggregate but do not match a registered prefix; Section 5.3 1161 describes how this is handled. 1163 Map-Register messages are sent periodically from an ETR to a Map- 1164 Server with a suggested interval between messages of one minute. A 1165 Map-Server should time out and remove an ETR's registration if it has 1166 not received a valid Map-Register message within the past 1167 three minutes. When first contacting a Map-Server after restart or 1168 changes to its EID-to-RLOC database mappings, an ETR may initially 1169 send Map-Register messages at an increased frequency, up to one every 1170 20 seconds. This "quick registration" period is limited to 1171 five minutes in duration. 1173 An ETR may request that a Map-Server explicitly acknowledge receipt 1174 and processing of a Map-Register message by setting the "want-map- 1175 notify" (M-bit) flag. A Map-Server that receives a Map-Register with 1176 this flag set will respond with a Map-Notify message. Typical use of 1177 this flag by an ETR would be to set it for Map-Register messages sent 1178 during the initial "quick registration" with a Map-Server but then 1179 set it only occasionally during steady-state maintenance of its 1180 association with that Map-Server. Note that the Map-Notify message 1181 is sent to UDP destination port 4342, not to the source port 1182 specified in the original Map-Register message. 1184 Note that a one-minute minimum registration interval during 1185 maintenance of an ETR-Map-Server association places a lower bound on 1186 how quickly and how frequently a mapping database entry can be 1187 updated. This may have implications for what sorts of mobility can 1188 be supported directly by the mapping system; shorter registration 1189 intervals or other mechanisms might be needed to support faster 1190 mobility in some cases. For a discussion on one way that faster 1191 mobility may be implemented for individual devices, please see 1192 [I-D.meyer-lisp-mn] 1194 An ETR may also request, by setting the "proxy Map-Reply" flag 1195 (P-bit) in the Map-Register message, that a Map-Server answer Map- 1196 Requests instead of forwarding them to the ETR. See 1197 [I-D.ietf-lisp-rfc6830bis] for details on how the Map-Server sets 1198 certain flags (such as those indicating whether the message is 1199 authoritative and how returned Locators should be treated) when 1200 sending a Map-Reply on behalf of an ETR. When an ETR requests proxy 1201 reply service, it should include all RLOCs for all ETRs for the EID- 1202 Prefix being registered, along with the routable flag ("R-bit") 1203 setting for each RLOC. The Map-Server includes all of this 1204 information in Map-Reply messages that it sends on behalf of the ETR. 1205 This differs from a non-proxy registration, since the latter need 1206 only provide one or more RLOCs for a Map-Server to use for forwarding 1207 Map-Requests; the registration information is not used in Map- 1208 Replies, so it being incomplete is not incorrect. 1210 An ETR that uses a Map-Server to publish its EID-to-RLOC mappings 1211 does not need to participate further in the mapping database 1212 protocol(s). When using a LISP+ALT mapping database, for example, 1213 this means that the ETR does not need to implement GRE or BGP, which 1214 greatly simplifies its configuration and reduces its cost of 1215 operation. 1217 Note that use of a Map-Server does not preclude an ETR from also 1218 connecting to the mapping database (i.e., it could also connect to 1219 the LISP+ALT network), but doing so doesn't seem particularly useful, 1220 as the whole purpose of using a Map-Server is to avoid the complexity 1221 of the mapping database protocols. 1223 5.3. Map-Server Processing 1225 Once a Map-Server has EID-Prefixes registered by its client ETRs, it 1226 can accept and process Map-Requests for them. 1228 In response to a Map-Request (received over the ALT if LISP+ALT is in 1229 use), the Map-Server first checks to see if the destination EID 1230 matches a configured EID-Prefix. If there is no match, the Map- 1231 Server returns a Negative Map-Reply with action code "Natively- 1232 Forward" and a 15-minute TTL. This may occur if a Map Request is 1233 received for a configured aggregate EID-Prefix for which no more- 1234 specific EID-Prefix exists; it indicates the presence of a non-LISP 1235 "hole" in the aggregate EID-Prefix. 1237 Next, the Map-Server checks to see if any ETRs have registered the 1238 matching EID-Prefix. If none are found, then the Map-Server returns 1239 a Negative Map-Reply with action code "Natively-Forward" and a 1240 1-minute TTL. 1242 If any of the registered ETRs for the EID-Prefix have requested proxy 1243 reply service, then the Map-Server answers the request instead of 1244 forwarding it. It returns a Map-Reply with the EID-Prefix, RLOCs, 1245 and other information learned through the registration process. 1247 If none of the ETRs have requested proxy reply service, then the Map- 1248 Server re-encapsulates and forwards the resulting Encapsulated Map- 1249 Request to one of the registered ETRs. It does not otherwise alter 1250 the Map-Request, so any Map-Reply sent by the ETR is returned to the 1251 RLOC in the Map-Request, not to the Map-Server. Unless also acting 1252 as a Map-Resolver, a Map-Server should never receive Map-Replies; any 1253 such messages should be discarded without response, perhaps 1254 accompanied by the logging of a diagnostic message if the rate of 1255 Map-Replies is suggestive of malicious traffic. 1257 5.4. Map-Resolver Processing 1259 Upon receipt of an Encapsulated Map-Request, a Map-Resolver 1260 decapsulates the enclosed message and then searches for the requested 1261 EID in its local database of mapping entries (statically configured 1262 or learned from associated ETRs if the Map-Resolver is also a Map- 1263 Server offering proxy reply service). If it finds a matching entry, 1264 it returns a LISP Map-Reply with the known mapping. 1266 If the Map-Resolver does not have the mapping entry and if it can 1267 determine that the EID is not in the mapping database (for example, 1268 if LISP+ALT is used, the Map-Resolver will have an ALT forwarding 1269 table that covers the full EID space), it immediately returns a 1270 negative LISP Map-Reply, with action code "Natively-Forward" and a 1271 15-minute TTL. To minimize the number of negative cache entries 1272 needed by an ITR, the Map-Resolver should return the least-specific 1273 prefix that both matches the original query and does not match any 1274 EID-Prefix known to exist in the LISP-capable infrastructure. 1276 If the Map-Resolver does not have sufficient information to know 1277 whether the EID exists, it needs to forward the Map-Request to 1278 another device that has more information about the EID being 1279 requested. To do this, it forwards the unencapsulated Map-Request, 1280 with the original ITR RLOC as the source, to the mapping database 1281 system. Using LISP+ALT, the Map-Resolver is connected to the ALT 1282 network and sends the Map-Request to the next ALT hop learned from 1283 its ALT BGP neighbors. The Map-Resolver does not send any response 1284 to the ITR; since the source RLOC is that of the ITR, the ETR or Map- 1285 Server that receives the Map-Request over the ALT and responds will 1286 do so directly to the ITR. 1288 5.4.1. Anycast Map-Resolver Operation 1290 A Map-Resolver can be set up to use "anycast", where the same address 1291 is assigned to multiple Map-Resolvers and is propagated through IGP 1292 routing, to facilitate the use of a topologically close Map-Resolver 1293 by each ITR. 1295 Note that Map-Server associations with ETRs should not use anycast 1296 addresses, as registrations need to be established between an ETR and 1297 a specific set of Map-Servers, each identified by a specific 1298 registration association. 1300 6. Security Considerations 1302 The 2-way LISP header nonce exchange documented in 1303 [I-D.ietf-lisp-rfc6830bis] can be used to avoid ITR spoofing attacks. 1305 To publish an authoritative EID-to-RLOC mapping with a Map-Server, an 1306 ETR includes authentication data that is a hash of the message using 1307 a pair-wise shared key. An implementation must support use of HMAC- 1308 SHA-1-96 [RFC2104] and should support use of HMAC-SHA-256-128 1309 [RFC6234] (SHA-256 truncated to 128 bits). 1311 As noted in Section 5.2, a Map-Server should verify that all EID- 1312 Prefixes registered by an ETR match the configuration stored on the 1313 Map-Server. 1315 The currently defined authentication mechanism for Map-Register 1316 messages does not provide protection against "replay" attacks by a 1317 "man-in-the-middle". Additional work is needed in this area. 1319 [I-D.ietf-lisp-sec] defines a proposed mechanism for providing origin 1320 authentication, integrity, anti-replay protection, and prevention of 1321 man-in-the-middle and "overclaiming" attacks on the Map-Request/Map- 1322 Reply exchange. Work is ongoing on this and other proposals for 1323 resolving these open security issues. 1325 While beyond the scope of securing an individual Map-Server or Map- 1326 Resolver, it should be noted that a BGP-based LISP+ALT network (if 1327 ALT is used as the mapping database infrastructure) can take 1328 advantage of standards work on adding security to BGP. 1330 A complete LISP threat analysis has been published in [RFC7835]. 1331 Please refer to it for more security related details. 1333 7. References 1335 7.1. Normative References 1337 [RFC1035] Mockapetris, P., "Domain names - implementation and 1338 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1339 November 1987, . 1341 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1342 Hashing for Message Authentication", RFC 2104, 1343 DOI 10.17487/RFC2104, February 1997, 1344 . 1346 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 1347 ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November 1348 1998, . 1350 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1351 "Randomness Requirements for Security", BCP 106, RFC 4086, 1352 DOI 10.17487/RFC4086, June 2005, 1353 . 1355 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 1356 Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, 1357 June 2005, . 1359 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 1360 384, and HMAC-SHA-512 with IPsec", RFC 4868, 1361 DOI 10.17487/RFC4868, May 2007, 1362 . 1364 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 1365 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 1366 DOI 10.17487/RFC6234, May 2011, 1367 . 1369 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 1370 Locator/ID Separation Protocol (LISP) for Multicast 1371 Environments", RFC 6831, DOI 10.17487/RFC6831, January 1372 2013, . 1374 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 1375 "Locator/ID Separation Protocol Alternative Logical 1376 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 1377 January 2013, . 1379 [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to 1380 Routing Locator (RLOC) Database", RFC 6837, 1381 DOI 10.17487/RFC6837, January 2013, 1382 . 1384 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 1385 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 1386 eXtensible Local Area Network (VXLAN): A Framework for 1387 Overlaying Virtualized Layer 2 Networks over Layer 3 1388 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 1389 . 1391 [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID 1392 Separation Protocol (LISP) Threat Analysis", RFC 7835, 1393 DOI 10.17487/RFC7835, April 2016, 1394 . 1396 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 1397 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 1398 February 2017, . 1400 [RFC8113] Boucadair, M. and C. Jacquenet, "Locator/ID Separation 1401 Protocol (LISP): Shared Extension Message & IANA Registry 1402 for Packet Type Allocations", RFC 8113, 1403 DOI 10.17487/RFC8113, March 2017, 1404 . 1406 7.2. Informative References 1408 [AFI] IANA, , "Address Family Identifier (AFIs)", ADDRESS FAMILY 1409 NUMBERS http://www.iana.org/assignments/address-family- 1410 numbers/address-family-numbers.xhtml?, Febuary 2007. 1412 [I-D.ermagan-lisp-nat-traversal] 1413 Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, 1414 F., and C. White, "NAT traversal for LISP", draft-ermagan- 1415 lisp-nat-traversal-12 (work in progress), March 2017. 1417 [I-D.ietf-lisp-ddt] 1418 Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 1419 Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp- 1420 ddt-09 (work in progress), January 2017. 1422 [I-D.ietf-lisp-introduction] 1423 Cabellos-Aparicio, A. and D. Saucez, "An Architectural 1424 Introduction to the Locator/ID Separation Protocol 1425 (LISP)", draft-ietf-lisp-introduction-13 (work in 1426 progress), April 2015. 1428 [I-D.ietf-lisp-rfc6830bis] 1429 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 1430 Cabellos-Aparicio, "The Locator/ID Separation Protocol 1431 (LISP)", draft-ietf-lisp-rfc6830bis-02 (work in progress), 1432 April 2017. 1434 [I-D.ietf-lisp-sec] 1435 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 1436 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-12 1437 (work in progress), November 2016. 1439 [I-D.ietf-lisp-signal-free-multicast] 1440 Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", 1441 draft-ietf-lisp-signal-free-multicast-03 (work in 1442 progress), April 2017. 1444 [I-D.lewis-lisp-gpe] 1445 Lewis, D., Agarwal, P., Kreeger, L., Maino, F., Quinn, P., 1446 Smith, M., and N. Yadav, "LISP Generic Protocol 1447 Extension", draft-lewis-lisp-gpe-02 (work in progress), 1448 July 2014. 1450 [I-D.meyer-lisp-mn] 1451 Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP 1452 Mobile Node", draft-meyer-lisp-mn-16 (work in progress), 1453 December 2016. 1455 [I-D.portoles-lisp-eid-mobility] 1456 Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, 1457 F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a 1458 Unified Control Plane", draft-portoles-lisp-eid- 1459 mobility-02 (work in progress), April 2017. 1461 [I-D.quinn-vxlan-gpe] 1462 Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F., 1463 Smith, M., Agarwal, P., Yong, L., Xu, X., Elzur, U., Garg, 1464 P., and D. Melman, "Generic Protocol Extension for VXLAN", 1465 draft-quinn-vxlan-gpe-04 (work in progress), February 1466 2015. 1468 [LISP-CONS] 1469 Brim, S., Chiappa, N., Farinacci, D., Fuller, V., Lewis, 1470 D., and D. Meyer, "LISP-CONS: A Content distribution 1471 Overlay Network Service for LISP", Work in Progress, April 1472 2008. 1474 Appendix A. Acknowledgments 1476 The authors would like to thank Greg Schudel, Darrel Lewis, John 1477 Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver, 1478 Fabio Maino, and members of the lisp@ietf.org mailing list for their 1479 feedback and helpful suggestions. 1481 Special thanks are due to Noel Chiappa for his extensive work on 1482 caching with LISP-CONS, some of which may be used by Map-Resolvers. 1484 Appendix B. Document Change Log 1486 [RFC Editor: Please delete this section on publication as RFC.] 1488 B.1. Changes to draft-ietf-lisp-rfc6833bis-03 1490 o Posted April 2017. 1492 o Add types 9-14 and specify they are not assigned. 1494 o Add the "LISP Shared Extension Message" type and point to RFC8113. 1496 B.2. Changes to draft-ietf-lisp-rfc6833bis-02 1498 o Posted April 2017. 1500 o Clarify that the LISP control-plane document defines how the LISP 1501 data-plane uses Map-Requests with either the SMR-bit set or the 1502 P-bit set supporting mapping updates and RLOC-probing. Indicating 1503 that other data-planes can use the same mechanisms or their own 1504 defined mechanisms to achieve the same functionality. 1506 B.3. Changes to draft-ietf-lisp-rfc6833bis-01 1508 o Posted March 2017. 1510 o Include references to new RFCs published. 1512 o Remove references to self. 1514 o Change references from RFC6830 to RFC6830bis. 1516 o Add two new action/reasons to a Map-Reply has posted to the LISP 1517 WG mailing list. 1519 o In intro section, add refernece to I-D.ietf-lisp-introduction. 1521 o Removed Open Issues section and references to "experimental". 1523 B.4. Changes to draft-ietf-lisp-rfc6833bis-00 1525 o Posted December 2016. 1527 o Created working group document from draft-farinacci-lisp 1528 -rfc6833-00 individual submission. No other changes made. 1530 B.5. Changes to draft-farinacci-lisp-rfc6833bis-00 1532 o Posted November 2016. 1534 o This is the initial draft to turn RFC 6833 into RFC 6833bis. 1536 o The document name has changed from the "Locator/ID Separation 1537 Protocol (LISP) Map-Server Interface" to the "Locator/ID 1538 Separation Protocol (LISP) Control-Plane". 1540 o The fundamental change was to move the control-plane messages from 1541 RFC 6830 to this document in an effort so any IETF developed or 1542 industry created data-plane could use the LISP mapping system and 1543 control-plane. 1545 o Update control-plane messages to incorporate what has been 1546 implemented in products during the early phase of LISP development 1547 but wasn't able to make it into RFC6830 and RFC6833 to make the 1548 Experimental RFC deadline. 1550 o Indicate there may be nodes in the mapping system that are not MRs 1551 or MSs, that is a ALT-node or a DDT-node. 1553 o Include LISP-DDT in Map-Resolver section and explain how they 1554 maintain a referral-cache. 1556 o Removed open issue about additional state in Map-Servers. With 1557 [I-D.ietf-lisp-ddt], Map-Servers have the same registration state 1558 and can give Map-Resolvers complete information in ms-ack Map- 1559 Referral messages. 1561 o Make reference to the LISP Threats Analysis RFC [RFC7835]. 1563 Authors' Addresses 1565 Vince Fuller 1566 Cisco Systems 1568 EMail: vaf@vaf.net 1569 Dino Farinacci 1570 Cisco Systems 1572 EMail: farinacci@gmail.com 1574 Albert Cabellos 1575 UPC/BarcelonaTech 1576 Campus Nord, C. Jordi Girona 1-3 1577 Barcelona, Catalunya 1578 Spain 1580 EMail: acabello@ac.upc.edu