People say that IPv6 is safer and faster than IPv4. The reality can be very different. Why?

1) IPSec
People say that IPv6 is more secure than IPv4 because IPSec is mandatory with IPv6.
First, the use of IPSec is not mandatory. The IPv6 node requirements are changing, and one of those changes is reducing IPsec from a MUST to a SHOULD, see <http://tools.ietf.org/html/draft-ietf-6man-node-req-bis-11#section-11>.

But that still does not mean that every IPv6-capable router and IPv6-capable switch implements IPsec.  High end core routers don’t implement IPsec.  IPSec may not be found on some cheap CPEs as well.

IPSec makes sense between CPE routers interconnecting remote sites through a public network, whether this public network is providing a level 1 (i.e. SDH),  a level 2 (i.e. ATM) or a level 3 (MPLS-VPN, IPv4 or IPv6) service.

IPSec also makes sense between hosts but for lots of reasons, hosts use mostly ssh, TLS, or other non-IPsec security mechanisms.

2) Transition to IPv6: tunnels, translation, dual-stack

2.1) Tunnels

- Currently IPv6 is mostly provided thanks to transitions methods. This means that your IPv6 traffic may get through an IPv6 in IPv4 tunnel to reach its destination. This extra encapsulation process is not free regarding performances (bandwidth, delay).

- IPv6 in IPv4 Tunnels are easy targets for attacks by…

packet injection or reflection. For instance, the 6to4 relays receive IPv6 traffic encapsulated in IPv4. They accept IPv4 packets from any source, decapsulate the IPv6 packets and then forward them to their IPv6 destination. With the automatic tunnels there is absolutely no control on the IPv4 source address of the packet received by the relay because it could come from any remote site. RFC3964 describes the security considerations for 6to4.

So any traffic using such tunnels cannot be safer or faster!

Even if some tunnels methods may allow providing better security than others.

- Also, IPv6 traffic encapsulated in IPv4 cannot be inspected by Firewalls unless the firewall is itself the tunnel tail-end or head-end. If the firewall is in the middle of a tunnel path, it can only inspect the external IPv4 encapsulation header, not the IPv6 header inside the encapsulated packet.

And when tunnels are not involved, translation may occur at some points.

2.2) Translation (NAT)

- Translation means that your initial DNS resolution for the source host may require twice more packets to get done.

- Also the DNS64 translation between the A record for IPv4 and the AAAA record for IPv6 can be the target of a DoS attack. The attacker just needs to flood the network with DNS requests requiring a translation to overwhelm the DNS64 translator.

- Then, a router in the path will also have to translate the IPv6 header to IPv4 and IPv4 to IPv6. This translation process may use a pool of addresses for bindings (i.e. Stateful NAT64). When the addresses of this pool get exhausted, there is no more translation possible and one side of the network is no more reachable from the other side. An attacker may send a lot of packets to consume the whole pool. Other DoS attacks may consume the NAT device memory by sending a lot of fragments or a lot of TCP SYN. For more details about these attacks see “Section 5.3. Attacks on NAT64” in this document:
http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful-12

Very clearly, the traffic which needs protocol translation cannot expect better performance or better security than the native IPv4 or IPv6 traffic!

3) IPv6 and dual-stack
IPv6 protocols stacks are newer and may contains more bugs than IPv4.
The IPv6 Firewalls software are also newer and may contain less security features than their IPv4 counterparts.
Finally, you must ensure that both protocols receive the same level of security

3) SEcure Neighbor Discovery (SEND rfc3971, CGA rfc3972)

The threats on IPv6 Neighbor Discovery are well described in rfc3756.

SEND is a great protocol to secure the IPv6 Network access. But unfortunately, SEND is currently only implemented on CISCO IOS and Linux.

SEND basically secures all the Neighbor Discovery protocols PDUs, introduces Cryptographically Generated Addresses and X.509 Certificates for routers.

With SEND your IPv6 address cannot be spoofed by anyone! Your IPv6 address may be be stolen but it is useless if you don’t have the key associated with the address! This is the Cryptographically Generated Addresses or CGA rfc3972.

With SEND, when you receive a Router Advertisement (RA) about a router claiming it is your default router, you first check if you have a certificate for this router. If the host don’t have such certificate yet, it will ask for it using new SEND messages. Then this certificate must come from a Certificate Authority that the host can trust. In other words, it is impossible for a rogue router to initiate a man-in-the-middle attack pretending it is your default router. This is Authorization Delegation Dicovery (ADD).

SEND would give the security advantage on IPv6 but it is not currently available for Windows or MAC OS !

The conclusion is that as long as we need transition to IPv6 tools, we cannot expect better security and better performance than with native traffic.