Slashdot Mirror
What About IPv6? How Long Until Widespread Deployment?
Christopher Blood asks: "Over at the register, they talk about the EU adopting IPv6. So what about the USA? When do we get it?
IPv6 would solve some and DOS problems and we will need the extra address space. What's the holdup?" While IPv6 may be the cure for all of our IPv4 ills, upgrading the whole internet to the new technology isn't going to happen over night. What has been done to prepare for the jump, and what still needs to happen before it can become a reality?
When corporate America determines they can make a profit from it.
sPh
true. but if you're not located next door to said company, the main trunk routing tables become ridiculous.
Remember --- M.I.T. has more assigned IP addresses than ALL OF CHINA.
It's not north america thats going to drive IPv6, it's Europe and Asia where they're already starting to feel the address squeeze.
From the point of view of any individual organization, there are no reasons to switch to IPv6 right now. First movers receive no benefits at all: in fact, it only makes communicating with the rest of the (currently IPv4) internet more difficult. Moreover, I imagine that many businesses large enough to have an impact already have a large IPv4 address block, and have a vested interest in discouraging others from making the switch:
The various hacks available for IPv4 do the job. I can easily imagine a scenario where Cisco doesn't push IPv6 routers hard enough in the future, and people invest more and more in NATs and so forth, making a global switch harder and harder as time goes on.
The fundamental problem is that IPv6 doesn't provide any short-term killer benefits, and that's what's necessary for an evolution to take place. My prediction (though predicting acceptance of technologies is always risky, so I may well turn out to be wrong) is that we will still be using an IPv4 internet in a decade.
Of course only blocking incoming connections is only a part of a security policy.
/. (as this very post bears witness to). Would my IPv6 site-local address be able to do the same - in other words, is the state of NAT for IPv6 anywhere near IPv4? Considering the common opinion is that NAT is unneeded in IPv6, I very much doubt it.
However, both the examples you gave in your message required you to be able to connect to the target machine via HTTP and issue an HTTP GET request - therefor you had inbound connectivity to the target, just not inbound connectivity to J. Random Port.
There is NO inbound port available to you. Not 80, not 22, not 25, nothing. The only inbound ports would be when I am FTPing down a file, if I am not running passive mode. However, since the firewall only allows traffic from the FTP server, you would either have to spoof that (and then all you would do is corrupt the file I am downloading) or hack the FTP server (same problem).
And as to the other people who pointed out that I could use a site-local address: Of course, what do you think 10.200.120.4 is? However, NAT for IPv4 is very well tested, so my "unroutable" 10.x.x.x address is still able to get to
The great thing about my workstation being unroutable is that, should I be stupid enough to get a Trojan that announces itself to the 'net and says "I am at $address $port, come abuse me", if $address is not routable, this does very little good for the script kiddie - even if the system reports a traceroute so that he can follow it back, he STILL cannot route a packet to it.
(now, this does not stop the Trojan from connecting to an [icq|http|SOAP|...] server and pulling its commands down, but as I stated at the first of this post, no one aspect of securing a system is sufficient - security is a journey, not a destination).
www.eFax.com are spammers
First thing I did when I took over responsibility for hosting and internet connectivity at a (largish) company I worked at was to replace their existing public IP space (a few thousand addresses) with private IP, hidden behind NAT. It made internal routing *far* easier.
Of course, a few hardcore techies complained. So, I said that if they had a problem with it, they could come tell me why. If they had a good reason for public IP and they convinced me they were trustable as far as security was concerned, I'd happily give them as many of the deallocated public addresses as they needed, and noted them down carefully. After a few months, those allocations would be reassessed.
As far as HP is concerned, something like:
find . -exec perl -pi -e 's/15\.(\d+\.\d+\.\d+)/10.$1/go'
should do the trick! =)
That doesn't change what the guy is saying. NAT prevents another computer from initiating a connection to the internal network, but it doesn't prevent you from being hacked. A clever hacker can hijack existing connections, or convince you to open connections that aren't friendly.
For example: you browse to www.ima.hacker.net. The page has code to exploit a browser vulerability, and the exploit code initiates a connection back to www.ima.hacker.net.
Another problem is connection hijacking -- a hacker can send extra packets to a firewall that actually get through because they are marked as being from the same port and address as those of a real connection. This is especially easy if the hacker is able to sniff packets en route.
Yes, being behind a NAT does reduce the risk of attacks: you probably only have to secure your client apps, not your server apps. But clients are vulnerable, too.
Overall, IPv6 will be far more resistant to hacking. The designers had the wisdom of many years of IPv4 problems and security flaws to influence the design. Now it is much harder to spoof a packet. Now you can't sniff packet ID numbers. Any advantage that you are currently attributing to NAT can be gotten with a firewall, and much more reliably.
Can't wait can't wait can't wait.
Time flies like an arrow. Fruit flies like a banana.