Why should IPv6 be any different from IPv4 in this regard? IPv6 and IPv4 are simply the means of carrying data around the internet. The vulnerabilities are in the various servers and apps etc. One thing IPv6 has going for it is it's much harder to find a target, unless you're in a position where you can find addresses in use. Simply port scanning a block of addresses, in hopes of finding a target, is not feasible with IPv6. Your question would be comparable to asking whether paved or gravel roads are better, when discussing front door locks.
Good point. So it's quite unlikely that a problem/flaw will only exist in the ipv6 stack and not the ipv4 stack for the application layer. What about exploiting lower layers on the network then? Malformed headers intentional or unintentional causing OS network/routers/switchs to buffer overload etc?
The exact same problems occur with IPv4 and other protocols. It has nothing to do with IPv6 or IPv4. Years ago, there were other protocols in common use, such as IPX and the old NetBIOS, among others. They've all experienced that sort of problem. Another advantage to IPv6 is that IPSec is part of the package, whereas it or other VPN had to be added to IPv4.
James - You are correct, brute force scanning of IPv6 addresses is a Fail. I had a customer call me, to tell me that someone was bruteforce scanning their network. We calculated the speed of the scan and the location of his first host, making the first device discovery sometime in 2050. There are other techniques which I document in past IPv6 security presentations located : http://sites.google.com/site/ipv6security/
I'm afraid I would tend to disagree somewhat. Migrating the codebase of an application provides an opportunity to introduce new bugs and potentially new security flaws by logical extension. In practice I expect the most common security issue resulting from this to be in simple ACL implementations, but more serious issues may also be introduced. That said, software is constantly developed in comparably drastic ways, so it could be said that 'it happens'. :-)
The information and tools mentioned on this page certainly demonstrates the newness of ipv6 and opportunity for exploitation. Entire operating systems have been vulnerable to ipv4 based attacks since their inception, many such expoits were identified only recently. This makes perfect sense since these protocols are rarely directly manipulated and new implementations of them (new products) are being developed every day. Any blatent flaws in ipv6 may exist unnoticed for years, but considering it has been subjected to a battery of peer review for years (in varying extents depending on the standard in question) it should be considered to be, in itself, safe. Any implementational flaws causing poor security or threat of dos are simply the problem of the source vendor and, unfortunately, the users thereof. (Sorry guys.)
But for what it is worth, we did our very best to make certain ipv6 is if anything more resilient than its predecesor.
Given that there's no security in IPv4, how can IPv6 be worse? How much has to be changed in an application to make it work over IPv6, other than address size? I thought that one of the ideas behind protocol stacks was to isolate the effects of changes in one layer affecting another.
I don't mean to suggest the security is inherently worse, only that when the mechanics of transport are changed, opportunities for exploitation may arise in certain applications.
Even with only a larger address size, issues may arise within applications which hash or otherwise key on the addresses.
Second Life is a popular immersive world game of sorts which, at the application protocol level, keys on addresses of nodes within the world (sims).
The Syllable OS TCP stack does the latter by hashing the IP addresses and ports of established TCP connections, which is insecure on both IPv4 or IPv6, but substantially easier to exploit with the latter. This bug has never been reported, probably because nobody has investigated this source code extensively.
On the pattern of this, swarming protocols such as bittorrent often communicate between totally foreign clients; for example, "deluge" and "transmission" are two different clients which may or may not have special provisions for communicating with each other. Transmission supports IPv6 entirely, so far as I can tell, but I have no idea if Deluge does. If my Transmission client sends a DHT notification (basically, a peer message,) to the Deluge client, it may expect an IPv4 address within the message. If it is improperly written to do something like this: "uint32_t addr; memcpy( &addr, &dhtmsg->addr, dhtmsg->addrlen );" the program will probably crash. Still, this is a potential window for code injection.
I don't believe at all that this is in any way the fault of IPv6 as a protocol. In these examples it is simply oversight by the developers. Reopening or changing code always has a tendency to "rock the boat", and especially considering how comfortable the average developer (or network admin) is with IPv6, they probably won't get it right the first time, but merely get it -working-, and this is where things get dangerous.
As I said, I find it unlikely (but not impossible) that inherent problems exist in any defining standard of IPv6, but I have no doubt that flaws are present in existing IPv6 implementations beit at the infrastructure level, operating system level, or application level.
After reading through this article though, if anything, IPv6 makes such attacks substantially more difficult. The best attack to derail an IPv6 network is probably boltcutters. The next best would be congestion, and that's the staple of IPv4 attacks.
As for MiM, cloning, etc., it's certainly more difficult with IPv6, but largely still possible I think, and I doubt that will ever change. Not that it would be impossible, but to cover every possible contengency at the protocol level would be impractical. A managed switch does wonders.
I must agree, problems exist at all levels of the specifications, implementation, architecture, deployment and operations. It is about the same with IPv4, the difference very few of us have been working with the IETF and Vendors to fix the problems.