[arin-discuss] Trying to Understand IPV6

Ron Cleven Ron at Cleven.com
Tue Sep 14 12:22:56 EDT 2010


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?"

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.

Even more confused.  Perhaps I am the only one.


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.
>
>  
>

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


More information about the ARIN-discuss mailing list