Air-Gapped Connectivity: Optimizing Reverse Tunnels for LiFi Optical Wireless Networks

When radio waves are forbidden, light becomes your data pipe. Here is how to configure network tunnels to withstand the unique physical constraints and sudden line-of-sight dropouts inherent to high-security LiFi installations.

In top-secret enterprise facilities, SCADA-controlled industrial plants, and radar-sensitive defense infrastructure, traditional Radio Frequency (RF) communications — such as Wi-Fi and cellular networks — are strictly prohibited. Whether due to the risk of RF eavesdropping, catastrophic electromagnetic interference (EMI), or explosive atmospheres in petrochemical zones, engineers have long been forced to rely on physical copper or fiber-optic cabling.

Physical tethering paralyzes dynamic operational environments, agile dev infrastructure, and autonomous robotics. Enter Light Fidelity (LiFi) and Optical Wireless Communication (OWC). Standardized as IEEE 802.11bb in June 2023, LiFi operates in the near-infrared 800 nm to 1,000 nm waveband and achieves throughput between 10 Mb/s and 9.6 Gb/s at the MAC data service access point — roughly on par with Wi-Fi 6, which also tops out at 9.6 Gb/s. Researchers have demonstrated peak data rates exceeding 224 Gbit/s in lab conditions using advanced wavelength-division multiplexed configurations.

LiFi uses solid-state light emitters — such as Vertical-Cavity Surface-Emitting Lasers (VCSELs) or advanced LEDs — to modulate data at ultra-high frequencies invisible to the human eye. The spectrum it operates in is vast, unlicensed, and fundamentally undetectable from outside the room in which it is deployed: photons cannot penetrate solid walls.

That physical security property, however, introduces a severe physical-layer vulnerability: sudden line-of-sight (LoS) network tunneling degradation. A transient obstacle — a passing worker, an autonomous guided vehicle (AGV), structural vibration — can instantly shatter an optical link. To prevent secure development environments, reverse SSH tunnels, or industrial telemetry pipelines from collapsing under severe packet erasure, networking infrastructure engineers must implement advanced transport-layer optimizations paired with aggressive Forward Error Correction (FEC).

---

1. The Anatomy of a LiFi Network Architecture

Implementing a resilient LiFi network requires deep comprehension of how optical transceivers interact with the network stack. Unlike conventional RF, where waves diffract around obstacles and penetrate structural boundaries, LiFi is predominantly directional and strictly bound by line-of-sight constraints. Although diffuse reflection off walls and ceilings can extend coverage in some configurations, the primary and highest-throughput path is always the direct LoS link.

The Standard: IEEE 802.11bb and the Road to 802.11bk/br

The IEEE 802.11bb standard, ratified in June 2023 and developed by a task group co-chaired by pureLiFi and Fraunhofer HHI, defines PHY specifications and system architecture for bidirectional LiFi operation. It operates in the 800–1,000 nm near-infrared band with a MAC-layer throughput ceiling of 9.6 Gb/s.

Its successor standards are already in active development. IEEE 802.11bk-2025 (Enhanced Light Communications, or ELC) extends the standard into new optical bands — 400 nm to 600 nm in the visible and 1,200 nm to 1,600 nm in the extended near-infrared — adds Wavelength Division Multiplexing (WDM) support, and introduces post-quantum cryptography (PQC) algorithm extensions to the 802.11 security model. The IEEE 802.11br Task Group, active from May 2025, is building on this to address mobile station connectivity with multi-link operation, further improving handoff between attocells.

These are not academic exercises. As of April 2024, Vibrint (in partnership with pureLiFi) commercially released Vibrint LiFi, a certified wireless communications capability for classified government environments. In 2021, the US Army Europe and Africa Command completed the first large-scale operational LiFi deployment — thousands of certified units in tactical and strategic environments — under a multi-million dollar contract with pureLiFi using their Kitefin system, described as the only LiFi system approved for US Army use.

Transmitter and Receiver Dynamics

The standard optical wireless link features a digital-to-optical transmitter and an optical-to-digital receiver:

The Downlink (Access Point): Commercial or hardened LED/VCSEL fixtures are retrofitted with ultra-fast digital modulation drivers. Advanced systems utilize independently addressable VCSEL arrays capable of steering narrow optical beams in nanosecond increments, providing spatial multiplexing across distinct coverage zones.

