v6 subnet size for DSL & leased line customers

Mon Dec 24 15:24:52 UTC 2007

> "Well, you say we need to spend more money every year on address  
> space.
> Right now we're paying $2,250/year for our /32, and we're able to  
> serve
> 65 thousand customers.  You want us to start paying $4,500/year, but  
> Bob
> tells me that we're wasting a lot of our current space, and if we were
> to begin allocating less space to customers [aside: /56 vs /48],  
> that we
> could actually serve sixteen million users for the same cash.  Is  
> there
> a compelling reason that we didn't do that from the outset?"
>
Right... Let's look at this in detail:

/48 per customer == 65,536 customers at $2,250 == $0.03433/customer
/56 per customer == 16,777,216 customers at $2,250 == $0.00013/customer

So, total savings per customer is $0.0342/customer _IF_ you have
16,777,216 customers.  On the other hand, sir, for those customers
who need more than 256 subnets, we're running the risk of having
to assign them multiple noncontiguous prefixes.  Although the cost
of doing so is not readily apparent, each router has a limit to the  
number
of prefixes that can be contained in the routing table.  The cost of
upgrading all of our routers later probably far exceeds the $0.03
per customer that we would save.  Really, in general, I think that
the place to look for per-customer savings opportunities would
be in places where we have a potential recovery greater than
$0.03 per customer.

> This discussion is getting really silly; the fact of the matter is  
> that
> this /is/ going to happen.  To pretend that it isn't is simply naive.
>
>> How high are your transit&equipment bills again, and how are you  
>> exactly
>> charging your customers? ah, not by bandwidth usage, very logical!
>
> Perhaps end-user ISP's don't charge by bandwidth usage...
>
True, but, they don't, generally, charge by the address, either.
Usually, they charge by the month.  If you can't cover $0.03/year/ 
customer
for address space in your monthly fees, then, raise your monthly
fee by $0.05.  I'm betting your customers won't care.

>> As an enduser I would love to pay the little fee for IP space that  
>> the
>> LIR (ISP in ARIN land) pays to the RIR and then simply pay for the
>> bandwidth that I am using + a little margin so that they ISP also  
>> earns
>> some bucks and can do writeoffs on equipment and personnel.
>
> Sure, but that's mostly fantasyland.  The average ISP is going to  
> want to
> monetize the variables.  You want more bandwidth, you pay more.  You  
> want
> more IP's, you pay more.  This is one of the reasons some of us are
> concerned about how IPv6 will /actually/ be deployed ...  quite  
> frankly,
> I would bet that it's a whole lot more likely that an end-user gets
> assigned a /64 than a /48 as the basic class of service, and charge  
> for
> additional bits.  If we are lucky, we might be able to s/64/56/.
>
> I mean, yeah, it'd be great if we could mandate /48 ...  but I just  
> can't
> see it as likely to happen.
>
I'm betting that competition will drive the boundary left without  
additional
fees.  After all, if you're only willing to dole out /64s and your  
competitor is
handing out /56 for the same price, then all the customers that want  
multiple
subnets are going to go to your competitor.  The ones that want /48s  
will
find a competitor that offers that.

That's how the real world works.  I remember having to repeatedly  
involve
senior management in rejecting requests for /24s from customers who
could not justify them because our sales people at Exodus kept promising
them.  The sales people continuously suggested that our competitors
were offering everyone /24s and that they had to do that to win the  
deals.

OTOH, "Raw bandwidth communications" seems to want to charge bandwidth
utilization not actually based on the bandwidth utilized, but, the  
number of
IP addresses routed.  They are not my ISP for that reason.

Different providers have different business models.  Consumers will
find the provider with the business model that best fits their needs.
That's the way it works in the real world.
>
> So, the point is, as engineers, let's not be completely naive.  Yes,  
> we
> /want/ end-users to receive a /56, maybe even a /48, but as an  
> engineer,
> I'm going to assume something more pessimistic.  If I'm a device  
> designer,
> I can safely do that, because if I don't assume that a PD is going  
> to be
> available and plan accordingly, then my device is going to work in  
> both
> cases, while the device someone who has relied on PD is going to break
> when it isn't available.
>
Assuming that PD is available is naive.  However, assuming it is not is
equally naive.  The device must be able to function in both  
circumstances
if possible, or, should handle the case where it can't function in a  
graceful
and informative manner.

Owen