randy/draft-l3nd
1
0
Fork 0
Code Issues 3 Pull requests Projects Releases Packages Wiki Activity Actions

howdy removed

Browse source
This commit is contained in:
Randy Bush 2022-02-13 04:28:30 -08:00
parent 29a605f85a
commit 6c011766bf
1 changed files with 199 additions and 239 deletions
Download patch file Download diff file Expand all files Collapse all files

432
draft-ymbk-idr-l3-discovery.xml
View file

@ -11,7 +11,7 @@
<?rfc tocindent="yes"?>
<?rfc tocompact="yes"?>
<rfc consensus="yes" category="std" submissionType="IETF" docName="draft-ymbk-idr-l3-discovery-00" ipr="trust200902">
<rfc consensus="yes" category="std" submissionType="IETF" docName="draft-ymbk-idr-l3nd-00" ipr="trust200902">
<front>
@ -46,13 +46,6 @@
</address>
</author>
<author initials="R." surname="Austein" fullname="Rob Austein">
<organization abbrev="Arrcus">Arrcus, Inc</organization>
<address>
<email>sra@hactrn.net</email>
</address>
</author>
<author fullname="Russ Housley" initials="R" surname="Housley">
<organization abbrev="Vigil Security">Vigil Security, LLC</organization>
<address>
@ -67,6 +60,13 @@
</address>
</author>
<author initials="R." surname="Austein" fullname="Rob Austein">
<organization abbrev="Arrcus">Arrcus, Inc</organization>
<address>
<email>sra@hactrn.net</email>
</address>
</author>
<author fullname="Keyur Patel" initials="K." surname="Patel">
<organization>Arrcus</organization>
<address>
@ -85,10 +85,9 @@
<abstract>
<t>Data Centers where the topology is BGP-based need to discover IP
Layer-3 BGP neighbors, neighbor IP addressing, etc. This Layer-3
BGP neighbor discovery prorocol identifies BGP neighbor
candidates.</t>
<t>Data Centers where the topology is BGP-based need to discover
neighbor IP addressing, IP Layer-3 BGP neighbors, etc. This Layer-3
Neighbor Discovery protocol identifies BGP neighbor candidates.</t>
</abstract>
@ -108,28 +107,31 @@
<section anchor="intro" title="Introduction">
<t>The Data Center (DC) environment presents unusual problems of
scale, e.g. O(10,000) forwarding devices, while its homogeneity
presents opportunities for simple approaches. Layer-3 Discovery and
Liveness (L3DL), <xref target="I-D.ietf-lsvr-l3dl"/>, provides a
solution at Layer-2. This document (set) provides a solution at
Layer-3, attempting to be as similar as reasonable to L3DL.</t>
<t>The Massive Data Center (MDC) environment presents unusual
problems of scale, e.g. O(10,000) forwarding devices, while its
homogeneity presents opportunities for simple approaches. Layer-3
Discovery and Liveness (L3DL), <xref target="I-D.ietf-lsvr-l3dl"/>,
provides neighbor discovery at Layer-2. This document (set)
provides a similar solution at Layer-3, attempting to be as similar
as reasonable to L3DL.</t>
<t>Layer-3 BGP Neighbor Discovery (L3ND) provides brutally simple
mechanisms for devices to <list style="symbols">
<t>Layer-3 Neighbor Discovery (L3ND) provides brutally simple
mechanisms for neighboring devices to <list style="symbols">
<t>Discover each other's IP Addresses,</t>
<t>Discover mutually supported layer-3 encapsulations, e.g.
IP/MPLS,</t>
<t>Discover Layer-3 IP and/or MPLS addressing of interfaces of the
encapsulations,</t>
<t>Provide for authenticity verification of protocol messages.</t>
<t>Provide for authenticity and verification of protocol
messages.</t>
</list></t>
<t>In this document, the use case for L3ND is for point to point
links in a datacenter Clos in order to exchange the data needed for
bootstrapping BGP-based peering. Once IP connectivity has been
leveraged to get layer-3 addressability and forwarding capabilities,
normal IP forwarding and routing can take over.</t>
links in a datacenter Clos (<xref target="Clos1"/>)in order to
exchange the data needed for bootstrapping BGP-based peering. Once
IP connectivity has been leveraged to get layer-3 addressability and
forwarding capabilities, normal IP forwarding and routing can take
over.</t>
<t>L3ND might be found to be more widely applicable to a range of
routing and similar protocols which need Layer-3 neighbor
@ -144,18 +146,18 @@
attempts to clarify the use of some possibly confusing terms:
<list hangIndent="11" style="hanging">
<?rfc subcompact="yes"?>
<t hangText="ASN:">Autonomous System Number <xref
<!-- <t hangText="ASN:">Autonomous System Number <xref
target="RFC4271"/>, a BGP identifier for an originator of
Layer-3 routes, particularly BGP announcements.</t>
Layer-3 routes, particularly BGP announcements.</t> -->
<t hangText="Clos:">A hierarchic subset of a crossbar switch
topology commonly used in data centers <xref target="Clos1"/>.</t>
<t hangText="Datagram:">The L3ND content of a single Layer-3
Multicast UDP Datagram.</t>
UDP Datagram.</t>
<t hangText="Encapsulation:">Address Family Indicator and
Subsequent Address Family Indicator (AFI/SAFI). I.e. classes of
layer-2.5 and 3 addresses such as IPv4, IPv6, MPLS, etc.</t>
<t hangText="Link or Logical Link:">A logical connection between
two logical ports on two devices. E.g. two VLANs between the same
two interfaces on two devices. E.g. two VLANs between the same
two ports are two links.</t>
<t hangText="MDC:">Massive Data Center, commonly composed of
thousands of Top of Rack Switches (TORs).</t>
@ -165,15 +167,15 @@
<t hangText="PDU:">Protocol Data Unit, an L3DL application layer
message. A PDU's content may need to be broken into multiple
Datagrams to make it through MTU or other restrictions.</t>
<t hangText="RouterID:">An 32-bit identifier unique in the
current routing domain, see <xref target="RFC6286"/>.</t>
<t hangText="Session:">An established, via OPEN PDUs, session
between two L3ND capable IP interfaces on a link,</t>
<!-- <t hangText="RouterID:">An 32-bit identifier unique in the
current routing domain, see <xref target="RFC6286"/>.</t> -->
<t hangText="Session:">An established, via exchange of OPEN PDUs,
session between two L3ND capable IP interfaces on a link,</t>
<t hangText="TOR:">Top Of Rack switch, aggregates the servers in
a rack and connects to aggregation layers of the Clos tree, AKA
the Clos spine.</t>
<t hangText="ZTP:">Zero Touch Provisioning gives devices initial
addresses, credentials, etc. on boot/restart.</t>
<!-- <t hangText="ZTP:">Zero Touch Provisioning gives devices initial
addresses, credentials, etc. on boot/restart.</t> -->
<?rfc subcompact="no"?>
</list></t>
@ -191,15 +193,15 @@
appropriate level of security options chosen.</t>
<t>The number of addresses of one Encapsulation type on an interface
link may be quite large given a TOR with tens of servers, each
server having a few hundred micro-services, resulting in an
link may be quite large given a TOR switch with tens of servers,
each server having a few hundred micro-services, resulting in an
inordinate number of addresses. And highly automated micro-service
migration can cause serious address prefix disaggregation, resulting
in interfaces with thousands of disaggregated prefixes.</t>
<t>Therefore the L3ND protocol is session oriented and uses
incremental announcement and withdrawal with session restart, a la
BGP (<xref target="RFC4271"/>).</t>
<t>To meet such scaling needs, the L3ND protocol is session oriented
and uses incremental announcement and withdrawal with session
restart, a la BGP (<xref target="RFC4271"/>).</t>
</section>
@ -208,7 +210,7 @@
<t><list style="symbols">
<t>Devices discover each other's IP Addresses on logical links
using Multicast and Unicast UDP</t>
<t>The main body of the protocol runs over TCP, optionally with
<t>The main body of the protocol runs over TCP, normally with
TLS</t>
<t>Further IP Address reachability may be exchanged</t>
<t>IP Encapsulation data are exchanged</t>
@ -249,74 +251,74 @@
BGP-like routing protocol (up-down in the above diagram):
<list style="symbols">
<t>A Layer-3 Multicast UDP datagram broadcasts an IP Address's
willingness to explore higher level peering. This is responded to
by a Unicast Layer-3 UDP datagram indicating willingness by a
second IP Address on the link.</t>
<t>A device broadcasts a Layer-3 Multicast UDP datagram (HELLO)
containing the port number that is willing to serve a TLS or raw
TCP connection to support the data exchange of the rest of the
protocol in a reliable and preferably authenticated manner.</t>
<t>The two devices than establish a TCP session in which
inter-device PDUs are used to exchange device and logical link
identities and layer-2.5 (MPLS) and 3 identifiers (not payloads),
e.g. more IP Addresses, loopback addresses, port identities, and
Encapsulations.</t>
<t>Another device on the link then establishes a TLS or raw TCP
session in which inter-device PDUs are used to exchange device and
logical link identities and layer-2.5 (MPLS) and 3 identifiers
(not payloads), e.g. more IP Addresses, loopback addresses, port
identities, and Encapsulations.</t>
<t>A L3BDL extension, <!-- <xref target="I-D.ymbk-idr-l3bdl-ulpc"/>,-->
describes the next upper layer L3BDL protocol to exchange BGP
<t>A L3DL extension, <!-- <xref target="I-D.ymbk-idr-l3bdl-ulpc"/>,-->
describes the next upper layer L3DL protocol to exchange BGP
parameter information.</t>
</list></t>
<t>The upper layer BGP family routing protocols cross all the
devices, though they are not part of these L3ND protocols.</t>
devices, but are not part of these L3ND protocols.</t>
</section>
<section anchor="ilpo" title="Inter-Link Protocol Overview">
<t>Two devices discover each other and their respective identities
by one sending a Multicast UDP HELLO PDU (<xref target="hello"/>),
and an other responding with a Unicast UDP HOWDY PDU. To assure
discovery of new devices coming up on a multi-link topology, devices
on such a topology, and only on a multi-link topology, send periodic
HELLOs forever, see <xref target="dhello"/>.</t>
<t>Two devices discover each other and their respective IP
identities by one sending a Multicast UDP HELLO PDU (<xref
target="hello"/>), and an other responds by attempting a TLS or raw
TCP connection. To assure discovery of new devices coming up on a
multi-link topology, devices on such a topology, and only on a
multi-link topology, send periodic HELLOs forever, see <xref
target="dhello"/>.</t>
<t>Once a new device is recognized, both devices attempt to
negotiate and establish a TCP session by sending unicast TCP
OPEN_REQ and OPEN_RESP to the source IP addresses of the received
HELLO/HOWDY. Once a TCP session is established, STARTTLS is used to
try and up-level the TCP session to TLS. Given the TCP/TLS session,
OPEN PDUs <xref target="open"/> are exchanged, the Encapsulations
(<xref target="afisafi"/>) configured on an end point may be
announced and modified. Note that these are only the encapsulation
and addresses configured on the announcing interface; though a
device's loopback and overlay interface(s) may also be
announced.</t>
<t>A device receivinga HELLO attempts to negotiate and establish a
TCP, preferably TLS, session to the server at the source IP
addresses of the received HELLO on the port advertised in the HELLO.
Given the TCP/TLS session, OPEN PDUs (<xref target="open"/>) are
exchanged, the Encapsulations (<xref target="afisafi"/>) configured
on an end point may be announced and modified. Note that these are
only the encapsulation and addresses configured on the announcing
interface; though a device's loopback and overlay interface(s) may
also be announced.</t>
<section anchor="ladder" title="L3ND Ladder Diagram">
<t>The HELLO, <xref target="hello"/>, is a priming message sent on
all configured logical links. It is a small L3ND Multicast UDP
PDU with the simple goal of discovering the IP identities of
IP speaking link endpoint(s) reachable on an IP link.</t>
all logical links configured for L3ND. It is a small L3ND
Multicast UDP PDU with the simple goal of advertising a TLS/TCP
service available on an advertised port on the sending IP
interface.</t>
<t>The HELLO PDU is either IPv4 or IPv6, which signals the
protocol to be used for the rest of the session(s) between
end-points. Two endpoints MAY establish a link for each AFI.</t>
<t>The HELLO PDU is either IPv4 or IPv6, which selects the AFI to
be used for the rest of the session(s) between end-points. Two
endpoints MAY establish a link for each AFI.</t>
<t>An interface on the link receiving the HELLO PDU and is to
negotiate higher level protocols responds with a Unicast UDP HOWDY
PDU <xref target="howdy"/>, with the source IP being its preferred
IP address.</t>
<t>Given the HELLO and HOWDY have revealed compatible IP
addresses, the two endpoints establish a TCP session. This
session may be secured with TLS using STARTTLS.</t>
<t>An interface on the link receiving the HELLO PDU attempts to
establish a TLS or raw TCP, as specified by the HELLO, session to
the source IP address of the HELLO on the port advertised in the
HELLO.</t>
<t>The OPEN, <xref target="open"/> PDUs, used to exchange details
about the L3ND session, and the ACK/ERROR PDU, are mandatory;
other PDUs are optional; though at least one encapsulation SHOULD
be agreed at some point.</t>
<t>Like Multi-Protocol BGP, <xref target="RFC4760"/>, an L3ND
session running over one AFI MAY carry encapsulations etc. of
different AFIs,</t>
<t>The following is a ladder-style diagram of the L3ND protocol
exchanges:</t>
@ -324,7 +326,7 @@
<artwork>
| HELLO | Logical Link Peer discovery
|----------------------------&gt;|
| HOWDY | Mandatory
| TCP OPEN | Mandatory
|&lt;----------------------------|
| |
| |
@ -389,9 +391,9 @@
<section anchor="tlv" title="TLV PDUs">
<t>The basic L3ND application layer PDU is a typical TLV (Type
Length Value) PDU. It includes a signature to provide optional
integrity and authentication. It may be broken into multiple
Datagrams, see xref target="transport".</t>
Length Value) PDU. As it is transported over TCP, integrity is
assured. When it is transported over TLS, authenticity is also
provided.</t>
<!--
protocol "Version = 0:8,PDU Type:8,Payload Length:32,Payload ...:48"
@ -414,6 +416,9 @@
<t>The fields of the basic L3ND header are as follows:
<list style="hanging">
<t hangText="Version:">An integer differentiating versions of the
L3ND protocol. Currently only Version 0 MAY BE specified.</t>
<t hangText="PDU Type:">An integer differentiating PDU payload
types. See <xref target="iana-types"/>.</t>
@ -430,7 +435,7 @@
<section anchor="hello" title="HELLO">
<!--
protocol "Version = 0:8,PDU Type = 0:8,Payload Length = 16:32,Flags:8,Algs:8"
protocol "Version = 0:8,PDU Type = 0:8,Payload Length = 24:32,Flags:8,Port:16"
-->
<figure>
@ -438,33 +443,33 @@
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 0 | PDU Type = 0 | Payload Length = 16 |
| Version = 0 | PDU Type = 0 | Payload Length = 24 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Flags |
~ | Flags | Port ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+
Flags (bit):
0 - 0 Naked TCP, 1 TLS
0 - 0 Raw TCP, 1 TLS
1 - 0 Self-Signed Cert for TLS, CA-based
</artwork>
</figure>
<t>The HELLO PDU is unique in that it is encapsulated in a multicast
UDP packet. It solicits HOWDY, <xref target="howdy"/>, response(s)
from other peers on the link. See <xref target="dhello"/> for why
multicast is used.</t>
UDP packet. It solicits TLS/TCP connections from other peers on a
link. See <xref target="dhello"/> for why multicast is used.</t>
<t>The HELLO PDU is an IPv4 or IPv6 UDP PDU sent to a link-local
multicast address. It solicits unicast HOWDY response(s) of teh
same AFI from other devices on the link.</t>
multicast address. It solicits a unicast TLS/TCP open request(s) of
the same AFI from other devices on the link.</t>
<t>The IPv4 UDP packets are sent to the IPv4 link local multicast
address (TBD1) and the IPv6 UDP packets are sent to an IPv6 link
Local multicast address (TBD2).</t>
<t>All L3ND PDUs other than HELLO AND HOWDY are sent via TCP, as the
peer's destination IP address is known after the HELLO/HOWDY
exchange.</t>
<t>All L3ND PDUs other than HELLO are sent via TLS/TCP, as the
peer's destination IP address is known after the HELLO.</t>
<t>When an interface is turned up on a device, it SHOULD issue a
HELLO if it is to participate in L3ND sessions.</t>
@ -483,9 +488,9 @@ Flags (bit):
the operator should be aware of the trade-off between timer tuning
and network noise and adjust the inter-HELLO timer accordingly.</t>
<t>The source IP address of the HELLO is the address soliciting
peering, and HOWDY PDU responses MUST be unicast to it using the
same AFI.</t>
<t>The source IP address of the HELLO is the address offering
TLS/TCP service, and responses MUST be unicast TLS/TCP client
session open requests to it using the same AFI.</t>
<t>If more than one device responds, one adjacency is formed for
each unique source IP address. L3ND treats each adjacency as a
@ -493,97 +498,59 @@ Flags (bit):
<t>When a HELLO is received from a source IP address with which
there is no established L3ND session, the receiver SHOULD respond by
sending an HOWDY PDU to the source IP address of the HELLO. The two
devices may then establish an L3ND TCP session.</t>
sending a TLS/TCP client session open request to the source IP
address of the HELLO to establish an L3ND TLS/TCP session.</t>
<t>To ameliorate possible load spikes during bootstrap or event
recovery, there SHOULD be a jittered delay between receipt of a
HELLO and issue of the HOWDY. The default delay range SHOULD be zero
to five seconds, and MUST be configurable.</t>
HELLO and TLS/TCP openb. The default delay range SHOULD be zero to
five seconds, and MUST be configurable.</t>
<t>If a HELLO is received from an IP Address with which there is an
established session for that AFI, the HELLO should be dropped.</t>
<t>The Payload Length is 16 to cover the Flags field.</t>
<t>The Payload Length is 24 to cover the Flags and Port fields.</t>
</section>
<section anchor="howdy" title="HOWDY">
<!--
protocol "Version = 0:8,PDU Type = 0:8,Payload Length = 16:32,Flags:8,Algs:8"
-->
<figure>
<artwork>
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 0 | PDU Type = 1 | Payload Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags (bit):
0 - 0 Naked TCP, 1 TLS
1 - 0 Self-Signed Cert for TLS, CA-based
</artwork>
</figure>
<t>The HOWDY PDU is identical in format to the HELLO PDU except it
is sent in a unicast UDP packet.</t>
<t>The unicast source address is that of the interface responding to
the HELLO multicast PDU. The destination address is the source
address of the HELLO to which it is responding. And the AFI MUST be
the same as the HELLO to which it is responding.</t>
<t>The receiver knows it is a HOWDY because it is unicast and the
destination address is the source address of the HELLO sent by the
receiver of the HOWDY.</t>
</section>
<section anchor="agree" title="TCP Agreement">
<section anchor="tcp" title="TCP Set-Up">
<t>If the receiver of a HELLO does not agree with the sender's
choice of TCP/TLS or does not agree with the verification choice,
Self-Signed or CA-based, the receiver is welcome to respond with a
HOWDY specifying its preferences.</t>
Self-Signed or CA-based, the receiver SHOULD respond with a HELLO
specifying its preferences.</t>
<t>If the HELLO sender does is not willing to agree with the choices
encoded in the HOWDY Flags, the HELLO sender MUST simply not attempt
to start the TCP session.</t>
<t>If the receiver of a HELLO agrees with the sender's choice of
TLS/TCP and authentication, both sides have agreed on an AFI for the
transport and on each other's IP address in that AFI. This is
sufficient to open a TCP session between them, which will allow for
very large data PDUs while obviating the need to invent complex
transports.</t>
<t>If the sender of the HOWDY does not receive a TCP SYN from the
sender of the HELLO, it MUST time out, log the problem, and go back
to its initial state.</t>
<t> The server, the sender of the HELLO, listens on the advertised
port for the TLS/TCP session open. The receiver of the accptable
HELLO, the TCP/TLS client, initiates a TLS or raw TCP session with
the sender of the HELLO, the TLS/TCP server, preferably TLS, as
negotiated. If TLS, the client chooses either a self-signed
certificate or one configured from the operational CA trusted by
both parties, as negotiated in the HELLO exchange.</t>
</section>
<t>If the TLS/TCP open fails, then this SHOULD be logged and the
parties MUST go back to the initial state and try HELLO.</t>
<section anchor="tcp0" title="TCP Set-Up">
<t>With the HELLO/HOWDY exchange, both sides have agreed on an AFI
and each other's IP address in that AFI. This is sufficient to open
a TCP session between them, which will allow for very large data
PDUs while obviating the need to invent complex transports.</t>
<t>The sender of the HELLO, having received agreement from the
sender of the HOWDY, initiates a TCP session, preferably TLS
protected, as agreed. If TLS, the initiator chooses either a
self-signed certificate or one configured from the operational CA
trusted by both parties, as agreed.</t>
<t>If the TCP open fails, then this SHOULD be logged and the parties
MUST go back to the initial state and try HELLO/HOWDY.</t>
<t>Once the TLS/TCP session has been established, the two devices
exchange L3ND PDUs, starting with OPENs.</t>
</section>
<section anchor="open" title="OPEN">
<t>Each device has learned the other's IP Address from the
HELLO/HOWDY exchange, see <xref target="hello"/> and established a
TCP session for a particular AFI.</t>
HELLO exchange, see <xref target="hello"/> and established a
TLS/TCP session for a particular AFI.</t>
<t>The first PDU each sends MUST be an OPEN, and the other side MUST
respond with an ACK PDU.</t>
<!--
protocol "Version = 0:8,PDU Type = 1:8,Payload Length:32,Nonce:32,AttrCount:8,Attribute List ...:40,Serial Number:32"
@ -615,12 +582,12 @@ Flags (bit):
needed to prevent session closure due to a repeated OPEN caused by a
race or a dropped or delayed ACK.</t>
<t>AttrCount is the number of attributes in the Attribute List.
Attributes are single octets the semantics of which are
operator-defined.</t>
<t>AttrCount is the number of attributes in the Attribute List. A
node may send zero or more attributes.</t>
<t>A node may have zero or more operator-defined attributes, e.g.:
spine, leaf, backbone, route reflector, arabica, ...</t>
<t>Attributes are single octets the semantics of which are
operator-defined, e.g.: spine, leaf, backbone, route reflector,
arabica, ....</t>
<t>Attribute syntax and semantics are local to an operator or
datacenter; hence there is no global registry. Nodes exchange
@ -630,12 +597,6 @@ Flags (bit):
verifyable keys in the PDUs. If the operator wants authentication,
integrity, etc. TLS MUST be configured.</t>
<t>Although delay and jitter in responding with an OPEN were
specified above, beware of load created by long strings of
authentication failures and retries. A configurable failure count
limit (default 8) SHOULD result in giving up on the connection
attempt.</t>
<t>The Serial Number is a monotonically increasing 32-bit value
representing the sender's state at the time of sending the last PDU.
It may be an integer, a timestamp, etc. If incrementing the Serial
@ -647,14 +608,6 @@ Flags (bit):
Serial Number greater (in the <xref target="RFC1982"/> sense), or
send a Serial Number of zero to request all data.</t>
<t>The Serial Number supports session resumption in anticipation of
peers having a very large amount of state they would prefer not to
re-exchange because of some glitch. The Serial Number is not
expected to wrap for a considerable time, e.g. days or weeks. But
to address the rare case it does, <xref target="RFC1982"/> on DNS
Serial Number Arithmetic should be used as it is in the Transmission
Sequence Number.</t>
<t>This allows a sender of an OPEN to tell the receiver that the
sender would like to resume a session and that the receiver only
needs to send data starting with the PDU with the lowest Serial
@ -668,31 +621,30 @@ Flags (bit):
failing OPEN PDU SHOULD then send an OPEN PDU with a Serial Number
of zero.</t>
<t>If a sender of OPEN does not receive an ACK of the OPEN PDU, then
they MUST resend the same OPEN PDU, with the same Nonce. Resending
an unacknowledged OPEN PDU, like other ACKed PDUs, SHOULD use
exponential back-off, see <xref target="RFC1122"/>.</t>
<t>If a sender of OPEN does not receive an ACK of the OPEN PDU in a
configurable time (default 30 seconds), then they MUST resend the
same OPEN PDU, with the same Nonce. Resending an unacknowledged
OPEN PDU, like other ACKed PDUs, SHOULD use exponential back-off,
see <xref target="RFC1122"/>.</t>
<t>If a properly authenticated OPEN arrives at L3ND speaker A with a
new Nonce from an IP Address, speaker B, with which A believes it
already has an L3ND session (i.e. OPENs have already been
exchanged), and the Serial Number in the OPEN PDU is non-zero,
<t>If an OPEN arrives at L3ND speaker A from B with which A believes
it already has an L3ND session (i.e. OPENs have already been
exchanged), and the Serial Number in B's OPEN PDU is non-zero,
speaker A SHOULD establish a new sending session by sending an OPEN
with the Serial Number being the same as that of A's last sent and
ACKed PDU. A MUST resume sending encapsulations etc. subsequent to
the requested Sequence Number. And B MUST retain all previously
discovered encapsulation and other data received from A.</t>
<t>If a properly authenticated OPEN arrives with a new Nonce from an
IP Address with which the receiving endpoint believes it already has
an L3ND session (i.e. OPENs have already been exchanged), and the
Serial Number in the OPEN is zero, then the receiver MUST assume
that the sending IP interface or entire device has been reset. All
Previously discovered encapsulation data MUST NOT be kept and MUST
BE discarded. and the recipient MUST respond with a new OPEN.</t>
<t>If an OPEN arrives at L3ND speaker A from B with which A believes
it already has an L3ND session (i.e. OPENs have already been
exchanged), and the Serial Number in B's OPEN is zero, then the A
MUST assume that B's internal state has been reset. All Previously
discovered encapsulation data MUST BE discarded; and A MUST respond
with a new OPEN with a Serial Number of zero.</t>
<t>TCP KeepAlives should be configured and tuned to meet local
operational needs..</t>
operational needs.</t>
</section>
@ -759,12 +711,13 @@ Flags (bit):
<t>If a PDU sender expects an ACK, e.g. for an OPEN, an
Encapsulation, a Vendor PDU, etc., and does not receive the ACK
for a configurable time (default one second), and the interface is
live, the sender resends the PDU using exponential back-off, see
<xref target="RFC1122"/>. This cycle MAY be repeated a
configurable number of times (default three) before it is
considered a failure. The session MAY BE considered closed in
this case of this ACK failure.</t>
for a configurable time (default three seconds), and the interface
and TLS/TCP session are live, the sender resends the PDU using
exponential back-off, see <xref target="RFC1122"/>. This cycle
MAY be repeated a configurable number of times (default three)
before it is considered a failure. The session MAY BE considered
closed in this case of this ACK failure, and both sides revert to
HELLO state.</t>
<t>If the link is broken below layer-3, retransmission MAY BE
retried when the link is restored.</t>
@ -779,13 +732,10 @@ Flags (bit):
established a TCP/TLS session and have successfully exchanged OPENs,
the L3ND session is considered established, and the devices SHOULD
exchange L3 interface encapsulations, L3 addresses, and L2.5
labels of the same AFI as the HELLO/HOWDY exchange.</t>
labels.</t>
<t>IPv4 based encapsulations are exchanged only over an IPv4-based
HELLO/HOWDY TCP/TLS session.</t>
<t>IPv6 based encapsulations are exchanged only over an IPv6-based
HELLO/HOWDY TCP/TLS session.</t>
<t>Encapsulations of any AFI/SAFI may be exchanged over a TCP/TLS
session irrespective of the AFI/SAFI of the session transport.</t>
<t>The Encapsulation types the peers exchange may be IPv4 (<xref
target="ipv4"/>), IPv6 (<xref target="ipv6"/>), MPLS IPv4 (<xref
@ -800,7 +750,7 @@ Flags (bit):
<t>A receiver of an encapsulation might recognize an addressing
conflict, such as both ends of the link trying to use the same
address. In this case, the receiver SHOULD respond with an error
address. In this case, the receiver MUST respond with an error
(Error Code 2) ACK. As there may be other usable addresses or
encapsulations, this error might log and continue, letting an upper
layer topology builder deal with what works.</t>
@ -850,30 +800,29 @@ Flags (bit):
state: data, ACKs, etc. must be kept for each peer session.</t>
<t>Over time, multiple Encapsulation PDUs may be sent for an
interface as configuration changes.</t>
interface in a session as configuration changes.</t>
<!--
<t>If the length of an Encapsulation PDU exceeds the Datagram size
limit on media, the PDU is broken into multiple Datagrams. See
<xref target="tlv"/>.</t>
<t>The Signature fields are described in <xref target="tlv"/>.</t>
-->
<t>The Receiver MUST acknowledge the Encapsulation PDU with a
Type=3, ACK PDU (<xref target="ack"/>) with the Encapsulation Type
being that of the encapsulation being announced, see <xref
target="ack"/>.</t>
<t>If the Sender does not receive an ACK in a configurable
interval (default one second), and the interface is live at
layer-2, they SHOULD retransmit. After a user configurable number
of failures (default three), the L3ND session should be considered
dead and the OPEN process SHOULD be restarted.</t>
interval (default three seconds), they SHOULD retransmit. After a
user configurable number of failures (default three), the L3ND
session should be considered dead and the HELLO process
SHOULD be restarted.</t>
<t>If the link is broken below layer-3, retransmission MAY BE
retried if data have not changed in the interim and the TCP/TLS
session is still alive.</t>
</section>
<section anchor="eflags" title="Encapsulaion Flags">
<t>The Encapsulation Flags are a sequence of bit fields as
@ -1255,6 +1204,20 @@ Flags (bit):
</section>
<section anchor="iana-ports" title="Ports for TLS/TCP">
<t>This document requests the IANA to assign two well-known TCP
Port Numbers, TBD3 and TBD4. to the L3 Neighbor Discovery
Protocol for the following, see <xref target="tcp"/>:</t>
<figure>
<artwork>
l3nd-tls
l3nd-tcp
</artwork>
</figure>
</section>
<section anchor="iana-types" title="PDU Types">
@ -1269,7 +1232,7 @@ Flags (bit):
Code PDU Name
---- -------------------
0 HELLO
1 HOWDY
1 reserved
2 OPEN
3 ACK
4 IPv4 Announcement
@ -1343,15 +1306,11 @@ Flags (bit):
<?rfc include="reference.RFC.3032.xml"?>
<?rfc include="reference.RFC.4271.xml"?>
<?rfc include="reference.RFC.5226.xml"?>
<!--
<?rfc include="reference.RFC.5880.xml"?>
-->
<?rfc include="reference.RFC.6286.xml"?>
<!--<?rfc include="reference.RFC.5880.xml"?> -->
<!--<?rfc include="reference.RFC.6286.xml"?> -->
<?rfc include="reference.RFC.8174.xml"?>
<?rfc include="reference.I-D.ietf-lsvr-l3dl.xml"?>
<!--
<?rfc include="reference.I-D.ietf-lsvr-l3dl-signing.xml"?>
-->
<!--<?rfc include="reference.I-D.ietf-lsvr-l3dl-signing.xml"?> -->
<reference anchor="IANA-PEN" target="https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers">
<front>
<title>IANA Private Enterprise Numbers</title>
@ -1364,6 +1323,7 @@ Flags (bit):
<references title="Informative References">
<?rfc include="reference.RFC.1122.xml"?>
<?rfc include="reference.RFC.1982.xml"?>
<?rfc include="reference.RFC.4760.xml"?>
<reference anchor="Clos1" target="https://en.wikipedia.org/wiki/Clos_network/">
<front>
<title>Clos Network</title>