Building an IPv6 Subnet Planner with AI Assistance

I’ve been a big fan of Caesar Kabalan’s IPv4 Visual Subnet Calculator for years. It’s one of those tools that does exactly what it needs to do: let you visually split and organize IPv4 address space for network planning and documentation. Simple, effective, no unnecessary complexity.

But as someone who has been absorbing IPv6 best practices from IPv6 Buzz on Packet Pushers, I wanted something similar for IPv6 planning. IPv6 subnet design has its own set of conventions—nibble-aligned boundaries, /48s for locations, /64s as the minimum assignable subnet—and I couldn’t find a tool that incorporated these principles in the same intuitive visual way.

The Failed Approach: Modifying the IPv4 Calculator

My first instinct was to clone the Visual Subnet Calculator repo and have various AI tools modify it to handle IPv6 instead of IPv4. This seemed like it should work. The UI paradigm was already proven, and theoretically the math just needed to change.

It didn’t work. After several attempts with different models, I never got very far. The fundamental issue, I believe, is that the structural differences between IPv4 and IPv6 lead to very different patterns needed to handle both protocols. IPv4’s binary subnetting with variable-length boundaries maps poorly to IPv6’s hex-based, nibble-aligned world. What makes sense for one doesn’t translate cleanly to the other. Trying to retrofit IPv6 into an IPv4-shaped codebase created more problems than it solved.

Starting Fresh with OpenCode

This morning I decided to abandon the modification approach and start from scratch using opencode.ai. The tool lets you work with different AI models depending on the task, which turned out to matter quite a bit.

I started with Claude Opus 4.5 for planning. The goal was to create a detailed implementation plan before writing any code—something I’ve found essential when working with AI on anything beyond trivial tasks. The plan needed to capture all the IPv6-specific requirements: accepting any prefix from /16 to /64 (including non-nibble-aligned RIR allocations like /21 or /47), always splitting to the next nibble boundary, displaying subnet counts in terms of /48s or /64s depending on context, and ensuring addresses display in proper RFC 5952 compressed notation.

With the plan documented, I moved to implementation. I tried GLM 4.6 and Claude Haiku 4.5 with limited success. The models could produce code, but the nuances of the IPv6 requirements—particularly the variable number of children when splitting non-nibble-aligned prefixes and the proper hex increment calculations—kept getting lost.

Switching to Claude Sonnet 4.5 changed things significantly. The model followed the implementation plan closely, handled the edge cases correctly, and produced a working single-file application that I could iterate on. The result is a tool that does what I needed: hierarchically divide IPv6 address space while respecting the conventions that make IPv6 planning practical.

The Result: IPv6 Subnet Planner

The tool is now live at v6plan.jasontally.com.

Key features that align with IPv6 best practices:

• Nibble-aligned splitting: Splits always occur at 4-bit boundaries, creating clean hexadecimal increments. A /20 splits into 16 /24s; a /21 splits into 8 /24s.

• Prefix flexibility: Accepts any prefix from /16 to /64, including the non-nibble-aligned allocations that ISPs often assign in the real world.

• Planning-focused counts: Shows /48 counts for larger allocations (since /48 is the typical site allocation) and /64 counts once you’re planning within a location.

• Visual hierarchy: Split and Join buttons span rows to make parent-child relationships clear.

• Annotations: Add notes and color-code subnets for documentation.

• Shareable URLs: Complete state encoded in the URL for sharing with colleagues.

• Quick load buttons: One-click loading of RFC 9637’s 3fff::/20 and RFC 3849’s 2001:db8::/32 documentation prefixes.

The whole thing is a single HTML file with embedded CSS and JavaScript. No build process, no dependencies, works offline once loaded. The source is available at github.com/jasontally/IPv6-Plan, including the implementation plan file that guided the AI-assisted development.

Lessons from the Process

The experience reinforced something I’ve observed before: AI assistance works best when you’ve already done the thinking about what you want to build. The detailed implementation plan—complete with tables showing expected split behavior, verification checklists, and common mistakes to avoid—was the difference between flailing and finishing. The AI models I tried were all capable of writing code, but only when given sufficiently precise requirements did the output match what I actually needed.

Starting from scratch also proved more effective than trying to adapt existing code in this case. Sometimes the path of least resistance isn’t.