On Jan 3, 2008 3:52 AM, Rick Astley <jnanog@gmail.com> wrote:
* /32 for ISPs unless they can justify more * /48 for subscribers unless they can justify more
Take someone like Comcast with ~12 million subscribers.
It would take an IPv6 /24 to get 16.7 million /48's (2^24). With a net efficiency of 10% they are going to need to be allocated 120 million /48's. It would take a /21 to give them 2^(48-21) = ~134 million /48's.
And indeed Rick, British Telecom, France Telecom and Deutsche Telekom did exactly these calculations and used them to justify the /19's and /20s that they were allocated from RIPE. Fortunately, there are only a handful of Comcasts. The vast majority of ISPs have customer counts well shy of the million mark. If you have more than 65,000 customers today, you should have little trouble justifying an initial IPv6 allocation larger than /32. You simply state in your application that you intended to assign a /48 to each. Any such reallocation up to a /48 is deemed to be automatically justified at the registry level.
So in short, a /48 to subscribers seems like complete overkill, and a /32 to ISP's seems completely inadequate (80 vs 16 bits).
This is why some folks recommend a /56 for small subscribers instead of a /48, reducing the waste by two and a half orders of magnitude. In a world where only the largest subscribers choose to deploy more than 4 IPv4 subnets (including their NATed subnets) why should the initial IPv6 assignment exceed 256 subnets?
It seems to me while being extra super sure we meet goal 1 of making sure NAT is gone for ever (and ever) we fail goal 2 of not allocating a bunch of prefixes to ISP's that are too small.
In my ever so humble opinion, IPv6 will not reach significant penetration at the customer level until NAT has been thoroughly implemented. Corporate information security officers will insist. Here's the thing: a stateful non-NAT firewall is automatically less secure than a stateful translating firewall. Why? Because a mistake configuring a NAT firewall breaks the network causing everything to stop working while a mistake with a firewall that does no translation causes data to flow unfiltered. Humans being humans, mistakes will be made. The first failure mode is highly preferable. This is one of the trifecta that most seriously obstruct the deployment and acceptance of IPv6. The others are: client stack prefers IPv6 to IPv4 when available (so wonderful for Internet stability during the deployment years) and "incompatibility" meaning that instead of simply requiring a software upgrade after which the IPv6 addresses corresponding to your configured IPv4 addresses just work, IPv6 requires an entirely new set of allocations and an entirely new configuration management infrastructure. Double the work. Somewhat less than double the fun. But that's just my opinion. Regards, Bill Herrin -- William D. Herrin herrin@dirtside.com bill@herrin.us 3005 Crane Dr. Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004