I'm siding with MMC. While I understand the need for conserving limited resources (e.g. IPv4 address, crude oil, dolphins, etc), but IPv6 is not in that situation. We currently have enough addresses space to provide addresses for 4.3 billion ISPs (/32), who in turn can provide service for 16 million sites (/56) each. That's 1 ISP per 1.6 person on the planet. Secondly, IPv6 is by convention a wasteful protocol - /64 LANs, /56 sites, /48 large sites. Depending on what you assign to customer, a /36 can only provide services to 4000 x /48 customers. By assigning a /36 to ISPs, people will have to update their filters to accept /36s, and I guarantee you there will be people deaggregating their /32 to /36 to "load balance traffic" If this is a commercial problem, let's solve this commercially. When we hit 10% utilization on our IPv6 free pool, maybe we can bring this up again. From: Matthew Moyle-Croft <mmc at internode dot com dot au> Date: Thu, 4 Aug 2011 08:18:21 +0800 To: Owen DeLong <owen at delong dot com> Cc: "John Mann (ITS)" <john.mann at monash dot edu>, "<sig-policy at lists dot apnic dot net>" <sig-policy at lists dot apnic dot net> Subject: Re: [sig-policy] prop-098 Optimizing IPv6 allocation strategies (simplified) On 04/08/2011, at 2:58 AM, Owen DeLong wrote:
If the issue is a commercial one then I'd suggest that it's fixed as a commercial problem not a technical allocation issue. If you're designated as having a "special need" then you get a discount on your IPv6 space rather than creating arguments about
how the allocation will occur? The problem goes back to this whole thing that we're trying to create "classes" for IPv6 allocation where none really exist. At best we're trying to create more classes of allocatees (new word?) than really exist. This is because we're still allocating
IPv6 space using IPv4 concepts such as extreme scarcity vs need and impending exhaustion of the stock. MMC
|