IPv6 Datagram Format
IPv6 datagram format is shown in the figure below.
Now, let us discuss the changes by analysing the IPv6 datagram format :
Expanded addressing capabilities
IPv6 increases the size of the IP address from 32 to 128 bits. This ensures that the world won’t run out of IP addresses.
Now, every grain of sand on the plant can be IP-addressable. In addition to unicast and multicast addresses, IPv6 has introduced a new type of address, called an anycast address, which allows a datagram to be delivered to any one of a group of hosts. (This feature could be used, for example, to send an HTTP GET to the nearest of a number of mirror sites that contain a given document.)
A streamlined 40-byte header
A number of IPv4 fields have been dropped or made optional. The resulting 40-byte fixed-length header allows for faster processing of the IP datagram. A new encoding of options allows for more flexible options processing.
Flow labelling and priority
IPv6 has an elusive definition of a flow. RFC 1752 and RFC 2460 state that this allows “labelling of packets belonging to particular flows for which the sender requests special handling, such as nondefault quality of service or real-time service.” For example, audio and video transmission might likely be treated as flow. On the other hand, the more traditional applications, such as file transfer and e-mail, might not be treated as flows. It is possible that the traffic carried by a high-priority user (for example, someone paying for better service for their traffic) might also be treated as a flow.
What is clear, however, is that the designers of IPv6 foresee the eventual need to be able to differentiate among the flows, even if the exact meaning of a flow has not yet been determined. The IPv6 header also has an 8-bit traffic class field. This field, like the TOS field in IPv4, can be used to give priority to certain datagrams within a flow, or tic can be used to give priority to datagrams from certain applications (for example, ICMP) over datagram from other applications (for example, network news).
This 4-bit field identifies the IP version number. Not surprisingly, IPv6 carries a value of 6 in this field. Note that putting a 4 in this field does not create a valid IPv4 datagram.
This 8-bit field is similar in spirit to the TOS field we saw in IPv4
This 20-bit field is used to identify a flow of datagrams
This 6-bit value is treated as an unsigned integer giving the number of bytes in the IPv6 datagram following the fixed-length, 40-byte datagram header.
This field identifies the protocol to which the contents (data field) of this datagram will be delivered (for example, to TCP or UDP). The filed uses the same values as the protocol field in the IPv4 header.
The contents of this field are decremented by one by each router that forward the datagram. If the hop limit count reaches zero, the datagram is discarded.
Source and destination addresses
The various formats of IPv6 128-bit addresses are described in RFC 4291.
This is the payload portion of the IPv6 datagram. When the datagram reaches its destination, the payload will be removed from the IP datagram and passed on to the protocol specified in the next header field.
Fields no longer present in IPv6
We shall see that there are a few fields that exist in IPv4, but are no longer present in IPv6.
IPv6 does not allow for fragmentation and reassembly at intermediate routers; these operations can be performed only by the source and destination. If an IPv6 datagram received by a router is too large to be forwarded over the outgoing link, the router simply drops the datagram and send a “Packet Too Big” ICMP error message back to the sender.
The sender can then resend the data, using a smaller IP datagram size. Fragmentation and reassembly is a time-consuming operation; removing this functionality from the routers and placing it squarely in the end systems considerably speeds up IP forwarding within the network.
Because the transport-layer (for example, TCP and UDP) and link-layer (for example, Ethernet) protocols in the internet layers perform checksumming, the designers of IP probably felt that this functionality was sufficiently redundant in the network layer that it could be removed. Once again, fast procession of IP packets was a central concern. Since the IPv4 header contains a TTL field (similar to hop limit in IPv6), the IPv4 header checksum needed to be recomputed at every router. As with fragmentation and reassembly , this too was a costly operation in IPv4.
An options field is no longer a part of the standard IP header. However, it has not gone away. Instead, the options field is one of the possible next headers pointed to from within the IPv6 header. That is, just as TCP or UDP protocol headers can be the next header within an IP packet, so too can an options field. The removal of the options field results in a fixed-length, 40-byte IP header.