Addressing plan exercise for our IPv6 course

Thu Jul 29 17:41:40 UTC 2010

On 29 Jul 2010 12:19, Owen DeLong wrote:
> On Jul 29, 2010, at 8:00 AM, Matthew Walster wrote:
>   
>> On 29 July 2010 15:49, Owen DeLong <owen at delong.com> wrote:
>>     
>>> If we give every household on the planet a /48 (approximately 3 billion /48s), we consume less than 1/8192 of 2000::/3.
>>>       
>> There are 65,536 /48s in a /32. It's not about how available 2000::/3
>> is, it's hassle to keep requesting additional PA space. Some ISPs
>> literally have millions of customers.
>>     
> If you have millions of customers, why get a /32? Why not take that fact and ask for the right amount of space?  1,000,000 customers should easily qualify you for a /24 or thereabouts. If you have 8,000,000 customers, you should probably be asking for a /20 or thereabouts.
>   

... and paying sixteen times as much in assignment and maintenance
fees.  See the problem there?

> It's not rocket science to ask for enough address space, and, if you have the number of customers to justify it based on a /48 per customer, the RIRs will happily allocate it to you.
>   

Yes.  However, I don't think the RIRs are as willing to give out address
space for _potential_ customers, e.g. if a telco or cableco wanted to
assign a single block to each CO/head end to account for future growth. 
OTOH, you can get address space based on a /48 per actual customer, then
actually assign a /64 per potential customer and have enough for massive
growth.

> Why waste valuable people's time to conserve nearly valueless
> renewable resources?
>   

By creating artificial scarcity, one can increase profits per unit of
nearly-valueless, renewable resources.  See also: De Beers and the
demonizing of artificial diamonds.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3646 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20100729/a483b95b/attachment.bin>