As can be immediately seen in Figure 1, the IPv6 header is much simpler and makes for a leaner protocol which leads to more efficient processing claims Graziana (2013). Both header versions use the initial version field to state the packet version, ipv4 or ipv6. IPv4s second field then states its header length as this can vary depending on the number of options. In comparison IPv6 headers are of a fixed 40-byte length and any additional options are referred to as header extensions and are referenced by the 8 bit “Next Header” field. The third field in the IPv4 header is the Type of Service (ToS) field which helps to provide IPv4 with a Quality of Service (QoS) feature, however RFC 2474 (1998) states that this field was not widely used and therefore was redesigned to use a technique called Differentiated Services Code Point (DSCP).
The American Registry for Internet Numbers (ARIN) is one of the five delegated authorities for controlling the allocation of IPv4 addresses and Hogg (2015) observes that they will soon announce that all their IPv4 addresses are used up. Sword (2016) adds that the Regional Internet Registry for Europe (RIPE) is now rationing their allocation to 1024 addresses per applicant. Sword (2016) claims that in the UK both Sky and British Telecom have announced the completion of their roll-outs to IPv6 and all their broadband lines will now support IPv6. Request for Comments (RFC) 791 (1981) defines the IPv4 header whilst RFC 2460 (1998) defines the IPv6 header.
In IPv6 Hagen (2014) observes the DSCP field is implemented using the now defunct traffic class field and renamed Differentiated Services (DS). This is used by DiffServ routers to determine the Quality of Service (QoS) of packets. IPV6 provides for a lot more traffic class granularity as it uses 6 bits compared to IPv4’s 3 bits. RFC 3168 (2001) specifies the final 2 bits of the IPV6 DS field (shown in Figure 2) as being used for Explicit Congestion Notification (ECN) and this enables end to end congestion control between two endpoints.
In IPv6 the third field is used for a new purpose which is one of Flow Control. RFC 6437 (2011) states that a flow is a sequence of packets sent from a source to a particular unicast, anycast or multicast destination.In IPv4 the traditional way of maintaining a flow is by using the 5 fields,source address, destination address, source port, destination port and protocol. In IPv6 however some of these fields may be unavailable due to encryption or fragmentation or it may prove inefficient locating the fields behind a raft of IPv6 extension headers RFC 6294 (2011) explains that due to confusion of its use it has not proven successful and therefore 20 bits are unused in most IPV6 headers however it does go on to explain some possible uses.RFC 3697 (2004) considers the security aspects of the flow label claiming it is not protected in any way and can be forged by a potential attacker. Hagen (2014) claims that companies are now finding uses for this flow control field which enable efficient IPv6 flow classifications. The flow label can be used by a source to label a set of packets belonging to the same flow. A flow is identified by the source address and a non-zero flow label. When routers receive the first packet of a new flow they can route all other packets belonging to the same flow faster by using cache memory.
The fourth field of both the IPv4 and IPv6 header states the total length of the IP packet and as this is a 16-bit field the maximum length of an IPV4 packet is 65635 bytes however an important difference is that whilst the IPv4 packet size includes the header packet, the IPv6 packet size is the payload portion alone.Furthermore, in IPv6, a Jumbogram extension header allows for packet sizes upto 4,294,967,295 bytes however RFC 2675 (1999) requires that all nodes in a network must be configured to accept Jumbograms.
The fifth,sixth and seventh field in IPv4 are used for packet fragmentation and assembly.They decide whether packets can be fragmented or not and if a packet has been fragmented then which fragment of the overall packet it is and whether further fragments are to come.
The fifth field of the IPv6 header is the “Next Header” field and serves 2 purposes. When there are no extension headers it serves a similar purpose to that of the IPv4 Protocol field whereby it states the protocol of the payload. These protocols are assigned a number and defined in RFC 1700 (1994). Supriyanto, Murugesan & Ramadass (2012) explain that in IPv6an extension header can be used for fragmentation however this opens vulnerabilities that do not appear in IPv4. Attackers can bypass filtering systems and are easily able to predict fragment identification fields.
Cisco (2006) state where Extension headers have been used then the “Next Header” field links to the first extension header as shown in Figure 3. RFC 2460 (1998) defines the extension headers as shown in Appendices Table 4 and 5 along with the Next Header values assigned to them. IPv6’s Extension Headers allow for the future growth of the internet claim Supriyanto, Murugesan & Ramadass (2012) who go onto explain that the most important feature is mandatory support for IPSEC in the authentication header to ensure security. They clarify this by explaining that whilst the IPSEC protocol is mandatory, its use is optional.
Hagen (2014) explains that the sixth field of the IPv6 header is the “Hop Limit” field and this performs a similar function to the IPv4 “Time to Live” (TTL) field whereby if a router decrements this field to zero then the packet is dropped. Additionally, in IPv6 an ICMPv6 Time Exceeded message is sent to the source to inform it the packet was dropped. The IPV4 Header Checksum field uses a Cyclic Redundancy check(CRC) to provide protection against corruption in transit. In IPV6 this field has been moved into the extension headers.
The final 2 fields in both the IPv4 and IPv6 headers are the Source and Destination fields which in the case of the source field contains the IP address of the originator and in the destination field contains the IPaddress of the final destination. Because these IPv6 fields (128 bit) are 4 times larger than their IPv4 (32 bit) counterparts the number of IPv6 addresses available are over 320 undecillions, i.e. 10₃₆.
warn that there is a possibility that many extension headers or very large
extension headers can create a DDOS attack overrunning the hardware resources
Comments are closed.
Star Trek Exhibition
I truly appreciate all your work, we simply would not be open without you and I know Paul Gregg(Sponsor) wanted to pass on his thanks as well. Richard Brundle, Star Trek Exhibition