idnits 2.17.1 draft-boucadair-lisp-bulk-07.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 03, 2018) is 2205 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) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) ** Obsolete normative reference: RFC 6833 (Obsoleted by RFC 9301) ** Obsolete normative reference: RFC 8113 (Obsoleted by RFC 9304) == Outdated reference: A later version (-08) exists of draft-kouvelas-lisp-map-server-reliable-transport-04 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft C. Jacquenet 4 Intended status: Standards Track Orange 5 Expires: October 5, 2018 April 03, 2018 7 LISP Mapping Bulk Retrieval 8 draft-boucadair-lisp-bulk-07 10 Abstract 12 This document extends Locator/ID Separation Protocol (LISP) with a 13 capability for bulk mapping retrieval. It does so by defining new 14 LISP messages that are meant to facilitate state recovery of mapping 15 tables and improve Ingress Tunnel Routers (ITR) recovery times, in 16 particular. Unlike base LISP, these new messages are transported 17 over TCP. 19 In addition, this document allows to request mappings that match 20 destination IP prefixes, names, or AS numbers. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on October 5, 2018. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 58 3. Bulk Mapping Retrieval: Message Formats . . . . . . . . . . . 3 59 3.1. Map-Bulk-Request Message Format . . . . . . . . . . . . . 3 60 3.2. Map-Bulk-Response Message Format . . . . . . . . . . . . 5 61 4. Generating a Map-Bulk-Request Message . . . . . . . . . . . 7 62 5. Processing a Map-Bulk-Request Message . . . . . . . . . . . . 8 63 6. Processing a Map-Bulk-Reply Message . . . . . . . . . . . . . 9 64 7. Bulk Mapping Retrival from Multiple Resolvers . . . . . . . . 10 65 8. Sample Examples . . . . . . . . . . . . . . . . . . . . . . . 11 66 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 67 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 68 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 69 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 12.1. Normative references . . . . . . . . . . . . . . . . . . 13 71 12.2. Informative references . . . . . . . . . . . . . . . . . 14 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 74 1. Introduction 76 Locator/ID Separation Protocol (LISP, [RFC6830] ) operation relies 77 upon a mapping mechanism that is used by ingress/egress Tunnel 78 Routers (xTR) to forward traffic over the LISP network. This 79 document extends LISP with a capability for bulk mappings retrieval. 80 It does so by defining new LISP messages that are meant to facilitate 81 state recovery of mapping tables and improve Ingress Tunnel Routers 82 (ITR) recovery times, in particular. 84 The base LISP specification does not define how a requestor may ask 85 for multiple EIDs. Indeed, the current LISP specification [RFC6830] 86 states the following: 88 Support for requesting multiple EIDs in a single Map-Request 89 message will be specified in a future version of the protocol. 91 [I-D.boucadair-lisp-multiple-records] defines a backward compatible 92 extension of the LISP Map-Request message to request multiple 93 records. 95 This document defines a more reliable method for the retrieval of 96 mapping records from one or multiple Map-Resolvers (Section 3). It 97 does so by using TCP ([RFC0793]) as a transport protocol for 98 exchanges the bulk retrieval messages. Other proposals have been 99 made to use TCP for reliable transport (e.g., 100 [I-D.kouvelas-lisp-map-server-reliable-transport]). 102 The extensions defined by this document allow for faster recovery of 103 mapping entries. For example: 105 1. Whenever an ITR fails for some reason, the faulty ITR needs to 106 recover at least the list of mappings for the most popular 107 prefixes in a timely manner, etc. 109 2. These extensions may be used by a leaf LISP network or enabled 110 between Mapping Systems for the sake of global mapping table 111 maintenance. Policies for the mapping entries to be recovered 112 are deployment-specific. 114 This document allows to request mappings that match destination IP 115 prefixes, names, or AS numbers. Other filter types may be defined in 116 future versions, if needed. 118 2. Requirements Language 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [RFC2119]. 124 3. Bulk Mapping Retrieval: Message Formats 126 To allow for a more reliable method when retrieving multiple EID 127 mapping records from one or multiple Map-Resolvers, this section 128 defines additional LISP messages that are, unlike LISP control 129 messages, transported over TCP. 131 After establishing a TCP connection towards a Map-Resolver (using the 132 LISP service port), the ITR sends a Map-Bulk-Request (Section 3.1). 133 Upon receipt of that message, the Map-Resolver must reply with one or 134 more Map-Bulk-Reply messages (Section 3.2). Once the last Map-Bulk- 135 Reply is received from the Map-Resolver, the underlying TCP 136 connection may be closed. 138 3.1. Map-Bulk-Request Message Format 140 The format of the Map-Bulk-Request message is shown in Figure 1. 142 0 1 2 3 143 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 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 |Type=15| Sub-type |R| Reserved | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Transaction ID | 148 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | | Length | | 150 F +-+-+-+-+-+-+-+-+ : 151 I : Filter : 152 L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 T ... 154 E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 R | Length | | 156 S +-+-+-+-+-+-+-+-+ : 157 | : Filter : 158 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 Figure 1: Map-Bulk-Request Message Format 162 The description of the fields is as follows: 164 o Type: MUST be set to 15(see [RFC8113]). 166 o Sub-type: MUST be set to 1025. 168 o R bit: MUST be set to 0 for Map-Bulk-Request messages. 170 o Reserved: reserved bits, MUST be sent as zeros and MUST be ignored 171 when received. 173 o Transaction ID: This field is used to uniquely identify a 174 connection context among those established with the same Map- 175 Resolver. Demux connections established with distinct Map- 176 Resolvers may rely on the address of the Map-Resolver. A 177 transaction-id MUST be unique for connections bound to the same 178 Map-Resolver. 180 o Length: This field indicates, in octets, the length of the filter 181 that is encoded in the "Filter" field. 183 o Filter: This field carries a destination EID (or a set thereof) 184 that is encoded as an UTF-8 string. This specification allows to 185 convey IP prefix literals, Names and/or AS numbers. One or 186 multiple filters may be present in a request. IPv4 prefixes are 187 encoded as IPv4-mapped IPv6 prefixes [RFC4291] (i.e., starting 188 with ::ffff:0:0/96). A mix of names, IP prefixes and AS numbers 189 may be enclosed in the same request. The value 0 is used to 190 indicate "ANY" mapping. 192 3.2. Map-Bulk-Response Message Format 194 The format of the Map-Bulk-Reply message is shown in Figure 2. 196 0 1 2 3 197 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 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 |Type=15| Sub-type |R|M|rsv| Records Count |Results| 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Transaction ID | 202 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | | Code | Length | | 204 F +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 205 I : Filter : 206 L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 T ... 208 E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 R | Code | Length | | 210 S +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 211 | : Filter : 212 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | | Record TTL | 214 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 R | Locator Count | EID mask-len | ACT |A| Reserved | 216 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 c | Rsvd | Map-Version Number | EID-Prefix-AFI | 218 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 r | EID-Prefix | 220 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | /| Priority | Weight | M Priority | M Weight | 222 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | o | Unused Flags |L|p|R| Loc-AFI | 224 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | \| Locator | 226 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 ... 228 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | | Record TTL | 230 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 R | Locator Count | EID mask-len | ACT |A| Reserved | 232 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 c | Rsvd | Map-Version Number | EID-Prefix-AFI | 234 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 r | EID-Prefix | 236 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | /| Priority | Weight | M Priority | M Weight | 238 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | o | Unused Flags |L|p|R| Loc-AFI | 240 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | \| Locator | 242 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 Figure 2: Map-Bulk-Reply Message Format 246 The description of the fields of the Map-Bulk-Reply is similar to 247 those of a LISP Map-Request message ([RFC6830]), except the 248 following: 250 o Type is to be defined. The same code is used for both Map-Bulk- 251 Request and Map-Bulk-Reply. 253 o R bit: MUST be set to 1 for Map-Bulk-Reply messages. 255 o M (more-data bit): When set, this flag indicates that other 256 records are to be expected from the Map-Resolver. 258 o rsv: reserved bits, MUST be sent as zeros and MUST be ignored when 259 received. 261 o Records Count: Indicates the number of records included in the 262 response. 264 o Result: indicates the result code of the processing of the Map- 265 Bulk-Request message. The following codes are defined: 267 0: SUCCESS. This code indicates the request is successfully 268 processed. 270 1: BULK-PROHIBITED. This code indicates the bulk mapping is 271 blocked for this ITR, leaf LISP network, subscriber, etc. 273 2: BULK-LIMIT. This code indicates a rate-limit is applied on the 274 Map-Bulk-Request messages from the same ITR, leaf LISP network, 275 subscriber, etc. The ITR SHOULD re-issue the request after the 276 expiry of a timer; the default value of that timer is 60 277 seconds. Other values may be configured on the ITR. 279 3: OUT-OF-RESOURCES. This code indicates a Map-Resolver is 280 running out of resources. The ITR SHOULD re-iterate the same 281 request after the expiry of a timer. The default value of that 282 timer is 300 seconds. Other values MAY be configured on the 283 ITR. 285 o Filter Count: 287 o Transaction ID: MUST echo the one included in the Map-Bulk- 288 Request. 290 o Code: Filters that were not processed by the Map-Resolver are 291 included. A filter MUST be included in a response if and only if 292 an error was encountered when processing that filter at the Map- 293 Resolver side. The code field provides more details about the 294 reason for not processing such filter. If all filters were 295 successfully processed by the Map-Resolver, this field MUST be set 296 to 0. The following values are defined: 298 0: FILTER-UNSUPPORTED. This code indicates a request is 299 successfully processed but this filter was not processed 300 because the format of the filter is not supported. 302 1: FILTER-BAD. This code indicates a request is successfully 303 processed but the filter was not processed because it is 304 malformed. 306 2: FILTER-MAX. This code indicates a request is successfully 307 processed but the filter was not processed because of a limit 308 enforced on the maximum number of filters to be processed. 310 3: FILTER-LOCAL. This code indicates a request is successfully 311 processed but the filter was not processed because of local 312 reasons. The ITR SHOULD, after a certain timer expires, send a 313 Map-Bulk-Request message for the set of filters that are not 314 processed with a reason code set to BULK-LOCAL. 316 o Length: Indicates the length of a filter this is not processed by 317 the Map-Resolver. 319 o Filter: Conveys a filter that is not processed by the Map- 320 Resolver. 322 4. Generating a Map-Bulk-Request Message 324 ITRs MUST support a configurable parameter to enable/disable bulk 325 mapping retrieval over TCP. The default value is set to "enabled". 327 If distinct port number is used by remote Map-Resolvers, the 328 destination port number to send Map-Bulk-Request messages SHOULD be 329 configured to the ITR. 331 After establishing a TCP connection towards a Map-Resolver (using the 332 LISP service port), the ITR MUST send a Map-Bulk-Request 333 (Section 3.1) to a Map-Resolver. Configuration information for 334 triggering bulk retrieval request messages MAY be provisioned to each 335 ITR. Multiple Map-Bulk-Request messages may be sent over the same 336 TCP connection. 338 An ITR that loses its mapping cache for some reason SHOULD generate a 339 Map-Bulk-Request message towards its Map-Resolver(s) with the set of 340 filters that are configured locally. 342 An ITR MAY generate several Map-Bulk-Request messages to the same or 343 distinct Map-Resolvers. 345 An ITR MUST generate a unique transaction-id per Map-Bulk-Request it 346 issues. 348 An ITR MUST expect that the Map-Resolver may limit the number of 349 filters that may be processed. Filters that are not accepted or not 350 processed by the Map-Resolvers are included in a Map-Bulk-Reply. 352 5. Processing a Map-Bulk-Request Message 354 A Map-Resolver that does not support the Map-Bulk-Request message 355 MUST silently ignore any Map-Bulk-Request message it receives. 357 Map-Resolvers MUST support a configurable parameter to enable/disable 358 the processing of Map-Bulk-Request messages. The default value is 359 set to "enabled". 361 A Map-Resolver that is enabled to process Map-Bulk-Request messages 362 MUST listen to incoming TCP connections on the default LISP service 363 port. ACLs MAY be configured to control the leaf networks that can 364 invoke this feature. 366 A Map-Resolver SHOULD support a configuration parameter to rate-limit 367 the number of simultaneous Map-Bulk-Request messages per leaf LISP 368 network, per ITR, etc. 370 If a Map-Resolver receives a Map-Bulk-Request message and it is 371 enabled to process it, a Map-Resolver MUST reply with one or multiple 372 Map-Bulk-Reply messages. 374 If multiple Map-Bulk-Reply messages are required to respond to a 375 given request, the Map-Resolver MUST: 377 o Echo the transaction-id. 379 o Set to R-bit. 381 o Set the M-bit for all Map-Bulk-Reply messages, except for the last 382 one. 384 o Include the set of filters that are not successfully processed for 385 some reason (e.g., malformed filter) and set the "Filter Count" 386 accordingly. 388 If filters are included in the request, the Map-Resolver MUST extract 389 those filters and lookup its mapping system accordingly. In 390 particular, the Map-Resolver MUST reply with a full mapping table if 391 a Null filter is included in the Map-Bulk-Request. 393 If bulk mapping retrieval is not allowed for a given ITR, the 394 'Result' field MUST be set to BULK-PROHIBITED. 396 If the Map-Resolver fails to process a request because limits for 397 that ITR are exceeded, it MUST set the 'Result' field to BULK-LIMIT. 399 If a subset of filters are successfully processed, the 'Result' field 400 MUST be set to SUCCESS. The set of filters that are not processed 401 MUST be echoed in the Map-Bulk-Reply; each with a failure code that 402 reflects the reason why the filter was not applied. If a filter type 403 is not supported by the Map-Resolver, the 'Code' field MUST be set to 404 FILTER-UNSUPPORTED. If the Map-Resolver fails to process some of the 405 filters included in a request because these filters were malformed, 406 it MUST echo the corresponding filters in the Map-Bulk-Reply message 407 and MUST set the 'Code' field to FILTER-BAD. f the Map-Resolver fails 408 to process some of the filters included in a request because a 409 maximum number of filters is supported, it MUST echo the 410 corresponding filters in the Map-Bulk-Reply message and set the 411 'Code' field to FILTER-MAX. If, for some other reasons, the Map- 412 Resolver fails to apply some filters included in a request, it MUST 413 echo the corresponding filter in the Map-Bulk-Reply message. The 414 'Code' field MUST be set to FILTER-LOCAL. 416 A Map-Resolver that is overloaded MUST reply with a Map-Bulk-Reply 417 message with the "Result" code set to OUT-OF-RESOURCES. 419 6. Processing a Map-Bulk-Reply Message 421 Upon receipt of a Map-Bulk-Reply message, the ITR MUST check whether 422 the message matches a Map-Bulk-Request it issued for the same Map- 423 Resolver. If no matching state is found, the message MUST be 424 silently dropped. If a state is found, the ITR MUST proceed as 425 follows: 427 o An ITR that receives the result code set to BULK-PROHIBITED MUST 428 NOT reissue a Map-Bulk-Request message to that Map-Resolver. 430 o An ITR that receives the result code set to BULK-LIMIT MUST NOT 431 try to resend the same request before the expiry of the 432 retransmission timeout (default value set to 60 seconds). 434 o An ITR that receives the result code set to OUT-OF-RESOURCES MUST 435 NOT resend the same request before 300 seconds. 437 o If the M-bit is set, it should expect that other Map-Bulk-Reply 438 messages will be received from this Map-Resolver. Appropriate 439 security mechanisms (e.g., Access Control Lists) SHOULD be 440 activated to allow the processing of these incoming unsolicited 441 Map-Bulk-Reply messages. 443 o If the M-bit is unset, this is an indication that this message 444 terminates the mapping bulk retrieval transaction. The ITR may 445 decide to terminate the underlying TCP connections if no other 446 transactions bound to the same Map-Resolver are active. 448 o Filters that are returned in the Map-Bulk-Reply message may not be 449 valid or have exceeded a limit. The "Code" field indicates the 450 reason for not processing these filters. In particular: 452 * An ITR that receives the 'Code' field set to FILTER-BAD or 453 FILTER-UNSUPPORTED MUST NOT resend the same filters that were 454 returned in the Map-Bulk-Reply message, in subsequent Map-Bulk- 455 Request messages. Furthermore, subsequent Map-Bulk-Request 456 messages MUST NOT use the unsupported format to encode the 457 filters. 459 * An ITR that receives the 'Code' field set to FILTER-MAX SHOULD 460 issue another Map-Bulk-Request message with the filters that 461 were returned in the Map-Bulk-Reply message with this code. 463 * An ITR that receives the 'Code' field set to FILTER-LOCAL 464 SHOULD for at least 60 seconds before issuing another Map-Bulk- 465 Request message with the filters that were returned in the Map- 466 Bulk-Reply message with this code. 468 7. Bulk Mapping Retrival from Multiple Resolvers 470 In order to retrieve mapping entries from multiple Map-Resolvers, an 471 ITR issues Map-Bulk-Request messages to a list of Map-Resolvers. 472 Each of these requests is handled as specified in Section 4. 474 An ITR MAY be configured to issue multiple Map-Bulk-Request messages 475 to distinct Map-Resolvers. 477 Conflicts may arise when contacting multiple Map-Resolvers. These 478 conflicts are not specific to the bulk mapping retrieval as this is 479 also an issue for individual mapping lookup. 481 8. Sample Examples 483 Figure 3 illustrates the example of a bulk mapping retrieval that is 484 achieved with one single Map-Bulk-Reply, while Figure 4 shows an 485 example of a bulk mapping retrieval that requires multiple Map-Bulk- 486 Reply messages. 488 +--------+ +--------+ 489 | ITR | | MR | 490 +--------+ +--------+ 491 |<- Session Establishment--->| 492 | | 493 |Map-Bulk-Request (ID, d_EID | 494 | d_EID2, ..., d_EIDn) | 495 |--------------------------->| 496 | Map-Bulk-Reply(M=0) | 497 |<---------------------------| 499 Figure 3: Example of Bulk Mapping Retrieval 501 +--------+ +--------+ 502 | ITR | | MR | 503 +--------+ +--------+ 504 |<- Session Establishment -->| 505 | | 506 |Map-Bulk-Request (ID, d_EID | 507 | d_EID2, ..., d_EIDn) | 508 |--------------------------->| 509 |Map-Bulk-Reply(M=1, rec1, | 510 | rec2, ..., recn)| 511 |<---------------------------| 512 |Map-Bulk-Reply(M=1,recn+1 | 513 | recn+2, ..., recm)| 514 |<---------------------------| 515 ... 516 |Map-Bulk-Reply(M=0, recs) | 517 |<---------------------------| 519 Figure 4: Example of Bulk Mapping Retrieval 521 The bulk mapping retrieval allows to retrieve records that do not 522 only match IP prefixes, but also AS numbers or even names. When 523 names or AS numbers are included, the Map-Resolver is responsible for 524 identifying which IP prefixes are to be returned. 526 An ITR can establish multiple transactions with the same Map-Resolver 527 as shown in Figure 5. 529 +--------+ +--------+ 530 | ITR | | MR | 531 +--------+ +--------+ 532 |<- Session Establishment -->| 533 | | 534 |Map-Bulk-Request (ID1) | 535 |--------------------------->| 536 | Map-Bulk-Reply(ID1) | 537 |<---------------------------| 538 ... 539 |Map-Bulk-Request (ID2) | 540 |--------------------------->| 541 | Map-Bulk-Reply(ID2) | 542 |<---------------------------| 543 | Map-Bulk-Reply(ID2) | 544 |<---------------------------| 545 ... 546 |Map-Bulk-Request (IDa) | 547 |--------------------------->| 548 |Map-Bulk-Request (IDb) | 549 |--------------------------->| 550 | Map-Bulk-Reply(IDa) | 551 |<---------------------------| 552 | Map-Bulk-Reply(IDb) | 553 |<---------------------------| 554 | Map-Bulk-Reply(IDb) | 555 |<---------------------------| 556 | Map-Bulk-Reply(IDa) | 557 |<---------------------------| 559 Figure 5: Multiple Transactions with the Same Map-Resolver 561 9. Security Considerations 563 In addition to the security considerations discussed in [RFC6830] and 564 [RFC6833], TCP-specific threats are valid for this specification 565 (e.g., [I-D.ietf-tcpm-tcp-security]). 567 In order to avoid exhausting the resources of Map-Resolvers, Map- 568 Bulk-Request messages SHOULD be rate-limited. Furthermore, a Map- 569 Resolver MAY configure ACLs to control leaf LISP networks that are 570 allowed to issue Map-Bulk-Request messages. 572 The structure of a record conveyed in a Map-Bulk-Reply is exactly the 573 same as in [RFC6830]. As such, this specification does leak 574 information that would not be revealed using the base LISP. 576 10. IANA Considerations 578 IANA has assigned this LISP Shared Extension Message Type Sub-type 579 ([RFC8113]) for this registry https://www.iana.org/assignments/lisp- 580 parameters/lisp-parameters.xhtml#lisp-shared-extension-message-type- 581 sub-types: 583 Message Sub-type Reference 584 ================================= ======= =============== 585 Map-Bulk-Request/Map-Bulk-Reply 1025 [This document] 587 11. Acknowledgments 589 This work is partly funded by ANR LISP-Lab project #ANR-13-INFR- 590 009-X. 592 Many thanks to S. Secci and Chi Dung Phung for the comments. 594 12. References 596 12.1. Normative references 598 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 599 RFC 793, DOI 10.17487/RFC0793, September 1981, 600 . 602 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 603 Requirement Levels", BCP 14, RFC 2119, 604 DOI 10.17487/RFC2119, March 1997, 605 . 607 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 608 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 609 2006, . 611 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 612 Locator/ID Separation Protocol (LISP)", RFC 6830, 613 DOI 10.17487/RFC6830, January 2013, 614 . 616 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 617 Protocol (LISP) Map-Server Interface", RFC 6833, 618 DOI 10.17487/RFC6833, January 2013, 619 . 621 [RFC8113] Boucadair, M. and C. Jacquenet, "Locator/ID Separation 622 Protocol (LISP): Shared Extension Message & IANA Registry 623 for Packet Type Allocations", RFC 8113, 624 DOI 10.17487/RFC8113, March 2017, 625 . 627 12.2. Informative references 629 [I-D.boucadair-lisp-multiple-records] 630 Boucadair, M. and C. Jacquenet, "Retrieving Multiple LISP 631 Records", draft-boucadair-lisp-multiple-records-00 (work 632 in progress), October 2017. 634 [I-D.ietf-tcpm-tcp-security] 635 Gont, F., "Survey of Security Hardening Methods for 636 Transmission Control Protocol (TCP) Implementations", 637 draft-ietf-tcpm-tcp-security-03 (work in progress), March 638 2012. 640 [I-D.kouvelas-lisp-map-server-reliable-transport] 641 Cassar, C., Leong, J., Lewis, D., Kouvelas, I., and J. 642 Arango, "LISP Map Server Reliable Transport", draft- 643 kouvelas-lisp-map-server-reliable-transport-04 (work in 644 progress), September 2017. 646 Authors' Addresses 648 Mohamed Boucadair 649 Orange 650 Rennes 35000 651 France 653 EMail: mohamed.boucadair@orange.com 655 Christian Jacquenet 656 Orange 657 Rennes 35000 658 France 660 EMail: christian.jacquenet@orange.com