idnits 2.17.1 draft-boucadair-lisp-bulk-05.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 26, 2017) is 2556 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-03 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 Updates: 6830 (if approved) Orange 5 Intended status: Standards Track April 26, 2017 6 Expires: October 28, 2017 8 LISP Mapping Bulk Retrieval 9 draft-boucadair-lisp-bulk-05 11 Abstract 13 This document extends Locator/ID Separation Protocol (LISP) with a 14 capability for bulk mapping retrieval. It does so by defining new 15 LISP messages that are meant to facilitate state recovery of mapping 16 tables and improve Ingress Tunnel Routers (ITR) recovery times, in 17 particular. In addition, this document allows to request mappings 18 that match destination IP prefixes, names, or AS numbers. 20 This document updates RFC6830. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on October 28, 2017. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Map-Request with Multiple Records . . . . . . . . . . . . . . 3 64 3. Bulk Mapping Retrieval . . . . . . . . . . . . . . . . . . . 7 65 3.1. Map-Bulk-Request Message Format . . . . . . . . . . . . . 9 66 3.2. Map-Bulk-Response Message Format . . . . . . . . . . . . 11 67 3.3. Generating a Map-Bulk-Request Message . . . . . . . . . 13 68 3.4. Processing a Map-Bulk-Request Message . . . . . . . . . . 14 69 3.5. Processing a Map-Bulk-Reply Message . . . . . . . . . . . 15 70 3.6. Bulk Mapping Retrival from Multiple Resolvers . . . . . . 16 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 73 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 7.1. Normative references . . . . . . . . . . . . . . . . . . 17 76 7.2. Informative references . . . . . . . . . . . . . . . . . 18 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 79 1. Introduction 81 Locator/ID Separation Protocol (LISP, [RFC6830] ) operation relies 82 upon a mapping mechanism that is used by ingress/egress Tunnel 83 Routers (xTR) to forward traffic over the LISP network. This 84 document extends LISP with a capability for bulk mappings retrieval. 85 It does so by defining new LISP messages that are meant to facilitate 86 state recovery of mapping tables and improve Ingress Tunnel Routers 87 (ITR) recovery times, in particular. 89 The base LISP specification does not define how a requestor may ask 90 for multiple EIDs. Indeed, the current LISP specification [RFC6830] 91 states the following: 93 Support for requesting multiple EIDs in a single Map-Request 94 message will be specified in a future version of the protocol. 96 The extensions defined by this document allow for faster recovery of 97 mapping entries. For example, whenever an ITR fails for some reason, 98 the faulty ITR needs to recover at least the list of mappings for the 99 most popular prefixes in a timely manner, etc. These extensions may 100 be used by a leaf LISP network or enabled between mapping systems for 101 the sake of global mapping table maintenance. Policies for the 102 mapping entries to be recovered are deployment-specific. 104 The document defines a backward compatible extension of the LISP Map- 105 Request message to request multiple records (Section 2). Also, it 106 defines a more reliable method for the retrieval of mapping records 107 from one or multiple Map-Resolvers (Section 3). It does so by using 108 TCP ([RFC0793]) as a transport protocol for exchanges the bulk 109 retrieval messages. Other proposals have been made to use TCP for 110 reliable transport (e.g., 111 [I-D.kouvelas-lisp-map-server-reliable-transport]) 113 This document allows to request mappings that match destination IP 114 prefixes, names, or AS numbers. Other filter types may be defined in 115 future versions, if needed. 117 2. Map-Request with Multiple Records 119 As mentioned in Section 1, [RFC6830] does not specify how an ITR can 120 request for multiple EIDs using the same Map-Request message. This 121 document fills that void. 123 Figure 1 shows the difference between the current Map-Request message 124 format and the new format that includes the proposed extension. This 125 extension is meant to allow an ITR to request multiple EID records by 126 using the same Map-Request. 128 The proposed design is backward compatible since it aligns the 129 additional requested EID records at the end of the Map-Request 130 message. 132 As specified in [RFC6830], a mapping system must be prepared to 133 receive a request for multiple EID records in a Map-Request message. 134 A receiver relies upon the content of the "Record Count" field of the 135 Map-Request message to detect whether one or multiple records are 136 carried in the request. 138 OLD: 139 0 1 2 3 140 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 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 |Type=1 |A|M|P|S|p|s| Reserved | IRC | Record Count | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Nonce . . . | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | . . . Nonce | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Source-EID-AFI | Source EID Address ... | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | ... | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | ITR-RLOC-AFI n | ITR-RLOC Address n ... | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 / | Reserved | EID mask-len | EID-Prefix-AFI | 158 Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 \ | EID-Prefix ... | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Map-Reply Record ... | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 NEW: 165 0 1 2 3 166 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 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 |Type=1 |A|M|P|S|p|s| Reserved | IRC | Record Count | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Nonce . . . | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | . . . Nonce | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Source-EID-AFI | Source EID Address ... | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | ... | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | ITR-RLOC-AFI n | ITR-RLOC Address n ... | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 / | Reserved | EID mask-len | EID-Prefix-AFI | 183 Rec 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 \ | EID-Prefix ... | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Map-Reply Record ... | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 / | Reserved | EID mask-len | EID-Prefix-AFI | 189 Rec 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 \ | EID-Prefix ... | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 : ... : 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 / | Reserved | EID mask-len | EID-Prefix-AFI | 195 Rec m +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 \ | EID-Prefix ... | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 Figure 1 201 The description of the fields of the updated Map-Request message is 202 exactly the same as in [RFC6830], except the additional records that 203 are prepended after the "Map-Reply Record" . The structure of a 204 record is exactly the same as in [RFC6830]. 206 When extracting the records included in a Map-Request message, a Map- 207 Resolver replies with the list of mappings that match these records. 208 One or multiple Map-Reply messages may be required to carry the 209 mapping records that match the requested EIDs included in a Map- 210 Request. 212 An ITR MUST be prepared to receive multiple Map-Reply messages from a 213 Map-Resolver as a response to a bulk Map-Request message that it 214 originally sent to that Map-Resolver. 216 In order to inform an ITR that subsequent Map-Reply messages will 217 follow (or not) , a dedicated flag bit is defined for this purpose: 218 it is called the M-bit (more-map-reply bit). 220 When set, the M-bit (more-map-reply bit) flag indicates this is not 221 the last Map-Reply message to be received by the requesting ITR; 222 additional Map-Reply messages follow. An implementation uses this 223 bit to decide when to terminate a request/response transaction. 225 If multiple Map-Reply messages are required to respond to a Map- 226 Request message, a Map-Resolver MUST set the M-bit flag for all Map- 227 Reply messages except for the last Map-Reply message. 229 OLD: 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 |Type=2 |P|E|S| Reserved | Record Count | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Nonce . . . | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | . . . Nonce | 238 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | | Record TTL | 240 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 R | Locator Count | EID mask-len | ACT |A| Reserved | 242 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 c | Rsvd | Map-Version Number | EID-Prefix-AFI | 244 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 r | EID-Prefix | 246 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | /| Priority | Weight | M Priority | M Weight | 248 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | o | Unused Flags |L|p|R| Loc-AFI | 250 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | \| Locator | 252 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 NEW: 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 |Type=2 |P|E|S|M| Reserved | Record Count | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Nonce . . . | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | . . . Nonce | 263 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | | Record TTL | 265 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 R | Locator Count | EID mask-len | ACT |A| Reserved | 267 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 c | Rsvd | Map-Version Number | EID-Prefix-AFI | 269 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 r | EID-Prefix | 271 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | /| Priority | Weight | M Priority | M Weight | 273 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | o | Unused Flags |L|p|R| Loc-AFI | 275 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | \| Locator | 277 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 In order to prevent reordering issues that would lead to drop 280 incoming Map-Reply messages, a more reliable solution is defined in 281 Section 3. 283 3. Bulk Mapping Retrieval 285 To allow for a more reliable method when retrieving multiple EID 286 mapping records from one or multiple Map-Resolvers, this section 287 defines additional LISP messages that are, unlike LISP control 288 messages, transported over TCP. 290 After establishing a TCP connection towards a Map-Resolver (using the 291 LISP service port), the ITR sends a Map-Bulk-Request (Section 3.1). 292 Upon receipt of that message, the Map-Resolver must reply with one or 293 more Map-Bulk-Reply messages (Section 3.2). Once the last Map-Bulk- 294 Reply is received from the Map-Resolver, the underlying TCP 295 connection may be closed. 297 Figure 2 illustrates the example of a bulk mapping retrieval that is 298 achieved with one single Map-Bulk-Reply, while Figure 3 shows an 299 example of a bulk mapping retrieval that requires multiple Map-Bulk- 300 Reply messages. 302 +--------+ +--------+ 303 | ITR | | MR | 304 +--------+ +--------+ 305 |<- Session Establishment--->| 306 | | 307 |Map-Bulk-Request (ID, d_EID | 308 | d_EID2, ..., d_EIDn) | 309 |--------------------------->| 310 | Map-Bulk-Reply(M=0) | 311 |<---------------------------| 313 Figure 2: Example of Bulk Mapping Retrieval 314 +--------+ +--------+ 315 | ITR | | MR | 316 +--------+ +--------+ 317 |<- Session Establishment -->| 318 | | 319 |Map-Bulk-Request (ID, d_EID | 320 | d_EID2, ..., d_EIDn) | 321 |--------------------------->| 322 |Map-Bulk-Reply(M=1, rec1, | 323 | rec2, ..., recn)| 324 |<---------------------------| 325 |Map-Bulk-Reply(M=1,recn+1 | 326 | recn+2, ..., recm)| 327 |<---------------------------| 328 ... 329 |Map-Bulk-Reply(M=0, recs) | 330 |<---------------------------| 332 Figure 3: Example of Bulk Mapping Retrieval 334 The bulk mapping retrieval allows to retrieve records that do not 335 only match IP prefixes, but also AS numbers or even names. When 336 names or AS numbers are included, the Map-Resolver is responsible for 337 identifying which IP prefixes are to be returned. 339 An ITR can establish multiple transactions with the same Map-Resolver 340 as shown in Figure 4. 342 +--------+ +--------+ 343 | ITR | | MR | 344 +--------+ +--------+ 345 |<- Session Establishment -->| 346 | | 347 |Map-Bulk-Request (ID1) | 348 |--------------------------->| 349 | Map-Bulk-Reply(ID1) | 350 |<---------------------------| 351 ... 352 |Map-Bulk-Request (ID2) | 353 |--------------------------->| 354 | Map-Bulk-Reply(ID2) | 355 |<---------------------------| 356 | Map-Bulk-Reply(ID2) | 357 |<---------------------------| 358 ... 359 |Map-Bulk-Request (IDa) | 360 |--------------------------->| 361 |Map-Bulk-Request (IDb) | 362 |--------------------------->| 363 | Map-Bulk-Reply(IDa) | 364 |<---------------------------| 365 | Map-Bulk-Reply(IDb) | 366 |<---------------------------| 367 | Map-Bulk-Reply(IDb) | 368 |<---------------------------| 369 | Map-Bulk-Reply(IDa) | 370 |<---------------------------| 372 Figure 4: Multiple Transactions with the Same Map-Resolver 374 3.1. Map-Bulk-Request Message Format 376 The format of the Map-Bulk-Request message is shown in Figure 5. 378 0 1 2 3 379 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 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 |Type=15| Sub-type |R| Reserved | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Transaction ID | 384 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | | Length | | 386 F +-+-+-+-+-+-+-+-+ : 387 I : Filter : 388 L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 T ... 390 E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 R | Length | | 392 S +-+-+-+-+-+-+-+-+ : 393 | : Filter : 394 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 Figure 5: Map-Bulk-Request Message Format 398 The description of the fields is as follows: 400 o Type: MUST be set to 15(see [RFC8113]). 402 o Sub-type: MUST be set to 1025. 404 o R bit: MUST be set to 0 for Map-Bulk-Request messages. 406 o Reserved: reserved bits, MUST be sent as zeros and MUST be ignored 407 when received. 409 o Transaction ID: This field is used to uniquely identify a 410 connection context among those established with the same Map- 411 Resolver. Demux connections established with distinct Map- 412 Resolvers may rely on the address of the Map-Resolver. A 413 transaction-id MUST be unique for connections bound to the same 414 Map-Resolver. 416 o Length: This field indicates, in octets, the length of the filter 417 that is encoded in the "Filter" field. 419 o Filter: This field carries a destination EID (or a set thereof) 420 that is encoded as an UTF-8 string. This specification allows to 421 convey IP prefix literals, Names and/or AS numbers. One or 422 multiple filters may be present in a request. IPv4 prefixes are 423 encoded as IPv4-mapped IPv6 prefixes [RFC4291] (i.e., starting 424 with ::ffff:0:0/96). A mix of names, IP prefixes and AS numbers 425 may be enclosed in the same request. The value 0 is used to 426 indicate "ANY" mapping. 428 3.2. Map-Bulk-Response Message Format 430 The format of the Map-Bulk-Reply message is shown in Figure 6. 432 0 1 2 3 433 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 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 |Type=15| Sub-type |R|M|rsv| Records Count |Results| 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Transaction ID | 438 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | | Code | Length | | 440 F +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 441 I : Filter : 442 L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 T ... 444 E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 R | Code | Length | | 446 S +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 447 | : Filter : 448 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | | Record TTL | 450 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 R | Locator Count | EID mask-len | ACT |A| Reserved | 452 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 c | Rsvd | Map-Version Number | EID-Prefix-AFI | 454 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 r | EID-Prefix | 456 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | /| Priority | Weight | M Priority | M Weight | 458 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | o | Unused Flags |L|p|R| Loc-AFI | 460 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | \| Locator | 462 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 ... 464 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | | Record TTL | 466 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 R | Locator Count | EID mask-len | ACT |A| Reserved | 468 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 c | Rsvd | Map-Version Number | EID-Prefix-AFI | 470 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 r | EID-Prefix | 472 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | /| Priority | Weight | M Priority | M Weight | 474 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | o | Unused Flags |L|p|R| Loc-AFI | 476 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | \| Locator | 478 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 Figure 6: Map-Bulk-Reply Message Format 482 The description of the fields of the Map-Bulk-Reply is similar to 483 those of a LISP Map-Request message ([RFC6830]), except the 484 following: 486 o Type is to be defined. The same code is used for both Map-Bulk- 487 Request and Map-Bulk-Reply. 489 o R bit: MUST be set to 1 for Map-Bulk-Reply messages. 491 o M (more-data bit): When set, this flag indicates that other 492 records are to be expected from the Map-Resolver. 494 o rsv: reserved bits, MUST be sent as zeros and MUST be ignored when 495 received. 497 o Records Count: Indicates the number of records included in the 498 response. 500 o Result: indicates the result code of the processing of the Map- 501 Bulk-Request message. The following codes are defined: 503 0: SUCCESS. This code indicates the request is successfully 504 processed. 506 1: BULK-PROHIBITED. This code indicates the bulk mapping is 507 blocked for this ITR, leaf LISP network, subscriber, etc. 509 2: BULK-LIMIT. This code indicates a rate-limit is applied on the 510 Map-Bulk-Request messages from the same ITR, leaf LISP network, 511 subscriber, etc. The ITR SHOULD re-issue the request after the 512 expiry of a timer; the default value of that timer is 60 513 seconds. Other values may be configured on the ITR. 515 3: OUT-OF-RESOURCES. This code indicates a Map-Resolver is 516 running out of resources. The ITR SHOULD re-iterate the same 517 request after the expiry of a timer. The default value of that 518 timer is 300 seconds. Other values MAY be configured on the 519 ITR. 521 o Filter Count: 523 o Transaction ID: MUST echo the one included in the Map-Bulk- 524 Request. 526 o Code: Filters that were not processed by the Map-Resolver are 527 included. A filter MUST be included in a response if and only if 528 an error was encountered when processing that filter at the Map- 529 Resolver side. The code field provides more details about the 530 reason for not processing such filter. If all filters were 531 successfully processed by the Map-Resolver, this field MUST be set 532 to 0. The following values are defined: 534 0: FILTER-UNSUPPORTED. This code indicates a request is 535 successfully processed but this filter was not processed 536 because the format of the filter is not supported. 538 1: FILTER-BAD. This code indicates a request is successfully 539 processed but the filter was not processed because it is 540 malformed. 542 2: FILTER-MAX. This code indicates a request is successfully 543 processed but the filter was not processed because of a limit 544 enforced on the maximum number of filters to be processed. 546 3: FILTER-LOCAL. This code indicates a request is successfully 547 processed but the filter was not processed because of local 548 reasons. The ITR SHOULD, after a certain timer expires, send a 549 Map-Bulk-Request message for the set of filters that are not 550 processed with a reason code set to BULK-LOCAL. 552 o Length: Indicates the length of a filter this is not processed by 553 the Map-Resolver. 555 o Filter: Conveys a filter that is not processed by the Map- 556 Resolver. 558 3.3. Generating a Map-Bulk-Request Message 560 ITRs MUST support a configurable parameter to enable/disable bulk 561 mapping retrieval over TCP. The default value is set to "enabled". 563 If distinct port number is used by remote Map-Resolvers, the 564 destination port number to send Map-Bulk-Request messages SHOULD be 565 configured to the ITR. 567 After establishing a TCP connection towards a Map-Resolver (using the 568 LISP service port), the ITR MUST send a Map-Bulk-Request 569 (Section 3.1) to a Map-Resolver. Configuration information for 570 triggering bulk retrieval request messages MAY be provisioned to each 571 ITR. Multiple Map-Bulk-Request messages may be sent over the same 572 TCP connection. 574 An ITR that loses its mapping cache for some reason SHOULD generate a 575 Map-Bulk-Request message towards its Map-Resolver(s) with the set of 576 filters that are configured locally. 578 An ITR MAY generate several Map-Bulk-Request messages to the same or 579 distinct Map-Resolvers. 581 An ITR MUST generate a unique transaction-id per Map-Bulk-Request it 582 issues. 584 An ITR MUST expect that the Map-Resolver may limit the number of 585 filters that may be processed. Filters that are not accepted or not 586 processed by the Map-Resolvers are included in a Map-Bulk-Reply. 588 3.4. Processing a Map-Bulk-Request Message 590 A Map-Resolver that does not support the Map-Bulk-Request message 591 MUST silently ignore any Map-Bulk-Request message it receives. 593 Map-Resolvers MUST support a configurable parameter to enable/disable 594 the processing of Map-Bulk-Request messages. The default value is 595 set to "enabled". 597 A Map-Resolver that is enabled to process Map-Bulk-Request messages 598 MUST listen to incoming TCP connections on the default LISP service 599 port. ACLs MAY be configured to control the leaf networks that can 600 invoke this feature. 602 A Map-Resolver SHOULD support a configuration parameter to rate-limit 603 the number of simultaneous Map-Bulk-Request messages per leaf LISP 604 network, per ITR, etc. 606 If a Map-Resolver receives a Map-Bulk-Request message and it is 607 enabled to process it, a Map-Resolver MUST reply with one or multiple 608 Map-Bulk-Reply messages. 610 If multiple Map-Bulk-Reply messages are required to respond to a 611 given request, the Map-Resolver MUST: 613 o Echo the transaction-id. 615 o Set to R-bit. 617 o Set the M-bit for all Map-Bulk-Reply messages, except for the last 618 one. 620 o Include the set of filters that are not successfully processed for 621 some reason (e.g., malformed filter) and set the "Filter Count" 622 accordingly. 624 If filters are included in the request, the Map-Resolver MUST extract 625 those filters and lookup its mapping system accordingly. In 626 particular, the Map-Resolver MUST reply with a full mapping table if 627 a Null filter is included in the Map-Bulk-Request. 629 If bulk mapping retrieval is not allowed for a given ITR, the 630 'Result' field MUST be set to BULK-PROHIBITED. 632 If the Map-Resolver fails to process a request because limits for 633 that ITR are exceeded, it MUST set the 'Result' field to BULK-LIMIT. 635 If a subset of filters are successfully processed, the 'Result' field 636 MUST be set to SUCCESS. The set of filters that are not processed 637 MUST be echoed in the Map-Bulk-Reply; each with a failure code that 638 reflects the reason why the filter was not applied. If a filter type 639 is not supported by the Map-Resolver, the 'Code' field MUST be set to 640 FILTER-UNSUPPORTED. If the Map-Resolver fails to process some of the 641 filters included in a request because these filters were malformed, 642 it MUST echo the corresponding filters in the Map-Bulk-Reply message 643 and MUST set the 'Code' field to FILTER-BAD. f the Map-Resolver fails 644 to process some of the filters included in a request because a 645 maximum number of filters is supported, it MUST echo the 646 corresponding filters in the Map-Bulk-Reply message and set the 647 'Code' field to FILTER-MAX. If, for some other reasons, the Map- 648 Resolver fails to apply some filters included in a request, it MUST 649 echo the corresponding filter in the Map-Bulk-Reply message. The 650 'Code' field MUST be set to FILTER-LOCAL. 652 A Map-Resolver that is overloaded MUST reply with a Map-Bulk-Reply 653 message with the "Result" code set to OUT-OF-RESOURCES. 655 3.5. Processing a Map-Bulk-Reply Message 657 Upon receipt of a Map-Bulk-Reply message, the ITR MUST check whether 658 the message matches a Map-Bulk-Request it issued for the same Map- 659 Resolver. If no matching state is found, the message MUST be 660 silently dropped. If a state is found, the ITR MUST proceed as 661 follows: 663 o An ITR that receives the result code set to BULK-PROHIBITED MUST 664 NOT reissue a Map-Bulk-Request message to that Map-Resolver. 666 o An ITR that receives the result code set to BULK-LIMIT MUST NOT 667 try to resend the same request before the expiry of the 668 retransmission timeout (default value set to 60 seconds). 670 o An ITR that receives the result code set to OUT-OF-RESOURCES MUST 671 NOT resend the same request before 300 seconds. 673 o If the M-bit is set, it should expect that other Map-Bulk-Reply 674 messages will be received from this Map-Resolver. Appropriate 675 security mechanisms (e.g., Access Control Lists) SHOULD be 676 activated to allow the processing of these incoming unsolicited 677 Map-Bulk-Reply messages. 679 o If the M-bit is unset, this is an indication that this message 680 terminates the mapping bulk retrieval transaction. The ITR may 681 decide to terminate the underlying TCP connections if no other 682 transactions bound to the same Map-Resolver are active. 684 o Filters that are returned in the Map-Bulk-Reply message may not be 685 valid or have exceeded a limit. The "Code" field indicates the 686 reason for not processing these filters. In particular: 688 * An ITR that receives the 'Code' field set to FILTER-BAD or 689 FILTER-UNSUPPORTED MUST NOT resend the same filters that were 690 returned in the Map-Bulk-Reply message, in subsequent Map-Bulk- 691 Request messages. Furthermore, subsequent Map-Bulk-Request 692 messages MUST NOT use the unsupported format to encode the 693 filters. 695 * An ITR that receives the 'Code' field set to FILTER-MAX SHOULD 696 issue another Map-Bulk-Request message with the filters that 697 were returned in the Map-Bulk-Reply message with this code. 699 * An ITR that receives the 'Code' field set to FILTER-LOCAL 700 SHOULD for at least 60 seconds before issuing another Map-Bulk- 701 Request message with the filters that were returned in the Map- 702 Bulk-Reply message with this code. 704 3.6. Bulk Mapping Retrival from Multiple Resolvers 706 In order to retrieve mapping entries from multiple Map-Resolvers, an 707 ITR issues Map-Bulk-Request messages to a list of Map-Resolvers. 708 Each of these requests is handled as specified in Section 3.3. 710 An ITR MAY be configured to issue multiple Map-Bulk-Request messages 711 to distinct Map-Resolvers. 713 Conflicts may arise when contacting multiple Map-Resolvers. These 714 conflicts are not specific to the bulk mapping retrieval as this is 715 also an issue for individual mapping lookup. 717 4. Security Considerations 719 In addition to the security considerations discussed in [RFC6830] and 720 [RFC6833], TCP-specific threats are valid for this specification 721 (e.g., [I-D.ietf-tcpm-tcp-security]). 723 In order to avoid exhausting the resources of Map-Resolvers, Map- 724 Bulk-Request messages SHOULD be rate-limited. Furthermore, a Map- 725 Resolver MAY configure ACLs to control leaf LISP networks that are 726 allowed to issue Map-Bulk-Request messages. 728 The structure of a record conveyed in a Map-Bulk-Reply is exactly the 729 same as in [RFC6830]. As such, this specification does leak 730 information that would not be revealed using the base LISP. 732 5. IANA Considerations 734 This document requests IANA to assign a new code from the LISP Shared 735 Extension Message Type Sub-types ([RFC8113]): 737 Message Sub-type Reference 738 ================================= ======= =============== 739 Map-Bulk-Request/Map-Bulk-Reply 1025 [This document] 741 6. Acknowledgments 743 This work is partly funded by ANR LISP-Lab project #ANR-13-INFR- 744 009-X. 746 Many thanks to S. Secci and Chi Dung Phung for the comments. 748 7. References 750 7.1. Normative references 752 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 753 RFC 793, DOI 10.17487/RFC0793, September 1981, 754 . 756 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 757 Requirement Levels", BCP 14, RFC 2119, 758 DOI 10.17487/RFC2119, March 1997, 759 . 761 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 762 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 763 2006, . 765 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 766 Locator/ID Separation Protocol (LISP)", RFC 6830, 767 DOI 10.17487/RFC6830, January 2013, 768 . 770 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 771 Protocol (LISP) Map-Server Interface", RFC 6833, 772 DOI 10.17487/RFC6833, January 2013, 773 . 775 [RFC8113] Boucadair, M. and C. Jacquenet, "Locator/ID Separation 776 Protocol (LISP): Shared Extension Message & IANA Registry 777 for Packet Type Allocations", RFC 8113, 778 DOI 10.17487/RFC8113, March 2017, 779 . 781 7.2. Informative references 783 [I-D.ietf-tcpm-tcp-security] 784 Gont, F., "Survey of Security Hardening Methods for 785 Transmission Control Protocol (TCP) Implementations", 786 draft-ietf-tcpm-tcp-security-03 (work in progress), March 787 2012. 789 [I-D.kouvelas-lisp-map-server-reliable-transport] 790 Cassar, C., Kouvelas, I., Lewis, D., Arango, J., and J. 791 Leong, "LISP Map Server Reliable Transport", draft- 792 kouvelas-lisp-map-server-reliable-transport-03 (work in 793 progress), March 2017. 795 Authors' Addresses 797 Mohamed Boucadair 798 Orange 799 Rennes 35000 800 France 802 EMail: mohamed.boucadair@orange.com 803 Christian Jacquenet 804 Orange 805 Rennes 35000 806 France 808 EMail: christian.jacquenet@orange.com