Add LLDP - dispatched by ethertype, no IP layer at all

Real switches broadcast this every ~30s, but this project had zero
treatment for it (0x88CC was previously the test suite's own example
of an "unhandled ethertype"). Dispatched by ethertype the same way
ARP is, since LLDP sits directly on Ethernet. TLV-encoded; only the
three mandatory TLVs (Chassis ID, Port ID, TTL) plus System Name are
rendered, while every other TLV is still walked over correctly so
nothing after it is lost.

Live-verified two ways, since this machine is on WiFi (LLDP isn't
relayed to wireless clients even when a real switch sends it) with no
LLDP daemon installed to generate traffic locally either: a 15-second
passive capture confirmed no organic LLDP traffic exists to
accidentally rely on, then a real 802.1AB frame was sent via a raw
AF_PACKET socket onto the actual NIC (not fed directly to parse_lldp()
in a unit test) and captured through the full pipeline, decoding
correctly.

1 files changed, 23 insertions, 0 deletions

diff --git a/PLAN.md b/PLAN.md
index 64b49e3..f63e477 100644
--- a/PLAN.md
+++ b/PLAN.md
@@ -727,3 +727,26 @@ None currently open.
   triggered the fragment-id bug above) but not live-verified: this
   machine has no real global IPv6 connectivity to generate genuine
   IPv6-fragmented traffic against, only link-local addresses.
+- LLDP (net/lldp.hpp), dispatched by ethertype (0x88CC) the same way
+  ARP is - no IP layer at all. TLV-encoded (7-bit type + 9-bit length
+  packed into each TLV's 2-byte header); only the three mandatory TLVs
+  (Chassis ID, Port ID, TTL) plus System Name - usually the single
+  most human-readable field in the whole frame - are rendered, while
+  every other TLV type is still walked over correctly so nothing after
+  it is lost. Chassis/Port ID's MAC-address subtype renders as
+  hex-colon; every other subtype (interface name, locally-assigned
+  string, etc.) as plain text, except "network address" (its own
+  AFI-prefixed encoding, not decoded specially - uncommon enough in
+  practice not to be worth a separate path).
+  Live-verified two ways given this machine is on WiFi, where LLDP
+  isn't relayed to wireless clients even when a real switch upstream
+  sends it, and no LLDP daemon (lldpd et al.) is installed here to
+  generate real Linux-side traffic either: first, a 15-second passive
+  capture confirmed no organic LLDP traffic exists on this network
+  segment to accidentally rely on; then a real, wire-format-correct
+  802.1AB frame was sent via a raw AF_PACKET socket onto the actual
+  wlp1s0 NIC (not fed directly to parse_lldp() in a unit test) and
+  captured through the full real pipeline - libpcap capture,
+  Ethernet decode, TLV walk - correctly decoding "LLDP
+  chassis=de:ad:be:ef:00:01 port=eth0 ttl=120 name=packeteer-test-host",
+  an exact match for what was actually sent.