IPv6 was designed to be an evolution of IPv4, introducing several improvements and simplifications to the packet header structure, while expanding functionality and address space.
Some fields that were present in the IPv4 header were removed or modified in IPv6.
Here are the main fields that were removed or significantly changed in the jump from IPv4 to IPv6:
- Header Checksum:
- IPv4: It includes a checksum field that helps ensure the integrity of the packet header.
- IPv6: This field was removed in IPv6. The integrity of the header is assumed to be ensured by other levels, typically by higher layers such as TCP or UDP, which have their own checksums.
- Fragment Identification, Flags, and Displacement:
- IPv4: These fields are used for packet fragmentation and reassembly.
- IPv6: In IPv6, fragmentation is not performed by the routers on the route. Instead, fragmentation is handled by the sending device and requires the use of a fragmentation extension header when necessary.
- Options:
- IPv4: The IPv4 header has an options field that can be used to support additional functions.
- IPv6: There is no options field in the IPv6 base header. Instead, IPv6 uses extension headers, which are inserted between the base header and the payload when additional functionality is needed.
- IHL (Internet Header Length):
- IPv4: The IHL field indicates the length of the IPv4 header, allowing variable size headers due to the options field.
- IPv6: The length of the IPv6 base header is fixed (40 bytes), therefore the IHL field was removed.
- Type of Service (now DSCP and ECN in IPv4):
- IPv4: Originally called “Service Type”, this field has evolved to incorporate DSCP (Differentiated Services Code Point) and ECN (Explicit Congestion Notification).
- IPv6: It introduces the “Traffic Class” field, which is similar to IPv4 DSCP to handle differentiated services and also supports ECN.
These changes reflect a design focused on simplifying packet processing in routers and improving support for functionalities such as quality of service and security without compromising the extensibility and flexibility of the protocol.
There are no tags for this post.