<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body 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>
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>
Even more confused.  Perhaps I am the only one.<br>
<br>
<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>
</body>
</html>