idnits 2.17.1 draft-kouvelas-lisp-map-server-reliable-transport-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 (18 January 2022) is 828 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC5925' is mentioned on line 768, but not defined == Missing Reference: 'RFC4895' is mentioned on line 769, but not defined == Unused Reference: 'RFC8060' is defined on line 825, but no explicit reference was found in the text == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-30 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Leong 3 Internet-Draft D. Lewis 4 Intended status: Experimental B. Pitta 5 Expires: 22 July 2022 Cisco Systems 6 C. Cassar 7 Tesla 8 I. Kouvelas 9 Arista Networks Inc. 10 J. Arango 11 Microsoft 12 18 January 2022 14 LISP Map Server Reliable Transport 15 draft-kouvelas-lisp-map-server-reliable-transport-07 17 Abstract 19 The communication between LISP ETRs and Map-Servers is based on 20 unreliable UDP message exchange coupled with periodic message 21 transmission in order to maintain soft state. The drawback of 22 periodic messaging is the constant load imposed on both the ETR and 23 the Map-Server. New use cases for LISP have increased the amount of 24 state that needs to be communicated with requirements that are not 25 satisfied by the current mechanism. This document introduces the use 26 of a reliable transport for ETR to Map-Server communication in order 27 to eliminate the periodic messaging overhead, while providing 28 reliability, flow-control and endpoint liveness detection. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 22 July 2022. 47 Copyright Notice 49 Copyright (c) 2022 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Revised BSD License text as 58 described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Revised BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 65 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . 4 66 4. Session Establishment . . . . . . . . . . . . . . . . . . . . 5 67 5. Error Notifications . . . . . . . . . . . . . . . . . . . . . 5 68 6. EID Prefix Registration . . . . . . . . . . . . . . . . . . . 7 69 6.1. Reliable Mapping Registration Messages . . . . . . . . . 7 70 6.1.1. Registration Message . . . . . . . . . . . . . . . . 8 71 6.1.2. Registration Acknowledgement Message . . . . . . . . 8 72 6.1.3. Registration Rejection Message . . . . . . . . . . . 9 73 6.1.4. Registration Refresh Message . . . . . . . . . . . . 10 74 6.1.5. Mapping Notification Message . . . . . . . . . . . . 12 75 6.2. ETR Behavior . . . . . . . . . . . . . . . . . . . . . . 13 76 6.3. Map-Server Behavior . . . . . . . . . . . . . . . . . . . 17 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 79 8.1. LISP Reliable Transport Message Types . . . . . . . . . . 18 80 8.2. Transport Protocol Port Numbers . . . . . . . . . . . . . 18 81 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 82 10. Normative References . . . . . . . . . . . . . . . . . . . . 19 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 85 1. Introduction 87 The communication channel between LISP ETRs and Map-Servers is based 88 on unreliable UDP message exchange [I-D.ietf-lisp-rfc6833bis]. Where 89 required, reliability is pursued through periodic retransmissions 90 that maintain soft state on the peer. Map-Register messages are 91 retransmitted every minute by an ETR and the Map-Server times out its 92 state if the state is not refreshed for three successive periods. 93 When registering multiple EID-Prefixes, the ETR includes multiple 94 mapping records in the Map-Register message. Packet size limitations 95 provide an upper bound to the number of mapping records that can be 96 placed in each Map-Register message. When the ETR has more EID- 97 Prefixes to register than can be packed in a single Map-Register 98 message, the mapping records for the EID-Prefixes are split across 99 multiple Map-Register messages. 101 The drawback of the periodic registration is the constant load that 102 it introduces on both the ETR and the Map-Server. The ETR uses 103 resources to periodically build and transmit the Map-Register 104 messages, and to process the resulting Map-Notify messages issued by 105 the Map-Server. The Map-Server uses resources to process the 106 received Map-Register messages, update the corresponding registration 107 state, and build and transmit the matching Map-Notify messages. When 108 the number of EID-Prefixes to be registered by an ETR is small, the 109 resulting load imposed by periodic registrations may not be 110 significant. The ETR will only transmit a single Map-Register 111 message each period that contains a small number of mapping records. 113 In some LISP deployments, a large set of EID-Prefixes must be 114 registered by each ETR (e.g. mobility, database redistribution). Use 115 cases with a large set of EID-Prefixes behind an ETR will result in a 116 much higher load. An example is LISP mobility deployments where EID- 117 Prefixes are limited to host entries. ETRs may have thousands of 118 hosts to register resulting in hundreds of Map-Register and Map- 119 Notify messages per registration period. 121 A transport is required for the ETR to Map-Server communication that 122 provides reliability, flow-control and endpoint liveness 123 notifications. This document describes the use of TCP or SCTP as a 124 LISP reliable transport. The initial application for the LISP 125 reliable transport session is the support of scalable EID prefix 126 registration. The reliable session mechanism is defined to be 127 extensible so that it can support additional LISP communication 128 requirements as they arise using a single reliable transport session 129 between an ETR and a Map-Server. The use of the reliable transport 130 session for EID prefix registration is an alternative and does not 131 replace the existing UDP based mechanism. 133 2. Requirements Notation 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC2119]. 139 3. Message Format 141 A single LISP reliable transport session may carry information for 142 multiple LISP applications. One such application is the registration 143 of EID to RLOC mappings that operates over a session between an ETR 144 and a Map-Server. Communication over a session is based on the 145 exchange of messages. This document defines a base set of messages 146 to support session establishment and management. It also defines the 147 messages for the EID to RLOC mapping registration application. 149 To support protocol extensibility when new applications, or 150 extensions to existing applications are introduced, the messages are 151 based on a TLV format. 153 0 1 2 3 154 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 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Type | Length | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Message ID | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Message Data ... 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Message End Marker | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 Reliable transport message format 167 * Type: 16 bit type field identifying the message type. 169 * Length: 16 bit field that provides the total size of the message 170 in octets including the length, type and end marker fields. The 171 length allows the receiver to locate the next message in the TCP 172 stream. The minimum value of the length field is 8. 174 * ID: A 32-bit value that identifies the message. May be used by 175 the receiver to identify the message in replies or notification 176 messages. 178 * Data: Type specific message contents. 180 * End Marker: A 32-bit message end marker that must be set to 181 0x9FACADE9. The End Marker is used by the receiver to validate 182 that it has correctly parsed or skipped a message and provides a 183 method to detect formatting errors. Note that message data may 184 also contain this marker, and that the marker itself is not 185 sufficient for parsing the message. 187 The base message format does not indicate how the peer should deal 188 with the message in cases where the message type is not supported/ 189 understood. This is best dealt with by the application. For 190 example, in case an error notification is returned, or an expected 191 acknowledgement message is not received, the application might choose 192 various courses of action; from simply logging that the feature is 193 not supported, all the way to tearing the relationship with the peer 194 down for the feature, or for all LISP features. 196 4. Session Establishment 198 To ensure backwards compatibility, the map server and ETR MUST 199 communicate via unreliable UDP messages until a TCP session between 200 the two is successfully established. 202 The map server authenticates the ETR with the authentication data 203 contained in the first UDP map-register message it receives from the 204 ETR. Once the ETR is authenticated, the map server performs a 205 passive open by listening on TCP port 4342, and does not qualify the 206 remote port. As a security measure, the map server accepts TCP 207 connections only from those ETRs that have been authenticated via UDP 208 map-register messages. 210 The ETR assumes the active role of the TCP session establishment by 211 connecting to the map server once it has received a UDP map-notify 212 message. 214 When a TCP session goes down, UDP authentication must take place 215 before a new TCP session is established. The map-server will not 216 accept a connection from the ETR until a UDP map-register has been 217 received. Similarly, the ETR will not attempt to establish a session 218 with the map server until an UDP map-notify message has been 219 received. 221 A single reliable transport session is established between the map 222 server and the ETR to cover all communication needs. For example, an 223 ETR that has EID prefix registrations for multiple EID instances and 224 EID address families will only establish a single session with the 225 map server. 227 5. Error Notifications 229 The error notification message is used to communicate base reliable 230 transport session communication errors. LISP applications making use 231 of the reliable transport session and having to communicate 232 application specific errors must define their own messages to do so. 233 An error notification is issued when the receiver of a message does 234 not recognize the message type or cannot parse the message contents. 236 The notification includes the offending message type and ID and as 237 much of the offending message data as the notification sender wishes 238 to. 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Type = 16 | Length | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Message ID | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Error Code | Reserved | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Offending Message Type | Offending Message Length | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Offending Message ID | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Offending Message Data ... 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Message End Marker | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 Error Notification message format 260 * Error Code: An 8 bit field identifying the type of error that 261 occurred. Defined errors are: 263 - Unrecognized message type. 265 - Message format error. 267 * Reserved: Set to zero by the sender and ignored by the receiver. 269 * Offending Message Type: 16 bit type field identifying the message 270 type of the offending message that triggered this error 271 notification. This is copied from the Type field of the offending 272 message. 274 * Offending Message Length: 16 bit field that provides the total 275 size of the offending message in octets. This is copied from the 276 Length field of the offending message. 278 * Offending Message ID: A 32-bit field that is set to the Message ID 279 field of the offending message. 281 * Offending Message Data: The Data from the offending message that 282 triggered this error notification. The sender of the notification 283 may include as much of the original data as is deemed necessary. 284 The length of the Offending Message Data field is not provided by 285 the Offending Message Length field and is determined by 286 subtracting the size of the other fields in the message from the 287 Length field. It is valid to not include any of the offending 288 message data when sending an error notification. 290 * End Marker: A 32-bit message end marker that must be set to 291 0x9FACADE9. The End Marker is used by the receiver to validate 292 that it has correctly parsed or skipped a message and provides a 293 method to detect formatting errors. Note that message data may 294 also contain this marker, and that the marker itself is not 295 sufficient for parsing the message. 297 An error notification cannot be the offending message in another 298 error notification and MUST NOT trigger such a message. 300 6. EID Prefix Registration 302 EID prefix registration uses the reliable transport session between 303 an ETR and a Map-Server to communicate the ETR local EID database EID 304 to RLOC mappings to the Map-Server. In contrast to the UDP based 305 periodic registration, mapping information over the reliable 306 transport session is only sent when there is new information 307 available for the Map-Server. The Map-Server does not maintain a 308 timer to expire registrations communicated over the reliable 309 transport session. Instead an explicit de-registration (a 310 registration carrying a zero TTL) is needed to delete the state 311 maintained by the Map-Server. 313 The key used to identify registration mapping records in the ETR to 314 Map-Server communication is the EID prefix. The prefix may be 315 specified using an LCAF encoding that includes an EID instance ID. 317 When the reliable transport session goes down, registration mappings 318 learned by the Map-Server are treated as periodic UDP registrations 319 and a timer is used to expire them after 3 minutes. During this 320 period UDP based registrations or the re-establishment of the 321 reliable transport session and subsequent communication of a new 322 mapping can update the EID prefix mapping state. 324 6.1. Reliable Mapping Registration Messages 326 This section defines the LISP reliable transport session messages 327 used to communicate local EID database registrations between the ETR 328 and the Map-Server. 330 6.1.1. Registration Message 332 The reliable transport registration message is used to communicate 333 EID to RLOC mapping registrations from the ETR to the Map-Server. To 334 increase code reuse, the "Message Data" field uses the same format as 335 the UDP Map-Registers but without the IP and UDP headers. A reliable 336 registration message MUST contain a single mapping-record. The map 337 server MUST discard any reliable registration message that contains 338 more than one mapping record. 340 The reliable transport session is authenticated by means of the 341 session establishment procedure. Thus, although the Map-Register 342 MUST carry the authentication data, it is up to the map server to 343 determine if each individual reliable registration message should be 344 authenticated. 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Type = 17 | Length | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Message ID | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Map-Register message ... 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 ... Map-Register message | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Message End Marker | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 Registration message format 362 6.1.2. Registration Acknowledgement Message 364 The Acknowledgement message is sent from the Map-Server to the ETR to 365 confirm successful registration of an EID prefix previously 366 communicated by a reliable transport session Registration message. 367 The Registration Acknowledgement message does not carry a mapping 368 record (the map servers view of the mapping). This is accomplished 369 by the LISP reliable transport Map Notification message. 371 0 1 2 3 372 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 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Type = 18 | Length | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Message ID | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Prefix-Length | EID-Prefix-AFI | EID-Prefix ... 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Message End Marker | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 Registration Acknowledgement message format 385 * Prefix-Length: Mask length for the EID prefix. 387 * EID-Prefix AFI: Address family identifier for the EID prefix in 388 the following field. 390 * EID-Prefix: The EID prefix from the received Registration. 392 6.1.3. Registration Rejection Message 394 The Registration Rejection Message is sent by the map server to the 395 ETR to indicate that the registration of a specific EID prefix is 396 being rejected or withdrawn. A rejection refers to a recently-sent 397 registration that is being immediately rejected. A withdrawal refers 398 to a previously accepted registration that is no longer acceptable, 399 perhaps due to a configuration change in the map-server. The ETR 400 must keep track of rejected EID prefixes and be prepared to re- 401 register their mappings when requested through a registration refresh 402 message. 404 0 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Type = 19 | Length | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Message ID | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Reason | Reserved | Prefix-Length | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | EID-Prefix-AFI | EID-Prefix ... 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Message End Marker | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 Registration Rejection message format 420 * Reason: Code identifying the reason for which the Map-Server 421 rejected or withdrew the registration. 423 - 1 - Not a valid site EID prefix. 425 - 2 - Authentication failure. 427 - 3 - Locator set not allowed. 429 - 4 - Used to cover reason that's not defined. 431 * Reserved: This field is reserved for future use. Set to zero by 432 the sender and ignored by the receiver. 434 * Prefix-Length: Mask length for the EID prefix. 436 * EID-Prefix-AFI: Address family identifier for the EID prefix in 437 the following field. 439 * EID-Prefix: The EID prefix being rejected or withdrawn. 441 6.1.4. Registration Refresh Message 443 Sent by the Map-Server to the ETR to request the (re-)transmission of 444 EID prefix database mapping Registration messages. 446 0 1 2 3 447 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 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Type = 20 | Length | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Message ID | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Scope |R| Reserved | Prefix-Length | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | EID-Prefix-AFI | EID-Prefix ... 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Message End Marker | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 Registration Refresh message format 462 * Scope: Determines the set of registrations being refreshed. 464 - 0 - All prefixes under all address families under all EID 465 instances are being refreshed. When using this scope the 466 Prefix-Length, EID-Prefix-AFI, and EID-Prefix fields MUST be 467 omitted. That is, the Message End Marker follows immediately 468 after the Reserved field. The total length of the message MUST 469 be 15 bytes. 471 - 1 - All prefixes under all address families under a single EID 472 instance are being refreshed. The Prefix-Length MUST be set to 473 zero, EID-Prefix-AFI MUST be set to LCAF type, the EID-Prefix 474 encodes the LCAF Instance ID, the LCAF address AFI MUST be set 475 to UNSPECIFIED. The total length of the message MUST be 30 476 bytes. 478 - 2 - All prefixes under a single address family under a single 479 EID instance are being refreshed. The Prefix-Length MUST be 480 set to zero, the EID-Prefix-AFI MUST be set to LCAF type and 481 the EID-Prefix MUST encode the Instance ID. The LCAF address 482 AFI MUST specify the address family to refresh, the actual 483 address SHOULD be set to zero. 485 - 3 - All prefixes covered by a specific EID prefix in a single 486 EID instance is being refreshed. The Prefix-Length, EID- 487 Prefix-AFI and EID prefix MUST be encoded accordingly. 489 - 4 - A specific EID prefix in a single EID instance is being 490 refreshed. The Prefix-Length, EID-Prefix-AFI and EID prefix 491 MUST be encoded accordingly. 493 The map-server has the flexibility to control the granularity of 494 the refresh by issuing refresh with different scopes. It can send 495 a single refresh with a coarse scope or send individual refreshes 496 with narrower scope. The ETR MUST be able to process all scopes 497 to ensure the map-server registration states are synchronized with 498 the ETR. 500 * R: Request from the ETR to only refresh registrations that have 501 been previously rejected by the Map-Server. If the R bit is set 502 then the scope cannot have a value of 3 and the EID-Prefix and 503 Prefix-Length fields must be omitted. 505 * Reserved: This field is reserved for future use. Set to zero by 506 the sender and ignored by the receiver. 508 * Prefix-Length: Mask length for the EID prefix. Refer to scope for 509 more details. 511 * EID-Prefix-AFI: Address family identifier for the EID prefix in 512 the following field. Refer to scope for more details. 514 * EID-Prefix: The EID prefix being refreshed. Refer to scope for 515 more details. 517 6.1.5. Mapping Notification Message 519 Mapping Notification messages communicate the Map-Server view of the 520 mapping for an EID prefix and no longer serve as a registration 521 acknowledgement. Mapping Notifications do not need message level 522 authentication as they are received over a reliable transport session 523 to a known Map-Server. Note that reliable transport Mapping 524 Notification messages do not reuse the UDP Map-Notify message format. 526 0 1 2 3 527 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 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Type = 21 | Length | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Message ID | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | xTR-ID 128 bits ... 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | xTR-ID 128 bits ... 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | xTR-ID 128 bits ... 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | xTR-ID 128 bits | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | site-ID 64 bits ... 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | site-ID 64 bits | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Mapping Record ... 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 ... Mapping Record | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Message End Marker | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 Mapping Notification message format 554 * xTR-ID: xTR-ID taken from the last valid registration the map- 555 server received for the EID-prefix conveyed in the mapping record. 557 * site-ID: site-ID taken from the last valid registration the map- 558 server received for the EID-prefix conveyed in the mapping record. 560 * Mapping Record: Mapping record of the EID-prefix the map-server is 561 conveying to the ETR. 563 6.2. ETR Behavior 565 The ETR operates the following per EID prefix, per MS state machine 566 that defines the reliable transport EID prefix registration behavior. 568 There are five states: 570 * No state: The local EID database prefix does not exist. 572 * Periodic: The local EID database prefix is being periodically 573 registered through UDP Map-Register messages as specified in []. 575 * Stable: From the ETR's perspective, no registrations are due to be 576 sent to the peer. The session to the peer is up, and the peer has 577 either acknowledged the registration, or is expected to request a 578 refresh in the future. 580 * AckWait: A Registration message for the prefix has been 581 transmitted to the Map-Server and the ETR is waiting for either a 582 Registration Acknowledge or Registration Rejected reply from the 583 Map-Server. 585 * Reject: The reliable transport registration for the local EID 586 database prefix was rejected by the Map-Server. From the ETR's 587 perspective, no registration is due to the peer AND the peer is 588 known to have rejected the registration. 590 The following events drive the state transitions: 592 * DB creation: The local EID database entry for the EID prefix is 593 created. 595 * DB deletion: The local EID database entry for the EID prefix is 596 deleted. 598 * DB change: The mapping contents or authentication information for 599 the local EID database entry changes. 601 * Session up: The reliable transport session to the Map-Server is 602 established. 604 * Session down: The reliable transport session the Map-Server goes 605 down. 607 * Recv Refresh: A Registration refresh message is received from the 608 Map-Server. 610 * Recv ACK: A Registration Acknowledge message is received from the 611 Map-Server. 613 * Recv Rejected: A Registration Rejected message is received from 614 the Map-Server. 616 * Periodic timer: The timer that drives generation of periodic UDP 617 Map-Register messages fires. 619 The state machine is: 621 +--------------------+--------------------------------------+ 622 | | Prev State | 623 | Event +-------------------+------------------+ 624 | | No state | Periodic | 625 +--------------------+-------------------+------------------+ 626 | DB creation | -> Periodic | N/A | 627 | [session down] | A1 | | 628 +--------------------+-------------------+------------------+ 629 | DB creation | -> AckWait | N/A | 630 | [session up] | A2 | | 631 +--------------------+-------------------+------------------+ 632 | DB deletion | N/A | -> No state | 633 | | | A3 | 634 +--------------------+-------------------+------------------+ 635 | DB change | N/A | - | 636 | | | A1 | 637 +--------------------+-------------------+------------------+ 638 | Session up | - | -> Stable | 639 | | | A4 | 640 +--------------------+-------------------+------------------+ 641 | Session down | - | N/A | 642 | | | | 643 +--------------------+-------------------+------------------+ 644 | Recv Refresh | - | N/A | 645 | | | | 646 +--------------------+-------------------+------------------+ 647 | Recv Refresh | - | N/A | 648 | [rejected] | | | 649 +--------------------+-------------------+------------------+ 650 | Recv ACK | - | N/A | 651 | | | | 652 +--------------------+-------------------+------------------+ 653 | Recv Rejection | - | N/A | 654 | | | | 655 +--------------------+-------------------+------------------+ 656 | Timer | N/A | - | 657 | | | A5 | 658 +--------------------+-------------------+------------------+ 660 xTR per EID prefix per MS state machine 661 +-----------------+-----------------------------------------------+ 662 | | Prev State | 663 | Event +---------------+---------------+---------------+ 664 | | Stable | AckWait | Rejected | 665 +-----------------+---------------+---------------+---------------+ 666 | DB creation | N/A | N/A | N/A | 667 | | | | | 668 +-----------------+---------------+---------------+---------------+ 669 | DB deletion | -> No state | -> No state | -> No state | 670 | | A6 | A6 | | 671 +-----------------+---------------+---------------+---------------+ 672 | DB change | -> AckWait | - | -> AckWait | 673 | | A2 | A2 | A2 | 674 +-----------------+---------------+---------------+---------------+ 675 | Session up | N/A | N/A | N/A | 676 | | | | | 677 +-----------------+---------------+---------------+---------------+ 678 | Session down | -> Periodic | -> Periodic | -> Periodic | 679 | | A7 | A7 | A7 | 680 +-----------------+---------------+---------------+---------------+ 681 | Recv Refresh | -> AckWait | - | -> AckWait | 682 | | A2 | A2 | A2 | 683 +-----------------+---------------+---------------+---------------+ 684 | Recv Refresh | - | - | -> AckWait | 685 | [rejected] | | A2 | A2 | 686 +-----------------+---------------+---------------+---------------+ 687 | Recv ACK | - | -> Stable | -> AckWait | 688 | | | | A2 | 689 +-----------------+---------------+---------------+---------------+ 690 | Recv Rejection | -> Rejected | -> Rejected | - | 691 | | | | | 692 +-----------------+---------------+---------------+---------------+ 693 | Timer | N/A | N/A | N/A | 694 | | | | | 695 +-----------------+---------------+---------------+---------------+ 697 xTR per EID prefix per MS state machine 699 Action descriptions: 701 * A1: Start periodic registration timer with zero delay. 703 * A2: Send Registration over reliable transport session. 705 * A3: Send UDP registration with zero TTL. 707 * A4: Stop periodic registration timer. 709 * A7: Send UDP registration and start periodic registration timer 710 with registration period. 712 * A6: Send Registration with TTL zero over reliable transport 713 session. 715 * A7: Start periodic registration timer with registration period. 717 All timer start actions must be jittered. 719 When the reliable transport session is established the ETR moves the 720 state machine into the Stable state without first registering the EID 721 prefix over the reliable transport session. The map server will send 722 a refresh message with a scope of 0 that will trigger the 723 registration message to be sent. Because other applications may be 724 using the reliable session, the refresh message signals the ETR that 725 the map server supports reliable map registration messages. This 726 model will also allow future optimizations where the Map-Server may 727 retain registration state from a previous instantiation of the 728 reliable transport session with the ETR and only request the refresh 729 of EID prefix state beyond some negotiated session progress marker. 731 Aa Map-Server authentication key change is treated as a DB change 732 event and will result in triggering a new Registration message to be 733 transmitted. 735 6.3. Map-Server Behavior 737 Received registrations create/update or delete mapping state. 739 A refresh with global scope is sent when a session between the ETR 740 and map-server is first established so the map-server can obtain the 741 complete database contents from the ETR. This refresh is also 742 serving as a capability signaling from the map-server to the ETR that 743 it can support reliable registration. 745 Refresh for rejected registrations sent (R bit set) when a new EID 746 prefix is configured on the Map-Server. 748 Refresh is sent whenever authentication key is changed or EID prefix 749 is deconfigured. Upon reception of the registration map-server can 750 decide whether to acknowledge the registration or issue rejection. 752 Mapping Notification message sent whenever the mapping for a 753 registered or more specific prefix for which notifications are 754 requested changes. ETR acknowledgement or rejection messaging for 755 Mapping Notification is not required because the ETR decides how to 756 process the message based on the registered mapping information. If 757 the mapping information changes the resulting registration will 758 trigger a new Mapping Notification message from the Map-Server. 760 7. Security Considerations 762 The LISP reliable transport session SHOULD be authenticated. On 763 controlled RLOC networks that can guarantee that the source RLOC 764 address of data packets cannot be spoofed, the authentication check 765 can be a source address validation on the reliable transport packets. 766 When the RLOC network does not provide such guarantees, reliable 767 transport authentication SHOULD be used. Implementations SHOULD 768 support the TCP Authentication Option (TCP-AO) [RFC5925] and SCTP 769 Authenticated Chunks [RFC4895]. 771 8. IANA Considerations 773 8.1. LISP Reliable Transport Message Types 775 Assignment of new LISP reliable transport message types is done 776 according to the "IETF Review" model defined in [RFC5266]. 778 The initial content of the registry should be as follows. 780 Type Name Reference 781 ----------- ---------------------------------------- -------------- 782 0-15 Reserved This document 783 16 Error Notification This document 784 17 Registration Message This document 785 18 Registration Acknowledgement Message This document 786 19 Registration Rejected Message This document 787 20 Registration Refresh Message This document 788 21 Mapping Notification Message This document 789 22-30 Reserved for EID membership distribution TBD 790 31-64999 Unassigned 791 65000-65535 Reserved for Experimental Use 793 8.2. Transport Protocol Port Numbers 795 TCP port 4342 already reserved for LISP CONS that is now obsolete. 796 Repurpose for reliable transport over TCP. Reserve an SCTP port. 798 9. Acknowledgments 800 The authors would like to thank Noel Chiappa, Dino Farinacci, Jesper 801 Skriver, Andre Pelletier and Les Ginsberg for their contributions to 802 this document. 804 10. Normative References 806 [I-D.ietf-lisp-rfc6833bis] 807 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, 808 "Locator/ID Separation Protocol (LISP) Control-Plane", 809 Work in Progress, Internet-Draft, draft-ietf-lisp- 810 rfc6833bis-30, 18 November 2020, 811 . 814 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 815 Requirement Levels", BCP 14, RFC 2119, 816 DOI 10.17487/RFC2119, March 1997, 817 . 819 [RFC5266] Devarapalli, V. and P. Eronen, "Secure Connectivity and 820 Mobility Using Mobile IPv4 and IKEv2 Mobility and 821 Multihoming (MOBIKE)", BCP 136, RFC 5266, 822 DOI 10.17487/RFC5266, June 2008, 823 . 825 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 826 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 827 February 2017, . 829 Authors' Addresses 831 Johnson Leong 832 Cisco Systems 833 Tasman Drive 834 San Jose, CA 95134 835 United States of America 837 Email: joleong@cisco.com 839 Darrel Lewis 840 Cisco Systems 841 Tasman Drive 842 San Jose, CA 95134 843 United States of America 844 Email: darlewis@cisco.com 846 Balaji Pitta 847 Cisco Systems 848 Tasman Drive 849 San Jose, CA 95134 850 United States of America 852 Email: bvenkata@cisco.com 854 Chris Cassar 855 Tesla 856 10 New Square Park 857 Bedfont Lakes 858 TW14 8HA 859 United Kingdom 861 Email: christiancassar@acm.org 863 Isidor Kouvelas 864 Arista Networks Inc. 865 5453 Great America Parkway 866 Santa Clara, CA 95054 867 United States of America 869 Email: isidor@kouvelas.net 871 Jesus Arango 872 Microsoft 874 Email: jearango@microsoft.com