Re: [sig-policy] prop-103-v001: A Final IP Address Policy Proposal
On Jul 9, 2012, at 2:52 PM, Owen DeLong wrote:
>
> On Jul 9, 2012, at 2:16 PM, Jay Daley wrote:
>
>>
>> On 9/07/2012, at 10:39 PM, Owen DeLong wrote:
>>> The problem with this being that a /32 is actually inadequate for all but the most simple and smaller ISP networks unless you victimize your users with smaller than /48 allocations.
>>
>> It stuns me every time I hear someone state that a /32, which is the equivalent of the *entire* IPv4 pace, is inadequate. Perhaps one day, in the same future where we all have flying cars, there will be so many devices in a house that we need more than a /56 but basing allocation on that aspiration makes me shudder. And as for describing it as 'victimisation', well I don't know where to start.
>
> IPv6 requires thinking quite a bit differently. In IPv4 we weren't giving a /16 to every end-site. In IPv6, we are.
I should clarify this... Fingers got ahead of brain...
In IPv4, we didn't give 65,536 unique addresses (let alone 65,536 unique subnets) to every end-site.
In IPv4, we should be giving 65,536 /64 network numbers to each end-site. (/48)
At that rate, any ISP that has more than 65,536 end-sites served (which is pretty small in many parts of the world these days), a /32 is facially inadequate.
When you allow for topological hierarchies and look at the desirability of being able to aggregate those hierarchies on nibble aligned boundaries for improved human factors, DNS, and other considerations, it becomes rapidly clear that all but the most trivial of ISP networks probably need at least a /28. There are way way way more than enough /28s to accommodate this and still have many many many prefixes sitting on the shelf by the end of IPv6's useful life.
>
> It's not about number of devices at the end. It's about number of subnets and about having enough bits to plan for automating hierarchical topologies at the end-site.
>
> It's about having better capabilities than we had in IPv4, not merely expanding the IPv4 paradigm and its foibles and limitations into a wider bitfield.
>
> If you inflict a limitation on your subscribers that prevents them from taking advantage of innovations and improvements in technology in the future, or, worse, prevents those innovations from taking place, then I'm not sure what better term to apply than victimization.
>
> Owen
>
> * sig-policy: APNIC SIG on resource management policy *
> _______________________________________________
> sig-policy mailing list
> sig-policy at lists dot apnic dot net
> http://mailman.apnic.net/mailman/listinfo/sig-policy