That is exactly why I wanted IPv6 - to allow me to learn about new technology. I had had some exposure to IPv6 starting in 2006 when Vista came out as IPv6 was used by default for link local communications of certain types. IPv6 was mandatory for the newer versions of Windows Messenger which had to get the o/s to fire up Teredo if IPv6 was absent, just to make IPv6 available, and the newer Windows Messenger app would not run over IPv4.
That is why Zen lost out in competition with AA in attracting me, because Zen dragged their heels for year after year after year and IPv6 only came available after an eternity something like five or six year, incredible, and I had long since given up on them because I wasn’t willing to wait. AA has had IPv6 since 2002, so I read in their website somewhere.
IPv6 is slower over the internet unfortunately and I am not sure why, from testers I have used, and the bloat for the additional header size is a bit too small to account for the difference that I have seen in the reported figures. It is however rock solid, as there is no possibility of failures due to DHCP bugs or kit failing when the network powers up if birds decides are relying on a DHCP IPv4 server and there is a random race to see who can boot up first. Of course you could have the same vulnerability with DHCPv6, but who uses that - it is completely unnecessary in the usual case. DHCP just sometimes goes wrong, if clients go to sleep then there can be DHCP problems. DHCP is a major security threat to unless you have the right advanced kit to defend against attackers. Also NAT is evil in my opinion and it is so difficult to get proper end-to end communications across networks with IPv4 as many users do not have proper routable IPv4 addresses but with IPv6 things tend to be done correctly. These things are not inherent to IPv6 vs IPv4 and IPv4 can be done such that proper addresses are used, no NAT and no reliance on DHCP.
IPv6 zeroconf startup and choosing of all IP addresses for yourself is rock solid, it just always works. MAC-based addresses are fail proof and the alternative method, random address generation works without problems.
IPv6 networking subsystem also tend to do a whole load of things using better techniques and practices since a lot of rethinks were stimulated around the time of IPv6 design, helpful best practice RFCs. Microsoft’s Vista IP subsystem applied all the new good practices that were in use for IPv6 to IPv4 as well, treating them both in the same way in many respects. IPv6 subsystems are better simply because it is a new fresh start in design, and as I said in some systems these code improvements spread to IPv4 too. So if ‘IPv6’ sometimes is more solid it is actually the code that is better, not the protocol itself.
So I would say that IPv6 can be more solid in terms of autoconfig working ok even in problem situations. IPv6 security is not at all better, because even if the problem DHCP server is gone, there are potential threats from bogus RAs. IPv6 security in respect of LAN-internal malefactors is something that has been shamefully ignored and is a problem in waiting. Neighbour Discovery (ND), the IPv6 name for the new version of ARP, is just as much a problem area as ARP is. The secured proposal for an upgrade to ND, SEND (RFC 3971) has not been deployed widely at all and I don’t know if this is because of problems with it or just ignorance or apathy. IPv6 certainly has its share of security problems relating to LAN-internal rogues and things have not got better, possibly the reverse. (I have been reading a book on IPv6-specific security issues.)
It is interesting that some corporates have now got rid of IPv4 completely for their internal stuff. Microsoft is one example, has got rid of IPv4 on large parts of their corporate network. Their wireless LANs including their guest SSID are IPv6-only. A lot of stuff has been found to fail because it works over IPv6 yet has occasional reliance on IPv4 facilities being there. So going from ‘dual stack’ (hate that term), ie 6 and 4, to IPv4-free is a real challenge.