Whatever happened to the IPv4 address crisis?
networkworld.com
networkworld.com
For an example of a real victim, look at Qatar, a country which only has a single IP address for the entire country (everyone sits behind a NAT): https://en.wikinews.org/wiki/Qatari_proxy_IP_address_tempora... [0]
Whenever someone from Qatar decides to vandalize Wikipedia, Wikipedia is forced (temporarily) to block the entire country from accessing Wikipedia. This has an adverse impact on the rest of the country.
Non-Qatari Wikipedia users also suffer, because Wikipedia makes those blocks very temporary (since they are effectively shutting off an entire country), which makes it easy for those vandals to regain access to Wikipedia quickly.
[0] This sad state of affairs is not solely due to IPv4 (incompetent/apathetic network administrators are also at fault), but it's a contributing factor.
Can't they just block IPs from editing? Seems like that would solve the problem
Browser configurations can be easily generated by a computer and you never run out.
Wikipedia has choices, and it's choosing something well within its rights to prevent abuse of its property, but they could choose to do something different.
Given the type of website Wikipedia aims to be, it's hard for them to give Qataris the service they want to deliver.
(I guess one method could be to force everyone from this IP address to create an account, but that goes against their openness/ease-of-editing-for-new-or-casual-users principle.)
I got lots of different answers while googling. Is it still a range (they rotate through their allocated space), or do my googling skills just stink?
I get you have an interest in the Qatar/Wikipedia situation, but it seems to be unlikely due to IP address resource management issues. Probably more like tyrannical control, if anything.
You piqued my interest, what?
Doing it solo now, but I need help.
You may have better luck with other continents. Try AfraNIC.
Is this the state of HN now?
Waiting for down votes for myself now.......
On the other hand, IPv4 and NAT are a boon to privacy. We'd be exquisitely trackable if NAT didn't exist and every single device had a unique, unchangeable, life-long IP address. That's more-or-less how IP addresses were supposed to behave and IPv6 brings that back.
We need to be thankful for NAT for the privacy it brought by accident.
Now you have two problems.
In reality you can't just decide for your customers that they do or don't need something - you have to ask them what they need (if you want to continue having customers). Nobody's going to re-engineer all their shit to support your wonky network if they can just go to another company that provides them what they need.
For Comcast and the like, once again give me the option to either do NAT64 or a full dual stack. As a regular consumer I probably won't care. As a gamer or a developer I might.
The IPv6 transition is going to happen sooner or later. Either you are going to make it painless for your customers by providing IPv6 early and using strategies to make the transition to IPv6-only smoother or you are going to make your customers suffer.
This has nothing to do with net neutrality. It's progress of technology. Your ISP doesn't give you IPX access do they? Instead this is a natural progression of technology. Want to use old tech? Pay a premium!
I think it's very close to dual-stack, and this technique has the advantage of being extremely easy to deploy. Especially if you already have NAT64 gateways setup in your network, then you have done more that half of the work :-).
[1] https://android.googlesource.com/platform/external/android-c... [2] http://www.ietf.org/proceedings/84/slides/slides-84-sunset4-...
I have a friend who runs a small low-cost minecraft hosting. He stopped giving his customers dedicated IPs at all. They get a range of ports and a hostname with appropriate srv records added.
That's the other result, technical work-arounds. You can point to a particular service on a particular port with an srv record, host multiple websites on one IP, even SSL-enabled ones with SNI, etc.
For whatever its drawbacks, IPv6 at least requires few application-layer changes. So I think it's a better solution to the problem than SRV records.
Unfortunately IPv6 adoption is not a matter of just providing access lanes to this wonderful new technology. IP permeates too much of the infrastructure, tooling, etc. How could it not? Some companies might find the cost/ROI of working around IPv4 limited address space to be less than migrating to IPv6.
You would want to assign an IPv4 address to the client transparently; and, since they're scarce, share it with several clients. That's what NAT64 does.
so the ipv6 address of 66.249.73.108 is 66.249.73.108:0
Rather than having to replace every single piece of hardware, software, nameserver and routing stack that works on IPv4. I could plug my IPv6 router into any ISP that gives a v4 address and have as many v6 addresses as could ever be needed.
It makes no sense to me why you would route IPv4 addresses on v6 LSB, it completely ignores current internet infrastructure and routing.
But you don't want to do that forever as you are now paying for a IPv4 header PLUS some more headers instead of just one IPv6 header if you have native IPv6.
so your routing table holds "66/4 port 1" ,"* port 2"
instead of hundreds of millions of entries to get the same thing by having the "66" >64 bits deep into the address (or worse ::66:* port 1, which breaks everything - hell how is this even done now?).
My point is, if the v4 address was in the MSB as standard, IPv6 would be working in virtually every single IPv6 device already.
As it is, we are all still using workarounds (and VPNs).
There are multiple issues with this. The first and probably most important one is that it doesn't address routing table fragmentation, which is pretty much solved with IPv6, because most ISPs will end up announcing on the order of 1 or 2 prefixes instead of dozens, which can't ever be aggregated (like is the case in the IPv4 world right now and will only get worse).
The second one is, that it doesn't gain you much in terms of deployment over IPv6 + tunnels.
> so your routing table holds "66/4 port 1" ,"* port 2" > instead of hundreds of millions of entries to get the same thing by having the "66" >64 bits deep into the address (or worse ::66:* port 1, which breaks everything - hell how is this even done now?).
Ok.. I have no idea what you are talking about here (mainly your notation is leaving me confused)..
> My point is, if the v4 address was in the MSB as standard, IPv6 would be working in virtually every single IPv6 device already.
Even in the presence of NAT?
my point is with that notation, right now we have say a google address of 66.249.73.108
How does IPv6 handle retaining all the existing work and man hours that has gone in to making packets go to the 66.249.73/24 network, as quickly as possible, from anywhere in the world.
It seems to me it expects every administrator from top to bottom to start from scratch, then everyone is scratching their heads as to why that hasn't happened.
>Even in the presence of NAT?
No, and this is a good thing, only IPv6 devices which have their own IPv4 address/network can issue IPv6 addresses on that network. This is a good thing. e.g. I get 66.249.73 to be 421D:4900:0:0 in hex.
In what universe does this need to be ditched and started from scratch, and making something:something:0042:1D49 re doing - by hand - every NS, routing table etc
Where did these hundreds of millions of higher level routing tables suddenly come from?
It keep being phrased as "what is the source address of an IPv6 host on an IPv4 network". It seems to me the answer should simply be "the first 32 bits of the IPv6 address" - and it seems stupid it's not structured like this.
So you will still need tunneling to make it work. As you will still have to run CGN to get all your customers online. Unless of course you do want to change the network infrastructure. At which point your solution gets much worse than plain and simple IPv6.
> It keep being phrased as "what is the source address of an IPv6 host on an IPv4 network". It seems to me the answer should simply be "the first 32 bits of the IPv6 address" - and it seems stupid it's not structured like this.
Sure.. that solves the routing problem (except for IPv4 routing table explosion), but doesn't solve the problem that IPv4-only hosts still can't talk to IPv5-hosts. You send [IPv4][IPv5] packet to IPv4 host. Huh? What's that IPv5 thing? Or the other way around.. IPv4 host sees AAA record (with IPv5) in DNS..
Your proposal solves nothing that can't also be done with IPv6 and tunnels if you are really keen on keeping your 5 old router running a few more months before throwing it away (which you can't do anyway, as your limited FIB size will force you to buy new hardware anyway, due to IPv4 route table fragmentation).
The full solution is NAT64.
To me, this indicates something either broken about IPv6 or a lessened severity of the IPv4 problem: If it's better to apply bandaids to IPv4 than to roll out IPv6, then either IPv6 is not easy and flexible enough to be a viable alternative, or the problems faced by IPv4 are not as intractable as was suggested.
2**128 = 3.4 * 10**38
grains of sand to one mile down [1] = 5.1 * 10**26
stars in the observable universe [2] = 7.0 * 10**22
estimated grains of sand [2] = 7.5 * 10**18
[1] [http://www.teracomtraining.com/tutorials/teracom-tutorial-IP...]
[2] [http://www.npr.org/blogs/krulwich/2012/09/17/161096233/which...]
When I looked at it 19 or the 20 involved in the RFC for ipv6 where from academia plus one guy from bell labs.
Migration and Interpenetration should have been the highest priority in the design on a replacement for ip4
Even 20 years ago the Internet was obviously not going to be able go on as before where you could make major changes over a long weekend during the summer at the few core university's that where the the internet.
That is why ipv6 should have been replaced.
It is a balancing act, but at some point we have to cash in our chips and make things usable in the short term.
I have even setup organizations with native IPv6 addresses (no tunnel) to watch them fear and lament it.
There's a thousand excuses and people need to look upon this as an opportunity; to up their skill set and mentor a new generation.
The potaroo site by Geoff Huston has been running for over a decade tracking address consumption.
Some history for ARIN consumption predictions: Feb 2014 predicts Mar 2015.
Oct 2013 predicts Jan 2015 [0].
Apr 2013 predicts Apr 2014 [1].
Nov 2012 predicts Sept 2013 [2].
Sep 2012 - RIPE out of addresses.
Apr 2011 - APNIC out of addresses.
Feb 2011 - IANA out of addresses.
Dec 2011 predicts July 2013 [3].
July 2011 predicts Nov 2013 [4].
Prior to this it's simply about IANA calculations, though with some algebra some dates could be extracted.
As well, here's a Cisco article from 2005 describing some of the painful parts of trying to predict the address consumption (where they guess 2016 in 2005): http://www.cisco.com/web/about/ac123/ac147/archived_issues/i...
[0] http://web.archive.org/web/20111227105916/http://www.potaroo... [1] http://web.archive.org/web/20111227105916/http://www.potaroo... [2] http://web.archive.org/web/20121122120407/http://www.potaroo... [3] http://web.archive.org/web/20111227105916/http://www.potaroo... [4] http://web.archive.org/web/20110709090704/http://www.potaroo...
These aren't brick walls but the shortage is already being felt. I know that at Efficito, one of the reasons we switched hosting providers was that we couldn't get ipv6 connections working flawlessly to our backup connections before (meaning more ipv4 space required). I don't think we will ever hit exhaustion per se.
The real problem is routing table size with BGP. As we continue to divide the internet into smaller routable blocks, this is requiring an exponential amount of memory in BGP routers. Currently, the global BGP table requires around 256mb of RAM. IPv6 makes this problem 4 times worse.
IPv6 is a failure, we don't actually _need_ everything to have a publicly routable address. There were only two real problems with IPv4: wasted space on legacy headers nobody uses, and NAT traversal. IETF thumbed their noses as NAT (not-invented-here syndrome) and instead of solving real problems using a pave-the-cowpaths-approach, they opted to design something that nobody has a real use for.
Anyway, I'm hoping a set of brilliant engineers comes forward to invent IPv5, where we still use 32 bit public address to be backward compatible with today's routing equipment, but uses some brilliant hack re-using unused IPv4 headers to allow direct address through a NAT.
Flame away.
1. In theory the routing table with IPv6 can be smaller. The address design should be hierarchical, which means you should be able to have much fewer routes. It's too early to tell if this is actually true or not, but the addresses themselves are 4x larger - which isn't going to be the determining factor in routing table size.
2. Not everything needs to be publically routable, true. IPv6 has the idea of link local and autonomous system local addressing which IPv4 doesn't have. The RFC 1918 block was used instead. But think for a second - there's only 4 billion addresses (less when you count bogons and multicast ranges), and it's only a matter of time until those are taken up. So we can choose to do it now, 2 years from now, or 5 years from now, but devices are growing faster than ever and it's only a function of time.
3. NAT is not a security feature, is not good for the internet, and the sunk costs spent building an ALG for every protocol to work around it is a significant development sinkhole. It's a workaround often masqueraded as security, and does cause many application problems. It's just not normally the application developers that have to fix those problems - it's the network and security teams.
4. IPv6 was created in the late 90's. People have been waiting for brilliance to supercede IPv6 for a while. I'll admit it's not the easiest, but there are a certain set of problems you have when you expand the address space.
5. I'm familiar with all the IPv4 headers, and nearly all of them are used. ID is used for packet identification, particularly through network services, DSCP is used heavily, DF and other flags are used - they're just obscure. If you look at IPv6 those same headers are basically recreated, though with slightly different names. The ones that aren't included are addressable through the extension headers.
So, yeah. That's another perspective that may help you understand why IPv6 is a bit of a quagmire. The faster people understand this, the sooner we get to a place where the chicken-egg problem fades away.
Is that even remotely close to being true in practise? Would we expect to see it be smaller than IPv4? Given the quadrupling of address sizes, wouldn't that mean there'd need to be 1/4th the number of routes? And peering destroys the hierarchy, does it not?
I was under the impression that the hierarchical routing had an assumption that networks could renumber at will. So multiple subnets might map to the same host or something to that effect. Is that incorrect?
>3. NAT is not a security feature
Except it turns out that proper NAT is equivalent to a firewall with inbound deny, outbound allow. Which is a pretty good start for security.
>ALG for every protocol
Applications that break with NAT usually do so due to poor design (hey SIP and FTP). With a firewall with default inbound deny, programs can't just accept inbound connections without doing work anyways (UPnP or whatnot). Although sure, it makes known-two-way datagram applications easier since you start transmitting and get a flow opened. Wouldn't help TCP based applications, for instance.
No.. the point is that each ISP will get only one very large prefix (/32 or bigger) instead of many small ones, which can't be aggregated like it is the case for IPv4.
Right now there are about 46k ASN's in the legacy internet announcing about 490k IPv4 routes. Best case with IPv6 you would end up with 46k routes.
In practise it looks like there are 8k ASNs in the internet announcing about 16k IPv6 routes. So while not perfect, it's still quite a lot better than for the legacy internet.
> Applications that break with NAT usually do so due to poor design
So how would you design a P2P application that has no poor design?
>So how would you design a P2P application that has no poor design?
SIP and FTP break even in non-P2P scenarios, so my comment was mainly directed at them. For P2P apps, NAT doesn't pose a whole lot more of a problem than a firewall with the same configuration. So you'd use UPnP or whatever protocol to get around it. At that point, it doesn't really matter, does it? The app talks to local gateway and ask for the IP and port forwarding either way.
Peering doesn't require you to announce more routes per se, although some networks do it for traffic engineering purposes. From an BGP [1] perspective there is not that much difference between peering and transit.
> I was under the impression that a lot of announcements were driven by the need for not relying on a single provider.
Multihoming is another issue. And you can explain the difference in the number of AS [2] as networks not having deployed IPv6 yet. But the number of announced routes per network will be lower for IPv6 than it is for IPv4 (which hasn't even reached the worst case yet).
> For P2P apps, NAT doesn't pose a whole lot more of a problem than a firewall with the same configuration. So you'd use UPnP or whatever protocol to get around it. At that point, it doesn't really matter, does it? The app talks to local gateway and ask for the IP and port forwarding either way.
But that way you are still pushing more logic into the applications (namely that they have to implement UPnP). Which actually might end up requiring more code than your actual application (SAFT [3] for instance..). Now in the firewall you could just allow known-good inbound ports and be done with it.
[1] http://en.wikipedia.org/wiki/Border_Gateway_Protocol [2] http://en.wikipedia.org/wiki/Autonomous_System_%28Internet%2... [3] http://fex.rus.uni-stuttgart.de/saft/sendfile.html
The original reason that I began using NAT was so that my ISP couldn't charge me per device. You just plugged in a NAT enabled router, and ran everything behind it. That became so ubiquitous that ISPs gave up on trying.
My concern about IPv6 is that ISPs will want to go back to charging per device. I didn't like that then, and I don't want it now.
The fact that demand for this is so low, just goes to show it's not needed at the moment.
In fact, I can't think of a single reason "why" IPv6 would be needed.
I definately don't want all my devices to have a web reachable address, far from it, total security nightmare.
one entry point - a VPN on IPv4 is just great thanks, secure and easy to manage. want to access my other devices, jump on the VPN.
I that sense, you can describe IPv6 security, as configuring your VPN with no password and letting anyone connect to it.
The other way to look at it, is the successsor to IPv4 is called tor.
There are 4 billion IPv4 addresses and 7 billion people on the planet. Before we even get into business use of IPv4 for servers and such we don't have enough addresses to do what you want.
It strikes me that it's more likely a lack of strategic investment in infrastructure.
Routers using TCAM seem to max out between 1-2M routes (divided across v4, v6, MPLS, etc). More recent routers are using slightly more flexible processors so there's some hope but the router product cycle is fairly lethargic.
IPv6 also deals better with packet headers, so it's easier to calculate for routers. I suspect however this will make more of a difference for high end routers with lots of traffic.
As others have mentioned, the dual-stack transition does require more resources. Then again, you can implement NAT64 (or 464xlat), which seem to become more realistic/robust/more widespread solutions (running dual-stack also means managing two layers of routes, two layers of firewalls, etc).
(Disclaimer: this is not my day job, I just find it lots of fun to play with on my local network and the Montreal local city mesh.)
Looks like they've got more than one /8. ARIN has been trying to get the holders of legacy space to sign new SLAs and to get them to give over some of the space, but considering the IP address market, why not just sell the space instead?
It's simply not worth the time and cost for such a short-lived bandaid.
1960s: Peak oil 1995 @12.5 billion barrels/year.
Today: Peak oil 2035, current production is over 2.5X the previously predicted peak.
There's also an increasing expectation that rather than "peak oil" being a supply-side constraint, it will be a demand-side constraint as more efficient use and alternative energy sources become available - that is, we will never "run out".
http://www.sciencedaily.com/releases/2013/07/130710114436.ht...
Don't be silly.
We previously had backups located in Denver and production servers located in Europe, both through the same hosting provider (FDC). We never could get IPv6 working flawlessly (high packet loss, etc) intercontinentally and the problems weren't on our side.
We moved to Hetzner and have our systems spread throughout their datacenters (backups, and some backend systems on one side, customer data on the other) and have had absolutely no problems with ipv6.
What this tells me is that somewhere between the Czech Republic and Colorado there are routers which although they sort of support ipv6 don't do so in a usable way.