The UK has an entire IPv4 /8 that it isn't using
blog.jgc.org
blog.jgc.org
More evidence for the core problem: fiat allocation doesn't work. If there was a functioning, liquid, accessible market for advertisable IP prefixes, you wouldn't have to convince anyone that a /8 was worth $1bn; it just would be.
There's plenty of numbers to go around; the sooner we get to v6 and get around this mess, the better.
IPv4 addresses are a scare resource. Acknowledging that, and allowing them to be traded at a price that reflects their value, is the surest way to get them out of the hands of those who are wasting them in the way tptacek and the article describe and into the hands of those who will do something more productive with them. Pricing IPv4 addresses would hasten adoption of IPv6 by providing a financial incentive to switch from IPv4 to IPv6 to those who can do so most easily (i.e., cheaply).
In other words, if you want to "get around this mess", stop allocating scarce and valuable IPv4 addresses as if they have no value.
So I?v4 addresses only seem valuable in this moment, because so many of them have been distributed -- bvut something that can be added in unlimited quantities (like a number) is inherently not valuable.
Do you remember when DOS and Windows file names could only contain eight plus three letters? Was the solution to proclaim file names valuable and charge extra for adding new combinations? Or simply to develop a new platform which allowed for longer names?
1. IPv4 addresses are overdemanded and undersupplied.
2. IPv6 addresses are practically limitless and will serve the same purpose once we switch over.
3. We should switch to IPv6 ASAP.
Where's the economic flaw?
(Also, it should be pointed out that allowing trades on IPv4 would not decrease availability, it would only increase it: Right now, you can't switch the owner of /x blocks without IANNA approval, so right now you have no choice but to push for switching to v6, whereas with trading you could waste money on v4 instead. Moreover, this would encourage the companies with the most money to buy IPv4 blocks rather than invest in switching over to v6, which would slow down the process for everyone since they're the biggest companies. TLDR -- force investment in IPv6 not IPv4. There's also a fairness issue since these IPv4 blocks were originally allocated for free -- should MIT be able to make billions on their block?)
Sort of, and sort of not right? Fiat allocation of a fixed resource, sure, but ISO does fiat allocation of OID space and it works because folks are free to grow as much as they want below it. As I recall one of the original 'next gen' IP proposals was like a huge address translation cloud, IPs were encapsulated in yet another layer which provided 'context' for the IP address inside. Basically every entity got their own 32 bit address space and ingress/egress to the Internet resulted in encapsulation and some additional router magic. One of the arguments against was the huge additional bandwidth cost. Of course we didn't realize at the time that few protocol changes could waste as much bandwidth as SPAM does.
The other challenge is that a functioning liquid market for IP addresses would most likely lead to speculation in IP address blocks. Worse is buying an address block from someone in Germany so that packets have to go to Germany first (top level static routing) to the router where they are re-allocated and then to their 'real' destination router. All very inefficient.
I, like other folks at Sun, was a big fan of a more modest 64 bit address proposal for V6, but alas it was not to be. That the conversion has taken as long as it has (and still isn't "here" nearly enough for a lot of users) really illustrates the dangers of the argument to 'permanently' fix things[1]. But innumeracy aside, the confounding issue is that IP addresses are 'structural' like telephone numbers and managing mobility of structural identifiers is always challenging (the cellular market deals with this all the time) so creating a truly liquid marketplace for these identifiers would ideally include fixing the structural issues which would allow the constraints to be fixed and thus eliminate the market.
Bottom line, it would have been great if folks had thought of that first, but they didn't and while future protocol developers can (and should) benefit from that experience, we're stuck with V4 address blocks that are stuck in various regions of the world.
[1] The most persuasive argument against 64 bit addresses was that this would only push the problem down the road, whereas 128 bit addresses fixed things once and for all.
I agree with you strongly that the 128 bit IP address is a huge design mistake, one that has unnecessarily retarded the deployment of IPv6 (I personally believe fatally so). Even in the '90s, a 64 bit number was still a scalar on most platforms you'd care about. And even in 2012, 128 bit numbers aren't. I think people drastically underestimate the amount of work it's going to take to upgrade the huge amount of software built on the assumption that you can store an IP address in a scalar.
The truly huge universe of code is at the application level. Sane applications use strings for remote hosts, or work with URL's, and let library- or OS-level code deal with the details of turning that into an address.
OS'es -- even Windows -- have supported IPv6 for nearly a decade. Most networking libraries I've come across also have IPv6 support.
The main problem isn't software, it's configuration. Namely the configuration of the interface between the customer network and the ISP. The ISP doesn't want to turn on IPv6 because it might break some customers, and the customer can't test IPv6 functionality since their ISP doesn't support it.
These problems are compounded for residential ISP's, since most of their customers can't be bothered to learn anything technical.
Alas, such discussions were not compelling.
you are missing a big point. This isn't like real-estate. This is plumbing.
Go do a search on "routing table growth"
This is actually a much larger problem than IPv4 runout. I mean, it's a problem that is further out, but it is going to hit well within my expected lifetime, and it's going to be a dramatically more difficult problem to solve.
The thing is, every time you break up a larger block into a smaller block, every router on the internet needs an entry in their routing tables[1] Usually, in content-addressable memory; Expensive stuff.
The thing is, the size of the global routing table? it's growing faster than moore's law.[2] I mean, it's not a huge deal now; for the price of a new compact car, you can get a router that has enough content-addressable memory to handle full tables and two 10g uplinks with 48 1g downlinks. reasonable cost of entry, if you ask me, and if you use dram (good luck with line rate 10G. don't think about faster line-rate.) well, then the cost is trivial. The routing table is under 500,000 entries in IPv4, so it's a trivial amount of dram.
The problem is that if this continues? (and all indications are that it's going to /massively accelerate/ if IPv6 catches on. At a minimum, you're gonna see the same number of ipv6 routes as ipv4 routes... and because IPv6 addresses are larger, ipv6 routes are larger) those routers are going to get more and more expensive.
So yeah, really? we need a way of charging, not for each IP, but for each announced route. Of course, that comes down hard on the little guys, whereas a per-IP charge is much more progressive. (a /8 takes up as many routing table entries as a /24.)
Getting by with a reduced number of IPs would be way easier for me than getting by without announcing my own block. Without BGP announcing my own block, my ISP has my balls in a vice. If they go down? I go down. More importantly, I need to change IPs when I switch to a new ISP.
I know what this is like, because I started out on my ISPs IP addresses, like almost everyone does. My provider found out that it's hard for me to switch off those IPs, so now I'm paying them, in total, for all the services they provide me, about twice market rate.
(It's actually really interesting, watching the dynamics of this problem play out on PPML or the like. Small players, like me, want to keep it easy to announce smaller blocks. We are fucked if you can only announce large blocks. Large players want tight restrictions on what size of a block you can announce, because they have the address space and they would rather not pay for more super-expensive CAM every time a Luke Crawford gets it in his head to start an ISP.)
[1] This is not strictly true. "every router that matters" would be closer to the truth. If you don't have full tables from multiple upstreams, well, you will be effected by rather more partial outages than if you do.
Now, it's quite possible that the Linux kernel's routing isn't dimensioned to provide this sort of performance, but if you want to avoid CAM in the IPv4 world, I don't see why you'd really need CAM...
(Also, I haven't looked carefully at how the L3 cache actually works on the E3s to make sure that it's shared between code and data, etc etc etc. Also, if you're actually implementing this, you presumably do want to include class E in the table, and then hope/assume that when class E doesn't get used, the CPU will be smart enough to cache the code instead.)
Hm. interesting. so, uh, for simplicity, we have 256^3 routes, right? each one is, uh, what,33 bits of data? I mean, you need 3 bytes for the network and then what, uh, 5 bits for the mask? then okay 4 bits for the dest so 33 bits per route, no? so (33*256^3)/8 is 69206016 bits, or what,66 megabytes? sweet jesus, you are right. I mean, you are off by an order of magnitude, but at this scale, who gives a shit about an order of magnitude.
Interesting. 'cause none of the commercial routers do this. which is fucking weird. With this optimization (only store the first 3 octets, as you aren't routing anything smaller, have a lookup table for dest. addresses.) you could take full tables in puny amounts of CAM that come on, say, l3 switches. I will ask around as to why this isn't done.
(of course, with IPv6, this does not come close to solving the problem. /32 is the 'standard' handout for ISPs, and usually the smallest prefix you accept is a /48. There are a lot of fucking /32s.)
Also, you'd have some complications, as /32s are commonly used to blackhole DDoS targets, but you only have a handful of those, so that would add complexity but it wouldn't kill the idea.
I bet I'm missing something- I mean, every two bit ISP would be really happy to give you ten grand for a 10G full-tables bgp router, and you can get l3 switches with enough cam for that and a few 10G ports for little more than half that.
>you can get l3 switches with enough cam for that and a few 10G ports for little more than half that.
Because I was confusing TCAM with DRAM; rather different sorts of things. (and that, I'd classify as a mistake of inattention. I made other mistakes in that message due to lack of knowledge, but, uh, yeah; I'm not usually /that/ dumb.)
Anyhow, uh, yeah. Looks like I also misunderstood what the parent comment was trying to do (/increase/ the size of the lookup table by breaking larger blocks into /24s, in order to reduce the number of cycles the CPU spends on the lookup.)
So yeah, in full? I'd delete my comment that I'm responding to here if I could. As I can't, I'd like to acknowledge my ignorance, for the record.
If I could rewrite that, I'd say something to the effect that huge amounts of effort have gone into making TCAM obsolete, and so far? well, progress is being made, but the progress isn't moving any faster than line-rates are going up, as far as I can tell. There are very smart people working on the problem, and they say it's a big problem. (my understanding and experience, as a sysadmin that also deals with networks, is that your linux-based PC routers can route something between 1G and 10G of line-rate small packets. Above that, PC routers can't cope with the PPS.)
Note, uh, I do have two spare E3 xeons laying about the office, and 10G interface cards for both, as well as (at least for a short while longer) two nice arista brand 10G switches, so if you are in the sunnyvale area, and you do want to test an idea or bench the current state of the art of software routers, well, it's something I've gotta do anyhow. I still don't have anything even attempting to route my new 10GbE Cogent port. (I've split off a 1Gbe connection using a switch, and plugged the 1Gbe connection into my existing quagga router.)
Given your constraints, I wonder if what you actually want is one switch for each upstream, and a gigabit link from each of your physical Xen servers to each switch that goes to an upstream. If your switches have to route at all, they can each have a default route to the one respective upstream connected to that switch. Then, have a VM on each physical Xen server with full routing tables to control how the outbound packets from all the VMs on that physical host get routed. And hopefully your switches can deal with a /32 route for each VM or something, if they just have a route per VM plus a default route to the one ISP they're connected to.
There's also the variant where you have a /24 block (or something) which has one IP address which is your ISP's router, and then one IP address per physical Xen server, and if your ISP is willing to take individual /32 announcements to your servers (I think this is technically feasible, but may require more mental flexibility than some ISPs have; on the other hand, I think you're talking Cogent, and mentioned that Cogent is willing to peer directly with your customers, which may imply that you're dealing with a flexible ISP), you can have the ISP do the layer 3 routing to the right physical host for traffic going to each VM. (The idea is that the ISP would not propagate the /32s to their peers; you'd separately send them a broader announcement that they could pass along to their peers.)
One other issue in this scheme is that if a single gigabit link between one physical Xen host and the switch going to one ISP breaks, inbound traffic that happens to come to the ISP attached to the switch with the broken link ought to have some mechanism to find its way over to the other switch for the one physical Xen host that has the broken link. I think there are ways that OSPF and or iBGP with the non-default next-hop-self setting can be made to do this.
Added to that, even if it was seeing only minuscule internal use, the UK government's IT project reputation suggests the renumbering would cost at least as much as the block would sell for, assuming the project would even complete prior to the entire planet properly migrating to v6 and the block losing its value.
We just got audited for RIPE for exactly this reason, and they made us specify details for all of the networks we use on our allocation to be allowed to keep our address space.
I'm wondering if RIPE can even do anything regarding that netblock in terms of possibly pulling it and re-allocating it.
All they can do (and have already done) is ask nicely for it back.
A central address registry along with 'public' allocations is the only way to avoid this kind of mess. The fact that public addresses are currently scarce doesn't make having unified addressing any less desirable (just presently impractical).
If anything, today, networks are more likely to end up interconnected than they were in 1994.
Under the circumstance that you have a spare /8 you aren't using for anything.
You could argue that "the best thing" in that case would be giving, selling, or leasing pieces of the /8 to someone who needs the space. But maybe you aren't in the philanthropy business, so giving's out.
And maybe the prices aren't high enough for your taste, so selling or leasing are out. Or maybe there's simply not enough demand on the market to absorb 16m addresses. Or maybe the terms of the allocation agreement say you're not allowed to transfer them, and you're afraid that trying to do so will give the Internet people a justification to give them to someone else.
> if routable IP addresses were easy to get, there would be lots of cases where it would make sense to use them
If your organization has a spare /8, routable IP addresses are easy to get for you, so these cases do make sense, for you.
There are a number of ways the IP addresses can not appear to the outside user and still be used as several have mentioned, and of course they can be for some project that isn't yet 'done' (the Coast Guard had a huge block like that as I recall) but the more interesting bit is to track the cost of getting an /24 network its inching up. At the time where the easy stuff has been reclaimed it will shoot up.
The amount of time spent bike-shedding "well, v4 isn't running out as fast as they say it is" or "NAT will save us" (lol, no) that time is better spent deploying v6. For many installations, its actually not that big of a deal to do.
If your network doesn't already support v6, you're the person everyone is waiting on! You don't need to wait for your upstream provider to supply you with v6, tunnels are super easy to get.
The only exception to tunneling is if you're hosting a public-facing service, don't have v6 connectivity and don't trust existing tunnel providers. In this case: First, why are you at you're current host or colo center? They're probably shit. Second, set up a box at a provider with good connectivity to run the tunnel yourself. This is basically what we already do when we want to use our public v4 space but the ISP doesn't want to let us talk BGP.
edit: And its not a "hackers" thing, its a "technical competency" thing.
And that's ignoring the possibilities that a) it's being used internally by its legitimate owners b) it's being used internally by other people. T-Mobile were seen to be (mis)using the /8 that belongs to the UK MOD for their internal networks, I wouldn't be surprised if they were doing that with this as well.
There aren't that many IPv4 addresses. There are no easy fixes. Just move to IPv6 already.
Between the bunch MIT got, the bunch that the military got and the bunch that IBM got, we can implement an entirely new protocol before we run out.
When Apple and MIT got their allocations it probably seemed pretty reasonable at the time. "How many organizations like that would be interested in the internet? A dozen? That sounds about right."
There was a time where anyone with a .net domain name would be able to apply for and probably get a /16 allocation with hardly any questions asked.
If by "really needed" you mean just in terms of having one address for each machine then sure there's a bunch not being used. Let's suppose half of them. Assuming a constant growth rate, that would last us for ten more years. But actually internet adoption is still accelerating. A safer assumption would be something like five.
But our routers would collapse under the strain of the enormous routing tables long before then. To be able to route efficiently subnets need to be logical regions in the network topology, not arbitrary collections of 2^n machines. CIDR, needed to mitigate against the shortage of IPv4 addresses (or more properly the shortage of subnets) has been slowing the internet down since 1993.
>Between the bunch MIT got, the bunch that the military got and the bunch that IBM got, we can implement an entirely new protocol before we run out.
Given that we've been working on IPv6 for 15 years and it's not fully deployed yet, no we can't. Even if every single address was unallocated today, we'd use them up before then.
The design of IPv6 began in the mid-90s, and RFCs were released in 96-98. Now, 15 years later, we are mostly still using IPv4.
In conclusion I think saying that we would have enough time to implement entirely new protocol if we'd reclaim unused addresses is way too optimistic. Even getting IPv6 really deployed at large in 4 years would be challenging enough.
What's the benefit of using them instead of a 10.0.0.0/8?
There's no way they would be so diligent to use that IP range internally without even a tiny bit of evidence externally.
"The 51.* addresses are in fact heavily used by DWP, but only internally. The best bit is this: for security reasons, there is a policy that in any communication, the leading octet of all such IP addresses must be redacted. Not like it's a matter of public record or anything. I did once toy with the idea of printing out the XKCD map of the IP4 address space, write "you are here" on it and pin it to the wall near DWP data networks teams, but I didn't think it would go down well."
Even Comcast supports IPv6.
All that's left are the clients, and the way I see that transition happening is in the low-cost sector. Sort of like an AOL where you won't have IPv4, so you'll have to access everything through a proxy except IPv6 sites. Eventually businesses will want to cater to this demographic and the stragglers will flip the IPv6 switch. With nobody on IPv4, it won't be a premium value-add anymore, and that era will be a distant memory of the past like BBSes are now.
Right now the IPv4 situation is not bad enough to make widespread IPv6 support critical to one's economic viability yet. Being able to see the animated turtle on kame.net isn't quite enough of an incentive, but the incentives will slowly shift.
(I see the same transition away from fossil fuels. Right now, an investment in alternative energies is pure speculation: it may pay off someday, but we don't know when that day is. When we've run out, though, the payoff will be clear: you will get infinite money the second you figure out some way to give humanity energy. This will encourage more investment than some nebulous LEED certification will. Tax credits are nice, but not as nice as cash.)
Seriously, unless you want to be posting to HN via IPv4 in 2050, there is clearly something major left undone. Don't call it a transition if you think that concept is undone, but it's not yet functionally possible to be on the Internet with no IPv4 stack or (possibly NATted) address, and I don't see that becoming the case anytime soon.
See http://cr.yp.to/djbdns/ipv6mess.html for a description of the problem that I mostly agree with. The depressing thing is that those complaints are no less valid a decade later.
It's happening.
You're expecting altruism or geekiness on the part of every single website ever -- it's fair to expect that from Google, but not from everyone. The transition may or may not be happen_ing_, but it will never finish.
Today, IPv6 is billed as a premium feature. Tomorrow, IPv4 will be the premium feature.
I don't think you understand how the Internet works. Or business. There is no foreseeable point at which it makes sense to bill an "Internet" service that's IPv6-only. That's doable _after_ the transition, but expecting that to happen now is not a transition.
The biggest issue will not be getting everybody onto IPv6. That will happen at some point, however distant. The bigger issue is that clients slow to transition to IPv6, for whatever reason, will experience IPv4 service degradation as more and more of the internet switches to an IPv6 only stack.
If it's been "being solved" over the last ten years, neither you or I will see the end of IPv4 on the public Internet within our lifetimes. Or, if we do, it's because something bigger and better will come along, obsoleting every version of IP. The debate over whether to switch to IPv6 will sound as silly as a debate about Morse code in the 1960s.
The future will come up with their protocols. IPv6, or maybe something other than IPv6, needs to be a protocol we can start using now (and not just because it's cool, but because it's useful) and not feel like it's wasted if it becomes irrelevant in 2025.
Then there's software. Many web apps don't support IPv6 (db fields limited to ipv4 format, or code assuming ipv4 format). For instance, Internet Brands is too busy with important business, like frivolous lawsuits, to fully support IPv6 in vBulletin. [1]
Some webapps have 3rd party hacks (or even first party hacks) to "support" ipv6 without modifying a lot of ipv4-dependent code, typically by hashing the ipv6 address, taking 32 bits, and using that as the ipv4 address. It's both disgusting and funny.
There's a long way to go before IPv4 is dead.
[1] http://tracker.vbulletin.com/browse/VBIV-9397 (you need a vbulletin.com forum login, unfortunately, and maybe also a linked license; in summary, it's a 2-year-old bug for full support of IPv6, it has no comments from vbulletin devs and no assignee.)
That being said, here is a list of people in charge of allocations: http://www.ampr.org/oldsite/amprnets.txt
Scary thought is it not!
The first real opertunity to move to IPV6 in any way would be mobile smartphones and there like and yet that is not happening. It realy is a case of the ISP's and mobile telco's that need to start initiating the IPV6 move and until they do nobody will be dragged into following.
Maybe if it was illegal to sell devices that don't at least support IPV6. But of a messy situation when you can buy devices made brand new that still dont offer IPV6 support, criminal realy.
Still when you look into the history of British railways and the better modern alternatives you can see how some legacy designs just carry on with there limitations of capacity oversight.
Another aspect is cunsumers have in many respects forgotten how to complain to a company and let there frustrations out on the internet in area's were the companys offering the services will completely fail to notice and allow you to complain and vent of without them even knowing or indeed having to care.
How many of you have asked there internet service provider if they support IPV6 or indeed what there plans are to offer it? Reason I ask is that I can bet it's lower than 1 in 100 or indeed 1 in 100,000. I can't even recall any one of my friends or anybody I know or have dealing with ever mentioning they had made such an enquiry. I know I have, please tell me I'm not alone at least.
And the top post claims it would be worth $1BB. Keep dreaming.
The truth is that the value is not in addresses, the value is in the network, and those who own the infrastructure, but of course there is no single infrastructure for the internet because it's a network of networks, owned by various parties.
The telephone company can charge you for a telephone number. It owns the network that you're going to use it on. If it didn't own the network, you would not pay for the number. You are paying to use the network. The number is just a formality.
This same is not true for the internet and IP numbers. The RIR's don't own any networks. There isn't even a clear line to the source of their authority to "allocate" address space. Does the US Government own the internet? Good luck with that argument. RIR's charge fees to "allocate" addresses, an administrative job, but we have no idea how the fees are spent. Maybe to pay the CEO's generous salary? How much work is it to keep track of some numbers? Maybe we should ask IANA. The whole scheme works based on cooperation and acquiescence.
No organisation ever paid $1BB for an /8. They got theirs for "free" (inconsequential maintenance fees notwithstanding).
IPv6 is still not mainstream, so this figure can reasonably increase over time with the increase in IPv4 scarcity.
Thus it stands to reason not to sell out just yet.
IP blocks are "licensed", not sold. These licenses can be transferred, but only under certain strict conditions.
The ARIN CEO stated [1]
«As you may be aware, ARIN is the Regional Internet Registry (RIR) responsible for Internet number resource management for Canada, United States, and parts of the Caribbean. In keeping with the policies developed by the community in this region, there are two possible ways to transfer IPv4 number resources to another party (via merger & acquisition transfer or via specified transfer), and these are detailed in section 8 of the Number Resource Policy Manual on the ARIN website at <https://www.arin.net/policy/nrpm.html>;
It is important to note that transfer of number resources via either method must be to another party that can demonstrate corresponding need. ARIN's registration services department can assist with this determination in advance or at the time of transfer. ARIN reiterates the importance of veracity in transfer requests and supporting documentation as fraudulent information can result in resource revocation.»
NRPM section 8 [2] says
«Number resources are nontransferable and are not assignable to any other organization unless ARIN has expressly and in writing approved a request for transfer.
…
It should be understood that number resources are not 'sold' under ARIN administration. Rather, number resources are assigned to an organization for its exclusive use for the purpose stated in the request, …»
Older blocks allocated directly from IANA have different conditions attached to them that may render the transfer of the these licenses simpler or harder.
[1] http://mailman.nanog.org/pipermail/nanog/2011-August/038888....
$10 x 4B x 12 months would solve the national debt in just a few years...
Also the assigned but unused IPv4 blocks don't do anything for other providers that actually need addresses.
However, L2TP and IPSec VPN connections work just fine over 3G on Rogers, no fees or APN changes required. So I'm not positive that NAT is the issue if I can establish the other types of VPN connections although this is hardly my area of expertise.
Even if they were to start announcing them or selling them it would be a HUGE project for IBM internally to make sure that their computers aren't going out on the web for internal resources, and it becomes an huge issue of having to renumber.
Unfortunately there is no good way to support something like that. Some companies didn't need to use the private LAN addresses because they had their own /8 and changing it now would require too much effort and work.
I'm probably forgetting a lot of things but to me it would seem doable to switch to private LAN addresses using DHCP and NAT, as long as there are no hardcoded IPs lingering around (but only hostnames which can be updated in a central location).
Thing is though, if a pretty compitent company like IBM who know how to do IT have not moved to IPV6 and use public IP ranges for there internal networks albiet router blocked. Well, it just don't bode well for other less technicaly compitent people to move now does it and the cycle of procrastination with IPV4 carry's on :(.
If I knew now what I knew then, I would've gone for a class B block. lol.
http://www.bluishcoder.co.nz/2011/05/12/namecoin-a-dns-alter...