A few days ago I posted here about SLDP, a Layer-2 bootstrap protocol for cross-family IPv4 ↔ IPv6 discovery. The feedback was brutal but fair. The main criticisms were:
- Two-way communication is infeasible in OT/brownfield you can't ask PLCs to run new firmware.
- Ethernet broadcast is a net negative; PLCs on RTOS can't afford a permanent listener.
- Everything everywhere would need to implement it.
- Existing protocols (LLDP + orchestration) already solve this.
- The orchestration story was hand-wavy.
I sat with it for a while and I think I was pitching the wrong thing. So I want to try a narrower claim and see if it survives scrutiny.
The reframe: SLDP as a NAT64 state pre-warmer
The real bottleneck in stateful NAT64 isn't throughput Jool, Tayga, and eBPF/XDP implementations are already fast. It's first-packet latency for new flows. The gateway has to:
- Look up the connection in its state table.
- Miss.
- Create a state entry (allocate a port, bind the tuple, insert).
- Then forward.
For a control loop in an OT environment, or a drone joining a swarm, that first-packet cost is real. And when 500 sensors boot at once, the gateway gets hit with a burst of state creation that it wasn't designed for.
What if the state was already there?
SLDP does one thing: one broadcast probe, one unicast reply, one round trip, no IP stack required.
The pipeline is now concrete:
· New IPv6 device boots and broadcasts an SLDP probe (before its IP stack is initialized).
· The NAT64 gateway (or a controller) replies with its cross-family tuple.
· An orchestrator writes a static NAT64 mapping into the gateway's translation table.
· When the IPv6 device's first real packet arrives, the gateway finds a ready entry. No lookup-miss, no state creation, no CPU spike.
This isn't a replacement for NAT64, DNS64, or anything else. It's a pre-processor that eliminates the state-creation hop.
What this fixes from the earlier feedback
· Two-way comms in OT: The legacy IPv4 PLCs don't need SLDP. The gateway speaks on their behalf. Only the new IPv6 device needs a responder and that's roughly 50 lines of firmware, not a full stack.
· Broadcast concern: The responder listens only during a bounded window say 30 seconds after boot, or when triggered by a management command. No permanent daemon. No RTOS-affecting listener.
· Orchestration hand-waving: Now concrete. SLDP → orchestrator → static NAT64 entry → pre-warmed fast path.
· Existing protocols: LLDP advertises passively every 30 s and doesn't carry cross-family tuples. DHCPv6, NDP, and mDNS all require IP stack init. SLDP's specific win is time-to-first-binding.
What it doesn't fix
· Existing IPv6 devices won't speak it. SLDP is a forward-looking protocol for devices being manufactured now that will be deployed over the next 5–10 years. It's not a retrofit. I'm not going to pretend otherwise.
· In managed environments, LLDP + a script can do this. You're right. But it's slower and requires a management plane. In air-gapped, tactical, or ad-hoc environments, that plane doesn't exist.
· Somebody still has to ship firmware. That's the hard part of any new protocol.
What I'm asking
Is the NAT64 acceleration framing a stronger argument? Does it survive the same scrutiny as the original pitch?
Specifically:
· If you ran this in a real OT plant with a real NAT64 gateway, would the first-packet latency reduction matter?
· Are there environments where SLDP's time-to-binding advantage is meaningless because something else already pre-warms state?
· Is there an existing mechanism I'm missing that already solves NAT64 state pre-warming at L2? (I've looked at LLDP TLVs, DHCPv6 + orchestration, and NDP-assisted flows. None give pre-IP binding.)
Code and dissector are on https://github.com/cyberghost-2/Simple-L2-Discovery-protocol-SLDP-
Not trying to sell anything. Trying to figure out if this is a real contribution or a solution in search of a problem. Looking for more feedback from you guys.
Source: r/ipv6 · by /u/1-GH0ST