idnits 2.17.00 (12 Aug 2021) /tmp/idnits44380/draft-ymbk-idr-l3nd-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == 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 (17 February 2022) is 93 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-00 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: 21 August 2022 Vigil Security 6 R. Austein 7 Arrcus 8 S. Hares 9 Hickory Hill Consulting 10 K. Patel 11 Arrcus 12 17 February 2022 14 Layer-3 Neighbor Discovery 15 draft-ymbk-idr-l3nd-00 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 21 August 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 7. TCP Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 8. OPEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 9. ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 9.1. Retransmission . . . . . . . . . . . . . . . . . . . . . 14 75 10. The Encapsulations . . . . . . . . . . . . . . . . . . . . . 14 76 10.1. The Encapsulation PDU Skeleton . . . . . . . . . . . . . 14 77 10.2. Encapsulaion Flags . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . . 21 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 . . . . . . . . . . . . . . . . . . . . . . . 22 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 Layer-3 Neighbor Discovery (L3ND) provides brutally simple mechanisms 111 for neighboring devices to 113 * Discover each other's IP Addresses, 115 * Discover mutually supported layer-3 encapsulations, e.g. IP/MPLS, 117 * Discover Layer-3 IP and/or MPLS addressing of interfaces of the 118 encapsulations, 120 * Provide for authenticity and verification of protocol messages. 122 In this document, the use case for L3ND is for point to point links 123 in a datacenter Clos ([Clos]) in order to exchange the data needed 124 for bootstrapping BGP-based peering, EVPNs, etc. Once IP 125 connectivity has been leveraged to get layer-3 addressability and 126 forwarding capabilities, normal IP forwarding and routing can take 127 over. 129 L3ND might be found to be widely applicable to a range of routing and 130 similar protocols which need Layer-3 neighbor discovery. 132 2. Terminology 134 Even though it concentrates on the inter-device layer, this document 135 relies heavily on routing terminology. The following attempts to 136 clarify the use of some possibly confusing terms: 138 Clos: A hierarchic subset of a crossbar switch topology commonly 139 used in data centers [Clos]. 141 Datagram: The L3ND content of a single Layer-3 UDP Datagram. 143 Encapsulation: Address Family Indicator and Subsequent Address 144 Family Indicator (AFI/SAFI). I.e. classes of Layer-2.5 145 and Layer-3 addresses such as IPv4, IPv6, MPLS. 147 Link or Logical Link: A logical connection between two interfaces on 148 two different devices. E.g. two VLANs between the same 149 two ports are two links. 151 MDC: Massive Data Center, commonly composed of thousands of Top 152 of Rack Switches (TORs). 154 MTU: Maximum Transmission Unit, the size in octets of the 155 largest packet that can be sent on a medium, see [RFC1122] 156 1.3.3. 158 PDU: Protocol Data Unit, an L3ND application layer message. A 159 PDU's content may need to be broken into multiple 160 Datagrams to make it through MTU or other restrictions. 162 Session: An established, via exchange of OPEN PDUs, session between 163 two L3ND capable IP interfaces on a link. 165 TOR Switch: Top Of Rack switch, aggregates the servers in a rack and 166 connects to aggregation layers of the Clos tree, AKA the 167 Clos spine. 169 3. Background 171 L3ND is primarily designed for a Clos type datacenter scale and 172 topology, but can accommodate richer topologies which contain 173 potential cycles. 175 While L3ND is designed for the MDC, there are no inherent reasons it 176 could not run on a WAN. The authentication and authorization needed 177 to run safely on a WAN need to be considered, and the appropriate 178 level of security options chosen. 180 The number of addresses of one Encapsulation type on an interface 181 link may be quite large given a TOR switch with tens of servers, each 182 server having a few hundred micro-services, resulting in an 183 inordinate number of addresses. And highly automated micro-service 184 migration can cause serious address prefix disaggregation, resulting 185 in interfaces with thousands of disaggregated prefixes. 187 To meet such scaling needs, the L3ND protocol is session oriented and 188 uses incremental announcement and withdrawal with session restart, a 189 la BGP ([RFC4271]). 191 4. Inter-Link Protocol Overview 193 A device broadcasts a Layer-3 Multicast UDP datagram (HELLO) 194 containing the port number that is willing to serve a TLS or raw TCP 195 connection to support the data exchange of the rest of the protocol 196 in a reliable and preferably authenticated manner. 198 Another device on the link then establishes a TLS or raw TCP session 199 in which inter-device PDUs are used to exchange device and logical 200 link identities and layer-2.5 (MPLS) and 3 identifiers (not 201 payloads), e.g. more IP Addresses, loopback addresses, port 202 identities, and Encapsulations. 204 To assure discovery of new devices coming up on a multi-link 205 topology, devices on such a topology, and only on a multi-link 206 topology, send periodic HELLOs forever, see Section 12.1. 208 Given the TLS/TCP session, OPEN PDUs (Section 8) are exchanged, the 209 Encapsulations (Section 10) configured on an end point may be 210 announced and modified. Note that these are only the encapsulation 211 and addresses configured on the announcing interface; though a 212 device's loopback and overlay interface(s) may also be announced. 214 4.1. L3ND Ladder Diagram 216 The HELLO, Section 6, is a priming message sent on all logical links 217 configured for L3ND. It is a small L3ND Multicast UDP PDU with the 218 simple goal of advertising a TLS/TCP service available on an 219 advertised port on the sending IP interface. 221 The HELLO PDU is either IPv4 or IPv6, which selects the AFI to be 222 used for the rest of the session(s) between end-points. Two 223 endpoints MAY establish a link for each AFI. 225 An interface on the link receiving the HELLO PDU attempts to 226 establish a TLS or raw TCP, as specified by the HELLO, session to the 227 source IP address of the HELLO on the port advertised in the HELLO. 229 The OPEN, Section 8 PDUs, used to exchange details about the L3ND 230 session, and the ACK/ERROR PDU, are mandatory; other PDUs are 231 optional; though at least one encapsulation SHOULD be agreed at some 232 point. 234 Like Multi-Protocol BGP, [RFC4760], an L3ND session running over one 235 AFI MAY carry encapsulations etc. of different AFIs, 237 A L3DL extension, [I-D.ymbk-idr-l3nd-ulpc], describes the next upper 238 layer L3DL protocol to exchange BGP parameter information. 240 The following is a ladder-style diagram of the L3ND protocol 241 exchanges: 243 | HELLO | Logical Link Peer discovery 244 |---------------------------->| 245 | TCP OPEN | Mandatory 246 |<----------------------------| 247 | | 248 | | 249 | OPEN | IDs, security, etc. 250 |---------------------------->| 251 | ACK | 252 |<----------------------------| 253 | | 254 | OPEN | Mandatory 255 |<----------------------------| 256 | ACK | 257 |---------------------------->| 258 | | 259 | | 260 | Interface IPv4 Addresses | Interface IPv4 Addresses 261 |---------------------------->| Optional 262 | ACK | 263 |<----------------------------| 264 | | 265 | Interface IPv4 Addresses | 266 |<----------------------------| 267 | ACK | 268 |---------------------------->| 269 | | 270 | | 271 | Interface IPv6 Addresses | Interface IPv6 Addresses 272 |---------------------------->| Optional 273 | ACK | 274 |<----------------------------| 275 | | 276 | Interface IPv6 Addresses | 277 |<----------------------------| 278 | ACK | 279 |---------------------------->| 280 | | 281 | | 282 | Interface MPLSv4 Labels | Interface MPLSv4 Labels 283 |---------------------------->| Optional 284 | ACK | 285 |<----------------------------| 286 | | 287 | Interface MPLSv4 Labels | Interface MPLSv4 Labels 288 |<----------------------------| Optional 289 | ACK | 290 |---------------------------->| 291 | | 292 | | 293 | Interface MPLSv6 Labels | Interface MPLSv6 Labels 294 |---------------------------->| Optional 295 | ACK | 296 |<----------------------------| 297 | | 298 | Interface MPLSv6 Labels | Interface MPLSv6 Labels 299 |<----------------------------| Optional 300 | ACK | 301 |---------------------------->| 303 5. TLV PDUs 305 The basic L3ND application layer PDU is a typical TLV (Type Length 306 Value) PDU. As it is transported over TCP, integrity is assured. 307 When it is transported over TLS, authenticity is also provided. 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Version = 0 | PDU Type | Payload Length ~ 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 ~ | ~ 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 316 ~ Payload ... ~ 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 The fields of the basic L3ND header are as follows: 321 Version: An integer differentiating versions of the L3ND protocol. 322 Currently only Version 0 MAY BE specified. 324 PDU Type: An integer differentiating PDU payload types. See 325 Section 16.3. 327 Payload Length: Total number of octets in the Payload field. 329 Payload: The application layer content of the L3ND PDU. 331 6. HELLO 332 0 1 2 3 333 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 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Version = 0 | PDU Type = 0 | Payload Length = 24 ~ 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 ~ | Flags | Port ~ 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 ~ | 340 +-+-+-+-+-+-+-+-+ 342 Flags (bit): 343 0 - 0 Raw TCP, 1 TLS 344 1 - 0 Self-Signed Cert for TLS, 1 CA-based 346 The Payload Length is 24 to cover the Flags and Port fields. 348 The Port is the TCP Port Number (default is TBD3) on which the HELLO 349 sender MUST have a waiting TLS/TCP (as specified in Flags) server 350 listening. Though the IANA assigned well-known port SHOULD be used, 351 this field allows configuration of alternate ports. 353 The IPv4 UDP packets are sent to the IPv4 link local multicast 354 address (TBD1) and the IPv6 UDP packets are sent to an IPv6 link 355 Local multicast address (TBD2). See Section 12.1 for why multicast 356 is used. 358 The HELLO PDU solicits a unicast TLS/TCP open request(s) of the same 359 AFI from other devices on the link. 361 When a HELLO is received from a source IP address with which there is 362 no established TLS/TCP L3ND session, the receiver SHOULD respond by 363 sending a TLS/TCP client open request, using the same AFI, to the 364 source IP address of the HELLO to establish an L3ND TLS/TCP session. 366 All L3ND PDUs other than HELLO are sent via TLS/TCP, as the server's 367 destination IP address is known after the HELLO. 369 When an interface is turned up on a device, it SHOULD issue a HELLO 370 if it is to participate in L3ND sessions and repeat HELLOs at a 371 configured interval, with a default of 60 seconds. 373 If the configured multicast destination address is one that is 374 propagated by switches, the HELLO SHOULD be repeated at a configured 375 interval, with a default of 60 seconds. This allows discovery by new 376 devices which come up on the mesh. In this multi-link scenario, the 377 operator should be aware of the trade-off between timer tuning and 378 network noise and adjust the inter-HELLO timer accordingly. 380 By default, GTSM, [RFC5082], SHOULD be enabled to test that a 381 received HELLO MUST be on the local link. It MAY be disabled by 382 configuration. GTSM check failures SHOULD be logged, though with 383 rate limiting to keep from overwhelming logs. 385 If more than one device responds, one adjacency is formed for each 386 unique source IP address. L3ND treats each adjacency as a separate 387 logical link. 389 To ameliorate possible load spikes during bootstrap or event 390 recovery, there SHOULD be a jittered delay between receipt of a HELLO 391 and TLS/TCP open. The default delay range SHOULD be zero to five 392 seconds, and MUST be configurable. 394 If a HELLO is received from an IP Address with which there is an 395 established session for that AFI, the HELLO should be dropped. 397 A device with a TLS/TCP listener SHOULD log or otherwise report 398 repeated failed inbound attempts. 400 7. TCP Set-Up 402 If the receiver of a HELLO does not agree with the sender's choice of 403 TLS/TCP or does not agree with the verification choice, Self-Signed 404 or CA-based, the receiver SHOULD respond with a HELLO specifying its 405 preferences. 407 As it is assumed that the configured deployment of a data center 408 would have compatible parameters on all devices, any disagreement 409 over TLS/TCP or trust anchors MUST be logged. 411 By default, GTSM, [RFC5082], SHOULD be enabled to ensure that a SYN 412 received in response to a HELLO is on the local link. It MAY be 413 disabled by configuration. GTSM check failures SHOULD be logged, 414 though with rate limiting to keep from overwhelming logs. 416 If the receiver of a HELLO agrees with the sender's choice of TLS/TCP 417 and authentication, both sides have agreed on an AFI for the 418 transport and on each other's IP address in that AFI. This is 419 sufficient to open a TCP session between them, which will allow for 420 very large data PDUs while obviating the need to invent complex 421 transports. 423 The server, the sender of the HELLO, listens on the advertised port 424 for the TLS/TCP session open. The receiver of the acceptable HELLO, 425 the TLS/TCP client, initiates a TLS or raw TCP session with the 426 sender of the HELLO, the TLS/TCP server, preferably TLS, as 427 advertised. If TLS, the server has chosen and signaled either a 428 self-signed certificate or one configured from the operational CA 429 trusted by both parties, as negotiated in the HELLO exchange. 431 Once the TLS/TCP session is established, if the link is configured as 432 point to point, the client side SHOULD stop listening on any port for 433 which it has sent a HELLO. The server side SHOULD stop sending 434 HELLOs. 436 If the TLS/TCP open fails, then this SHOULD be logged and the parties 437 MUST go back to the initial state and try HELLO. 439 Should an interface with an established TLS/TCP session be 440 reconfigured changing the TLS/TCP parameters, the TLS/TCP session 441 should be closed or torn down. 443 Should the TLS/TCP session terminate for any reason, the devices 444 SHOULD restart/resume HELLOs. When the new TLS/TCP session is 445 started, if possible the OPEN PDU SHOULD try to resume the lost 446 logical session by using the same nonce and resuming from the last 447 Serial Number. 449 Once the TLS/TCP session has been established, the two devices 450 exchange L3ND PDUs, starting with OPENs. 452 8. OPEN 454 Each device has learned the other's IP Address from the HELLO 455 exchange, see Section 6 and established a TLS/TCP session for a 456 particular AFI. 458 The first PDU each sends MUST be an OPEN, and the other side MUST 459 respond with an ACK PDU. 461 0 1 2 3 462 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 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Version = 0 | PDU Type = 2 | Payload Length ~ 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 ~ | Nonce ~ 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 ~ | AttrCount | ~ 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 470 ~ Attribute List ... ~ 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Serial Number | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 The Payload Length is the number of octets in all fields of the PDU 476 from the Nonce through the Serial Number. 478 The Nonce enables detection of a duplicate OPEN PDU. It SHOULD be 479 either a random number or a high resolution timestamp. It is needed 480 to prevent session closure due to a repeated OPEN caused by a race or 481 a dropped or delayed ACK. It can be used to resume a dropped logical 482 session. 484 AttrCount is the number of attributes in the Attribute List. A node 485 may send zero or more attributes. 487 Attributes are single octets the semantics of which are operator- 488 defined, e.g.: spine, leaf, backbone, route reflector, arabica, ... 490 Attribute syntax and semantics are local to an operator or 491 datacenter; hence there is no global registry. Nodes exchange their 492 attributes only in the OPEN PDU. 494 Unlike L3DL [I-D.ietf-lsvr-l3dl], there are no verifiable keys in the 495 PDUs. If the operator wants authentication, integrity, 496 confidentiality, then TLS MUST have been requested by the HELLO and 497 agreed by the TLS session open. 499 The Serial Number is a monotonically increasing 32-bit value 500 representing the sender's state at the time of sending the last PDU. 501 It may be an integer, a timestamp, etc. If incrementing the Serial 502 Number would cause it to be zero, it should be incremented again. 504 On session restart (new OPEN, same Nonce), a receiver MAY send the 505 last received Serial Number to tell the sender to only send data with 506 a Serial Number greater (in the [RFC1982] sense), or send a Serial 507 Number of zero to request all data. 509 This allows a sender of an OPEN to tell the receiver that the sender 510 would like to resume a logical session and that the receiver only 511 needs to send data starting with the PDU with the lowest Serial 512 Number greater (in the [RFC1982] sense) than the one sent in the 513 OPEN. If the sender is not trying to resume a dropped session, the 514 Serial Number MUST be zero. 516 If the receiver of an OPEN PDU with a non-zero Serial Number can not 517 resume from the requested point, it should return an ACK with an 518 Error Code of 2, Session could not be continued. The sender of the 519 failing OPEN PDU SHOULD then send an OPEN PDU with a Serial Number of 520 zero. 522 If a sender of OPEN does not receive an ACK of the OPEN PDU in a 523 configurable time (default 30 seconds), then they SHOULD close or 524 otherwise terminate the TLS/TCP session and restart from the HELLO 525 state. 527 If an OPEN arrives at L3ND speaker A from B with which A believes it 528 already has an L3ND session (i.e. OPENs have already been 529 exchanged), and the Serial Number in B's OPEN PDU is non-zero, 530 speaker A SHOULD establish a new sending session by sending an OPEN 531 with the Serial Number being the same as that of A's last sent and 532 ACKed PDU. A MUST resume sending encapsulations etc. subsequent to 533 the requested Sequence Number. And B MUST retain all previously 534 discovered encapsulation and other data received from A. 536 If an OPEN arrives at L3ND speaker A from B with which A believes it 537 already has an L3ND session (i.e. OPENs have already been 538 exchanged), and the Serial Number in B's OPEN is zero, then the A 539 MUST assume that B's internal state has been reset. All Previously 540 discovered encapsulation data MUST BE discarded; and A MUST respond 541 with a new OPEN with a Serial Number of zero. 543 TCP KeepAlives should be configured and tuned to meet local 544 operational needs. Some defaults and recommendations are needed 545 here. 547 9. ACK 549 The ACK PDU acknowledges receipt of a PDU and reports any error 550 condition which might have been raised. 552 0 1 2 3 553 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 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Version = 0 | PDU Type = 3 | Payload Length = 5 ~ 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 ~ | ACKed PDU | EType | ~ 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 ~ Error Code | Error Hint | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 The ACK acknowledges receipt of an OPEN, Encapsulation, Vendor PDU, 563 etc. 565 The ACKed PDU is the PDU Type of the PDU being acknowledged, e.g., 566 OPEN, one of the Encapsulations, etc. 568 If there was an error processing the received PDU, then the EType is 569 non-zero. If the EType is zero, Error Code and Error Hint MUST also 570 be zero. 572 A non-zero EType is the receiver's way of telling the PDU's sender 573 that the receiver had problems processing the PDU. The Error Code 574 and Error Hint will tell the sender more detail about the error. 576 The decimal value of EType gives a strong hint how the receiver 577 sending the ACK believes things should proceed: 579 0 - No Error, Error Code and Error Hint MUST be zero 581 1 - Warning, something not too serious happened, continue 583 2 - Session should not be continued, try to restart 585 3 - Restart is hopeless, call the operator 587 4-15 - Reserved 589 The Error Codes, noting protocol failures, are listed in 590 Section 16.5. Someone stuck in the 1990s might think the catenation 591 of EType and Error Code as an echo of 0x1zzz, 0x2zzz, etc. They 592 might be right; or not. 594 The Error Hint, an arbitrary 16 bits, is any additional data the 595 sender of the error PDU thinks will help the recipient or the 596 debugger with the particular error. 598 9.1. Retransmission 600 If a PDU sender expects an ACK, e.g. for an OPEN, an Encapsulation, a 601 Vendor PDU, etc., and does not receive the ACK for a configurable 602 time (default three seconds) the TLS/TCP session should be closed or 603 dropped, and both sides revert to HELLO state. 605 10. The Encapsulations 607 Once the devices know each other's IP Addresses, and have established 608 a TLS/TCP session and have successfully exchanged OPENs, the L3ND 609 session is considered established, and the devices SHOULD exchange 610 Layer-3 interface encapsulations, Layer-3 addresses, and Layer-2.5 611 labels. 613 Encapsulations of any AFI/SAFI may be exchanged over a TLS/TCP 614 session irrespective of the AFI/SAFI of the session transport. 616 The Encapsulation types the peers exchange may be IPv4 617 (Section 10.3), IPv6 (Section 10.4), MPLS IPv4 (Section 10.6), MPLS 618 IPv6 (Section 10.7), and/or possibly others not defined here. 620 The sender of an Encapsulation PDU MUST NOT assume that the peer is 621 capable of the same Encapsulation Type. An ACK (Section 9) merely 622 acknowledges receipt. Only if both peers have sent the same 623 Encapsulation Type is it safe for Layer-3 protocols to assume that 624 they are compatible for that type. 626 A receiver of an encapsulation might recognize an addressing 627 conflict, such as both ends of the link trying to use the same 628 address. In this case, the receiver MUST respond with an error 629 (Error Code 2) ACK. As there may be other usable addresses or 630 encapsulations, this error might log and continue, letting an upper 631 layer topology builder deal with what works. 633 Further, to consider a logical link of a type to formally be 634 established so that it may be pushed up to upper layer protocols, the 635 addressing for the type must be compatible, e.g. on the same IP 636 subnet. 638 10.1. The Encapsulation PDU Skeleton 640 The header for all encapsulation PDUs is as follows: 642 0 1 2 3 643 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 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Version = 0 | PDU Type | Payload Length ~ 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 ~ | Count ~ 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 ~ | Serial Number ~ 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 ~ | Encapsulation List... ~ 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 An Encapsulation PDU describes zero or more addresses of the 655 encapsulation type. 657 The 24-bit Count is the number of Encapsulations in the Encapsulation 658 list. 660 The Serial Number is a monotonically increasing 32-bit value 661 representing the sender's state in time. It may be an integer, a 662 timestamp, etc. On session restart (new OPEN), a receiver MAY send 663 the last received Session Number to tell the sender to only send 664 newer data. 666 If a sender has multiple links on the same interface, separate state: 667 data, ACKs, etc. must be kept for each peer session. 669 Over time, multiple Encapsulation PDUs may be sent for an interface 670 in a session as configuration changes. 672 The Receiver MUST acknowledge the Encapsulation PDU with a Type=3, 673 ACK PDU (Section 9) with the Encapsulation Type being that of the 674 encapsulation being announced, see Section 9. 676 If the Sender does not receive an ACK in a configurable interval 677 (default three seconds), they SHOULD retransmit. After a user 678 configurable number of failures (default three), the L3ND session 679 should be considered dead and the HELLO process SHOULD be restarted. 681 If the link is broken below layer-3, retransmission MAY BE retried if 682 data have not changed in the interim and the TLS/TCP session is still 683 alive. 685 10.2. Encapsulaion Flags 687 The Encapsulation Flags are a sequence of bit fields as follows: 689 0 1 2 3 4 ... 7 690 +------------+------------+------------+------------+------------+ 691 | Ann/With | Primary | Under/Over | Loopback | Reserved ..| 692 +------------+------------+------------+------------+------------+ 694 Each encapsulation in an Encapsulation PDU of Type T may announce new 695 and/or withdraw old encapsulations of Type T. It indicates this with 696 the Ann/With Encapsulation Flag, Announce == 1, Withdraw == 0. 698 Each Encapsulation interface address in an Encapsulation PDU is 699 either a new encapsulation be announced (Ann/With == 1) (yes, a la 700 BGP) or requests one be withdrawn (Ann/With == 0). Adding an 701 encapsulation which already exists SHOULD raise an Announce/Withdraw 702 Error (see Section 16.5); the EType SHOULD be 2, suggesting a session 703 restart (see Section 9 so all encapsulations will be resent. 705 If an interface on a link has multiple addresses for an encapsulation 706 type, one and only one address MAY be marked as primary (Primary Flag 707 == 1) for that Encapsulation Type. 709 An Encapsulation interface address in an Encapsulation PDU MAY be 710 marked as a loopback, in which case the Loopback bit is set. 711 Loopback addresses are generally not seen directly on an external 712 interface. One or more loopback addresses MAY be exposed by 713 configuration on one or more L3ND speaking external interfaces, e.g. 714 for iBGP peering. They SHOULD be marked as such, Loopback Flag == 1. 716 Each Encapsulation interface address in an Encapsulation PDU is that 717 of the direct 'underlay interface (Under/Over == 1), or an 'overlay' 718 address (Under/Over == 0), likely that of a VM or container guest 719 bridged or configured on to the interface already having an underlay 720 address. 722 10.3. IPv4 Encapsulation 724 The IPv4 Encapsulation describes a device's ability to exchange IPv4 725 packets on one or more subnets. It does so by stating the 726 interface's addresses and the corresponding prefix lengths. 728 0 1 2 3 729 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 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | Version = 0 | PDU Type = 4 | Payload Length ~ 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 ~ | Count ~ 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 ~ | Serial Number ~ 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 ~ | Encaps Flags | IPv4 Address ~ 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 ~ | PrefixLen | more ... ~ 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 The 24-bit Count is the sum of the number of IPv4 Encapsulations 743 being announced and/or withdrawn. 745 10.4. IPv6 Encapsulation 747 The IPv6 Encapsulation describes a link's ability to exchange IPv6 748 packets on one or more subnets. It does so by stating the 749 interface's addresses and the corresponding prefix lengths. 751 0 1 2 3 752 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 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | Version = 0 | PDU Type = 5 | Payload Length ~ 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 ~ | Count ~ 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 ~ | Serial Number ~ 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 ~ | Encaps Flags | ~ 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 762 | ~ 763 + + 764 ~ ~ 765 + + 766 ~ IPv6 Prefix ~ 767 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 ~ | PrefixLen | more ... ~ 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 The 24-bit Count is the sum of the number of IPv6 Encapsulations 772 being announced and/or withdrawn. 774 10.5. MPLS Label List 776 As an MPLS enabled interface may have a label stack, see [RFC3032], a 777 variable length list of labels is needed. These are the labels the 778 sender will accept for the prefix to which the list is attached. 780 0 1 2 3 781 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 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | Label Count | Label | Exp |S| 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 ~ Label | Exp |S| more ... ~ 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 A Label Count of zero is an implicit withdraw of all labels for that 789 prefix on that interface. 791 10.6. MPLS IPv4 Encapsulation 793 The MPLS IPv4 Encapsulation describes a logical link's ability to 794 exchange labeled IPv4 packets on one or more subnets. It does so by 795 stating the interface's addresses the corresponding prefix lengths, 796 and the corresponding labels which will be accepted for each address. 798 0 1 2 3 799 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 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | Version = 0 | PDU Type = 6 | Payload Length ~ 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 ~ | Count ~ 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 ~ | Serial Number ~ 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 ~ | Encaps Flags | MPLS Label List ... ~ 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | IPv4 Address | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | PrefixLen | more ... ~ 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 The 24-bit Count is the sum of the number of MPLSv4 Encapsulation 815 being announced and/or withdrawn. 817 10.7. MPLS IPv6 Encapsulation 819 The MPLS IPv6 Encapsulation describes a logical link's ability to 820 exchange labeled IPv6 packets on one or more subnets. It does so by 821 stating the interface's addresses, the corresponding prefix lengths, 822 and the corresponding labels which will be accepted for each address. 824 0 1 2 3 825 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 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | Version = 0 | PDU Type = 7 | Payload Length ~ 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 ~ | Count ~ 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 ~ | Serial Number ~ 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 ~ | Encaps Flags | MPLS Label List ... | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | ~ 836 + + 837 ~ ~ 838 + IPv6 Address + 839 ~ ~ 840 + + 841 ~ | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | Prefix Len | more ... ~ 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 The 24-bit Count is the sum of the number of MPLSv6 Encapsulations 847 being announced and/or withdrawn. 849 11. VENDOR - Vendor Extensions 851 0 1 2 3 852 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 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | Version = 0 | PDU Type = 255| Payload Length ~ 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 ~ | Serial Number ~ 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 ~ | Enterprise Number ~ 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 ~ | Ent Type | Enterprise Data ... ~ 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 Vendors or enterprises may define TLVs beyond the scope of L3ND 863 standards. This is done using a Private Enterprise Number [IANA-PEN] 864 followed by Enterprise Data in a format defined for that Enterprise 865 Number and Ent Type. 867 Ent Type allows a Vendor PDU to be sub-typed in the event that the 868 vendor/enterprise needs multiple PDU types. 870 As with Encapsulation PDUs, a receiver of a Vendor PDU MUST respond 871 with an ACK or an ERROR PDU. Similarly, a Vendor PDU MUST only be 872 sent over an open session. 874 12. Discussion 876 This section explores some trade-offs taken and some considerations. 878 12.1. HELLO Discussion 880 A device may send IP packets an Layer-3 interface which transmits 881 data over a single Layer-2 interface or multiple Layer-2 interfaces. 882 Packets sourced by one Layer-3 IP interface over multiple Layer-2 883 should consider that an Layer-3 interface with multiple Layer-2 884 interfaces could have many devices which might come at various times, 885 therefore the configured HELLO PDU retransmit time SHOULD be set to a 886 non-zero value, and periodic HELLOs should continue. Packets 887 transmitted on a single Layer-2 interface on a point-to-point (p2p) 888 connection, MAY set the configuration value to zero, so once a TLS/ 889 TCP session is up, HELLOs are no longer desirable. 891 A device with multiple Layer-2 interfaces, traditionally called a 892 switch, may be used to forward frames and therefore packets from 893 multiple devices to one Layer-3 interface, I, on an L3ND speaking 894 device. Interface I could discover a peer J across the switch. 895 Later, a prospective peer K could come up across the switch. If I 896 was not still sending and listening for HELLOs, the potential peering 897 with K could not be discovered. Therefore, on multi-link interfaces, 898 L3ND MUST continue to send HELLOs as long as they are turned up. 900 13. VLANs/SVIs/Sub-interfaces 902 One can think of the protocol as an instance (i.e. state machine) 903 which runs on each logical link of a device. 905 As the upper routing layer must view VLAN topologies as separate 906 graphs, L3ND treats VLAN ports as separate links. 908 As Sub-Interfaces each have their own layer-3 identities, they act as 909 separate interfaces, forming their own links. 911 14. Implementation Considerations 913 An implementation SHOULD provide the ability to configure each 914 logical interface as L3ND speaking or not. 916 An implementation SHOULD provide the ability to distribute one or 917 more loopback addresses or interfaces into L3ND on an external L3ND 918 speaking interface. 920 An implementation SHOULD provide the ability to distribute one or 921 more overlay and/or underlay addresses or interfaces into L3ND on an 922 external L3ND speaking interface. 924 An implementation SHOULD provide the ability to configure one of the 925 addresses of an encapsulation as primary on an L3ND speaking 926 interface. If there is only one address for a particular 927 encapsulation, the implementation MAY mark it as primary by default. 929 An implementation MAY allow optional configuration which updates the 930 local forwarding table with overlay and underlay data both learned 931 from L3ND peers and configured locally. 933 15. Security Considerations 935 The protocol as is MUST NOT be used outside a datacenter or similarly 936 closed environment without using TLS encapsulation which is based on 937 a configured CA trust anchor. 939 Many datacenter operators have a strange belief that physical walls 940 and firewalls provide sufficient security. This is not credible. 941 All DC protocols need to be examined for exposure and attack surface. 942 In the case of L3ND, authentication and integrity as provided by TLS 943 validated to a configured shared CA trust anchor is strongly 944 RECOMMENDED. 946 It is generally unwise to assume that on the wire Layer-3 is secure. 947 Strange/unauthorized devices may plug into a port. Mis-wiring is 948 very common in datacenter installations. A poisoned laptop might be 949 plugged into a device's port, form malicious sessions, etc. to 950 divert, intercept, or drop traffic. 952 Similarly, malicious nodes/devices could mis-announce addressing. 954 If OPENs are not using validated TLS, an attacker could forge an OPEN 955 for an existing session and cause the session to be reset. 957 16. IANA Considerations 958 16.1. Link Local Layer-3 Addresses 960 IANA is requested to assignment one address (TBD1) for L3DL-L3-LL 961 from the IPv4 Multicast Address Space Registry from the Local Network 962 Control Block (224.0.0.0 - 224.0.0.255 (224.0.0/24)). 964 IANA is requested to assign one address (TBD2) for L3DL-L3-LL from 965 the IPv6 Multicast Address Space Registry in the the IPv6 Link-Local 966 Scope Multicast address (TBD:2). 968 16.2. Ports for TLS/TCP 970 This document requests the IANA to assign a well-known TCP Port 971 Number (TBD3) to the Layer-3 Neighbor Discovery Protocol for the 972 following, see Section 7: 974 l3nd-server 976 16.3. PDU Types 978 This document requests the IANA create a registry for L3ND PDU Type, 979 which may range from 0 to 255. The name of the registry should be 980 L3ND-PDU-Type. The policy for adding to the registry is RFC Required 981 per [RFC5226], either standards track or experimental. The initial 982 entries should be the following: 984 PDU 985 Code PDU Name 986 ---- ------------------- 987 0 HELLO 988 1 reserved 989 2 OPEN 990 3 ACK 991 4 IPv4 Announcement 992 5 IPv6 Announcement 993 6 MPLS IPv4 Announcement 994 7 MPLS IPv6 Announcement 995 8-254 Reserved 996 255 Vendor 998 16.4. Flag Bits 1000 This document requests the IANA create a registry for L3ND PL Flag 1001 Bits, which may range from 0 to 7. The name of the registry should 1002 be L3ND-PL-Flag-Bits. The policy for adding to the registry is RFC 1003 Required per [RFC5226], either standards track or experimental. The 1004 initial entries should be the following: 1006 Bit Bit Name 1007 ---- ------------------- 1008 0 Announce/Withdraw (ann == 0) 1009 1 Primary 1010 2 Underlay/Overlay (under == 0) 1011 3 Loopback 1012 4-7 Reserved 1014 16.5. Error Codes 1016 This document requests the IANA create a registry for L3ND Error 1017 Codes, a 16 bit integer. The name of the registry should be L3ND- 1018 Error-Codes. The policy for adding to the registry is RFC Required 1019 per [RFC5226], either standards track or experimental. The initial 1020 entries should be the following: 1022 Error 1023 Code Error Name 1024 ---- ------------------- 1025 0 No Error 1026 1 Checksum Error 1027 2 Logical Link Addressing Conflict 1028 3 reserved 1029 4 Announce/Withdraw Error 1031 17. Acknowledgments 1033 Many kind people helped with the Layer-2 cousin of this protocol, 1034 L3DL. Cristel Pelsser provided multiple reviews, Harsha Kovuru 1035 commented during implementation, Jeff Haas reviewed and commented, 1036 Joerg Ott did an early but deep transport review, Joe Clarke provided 1037 a useful ops review, John Scudder a deeply serious review and 1038 comments, Martijn Schmidt contributed, and Neeraj Malhotra reviewed. 1040 18. References 1042 18.1. Normative References 1044 [I-D.ietf-lsvr-l3dl] 1045 Bush, R., Austein, R., and K. Patel, "Layer-3 Discovery 1046 and Liveness", Work in Progress, Internet-Draft, draft- 1047 ietf-lsvr-l3dl-08, 14 October 2021, 1048 . 1051 [IANA-PEN] "IANA Private Enterprise Numbers", 1052 . 1055 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1056 Requirement Levels", BCP 14, RFC 2119, 1057 DOI 10.17487/RFC2119, March 1997, 1058 . 1060 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1061 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1062 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 1063 . 1065 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1066 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1067 DOI 10.17487/RFC4271, January 2006, 1068 . 1070 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 1071 Pignataro, "The Generalized TTL Security Mechanism 1072 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 1073 . 1075 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1076 IANA Considerations Section in RFCs", RFC 5226, 1077 DOI 10.17487/RFC5226, May 2008, 1078 . 1080 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1081 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1082 May 2017, . 1084 18.2. Informative References 1086 [Clos] "Clos Network", 1087 . 1089 [I-D.ymbk-idr-l3nd-ulpc] 1090 Bush, R. and K. Patel, "L3ND Upper-Layer Protocol 1091 Configuration", Work in Progress, Internet-Draft, draft- 1092 ymbk-idr-l3nd-ulpc-00, 16 February 2022, 1093 . 1096 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1097 Communication Layers", STD 3, RFC 1122, 1098 DOI 10.17487/RFC1122, October 1989, 1099 . 1101 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 1102 DOI 10.17487/RFC1982, August 1996, 1103 . 1105 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1106 "Multiprotocol Extensions for BGP-4", RFC 4760, 1107 DOI 10.17487/RFC4760, January 2007, 1108 . 1110 Authors' Addresses 1112 Randy Bush 1113 Arrcus & Internet Initiative Japan 1114 5147 Crystal Springs 1115 Bainbridge Island, WA 98110 1116 United States of America 1117 Email: randy@psg.com 1119 Russ Housley 1120 Vigil Security, LLC 1121 516 Dranesville Road 1122 Herndon, VA 20170 1123 United States of America 1124 Email: housley@vigilsec.com 1126 Rob Austein 1127 Arrcus, Inc 1128 Email: sra@hactrn.net 1130 Susan Hares 1131 Hickory Hill Consulting 1132 7453 Hickory Hill 1133 Saline, MI 48176 1134 United States of America 1135 Phone: +1-734-604-0332 1136 Email: shares@ndzh.com 1138 Keyur Patel 1139 Arrcus 1140 2077 Gateway Place, Suite #400 1141 San Jose, CA 95119 1142 United States of America 1143 Email: keyur@arrcus.com