Let's consider some of the implications of the design of the IPv6 header. There is no field equivalent to the IPv4 options field, so the equivalent facilities are now provided by extension headers. These headers, and the fact that the IPv6 header has no checksum, have some influence on how upper level checksums are calculated. Also, the larger addresses used mean that more of a packet is taken up with headers, so header compression is correspondingly more important.
In Section 3.2.1 earlier in this chapter, we observed that the IPv4 notion of including options directly within the main header had been abandoned. However, IP options did serve a purpose, and that purpose is now achieved in IPv6 using extension headers. These headers are chained together. Within the IPv6 header the Next Header field tells you the type of the next extension header, which in turn has a Next Header and so on. The basic types of header discussed in RFC 2460 are the Hop-by-Hop Options header (type 0), the Routing header (type 43), the Fragment header (type 44), and the Destination Options header (type 60).
To make sure this process of chaining headers together terminates, there are a few special types of Next Header that do not themselves have a Next Header field. These include 6 = TCP, 17 = UDP, 58 = ICMPv6 and the rather odd 59, which means "there is no next header."
For example, Figure 3-5 shows an IPv6 packet containing an IPv6 header, followed by a routing header, ...