You might not be implementing it yet but IPv6 is going to happen one day, so we’ve decided to take a look at what it offers and how it looks. In this article we’ll start with the how the packets are structured and some of the options you can use.
Unlike IPv4, which has variable sized headers depending on options, the IPv6 header is a fixed 40 bytes. With a fixed length, the header can be read in hardware, speeding up processing. Options are catered for using separate Extension headers, which in the main routers don’t need to process, since a lot more functionality is pushed onto the IPv6 end station.
Most of the header is addressing information - 32 bytes are needed for the source and destination IP addresses. So from the familiar IPv4 header, we no longer have Header Length (not needed now), the Identification, Flags and Fragment Offset fields, or the Header Checksum. Removing the checksum again speeds up processing and the decision was made that since there’s a checksum at the transport layer, it’s not really needed here anymore.
The other three fields have vanished since IPv6 no longer caters for fragmentation at the router. That’s not to say it can’t be done, but it’s now the responsibility of the sending host to figure out the max MTU across a path and fragment accordingly - the routers won’t do it for you. There’s a Path MTU Discovery process to handle this, which will mean that you’ll need to ensure that your network doesn’t filter out the ICMP packets needed for this to work.
Of the fields left in, the TTL has become a Hop Limit field, which makes more sense since that’s how it’s used anyway - it works exactly the same, with each router decrementing the value by one. The Protocol field is now Next Header, and it’s this field that tells you if there is an Extension Header following, or if it’s straight into an upper layer protocol - TCP, ICMP etc - using the same protocol values as in IPv4. Payload Length now no longer includes the length of the IP header (though does include the length of any Extension Headers) and Type of Service is now called TrafficClass.
There’s one new field - the Flow Label. This is to allow groups of packets belonging to the same flow, and requiring the same treatment, to be identified so that each packet doesn’t have to be processed separately. It is designed, particularly, to aid real-time traffic handling.
To allow for any other options, IPv6 has the concept of Extension Headers. There are several defined and one or more can be used in any packet, as long as they appear in the order given below:
- Hop-by-Hop Options header
- Hop-by-Hop Options header
- Destination Options header
- Routing header
- Fragment header
- Authentication header
- Encapsulating Security Payload header
Apart from the Hop-by-Hop header, these headers are processed only by the destination station -intervening routers don’t have to bother with them, so can move things along more quickly. The only slightly odd one in this respect is the Destination Options header, which may also appear right at the end - IPv6 is designed to improve mobility operations, so the destination IP address in the IPv6 header may not actually be the final destination for the packet. This information will be included in the Routing header, which will be read by the station with that destination address, and swapped in before the packet is sent off again. So you can have two Destination Options values - one for the intermediate destinations and another for the very final resting place of the packet.
The Fragment header, as discussed, lets end stations fragment packets down to fit the path MTU size, while the Authentication and ESP headers basically provide IPSec authentication and integrity within the IPv6 packet itself - we’ll cover this in more detail in a later article, as this could have a significant effect on current VPN implementations.
We’ve already said that IPv6 addresses are now 16 bytes long, rather than the familiar 4, so they’re certainly not going to be as easy to remember. We’ll cover all the intricacies of addressing in IPv6 Addressing, but just to give you a flavour - a couple of significant changes:
First off, there will be no broadcast address any more - good news for anyone who has suffered the joys of a broadcast storm! Instead we have unicast, multicast and ‘anycast’ addresses.
IPv6 addresses are made up of a general routing prefix (a range of addresses to identify a site may be allocated by your ISP) a subnet ID (well, at least that sounds familiar) and an interface ID. So far so good. Now the fun bit - an interface can be assigned multiple addresses (ok, like secondary addressing?) of ANY type ie unicast or multicast. So a source can be a multicast. And the same address can be assigned to more than one interface to allow load sharing (goodbye HSRP/VRRP?).
And just to finish off - the address is expressed in hex, not decimal, so an IP address will look something like FE80:0000:0000:0000:0202:B3FF:12CD:5432
Confused yet? Watch for the next article where we’ll explain.