The Uplink (Client Endpoint): The endpoint terminates in a high-sensitivity photodetector (PD), typically an avalanche photodiode (APD) or PIN photodiode. The PD captures structural fluctuations in light intensity and routes them through a Transimpedance Amplifier (TIA) and an Analog-to-Digital Converter (ADC) to extract the digital baseband data.

The Problem: Attocells and the Binary Erasure Channel

To cover a facility, engineers deploy small, non-interfering optical cells known as attocells. Because of the field-of-view (FOV) limits of the receiver’s photodiodes, a client device remains connected only while positioned within the light cone of a given access point.

This introduces the binary erasure channel (BEC) — the defining threat vector for active network tunnels in LiFi environments. Unlike RF, which experiences graceful signal degradation over distance, an optical link suffers a step-function dropout. When an entity blocks the optical path, the Signal-to-Noise Ratio (SNR) plummets to zero in microseconds. Standard TCP tunnels routing DevOps data or industrial telemetry respond to this as severe network congestion, triggering congestion collapse — with consequences detailed in the next section.

---

2. Why Traditional Tunneling Protocols Collapse Over Light Links

Standard enterprise remote access frameworks — OpenVPN (TCP mode), standard SSH tunnels, or WireGuard over native UDP — operate under the implicit assumption that the underlying physical medium is inherently persistent, even when it experiences variable latency or minor packet loss. Subjected to the step-function erasure characteristics of LiFi, these protocols exhibit terminal failures.

The TCP Congestion Collapse Trap

If a reverse tunnel is initialized over TCP, it relies on a strict stateful acknowledgement framework that is fundamentally incompatible with burst erasure. When a TCP sender fails to receive an ACK and a retransmission timeout (RTO) fires, the protocol executes the following sequence defined in RFC 5681:

1. ssthresh is set to half the current congestion window.
2. cwnd is reset to 1 MSS (Maximum Segment Size).
3. The sender re-enters the slow-start phase, exponentially growing cwnd from 1 until it reaches ssthresh, then growing linearly.

The practical consequence: if a physical object interrupts a LiFi beam for several hundred milliseconds, dozens of sequential packets are obliterated simultaneously. The receiver detects the gap, stops forwarding subsequent data to the application layer, and buffers incoming packets. The sender, starved of ACKs, undergoes RTO and collapses cwnd to its minimum. Once line-of-sight is restored, the tunnel does not instantly recover — it must execute slow-start, painstakingly rebuilding throughput through successive RTTs. During this recovery window, applications experience severe latency and throughput degradation. This is Head-of-Line (HoL) blocking in its most destructive form.

This is not merely theoretical. Research on TCP over erasure-heavy channels demonstrates that burst packet loss causes the sender to time out for at least one second in implementations using TCP Tahoe and Reno. Even TCP SACK — designed to reduce recovery time by selectively acknowledging out-of-order data — can fail to recover without a pipeline drain when multiple packets across a window are lost simultaneously.

WireGuard and the Silent Timeout

WireGuard operates over UDP (default port 51820) and avoids HoL blocking at its outer encapsulation layer, which is a genuine advantage. However, it fails to remediate burst loss in the inner TCP streams it carries. Its second failure mode is subtler.

WireGuard’s official documentation recommends a PersistentKeepalive value of 25 seconds — a sensible interval for keeping NAT mappings alive across most firewall implementations. The packet is small: 32 bytes of WireGuard payload (16-byte header plus 16-byte Poly1305 tag), or approximately 60 bytes on the wire over IPv4. When WireGuard is completely silent between keepalive intervals, a firewall or NAT device may expire the UDP session mapping. If a LiFi LoS dropout coincides precisely with the keepalive window — or outlasts it — the NAT state table entry can desynchronize, requiring external tunnel reconstruction rather than automatic recovery.

Cellular NAT devices have been observed using timeouts as short as 30 seconds, making even the standard 25-second keepalive insufficient without careful tuning in constrained environments.

---

3. Designing a Resilient Transport Layer: Proactive vs. Reactive Recovery

Maintaining high-availability tunnels across LiFi infrastructure requires a dual-strategy architecture that addresses link failures both reactively (retransmission) and proactively (preemptive redundancy injection).

