Consider carefully: to really deploy IPv6, we'll need to change most of our networking software (clients and servers) to handle v6 addresses. This would be hard enough if the v6 migration was a one-liner. But it isn't. Beyond the fact that you have to handle both sockaddr_in and sockaddr_in6, note that v4 addresses are scalar values for C programs. C does not have a scalar 128 bit type.
Our v6 future is NAT'd to the horizon. If that's the case, what's the major win for v6 to this generation?
The notion that we're imminently going to run out of v4 addresses is at least somewhat artificial, since we run fiat allocation schemes right now and could migrate to a market-based allocation to replace it. There are companies addressing desktop machines with routable /16 components because they don't believe in NAT; there are companies grandfathered in to /8(!) allocations. A lot of this waste might stop if people had to pay for it.
A market is an excellent way to manage scarcity. However, ipv6 is preferable to well managed scarcity because it effectively eliminates the scarcity. Addresses under ipv6 are practically unlimited.
A typical ipv6 allocation for an end user is a /48. This allocation consists of 65,536 subnets, each of which has 18,446,744,073,709,551,616 individual addresses. This is just for the end user! Your grandma's cellphone will have 18,446,744,073,709,551,616*65,536 address available to it. No one will ever have to worry about running out again.
The market is a great way to allocate wheat, but imagine if we could make a machine that generated unlimited wheat. Why not use it?
Look at the population of Asia and look at the current ip allocations for that region. It's insanely small! Think about the next 30 years. All of those people are going to want internet access. Demand for ips is only going to grow and the difficulty associated with any sort of fundamental change is only going to grow.
IPv6 isn't perfect but it's needed and needed soon.
So, I agree with you about all of this, but it's simply orthogonal to the discussion. We are not charting a course in a vacuum, based on pure competing principles.
People have been arguing for the urgency of migrating to IPv6 for over a decade now. Not in the abstract. A decade ago was 2000, and in 2000, people were also seriously concerned about IP address depletion, and certain that we needed to imminently migrate to IPv6.
So the first thing you want to address in this argument is whether or not the Internet --- or, more precisely, the value propositions and service model of the current Internet --- is going to collapse if we don't migrate. And, no, it turns out, it's not going to collapse. It will surely be more expensive for a Fortune 100 company to hold on to a vanity /8, but most of us aren't going to notice any change in a market-driven allocation world.
To me, it follows from this that if we're going to have a usable IPv4 Internet for the foreseeable future, we have a choice:
* We can pursue IPv6 with all vigor and alacrity, forklifting out every piece of software that treats an IPv4 address as a number instead of an opaque bundle of an arbitrary number of bits, or
* We can reconsider whether a constituency in a persistent entry in the global BGP4 routing table is what it means to be a "first class citizen" of the Internet, and instead build a new city on top of the ruins of the old one, relegating IPv4 addresses (over time) to the same trash heap as MAC addresses. This isn't a pie-in-the-sky idea; CDNs and cloud providers are an immediate half-step in that direction, and overlay networks are a reasonable architectural goal for the next 5 years.
In our overlay future, we get more than just expandable addressing; we get multicast service models (which IPv6 isn't going to provide), we get true multihoming (which IPv6 isn't going to provide), we get first-class peer-to-peer routing (which IPv6 isn't going to provide), and we get ISP portability without any intervention or agreement by a nationwide telco or MSP.
Your grandma's cellphone will have 18,446,744,073,709,551,61665,536 address available to it.*
Good to know they're not being wastefully allocated this time around.
"Man said, "Carefully husbanded, as directed by the Cosmic AC, the IPv6 addresses that are even yet left in all the Universe will last for billions of years."
"But even so," said Man, "eventually it will all come to an end. However it may be husbanded, however stretched out, IP addresses once allocated are gone and cannot be restored. Entropy must increase to the maximum."
Man said, "Can wasteful IP allocation not be reversed? Let us ask the Cosmic AC.
I wasn't suggesting they would be used, I was suggesting they would be wasted.
Unless you want to run your new company as a process on my grandma's cellphone, that she can have more IP addresses on it than I can make a witty comparatory analogy about, is merely stupid and wasteful allocation.
The IPv6 address space may be so big we could never use it all, it's not so big we could never wastefully allocate it all.
You're not understanding the scales involved. You're complaining that the smallest package of salt at the store is a .5 kilo when all you need is a dash. That's crazy. There are oceans full of salt. Humanity will never want for salt.
Hate to break the analogy, but, actually: not true. There's a simple numeric scaling bottleneck with IPv6 already: routing table size. There will, for the foreseeable future, be scarcity in portable routable addresses.
What you are proposing is likely to trigger (or at least prolong) a dark age of the internet. And I'm not exaggerating the slightest.
If people have to pay for IP addresses, then the internet will be divided in two: those who can pay, and those who can't run a server. And I predict that the crushing majority of people who use the internet will be of the second category. This would obviously be a catastrophe for freedom of speech and even privacy.
The major win for v6 is enormous: an IP for everyone, and the possibility for a server at every home, which will at last give us the decentralized internet we should have had in the first place.
If it costs $5/yr for a single IP address, I'm not too concerned about the cost.
Meanwhile, most of the applications YC-types build don't necessarily need routable IP addresses. In a better world, most of our content would be delivered via overlay networks that abstract away that detail anyways. In the immediacy, what matters is the DNS.
We are in a dark age of the Internet, and it's our own doing. We've tethered ourselves to an archaic protocol that already indentures us to massive telco and cable operators, and would even if we had portable /32's assigned directly and personally from ARIN.
I don't see why we should be focusing all our engineering efforts on this one technological detail, tethering us forever to the idea that a license to speak on the Internet entails an IP address. There's 15+ years of research behind better networking topologies that care no more about IP addresses than a home router cares about Ethernet MAC addresses. Let's go that direction. It's easier, and probably better.
> I don't see why we should be focusing all our engineering efforts on this one technological detail, tethering us forever to the idea that a license to speak on the Internet entails an IP address. There's 15+ years of research behind better networking topologies that care no more about IP addresses than a home router cares about Ethernet MAC addresses. Let's go that direction. It's easier, and probably better.
can you please elaborate on the above a bit ? bunch of pointers to papers would be most appreciated. thanks !
Check out "A Layered Naming Architecture for the Internet". This is the paper we focused on in an Advanced Networking class when we talked about naming. It aggregates several key principles from the literature into one system. I haven't read the RON paper Thomas linked to, but based on a quick glance, I'd say both papers are definitely worth your time. The Naming paper is actually written by several of the same people who wrote or collaborated on RON.
Feel free to drop me an email if you want to discuss the Naming paper.
Virtually any number between $1 and $100/yr seems reasonable to me. Consider: for the rare (and hopefully rarer and rarer) cases where you need a "native" IP address, 1 will almost always do. Meanwhile, all these prices are feasible (in a first-world kind of way) for individuals, but untenable for wasteful use by company IT departments.
$6.5MM/yr may not sound like a dealbreaker for a F-500's /16, but that's actually quite a lot of headcount.
Unfortunately $25k is quite a lot for a /24, and you need a /24 if you want to have a network with independent BGP routing (because this is the smallest block in most BGP routers)
I manage the networks for a small company and we only need a few public IPs, but because we want the reliability we have a dual-homed connection via two ISPs, and our own /24.
Most small companies are not in a position to get a BGP-advertised default-free connection to multiple ISPs for an allocation as small as a /24. Can it be done? I'm sure, but only after a sizeable investment of time and effort.
My point being, it's not as if this is a capability IPv4 currently provides that is imminently going to be snuffed out by address exhaustion. The ship sailed on free/easy multihoming when Sprint started filtering anything smaller than a /19, back in '97.
You obviously have more experience with this than me, but in the UK we had no trouble getting BGP advertising with two ISPs for incoming connections (though we're not default-free, just using HSRP between ISPs for outbound).
There are plenty of people who have done this more recently than 1998, which is the last time I had to register an ARIN allocation. That was for a fairly large regional ISP in Chicago, for the sole purposes of multihoming, and it was a nightmare; I ended up having to call in a favor from a friend close to ARIN.
Surely someone who runs a multihomed hosted app (maybe a YC company) can chime in on how easy it is for a startup to get a BGP advertisement in 2010.
Most IP allocations to organisations these days are not PI (provider-independent) blocks from RIRs; they are simply aggregated from an upstream ISP's larger announcement. That doesn't mean you can't punch holes in their aggregate by announcing that same block (if it's a /24 or larger) through ISP #2, but it does not result in any new numbering allocations from ARIN, net.
It's pretty rare to get a PI block these days unless you're pretty dang large, and taking aim for at least a /20.
Well, you have to have your own ASN to announce it, yes. :) And certainly, you have to get the other ISP to allow this announcement from you through their filters, but that's a normal part of establishing BGP routing with another provider.
But the point is that if Level3 announces 4.0.0.0/8, yes, you can announce 4.16.73.0/24 through them, and through Global Crossing as well. Level3 does have to forward your announcement to its peers de-aggregated, though; that is, if they just fold it into their 4.0.0.0/10 announcement, incoming traffic will prefer your /24 announcement through GX because the prefix is longer/more specific, and plus that gives Level3 no way to withdraw the announcement if the link goes down. Not everybody will happily let you punch holes in their nice, clean aggregate like that, potentially hosing their AS as a whole with flap dampening penalties and such if the link is flaky. However, it is normal order of business with Tier 1s.
But yes, if you have an ASN, you can announce a /24 or bigger directly. You can't do anything smaller, though I have the sneaking suspicion that may change. There are some cranky network operators out there who have not upgraded to equipment with the horsepower and RAM (most importantly RAM) to hold a full BGP view consisting of prefixes down to the /24 granularity, and will indeed filter higher, but they're techically misrouting -- their problem. In any case, that's not the norm, no.
If everybody filtered prefixes smaller than /19 or /20, then multihoming would be the province of a relatively small plutocracy of institutions. I haven't run the numbers any time remotely recently, but most announcements, by volume, are of prefixes smaller than /19 for sure.
If I'm reading "Prefix Length Distributions" right, 52% of all announcements are /24s, and average prefix length is 22.33.
Now, technically, what's being announced != what's being filtered by influential backbones. But it has to be pretty dang close, or ~52% of all announced networks would not be routable from Sprint. :-)
I agree that the internet would be better off if it was more decoupled from monolithic backbones. Even more, the commercialization arguments underway sound a lot like arguments to deregulate housing loans in 1995...I do not think that IP addresses should be controlled by cable and datacenter companies, who have every interest to inflate the prices. And that is what market regulation without any standards or rational planning will result in.
An IP address is a human right on the same order as education and cultural freedom. But I bet that even with v4 people could figure out creative ways to get servers running for a lot more people. Let's not be sensationalist.
Why is first-class access to the Internet a human right? Isn't "ability to communicate freely" the right, and the Internet just an implementation detail?
Well, it's the implementation detail. Right now, without a first class internet connection, you can't completely exercise your ability to communicate (and publish) freely. Likewise, I think that right now, without a public IP, you don't have a first class internet connection.
So, by the contraposition, the transitivity of the implication, and my mathematical powers, having a public IP should be treated as the fundamental right it enables.
Of course, if there are several efficient "implementation details" which enable the layer above, then you just need one of those.
Your public IP address is also not a first-class Internet connection. You think it is[1], because you have a crappy Internet connection. But if you were an established company trying to use the address for real connectivity, you'd quickly realize that your IP address is nothing more than a stamp your ISP is putting on a connection it's lending you. You cannot, for instance, advertise your /32 on two different networks through BGP. Other people can, because they have better, more meaningful addresses.
So this notion that we all have a fundamental right to full and fair access to the Internet is already subverted by the fact that we're all default-routed second class citizens of the Internet.
In an overlay network world --- a world that is easier for us to travel to than an all-IPv6 world --- this wouldn't be a problem. Addresses would be inherently portable, multihomed access (both through ISPs and through our friends and neighbors) would be the norm, the notion of "server" addresses and "home" addresses (where you can't take port 25 connections) would be extinct.
Unfortunately --- but very importantly --- this is not equally true of an all-IPv6 world. There is nothing magical that IPv6 does to give us all access to the BGP RIB's of top-tier providers. You're still going to be some ISP's b+tch whether your IP address is 32 bits long or 128 bits wrong.
I'm not arguing that people don't have this fundamental right you want them to[2]. I'm saying that the IP address doesn't actually give it to them. Static IP addresses are just something for geeks to argue about while the telcos continue locking down the Internet.
[1] I'm being presumptive because it simplifies the point I'm making; sorry.
[2] All though I don't think they in fact have that right; things that compromise the "right to IP addresses" are invariably first-world kinds of problems.
Well, being your own ISP[1] is indeed important. To bad it's (1) such a hassle, and (2) the big players don't want to peer with the small ones any more. (In France, the http://fdn.fr non-profit is taking steps towards solving (1))
Overlay networks sound fantastic. Maybe Eben Moglen's FreedomBox (or something similar) could make it a reality?
[1]: For instance by being a member of a non-profit which itself is the actual ISP.
Sure, if that's what you think. I don't have a problem with that. What I don't understand is why a personal 32-bit (or 128-bit) identifier is a human right. If it is, most of you, including the ones with static addresses, are getting shafted. Your address means less than you probably think it does.
"if people had to pay for it" is the key. Once it is more expensive to support IPv4 than to adopt IPv6 for any given entity, that entity will adopt IPv6. That point is coming soon, it just happens to coincide with us running out of IPv4 addresses the way they are being allocated today.
This sounds completely reasonable to me. If IPv6 is truly the right solution, then the market will gradually dial up the pain for native IPv4 and we'll switch naturally.
What really needs to happen is the various RIRs need to expedite this process by making v6 extremely cheap or free, and making v4 prohibitively expensive. They will cop flack for it, but this is the bitter pill that needs swallowing.
IPv6 addresses are already free or nearly free. I think there's an important difference between scarcity naturally driving up IPv4 prices which encourages IPv6 adoption and artificially raising IPv4 prices to strong-arm people to switch to IPv6 because it's "good for them".
The problem with IPv4 addresses TODAY is that they're artificially priced. People deliberately do stupid things with their addresses (like, assigning permanent routable /32's to every computer in a dorm resnet) so they can avoid having to justify and possibly lose their vanity /16's.
"market based allocation" - this means further deaggregation of the existing prefixes.
Which translates into eventual serious capital expenditures for the carriers to hold the large tables. Worldwide.
In addition to the money required to pay for carrier grade translators. Though my employer produces them (amongst other stuff) - I do not think that architecturally they are a good thing.
All this money will need to come from somewhere. As the profit from a "prefix sold" goes into one pocket, but the expenditures are spread around the world, it means this profit would not come from IP addresses. It will come from the subscribers' monthly payments and quotas.
Translating: bye bye unmetered access on the cheap. Not so long ago in .be the ISPs were charging after you go over 10Gb on the DSL line.
About squeezing out the /8s from the current owner: that would help but not for long. It's like getting the additional credit line from the bank on the credit card.
Help me understand how RIB explosion is a major cost factor in IPv4, where there is a fundamental engineering incentive to dynamically allocate, but isn't in IPv6, which has as part of its value proposition the notion of everyone keeping a persistant block of addresses?
everyone is not going to keep the persistent block of addresses.
everyone with an AS# and BGP might - same as now for IPv4.
everyone who is single-homed to the same ISP - just might as well, since they will be using provider-assigned space that will be aggregated by their ISP.
I suspect that you interpret the last item as an advertisement that every Joe and his dog will get a PI prefix - I think they won't.
PA vs. PI space is an interesting topic, there is currently a very lively discussion going on in IETF on this:
Help me understand how making it technically simpler for people to have persistant portable allocations is going to decrease RIB sizes. It's been over a decade since I had to write a BGP regex, but to my uneducated eyes, it looks like the exact opposite is true.
It really feels to me like nobody wants to acknowledge that IP addresses are just the license plate numbers that ISPs issue; that, or they hope that IPv6 is going to magically change that.
What I see you saying is "yeah, well, that's not going to be a problem because very few people are going to bother to ask for portable addresses". But clearly more people are going to ask in a world where it's numerically possible for them to have one than in a world where it isn't.
It depends on the economic (dis)incentives around such an action, and they will be the main determining factor, as opposed to technicalities. Whether it will be much easier with IPv6 than with IPv4 - the time will show.
Much like with the a migration itself - which is a balance of the cost of hinging on the IPv4 only (investing into NATs and support), or investing into IPv6 infra as well as a strategic way forward. I have no material interest in either (gee, FWIW the NAT mess could provide much more billable work:), but having helped non-single digit hundred of people people un-shoot themselves with NATs in the past 10 years, I think IPv6 is cleaner architecturally in the long run - because it is simpler.
But I think we both agree it's a matter of economics. What is simpler and cheaper to use. And the fact that the p2p substrate in the heavily-NATted environment is a dead-on competitive advantage - so no-one is going to play the charity and release their code for the benefit of the community.
What is the benefit of having address that is scalar type in some programming language? Except that you get endian issues for free.
And exactly this "stop wasting address space for insignificant devices that are not mine" attitude is the problem that IPv6 tries to solve. I don't see any reason why there should be two classes of internet-connected and almost-internet-connected devices.
There is zero benefit to having addresses be scalar integers. What's your point? IPv4 addresses happen to be scalar integers, and are often treated that way, particularly in C code. Tsk tsk all you want, we still have to fix it.
I don't see any reason either, but engineering purity doesn't trump reality; reality suggests that freeing us from the distinction might not be worth the cost, at least not soon.
Ok, there are benefits to not having to use bignum routines to do netmask calculations in those few applications that address whole networks at a time.
The problem is in the library frameworks that do not give at all the means of making an IPv6 socket.
Once that problem is solved - porting the properly written apps is not going to be too difficult.
For the IPv4 address literals being scalars - well, properly written programs would have used the DNS names in the first place, and the use of the addresses would be appropriately contained. So I would treat this much as other bugs.
Pointers may also fit into int, but it is not a reason to fit them there.
Our v6 future is NAT'd to the horizon. If that's the case, what's the major win for v6 to this generation?
The notion that we're imminently going to run out of v4 addresses is at least somewhat artificial, since we run fiat allocation schemes right now and could migrate to a market-based allocation to replace it. There are companies addressing desktop machines with routable /16 components because they don't believe in NAT; there are companies grandfathered in to /8(!) allocations. A lot of this waste might stop if people had to pay for it.