Summary

  • A 27 October individual Internet-Draft proposes BGP over Ethernet-carried QUIC, without IP or UDP headers. A session is bound to a local interface, configured peer MAC, remote AS and per-peer key; the exchange fabric must admit the proposed EtherType.
  • The optional Link Next Hop capability lets a peer send either its own next hop or a third-party MAC on the same segment. The draft says the receiver cannot verify that the third-party MAC belongs to the route origin. Authentication protects the BGP conversation; next-hop policy determines where data packets can be sent.

The control channel moves downstairs

The author of BoL2Q proposes carrying QUIC packets directly in Ethernet frames. Take away the IP and UDP headers and a BGP session can run only between speakers sharing a Layer 2 segment. Its peer is configured by interface and MAC address, alongside remote AS and a pre-shared key. The draft asks for a new EtherType and hardware support to send those frames to a separate control-plane policing class. An Internet exchange must allow that EtherType across member ports before any such session can form.

This is a deliberate rearrangement of the front door. Today, operators commonly use BGP-4 over TCP/IP and rely on address, filter and authentication settings around that session. The draft moves reachability to an Ethernet segment and peer identity to the configured MAC, TLS handshake and BGP OPEN. A frame from an unconfigured source MAC is discarded. But the MAC itself is a selector, not an authenticator: a station on the link can spoof it. The configured key and remote-AS check decide whether a peer gets through. The proposal requires external PSK support with forward secrecy, forbids 0-RTT data, and fixes the connection to its local interface and peer MAC. A MAC change resets the session.

The link boundary has real value. Off-link hosts cannot IP-route a packet into this particular control session. It also creates a clear local bill of work: somebody at the exchange approves the EtherType; somebody at each router maintains the peer MAC and key; forwarding hardware must recognize and rate-limit the new class. The author acknowledges that on-link spoofing can disrupt switch MAC learning or starve a per-session rate limit even while QUIC prevents a session takeover without the key. A lock on the session does not make the shared switch fabric disappear.

The route points at a different machine

The more consequential change sits in an optional BGP capability. On an unnumbered segment there may be no IP address to use as a route’s next hop. The draft therefore defines Link Next Hop. Length zero means the authenticated session peer. Length six carries a 48-bit unicast MAC for a third router on the same Ethernet segment. A receiver that installs such a route uses the BoL2Q interface and the named MAC as its Layer 2 destination. Data packets remain ordinary IPv4 or IPv6 frames; the control session’s new transport is separate from their forwarding path.

That third-party form is useful to route servers. A server can pass along the originating member’s MAC so traffic goes directly between members, rather than through the server. A route reflector on the same segment can likewise preserve the originating router as the next hop. The propagation rule has a fence: if the named router is reachable on the same BoL2Q interface, the speaker may advertise its MAC; otherwise it must use itself as next hop, or withhold the route if it has no usable address. A changed peer MAC resets the session and withdraws learned routes, including propagated ones.

Now read the draft’s security section instead of its sales pitch. It says the receiving router cannot verify that a third-party MAC belongs to the router that originated the route. A peer trusted to speak BGP can point traffic at any station on that segment. This is where the decision leaves cryptography. The session handshake authenticates the speaker. It does not certify the speaker’s statement about a different device. The draft names route-server policy and receiver-side next-hop checks as the counterweight. An exchange that admits the EtherType but ignores the MAC destination rule has opened one door and left the corridor unguarded.

The proposal is narrow on purpose. QUIC version 1 supplies the protected transport machinery, but this profile disables migration and early data and uses one BGP stream. BGP messages and path selection remain as before. Multihop sessions stay on their existing transports. The requested EtherType and capability code still appear as TBD1 and TBD2 in the individual draft. The text gives an engineering design, not an assigned code point or a working exchange.

The practical question is whether a network can prove the sequence it asks operators to trust: exchange admits frames; router accepts a configured peer; TLS authenticates that peer; BGP OPEN matches the AS; Link Next Hop names a MAC; receiver policy permits the MAC; forwarding hardware installs it. The first four steps can be perfect while the fifth points at the wrong box. That is the distinction this proposal makes unusually visible.

Official originals