idnits 2.17.00 (12 Aug 2021) /tmp/idnits44726/draft-ymbk-idr-l3nd-01.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (3 March 2022) is 79 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-09) exists of draft-ietf-lsvr-l3dl-08 -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-PEN' ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-05) exists of draft-ymbk-idr-l3nd-ulpc-02 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Bush 3 Internet-Draft Arrcus & Internet Initiative Japan 4 Intended status: Standards Track R. Housley 5 Expires: 4 September 2022 Vigil Security 6 R. Austein 7 Arrcus 8 S. Hares 9 Hickory Hill Consulting 10 K. Patel 11 Arrcus 12 3 March 2022 14 Layer-3 Neighbor Discovery 15 draft-ymbk-idr-l3nd-01 17 Abstract 19 Data Centers where the topology is BGP-based need to discover 20 neighbor IP addressing, IP Layer-3 BGP neighbors, etc. This Layer-3 21 Neighbor Discovery protocol identifies BGP neighbor candidates. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 27 "OPTIONAL" in this document are to be interpreted as described in BCP 28 14 [RFC2119] [RFC8174] when, and only when, they appear in all 29 capitals, as shown here. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on 4 September 2022. 48 Copyright Notice 50 Copyright (c) 2022 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Revised BSD License text as 59 described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Revised BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4. Inter-Link Protocol Overview . . . . . . . . . . . . . . . . 5 68 4.1. L3ND Ladder Diagram . . . . . . . . . . . . . . . . . . . 5 69 5. TLV PDUs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 6. HELLO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 7. TCP Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 8. OPEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 9. ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 9.1. Retransmission . . . . . . . . . . . . . . . . . . . . . 14 75 10. The Encapsulations . . . . . . . . . . . . . . . . . . . . . 14 76 10.1. The Encapsulation PDU Skeleton . . . . . . . . . . . . . 15 77 10.2. Encapsulaion Flags . . . . . . . . . . . . . . . . . . . 16 78 10.3. IPv4 Encapsulation . . . . . . . . . . . . . . . . . . . 16 79 10.4. IPv6 Encapsulation . . . . . . . . . . . . . . . . . . . 17 80 10.5. MPLS Label List . . . . . . . . . . . . . . . . . . . . 18 81 10.6. MPLS IPv4 Encapsulation . . . . . . . . . . . . . . . . 18 82 10.7. MPLS IPv6 Encapsulation . . . . . . . . . . . . . . . . 19 83 11. VENDOR - Vendor Extensions . . . . . . . . . . . . . . . . . 19 84 12. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 20 85 12.1. HELLO Discussion . . . . . . . . . . . . . . . . . . . . 20 86 13. VLANs/SVIs/Sub-interfaces . . . . . . . . . . . . . . . . . . 20 87 14. Implementation Considerations . . . . . . . . . . . . . . . . 21 88 15. Security Considerations . . . . . . . . . . . . . . . . . . . 21 89 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 90 16.1. Link Local Layer-3 Addresses . . . . . . . . . . . . . . 22 91 16.2. Ports for TLS/TCP . . . . . . . . . . . . . . . . . . . 22 92 16.3. PDU Types . . . . . . . . . . . . . . . . . . . . . . . 22 93 16.4. Flag Bits . . . . . . . . . . . . . . . . . . . . . . . 23 94 16.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . 23 95 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 96 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 97 18.1. Normative References . . . . . . . . . . . . . . . . . . 23 98 18.2. Informative References . . . . . . . . . . . . . . . . . 24 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 101 1. Introduction 103 The Massive Data Center (MDC) environment presents unusual problems 104 of scale, e.g. O(10,000) forwarding devices, while its homogeneity 105 presents opportunities for simple approaches. Layer-3 Discovery and 106 Liveness (L3DL), [I-D.ietf-lsvr-l3dl], provides neighbor discovery at 107 Layer-2. This document (set) provides a similar solution at Layer-3, 108 attempting to be as similar as reasonable to L3DL. 110 Some guiding principles when dealing with datacenters with tens of 111 thousands of devices are 113 * Predictable Reliability, 115 * Security: Authorization and Integrity more than Confidentiality, 116 and 118 * Massive Scalability 120 Layer-3 Neighbor Discovery (L3ND) provides brutally simple mechanisms 121 for neighboring devices to 123 * Discover each other's IP Addresses, 125 * Discover mutually supported layer-3 encapsulations, e.g. IP/MPLS, 127 * Discover Layer-3 IP and/or MPLS addressing of interfaces of the 128 encapsulations, 130 * Provide authenticity, integrity, and verification of protocol 131 messages, and 133 * Accommodate scaling needed for EVPN etc. 135 L3DN is intended for use within single IP subnets (IP over Ethernet 136 or other point-to-point or multi-point IP link) in order to exchange 137 the data needed to bootstrap BGP-based peering, EVPN, etc.; 138 especially in a datacenter Clos [Clos] environment. Once IP 139 connectivity has been leveraged to discover1 layer-3 addressability 140 and forwarding capabilities, normal IP forwarding and routing can 141 take over. 143 L3ND might be found to be widely applicable to a range of routing and 144 similar protocols which need Layer-3 neighbor discovery. 146 2. Terminology 148 Even though it concentrates on the inter-device layer, this document 149 relies heavily on routing terminology. The following attempts to 150 clarify the use of some possibly confusing terms: 152 Clos: A hierarchic subset of a crossbar switch topology commonly 153 used in data centers [Clos]. 155 Datagram: The L3ND content of a single Layer-3 UDP Datagram. 157 Encapsulation: Address Family Indicator and Subsequent Address 158 Family Indicator (AFI/SAFI). I.e. classes of Layer-2.5 159 and Layer-3 addresses such as IPv4, IPv6, MPLS. 161 Link or Logical Link: A logical connection between two interfaces on 162 two different devices. E.g. two VLANs between the same 163 two ports are two links. 165 MDC: Massive Data Center, commonly composed of thousands of Top 166 of Rack Switches (TORs). 168 MTU: Maximum Transmission Unit, the size in octets of the 169 largest packet that can be sent on a medium, see [RFC1122] 170 1.3.3. 172 PDU: Protocol Data Unit, an L3ND application layer message. A 173 PDU's content may need to be broken into multiple 174 Datagrams to make it through MTU or other restrictions. 176 Session: An established, via exchange of OPEN PDUs, session between 177 two L3ND capable IP interfaces on a link. 179 TOR Switch: Top Of Rack switch, aggregates the servers in a rack and 180 connects to aggregation layers of the Clos tree, AKA the 181 Clos spine. 183 3. Background 185 L3ND is primarily designed for a Clos type datacenter scale and 186 topology, but can accommodate richer topologies which contain 187 potential cycles. 189 While L3ND is designed for the MDC, there are no inherent reasons it 190 could not run on a WAN. The authentication and authorization needed 191 to run safely on a WAN need to be considered, and the appropriate 192 level of security options chosen. 194 The number of addresses of one Encapsulation type on an interface 195 link may be quite large given a TOR switch with tens of servers, each 196 server having a few hundred micro-services, resulting in an 197 inordinate number of addresses. And highly automated micro-service 198 migration can cause serious address prefix disaggregation, resulting 199 in interfaces with thousands of disaggregated prefixes. 201 To meet such scaling needs, the L3ND protocol is session oriented and 202 uses incremental announcement and withdrawal with session restart, a 203 la BGP ([RFC4271]). 205 4. Inter-Link Protocol Overview 207 A device broadcasts a Layer-3 Multicast UDP datagram (HELLO) 208 containing the port number that is willing to serve a TLS or raw TCP 209 connection to support the data exchange of the rest of the protocol 210 in a reliable and preferably authenticated manner. 212 Another device on the link then establishes a TLS or raw TCP session 213 in which inter-device PDUs are used to exchange device and logical 214 link identities and layer-2.5 (MPLS) and 3 identifiers (not 215 payloads), e.g. more IP Addresses, loopback addresses, port 216 identities, and Encapsulations. 218 To assure discovery of new devices coming up on a multi-link 219 topology, devices on such a topology, and only on a multi-link 220 topology, send periodic HELLOs forever, see Section 12.1. 222 Given the TLS/TCP session, OPEN PDUs (Section 8) are exchanged, the 223 Encapsulations (Section 10) configured on an end point may be 224 announced and modified. Note that these are only the encapsulation 225 and addresses configured on the announcing interface; though a 226 device's loopback and overlay interface(s) may also be announced. 228 4.1. L3ND Ladder Diagram 230 The HELLO, Section 6, is a priming message sent on all logical links 231 configured for L3ND. It is a small L3ND Multicast UDP PDU with the 232 simple goal of advertising a TLS/TCP service available on an 233 advertised port on the sending IP interface. 235 The HELLO PDU is either IPv4 or IPv6, which selects the AFI to be 236 used for the rest of the session(s) between end-points. Two 237 endpoints MAY establish a link for each AFI. 239 An interface on the link receiving the HELLO PDU attempts to 240 establish a TLS or raw TCP, as specified by the HELLO, session to the 241 source IP address of the HELLO on the port advertised in the HELLO. 243 The OPEN, Section 8 PDUs, used to exchange details about the L3ND 244 session, and the ACK/ERROR PDU, are mandatory; other PDUs are 245 optional; though at least one encapsulation SHOULD be agreed at some 246 point. 248 Like Multi-Protocol BGP, [RFC4760], an L3ND session running over one 249 AFI MAY carry encapsulations etc. of different AFIs, 251 A L3DL extension, [I-D.ymbk-idr-l3nd-ulpc], describes the next upper 252 layer L3DL protocol to exchange BGP parameter information. 254 The following is a ladder-style diagram of the L3ND protocol 255 exchanges: 257 | HELLO | Logical Link Peer discovery 258 |---------------------------->| 259 | TCP OPEN | Mandatory 260 |<----------------------------| 261 | | 262 | | 263 | OPEN | IDs, security, etc. 264 |---------------------------->| 265 | ACK | 266 |<----------------------------| 267 | | 268 | OPEN | Mandatory 269 |<----------------------------| 270 | ACK | 271 |---------------------------->| 272 | | 273 | | 274 | Interface IPv4 Addresses | Interface IPv4 Addresses 275 |---------------------------->| Optional 276 | ACK | 277 |<----------------------------| 278 | | 279 | Interface IPv4 Addresses | 280 |<----------------------------| 281 | ACK | 282 |---------------------------->| 283 | | 284 | | 285 | Interface IPv6 Addresses | Interface IPv6 Addresses 286 |---------------------------->| Optional 287 | ACK | 288 |<----------------------------| 289 | | 290 | Interface IPv6 Addresses | 291 |<----------------------------| 292 | ACK | 293 |---------------------------->| 294 | | 295 | | 296 | Interface MPLSv4 Labels | Interface MPLSv4 Labels 297 |---------------------------->| Optional 298 | ACK | 299 |<----------------------------| 300 | | 301 | Interface MPLSv4 Labels | Interface MPLSv4 Labels 302 |<----------------------------| Optional 303 | ACK | 304 |---------------------------->| 305 | | 306 | | 307 | Interface MPLSv6 Labels | Interface MPLSv6 Labels 308 |---------------------------->| Optional 309 | ACK | 310 |<----------------------------| 311 | | 312 | Interface MPLSv6 Labels | Interface MPLSv6 Labels 313 |<----------------------------| Optional 314 | ACK | 315 |---------------------------->| 317 5. TLV PDUs 319 The basic L3ND application layer PDU is a typical TLV (Type Length 320 Value) PDU. As it is transported over TCP, integrity is assured. 321 When it is transported over TLS, authenticity is also provided. 323 0 1 2 3 324 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 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Version = 0 | PDU Type | Payload Length ~ 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 ~ | ~ 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 330 ~ Payload ... ~ 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 The fields of the basic L3ND header are as follows: 335 Version: An integer differentiating versions of the L3ND protocol. 336 Currently only Version 0 MAY BE specified. 338 PDU Type: An integer differentiating PDU payload types. See 339 Section 16.3. 341 Payload Length: Total number of octets in the Payload field. 343 Payload: The application layer content of the L3ND PDU. 345 6. HELLO 347 0 1 2 3 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Version = 0 | PDU Type = 0 | Payload Length = 24 ~ 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 ~ | Flags | Port ~ 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 ~ | 355 +-+-+-+-+-+-+-+-+ 357 Flags (bit): 358 0 - 0 Raw TCP, 1 TLS 359 1 - 0 Self-Signed Cert for TLS, 1 CA-based 361 The Payload Length is 24 to cover the Flags and Port fields. 363 The Port is the TCP Port Number (default is TBD3) on which the HELLO 364 sender MUST have a waiting TLS/TCP (as specified in Flags) server 365 listening. Though the IANA assigned well-known port SHOULD be used, 366 this field allows configuration of alternate ports. 368 The IPv4 UDP packets are sent to the IPv4 link local multicast 369 address (TBD1) and the IPv6 UDP packets are sent to an IPv6 link 370 Local multicast address (TBD2). See Section 12.1 for why multicast 371 is used. 373 The HELLO PDU solicits a unicast TLS/TCP open request(s) of the same 374 AFI from other devices on the link. 376 When a HELLO is received from a source IP address with which there is 377 no established TLS/TCP L3ND session, the receiver SHOULD respond by 378 sending a TLS/TCP client open request, using the same AFI, to the 379 source IP address of the HELLO to establish an L3ND TLS/TCP session. 381 All L3ND PDUs other than HELLO are sent via TLS/TCP, as the server's 382 destination IP address is known after the HELLO. 384 When an interface is turned up on a device, it SHOULD issue a HELLO 385 if it is to participate in L3ND sessions and repeat HELLOs at a 386 configured interval, with a default of 60 seconds. 388 If the configured multicast destination address is one that is 389 propagated by switches, the HELLO SHOULD be repeated at a configured 390 interval, with a default of 60 seconds. This allows discovery by new 391 devices which come up on the mesh. In this multi-link scenario, the 392 operator should be aware of the trade-off between timer tuning and 393 network noise and adjust the inter-HELLO timer accordingly. 395 By default, GTSM, [RFC5082], SHOULD be enabled to test that a 396 received HELLO MUST be on the local link. It MAY be disabled by 397 configuration. GTSM check failures SHOULD be logged, though with 398 rate limiting to keep from overwhelming logs. 400 If more than one device responds, one adjacency is formed for each 401 unique source IP address. L3ND treats each adjacency as a separate 402 logical link. 404 To ameliorate possible load spikes during bootstrap or event 405 recovery, there SHOULD be a jittered delay between receipt of a HELLO 406 and TLS/TCP open. The default delay range SHOULD be zero to five 407 seconds, and MUST be configurable. 409 If a HELLO is received from an IP Address with which there is an 410 established session for that AFI, the HELLO should be dropped. 412 A device with a TLS/TCP listener SHOULD log or otherwise report 413 repeated failed inbound attempts. 415 7. TCP Set-Up 417 If the receiver of a HELLO does not agree with the sender's choice of 418 TLS/TCP or does not agree with the verification choice, Self-Signed 419 or CA-based, the receiver SHOULD respond with a HELLO specifying its 420 preferences. 422 As it is assumed that the configured deployment of a data center 423 would have compatible parameters on all devices, any disagreement 424 over TLS/TCP or trust anchors MUST be logged. 426 By default, GTSM, [RFC5082], SHOULD be enabled to ensure that a SYN 427 received in response to a HELLO is on the local link. It MAY be 428 disabled by configuration. GTSM check failures SHOULD be logged, 429 though with rate limiting to keep from overwhelming logs. 431 If the receiver of a HELLO agrees with the sender's choice of TLS/TCP 432 and authentication, both sides have agreed on an AFI for the 433 transport and on each other's IP address in that AFI. This is 434 sufficient to open a TCP session between them, which will allow for 435 very large data PDUs while obviating the need to invent complex 436 transports. 438 The L3ND peer with the higher IP address MUST act as the TLS/TCP 439 client and open the transport session (send SYN) toward the peer with 440 the lower IP address. 442 The server, the sender of the HELLO with the lower IP address, 443 listens on the advertised port for the TLS/TCP session open. The 444 receiver of the acceptable HELLO, the TLS/TCP client, initiates a TLS 445 or raw TCP session with the sender of the HELLO, the TLS/TCP server, 446 preferably TLS, as advertised. If TLS, the server has chosen and 447 signaled either a self-signed certificate or one configured from the 448 operational CA trusted by both parties, as negotiated in the HELLO 449 exchange. 451 Once the TLS/TCP session is established, if the link is configured as 452 point to point, the client side SHOULD stop listening on any port for 453 which it has sent a HELLO. The server side SHOULD stop sending 454 HELLOs. 456 If the TLS/TCP open fails, then this SHOULD be logged and the parties 457 MUST go back to the initial state and try HELLO. 459 Should an interface with an established TLS/TCP session be 460 reconfigured changing the TLS/TCP parameters, the TLS/TCP session 461 should be closed or torn down. 463 Should the TLS/TCP session terminate for any reason, the devices 464 SHOULD restart/resume HELLOs. When the new TLS/TCP session is 465 started, if possible the OPEN PDU SHOULD try to resume the lost 466 logical session by using the same nonce and resuming from the last 467 Serial Number. 469 Once the TLS/TCP session has been established, the two devices 470 exchange L3ND PDUs, starting with OPENs. 472 8. OPEN 474 Each device has learned the other's IP Address from the HELLO 475 exchange, see Section 6 and established a TLS/TCP session for a 476 particular AFI. 478 The first PDU each sends MUST be an OPEN, and the other side MUST 479 respond with an ACK PDU. 481 0 1 2 3 482 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 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Version = 0 | PDU Type = 2 | Payload Length ~ 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 ~ | Nonce ~ 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 ~ | AttrCount | ~ 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 490 ~ Attribute List ... ~ 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Serial Number | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 The Payload Length is the number of octets in all fields of the PDU 496 from the Nonce through the Serial Number. 498 The Nonce enables detection of a duplicate OPEN PDU. It SHOULD be 499 either a random number or a high resolution timestamp. It is needed 500 to prevent session closure due to a repeated OPEN caused by a race or 501 a dropped or delayed ACK. It can be used to resume a dropped logical 502 session. 504 AttrCount is the number of attributes in the Attribute List. A node 505 may send zero or more attributes. 507 Attributes are single octets the semantics of which are operator- 508 defined, e.g.: spine, leaf, backbone, route reflector, arabica, ... 510 Attribute syntax and semantics are local to an operator or 511 datacenter; hence there is no global registry. Nodes exchange their 512 attributes only in the OPEN PDU. 514 Unlike L3DL [I-D.ietf-lsvr-l3dl], there are no verifiable keys in the 515 PDUs. If the operator wants authentication, integrity, 516 confidentiality, then TLS MUST have been requested by the HELLO and 517 agreed by the TLS session open. 519 The Serial Number is a monotonically increasing 32-bit value 520 representing the sender's state at the time of sending the last PDU. 521 It may be an integer, a timestamp, etc. If incrementing the Serial 522 Number would cause it to be zero, it should be incremented again. 524 On session restart (new OPEN, same Nonce), a receiver MAY send the 525 last received Serial Number to tell the sender to only send data with 526 a Serial Number greater (in the [RFC1982] sense), or send a Serial 527 Number of zero to request all data. 529 This allows a sender of an OPEN to tell the receiver that the sender 530 would like to resume a logical session and that the receiver only 531 needs to send data starting with the PDU with the lowest Serial 532 Number greater (in the [RFC1982] sense) than the one sent in the 533 OPEN. If the sender is not trying to resume a dropped session, the 534 Serial Number MUST be zero. 536 If the receiver of an OPEN PDU with a non-zero Serial Number can not 537 resume from the requested point, it should return an ACK with an 538 Error Code of 2, Session could not be continued. The sender of the 539 failing OPEN PDU SHOULD then send an OPEN PDU with a Serial Number of 540 zero. 542 If a sender of OPEN does not receive an ACK of the OPEN PDU in a 543 configurable time (default 30 seconds), then they SHOULD close or 544 otherwise terminate the TLS/TCP session and restart from the HELLO 545 state. 547 If an OPEN arrives at L3ND speaker A from B with which A believes it 548 already has an L3ND session (i.e. OPENs have already been 549 exchanged), and the Serial Number in B's OPEN PDU is non-zero, 550 speaker A SHOULD establish a new sending session by sending an OPEN 551 with the Serial Number being the same as that of A's last sent and 552 ACKed PDU. A MUST resume sending encapsulations etc. subsequent to 553 the requested Sequence Number. And B MUST retain all previously 554 discovered encapsulation and other data received from A. 556 If an OPEN arrives at L3ND speaker A from B with which A believes it 557 already has an L3ND session (i.e. OPENs have already been 558 exchanged), and the Serial Number in B's OPEN is zero, then the A 559 MUST assume that B's internal state has been reset. All Previously 560 discovered encapsulation data MUST BE discarded; and A MUST respond 561 with a new OPEN with a Serial Number of zero. 563 TCP KeepAlives should be configured and tuned to meet local 564 operational needs. Some defaults and recommendations are needed 565 here. 567 9. ACK 569 The ACK PDU acknowledges receipt of a PDU and reports any error 570 condition which might have been raised. 572 0 1 2 3 573 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 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Version = 0 | PDU Type = 3 | Payload Length = 5 ~ 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 ~ | ACKed PDU | EType | ~ 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 ~ Error Code | Error Hint | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 The ACK acknowledges receipt of an OPEN, Encapsulation, Vendor PDU, 583 etc. 585 The ACKed PDU is the PDU Type of the PDU being acknowledged, e.g., 586 OPEN, one of the Encapsulations, etc. 588 If there was an error processing the received PDU, then the EType is 589 non-zero. If the EType is zero, Error Code and Error Hint MUST also 590 be zero. 592 A non-zero EType is the receiver's way of telling the PDU's sender 593 that the receiver had problems processing the PDU. The Error Code 594 and Error Hint will tell the sender more detail about the error. 596 The decimal value of EType gives a strong hint how the receiver 597 sending the ACK believes things should proceed: 599 0 - No Error, Error Code and Error Hint MUST be zero 601 1 - Warning, something not too serious happened, continue 603 2 - Session should not be continued, try to restart 604 3 - Restart is hopeless, call the operator 606 4-15 - Reserved 608 The Error Codes, noting protocol failures, are listed in 609 Section 16.5. Someone stuck in the 1990s might think the catenation 610 of EType and Error Code as an echo of 0x1zzz, 0x2zzz, etc. They 611 might be right; or not. 613 The Error Hint, an arbitrary 16 bits, is any additional data the 614 sender of the error PDU thinks will help the recipient or the 615 debugger with the particular error. 617 9.1. Retransmission 619 If a PDU sender expects an ACK, e.g. for an OPEN, an Encapsulation, a 620 Vendor PDU, etc., and does not receive the ACK for a configurable 621 time (default three seconds) the TLS/TCP session should be closed or 622 dropped, and both sides revert to HELLO state. 624 10. The Encapsulations 626 Once the devices know each other's IP Addresses, and have established 627 a TLS/TCP session and have successfully exchanged OPENs, the L3ND 628 session is considered established, and the devices SHOULD exchange 629 Layer-3 interface encapsulations, Layer-3 addresses, and Layer-2.5 630 labels. 632 Encapsulations of any AFI/SAFI may be exchanged over a TLS/TCP 633 session irrespective of the AFI/SAFI of the session transport. 635 The Encapsulation types the peers exchange may be IPv4 636 (Section 10.3), IPv6 (Section 10.4), MPLS IPv4 (Section 10.6), MPLS 637 IPv6 (Section 10.7), and/or possibly others not defined here. 639 The sender of an Encapsulation PDU MUST NOT assume that the peer is 640 capable of the same Encapsulation Type. An ACK (Section 9) merely 641 acknowledges receipt. Only if both peers have sent the same 642 Encapsulation Type is it safe for Layer-3 protocols to assume that 643 they are compatible for that type. 645 A receiver of an encapsulation might recognize an addressing 646 conflict, such as both ends of the link trying to use the same 647 address. In this case, the receiver MUST respond with an error 648 (Error Code 2) ACK. As there may be other usable addresses or 649 encapsulations, this error might log and continue, letting an upper 650 layer topology builder deal with what works. 652 Further, to consider a logical link of a type to formally be 653 established so that it may be pushed up to upper layer protocols, the 654 addressing for the type must be compatible, e.g. on the same IP 655 subnet. 657 10.1. The Encapsulation PDU Skeleton 659 The header for all encapsulation PDUs is as follows: 661 0 1 2 3 662 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 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | Version = 0 | PDU Type | Payload Length ~ 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 ~ | Count ~ 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 ~ | Serial Number ~ 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 ~ | Encapsulation List... ~ 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 An Encapsulation PDU describes zero or more addresses of the 674 encapsulation type. 676 The 24-bit Count is the number of Encapsulations in the Encapsulation 677 list. 679 The Serial Number is a monotonically increasing 32-bit value 680 representing the sender's state in time. It may be an integer, a 681 timestamp, etc. On session restart (new OPEN), a receiver MAY send 682 the last received Session Number to tell the sender to only send 683 newer data. 685 If a sender has multiple links on the same interface, separate state: 686 data, ACKs, etc. must be kept for each peer session. 688 Over time, multiple Encapsulation PDUs may be sent for an interface 689 in a session as configuration changes. 691 The Receiver MUST acknowledge the Encapsulation PDU with a Type=3, 692 ACK PDU (Section 9) with the Encapsulation Type being that of the 693 encapsulation being announced, see Section 9. 695 If the Sender does not receive an ACK in a configurable interval 696 (default three seconds), they SHOULD retransmit. After a user 697 configurable number of failures (default three), the L3ND session 698 should be considered dead and the HELLO process SHOULD be restarted. 700 If the link is broken below layer-3, retransmission MAY BE retried if 701 data have not changed in the interim and the TLS/TCP session is still 702 alive. 704 10.2. Encapsulaion Flags 706 The Encapsulation Flags are a sequence of bit fields as follows: 708 0 1 2 3 4 ... 7 709 +------------+------------+------------+------------+------------+ 710 | Ann/With | Primary | Under/Over | Loopback | Reserved ..| 711 +------------+------------+------------+------------+------------+ 713 Each encapsulation in an Encapsulation PDU of Type T may announce new 714 and/or withdraw old encapsulations of Type T. It indicates this with 715 the Ann/With Encapsulation Flag, Announce == 1, Withdraw == 0. 717 Each Encapsulation interface address in an Encapsulation PDU is 718 either a new encapsulation be announced (Ann/With == 1) (yes, a la 719 BGP) or requests one be withdrawn (Ann/With == 0). Adding an 720 encapsulation which already exists SHOULD raise an Announce/Withdraw 721 Error (see Section 16.5); the EType SHOULD be 2, suggesting a session 722 restart (see Section 9 so all encapsulations will be resent. 724 If an interface on a link has multiple addresses for an encapsulation 725 type, one and only one address MAY be marked as primary (Primary Flag 726 == 1) for that Encapsulation Type. 728 An Encapsulation interface address in an Encapsulation PDU MAY be 729 marked as a loopback, in which case the Loopback bit is set. 730 Loopback addresses are generally not seen directly on an external 731 interface. One or more loopback addresses MAY be exposed by 732 configuration on one or more L3ND speaking external interfaces, e.g. 733 for iBGP peering. They SHOULD be marked as such, Loopback Flag == 1. 735 Each Encapsulation interface address in an Encapsulation PDU is that 736 of the direct 'underlay interface (Under/Over == 1), or an 'overlay' 737 address (Under/Over == 0), likely that of a VM or container guest 738 bridged or configured on to the interface already having an underlay 739 address. 741 10.3. IPv4 Encapsulation 743 The IPv4 Encapsulation describes a device's ability to exchange IPv4 744 packets on one or more subnets. It does so by stating the 745 interface's addresses and the corresponding prefix lengths. 747 0 1 2 3 748 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 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | Version = 0 | PDU Type = 4 | Payload Length ~ 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 ~ | Count ~ 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 ~ | Serial Number ~ 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 ~ | Encaps Flags | IPv4 Address ~ 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 ~ | PrefixLen | more ... ~ 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 The 24-bit Count is the sum of the number of IPv4 Encapsulations 762 being announced and/or withdrawn. 764 10.4. IPv6 Encapsulation 766 The IPv6 Encapsulation describes a link's ability to exchange IPv6 767 packets on one or more subnets. It does so by stating the 768 interface's addresses and the corresponding prefix lengths. 770 0 1 2 3 771 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 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | Version = 0 | PDU Type = 5 | Payload Length ~ 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 ~ | Count ~ 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 ~ | Serial Number ~ 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 ~ | Encaps Flags | ~ 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 781 | ~ 782 + + 783 ~ ~ 784 + + 785 ~ IPv6 Prefix ~ 786 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 ~ | PrefixLen | more ... ~ 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 The 24-bit Count is the sum of the number of IPv6 Encapsulations 791 being announced and/or withdrawn. 793 10.5. MPLS Label List 795 As an MPLS enabled interface may have a label stack, see [RFC3032], a 796 variable length list of labels is needed. These are the labels the 797 sender will accept for the prefix to which the list is attached. 799 0 1 2 3 800 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 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Label Count | Label | Exp |S| 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 ~ Label | Exp |S| more ... ~ 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 A Label Count of zero is an implicit withdraw of all labels for that 808 prefix on that interface. 810 10.6. MPLS IPv4 Encapsulation 812 The MPLS IPv4 Encapsulation describes a logical link's ability to 813 exchange labeled IPv4 packets on one or more subnets. It does so by 814 stating the interface's addresses the corresponding prefix lengths, 815 and the corresponding labels which will be accepted for each address. 817 0 1 2 3 818 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 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 | Version = 0 | PDU Type = 6 | Payload Length ~ 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 ~ | Count ~ 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 ~ | Serial Number ~ 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 ~ | Encaps Flags | MPLS Label List ... ~ 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | IPv4 Address | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | PrefixLen | more ... ~ 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 The 24-bit Count is the sum of the number of MPLSv4 Encapsulation 834 being announced and/or withdrawn. 836 10.7. MPLS IPv6 Encapsulation 838 The MPLS IPv6 Encapsulation describes a logical link's ability to 839 exchange labeled IPv6 packets on one or more subnets. It does so by 840 stating the interface's addresses, the corresponding prefix lengths, 841 and the corresponding labels which will be accepted for each address. 843 0 1 2 3 844 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 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | Version = 0 | PDU Type = 7 | Payload Length ~ 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 ~ | Count ~ 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 ~ | Serial Number ~ 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 ~ | Encaps Flags | MPLS Label List ... | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | ~ 855 + + 856 ~ ~ 857 + IPv6 Address + 858 ~ ~ 859 + + 860 ~ | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | Prefix Len | more ... ~ 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 The 24-bit Count is the sum of the number of MPLSv6 Encapsulations 866 being announced and/or withdrawn. 868 11. VENDOR - Vendor Extensions 870 0 1 2 3 871 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 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | Version = 0 | PDU Type = 255| Payload Length ~ 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 ~ | Serial Number ~ 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 ~ | Enterprise Number ~ 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 ~ | Ent Type | Enterprise Data ... ~ 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 Vendors or enterprises may define TLVs beyond the scope of L3ND 882 standards. This is done using a Private Enterprise Number [IANA-PEN] 883 followed by Enterprise Data in a format defined for that Enterprise 884 Number and Ent Type. 886 Ent Type allows a Vendor PDU to be sub-typed in the event that the 887 vendor/enterprise needs multiple PDU types. 889 As with Encapsulation PDUs, a receiver of a Vendor PDU MUST respond 890 with an ACK or an ERROR PDU. Similarly, a Vendor PDU MUST only be 891 sent over an open session. 893 12. Discussion 895 This section explores some trade-offs taken and some considerations. 897 12.1. HELLO Discussion 899 A device may send IP packets an Layer-3 interface which transmits 900 data over a single Layer-2 interface or multiple Layer-2 interfaces. 901 Packets sourced by one Layer-3 IP interface over multiple Layer-2 902 should consider that an Layer-3 interface with multiple Layer-2 903 interfaces could have many devices which might come at various times, 904 therefore the configured HELLO PDU retransmit time SHOULD be set to a 905 non-zero value, and periodic HELLOs should continue. Packets 906 transmitted on a single Layer-2 interface on a point-to-point (p2p) 907 connection, MAY set the configuration value to zero, so once a TLS/ 908 TCP session is up, HELLOs are no longer desirable. 910 A device with multiple Layer-2 interfaces, traditionally called a 911 switch, may be used to forward frames and therefore packets from 912 multiple devices to one Layer-3 interface, I, on an L3ND speaking 913 device. Interface I could discover a peer J across the switch. 914 Later, a prospective peer K could come up across the switch. If I 915 was not still sending and listening for HELLOs, the potential peering 916 with K could not be discovered. Therefore, on multi-link interfaces, 917 L3ND MUST continue to send HELLOs as long as they are turned up. 919 13. VLANs/SVIs/Sub-interfaces 921 One can think of the protocol as an instance (i.e. state machine) 922 which runs on each logical link of a device. 924 As the upper routing layer must view VLAN topologies as separate 925 graphs, L3ND treats VLAN ports as separate links. 927 As Sub-Interfaces each have their own layer-3 identities, they act as 928 separate interfaces, forming their own links. 930 14. Implementation Considerations 932 An implementation SHOULD provide the ability to configure each 933 logical interface as L3ND speaking or not. 935 An implementation SHOULD provide the ability to distribute one or 936 more loopback addresses or interfaces into L3ND on an external L3ND 937 speaking interface. 939 An implementation SHOULD provide the ability to distribute one or 940 more overlay and/or underlay addresses or interfaces into L3ND on an 941 external L3ND speaking interface. 943 An implementation SHOULD provide the ability to configure one of the 944 addresses of an encapsulation as primary on an L3ND speaking 945 interface. If there is only one address for a particular 946 encapsulation, the implementation MAY mark it as primary by default. 948 An implementation MAY allow optional configuration which updates the 949 local forwarding table with overlay and underlay data both learned 950 from L3ND peers and configured locally. 952 15. Security Considerations 954 For TLS, version 1.1 or later MUST be used. 956 The protocol as is MUST NOT be used outside a datacenter or similarly 957 closed environment without using TLS encapsulation which is based on 958 a configured CA trust anchor. 960 Many datacenter operators have a strange belief that physical walls 961 and firewalls provide sufficient security. This is not credible. 962 All DC protocols need to be examined for exposure and attack surface. 963 In the case of L3ND, authentication and integrity as provided by TLS 964 validated to a configured shared CA trust anchor is strongly 965 RECOMMENDED. 967 It is generally unwise to assume that on the wire Layer-3 is secure. 968 Strange/unauthorized devices may plug into a port. Mis-wiring is 969 very common in datacenter installations. A poisoned laptop might be 970 plugged into a device's port, form malicious sessions, etc. to 971 divert, intercept, or drop traffic. 973 Similarly, malicious nodes/devices could mis-announce addressing. 975 If OPEN PDUs are not over validated TLS, an attacker could forge an 976 OPEN for an existing session and cause the session to be reset. 978 16. IANA Considerations 980 16.1. Link Local Layer-3 Addresses 982 IANA is requested to assignment one address (TBD1) for L3DL-L3-LL 983 from the IPv4 Multicast Address Space Registry from the Local Network 984 Control Block (224.0.0.0 - 224.0.0.255 (224.0.0/24)). 986 IANA is requested to assign one address (TBD2) for L3DL-L3-LL from 987 the IPv6 Multicast Address Space Registry in the the IPv6 Link-Local 988 Scope Multicast address (TBD:2). 990 16.2. Ports for TLS/TCP 992 This document requests the IANA to assign a well-known TCP Port 993 Number (TBD3) to the Layer-3 Neighbor Discovery Protocol for the 994 following, see Section 7: 996 l3nd-server 998 16.3. PDU Types 1000 This document requests the IANA create a registry for L3ND PDU Type, 1001 which may range from 0 to 255. The name of the registry should be 1002 L3ND-PDU-Type. The policy for adding to the registry is RFC Required 1003 per [RFC5226], either standards track or experimental. The initial 1004 entries should be the following: 1006 PDU 1007 Code PDU Name 1008 ---- ------------------- 1009 0 HELLO 1010 1 reserved 1011 2 OPEN 1012 3 ACK 1013 4 IPv4 Announcement 1014 5 IPv6 Announcement 1015 6 MPLS IPv4 Announcement 1016 7 MPLS IPv6 Announcement 1017 8-254 Reserved 1018 255 Vendor 1020 16.4. Flag Bits 1022 This document requests the IANA create a registry for L3ND PL Flag 1023 Bits, which may range from 0 to 7. The name of the registry should 1024 be L3ND-PL-Flag-Bits. The policy for adding to the registry is RFC 1025 Required per [RFC5226], either standards track or experimental. The 1026 initial entries should be the following: 1028 Bit Bit Name 1029 ---- ------------------- 1030 0 Announce/Withdraw (ann == 0) 1031 1 Primary 1032 2 Underlay/Overlay (under == 0) 1033 3 Loopback 1034 4-7 Reserved 1036 16.5. Error Codes 1038 This document requests the IANA create a registry for L3ND Error 1039 Codes, a 16 bit integer. The name of the registry should be L3ND- 1040 Error-Codes. The policy for adding to the registry is RFC Required 1041 per [RFC5226], either standards track or experimental. The initial 1042 entries should be the following: 1044 Error 1045 Code Error Name 1046 ---- ------------------- 1047 0 No Error 1048 1 Checksum Error 1049 2 Logical Link Addressing Conflict 1050 3 reserved 1051 4 Announce/Withdraw Error 1053 17. Acknowledgments 1055 Many kind people helped with the Layer-2 cousin of this protocol, 1056 L3DL. Cristel Pelsser provided multiple reviews, Harsha Kovuru 1057 commented during implementation, Jeff Haas reviewed and commented, 1058 Joerg Ott did an early but deep transport review, Joe Clarke provided 1059 a useful ops review, John Scudder a deeply serious review and 1060 comments, Martijn Schmidt contributed, and Neeraj Malhotra reviewed. 1062 18. References 1064 18.1. Normative References 1066 [I-D.ietf-lsvr-l3dl] 1067 Bush, R., Austein, R., and K. Patel, "Layer-3 Discovery 1068 and Liveness", Work in Progress, Internet-Draft, draft- 1069 ietf-lsvr-l3dl-08, 14 October 2021, 1070 . 1073 [IANA-PEN] "IANA Private Enterprise Numbers", 1074 . 1077 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1078 Requirement Levels", BCP 14, RFC 2119, 1079 DOI 10.17487/RFC2119, March 1997, 1080 . 1082 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1083 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1084 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 1085 . 1087 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1088 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1089 DOI 10.17487/RFC4271, January 2006, 1090 . 1092 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 1093 Pignataro, "The Generalized TTL Security Mechanism 1094 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 1095 . 1097 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1098 IANA Considerations Section in RFCs", RFC 5226, 1099 DOI 10.17487/RFC5226, May 2008, 1100 . 1102 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1103 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1104 May 2017, . 1106 18.2. Informative References 1108 [Clos] "Clos Network", 1109 . 1111 [I-D.ymbk-idr-l3nd-ulpc] 1112 Bush, R. and K. Patel, "L3ND Upper-Layer Protocol 1113 Configuration", Work in Progress, Internet-Draft, draft- 1114 ymbk-idr-l3nd-ulpc-02, 27 February 2022, 1115 . 1118 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1119 Communication Layers", STD 3, RFC 1122, 1120 DOI 10.17487/RFC1122, October 1989, 1121 . 1123 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 1124 DOI 10.17487/RFC1982, August 1996, 1125 . 1127 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1128 "Multiprotocol Extensions for BGP-4", RFC 4760, 1129 DOI 10.17487/RFC4760, January 2007, 1130 . 1132 Authors' Addresses 1134 Randy Bush 1135 Arrcus & Internet Initiative Japan 1136 5147 Crystal Springs 1137 Bainbridge Island, WA 98110 1138 United States of America 1139 Email: randy@psg.com 1141 Russ Housley 1142 Vigil Security, LLC 1143 516 Dranesville Road 1144 Herndon, VA 20170 1145 United States of America 1146 Email: housley@vigilsec.com 1148 Rob Austein 1149 Arrcus, Inc 1150 Email: sra@hactrn.net 1152 Susan Hares 1153 Hickory Hill Consulting 1154 7453 Hickory Hill 1155 Saline, MI 48176 1156 United States of America 1157 Phone: +1-734-604-0332 1158 Email: shares@ndzh.com 1159 Keyur Patel 1160 Arrcus 1161 2077 Gateway Place, Suite #400 1162 San Jose, CA 95119 1163 United States of America 1164 Email: keyur@arrcus.com