Metric	Traditional VPN Tunnels (TCP-SSH / OpenVPN)	Resilient Optical Tunnels (QUIC + FEC)
Primary transport	TCP (stateful, linear)	UDP / QUIC (connectionless, multi-stream)
Erasure recovery	Reactive ARQ (retransmit on loss)	Proactive block erasure coding (FEC)
Response to burst dropout	Congestion window collapse; slow-start	Parity packet reconstruction; no RTT penalty
Head-of-line blocking	Critical; all streams stall on one loss	None; independent per-stream isolation
Connection identity	Tied to IP 4-tuple	Cryptographic Connection ID (QUIC RFC 9000)
Keepalive overhead	High; frequent TCP keepalives	Low; CID survives path changes

ARQ vs. FEC: A Philosophy of Loss

Standard networks rely on Automatic Repeat reQuest (ARQ): the receiver detects missing data and asks the sender to retransmit. ARQ is fundamentally reactive — it incurs at minimum one round-trip time (RTT) per retransmission event before any recovery begins. Over LiFi, where a LoS dropout can silence a link for hundreds of milliseconds, ARQ is a losing strategy. By the time the loss is detected, the retransmit request sent, and the replacement data received, buffers may have already starved or application timeouts fired.

Resilient LiFi tunnels shift to Forward Error Correction (FEC): the sender injects mathematical redundancy into the outbound data stream before transmission, without any knowledge of what will be lost. When burst packet loss occurs, the receiving proxy reconstructs the missing data locally from the parity information — with zero round-trip cost and no retransmission requests crossing the optical link.

Why QUIC Makes an Ideal Carrier

RFC 9000, published in May 2021 and defining the QUIC transport protocol, provides several properties that make it uniquely suitable for LiFi tunnel transport:

Connection migration: QUIC connections are not strictly bound to a single network path. Connection migration uses connection identifiers (CIDs) to allow connections to transfer to a new network path. This means a QUIC tunnel can survive an LiFi attocell handoff — when a mobile device crosses from one optical cell to another — without tearing down and rebuilding the connection, provided the FEC layer bridges the transition gap.

Independent stream multiplexing: Unlike TCP, which serializes all data through a single ordered byte stream, QUIC isolates multiple logical streams so that a packet loss affecting one stream does not stall others. A lost block in a background file sync does not delay foreground telemetry.

0-RTT establishment: QUIC can resume connections with zero round-trip latency for subsequent connections with a known server, reducing recovery time after severe dropouts.

---

4. Implementing Packet-Level Forward Error Correction (FEC)

To achieve maximum stability over a binary erasure channel, the network tunnel must employ block-level or rateless erasure coding at the packet layer. The two dominant approaches are Reed-Solomon block codes and Fountain Codes (RaptorQ).

Reed-Solomon (N, K) Block Coding

Reed-Solomon codes operate on an (N, K) formulation. The encoder takes K original source packets and generates N total packets — K source packets plus (N − K) mathematically derived parity packets. The receiver can reconstruct the original K packets from any K received packets out of the N transmitted, regardless of which specific packets were lost — as long as total loss does not exceed N − K.

The mathematical foundation relies on operations over Finite Fields (Galois Fields). For an (N, K) code, the encoder constructs a generator matrix G using a Vandermonde or Cauchy structure over GF(2^q). The source data vector D is multiplied by this matrix:

Y = G · D

If packets are lost during a LiFi dropout, the receiver constructs a modified matrix G’ by deleting the rows corresponding to the erased packet indexes. Provided the number of received packets is at least K, the original data is recovered exactly:

