Php Ip Laravel Package

Product Decisions This Supports

• Feature scope and investment bets: Use this package as the substrate for any feature that reasons about network identity — IP allowlists/denylists, per-tenant CIDR policies, rate limiting and abuse detection, webhook source validation (payment, identity, messaging providers), VPN/office egress rules, audit-log enrichment, and "trusted proxy" handling for X-Forwarded-For. If a feature needs containment, overlap, or enumeration, this library replaces bespoke bitwise math with a tested API and lets you scope that feature in days rather than weeks.
• IPv6 readiness as a roadmap decision: The library gives IPv4 and IPv6 a unified API (IPv4, IPv6, IPv4Block, IPv6Block). That makes "do we support IPv6 in access rules / logging / customer config" a product choice rather than an engineering constraint — a materially cheaper decision to say yes to.
• Build vs. buy: Strong buy. The domain is narrow, deterministic, and fully specified by RFCs; there is no product differentiation to be gained from writing it in-house, and a hand-rolled implementation is a recurring source of off-by-one and integer-overflow defects in security-adjacent code.
• Build vs. adopt vs. vendor: Because the surface area is small and self-contained (no network I/O, no external services, no data stores), adoption cost is low and reversibility is high — a favorable profile for a dependency you can swap later without user-visible impact.
• Prioritization of "network hygiene" work: Makes cheap, credible roadmap items out of subnet overlap validation in tenant configuration UIs, safe handling of IPv4-mapped IPv6 and mixed-format input, and correct normalization of stored addresses — items that otherwise sit in the backlog forever because each is too small to justify its own project.

When to Consider This Package

Adopt when:

• You need real CIDR semantics: membership tests, block overlap detection, subnet splitting, iteration over a block, and address arithmetic (increment/decrement). PHP's native filter_var, ip2long, and inet_pton validate and convert but do not do this arithmetic.
• You need IPv4 and IPv6 parity from a single code path, especially for security-relevant rules where divergent v4/v6 logic is a classic source of bypasses.
• You are working inside an existing Laravel/PHP application and want a dependency-free, MIT-licensed, in-process library — no service calls, no extension beyond math support, trivially unit-testable.
• Your use cases are deterministic and offline: policy evaluation, configuration validation, log parsing, test fixtures. The library is pure computation, which is exactly the right shape for these.

Look elsewhere or plan a spike when:

• Maintenance cadence is a hard requirement. Last release was March 2022 and the project has modest adoption (~180 stars). Mitigating factors: this is a slow-moving RFC domain where a stable API is a feature, not a warning sign; and the code is small enough to fork or vendor. But if your organization requires an actively released dependency for every package, this will trip an approval gate.
• Runtime constraints. Verify extension requirements (GMP/BCMath for arbitrary-precision IPv6 arithmetic) against your production images, and confirm the supported PHP version range against your target runtime before committing — a 2022 release may not be tested against your current PHP minor.
• You need more than CIDR. IP ranges (start–end, non-CIDR), address storage/type abstraction, or geo/ASN enrichment are out of scope here. mlocati/ip-lib is the closest actively maintained comparator and covers ranges; a dedicated geo-IP database is a different purchase entirely.
• Your need is validation only. If all you do is confirm a string is an IP or a CIDR, filter_var plus a regex is sufficient and you should not take the dependency.

Recommendation: Run a short spike (a day, ideally against your actual allowlist/webhook/tenant-config paths) comparing this library with mlocati/ip-lib on PHP-version compatibility, extension requirements, and release cadence. Pick whichever passes your dependency policy; the API differences will not be the deciding factor.

How to Pitch It (Stakeholders)

For executives: We can add reliable network-based access control — allowlists, tenant subnet rules, trusted-proxy handling, webhook source verification — with a small, free, MIT-licensed library instead of custom code. The business case is risk reduction and speed: homegrown IP math is a known source of security defects (IPv6 bypasses, off-by-one subnet boundaries), and this package removes that class of bug from our surface area while making IPv6 support a config change rather than a project. Cost is near zero; integration is contained; the main governance question is that the last release was 2022, which for a stable, RFC-defined domain is low risk and is mitigated by a small codebase we could fork if needed. The high opportunity score reflects a real gap: PHP's built-in IP functions are validation-only, so teams either write this themselves or go without.

For engineering: Pure-PHP, in-process, no I/O, deterministic, and straightforward to unit test — a good fit for Laravel service classes and form requests. It gives you typed address and block objects with containment, overlap, splitting, and arithmetic, so policy code reads as intent rather than bit manipulation. Two things to confirm before we adopt: extension availability (GMP/BCMath) in our runtime images, and tested PHP-version coverage given the 2022 last release. If either is a problem, mlocati/ip-lib is the drop-in alternative with broader range support; I'd like a one-day spike comparing both against our actual webhook-validation and tenant-subnet paths, then a decision.