v6 subnet size for DSL & leased line customers

Tue Dec 25 17:01:03 UTC 2007

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

Okay, here's a problem.  You keep making these statements which bear no
resemblance to the real world.

If I "need more than 256 subnets", and I approach my ISP to ask for such,
there are at least two obvious answers which are incredibly more likely
than any risk of "assign[ing] them[me] multiple noncontiguous prefixes."

Answer 1: "We don't provide more space on your Cableco Cable Modem
Service.  If you would like, we do offer Cableco Business Class Service."

Answer 2: "We can assign you a larger prefix, however, you'll need to
power cycle the cable modem and your addresses will change."

Remember, this is residential broadband.  Saying /no/ is fairly common
(in the same way that I can't get custom PTR DNS for a static IP address
on a resi connection with many service providers.)

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

Yeah, well, I'm not impressed.  As an operator community, we've been so
good about getting our own affairs in order there.

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

How about /not/ upgrading all of your routers and keeping the "$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.

Customers at the low end of the spectrum do in fact care, and my guess
would be that they'd rather save the nickel than get extra address space
that only 1 in 1,000 of them might ever get around to using.

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

Ah!  That's good.  Now we're making some progress.

The first question most businesses have when they're spending money is
"how much is it."  Not "how much is it on a per-customer basis."  If I
go and ask for a new $2000 server so that I can put up some neat new
thing, such as a reverse-traceroute webserver, the idea is that I should
need to justify why it can't be done on an existing webserver.  Maybe it
can, but maybe it can't (let's say because it'll connect out to our
routers and the security risk warrants a separate server).  The fact
that it might only cost a penny per month per customer is irrelevant to
the higher-level analysis.

In the same way, if an ISP can avoid spending money, there are almost
certainly some who will do so.  Since the average customer is likely to
be more than adequately served by 256 subnets for the foreseeable future,
there will undoubtedly be some that allocate /56's (or even /64's).
Market pressures, the actual needs of consumers, and whether or not it
actually winds up as cheaper to support a single address space size on
backroom systems will all work to shape what actually happens.

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

No, it's not equally naive.  The bridging scenario is likely to work in
all cases, therefore, assuming bridging as a least common denominator is
actually pretty "smart" - even though I would prefer to see a full
implementation that works in all cases.  Assume the worst, hope for the
best.  If that's "naive", well, then it's all a lost cause.  You can call
it "coldly cynical" all you'd like, though.  ;-)

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

That much is certain.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.