idnits 2.17.1 draft-ietf-lisp-pubsub-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 8, 2021) is 1201 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == 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-21 Summary: 0 errors (**), 0 flaws (~~), 3 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: July 12, 2021 Google 6 A. Cabellos 7 UPC/BarcelonaTech 8 S. Barkai 9 Nexar 10 M. Boucadair 11 Orange 12 January 8, 2021 14 Publish/Subscribe Functionality for LISP 15 draft-ietf-lisp-pubsub-07 17 Abstract 19 This document specifies an extension to the use of Map-Request to 20 enable Publish/Subscribe (PubSub) operation for LISP. 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 July 12, 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 Language . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 11 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 71 1. Introduction 73 The Locator/ID Separation Protocol (LISP) [I-D.ietf-lisp-rfc6833bis] 74 splits current IP addresses in two different namespaces, Endpoint 75 Identifiers (EIDs) and Routing Locators (RLOCs). LISP uses a map- 76 and-encap approach that relies on (1) a Mapping System (basically a 77 distributed database) that stores and disseminates EID-RLOC mappings 78 and on (2) LISP tunnel routers (xTRs) that encapsulate and 79 decapsulate data packets based on the content of those mappings. 81 Ingress Tunnel Routers (ITRs) / Re-encapsulating Tunnel Routers 82 (RTRs) / Proxy Ingress Tunnel Routers (PITRs) pull EID-to-RLOC 83 mapping information from the Mapping System by means of an explicit 84 request message. Section 7.1 of [I-D.ietf-lisp-rfc6833bis] indicates 85 how Egress Tunnel Routers (ETRs) can tell ITRs/RTRs/PITRs about 86 mapping changes. This document presents a Publish/Subscribe (PubSub) 87 extension in which the Mapping System can notify ITRs/RTRs/PITRs 88 about mapping changes. When this mechanism is used, mapping changes 89 can be notified faster and can be managed in the Mapping System 90 versus the LISP sites. 92 In general, when an ITR/RTR/PITR wants to be notified for mapping 93 changes for a given EID-prefix, the following steps occur: 95 (1) The ITR/RTR/PITR sends a Map-Request for that EID-prefix. 97 (2) The ITR/RTR/PITR sets the Notification-Requested bit (N-bit) on 98 the Map-Request and includes its xTR-ID and Site-ID. 100 (3) The Map-Request is forwarded to one of the Map-Servers that the 101 EID-prefix is registered to. 103 (4) The Map-Server creates subscription state for the ITR/RTR/PITR 104 on the EID-prefix. 106 (5) The Map-Server sends a Map-Notify to the ITR/RTR/PITR to 107 acknowledge the successful subscription. 109 (6) When there is an RLOC-set change for the EID-prefix, the Map- 110 Server sends a Map-Notify message to each ITR/RTR/PITR in the 111 subscription list. 113 (7) Each ITR/RTR/PITR sends a Map-Notify-Ack to acknowledge the 114 received Map-Notify. 116 This operation is repeated for all EID-prefixes for which ITR/RTR/ 117 PITR want to be notified. The ITR/RTR/PITR can set the N-bit for 118 several EID-prefixes within a single Map-Request. 120 2. Requirements Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 124 "OPTIONAL" in this document are to be interpreted as described in BCP 125 14 [RFC2119] [RFC8174] when, and only when, they appear in all 126 capitals, as shown here. 128 3. Deployment Assumptions 130 The specification described in this document makes the following 131 deployment assumptions: 133 (1) A unique 128-bit xTR-ID (plus a 64-bit Site-ID) identifier is 134 assigned to each xTR. 136 (2) Map-Servers are configured in proxy-reply mode, i.e., they are 137 solicited to generate and send Map-Reply messages for the 138 mappings they are serving. 140 The distribution of xTR-IDs (and Site-IDs) are out of the scope of 141 this document. 143 4. Map-Request PubSub Additions 145 Figure 1 shows the format of the updated Map-Request to support the 146 PubSub functionality. 148 0 1 2 3 149 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 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 |Type=1 |A|M|P|S|p|s|R|I| Rsvd |L|D| IRC | Record Count | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Nonce . . . | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | . . . Nonce | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Source-EID-AFI | Source EID Address ... | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | ... | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | ITR-RLOC-AFI n | ITR-RLOC Address n ... | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 / |N| Reserved | EID mask-len | EID-Prefix-AFI | 166 Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 \ | EID-Prefix ... | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Map-Reply Record ... | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | | 172 + + 173 | | 174 + xTR-ID + 175 | | 176 + + 177 | | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | | 180 + Site-ID + 181 | | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 Figure 1: Map-Request with I-bit, N-bit, xTR-ID, and Site-ID 186 The following is added to the Map-Request message defined in 187 Section 5.2 of [I-D.ietf-lisp-rfc6833bis]: 189 xTR-ID bit (I-bit): The I-bit of a Map-Request message is set to 1 190 to indicate that a 128 bit xTR-ID and a 64 bit Site-ID fields are 191 present at the end of the Map-Request message. If an xTR is 192 configured with an xTR-ID or Site-ID, it MUST set the I-bit to 1 193 and include its xTR-ID and Site-ID in the Map-Request messages it 194 generates. If either the xTR-ID or Site-ID is not configured, an 195 unspecified value is encoded for whichever ID that is not 196 configured. 198 Notification-Requested bit (N-bit): The N-bit of an EID-record is 199 set to 1 to specify that the xTR wants to be notified of updates 200 for that mapping record. 202 xTR-ID field: xTR-ID is a 128 bit field at the end of the Map- 203 Request message, starting after the final Record in the message 204 (or the Map-Reply Record, if present). The xTR-ID is used to 205 uniquely identify the sender of a Map-Request message. The xTR-ID 206 is defined in Section 5.6 of [I-D.ietf-lisp-rfc6833bis] 208 Site-ID field: Site-ID is a 64 bit field at the end of the Map- 209 Request message, following the xTR-ID. Site-ID is used by the 210 Map-Server receiving the Map-Request message to identify which 211 xTRs belong to the same site. The Site-ID is defined in 212 Section 5.6 of [I-D.ietf-lisp-rfc6833bis] 214 5. Mapping Request Subscribe Procedures 216 The xTR subscribes for RLOC-set changes for a given EID-prefix by 217 sending a Map-Request to the Mapping System with the N-bit set on the 218 EID-Record. The xTR builds a Map-Request according to Section 5.3 of 219 [I-D.ietf-lisp-rfc6833bis] but also does the following: 221 (1) The xTR MUST set the I-bit to 1 and append its xTR-ID and Site- 222 ID to the Map-Request. The xTR-ID uniquely identifies the xTR. 224 (2) The xTR MUST set the N-bit to 1 for each EID-Record to which the 225 xTR wants to subscribe. 227 The Map-Request is forwarded to the appropriate Map-Server through 228 the Mapping System. This document does not assume that a Map-Server 229 is pre-assigned to handle the subscription state for a given xTR. 230 The Map-Server that receives the Map-Request will be the Map-Server 231 responsible to notify that specific xTR about future mapping changes 232 for the subscribed mapping records. 234 Upon receipt of the Map-Request, the Map-Server processes it as 235 described in Section 8.3 of [I-D.ietf-lisp-rfc6833bis]. Furthermore, 236 upon processing, for each EID-Record that has the N-bit set to 1, the 237 Map-Server proceeds adding the xTR-ID contained in the Map-Request to 238 the list of xTR that have requested to be subscribed to that mapping 239 record. 241 If the xTR-ID is added to the list, the Map-Server MUST send a Map- 242 Notify message back to the xTR to acknowledge the successful 243 subscription. The Map-Server MUST follow the specification in 244 Section 5.7 of [I-D.ietf-lisp-rfc6833bis] to build the Map-Notify 245 with the following considerations: 247 (1) The Map-Server MUST use the nonce from the Map-Request as the 248 nonce for the Map-Notify. 250 (2) The Map-Server MUST use its security association with the xTR 251 (see Section 7.1) to compute the authentication data of the Map- 252 Notify. 254 (3) The Map-Server MUST send the Map-Notify to one of the ITR-RLOCs 255 received in the Map-Request. 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 If the Map-Request only has one ITR-RLOC with AFI = 0 (i.e., Unknown 287 Address), the Map-Server MUST remove the subscription state for that 288 xTR-ID. In this case, the Map-Server MUST send the Map-Notify to the 289 source RLOC of the Map-Request. When the TTL for the EID-record 290 expires, the EID-prefix is removed from the Map-Server's subscription 291 cache. On EID-Record removal, the Map-Server notifies the 292 subscribers via a Map-Notify with TTL equal 0. 294 6. Mapping Notification Publish Procedures 296 The publish procedure is implemented via Map-Notify messages that the 297 Map-Server sends to xTRs. The xTRs acknowledge the reception of Map- 298 Notifies via sending Map-Notify-Ack messages back to the Map-Server. 299 The complete mechanism works as follows. 301 When a mapping stored in a Map-Server is updated (e.g., via a Map- 302 Register from an ETR), the Map-Server MUST notify the subscribers of 303 that mapping via sending Map-Notify messages with the most updated 304 mapping information. The Map-Notify message sent to each of the 305 subscribers as a result of an update event MUST follow the exact 306 encoding and logic defined in Section 5.7 of 307 [I-D.ietf-lisp-rfc6833bis] for Map-Notify, except for the following: 309 (1) The Map-Notify MUST be sent to one of the ITR-RLOCs associated 310 with the xTR-ID of the subscriber. 312 (2) The Map-Server increments the nonce by one every time it sends a 313 Map-Notify as publication to an xTR-ID for a particular EID- 314 Record. The starting nonce is set as follows, if the 315 subscription state at the Map-Server was created by a received 316 Map-Request with the N-bit set, the starting nonce in the Map- 317 Notify sent as publication MUST be the one used in the Map- 318 Request that created the subscription state. If the 319 subscription state was created by explicit configuration at the 320 Map-Server, the starting nonce in the Map-Notify sent as 321 publication MUST be randomly generated by the Map-Server. 323 (3) The Map-Server MUST use its security association with the xTR to 324 compute the authentication data of the Map-Notify. 326 When the xTR receives a Map-Notify with an EID not local to the xTR, 327 the xTR knows that the Map-Notify has been received to update an 328 entry on its map-cache. Processing of unsolicited Map-Notify 329 messages MUST be explicitly enabled via configuration at the xTR. 330 The xTR MUST keep track of the last nonce seen in a Map-Notify 331 received as a publication from the Map-Server for the EID-Record. If 332 a Map-Notify received as a publication has a nonce value that is not 333 greater than the saved nonce, the xTR drops the Map-Notify message 334 and logs the fact a replay attack could have occurred. To compare 335 two nonces, the xTR uses the serial number arithmetic defined in 336 [RFC1982] with SERIAL_BITS = 64. The nonce field space (64 bits) is 337 considered large enough to not be depleted during normal operation of 338 the protocol (e.g., assuming a fast publication rate of one Map- 339 Notify per EID-Record per Map-Server per second, the nonce field 340 space will not be depleted in 0.5 trillion years). The same 341 considerations discussed in Section 5.6 of [I-D.ietf-lisp-rfc6833bis] 342 regarding storing Map-Register nonces apply here for Map-Notify 343 nonces. 345 The xTR processes the received Map-Notify as specified in Section 5.7 346 of [I-D.ietf-lisp-rfc6833bis], with the following considerations. 347 The xTR MUST use its security association with the Map-Server (see 348 Section 7.1) to validate the authentication data on the Map-Notify. 349 The xTR MUST use the mapping information carried in the Map-Notify to 350 update its internal map-cache. The xTR MUST acknowledge the Map- 351 Notify by sending back a Map-Notify-Ack (specified in Section 5.7 of 352 [I-D.ietf-lisp-rfc6833bis]), with the nonce from the Map-Notify, to 353 the Map-Server. If after a configurable timeout, the Map-Server has 354 not received back the Map-Notify-Ack, it can try to send the Map- 355 Notify to a different ITR-RLOC for that xTR-ID. 357 7. Security Considerations 359 Generic security considerations related to LISP control messages are 360 discussed in Section 9 of [I-D.ietf-lisp-rfc6833bis]. 362 In the particular case of PubSub, cache poisoning via malicious Map- 363 Notify messages is avoided by the use of nonce and the security 364 association between the ITRs and the Map-Servers. 366 7.1. Security Association between ITR and MS 368 Since Map-Notifies from the Map-Server to the ITR need to be 369 authenticated, there is a need for a soft-state or hard-state 370 security association (e.g. a PubSubKey) between the ITRs and the Map- 371 Servers. For some controlled deployments, it might be possible to 372 have a shared PubSubKey (or set of keys) between the ITRs and the 373 Map-Servers. However, if pre-shared keys are not used in the 374 deployment, LISP-SEC [I-D.ietf-lisp-sec] can be used as follows to 375 create a security association between the ITR and the MS. 377 First, when the ITR is sending a Map-Request with the N-bit set 378 following Section 5, the ITR also performs the steps described in 379 Section 5.4 of [I-D.ietf-lisp-sec]. The ITR can then generate a 380 PubSubKey by deriving a key from the OTK as follows: PubSubKey = KDF( 381 OTK ), where KDF is the Key Derivation Function indicated by the OTK 382 Wrapping ID. If OTK Wrapping ID equals NULL-KEY-WRAP-128 then the 383 PubSubKey is the OTK. Note that as opposed to the pre-shared 384 PubSubKey, this generated PubSubKey is different per EID-Record the 385 ITR subscribes to (since the ITR will use a different OTK per Map- 386 Request). 388 When the Map-Server receives the Map-Request it follows Section 5. 389 If according to Section 5 the Map-Server is to reply with a Map-Reply 390 (e.g. due to PubSub not supported or subscription not accepted), then 391 it follows normal LISP-SEC procedure described in Section 5.7 of 392 [I-D.ietf-lisp-sec]. No PubSubKey or security association is created 393 in this case. 395 Otherwise, if, by following Section 5, the Map-Server is to reply 396 with a Map-Notify (e.g. due to subscription accepted) to a received 397 Map-Request, the following extra steps take place (note that if the 398 MS replies with a Map-Notify, none of the regular LISP-SEC steps 399 regarding Map-Reply described in Section 5.7 of [I-D.ietf-lisp-sec] 400 takes place). 402 o The MS extracts the OTK and OTK Wrapping ID from the LISP-SEC ECM 403 Authentication Data. 405 o The MS generates a PubSubKey by deriving a key from the OTK as 406 described before for the ITR. This is the same PubSubKey derived 407 at the ITR which is used to establish a security association 408 between the ITR and the MS. 410 o The PubSubKey can now be used to sign and authenticate any Map- 411 Notify between the MS and the ITR for the subscribed EID-Record. 412 This includes the Map-Notify sent as a confirmation to the 413 subscription. When the ITR wants to update the security 414 association for that MS and EID-Record, it follows again the 415 procedure described in this section. 417 7.2. DDoS Attack Mitigation 419 Misbehaving nodes may send massive subscription requests which may 420 lead to exhaust the resources of Map-Servers. Furthermore, 421 frequently changing the state of a subscription may also be 422 considered as an attack vector. To mitigate such issues, xTRs SHOULD 423 rate-limit Map-Requests and Map-Servers SHOULD rate-limit Map- 424 Notifies. Rate-limiting Map-Requests is discussed in Section 5.3 of 425 [I-D.ietf-lisp-rfc6833bis] and the same guidelines apply here. To 426 rate-limit Map-Notifies, a Map-Server MUST NOT send more than one 427 Map-Notify per second to a particular xTR-ID. This parameter MUST be 428 configurable. Note that when the Map-Notify rate-limit threshold is 429 met for a particular xTR-ID, the Map-Server will silently discard 430 additional subscription requests from that xTR-ID. Similarly, for 431 pending mapping updates that need to be notified to that xTR-ID, the 432 Map-Server will combine them into a single Map-Notify (with multiple 433 EID-records) which it will send when the rate-limit mechanism allows 434 it to transmit again Map-Notifies to that xTR-ID. 436 8. Contributors 438 Dino Farinacci 439 lispers.net 440 San Jose, CA 441 USA 443 Email: farinacci@gmail.com 445 Johnson Leong 447 Email: johnsonleong@gmail.com 449 Fabio Maino 450 Cisco 451 170 Tasman Drive 452 San Jose, CA 453 USA 455 Email: fmaino@cisco.com 457 Christian Jacquenet 458 Orange 459 Rennes 35000 460 France 462 Email: christian.jacquenet@orange.com 464 Stefano Secci 465 Cnam 466 France 468 Email: stefano.secci@cnam.fr 470 9. Acknowledgments 472 This work is partly funded by the ANR LISP-Lab project #ANR- 473 13-INFR-009 (https://www.lisp-lab.org). 475 10. IANA Considerations 477 This document is requesting bit allocations in the Map-Request 478 message from the "LISP Control Plane Header Bits" registry introduced 479 in Section 12.6 of [I-D.ietf-lisp-rfc6833bis]. In particular, this 480 document requests allocating the following two bits from the sub- 481 registry "Map-Request Header Bits". The position of these two bits 482 in the Map-Request message can be found in Figure 1. 484 +----------+---------------+-------------+--------------------------+ 485 | Spec | IANA Name | Bit | Description | 486 | Name | | Position | | 487 +----------+---------------+-------------+--------------------------+ 488 | I | map-request-I | 11 | xTR-ID Bit | 489 | N | map-request-N | ... + 0 | Notification-Requested | 490 | | | | Bit | 491 +----------+---------------+-------------+--------------------------+ 493 Table 1: Additions to the LISP Map-Request Header Bits Sub-Registry 495 11. Normative References 497 [I-D.ietf-lisp-rfc6833bis] 498 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos- 499 Aparicio, "Locator/ID Separation Protocol (LISP) Control- 500 Plane", draft-ietf-lisp-rfc6833bis-30 (work in progress), 501 November 2020. 503 [I-D.ietf-lisp-sec] 504 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 505 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-21 506 (work in progress), July 2020. 508 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 509 DOI 10.17487/RFC1982, August 1996, 510 . 512 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 513 Requirement Levels", BCP 14, RFC 2119, 514 DOI 10.17487/RFC2119, March 1997, 515 . 517 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 518 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 519 May 2017, . 521 Authors' Addresses 523 Alberto Rodriguez-Natal 524 Cisco 525 170 Tasman Drive 526 San Jose, CA 527 USA 529 Email: natal@cisco.com 531 Vina Ermagan 532 Google 533 USA 535 Email: ermagan@gmail.com 537 Albert Cabellos 538 UPC/BarcelonaTech 539 Barcelona 540 Spain 542 Email: acabello@ac.upc.edu 544 Sharon Barkai 545 Nexar 547 Email: sharon.barkai@getnexar.com 549 Mohamed Boucadair 550 Orange 551 Rennes 35000 552 France 554 Email: mohamed.boucadair@orange.com