On 26/01/2010, at 8:50 AM, Tim Durack wrote: > This is what we have planned: > > 2620:0000:xx00::/41 AS-NETx-2620-0-xx00 > > 2620:0000:xx00::/44 Infrastructure > > > 2620:0000:xx01::/48 Pop1 Infrastructure > > > 2620:0000:xx01:0000::/64 Router Loopback > (2^64 x /128) > 2620:0000:xx01:0001::/64 Transit net > (2^48 x /112) > > 2620:0000:xx01:0002::/64 Server Switch > management > 2620:0000:xx01:0003::/64 Access Switch > management > > 2620:0000:xx0f::/48 Pop16 Infrastructure
Why do you force POP infrastructure to be a /48? That allows you only 16 POPs which is pretty restrictive IMO. Why not simply take say 4 /48s and sparsely allocate /56s to each POP and then grow the /56s if you require more networks at each POP. You only have a need for 4 /64s at each POP right now, so the 256 that a /56 gives you sounds like more than enough, and up to 1024 POPs (assuming you don't outgrow any of the /56s). Also I'd strongly recommend not stuffing decimal numbers in to a hexadecimal field. It might seem like a good idea right now to make the learning curve easier, but it's going to make stuff annoying long term. You don't have anything in IPv4 that's big enough to indicate the VLAN number and you've lived just fine for years, so forcing it to be decimal like that isn't really needed. You're much better off giving your staff the tools to translate between the two, rather than burn networks in order to fudge some kind of human readability out of it and sacrificing your address space to get it. % printf "%04x\n" 4095 0fff % printf "%d\n" 0x0fff 4095 -- Nathan Ward
