Languages
πΊπΈ English | π·πΊ Π ΡΡΡΠΊΠΈΠΉ
Net Lattice is a modern, cross-platform Rust library for configuring and inspecting operating system networking through a single, strongly typed API.
Status: Net Lattice provides cross-platform network inspection, route and address mutation, and synchronous change monitoring with an optional async interface through native operating-system APIs on Linux, Windows, and macOS. Stage 0.12 of the architecture plan has shipped; see Current Status below.
Operating systems expose networking configuration and state through wildly different, low-level, and often platform-specific interfaces: Linux Netlink, the Windows IP Helper API, and macOS BSD routing facilities, among others. Applications that need to inspect or configure networking β IP addresses, routes, interfaces, neighbors, and more β are typically forced to either shell out to external tools, parse text output, or write and maintain separate platform-specific integrations.
Net Lattice aims to unify these interfaces behind a single, strongly typed, idiomatic Rust API, so that consumers never need to deal with raw platform structures, shell commands, or ad hoc string parsing.
Cross-platform networking tooling in the Rust ecosystem is fragmented. Existing solutions are frequently platform-specific, incomplete, or built around shelling out to system utilities such as ip, netsh, or route. This is fragile, hard to test, and unsuitable for building robust, production-grade network management software.
Net Lattice is intended to fill this gap by providing a single, well-designed abstraction layer over native OS networking APIs.
- Strong typing over strings. Consumers interact with typed Rust values β addresses, prefixes, routes, interfaces β never raw strings or shell commands.
- Native APIs, not subprocesses. Net Lattice talks directly to platform networking APIs (Netlink, IP Helper API, route sockets) rather than invoking external CLI tools.
- Cross-platform by design. A single API surface backed by platform-specific implementations, so applications do not need to special-case operating systems.
- Correctness and safety first. Networking configuration is sensitive; the library should make incorrect states difficult to represent.
- Incremental, well-considered growth. Features are added deliberately, with attention to API design and long-term maintainability, rather than rushed to cover every possible use case.
Implemented:
- IPv4/IPv6 address and prefix types
- Interface-address inspection and mutation
- Route inspection and mutation
- Interface inspection
- DNS resolver inspection
- Neighbor tables (ARP/NDP)
- Network monitoring and change notifications
- Optional runtime-agnostic async event stream
Planned:
- DNS mutation
- VLANs
- VRFs
- Network namespaces
- Firewall integration
- Transactional configuration
- Declarative networking
- Net Lattice is not a replacement for full network management daemons (e.g. NetworkManager, systemd-networkd).
- Net Lattice does not aim to provide a command-line interface or GUI as part of the core library.
- Net Lattice does not aim to parse or wrap the output of external CLI tools as a long-term strategy.
- Net Lattice does not aim to support every conceivable network protocol or vendor extension from day one.
Stage 0.12 of the architecture's Incremental Delivery Plan has landed:
net-lattice-core,net-lattice-ipnet-lattice-model'sroute,mac,interface,dns,neighbor,ifaddr, andeventmodules;NewInterfaceAddressexpresses address-assignment intent separately from an observedInterfaceAddressnet-lattice-platform'sRouteProvider,InterfaceProvider,DnsProvider,NeighborProvider,AddressProvider,AddressMutator,CapabilityProvider, synchronousEventProvider/boundedEventReceiver, and optional async monitoring supportnet-lattice-async, which exposes the single runtime-agnosticEventStreamtype- the
net-latticefacade, includingLattice::add_address(),Lattice::remove_address(),Lattice::capabilities(),Lattice::supports(),Lattice::watch(),Lattice::watch_filtered(), and feature-gatedLattice::watch_async()
This gives real route and interface-address management, interface listing, DNS resolver reads, neighbor (ARP/NDP) table reads, and bounded network-change monitoring on Linux, Windows, and macOS. Address creation accepts NewInterfaceAddress and returns the resulting observed InterfaceAddress, so callers never invent an address ID. EventFilter composes domain selectors (routes()) and object selectors (route(route_id)); every backend applies the filter before enqueueing an ordinary event. Query Lattice::supports(Capability::MONITORING) before watching in portable code; the facade returns Error::Unsupported before opening a watcher when monitoring is unavailable. Net Lattice's async feature uses and re-exports the EventStream implementation from net-lattice-async; applications need only enable that facade feature. Lattice::watch_async(filter) remains the Stage 0.11 async API and has the same filter semantics as Lattice::watch_filtered(filter). Tokio is used internally where the native implementation requires it, while applications interact only with the runtime-independent futures::Stream interface. Platform backends use Netlink on Linux, the IP Helper API on Windows, and BSD routing sockets, getifaddrs, and address ioctls on macOS. This is still not a complete library: DNS mutation, VLANs, VRFs, namespaces, firewall integration, transactional configuration, declarative networking, and other advanced capabilities are still ahead; see ARCHITECTURE.md's Incremental Delivery Plan for the staged roadmap and CHANGELOG.md for what has actually shipped.
| Capability | Linux | Windows | macOS |
|---|---|---|---|
| Route inspection | β | β | β |
| Route mutation | β | β | β |
| Interface inspection | β | β | β |
| Interface-address inspection | β | β | β |
| Interface-address mutation | β | β | β |
| Neighbor table inspection | β | β | β |
| DNS resolver inspection | β | β | β |
| Change monitoring | β | β | β |
| Async change monitoring | β | β | β |
Event streams are bounded. If a consumer falls behind, the watcher records and delivers Event::ResyncRequired { .. } before a subsequent ordinary event instead of retaining an unbounded backlog. Re-read the affected provider state before relying on subsequent events.
let route_events = EventFilter::none().route(route_id);
let watcher = lattice.watch_filtered(route_events)?;use net_lattice::{Lattice, Result};
fn main() -> Result<()> {
let lattice = Lattice::connect()?;
for interface in lattice.interfaces()? {
println!("{interface:?}");
}
for route in lattice.routes()? {
println!("{route:?}");
}
let watcher = lattice.watch()?;
loop {
let event = watcher.recv()?;
println!("{event:?}");
}
}Enable the optional async facade with net-lattice = { version = "0.12", features = ["async"] }. It returns the same futures::Stream on each supported platform:
use futures::StreamExt;
use net_lattice::{EventFilter, Lattice, Result};
async fn monitor() -> Result<()> {
let lattice = Lattice::connect()?;
let mut events = lattice.watch_async(EventFilter::ALL)?;
while let Some(event) = events.next().await {
println!("{:?}", event?);
}
Ok(())
}Address assignment uses a request type, so callers never construct an observed address ID:
use net_lattice::{
Error, Ipv4Address, Ipv4Network, Ipv4PrefixLength, Network, NewInterfaceAddress,
};
let interface = lattice
.interfaces()?
.into_iter()
.next()
.ok_or(Error::NotFound)?;
let request = NewInterfaceAddress::new(
interface.id,
Network::from(Ipv4Network::new(
Ipv4Address::new(192, 0, 2, 10),
Ipv4PrefixLength::new(24)?,
)),
);
let observed = lattice.add_address(request)?;- Bootstrap (completed) β repository infrastructure, licensing, community health files, and tooling configuration.
- Design (completed) β define the crate layout, core abstractions, and platform abstraction strategy. See ARCHITECTURE.md for the planned workspace structure.
- Foundations (completed) β core IP/route/interface types and all three platform backends shipped.
- Platform parity (completed) β Linux, Windows, and macOS route and address mutation, interface, DNS-read, neighbor-read, address-read, and monitoring backends shipped.
- Stage 0.9: Address mutation (completed) β cross-platform assignment and removal of interface IPv4/IPv6 addresses.
- Stage 0.10: Event semantics (completed) β bounded delivery, overflow and resynchronization signaling, filtering, cancellation, and error propagation.
- Stage 0.11: Async events (completed) β optional
asyncfacade feature, one runtime-agnosticEventStream, and native Tokio-backed delivery in every platform backend. - Stage 0.12: Watcher API stabilization (completed) β composable object/domain filters, filtering before queueing, monitoring-capability validation, and consistent filter semantics across synchronous and async watchers while preserving the released 0.11 API.
- Stage 0.13: DNS mutation β capability-gated resolver configuration through supported native system mechanisms.
- Stage 0.14: Transaction primitives β plans, application, failure reporting, and rollback boundaries for mutations.
- Stage 0.15: Declarative networking β
CurrentState,DesiredState,Diff, andApplyPlanbuilt on the stable mutation foundation. - Stage 0.16+: Capability domains β VLAN, VRF, namespaces, firewall, and tunnel support, gated by explicit runtime capabilities.
- 1.0 β stable cross-platform inspection, monitoring, and mutation foundation.
Contributions are welcome. See CONTRIBUTING.md for guidelines, CODE_OF_CONDUCT.md for community expectations, and SECURITY.md for reporting security issues.
Net Lattice is licensed under the Mozilla Public License 2.0 (MPL-2.0).