[arin-discuss] Trying to Understand IPV6

[Owen DeLong]

On Sep 14, 2010, at 9:22 AM, Ron Cleven wrote:

> This was, of course, the point of my question.  It would seem that whoever came up with the crazy scheme of 64bit subnets never thought about how many ISP's and customers there are.in the world.  We could have accommodated all the ISP's in the universe each of whom could accommodate all the customers in the universe to ensure nobody would ever have to go back for more allocations.  Is there a link that would describe "what is the reasoning (if any) behind the math?"
> 
We still can. We just can't do it with /32s to very large ISPs. They'll need larger blocks.

In fact, reviewing the math, I think most ISPs will need /28s.

> More simply, it would seem to have been trivial to accommodate the idea of every ISP only ever needing one allocation, no matter what size they are.  There was plenty of bits, which now appear to have been squandered by committee.
> 
I disagree... There are still plenty of bits. There are actually good reasons for the /64 decision.

Consider this... There are probably about 30,000 ISPs worldwide. (~30,000 active ASNs in the global table, yes some are not ISPs, but, not all ISPs are in the table, either. I figure it's about the best approximation available).

At that rate, if we gave every one of them 10 /28s (2 from each RIR) we would only consume the first /12 in each region.

> Even more confused.  Perhaps I am the only one.
> 
There are several good reasons for the idea of a uniform subnet size.

Stateless Address Auto-Configuration is the primary reason to make 64 bits that size.

There are some pretty good benefits to SLAAC and I think it's a worthwhile use of those bits.

Owen

> 
> Owen DeLong wrote:
>> 
>> Tom,
>> 
>> If you know you have 115k customers, you should request more
>> than a /32 to begin with. Probably something approaching a 30
>> or a /29 under current policy. I am soon going to be drafting a  policy
>> proposal that supports the notion of rounding up to nibble boundaries
>> in order to provide better guidance to ISPs on right-sizing their requests
>> and also to provide better human factors engineering in the address
>> space overall.
>> 
>> Owen
>> 
>> On Sep 14, 2010, at 7:23 AM, Tom Bourgeois wrote:
>> 
>>   
>>> ________________________________
>>> 
>>> From: arin-discuss-bounces at arin.net
>>> [mailto:arin-discuss-bounces at arin.net] On Behalf Of Ron Cleven
>>> Sent: Tuesday, September 14, 2010 9:49 AM
>>> To: arin-discuss at arin.net
>>> Subject: Re: [arin-discuss] Trying to Understand IPV6
>>> 
>>> 
>>> I was with you right with you (assign /48 to every customer, no
>>> exceptions) up until you came up with the big-isp exception (assign /56
>>> to private residences).
>>> 
>>> Why would Comcast (using your example) customers get "only" a /56?
>>> 
>>> Is there something wrong with the math (are big-isp's going to run out
>>> of /48's)?
>>> 
>>> If it is ok for Comcast customers to get /56's, why isn't it ok for all
>>> other private residences to get /56's (what are the /56 customers giving
>>> up)?
>>> 
>>> As usual, I am horribly confused.
>>> 
>>> Ditto.  We currently have around 115k residential data subs in addition
>>> to a few thousand business customers.  Compared to the Comcasts, AT&Ts,
>>> and Time Warner's of the world we're definitely on the small side but if
>>> I give everyone a /48 then I guess I need to go back and get a couple
>>> more /32s soon.  I guess I don't see the huge problem with aggregation
>>> on our local plant.
>>> 
>>> michael.dillon at bt.com wrote:
>>> 
>>> 
>>> 
>>> 	
>>> 	It is very typical. /48 to every customer, no exceptions. If a
>>> customer
>>> 	wants less, assign them a /48 anyway and only tell them the
>>> first part
>>> 	of the prefix. When they get wiser, tell them the /48 that you 
>>> 	"reserved" for them. 
>>> 	
>>> 	The non-typical case is an ISP with very large numbers of
>>> residential
>>> 	customers (something like Comcast for instance) where it makes
>>> sense
>>> 	to assign /56 to private residences and /48 to everyone else.
>>> 	
>>> 	  
>>> 
>>> 
>>> _______________________________________________
>>> ARIN-Discuss
>>> You are receiving this message because you are subscribed to
>>> the ARIN Discussion Mailing List (ARIN-discuss at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-discuss
>>> Please contact info at arin.net if you experience any issues.
>>>     
>> 
>> _______________________________________________
>> ARIN-Discuss
>> You are receiving this message because you are subscribed to
>> the ARIN Discussion Mailing List (ARIN-discuss at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-discuss
>> Please contact info at arin.net if you experience any issues.
>> 
>>   
> 
> _______________________________________________
> ARIN-Discuss
> You are receiving this message because you are subscribed to
> the ARIN Discussion Mailing List (ARIN-discuss at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-discuss
> Please contact info at arin.net if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-discuss/attachments/20100914/b7371b7e/attachment.html>