idnits 2.17.1 draft-ietf-lisp-pubsub-09.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 (June 28, 2021) is 1023 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-38) exists of draft-ietf-lisp-rfc6830bis-36 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-30 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-22 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LISP Working Group A. Rodriguez-Natal 3 Internet-Draft Cisco 4 Intended status: Experimental V. Ermagan 5 Expires: December 30, 2021 Google 6 A. Cabellos 7 UPC/BarcelonaTech 8 S. Barkai 9 Nexar 10 M. Boucadair 11 Orange 12 June 28, 2021 14 Publish/Subscribe Functionality for LISP 15 draft-ietf-lisp-pubsub-09 17 Abstract 19 This document specifies an extension to the Request/Reply based LISP 20 Control Plane to enable Publish/Subscribe (PubSub) operation. 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 December 30, 2021. 39 Copyright Notice 41 Copyright (c) 2021 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 Notation . . . . . . . . . . . . . . . . . . . . 3 58 3. Deployment Assumptions . . . . . . . . . . . . . . . . . . . 3 59 4. Map-Request PubSub Additions . . . . . . . . . . . . . . . . 4 60 5. Mapping Request Subscribe Procedures . . . . . . . . . . . . 5 61 6. Mapping Notification Publish Procedures . . . . . . . . . . . 7 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 7.1. Security Association between ITR and MS . . . . . . . . . 8 64 7.2. DDoS Attack Mitigation . . . . . . . . . . . . . . . . . 9 65 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 66 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 67 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 11. Normative References . . . . . . . . . . . . . . . . . . . . 12 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 71 1. Introduction 73 The Locator/ID Separation Protocol (LISP) [I-D.ietf-lisp-rfc6830bis] 74 [I-D.ietf-lisp-rfc6833bis] splits current IP addresses in two 75 different namespaces, Endpoint Identifiers (EIDs) and Routing 76 Locators (RLOCs). LISP uses a map-and-encap approach that relies on 77 (1) a Mapping System (basically a distributed database) that stores 78 and disseminates EID-RLOC mappings and on (2) LISP tunnel routers 79 (xTRs) that encapsulate and decapsulate data packets based on the 80 content of those mappings. 82 Ingress Tunnel Routers (ITRs) / Re-encapsulating Tunnel Routers 83 (RTRs) / Proxy Ingress Tunnel Routers (PITRs) pull EID-to-RLOC 84 mapping information from the Mapping System by means of an explicit 85 request message. Section 6.1 of [I-D.ietf-lisp-rfc6833bis] indicates 86 how Egress Tunnel Routers (ETRs) can tell ITRs/RTRs/PITRs about 87 mapping changes. This document presents a Publish/Subscribe (PubSub) 88 extension in which the Mapping System can notify ITRs/RTRs/PITRs 89 about mapping changes. When this mechanism is used, mapping changes 90 can be notified faster and can be managed in the Mapping System 91 versus the LISP sites. 93 In general, when an ITR/RTR/PITR wants to be notified for mapping 94 changes for a given EID-prefix, the following steps occur: 96 (1) The ITR/RTR/PITR sends a Map-Request for that EID-prefix. 98 (2) The ITR/RTR/PITR sets the Notification-Requested bit (N-bit) on 99 the Map-Request and includes its xTR-ID and Site-ID. 101 (3) The Map-Request is forwarded to one of the Map-Servers that the 102 EID-prefix is registered to. 104 (4) The Map-Server creates subscription state for the ITR/RTR/PITR 105 on the EID-prefix. 107 (5) The Map-Server sends a Map-Notify to the ITR/RTR/PITR to 108 acknowledge the successful subscription. 110 (6) When there is a change in the mapping of the EID-Prefix, the 111 Map-Server sends a Map-Notify message to each ITR/RTR/PITR in 112 the subscription list. 114 (7) Each ITR/RTR/PITR sends a Map-Notify-Ack to acknowledge the 115 received Map-Notify. 117 This operation is repeated for all EID-prefixes for which ITR/RTR/ 118 PITR want to be notified. The ITR/RTR/PITR can set the N-bit for 119 several EID-prefixes within a single Map-Request. 121 2. Requirements Notation 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in BCP 126 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 3. Deployment Assumptions 131 The specification described in this document makes the following 132 deployment assumptions: 134 (1) A unique 128-bit xTR-ID (plus a 64-bit Site-ID) identifier is 135 assigned to each xTR. 137 (2) Map-Servers are configured in proxy-reply mode, i.e., they are 138 solicited to generate and send Map-Reply messages for the 139 mappings they are serving. 141 The distribution of xTR-IDs (and Site-IDs) are out of the scope of 142 this document. 144 4. Map-Request PubSub Additions 146 Figure 1 shows the format of the updated Map-Request to support the 147 PubSub functionality. 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 |Type=1 |A|M|P|S|p|s|R|I| Rsvd |L|D| IRC | Record Count | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Nonce . . . | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | . . . Nonce | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Source-EID-AFI | Source EID Address ... | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | ... | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | ITR-RLOC-AFI n | ITR-RLOC Address n ... | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 / |N| Reserved | EID mask-len | EID-Prefix-AFI | 167 Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 \ | EID-Prefix ... | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Map-Reply Record ... | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | | 173 + + 174 | | 175 + xTR-ID + 176 | | 177 + + 178 | | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | | 181 + Site-ID + 182 | | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 Figure 1: Map-Request with I-bit, N-bit, xTR-ID, and Site-ID 187 The following is added to the Map-Request message defined in 188 Section 5.2 of [I-D.ietf-lisp-rfc6833bis]: 190 xTR-ID bit (I-bit): This bit is set to 1 to indicate that a 128 191 bit xTR-ID and a 64 bit Site-ID fields are present at the end of 192 the Map-Request message. For PubSub operation, an xTR MUST be 193 configured with an xTR-ID and Site-ID, and it MUST set the I bit 194 to 1 and include its xTR-ID and Site-ID in the Map-Request 195 messages it generates. 197 Notification-Requested bit (N-bit): The N-bit of an EID-record is 198 set to 1 to specify that the xTR wants to be notified of updates 199 for that mapping record. 201 xTR-ID field: xTR-ID is a 128 bit field at the end of the Map- 202 Request message, starting after the final Record in the message 203 (or the Map-Reply Record, if present). The xTR-ID is used to 204 uniquely identify the sender of a Map-Request message. The xTR-ID 205 is defined in Section 5.6 of [I-D.ietf-lisp-rfc6833bis] 207 Site-ID field: Site-ID is a 64 bit field at the end of the Map- 208 Request message, following the xTR-ID. Site-ID is used by the 209 Map-Server receiving the Map-Request message to identify which 210 xTRs belong to the same site. The Site-ID is defined in 211 Section 5.6 of [I-D.ietf-lisp-rfc6833bis] 213 5. Mapping Request Subscribe Procedures 215 The xTR subscribes for changes for a given EID-prefix by sending a 216 Map-Request to the Mapping System with the N-bit set on the EID- 217 Record. The xTR builds a Map-Request according to Section 5.3 of 218 [I-D.ietf-lisp-rfc6833bis] but also does the following: 220 (1) The xTR MUST set the I-bit to 1 and append its xTR-ID and Site- 221 ID to the Map-Request. The xTR-ID uniquely identifies the xTR. 223 (2) The xTR MUST set the N-bit to 1 for each EID-Record to which the 224 xTR wants to subscribe. 226 The Map-Request is forwarded to the appropriate Map-Server through 227 the Mapping System. This document does not assume that a Map-Server 228 is pre-assigned to handle the subscription state for a given xTR. 229 The Map-Server that receives the Map-Request will be the Map-Server 230 responsible to notify that specific xTR about future mapping changes 231 for the subscribed mapping records. 233 Upon receipt of the Map-Request, the Map-Server processes it as 234 described in Section 8.3 of [I-D.ietf-lisp-rfc6833bis]. Furthermore, 235 upon processing, for each EID-Record that has the N-bit set to 1, the 236 Map-Server proceeds to add the xTR-ID contained in the Map-Request to 237 the list of xTRs that have requested to be subscribed to that mapping 238 record. 240 If the xTR-ID is added to the list, the Map-Server MUST send a Map- 241 Notify message back to the xTR to acknowledge the successful 242 subscription. The Map-Server MUST follow the specification in 243 Section 5.7 of [I-D.ietf-lisp-rfc6833bis] to build the Map-Notify 244 with the following considerations: 246 (1) The Map-Server MUST use the nonce from the Map-Request as the 247 nonce for the Map-Notify. 249 (2) The Map-Server MUST use its security association with the xTR 250 (see Section 7.1) to compute the authentication data of the Map- 251 Notify. 253 (3) The Map-Server MUST send the Map-Notify to one of the ITR-RLOCs 254 received in the Map-Request (which one is implementation 255 specific). 257 When the xTR receives a Map-Notify with a nonce that matches one in 258 the list of outstanding Map-Request messages sent with an N-bit set, 259 it knows that the Map-Notify is to acknowledge a successful 260 subscription. The xTR processes this Map-Notify as described in 261 Section 5.7 of [I-D.ietf-lisp-rfc6833bis] with the following 262 considerations. The xTR MUST use its security association with the 263 Map-Server (see Section 7.1) to validate the authentication data on 264 the Map-Notify. The xTR MUST use the Map-Notify to populate its map- 265 cache with the returned EID-prefix and RLOC-set. 267 The subscription of an xTR-ID to the list of subscribers for the EID- 268 Record may fail for a number of reasons. For example, because of 269 local configuration policies (such as accept and drop lists of 270 subscribers), or because the Map-Server has exhausted the resources 271 to dedicate to the subscription of that EID-Record (e.g., the number 272 of subscribers excess the capacity of the Map-Server). 274 If the subscription fails, the Map-Server MUST send a Map-Reply to 275 the originator of the Map-Request, as described in Section 8.3 of 276 [I-D.ietf-lisp-rfc6833bis]. The xTR processes the Map-Reply as 277 specified in Section 8.1 of [I-D.ietf-lisp-rfc6833bis]. 279 If an xTR-ID is successfully added to the list of subscribers for an 280 EID-Record, the Map-Server MUST extract the nonce and ITR-RLOCs 281 present in the Map-Request, and store the association between the 282 EID-Record, xTR-ID, ITR-RLOCs and nonce. Any already present state 283 regarding ITR-RLOCs and/or nonce for the same xTR-ID MUST be 284 overwritten. 286 The following specifies the procedure to remove a subscription. If 287 the Map-Request only has one ITR-RLOC with AFI = 0 (i.e., Unknown 288 Address), the Map-Server MUST remove the subscription state for that 289 xTR-ID. In this case, the Map-Server MUST send the Map-Notify to the 290 source RLOC of the Map-Request. 292 When an EID-Record is removed from the Map-Server (either when 293 explicitly withdrawn or when its TTL expires), the Map-Server 294 notifies its subscribers (if any) via a Map-Notify with TTL equal 0. 296 6. Mapping Notification Publish Procedures 298 The publish procedure is implemented via Map-Notify messages that the 299 Map-Server sends to xTRs. The xTRs acknowledge the reception of Map- 300 Notifies via sending Map-Notify-Ack messages back to the Map-Server. 301 The complete mechanism works as follows. 303 When a mapping stored in a Map-Server is updated (e.g., via a Map- 304 Register from an ETR), the Map-Server MUST notify the subscribers of 305 that mapping via sending Map-Notify messages with the most updated 306 mapping information. The Map-Notify message sent to each of the 307 subscribers as a result of an update event MUST follow the exact 308 encoding and logic defined in Section 5.7 of 309 [I-D.ietf-lisp-rfc6833bis] for Map-Notify, except for the following: 311 (1) The Map-Notify MUST be sent to one of the ITR-RLOCs associated 312 with the xTR-ID of the subscriber (which one is implementation 313 specific). 315 (2) The Map-Server increments the nonce by one every time it sends a 316 Map-Notify as publication to an xTR-ID for a particular EID- 317 Record. The starting nonce is set as follows, if the 318 subscription state at the Map-Server was created by a received 319 Map-Request with the N-bit set, the starting nonce in the Map- 320 Notify sent as publication MUST be the one used in the Map- 321 Request that created the subscription state. If the 322 subscription state was created by explicit configuration at the 323 Map-Server (possible when a pre-shared security association 324 exists, see Section 7), the starting nonce in the Map-Notify 325 sent as publication MUST be randomly generated by the Map- 326 Server. 328 (3) The Map-Server MUST use its security association with the xTR to 329 compute the authentication data of the Map-Notify. 331 When the xTR receives a Map-Notify with an EID not local to the xTR, 332 the xTR knows that the Map-Notify has been received to update an 333 entry on its map-cache. Processing of unsolicited Map-Notify 334 messages MUST be explicitly enabled via configuration at the xTR. 335 The xTR MUST keep track of the last nonce seen in a Map-Notify 336 received as a publication from the Map-Server for the EID-Record. If 337 a Map-Notify received as a publication has a nonce value that is not 338 greater than the saved nonce, the xTR drops the Map-Notify message 339 and logs the fact a replay attack could have occurred. To compare 340 two nonces, the xTR uses the serial number arithmetic defined in 341 [RFC1982] with SERIAL_BITS = 64. The nonce field space (64 bits) is 342 considered large enough to not be depleted during normal operation of 343 the protocol (e.g., assuming a fast publication rate of one Map- 344 Notify per EID-Record per Map-Server per second, the nonce field 345 space will not be depleted in 0.5 trillion years). The same 346 considerations discussed in Section 5.6 of [I-D.ietf-lisp-rfc6833bis] 347 regarding storing Map-Register nonces apply here for Map-Notify 348 nonces. 350 The xTR processes the received Map-Notify as specified in Section 5.7 351 of [I-D.ietf-lisp-rfc6833bis], with the following considerations. 352 The xTR MUST use its security association with the Map-Server (see 353 Section 7.1) to validate the authentication data on the Map-Notify. 354 The xTR MUST use the mapping information carried in the Map-Notify to 355 update its internal map-cache. The xTR MUST acknowledge the Map- 356 Notify by sending back a Map-Notify-Ack (specified in Section 5.7 of 357 [I-D.ietf-lisp-rfc6833bis]), with the nonce from the Map-Notify, to 358 the Map-Server. If after a configurable timeout, the Map-Server has 359 not received back the Map-Notify-Ack, it can try to send the Map- 360 Notify to a different ITR-RLOC for that xTR-ID. If the Map-Server 361 tries all the ITR-RLOCs without receiving a response, it may stop 362 trying to send the Map-Notify. 364 7. Security Considerations 366 Generic security considerations related to LISP control messages are 367 discussed in Section 9 of [I-D.ietf-lisp-rfc6833bis]. 369 In the particular case of PubSub, cache poisoning via malicious Map- 370 Notify messages is avoided by the use of nonce and the security 371 association between the ITRs and the Map-Servers. 373 7.1. Security Association between ITR and MS 375 Since Map-Notifies from the Map-Server to the ITR need to be 376 authenticated, there is a need for a soft-state or hard-state 377 security association (e.g. a PubSubKey) between the ITRs and the Map- 378 Servers. For some controlled deployments, it might be possible to 379 have a shared PubSubKey (or set of keys) between the ITRs and the 380 Map-Servers. However, if pre-shared keys are not used in the 381 deployment, LISP-SEC [I-D.ietf-lisp-sec] can be used as follows to 382 create a security association between the ITR and the MS. 384 First, when the ITR is sending a Map-Request with the N-bit set 385 following Section 5, the ITR also performs the steps described in 386 Section 5.4 of [I-D.ietf-lisp-sec]. The ITR can then generate a 387 PubSubKey by deriving a key from the OTK as follows: PubSubKey = KDF( 388 OTK ), where KDF is the Key Derivation Function indicated by the OTK 389 Wrapping ID. If OTK Wrapping ID equals NULL-KEY-WRAP-128 then the 390 PubSubKey is the OTK. Note that as opposed to the pre-shared 391 PubSubKey, this generated PubSubKey is different per EID-Record the 392 ITR subscribes to (since the ITR will use a different OTK per Map- 393 Request). 395 When the Map-Server receives the Map-Request it follows Section 5. 396 If according to Section 5 the Map-Server is to reply with a Map-Reply 397 (e.g. due to PubSub not supported or subscription not accepted), then 398 it follows normal LISP-SEC procedure described in Section 5.7 of 399 [I-D.ietf-lisp-sec]. No PubSubKey or security association is created 400 in this case. 402 Otherwise, if, by following Section 5, the Map-Server is to reply 403 with a Map-Notify (e.g. due to subscription accepted) to a received 404 Map-Request, the following extra steps take place (note that if the 405 MS replies with a Map-Notify, none of the regular LISP-SEC steps 406 regarding Map-Reply described in Section 5.7 of [I-D.ietf-lisp-sec] 407 takes place). 409 o The MS extracts the OTK and OTK Wrapping ID from the LISP-SEC ECM 410 Authentication Data. 412 o The MS generates a PubSubKey by deriving a key from the OTK as 413 described before for the ITR. This is the same PubSubKey derived 414 at the ITR which is used to establish a security association 415 between the ITR and the MS. 417 o The PubSubKey can now be used to sign and authenticate any Map- 418 Notify between the MS and the ITR for the subscribed EID-Record. 419 This includes the Map-Notify sent as a confirmation to the 420 subscription. When the ITR wants to update the security 421 association for that MS and EID-Record, it follows again the 422 procedure described in this section. 424 7.2. DDoS Attack Mitigation 426 Misbehaving nodes may send massive subscription requests which may 427 lead to exhaust the resources of Map-Servers. Furthermore, 428 frequently changing the state of a subscription may also be 429 considered as an attack vector. To mitigate such issues, xTRs SHOULD 430 rate-limit Map-Requests and Map-Servers SHOULD rate-limit Map- 431 Notifies. Rate-limiting Map-Requests is discussed in Section 5.3 of 433 [I-D.ietf-lisp-rfc6833bis] and the same guidelines apply here. To 434 rate-limit Map-Notifies, a Map-Server MUST NOT send more than one 435 Map-Notify per second to a particular xTR-ID. This parameter MUST be 436 configurable. Note that when the Map-Notify rate-limit threshold is 437 met for a particular xTR-ID, the Map-Server will silently discard 438 additional subscription requests from that xTR-ID. Similarly, for 439 pending mapping updates that need to be notified to that xTR-ID, the 440 Map-Server will combine them into a single Map-Notify (with multiple 441 EID-records) which it will send when the rate-limit mechanism allows 442 it to transmit again Map-Notifies to that xTR-ID. 444 8. Contributors 445 Dino Farinacci 446 lispers.net 447 San Jose, CA 448 USA 450 Email: farinacci@gmail.com 452 Johnson Leong 454 Email: johnsonleong@gmail.com 456 Fabio Maino 457 Cisco 458 170 Tasman Drive 459 San Jose, CA 460 USA 462 Email: fmaino@cisco.com 464 Christian Jacquenet 465 Orange 466 Rennes 35000 467 France 469 Email: christian.jacquenet@orange.com 471 Stefano Secci 472 Cnam 473 France 475 Email: stefano.secci@cnam.fr 477 9. Acknowledgments 479 This work is partly funded by the ANR LISP-Lab project #ANR- 480 13-INFR-009 (https://www.lisp-lab.org). 482 10. IANA Considerations 484 This document requests IANA to assign a new bit from the "LISP 485 Control Plane Header Bits: Map-Request" sub-registry under the 486 "Locator/ID Separation Protocol (LISP) Parameters" registry available 487 at [IANA-LISP]. The position of this bit in the Map-Request message 488 can be found in Figure 1. 490 +-----------+---------------+--------------+-------------+ 491 | Spec Name | IANA Name | Bit Position | Description | 492 +-----------+---------------+--------------+-------------+ 493 | I | map-request-I | 11 | xTR-ID Bit | 494 +-----------+---------------+--------------+-------------+ 496 Table 1: Additions to the Map-Request Header Bits Sub-Registry 498 This document also requests the creation of a new sub-registry 499 entitled "LISP Map-Request Record Bits" under the "Locator/ID 500 Separation Protocol (LISP) Parameters" registry available at 501 [IANA-LISP]. 503 The initial content of this sub-registry is shown below: 505 +----------+---------------+-------------+--------------------------+ 506 | Spec | IANA Name | Bit | Description | 507 | Name | | Position | | 508 +----------+---------------+-------------+--------------------------+ 509 | N | map-request-N | 1 | Notification-Requested | 510 | | | | Bit | 511 +----------+---------------+-------------+--------------------------+ 513 Bits in position 2-8 are for future assignment. 515 The policy for allocating new bits from this sub-registry is 516 Specification Required (Section 4.6 of [RFC8126]). 518 11. Normative References 520 [I-D.ietf-lisp-rfc6830bis] 521 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 522 Cabellos, "The Locator/ID Separation Protocol (LISP)", 523 draft-ietf-lisp-rfc6830bis-36 (work in progress), November 524 2020. 526 [I-D.ietf-lisp-rfc6833bis] 527 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, 528 "Locator/ID Separation Protocol (LISP) Control-Plane", 529 draft-ietf-lisp-rfc6833bis-30 (work in progress), November 530 2020. 532 [I-D.ietf-lisp-sec] 533 Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, 534 "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-22 (work 535 in progress), January 2021. 537 [IANA-LISP] 538 IANA, "Locator/ID Separation Protocol (LISP) Parameters", 539 . 542 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 543 DOI 10.17487/RFC1982, August 1996, 544 . 546 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 547 Requirement Levels", BCP 14, RFC 2119, 548 DOI 10.17487/RFC2119, March 1997, 549 . 551 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 552 Writing an IANA Considerations Section in RFCs", BCP 26, 553 RFC 8126, DOI 10.17487/RFC8126, June 2017, 554 . 556 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 557 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 558 May 2017, . 560 Authors' Addresses 562 Alberto Rodriguez-Natal 563 Cisco 564 170 Tasman Drive 565 San Jose, CA 566 USA 568 Email: natal@cisco.com 570 Vina Ermagan 571 Google 572 USA 574 Email: ermagan@gmail.com 575 Albert Cabellos 576 UPC/BarcelonaTech 577 Barcelona 578 Spain 580 Email: acabello@ac.upc.edu 582 Sharon Barkai 583 Nexar 585 Email: sharon.barkai@getnexar.com 587 Mohamed Boucadair 588 Orange 589 Rennes 35000 590 France 592 Email: mohamed.boucadair@orange.com