<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Sep 14, 2010, at 9:22 AM, Ron Cleven wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<div bgcolor="#ffffff" text="#000000">
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?"<br>
<br></div></blockquote>We still can. We just can't do it with /32s to very large ISPs. They'll need larger blocks.</div><div><br></div><div>In fact, reviewing the math, I think most ISPs will need /28s.</div><div><br><blockquote type="cite"><div bgcolor="#ffffff" text="#000000">
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.<br>
<br></div></blockquote>I disagree... There are still plenty of bits. There are actually good reasons for the /64 decision.</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br><blockquote type="cite"><div bgcolor="#ffffff" text="#000000">
Even more confused. Perhaps I am the only one.<br>
<br></div></blockquote>There are several good reasons for the idea of a uniform subnet size.</div><div><br></div><div>Stateless Address Auto-Configuration is the primary reason to make 64 bits that size.</div><div><br></div><div>There are some pretty good benefits to SLAAC and I think it's a worthwhile use of those bits.</div><div><br></div><div>Owen</div><div><br></div><div><blockquote type="cite"><div bgcolor="#ffffff" text="#000000">
<br>
Owen DeLong wrote:
<blockquote cite="midB0AA001F-922E-4B75-ACD4-A75597D12B41@delong.com" type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">________________________________
From: <a class="moz-txt-link-abbreviated" href="mailto:arin-discuss-bounces@arin.net">arin-discuss-bounces@arin.net</a>
[<a class="moz-txt-link-freetext" href="mailto:arin-discuss-bounces@arin.net">mailto:arin-discuss-bounces@arin.net</a>] On Behalf Of Ron Cleven
Sent: Tuesday, September 14, 2010 9:49 AM
To: <a class="moz-txt-link-abbreviated" href="mailto:arin-discuss@arin.net">arin-discuss@arin.net</a>
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.
<a class="moz-txt-link-abbreviated" href="mailto:michael.dillon@bt.com">michael.dillon@bt.com</a> 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 (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-discuss@arin.net">ARIN-discuss@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a class="moz-txt-link-freetext" href="http://lists.arin.net/mailman/listinfo/arin-discuss">http://lists.arin.net/mailman/listinfo/arin-discuss</a>
Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.
</pre>
</blockquote>
<pre wrap=""><!---->
_______________________________________________
ARIN-Discuss
You are receiving this message because you are subscribed to
the ARIN Discussion Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-discuss@arin.net">ARIN-discuss@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a class="moz-txt-link-freetext" href="http://lists.arin.net/mailman/listinfo/arin-discuss">http://lists.arin.net/mailman/listinfo/arin-discuss</a>
Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.
</pre>
</blockquote>
<br>
</div>
_______________________________________________<br>ARIN-Discuss<br>You are receiving this message because you are subscribed to<br>the ARIN Discussion Mailing List (<a href="mailto:ARIN-discuss@arin.net">ARIN-discuss@arin.net</a>).<br>Unsubscribe or manage your mailing list subscription at:<br><a href="http://lists.arin.net/mailman/listinfo/arin-discuss">http://lists.arin.net/mailman/listinfo/arin-discuss</a><br>Please contact info@arin.net if you experience any issues.</blockquote></div><br></body></html>