« previous 1 2 3 4 next »

Simple Headers

With the IPv4 protocol, routers have to verify checksums and fragment packets. While this is generally not much effort, the enormous throughput of current connections does require considerable computing power. Both the fragmentation and IP header checksums have been dispensed with in IPv6. Only the TCP header carries a checksum. Therefore, it is up to the recipient to recognise flawed packets, and to request the respective packets again from the sender.

In IPv6 headers, address fields are on 64-bit bounaries. This streamlines router computing and promises higher throughputs.

Due to the lack of fragmentation, routers now generally need to discard oversized packets and inform the sender about these errors via ICMP messages. The sender will in turn reduce the maximum packet size for this route (MTU, Maximum Transmission Unit). In IPv4, this Path MTU Discovery procedure is optional, and an IPv4 server needs to set the don't-fragment bit in order to utilise it.

If the router's error message sent via the ICMP block is lost along the way, for example due to a flawed firewall configuration, Path MTU Discovery fails. In these very rare cases, the sender has to use the smallest possible MTU. With IPv4, this MTU is only 68 bytes. This strategy needlessly increases the percentage of admin information for routes which generally allow larger MTUs, and the connection is consequently not used to its full capacity. This effect is reduced drastically in IPv6 as all IPv6-compliant devices must be able to handle a minimum packet size of 1028 bytes. Like IPv4 they can, of course, also transport smaller packets.

In IPv6, header length is no longer variable and the address fields are limited to 64 bits (64-bit alignment). This saves router capacity and allows higher throughputs. Flags like the don't-fragment bit are no longer transmitted as part of the header, but are now transmitted as options between the IP layer and UDP/TCP instead.

Flexible addresses

With Mobile IPv6, devices like laptops can be connected using their local IP addresses wherever they are, for example at conferences or at any WiFi hotspot. For this purpose, IPv6 was equipped with an ICMP redirect message that the laptop at the conference can use to inform its home agent about which IPs it is using for its connection. The agent will then redirect any incoming connections.

Security experts will probably be alarmed by this scenario as it is feared that crackers could intend to maliciously redirect some important financial website. Therefore, the agent can't just comply with requests for redirection, and the administrator has to ensure correct authentication via encryption. IPv6 offers adequate encryption via IPsec (RFC 2411). Although already available in IPv4, IPsec is here used mainly in tunnel mode VPNs rather than for point-to-point connections, as in IPv6.

In the free software scene, IPv6 has been widely adopted. There is a good range of IPv6-compliant applications. Although only name servers and various tools like Ping or Traceroute were available initially, programs now also include web servers, browsers and mailers, and practical IPv6 skills can be developed at least within the LAN.

IPv6 is worthwhile in a LAN environment since it doesn't involve broadcasts which can provoke high network loads. Any transmissions handled via broadcast under IPv4 can be handled via multicast. This causes neighbour discovery packets in large switched Ethernets to be transmitted on the strands used by the host only.

« previous 1 2 3 4 next »