Ipv4 Subnet Calculator Laravel Package

Product Decisions This Supports

• Feature scoping for anything "network-shaped." Any PM surface that asks a user for an IP or CIDR — tenant/VPC provisioning, allowlists, firewall rule builders, DHCP scope setup, office/VPN onboarding, device enrollment — needs the same derivation: network address, broadcast, mask, usable host range, host count, CIDR notation, containment/overlap checks. This package answers those deterministically in-process, so you can scope these features as "small" instead of "needs a network engineer."
• Build vs. buy (and the answer is usually "consume"). The bit math is deceptively bug-prone at non-octet boundaries and at /31 and /32. Writing it yourself is a 2–5 day task plus a permanent tail of edge-case bugs; adopting an MIT-licensed, dependency-free calculator is hours of work and zero licensing friction. Default recommendation: consume, wrap, move on.
• Roadmap sequencing. Treat it as an enabler, not a headline. It unblocks "let customers self-serve their own network config" stories without a platform investment. It should never appear on a roadmap slide, but it frequently sits underneath three items that do.
• IPAM-lite vs. full IPAM decision. This package does calculation, not allocation. It's the right tool if you want to show users the consequences of a subnet choice, validate inputs, or size a pool. It is the wrong tool if you need to track which subnets are already assigned, prevent overlapping allocations across records, or reconcile against cloud provider state — that's a persistence and concurrency problem, and choosing this package as the foundation for it is a scope trap worth naming explicitly in the decision doc.
• Validation and error-prevention as a product surface. Most subnet-related support tickets are user input errors (wrong mask, host bits set, overlapping ranges). Inline calculation and validation at the point of entry converts support load into product quality — an easy win to prioritize against louder but lower-yield features.
• Pricing and packaging. Network-configuration conveniences are a natural gate for higher tiers in infra/devtool products (multi-tenant network planning, bulk CSV of subnets, overlap auditing). The package's cost profile (free, MIT, no runtime dependency) means the gate is safe to introduce without margin analysis.
• Data-model decisions. It legitimizes storing the canonical CIDR string and deriving everything else on read, rather than persisting seven denormalized columns that drift. Fewer columns, one source of truth, cheaper migrations.
• Explicit non-decision: IPv6. If v6 is on the roadmap within two years, flag now that this package is v4-only; the eventual answer is a second library or a thin internal service, and that shapes how much logic you allow to leak into your codebase today.

When to Consider This Package

Adopt when:

• You're on PHP/Laravel and the need is calculation and validation, not state management.
• You want zero infrastructure: no API call, no service, no database, no network egress — calculation happens synchronously in the request.
• Your inputs are IPv4 only, or v4 is the only case you actually ship this quarter.
• You want a small, auditable dependency (MIT, no transitive deps) rather than a networking framework or cloud SDK.
• You need results in microseconds inside a form request / validation rule / job, including bulk operations over thousands of rows.
• The output feeds a human (display, confirmation, warning) or generated config, not a reconciliation engine.

Look elsewhere when:

• IPv6 is required or imminent. Subnetting semantics, notation, and host-count conventions differ enough that v4 logic is not a stepping stone.
• You need stateful IPAM: allocation records, overlap prevention across tenants, reservations, release/reuse, audit trails. That's phpIPAM, NetBox, or your own table with real locking — this package can sit beside it for display, not under it for truth.
• You need BGP/ASN/RPKI, geo-IP, ASN lookup, DNS, or cloud VPC reconciliation — out of scope by design.
• Your stack is polyglot and multiple services must produce identical results. Then the right move is one internal calculation service (or a shared, versioned spec with tests in each language), not per-language libraries that can drift.
• You require vendor support, SLAs, or a guaranteed maintenance commitment. Stars and dependent count are modest and the maintainer set is small; treat it as source you are comfortable owning rather than a supplier relationship.
• Your security/compliance process treats new direct dependencies as expensive. The counter-argument is that the surface area here is tiny and the code is short enough to vendor and review line-by-line — but make that a deliberate, documented choice.

Adoption guardrails (worth writing into the ticket): pin the version in composer.lock, wrap it behind a small internal interface (e.g., SubnetCalculator contract) so swapping or forking is a one-file change, add your own characterization tests for the boundary cases you care about (/31, /32, /30, non-octet masks, host-bits-set input), and note the fork path in the ADR. This converts "single-maintainer risk" from a blocker into a footnote.

How to Pitch It (Stakeholders)

To executives (one paragraph): We have several customer-facing features that all need the same small piece of networking arithmetic — validating a customer's subnet, showing them the usable address range, sizing a DHCP pool, catching overlapping ranges before they cause an outage. We can either have engineering build and permanently maintain that math, or adopt a free, permissively licensed, dependency-free library that's already had the edge cases shaken out. The second option removes a recurring class of customer-facing errors, unblocks two or three roadmap items this quarter at roughly a day of integration work, and carries no licensing cost. The residual risk is maintainer concentration, which we mitigate by pinning the version and isolating it behind our own interface — a few hours of work that we'd do anyway.

To engineering (the practical case): MIT, no transitive dependencies, pure PHP, drops into a Laravel service or a Rule object without an adapter layer. Synchronous and allocation-light, so it's safe in request paths and batch jobs. We'll consume it through a thin contract so we're not coupled to the vendor's API, pin it, and add characterization tests around the boundaries we actually rely on (/31, /32, host-bits-set, non-octet masks). Realistic integration: half a day for the wrapper plus a day of feature work per surface. What we are explicitly not doing is using it as the basis for allocation state — if we later need to know which subnets are taken, that's a schema and concurrency problem and we'll scope it separately.

To the security/architecture reviewer: Read the source before approving — it's small enough to review in one sitting, which is the actual argument here. No network calls, no filesystem access, no native extensions, deterministic output for a given input. The dependency is a calculation, not a capability.