| Internet-Draft | BGP over Layer 2 QUIC | October 2026 |
| Pospichal | Expires 30 April 2027 | [Page] |
This document specifies BGP over Layer 2 QUIC (BoL2Q), a transport for external and internal BGP sessions between speakers that share an Ethernet segment, in which QUIC packets are carried directly in Ethernet frames, identified by a dedicated EtherType, without IP or UDP headers. A BoL2Q session has no IP address and no transport port, so it cannot be reached from beyond the link on which it runs, and it requires no IP-layer configuration of any kind: a session is defined by a local interface, the MAC address of the peer, the remote Autonomous System number and a pre-shared key. BoL2Q reuses QUIC version 1 and TLS 1.3 unchanged, apart from the replacement of the UDP/IP path by an Ethernet path. Optionally, a "Link Next Hop" capability allows routes to be installed with a router on the same Ethernet segment as the next hop, identified either as the session peer itself or by its MAC address. This enables forwarding over links that carry no interface addresses, including through route reflectors and route servers.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 30 April 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The Border Gateway Protocol (BGP) [RFC4271] uses TCP as its transport. Because a TCP-based BGP session is bound to IP addresses, an operator has to take explicit steps to prevent the session from being reached by hosts beyond the directly connected peer: infrastructure access lists, the Generalized TTL Security Mechanism (GTSM) [RFC5082], control-plane policing, and session authentication such as TCP-AO [RFC5925].¶
Using IPv6 link-local addresses [RFC8950] or Unique Local Addresses (ULAs) [RFC4193] for peering does not remove this burden. Link-local addresses are usually derived from interface identifiers and are not static, so they change with hardware unless every one of them is configured by hand. ULAs are routable, so ULAs used on an Internet Exchange Point peering LAN can propagate into the networks of exchange participants, for example through redistribution of connected routes, as the IPv4 prefixes of peering LANs commonly do today. In both cases, IPv6 and Neighbor Discovery have to be enabled and working on the link, and the session remains an IP endpoint. Its isolation then depends on the IP stack behaving correctly: an implementation defect in address handling, scoping or filtering can expose the session to hosts beyond the link.¶
In principle, combining these mechanisms confines a session to its link. In practice, the combination is rarely, if ever, deployed on production inter-domain sessions. Each mechanism was added later to fix a weakness of the one before it, and each has to be configured separately for every peering. Support and configuration models differ between platforms. On some platforms, enforcing GTSM at an Internet Exchange Point requires large, hand-maintained firewall filters, which makes it impractical there. TCP-AO is not widely deployed, and most sessions still rely on TCP-MD5 or on no authentication at all.¶
BoL2Q takes a different approach: the control session is carried in Ethernet frames that are never IP-routed, so the property "reachable only from this link" is structural rather than the result of filtering, and peer authentication is part of the transport handshake rather than a separate option. Because no IP stack is involved in the session, defects in that stack cannot expose it.¶
BoL2Q also limits Broadcast, Unknown unicast and Multicast (BUM) traffic on the segment. A TCP-based session over IP depends on address resolution, ARP for IPv4 and Neighbor Discovery for IPv6, and Neighbor Discovery relies on group-addressed frames that every station on the segment has to receive and process. BoL2Q uses neither. It sends no broadcast and no multicast frames, because the MAC address of the peer is configured (Section 5). Its frames are unicast. As with any unicast traffic, a switch forwards them to all ports until it has learned the destination address from a frame sent by the peer. On large shared segments, such as the peering LAN of an Internet Exchange Point, where operators already work to keep BUM traffic low, the number of BGP sessions then does not add to it.¶
BoL2Q also adds diversity. Operators commonly have several comparable alternatives for one function, such as OSPF and IS-IS as interior gateway protocols. For confining BGP sessions to a link, IPv6 link-local addresses and ULAs are variants of the same IP-based approach. BoL2Q provides a fundamentally different one, with its own implementation and failure modes.¶
BoL2Q is deliberately narrow in scope:¶
It replaces only the transport of BGP. BGP messages, the BGP Finite State Machine, error handling [RFC7606] and path selection are unchanged.¶
It uses QUIC version 1 [RFC9000] with TLS 1.3 [RFC9001] essentially unchanged. This document only specifies how QUIC packets are framed on Ethernet and what replaces the notion of a UDP/IP path.¶
It specifies only sessions in which the MAC address of the peer is configured. Automatic discovery of peers and connection migration are not defined here, but are not precluded and can be defined by future documents (Section 5).¶
It applies to sessions between Layer 2 adjacent speakers, both eBGP and iBGP. Sessions that cross a Layer 3 hop, such as multihop eBGP or iBGP between loopbacks reached through an IGP, continue to use TCP [RFC4271] or QUIC over UDP [I-D.retana-idr-bgp-quic].¶
This narrowness is a design principle. BoL2Q specifies a single way to address a peer and defines nothing that a configured session does not need. Additional mechanisms can be defined by future documents.¶
The control traffic of BoL2Q still traverses the same physical link and the same forwarding hardware as data traffic. BoL2Q is therefore not an out-of-band control plane; it is a link-confined one.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
A BGP speaker that implements this specification.¶
An Ethernet interface, or an IEEE 802.1Q [IEEE802.1Q] VLAN sub-interface, on which BoL2Q is enabled. A Link Aggregation Group counts as a single BoL2Q interface.¶
In QUIC [RFC9000], a path is identified by local and remote IP addresses and UDP ports. In BoL2Q, a path is identified by the tuple (BoL2Q interface, local MAC address, remote MAC address).¶
The QUIC stream that carries BGP messages (see Section 6.3).¶
Two BGP speakers are Layer 2 adjacent if they have interfaces in the same Ethernet broadcast domain, whether that is a single cable or a bridged VLAN.¶
BoL2Q is intended for BGP sessions between Layer 2 adjacent speakers. For eBGP, these include private network interconnects, transit and customer hand-offs, bilateral peering at Internet Exchange Points, and the links of routed data-center fabrics. For iBGP, they include sessions between routers that share a link or a VLAN, for example border routers in one point of presence (Section 2.3). The complete configuration of a session may look like:¶
router bgp 64496
neighbor 00:53:00:ab:cd:ef HundredGigE0/0/0 remote-as 64500
psk-keychain PEER-64500¶
The neighbor is identified by its MAC address and the local interface through which it is reached (Section 5). The MAC address is always required. The syntax shown is illustrative only. Whether BoL2Q also has to be enabled on the interface itself, and how, is left to each implementation.¶
No IP addresses, access lists, TTL settings or TCP authentication options are involved. The configuration is the same on every platform, because it does not depend on how the platform implements packet filtering.¶
Compared with existing practice, BoL2Q offers:¶
Reachability confined to the link by construction, with no dependence on correct filter configuration.¶
No IP-layer dependency of the control plane: no ARP, Neighbor Discovery or addressing plan is needed to bring a session up.¶
Mandatory peer authentication and integrity protection via TLS 1.3, with the same operational model as a TCP-MD5 password (a per-peer key).¶
No broadcast or multicast traffic caused by the session: there is no ARP and no IPv6 Neighbor Discovery (Section 5).¶
Control-plane protection without per-peer access lists. Today, every new BGP neighbor has to be added to the control-plane policing filters for IPv4 and IPv6. With BoL2Q, protection consists of a classification by EtherType with its own rate limit, separate from the IPv4 and IPv6 punt classes, and it does not change when peers are added or removed. Rate limits per session, where an implementation provides them, are derived from the session configuration (Section 9).¶
The costs are:¶
A new EtherType has to be recognized and punted to the control plane by forwarding hardware.¶
A QUIC implementation able to run over raw Ethernet is required in the router operating system.¶
Only sessions between Layer 2 adjacent speakers are supported.¶
Shared Layer 2 infrastructures, Internet Exchange Points in particular, commonly admit only the IPv4, ARP and IPv6 EtherTypes. BoL2Q can be used on such an infrastructure only if its operator admits the BoL2Q EtherType (Section 2.2).¶
The MAC address of every peer has to be configured, and has to be updated when the peer's MAC address changes.¶
BoL2Q is not suitable for any session that crosses a Layer 3 hop.¶
BoL2Q uses QUIC as a reliable, authenticated byte stream with TLS 1.3 and protection against resource exhaustion. It does not rely on most other properties of QUIC, such as multiple streams, connection migration, 0-RTT or resilience to middleboxes. The following alternatives were considered.¶
TCP has no length field of its own and takes the length of a segment from the IP header, so the framing of Section 3 would be needed in this case as well. The TCP checksum covers a pseudo-header that contains IP addresses, and TCP-AO [RFC5925] uses IP addresses in its MAC and in key derivation. Both would have to be redefined for MAC addresses, which would create a new security specification that has not been analyzed. Operating system TCP implementations also require an IP layer, so a separate TCP stack would be needed.¶
This needs the same framing and checksum adaptations as above, and combines two stateful protocols where QUIC provides both functions in one.¶
This would have no implementations and no security analysis. One variant considered was the OSI protocol stack, whose addressing is used by IS-IS [RFC1195]. Its network and transport layers would add further headers that nothing in BoL2Q needs, and would reduce the space available for the message. Implementations of OSI protocols in routers are very limited and probably not usable for this purpose.¶
QUIC is specified and analyzed, authenticates peers with TLS 1.3 and provides anti-amplification and Retry mechanisms. QUIC implementations commonly exchange datagrams with the caller and do not access the network themselves, so carrying those datagrams in Ethernet frames instead of UDP needs only a thin adaptation layer. Implementations of [I-D.retana-idr-bgp-quic] will include QUIC in any case.¶
Bilateral sessions at an Internet Exchange Point are configured like any other BoL2Q session, with the MAC address of each peer (Section 5). Exchanges commonly restrict each member port to a registered MAC address, so these addresses are stable in practice, and exchanges can publish them to their members, for example together with the member's IP addresses.¶
A BoL2Q session adds no ARP, Neighbor Discovery or other group-addressed traffic to the peering LAN, which is of particular interest to exchanges that filter or rate-limit such traffic.¶
The exchange has to admit frames with the BoL2Q EtherType between member ports. Because the exchange forwards these frames without inspecting their content, admitting them requires no change other than the EtherType filter.¶
A route server can run BoL2Q sessions with its members. Using the third-party form of the Link Next Hop (Section 8.4), it passes on the MAC address of the member that originated a route, so traffic flows directly between members as it does today with IP next hops.¶
Nothing in BoL2Q is specific to eBGP. An iBGP session between Layer 2 adjacent speakers is configured in the same way, with the remote AS equal to the local AS. Typical cases are routers that share a link or a core VLAN within a point of presence, and route reflectors whose clients are on the same segment.¶
Route reflection [RFC4456] and confederations operate unchanged over BoL2Q. When the Link Next Hop capability (Section 8) is used on iBGP sessions, the propagation rules of Section 8 apply. A route reflector whose clients share a segment reflects a client's route with a third-party Link Next Hop (Section 8.4) that carries the client's MAC address, so the client remains the forwarding next hop, as with IP next hops today. Where the client is not on the segment of the receiving peer, the reflector sets the next hop to itself.¶
A BoL2Q frame is an Ethernet frame [IEEE802.3], optionally carrying IEEE 802.1Q tags, with the following payload:¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination MAC Address (6 octets) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Source MAC Address (6 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional 802.1Q tags) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EtherType (TBD1) | Version | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | QUIC Datagram (Length octets) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value TBD1, to be assigned by the IEEE Registration Authority (Section 11).¶
The BoL2Q header version. This document defines version 0. A receiver MUST silently discard frames carrying a version it does not implement.¶
MUST be set to zero on transmission and MUST be ignored on receipt.¶
The length in octets of the QUIC Datagram field. A QUIC datagram consists of one or more coalesced QUIC packets (Section 12.2 of [RFC9000]).¶
QUIC short-header packets do not carry a length field and extend to the end of the datagram. Because Ethernet pads frames shorter than the minimum frame size, the Length field is needed to delimit the QUIC datagram. A receiver MUST ignore any octets following the QUIC datagram, and MUST silently discard a frame whose Length exceeds the remaining payload.¶
The BoL2Q header occupies 4 octets of the Ethernet payload. The maximum QUIC datagram size is therefore the interface MTU minus 4 octets; for a standard Ethernet MTU of 1500 octets, this is 1496 octets. IEEE 802.1Q tags and the frame check sequence are not part of the MTU and do not reduce this value.¶
A BoL2Q speaker MUST set the max_udp_payload_size transport parameter (Section 18.2 of [RFC9000]) to a value no greater than its interface MTU minus 4, and MUST NOT send QUIC datagrams larger than the value advertised by its peer. QUIC requires paths to support datagrams of at least 1200 octets. BoL2Q therefore requires an Ethernet payload of at least 1204 octets on the interface and on the Layer 2 path between the peers, and a speaker MUST NOT enable BoL2Q on an interface with a smaller MTU. A standard Ethernet MTU of 1500 octets satisfies this.¶
Larger datagrams MAY be used when jumbo frames are configured on both ends of the link. Implementations MAY verify the usable size with Datagram Packetization Layer Path MTU Discovery [RFC8899]. Because the stream layer of QUIC segments BGP messages into packets, no fragmentation mechanism is needed or defined.¶
BoL2Q does not use ARP or IPv6 Neighbor Discovery. This document defines a single way to address a peer: each session is configured with the BoL2Q interface through which the peer is reached and the unicast MAC address of the peer. The MAC address is mandatory. A speaker sends its Initial packets to that address and uses it as the destination of all frames of the session. This document defines no learning of the address of the peer from received frames, and no use of a group MAC address.¶
Consequently, a session causes no broadcast or multicast traffic. The frames of a session are ordinary unicast frames.¶
Automatic discovery of peers is not precluded. A future specification can define it, using a new BoL2Q header version or a distinct ALPN token, and can then change the rules of this section.¶
Unless a future specification defines otherwise, a speaker MUST NOT send BoL2Q frames to a group MAC address (one with the Individual/Group bit set), and MUST silently discard received BoL2Q frames whose destination address is a group address.¶
A speaker MUST use non-zero-length QUIC Connection IDs, so that the two connections that exist between the same pair of MAC addresses during a connection collision can be told apart.¶
The configured MAC address tells a speaker which session an incoming Initial packet belongs to, and therefore which key and which remote AS apply to it. A speaker MUST discard, without sending any response, BoL2Q frames received on a BoL2Q interface from a source MAC address that is not configured as a peer on that interface, and QUIC packets of an existing connection received from any source MAC address other than the configured one.¶
The MAC address is not an authenticator, because MAC addresses can be spoofed on a link. Acceptance of a peer is decided by the TLS handshake (Section 6.2) and by the BGP OPEN exchange: the connection has to authenticate with the key configured for the peer, and the peer AS in the OPEN message has to match the configured remote AS.¶
Operators SHOULD configure the MAC address of each BoL2Q interface explicitly, instead of relying on an address derived from the hardware, so that it does not change when a line card or an optic is replaced. This is already common practice on the ports of some Internet Exchange Points. If a MAC address does change, the configured MAC address has to be updated at the peers of the replaced router; the key and the remote AS are unchanged.¶
BoL2Q uses QUIC version 1 [RFC9000] [RFC9001]. Except as stated in this section, the behavior specified in those documents applies unchanged, with the path definition from the Terminology section replacing UDP/IP addresses and ports.¶
The speaker that sends the first Initial packet of a connection is the QUIC client; the other is the QUIC server. Either speaker MAY initiate.¶
The client MUST offer the Application-Layer Protocol Negotiation [RFC7301] token "bol2q". A server that does not receive this token MUST abort the handshake with the TLS no_application_protocol alert, carried as the QUIC CRYPTO_ERROR 0x0178 (Section 8.1 of [RFC9001]).¶
QUIC packet protection as specified in [RFC9001] is always used. A BoL2Q speaker MUST NOT offer or accept cipher suites without encryption or integrity-only suites.¶
The TLS 1.3 [RFC9846] handshake MUST authenticate both endpoints. Implementations:¶
MUST support authentication with an external pre-shared key (PSK) using the psk_dhe_ke key exchange mode, which provides forward secrecy. The PSK is configured per peer, in the same way as a TCP-MD5 or TCP-AO key today. Operators SHOULD use a distinct key for each peer with at least 128 bits of entropy [RFC9257].¶
MAY support certificate or raw public key [RFC7250] authentication, for example with the peer's key pinned in configuration.¶
The server selects the PSK for an incoming connection by the session that matches the source MAC address of the Initial packet (Section 5). The PSK identity in the ClientHello is configured for the session together with the PSK, and the handshake MUST fail if it does not identify the PSK configured for that session.¶
A BoL2Q speaker MUST NOT send or accept 0-RTT data (Section 4.6 of [RFC9001]). BGP has no use for early data, and refusing it avoids questions about replay of data protected by an external PSK.¶
Control traffic of BGP is small in volume and is processed by the route processor, not by forwarding hardware, so the cost of encryption is not a reason to weaken this profile.¶
The client opens exactly one bidirectional stream, the first client-initiated bidirectional stream (stream ID 0). This stream is the BGP stream and carries BGP messages encoded exactly as they would be on a TCP connection.¶
To have the QUIC layer enforce this, the server MUST set initial_max_streams_bidi to 1, and both endpoints MUST set initial_max_streams_uni to 0. The client MUST set initial_max_streams_bidi to 0. A peer exceeding these limits triggers a STREAM_LIMIT_ERROR as specified in [RFC9000].¶
Carrying several channels per connection, as in [I-D.retana-idr-bgp-quic], is outside the scope of this document. It may be defined by a future document using a distinct ALPN token.¶
This document does not define connection migration. The address of the peer is known from the configuration of the session, so the path of a connection, (BoL2Q interface, local MAC address, configured remote MAC address), is fixed for the lifetime of the connection. A BoL2Q speaker therefore MUST send the disable_active_migration transport parameter (Section 18.2 of [RFC9000]), MUST NOT initiate connection migration, and MUST NOT adopt a different remote MAC address learned from received frames.¶
A connection is bound to its interface. A Link Aggregation Group presents a single MAC address, so rebalancing between its member links is not a path change. If the configured remote MAC address of a session is changed, the connection to the old address is closed and a new one is established.¶
Connection migration is not precluded. A future specification can define it, using a new BoL2Q header version or a distinct ALPN token, and can then replace the rules of this section.¶
Stateless Reset (Section 10.3 of [RFC9000]) and Retry (Section 8.1.2 of [RFC9000]) operate unchanged. Address validation tokens are bound to the path as defined here.¶
The anti-amplification limit for unvalidated paths applies unchanged.¶
ECN is not available, because there is no IP header. ECN validation is not performed.¶
The max_idle_timeout transport parameter SHOULD be set to 0 (disabled), so that liveness is governed by the BGP Hold Time, which is negotiated only later, in the OPEN message. If a non-zero value is used, it SHOULD NOT be smaller than the largest Hold Time that the speaker is willing to negotiate. If the negotiated Hold Time is zero, so that no KEEPALIVE messages are sent, a speaker that has set a non-zero max_idle_timeout SHOULD send QUIC PING frames to keep the connection open.¶
BoL2Q events map to the TCP-related events of Section 8 of [RFC4271]:¶
Completion of the QUIC handshake on a connection initiated by the local speaker corresponds to Tcp_CR_Acked.¶
Completion of the QUIC handshake on a connection initiated by the peer corresponds to TcpConnectionConfirmed.¶
Handshake failure, or receipt of CONNECTION_CLOSE or a Stateless Reset, corresponds to TcpConnectionFails.¶
Because the max_idle_timeout transport parameter is normally disabled (Section 6), a connection on which the peer never sends an OPEN message is closed by the large HoldTimer value that the BGP Finite State Machine uses in the OpenSent state (Section 8.2.2 of [RFC4271]). No additional timer is defined.¶
As there are no transport ports, both speakers can initiate simultaneously and so create two QUIC connections. Each proceeds independently through the OPEN exchange on its BGP stream. Collision detection is then performed exactly as specified in Section 6.8 of [RFC4271], as updated by Section 2.3 of [RFC6286]. The connection initiated by the speaker with the higher BGP Identifier is retained. If both BGP Identifiers are equal, which RFC 6286 permits only between different ASes, the connection initiated by the speaker with the larger AS number is retained. Between speakers of the same AS, equal BGP Identifiers are an error, which is handled as specified in Section 2.2 of [RFC6286] (Bad BGP Identifier).¶
The connection to be dropped is closed by sending a NOTIFICATION message (Cease, Connection Collision Resolution), followed by CONNECTION_CLOSE with the application error code BOL2Q_COLLISION.¶
When BGP closes the session, it sends a NOTIFICATION message where [RFC4271] requires one, closes the BGP stream, and then closes the QUIC connection. The application error code is BOL2Q_BGP_NOTIFICATION if a NOTIFICATION message was sent or received, and BOL2Q_NO_ERROR otherwise. BOL2Q_INTERNAL_ERROR is used when the connection is closed because of an error in the implementation, for example when it runs out of resources.¶
The error handling of UPDATE messages specified in [RFC7606] applies unchanged. In particular, most malformed attributes result in treat-as-withdraw rather than session reset.¶
BFD [RFC5880] single-hop sessions require IP. Where faster detection than the BGP Hold Time is needed on links without IP addresses, operators can rely on link-layer mechanisms such as loss of signal or Ethernet OAM. A BoL2Q-specific liveness mechanism is outside the scope of this document.¶
On a link that carries no interface addresses, there is no IP address to place in the NEXT_HOP of routes learned from the peer. This section defines an optional capability that names a router on the same Ethernet segment as the next hop: either the session peer itself, or a third router identified by its MAC address. It is similar in spirit to the use of IPv6 link-local next hops [RFC8950], but does not depend on Neighbor Discovery.¶
The Link Next Hop capability (code TBD2) is advertised as defined in [RFC5492]. Its value is a list of tuples, each consisting of an AFI (2 octets), a Reserved octet (set to zero) and a SAFI (1 octet), listing the address families for which the speaker can receive Link Next Hop routes. The capability MUST NOT be sent on sessions that do not use BoL2Q, and MUST be ignored if received on such a session. It applies only to address families that are also negotiated with the Multiprotocol Extensions capability [RFC4760].¶
For an AFI/SAFI for which the receiver has advertised the capability, a speaker MAY send MP_REACH_NLRI [RFC4760] with a Link Next Hop in one of two forms, distinguished by the Length of Next Hop Network Address field:¶
The next hop is the BoL2Q peer that sent the UPDATE, reached over the path of this session.¶
The Next Hop Network Address field carries a 48-bit unicast MAC address. The next hop is the router with that MAC address on the same BoL2Q interface over which the UPDATE was received.¶
IPv4 unicast routes with a Link Next Hop are always carried in MP_REACH_NLRI. This document defines Link Next Hops for the unicast SAFI (1) of AFI 1 (IPv4) and AFI 2 (IPv6). Use with other SAFIs is left to future documents. BGP labeled unicast [RFC8277] is a natural first candidate, because it allows MPLS labels to be distributed on links that carry no IP addresses. SAFIs whose next hop includes a Route Distinguisher need further definition of the next hop encoding and of the forwarding of labeled packets.¶
Address families whose next hop is not used for forwarding, such as Flow Specification [RFC8955], need no Link Next Hop. BoL2Q carries them like any other BGP session, and they are not listed in the capability.¶
A receiver MUST treat a third-party Link Next Hop that contains a group MAC address (one with the Individual/Group bit set) as a malformed attribute and handle the UPDATE as treat-as-withdraw [RFC7606].¶
A receiver installs a route with a Link Next Hop with the BoL2Q interface of the session as its outgoing interface. Its Layer 2 destination is:¶
for the peer form, the configured remote MAC address of the session;¶
for the third-party form, the MAC address carried in the attribute.¶
Data packets are ordinary IPv4 or IPv6 frames. When the session goes down, the routes are removed as usual.¶
A speaker that advertises a route with a Link Next Hop to another peer proceeds as follows:¶
If the router that the Link Next Hop denotes is reachable over the same BoL2Q interface as the session to the receiving peer, the speaker MAY advertise the route with a third-party Link Next Hop carrying that router's MAC address. For a route learned with the peer form, this is the configured remote MAC address of the session over which the route was learned. For a route learned with the third-party form, it is the MAC address carried in the attribute.¶
Otherwise, the speaker MUST set the next hop to itself, using one of its own IP addresses, or, on a BoL2Q session that has negotiated the capability for the address family, the peer form of the Link Next Hop. If the speaker has no address it can use, it MUST NOT advertise the route to that peer.¶
Rule 1 lets route reflectors (Section 2.3) and Internet Exchange Point route servers (Section 2.2) keep the originating router as the forwarding next hop, as they do today with IP next hops. Rule 2 matches the common practice of using next-hop-self at the AS boundary.¶
The remote MAC address of a session changes only by reconfiguration, which resets the session. The routes learned over it are then withdrawn, and a speaker that has propagated them under rule 1 withdraws them as well.¶
This document does not specify split-horizon behavior beyond that of [RFC4271] and [RFC4456].¶
Routers that use Link Next Hops on unnumbered links still need a source address for ICMP messages and diagnostics. As on other unnumbered links, the router's loopback address is used.¶
Forwarding hardware may, hypothetically, have a mechanism that resolves a route only through an IP next hop with an IP adjacency, and cannot install a Layer 2 address as the next hop directly. In this case, it is suggested that the implementation uses internal Layer 3 information to work around this limitation, for example an IPv6 link-local address derived from the MAC address of the next hop and bound to that MAC address as a static adjacency, so that neither ARP nor Neighbor Discovery is needed. Such an address is internal to the implementation: it is not configured by the operator, is not sent in any protocol message, and does not change the behavior of BoL2Q on the wire.¶
Since the BGP stream is a reliable, ordered byte stream, it can be presented to an existing BGP implementation through a socket-like abstraction in place of a TCP socket. The BGP message processing code needs no changes; only the configuration and the transport layer are new.¶
Forwarding hardware has to recognize EtherType TBD1 and deliver such frames to the control plane. Implementations:¶
MUST deliver BoL2Q frames to the control plane only from interfaces on which BoL2Q is enabled;¶
MUST classify BoL2Q frames delivered to the control plane by EtherType into a class of their own, separate from the IPv4 and IPv6 punt classes, and MUST support a rate limit for that class, as for the other classes of control plane traffic [RFC6192];¶
SHOULD support, in addition, a rate limit per session, applied to frames whose source MAC address is the configured MAC address of the peer, so that a single peer, or a station using its address, cannot use up the rate limit of the class at the expense of other sessions. Frames from source MAC addresses that are not configured SHOULD be rate-limited separately from all sessions;¶
SHOULD allow the operator to enable or disable BoL2Q per interface, without any per-peer filter entries;¶
SHOULD log the receipt of BoL2Q frames from a source MAC address for which no session is configured (Section 5), and SHOULD limit the rate of such log entries.¶
With TCP-based BGP, control-plane policing filters typically list the addresses of all configured neighbors, and have to be updated whenever a neighbor is added or removed. BoL2Q requires no such entries: frames are admitted by EtherType and interface, and every connection is then authenticated by the TLS handshake (Section 6.2). A rate limit per session uses the MAC address that is already configured for the session, so no separate filter entry has to be maintained.¶
BoL2Q frames are not IP-routed, so a BoL2Q session cannot be reached from beyond its link. The remaining attacker is one that can send or receive frames on the link itself.¶
An on-link attacker cannot establish a session or inject BGP messages without the authentication key (Section 6.2). Spoofing the peer's MAC address does not allow the attacker to take over a session, because QUIC packet protection authenticates every packet and the connection is not moved to a different MAC address. An attacker that sends frames with the source MAC address of a peer can, however, cause switches to associate that address with the attacker's port, and so disrupt delivery of the peer's frames until the peer sends again. This is a denial of service, as with any Ethernet traffic, and does not compromise the session. A station that spoofs the source MAC address of a peer can likewise exhaust the rate limit of that session (Section 9), and so starve the genuine peer of it, but not other sessions. Port security on the switches, such as binding a MAC address to a port, or MACsec reduces this exposure.¶
Frames from a source MAC address for which no session is configured are discarded (Section 5), and implementations are expected to log such attempts (Section 9).¶
An on-link attacker can, however, send Initial packets to consume control-plane resources. The QUIC anti-amplification limit, Retry packets and the rate limits required in Section 9 mitigate this, but cannot eliminate it, just as with TCP-based BGP. The considerations of Section 21 of [RFC9000] apply, with MAC addresses in place of IP addresses.¶
BoL2Q protects only the BGP control session. Where data-plane traffic on a shared Layer 2 infrastructure also needs protection, MACsec [IEEE802.1AE] can be used beneath BoL2Q.¶
The peer form of the Link Next Hop points only to the authenticated peer of a session, at the MAC address configured for it. The third-party form points to a MAC address chosen by the sender. The receiver cannot verify that this address belongs to the router that originated the route, so a peer can steer traffic to any station on the segment. This is the same trust model as for third-party IP next hops on a shared segment today, and the same mitigations apply, for example next-hop checks in route-server policy or at the receiver. The address is always confined to the segment of the session; group addresses are rejected.¶
The IEEE Registration Authority is requested to assign an EtherType for BoL2Q (TBD1).¶
IANA is requested to register "bol2q" in the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry, referencing this document.¶
IANA is requested to assign a value (TBD2) from the "Capability Codes" registry for "Link Next Hop", referencing this document.¶
IANA is requested to create a "BoL2Q Header Versions" registry. Values range from 0 to 255; value 0 is assigned to this document. The registration policy is Standards Action.¶
IANA is requested to create a "BoL2Q Application Error Codes" registry for the QUIC application error codes used by BoL2Q, with the registration policy Specification Required and the following initial entries:¶
| Value | Name | Description |
|---|---|---|
| 0x00 | BOL2Q_NO_ERROR | Session closed without error |
| 0x01 | BOL2Q_BGP_NOTIFICATION | Session closed after a NOTIFICATION |
| 0x02 | BOL2Q_COLLISION | Connection collision resolution |
| 0x03 | BOL2Q_INTERNAL_ERROR | Implementation error |
This section is to be removed before publishing as an RFC.¶
Split-horizon behavior for third-party Link Next Hops, for example whether a speaker should suppress a route whose Link Next Hop is the MAC address of the receiving peer.¶
Willingness of Internet Exchange Point operators to admit the BoL2Q EtherType, and a standard way for exchanges to publish member MAC addresses.¶
Fast failure detection on links without IP (a BoL2Q liveness mechanism, or reliance on Ethernet OAM).¶
Link Next Hop for BGP labeled unicast, for example to build MPLS services on links whose control plane is BoL2Q, and later for the VPN address families. A BoL2Q session must not depend on a pseudowire or label-switched path whose routes are learned over the same session; this needs to be stated when MPLS use is specified.¶
Whether a multi-channel mode aligned with [I-D.retana-idr-bgp-quic] should be defined.¶
This document was written with the assistance of an AI system. Using the keys of [I-D.abaris-aicdh]: mode is ai-originated, because the text was first generated by the AI from the design of the author and then revised at the author's direction; model is Claude, with several versions used and not recorded; provider is Anthropic; and reviewed-by is the author. The design is the author's. The AI also proposed details of the text and of the protocol, which the author reviewed, changed or accepted, and the author is responsible for the whole document.¶
The author thanks the authors of [I-D.retana-idr-bgp-quic] for their work on BGP over QUIC, Eric Vyncke, whose two talks encouraged the author to write this document, and the participants of the IETF IDR working group for discussions on control-plane transport isolation.¶