Secure by Default
A few of the changes in IPv6 are relatively simple, just making things that are optional parts of IPv4 compulsory. One of the most interesting is IPsec. This is currently used mainly for VPNs, establishing an encrypted connection between two routers and preventing any intermediate packets from being intercepted.
With IPv6, you can guarantee that any endpoint will support IPsec, which means that you can always establish an encrypted connection. With IPv4, most of the time, you will use SSL for encryption. This operates slightly higher up the protocol stack and requires every application that uses it to be specifically configured to do so.
Currently, IPsec is most commonly used with encryption keys that are shared out of band. One alternative way of using it is to embed a public key that can be used to negotiate an IPsec connection in the DNS records. For this to work, the DNS record itself needs signing with DNSSEC. This is due to be supported on the major root domains over the next few months.
If you do your DNS queries over IPsec, then you can also get the request and response encrypted so no one can tell which sites you are looking up (although your ISP can obviously tell which IP addresses you connect to). Unlike SSL, IPsec works for every kind of connection, including UDP, so things like Voice over IP can benefit significantly from IPv6. The endpoints can connect directly without having to navigate NATs, and the entire connection can be encrypted.
The other addition is multicast. In IPv4, one address on each subnet is reserved as the broadcast address. Packets sent here are delivered to every machine on the subnet. This made a lot of sense when most networks were buses. All packets were broadcast anyway; this just told every receiver to look at them. Sending to the broadcast address was more efficient than sending two copies of a packet if two people wanted to look at it.
With switched networks, this is not the case. Each computer can send and receive a certain amount, and the switch will route these packets between the machines, so four computers on a 100Mbit network can be having two independent conversations at 100Mb/s. If you send a packet to the broadcast address, it's sent to everyone, even people who don't want it.
Multicast is a bit more clever. It defines groups of computers and assigns them a shared IP address. Packets sent to this address are routed to every computer that has opted into the group. Unlike broadcast, multicast packets are routable. You can have lots of computers on different networks in a multicast group and only generate two packets when the source packet reaches a router that has members on two downstream networks. If, for example, you had an Internet radio station using IPv6 multicast, then the station would send one stream of packets to your ISP. Your ISP would send a copy of the stream to each of its customers who were listening. When the packets hit your router, it would send a copy to each machine you have that is listening to the stream.
You can use the same mechanism for things such as conferencing calls. Currently, if you have ten people in a video conferencing session, then either each one needs to stream ten copies of his or hers camera's output, or you need a server somewhere that can handle the relaying. With multicast, everyone would send one copy to ten people. With consumer network connections, which typically have a lot more downstream bandwidth than upstream, this is particularly attractive.
Broadcast is also used when you don't know which computer you should be using[md]for example, for service discovery. IPv6 replaces this use with anycast. Anycast is somewhat like multicast in that a group of addresses is associated with the anycast address, but unlike multicast, a packet sent to that address is only delivered to one machine. This is useful for things such as autoconfiguration.