idnits 2.17.1 draft-boucadair-lisp-bulk-00.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 (September 15, 2015) is 3144 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) ** Obsolete normative reference: RFC 6833 (Obsoleted by RFC 9301) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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) France Telecom 5 Intended status: Experimental September 15, 2015 6 Expires: March 18, 2016 8 LISP Mapping Bulk Retrieval 9 draft-boucadair-lisp-bulk-00.txt 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 March 18, 2016. 45 Copyright Notice 47 Copyright (c) 2015 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-Response Message . . . . . . . . . 15 70 3.6. Bulk Mapping Retrival from Multiple Resolvers . . . . . . 16 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 73 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 7.1. Normative references . . . . . . . . . . . . . . . . . . 17 76 7.2. Informative references . . . . . . . . . . . . . . . . . 17 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 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). 109 This document allows to request mappings that match destination IP 110 prefixes, names, or AS numbers. Other filter types may be defined in 111 future versions, if needed. 113 2. Map-Request with Multiple Records 115 As mentioned in Section 1, [RFC6830] does not specify how an ITR can 116 request for multiple EIDs using the same Map-Request message. This 117 document fills that void. 119 Figure 1 shows the difference between the current Map-Request message 120 format and the new format that includes the proposed extension. This 121 extension is meant to allow an ITR to request multiple EID records by 122 using the same Map-Request. 124 The proposed design is backward compatible since it aligns the 125 additional requested EID records at the end of the Map-Request 126 message. 128 As specified in [RFC6830], a mapping system must be prepared to 129 receive a request for multiple EID records in a Map-Request message. 130 A receiver relies upon the content of the "Record Count" field of the 131 Map-Request message to detect whether one or multiple records are 132 carried in the request. 134 OLD: 135 0 1 2 3 136 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 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 |Type=1 |A|M|P|S|p|s| Reserved | IRC | Record Count | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Nonce . . . | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | . . . Nonce | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Source-EID-AFI | Source EID Address ... | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | ... | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | ITR-RLOC-AFI n | ITR-RLOC Address n ... | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 / | Reserved | EID mask-len | EID-Prefix-AFI | 153 Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 \ | EID-Prefix ... | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Map-Reply Record ... | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 NEW: 160 0 1 2 3 161 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 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 |Type=1 |A|M|P|S|p|s| Reserved | IRC | Record Count | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Nonce . . . | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | . . . Nonce | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Source-EID-AFI | Source EID Address ... | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | ... | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | ITR-RLOC-AFI n | ITR-RLOC Address n ... | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 / |N| Reserved | EID mask-len | EID-Prefix-AFI | 178 Rec 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 \ | EID-Prefix ... | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Map-Reply Record ... | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 / |N| Reserved | EID mask-len | EID-Prefix-AFI | 184 Rec 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 \ | EID-Prefix ... | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 : ... : 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 / |N| Reserved | EID mask-len | EID-Prefix-AFI | 191 Rec m +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 \ | EID-Prefix ... | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 Figure 1 197 The description of the fields of the updated Map-Request message is 198 exactly the same as in [RFC6830], except the additional records that 199 are prepended after the "Map-Reply Record" and the definition of a 200 reserved bit, denoted as the N-bit (next-eid record bit). The 201 structure of a record is exactly the same as in [RFC6830]. 203 When set, the N-bit (next-eid record bit) flag indicates that this is 204 not the last record carried in the message. An implementation uses 205 the value of this bit to position the last record in the message. 207 When extracting the records included in a Map-Request message, a Map- 208 Resolver replies with the list of mappings that match these records. 209 One or multiple Map-Reply messages may be required to carry the 210 mapping records that match the requested EIDs included in a Map- 211 Request. 213 An ITR MUST be prepared to receive multiple Map-Reply messages from a 214 Map-Resolver as a response to a bulk Map-Request message that it 215 originally sent to that Map-Resolver. 217 In order to inform an ITR that subsequent Map-Reply messages will 218 follow (or not) , a dedicated flag bit is defined for this purpose: 219 it is called the M-bit (more-map-reply bit). 221 When set, the M-bit (more-map-reply bit) flag indicates this is not 222 the last Map-Reply message to be received by the requesting ITR; 223 additional Map-Reply messages follow. An implementation uses this 224 bit to decide when to terminate a request/response transaction. 226 If multiple Map-Reply messages are required to respond to a Map- 227 Request message, a Map-Resolver MUST set the M-bit flag for all Map- 228 Reply messages except for the last Map-Reply message. 230 OLD: 231 0 1 2 3 232 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 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 |Type=2 |P|E|S| Reserved | Record Count | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Nonce . . . | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | . . . Nonce | 239 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | | Record TTL | 241 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 R | Locator Count | EID mask-len | ACT |A| Reserved | 243 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 c | Rsvd | Map-Version Number | EID-Prefix-AFI | 245 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 r | EID-Prefix | 247 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | /| Priority | Weight | M Priority | M Weight | 249 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | o | Unused Flags |L|p|R| Loc-AFI | 251 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | \| Locator | 253 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 NEW: 256 0 1 2 3 257 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 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 |Type=2 |P|E|S|M| Reserved | Record Count | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Nonce . . . | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | . . . Nonce | 264 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | | Record TTL | 266 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 R | Locator Count | EID mask-len | ACT |A| Reserved | 268 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 c | Rsvd | Map-Version Number | EID-Prefix-AFI | 270 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 r | EID-Prefix | 272 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | /| Priority | Weight | M Priority | M Weight | 274 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | o | Unused Flags |L|p|R| Loc-AFI | 276 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | \| Locator | 278 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 In order to prevent reordering issues that would lead to drop 281 incoming Map-Reply messages, a more reliable solution is defined in 282 Section 3. 284 3. Bulk Mapping Retrieval 286 To allow for a more reliable method when retrieving multiple EID 287 mapping records from one or multiple Map-Resolvers, this section 288 defines additional LISP messages that are, unlike LISP control 289 messages, transported over TCP. 291 After establishing a TCP connection towards a Map-Resolver (using the 292 LISP service port), the ITR sends a Map-Bulk-Request (Section 3.1). 293 Upon receipt of that message, the Map-Resolver must reply with one or 294 more Map-Bulk-Response messages (Section 3.2). Once the last Map- 295 Bulk-Response is received from the Map-Resolver, the underlying TCP 296 connection may be closed. 298 Figure 2 illustrates the example of a bulk mapping retrieval that is 299 achieved with one single Map-Bulk-Response, while Figure 3 shows an 300 example of a bulk mapping retrieval that requires multiple Map-Bulk- 301 Response messages. 303 +--------+ +--------+ 304 | ITR | | MR | 305 +--------+ +--------+ 306 |<- Session Establishment--->| 307 | | 308 |Map-Bulk-Request (ID, d_EID | 309 | d_EID2, ..., d_EIDn) | 310 |--------------------------->| 311 | Map-Bulk-Response(M=0)| 312 |<---------------------------| 314 Figure 2: Example of Bulk Mapping Retrieval 315 +--------+ +--------+ 316 | ITR | | MR | 317 +--------+ +--------+ 318 |<- Session Establishment -->| 319 | | 320 |Map-Bulk-Request (ID, d_EID | 321 | d_EID2, ..., d_EIDn) | 322 |--------------------------->| 323 |Map-Bulk-Response(M=1, rec1,| 324 | rec2, ..., recn)| 325 |<---------------------------| 326 |Map-Bulk-Response(M=1,recn+1| 327 | recn+2, ..., recm)| 328 |<---------------------------| 329 ... 330 |Map-Bulk-Response(M=0, recs)| 331 |<---------------------------| 333 Figure 3: Example of Bulk Mapping Retrieval 335 The bulk mapping retrieval allows to retrieve records that do not 336 only match IP prefixes, but also AS numbers or even names. When 337 names or AS numbers are included, the Map-Resolver is responsible for 338 identifying which IP prefixes are to be returned. 340 An ITR can establish multiple transactions with the same Map-Resolver 341 as shown in Figure 4. 343 +--------+ +--------+ 344 | ITR | | MR | 345 +--------+ +--------+ 346 |<- Session Establishment -->| 347 | | 348 |Map-Bulk-Request (ID1) | 349 |--------------------------->| 350 | Map-Bulk-Response(ID1)| 351 |<---------------------------| 352 ... 353 |Map-Bulk-Request (ID2) | 354 |--------------------------->| 355 | Map-Bulk-Response(ID2)| 356 |<---------------------------| 357 | Map-Bulk-Response(ID2)| 358 |<---------------------------| 359 ... 360 |Map-Bulk-Request (IDa) | 361 |--------------------------->| 362 |Map-Bulk-Request (IDb) | 363 |--------------------------->| 364 | Map-Bulk-Response(IDa)| 365 |<---------------------------| 366 | Map-Bulk-Response(IDb)| 367 |<---------------------------| 368 | Map-Bulk-Response(IDb)| 369 |<---------------------------| 370 | Map-Bulk-Response(IDa)| 371 |<---------------------------| 373 Figure 4: Multiple Transactions with the Same Map-Resolver 375 3.1. Map-Bulk-Request Message Format 377 The format of the Map-Bulk-Request message is shown in Figure 5. 379 0 1 2 3 380 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 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Type | Reserved | Filter Len | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Transaction ID | 385 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | | Length | | 387 F +-+-+-+-+-+-+-+-+ : 388 I : Filter : 389 L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 T ... 391 E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 R | Length | | 393 S +-+-+-+-+-+-+-+-+ : 394 | : Filter : 395 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 Figure 5: Map-Bulk-Request Message Format 399 The description of the fields is as follows: 401 o Type is to be defined (see Section 5). 403 o Reserved: reserved bits, MUST be sent as zeros and MUST be ignored 404 when received. Some of these bits may be used to indicate the 405 type of the enclosed filter (e.g., lookup to retrieve all EIDs 406 serviced by an ETR). 408 o Filter Len: This field indicates in bytes, the length of the 409 filters included in the request. It is equal to (sum of "8+Length 410 of Filter"), where "Filter" denotes the filters included in the 411 message. 413 o Transaction ID: This field is used to uniquely identify a 414 connection context among those established with the same Map- 415 Resolver. Demux connections established with distinct Map- 416 Resolvers may rely on the address of the Map-Resolver. A 417 transaction-id MUST be unique for connections bound to the same 418 Map-Resolver. 420 o Length: This field indicates, in octets, the length of the filter 421 that is encoded in the "Filter" field. 423 o Filter: This field carries a destination EID (or a set thereof) 424 that is encoded as an UTF-8 string. This specification allows to 425 convey IP prefix literals, Names and/or AS numbers. One or 426 multiple filters may be present in a request. IPv4 prefixes are 427 encoded as IPv4-mapped IPv6 prefixes [RFC4291] (i.e., starting 428 with ::ffff:0:0/96). A mix of names, IP prefixes and AS numbers 429 may be enclosed in the same request. The value 0 is used to 430 indicate "ANY" mapping. 432 3.2. Map-Bulk-Response Message Format 434 The format of the Map-Bulk-Response message is shown in Figure 6. 436 0 1 2 3 437 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 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Type |M| rsv | Records Count |Results | Filter Len | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Transaction ID | 442 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | | Length | | 444 F +-+-+-+-+-+-+-+-+ : 445 I : Filter : 446 L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 T ... 448 E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 R | Length | | 450 S +-+-+-+-+-+-+-+-+ : 451 | : Filter : 452 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | | Record TTL | 454 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 R | Locator Count | EID mask-len | ACT |A| Reserved | 456 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 c | Rsvd | Map-Version Number | EID-Prefix-AFI | 458 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 r | EID-Prefix | 460 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | /| Priority | Weight | M Priority | M Weight | 462 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | o | Unused Flags |L|p|R| Loc-AFI | 464 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | \| Locator | 466 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 ... 468 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | | Record TTL | 470 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 R | Locator Count | EID mask-len | ACT |A| Reserved | 472 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 c | Rsvd | Map-Version Number | EID-Prefix-AFI | 474 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 r | EID-Prefix | 476 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | /| Priority | Weight | M Priority | M Weight | 478 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | o | Unused Flags |L|p|R| Loc-AFI | 480 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | \| Locator | 482 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 Figure 6: Map-Bulk-Response Message Format 486 The description of the fields of the Map-Bulk-Response is similar to 487 those of a LISP Map-Request message ([RFC6830]), except the 488 following: 490 o Type is to be defined (see Section 5). 492 o M (more-data bit): When set, this flag indicates that other 493 records are to be expected from the Map-Resolver. 495 o Reserved: reserved bits, MUST be sent as zeros and MUST be ignored 496 when received. 498 o Records Count: Indicates the number of records included in the 499 response. 501 o Result: indicates the result code of the processing of the Map- 502 Bulk-Request message. The following codes are defined: 504 0: SUCCESS. This code indicates the request is successfully 505 processed. 507 1: BULK-PROHIBITED. This code indicates the bulk mapping is 508 blocked for this ITR, leaf LISP network, subscriber, etc. 510 2: BULK-LIMIT. This code indicates a rate-limit is applied on the 511 Map-Bulk-Request messages from the same ITR, leaf LISP network, 512 subscriber, etc. The ITR SHOULD re-issue the request after the 513 expiry of a timer; the default value of that timer is 60 514 seconds. Other values may be configured on the ITR. 516 3: BULK-FILTER-UNSUPPORTED. This code indicates a request is 517 successfully processed but some or all filters were not 518 processed because the format of these filters is not supported. 520 4: BULK-FILTER-BAD. This code indicates a request is successfully 521 processed but some filters were not processed because they were 522 malformed. 524 5: BULK-LOCAL. This code indicates a request is successfully 525 processed but some filters were not processed because of local 526 reasons. The ITR SHOULD, after a certain timer expires, send a 527 Map-Bulk-Request message for the set of filters that are 528 included in the Map-Bulk-Response message. 530 6: OUT-OF-RESOURCES. This code indicates a Map-Resolver is 531 running out of resources. The ITR SHOULD re-iterate the same 532 request after the expiry of a timer. The default value of that 533 timer is 300 seconds. Other values MAY be configured on the 534 ITR. 536 o Filter Len: This field indicates in bytes, the length of the 537 filters that were not processed by the Map-Resolver. A filter 538 MUST be included in a response if and only if an error was 539 encountered when processing that filter at the Map-Resolver side. 540 The "Result" code provides more details about the reason for not 541 processing such filter. If all filters were successfully 542 processed by the Map-Resolver, this field MUST be set to 0. 544 o Transaction ID: MUST echo the one included in the Map-Bulk- 545 Request. 547 3.3. Generating a Map-Bulk-Request Message 549 ITRs MUST support a configurable parameter to enable/disable bulk 550 mapping retrieval over TCP. The default value is set to "enabled". 552 If distinct port number is used by remote Map-Resolvers, the 553 destination port number to send Map-Bulk-Request messages SHOULD be 554 configured to the ITR. 556 After establishing a TCP connection towards a Map-Resolver (using the 557 LISP service port), the ITR MUST send a Map-Bulk-Request 558 (Section 3.1) to a Map-Resolver. Configuration information for 559 triggering bulk retrieval request messages MAY be provisioned to each 560 ITR. Multiple Map-Bulk-Request messages may be sent over the same 561 TCP connection. 563 An ITR that loses its mapping cache for some reason SHOULD generate a 564 Map-Bulk-Request message towards its Map-Resolver(s) with the set of 565 filters that are configured locally. 567 An ITR MAY generate several Map-Bulk-Request messages to the same or 568 distinct Map-Resolvers. 570 An ITR MUST generate a unique transaction-id per Map-Bulk-Request it 571 issues. 573 An ITR MUST expect that the Map-Resolver may limit the number of 574 filters that may be processed. Filters that are not accepted or not 575 processed by the Map-Resolvers are included in a Map-Bulk-Response. 577 3.4. Processing a Map-Bulk-Request Message 579 A Map-Resolver that does not support the Map-Bulk-Request message 580 MUST silently ignore any Map-Bulk-Request message it receives. 582 Map-Resolvers MUST support a configurable parameter to enable/disable 583 the processing of Map-Bulk-Request messages. The default value is 584 set to "enabled". 586 A Map-Resolver that is enabled to process Map-Bulk-Request messages 587 MUST listen to incoming TCP connections on the default LISP service 588 port. ACLs MAY be configured to control the leaf networks that can 589 invoke this feature. 591 A Map-Resolver SHOULD support a configuration parameter to rate-limit 592 the number of simultaneous Map-Bulk-Request messages per leaf LISP 593 network, per ITR, etc. 595 If a Map-Resolver receives a Map-Bulk-Request message and it is 596 enabled to process it, a Map-Resolver MUST reply with one or multiple 597 Map-Bulk-Response messages. 599 If multiple Map-Bulk-Response messages are required to respond to a 600 given request, the Map-Resolver MUST: 602 o Echo the transaction-id. 604 o Set the M-bit for all Map-Bulk-Response messages, except for the 605 last one. 607 o Include the set of filters that are not successfully processed for 608 some reason (e.g., malformed filter) and set the "Filter Len" 609 accordingly. 611 If filters are included in the request, the Map-Resolver MUST extract 612 those filters and lookup its mapping system accordingly. In 613 particular, the Map-Resolver MUST reply with a full mapping table if 614 a Null filter is included in the Map-Bulk-Request. 616 If bulk mapping retrieval is not allowed for a given ITR, the 617 'Result' field MUST be set to BULK-PROHIBITED. 619 If a filter type is not supported by the Map-Resover, the 'Result' 620 field MUST be set to BULK-FILTER-UNSUPPORTED. The set of filters 621 that are not processed MUST be echoed in the Map-Bulk-Response. 623 If all filters are successfully processed, the 'Result' field MUST be 624 set to SUCCESS. 626 If the Map-Resolver fails to process a request because limits for 627 that ITR are exceeded, it MUST set the 'Result' field to BULK-LIMIT. 629 If the Map-Resolver fails to process some of the filters included in 630 a request because these filters were malformed, it MUST echo the 631 corresponding filters in the Map-Bulk-Response message. The 'Result' 632 field MUST be set to BULK-FILTER-BAD 634 If, for some other reasons, the Map-Resolver fails to apply the 635 filters included in a request, it MUST echo the corresponding filter 636 in the Map-Bulk-Response message. The 'Result' field MUST be set to 637 BULK-LIMIT. 639 A Map-Resolver that is overloaded MUST reply with a Map-Bulk-Response 640 message with the "Result" code set to OUT-OF-RESOURCES. 642 3.5. Processing a Map-Bulk-Response Message 644 Upon receipt of a Map-Bulk-Response message, the ITR MUST check 645 whether the message matches a Map-Bulk-Request it issued for the same 646 Map-Resolver. If no matching state is found, the message MUST be 647 silently dropped. If a state is found, the ITR MUST proceed as 648 follows: 650 o An ITR that receives the result code set to BULK-PROHIBITED MUST 651 NOT reissue a Map-Bulk-Request message to that Map-Resolver. 653 o An ITR that receives the result code set to BULK-LIMIT MUST NOT 654 try to resend the same request before the expiry of the 655 retransmission timeout (default value set to 60 seconds). 657 o An ITR that receives the result code set to OUT-OF-RESOURCES MUST 658 NOT resend the same request before 300 seconds. 660 o If the M-bit is set, it should expect that other Map-Bulk-Response 661 messages will be received from this Map-Resolver. Appropriate 662 security mechanisms (e.g., Access Control Lists) SHOULD be 663 activated to allow the processing of these incoming unsolicited 664 Map-Bulk-Response messages. 666 o If the M-bit is unset, this is an indication that this message 667 terminates the mapping bulk retrieval transaction. The ITR may 668 decide to terminate the underlying TCP connections if no other 669 transactions bound to the same Map-Resolver are active. 671 o Filters that are returned in the Map-Bulk-Response message may not 672 be valid or have exceeded a limit. The "Result" code indicates 673 the reason for not processing these filters. In particular: 675 * An ITR that receives the result code set to BULK-FILTER-BAD or 676 BULK-FILTER-UNSUPPORTED MUST NOT resend the same filters that 677 were returned in the Map-Bulk-Response message, in subsequent 678 Map-Bulk-Request messages. Furthermore, subsequent Map-Bulk- 679 Request messages MUST NOT use the unsupported format to encode 680 the filters. 682 * An ITR that receives the result code set to BULK-LOCAL SHOULD 683 for at least 60 seconds before issuing another Map-Bulk-Request 684 message with the filters that were returned in the Map-Bulk- 685 Response message. 687 3.6. Bulk Mapping Retrival from Multiple Resolvers 689 In order to retrieve mapping entries from multiple Map-Resolvers, an 690 ITR issues Map-Bulk-Request messages to a list of Map-Resolvers. 691 Each of these requests is handled as specified in Section 3.3. 693 An ITR MAY be configured to issue multiple Map-Bulk-Request messages 694 to distinct Map-Resolvers. 696 Conflicts may arise when contacting multiple Map-Resolvers. These 697 conflicts are not specific to the bulk mapping retrieval as this is 698 also an issue for individual mapping lookup. 700 4. Security Considerations 702 In addition to the security considerations discussed in [RFC6830] and 703 [RFC6833], TCP-specific threats are valid for this specification 704 (e.g., [I-D.ietf-tcpm-tcp-security]). 706 In order to avoid exhausting the resources of Map-Resolvers, Map- 707 Bulk-Request messages SHOULD be rate-limited. Furthermore, a Map- 708 Resolver MAY configure ACLs to control leaf LISP networks that are 709 allowed to issue Map-Bulk-Request messages. 711 The structure of a record conveyed in a Map-Bulk-Response is exactly 712 the same as in [RFC6830]. As such, this specification does leak 713 information that would not be revealed using the base LISP. 715 5. IANA Considerations 717 To be completed. 719 6. Acknowledgments 721 This work is partly funded by ANR LISP-Lab project #ANR-13-INFR- 722 009-X. 724 7. References 726 7.1. Normative references 728 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 729 Requirement Levels", BCP 14, RFC 2119, 730 DOI 10.17487/RFC2119, March 1997, 731 . 733 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 734 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 735 2006, . 737 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 738 Locator/ID Separation Protocol (LISP)", RFC 6830, 739 DOI 10.17487/RFC6830, January 2013, 740 . 742 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 743 Protocol (LISP) Map-Server Interface", RFC 6833, 744 DOI 10.17487/RFC6833, January 2013, 745 . 747 7.2. Informative references 749 [I-D.ietf-tcpm-tcp-security] 750 Gont, F., "Survey of Security Hardening Methods for 751 Transmission Control Protocol (TCP) Implementations", 752 draft-ietf-tcpm-tcp-security-03 (work in progress), March 753 2012. 755 Authors' Addresses 757 Mohamed Boucadair 758 France Telecom 759 Rennes 35000 760 France 762 EMail: mohamed.boucadair@orange.com 763 Christian Jacquenet 764 France Telecom 765 Rennes 35000 766 France 768 EMail: christian.jacquenet@orange.com