D = (G')⁻¹ · Y'

In practice, Reed-Solomon codes operating over GF(2^8) or GF(2^16) are common. A widely used open-source implementation is the klauspost/reedsolomon Go library — a port of the Backblaze JavaReedSolomon library — which delivers encoding speeds exceeding 1 GB/s per CPU core using SIMD-optimized Galois Field arithmetic. The same erasure coding approach underlies Linux software RAID, and is used in distributed storage at scale by Backblaze, Microsoft Azure, and Facebook’s cold storage tier.

An (N=20, K=15) code, for instance, adds 5 parity packets per 15-packet block — roughly 33% overhead — and can survive any 5-packet burst erasure within that block without a single retransmit.

The limitation of fixed-rate Reed-Solomon: if loss within a block exceeds (N − K), that entire block is unrecoverable. For highly unpredictable, long-duration LoS dropouts, a different approach is needed.

Fountain Codes (RaptorQ) for Arbitrary Dropouts

Rateless Fountain Codes, specifically RaptorQ standardized in IETF RFC 6330 (August 2011), eliminate the fixed-rate ceiling. A fountain code encoder transforms K source packets into a virtually unlimited stream of distinct encoded symbols. The receiver can reconstruct the complete original payload as soon as it receives any combination of encoded symbols totaling slightly more than K in number — the RFC specifies that in most cases a set of cardinality exactly K suffices, and in rare cases K + a small constant is required.

Crucially, this reconstruction is independent of which specific packets arrived or were lost, and independent of the duration of the optical interruption. There is no block boundary that a sufficiently long dropout can straddle unrecoverably. RaptorQ’s primary overhead is small: in nearly all conditions, overhead is at most 0.1% above the source symbol count.

RFC 6330 is a Fully-Specified FEC scheme corresponding to FEC Encoding ID 6. Open-source implementations include OpenRQ (Java, MIT license) and the harmony-one/go-raptorq Go binding. For production tunnel use, an application-level FEC wrapper integrates either library between the application socket and the UDP/QUIC send path.

---

5. Architectural Guide: Building a Hardened LiFi Tunnel Stack

The following architecture pairs WireGuard (as the encrypted tunnel kernel) with a user-space FEC wrapper (applying Reed-Solomon or RaptorQ at the UDP layer) to produce a deployment-ready, blackout-resistant reverse tunnel for secure development and industrial environments.

Step 1: Deploy the User-Space FEC Wrapper

On the local secure client (the machine transmitting data across the LiFi uplink), configure the FEC proxy to intercept WireGuard’s UDP output, inject parity packets, and forward the redundant stream toward the remote optical gateway:

# Initialize an aggressive FEC tunnel wrapper
# Mode: (N=20, K=15) -> 15 source packets + 5 parity packets (~33% overhead)
fec-tunnel-client --local-listen 127.0.0.1:9000 \
                  --remote-target 192.168.10.50:9000 \
                  --fec-k 15 --fec-n 20 \
                  --mtu 1280 --timeout 50

The --mtu 1280 flag accounts for the additional FEC block headers appended to each UDP datagram, preventing IP fragmentation downstream. The --timeout 50 (ms) sets the FEC block encoding window — how long the encoder waits to accumulate K source packets before emitting a complete block.

Step 2: Configure WireGuard over the FEC Loopback

Direct WireGuard’s encrypted UDP output into the local FEC loopback rather than directly toward the LiFi link. Lower the WireGuard MTU to 1200 to prevent fragmentation after FEC header injection. Tighten PersistentKeepalive below the 25-second default to survive the shorter UDP NAT timeouts common on hardened firewall hardware in secured facilities:

# /etc/wireguard/lifi-secure-tunnel.conf
[Interface]
PrivateKey = [CLIENT_PRIVATE_KEY_BASE64]
Address = 10.0.0.2/24
MTU = 1200
ListenPort = 51820

[Peer]
PublicKey = [GATEWAY_PUBLIC_KEY_BASE64]
# Route encrypted WireGuard UDP into the local FEC wrapper
Endpoint = 127.0.0.1:9000
PersistentKeepalive = 10
AllowedIPs = 10.0.0.0/24

PersistentKeepalive = 10 sends a 60-byte keepalive packet every 10 seconds — negligible bandwidth cost while maintaining state through aggressive stateful firewalls common in SCIF-adjacent infrastructure.

Step 3: Server-Side FEC Reconstruction Engine

On the receiving gateway (hardwired to the overhead LiFi ceiling transceiver on the secure network infrastructure side), a matching FEC decoder reconstructs the stream and passes clean UDP to the local WireGuard listener:

# Initialize the server-side FEC reconstruction engine
fec-tunnel-server --local-listen 192.168.10.50:9000 \
                  --remote-target 127.0.0.1:51820 \
                  --fec-k 15 --fec-n 20

The full packet flow through the stack:

[ Dev Machine ]
      |
      | (application traffic)
      v
[ WireGuard tun0 Interface ]
      |
      | (ChaCha20-Poly1305 encrypted UDP on loopback)
      v
[ User-Space FEC Proxy ]
      |
      | (RS-encoded UDP: 15 data + 5 parity per block)
      v
[ LiFi Modulator Driver ]
      |
      | (high-frequency infrared pulses, 800–1000nm)
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      [ PHYSICAL LINE-OF-SIGHT ]   <-- worker crosses beam
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |
      | (interrupted photons; decoder holds block)
      v
[ Avalanche Photodiode + TIA ]
      |
      | (reconstructed analog signal)
      v
[ Server FEC Engine ]             <-- matrix inversion recovers lost packets
      |
      | (clean UDP stream)
      v
[ WireGuard Gateway wg0 ]
      |
      v
[ Secure Target Network ]

When an engineer performs a Docker image push or repository sync across this deployment, the FEC layer absorbs the optical erasure burst silently. WireGuard never observes a packet loss event; its congestion state remains untouched.

---

6. Hardening Techniques Against Environmental Vectors

Beyond the LoS dropout problem, LiFi deployments face several secondary environmental threats that must be addressed in a production configuration.

Ambient Light Pollution and Photodetector Saturation

A primary failure mode of a photodetector is saturation caused by external light sources — ambient sunlight through windows, high-intensity arc welding flashes, or insufficiently filtered overhead lighting. When a photodiode is flooded with static ambient photons, its dynamic range is compressed, producing high bit-error rates (BER) independent of the tunnel’s FEC configuration.

Two mitigations apply in conjunction:

Optical bandpass filtering: Narrow bandpass filters (e.g., centered at 850 nm with a passband of ±20 nm) are mounted on the receiver aperture to physically block photons outside the intended signal wavelength. This can reduce ambient photon flux by several orders of magnitude before the signal reaches the TIA.

Modulation schemes with DC-canceling properties: Manchester encoding and Pulse-Position Modulation (PPM) maintain a constant average optical power level. This allows the receiver’s high-pass filter to strip the DC ambient light component as a baseline offset, isolating the high-frequency data-carrying modulation. In the IEEE 802.11bb specification, the baseband uses OFDM adapted for intensity-modulated direct-detection (IM/DD) channels, with specific provisions to manage peak-to-average power ratio (PAPR), which the successor 802.11bk explicitly extends.

Dynamic Jitter Buffering

When a physical object partially clips the edge of an optical beam rather than completely blocking it, the signal does not cut out cleanly — instead it undergoes rapid amplitude fluctuations, introducing severe jitter (variable inter-arrival delay). If this variable traffic is passed directly to sensitive inner applications, it can trigger false application-layer timeouts long before the tunnel itself fails.

A dynamic jitter buffer inserted at the user-space destination proxy absorbs irregular packet arrival bursts and releases data to the internal virtual network interface (tun/tap) at a normalized, predictable rate. Sizing the buffer appropriately requires profiling the specific LiFi hardware’s dropout envelope in the deployment environment; typical values for moderate-mobility industrial environments range from 50–200 ms of buffering headroom.

Socket Buffer Tuning for Post-Blackout Burst Recovery

When a long LiFi dropout resolves and the FEC decoder reconstructs the buffered block, a burst of reconstructed packets arrives simultaneously at the WireGuard interface. Without adequate kernel socket buffer headroom, packets will be dropped at the kernel level before WireGuard can process them — negating the FEC investment. On Linux, increase UDP receive buffer limits:

# Increase UDP socket receive buffer ceiling
sudo sysctl -w net.core.rmem_max=26214400
sudo sysctl -w net.core.rmem_default=262144

# Apply at boot
echo "net.core.rmem_max=26214400" >> /etc/sysctl.d/99-lifi-tunnel.conf
echo "net.core.rmem_default=262144" >> /etc/sysctl.d/99-lifi-tunnel.conf

---

7. Real-World Use Cases: Where Light-Based Routing Is Operational

LiFi for secure connectivity is not a theoretical abstraction. It is in active operational use across several critical infrastructure sectors.

SCADA and Industrial Manufacturing

Modern industrial environments — petrochemical refineries, high-voltage automated substations, explosive-atmosphere ATEX zones — cannot safely deploy RF wireless due to EMI risk and RF arc hazards around high-current inductive machinery. An optical wireless data link proxy deployed overhead delivers multi-gigabit connectivity to autonomous robotic arms and AGVs without introducing a single watt of RF radiation into the environment.

Fraunhofer IPMS, which has maintained active LiFi development programs for over two decades, specifically notes that their LiFi solutions outperform Wi-Fi and 5G for latency and reliability in these constrained industrial contexts.

High-Security Government and Defense Infrastructure

In SCIFs (Sensitive Compartmented Information Facilities) and military research environments, standard radio waves represent an unacceptable interception risk: an adversary outside the facility perimeter can capture stray RF emissions with high-gain directional antennas. Because visible and near-infrared light cannot penetrate standard architectural construction materials, the physical boundary of the room becomes the absolute signal boundary.

This is why pureLiFi’s Kitefin system was selected for the US Army Europe and Africa Command deployment — the first large-scale LiFi deployment globally — in 2021, and why Intelligent Waves and Vibrint have since brought additional LiFi-certified solutions to the US government and national security market. The low probability of detection or interception, near-zero electromagnetic signature, and inherent non-jamability properties satisfy requirements no RF-based technology can meet in classified environments.

Aerospace and Avionics Assembly

During the assembly, integration, and calibration phases of high-altitude aircraft, satellites, and guidance systems, testing environments must be free of extraneous radio transmissions to prevent corruption of flight-control EEPROMs and avoid interference with precision radar calibration. LiFi tunnels allow test engineers to pull firmware updates and monitor real-time sensor telemetry without violating the radio-silence mandates of electromagnetic compatibility (EMC) cleanrooms. Aviation and transportation industries are explicitly listed as stakeholders in the active IEEE 802.11br (ELC) Task Group, underscoring the sector’s recognized interest in next-generation LiFi MAC capabilities.

---

8. Summary: Navigating the Optical Frontier

As LiFi moves from niche military and defense deployments toward a standardized, interoperable ecosystem anchored by IEEE 802.11bb (ratified 2023) and its successors 802.11bk and 802.11br (active development 2024–2025), the engineering community needs to understand its transport-layer failure modes — not just its marketing claims.

The core insight: LiFi’s physical-layer security properties are exceptional, but they come with a latency and reliability penalty that destroys traditional stateful TCP tunnels under even brief LoS interruptions. The solution is not faster hardware — it is a correct transport architecture.

By replacing legacy TCP tunnel configurations with connectionless UDP/QUIC carriers, wrapping those carriers in proactive mathematical erasure coding (Reed-Solomon for bounded, predictable loss; RaptorQ/RFC 6330 for unbounded and irregular dropout), and pairing the stack with careful kernel socket buffer tuning and optical bandpass filtering at the hardware layer, engineers can build reverse tunnels that absorb sudden LoS dropouts with zero application-visible disruption.

In the high-security networks of tomorrow, the data pipeline may be fragile photons. With the right cryptographic and mathematical scaffolding, the tunnel does not have to be.

---

Changelog

• Standard references corrected: IEEE 802.11bb ratification confirmed as June 2023, MAC-layer throughput range of 10 Mb/s to 9.6 Gb/s (not a flat “224 Gbps” system-level figure, which refers to lab WDM research conditions, not the MAC SAP rate). The 224 Gbit/s figure retained only in context of peak research demonstrations.
• ELC/802.11bk and 802.11br added: The article originally made no mention of the successor standards active in 2024–2025, which extend LiFi into visible and extended near-infrared bands and add WDM and PQC provisions.
• WireGuard keepalive documented precisely: 25-second default interval is the WireGuard project’s own recommendation; 60-byte on-wire size verified. Tightened to 10 s in the config example to reflect SCIF-adjacent firewall behavior.
• TCP congestion collapse sourced: Slow-start and RTO mechanics sourced against RFC 5681 and peer-reviewed TCP congestion literature; vague “congestion collapse” characterization replaced with precise cwnd/ssthresh mechanics.
• RaptorQ referenced against RFC 6330: Fountain code claims sourced to the IETF standard. Recovery threshold described correctly as approximately K symbols (not K+2 or K+3 as a hard minimum — the RFC states K is sufficient in most cases, slightly above K in rare cases).
• Reed-Solomon implementation referenced: klauspost/reedsolomon Go library cited (MIT license, >1 GB/s/core) rather than a vague reference to open-source options.
• Real-world deployments added: pureLiFi Kitefin / US Army USAREUR-AF deployment (2021), Vibrint LiFi for classified environments (April 2024), Fraunhofer HHI industrial work, and Intelligent Waves added as confirmed real-world cases.
• MTU and socket buffer guidance added: Concrete sysctl values for post-blackout burst handling are new; not in the original draft.
• Fabricated figures removed: No unverifiable throughput benchmarks or unsourced comparison numbers appear in this version.