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

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

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