North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: v6 subnet size for DSL & leased line customers
- From: Leigh Porter
- Date: Tue Dec 25 12:44:36 2007
Wow, is this what you folks do at Christmas ?
Joe Greco wrote:
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
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
This discussion is getting really silly; the fact of the matter is
thatTrue, but, they don't, generally, charge by the address, either.
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
exactlyPerhaps end-user ISP's don't charge by bandwidth usage...
charging your customers? ah, not by bandwidth usage, very logical!
Usually, they charge by the month. If you can't cover $0.03/year/
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.
I'm betting that competition will drive the boundary left without
As an enduser I would love to pay the little fee for IP space that
theSure, but that's mostly fantasyland. The average ISP is going to
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
some bucks and can do writeoffs on equipment and personnel.
monetize the variables. You want more bandwidth, you pay more. You
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
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
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
see it as likely to happen.
fees. After all, if you're only willing to dole out /64s and your
handing out /56 for the same price, then all the customers that want
subnets are going to go to your competitor. The ones that want /48s
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,
weAssuming that PD is available is naive. However, assuming it is not is
/want/ end-users to receive a /56, maybe even a /48, but as an
I'm going to assume something more pessimistic. If I'm a device
I can safely do that, because if I don't assume that a PD is going
available and plan accordingly, then my device is going to work in
cases, while the device someone who has relied on PD is going to break
when it isn't available.
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
if possible, or, should handle the case where it can't function in a
and informative manner.
That much is certain.