Edit, 2011-05-03: To all those poor souls who have been directed here by Google in their search for best practices on IPv4 and/or IPv6 subnet allocations (or worse, the HP A5500's NAT capabilities), please accept my sincere apologies. This page is more about asking questions than providing answers.
This is my third go at writing this post. I started in the middle of the night, because I woke up with IPv4 allocations and VLAN assignments running around in my head and couldn't get back sleep. After writing what seemed to me a reasonably coherent post, I accidentally hit the back button instead of the left arrow (surely they could have found somewhere better to put that on the ThinkPad keyboard). Dismal failure 1 for the day. After that I just threw a few notes in here as a draft and went back to bed.
I'm in the middle of a major network redesign for a client, a medium-sized K-12 private school. We have about 70 switches, and a little over 2000 ports. It's nowhere near the scale of a university, enterprise data centre, or service provider network, but it requires significantly more design, planning, and implementation effort than your average small network.
The campus houses a few loosely-coupled related entities over about 25 or so buildings, all connected by Gigabit fibre. A few years ago when we upgraded the phone system and switched to VoIP, I made an allocation plan for subnets using the 10.0.0.0/8 IPv4 space. We have quite a few VLANs, using /16 and /24 subnet sizes.
The network upgrade I'm working on has a number of goals: getting all client systems off the server VLAN (which has been progressing slowly over the last 18-24 months), providing redundant routing using a new pair of HP A5500 switches using IRF (HP/3Com's equivalent to Cisco stacking), and moving routing between VLANs from an old cluster of Linux servers to the new switches.
At the same time, I'm planning a move from switch-based VLANs to building-based VLANs, and I thought to myself: since we're going to need IPv6 on the outside network soon, I'd better make sure my new plan allows for IPv6 on the inside. I want to keep the IPv6 structure pretty much identical to IPv4, since our subnet plan mirrors the physical structure of the network.
Selecting the subnet size on IPv6 is easy, since it's pretty much fixed to /64 (insert appropriate mind-boggling about why we would want burn half of our addressing bits on the local subnet here), but there's another complication: because there's no NAT (yet), my IPv6 subnet plan must fit within our external address range. This is a big difference for many (most?) organisations using IPv4 only: at the moment, we have complete logical decoupling of our internal and external address ranges; under IPv6 we must tie the two together.
This is my big concern with the lack of NAT in IPv6: it places constraints on internal network design that do not exist in the IPv4+NAT world. I don't dispute the wisdom of the designers in leaving out NAT - it is unquestionably a complicating hack. But in my limited understanding of IPv6, I'm not aware of an equivalent to the useful part of IPv4 NAT (the internal/external address decoupling). When we implement IPv6, I'm guessing that I'll implement one-to-one address translation at our network edge to achieve equivalent functionality.
So what happens with our external address space? I'm not fully clear on APNIC's IPv6 allocation rules, but as far as I can tell, an existing holder of an IPv4 /23 can expect a maximum IPv6 allocation of a /48. This means that we would have 16 bits of subnets, which is exactly the same number of /24s we have available in the 10.0.0.0/8 address space. My first reaction to this was, "Sweet - I'll use the exact same subnet numbers in hexadecimal, and I'll have my IPv6 subnet plan." But I wonder whether that's all there is to it. And having exactly the same number of subnets at our disposal doesn't seem like much of a leap forward in terms of protocol functionality...
What are other people's thoughts? Are the issues for IPv6 subnet allocation different from IPv4? Is there a best practice for this sort of thing?