Lunar Conformance

Lunar implements the RADIUS base protocol fully and correctly. It answers the wire the way the RFCs require (packet structure and length rules, the Request/Response Authenticator, attribute encoding, duplicate handling and the standard request/response codes) so it interoperates with standards-compliant NAS equipment out of the box.

What it supports today

Lunar implements the RADIUS protocol itself, so the core AAA feature set an ISP needs is available now:

Authentication, accounting and dynamic authorization (RFC 5176 CoA / Disconnect).
PAP, CHAP, MS-CHAP and MS-CHAPv2.
Multiple virtual RADIUS servers per instance, standard and vendor attribute dictionaries, tagged and vendor-specific attributes.
Message-Authenticator handling to current best practice (post BlastRADIUS / CVE-2024-3596).
Optional Kafka streaming of authentication and accounting events for billing, analytics and audit.

Our focus has deliberately been on the functionality ISPs actually run in production. A few more enterprise-oriented pieces are not built yet:

RADIUS over TCP and RadSec (RADIUS over TLS).
EAP methods such as EAP-TLS, EAP-TTLS and more.

These are on the roadmap and, because lunar already implements the RADIUS protocol end to end, adding fundamental features like these is quick and straightforward. We add them on a short timeline based on customer demand. If you need an enterprise feature that is not here yet, it can usually be supported surprisingly fast. Just ask.

Standards and interoperability

Lunar follows the RADIUS standards strictly, so it interoperates cleanly with other vendors' equipment. There are no lunar-specific quirks on the wire. It has been tested against FreeRADIUS clients, proxies and servers, including in production.

Lunar also runs alongside other vendors' RADIUS servers, exchanging RADIUS with them directly (both serving requests to them and receiving requests from them). That includes FreeRADIUS, the well-known open-source RADIUS server. So it drops into an existing multi-vendor RADIUS environment rather than requiring you to replace it.

In live production at large internet service providers, lunar already serves many NAS devices, Wi-Fi hotspots and other equipment, collectively handling hundreds of millions of requests per day. Known interoperable vendors include:

NetElastic	Juniper (MX)	MikroTik
Cisco	Nokia	H3C
Huawei

Implemented

Area	Standard	What lunar implements
Core protocol	RFC 2865: RADIUS	The base protocol: Access-Request / Access-Accept / Access-Reject / Access- Challenge, the Request and Response Authenticators, the 4096-byte packet limit, attribute encoding and duplicate-attribute ordering (s4.1), the User-Password hiding scheme (s5.2), CHAP (s5.3), the Vendor-Specific attribute (s5.26) and Proxy-State echo (s5.33).
	RFC 2866: RADIUS Accounting	Accounting-Request / Accounting- Response with the accounting Request Authenticator, Start / Interim-Update / Stop handling and the usage counters.
	RFC 2869: RADIUS Extensions	The gigawords counters used to represent 64-bit usage totals across 32-bit counter wraps.
Dynamic authorization and liveness	RFC 5176: Dynamic Authorization (CoA / Disconnect)	Both directions: inbound CoA-Request / Disconnect-Request forwarded to your backend for a decision, and outbound CoA / Disconnect relayed from your backend to a NAS with ACK / NAK handling.
	RFC 5997: Status- Server	The liveness probe, used both when a NAS probes lunar and by lunar's own full-path virtual ping route.
Attributes, tunnels and data types	RFC 2868: Tunnel attributes	Tagged attributes, with the tag carried on the attribute name (name:tag).
	RFC 3162: RADIUS and IPv6	IPv6 address and related attribute types.
	RFC 6929: Extended attributes	The extended attribute space and TLV encodings.
	RFC 8044: Data Types in RADIUS	The standard attribute data-type model lunar's dictionaries use.
Security	RFC 3579: RADIUS support for EAP	Lunar adds and verifies Message- Authenticator, the mitigation for BlastRADIUS (CVE-2024-3596), per client policy.
Authentication methods	RFC 1994: CHAP	The challenge/response material is delivered to your backend for verification.
	RFC 2433: MS- CHAP; RFC 2759: MS-CHAPv2; RFC 2548 layout	Microsoft CHAP and MS-CHAPv2, with the RFC 2548 vendor attribute layout; challenge/response material is delivered to your backend for verification.
Address and number formatting	RFC 5952: IPv6 text representation	Canonical IPv6 text representation when lunar emits addresses, so IPv6 values are formatted consistently in the JSON your backend receives.

Partially implemented / specific scope

EAP (RFC 3579 transport): Lunar fully transports EAP: it carries EAP-Message attributes and relays the multi-round Access-Challenge exchange, correlating rounds on the State attribute (RFC 2865 s5.33). But it does not itself terminate any specific EAP method today. A method such as EAP-TLS runs in your backend across those rounds. Native EAP-TLS termination inside lunar is on the roadmap, see Authentication.