Is data always encrypted in IPv6 communications?

Solution 1:

No.

IPv6 has IPsec built-in as part of the protocol, and it's not a bolt-on as it is with IPv4. However, this doesn't mean it's enabled by default, it just means it's a (theoretically) lower overhead on the network stack.

Generally, IPsec usage is determinated at the IP-level of the network stack, and therefore determined by the system policies itself. e.g. System A might have a policy that requires both AH and ESP to have any communication with the 4.0.0.0/8 subnet.

Update: to be clear, the application doesn't care - it just knows it has to open a network connection somewhere and send/receive data down it. The system then has to figure out whether to negotiate IPsec for the given requested connection. IPsec is very much designed to be a low-level authentication/encryption mechanism and is purposefully built so that higher-level protocols and applications don't have to worry about it.

That said, it's just another network-level security control, and shouldn't necessarily be used in isolation or relied upon to guarantee 'security' - if you're trying to solve and authentication problem, it's entirely possible that you'd want the application to enforce some sort of user-level authentication whilst leaving machine-level authentication down to IPsec.

Solution 2:

Short answer: No.

Long answer: IPsec was considered when designing IPv6, in the sense that, unlike in IPv4, IPsec (when used) is part of the IPv6 header.

More explanation: in IPv4, IPsec runs on top of IP itself. It's actually a Layer 4 protocol that 'masquerades' as a Layer 3 protocol (so that the usual L4 protocols of TCP and UDP will still be able to work). The ESP (Encapsulating Security Payload) cannot span between IP packets. As a result, IPsec packets usually will have severely reduced payload capacity if fragmentation is prevented. Plus, because it's on top of IP, IP's header is not protected.

In IPv6, IPsec is part of IP itself. It can span packets, since the ESP header is now a part of IP's header. And because it's integrated with IP, more parts of the IP header can be protected.

I hope my 'in a nutshell' explanation is clear enough.

Solution 3:

To you Followup Question:

The operating system defines when to use encryption. These "policy" options are within control panels / configuration policies. You say things like "if you want to connect to any address in subnet ab12:: you must have secret Blah1234". There are options to use PKI.

At the moment an application cannot add to this policy or demand this policy is set up. There is a mention in the linux socket ipv6 section "IPSec support for EH and AH headers is missing. " so people have thought of this but there is currently no known working implementations.

Solution 4:

To your followup question yes and no.

Applications can specify encryption, but the encryption is done at the application level. There are a wide variety of unencrypted/encrypted protocol pairs using different ports such as HTTP/HTTPS, LDAP/LDAPS, IMAP/IMAPS, and SMTP/SSMTP. These all use SSL or TLS encryption. Some services will offer a startTLS option which allow an encrypted connection to be started on the normally unencrypted port. SSH is an application which always uses an encrypted connection. Encryption is end to end for these cases. (There is a NULL encryption algorithm which can be used, and the encrypted content will be transported unencrypted.)

IPSEC is configured by the administrator and the application will not be aware whether or not the connection is encrypted. I have mainly seen IPSEC used to bridge traffic between LANs over unsecured connections (VPN connections). I believe IPSEC may apply to only part of the route, so on some network segments the data is transmitted in the clear (unencrypted).

Given a choice I will use application encryption as network encryption is not heavily used.