"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