So although IPSec is a mandatory part of IPv6, it's not mandatory to use it. It's nice to have seat belts, and having seat belts built in does make it more likely people will use them.
We've been using IPSec for years in IPv4, mostly in VPNs. IPSec was invented for IPv6 and then retrofitted to IPv4, so it is no wonder the mechanics are so similar. IPv6 uses two extension headers (rather than header options) to support IPSec.
The Authentication Header (AH) provides authentication and integrity. An integrity check value (ICV) is calculated over the packet and the result is inserted into the packet as an extension header. The recipient calculates the ICV, and if the received ICV matches the calculated ICV, the recipient knows the message comes from the address that appears to have sent it, it was not altered in transit. However, nothing is hidden — the packet is not encrypted.
Because the source and destination addresses are included in the ICV calculation, AH cannot pass network address translation (NAT). The Encapsulating Security Payload (ESP) header encrypts payloads, hiding them from prying eyes while in transit. The payloads are not transmitted; they are replaced by ESP headers.
The ESP header does ensure the integrity of the payload, but it doesn't guarantee the integrity of anything else, such as the source and destination addresses, or any other headers that may accompany the packet.
The solution? Use both types of header: ESP to encrypt the payload and AH to ensure the integrity of the entire packet.
Internet Control Message Protocol (ICMP)
Many IPv4 network managers block all ICMP. It is a simple and effective way to protect against various attacks. While most well-managed networks are not quit so heavy-handed, it is still quite a common approach. But it's an approach that does not work very well with IPv6.
IPv6 uses ICMPv6 to do critical things like neighbour discovery. Blocking ICMPv6 on an internal interface will interfere with these things. Blocking it on an outside interface, at the border of a network will have a more subtle effect — it will break path MTU discovery (PMTUD).
IPv6 fragments packets only at the source, and reassembles them only at the destination. Fragmentation is done at the edges of the network, making the core faster and more efficient. When a router discovers that it cannot forward a packet because it is too large for the outgoing interface, the router sends an ICMPv6 “packet too big” response back to the source, giving the maximum transmission unit (MTU) that it can support. The source node tries again with that MTU. This is repeated until a packet size is found that is small enough to make it through all intervening routers to the destination.
If anyone along the way is blocking ICMPv6, packets will be dropped, and the sender will have no reason to try smaller packets. By all means block those ICMPv6 types that you don't need — router advertisements on an outside interface, for example. And by all means rate limit those that might otherwise pose a risk — echo requests, perhaps. But block with care!
If you are providing a service that may be affected by other people breaking PMTUD, such as a website, consider setting your outgoing MTU to 1280 - the minimum size that IPv6 supports. You will lose some efficiency, but will be immune to PMTUD failures.