The mandatory presence of IPsec in IPv6 is a great step for security in the Internet. But there are some areas where IPsec cannot easily be combined with other services:
Tunneling, a fundamental element of both IPsec and multiple transition mechanisms, creates difficulties for existing firewalls and security gateways at the edge of the internal network. An encrypted IPsec tunnel built through a firewall providing end-to-end security for hosts on either side makes it impossible for the firewall to detect dangerous or unauthorized content. To solve this issue, the SAs have to be defined between the security gateways, not between the end nodes. Another issue is that the inner packet can contain information that presents a threat for the internal network. This could be routing information or network control messages (e.g., ICMP redirect).
A similar problem exists when using NATs, which we all know are very common, especially in places where we would like to use IPsec (e.g., access to the company network from home or from a hotel/airport). NAT does address translation and, in many cases, port translation in the IP header. This creates a problem when authentication and/or encryption are used. RFC 3947, "Negotiation of NAT-Traversal in the IKE," provides a solution for IKEv1. IKEv2 includes improved NAT traversal support. Some vendors offer proprietary solutions. In the future, when we create IPv6 networks without NAT, this issue will go away.
Quality of Service (QoS) allows a router to discard packets based on information in certain fields (e.g., Class and Flow label). Packet loss is a security violation with IPsec. This situation can lead to a certain service being unable to get established (e.g., IKE exchange).
The extended mobility options with constantly changing IP addresses can lead to situations that are difficult to manage and control in IPsec environments. Dynamic addresses create difficulties if they are used for IKE identity checks.